public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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