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
