Re: Nested suspends; messages vs. states

Benjamin Herrenschmidt
2005-03-23T23:49:49Z

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

On Tue, 2005-03-22 at 12:24 -0500, Alan Stern wrote:
> On Tue, 22 Mar 2005, Pavel Machek wrote:
>
> > And do we really want user writing D2 to /sys file?
>
> Yes, absolutely. And we want the power/state file to contain "D2" when
> a PCI device is in that state.

No. "D2" isn't a leaf device state imho. It's a PCI state tho, but I
would have the driver expose some more meaninful names, like "standby",
"suspended", ... If the entire PCI busses goes unclocked, we could have
the PCI _bus_ expose D2. If the PCI bus is about to lose power, we could
haev the PCI _bus_ expose D3. But the leaf driver should be more
meaninful, that is the power states should be relative to the function
of the driver.

> > > 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?
>
> But once the device is in a particular state, the reason why it entered
> that state doesn't matter any more. Certainly it shouldn't be _part_ of
> the state.

It does matter for one thing: Wether the device can get out of the state
by itself (upon reception of a request for example) or should it block
all activities until resume().

> Consider this: Device states are bus- or device-specific structures, as
> discussed before. But the PM core can export a set of minimal generic
> state structures for use by drivers that don't need anything more
> complicated than On, Frozen, or Suspended. How does that sound?

Yes. That is also a compatibility path from current scheme. But I
wouldn't make these states accessibles to userland ...

Ben.