Alan Stern writes:
> > Most drivers suspended their hardware in the second call. If they are
> > in the middle of a conversation with their device that *has* to be
> > completed, they can do that by polling.
>
> Ugh. That will cause problems when you try to integrate runtime
> suspend. In fact this whole approach is unsuitable for runtime PM and
> it obscures the similarities between runtime PM and STR.
Yes there are similarities, but it would be a big mistake to say that
a requirement for STR is that all drivers do runtime PM.
If a driver does runtime PM, that's great, and it is useful for
implementing STR. However, there are a class of devices for which
runtime PM is not possible or not useful, but which can suspend/resume
just fine as part of suspending/resuming the complete system, and for
which all that is needed is some small amount of simple hardware
poking just before the system as a whole is put into suspend. For
those a late-suspend call with interrupts off is the simplest and best
way to go.
Think of a serial port on a motherboard for instance, where the only
power control is the overall power control for the system. All that
is needed is to poll for the transmitter being empty (with timeout, of
course) in the late-suspend call (and possibly also turn off output
drivers, perhaps), and to reinitialize some registers in an
early-resume call.
The main attraction of the late-suspend call is that it really does,
reliably, guarantee that the driver's I/O request methods won't get
called between the late-suspend call and the early-resume call.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
