From: Takashi Iwai <tiwai@suse.de>
To: "Cássio Gabriel" <cassiogabrielcontato@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
linuxppc-dev@lists.ozlabs.org, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] ALSA: aoa: i2sbus: clear stale prepared state
Date: Tue, 31 Mar 2026 16:27:51 +0200 [thread overview]
Message-ID: <878qb8rs48.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260330-aoa-i2sbus-clear-stale-active-v1-1-47a6c0a3ac9e@gmail.com>
On Tue, 31 Mar 2026 00:27:28 +0200,
Cássio Gabriel wrote:
>
> The i2sbus PCM code uses pi->active to constrain the sibling stream to
> an already prepared duplex format and rate in i2sbus_pcm_open().
>
> That state is set from i2sbus_pcm_prepare(), but the current code only
> clears it on close. As a result, the sibling stream can inherit stale
> constraints after the prepared state has been torn down, or after a new
> prepare attempt fails before completing.
>
> Clear pi->active when hw_params() or hw_free() drops the prepared state,
> clear it before starting a new prepare attempt, and set it again only
> after prepare succeeds.
>
> Replace the stale FIXME in the duplex constraint comment with
> a description of the current driver behavior: i2sbus still programs a
> single shared transport configuration for both directions, so mixed
> formats are not supported in duplex mode.
>
> Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
> sound/aoa/soundbus/i2sbus/pcm.c | 53 ++++++++++++++++++++++++++++++++---------
> 1 file changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/sound/aoa/soundbus/i2sbus/pcm.c b/sound/aoa/soundbus/i2sbus/pcm.c
> index 97c807e67d56..47a89da43cff 100644
> --- a/sound/aoa/soundbus/i2sbus/pcm.c
> +++ b/sound/aoa/soundbus/i2sbus/pcm.c
> @@ -165,17 +165,16 @@ static int i2sbus_pcm_open(struct i2sbus_dev *i2sdev, int in)
> * currently in use (if any). */
> hw->rate_min = 5512;
> hw->rate_max = 192000;
> - /* if the other stream is active, then we can only
> - * support what it is currently using.
> - * FIXME: I lied. This comment is wrong. We can support
> - * anything that works with the same serial format, ie.
> - * when recording 24 bit sound we can well play 16 bit
> - * sound at the same time iff using the same transfer mode.
> + /* If the other stream is already prepared, keep this stream
> + * on the same duplex format and rate.
> + *
> + * i2sbus_pcm_prepare() still programs one shared transport
> + * configuration for both directions, so mixed duplex formats
> + * are not supported here.
> */
> if (other->active) {
> - /* FIXME: is this guaranteed by the alsa api? */
> hw->formats &= pcm_format_to_bits(i2sdev->format);
> - /* see above, restrict rates to the one we already have */
> + /* Restrict rates to the one already in use. */
> hw->rate_min = i2sdev->rate;
> hw->rate_max = i2sdev->rate;
> }
> @@ -283,6 +282,22 @@ void i2sbus_wait_for_stop_both(struct i2sbus_dev *i2sdev)
> }
> #endif
>
> +static void i2sbus_pcm_clear_active(struct i2sbus_dev *i2sdev, int in)
> +{
> + struct pcm_info *pi;
> +
> + guard(mutex)(&i2sdev->lock);
> +
> + get_pcm_info(i2sdev, in, &pi, NULL);
> + pi->active = 0;
> +}
> +
> +static inline int i2sbus_hw_params(struct snd_pcm_substream *substream, int in)
> +{
> + i2sbus_pcm_clear_active(snd_pcm_substream_chip(substream), in);
> + return 0;
> +}
> +
> static inline int i2sbus_hw_free(struct snd_pcm_substream *substream, int in)
> {
> struct i2sbus_dev *i2sdev = snd_pcm_substream_chip(substream);
> @@ -291,14 +306,25 @@ static inline int i2sbus_hw_free(struct snd_pcm_substream *substream, int in)
> get_pcm_info(i2sdev, in, &pi, NULL);
> if (pi->dbdma_ring.stopping)
> i2sbus_wait_for_stop(i2sdev, pi);
> + i2sbus_pcm_clear_active(i2sdev, in);
> return 0;
> }
>
> +static int i2sbus_playback_hw_params(struct snd_pcm_substream *substream)
> +{
> + return i2sbus_hw_params(substream, 0);
> +}
> +
> static int i2sbus_playback_hw_free(struct snd_pcm_substream *substream)
> {
> return i2sbus_hw_free(substream, 0);
> }
>
> +static int i2sbus_record_hw_params(struct snd_pcm_substream *substream)
> +{
> + return i2sbus_hw_params(substream, 1);
> +}
> +
> static int i2sbus_record_hw_free(struct snd_pcm_substream *substream)
> {
> return i2sbus_hw_free(substream, 1);
> @@ -335,7 +361,7 @@ static int i2sbus_pcm_prepare(struct i2sbus_dev *i2sdev, int in)
> return -EINVAL;
>
> runtime = pi->substream->runtime;
> - pi->active = 1;
> + pi->active = 0;
> if (other->active &&
> ((i2sdev->format != runtime->format)
> || (i2sdev->rate != runtime->rate)))
Do we need to clear the active flag here? It must have been cleared
by hw_params call. Or is it the case for errors?
thanks,
Takashi
next prev parent reply other threads:[~2026-03-31 14:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 22:27 [PATCH] ALSA: aoa: i2sbus: clear stale prepared state Cássio Gabriel
2026-03-31 14:27 ` Takashi Iwai [this message]
2026-03-31 16:15 ` Cássio Gabriel Monteiro Pires
2026-03-31 17:10 ` kernel test robot
2026-03-31 20:53 ` Cássio Gabriel Monteiro Pires
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=878qb8rs48.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=cassiogabrielcontato@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=perex@perex.cz \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.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 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.