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.
Reported-by: Liu Ying <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
---
v2: moved entire snipped under new flag check (Liu)
drivers/clk/clk-fractional-divider.c | 10 ++++++----
include/linux/clk-provider.h | 5 +++++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-fractional-divider.c b/drivers/clk/clk-fractional-divider.c
index 535d299af646..5f4b6a8aef67 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -76,16 +76,18 @@ void clk_fractional_divider_general_approximation(struct clk_hw *hw,
unsigned long *m, unsigned long *n)
{
struct clk_fractional_divider *fd = to_clk_fd(hw);
- unsigned long scale;
/*
* Get rate closer to *parent_rate to guarantee there is no overflow
* for m and n. In the result it will be the nearest rate left shifted
* by (scale - fd->nwidth) bits.
*/
- scale = fls_long(*parent_rate / rate - 1);
- if (scale > fd->nwidth)
- rate <<= scale - fd->nwidth;
+ if (!(fd->flags & CLK_FRAC_DIVIDER_NO_PRESCALER)) {
+ unsigned long scale = fls_long(*parent_rate / rate - 1);
+
+ if (scale > fd->nwidth)
+ rate <<= scale - fd->nwidth;
+ }
rational_best_approximation(rate, *parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
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,
--
2.30.2
On Fri, 2021-07-16 at 16:34 +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.
As I mentioned in v1 comment, it seems to be good to decouple the
prescaler knowledge from this common fractional divider clk driver.
This way, we'll make it simpler and easier to maintain. Also, then, the
NO_PRESCALER flag is not needed at all. However, it seems that two
Intel drivers which use the frational divider drivers will be affected
and rate negotiation logics need to be implemented for them. Please
consider if it's doable or not.
If we ultimately keep the prescaler knowledge here, please consider to
add the NO_PRESCALER flag for i.MX7ulp as it hasn't the prescaler IIUC.
Regards,
Liu Ying
>
> Reported-by: Liu Ying <[email protected]>
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
> v2: moved entire snipped under new flag check (Liu)
> drivers/clk/clk-fractional-divider.c | 10 ++++++----
> include/linux/clk-provider.h | 5 +++++
> 2 files changed, 11 insertions(+), 4 deletions(-)
On Thu, Jul 22, 2021 at 12:33 PM Liu Ying <[email protected]> wrote:
> On Fri, 2021-07-16 at 16:34 +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.
>
> As I mentioned in v1 comment, it seems to be good to decouple the
> prescaler knowledge from this common fractional divider clk driver.
> This way, we'll make it simpler and easier to maintain. Also, then, the
> NO_PRESCALER flag is not needed at all. However, it seems that two
> Intel drivers which use the frational divider drivers will be affected
> and rate negotiation logics need to be implemented for them. Please
> consider if it's doable or not.
The current driver works for the certain hardware without this change.
If you think it's better, submit a proposal we will discuss.
> If we ultimately keep the prescaler knowledge here, please consider to
> add the NO_PRESCALER flag for i.MX7ulp as it hasn't the prescaler IIUC.
You mean there is a code which is currently using this driver w/o
taking into account this prescaller flavour? Can you, please, point
out, I'll definitely update it. Thanks for the catch!
--
With Best Regards,
Andy Shevchenko
On Thu, 2021-07-22 at 12:38 +0300, Andy Shevchenko wrote:
> On Thu, Jul 22, 2021 at 12:33 PM Liu Ying <[email protected]> wrote:
> > On Fri, 2021-07-16 at 16:34 +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.
> >
> > As I mentioned in v1 comment, it seems to be good to decouple the
> > prescaler knowledge from this common fractional divider clk driver.
> > This way, we'll make it simpler and easier to maintain. Also, then, the
> > NO_PRESCALER flag is not needed at all. However, it seems that two
> > Intel drivers which use the frational divider drivers will be affected
> > and rate negotiation logics need to be implemented for them. Please
> > consider if it's doable or not.
>
> The current driver works for the certain hardware without this change.
> If you think it's better, submit a proposal we will discuss.
Well, I'm not afford to do so. Just share an idea. I haven't got the
intel HW to test. As I mentioned in v1 comment, it seems that you have
experience on relevent drivers and HW to test, may I encourage you to
do that :-) Or forget that if you really think you won't do that.
>
> > If we ultimately keep the prescaler knowledge here, please consider to
> > add the NO_PRESCALER flag for i.MX7ulp as it hasn't the prescaler IIUC.
>
> You mean there is a code which is currently using this driver w/o
> taking into account this prescaller flavour? Can you, please, point
> out, I'll definitely update it. Thanks for the catch!
drivers/clk/imx/clk-composite-7ulp.c
Regards,
Liu Ying
>
On Thu, Jul 22, 2021 at 05:43:49PM +0800, Liu Ying wrote:
> On Thu, 2021-07-22 at 12:38 +0300, Andy Shevchenko wrote:
> > On Thu, Jul 22, 2021 at 12:33 PM Liu Ying <[email protected]> wrote:
> > > On Fri, 2021-07-16 at 16:34 +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.
> > >
> > > As I mentioned in v1 comment, it seems to be good to decouple the
> > > prescaler knowledge from this common fractional divider clk driver.
> > > This way, we'll make it simpler and easier to maintain. Also, then, the
> > > NO_PRESCALER flag is not needed at all. However, it seems that two
> > > Intel drivers which use the frational divider drivers will be affected
> > > and rate negotiation logics need to be implemented for them. Please
> > > consider if it's doable or not.
> >
> > The current driver works for the certain hardware without this change.
> > If you think it's better, submit a proposal we will discuss.
>
> Well, I'm not afford to do so. Just share an idea. I haven't got the
> intel HW to test. As I mentioned in v1 comment, it seems that you have
> experience on relevent drivers and HW to test, may I encourage you to
> do that :-) Or forget that if you really think you won't do that.
Noted. I am in support of this idea, and will help with testing on Intel HW
if anyone submits the code.
> > > If we ultimately keep the prescaler knowledge here, please consider to
> > > add the NO_PRESCALER flag for i.MX7ulp as it hasn't the prescaler IIUC.
> >
> > You mean there is a code which is currently using this driver w/o
> > taking into account this prescaller flavour? Can you, please, point
> > out, I'll definitely update it. Thanks for the catch!
>
> drivers/clk/imx/clk-composite-7ulp.c
Thanks, I'll update in v3. Can you, please, look the other patch(es)?
--
With Best Regards,
Andy Shevchenko