Documentation/power/devices.txt

   1
   2 Device Power Management
   3
   4
   5 Device power management encompasses two areas - the ability to save
   6 state and transition a device to a low-power state when the system is
   7 entering a low-power state; and the ability to transition a device to
   8 a low-power state while the system is running (and independently of
   9 any other power management activity).
  10
  11
  12 Methods
  13
  14 The methods to suspend and resume devices reside in struct bus_type:
  15
  16 struct bus_type {
  17        ...
  18        int             (*suspend)(struct device * dev, u32 state);
  19        int             (*resume)(struct device * dev);
  20 };
  21
  22 Each bus driver is responsible implementing these methods, translating
  23 the call into a bus-specific request and forwarding the call to the
  24 bus-specific drivers. For example, PCI drivers implement suspend() and
  25 resume() methods in struct pci_driver. The PCI core is simply
  26 responsible for translating the pointers to PCI-specific ones and
  27 calling the low-level driver.
  28
  29 This is done to a) ease transition to the new power management methods
  30 and leverage the existing PM code in various bus drivers; b) allow
  31 buses to implement generic and default PM routines for devices, and c)
  32 make the flow of execution obvious to the reader.
  33
  34
  35 System Power Management
  36
  37 When the system enters a low-power state, the device tree is walked in
  38 a depth-first fashion to transition each device into a low-power
  39 state. The ordering of the device tree is guaranteed by the order in
  40 which devices get registered - children are never registered before
  41 their ancestors, and devices are placed at the back of the list when
  42 registered. By walking the list in reverse order, we are guaranteed to
  43 suspend devices in the proper order.
  44
  45 Devices are suspended once with interrupts enabled. Drivers are
  46 expected to stop I/O transactions, save device state, and place the
  47 device into a low-power state. Drivers may sleep, allocate memory,
  48 etc. at will.
  49
  50 Some devices are broken and will inevitably have problems powering
  51 down or disabling themselves with interrupts enabled. For these
  52 special cases, they may return -EAGAIN. This will put the device on a
  53 list to be taken care of later. When interrupts are disabled, before
  54 we enter the low-power state, their drivers are called again to put
  55 their device to sleep.
  56
  57 On resume, the devices that returned -EAGAIN will be called to power
  58 themselves back on with interrupts disabled. Once interrupts have been
  59 re-enabled, the rest of the drivers will be called to resume their
  60 devices. On resume, a driver is responsible for powering back on each
  61 device, restoring state, and re-enabling I/O transactions for that
  62 device.
  63
  64 System devices follow a slightly different API, which can be found in
  65
  66         include/linux/sysdev.h
  67         drivers/base/sys.c
  68
  69 System devices will only be suspended with interrupts disabled, and
  70 after all other devices have been suspended. On resume, they will be
  71 resumed before any other devices, and also with interrupts disabled.
  72
  73
  74 Runtime Power Management
  75
  76 Many devices are able to dynamically power down while the system is
  77 still running. This feature is useful for devices that are not being
  78 used, and can offer significant power savings on a running system.
  79
  80 In each device's directory, there is a 'power' directory, which
  81 contains at least a 'state' file. Reading from this file displays what
  82 power state the device is currently in. Writing to this file initiates
  83 a transition to the specified power state, which must be a decimal in
  84 the range 1-3, inclusive; or 0 for 'On'.
  85
  86 The PM core will call the ->suspend() method in the bus_type object
  87 that the device belongs to if the specified state is not 0, or
  88 ->resume() if it is.
  89
  90 Nothing will happen if the specified state is the same state the
  91 device is currently in.
  92
  93 If the device is already in a low-power state, and the specified state
  94 is another, but different, low-power state, the ->resume() method will
  95 first be called to power the device back on, then ->suspend() will be
  96 called again with the new state.
  97
  98 The driver is responsible for saving the working state of the device
  99 and putting it into the low-power state specified. If this was
 100 successful, it returns 0, and the device's power_state field is
 101 updated.
 102
 103 The driver must take care to know whether or not it is able to
 104 properly resume the device, including all step of reinitialization
 105 necessary. (This is the hardest part, and the one most protected by
 106 NDA'd documents).
 107
 108 The driver must also take care not to suspend a device that is
 109 currently in use. It is their responsibility to provide their own
 110 exclusion mechanisms.
 111
 112 The runtime power transition happens with interrupts enabled. If a
 113 device cannot support being powered down with interrupts, it may
 114 return -EAGAIN (as it would during a system power management
 115 transition),  but it will _not_ be called again, and the transaction
 116 will fail.
 117
 118 There is currently no way to know what states a device or driver
 119 supports a priori. This will change in the future.
 120
 121
 122 Driver Detach Power Management
 123
 124 The kernel now supports the ability to place a device in a low-power
 125 state when it is detached from its driver, which happens when its
 126 module is removed.
 127
 128 Each device contains a 'detach_state' file in its sysfs directory
 129 which can be used to control this state. Reading from this file
 130 displays what the current detach state is set to. This is 0 (On) by
 131 default. A user may write a positive integer value to this file in the
 132 range of 1-4 inclusive.
 133
 134 A value of 1-3 will indicate the device should be placed in that
 135 low-power state, which will cause ->suspend() to be called for that
 136 device. A value of 4 indicates that the device should be shutdown, so
 137 ->shutdown() will be called for that device.
 138
 139 The driver is responsible for reinitializing the device when the
 140 module is re-inserted during it's ->probe() (or equivalent) method.
 141 The driver core will not call any extra functions when binding the
 142 device to the driver.
 143