The patches provided in the following three emails continue the unified,
simplified PowerOp concept of power management. The patches
can be found at:
http://source.mvista.com/~dsingleton
powerop-core.patch
powerop-cpufreq.patch
powerop-x86-centrino.patch
The patches break the working PowerOP feature into
three logical parts. The first patch is the powerop-core.patch
that adds support for an operating point in the standard linux
power management infrastructure (CONFIG_PM) and adds a new
function to perform transitioning to operating points other
than suspend to memory or disk.
The second patch, powerop-cpufreq.patch, adds the cpufreq
portion of the patch that makes cpufreq tables a set of PowerOp
operating points.
The third patch, powerop-x86-centrino.patch, adds
operating points for all the centrino-speedstep processors.
This set of patches has changed in the following ways.
1) The patch is now broken out of the cpufreq code and implements
operating points for whatever speedstep-centrino the system
detects upon boot.
2) The naming scheme for operating points has been unified to
provide a better interface to the PowerOp power manager daemon.
The names range from:
highest
high
medhigh
medium
medlow
low
lowest
PowerOp maps the supported processor frequencies onto this
namespace list. The set of centrino processors it supports have
supported sets of between four and six different operating points.
The PowerOP daemon, coming soon, can simply read the supported
set of operating points and make some simple rules based
decisions about when to transition to various operating points.
The goal of a unified name space is to provide a PowerOp manager
that runs out of the box, with very little setup by the user.
3) This patch supports the ability to provide dynamic, on-the-fly
operating points to the framework via a loadable module. The
operating
point parameters of frequency, voltage and transition latency
can be passed at insmod time to create any new operating point
the centrino hardware will support.
I think I finally understand the 'why' of hardware vendors asking
for a requirement of dynamic, on the fly, operating points.
I have two sets of hardware that support a wide range of
processor speeds and voltages depending on:
a) the rotary and dip switch setting of the board (the mainstone).
or
b) the revision or stepping of the hardware on the board.
Certain revs of hardware support different frequencies and
voltages.
Some steppings won't run all the frequencies.
The hardware vendors want to provide support for all the
frequencies and voltages that the system could support,
depending on the switch settings or rev of hardware without
having to change kernel code and recompile the kernel.
The new dynamic, on the fly, operating point module will allow
for this feature.
David
