[RFC v2] ARM: i.MX pllv1: Implement set_rate

[l.stach@pengutronix.de (Lucas Stach)]

Am Montag, den 22.07.2013, 19:18 +0400 schrieb Alexander Shiyan:
> On Sun, 21 Jul 2013 14:37:59 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > On Sat, Jul 20, 2013 at 04:18:01PM +0400, Alexander Shiyan wrote:
> > > On Sat, 20 Jul 2013 13:58:29 +0200
> > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > 
> > > > > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > > > > This patch implements frequency change for i.MX pllv1.
> > > > > > > Selection of the values of the registers is not optimal, since is
> > > > > > > made by simple enumeration of all possible values.
> > > > > > 
> > > > > > You do not mention why you want to adjust the rate. Normally we've been
> > > > > > happy with the static values from the bootloader.
> > > > > 
> > > > > For CPUfreq.
> > > > > Only one barrier to make it workable.
> > > > 
> > > > Isn't it better to adjust the dividers only? I haven't made good
> > > > experience with adjusting the PLLs.
> > > 
> > > The frequency value after booting can be quite arbitrary.
> > > 
> > > Since we define possible frequencies for the CPU (266 and 399 MHz),
> > > I can offer as variant to use a fixed constant values for PLL.
> > 
> > AFAIK the PLL should run at 800MHz. With dividers of 2, 3 and 6 we get
> > 400, 266 and 133MHz. I don't think having more fine grained control
> > about the CPU frequency is necessary from a power saving point of view.
> > Let's keep the variants to a minimum to make the whole stuff more
> > robust.
> 
> What about switching the source?
> In any case, I have already made an efficient algorithm to calculate
> the PLL and after some tests, I will introduce it.
> Thanks.
> 
Both changing the divider or changing source should be glitchfree in the
CPU clock path. Using the divider should be enough to allow to scale the
CPU frequency with the accuracy needed for simple CPUfreq.

Using the PLL to scale the frequency is a really bad idea, as it's both
not glitchfree on it's own plus it adds considerable delay to the clock
change. In order to use the PLL for clock scaling you have to first
switch the CPU away from the PLL (making sure you have an alternative
clock path that can satisfy the CPUs requirements), then reprogram PLL,
wait for the PLL to lock, then switch back to the PLL. Sounds utterly
complex for a simple clock change that could be done by just flipping
the divider bits, isn't it?

Regards,
Lucas 
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |