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 <[EMAIL PROTECTED]> 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 > >
