From: Adam Belay <abelay@novell.com>
To: David Brownell <david-b@pacbell.net>
Cc: linux-pm@lists.osdl.org
Subject: Re: [RFC] A New Power Management API
Date: Sun, 17 Apr 2005 16:25:17 -0400 [thread overview]
Message-ID: <1113769518.3451.87.camel@localhost.localdomain> (raw)
In-Reply-To: <200504161027.53592.david-b@pacbell.net>
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Sat, 2005-04-16 at 10:27 -0700, David Brownell wrote:
> On Thursday 14 April 2005 7:46 pm, Adam Belay wrote:
>
> > The new API uses a power container/domain model.
>
> I like that as a basic organizing principle, and I don't think
> anyone has problems with the notion that the power relationships
> can't always map directly to the physical device tree.
>
> Could you describe a bit about how the containers behave? For
> example, when a device drops its power consumption, how does it
> notify its container? And when sets of devices -- e.g. all USB
> devices, all PCI devices -- support the same power states, how
> will that code be shared? Would "struct power_device" be the
> driver model replacement for "struct power"?
Here are my current thoughts:
When greatest common denominator of power requirements is lowered (as a
result of a power_device lowering its state), the policy manager of the
container "struct power_device" will be notified. Code for the same
states will not be shared, because the method of transitioning these
states is different. Also their meanings are often different. However,
if the states are the same, the mappings will likely be simplistic.
Every "struct device' will have a "struct power_device", but not every
"struct power_device" must have a "struct device". "struct
power_device" will be the base unit of power management topologies.
>
> Also, I'd rather see "struct system_power_state *" everywhere
> you're now passing "int system_state" in the API.
>
> - Dave
Fixed. Thanks for the suggestion.
Adam
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2005-04-17 20:25 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
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 [this message]
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=1113769518.3451.87.camel@localhost.localdomain \
--to=abelay@novell.com \
--cc=david-b@pacbell.net \
--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