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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|