Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "S.j. Wang" <shengjiu.wang@nxp.com>
To:     Nicolin Chen <nicoleotsuka@gmail.com>
CC:     "timur@kernel.org" <timur@kernel.org>,
        "Xiubo.Lee@gmail.com" <Xiubo.Lee@gmail.com>,
        "festevam@gmail.com" <festevam@gmail.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "perex@perex.cz" <perex@perex.cz>,
        "tiwai@suse.com" <tiwai@suse.com>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_asrc: refine the setting of internal clock
 divider
Thread-Topic: [PATCH] ASoC: fsl_asrc: refine the setting of internal clock
 divider
Thread-Index: AdWK9JxJMGzwqHsSSM+MgjXQwBho3Q==
Date:   Fri, 25 Oct 2019 05:33:17 +0000
Message-ID: <VE1PR04MB6479AC63FFE5D57B4E2C33D2E3650@VE1PR04MB6479.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c541a0d-ca89-4f03-6280-08d7590cd70d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 05:33:17.6613
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5Bdj5SPVsEECrGMBWqbAdN6DQBb92uZ8Ku9JkmNDSbX38qV15glplFKw/vFHpBTJiaIfOClu2aJnxoGzzNT11Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6621
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi
>=20
> On Wed, Oct 23, 2019 at 06:25:20AM +0000, S.j. Wang wrote:
> > > On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote:
> > > > For P2P output, the output divider should align with the output
> > > > sample
> > >
> > > I think we should avoid "P2P" (or "M2M") keyword in the mainline
> > > code as we know M2M will never get merged while somebody working
> > > with the mainline and caring about new feature might be confused.
> >
> > Ok. But we still curious that is there a way to upstream m2m?
>=20
> Hmm..I would love to see that happening. Here is an old discussion that
> you may want to take a look:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmail
> man.alsa-project.org%2Fpipermail%2Falsa-devel%2F2014-
> May%2F076797.html&amp;data=3D02%7C01%7Cshengjiu.wang%40nxp.com%7
> Ce902d2bac4254d2faa0f08d757ecac0e%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C637074546320396681&amp;sdata=3Dbg%2BLwRQnUPhW8f
> mE972O%2F53MyVftJkK140PSnmC%2FDKQ%3D&amp;reserved=3D0
>=20
> > > It makes sense to me, yet I feel that the delay at the beginning of
> > > the audio playback might be longer as a compromise. I am okay with
> > > this decision though...
> > >
> > > > The maximum divider of asrc clock is 1024, but there is no
> > > > judgement for this limitaion in driver, which may cause the
> > > > divider setting not correct.
> > > >
> > > > For non-ideal ratio mode, the clock rate should divide the sample
> > > > rate with no remainder, and the quotient should be less than 1024.
> > > >
> > > > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
>=20
> > > > @@ -351,7 +352,9 @@ static int fsl_asrc_config_pair(struct
> > > > fsl_asrc_pair
> > > *pair)
> > > >       /* We only have output clock for ideal ratio mode */
> > > >       clk =3D asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]];
> > > >
> > > > -     div[IN] =3D clk_get_rate(clk) / inrate;
> > > > +     clk_rate =3D clk_get_rate(clk);
> > >
> > > The fsl_asrc.c file has config.inclk being set to INCLK_NONE and
> > > this sets the "ideal" in this function to true. So, although we tend
> > > to not use ideal ratio setting for p2p cases, yet the input clock is
> > > still not physically connected, so we still use output clock for div[=
IN]
> calculation?
> >
> > For p2p case, it can be ideal or non-ideal.  For non-ideal, we still
> > use Output clock for div calculation.
> >
> > >
> > > I am thinking something simplier: if we decided not to use ideal
> > > ratio for "P2P", instead of adding "bool p2p" with the confusing
> > > "ideal" in this function, could we just set config.inclk to the same
> > > clock as the output one for "P2P"? By doing so, "P2P" won't go
> > > through ideal ratio mode while still having a clock rate from the out=
put
> clock for div[IN] calculation here.
> >
> > Bool p2p is to force output rate to be sample rate, no impact to ideal
> > Ratio mode.
>=20
> I just realized that the function has a bottom part for ideal mode
> exclusively -- if we treat p2p as !ideal, those configurations will be mi=
ssing.
> So you're right, should have an extra boolean variable.
>=20
> > >
> > > > +     rem[IN] =3D do_div(clk_rate, inrate);
> > > > +     div[IN] =3D (u32)clk_rate;
> > > >       if (div[IN] =3D=3D 0) {
> > >
> > > Could we check div[IN] and rem[IN] here? Like:
> > >         if (div[IN] =3D=3D 0 || div[IN] > 1024) {
> > >                 pair_err();
> > >                 goto out;
> > >         }
> > >
> > >         if (!ideal && rem[IN]) {
> > >                 pair_err();
> > >                 goto out;
> > >         }
> > >
> > > According to your commit log, I think the max-1024 limitation should
> > > be applied to all cases, not confined to "!ideal" cases right? And
> > > we should add some comments also, indicating it is limited by hardwar=
e.
> >
> > For ideal mode,  my test result is  the divider not impact the output r=
esult.
> > Which means it is ok for ideal mode even divider is not correct...
>=20
> OK.
>=20
> > >
> > > >               pair_err("failed to support input sample rate %dHz
> > > > by
> > > asrck_%x\n",
> > > >                               inrate, clk_index[ideal ? OUT :
> > > > IN]); @@
> > > > -360,11 +363,20 @@ static int fsl_asrc_config_pair(struct
> > > > fsl_asrc_pair *pair)
> > > >
> > > >       clk =3D asrc_priv->asrck_clk[clk_index[OUT]];
> > > >
> > > > -     /* Use fixed output rate for Ideal Ratio mode (INCLK_NONE) */
> > > > -     if (ideal)
> > > > -             div[OUT] =3D clk_get_rate(clk) / IDEAL_RATIO_RATE;
> > > > -     else
> > > > -             div[OUT] =3D clk_get_rate(clk) / outrate;
> > > > +     /*
> > > > +      * When P2P mode, output rate should align with the out
> samplerate.
> > > > +      * if set too high output rate, there will be lots of Overloa=
d.
> > > > +      * When M2M mode, output rate should also need to align with
> > > > + the out
> > >
> > > For this "should", do you actually mean "M2M could also"? Sorry, I'm
> > > just trying to understand everyting here, not intentionally being pic=
ky at
> words.
> > > My understanding is that we still keep the ideal ratio setting
> > > because "M2M" still uses it.
> >
> > We use IDEAL_RATIO_RATE as output rate for m2m mode, it likes a Tricky
> > operation, in order to improve the performance. I think The correct
> > operation is to use the real output rate, but the performance Is bad.
> > So it is a compromise.
>=20
> I see.
>=20
> > >
> > > > +      * samplerate, but M2M must use less time to achieve good
> > > performance.
> > > > +      */
> > > > +     clk_rate =3D clk_get_rate(clk);
> > > > +     if (p2p || !ideal) {
> > > > +             rem[OUT] =3D do_div(clk_rate, outrate);
> > > > +             div[OUT] =3D clk_rate;
> > > > +     } else {
> > > > +             rem[OUT] =3D do_div(clk_rate, IDEAL_RATIO_RATE);
> > > > +             div[OUT] =3D clk_rate;
> > > > +     }
> > > >
> > > >       if (div[OUT] =3D=3D 0) {
> > > >               pair_err("failed to support output sample rate %dHz
> > > > by asrck_%x\n", @@ -372,6 +384,16 @@ static int
> > > > fsl_asrc_config_pair(struct
> > > fsl_asrc_pair *pair)
> > > >               return -EINVAL;
> > > >       }
> > > >
> > > > +     if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 ||
> > > > +                    rem[IN] !=3D 0 || rem[OUT] !=3D 0)) {
> > > > +     if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || rem[IN]
> > > > + || rem[OUT] !=3D 0)) {
> > >
> > > So for ideal =3D=3D true, these limitaions are not applied any more?
> > > Remember that the "ideal" is true for "p2p =3D=3D true" cases here.
> >
> > No, not applied.  for ideal, the div don't impact the output result
> > Even it is not accurate.
>=20
> I see.
>=20
> > >
> > > > +             pair_err("The divider can't be used for non ideal mod=
e\n");
> > > > +             return -EINVAL;
> > > > +     }
> > > > +
> > > > +     /* Divider range is [1, 1024] */
> > > > +     div[IN] =3D min_t(u32, 1024, div[IN]);
> > > > +     div[OUT] =3D min_t(u32, 1024, div[OUT]);
> > >
> > > Hmm, this looks like we want to allow ideal ratio cases and p2p
> > > cases to operate any way, even if the divider wasn't within the
> > > range to get the in/out rates from the output clock?
> >
> > Yes. We still allow the p2p =3D true,  ideal =3D false.  Note that p2p =
is
> > not Equal to ideal.
>=20
> Got it.
>=20
> Overall, I feel it's better to have a naming to state the purpose of usin=
g
> ideal configurations without the IDEAL_RATIO_RATE setup.
>         bool use_ideal_rate;
> And we can put into the asrc_config structure if there's no major problem=
.
>=20

Asrc_config may exposed to user, I don't think user need to care about
The using of ideal rate or not.=20

> So the condition check for the calculation would be:
> +       if (ideal && config->use_ideal_rate)
> +               rem[OUT] =3D do_div(clk_rate, IDEAL_RATIO_RATE);
> +       else
> +               rem[OUT] =3D do_div(clk_rate, outrate);
> +       div[OUT] =3D clk_rate;
>=20
> And for that if (!ideal && div[IN]....rem[OUT]), I feel it would be clear=
 to
> have them separately, as the existing "div[IN] =3D=3D 0"
> and "div[OUT] =3D=3D 0" checks, so that we can tell users which side of t=
he
> divider is out of range and what the sample rate and clock rate are.
>=20
Do you mean need to combine this judgement with "div[IN] =3D=3D 0"
Or "div[OUT] =3D=3D 0"?

Best regards
Wang shengjiu