On Sun, 26 Sep 2004, Alan Stern wrote:
> In fact there are three distinct but closely related concepts involved,
> and they all need to be handled simultaneously in some reasonably way.
> They are: power level, IRQ/DMA enabled (or activity level if you prefer),
> and wakeup enabled. These things are almost independent (except that
> wakeup is meaningless in the full-power state). But they are tied
> together in bizarre ways, such as not being able to change the wakeup
> enable setting if the device isn't at full power. Or the fact that at
> some points in the device tree, wakeup requests are transformed into
> interrupt requests.
Here's a slightly more organized way of putting things. We have:
suspend (equivalently, power) levels: On, Low, or Off
activity levels: IRQ/DMA enabled (High) or disabled (Low)
wakeup levels: Wakeup requests enabled or disabled (this refers
to the device's ability to generate wakeup requests or propagate
such requests from its children upward -- it says nothing about
whether ancestor devices will pay any attention to these requests)
Before a device is configured its power level is unknown. However its
activity level must be Low and wakeups must be disabled.
Many drivers and devices might want to subdivide the On or Low power
levels internally. That's fine, but I can't think of any good way for
them to communicate those subdivisions through the PM core.
It should be safe to assume that a power-Off device is always in the
activity-Low level. Some devices may not support activity-High in the
power-Low state. Some devices may not support wakeup in the activity-Low
state or the power-Low state. Some devices may support wakeup even in the
power-Off state.
There is a number of restrictions on possible transitions:
The PM core will never try to decrease the suspend level from
Off to Low.
The PM core will never try to put a child into a lower suspend
level than its parent (or the other way around, put a parent into
a higher suspend level than its child).
Ditto for activity levels. Furthermore, the PM core will never
try to make a child active when the parent is not at power-On.
It's legal for a parent to have wakeup disabled while a child
has wakeup enabled. In this situation wakeup requests from the
child may or may not be received by the system.
A device might not be able to move from power-Low to power-Off
if its parent is not at power-On. Likewise, a device may not
be able to change wakeup levels if it is not at power-On, or
merely if its parent is not at power-On. It's also possible that
even though the device may be unable to make this transition, if
its parent is changed then the device will automatically follow
along. Such cases are indicated by returning appropriate error
codes to the various PM callbacks: codes indicate "Device must
be power-On", "Parent must be power-On", or "Will follow parent".
Does this sound like a suitable framework for describing device states?
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
