diff options
-rw-r--r-- | Documentation/power/devices.txt | 90 |
1 files changed, 0 insertions, 90 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index f987afe43e28..fba1e05c47c7 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
@@ -135,96 +135,6 @@ HW. | |||
135 | 135 | ||
136 | FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from | 136 | FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from |
137 | scratch. That probably means stop accepting upstream requests, the | 137 | scratch. That probably means stop accepting upstream requests, the |
138 | actual policy of what to do with them beeing specific to a given | ||
139 | driver. It's acceptable for a network driver to just drop packets | ||
140 | while a block driver is expected to block the queue so no request is | ||
141 | lost. (Use IDE as an example on how to do that). FREEZE requires no | ||
142 | power state change, and it's expected for drivers to be able to | ||
143 | quickly transition back to operating state. | ||
144 | |||
145 | SUSPEND -- like FREEZE, but also put hardware into low-power state. If | ||
146 | there's need to distinguish several levels of sleep, additional flag | ||
147 | is probably best way to do that. | ||
148 | |||
149 | Transitions are only from a resumed state to a suspended state, never | ||
150 | between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen, | ||
151 | FREEZE -> SUSPEND or SUSPEND -> FREEZE can not). | ||
152 | |||
153 | All events are: | ||
154 | |||
155 | [NOTE NOTE NOTE: If you are driver author, you should not care; you | ||
156 | should only look at event, and ignore flags.] | ||
157 | |||
158 | #Prepare for suspend -- userland is still running but we are going to | ||
159 | #enter suspend state. This gives drivers chance to load firmware from | ||
160 | #disk and store it in memory, or do other activities taht require | ||
161 | #operating userland, ability to kmalloc GFP_KERNEL, etc... All of these | ||
162 | #are forbiden once the suspend dance is started.. event = ON, flags = | ||
163 | #PREPARE_TO_SUSPEND | ||
164 | |||
165 | Apm standby -- prepare for APM event. Quiesce devices to make life | ||
166 | easier for APM BIOS. event = FREEZE, flags = APM_STANDBY | ||
167 | |||
168 | Apm suspend -- same as APM_STANDBY, but it we should probably avoid | ||
169 | spinning down disks. event = FREEZE, flags = APM_SUSPEND | ||
170 | |||
171 | System halt, reboot -- quiesce devices to make life easier for BIOS. event | ||
172 | = FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT | ||
173 | |||
174 | System shutdown -- at least disks need to be spun down, or data may be | ||
175 | lost. Quiesce devices, just to make life easier for BIOS. event = | ||
176 | FREEZE, flags = SYSTEM_SHUTDOWN | ||
177 | |||
178 | Kexec -- turn off DMAs and put hardware into some state where new | ||
179 | kernel can take over. event = FREEZE, flags = KEXEC | ||
180 | |||
181 | Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake | ||
182 | may need to be enabled on some devices. This actually has at least 3 | ||
183 | subtypes, system can reboot, enter S4 and enter S5 at the end of | ||
184 | swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT, | ||
185 | SYSTEM_SHUTDOWN, SYSTEM_S4 | ||
186 | |||
187 | Suspend to ram -- put devices into low power state. event = SUSPEND, | ||
188 | flags = SUSPEND_TO_RAM | ||
189 | |||
190 | Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put | ||
191 | devices into low power mode, but you must be able to reinitialize | ||
192 | device from scratch in resume method. This has two flavors, its done | ||
193 | once on suspending kernel, once on resuming kernel. event = FREEZE, | ||
194 | flags = DURING_SUSPEND or DURING_RESUME | ||
195 | |||
196 | Device detach requested from /sys -- deinitialize device; proably same as | ||
197 | SYSTEM_SHUTDOWN, I do not understand this one too much. probably event | ||
198 | = FREEZE, flags = DEV_DETACH. | ||
199 | |||
200 | #These are not really events sent: | ||
201 | # | ||
202 | #System fully on -- device is working normally; this is probably never | ||
203 | #passed to suspend() method... event = ON, flags = 0 | ||
204 | # | ||
205 | #Ready after resume -- userland is now running, again. Time to free any | ||
206 | #memory you ate during prepare to suspend... event = ON, flags = | ||
207 | #READY_AFTER_RESUME | ||
208 | # | ||
209 | |||
210 | |||
211 | pm_message_t meaning | ||
212 | |||
213 | pm_message_t has two fields. event ("major"), and flags. If driver | ||
214 | does not know event code, it aborts the request, returning error. Some | ||
215 | drivers may need to deal with special cases based on the actual type | ||
216 | of suspend operation being done at the system level. This is why | ||
217 | there are flags. | ||
218 | |||
219 | Event codes are: | ||
220 | |||
221 | ON -- no need to do anything except special cases like broken | ||
222 | HW. | ||
223 | |||
224 | # NOTIFICATION -- pretty much same as ON? | ||
225 | |||
226 | FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from | ||
227 | scratch. That probably means stop accepting upstream requests, the | ||
228 | actual policy of what to do with them being specific to a given | 138 | actual policy of what to do with them being specific to a given |
229 | driver. It's acceptable for a network driver to just drop packets | 139 | driver. It's acceptable for a network driver to just drop packets |
230 | while a block driver is expected to block the queue so no request is | 140 | while a block driver is expected to block the queue so no request is |