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

[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

[Sound-open-firmware] SOF firmware and topology files
by Mark Pearson 24 Oct '19

24 Oct '19

Hi, I while back I was on the email list asking questions about backporting kernel fixes to Debian and getting the ucm files into Debian - and all of that has now been done. Many thanks for the pointers and the help. We almost have the Lenovo X1Carbon-7 audio working "out of the box" with Debian but there are still a few wrinkles and I'd appreciate any insight as to the best way to address these - and more importantly what I can do to help that happen :) 1) I currently add a blacklist file to stop the snd_hda_intel and snd_soc_skl drivers being loaded. I think based on some discussion and patches I saw in the alsa-devel thread you may have solved that issue - is that correct or is it still work in progress? 2) I've been using the sof-cnl-signed-intel.ri from the 1.3 release (and it's working great). Is there a plan how this will be handled downstream? For instance for Debian I didn't know whether it would become part of the intel-firmware package, or if maybe sof becomes its own package would be built by itself and the firmware grabbed from there, or does it go with some other alsa package? As an aside I tried the second approach (building it myself) but the resultant sof-cnl.ri fails to load succesfully. I haven't debugged it yet but are there any particular pointers on whether this should usually work or ideas why it wouldn't. 3) I've also got a sof-hda-generic.tplg file the origins of which I'm a bit unsure (I think I swiped it from Ubuntu as they have an image that works well on the X1C7). I tried building my own version but get ipc errors (I can share if of interest). Similarly to the sof-cnl.ri file - is there a plan/recommendations as to how this should make its way downstream? Thanks in advance Mark Pearson

2 1

[Sound-open-firmware] How does one debug IPC errors?
by Paul Olaru 21 Oct '19

21 Oct '19

Right now I'm still working on the ESAI SOF driver. Based on the current branch I'm getting an out of memory issue. Solved by increasing the system runtime heap, not a real problem even if a surprising one to me, will probably send the fix together with the ESAI driver. However, I'm getting a second issue: Whenever I'm trying to play anything I see the etrace log filled with "ipc: msg hdr for 0x600a0000 not found replace 0" and playback doesn't progress. Also in another weirder circumstance (invalid aplay followed by a valid one) I heard it play but for some reason the host buffer was copied only at odd times (and I heard the same 64k or 16384 samples many times over instead of once). How should I continue investigating this issue? (also due to a failed stop - kernel reported IPC timeout for 0x60050000 and 0x60030000, I'm still getting the issues for 0x600a0000 in a continuous loop on the firmware side, about the time it would take to normally play those samples; until reboot I cannot send any other commands to the DSP either). Also, should I send the current state of the ESAI driver, even if there is a little more cleanup that needs to be done on it? Now that I cannot reliably test it anymore.

3 4