> No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
> may also be in response to a 30 minute timeout expiring. If I get a WoL
> packet in the 0.5 of a second between userspace deciding to suspend and
> actually doing so, the system shouldn't suspend.
I don't think that argument holds water in the form you have it
What about 5 nanoseconds before you suspend. Now you can't do that (laws
of physics and stuff).
So your position would seem to be "we have a race but can debate how big
is permissible"
The usual model is
"At no point should we be in a position when entering a suspend style
deep sleep where we neither abort the suspend, nor commit to a
suspend/resume sequence if the events we care about occur"
and that is why the hardware model is
Set wake flags
Check if idle
If idle
Suspend
else
Clear wake flags
Unwind
and the wake flags guarantee that an event at any point after the wake
flags are set until they are cleared will cause a suspend to be resumed,
possibly immediately after the suspend.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
