- Sound-open-firmware - mailman.alsa-project.org

[Sound-open-firmware] Issues with using qemu emulator
by Tomasz Duszynski 10 Dec '19

10 Dec '19

Hi, I heard about SOF some time ago but did not have time to take a closer look until now. I decided to start with Qemu and stumbled upon some problems. Would be great if someone could take a look at attached logs. Here's component stack I have at the moment: 1. Linux: branch topic/sof-dev, commit 3c39107 ASoC: topology: Check return value for soc_tplg_pcm_create() 2. SOF: branch sof-dev, commit c7d0149 pipeline: fix tasks initialization commit 3. Qemu: branch sof-v4.2 commit 8b66b81 qemu: io-bridge: remind users to start DSP first. I am starting VMs using provided helper scripts i.e xtensa-host.sh and x86-host.sh (run in that sequence). Here's what ./xtensa-host.sh shows: [tdu@home:~/workspace/sof/qemu]$ ./xtensa-host.sh byt ./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -nographic -S bridge-io: qemu-bridge-iram-mem fd 9 region 1 at 0x7fa5d8fd2000 allocated 81920 bytes bridge-io: qemu-bridge-dram-mem fd 10 region 2 at 0x7fa5c988e000 allocated 163840 bytes bridge-io: qemu-bridge-dmac0-io fd 11 region 3 at 0x7fa5d900f000 allocated 4096 bytes bridge-io: qemu-bridge-dmac1-io fd 12 region 4 at 0x7fa5d8fd1000 allocated 4096 bytes bridge-io: qemu-bridge-ssp0-io fd 13 region 5 at 0x7fa5d8fd0000 allocated 4096 bytes bridge-io: qemu-bridge-ssp1-io fd 14 region 6 at 0x7fa5d8fcf000 allocated 4096 bytes bridge-io: qemu-bridge-ssp2-io fd 15 region 7 at 0x7fa5d8fce000 allocated 4096 bytes bridge-io: qemu-bridge-shim-io fd 16 region 8 at 0x7fa5d8fcd000 allocated 4096 bytes bridge-io: qemu-bridge-mbox-io fd 17 region 9 at 0x7fa5d8fcc000 allocated 4096 bytes bridge-io-mq: added /qemu-io-parent-byt bridge-io-mq: added /qemu-io-child-byt ** Baytrail Xtensa HiFi2 EP DSP initialised. ** Waiting for host to load firmware... bridge-io: 0 messages are currently on child queue. QEMU 4.1.93 monitor - type 'help' for more information (qemu) bridge-io: msg recv 0 type 1 size 20 msg 32 msg: id 0 msg 32 size 20 type 1 bridge-io: msg recv 1 type 1 size 20 msg 32 msg: id 1 msg 32 size 20 type 1 bridge-io: msg recv 2 type 1 size 20 msg 32 msg: id 2 msg 32 size 20 type 1 cpu: running irq: SHIM_IMRLPESC masking 0 mask 0 active 0 irq: SC send busy interrupt 0xc2 irq: SHIM_IMRLPESC masking 1 mask 1 active 0 irq: SHIM_IMRLPESC masking 0 mask 0 active 0 irq: SC send busy interrupt 0xc5 irq: SHIM_IMRLPESC masking 1 mask 1 active 0 irq: SHIM_IMRLPESC masking 0 mask 0 active 0 IRQ: from DMAC 0 status 0 block 0 tfr 0 IRQ: from DMAC 0 status 0 block 0 tfr 0 irq: IMRD masking 0 mask 0 active 0 irq: PIMR masking 0 mask 38 active 0 IRQ: from DMAC 1 status 0 block 0 tfr 0 IRQ: from DMAC 1 status 0 block 0 tfr 0 irq: send busy interrupt 0x80000000 bridge-io: msg send: 0 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 3 type 2 size 16 msg 64 msg: id 3 msg 64 size 16 type 2 IRQ: from HOST status 1 mask 0 active 1 cmd 0 irq: IMRD masking 1 mask 1 active 0 irq: IMRD masking 1 mask 0 active 1 bridge-io: msg recv 4 type 2 size 16 msg 64 msg: id 4 msg 64 size 16 type 2 IRQ: from HOST status 2 mask 0 active 2 cmd 0 irq: IMRD masking 2 mask 2 active 0 dma: 0:0: start SAR 0xd8f7000 DAR 0xff30c338 size 0x28 DMA req: src 0xd8f7000 dest 0xff30c338 size 0x28 bridge-io: msg send: 1 type 5 msg 96 size 56 ret 0 bridge-io: msg recv 5 type 5 size 56 msg 97 msg: id 5 msg 97 size 56 type 5 bridge-io: qemu-bridge-dmac:0.0 fd 20 region 16 at 0x7fa5d8fcb000 allocated 40 bytes IRQ: from DMAC 0 status 2 block 1 tfr 0 IRQ: DMAC 0 set DMA req complete: src 0xd8f7000 dest 0xff30c338 size 0x38 bridge-io: msg send: 2 type 5 msg 98 size 56 ret 0 IRQ: from DMAC 0 status 3 block 1 tfr 1 IRQ: from DMAC 0 status 3 block 1 tfr 1 IRQ: from DMAC 0 status 3 block 1 tfr 1 irq: send done interrupt 0x40000000 bridge-io: msg send: 3 type 2 msg 64 size 16 ret 0 irq: IMRD masking 2 mask 0 active 2 bridge-io: msg recv 6 type 2 size 16 msg 64 msg: id 6 msg 64 size 16 type 2 IRQ: from HOST status 2 mask 0 active 2 cmd 0 irq: IMRD masking 2 mask 2 active 0 irq: send done interrupt 0x40000000 bridge-io: msg send: 4 type 2 msg 64 size 16 ret 0 irq: IMRD masking 2 mask 0 active 2 dma: 1:0: start SAR 0xff31c800 DAR 0x0 size 0x83c DMA req: src 0xff31c800 dest 0x0 size 0x83c bridge-io: msg send: 5 type 5 msg 96 size 56 ret 0 bridge-io: msg recv 7 type 5 size 56 msg 97 msg: id 7 msg 97 size 56 type 5 error: can't create SHM size 0x83c for DMAC 1 chan 0 While the companion x86-host.sh shows: [tdu@home:~/workspace/sof/qemu]$ ./x86-host.sh byt bridge-io: qemu-bridge-iram-mem fd 19 region 1 at 0x7f09d9cb7000 allocated 81920 bytes bridge-io: qemu-bridge-dram-mem fd 20 region 2 at 0x7f09cbfd8000 allocated 163840 bytes bridge-io: qemu-bridge-pci-io fd 21 region 3 at 0x7f09e93d1000 allocated 4096 bytes bridge-io: qemu-bridge-shim-io fd 22 region 4 at 0x7f09e93d0000 allocated 4096 bytes bridge-io: qemu-bridge-mbox-io fd 23 region 5 at 0x7f09e93cf000 allocated 4096 bytes bridge-io-mq: added /qemu-io-parent-byt bridge-io-mq: added /qemu-io-child-byt bridge-io: 0 messages are currently on parent queue. bridge-io: msg send: 0 type 1 msg 32 size 20 ret 0 bridge-io: msg send: 1 type 1 msg 32 size 20 ret 0 bridge-io: msg send: 2 type 1 msg 32 size 20 ret 0 bridge-io: msg recv 0 type 2 size 16 msg 64 msg: id 0 msg 64 size 16 type 2 DSP IRQ: status 2 mask 0 active 2 cmd 70028800 irq: masking 0 mask 0 active 0 irq: send done interrupt 0x40000000 bridge-io: msg send: 3 type 2 msg 64 size 16 ret 0 irq: masking 1 mask 0 active 2 irq: send busy interrupt 0x80000000 bridge-io: msg send: 4 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 1 type 5 size 56 msg 96 msg: id 1 msg 96 size 56 type 5 bridge-io: qemu-bridge-(null) fd 31 region 16 at 0x7f09d9c9e000 allocated 40 bytes bridge-io: msg send: 5 type 5 msg 97 size 56 ret 0 bridge-io: msg recv 2 type 5 size 56 msg 98 msg: id 2 msg 98 size 56 type 5 bridge-io: msg recv 3 type 2 size 16 msg 64 msg: id 3 msg 64 size 16 type 2 DSP IRQ: status 1 mask 0 active 1 cmd 70028800 irq: masking 2 mask 0 active 0 irq: masking 0 mask 0 active 1 irq: send busy interrupt 0x80000000 bridge-io: msg send: 6 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 4 type 2 size 16 msg 64 msg: id 4 msg 64 size 16 type 2 DSP IRQ: status 1 mask 0 active 1 cmd 70028800 bridge-io: msg recv 5 type 5 size 56 msg 96 msg: id 5 msg 96 size 56 type 5 error: cant alloc dma SHM -16 bridge-io: msg send: 7 type 5 msg 97 size 56 ret 0 irq: masking 2 mask 0 active 0 irq: masking 0 mask 0 active 1 So if I am not mistaken setup fails because some shared memory region cannot be allocated. Below a callstack leading to error present in logs. hw/dma/dw-dma-core.c: dw_dma_msg() dma_M2M_do_transfer() qemu_io_register_shm() <-- ADSP_IO_SHM_DMA(1, 0) region if (_iob.shm[region].fd) return -EBUSY; Now, if one goes back to xtensa logs it turns out that code wants region ADSP_IO_SHM_DMA(1, 0) which evaluates to 32. This means we are touching memory outside _iob.shm[] array (which has 32 entries). Any thoughts?

