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
out-of-band.
- 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
driver:
- 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
patches.
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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
