Re: Nested suspends; messages vs. states

["Jordan Crouse" <jordan.crouse-5C7GfCeVMHo@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Wed, 23 Mar 2005 10:58:54 -0800
"David Brownell" <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:

> So, two types of request to drivers then.  The main one would be to
> become compatible with a given system power state; flexible.  The
> inflexible one would be to go into a specific device power state.

I like the idea of the flexible request.  This would add the ability for
the policy to individually manage devices that for one reason or another
cannot or should not enter a power state compatible with the system
power state. 

As an illustrative example, I'm thinking of a fictitious VoIP phone with
an audio device that has an abnormally large latency resuming from a
clocks off power state, so by the time it wakes up and is ready to go,
the incoming call is lost.  At this point, the user/developer/designer
could decide that the the extra power consumed by leaving the clocks on
is less important then having a responsive device, and the policy is set
so that the device only enters a D1 state with a suspend-to-ram system
power state, rather then a D3 state as it normally would (pardon the
PCI/ACPI terms, they're just for simplicity).

In that case, even though the device state wouldn't technically be
compatible with the given system state, it would still be the
best fit for the platform as a whole.

Jordan




[-- Attachment #2: Type: text/plain, Size: 0 bytes --]