Re: [PATCH v2 1/2] clk: fractional-divider: switch to rational best approximation

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, 2015-03-31 at 10:42 +0300, Andy Shevchenko wrote:
> On Tue, Mar 31, 2015 at 3:32 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 03/30/15 11:57, Andy Shevchenko wrote:
> >> This patch converts the code to use rational best approximation algorithm which
> >> is more precise.
> 
> >> --- a/drivers/clk/Kconfig
> >> +++ b/drivers/clk/Kconfig
> >> @@ -14,6 +14,7 @@ config COMMON_CLK
> >>       select HAVE_CLK_PREPARE
> >>       select CLKDEV_LOOKUP
> >>       select SRCU
> >> +     select RATIONAL
> >>       ---help---
> >>         The common clock framework is a single definition of struct
> >>         clk, useful across many platforms, as well as an
> >> @@ -63,7 +64,6 @@ config COMMON_CLK_SI5351
> >>       tristate "Clock driver for SiLabs 5351A/B/C"
> >>       depends on I2C
> >>       select REGMAP_I2C
> >> -     select RATIONAL
> >>       ---help---
> >>         This driver supports Silicon Labs 5351A/B/C programmable clock
> >>         generators.
> >> @@ -139,7 +139,6 @@ config COMMON_CLK_CDCE706
> >>       tristate "Clock driver for TI CDCE706 clock synthesizer"
> >>       depends on I2C
> >>       select REGMAP_I2C
> >> -     select RATIONAL
> >>       ---help---
> >>         This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
> >
> > Will some kernel janitor find us if we leave the selects here? I know
> > you removed it because COMMON_CLK must be Y here and we'd always select
> > RATIONAL, but it feels better to leave it alone and actually split off
> > the basic clock types into individual configs so that the tiny kernel
> > users don't have unused code lying around. That could be future work
> > someday and then we might forget to select RATIONAL again.
> 
> I'm fine with that as well. So, do I need to resend or you apply
> modified version?

There are couple of issues with arithmetics, such as we can't use
mult_frac() because of potential overflow on 32 bit kernels, so I will
resend new version.

-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy