Re: [PATCH] ASoC: ti: davinci-mcasp: Protect hw_params callback against race

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

 




On 12/08/2019 14.13, Mark Brown wrote:
> On Mon, Aug 12, 2019 at 12:53:04PM +0300, Peter Ujfalusi wrote:
>> If the playback and capture of the same McASP is connected to different
>> dai link (non duplex PCM links, like with pcm3168a codec) then there is
>> a high probability of race between the two direction leaving McASP in a
>> confused state.
>>
>> Protect the hw_params() with a mutex to make sure that this is not
>> happening.
> 
> This feels like something we might want to consider moving up to the
> core, though not every device is going to need it I guess it should be
> safe to do there.

soc_pcm_hw_params() is already protected by
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);

which (I think) gives protection for dai_links when they support both
playback and capture.

I faced with the concurrency when interfacing with pcm3168a codec, which
require two dai_links. One for playback and one for capture so they
don't share the same snd_soc_pcm_runtime.

I believe moving the
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);

to card level could substitute (new mutex on the card for pcm operations
probably) the need to handle this in drivers.

We would need to change soc-core/pcm/compress for this.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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