Re: [PATCH] ASoC: core: Move pcm_mutex up to card level from snd_soc_pcm_runtime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/15/19 2:07 AM, Peter Ujfalusi wrote:


On 14/08/2019 21.14, Pierre-Louis Bossart wrote:


On 8/13/19 5:45 AM, Peter Ujfalusi wrote:
The pcm_mutex is used to prevent concurrent execution of snd_pcm_ops
callbacks. This works fine most of the cases but it can not handle setups
when the same DAI is used by different rtd, for example:
pcm3168a have two DAIs: one for Playback and one for Capture.
If the codec is connected to a single CPU DAI we need to have two
dai_link
to support both playback and capture.

In this case the snd_pcm_ops callbacks can be executed in parallel
causing
unexpected races in DAI drivers.

By moving the pcm_mutex up to card level this can be solved
while - hopefully - not breaking other setups.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@xxxxxx>
---
Hi,

I have tested the patch on several boards. it fixes the issue with
single card
with multiple dai_links where the CPU side (mcasp) is the same.

However I can not test with anything which use DPCM. It would be great
if the
patch would gather few tested-by from folks having access to more
complicated
setups.

Actually you *can* test by submitting a PR for SOF, it'll trigger some
tests on Intel platforms using DPCM. It's not going to test anything
related to the compressed API but it's better than nothing.

Good to know and thanks.
I would not thought of abusing the SOF project to run tests, not that I
know how to trigger the right tests ;)

well we will run those tests anyways when we do the weekly merges, and when in doubt it might be more productive for an ALSA contributor to run the tests ahead of time than report that things are broken after the merge (as seen 2 weeks in a row with the module_put and compilation issues)



I took this patch and created one PR as an example
https://github.com/thesofproject/linux/pull/1132

Should I be worried because of your comment there saying 'I have no idea
why the BYT_NOCODEC mode fails, there's no information provided.' ?

Redoing the tests removes that error, so this looks fine. Must have been a CI glitch

Will share results when I have them.

So far no issues. so FWIW since it's just 1st order automatic testing

Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux