Pavel:
I gather that you're more interested in system-wide suspend and resume,
and not so much in selective suspend/resume. But the two features
interact and can't be entirely separated. At the very minimum, system
suspend has to be able to deal with devices that are already in a
low-power mode because they were selectively suspended.
On Fri, 24 Sep 2004, Pavel Machek wrote:
> > There's no check for suspending a device with fully-powered
> > children, or conversely, resuming a child while its parent is
> > still suspended.
>
> This only happens in per-device suspend, right?
Not so, or at least, not quite. For example, in
drivers/base/power/suspend.c, suspend_device() won't do anything if the
device isn't at full power to begin with. So if the parent is at full
power but the child is in low power when a system-wide suspend occurs, the
child will be left at low power while the parent is turned off.
> > Unnecessary calls (to suspend to a level lower than the device's
> > current power state) aren't always avoided.
>
> This only happens in per-device suspend, right?
Yes, because system suspend doesn't do anything to devices that aren't at
full power. Of course, that means it doesn't tell them to turn off.
> > The locking is insufficient (no protection against calling a
> > driver's suspend() during probe() for example) and prone to
> > deadlock.
>
> Again, I guess patch will be welcome.
To fix this properly requires changes in the heart of the driver model.
It can't be patched up simply by altering a few routines in the PM core.
> > The meaning of the power states is unclear, particularly for
> > buses that don't support all the PCI states.
>
> Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> suspended. What should be done is convert that interface to enums or
> some kind of structure, probably solving per-device suspend at the
> same time. I'd prefer drivers to ignore that parameter for now.
Although the picture isn't really clear, I gather the device states one
really needs to consider could be described something like this (using an
ad hoc notation):
S0: Full power, S0': Full power,
IRQ & DMA enabled IRQ & DMA disabled
S1: Low power, S1': Low power,
IRQ enabled for wakeup requests, IRQ & DMA disabled
DMA disabled
S2: Power off, S2': Power off,
IRQ & DMA disabled, IRQ & DMA disabled
PME# enabled PME# disabled
S0' is a device's initial unconfigured state. S0 is the normal
operational state. Selective suspend would use state S1. Suspend-to-RAM
and suspend-to-disk would use S2 for devices that support PME#, otherwise
S2'. Perhaps there's no need to distinguish between the two; I don't know
how closely people want to tie remote wakeup enable/disable with power
states, although they are related concepts.
Not all devices need to distinguish among all the states. For example,
S0, S0', and S1 would all correspond to PCI's D0 state. The differences
are that in S0' the device's interrupt-enable registers are turned off
(and likewise for DMA), and in S1 the device's internal clocks and other
high-power components are turned off. S1' would corrrespond to D3hot, and
S2 and S2' would correspond to D3cold.
The distinction between the unprimed and the primed states is needed when
preparing or restoring a memory image for suspend-to-disk. Devices
shouldn't be allowed to generate interrupt requests at those times.
Perhaps some devices will want additional intermediate low-power states
(such as D1 and D2). For the moment it's easier not to worry about them.
As far as system suspend is concerned, only the full-power and power-off
states matter. But for selective suspend, obviously the low-power states
are very important.
> > dpm_runtime_suspend doesn't allow transitions from one reduced-power
> > state to a more-reduced-power state, even when the device is
> > capable of doing it. Instead the device is forced to return to
> > full power first. Oddly enough, device_suspend() does allow such
> > transitions.
>
> That's part of half-done per-device infrastructure, right?
Yes.
> > The transitions to and from the device-idle states needed for
> > suspend-to-disk aren't well defined.
>
> I'll answer questions if you promise to submit documentation patch
> ;-)).
I'll be happy to work on documentation once it's clear exactly how
everything (including selective suspend) is supposed to work! :-)
> device-idle states needs to ensure:
>
> * no DMA running
> * even if kernel state is lost, you are able to bring device back to
> normal state... Or "when one kernel is replaced with another one, all
> variables are lost, you still can resume that device". Easily
> accomplished by having just one hardware state you put it into.
I'm not so sure about that last bit. If a driver was loaded manually or
by a hotplug program, then it won't be present in the bootup kernel when
the memory image is restored. Consequently its device won't be put into
the desired hardware state -- it will be in the virgin unconfigured
state, S0'. Of course, a driver can tell at compile time whether this is
the case by testing "#ifdef MODULE".
Also, it seems like it might be important to inform drivers, when resuming
from the "idle for memory image" state, whether the system has gone down
and come back up in the meantime. In other words, are we resuming for
purposes of writing the memory image to swap as part of the
suspend-to-disk, or are we now in the resume-from-disk stage? Drivers
might want to know.
> I'll gladly help with everything thats used by suspend-to-{RAM,disk},
> which basically means everything but per-device power
> managment. Per-device power managment basically needs to be designed,
> first.
Is Patrick the best person to ask about doing that design?
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
