From: Todd Poynor <tpoynor@mvista.com>
To: Jordan Crouse <jordan.crouse@amd.com>
Cc: linux-pm@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: PowerOP Take 2 0/3 Intro
Date: Thu, 25 Aug 2005 15:08:55 -0700 [thread overview]
Message-ID: <430E4177.10600@mvista.com> (raw)
In-Reply-To: <20050825210940.GX31472@cosmic.amd.com>
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
next prev parent reply other threads:[~2005-08-25 22:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-25 2:51 PowerOP Take 2 0/3 Intro Todd Poynor
2005-08-25 21:09 ` Jordan Crouse
2005-08-25 22:08 ` Todd Poynor [this message]
2005-08-31 20:04 ` [linux-pm] " Patrick Mochel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=430E4177.10600@mvista.com \
--to=tpoynor@mvista.com \
--cc=jordan.crouse@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox