Bruno Ducrot wrote:
> ATM I'm wondering what are the pro for those patches wrt current cpufreq
infrastructure (especially cpufreq's notion of notifiers).
I still don't find a good one but I'm surely missing something obvious.
This is lower layer than cpufreq, intended for use by cpufreq (and
potentially DPM and other frameworks, although moving embedded to use
cpufreq is certainly an option) to do the actual hardware modifications
at the lowest layer. There are no notifiers et al because the
higher-layer frameworks handle that portion of it. More on that in a
moment.
The main goal is to open up interfaces to operating points comprised of
arbitrary power parameters, as an alternative to the "cpu frequency"
parameter that cpufreq is designed around. In the desktop/server world
this may not be a high concern for two reasons: (1) although various
folks do want to manage voltages separately (namely so-called
"undervolting"), in most cases the safe answer is to stick with a
voltage preprogrammed into cpufreq that matches what the silicon vendor
as validated and supports; (2) various additional clocks, dividers, etc.
potential power parameters might exist in the hardware, but interfaces
for software control are often not readily available, and the associated
parameters are typically set once by the BIOS at boot time (possibly
with a menu to allow you override the defaults).
In the embedded world, however, silicon vendors typically produce
hardware that are run by, and specify validated operating points that
are comprised of, 6-7 basic parameters (clocks, voltages, dividers,
etc.), and in many cases it is useful to manage all these parameters for
additional battery savings at runtime (and these systems are often
powered by much smaller batteries than the notebooks powered by
desktop-class processors, and so more aggressive reductions in power
consumption may be pursued). Similar interfaces are already in use for
managing such hardware, with benefits that largely depend on the
capabilities of the hardware (in the case of the IBM PowerPC 405LP for
which it was originally developed this was pretty extensively studied).
It is possible, of course, to choose operating points according to cpu
frequency and hardcode the settings of other power parameters to match,
restricting the choices for the other parameters. There are, however,
power consumption and performance (primarily latency of transition
between operating points) advantages to being able to choose memory bus
speeds, core PLL speeds, voltages (yes, some embedded platforms do allow
this to be chosen within limits imposed by other clock speeds), etc.
The embedded hardware designers could probably express this more
eloquently than I can.
A secondary goal is to separate the code to perform platform-specific
hardware modifications from the upper layers which by necessity carry
various assumptions that may not be appropriate for all situations. The
notifiers are one example of this: DPM typically minimizes use of
notifiers and requires notifiers to be able to operate in interrupt and
in idle loop context, due to those additional situations in which DPM
manages power parameters.
--
Todd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/