Commit | Line | Data |
---|---|---|
4fc08400 DB |
1 | Most of the code in Linux is device drivers, so most of the Linux power |
2 | management code is also driver-specific. Most drivers will do very little; | |
3 | others, especially for platforms with small batteries (like cell phones), | |
4 | will do a lot. | |
5 | ||
6 | This writeup gives an overview of how drivers interact with system-wide | |
7 | power management goals, emphasizing the models and interfaces that are | |
8 | shared by everything that hooks up to the driver model core. Read it as | |
9 | background for the domain-specific work you'd do with any specific driver. | |
10 | ||
11 | ||
12 | Two Models for Device Power Management | |
13 | ====================================== | |
14 | Drivers will use one or both of these models to put devices into low-power | |
15 | states: | |
16 | ||
17 | System Sleep model: | |
18 | Drivers can enter low power states as part of entering system-wide | |
19 | low-power states like "suspend-to-ram", or (mostly for systems with | |
20 | disks) "hibernate" (suspend-to-disk). | |
21 | ||
22 | This is something that device, bus, and class drivers collaborate on | |
23 | by implementing various role-specific suspend and resume methods to | |
24 | cleanly power down hardware and software subsystems, then reactivate | |
25 | them without loss of data. | |
26 | ||
27 | Some drivers can manage hardware wakeup events, which make the system | |
28 | leave that low-power state. This feature may be disabled using the | |
29 | relevant /sys/devices/.../power/wakeup file; enabling it may cost some | |
30 | power usage, but let the whole system enter low power states more often. | |
31 | ||
32 | Runtime Power Management model: | |
33 | Drivers may also enter low power states while the system is running, | |
34 | independently of other power management activity. Upstream drivers | |
35 | will normally not know (or care) if the device is in some low power | |
36 | state when issuing requests; the driver will auto-resume anything | |
37 | that's needed when it gets a request. | |
38 | ||
39 | This doesn't have, or need much infrastructure; it's just something you | |
40 | should do when writing your drivers. For example, clk_disable() unused | |
41 | clocks as part of minimizing power drain for currently-unused hardware. | |
42 | Of course, sometimes clusters of drivers will collaborate with each | |
43 | other, which could involve task-specific power management. | |
44 | ||
45 | There's not a lot to be said about those low power states except that they | |
46 | are very system-specific, and often device-specific. Also, that if enough | |
47 | drivers put themselves into low power states (at "runtime"), the effect may be | |
48 | the same as entering some system-wide low-power state (system sleep) ... and | |
49 | that synergies exist, so that several drivers using runtime pm might put the | |
50 | system into a state where even deeper power saving options are available. | |
51 | ||
52 | Most suspended devices will have quiesced all I/O: no more DMA or irqs, no | |
53 | more data read or written, and requests from upstream drivers are no longer | |
54 | accepted. A given bus or platform may have different requirements though. | |
55 | ||
56 | Examples of hardware wakeup events include an alarm from a real time clock, | |
57 | network wake-on-LAN packets, keyboard or mouse activity, and media insertion | |
58 | or removal (for PCMCIA, MMC/SD, USB, and so on). | |
59 | ||
60 | ||
61 | Interfaces for Entering System Sleep States | |
62 | =========================================== | |
63 | Most of the programming interfaces a device driver needs to know about | |
64 | relate to that first model: entering a system-wide low power state, | |
65 | rather than just minimizing power consumption by one device. | |
66 | ||
67 | ||
68 | Bus Driver Methods | |
69 | ------------------ | |
70 | The core methods to suspend and resume devices reside in struct bus_type. | |
71 | These are mostly of interest to people writing infrastructure for busses | |
72 | like PCI or USB, or because they define the primitives that device drivers | |
73 | may need to apply in domain-specific ways to their devices: | |
1da177e4 | 74 | |
4fc08400 DB |
75 | struct bus_type { |
76 | ... | |
77 | int (*suspend)(struct device *dev, pm_message_t state); | |
78 | int (*suspend_late)(struct device *dev, pm_message_t state); | |
1da177e4 | 79 | |
4fc08400 DB |
80 | int (*resume_early)(struct device *dev); |
81 | int (*resume)(struct device *dev); | |
82 | }; | |
1da177e4 | 83 | |
4fc08400 DB |
84 | Bus drivers implement those methods as appropriate for the hardware and |
85 | the drivers using it; PCI works differently from USB, and so on. Not many | |
86 | people write bus drivers; most driver code is a "device driver" that | |
87 | builds on top of bus-specific framework code. | |
88 | ||
89 | For more information on these driver calls, see the description later; | |
90 | they are called in phases for every device, respecting the parent-child | |
91 | sequencing in the driver model tree. Note that as this is being written, | |
92 | only the suspend() and resume() are widely available; not many bus drivers | |
93 | leverage all of those phases, or pass them down to lower driver levels. | |
94 | ||
95 | ||
96 | /sys/devices/.../power/wakeup files | |
97 | ----------------------------------- | |
98 | All devices in the driver model have two flags to control handling of | |
99 | wakeup events, which are hardware signals that can force the device and/or | |
100 | system out of a low power state. These are initialized by bus or device | |
101 | driver code using device_init_wakeup(dev,can_wakeup). | |
102 | ||
103 | The "can_wakeup" flag just records whether the device (and its driver) can | |
104 | physically support wakeup events. When that flag is clear, the sysfs | |
105 | "wakeup" file is empty, and device_may_wakeup() returns false. | |
106 | ||
107 | For devices that can issue wakeup events, a separate flag controls whether | |
108 | that device should try to use its wakeup mechanism. The initial value of | |
109 | device_may_wakeup() will be true, so that the device's "wakeup" file holds | |
110 | the value "enabled". Userspace can change that to "disabled" so that | |
111 | device_may_wakeup() returns false; or change it back to "enabled" (so that | |
112 | it returns true again). | |
113 | ||
114 | ||
115 | EXAMPLE: PCI Device Driver Methods | |
116 | ----------------------------------- | |
117 | PCI framework software calls these methods when the PCI device driver bound | |
118 | to a device device has provided them: | |
119 | ||
120 | struct pci_driver { | |
121 | ... | |
122 | int (*suspend)(struct pci_device *pdev, pm_message_t state); | |
123 | int (*suspend_late)(struct pci_device *pdev, pm_message_t state); | |
124 | ||
125 | int (*resume_early)(struct pci_device *pdev); | |
126 | int (*resume)(struct pci_device *pdev); | |
127 | }; | |
1da177e4 | 128 | |
4fc08400 DB |
129 | Drivers will implement those methods, and call PCI-specific procedures |
130 | like pci_set_power_state(), pci_enable_wake(), pci_save_state(), and | |
131 | pci_restore_state() to manage PCI-specific mechanisms. (PCI config space | |
132 | could be saved during driver probe, if it weren't for the fact that some | |
133 | systems rely on userspace tweaking using setpci.) Devices are suspended | |
134 | before their bridges enter low power states, and likewise bridges resume | |
135 | before their devices. | |
136 | ||
137 | ||
138 | Upper Layers of Driver Stacks | |
139 | ----------------------------- | |
140 | Device drivers generally have at least two interfaces, and the methods | |
141 | sketched above are the ones which apply to the lower level (nearer PCI, USB, | |
142 | or other bus hardware). The network and block layers are examples of upper | |
143 | level interfaces, as is a character device talking to userspace. | |
144 | ||
145 | Power management requests normally need to flow through those upper levels, | |
146 | which often use domain-oriented requests like "blank that screen". In | |
147 | some cases those upper levels will have power management intelligence that | |
148 | relates to end-user activity, or other devices that work in cooperation. | |
149 | ||
150 | When those interfaces are structured using class interfaces, there is a | |
151 | standard way to have the upper layer stop issuing requests to a given | |
152 | class device (and restart later): | |
153 | ||
154 | struct class { | |
155 | ... | |
156 | int (*suspend)(struct device *dev, pm_message_t state); | |
157 | int (*resume)(struct device *dev); | |
158 | }; | |
1da177e4 | 159 | |
4fc08400 DB |
160 | Those calls are issued in specific phases of the process by which the |
161 | system enters a low power "suspend" state, or resumes from it. | |
162 | ||
163 | ||
164 | Calling Drivers to Enter System Sleep States | |
165 | ============================================ | |
166 | When the system enters a low power state, each device's driver is asked | |
167 | to suspend the device by putting it into state compatible with the target | |
168 | system state. That's usually some version of "off", but the details are | |
169 | system-specific. Also, wakeup-enabled devices will usually stay partly | |
170 | functional in order to wake the system. | |
171 | ||
172 | When the system leaves that low power state, the device's driver is asked | |
173 | to resume it. The suspend and resume operations always go together, and | |
174 | both are multi-phase operations. | |
175 | ||
176 | For simple drivers, suspend might quiesce the device using the class code | |
177 | and then turn its hardware as "off" as possible with late_suspend. The | |
178 | matching resume calls would then completely reinitialize the hardware | |
179 | before reactivating its class I/O queues. | |
180 | ||
181 | More power-aware drivers drivers will use more than one device low power | |
182 | state, either at runtime or during system sleep states, and might trigger | |
183 | system wakeup events. | |
184 | ||
185 | ||
186 | Call Sequence Guarantees | |
187 | ------------------------ | |
188 | To ensure that bridges and similar links needed to talk to a device are | |
189 | available when the device is suspended or resumed, the device tree is | |
190 | walked in a bottom-up order to suspend devices. A top-down order is | |
191 | used to resume those devices. | |
192 | ||
193 | The ordering of the device tree is defined by the order in which devices | |
194 | get registered: a child can never be registered, probed or resumed before | |
195 | its parent; and can't be removed or suspended after that parent. | |
196 | ||
197 | The policy is that the device tree should match hardware bus topology. | |
198 | (Or at least the control bus, for devices which use multiple busses.) | |
58aca232 RW |
199 | In particular, this means that a device registration may fail if the parent of |
200 | the device is suspending (ie. has been chosen by the PM core as the next | |
201 | device to suspend) or has already suspended, as well as after all of the other | |
202 | devices have been suspended. Device drivers must be prepared to cope with such | |
203 | situations. | |
4fc08400 DB |
204 | |
205 | ||
206 | Suspending Devices | |
207 | ------------------ | |
208 | Suspending a given device is done in several phases. Suspending the | |
209 | system always includes every phase, executing calls for every device | |
210 | before the next phase begins. Not all busses or classes support all | |
211 | these callbacks; and not all drivers use all the callbacks. | |
212 | ||
213 | The phases are seen by driver notifications issued in this order: | |
214 | ||
215 | 1 class.suspend(dev, message) is called after tasks are frozen, for | |
216 | devices associated with a class that has such a method. This | |
217 | method may sleep. | |
218 | ||
219 | Since I/O activity usually comes from such higher layers, this is | |
220 | a good place to quiesce all drivers of a given type (and keep such | |
221 | code out of those drivers). | |
222 | ||
223 | 2 bus.suspend(dev, message) is called next. This method may sleep, | |
224 | and is often morphed into a device driver call with bus-specific | |
225 | parameters and/or rules. | |
226 | ||
227 | This call should handle parts of device suspend logic that require | |
228 | sleeping. It probably does work to quiesce the device which hasn't | |
229 | been abstracted into class.suspend() or bus.suspend_late(). | |
230 | ||
231 | 3 bus.suspend_late(dev, message) is called with IRQs disabled, and | |
232 | with only one CPU active. Until the bus.resume_early() phase | |
233 | completes (see later), IRQs are not enabled again. This method | |
234 | won't be exposed by all busses; for message based busses like USB, | |
235 | I2C, or SPI, device interactions normally require IRQs. This bus | |
236 | call may be morphed into a driver call with bus-specific parameters. | |
237 | ||
238 | This call might save low level hardware state that might otherwise | |
239 | be lost in the upcoming low power state, and actually put the | |
240 | device into a low power state ... so that in some cases the device | |
241 | may stay partly usable until this late. This "late" call may also | |
242 | help when coping with hardware that behaves badly. | |
243 | ||
244 | The pm_message_t parameter is currently used to refine those semantics | |
245 | (described later). | |
246 | ||
247 | At the end of those phases, drivers should normally have stopped all I/O | |
248 | transactions (DMA, IRQs), saved enough state that they can re-initialize | |
249 | or restore previous state (as needed by the hardware), and placed the | |
250 | device into a low-power state. On many platforms they will also use | |
251 | clk_disable() to gate off one or more clock sources; sometimes they will | |
252 | also switch off power supplies, or reduce voltages. Drivers which have | |
253 | runtime PM support may already have performed some or all of the steps | |
254 | needed to prepare for the upcoming system sleep state. | |
255 | ||
256 | When any driver sees that its device_can_wakeup(dev), it should make sure | |
257 | to use the relevant hardware signals to trigger a system wakeup event. | |
258 | For example, enable_irq_wake() might identify GPIO signals hooked up to | |
259 | a switch or other external hardware, and pci_enable_wake() does something | |
260 | similar for PCI's PME# signal. | |
261 | ||
262 | If a driver (or bus, or class) fails it suspend method, the system won't | |
263 | enter the desired low power state; it will resume all the devices it's | |
264 | suspended so far. | |
265 | ||
266 | Note that drivers may need to perform different actions based on the target | |
267 | system lowpower/sleep state. At this writing, there are only platform | |
268 | specific APIs through which drivers could determine those target states. | |
269 | ||
270 | ||
271 | Device Low Power (suspend) States | |
272 | --------------------------------- | |
273 | Device low-power states aren't very standard. One device might only handle | |
274 | "on" and "off, while another might support a dozen different versions of | |
275 | "on" (how many engines are active?), plus a state that gets back to "on" | |
276 | faster than from a full "off". | |
277 | ||
278 | Some busses define rules about what different suspend states mean. PCI | |
279 | gives one example: after the suspend sequence completes, a non-legacy | |
280 | PCI device may not perform DMA or issue IRQs, and any wakeup events it | |
281 | issues would be issued through the PME# bus signal. Plus, there are | |
282 | several PCI-standard device states, some of which are optional. | |
283 | ||
284 | In contrast, integrated system-on-chip processors often use irqs as the | |
285 | wakeup event sources (so drivers would call enable_irq_wake) and might | |
286 | be able to treat DMA completion as a wakeup event (sometimes DMA can stay | |
287 | active too, it'd only be the CPU and some peripherals that sleep). | |
288 | ||
289 | Some details here may be platform-specific. Systems may have devices that | |
290 | can be fully active in certain sleep states, such as an LCD display that's | |
291 | refreshed using DMA while most of the system is sleeping lightly ... and | |
292 | its frame buffer might even be updated by a DSP or other non-Linux CPU while | |
293 | the Linux control processor stays idle. | |
294 | ||
295 | Moreover, the specific actions taken may depend on the target system state. | |
296 | One target system state might allow a given device to be very operational; | |
297 | another might require a hard shut down with re-initialization on resume. | |
298 | And two different target systems might use the same device in different | |
299 | ways; the aforementioned LCD might be active in one product's "standby", | |
300 | but a different product using the same SOC might work differently. | |
301 | ||
302 | ||
303 | Meaning of pm_message_t.event | |
304 | ----------------------------- | |
305 | Parameters to suspend calls include the device affected and a message of | |
306 | type pm_message_t, which has one field: the event. If driver does not | |
307 | recognize the event code, suspend calls may abort the request and return | |
308 | a negative errno. However, most drivers will be fine if they implement | |
309 | PM_EVENT_SUSPEND semantics for all messages. | |
310 | ||
311 | The event codes are used to refine the goal of suspending the device, and | |
312 | mostly matter when creating or resuming system memory image snapshots, as | |
313 | used with suspend-to-disk: | |
314 | ||
315 | PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power | |
316 | state. When used with system sleep states like "suspend-to-RAM" or | |
317 | "standby", the upcoming resume() call will often be able to rely on | |
3a2d5b70 RW |
318 | state kept in hardware, or issue system wakeup events. |
319 | ||
320 | PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup | |
321 | events as appropriate. It is only used with hibernation | |
322 | (suspend-to-disk) and few devices are able to wake up the system from | |
323 | this state; most are completely powered off. | |
4fc08400 DB |
324 | |
325 | PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into | |
326 | any low power mode. A system snapshot is about to be taken, often | |
327 | followed by a call to the driver's resume() method. Neither wakeup | |
328 | events nor DMA are allowed. | |
329 | ||
330 | PM_EVENT_PRETHAW -- quiesce the driver, knowing that the upcoming resume() | |
331 | will restore a suspend-to-disk snapshot from a different kernel image. | |
332 | Drivers that are smart enough to look at their hardware state during | |
333 | resume() processing need that state to be correct ... a PRETHAW could | |
334 | be used to invalidate that state (by resetting the device), like a | |
335 | shutdown() invocation would before a kexec() or system halt. Other | |
336 | drivers might handle this the same way as PM_EVENT_FREEZE. Neither | |
337 | wakeup events nor DMA are allowed. | |
338 | ||
339 | To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or | |
3a2d5b70 RW |
340 | the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event |
341 | codes are used for hibernation ("Suspend to Disk", STD, ACPI S4). | |
4fc08400 DB |
342 | |
343 | There's also PM_EVENT_ON, a value which never appears as a suspend event | |
344 | but is sometimes used to record the "not suspended" device state. | |
345 | ||
346 | ||
347 | Resuming Devices | |
348 | ---------------- | |
349 | Resuming is done in multiple phases, much like suspending, with all | |
350 | devices processing each phase's calls before the next phase begins. | |
351 | ||
352 | The phases are seen by driver notifications issued in this order: | |
353 | ||
354 | 1 bus.resume_early(dev) is called with IRQs disabled, and with | |
355 | only one CPU active. As with bus.suspend_late(), this method | |
356 | won't be supported on busses that require IRQs in order to | |
357 | interact with devices. | |
358 | ||
359 | This reverses the effects of bus.suspend_late(). | |
360 | ||
361 | 2 bus.resume(dev) is called next. This may be morphed into a device | |
362 | driver call with bus-specific parameters; implementations may sleep. | |
363 | ||
364 | This reverses the effects of bus.suspend(). | |
365 | ||
366 | 3 class.resume(dev) is called for devices associated with a class | |
367 | that has such a method. Implementations may sleep. | |
368 | ||
369 | This reverses the effects of class.suspend(), and would usually | |
370 | reactivate the device's I/O queue. | |
371 | ||
372 | At the end of those phases, drivers should normally be as functional as | |
373 | they were before suspending: I/O can be performed using DMA and IRQs, and | |
374 | the relevant clocks are gated on. The device need not be "fully on"; it | |
375 | might be in a runtime lowpower/suspend state that acts as if it were. | |
376 | ||
377 | However, the details here may again be platform-specific. For example, | |
378 | some systems support multiple "run" states, and the mode in effect at | |
379 | the end of resume() might not be the one which preceded suspension. | |
380 | That means availability of certain clocks or power supplies changed, | |
381 | which could easily affect how a driver works. | |
382 | ||
383 | ||
384 | Drivers need to be able to handle hardware which has been reset since the | |
385 | suspend methods were called, for example by complete reinitialization. | |
386 | This may be the hardest part, and the one most protected by NDA'd documents | |
387 | and chip errata. It's simplest if the hardware state hasn't changed since | |
388 | the suspend() was called, but that can't always be guaranteed. | |
389 | ||
390 | Drivers must also be prepared to notice that the device has been removed | |
391 | while the system was powered off, whenever that's physically possible. | |
392 | PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses | |
393 | where common Linux platforms will see such removal. Details of how drivers | |
394 | will notice and handle such removals are currently bus-specific, and often | |
395 | involve a separate thread. | |
1da177e4 | 396 | |
1da177e4 | 397 | |
4fc08400 DB |
398 | Note that the bus-specific runtime PM wakeup mechanism can exist, and might |
399 | be defined to share some of the same driver code as for system wakeup. For | |
400 | example, a bus-specific device driver's resume() method might be used there, | |
401 | so it wouldn't only be called from bus.resume() during system-wide wakeup. | |
402 | See bus-specific information about how runtime wakeup events are handled. | |
1da177e4 | 403 | |
1da177e4 | 404 | |
4fc08400 DB |
405 | System Devices |
406 | -------------- | |
1da177e4 LT |
407 | System devices follow a slightly different API, which can be found in |
408 | ||
409 | include/linux/sysdev.h | |
410 | drivers/base/sys.c | |
411 | ||
4fc08400 DB |
412 | System devices will only be suspended with interrupts disabled, and after |
413 | all other devices have been suspended. On resume, they will be resumed | |
414 | before any other devices, and also with interrupts disabled. | |
1da177e4 | 415 | |
4fc08400 DB |
416 | That is, IRQs are disabled, the suspend_late() phase begins, then the |
417 | sysdev_driver.suspend() phase, and the system enters a sleep state. Then | |
418 | the sysdev_driver.resume() phase begins, followed by the resume_early() | |
419 | phase, after which IRQs are enabled. | |
1da177e4 | 420 | |
4fc08400 DB |
421 | Code to actually enter and exit the system-wide low power state sometimes |
422 | involves hardware details that are only known to the boot firmware, and | |
423 | may leave a CPU running software (from SRAM or flash memory) that monitors | |
424 | the system and manages its wakeup sequence. | |
1da177e4 | 425 | |
1da177e4 | 426 | |
4fc08400 DB |
427 | Runtime Power Management |
428 | ======================== | |
429 | Many devices are able to dynamically power down while the system is still | |
430 | running. This feature is useful for devices that are not being used, and | |
431 | can offer significant power savings on a running system. These devices | |
432 | often support a range of runtime power states, which might use names such | |
433 | as "off", "sleep", "idle", "active", and so on. Those states will in some | |
434 | cases (like PCI) be partially constrained by a bus the device uses, and will | |
435 | usually include hardware states that are also used in system sleep states. | |
436 | ||
437 | However, note that if a driver puts a device into a runtime low power state | |
438 | and the system then goes into a system-wide sleep state, it normally ought | |
439 | to resume into that runtime low power state rather than "full on". Such | |
440 | distinctions would be part of the driver-internal state machine for that | |
441 | hardware; the whole point of runtime power management is to be sure that | |
442 | drivers are decoupled in that way from the state machine governing phases | |
443 | of the system-wide power/sleep state transitions. | |
444 | ||
445 | ||
446 | Power Saving Techniques | |
447 | ----------------------- | |
448 | Normally runtime power management is handled by the drivers without specific | |
449 | userspace or kernel intervention, by device-aware use of techniques like: | |
450 | ||
451 | Using information provided by other system layers | |
452 | - stay deeply "off" except between open() and close() | |
453 | - if transceiver/PHY indicates "nobody connected", stay "off" | |
454 | - application protocols may include power commands or hints | |
455 | ||
456 | Using fewer CPU cycles | |
457 | - using DMA instead of PIO | |
458 | - removing timers, or making them lower frequency | |
459 | - shortening "hot" code paths | |
460 | - eliminating cache misses | |
461 | - (sometimes) offloading work to device firmware | |
462 | ||
463 | Reducing other resource costs | |
464 | - gating off unused clocks in software (or hardware) | |
465 | - switching off unused power supplies | |
466 | - eliminating (or delaying/merging) IRQs | |
467 | - tuning DMA to use word and/or burst modes | |
468 | ||
469 | Using device-specific low power states | |
470 | - using lower voltages | |
471 | - avoiding needless DMA transfers | |
472 | ||
473 | Read your hardware documentation carefully to see the opportunities that | |
474 | may be available. If you can, measure the actual power usage and check | |
475 | it against the budget established for your project. | |
476 | ||
477 | ||
478 | Examples: USB hosts, system timer, system CPU | |
479 | ---------------------------------------------- | |
480 | USB host controllers make interesting, if complex, examples. In many cases | |
481 | these have no work to do: no USB devices are connected, or all of them are | |
482 | in the USB "suspend" state. Linux host controller drivers can then disable | |
483 | periodic DMA transfers that would otherwise be a constant power drain on the | |
484 | memory subsystem, and enter a suspend state. In power-aware controllers, | |
485 | entering that suspend state may disable the clock used with USB signaling, | |
486 | saving a certain amount of power. | |
487 | ||
488 | The controller will be woken from that state (with an IRQ) by changes to the | |
489 | signal state on the data lines of a given port, for example by an existing | |
490 | peripheral requesting "remote wakeup" or by plugging a new peripheral. The | |
491 | same wakeup mechanism usually works from "standby" sleep states, and on some | |
492 | systems also from "suspend to RAM" (or even "suspend to disk") states. | |
493 | (Except that ACPI may be involved instead of normal IRQs, on some hardware.) | |
494 | ||
495 | System devices like timers and CPUs may have special roles in the platform | |
496 | power management scheme. For example, system timers using a "dynamic tick" | |
497 | approach don't just save CPU cycles (by eliminating needless timer IRQs), | |
498 | but they may also open the door to using lower power CPU "idle" states that | |
499 | cost more than a jiffie to enter and exit. On x86 systems these are states | |
500 | like "C3"; note that periodic DMA transfers from a USB host controller will | |
501 | also prevent entry to a C3 state, much like a periodic timer IRQ. | |
502 | ||
503 | That kind of runtime mechanism interaction is common. "System On Chip" (SOC) | |
504 | processors often have low power idle modes that can't be entered unless | |
505 | certain medium-speed clocks (often 12 or 48 MHz) are gated off. When the | |
506 | drivers gate those clocks effectively, then the system idle task may be able | |
507 | to use the lower power idle modes and thereby increase battery life. | |
508 | ||
509 | If the CPU can have a "cpufreq" driver, there also may be opportunities | |
510 | to shift to lower voltage settings and reduce the power cost of executing | |
511 | a given number of instructions. (Without voltage adjustment, it's rare | |
512 | for cpufreq to save much power; the cost-per-instruction must go down.) |