Re: Nested suspends; messages vs. states

[Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>]

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

Hi!

> > > > > 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. 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.
> 
> That's useless for sysfs.  It won't know to call pci_choose_state when it 
> has to display the device's current power state in an attribute file.  Nor 
> will it know what pm_message_t to send the driver when the user writes the 
> string "D2" to the attribute.

And do we really want user writing D2 to /sys file?

> Even just from first principles the mistake is apparent.  pm_message_t is
> (or will be, when the structure is defined in its final form) a _message_,
> not a _state_.  It contains (will contain) things other than the power
> state setting, such as the "flags" field.  Why would a device want to
> store pm_message_t.flags as part of its current state?

Because device may enter different hw states for different flags?

									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

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