From: Richard Acayan <mailingradian@gmail.com>
To: 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>,
	Richard Acayan <mailingradian@gmail.com>,
	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: ASoC q6asm race condition when stopping and preparing the stream
Date: Fri, 1 May 2026 10:41:49 -0400	[thread overview]
Message-ID: <afS7rTHdc9TyIeLx@rdacayan> (raw)

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.

next             reply	other threads:[~2026-05-01 14:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01 14:41 Richard Acayan [this message]
2026-05-01 15:27 ` ASoC q6asm race condition when stopping and preparing the stream Alexey Klimov
2026-05-01 23:53   ` Richard Acayan
2026-05-15  5:59     ` Val Packett
2026-05-15  9:22       ` Srinivas Kandagatla
2026-05-15 17:38   ` Srinivas Kandagatla
2026-05-15  9:17 ` Srinivas Kandagatla

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=afS7rTHdc9TyIeLx@rdacayan \
    --to=mailingradian@gmail.com \
    --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=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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.