Hi Stephen,
On Sat, Apr 22, 2017 at 3:27 AM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote:
> On 04/21, Geert Uytterhoeven wrote:
>> > --- a/drivers/clk/renesas/rcar-gen3-cpg.c
>> > +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
>> > +static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
>> > + unsigned long parent_rate)
>> > +{
>> > + struct cpg_z_clk *zclk = to_z_clk(hw);
>> > + unsigned int mult;
>> > + unsigned int val;
>> > + unsigned long rate;
>> > +
>> > + val = (clk_readl(zclk->reg) & CPG_FRQCRC_ZFC_MASK)
>> > + >> CPG_FRQCRC_ZFC_SHIFT;
>> > + mult = 32 - val;
>> > +
>> > + rate = div_u64((u64)parent_rate * mult + 16, 32);
>> > + /* Round to closest value at 100MHz unit */
>> > + rate = 100000000*DIV_ROUND_CLOSEST(rate, 100000000);
>>
>> Mike, Stephen: what's your opinion about such rounding tricks?
>
> What's wrong with the true rate? I'd prefer we calculate the true
> rate unless there's some reason. Typically that's what a comment
> is for, not to explain what the code is doing which is usually
> self evident from reading it.
The (intermediate) true rate may be a fractional number.
Since clock rate division and multiplication operate on integer numbers
(unsigned long), the calculated rate may deviate from the true rate due to
rounding or truncation.
The hack above is an attempt to correct that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
