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

On Thursday, 21 June 2007 16:48, David Brownell wrote:

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

quoted

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