CPU Speed in HAL

[Richard Hughes]

As most of you probably know, most new laptops can scale the speed of
the cpu to save considerable amounts of power. Now I've persuaded my
kernel to load the speedstep module, I've found my battery life
*substantially* increases when I scale my CPU manually.

CPU speed is usually taken care of by system daemons such as cpuspeed,
cpufreqd, powernowd, speedy or by a setuid applet such as the cpufreq
applet. What I'm proposing is that we move the raw information reporting
(from sysfs and procfs) into HAL. This means session programs such as
the cpufreq applet and g-p-m do not have to be set setuid to talk to the
hardware. I appreciate there are already daemons that just sit and poll
the cpufreq hardware, which you can talk to in many different ways, but
to make all the elements "just work" I think we need a really simple HAL
API so that the cpufreq applet and g-p-m (and potentially other daemons)
can take advantages of the abstraction.

What I'm proposing:
On the CPU devices (which we have already for acpi) two additional keys:
strlist	cpufreq.allowed_frequencies
int	cpufreq.current_frequency

And one additional method.
bool	o.fd.h.Device.SystemPowerManagement.SetCPUFrequency(int frequency)

I'm not thinking of exporting stuff like the kernel cpufreq policy, or
the voltage steps as this is either not required, or can be done at
higher levels (such as manually with the applet and automatically with
g-p-m).

The method can be a simple script (like SetLCDBrightness) or a simple
c-file (if we want to check that the frequency range is valid before we
shunt it into sysfs or procfs) -- probably a good idea. All the patches
are likely to be less than a few hundred lines of code.

If this works okay in HAL, I would send patches to the cpufreq applet
author to use HAL as an optional "backend" (just like has been done for
the battstat applet) so that the low level hardware code can be
depreciated.

This is something I would really like to add to HAL. Comments please.

Richard.