1 0

[Sound-open-firmware] How to check first frames on playback
by Paul Olaru 05 Dec '19

05 Dec '19

What is a good way to check that the first frames when starting playback with a file are correct and not reordered or repeated? I have tried to modify my host DMA driver to dump the frames as it transfers them and I see that the data transferred is the same as in the file but the first two frames are reordered and repeated, at least when I set the buffer size to be very small in aplay (--buffer-size=96). My test is to attempt to play a 768-byte raw file (2 channels, S16_LE) and dump all the data transferred by my host DMA driver. From the dumps (within the limits of etrace; I don't have DMA trace working as I didn't focus on that) I notice that several of the frames within the first period (first 384 bytes) end up being repeated and in the wrong ordering. The issue is unimportant with uncompressed playback as that would just be a small, 2ms glitch which is hardly audible, especially if you also have a volume ramp or the file is silent or mostly silent in the beginning. However, I want to implement support for compressed playback at some point which requires such glitches to not happen with the data before it even enters the pipeline (any bit change will cause corruption which is definitely audible or even failure of the decoding algorithm). So how should I check that the first few frames during playback are actually the correct ones?

3 3

[Sound-open-firmware] Converting a non BE to BE inside soc_check_tplg_fes
by Daniel Baluta 26 Nov '19

