Variable Clock Frequency and Power Saving

[Jonas Bonn]

> Thanks for looking at this area.  500mS chunks in SLOW or some strong
> powersaving mode wth short wakes before the next one is pretty serious
> potential powersaving.
>

So, I have been working on this via an approach that moves toward
making "struct clk" more of a first-class citizen and allowing drivers
to hook up to a clock, specifying frequency constraints and getting
frequency change callbacks in order to make device configuration
changes, as necessary.

The benefit of this approach is that it:
a)  Moves "clock" code closer to "struct clk" definitions
b)  Allows cpuidle and cpufreq to coexist nicely
c)  Moves frequency constraint information to device drivers
d)  Allows device and clock frequency constraints to change
dynamically depending on whether a device is in use or not

I have this working for the GTA01 and it's running with cpuidle
dropping the clocks to a low frequency and the drivers do the right
thing.  The framebuffer "disengages" from the clock when the screen is
blanked, thus allowing an even lower frequency in that case.  All in
all, it works as I envisioned and I'd like to get some feedback on the
various bits now.

In order to get some kind of discussion started, I am going to append
the "clk" bits to this mail.  There are some bits that are still
hard-coded and not quite finished, but the basic idea is there.  See
the very end of the patch for documentation around the new "clk_dev"
API which allows devices to hook up to clocks of interest.  I have
modified drivers for NAND, framebuffer, and SDIO that make uses of
this API; I just need to clean things up a bit first before posting
them.

The actual frequency changing bits are largely borrowed from Cesar's
CPU frequency tree.  As mentioned, this change means that the
frequency changing implementation can be moved out of cpufreq and
closer to the clk's themselves.

Sorry for the chaotic post... this is an "early" submit in the "submit
early, submit often" idiom.  I'm looking forward to your feedback.

Regards,
Jonas