Sound-open-firmware September 2019

sound-open-firmware@alsa-project.org

11 participants
7 discussions

[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 14 Sep '19

14 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

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware September 2019