diff options
Diffstat (limited to 'Documentation/power')
| -rw-r--r-- | Documentation/power/devices.txt | 847 | ||||
| -rw-r--r-- | Documentation/power/pci.txt | 1258 | ||||
| -rw-r--r-- | Documentation/power/pm_qos_interface.txt | 48 | ||||
| -rw-r--r-- | Documentation/power/regulator/consumer.txt | 10 | ||||
| -rw-r--r-- | Documentation/power/regulator/machine.txt | 2 | ||||
| -rw-r--r-- | Documentation/power/regulator/overview.txt | 6 | ||||
| -rw-r--r-- | Documentation/power/runtime_pm.txt | 95 | ||||
| -rw-r--r-- | Documentation/power/userland-swsusp.txt | 4 |
8 files changed, 1607 insertions, 663 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index c9abbd86bc18..57080cd74575 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -1,7 +1,13 @@ +Device Power Management + +Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. +Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu> + + Most of the code in Linux is device drivers, so most of the Linux power -management code is also driver-specific. Most drivers will do very little; -others, especially for platforms with small batteries (like cell phones), -will do a lot. +management (PM) code is also driver-specific. Most drivers will do very +little; others, especially for platforms with small batteries (like cell +phones), will do a lot. This writeup gives an overview of how drivers interact with system-wide power management goals, emphasizing the models and interfaces that are @@ -15,9 +21,10 @@ Drivers will use one or both of these models to put devices into low-power states: System Sleep model: - Drivers can enter low power states as part of entering system-wide - low-power states like "suspend-to-ram", or (mostly for systems with - disks) "hibernate" (suspend-to-disk). + Drivers can enter low-power states as part of entering system-wide + low-power states like "suspend" (also known as "suspend-to-RAM"), or + (mostly for systems with disks) "hibernation" (also known as + "suspend-to-disk"). This is something that device, bus, and class drivers collaborate on by implementing various role-specific suspend and resume methods to @@ -25,33 +32,41 @@ states: them without loss of data. Some drivers can manage hardware wakeup events, which make the system - leave that low-power state. This feature may be disabled using the - relevant /sys/devices/.../power/wakeup file; enabling it may cost some - power usage, but let the whole system enter low power states more often. + leave the low-power state. This feature may be enabled or disabled + using the relevant /sys/devices/.../power/wakeup file (for Ethernet + drivers the ioctl interface used by ethtool may also be used for this + purpose); enabling it may cost some power usage, but let the whole + system enter low-power states more often. Runtime Power Management model: - Drivers may also enter low power states while the system is running, - independently of other power management activity. Upstream drivers - will normally not know (or care) if the device is in some low power - state when issuing requests; the driver will auto-resume anything - that's needed when it gets a request. - - This doesn't have, or need much infrastructure; it's just something you - should do when writing your drivers. For example, clk_disable() unused - clocks as part of minimizing power drain for currently-unused hardware. - Of course, sometimes clusters of drivers will collaborate with each - other, which could involve task-specific power management. - -There's not a lot to be said about those low power states except that they -are very system-specific, and often device-specific. Also, that if enough -drivers put themselves into low power states (at "runtime"), the effect may be -the same as entering some system-wide low-power state (system sleep) ... and -that synergies exist, so that several drivers using runtime pm might put the -system into a state where even deeper power saving options are available. - -Most suspended devices will have quiesced all I/O: no more DMA or irqs, no -more data read or written, and requests from upstream drivers are no longer -accepted. A given bus or platform may have different requirements though. + Devices may also be put into low-power states while the system is + running, independently of other power management activity in principle. + However, devices are not generally independent of each other (for + example, a parent device cannot be suspended unless all of its child + devices have been suspended). Moreover, depending on the bus type the + device is on, it may be necessary to carry out some bus-specific + operations on the device for this purpose. Devices put into low power + states at run time may require special handling during system-wide power + transitions (suspend or hibernation). + + For these reasons not only the device driver itself, but also the + appropriate subsystem (bus type, device type or device class) driver and + the PM core are involved in runtime power management. As in the system + sleep power management case, they need to collaborate by implementing + various role-specific suspend and resume methods, so that the hardware + is cleanly powered down and reactivated without data or service loss. + +There's not a lot to be said about those low-power states except that they are +very system-specific, and often device-specific. Also, that if enough devices +have been put into low-power states (at runtime), the effect may be very similar +to entering some system-wide low-power state (system sleep) ... and that +synergies exist, so that several drivers using runtime PM might put the system +into a state where even deeper power saving options are available. + +Most suspended devices will have quiesced all I/O: no more DMA or IRQs (except +for wakeup events), no more data read or written, and requests from upstream +drivers are no longer accepted. A given bus or platform may have different +requirements though. Examples of hardware wakeup events include an alarm from a real time clock, network wake-on-LAN packets, keyboard or mouse activity, and media insertion @@ -60,129 +75,152 @@ or removal (for PCMCIA, MMC/SD, USB, and so on). Interfaces for Entering System Sleep States =========================================== -Most of the programming interfaces a device driver needs to know about -relate to that first model: entering a system-wide low power state, -rather than just minimizing power consumption by one device. - - -Bus Driver Methods ------------------- -The core methods to suspend and resume devices reside in struct bus_type. -These are mostly of interest to people writing infrastructure for busses -like PCI or USB, or because they define the primitives that device drivers -may need to apply in domain-specific ways to their devices: - -struct bus_type { - ... - int (*suspend)(struct device *dev, pm_message_t state); - int (*resume)(struct device *dev); +There are programming interfaces provided for subsystems (bus type, device type, +device class) and device drivers to allow them to participate in the power +management of devices they are concerned with. These interfaces cover both +system sleep and runtime power management. + + +Device Power Management Operations +---------------------------------- +Device power management operations, at the subsystem level as well as at the +device driver level, are implemented by defining and populating objects of type +struct dev_pm_ops: + +struct dev_pm_ops { + int (*prepare)(struct device *dev); + void (*complete)(struct device *dev); + int (*suspend)(struct device *dev); + int (*resume)(struct device *dev); + int (*freeze)(struct device *dev); + int (*thaw)(struct device *dev); + int (*poweroff)(struct device *dev); + int (*restore)(struct device *dev); + int (*suspend_noirq)(struct device *dev); + int (*resume_noirq)(struct device *dev); + int (*freeze_noirq)(struct device *dev); + int (*thaw_noirq)(struct device *dev); + int (*poweroff_noirq)(struct device *dev); + int (*restore_noirq)(struct device *dev); + int (*runtime_suspend)(struct device *dev); + int (*runtime_resume)(struct device *dev); + int (*runtime_idle)(struct device *dev); }; -Bus drivers implement those methods as appropriate for the hardware and -the drivers using it; PCI works differently from USB, and so on. Not many -people write bus drivers; most driver code is a "device driver" that -builds on top of bus-specific framework code. +This structure is defined in include/linux/pm.h and the methods included in it +are also described in that file. Their roles will be explained in what follows. +For now, it should be sufficient to remember that the last three methods are +specific to runtime power management while the remaining ones are used during +system-wide power transitions. -For more information on these driver calls, see the description later; -they are called in phases for every device, respecting the parent-child -sequencing in the driver model tree. Note that as this is being written, -only the suspend() and resume() are widely available; not many bus drivers -leverage all of those phases, or pass them down to lower driver levels. +There also is a deprecated "old" or "legacy" interface for power management +operations available at least for some subsystems. This approach does not use +struct dev_pm_ops objects and it is suitable only for implementing system sleep +power management methods. Therefore it is not described in this document, so +please refer directly to the source code for more information about it. -/sys/devices/.../power/wakeup files ------------------------------------ -All devices in the driver model have two flags to control handling of -wakeup events, which are hardware signals that can force the device and/or -system out of a low power state. These are initialized by bus or device -driver code using device_init_wakeup(dev,can_wakeup). +Subsystem-Level Methods +----------------------- +The core methods to suspend and resume devices reside in struct dev_pm_ops +pointed to by the pm member of struct bus_type, struct device_type and +struct class. They are mostly of interest to the people writing infrastructure +for buses, like PCI or USB, or device type and device class drivers. -The "can_wakeup" flag just records whether the device (and its driver) can -physically support wakeup events. When that flag is clear, the sysfs -"wakeup" file is empty, and device_may_wakeup() returns false. +Bus drivers implement these methods as appropriate for the hardware and the +drivers using it; PCI works differently from USB, and so on. Not many people +write subsystem-level drivers; most driver code is a "device driver" that builds +on top of bus-specific framework code. -For devices that can issue wakeup events, a separate flag controls whether -that device should try to use its wakeup mechanism. The initial value of -device_may_wakeup() will be true, so that the device's "wakeup" file holds -the value "enabled". Userspace can change that to "disabled" so that -device_may_wakeup() returns false; or change it back to "enabled" (so that -it returns true again). +For more information on these driver calls, see the description later; +they are called in phases for every device, respecting the parent-child +sequencing in the driver model tree. -EXAMPLE: PCI Device Driver Methods +/sys/devices/.../power/wakeup files ----------------------------------- -PCI framework software calls these methods when the PCI device driver bound -to a device device has provided them: - -struct pci_driver { - ... - int (*suspend)(struct pci_device *pdev, pm_message_t state); - int (*suspend_late)(struct pci_device *pdev, pm_message_t state); +All devices in the driver model have two flags to control handling of wakeup +events (hardware signals that can force the device and/or system out of a low +power state). These flags are initialized by bus or device driver code using +device_set_wakeup_capable() and device_set_wakeup_enable(), defined in +include/linux/pm_wakeup.h. - int (*resume_early)(struct pci_device *pdev); - int (*resume)(struct pci_device *pdev); -}; - -Drivers will implement those methods, and call PCI-specific procedures -like pci_set_power_state(), pci_enable_wake(), pci_save_state(), and -pci_restore_state() to manage PCI-specific mechanisms. (PCI config space -could be saved during driver probe, if it weren't for the fact that some -systems rely on userspace tweaking using setpci.) Devices are suspended -before their bridges enter low power states, and likewise bridges resume -before their devices. - - -Upper Layers of Driver Stacks ------------------------------ -Device drivers generally have at least two interfaces, and the methods -sketched above are the ones which apply to the lower level (nearer PCI, USB, -or other bus hardware). The network and block layers are examples of upper -level interfaces, as is a character device talking to userspace. - -Power management requests normally need to flow through those upper levels, -which often use domain-oriented requests like "blank that screen". In -some cases those upper levels will have power management intelligence that -relates to end-user activity, or other devices that work in cooperation. - -When those interfaces are structured using class interfaces, there is a -standard way to have the upper layer stop issuing requests to a given -class device (and restart later): - -struct class { - ... - int (*suspend)(struct device *dev, pm_message_t state); - int (*resume)(struct device *dev); -}; - -Those calls are issued in specific phases of the process by which the -system enters a low power "suspend" state, or resumes from it. - - -Calling Drivers to Enter System Sleep States -============================================ -When the system enters a low power state, each device's driver is asked -to suspend the device by putting it into state compatible with the target +The "can_wakeup" flag just records whether the device (and its driver) can +physically support wakeup events. The device_set_wakeup_capable() routine +affects this flag. The "should_wakeup" flag controls whether the device should +try to use its wakeup mechanism. device_set_wakeup_enable() affects this flag; +for the most part drivers should not change its value. The initial value of +should_wakeup is supposed to be false for the majority of devices; the major +exceptions are power buttons, keyboards, and Ethernet adapters whose WoL +(wake-on-LAN) feature has been set up with ethtool. + +Whether or not a device is capable of issuing wakeup events is a hardware +matter, and the kernel is responsible for keeping track of it. By contrast, +whether or not a wakeup-capable device should issue wakeup events is a policy +decision, and it is managed by user space through a sysfs attribute: the +power/wakeup file. User space can write the strings "enabled" or "disabled" to +set or clear the should_wakeup flag, respectively. Reads from the file will +return the corresponding string if can_wakeup is true, but if can_wakeup is +false then reads will return an empty string, to indicate that the device +doesn't support wakeup events. (But even though the file appears empty, writes +will still affect the should_wakeup flag.) + +The device_may_wakeup() routine returns true only if both flags are set. +Drivers should check this routine when putting devices in a low-power state +during a system sleep transition, to see whether or not to enable the devices' +wakeup mechanisms. However for runtime power management, wakeup events should +be enabled whenever the device and driver both support them, regardless of the +should_wakeup flag. + + +/sys/devices/.../power/control files +------------------------------------ +Each device in the driver model has a flag to control whether it is subject to +runtime power management. This flag, called runtime_auto, is initialized by the +bus type (or generally subsystem) code using pm_runtime_allow() or +pm_runtime_forbid(); the default is to allow runtime power management. + +The setting can be adjusted by user space by writing either "on" or "auto" to +the device's power/control sysfs file. Writing "auto" calls pm_runtime_allow(), +setting the flag and allowing the device to be runtime power-managed by its +driver. Writing "on" calls pm_runtime_forbid(), clearing the flag, returning +the device to full power if it was in a low-power state, and preventing the +device from being runtime power-managed. User space can check the current value +of the runtime_auto flag by reading the file. + +The device's runtime_auto flag has no effect on the handling of system-wide +power transitions. In particular, the device can (and in the majority of cases +should and will) be put into a low-power state during a system-wide transition +to a sleep state even though its runtime_auto flag is clear. + +For more information about the runtime power management framework, refer to +Documentation/power/runtime_pm.txt. + + +Calling Drivers to Enter and Leave System Sleep States +====================================================== +When the system goes into a sleep state, each device's driver is asked to +suspend the device by putting it into a state compatible with the target system state. That's usually some version of "off", but the details are system-specific. Also, wakeup-enabled devices will usually stay partly functional in order to wake the system. -When the system leaves that low power state, the device's driver is asked -to resume it. The suspend and resume operations always go together, and -both are multi-phase operations. +When the system leaves that low-power state, the device's driver is asked to +resume it by returning it to full power. The suspend and resume operations +always go together, and both are multi-phase operations. -For simple drivers, suspend might quiesce the device using the class code -and then turn its hardware as "off" as possible with late_suspend. The +For simple drivers, suspend might quiesce the device using class code +and then turn its hardware as "off" as possible during suspend_noirq. The matching resume calls would then completely reinitialize the hardware before reactivating its class I/O queues. -More power-aware drivers drivers will use more than one device low power -state, either at runtime or during system sleep states, and might trigger -system wakeup events. +More power-aware drivers might prepare the devices for triggering system wakeup +events. Call Sequence Guarantees ------------------------ -To ensure that bridges and similar links needed to talk to a device are +To ensure that bridges and similar links needing to talk to a device are available when the device is suspended or resumed, the device tree is walked in a bottom-up order to suspend devices. A top-down order is used to resume those devices. @@ -194,67 +232,310 @@ its parent; and can't be removed or suspended after that parent. The policy is that the device tree should match hardware bus topology. (Or at least the control bus, for devices which use multiple busses.) In particular, this means that a device registration may fail if the parent of -the device is suspending (ie. has been chosen by the PM core as the next +the device is suspending (i.e. has been chosen by the PM core as the next device to suspend) or has already suspended, as well as after all of the other devices have been suspended. Device drivers must be prepared to cope with such situations. -Suspending Devices ------------------- -Suspending a given device is done in several phases. Suspending the -system always includes every phase, executing calls for every device -before the next phase begins. Not all busses or classes support all -these callbacks; and not all drivers use all the callbacks. +System Power Management Phases +------------------------------ +Suspending or resuming the system is done in several phases. Different phases +are used for standby or memory sleep states ("suspend-to-RAM") and the +hibernation state ("suspend-to-disk"). Each phase involves executing callbacks +for every device before the next phase begins. Not all busses or classes +support all these callbacks and not all drivers use all the callbacks. The +various phases always run after tasks have been frozen and before they are +unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have +been disabled (except for those marked with the IRQ_WAKEUP flag). -The phases are seen by driver notifications issued in this order: +Most phases use bus, type, and class callbacks (that is, methods defined in +dev->bus->pm, dev->type->pm, and dev->class->pm). The prepare and complete +phases are exceptions; they use only bus callbacks. When multiple callbacks +are used in a phase, they are invoked in the order: <class, type, bus> during +power-down transitions and in the opposite order during power-up transitions. +For example, during the suspend phase the PM core invokes - 1 class.suspend(dev, message) is called after tasks are frozen, for - devices associated with a class that has such a method. This - method may sleep. + dev->class->pm.suspend(dev); + dev->type->pm.suspend(dev); + dev->bus->pm.suspend(dev); - Since I/O activity usually comes from such higher layers, this is - a good place to quiesce all drivers of a given type (and keep such - code out of those drivers). +before moving on to the next device, whereas during the resume phase the core +invokes - 2 bus.suspend(dev, message) is called next. This method may sleep, - and is often morphed into a device driver call with bus-specific - parameters and/or rules. + dev->bus->pm.resume(dev); + dev->type->pm.resume(dev); + dev->class->pm.resume(dev); - This call should handle parts of device suspend logic that require - sleeping. It probably does work to quiesce the device which hasn't - been abstracted into class.suspend(). +These callbacks may in turn invoke device- or driver-specific methods stored in +dev->driver->pm, but they don't have to. -The pm_message_t parameter is currently used to refine those semantics -(described later). -At the end of those phases, drivers should normally have stopped all I/O -transactions (DMA, IRQs), saved enough state that they can re-initialize -or restore previous state (as needed by the hardware), and placed the -device into a low-power state. On many platforms they will also use -clk_disable() to gate off one or more clock sources; sometimes they will -also switch off power supplies, or reduce voltages. Drivers which have -runtime PM support may already have performed some or all of the steps -needed to prepare for the upcoming system sleep state. +Entering System Suspend +----------------------- +When the system goes into the standby or memory sleep state, the phases are: + + prepare, suspend, suspend_noirq. + + 1. The prepare phase is meant to prevent races by preventing new devices + from being registered; the PM core would never know that all the + children of a device had been suspended if new children could be + registered at will. (By contrast, devices may be unregistered at any + time.) Unlike the other suspend-related phases, during the prepare + phase the device tree is traversed top-down. + + The prepare phase uses only a bus callback. After the callback method + returns, no new children may be registered below the device. The method + may also prepare the device or driver in some way for the upcoming + system power transition, but it should not put the device into a + low-power state. + + 2. The suspend methods should quiesce the device to stop it from performing + I/O. They also may save the device registers and put it into the + appropriate low-power state, depending on the bus type the device is on, + and they may enable wakeup events. + + 3. The suspend_noirq phase occurs after IRQ handlers have been disabled, + which means that the driver's interrupt handler will not be called while + the callback method is running. The methods should save the values of + the device's registers that weren't saved previously and finally put the + device into the appropriate low-power state. + + The majority of subsystems and device drivers need not implement this + callback. However, bus types allowing devices to share interrupt + vectors, like PCI, generally need it; otherwise a driver might encounter + an error during the suspend phase by fielding a shared interrupt + generated by some other device after its own device had been set to low + power. + +At the end of these phases, drivers should have stopped all I/O transactions +(DMA, IRQs), saved enough state that they can re-initialize or restore previous +state (as needed by the hardware), and placed the device into a low-power state. +On many platforms they will gate off one or more clock sources; sometimes they +will also switch off power supplies or reduce voltages. (Drivers supporting +runtime PM may already have performed some or all of these steps.) + +If device_may_wakeup(dev) returns true, the device should be prepared for +generating hardware wakeup signals to trigger a system wakeup event when the +system is in the sleep state. For example, enable_irq_wake() might identify +GPIO signals hooked up to a switch or other external hardware, and +pci_enable_wake() does something similar for the PCI PME signal. + +If any of these callbacks returns an error, the system won't enter the desired +low-power state. Instead the PM core will unwind its actions by resuming all +the devices that were suspended. + + +Leaving System Suspend +---------------------- +When resuming from standby or memory sleep, the phases are: + + resume_noirq, resume, complete. + + 1. The resume_noirq callback methods should perform any actions needed + before the driver's interrupt handlers are invoked. This generally + means undoing the actions of the suspend_noirq phase. If the bus type + permits devices to share interrupt vectors, like PCI, the method should + bring the device and its driver into a state in which the driver can + recognize if the device is the source of incoming interrupts, if any, + and handle them correctly. + + For example, the PCI bus type's ->pm.resume_noirq() puts the device into + the full-power state (D0 in the PCI terminology) and restores the + standard configuration registers of the device. Then it calls the + device driver's ->pm.resume_noirq() method to perform device-specific + actions. + + 2. The resume methods should bring the the device back to its operating + state, so that it can perform normal I/O. This generally involves + undoing the actions of the suspend phase. + + 3. The complete phase uses only a bus callback. The method should undo the + actions of the prepare phase. Note, however, that new children may be + registered below the device as soon as the resume callbacks occur; it's + not necessary to wait until the complete phase. + +At the end of these phases, drivers should be as functional as they were before +suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are +gated on. Even if the device was in a low-power state before the system sleep +because of runtime power management, afterwards it should be back in its +full-power state. There are multiple reasons why it's best to do this; they are +discussed in more detail in Documentation/power/runtime_pm.txt. -When any driver sees that its device_can_wakeup(dev), it should make sure -to use the relevant hardware signals to trigger a system wakeup event. -For example, enable_irq_wake() might identify GPIO signals hooked up to -a switch or other external hardware, and pci_enable_wake() does something -similar for PCI's PME# signal. +However, the details here may again be platform-specific. For example, +some systems support multiple "run" states, and the mode in effect at +the end of resume might not be the one which preceded suspension. +That means availability of certain clocks or power supplies changed, +which could easily affect how a driver works. + +Drivers need to be able to handle hardware which has been reset since the +suspend methods were called, for example by complete reinitialization. +This may be the hardest part, and the one most protected by NDA'd documents +and chip errata. It's simplest if the hardware state hasn't changed since +the suspend was carried out, but that can't be guaranteed (in fact, it ususally +is not the case). + +Drivers must also be prepared to notice that the device has been removed +while the system was powered down, whenever that's physically possible. +PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses +where common Linux platforms will see such removal. Details of how drivers +will notice and handle such removals are currently bus-specific, and often +involve a separate thread. + +These callbacks may return an error value, but the PM core will ignore such +errors since there's nothing it can do about them other than printing them in +the system log. + + +Entering Hibernation +-------------------- +Hibernating the system is more complicated than putting it into the standby or +memory sleep state, because it involves creating and saving a system image. +Therefore there are more phases for hibernation, with a different set of +callbacks. These phases always run after tasks have been frozen and memory has +been freed. + +The general procedure for hibernation is to quiesce all devices (freeze), create +an image of the system memory while everything is stable, reactivate all +devices (thaw), write the image to permanent storage, and finally shut down the +system (poweroff). The phases used to accomplish this are: + + prepare, freeze, freeze_noirq, thaw_noirq, thaw, complete, + prepare, poweroff, poweroff_noirq + + 1. The prepare phase is discussed in the "Entering System Suspend" section + above. + + 2. The freeze methods should quiesce the device so that it doesn't generate + IRQs or DMA, and they may need to save the values of device registers. + However the device does not have to be put in a low-power state, and to + save time it's best not to do so. Also, the device should not be + prepared to generate wakeup events. + + 3. The freeze_noirq phase is analogous to the suspend_noirq phase discussed + above, except again that the device should not be put in a low-power + state and should not be allowed to generate wakeup events. + +At this point the system image is created. All devices should be inactive and +the contents of memory should remain undisturbed while this happens, so that the +image forms an atomic snapshot of the system state. + + 4. The thaw_noirq phase is analogous to the resume_noirq phase discussed + above. The main difference is that its methods can assume the device is + in the same state as at the end of the freeze_noirq phase. + + 5. The thaw phase is analogous to the resume phase discussed above. Its + methods should bring the device back to an operating state, so that it + can be used for saving the image if necessary. + + 6. The complete phase is discussed in the "Leaving System Suspend" section + above. + +At this point the system image is saved, and the devices then need to be +prepared for the upcoming system shutdown. This is much like suspending them +before putting the system into the standby or memory sleep state, and the phases +are similar. + + 7. The prepare phase is discussed above. + + 8. The poweroff phase is analogous to the suspend phase. + + 9. The poweroff_noirq phase is analogous to the suspend_noirq phase. + +The poweroff and poweroff_noirq callbacks should do essentially the same things +as the suspend and suspend_noirq callbacks. The only notable difference is that +they need not store the device register values, because the registers should +already have been stored during the freeze or freeze_noirq phases. + + +Leaving Hibernation +------------------- +Resuming from hibernation is, again, more complicated than resuming from a sleep +state in which the contents of main memory are preserved, because it requires +a system image to be loaded into memory and the pre-hibernation memory contents +to be restored before control can be passed back to the image kernel. + +Although in principle, the image might be loaded into memory and the +pre-hibernation memory contents restored by the boot loader, in practice this +can't be done because boot loaders aren't smart enough and there is no +established protocol for passing the necessary information. So instead, the +boot loader loads a fresh instance of the kernel, called the boot kernel, into +memory and passes control to it in the usual way. Then the boot kernel reads +the system image, restores the pre-hibernation memory contents, and passes +control to the image kernel. Thus two different kernels are involved in +resuming from hibernation. In fact, the boot kernel may be completely different +from the image kernel: a different configuration and even a different version. +This has important consequences for device drivers and their subsystems. + +To be able to load the system image into memory, the boot kernel needs to +include at least a subset of device drivers allowing it to access the storage +medium containing the image, although it doesn't need to include all of the +drivers present in the image kernel. After the image has been loaded, the +devices managed by the boot kernel need to be prepared for passing control back +to the image kernel. This is very similar to the initial steps involved in +creating a system image, and it is accomplished in the same way, using prepare, +freeze, and freeze_noirq phases. However the devices affected by these phases +are only those having drivers in the boot kernel; other devices will still be in +whatever state the boot loader left them. + +Should the restoration of the pre-hibernation memory contents fail, the boot +kernel would go through the "thawing" procedure described above, using the +thaw_noirq, thaw, and complete phases, and then continue running normally. This +happens only rarely. Most often the pre-hibernation memory contents are +restored successfully and control is passed to the image kernel, which then +becomes responsible for bringing the system back to the working state. + +To achieve this, the image kernel must restore the devices' pre-hibernation +functionality. The operation is much like waking up from the memory sleep +state, although it involves different phases: + + restore_noirq, restore, complete + + 1. The restore_noirq phase is analogous to the resume_noirq phase. + + 2. The restore phase is analogous to the resume phase. + + 3. The complete phase is discussed above. + +The main difference from resume[_noirq] is that restore[_noirq] must assume the +device has been accessed and reconfigured by the boot loader or the boot kernel. +Consequently the state of the device may be different from the state remembered +from the freeze and freeze_noirq phases. The device may even need to be reset +and completely re-initialized. In many cases this difference doesn't matter, so +the resume[_noirq] and restore[_norq] method pointers can be set to the same +routines. Nevertheless, different callback pointers are used in case there is a +situation where it actually matters. -If a driver (or bus, or class) fails it suspend method, the system won't -enter the desired low power state; it will resume all the devices it's -suspended so far. -Note that drivers may need to perform different actions based on the target -system lowpower/sleep state. At this writing, there are only platform -specific APIs through which drivers could determine those target states. +System Devices +-------------- +System devices (sysdevs) follow a slightly different API, which can be found in + + include/linux/sysdev.h + drivers/base/sys.c + +System devices will be suspended with interrupts disabled, and after all other +devices have been suspended. On resume, they will be resumed before any other +devices, and also with interrupts disabled. These things occur in special +"sysdev_driver" phases, which affect only system devices. + +Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when +the non-boot CPUs are all offline and IRQs are disabled on the remaining online +CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a +sleep state (or a system image is created). During resume (or after the image +has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs +are enabled on the only online CPU, the non-boot CPUs are enabled, and the +resume_noirq (or thaw_noirq or restore_noirq) phase begins. + +Code to actually enter and exit the system-wide low power state sometimes +involves hardware details that are only known to the boot firmware, and +may leave a CPU running software (from SRAM or flash memory) that monitors +the system and manages its wakeup sequence. Device Low Power (suspend) States --------------------------------- -Device low-power states aren't very standard. One device might only handle +Device low-power states aren't standard. One device might only handle "on" and "off, while another might support a dozen different versions of "on" (how many engines are active?), plus a state that gets back to "on" faster than from a full "off". @@ -265,7 +546,7 @@ PCI device may not perform DMA or issue IRQs, and any wakeup events it issues would be issued through the PME# bus signal. Plus, there are several PCI-standard device states, some of which are optional. -In contrast, integrated system-on-chip processors often use irqs as the +In contrast, integrated system-on-chip processors often use IRQs as the wakeup event sources (so drivers would call enable_irq_wake) and might be able to treat DMA completion as a wakeup event (sometimes DMA can stay active too, it'd only be the CPU and some peripherals that sleep). @@ -284,120 +565,17 @@ ways; the aforementioned LCD might be active in one product's "standby", but a different product using the same SOC might work differently. -Meaning of pm_message_t.event ------------------------------ -Parameters to suspend calls include the device affected and a message of -type pm_message_t, which has one field: the event. If driver does not -recognize the event code, suspend calls may abort the request and return -a negative errno. However, most drivers will be fine if they implement -PM_EVENT_SUSPEND semantics for all messages. +Power Management Notifiers +-------------------------- +There are some operations that cannot be carried out by the power management +callbacks discussed above, because the callbacks occur too late or too early. +To handle these cases, subsystems and device drivers may register power +management notifiers that are called before tasks are frozen and after they have +been thawed. Generally speaking, the PM notifiers are suitable for performing +actions that either require user space to be available, or at least won't +interfere with user space. -The event codes are used to refine the goal of suspending the device, and -mostly matter when creating or resuming system memory image snapshots, as -used with suspend-to-disk: - - PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power - state. When used with system sleep states like "suspend-to-RAM" or - "standby", the upcoming resume() call will often be able to rely on - state kept in hardware, or issue system wakeup events. - - PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup - events as appropriate. It is only used with hibernation - (suspend-to-disk) and few devices are able to wake up the system from - this state; most are completely powered off. - - PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into - any low power mode. A system snapshot is about to be taken, often - followed by a call to the driver's resume() method. Neither wakeup - events nor DMA are allowed. - - PM_EVENT_PRETHAW -- quiesce the driver, knowing that the upcoming resume() - will restore a suspend-to-disk snapshot from a different kernel image. - Drivers that are smart enough to look at their hardware state during - resume() processing need that state to be correct ... a PRETHAW could - be used to invalidate that state (by resetting the device), like a - shutdown() invocation would before a kexec() or system halt. Other - drivers might handle this the same way as PM_EVENT_FREEZE. Neither - wakeup events nor DMA are allowed. - -To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or -the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event -codes are used for hibernation ("Suspend to Disk", STD, ACPI S4). - -There's also PM_EVENT_ON, a value which never appears as a suspend event -but is sometimes used to record the "not suspended" device state. - - -Resuming Devices ----------------- -Resuming is done in multiple phases, much like suspending, with all -devices processing each phase's calls before the next phase begins. - -The phases are seen by driver notifications issued in this order: - - 1 bus.resume(dev) reverses the effects of bus.suspend(). This may - be morphed into a device driver call with bus-specific parameters; - implementations may sleep. - - 2 class.resume(dev) is called for devices associated with a class - that has such a method. Implementations may sleep. - - This reverses the effects of class.suspend(), and would usually - reactivate the device's I/O queue. - -At the end of those phases, drivers should normally be as functional as -they were before suspending: I/O can be performed using DMA and IRQs, and -the relevant clocks are gated on. The device need not be "fully on"; it -might be in a runtime lowpower/suspend state that acts as if it were. - -However, the details here may again be platform-specific. For example, -some systems support multiple "run" states, and the mode in effect at -the end of resume() might not be the one which preceded suspension. -That means availability of certain clocks or power supplies changed, -which could easily affect how a driver works. - - -Drivers need to be able to handle hardware which has been reset since the -suspend methods were called, for example by complete reinitialization. -This may be the hardest part, and the one most protected by NDA'd documents -and chip errata. It's simplest if the hardware state hasn't changed since -the suspend() was called, but that can't always be guaranteed. - -Drivers must also be prepared to notice that the device has been removed -while the system was powered off, whenever that's physically possible. -PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses -where common Linux platforms will see such removal. Details of how drivers -will notice and handle such removals are currently bus-specific, and often -involve a separate thread. - - -Note that the bus-specific runtime PM wakeup mechanism can exist, and might -be defined to share some of the same driver code as for system wakeup. For -example, a bus-specific device driver's resume() method might be used there, -so it wouldn't only be called from bus.resume() during system-wide wakeup. -See bus-specific information about how runtime wakeup events are handled. - - -System Devices --------------- -System devices follow a slightly different API, which can be found in - - include/linux/sysdev.h - drivers/base/sys.c - -System devices will only be suspended with interrupts disabled, and after -all other devices have been suspended. On resume, they will be resumed -before any other devices, and also with interrupts disabled. - -That is, IRQs are disabled, the suspend_late() phase begins, then the -sysdev_driver.suspend() phase, and the system enters a sleep state. Then -the sysdev_driver.resume() phase begins, followed by the resume_early() -phase, after which IRQs are enabled. - -Code to actually enter and exit the system-wide low power state sometimes -involves hardware details that are only known to the boot firmware, and -may leave a CPU running software (from SRAM or flash memory) that monitors -the system and manages its wakeup sequence. +For details refer to Documentation/power/notifiers.txt. Runtime Power Management @@ -407,82 +585,23 @@ running. This feature is useful for devices that are not being used, and can offer significant power savings on a running system. These devices often support a range of runtime power states, which might use names such as "off", "sleep", "idle", "active", and so on. Those states will in some -cases (like PCI) be partially constrained by a bus the device uses, and will +cases (like PCI) be partially constrained by the bus the device uses, and will usually include hardware states that are also used in system sleep states. -However, note that if a driver puts a device into a runtime low power state -and the system then goes into a system-wide sleep state, it normally ought -to resume into that runtime low power state rather than "full on". Such -distinctions would be part of the driver-internal state machine for that -hardware; the whole point of runtime power management is to be sure that -drivers are decoupled in that way from the state machine governing phases -of the system-wide power/sleep state transitions. - - -Power Saving Techniques ------------------------ -Normally runtime power management is handled by the drivers without specific -userspace or kernel intervention, by device-aware use of techniques like: - - Using information provided by other system layers - - stay deeply "off" except between open() and close() - - if transceiver/PHY indicates "nobody connected", stay "off" - - application protocols may include power commands or hints - - Using fewer CPU cycles - - using DMA instead of PIO - - removing timers, or making them lower frequency - - shortening "hot" code paths - - eliminating cache misses - - (sometimes) offloading work to device firmware - - Reducing other resource costs - - gating off unused clocks in software (or hardware) - - switching off unused power supplies - - eliminating (or delaying/merging) IRQs - - tuning DMA to use word and/or burst modes - - Using device-specific low power states - - using lower voltages - - avoiding needless DMA transfers - -Read your hardware documentation carefully to see the opportunities that -may be available. If you can, measure the actual power usage and check -it against the budget established for your project. - - -Examples: USB hosts, system timer, system CPU ----------------------------------------------- -USB host controllers make interesting, if complex, examples. In many cases -these have no work to do: no USB devices are connected, or all of them are -in the USB "suspend" state. Linux host controller drivers can then disable -periodic DMA transfers that would otherwise be a constant power drain on the -memory subsystem, and enter a suspend state. In power-aware controllers, -entering that suspend state may disable the clock used with USB signaling, -saving a certain amount of power. - -The controller will be woken from that state (with an IRQ) by changes to the -signal state on the data lines of a given port, for example by an existing -peripheral requesting "remote wakeup" or by plugging a new peripheral. The -same wakeup mechanism usually works from "standby" sleep states, and on some -systems also from "suspend to RAM" (or even "suspend to disk") states. -(Except that ACPI may be involved instead of normal IRQs, on some hardware.) - -System devices like timers and CPUs may have special roles in the platform -power management scheme. For example, system timers using a "dynamic tick" -approach don't just save CPU cycles (by eliminating needless timer IRQs), -but they may also open the door to using lower power CPU "idle" states that -cost more than a jiffie to enter and exit. On x86 systems these are states -like "C3"; note that periodic DMA transfers from a USB host controller will -also prevent entry to a C3 state, much like a periodic timer IRQ. - -That kind of runtime mechanism interaction is common. "System On Chip" (SOC) -processors often have low power idle modes that can't be entered unless -certain medium-speed clocks (often 12 or 48 MHz) are gated off. When the -drivers gate those clocks effectively, then the system idle task may be able -to use the lower power idle modes and thereby increase battery life. - -If the CPU can have a "cpufreq" driver, there also may be opportunities -to shift to lower voltage settings and reduce the power cost of executing -a given number of instructions. (Without voltage adjustment, it's rare -for cpufreq to save much power; the cost-per-instruction must go down.) +A system-wide power transition can be started while some devices are in low +power states due to runtime power management. The system sleep PM callbacks +should recognize such situations and react to them appropriately, but the +necessary actions are subsystem-specific. + +In some cases the decision may be made at the subsystem level while in other +cases the device driver may be left to decide. In some cases it may be +desirable to leave a suspended device in that state during a system-wide power +transition, but in other cases the device must be put back into the full-power +state temporarily, for example so that its system wakeup capability can be +disabled. This all depends on the hardware and the design of the subsystem and +device driver in question. + +During system-wide resume from a sleep state it's best to put devices into the +full-power state, as explained in Documentation/power/runtime_pm.txt. Refer to +that document for more information regarding this particular issue as well as +for information on the device runtime power management framework in general. diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index dd8fe43888d3..62328d76b55b 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -1,299 +1,1025 @@ - PCI Power Management -~~~~~~~~~~~~~~~~~~~~ -An overview of the concepts and the related functions in the Linux kernel +Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. + +An overview of concepts and the Linux kernel's interfaces related to PCI power +management. Based on previous work by Patrick Mochel <mochel@transmeta.com> +(and others). -Patrick Mochel <mochel@transmeta.com> -(and others) +This document only covers the aspects of power management specific to PCI +devices. For general description of the kernel's interfaces related to device +power management refer to Documentation/power/devices.txt and +Documentation/power/runtime_pm.txt. --------------------------------------------------------------------------- -1. Overview -2. How the PCI Subsystem Does Power Management -3. PCI Utility Functions -4. PCI Device Drivers -5. Resources - -1. Overview -~~~~~~~~~~~ - -The PCI Power Management Specification was introduced between the PCI 2.1 and -PCI 2.2 Specifications. It a standard interface for controlling various -power management operations. - -Implementation of the PCI PM Spec is optional, as are several sub-components of -it. If a device supports the PCI PM Spec, the device will have an 8 byte -capability field in its PCI configuration space. This field is used to describe -and control the standard PCI power management features. - -The PCI PM spec defines 4 operating states for devices (D0 - D3) and for buses -(B0 - B3). The higher the number, the less power the device consumes. However, -the higher the number, the longer the latency is for the device to return to -an operational state (D0). - -There are actually two D3 states. When someone talks about D3, they usually -mean D3hot, which corresponds to an ACPI D2 state (power is reduced, the -device may lose some context). But they may also mean D3cold, which is an -ACPI D3 state (power is fully off, all state was discarded); or both. - -Bus power management is not covered in this version of this document. - -Note that all PCI devices support D0 and D3cold by default, regardless of -whether or not they implement any of the PCI PM spec. - -The possible state transitions that a device can undergo are: - -+---------------------------+ -| Current State | New State | -+---------------------------+ -| D0 | D1, D2, D3| -+---------------------------+ -| D1 | D2, D3 | -+---------------------------+ -| D2 | D3 | -+---------------------------+ -| D1, D2, D3 | D0 | -+---------------------------+ - -Note that when the system is entering a global suspend state, all devices will -be placed into D3 and when resuming, all devices will be placed into D0. -However, when the system is running, other state transitions are possible. - -2. How The PCI Subsystem Handles Power Management -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The PCI suspend/resume functionality is accessed indirectly via the Power -Management subsystem. At boot, the PCI driver registers a power management -callback with that layer. Upon entering a suspend state, the PM layer iterates -through all of its registered callbacks. This currently takes place only during -APM state transitions. - -Upon going to sleep, the PCI subsystem walks its device tree twice. Both times, -it does a depth first walk of the device tree. The first walk saves each of the -device's state and checks for devices that will prevent the system from entering -a global power state. The next walk then places the devices in a low power +1. Hardware and Platform Support for PCI Power Management +2. PCI Subsystem and Device Power Management +3. PCI Device Drivers and Power Management +4. Resources + + +1. Hardware and Platform Support for PCI Power Management +========================================================= + +1.1. Native and Platform-Based Power Management +----------------------------------------------- +In general, power management is a feature allowing one to save energy by putting +devices into states in which they draw less power (low-power states) at the +price of reduced functionality or performance. + +Usually, a device is put into a low-power state when it is underutilized or +completely inactive. However, when it is necessary to use the device once +again, it has to be put back into the "fully functional" state (full-power +state). This may happen when there are some data for the device to handle or +as a result of an external event requiring the device to be active, which may +be signaled by the device itself. + +PCI devices may be put into low-power states in two ways, by using the device +capabilities introduced by the PCI Bus Power Management Interface Specification, +or with the help of platform firmware, such as an ACPI BIOS. In the first +approach, that is referred to as the native PCI power management (native PCI PM) +in what follows, the device power state is changed as a result of writing a +specific value into one of its standard configuration registers. The second +approach requires the platform firmware to provide special methods that may be +used by the kernel to change the device's power state. + +Devices supporting the native PCI PM usually can generate wakeup signals called +Power Management Events (PMEs) to let the kernel know about external events +requiring the device to be active. After receiving a PME the kernel is supposed +to put the device that sent it into the full-power state. However, the PCI Bus +Power Management Interface Specification doesn't define any standard method of +delivering the PME from the device to the CPU and the operating system kernel. +It is assumed that the platform firmware will perform this task and therefore, +even though a PCI device is set up to generate PMEs, it also may be necessary to +prepare the platform firmware for notifying the CPU of the PMEs coming from the +device (e.g. by generating interrupts). + +In turn, if the methods provided by the platform firmware are used for changing +the power state of a device, usually the platform also provides a method for +preparing the device to generate wakeup signals. In that case, however, it +often also is necessary to prepare the device for generating PMEs using the +native PCI PM mechanism, because the method provided by the platform depends on +that. + +Thus in many situations both the native and the platform-based power management +mechanisms have to be used simultaneously to obtain the desired result. + +1.2. Native PCI Power Management +-------------------------------- +The PCI Bus Power Management Interface Specification (PCI PM Spec) was +introduced between the PCI 2.1 and PCI 2.2 Specifications. It defined a +standard interface for performing various operations related to power +management. + +The implementation of the PCI PM Spec is optional for conventional PCI devices, +but it is mandatory for PCI Express devices. If a device supports the PCI PM +Spec, it has an 8 byte power management capability field in its PCI +configuration space. This field is used to describe and control the standard +features related to the native PCI power management. + +The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses +(B0-B3). The higher the number, the less power is drawn by the device or bus +in that state. However, the higher the number, the longer the latency for +the device or bus to return to the full-power state (D0 or B0, respectively). + +There are two variants of the D3 state defined by the specification. The first +one is D3hot, referred to as the software accessible D3, because devices can be +programmed to go into it. The second one, D3cold, is the state that PCI devices +are in when the supply voltage (Vcc) is removed from them. It is not possible +to program a PCI device to go into D3cold, although there may be a programmable +interface for putting the bus the device is on into a state in which Vcc is +removed from all devices on the bus. + +PCI bus power management, however, is not supported by the Linux kernel at the +time of this writing and therefore it is not covered by this document. + +Note that every PCI device can be in the full-power state (D0) or in D3cold, +regardless of whether or not it implements the PCI PM Spec. In addition to +that, if the PCI PM Spec is implemented by the device, it must support D3hot +as well as D0. The support for the D1 and D2 power states is optional. + +PCI devices supporting the PCI PM Spec can be programmed to go to any of the +supported low-power states (except for D3cold). While in D1-D3hot the +standard configuration registers of the device must be accessible to software +(i.e. the device is required to respond to PCI configuration accesses), although +its I/O and memory spaces are then disabled. This allows the device to be +programmatically put into D0. Thus the kernel can switch the device back and +forth between D0 and the supported low-power states (except for D3cold) and the +possible power state transitions the device can undergo are the following: + ++----------------------------+ +| Current State | New State | ++----------------------------+ +| D0 | D1, D2, D3 | ++----------------------------+ +| D1 | D2, D3 | ++----------------------------+ +| D2 | D3 | ++----------------------------+ +| D1, D2, D3 | D0 | ++----------------------------+ + +The transition from D3cold to D0 occurs when the supply voltage is provided to +the device (i.e. power is restored). In that case the device returns to D0 with +a full power-on reset sequence and the power-on defaults are restored to the +device by hardware just as at initial power up. + +PCI devices supporting the PCI PM Spec can be programmed to generate PMEs +while in a low-power state (D1-D3), but they are not required to be capable +of generating PMEs from all supported low-power states. In particular, the +capability of generating PMEs from D3cold is optional and depends on the +presence of additional voltage (3.3Vaux) allowing the device to remain +sufficiently active to generate a wakeup signal. + +1.3. ACPI Device Power Management +--------------------------------- +The platform firmware support for the power management of PCI devices is +system-specific. However, if the system in question is compliant with the +Advanced Configuration and Power Interface (ACPI) Specification, like the +majority of x86-based systems, it is supposed to implement device power +management interfaces defined by the ACPI standard. + +For this purpose the ACPI BIOS provides special functions called "control +methods" that may be executed by the kernel to perform specific tasks, such as +putting a device into a low-power state. These control methods are encoded +using special byte-code language called the ACPI Machine Language (AML) and +stored in the machine's BIOS. The kernel loads them from the BIOS and executes +them as needed using an AML interpreter that translates the AML byte code into +computations and memory or I/O space accesses. This way, in theory, a BIOS +writer can provide the kernel with a means to perform actions depending +on the system design in a system-specific fashion. + +ACPI control methods may be divided into global control methods, that are not +associated with any particular devices, and device control methods, that have +to be defined separately for each device supposed to be handled with the help of +the platform. This means, in particular, that ACPI device control methods can +only be used to handle devices that the BIOS writer knew about in advance. The +ACPI methods used for device power management fall into that category. + +The ACPI specification assumes that devices can be in one of four power states +labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM +D0-D3 states (although the difference between D3hot and D3cold is not taken +into account by ACPI). Moreover, for each power state of a device there is a +set of power resources that have to be enabled for the device to be put into +that state. These power resources are controlled (i.e. enabled or disabled) +with the help of their own control methods, _ON and _OFF, that have to be +defined individually for each of them. + +To put a device into the ACPI power state Dx (where x is a number between 0 and +3 inclusive) the kernel is supposed to (1) enable the power resources required +by the device in this state using their _ON control methods and (2) execute the +_PSx control method defined for the device. In addition to that, if the device +is going to be put into a low-power state (D1-D3) and is supposed to generate +wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI +3.0) control method defined for it has to be executed before _PSx. Power +resources that are not required by the device in the target power state and are +not required any more by any other device should be disabled (by executing their +_OFF control methods). If the current power state of the device is D3, it can +only be put into D0 this way. + +However, quite often the power states of devices are changed during a +system-wide transition into a sleep state or back into the working state. ACPI +defines four system sleep states, S1, S2, S3, and S4, and denotes the system +working state as S0. In general, the target system sleep (or working) state +determines the highest power (lowest number) state the device can be put +into and the kernel is supposed to obtain this information by executing the +device's _SxD control method (where x is a number between 0 and 4 inclusive). +If the device is required to wake up the system from the target sleep state, the +lowest power (highest number) state it can be put into is also determined by the +target state of the system. The kernel is then supposed to use the device's +_SxW control method to obtain the number of that state. It also is supposed to +use the device's _PRW control method to learn which power resources need to be +enabled for the device to be able to generate wakeup signals. + +1.4. Wakeup Signaling +--------------------- +Wakeup signals generated by PCI devices, either as native PCI PMEs, or as +a result of the execution of the _DSW (or _PSW) ACPI control method before +putting the device into a low-power state, have to be caught and handled as +appropriate. If they are sent while the system is in the working state +(ACPI S0), they should be translated into interrupts so that the kernel can +put the devices generating them into the full-power state and take care of the +events that triggered them. In turn, if they are sent while the system is +sleeping, they should cause the system's core logic to trigger wakeup. + +On ACPI-based systems wakeup signals sent by conventional PCI devices are +converted into ACPI General-Purpose Events (GPEs) which are hardware signals +from the system core logic generated in response to various events that need to +be acted upon. Every GPE is associated with one or more sources of potentially +interesting events. In particular, a GPE may be associated with a PCI device +capable of signaling wakeup. The information on the connections between GPEs +and event sources is recorded in the system's ACPI BIOS from where it can be +read by the kernel. + +If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE +associated with it (if there is one) is triggered. The GPEs associated with PCI +bridges may also be triggered in response to a wakeup signal from one of the +devices below the bridge (this also is the case for root bridges) and, for +example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be +handled this way. + +A GPE may be triggered when the system is sleeping (i.e. when it is in one of +the ACPI S1-S4 states), in which case system wakeup is started by its core logic +(the device that was the source of the signal causing the system wakeup to occur +may be identified later). The GPEs used in such situations are referred to as +wakeup GPEs. + +Usually, however, GPEs are also triggered when the system is in the working +state (ACPI S0) and in that case the system's core logic generates a System +Control Interrupt (SCI) to notify the kernel of the event. Then, the SCI +handler identifies the GPE that caused the interrupt to be generated which, +in turn, allows the kernel to identify the source of the event (that may be +a PCI device signaling wakeup). The GPEs used for notifying the kernel of +events occurring while the system is in the working state are referred to as +runtime GPEs. + +Unfortunately, there is no standard way of handling wakeup signals sent by +conventional PCI devices on systems that are not ACPI-based, but there is one +for PCI Express devices. Namely, the PCI Express Base Specification introduced +a native mechanism for converting native PCI PMEs into interrupts generated by +root ports. For conventional PCI devices native PMEs are out-of-band, so they +are routed separately and they need not pass through bridges (in principle they +may be routed directly to the system's core logic), but for PCI Express devices +they are in-band messages that have to pass through the PCI Express hierarchy, +including the root port on the path from the device to the Root Complex. Thus +it was possible to introduce a mechanism by which a root port generates an +interrupt whenever it receives a PME message from one of the devices below it. +The PCI Express Requester ID of the device that sent the PME message is then +recorded in one of the root port's configuration registers from where it may be +read by the interrupt handler allowing the device to be identified. [PME +messages sent by PCI Express endpoints integrated with the Root Complex don't +pass through root ports, but instead they cause a Root Complex Event Collector +(if there is one) to generate interrupts.] + +In principle the native PCI Express PME signaling may also be used on ACPI-based +systems along with the GPEs, but to use it the kernel has to ask the system's +ACPI BIOS to release control of root port configuration registers. The ACPI +BIOS, however, is not required to allow the kernel to control these registers +and if it doesn't do that, the kernel must not modify their contents. Of course +the native PCI Express PME signaling cannot be used by the kernel in that case. + + +2. PCI Subsystem and Device Power Management +============================================ + +2.1. Device Power Management Callbacks +-------------------------------------- +The PCI Subsystem participates in the power management of PCI devices in a +number of ways. First of all, it provides an intermediate code layer between +the device power management core (PM core) and PCI device drivers. +Specifically, the pm field of the PCI subsystem's struct bus_type object, +pci_bus_type, points to a struct dev_pm_ops object, pci_dev_pm_ops, containing +pointers to several device power management callbacks: + +const struct dev_pm_ops pci_dev_pm_ops = { + .prepare = pci_pm_prepare, + .complete = pci_pm_complete, + .suspend = pci_pm_suspend, + .resume = pci_pm_resume, + .freeze = pci_pm_freeze, + .thaw = pci_pm_thaw, + .poweroff = pci_pm_poweroff, + .restore = pci_pm_restore, + .suspend_noirq = pci_pm_suspend_noirq, + .resume_noirq = pci_pm_resume_noirq, + .freeze_noirq = pci_pm_freeze_noirq, + .thaw_noirq = pci_pm_thaw_noirq, + .poweroff_noirq = pci_pm_poweroff_noirq, + .restore_noirq = pci_pm_restore_noirq, + .runtime_suspend = pci_pm_runtime_suspend, + .runtime_resume = pci_pm_runtime_resume, + .runtime_idle = pci_pm_runtime_idle, +}; + +These callbacks are executed by the PM core in various situations related to +device power management and they, in turn, execute power management callbacks +provided by PCI device drivers. They also perform power management operations +involving some standard configuration registers of PCI devices that device +drivers need not know or care about. + +The structure representing a PCI device, struct pci_dev, contains several fields +that these callbacks operate on: + +struct pci_dev { + ... + pci_power_t current_state; /* Current operating state. */ + int pm_cap; /* PM capability offset in the + configuration space */ + unsigned int pme_support:5; /* Bitmask of states from which PME# + can be generated */ + unsigned int pme_interrupt:1;/* Is native PCIe PME signaling used? */ + unsigned int d1_support:1; /* Low power state D1 is supported */ + unsigned int d2_support:1; /* Low power state D2 is supported */ + unsigned int no_d1d2:1; /* D1 and D2 are forbidden */ + unsigned int wakeup_prepared:1; /* Device prepared for wake up */ + unsigned int d3_delay; /* D3->D0 transition time in ms */ + ... +}; + +They also indirectly use some fields of the struct device that is embedded in +struct pci_dev. + +2.2. Device Initialization +-------------------------- +The PCI subsystem's first task related to device power management is to +prepare the device for power management and initialize the fields of struct +pci_dev used for this purpose. This happens in two functions defined in +drivers/pci/pci.c, pci_pm_init() and platform_pci_wakeup_init(). + +The first of these functions checks if the device supports native PCI PM +and if that's the case the offset of its power management capability structure +in the configuration space is stored in the pm_cap field of the device's struct +pci_dev object. Next, the function checks which PCI low-power states are +supported by the device and from which low-power states the device can generate +native PCI PMEs. The power management fields of the device's struct pci_dev and +the struct device embedded in it are updated accordingly and the generation of +PMEs by the device is disabled. + +The second function checks if the device can be prepared to signal wakeup with +the help of the platform firmware, such as the ACPI BIOS. If that is the case, +the function updates the wakeup fields in struct device embedded in the +device's struct pci_dev and uses the firmware-provided method to prevent the +device from signaling wakeup. + +At this point the device is ready for power management. For driverless devices, +however, this functionality is limited to a few basic operations carried out +during system-wide transitions to a sleep state and back to the working state. + +2.3. Runtime Device Power Management +------------------------------------ +The PCI subsystem plays a vital role in the runtime power management of PCI +devices. For this purpose it uses the general runtime power management +(runtime PM) framework described in Documentation/power/runtime_pm.txt. +Namely, it provides subsystem-level callbacks: + + pci_pm_runtime_suspend() + pci_pm_runtime_resume() + pci_pm_runtime_idle() + +that are executed by the core runtime PM routines. It also implements the +entire mechanics necessary for handling runtime wakeup signals from PCI devices +in low-power states, which at the time of this writing works for both the native +PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in +Section 1. + +First, a PCI device is put into a low-power state, or suspended, with the help +of pm_schedule_suspend() or pm_runtime_suspend() which for PCI devices call +pci_pm_runtime_suspend() to do the actual job. For this to work, the device's +driver has to provide a pm->runtime_suspend() callback (see below), which is +run by pci_pm_runtime_suspend() as the first action. If the driver's callback +returns successfully, the device's standard configuration registers are saved, +the device is prepared to generate wakeup signals and, finally, it is put into +the target low-power state. + +The low-power state to put the device into is the lowest-power (highest number) +state from which it can signal wakeup. The exact method of signaling wakeup is +system-dependent and is determined by the PCI subsystem on the basis of the +reported capabilities of the device and the platform firmware. To prepare the +device for signaling wakeup and put it into the selected low-power state, the +PCI subsystem can use the platform firmware as well as the device's native PCI +PM capabilities, if supported. + +It is expected that the device driver's pm->runtime_suspend() callback will +not attempt to prepare the device for signaling wakeup or to put it into a +low-power state. The driver ought to leave these tasks to the PCI subsystem +that has all of the information necessary to perform them. + +A suspended device is brought back into the "active" state, or resumed, +with the help of pm_request_resume() or pm_runtime_resume() which both call +pci_pm_runtime_resume() for PCI devices. Again, this only works if the device's +driver provides a pm->runtime_resume() callback (see below). However, before +the driver's callback is executed, pci_pm_runtime_resume() brings the device +back into the full-power state, prevents it from signaling wakeup while in that +state and restores its standard configuration registers. Thus the driver's +callback need not worry about the PCI-specific aspects of the device resume. + +Note that generally pci_pm_runtime_resume() may be called in two different +situations. First, it may be called at the request of the device's driver, for +example if there are some data for it to process. Second, it may be called +as a result of a wakeup signal from the device itself (this sometimes is +referred to as "remote wakeup"). Of course, for this purpose the wakeup signal +is handled in one of the ways described in Section 1 and finally converted into +a notification for the PCI subsystem after the source device has been +identified. + +The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle() +and pm_request_idle(), executes the device driver's pm->runtime_idle() +callback, if defined, and if that callback doesn't return error code (or is not +present at all), suspends the device with the help of pm_runtime_suspend(). +Sometimes pci_pm_runtime_idle() is called automatically by the PM core (for +example, it is called right after the device has just been resumed), in which +cases it is expected to suspend the device if that makes sense. Usually, +however, the PCI subsystem doesn't really know if the device really can be +suspended, so it lets the device's driver decide by running its +pm->runtime_idle() callback. + +2.4. System-Wide Power Transitions +---------------------------------- +There are a few different types of system-wide power transitions, described in +Documentation/power/devices.txt. Each of them requires devices to be handled +in a specific way and the PM core executes subsystem-level power management +callbacks for this purpose. They are executed in phases such that each phase +involves executing the same subsystem-level callback for every device belonging +to the given subsystem before the next phase begins. These phases always run +after tasks have been frozen. + +2.4.1. System Suspend + +When the system is going into a sleep state in which the contents of memory will +be preserved, such as one of the ACPI sleep states S1-S3, the phases are: + + prepare, suspend, suspend_noirq. + +The following PCI bus type's callbacks, respectively, are used in these phases: + + pci_pm_prepare() + pci_pm_suspend() + pci_pm_suspend_noirq() + +The pci_pm_prepare() routine first puts the device into the "fully functional" +state with the help of pm_runtime_resume(). Then, it executes the device +driver's pm->prepare() callback if defined (i.e. if the driver's struct +dev_pm_ops object is present and the prepare pointer in that object is valid). + +The pci_pm_suspend() routine first checks if the device's driver implements +legacy PCI suspend routines (see Section 3), in which case the driver's legacy +suspend callback is executed, if present, and its result is returned. Next, if +the device's driver doesn't provide a struct dev_pm_ops object (containing +pointers to the driver's callbacks), pci_pm_default_suspend() is called, which +simply turns off the device's bus master capability and runs +pcibios_disable_device() to disable it, unless the device is a bridge (PCI +bridges are ignored by this routine). Next, the device driver's pm->suspend() +callback is executed, if defined, and its result is returned if it fails. +Finally, pci_fixup_device() is called to apply hardware suspend quirks related +to the device if necessary. + +Note that the suspend phase is carried out asynchronously for PCI devices, so +the pci_pm_suspend() callback may be executed in parallel for any pair of PCI +devices that don't depend on each other in a known way (i.e. none of the paths +in the device tree from the root bridge to a leaf device contains both of them). + +The pci_pm_suspend_noirq() routine is executed after suspend_device_irqs() has +been called, which means that the device driver's interrupt handler won't be +invoked while this routine is running. It first checks if the device's driver +implements legacy PCI suspends routines (Section 3), in which case the legacy +late suspend routine is called and its result is returned (the standard +configuration registers of the device are saved if the driver's callback hasn't +done that). Second, if the device driver's struct dev_pm_ops object is not +present, the device's standard configuration registers are saved and the routine +returns success. Otherwise the device driver's pm->suspend_noirq() callback is +executed, if present, and its result is returned if it fails. Next, if the +device's standard configuration registers haven't been saved yet (one of the +device driver's callbacks executed before might do that), pci_pm_suspend_noirq() +saves them, prepares the device to signal wakeup (if necessary) and puts it into +a low-power state. + +The low-power state to put the device into is the lowest-power (highest number) +state from which it can signal wakeup while the system is in the target sleep +state. Just like in the runtime PM case described above, the mechanism of +signaling wakeup is system-dependent and determined by the PCI subsystem, which +is also responsible for preparing the device to signal wakeup from the system's +target sleep state as appropriate. + +PCI device drivers (that don't implement legacy power management callbacks) are +generally not expected to prepare devices for signaling wakeup or to put them +into low-power states. However, if one of the driver's suspend callbacks +(pm->suspend() or pm->suspend_noirq()) saves the device's standard configuration +registers, pci_pm_suspend_noirq() will assume that the device has been prepared +to signal wakeup and put into a low-power state by the driver (the driver is +then assumed to have used the helper functions provided by the PCI subsystem for +this purpose). PCI device drivers are not encouraged to do that, but in some +rare cases doing that in the driver may be the optimum approach. + +2.4.2. System Resume + +When the system is undergoing a transition from a sleep state in which the +contents of memory have been preserved, such as one of the ACPI sleep states +S1-S3, into the working state (ACPI S0), the phases are: + + resume_noirq, resume, complete. + +The following PCI bus type's callbacks, respectively, are executed in these +phases: + + pci_pm_resume_noirq() + pci_pm_resume() + pci_pm_complete() + +The pci_pm_resume_noirq() routine first puts the device into the full-power +state, restores its standard configuration registers and applies early resume +hardware quirks related to the device, if necessary. This is done +unconditionally, regardless of whether or not the device's driver implements +legacy PCI power management callbacks (this way all PCI devices are in the +full-power state and their standard configuration registers have been restored +when their interrupt handlers are invoked for the first time during resume, +which allows the kernel to avoid problems with the handling of shared interrupts +by drivers whose devices are still suspended). If legacy PCI power management +callbacks (see Section 3) are implemented by the device's driver, the legacy +early resume callback is executed and its result is returned. Otherwise, the +device driver's pm->resume_noirq() callback is executed, if defined, and its +result is returned. + +The pci_pm_resume() routine first checks if the device's standard configuration +registers have been restored and restores them if that's not the case (this +only is necessary in the error path during a failing suspend). Next, resume +hardware quirks related to the device are applied, if necessary, and if the +device's driver implements legacy PCI power management callbacks (see +Section 3), the driver's legacy resume callback is executed and its result is +returned. Otherwise, the device's wakeup signaling mechanisms are blocked and +its driver's pm->resume() callback is executed, if defined (the callback's +result is then returned). + +The resume phase is carried out asynchronously for PCI devices, like the +suspend phase described above, which means that if two PCI devices don't depend +on each other in a known way, the pci_pm_resume() routine may be executed for +the both of them in parallel. + +The pci_pm_complete() routine only executes the device driver's pm->complete() +callback, if defined. + +2.4.3. System Hibernation + +System hibernation is more complicated than system suspend, because it requires +a system image to be created and written into a persistent storage medium. The +image is created atomically and all devices are quiesced, or frozen, before that +happens. + +The freezing of devices is carried out after enough memory has been freed (at +the time of this writing the image creation requires at least 50% of system RAM +to be free) in the following three phases: + + prepare, freeze, freeze_noirq + +that correspond to the PCI bus type's callbacks: + + pci_pm_prepare() + pci_pm_freeze() + pci_pm_freeze_noirq() + +This means that the prepare phase is exactly the same as for system suspend. +The other two phases, however, are different. + +The pci_pm_freeze() routine is quite similar to pci_pm_suspend(), but it runs +the device driver's pm->freeze() callback, if defined, instead of pm->suspend(), +and it doesn't apply the suspend-related hardware quirks. It is executed +asynchronously for different PCI devices that don't depend on each other in a +known way. + +The pci_pm_freeze_noirq() routine, in turn, is similar to +pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq() +routine instead of pm->suspend_noirq(). It also doesn't attempt to prepare the +device for signaling wakeup and put it into a low-power state. Still, it saves +the device's standard configuration registers if they haven't been saved by one +of the driver's callbacks. + +Once the image has been created, it has to be saved. However, at this point all +devices are frozen and they cannot handle I/O, while their ability to handle +I/O is obviously necessary for the image saving. Thus they have to be brought +back to the fully functional state and this is done in the following phases: + + thaw_noirq, thaw, complete + +using the following PCI bus type's callbacks: + + pci_pm_thaw_noirq() + pci_pm_thaw() + pci_pm_complete() + +respectively. + +The first of them, pci_pm_thaw_noirq(), is analogous to pci_pm_resume_noirq(), +but it doesn't put the device into the full power state and doesn't attempt to +restore its standard configuration registers. It also executes the device +driver's pm->thaw_noirq() callback, if defined, instead of pm->resume_noirq(). + +The pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device +driver's pm->thaw() callback instead of pm->resume(). It is executed +asynchronously for different PCI devices that don't depend on each other in a +known way. + +The complete phase it the same as for system resume. + +After saving the image, devices need to be powered down before the system can +enter the target sleep state (ACPI S4 for ACPI-based systems). This is done in +three phases: + + prepare, poweroff, poweroff_noirq + +where the prepare phase is exactly the same as for system suspend. The other +two phases are analogous to the suspend and suspend_noirq phases, respectively. +The PCI subsystem-level callbacks they correspond to + + pci_pm_poweroff() + pci_pm_poweroff_noirq() + +work in analogy with pci_pm_suspend() and pci_pm_poweroff_noirq(), respectively, +although they don't attempt to save the device's standard configuration +registers. + +2.4.4. System Restore + +System restore requires a hibernation image to be loaded into memory and the +pre-hibernation memory contents to be restored before the pre-hibernation system +activity can be resumed. + +As described in Documentation/power/devices.txt, the hibernation image is loaded +into memory by a fresh instance of the kernel, called the boot kernel, which in +turn is loaded and run by a boot loader in the usual way. After the boot kernel +has loaded the image, it needs to replace its own code and data with the code +and data of the "hibernated" kernel stored within the image, called the image +kernel. For this purpose all devices are frozen just like before creating +the image during hibernation, in the + + prepare, freeze, freeze_noirq + +phases described above. However, the devices affected by these phases are only +those having drivers in the boot kernel; other devices will still be in whatever +state the boot loader left them. + +Should the restoration of the pre-hibernation memory contents fail, the boot +kernel would go through the "thawing" procedure described above, using the +thaw_noirq, thaw, and complete phases (that will only affect the devices having +drivers in the boot kernel), and then continue running normally. + +If the pre-hibernation memory contents are restored successfully, which is the +usual situation, control is passed to the image kernel, which then becomes +responsible for bringing the system back to the working state. To achieve this, +it must restore the devices' pre-hibernation functionality, which is done much +like waking up from the memory sleep state, although it involves different +phases: + + restore_noirq, restore, complete + +The first two of these are analogous to the resume_noirq and resume phases +described above, respectively, and correspond to the following PCI subsystem +callbacks: + + pci_pm_restore_noirq() + pci_pm_restore() + +These callbacks work in analogy with pci_pm_resume_noirq() and pci_pm_resume(), +respectively, but they execute the device driver's pm->restore_noirq() and +pm->restore() callbacks, if available. + +The complete phase is carried out in exactly the same way as during system +resume. + + +3. PCI Device Drivers and Power Management +========================================== + +3.1. Power Management Callbacks +------------------------------- +PCI device drivers participate in power management by providing callbacks to be +executed by the PCI subsystem's power management routines described above and by +controlling the runtime power management of their devices. + +At the time of this writing there are two ways to define power management +callbacks for a PCI device driver, the recommended one, based on using a +dev_pm_ops structure described in Documentation/power/devices.txt, and the +"legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and +.resume() callbacks from struct pci_driver are used. The legacy approach, +however, doesn't allow one to define runtime power management callbacks and is +not really suitable for any new drivers. Therefore it is not covered by this +document (refer to the source code to learn more about it). + +It is recommended that all PCI device drivers define a struct dev_pm_ops object +containing pointers to power management (PM) callbacks that will be executed by +the PCI subsystem's PM routines in various circumstances. A pointer to the +driver's struct dev_pm_ops object has to be assigned to the driver.pm field in +its struct pci_driver object. Once that has happened, the "legacy" PM callbacks +in struct pci_driver are ignored (even if they are not NULL). + +The PM callbacks in struct dev_pm_ops are not mandatory and if they are not +defined (i.e. the respective fields of struct dev_pm_ops are unset) the PCI +subsystem will handle the device in a simplified default manner. If they are +defined, though, they are expected to behave as described in the following +subsections. + +3.1.1. prepare() + +The prepare() callback is executed during system suspend, during hibernation +(when a hibernation image is about to be created), during power-off after +saving a hibernation image and during system restore, when a hibernation image +has just been loaded into memory. + +This callback is only necessary if the driver's device has children that in +general may be registered at any time. In that case the role of the prepare() +callback is to prevent new children of the device from being registered until +one of the resume_noirq(), thaw_noirq(), or restore_noirq() callbacks is run. + +In addition to that the prepare() callback may carry out some operations +preparing the device to be suspended, although it should not allocate memory +(if additional memory is required to suspend the device, it has to be +preallocated earlier, for example in a suspend/hibernate notifier as described +in Documentation/power/notifiers.txt). + +3.1.2. suspend() + +The suspend() callback is only executed during system suspend, after prepare() +callbacks have been executed for all devices in the system. + +This callback is expected to quiesce the device and prepare it to be put into a +low-power state by the PCI subsystem. It is not required (in fact it even is +not recommended) that a PCI driver's suspend() callback save the standard +configuration registers of the device, prepare it for waking up the system, or +put it into a low-power state. All of these operations can very well be taken +care of by the PCI subsystem, without the driver's participation. + +However, in some rare case it is convenient to carry out these operations in +a PCI driver. Then, pci_save_state(), pci_prepare_to_sleep(), and +pci_set_power_state() should be used to save the device's standard configuration +registers, to prepare it for system wakeup (if necessary), and to put it into a +low-power state, respectively. Moreover, if the driver calls pci_save_state(), +the PCI subsystem will not execute either pci_prepare_to_sleep(), or +pci_set_power_state() for its device, so the driver is then responsible for +handling the device as appropriate. + +While the suspend() callback is being executed, the driver's interrupt handler +can be invoked to handle an interrupt from the device, so all suspend-related +operations relying on the driver's ability to handle interrupts should be +carried out in this callback. + +3.1.3. suspend_noirq() + +The suspend_noirq() callback is only executed during system suspend, after +suspend() callbacks have been executed for all devices in the system and +after device interrupts have been disabled by the PM core. + +The difference between suspend_noirq() and suspend() is that the driver's +interrupt handler will not be invoked while suspend_noirq() is running. Thus +suspend_noirq() can carry out operations that would cause race conditions to +arise if they were performed in suspend(). + +3.1.4. freeze() + +The freeze() callback is hibernation-specific and is executed in two situations, +during hibernation, after prepare() callbacks have been executed for all devices +in preparation for the creation of a system image, and during restore, +after a system image has been loaded into memory from persistent storage and the +prepare() callbacks have been executed for all devices. + +The role of this callback is analogous to the role of the suspend() callback +described above. In fact, they only need to be different in the rare cases when +the driver takes the responsibility for putting the device into a low-power state. -The first walk allows a graceful recovery in the event of a failure, since none -of the devices have actually been powered down. - -In both walks, in particular the second, all children of a bridge are touched -before the actual bridge itself. This allows the bridge to retain power while -its children are being accessed. - -Upon resuming from sleep, just the opposite must be true: all bridges must be -powered on and restored before their children are powered on. This is easily -accomplished with a breadth-first walk of the PCI device tree. - - -3. PCI Utility Functions -~~~~~~~~~~~~~~~~~~~~~~~~ - -These are helper functions designed to be called by individual device drivers. -Assuming that a device behaves as advertised, these should be applicable in most -cases. However, results may vary. - -Note that these functions are never implicitly called for the driver. The driver -is always responsible for deciding when and if to call these. - - -pci_save_state --------------- - -Usage: - pci_save_state(struct pci_dev *dev); - -Description: - Save first 64 bytes of PCI config space, along with any additional - PCI-Express or PCI-X information. - - -pci_restore_state ------------------ - -Usage: - pci_restore_state(struct pci_dev *dev); - -Description: - Restore previously saved config space. - - -pci_set_power_state -------------------- - -Usage: - pci_set_power_state(struct pci_dev *dev, pci_power_t state); - -Description: - Transition device to low power state using PCI PM Capabilities - registers. - - Will fail under one of the following conditions: - - If state is less than current state, but not D0 (illegal transition) - - Device doesn't support PM Capabilities - - Device does not support requested state - - -pci_enable_wake ---------------- - -Usage: - pci_enable_wake(struct pci_dev *dev, pci_power_t state, int enable); - -Description: - Enable device to generate PME# during low power state using PCI PM - Capabilities. - - Checks whether if device supports generating PME# from requested state - and fail if it does not, unless enable == 0 (request is to disable wake - events, which is implicit if it doesn't even support it in the first - place). - - Note that the PMC Register in the device's PM Capabilities has a bitmask - of the states it supports generating PME# from. D3hot is bit 3 and - D3cold is bit 4. So, while a value of 4 as the state may not seem - semantically correct, it is. - - -4. PCI Device Drivers -~~~~~~~~~~~~~~~~~~~~~ - -These functions are intended for use by individual drivers, and are defined in -struct pci_driver: - - int (*suspend) (struct pci_dev *dev, pm_message_t state); - int (*resume) (struct pci_dev *dev); - - -suspend -------- - -Usage: - -if (dev->driver && dev->driver->suspend) - dev->driver->suspend(dev,state); - -A driver uses this function to actually transition the device into a low power -state. This should include disabling I/O, IRQs, and bus-mastering, as well as -physically transitioning the device to a lower power state; it may also include -calls to pci_enable_wake(). - -Bus mastering may be disabled by doing: - -pci_disable_device(dev); - -For devices that support the PCI PM Spec, this may be used to set the device's -power state to match the suspend() parameter: - -pci_set_power_state(dev,state); - -The driver is also responsible for disabling any other device-specific features -(e.g blanking screen, turning off on-card memory, etc). - -The driver should be sure to track the current state of the device, as it may -obviate the need for some operations. - -The driver should update the current_state field in its pci_dev structure in -this function, except for PM-capable devices when pci_set_power_state is used. - -resume ------- - -Usage: - -if (dev->driver && dev->driver->resume) - dev->driver->resume(dev) +In that cases the freeze() callback should not prepare the device system wakeup +or put it into a low-power state. Still, either it or freeze_noirq() should +save the device's standard configuration registers using pci_save_state(). -The resume callback may be called from any power state, and is always meant to -transition the device to the D0 state. +3.1.5. freeze_noirq() -The driver is responsible for reenabling any features of the device that had -been disabled during previous suspend calls, such as IRQs and bus mastering, -as well as calling pci_restore_state(). +The freeze_noirq() callback is hibernation-specific. It is executed during +hibernation, after prepare() and freeze() callbacks have been executed for all +devices in preparation for the creation of a system image, and during restore, +after a system image has been loaded into memory and after prepare() and +freeze() callbacks have been executed for all devices. It is always executed +after device interrupts have been disabled by the PM core. -If the device is currently in D3, it may need to be reinitialized in resume(). +The role of this callback is analogous to the role of the suspend_noirq() +callback described above and it very rarely is necessary to define +freeze_noirq(). - * Some types of devices, like bus controllers, will preserve context in D3hot - (using Vcc power). Their drivers will often want to avoid re-initializing - them after re-entering D0 (perhaps to avoid resetting downstream devices). +The difference between freeze_noirq() and freeze() is analogous to the +difference between suspend_noirq() and suspend(). - * Other kinds of devices in D3hot will discard device context as part of a - soft reset when re-entering the D0 state. - - * Devices resuming from D3cold always go through a power-on reset. Some - device context can also be preserved using Vaux power. +3.1.6. poweroff() - * Some systems hide D3cold resume paths from drivers. For example, on PCs - the resume path for suspend-to-disk often runs BIOS powerup code, which - will sometimes re-initialize the device. +The poweroff() callback is hibernation-specific. It is executed when the system +is about to be powered off after saving a hibernation image to a persistent +storage. prepare() callbacks are executed for all devices before poweroff() is +called. -To handle resets during D3 to D0 transitions, it may be convenient to share -device initialization code between probe() and resume(). Device parameters -can also be saved before the driver suspends into D3, avoiding re-probe. +The role of this callback is analogous to the role of the suspend() and freeze() +callbacks described above, although it does not need to save the contents of +the device's registers. In particular, if the driver wants to put the device +into a low-power state itself instead of allowing the PCI subsystem to do that, +the poweroff() callback should use pci_prepare_to_sleep() and +pci_set_power_state() to prepare the device for system wakeup and to put it +into a low-power state, respectively, but it need not save the device's standard +configuration registers. -If the device supports the PCI PM Spec, it can use this to physically transition -the device to D0: +3.1.7. poweroff_noirq() -pci_set_power_state(dev,0); +The poweroff_noirq() callback is hibernation-specific. It is executed after +poweroff() callbacks have been executed for all devices in the system. -Note that if the entire system is transitioning out of a global sleep state, all -devices will be placed in the D0 state, so this is not necessary. However, in -the event that the device is placed in the D3 state during normal operation, -this call is necessary. It is impossible to determine which of the two events is -taking place in the driver, so it is always a good idea to make that call. +The role of this callback is analogous to the role of the suspend_noirq() and +freeze_noirq() callbacks described above, but it does not need to save the +contents of the device's registers. -The driver should take note of the state that it is resuming from in order to -ensure correct (and speedy) operation. +The difference between poweroff_noirq() and poweroff() is analogous to the +difference between suspend_noirq() and suspend(). -The driver should update the current_state field in its pci_dev structure in -this function, except for PM-capable devices when pci_set_power_state is used. +3.1.8. resume_noirq() +The resume_noirq() callback is only executed during system resume, after the +PM core has enabled the non-boot CPUs. The driver's interrupt handler will not +be invoked while resume_noirq() is running, so this callback can carry out +operations that might race with the interrupt handler. +Since the PCI subsystem unconditionally puts all devices into the full power +state in the resume_noirq phase of system resume and restores their standard +configuration registers, resume_noirq() is usually not necessary. In general +it should only be used for performing operations that would lead to race +conditions if carried out by resume(). -A reference implementation -------------------------- -.suspend() -{ - /* driver specific operations */ +3.1.9. resume() - /* Disable IRQ */ - free_irq(); - /* If using MSI */ - pci_disable_msi(); +The resume() callback is only executed during system resume, after +resume_noirq() callbacks have been executed for all devices in the system and +device interrupts have been enabled by the PM core. - pci_save_state(); - pci_enable_wake(); - /* Disable IO/bus master/irq router */ - pci_disable_device(); - pci_set_power_state(pci_choose_state()); -} +This callback is responsible for restoring the pre-suspend configuration of the +device and bringing it back to the fully functional state. The device should be +able to process I/O in a usual way after resume() has returned. -.resume() -{ - pci_set_power_state(PCI_D0); - pci_restore_state(); - /* device's irq possibly is changed, driver should take care */ - pci_enable_device(); - pci_set_master(); +3.1.10. thaw_noirq() - /* if using MSI, device's vector possibly is changed */ - pci_enable_msi(); +The thaw_noirq() callback is hibernation-specific. It is executed after a +system image has been created and the non-boot CPUs have been enabled by the PM +core, in the thaw_noirq phase of hibernation. It also may be executed if the +loading of a hibernation image fails during system restore (it is then executed +after enabling the non-boot CPUs). The driver's interrupt handler will not be +invoked while thaw_noirq() is running. - request_irq(); - /* driver specific operations; */ -} +The role of this callback is analogous to the role of resume_noirq(). The +difference between these two callbacks is that thaw_noirq() is executed after +freeze() and freeze_noirq(), so in general it does not need to modify the +contents of the device's registers. -This is a typical implementation. Drivers can slightly change the order -of the operations in the implementation, ignore some operations or add -more driver specific operations in it, but drivers should do something like -this on the whole. +3.1.11. thaw() -5. Resources -~~~~~~~~~~~~ +The thaw() callback is hibernation-specific. It is executed after thaw_noirq() +callbacks have been executed for all devices in the system and after device +interrupts have been enabled by the PM core. -PCI Local Bus Specification -PCI Bus Power Management Interface Specification +This callback is responsible for restoring the pre-freeze configuration of +the device, so that it will work in a usual way after thaw() has returned. - http://www.pcisig.com +3.1.12. restore_noirq() +The restore_noirq() callback is hibernation-specific. It is executed in the +restore_noirq phase of hibernation, when the boot kernel has passed control to +the image kernel and the non-boot CPUs have been enabled by the image kernel's +PM core. + +This callback is analogous to resume_noirq() with the exception that it cannot +make any assumption on the previous state of the device, even if the BIOS (or +generally the platform firmware) is known to preserve that state over a +suspend-resume cycle. + +For the vast majority of PCI device drivers there is no difference between +resume_noirq() and restore_noirq(). + +3.1.13. restore() + +The restore() callback is hibernation-specific. It is executed after +restore_noirq() callbacks have been executed for all devices in the system and +after the PM core has enabled device drivers' interrupt handlers to be invoked. + +This callback is analogous to resume(), just like restore_noirq() is analogous +to resume_noirq(). Consequently, the difference between restore_noirq() and +restore() is analogous to the difference between resume_noirq() and resume(). + +For the vast majority of PCI device drivers there is no difference between +resume() and restore(). + +3.1.14. complete() + +The complete() callback is executed in the following situations: + - during system resume, after resume() callbacks have been executed for all + devices, + - during hibernation, before saving the system image, after thaw() callbacks + have been executed for all devices, + - during system restore, when the system is going back to its pre-hibernation + state, after restore() callbacks have been executed for all devices. +It also may be executed if the loading of a hibernation image into memory fails +(in that case it is run after thaw() callbacks have been executed for all +devices that have drivers in the boot kernel). + +This callback is entirely optional, although it may be necessary if the +prepare() callback performs operations that need to be reversed. + +3.1.15. runtime_suspend() + +The runtime_suspend() callback is specific to device runtime power management +(runtime PM). It is executed by the PM core's runtime PM framework when the +device is about to be suspended (i.e. quiesced and put into a low-power state) +at run time. + +This callback is responsible for freezing the device and preparing it to be +put into a low-power state, but it must allow the PCI subsystem to perform all +of the PCI-specific actions necessary for suspending the device. + +3.1.16. runtime_resume() + +The runtime_resume() callback is specific to device runtime PM. It is executed +by the PM core's runtime PM framework when the device is about to be resumed +(i.e. put into the full-power state and programmed to process I/O normally) at +run time. + +This callback is responsible for restoring the normal functionality of the +device after it has been put into the full-power state by the PCI subsystem. +The device is expected to be able to process I/O in the usual way after +runtime_resume() has returned. + +3.1.17. runtime_idle() + +The runtime_idle() callback is specific to device runtime PM. It is executed +by the PM core's runtime PM framework whenever it may be desirable to suspend +the device according to the PM core's information. In particular, it is +automatically executed right after runtime_resume() has returned in case the +resume of the device has happened as a result of a spurious event. + +This callback is optional, but if it is not implemented or if it returns 0, the +PCI subsystem will call pm_runtime_suspend() for the device, which in turn will +cause the driver's runtime_suspend() callback to be executed. + +3.1.18. Pointing Multiple Callback Pointers to One Routine + +Although in principle each of the callbacks described in the previous +subsections can be defined as a separate function, it often is convenient to +point two or more members of struct dev_pm_ops to the same routine. There are +a few convenience macros that can be used for this purpose. + +The SIMPLE_DEV_PM_OPS macro declares a struct dev_pm_ops object with one +suspend routine pointed to by the .suspend(), .freeze(), and .poweroff() +members and one resume routine pointed to by the .resume(), .thaw(), and +.restore() members. The other function pointers in this struct dev_pm_ops are +unset. + +The UNIVERSAL_DEV_PM_OPS macro is similar to SIMPLE_DEV_PM_OPS, but it +additionally sets the .runtime_resume() pointer to the same value as +.resume() (and .thaw(), and .restore()) and the .runtime_suspend() pointer to +the same value as .suspend() (and .freeze() and .poweroff()). + +The SET_SYSTEM_SLEEP_PM_OPS can be used inside of a declaration of struct +dev_pm_ops to indicate that one suspend routine is to be pointed to by the +.suspend(), .freeze(), and .poweroff() members and one resume routine is to +be pointed to by the .resume(), .thaw(), and .restore() members. + +3.2. Device Runtime Power Management +------------------------------------ +In addition to providing device power management callbacks PCI device drivers +are responsible for controlling the runtime power management (runtime PM) of +their devices. + +The PCI device runtime PM is optional, but it is recommended that PCI device +drivers implement it at least in the cases where there is a reliable way of +verifying that the device is not used (like when the network cable is detached +from an Ethernet adapter or there are no devices attached to a USB controller). + +To support the PCI runtime PM the driver first needs to implement the +runtime_suspend() and runtime_resume() callbacks. It also may need to implement +the runtime_idle() callback to prevent the device from being suspended again +every time right after the runtime_resume() callback has returned +(alternatively, the runtime_suspend() callback will have to check if the +device should really be suspended and return -EAGAIN if that is not the case). + +The runtime PM of PCI devices is disabled by default. It is also blocked by +pci_pm_init() that runs the pm_runtime_forbid() helper function. If a PCI +driver implements the runtime PM callbacks and intends to use the runtime PM +framework provided by the PM core and the PCI subsystem, it should enable this +feature by executing the pm_runtime_enable() helper function. However, the +driver should not call the pm_runtime_allow() helper function unblocking +the runtime PM of the device. Instead, it should allow user space or some +platform-specific code to do that (user space can do it via sysfs), although +once it has called pm_runtime_enable(), it must be prepared to handle the +runtime PM of the device correctly as soon as pm_runtime_allow() is called +(which may happen at any time). [It also is possible that user space causes +pm_runtime_allow() to be called via sysfs before the driver is loaded, so in +fact the driver has to be prepared to handle the runtime PM of the device as +soon as it calls pm_runtime_enable().] + +The runtime PM framework works by processing requests to suspend or resume +devices, or to check if they are idle (in which cases it is reasonable to +subsequently request that they be suspended). These requests are represented +by work items put into the power management workqueue, pm_wq. Although there +are a few situations in which power management requests are automatically +queued by the PM core (for example, after processing a request to resume a +device the PM core automatically queues a request to check if the device is +idle), device drivers are generally responsible for queuing power management +requests for their devices. For this purpose they should use the runtime PM +helper functions provided by the PM core, discussed in +Documentation/power/runtime_pm.txt. + +Devices can also be suspended and resumed synchronously, without placing a +request into pm_wq. In the majority of cases this also is done by their +drivers that use helper functions provided by the PM core for this purpose. + +For more information on the runtime PM of devices refer to +Documentation/power/runtime_pm.txt. + + +4. Resources +============ + +PCI Local Bus Specification, Rev. 3.0 +PCI Bus Power Management Interface Specification, Rev. 1.2 +Advanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b +PCI Express Base Specification, Rev. 2.0 +Documentation/power/devices.txt +Documentation/power/runtime_pm.txt diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index c40866e8b957..bfed898a03fc 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -18,44 +18,46 @@ and pm_qos_params.h. This is done because having the available parameters being runtime configurable or changeable from a driver was seen as too easy to abuse. -For each parameter a list of performance requirements is maintained along with +For each parameter a list of performance requests is maintained along with an aggregated target value. The aggregated target value is updated with -changes to the requirement list or elements of the list. Typically the -aggregated target value is simply the max or min of the requirement values held +changes to the request list or elements of the list. Typically the +aggregated target value is simply the max or min of the request values held in the parameter list elements. From kernel mode the use of this interface is simple: -pm_qos_add_requirement(param_id, name, target_value): -Will insert a named element in the list for that identified PM_QOS parameter -with the target value. Upon change to this list the new target is recomputed -and any registered notifiers are called only if the target value is now -different. -pm_qos_update_requirement(param_id, name, new_target_value): -Will search the list identified by the param_id for the named list element and -then update its target value, calling the notification tree if the aggregated -target is changed. with that name is already registered. +handle = pm_qos_add_request(param_class, target_value): +Will insert an element into the list for that identified PM_QOS class with the +target value. Upon change to this list the new target is recomputed and any +registered notifiers are called only if the target value is now different. +Clients of pm_qos need to save the returned handle. -pm_qos_remove_requirement(param_id, name): -Will search the identified list for the named element and remove it, after -removal it will update the aggregate target and call the notification tree if -the target was changed as a result of removing the named requirement. +void pm_qos_update_request(handle, new_target_value): +Will update the list element pointed to by the handle with the new target value +and recompute the new aggregated target, calling the notification tree if the +target is changed. + +void pm_qos_remove_request(handle): +Will remove the element. After removal it will update the aggregate target and +call the notification tree if the target was changed as a result of removing +the request. From user mode: -Only processes can register a pm_qos requirement. To provide for automatic -cleanup for process the interface requires the process to register its -parameter requirements in the following way: +Only processes can register a pm_qos request. To provide for automatic +cleanup of a process, the interface requires the process to register its +parameter requests in the following way: To register the default pm_qos target for the specific parameter, the process must open one of /dev/[cpu_dma_latency, network_latency, network_throughput] As long as the device node is held open that process has a registered -requirement on the parameter. The name of the requirement is "process_<PID>" -derived from the current->pid from within the open system call. +request on the parameter. -To change the requested target value the process needs to write a s32 value to -the open device node. This translates to a pm_qos_update_requirement call. +To change the requested target value the process needs to write an s32 value to +the open device node. Alternatively the user mode program could write a hex +string for the value using 10 char long format e.g. "0x12345678". This +translates to a pm_qos_update_request call. To remove the user mode request for a target value simply close the device node. diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt index cdebb5145c25..55c4175d8099 100644 --- a/Documentation/power/regulator/consumer.txt +++ b/Documentation/power/regulator/consumer.txt @@ -8,11 +8,11 @@ Please see overview.txt for a description of the terms used in this text. 1. Consumer Regulator Access (static & dynamic drivers) ======================================================= -A consumer driver can get access to it's supply regulator by calling :- +A consumer driver can get access to its supply regulator by calling :- regulator = regulator_get(dev, "Vcc"); -The consumer passes in it's struct device pointer and power supply ID. The core +The consumer passes in its struct device pointer and power supply ID. The core then finds the correct regulator by consulting a machine specific lookup table. If the lookup is successful then this call will return a pointer to the struct regulator that supplies this consumer. @@ -34,7 +34,7 @@ usually be called in your device drivers probe() and remove() respectively. 2. Regulator Output Enable & Disable (static & dynamic drivers) ==================================================================== -A consumer can enable it's power supply by calling:- +A consumer can enable its power supply by calling:- int regulator_enable(regulator); @@ -49,7 +49,7 @@ int regulator_is_enabled(regulator); This will return > zero when the regulator is enabled. -A consumer can disable it's supply when no longer needed by calling :- +A consumer can disable its supply when no longer needed by calling :- int regulator_disable(regulator); @@ -140,7 +140,7 @@ by calling :- int regulator_set_optimum_mode(struct regulator *regulator, int load_uA); This will cause the core to recalculate the total load on the regulator (based -on all it's consumers) and change operating mode (if necessary and permitted) +on all its consumers) and change operating mode (if necessary and permitted) to best match the current operating load. The load_uA value can be determined from the consumers datasheet. e.g.most diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index 63728fed620b..bdec39b9bd75 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -52,7 +52,7 @@ static struct regulator_init_data regulator1_data = { }; Regulator-1 supplies power to Regulator-2. This relationship must be registered -with the core so that Regulator-1 is also enabled when Consumer A enables it's +with the core so that Regulator-1 is also enabled when Consumer A enables its supply (Regulator-2). The supply regulator is set by the supply_regulator_dev field below:- diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt index ffd185bb6054..9363e056188a 100644 --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -35,16 +35,16 @@ Some terms used in this document:- o Consumer - Electronic device that is supplied power by a regulator. Consumers can be classified into two types:- - Static: consumer does not change it's supply voltage or + Static: consumer does not change its supply voltage or current limit. It only needs to enable or disable it's - power supply. It's supply voltage is set by the hardware, + power supply. Its supply voltage is set by the hardware, bootloader, firmware or kernel board initialisation code. Dynamic: consumer needs to change it's supply voltage or current limit to meet operation demands. - o Power Domain - Electronic circuit that is supplied it's input power by the + o Power Domain - Electronic circuit that is supplied its input power by the output power of a regulator, switch or by another power domain. diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 356fd86f4ea8..55b859b3bc72 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -224,6 +224,12 @@ defined in include/linux/pm.h: RPM_SUSPENDED, which means that each device is initially regarded by the PM core as 'suspended', regardless of its real hardware status + unsigned int runtime_auto; + - if set, indicates that the user space has allowed the device driver to + power manage the device at run time via the /sys/devices/.../power/control + interface; it may only be modified with the help of the pm_runtime_allow() + and pm_runtime_forbid() helper functions + All of the above fields are members of the 'power' member of 'struct device'. 4. Run-time PM Device Helper Functions @@ -250,7 +256,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: to suspend the device again in future int pm_runtime_resume(struct device *dev); - - execute the subsystem-leve resume callback for the device; returns 0 on + - execute the subsystem-level resume callback for the device; returns 0 on success, 1 if the device's run-time PM status was already 'active' or error code on failure, where -EAGAIN means it may be safe to attempt to resume the device again in future, but 'power.runtime_error' should be @@ -329,6 +335,20 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: 'power.runtime_error' is set or 'power.disable_depth' is greater than zero) + bool pm_runtime_suspended(struct device *dev); + - return true if the device's runtime PM status is 'suspended', or false + otherwise + + void pm_runtime_allow(struct device *dev); + - set the power.runtime_auto flag for the device and decrease its usage + counter (used by the /sys/devices/.../power/control interface to + effectively allow the device to be power managed at run time) + + void pm_runtime_forbid(struct device *dev); + - unset the power.runtime_auto flag for the device and increase its usage + counter (used by the /sys/devices/.../power/control interface to + effectively prevent the device from being power managed at run time) + It is safe to execute the following helper functions from interrupt context: pm_request_idle() @@ -382,6 +402,18 @@ may be desirable to suspend the device as soon as ->probe() or ->remove() has finished, so the PM core uses pm_runtime_idle_sync() to invoke the subsystem-level idle callback for the device at that time. +The user space can effectively disallow the driver of the device to power manage +it at run time by changing the value of its /sys/devices/.../power/control +attribute to "on", which causes pm_runtime_forbid() to be called. In principle, +this mechanism may also be used by the driver to effectively turn off the +run-time power management of the device until the user space turns it on. +Namely, during the initialization the driver can make sure that the run-time PM +status of the device is 'active' and call pm_runtime_forbid(). It should be +noted, however, that if the user space has already intentionally changed the +value of /sys/devices/.../power/control to "auto" to allow the driver to power +manage the device at run time, the driver may confuse it by using +pm_runtime_forbid() this way. + 6. Run-time PM and System Sleep Run-time PM and system sleep (i.e., system suspend and hibernation, also known @@ -431,3 +463,64 @@ The PM core always increments the run-time usage counter before calling the ->prepare() callback and decrements it after calling the ->complete() callback. Hence disabling run-time PM temporarily like this will not cause any run-time suspend callbacks to be lost. + +7. Generic subsystem callbacks + +Subsystems may wish to conserve code space by using the set of generic power +management callbacks provided by the PM core, defined in +driver/base/power/generic_ops.c: + + int pm_generic_runtime_idle(struct device *dev); + - invoke the ->runtime_idle() callback provided by the driver of this + device, if defined, and call pm_runtime_suspend() for this device if the + return value is 0 or the callback is not defined + + int pm_generic_runtime_suspend(struct device *dev); + - invoke the ->runtime_suspend() callback provided by the driver of this + device and return its result, or return -EINVAL if not defined + + int pm_generic_runtime_resume(struct device *dev); + - invoke the ->runtime_resume() callback provided by the driver of this + device and return its result, or return -EINVAL if not defined + + int pm_generic_suspend(struct device *dev); + - if the device has not been suspended at run time, invoke the ->suspend() + callback provided by its driver and return its result, or return 0 if not + defined + + int pm_generic_resume(struct device *dev); + - invoke the ->resume() callback provided by the driver of this device and, + if successful, change the device's runtime PM status to 'active' + + int pm_generic_freeze(struct device *dev); + - if the device has not been suspended at run time, invoke the ->freeze() + callback provided by its driver and return its result, or return 0 if not + defined + + int pm_generic_thaw(struct device *dev); + - if the device has not been suspended at run time, invoke the ->thaw() + callback provided by its driver and return its result, or return 0 if not + defined + + int pm_generic_poweroff(struct device *dev); + - if the device has not been suspended at run time, invoke the ->poweroff() + callback provided by its driver and return its result, or return 0 if not + defined + + int pm_generic_restore(struct device *dev); + - invoke the ->restore() callback provided by the driver of this device and, + if successful, change the device's runtime PM status to 'active' + +These functions can be assigned to the ->runtime_idle(), ->runtime_suspend(), +->runtime_resume(), ->suspend(), ->resume(), ->freeze(), ->thaw(), ->poweroff(), +or ->restore() callback pointers in the subsystem-level dev_pm_ops structures. + +If a subsystem wishes to use all of them at the same time, it can simply assign +the GENERIC_SUBSYS_PM_OPS macro, defined in include/linux/pm.h, to its +dev_pm_ops structure pointer. + +Device drivers that wish to use the same function as a system suspend, freeze, +poweroff and run-time suspend callback, and similarly for system resume, thaw, +restore, and run-time resume, can achieve this with the help of the +UNIVERSAL_DEV_PM_OPS macro defined in include/linux/pm.h (possibly setting its +last argument to NULL). diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt index b967cd9137d6..81680f9f5909 100644 --- a/Documentation/power/userland-swsusp.txt +++ b/Documentation/power/userland-swsusp.txt @@ -24,6 +24,10 @@ assumed to be in the resume mode. The device cannot be open for simultaneous reading and writing. It is also impossible to have the device open more than once at a time. +Even opening the device has side effects. Data structures are +allocated, and PM_HIBERNATION_PREPARE / PM_RESTORE_PREPARE chains are +called. + The ioctl() commands recognized by the device are: SNAPSHOT_FREEZE - freeze user space processes (the current process is |
