[PATCH 0/9] Experimental S3C2410A cpufreq driver

Cesar Eduardo Barros cesarb at cesarb.net
Wed Feb 13 02:23:42 CET 2008

For some weeks I have been working on a cpufreq driver for the GTA01 (to 
try to make its battery last a bit longer). It's far from complete (it 
will end up touching almost every device driver for the SoC), but the 
core code (which does the frequency switching) is mostly ready.

Along the way, I added GTA02 support; however, that not only is 
completely untested, it also will interact badly with the FIQ-using 
drivers (it disables FIQ during the frequency transition), at least 
until mutual locking is added so the frequency changes wait for the use 
of the FIQ to end.

Some characteristics of the S3C2410 are not well supported by the core 
cpufreq architecture, meaning it had to be bent a bit to fit:

- The cpufreq core thinks only about the CPU clock, however the drivers 
are interested mostly on the bus clocks; this information is passed 
- The cpufreq core believes the drivers will want to set a minimum 
frequency (or a maximum frequency) below (or above) which they won't 
operate correctly; however, some drivers want to exclude specific 
frequencies in the middle of the range (like the serial driver, where 
some frequencies don't have a divider where it doesn't get out of spec, 
or the framebuffer driver, which wants to exclude frequencies which will 
cause flicker). Also, some drivers want the frequency not to change, but 
don't care which frequency should be used.
- There are several ways to set a particular frequency (varying the 
divider settings).

The following drivers have already been adapted to work with the cpufreq 

- The timer driver (arch/arm/plat-s3c24xx/time.c) was modified to adjust 
the current and reload values.
- The NAND driver (drivers/mtd/nand/s3c2410.c) was modified to adjust 
the timings.
- The serial driver (drivers/serial/s3c2410.c) was modified to pause the 
transmission and reception (via the flow control pins) before the 
frequency change, and reset the baud rate generator and unpause after 
the frequency change. It also tells the cpufreq driver which frequencies 
will work correctly.
- The framebuffer driver (drivers/video/s3c2410fb.c) was modified to 
adjust the timings and tell the cpufreq driver which frequencies will 
generate too much flicker. However, even after adjusting the pixel 
clock, I still get a bit of flicker in some frequencies.

The code has been lightly tested on a green-PCB GTA01Bv4 (including with 
the more demanding "ondemand" cpufreq governor). I have verified that 
gsmd can still talk to the modem, and the variable flicker gives visual 
feedback on the frequency changes. I haven't tested with a SD card (or 
even with a SIM), and didn't test sound/vibrator.

I plan to work next on the USB gadget driver (which not only has a 
minimum required frequency according to the datasheet but also for some 
reason misbehaves if in use during a frequency transition).

The code I am currently working on can be found at 
http://repo.or.cz/w/linux-2.6/s3c2410-cpufreq.git on the 
s3c2410-cpufreq-om branch; I will also reply to this message with the 

For more information, see http://wiki.openmoko.org/wiki/User:CesarB/cpufreq

Comments and suggestions are welcome. More information on the correct 
formula for the PLL lock time would also be good.

Cesar Eduardo Barros
cesarb at cesarb.net
cesar.barros at gmail.com

More information about the openmoko-kernel mailing list