On Mon, 2004-11-01 at 10:34 -0700, David Brownell wrote:
> Yes, and that's something that the PM core should be able
> to help with. As you say: it needs to apply generally.
>
> In fact, I think that's exactly the functionality needed
> during STD so that it can wake up just the swap device
> that'll be used to write the memory snapshot ...
Nope. Let's keep the frozen queue semantics for system sleep
pleaes, I do not trust _at_all_ "hoping" that we won't get
any requests after the power management dance, so auto-wakeup
isn't a solution I would consider realistic here.
However, having "local" PM with auto-resume be a PM state,
hrm... why not. However, before we go that way, what is the
actual impact of this ?
Do we intend to keep a state variable at all at the device model
layer ? The current state variable is confusing and about to be
killed if I understand our previous discussions.
If we keep one, what does it contain ? A bus specific state
informations or the mirror of the last pm_request sent to the
driver ? (that is idle, suspended, frozen, ...)
Note that there is also the feature I've been talking about in
the beginning of beeing able to trigger local PM of devices (with
auto-resume) from userland, possibly sysfs. One way to do it is
have the request to get to such a state go via suspend() too with
a different pm message.
As we saw earlier, the different between those states and the system
states is essentially the "freeze" semantics. The system states imply
a power level (or none) plus the freeze semantic. The "local" states
imply a power level without the freeze semantic (or auto-resume, no
queue freezing, no packet dropping, ...)
We could have the PM message be broken further then, and have "freeze"
be one of the flags. Which means that the main messages wouldn't be
freeze,idle,suspend, but more like nop,idle,suspend, each of them
possibly beeing added the "freeze" flag...
If that makes any sense ...
the drivers would then typically do
if (msg->flags & PM_FLAG_FREEZE) {
me->frozen = 1;
do_freeze_queue();
}
switch(msg->state) {
case PM_STATE_IDLE:
do_set_device_doze();
break;
case PM_STATE_SUSPEND:
do_set_device_sleep();
break;
}
And in whatever upstream request processing function:
if (me->frozen)
don't process
if (me->idle || me->suspended)
wake_device();
Though for block devices, it should be a bit more complicated, in the
form of a special request going down the queue, like I do on IDE
already.
This is just an idea...
Ben.
