Variable Clock Frequency and Power Saving

Micael Henriksson micael.h at gmail.com
Wed Oct 29 01:28:40 CET 2008


Hi!

I implemented some parts of cpufreq driver about a year ago when I got
my GTA01, however I only added handlers for the serial port and nand
before I got stuck with the USB block which didn't want to play...
Soon after CesarB also made the same implementation, but had also
added support for the framebuffer and some thing else.. also think he
made a wiki page.. long time since I checked this!

When I saw some mails lately about large power savings when blanking
the display I actually started looking at this again.
I have not had time the last days to make any coding, but I had some
ideas about improvements.
* To workaround the dying USB block, don't change speed when something
is connected. If at a low speed when something is connected, power
down the USB and set to full speed before making any communication.
(don't know it'll work..)
* Using SLOW mode causes a flashing display, so only go here when
display is blanked...

I don't have a git branch for this but there should be some patches in
the mail archive from Cesars patches. I think I have my old stuff left
too, but need don't think they will apply to easily against 2.6.27..
Anyway.. it should not be too hard to make this again..

The unfortunate problem is as you say the clock distribution in
s3c2410. A lot of drivers need to be notified about a frequency
change!

It would be very interesting looking at this again!

cheers,
/Micael

On Tue, Oct 28, 2008 at 9:20 PM, Jonas Bonn <jonas.bonn at gmail.com> wrote:
> Hello All!
>
> I put together a cpuidle driver for the S3C2410 and added the
> NO_HZ/clockevents work from Andresz to my build.  What follows is a
> list of time spent in idle (that's S3C2410 mode IDLE) for my GTA01.
> Some of the long idle times are really impressive (almost 0.5
> seconds).
>

>
> Anyway, the point of this post is to see what is happening in
> powersaving work.  I had a look at adding an idle-mode that switches
> to SLOW mode; this might be feasible, but as so many drivers need to
> adjust to the change of clock rate, the time to enter and leave this
> idle mode becomes significant (although, for 0.5 seconds, it should be
> no problem).
>
> That said, there is no support for clock rate adjustment at all right
> now.  Is somebody working on this or does this already work in
> somebody's tree somewhere?
>
> I think we need to adjust the 'clk' infrastructure so that:
> i)  Children are notified when parent clock rate changes
> ii)  Clocks can be reparented (for example, for SLOW mode we switch
> from MPLL to XTAL).
> iii)  Clocks get a list of callbacks to invoke when their rate changes
> so that drivers can make the necessary adjustments.  (e.g. framebuffer
> driver needs to know when hclk changes in order to adjust its vclk
> divider)
>
> Looking forward to feedback.
> /Jonas
>
>



More information about the openmoko-kernel mailing list