Re: Nested suspends; messages vs. states

Pavel Machek
2005-03-22T11:08:02Z

[-- 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!