On Sunday 28 November 2004 1:41 pm, Benjamin Herrenschmidt wrote:
>
> Didn't we discuss already the fact that this mix of selective & system
> suspend was totally unacceptable and should be split in different
> calls ?
Not that I recall. In fact I've said repeatedly that there's
no point to a PM "framework" that makes selective suspend too
difficult ... the hardware handles it, and Linux shouldn't
cripple its PM software by refusing to use it. The whole point
is power saving, after all.
> We _MUST_ provide different selectors to suspend() if we ever
> want to really support selective suspend (the current stuff or writing a
> random number to /sys/*/power/state is crap).
>
> In which case, a device which is whatever "selective" (I call it local)
> suspend state would still get a suspend() request for a system
> transition and so can keep track of it.
Seems to me there are two cases here for "selective" suspend.
One is the /sys/devices/*/power/state crap, for which I think
the consensus is that it's got to change(*). That's basically
equivalent to calling driver suspend() and resume() directly;
the "DPM" calls are effectively unusable, and not just because
they're not even exported outside of drivers/base/power.
The other case is driver-internal, where I think there's also
some consensus that nobody else in the system should care.
If the driver can save power, let it; but it should still be
responding to the appropriate level of external requests.
Including not-at-all, if frozen by any suspend() call.
> > It doesn't make sense for the driver to resume the
> > Ethernet interface when the whole system is about to go to sleep. On the
> > other hand, since the request has already been delivered, if the driver
> > ignores it then it will be lost forever.
>
> Again, in most of the cases I've seen, the request isn't something that
> goes up to the driver... But it seems USB is different in this case.
I'm not sure it is. Devices issue resume signaling, which is
summarized in section 7.1.7.7 of the USB 2.0 spec. That's
reported to drivers using normal mechanisms: the hub status
interrupt transfer, a root hub IRQ, or for PCI root hubs in
a low power state possibly PME#.
If the hub is issuing SOFs (or their low speed equivalent),
the device will no longer be in suspend state, it can be
drawing up to 1/2 Amp. I'm not sure what happens if the
root hub tries to ignore such events while the system is
trying to sleep; PCI systems might not act like others.
But I don't think the resume events will be lost.
> Anyway, I suppose that if you press a key on your USB keyboard just
> after it got suspended and before the machine is actually suspended,
> then it won't be seen as a waekup request for the machine... There is
> simply _nothing_ you can do about that and trying to do something would
> render the stuff even more complicated. Besides, once you had your
> suspend request, you can't talk to your USB device anymore anyway.
I think it depends on whether the root hub latches the resume
request. Not latching such requests seems pretty nonsensical.
Maybe the solution is to just let the hardware do what it wants,
and just expect the software to cope. Are there other options?
- Dave
(*) Evil things about that: semantics of the numbers are at best
fundamentally confused.
Good things about that: it provides a way to unit-test driver
suspend transitions without requiring any error-prone system
sleep state transitions!
