|
|
@@ -118,96 +118,6 @@ will fail.
|
|
|
There is currently no way to know what states a device or driver
|
|
|
supports a priori. This will change in the future.
|
|
|
|
|
|
-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:
|
|
|
-
|
|
|
-ON -- no need to do anything except special cases like broken
|
|
|
-HW.
|
|
|
-
|
|
|
-# NOTIFICATION -- pretty much same as ON?
|
|
|
-
|
|
|
-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.
|
|
|
-
|
|
|
-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.
|
|
|
-
|
|
|
-Transitions are only from a resumed state to a suspended state, never
|
|
|
-between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen,
|
|
|
-FREEZE -> SUSPEND or SUSPEND -> FREEZE can not).
|
|
|
-
|
|
|
-All events are:
|
|
|
-
|
|
|
-[NOTE NOTE NOTE: If you are driver author, you should not care; you
|
|
|
-should only look at event, and ignore flags.]
|
|
|
-
|
|
|
-#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, 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.. event = ON, flags =
|
|
|
-#PREPARE_TO_SUSPEND
|
|
|
-
|
|
|
-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.
|
|
|
-
|
|
|
-#These are not really events sent:
|
|
|
-#
|
|
|
-#System fully on -- device is working normally; this is probably never
|
|
|
-#passed to suspend() method... event = ON, flags = 0
|
|
|
-#
|
|
|
-#Ready after resume -- userland is now running, again. Time to free any
|
|
|
-#memory you ate during prepare to suspend... event = ON, flags =
|
|
|
-#READY_AFTER_RESUME
|
|
|
-#
|
|
|
-
|
|
|
-
|
|
|
pm_message_t meaning
|
|
|
|
|
|
pm_message_t has two fields. event ("major"), and flags. If driver
|
David Brownell