You need a fully built OpenMoko tree for the cross-compiler and uboot tools.

You need a fully built OpenMoko tree for the cross-compiler and uboot tools.

−

# Checkout the s3c2410-cpufreq-om branch

+

# Checkout the s3c2410-cpufreq-om branch (or the wip branch for work in progress)

# Copy the defconfig file from branches/src/target/kernel/2.6.24.x/config on the OpenMoko svn as the <code>.config</code> file

# Copy the defconfig file from branches/src/target/kernel/2.6.24.x/config on the OpenMoko svn as the <code>.config</code> file

# Set the PATH to the correct value (check the run.* temporary files bitbake generates to find out the correct value)

# Set the PATH to the correct value (check the run.* temporary files bitbake generates to find out the correct value)

Revision as of 02:53, 3 February 2008

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).

To build

NOTE: Do not run on real hardware, unless you really know what you are doing. This code is mostly untested, and changes frequently. It might even not compile.

You need a fully built OpenMoko tree for the cross-compiler and uboot tools.

Checkout the s3c2410-cpufreq-om branch (or the wip branch for work in progress)

Copy the defconfig file from branches/src/target/kernel/2.6.24.x/config on the OpenMoko svn as the .config file

Set the PATH to the correct value (check the run.* temporary files bitbake generates to find out the correct value)

Run make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- oldconfig and answer correctly the questions

Run make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

The last line of the output tells you the correct file which should be flashed on the emulator.

Hints

Enable 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.

To test on 2.6.22.5, use git format-patch -o dir master-om..s3c2410-cpufreq-om 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).

What's already done

Driver

Status

core

Working

timer

Working

nand

Working

serial

Working

framebuffer

Working

S3C2410A cpufreq driver

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 driver

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.

Serial driver

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).

Framebuffer driver

The cpufreq notifier on drivers/video/s3c2410fb.c is responsible for dynamically changing the frequency divider used to derive the video clocks.

NAND driver

The cpufreq notifier on drivers/mtd/nand/s3c2410.c is responsible for reprogramming the NAND timings after a frequency change.

What's missing

S3C2410A cpufreq driver

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.

Missing drivers

Backlight (uses a PWM timer; not a problem with full brightness)

Vibrator (uses a PWM timer)

MMC/SD (can be avoided by not plugging it in)

I2C (without a notifier and booting at the maximum speed, it can only get slower; there should be no side effects, since there's no minimum bus speed)

IIS

SPI

GTA02 driver

The GTA02 uses a different (but similar) SoC. Parts of the code have to be changed to be able to work on both. Also, part of the serial notifier code is specific to each kind of SoC.

Frequency restrictions

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.

The datasheet says the USB device gets unstable if the frequency is below a minimum value

When using the IIS device, changing the frequency might not be a good idea, since it can cause audio glitches. It also probably needs a minimum frequency depending on the output audio frequency and sample size.

The LCD device might also need a minimum frequency.

The serial baudrate generator might not have a good enough divider value for some baud rates and some clock frequencies (for instance, 115200 at 12000 kHz)

See also

Views

Personal tools

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).

To build

NOTE: Do not run on real hardware, unless you really know what you are doing. This code is mostly untested, and changes frequently. It might even not compile.

You need a fully built OpenMoko tree for the cross-compiler and uboot tools.

Checkout the s3c2410-cpufreq-om branch

Copy the defconfig file from branches/src/target/kernel/2.6.24.x/config on the OpenMoko svn as the .config file

Set the PATH to the correct value (check the run.* temporary files bitbake generates to find out the correct value)

Run make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- oldconfig and answer correctly the questions

Run make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

The last line of the output tells you the correct file which should be flashed on the emulator.

Hints

Enable 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.

To test on 2.6.22.5, use git format-patch -o dir master-om..s3c2410-cpufreq-om 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).

What's already done

Driver

Status

core

Working

timer

Working

nand

Working

serial

Working

framebuffer

Working

S3C2410A cpufreq driver

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 driver

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.

Serial driver

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).

Framebuffer driver

The cpufreq notifier on drivers/video/s3c2410fb.c is responsible for dynamically changing the frequency divider used to derive the video clocks.

NAND driver

The cpufreq notifier on drivers/mtd/nand/s3c2410.c is responsible for reprogramming the NAND timings after a frequency change.

What's missing

S3C2410A cpufreq driver

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.

Missing drivers

Backlight (uses a PWM timer; not a problem with full brightness)

Vibrator (uses a PWM timer)

MMC/SD (can be avoided by not plugging it in)

I2C (without a notifier and booting at the maximum speed, it can only get slower; there should be no side effects, since there's no minimum bus speed)

IIS

SPI

GTA02 driver

The GTA02 uses a different (but similar) SoC. Parts of the code have to be changed to be able to work on both. Also, part of the serial notifier code is specific to each kind of SoC.

Frequency restrictions

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.

The datasheet says the USB device gets unstable if the frequency is below a minimum value

When using the IIS device, changing the frequency might not be a good idea, since it can cause audio glitches. It also probably needs a minimum frequency depending on the output audio frequency and sample size.

The LCD device might also need a minimum frequency.

The serial baudrate generator might not have a good enough divider value for some baud rates and some clock frequencies (for instance, 115200 at 12000 kHz)