public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jordan Crouse" <jordan.crouse@amd.com>
To: linux-pm@lists.osdl.org
Subject: Re: [RFC] A New Power Management API
Date: Fri, 15 Apr 2005 09:50:03 -0600	[thread overview]
Message-ID: <20050415095003.52f3185a@cosmic.amd.com> (raw)
In-Reply-To: <1113533193.3451.40.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Adam - 

Nice stuff.  A few comments.  First, a question:

Is it safe to assume that PMU devices  (like these:
 http://www.dialog-semiconductor.com/template.php?page_id=62) would fall
under the category of Power Resources?  if so, we may need to consider
some more advanced hooks than just on/off.

Secondly, I have some comments regarding the system states, especially
the last three.  While those three states are important, right off the
bat I can think of several scenarios where additional power states could
be imagined.  I fear that if we hard code these states, then every
individual with a slightly different usage model on a given platform
would have to patch the kernel accordingly.  This isn't such a far
fetched scenario on an embedded platform.

This is where I see the policy managers taking a greater role.  In
addition to the hard coded states (the first five you defined sound fine
to me), the user would define a number of pseudo system states as well
as define the translation tables for device states under those pseudo
states. Each pseudo state would be registered with the PM core and
assigned a unique identifier.

We would then define a system state flag, say
PM_SYSTEM_STATE_PSEUDO, which would prompt a driver to query its policy
manager to get the translation for the right device state.  Those
devices that don't understand or care about user defined power
states would simply ignore the flag.

I think that way we could keep things simple for for the laptop /
desktop folks while still providing a bit of flexibility on the embedded
side of things.

Regards,
Jordan

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






 


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2005-04-15 15:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15  2:46 [RFC] A New Power Management API Adam Belay
2005-04-15  8:21 ` Benjamin Herrenschmidt
2005-04-15 13:16 ` Daniel Petrini
2005-04-15 18:20   ` Adam Belay
2005-04-16 17:13   ` David Brownell
2005-04-17 20:26     ` Adam Belay
2005-04-15 15:50 ` Jordan Crouse [this message]
2005-04-15 18:54   ` Adam Belay
2005-04-16  2:53     ` Todd Poynor
2005-04-16 19:26       ` David Brownell
2005-04-19  3:09         ` Todd Poynor
2005-05-08 19:05           ` David Brownell
2005-04-16 18:24     ` David Brownell
2005-04-17 20:48       ` Adam Belay
2005-04-17 22:29         ` David Brownell
2005-04-17 23:01           ` Adam Belay
2005-04-16 17:27 ` David Brownell
2005-04-17 20:25   ` Adam Belay

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=20050415095003.52f3185a@cosmic.amd.com \
    --to=jordan.crouse@amd.com \
    --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