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

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

[Sound-open-firmware] Backport of SOF driver to 5.2.9 fixes
by Mark Pearson 25 Sep '19

25 Sep '19

Hi SOF folks, I've been able to address the issue I was seeing with 5.2.9 kernel and the SOF driver on our whiskeylake based system but would really appreciate a quick review from the experts to confirm that I've not missed anything important or add any extra insight. The problem was seen on boot - the driver suspends and resumes a couple of times during boot and during the second resume failed to load the firmware (err -110). After that point the driver, and hence the audio, isn't useable. I backported these commits to address the problem: https://github.com/thesofproject/linux/commit/bf705eaa7ce07f9c132f8e367fc2f… https://github.com/thesofproject/linux/commit/64632de9140e52b72781fefe54231… https://github.com/thesofproject/linux/commit/7623ae793c28cc0928c5d1292542d… https://github.com/thesofproject/linux/commit/f5dbba9fee801f4678a50d92c785f… https://github.com/thesofproject/linux/commit/bb1ea3b31c28a131a5f5a50dd3251… We're still doing some testing to get confidence the fix is correct and stable but so far it looks good - everything is working. Thanks Mark

3 3

[Sound-open-firmware] Questions about the pause-release flow
by Paul Olaru 16 Sep '19

16 Sep '19

Right now I have a working (but not yet cleaned up) set of drivers (host DMA, DAI DMA and DAI itself) and I figured I could test for pause-release (even if the rates seem incorrect; can't actually check for correctness until the codec driver is also ready). The issue I encountered is: I can pause, however whenever I press <SPACE> again on aplay, I get "pause release error: Invalid argument" and the SOF log shows "dai_comp_trigger(), PAUSE/STOP" immediately followed by a -22 (-EINVAL) return code from pipeline_trigger. Shouldn't unpausing actually send COMP_TRIGGER_RELEASE? I am doing my own state checking but I suspect it may be wrong. What should I look into, and is this actually correct behavior?

2 4

[Sound-open-firmware] Whiskeylake support and kernel version
by Mark Pearson 15 Sep '19

15 Sep '19

Hi, I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration) Thanks! Mark

4 12

[Sound-open-firmware] Status of Braswell
by Curtis Malainey 11 Sep '19

11 Sep '19

Hello SOF team, I am just curious what the status of Braswell devices are right now. If the status is unknown that is fine. I may be doing some experimenting with them in the near future. Any known issues or caveats would be appreciated. :) Curtis

3 8

[Sound-open-firmware] Questions about the DAI DMA/pipeline flow
by Paul Olaru 05 Sep '19

05 Sep '19

Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored). What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms). Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes?

3 5

[Sound-open-firmware] System Controller Unit firmware code inside SOF
by Daniel Baluta 03 Sep '19

03 Sep '19

Hi Liam / Pierre, I want to hear your take on the following. On some of our i.MX platforms most of the critical functions like PM, clocks, interrupts are handled by a special core name SCU (System Controller Unit). It runs a special firmware (SCFW). In order for our DSP core to communicate with SCU it needs to use a special interface exported by the SCFW. The interface is BSD-3 Clause licensed. Anyhow, as you might expect the coding style / file naming / organization is firmware like. That means very very different from what we have in SOF. Do you think such an interface would be acceptable to be merged in SOF? Or should we spent some time to rewrite it from scratch to match the quality of the existing SOF code? The bad part in rewriting it from scratch is that we need to update-it by hand each time the SCFW interface changes. thanks, Daniel.

3 2

[Sound-open-firmware] Machine driver for pcm512x
by Daniel Baluta 03 Sep '19

03 Sep '19

Hi all, I'm looking at sof-apl-pcm512x-nohdmi.m4 scenario in SOF (I choose this because it looks to be the simplest scenario that also involves a codec). But I couldn't find the machine driver corresponding to this in Linux kernel code. Any idea? Daniel.

3 2