Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Wednesday, 20 June 2007 16:08, Alan Stern wrote:
> On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
> 
> > > 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.
> > 
> > Alternatively, we could introduce a pm_target() global PM operation that will
> > set the target sleep state for the entire system.
> > 
> > I think we should discuss that on linux-pm before any decision is made.
> 
> Pardon me for asking what may be a dumb question.  Why does ACPI (or
> anything else) need to know the target system state in order to decide
> how a device should be suspended or whether wakeup should be enabled?

The question isn't so dumb. ;-)

For each device (handled by it) ACPI defines _SxD and _SxW methods returning
the highest power (lowest number) D-state supported by the device in the
(system-wide) state Sx and the lowest power (highest number) D-state in which
the device can wake up the system being in the Sx sleep state, respectively.
The target power state of the device should be determined on the basis of these
values (along with the device's wake up setting) and they depend on the target
system sleep state.

Greetings,
Rafael


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

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]

On Wednesday 20 June 2007, Alan Stern wrote:
> On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
> 
> Pardon me for asking what may be a dumb question.  Why does ACPI (or
> anything else) need to know the target system state in order to decide
> how a device should be suspended or whether wakeup should be enabled?

Because the things that distinguish different states are
the particular resources that are available in that state.

A device that needs resource X to be active (e.g. to wake
that part of the system) can't stay active in states where
X is unavailable.  A device that won't issue wakeup events
can probably enter lower power states.

I think it'd be pure confusion to care about whether wakeup
"should" be enabled in this state versus that one.  Enable it
when it's requested and possible, but otherwise there's nothing
to be done.  Runtime PM policies will mostly avoid device states
where wakeup can't work (unless it's disabled for that device),
but if the system enters a state where it can't, tough!


One canonical example is portions of the clock tree that
are available in one state but not another.  My pet example
being the USB clock, often 48 MHz, not being available in
deeper sleep states ... e.g.

  http://lkml.org/lkml/2007/3/22/241
  http://lkml.org/lkml/2007/3/22/242

It's routine for system power states to care about clocks
like that.  PXA 25x docs are probably where I first ran
across that issue, but docs for pretty much any SOC will
talk first about clocks when discussing power management.
(Current flows when clocks tick ...)


Another is power domains.  ACPI talks about those (but not
clocks!) as board level things ... e.g. turn off this power
supply on the mainboard.  Newer SOCs must manage these for
on-chip devices too, since newer manufacturing processes
(with smaller feature sizes) involve higher leakage current
(flowing even when clocks don't tick).

- Dave

[RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

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.

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

I think we should discuss that on linux-pm before any decision is made.

Greetings,
Rafael


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

[RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

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.

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

I think we should discuss that on linux-pm before any decision is made.

Greetings,
Rafael


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

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Alan Stern]

On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:

> > 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.
> 
> Alternatively, we could introduce a pm_target() global PM operation that will
> set the target sleep state for the entire system.
> 
> I think we should discuss that on linux-pm before any decision is made.

Pardon me for asking what may be a dumb question.  Why does ACPI (or
anything else) need to know the target system state in order to decide
how a device should be suspended or whether wakeup should be enabled?

Alan Stern

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Len Brown]

On Wednesday 20 June 2007 07:32, 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.
> 
> Alternatively, we could introduce a pm_target() global PM operation that will
> set the target sleep state for the entire system.
> 
> I think we should discuss that on linux-pm before any decision is made.

okay, this thread include linux-pm....

I support the proposal that pm_message_t include the target state
in addition to the phase of entering that state.
The reasoning is simple, device drivers that receive a pm_message_t
will do different things depending on the target state.
The example at hand is ACPI devices that need to know how deep a D-state
to go into based on the S-state, and this in-turn depends on if they
are enabled as wakeup devices or not.

thanks,
-Len

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]

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

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 09:04, David Brownell wrote:
> 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".

The issue at hand is that some device drivers may need to know what the
target sleep state of the system will be when their .suspend() routines are
being executed.  Currently, there's no means of passing that information to the
drivers and my question is how to do this.

IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.

Greetings,
Rafael


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

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Pavel Machek]

Hi!

> > > > 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".
> 
> The issue at hand is that some device drivers may need to know what the
> target sleep state of the system will be when their .suspend() routines are
> being executed.  Currently, there's no means of passing that information to the
> drivers and my question is how to do this.
> 
> IMO it can be done in two different ways:
> 1) via a .suspend() argument
> 2) via a global variable that the drivers can read.

Just do 1). Global variables are ugly, and we already have space in
pm_message_t. 
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

Hi,

