[lkml]   [2002]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH][2.5.35] CPU frequency and voltage scaling (0/5)
Hi Linus, hpa, lkml,

The following patches add CPU frequency and volatage scaling
support (Intel SpeedStep, AMD PowerNow, etc.) to kernel 2.5.35.

As was discussed last time, the cpufreq patches have been reworked to use a
policy-based approach now. A cpufreq policy consists of four values:
cpu - the affected CPU nr., or CPUFREQ_ALL_CPUS for all cpus
min - minimum frequency in kHz
max - maximum frequency in kHz

The interface to userspace is /proc/cpufreq, and the user can "echo" a new
policy into this file using the following syntax:
[cpu:]min_freq:max_freq:policy or

with policy either "powersave" or "performance". The cpu argument is

In cpufreq drivers for "dumb" hardware which can only be set to a specific
frequency (and not to a frequency range), one value within the policy range
is selected, and the CPU is statically set to this frequency until a new
policy is set. "Virtual" dynamic frequency changing is not yet implemented.

For more information, take a look at the file Documentation/cpufreq in
patch 4/5.

Patch 1/5: cpufreq-core
The cpufreq core offers a common interface to the CPU clock
speed features of ARM, PPC and x86 CPUs.

In order for this code to be built, an architecture must define the
CONFIG_CPU_FREQ configuration symbol. The i386 code follows in
parts 2 and 3, the ARM and PPC ports will most likely follow in the
next days or weeks.

Specifically on ARM CPUs, cpufreq_notify_transition is especially
important, since various ARM system on a chip implementations
derive peripheral clocks from the CPU clock (eg, LCD controllers,
SDRAM controllers, etc). The core allows these peripherals to take
action either prior and/or after the actual CPU clock adjustment so
we don't go out of tolerance. Please note that CPUFREQ_TRANSITION_NOTIFIERS
are only called on "dumb" cpufreq hardware. On Transmeta Crusoe processors,
where core frequency changes have no external implications, these can safely
be ignored.

Patch 2/5: cpufreq-i386-core
The main part of this patch is a CPUFreq transition notifier in
arch/i386/kernel/time.c. It updates the i386-specific cpu_khz,
cpu_data[].loops_per_jiffy and fast_gettimeoffset_quotient on
each frequency change.

Additionally, this patch allows "cpu_khz" to be exported (it is needed
for some cpufreq drivers) and adds transmeta-related MSR #defines to

Patch 3/5: cpufreq-i386-drivers
Six i386 CPUFreq drivers are ready to be merged this time. These are:
elanfreq.c: The AMD Elan CPU family offers extensive clock scaling
longhaul.c: VIA Longhaul processor clock + voltage scaling
longrun.c: Transmeta Crusoe Longrun clock + voltage scaling
p4-clockmod.c: clock modulation on P4 Xeon processors
powernow-k6.c: mobile AMD K6-2+ / mobile AMD K6-3+ clock scaling
speedstep.c: clock and voltage scaling on mobile Intel Pentium 3 and 4s,
but (unfortunately) only on ICH2-M or ICH3-M based

Support for mobile AMD K7 processors is still in development.

Patch 4/5: cpufreq-doc
an entry to the CREDITS and the MAINTAINERS files, texts, and
extensive documentation in linux/Documentation/cpufreq

Patch 5/5: cpufreq-core-24api
Some user-space tools already rely on the "old", one-frequency
/proc/sys/cpu/ interface suggested previously. This add-on patch allows a
CONFIG option which emulates this interface but still uses the policy
interface towards the cpufreq drivers.
Please note that the other patches do not rely on this patch and work fine
without this patch applied, but only with the /proc/cpufreq interface.

Comments welcome; however please ensure that the cpufreq development
list at receives a copy of all comments.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:22    [W:0.059 / U:7.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site