* ASoC q6asm race condition when stopping and preparing the stream
@ 2026-05-01 14:41 Richard Acayan
2026-05-01 15:27 ` Alexey Klimov
0 siblings, 1 reply; 3+ messages in thread
From: Richard Acayan @ 2026-05-01 14:41 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Greg Kroah-Hartman, Richard Acayan, Kees Cook,
Joris Verhaegen, Kuninori Morimoto, linux-sound, linux-arm-msm,
linux-kernel
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.
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.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: ASoC q6asm race condition when stopping and preparing the stream
2026-05-01 14:41 ASoC q6asm race condition when stopping and preparing the stream Richard Acayan
@ 2026-05-01 15:27 ` Alexey Klimov
2026-05-01 23:53 ` Richard Acayan
0 siblings, 1 reply; 3+ messages in thread
From: Alexey Klimov @ 2026-05-01 15:27 UTC (permalink / raw)
To: Richard Acayan, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Greg Kroah-Hartman, Kees Cook,
Joris Verhaegen, Kuninori Morimoto, linux-sound, linux-arm-msm,
linux-kernel
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?
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: ASoC q6asm race condition when stopping and preparing the stream
2026-05-01 15:27 ` Alexey Klimov
@ 2026-05-01 23:53 ` Richard Acayan
0 siblings, 0 replies; 3+ messages in thread
From: Richard Acayan @ 2026-05-01 23:53 UTC (permalink / raw)
To: Alexey Klimov
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Greg Kroah-Hartman, Kees Cook, Joris Verhaegen,
Kuninori Morimoto, linux-sound, linux-arm-msm, linux-kernel
On Fri, May 01, 2026 at 04:27:57PM +0100, 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?
I don't really have an easy way to reproduce. On a device with a
Qualcomm SoC and q6asm, running postmarketOS with Phosh and without the
workaround, waiting a few hours usually reproduces it.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-01 23:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-01 14:41 ASoC q6asm race condition when stopping and preparing the stream Richard Acayan
2026-05-01 15:27 ` Alexey Klimov
2026-05-01 23:53 ` Richard Acayan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox