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 <david-b@pacbell.net>]

On Wednesday 20 June 2007, Rafael J. Wysocki wrote:
> On Wednesday, 20 June 2007 08:18, Shaohua Li wrote:
> > On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
> > > > Based on David's patch
> > > > http://marc.info/?l=linux-acpi&m=117873972806360&w=2
> > > > I slightly changed it.
> > > > 
> > > > Add a helper routine, which gets the sleep state of a ACPI device.
> > > 
> > > Is it going to work with the recent code ordering changes?  I mean,
> > > acpi_pm_prepare() is now called after device_suspend() (and analogously for
> > > the hibernation), so the target ACPI state is not known when the drivers'
> > > .suspend() routines are being called.
>
> > Not. Could pm_message_t have a member indicating the suspend state?
> 
> Well, I thought about that, but I did't know what people on linux-pm would
> think about that.

Let's get rid of pm_message_t entirely.  Didn't we already discuss
how the main reasons for it will vanish if drivers get new PM methods?

 
> Alternatively, we could introduce a pm_target() global PM operation that will
> set the target sleep state for the entire system.

I hope you mean "get the target state"!!

If drivers actually need a handle on that state, that'd be a fair
approach; make it an opaque type though, platform-specific.

But actually I don't see much point to having such a struct.  What
matters is the attributes of the target state (what resources will
be present, especially), and that rarely needs to be indicated by
any kind of cookie.  Consider the "current" task ... it's implicit,
always present (except in IRQ contexts), and hardly ever accessed
despite being more fundamental than "target PM state".

- Dave