6.1-stable patches

added patches:
	asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch

diff --git a/queue-6.1/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch b/queue-6.1/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch
new file mode 100644 (file)
index 0000000..1a76ac4
--- /dev/null
+++ b/queue-6.1/asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch
@@ -0,0 +1,59 @@
+From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001
+From: Arun Raghavan <arun@asymptotic.io>
+Date: Thu, 26 Jun 2025 09:08:25 -0400
+Subject: ASoC: fsl_sai: Force a software reset when starting in consumer mode
+
+From: Arun Raghavan <arun@asymptotic.io>
+
+commit dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 upstream.
+
+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@asymptotic.io>
+Reported-by: Pieterjan Camerlynck <p.camerlynck@televic.com>
+Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode")
+Cc: stable@vger.kernel.org
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/fsl/fsl_sai.c |   14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/sound/soc/fsl/fsl_sai.c
++++ b/sound/soc/fsl/fsl_sai.c
+@@ -762,13 +762,15 @@ static void fsl_sai_config_disable(struc
+        * 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) {
+-              /* 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,

diff --git a/queue-6.1/series b/queue-6.1/series
index c583bbb2b2a8f935055b0881149925589fdd9417..4ead1d09c1e1d9d90235dd489df9a581905386c4 100644 (file)
--- a/queue-6.1/series
+++ b/queue-6.1/series
@@ -73,3 +73,4 @@ usb-hub-don-t-try-to-recover-devices-lost-during-warm-reset.patch
 usb-musb-add-and-use-inline-functions-musb_-get-set-_state.patch
 usb-musb-fix-gadget-state-on-disconnect.patch
 usb-dwc3-qcom-don-t-leave-bcr-asserted.patch
+asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch