Re: Nested suspends; messages vs. states

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

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

On Wednesday 23 March 2005 11:37 am, Jordan Crouse wrote:
> 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. 

Why wouldn't "can't enter compatible state" be an error case, preventing
entry to that 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.

I'll pick on that example though:  the audio output and radio input
will be separate devices, with separate management.  Audio won't be
providing a reason to drop the call; that'd be specific to the radio
handling code.


> 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).

There's no problem with different devices having different power
states.  They're different devices for a reason, after all!

The radio needs to be active enough to detect it's the target
of a call, and issue a system wakeup event.  Then the rest of
the system needs to be able to wake up quickly enough not to
make the user doze off.  :)


> 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.

No, it would by definition be compatible.  Otherwise the system
couldn't enter that state!  There's no rule saying that all
PCI devices must be in PCI_D3 state when the system is in S3.
PCI D1 or D2 states can be more appropriate ... Ben has lots
of video driver examples (devices are sometimes reset in D3, and
maybe Linux relies on BIOS init), and there are other cases  too.

- Dave

 
> Jordan
> 
> 
> 
> 

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