Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1251177 > unrolled thread

[PATCH] ASoC: fsl_sai: fix Rx synchrounous mode

Started byStefan Agner <stefan@agner.ch>
First post2015-10-20 02:50 +0200
Last post2015-10-22 21:00 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] ASoC: fsl_sai: fix Rx synchrounous mode Stefan Agner <stefan@agner.ch> - 2015-10-20 02:50 +0200
    Re: [PATCH] ASoC: fsl_sai: fix Rx synchrounous mode Nicolin Chen <nicoleotsuka@gmail.com> - 2015-10-22 21:00 +0200

#1251177 — [PATCH] ASoC: fsl_sai: fix Rx synchrounous mode

FromStefan Agner <stefan@agner.ch>
Date2015-10-20 02:50 +0200
Subject[PATCH] ASoC: fsl_sai: fix Rx synchrounous mode
Message-ID<qlthL-4kA-7@gated-at.bofh.it>
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
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@agner.ch>
---
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1254095

FromNicolin Chen <nicoleotsuka@gmail.com>
Date2015-10-22 21:00 +0200
Message-ID<qmtfI-2HW-21@gated-at.bofh.it>
In reply to#1251177
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@agner.ch>

Acked-by: Nicolin Chen <nicoleotsuka@gmail.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web