>> I forgot to mention to disable interrupts after the SUSPEND_NOTIFY call.
>> The idea is to allocate all memory in the first pass, disable interrupts,
>> then save state. Would that work? Or, should some of the state saving take
>> place with interrupts enabled?
>
>That looks ugly, because you'd need to add DONT_SUSPEND_NOTIFY, called
>when SUSPEND_NOTIFY fails.
> Pavel
No, interrupts have to be shut down between SUSPEND_SAVE_STATE and
SUSPEND_POWER_DOWN, I beleive.
SUSPEND_SAVE_STATE must run with interrupts enabled, as it's supposed
to both block new incoming IOs and wait for pending ones to complete (*).
It would be sub-efficient to force drivers to implement polled IOs for
this case.
SUSPEND_POWER_DOWN itself should perfectly be able to run with interrupts
disabled, I beleive, as must of the actual suspend sequence can be done
in SUSPEND_SAVE_STATE on most chips.
There is no problem with failure there. Just call RESUME_POWER_ON if
SUSPEND_POWER_DOWN failed (or later), then RESUME_RESTORE_STATE in
all cases. The driver knows from which state it comes from anyway,
and we don't have, I beleive, that strick VM need of separating
suspend from free's. Well... let's think more about it... we might
actually need to allocate memory in RESUME_RESTORE_STATE to create
new requests or whatever the driver need... but we can also do that
earlier, inside SUSPEND_NOTIFY (or just use whatever memory we
pre-allocated to save state). So it might make sense to have the
resume process be an exact mirror of the wakeup one, or not, maybe
just a matter of taste.
In most cases, keep in mind that most drivers won't need to implement
all of these.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 21:00:36 EST