PowerOP Take 2 0/3 Intro

PowerOP Take 2 0/3 Intro

[Todd Poynor]

PowerOP is a system power parameter management API submitted for
discussion.  PowerOP writes and reads power "operating points",
comprised of arbitrary values, called power parameters, that correspond
to registers, clocks, dividers, voltage regulators, etc. that may be
modified to set a basic power/performance point for the system.
Higher-layer power management software passes a platform-specific struct
of power parameters to a backend that makes the requested adjustments.

PowerOP can be thought of as a layer below cpufreq that actually
accesses the hardware to make cpu frequency, voltage, core bus, and
perhaps other modifications to set a power point.  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.  It pushes the hardware-level power
parameter management down to a level that can be shared with other power
management policy frameworks that deal with entire operating points as
the basic unit of system power management for reasons described below,
and that 

The new layer is intended to leave all power policy decisions, and
various other power management chores such as driver notification, to
higher layers in a power management software stack.

This work is aimed in part at supporting embedded systems, which often
have several parameters that can be set and the cpu frequency
abstraction specifies only part of the operating point that may be
managed from software.  For example, an XScale PXA27x could be
considered to have six basic power parameters (mainly cpu run mode and
memory and bus dividers) that for the most part should be set in tandem
to known good sets of values as validated by the silicon vendor.
Embedded systems typically handle more hardware clock manipulation
directly in Linux than do, for example, desktop/server systems based on
ACPI interfaces.  Desktop/server systems may also benefit from the
ability to select custom voltages, bus speeds, etc., although deviating
from values validated by the hardware vendor is risky and controversial.

An optional sysfs interface to create and activate operating points is
also submitted for discussion.  This interface could be used in an
actual power management stack, or at least can serve as a starting point
for discussing how to manage operating points at the next higher layer
in the power management soctware stack.

cpufreq is another possible interface. PowerOP can fit below cpufreq to
make cpu frequency, voltage, core bus, and perhaps other modifications
to set a power point, leaving cpufreq to manage the interfaces based
around the "cpu frequency" abstraction, the policies and governors that
select the frequency, its notifiers, and so forth.  An example hooking
up support for one cpufreq platform to PowerOP has been previously
submitted.  Some discussion regarding incorporating an expanded set of
power parameters into the cpufreq interfaces has also taken place.

Re: PowerOP Take 2 0/3 Intro

[Jordan Crouse]

Todd - do you have a ChangeLog from Take 1? :)

Jordan
-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

Re: PowerOP Take 2 0/3 Intro

[Todd Poynor]

Jordan Crouse wrote:
> Todd - do you have a ChangeLog from Take 1? :)

Right, here's what's changed in this version...

The generic structure of an operating point as an array of integers is 
dropped.  A struct powerop_point is now an entirely backend-defined 
struct of arbitrary fields.

There is no more PowerOP core layer; all data structures and functions 
for core functionality are provided by the machine-specific backend.

The diagnostic sysfs UI has been split out into a separate, optional 
patch.  A more full-featured UI allowing operating point creation and 
activation via sysfs has also been provided in that patch.  This UI 
primarily serves as an example for experimentation purposes, but is 
pretty close to what a basic userspace-based policy manager might need 
to switch operating points in response to infrequent changes in system 
state.

The UI also embodies the notion of a list of "named operating points" 
that could be registered by other means, such as loading a module with 
data structures that encode the desired operating points (as David 
Brownell has suggested).  The named operating points registered from 
such other interfaces can also be activated from the sysfs UI (that is, 
the hardware can be told to run at that operating point), as an example 
of how to tie in userspace policy managers with such a scheme.

The example platform backend this time is for an embedded system: the TI 
OMAP1 family of processors used for numerous mobile phones and PDAs.  It 
may better illustrate why managing multiple power parameters might be a 
useful capability.  I haven't put out an example of cpufreq integration 
this time, but the idea has changed little from before.

In case it's getting lost in all these details, the main point of all 
this is to pose the question: "are arbitrary power parameters arranged 
into a set with mutually consistent values (called here an operating 
point) a good low-level abstraction for system power management of a 
wide variety of platforms?"  Thanks,

-- 
Todd

Re: [linux-pm] Re: PowerOP Take 2 0/3 Intro

[Patrick Mochel]

On Thu, 25 Aug 2005, Todd Poynor wrote:

> In case it's getting lost in all these details, the main point of all
> this is to pose the question: "are arbitrary power parameters arranged
> into a set with mutually consistent values (called here an operating
> point) a good low-level abstraction for system power management of a
> wide variety of platforms?"  Thanks,

Yes, I think so. This seems to be one of the main concerns of the embedded
platform developers, especially e.g. the OMAP people.

The thing I'm most concerned about is integration with other mainstream
platforms. cpufreq works reasonably well for desktop and laptop system,
for CPU frequency. But, I expect to see more flexibility in the power
management parameters in other aspects of the system in the near future.

How do we deal with that? If it's PowerOP, then how does it interact with
cpufreq and its user space tools? If it's used in conjunction (using
cpufreq for the CPUs and PowerOP for everything else), what can we do to
integrate the UI?

Personally I think that they are fine sitting side by side for now, but we
need to do some work on the low-level tools. For one, setting 8 values in
sysfs to effect a change is not very friendly. For another, it took a long
time to get the cpufreq stuff right. How do we learn from that and avoid
that?

Thanks,


	Pat