View source for User:CesarB/cpufreq
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Template used on this page:
Return to User:CesarB/cpufreq.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Template used on this page:
Return to User:CesarB/cpufreq.
The cpufreq subsystem is a Linux kernel subsystem responsible for managing the CPU frequency. It's commonly used in laptops to reduce power usage when idle.
On the S3C2410, adjusting the CPU frequency changes the clocks for almost all devices on the chip. This means that, to write a cpufreq driver for the S3C2410, you have to also adjust some values on almost all devices.
This project aims to implement the cpufreq driver (which manages the CPU frequency transitions) and a cpufreq notifier for all the affected drivers (to do two things: quiesce the device before the change, and adjust the frequency after the change). Deciding which frequency to use is the responsability of code from somewhere else (either cpufreq governors or userspace).
The most recent version of the code can be found at http://repo.or.cz/w/linux-2.6/s3c2410-cpufreq.git on the branches s3c2410-cpufreq (for code which applies on top of the upstream "git HEAD" kernel) and s3c2410-cpufreq-gta01 (for code which applies on top of the OpenMoko patched kernel).
NOTE: Do not run on real hardware, unless you really know what you are doing. This code is completely untested. It might even not compile. |
You need a fully built OpenMoko tree for the cross-compiler and uboot tools.
.config
file
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- oldconfig
and answer correctly the questions
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
CONFIG_CPU_FREQ_DEBUG
and add cpufreq.debug=7
to the kernel command line to enable the relevant debug output. You can also enable it after boot by going to the correct place at /sys/modules and changing the values there.
git format-patch -o dir master..s3c2410-cpufreq
to generate a set of patches, and apply them all on top of the OpenMoko patches 2.6.22.5 kernel, except the framebuffer patch(es) (the 2.6.24.x code for the framebuffer is different from the 2.6.22.5 one).
This code resides on arch/arm/mach-s3c2410/s3c2410-cpufreq.c
and is responsible for actually changing the frequency.
The list of available frequencies and their parameters (HCLK/PCLK dividers) can be found on this file.
Timer 4 is used by the kernel as the periodic tick timer. The cpufreq notifier on arch/arm/plat-s3c24xx/time.c
is responsible for adjusting the current and reload values of the timer to match the new frequency.
The cpufreq notifier on drivers/serial/s3c2410.c
is responsible for (if possible) pausing both sides of the serial transmission before the frequency change and reloading the baud generator (and unpausing the serial transmission) after the change.
Pausing the transmission is currently only possible with hardware flow control. Since both serial ports on GTA01 use hardware flow control, that's not a problem (unless you are using the serial console).
The cpufreq notifier on drivers/video/s3c2410fb.c
is responsible for turning off the video before the frequency change and reloading its configuration after the frequency change.
The cpufreq notifier on drivers/mtd/nand/s3c2410.c
is responsible for reprogramming the NAND timings after a frequency change.
The frequency table should be checked for better divisor values (1:1:1 might be appropriate in more situations), and the code should be able to deal with HDIVN1 and different bus modes.
The cpufreq notifier should perhaps use a higher priority, so as to run before all the others for more precise timekeeping.
The cpufreq notifier should make sure the NAND is quiesced before the frequency change, or change the timings to the most conservative ones before the frequency change.
Some drivers need specific frequencies. Currently there's no way to tell the cpufreq core of that, but at minimum a cpufreq notifier should be used to turn them off if they won't be able to work with that frequency.
2.6.24.x doesn't boot on GTA01. I hand-extracted the patches and applied them all on top of GTA01's 2.6.22.5 kernel, except for the framebuffer patch (which depends on some changes made after 2.6.24). It was booted on a GTA01 without the SD card or the SIM attached (just in case). The results were:
Same 2.6.22.5 kernel, with several bugfixes applied (in particular, the problem which prevented the timer notifier from running was fixed).
This time, the whole test was done from the terminal, to avoid the USB lockup.
After a few more bugfixes, still 2.6.22.5, also tested from the terminal (untethered).
This time, due to the nature of the tests, I commented out all speeds below 12000 kHz.
cat scaling_cur_speed
locked up (not answering to Ctrl-C/Ctrl-Z); requested a shutdown via the power menu, which worked (still with the severe flicker showing it was still at 12000 kHz.
Another test was to see if gsmd still worked.
libgsmd-tool -m atcmd
and checking for the response: worked at 266000, 133000, 66000, 33000, and failed at 12000 (timeout).
Trying to find out why gsmd stops working at 12000.