[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMZO5BgsU0ijdoaZs5e=qwb2PYZsEnx_RxfgQ+dosL8hPRKyA@mail.gmail.com>
Date: Thu, 26 Jun 2025 08:58:01 -0300
From: Fabio Estevam <festevam@...il.com>
To: Arun Raghavan <arun@...nraghavan.net>
Cc: Shengjiu Wang <shengjiu.wang@...il.com>, Xiubo Li <Xiubo.Lee@...il.com>,
Nicolin Chen <nicoleotsuka@...il.com>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Pieterjan Camerlynck <p.camerlynck@...evic.com>, linux-sound@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
Arun Raghavan <arun@...mptotic.io>
Subject: Re: [PATCH v3] ASoC: fsl_sai: Force a software reset when starting in
consumer mode
Hi Arun,
On Thu, Jun 26, 2025 at 8:52 AM Arun Raghavan <arun@...nraghavan.net> wrote:
>
> From: Arun Raghavan <arun@...mptotic.io>
>
> On an imx8mm platform with an external clock provider, when running the
> receiver (arecord) and triggering an xrun with xrun_injection, we see a
> channel swap/offset. This happens sometimes when running only the
> receiver, but occurs reliably if a transmitter (aplay) is also
> concurrently running.
>
> It seems that the SAI loses track of frame sync during the trigger stop
> -> trigger start cycle that occurs during an xrun. Doing just a FIFO
> reset in this case does not suffice, and only a software reset seems to
> get it back on track.
>
> This looks like the same h/w bug that is already handled for the
> producer case, so we now do the reset unconditionally on config disable.
>
> Signed-off-by: Arun Raghavan <arun@...mptotic.io>
> Reported-by: Pieterjan Camerlynck <p.camerlynck@...evic.com>
What about adding a Fixes tag and Cc stable so that it gets backported
to the stable trees?
Powered by blists - more mailing lists