On Thursday, 21 June 2007 15:03, Pavel Machek wrote:
> Hi!
> 
> > > > > 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".
> > 
> > The issue at hand is that some device drivers may need to know what the
> > target sleep state of the system will be when their .suspend() routines are
> > being executed.  Currently, there's no means of passing that information to the
> > drivers and my question is how to do this.
> > 
> > IMO it can be done in two different ways:
> > 1) via a .suspend() argument
> > 2) via a global variable that the drivers can read.
> 
> Just do 1). Global variables are ugly, and we already have space in
> pm_message_t. 

Well, this is what Len voted for, I think.  David is against it.

I also think that the cleanest way would be to pass that as an argument
to .suspend(), but currently pm_message_t. is passed by value and if we
made it a real struct (ie. with more than one field), that would also become
ugly, IMHO.

So, can we make pm_message_t consist only of the target state?

Greetings,
Rafael


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

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]

> > IMO it can be done in two different ways:
> > 1) via a .suspend() argument
> > 2) via a global variable that the drivers can read.

For sufficiently small values of "two" that is.  

Other solutions that have been described on the PM list include

  3) Providing accessors to the information actually needed
     in drivers ... e.g. say whether this clock or power domain
     will be available in that target state.

  4) Act more like "current" ... there's a function returning
     whatever "state" struct is settled on.  (But ideally
     without the pseudo-global.)

I'm amused that nobody really reacted to the technical comments in
my previous posts on this thread.  That's unfortunate, since from
where I sit it feels to me like everyone else is a johnny-come-lately
on this issue, and is now grasping at the quickest and dirtiest ways
to work around the issue instead of coming to grasp with the various
underlying issues.

IMO #3 is strongly preferable.


> Just do 1). Global variables are ugly, and we already have space in
> pm_message_t. 

There is no space in the ugly pm_message_t structure.  Adding to
that would involve creating a **larger** structure and passing it
around on the stack all the time.

Pavel, I know that for some perverse reason you actually like
that structure, and the notion of passing it around *BY VALUE*
instead of by reference.  But that approach has never been
universally acclaimed, and has in fact always had opposition;
the only way you got it merged in the first place was to send
in mountains of patches and ignore the negative feedback.

But I really thought the discussion on new PM methods, back a
couple months now, was going to finally get rid of that.

- Dave

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]

On Thursday 21 June 2007, Rafael J. Wysocki wrote:

> So, can we make pm_message_t consist only of the target state?

Let's just finally get rid of pm_message_t.

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 18:35, David Brownell wrote:
> On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> 
> > So, can we make pm_message_t consist only of the target state?
> 
> Let's just finally get rid of pm_message_t.

Fine.  How to we solve the problem at hand, then?


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

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 17:37, David Brownell wrote:
> 
> > > IMO it can be done in two different ways:
> > > 1) via a .suspend() argument
> > > 2) via a global variable that the drivers can read.
> 
> For sufficiently small values of "two" that is.  
> 
> Other solutions that have been described on the PM list include
> 
>   3) Providing accessors to the information actually needed
>      in drivers ... e.g. say whether this clock or power domain
>      will be available in that target state.

Well, you need to store that information somewhere.  The way in which
it will be provided to drivers is a secondary thing.

To me, the most important question is whether we want to pass that information
as a .suspend() argument or in any different way, which involves the use of a
global variable (or a set of variables) and that's 2).

>   4) Act more like "current" ... there's a function returning
>      whatever "state" struct is settled on.  (But ideally
>      without the pseudo-global.)

How would you be going to arrange that in practice?

> I'm amused that nobody really reacted to the technical comments in
> my previous posts on this thread.  That's unfortunate, since from
> where I sit it feels to me like everyone else is a johnny-come-lately
> on this issue, and is now grasping at the quickest and dirtiest ways
> to work around the issue instead of coming to grasp with the various
> underlying issues.
> 
> IMO #3 is strongly preferable.

Of course we can do that.  At least I don't have any objections.

Greetings,
Rafael


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

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]

On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> The issue at hand is that some device drivers may need to know what the
> target sleep state of the system will be when their .suspend() routines are
> being executed.  Currently, there's no means of passing that information to the
> drivers and my question is how to do this.

Actually what they need to know is some *attribute* of that state.

They really don't care what the state is.  The $SUBJECT patch isn't
driver code ... it's for platform hooks that expose attributes to
the drivers.  Specifically, it's ACPI code, talking to drivers that
must run on non-ACPI systems.  Any driver that thinks it needs to
understand anything about ACPI states is sadly broken.

Remember also that the Linux "states" (in /sys/power/state) are an
inadequate representation of what most hardware can do.  Common
hardware can support a lot more low power sleep modes than the two
states Linux currently defines ... a limitation inherited from
first APM, and them more recently ACPI, which doesn't fit embedded
systems well at all.

- Dave

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 16:48, David Brownell wrote:
> On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> > The issue at hand is that some device drivers may need to know what the
> > target sleep state of the system will be when their .suspend() routines are
> > being executed.  Currently, there's no means of passing that information to the
> > drivers and my question is how to do this.
> 
> Actually what they need to know is some *attribute* of that state.

Generally, yes.

> They really don't care what the state is.  The $SUBJECT patch isn't
> driver code ... it's for platform hooks that expose attributes to
> the drivers.  Specifically, it's ACPI code, talking to drivers that
> must run on non-ACPI systems.  Any driver that thinks it needs to
> understand anything about ACPI states is sadly broken.

But finally it has to place the device into a specific state and that state
needs to be determined somehow.  And, if ACPI is involved, it needs to be
told at one point if the final system state is supposed to be S1 or S2 or S3
(I guess we can discard S2 safely) just to tell the driver which power states
of the device are suitable.

That's why I thought we might introduce an additional global pm_op that
could be used to provide ACPI with that information without engaging drivers in
passing it.

> Remember also that the Linux "states" (in /sys/power/state) are an
> inadequate representation of what most hardware can do.

Do we really want to introduce more system sleep states right at this point?

> Common hardware can support a lot more low power sleep modes than the two
> states Linux currently defines ... a limitation inherited from first APM, and
> them more recently ACPI, which doesn't fit embedded systems well at all.

I agree with that, but right now we have an ACPI-related problem at hand.

Greetings,
Rafael


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

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]

On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> On Thursday, 21 June 2007 16:48, David Brownell wrote:

> > They really don't care what the state is.  The $SUBJECT patch isn't
> > driver code ... it's for platform hooks that expose attributes to
> > the drivers.  Specifically, it's ACPI code, talking to drivers that
> > must run on non-ACPI systems.  Any driver that thinks it needs to
> > understand anything about ACPI states is sadly broken.
> 
> But finally it has to place the device into a specific state and that state
> needs to be determined somehow. 

I suppose I'm still thinking that the approach in my original
patch works Just Fine.  Layering is kind of like this, going
from top to bottom (and omitting the go-to-pci-hardware stack,
and the initial ACPI pm hook before suspension starts):

	PM infrastructure ... calling suspend() for everything

	PCI bus support ... translates to PCI-specific typed call

	PCI driver ... suspend() calling pci_choose_state()

	ACPI support for PCI ... implementing choose_state()

	ACPI core code ... remembering ACPI_STATE_Sx, calling AML

That is, ACPI gets invoked at various points, but the driver and
core code doesn't need to know ACPI from Rumpelstiltskin.

- Dave

Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 22:22, David Brownell wrote:
> On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> > On Thursday, 21 June 2007 16:48, David Brownell wrote:
> 
> > > They really don't care what the state is.  The $SUBJECT patch isn't
> > > driver code ... it's for platform hooks that expose attributes to
> > > the drivers.  Specifically, it's ACPI code, talking to drivers that
> > > must run on non-ACPI systems.  Any driver that thinks it needs to
> > > understand anything about ACPI states is sadly broken.
> > 
> > But finally it has to place the device into a specific state and that state
> > needs to be determined somehow. 
> 
> I suppose I'm still thinking that the approach in my original
> patch works Just Fine.  Layering is kind of like this, going
> from top to bottom (and omitting the go-to-pci-hardware stack,
> and the initial ACPI pm hook before suspension starts):

We're missing that hook right now. ;-)

> 	PM infrastructure ... calling suspend() for everything
> 
> 	PCI bus support ... translates to PCI-specific typed call
> 
> 	PCI driver ... suspend() calling pci_choose_state()
> 
> 	ACPI support for PCI ... implementing choose_state()
> 
> 	ACPI core code ... remembering ACPI_STATE_Sx, calling AML
> 
> That is, ACPI gets invoked at various points, but the driver and
> core code doesn't need to know ACPI from Rumpelstiltskin.

I agree with that, but we need to add a mechanism to tell the ACPI core
what it needs to know (ie. the target system sleep state) before we suspend
devices or while we are suspending them.

Greetings,
Rafael


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

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]

On Wednesday 20 June 2007, Len Brown wrote:

> I support the proposal that pm_message_t include the target state
> in addition to the phase of entering that state.
> The reasoning is simple, device drivers that receive a pm_message_t
> will do different things depending on the target state.

They should do that based on attributes of the target state,
not any particular notion (e.g. from ACPI) of what the states
may be ...


> The example at hand is ACPI devices that need to know how deep a D-state
> to go into based on the S-state, and this in-turn depends on if they
> are enabled as wakeup devices or not.

None of that needs to involve growing pm_message_t (yeech!),
or even knowing that this system's PM infrastructure uses ACPI.

The ACPI bits need to know about ACPI target state, agreed, but
such stuff can (and should!) be interfaces that normal drivers
never see.

In fact, that's why pci_choose_state() exists.  Its implementation
has always sucked, sure, but not the notion that ACPI can answer
the question following APCI rules, while other PCI platforms can
answer the question using other (non-ACPI) rules.  And likewise
for other device types, including SOC devices.

- Dave