26 Nov '19

Hi all, I am trying how a non-BE link is converted to a BE link inside soc_check_tplg_fes. soc_check_tplg_fes => for all components that have ignore_machine setup to card name => dai_link->platforms->name = component->name; => dai_link->no_pcm = 1; But the thing is that the link is a true non-DPCM link, than fields like dpcm_playback/dpcm_capture are not set and playback/record substreams are no created. The question is: is this supposed to be working with non-DPCM links?

3 4

[Sound-open-firmware] Headers circular dependency
by Paul Olaru 21 Nov '19

21 Nov '19

As I was trying to turn the main macros (spin_lock, spin_lock_irq and the others) from <spinlock.h> I have uncovered the fact that <sof/spinlock.h> includes <sof/drivers/interrupt.h> and <sof/drivers/interrupt.h> includes <sof/spinlock.h>, which means that for every C file that includes either of them one of the two will not see the declarations of the other. Is this circular dependency actually real? Right now I have issues with interrupt_global_disable - it does an implicit declaration in <spinlock.h> due to <interrupt.h> being included first (or only) within some C files. If I try to include <arch/spinlock.h> from <sof/interrupt.h> I only get the error for "this file shouldn't be included from outside of sof/spinlock.h", but if I try to hack it to believe it's from there I get no further errors. I will submit a pull request displaying that soon (hopefully today) but I need feedback on whether this is the best approach. I mean the cyclic dependency is real because <sof/interrupt.h> needs to use spinlock_t but <sof/spinlock.h> requires several things from <sof/interrupt.h> so I believe it needs to be fixed even if the macros from <sof/spinlock.h> are left as macros.

1 0

[Sound-open-firmware] Stack alignment issues with XCC?
by Paul Olaru 20 Nov '19

20 Nov '19

Hello, I'm trying to begin doing all my builds with XCC for testing and, besides one issue where I need to manually insert stack alignment code in the IRQ handling function for the DMA domain it seems to work. Also, if I align the stack within my IRQ_STEER handler it remains aligned for the domain handler just fine. My question is, why within irq_handler (see src/drivers/imx/interrupt.c, function begins around line 275) the stack is not aligned? Did you also encounter this issue on other platforms? And is there any good solution other than that bit of inline assembly that just force-aligns the stack pointer when entering the cascaded IRQ handler? Without this code I seem to get panics with an alignment exception, the address pointing within an Interrupt stack and epc0 not being correct (I think I need to investigate that as well but that's a low-priority issue). Compiler version for reference (in case there is a known issue I'm not aware of): xt-xcc -v xt-xcc version 11.0.4 Thread model: single

2 6

[Sound-open-firmware] Handling DAI clocks in SOF
by Daniel Baluta 14 Nov '19

14 Nov '19

Hi all, I am asking your opinion on how to better handle clocks / pinctrl configuration in SOF for IMX. As far as I know Intel platforms deal with this stuff on Firmware side. Unfortunately for IMX this cannot be done easily. The interface on touching resources (clocks, pinctrl) in i.MX8/i.MX8X uses a separate dedicated core (M4) named System Controller. Linux kernel has a mechanism implemented to communicate with this SC and to request for clock operations (enable, disable, set rate etc). So, would you see it fit to create (on Linux kernel side) dummy DAI drivers which just take care of resource configuration? thanks, Daniel.

2 1

[Sound-open-firmware] How to figure out the direction when dai_config is called?
by Paul Olaru 11 Nov '19

11 Nov '19

On the i.MX platform, the SAI and ESAI DAIs require the direction (whether it's playback or capture) to be able to correctly decide which DMA channel is to be used (the channels differ between playback and capture). I have just made a simple modification to the pipeline to also have a record pipeline on the ESAI and I'm getting an error due to attempting to request channel 7 (Playback) twice. It seems that dai_config is called twice within the same IPC request (once for each instance of the DAI) and in both cases with the same direction too. What would be the best approach with this one? I have attached the diff with my current attempt to adding that record pipeline. Perhaps something is wrong with that?

2 4

[Sound-open-firmware] [PATCH 0/4] Adapt imx implementation to multi client SOF
by Daniel Baluta 30 Oct '19

30 Oct '19

Hi Ranjani, Patches with SQUASHME must be squashed into your corresponding commits. RFC patch is just an idea on how to abstract ACPI / DT stuff. This adds a generic version of the machine driver descriptor snd_soc_fw_mach. With the help of snd_soc_fw_mach we can make sof_audio_dev platform independent. Also, I hope that we could also make sof_dev_desc platform independent in my next iteration of the patch. So please take patches 1, 2 and 3 and squash them into your PR. Daniel Baluta (4): [SQUASHME] ASoC: SOF: move machine driver selection to the audio client [SQUASHME]ASoC: SOF: Split DSP ops into core ops and audio ops [SQUASHME] ASoC: SOF: Introduce default_fw_filename member in sof_dev_desc [RFC] ASoC: SOF: Introduce snd_soc_fw_mach descriptor include/sound/soc-of.h | 22 ++++++++++++++++++++++ include/sound/sof.h | 26 ++++++++++++++++++++++++++ sound/soc/sof/imx/imx8.c | 22 +++++++++++++++------- sound/soc/sof/pcm.c | 2 +- sound/soc/sof/sof-audio.h | 2 +- sound/soc/sof/sof-of-dev.c | 33 ++++----------------------------- 6 files changed, 69 insertions(+), 38 deletions(-) create mode 100644 include/sound/soc-of.h -- 2.17.1

2 5

[Sound-open-firmware] Linus at ELCE2019: "People should really write good commit messages"
by Daniel Baluta 29 Oct '19

29 Oct '19

... and explain WHY the change is needed. This will help others understand the change 3 years later! Lets keep this in mind when doing the review and coding!

1 0

Re: [Sound-open-firmware] How to debug rare DSP crashes (moving discussion over from GH)
by Paul Olaru 28 Oct '19

28 Oct '19

Replying now, after I have added traces within platform_panic I *do not* see them (also back on the default config I seem to have caused it to fail within first playthrough; it's also luck based with the timing). Will try tomorrow to also add prints in the agent itself and turn off other extra traces (so I don't get *too* much spam in the etrace buffer). I had written trace_error in there, which should have added the error within the etrace buffer I believe. -----Original Message----- From: Sound-open-firmware <sound-open-firmware-bounces(a)alsa-project.org> On Behalf Of Paul Olaru Sent: Monday, October 28, 2019 2:22 PM To: sound-open-firmware(a)alsa-project.org; Lauda, Tomasz <tomasz.lauda(a)intel.com> Cc: Jerome Laclavere <jerome.laclavere(a)nxp.com>; Daniel Baluta <daniel.baluta(a)nxp.com>; Guido Roncarolo <guido.roncarolo(a)nxp.com> Subject: [Sound-open-firmware] How to debug rare DSP crashes (moving discussion over from GH) Moving the discussion from https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… over to this list. In summary, whenever I have the system agent enabled and at default values, after two or three continuous playthroughs (depending on which timer I use as the platform timer, for the most part) of the same song (with duration 17:06) I get a complete freeze (with verbose traces enabled I see no more activity in the trace mailbox, not even the WFX/WFE which are essentially flooding the trace mailbox during normal function) and no signs of panic (I'm going to test now with a trace added in platform_panic; currently this function is empty). Disabling the system agent helps, changing CONFIG_SYSTICK_PERIOD to 2000 also helps. And I hear no glitch at all during the playthroughs with either of these changes applied (although a 1ms or smaller glitch once in 30 minutes is probably unnoticeable by any human ear is it?) How should I continue with this? I'll come back and mention if there is a panic or the freeze comes from something else. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware(a)alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.a…

1 1