From: Arun Raghavan arun@asymptotic.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@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 ---
v4 - Add Fixes and cc stable
v3 - Incorporate feedback from Shengjiu Wang to consolidate with the existing handling of this issue in producer mode
v2 (no longer relevant) - Address build warning from kernel test robot
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,
On Thu, Jun 26, 2025 at 10:09 AM Arun Raghavan arun@arunraghavan.net wrote:
From: Arun Raghavan arun@asymptotic.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@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
On Thu, Jun 26, 2025 at 9:09 PM Arun Raghavan arun@arunraghavan.net wrote:
From: Arun Raghavan arun@asymptotic.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@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
Acked-by: Shengjiu Wang shengjiu.wang@gmail.com
Best regards Shengjiu Wang
v4
- Add Fixes and cc stable
v3
- Incorporate feedback from Shengjiu Wang to consolidate with the existing handling of this issue in producer mode
v2 (no longer relevant)
- Address build warning from kernel test robot
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
On Thu, 26 Jun 2025 09:08:25 -0400, Arun Raghavan wrote:
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.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_sai: Force a software reset when starting in consumer mode commit: dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
linux-stable-mirror@lists.linaro.org
-
Arun Raghavan -
Fabio Estevam -
Mark Brown -
Shengjiu Wang