linux-kernel - Re: [PATCH] ASoC: fsl_sai: fix Rx synchrounous mode

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]

Date:	Thu, 22 Oct 2015 11:57:38 -0700
From:	Nicolin Chen <nicoleotsuka@...il.com>
To:	Stefan Agner <stefan@...er.ch>
Cc:	broonie@...nel.org, timur@...i.org, Xiubo.Lee@...il.com,
	lgirdwood@...il.com, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: fsl_sai: fix Rx synchrounous mode

On Mon, Oct 19, 2015 at 05:42:23PM -0700, Stefan Agner wrote:
> When using the Rx clock for both, transmitter and receiver, the
> transmitter needs to be set to synchronous with receiver.
> 
> This reverts 855675f6e6a6 ("ASoC: fsl_sai: Set SYNC bit of TCR2 to
> Asynchronous Mode"), which, judiging from the commit log, seems to
> mixed up between the two synchronous modes: The boolean

Actually my original patch I sent to the mail list was different:
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-August/079639.html

It should be applied before the asynchronous patches however they
are somehow disordered. I guess that's why now the commit appears
in such confusing way. But anyway it's a bug I should have noticed
long time ago.

Thanks a lot

> sai->synchronous[TX] is indicating wheather the SAI should work in
> Rx synchronous mode (sync Tx with Rx), hence if the value is true,
> the SYNC field of TCR2 needs to be set to 0x1 ("Synchronous with
> receiver").
> 
> Signed-off-by: Stefan Agner <stefan@...er.ch>

Acked-by: Nicolin Chen <nicoleotsuka@...il.com>

> ---
> Hi Nicolin,
> 
> I got this reported from a customer, he tried to use the device
> tree property "fsl,sai-synchronous-rx" according to the description
> but it failed. In a quick test, setting the SYNC field of TCR2 to
> 0x1 helped in his case. So I think this here is right. But given
> that you chaged the very same line can you review that again and
> give me a Ack/Nack?
> 
> --
> Stefan
> 
>  sound/soc/fsl/fsl_sai.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index a18fd92..1f0e552 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -454,7 +454,8 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
>  	 * Rx sync with Tx clocks: Clear SYNC for Tx, set it for Rx.
>  	 * Tx sync with Rx clocks: Clear SYNC for Rx, set it for Tx.
>  	 */
> -	regmap_update_bits(sai->regmap, FSL_SAI_TCR2, FSL_SAI_CR2_SYNC, 0);
> +	regmap_update_bits(sai->regmap, FSL_SAI_TCR2, FSL_SAI_CR2_SYNC,
> +		           sai->synchronous[TX] ? FSL_SAI_CR2_SYNC : 0);
>  	regmap_update_bits(sai->regmap, FSL_SAI_RCR2, FSL_SAI_CR2_SYNC,
>  			   sai->synchronous[RX] ? FSL_SAI_CR2_SYNC : 0);
>  
> -- 
> 2.6.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/