Re: Nested suspends; messages vs. states

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

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

On Monday 21 March 2005 2:26 pm, Pavel Machek wrote:
> On Po 21-03-05 16:14:09, Alan Stern wrote:
> > On Mon, 21 Mar 2005, Pavel Machek wrote:
> > 
> > > > 	pm_message_t		power_state;
> > > > 
> > > > Obviously a message isn't the same thing as a state.  This looks like 
> > > > something that will need to be changed in a lot of drivers when we 
> > > > introduce the new notion of a power state.
> > > 
> > > This is not so obvious to me. 

It's a semantics thing, among others.  "System transitioning to
state Z" is a message, as is "system leaving state Z".  Both are
distinct from the "system state Z" being described.

Just like the system power state is distinct from the power state
of each device in the system.


> > > Message seems to represent the state 
> > > driver is in quite well... Plus we need PMSG_ON for state the device
> > > gets after resume, but that's quite easy...
> > 
> > So what value for power_state do you use to tell apart PCI D1 from D2?
> 
> You just ask via pci_choose_state(), and it tells
> you... pci_choose_state() should be deterministic.

Gaack, that again?  No.  Different devices support different
states, so it's got to depend on at least the device hardware
and the target system state.  Not "deterministic" as in the
current version.  I'm going to have to dig up the original
code, it didn't have bugs like that.

Also driver capabilities matter, since they don't all know how
to cope with the partial device reset that may be associated with
transition from D3 (but not D2 or D1) ... but at least in that
case the driver can ensure it doesn't choose PCI_D3 unless it
can actually cope with that result.

- Dave




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