From: "Alexey Klimov" <alexey.klimov@linaro.org>
To: "Richard Acayan" <mailingradian@gmail.com>,
"Srinivas Kandagatla" <srini@kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Kees Cook" <kees@kernel.org>,
"Joris Verhaegen" <verhaegen@google.com>,
"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
<linux-sound@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: ASoC q6asm race condition when stopping and preparing the stream
Date: Fri, 01 May 2026 16:27:57 +0100 [thread overview]
Message-ID: <DI7G2SF71B39.22LPDZWBG87O9@linaro.org> (raw)
In-Reply-To: <afS7rTHdc9TyIeLx@rdacayan>
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
next prev parent reply other threads:[~2026-05-01 15:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 14:41 ASoC q6asm race condition when stopping and preparing the stream Richard Acayan
2026-05-01 15:27 ` Alexey Klimov [this message]
2026-05-01 23:53 ` Richard Acayan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DI7G2SF71B39.22LPDZWBG87O9@linaro.org \
--to=alexey.klimov@linaro.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mailingradian@gmail.com \
--cc=perex@perex.cz \
--cc=srini@kernel.org \
--cc=tiwai@suse.com \
--cc=verhaegen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox