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

[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

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

28 Oct '19

Moving the discussion from https://github.com/thesofproject/sof/pull/1998 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.

1 0

Re: [Sound-open-firmware] SOF firmware and topology files
by Pierre-Louis Bossart 25 Oct '19

25 Oct '19

> Mark, I'm currently putting together / testing the sof ucm for Dell and Lenovo devices. > Unfortunately I've not yet received the X1 (it is shipped to me). So ucm's for > Dell and Lenovo will be in alsa-ucm-conf repository, Jaroslav has already done > Some differentiation to handle Lenove differences. > > Pierre, actually I'm not sure how the topology differentiation will be done? > So for example can we load different topology in these 2 manufacturers device? > So if it is just overwriting the new topology with same name, how to differentiate? The topology should change only if the firmware changed, e.g. with the addition of a processing, path or secret sauce that's not in the default firmware released by Intel. We have a default topology file path which can be modified with a kernel module parameter (see in sof-pci-dev.c), and we could also add DMI quirks to do this change as well. The file name would be identical, just located in a different directory (and not necessarily in /lib/firmware/intel/sof-tplg). If an OEM decided to make changes to the topology, I'd guess they are on the hook to provide such changes to downstream distros? I am not sure we can manage all possible variations in a central repo, it's hard enough to provide all the default pieces already...

2 2