[alsa-devel] [PATCH] ASoC: core: Move pcm_mutex up to card level from snd_soc_pcm_runtime

[Pierre-Louis Bossart]

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 at ti.com>
>>> ---
>>> 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 at linux.intel.com>