Message-ID: <VE1PR04MB6479AC63FFE5D57B4E2C33D2E3650@VE1PR04MB6479.eurprd04.prod.outlook.com>
Date:   Fri, 25 Oct 2019 05:33:17 +0000
From:   "S.j. Wang" <shengjiu.wang@....com>
To:     Nicolin Chen <nicoleotsuka@...il.com>
CC:     "timur@...nel.org" <timur@...nel.org>,
        "Xiubo.Lee@...il.com" <Xiubo.Lee@...il.com>,
        "festevam@...il.com" <festevam@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: fsl_asrc: refine the setting of internal clock
 divider

Hi
> 
> 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?
> 
> 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=https%3A%2F%2Fmail
> man.alsa-project.org%2Fpipermail%2Falsa-devel%2F2014-
> May%2F076797.html&amp;data=02%7C01%7Cshengjiu.wang%40nxp.com%7
> Ce902d2bac4254d2faa0f08d757ecac0e%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C637074546320396681&amp;sdata=bg%2BLwRQnUPhW8f
> mE972O%2F53MyVftJkK140PSnmC%2FDKQ%3D&amp;reserved=0
> 
> > > 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@....com>
> 
> > > > @@ -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 = asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]];
> > > >
> > > > -     div[IN] = clk_get_rate(clk) / inrate;
> > > > +     clk_rate = 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 output
> clock for div[IN] calculation here.
> >
> > Bool p2p is to force output rate to be sample rate, no impact to ideal
> > Ratio mode.
> 
> I just realized that the function has a bottom part for ideal mode
> exclusively -- if we treat p2p as !ideal, those configurations will be missing.
> So you're right, should have an extra boolean variable.
> 
> > >
> > > > +     rem[IN] = do_div(clk_rate, inrate);
> > > > +     div[IN] = (u32)clk_rate;
> > > >       if (div[IN] == 0) {
> > >
> > > Could we check div[IN] and rem[IN] here? Like:
> > >         if (div[IN] == 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 hardware.
> >
> > For ideal mode,  my test result is  the divider not impact the output result.
> > Which means it is ok for ideal mode even divider is not correct...
> 
> OK.
> 
> > >
> > > >               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 = asrc_priv->asrck_clk[clk_index[OUT]];
> > > >
> > > > -     /* Use fixed output rate for Ideal Ratio mode (INCLK_NONE) */
> > > > -     if (ideal)
> > > > -             div[OUT] = clk_get_rate(clk) / IDEAL_RATIO_RATE;
> > > > -     else
> > > > -             div[OUT] = 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 Overload.
> > > > +      * 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 picky 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.
> 
> I see.
> 
> > >
> > > > +      * samplerate, but M2M must use less time to achieve good
> > > performance.
> > > > +      */
> > > > +     clk_rate = clk_get_rate(clk);
> > > > +     if (p2p || !ideal) {
> > > > +             rem[OUT] = do_div(clk_rate, outrate);
> > > > +             div[OUT] = clk_rate;
> > > > +     } else {
> > > > +             rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE);
> > > > +             div[OUT] = clk_rate;
> > > > +     }
> > > >
> > > >       if (div[OUT] == 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] != 0 || rem[OUT] != 0)) {
> > > > +     if (!ideal && (div[IN] > 1024 || div[OUT] > 1024 || rem[IN]
> > > > + || rem[OUT] != 0)) {
> > >
> > > So for ideal == true, these limitaions are not applied any more?
> > > Remember that the "ideal" is true for "p2p == true" cases here.
> >
> > No, not applied.  for ideal, the div don't impact the output result
> > Even it is not accurate.
> 
> I see.
> 
> > >
> > > > +             pair_err("The divider can't be used for non ideal mode\n");
> > > > +             return -EINVAL;
> > > > +     }
> > > > +
> > > > +     /* Divider range is [1, 1024] */
> > > > +     div[IN] = min_t(u32, 1024, div[IN]);
> > > > +     div[OUT] = 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 = true,  ideal = false.  Note that p2p is
> > not Equal to ideal.
> 
> Got it.
> 
> Overall, I feel it's better to have a naming to state the purpose of using
> 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.
> 

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

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

Best regards
Wang shengjiu

Powered by blists - more mailing lists