From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Shengjiu Wang <shengjiu.wang@gmail.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Timur Tabi <timur@kernel.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
Fabio Estevam <festevam@gmail.com>,
Shengjiu Wang <shengjiu.wang@nxp.com>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linuxppc-dev@lists.ozlabs.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
Date: Mon, 3 Aug 2020 14:57:35 -0700 [thread overview]
Message-ID: <20200803215735.GA5461@Asurada-Nvidia> (raw)
In-Reply-To: <CAA+D8AOGF44UUq=P1S-M5TUwDUaOnqVmHJKPDBM9DAzt1nVzmQ@mail.gmail.com>
On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > clock generation. The TCSR.TE is no need to enabled when only RX
> > > is enabled.
> >
> > You are correct if there's only RX running without TX joining.
> > However, that's something we can't guarantee. Then we'd enable
> > TE after RE is enabled, which is against what RM recommends:
> >
> > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > # If the receiver bit clock and frame sync are to be used by
> > # both the transmitter and receiver, it is recommended that
> > # the receiver is the last enabled and the first disabled.
> >
> > I remember I did this "ugly" design by strictly following what
> > RM says. If hardware team has updated the RM or removed this
> > limitation, please quote in the commit logs.
>
> There is no change in RM and same recommandation.
>
> My change does not violate the RM. The direction which generates
> the clock is still last enabled.
Using Tx syncing with Rx clock for example,
T1: arecord (non-stop) => set RE
T2: aplay => set TE then RE (but RE is already set at T1)
Anything that I am missing?
> > > + if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> > > + } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> >
> > Two identical regmap_update_bits calls -- both on !tx (RX?)
> The content for regmap_update_bits is the same, but the precondition
> is different.
> The first one is for tx=false and enable TCSR.TE. (TX generate clock)
> The second one is for tx=true and enable RSCR.RE (RX generate clock)
Why not merge them?
+ if ((!sai->synchronous[TX] && sai->synchronous[RX] && !tx) ||
+ ((!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Shengjiu Wang <shengjiu.wang@gmail.com>
Cc: Shengjiu Wang <shengjiu.wang@nxp.com>,
Linux-ALSA <alsa-devel@alsa-project.org>,
Timur Tabi <timur@kernel.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
Date: Mon, 3 Aug 2020 14:57:35 -0700 [thread overview]
Message-ID: <20200803215735.GA5461@Asurada-Nvidia> (raw)
In-Reply-To: <CAA+D8AOGF44UUq=P1S-M5TUwDUaOnqVmHJKPDBM9DAzt1nVzmQ@mail.gmail.com>
On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > clock generation. The TCSR.TE is no need to enabled when only RX
> > > is enabled.
> >
> > You are correct if there's only RX running without TX joining.
> > However, that's something we can't guarantee. Then we'd enable
> > TE after RE is enabled, which is against what RM recommends:
> >
> > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > # If the receiver bit clock and frame sync are to be used by
> > # both the transmitter and receiver, it is recommended that
> > # the receiver is the last enabled and the first disabled.
> >
> > I remember I did this "ugly" design by strictly following what
> > RM says. If hardware team has updated the RM or removed this
> > limitation, please quote in the commit logs.
>
> There is no change in RM and same recommandation.
>
> My change does not violate the RM. The direction which generates
> the clock is still last enabled.
Using Tx syncing with Rx clock for example,
T1: arecord (non-stop) => set RE
T2: aplay => set TE then RE (but RE is already set at T1)
Anything that I am missing?
> > > + if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> > > + } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> >
> > Two identical regmap_update_bits calls -- both on !tx (RX?)
> The content for regmap_update_bits is the same, but the precondition
> is different.
> The first one is for tx=false and enable TCSR.TE. (TX generate clock)
> The second one is for tx=true and enable RSCR.RE (RX generate clock)
Why not merge them?
+ if ((!sai->synchronous[TX] && sai->synchronous[RX] && !tx) ||
+ ((!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
next prev parent reply other threads:[~2020-08-03 21:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 3:17 [PATCH] ASoC: fsl_sai: Clean code for synchronize mode Shengjiu Wang
2020-08-03 5:40 ` Nicolin Chen
2020-08-03 5:40 ` Nicolin Chen
2020-08-03 5:40 ` Nicolin Chen
2020-08-03 8:04 ` Shengjiu Wang
2020-08-03 8:04 ` Shengjiu Wang
2020-08-03 21:57 ` Nicolin Chen [this message]
2020-08-03 21:57 ` Nicolin Chen
2020-08-04 1:39 ` Shengjiu Wang
2020-08-04 1:39 ` Shengjiu Wang
2020-08-04 2:11 ` Nicolin Chen
2020-08-04 2:11 ` Nicolin Chen
2020-08-04 2:35 ` Shengjiu Wang
2020-08-04 2:35 ` Shengjiu Wang
2020-08-04 3:00 ` Nicolin Chen
2020-08-04 3:00 ` Nicolin Chen
2020-08-04 3:23 ` Shengjiu Wang
2020-08-04 3:23 ` Shengjiu Wang
2020-08-04 4:22 ` Shengjiu Wang
2020-08-04 4:22 ` Shengjiu Wang
2020-08-04 7:03 ` Nicolin Chen
2020-08-04 7:03 ` Nicolin Chen
2020-08-04 7:08 ` Nicolin Chen
2020-08-04 7:08 ` Nicolin Chen
2020-08-04 7:53 ` Shengjiu Wang
2020-08-04 7:53 ` Shengjiu Wang
2020-08-04 8:13 ` Nicolin Chen
2020-08-04 8:13 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200803215735.GA5461@Asurada-Nvidia \
--to=nicoleotsuka@gmail.com \
--cc=Xiubo.Lee@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=festevam@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=shengjiu.wang@gmail.com \
--cc=shengjiu.wang@nxp.com \
--cc=timur@kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.