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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/