lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <a189942a-39e8-4241-9301-844fb39a0f14@app.fastmail.com>
Date: Thu, 26 Jun 2025 07:44:48 -0400
From: "Arun Raghavan" <arun@...nraghavan.net>
To: "Shengjiu Wang" <shengjiu.wang@...il.com>
Cc: "Xiubo Li" <Xiubo.Lee@...il.com>, "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: Re: [PATCH v2] ASoC: fsl_sai: Force a software reset when starting in consumer
 mode

On Thu, 26 Jun 2025, at 2:55 AM, Shengjiu Wang wrote:
> On Thu, Jun 26, 2025 at 7:58 AM Arun Raghavan <arun@...nraghavan.net> wrote:
>>
>> From: Arun Raghavan <arun@...mptotic.io>
>>
>> In a setup 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.
>>
>> The theory is that SAI seems to lose 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.
>>
>> Signed-off-by: Arun Raghavan <arun@...mptotic.io>
>> Reported-by: Pieterjan Camerlynck <p.camerlynck@...evic.com>
>> ---
>>
>> v2:
>> - Address build warning from kernel test robot
>>
>>  sound/soc/fsl/fsl_sai.c | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
>> index af1a168d35e3..d158352c7640 100644
>> --- a/sound/soc/fsl/fsl_sai.c
>> +++ b/sound/soc/fsl/fsl_sai.c
>> @@ -841,6 +841,18 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
>>         case SNDRV_PCM_TRIGGER_START:
>>         case SNDRV_PCM_TRIGGER_RESUME:
>>         case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> +               /*
>> +                * Force a software reset if we are not the clock provider, as we
>> +                * might have lost frame sync during xrun recovery.
>> +                */
>> +               if (sai->is_consumer_mode[tx]) {
>> +                       regmap_update_bits(sai->regmap,
>> +                                       FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR,
>> +                                       FSL_SAI_CSR_SR);
>> +                       regmap_update_bits(sai->regmap,
>> +                                       FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR,
>> +                                       0);
>> +               }
>
> Which platform are you using?  and please add chip info in your commit
> message.

It's an imx8mm. I'll add that to the commit message.

> This change can be moved to fsl_sai_config_disable(). that is:
>
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -798,18 +798,16 @@ static void fsl_sai_config_disable(struct
> fsl_sai *sai, int dir)
>                            FSL_SAI_CSR_FR, FSL_SAI_CSR_FR);
>
>         /*
> -        * For sai master mode, after several open/close sai,
> +        * For sai master/slave mode, after several open/close sai,
>          * there will be no frame clock, and can't recover
>          * anymore. Add software reset to fix this issue.
>          * This is a hardware bug, and will be fix in the
>          * next sai version.
>          */
> -       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);
>  }
>
> Could you please try the above change to also work for your case?

Ah, I should've spotted that! Yes, doing it this way works just fine. Updated patch incoming.

Thank you,
Arun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