[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250626115218.141874-1-arun@arunraghavan.net>
Date: Thu, 26 Jun 2025 07:52:18 -0400
From: Arun Raghavan <arun@...nraghavan.net>
To: Shengjiu Wang <shengjiu.wang@...il.com>,
Xiubo Li <Xiubo.Lee@...il.com>
Cc: Fabio Estevam <festevam@...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: [PATCH v3] ASoC: fsl_sai: Force a software reset when starting in consumer mode
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>
---
v3
- Incorporate feedback from Shengjiu Wang to consolidate with the
existing handling of this issue in producer mode
sound/soc/fsl/fsl_sai.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index af1a168d35e3..50af6b725670 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -803,13 +803,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai, int dir)
* anymore. Add software reset to fix this issue.
* This is a hardware bug, and will be fix in the
* next sai version.
+ *
+ * In consumer mode, this can happen even after a
+ * single open/close, especially if both tx and rx
+ * are running concurrently.
*/
- if (!sai->is_consumer_mode[tx]) {
- /* Software Reset */
- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
- /* Clear SR bit to finish the reset */
- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
- }
+ /* Software Reset */
+ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
+ /* Clear SR bit to finish the reset */
+ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
}
static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
--
2.49.0
Powered by blists - more mailing lists