Re: ASoC q6asm race condition when stopping and preparing the stream

[Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>]

On 5/1/26 3:27 PM, Alexey Klimov wrote:
> On Fri May 1, 2026 at 3:41 PM BST, Richard Acayan wrote:
>> Hi,
>>
>> There seems to be a race condition in q6asm when stopping the stream
>> (with uncompressed PCM). When receiving SNDRV_PCM_TRIGGER_STOP, the
>> driver sets the state to Q6ASM_STREAM_STOPPED and sends CMD_EOS to the
>> ADSP. If userspace decides to prepare the stream again in
>> q6asm_dai_prepare before receiving ASM_CLIENT_EVENT_CMD_EOS_DONE, the
>> memory-mapped region appears to still be in use and fails to map again.
>>
>> I believe this race was observed since commit 81c53b52de21 ("ASoC: qcom:
>> qdsp6: q6asm-dai: set 10 ms period and buffer alignment."), but would
>> need to verify. On sdm670, we are coping downstream by keeping the state
>> as Q6ASM_STREAM_RUNNING until receiving CMD_EOS_DONE.
> 
> Do you have a reproducer or specific steps to test/reproduce the issue?
> 

Manage to reproduce this on my UNO -Q device, will update you once I
have a fix.

--srini
> 
>> Can the ADSP emit DATA_WRITE_DONE or DATA_READ_DONE before CMD_EOS_DONE?
>> We might need an extra stopping state between CMD_EOS and CMD_EOS_DONE
>> so the driver doesn't request more data transfers.
> 
> Thanks,
> Alexey