Messages in this thread Patch in this message | | | Subject | Re: [PATCH v1 2/3] clk: fractional-divider: Introduce NO_PRESCALER flag | From | Liu Ying <> | Date | Fri, 16 Jul 2021 10:43:57 +0800 |
| |
On Thu, 2021-07-15 at 15:07 +0300, Andy Shevchenko wrote: > The newly introduced flag, when set, makes the flow to skip > the assumption that the caller will use an additional 2^scale > prescaler to get the desired clock rate.
Now, I start to be aware of the reason why the "left shifting" is needed but still not 100% sure that details are all right. IIUC, you are considering a potential HW prescaler here, while I thought the HW model is just a fractional divider(M/N) and the driver is fully agnostic to the potential HW prescaler.
> > Reported-by: Liu Ying <victor.liu@nxp.com> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > drivers/clk/clk-fractional-divider.c | 2 +- > include/linux/clk-provider.h | 5 +++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/clk-fractional-divider.c b/drivers/clk/clk-fractional-divider.c > index 535d299af646..b2f9aae9f172 100644 > --- a/drivers/clk/clk-fractional-divider.c > +++ b/drivers/clk/clk-fractional-divider.c > @@ -84,7 +84,7 @@ void clk_fractional_divider_general_approximation(struct clk_hw *hw, > * by (scale - fd->nwidth) bits. > */ > scale = fls_long(*parent_rate / rate - 1); > - if (scale > fd->nwidth) > + if (scale > fd->nwidth && !(fd->flags & CLK_FRAC_DIVIDER_NO_PRESCALER)) > rate <<= scale - fd->nwidth;
First of all, check the CLK_FRAC_DIVIDER_NO_PRESCALER flag for the entire above snippet of code?
Second and more important, it seems that it would be good to decouple the prescaler knowledge from this fractional divider clk driver so as to make it simple(Output rate = (m / n) * parent_rate). This way, the CLK_FRAC_DIVIDER_NO_PRESCALER flag is not even needed at the first place, which means rational_best_approximation() just _directly_ offer best_{numerator,denominator} for all cases. Further more, is it possilbe for rational_best_approximation() to make sure there is no risk of overflow for best_{numerator,denominator}, since max_{numerator,denominator} are already handed over to rational_best_approximation()? Overflowed/unreasonable best_{numerator,denominator} don't sound like the "best" offered value. If that's impossible, then audit best_{numerator,denominator} after calling rational_best_approximation()?
Make sense?
Regards, Liu Ying
> > rational_best_approximation(rate, *parent_rate, > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h > index d83b829305c0..f74d0afe275f 100644 > --- a/include/linux/clk-provider.h > +++ b/include/linux/clk-provider.h > @@ -1001,6 +1001,10 @@ struct clk_hw *devm_clk_hw_register_fixed_factor(struct device *dev, > * CLK_FRAC_DIVIDER_BIG_ENDIAN - By default little endian register accesses are > * used for the divider register. Setting this flag makes the register > * accesses big endian. > + * CLK_FRAC_DIVIDER_NO_PRESCALER - By default the resulting rate may be shifted > + * left by a few bits in case when the asked one is quite small to satisfy > + * the desired range of denominator. If the caller wants to get the best > + * rate without using an additional prescaler, this flag may be set. > */ > struct clk_fractional_divider { > struct clk_hw hw; > @@ -1022,6 +1026,7 @@ struct clk_fractional_divider { > > #define CLK_FRAC_DIVIDER_ZERO_BASED BIT(0) > #define CLK_FRAC_DIVIDER_BIG_ENDIAN BIT(1) > +#define CLK_FRAC_DIVIDER_NO_PRESCALER BIT(2) > > extern const struct clk_ops clk_fractional_divider_ops; > struct clk *clk_register_fractional_divider(struct device *dev,
| |