[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220311025332.75830C340E8@smtp.kernel.org>
Date: Thu, 10 Mar 2022 18:53:30 -0800
From: Stephen Boyd <sboyd@...nel.org>
To: Emil Renner Berthing <kernel@...il.dk>, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org
Cc: Emil Renner Berthing <kernel@...il.dk>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>,
Michael Zhu <michael.zhu@...rfivetech.com>,
Fu Wei <tekkamanninja@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/7] clk: starfive: jh7100: Don't round divisor up twice
Quoting Emil Renner Berthing (2022-01-26 09:39:47)
> The problem is best illustrated by an example. Suppose a consumer wants
> a 4MHz clock rate from a divider with a 10MHz parent. It would then
> call
>
> clk_round_rate(clk, 4000000)
>
> which would call into our determine_rate() callback that correctly
> rounds up and finds that a divisor of 3 gives the highest possible
> frequency below the requested 4MHz and returns 10000000 / 3 = 3333333Hz.
>
> However the consumer would then call
>
> clk_set_rate(clk, 3333333)
>
> but since 3333333 doesn't divide 10000000 evenly our set_rate() callback
> would again round the divisor up and set it to 4 which results in an
> unnecessarily low rate of 2.5MHz.
>
> Fix it by using DIV_ROUND_CLOSEST in the set_rate() callback.
>
> Fixes: 4210be668a09 ("clk: starfive: Add JH7100 clock generator driver")
> Signed-off-by: Emil Renner Berthing <kernel@...il.dk>
> ---
Applied to clk-next
Powered by blists - more mailing lists