On Wed, 2004-11-03 at 01:39 +0100, Pavel Machek wrote:
> Ok, I see that. Reboot/shutdown probably wants freeze then, because
> that gives us better default behaviour. ... I'd still like to keep
> event=ON for things like prepare_for_supend.
Why ? Why not use specific events for these and keep the flags for
telling us what king of suspend (ram/disk/...) will happen ?
> Pavel
>
> PS: Here is updated version...
>
>
> pm_message_t meaning
>
> pm_message_t has two fields. event ("major"), and flags. If driver
> does not know event code, it aborts the request, returning error. Some
> drivers may need to deal with special cases based on the actual type
> of suspend operation being done at the system level. This is why
> there are flags.
>
> Event codes are:
We absolutely need to do something about resume too btw... We need to
know on resume at least if we are unfreezing after snapshot, or
unfreezing after reboot/S4
> ON -- no need to do anything except special cases like broken
> HW.
>
> FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
> scratch. That probably means stop accepting upstream requests, the
> actual policy of what to do with them beeing specific to a given
> driver. It's acceptable for a network driver to just drop packets
> while a block driver is expected to block the queue so no request is
> lost. (Use IDE as an example on how to do that). FREEZE requires no
> power state change, and it's expected for drivers to be able to
> quickly transition back to operating state.
Wether resume has to re-init HW or not should be provided by some
additional infos to resume, which is why I want to turn it into a
pm_message_t too. Also, POST_RESUME should be sent to resume(), not to
suspend().
> SUSPEND -- like FREEZE, but also put hardware into low-power state. If
> there's need to distinguish several levels of sleep, additional flag
> is probably best way to do that.
No, again, flags are to be really exceptional imho... which is why I
want to keep the definition of STANDBY around
> All events are:
>
> Prepare for suspend -- userland is still running but we are going to
> enter suspend state. This gives drivers chance to load firmware from
> disk and store it in memory. event = ON, flags = PREPARE_TO_SUSPEND
Or do other activities taht require operating userland, ability to
kmalloc GFP_KERNEL, etc... All of these are forbiden once the suspend
dance is started.
> Apm standby -- prepare for APM event. Quiesce devices to make life
> easier for APM BIOS. event = FREEZE, flags = APM_STANDBY
>
> Apm suspend -- same as APM_STANDBY, but it we should probably avoid
> spinning down disks. event = FREEZE, flags = APM_SUSPEND
>
> System halt, reboot -- quiesce devices to make life easier for BIOS. event
> = FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT
>
> System shutdown -- at least disks need to be spun down, or data may be
> lost. Quiesce devices, just to make life easier for BIOS. event =
> FREEZE, flags = SYSTEM_SHUTDOWN
>
> Kexec -- turn off DMAs and put hardware into some state where new
> kernel can take over. event = FREEZE, flags = KEXEC
>
> Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake
> may need to be enabled on some devices. This actually has at least 3
> subtypes, system can reboot, enter S4 and enter S5 at the end of
> swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT,
> SYSTEM_SHUTDOWN, SYSTEM_S4
>
> Suspend to ram -- put devices into low power state. event = SUSPEND,
> flags = SUSPEND_TO_RAM
>
> Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put
> devices into low power mode, but you must be able to reinitialize
> device from scratch in resume method. This has two flavors, its done
> once on suspending kernel, once on resuming kernel. event = FREEZE,
> flags = DURING_SUSPEND or DURING_RESUME
>
> Device detach requested from /sys -- deinitialize device; proably same as
> SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
> = FREEZE, flags = DEV_DETACH.
>
> System fully on -- device is working normally; this is probably never
> passed to suspend() method... event = ON, flags = 0
This is a resume() call.
