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