public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: Re: Platform-specific system power states
Date: Sat, 23 Jun 2007 22:20:05 +0200	[thread overview]
Message-ID: <200706232220.06142.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0706222130440.11186-100000@netrider.rowland.org>

On Saturday, 23 June 2007 03:32, Alan Stern wrote:
> On Fri, 22 Jun 2007, Rafael J. Wysocki wrote:
> 
> > On Friday, 22 June 2007 21:49, David Brownell wrote:
> > > On Thursday 21 June 2007, Alan Stern wrote:
> > > > 
> > > > I'd be perfectly happy to have the list of supported system power 
> > > > states be exported by the platform code instead of predetermined by the 
> > > > PM core.  It would still be necessary to add a method whereby the PM 
> > > > core could inform the platform about the new target state at the 
> > > > beginning of a state change.  And of course there would have to be a 
> > > > way for drivers or subsystems to query the platform, to see what 
> > > > resources would be available.
> > > 
> > > Rafael will propose the new method, I guess;
> > 
> > Yes, I will.
> > 
> > Still, for now, I'm going to make it take an integer argument equal to either
> > PM_SUSPEND_STANDBY or PM_SUSPEND_MEM, since these are the only two sleep states
> > known to the core right now.
> > 
> > I think, however, that in the long run the better solution would be to make
> > the platform tell the PM core, during the initialization, what system sleep
> > states are available.  Then, before the transition, the PM core will tell the
> > platform which state is the target one.  IMO for this purpose the sleep will
> > need to be identified in a universal way and perhaps it's a good idea to
> > discuss that for a while. ;-)
> 
> A good way to identify a sleep state would be a pointer to a string 
> containing the state's name.  The PM core could use these pointers to 
> export the states in sysfs.

Well, I thought of exactly the same thing.

Perhaps we can generalize it a bit by defining:

struct pm_sleep_state {
	char *name;
};

and make the platforms give us a NULL-terminated array of such things during
the initializatiion.

Then, if it turns out to be convenient to add another field to this structure,
there won't be any problems with that.  Also, the platforms will be able to
embed a struct pm_sleep_state in their internal structures representing system
sleep states, if need be.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

  reply	other threads:[~2007-06-23 20:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44L0.0706211424170.14859-100000@iolanthe.rowland.org>
2007-06-21 19:51 ` Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help) David Brownell
2007-06-21 20:19 ` Rafael J. Wysocki
     [not found] ` <200706212219.52699.rjw@sisk.pl>
2007-06-21 20:32   ` David Brownell
     [not found]   ` <200706211332.23466.david-b@pacbell.net>
2007-06-21 20:50     ` Rafael J. Wysocki
     [not found] ` <200706211251.52952.david-b@pacbell.net>
2007-06-21 20:35   ` Rafael J. Wysocki
     [not found]   ` <200706212235.23947.rjw@sisk.pl>
2007-06-21 20:46     ` David Brownell
     [not found]     ` <200706211346.43198.david-b@pacbell.net>
2007-06-21 21:02       ` Rafael J. Wysocki
2007-06-21 21:00   ` Platform-specific system power states Alan Stern
2007-06-22 19:49     ` David Brownell
2007-06-22 21:30       ` Rafael J. Wysocki
2007-06-23  1:32         ` Alan Stern
2007-06-23 20:20           ` Rafael J. Wysocki [this message]
2007-06-25  0:10             ` David Brownell
2007-06-25 22:59               ` Rafael J. Wysocki
2007-06-25  0:26         ` David Brownell
2007-06-25 23:04           ` Rafael J. Wysocki

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=200706232220.06142.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=stern@rowland.harvard.edu \
    /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