pci.txt 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336
  1. PCI Power Management
  2. ~~~~~~~~~~~~~~~~~~~~
  3. An overview of the concepts and the related functions in the Linux kernel
  4. Patrick Mochel <mochel@transmeta.com>
  5. (and others)
  6. ---------------------------------------------------------------------------
  7. 1. Overview
  8. 2. How the PCI Subsystem Does Power Management
  9. 3. PCI Utility Functions
  10. 4. PCI Device Drivers
  11. 5. Resources
  12. 1. Overview
  13. ~~~~~~~~~~~
  14. The PCI Power Management Specification was introduced between the PCI 2.1 and
  15. PCI 2.2 Specifications. It a standard interface for controlling various
  16. power management operations.
  17. Implementation of the PCI PM Spec is optional, as are several sub-components of
  18. it. If a device supports the PCI PM Spec, the device will have an 8 byte
  19. capability field in its PCI configuration space. This field is used to describe
  20. and control the standard PCI power management features.
  21. The PCI PM spec defines 4 operating states for devices (D0 - D3) and for buses
  22. (B0 - B3). The higher the number, the less power the device consumes. However,
  23. the higher the number, the longer the latency is for the device to return to
  24. an operational state (D0).
  25. There are actually two D3 states. When someone talks about D3, they usually
  26. mean D3hot, which corresponds to an ACPI D2 state (power is reduced, the
  27. device may lose some context). But they may also mean D3cold, which is an
  28. ACPI D3 state (power is fully off, all state was discarded); or both.
  29. Bus power management is not covered in this version of this document.
  30. Note that all PCI devices support D0 and D3cold by default, regardless of
  31. whether or not they implement any of the PCI PM spec.
  32. The possible state transitions that a device can undergo are:
  33. +---------------------------+
  34. | Current State | New State |
  35. +---------------------------+
  36. | D0 | D1, D2, D3|
  37. +---------------------------+
  38. | D1 | D2, D3 |
  39. +---------------------------+
  40. | D2 | D3 |
  41. +---------------------------+
  42. | D1, D2, D3 | D0 |
  43. +---------------------------+
  44. Note that when the system is entering a global suspend state, all devices will
  45. be placed into D3 and when resuming, all devices will be placed into D0.
  46. However, when the system is running, other state transitions are possible.
  47. 2. How The PCI Subsystem Handles Power Management
  48. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  49. The PCI suspend/resume functionality is accessed indirectly via the Power
  50. Management subsystem. At boot, the PCI driver registers a power management
  51. callback with that layer. Upon entering a suspend state, the PM layer iterates
  52. through all of its registered callbacks. This currently takes place only during
  53. APM state transitions.
  54. Upon going to sleep, the PCI subsystem walks its device tree twice. Both times,
  55. it does a depth first walk of the device tree. The first walk saves each of the
  56. device's state and checks for devices that will prevent the system from entering
  57. a global power state. The next walk then places the devices in a low power
  58. state.
  59. The first walk allows a graceful recovery in the event of a failure, since none
  60. of the devices have actually been powered down.
  61. In both walks, in particular the second, all children of a bridge are touched
  62. before the actual bridge itself. This allows the bridge to retain power while
  63. its children are being accessed.
  64. Upon resuming from sleep, just the opposite must be true: all bridges must be
  65. powered on and restored before their children are powered on. This is easily
  66. accomplished with a breadth-first walk of the PCI device tree.
  67. 3. PCI Utility Functions
  68. ~~~~~~~~~~~~~~~~~~~~~~~~
  69. These are helper functions designed to be called by individual device drivers.
  70. Assuming that a device behaves as advertised, these should be applicable in most
  71. cases. However, results may vary.
  72. Note that these functions are never implicitly called for the driver. The driver
  73. is always responsible for deciding when and if to call these.
  74. pci_save_state
  75. --------------
  76. Usage:
  77. pci_save_state(struct pci_dev *dev);
  78. Description:
  79. Save first 64 bytes of PCI config space, along with any additional
  80. PCI-Express or PCI-X information.
  81. pci_restore_state
  82. -----------------
  83. Usage:
  84. pci_restore_state(struct pci_dev *dev);
  85. Description:
  86. Restore previously saved config space.
  87. pci_set_power_state
  88. -------------------
  89. Usage:
  90. pci_set_power_state(struct pci_dev *dev, pci_power_t state);
  91. Description:
  92. Transition device to low power state using PCI PM Capabilities
  93. registers.
  94. Will fail under one of the following conditions:
  95. - If state is less than current state, but not D0 (illegal transition)
  96. - Device doesn't support PM Capabilities
  97. - Device does not support requested state
  98. pci_enable_wake
  99. ---------------
  100. Usage:
  101. pci_enable_wake(struct pci_dev *dev, pci_power_t state, int enable);
  102. Description:
  103. Enable device to generate PME# during low power state using PCI PM
  104. Capabilities.
  105. Checks whether if device supports generating PME# from requested state
  106. and fail if it does not, unless enable == 0 (request is to disable wake
  107. events, which is implicit if it doesn't even support it in the first
  108. place).
  109. Note that the PMC Register in the device's PM Capabilities has a bitmask
  110. of the states it supports generating PME# from. D3hot is bit 3 and
  111. D3cold is bit 4. So, while a value of 4 as the state may not seem
  112. semantically correct, it is.
  113. 4. PCI Device Drivers
  114. ~~~~~~~~~~~~~~~~~~~~~
  115. These functions are intended for use by individual drivers, and are defined in
  116. struct pci_driver:
  117. int (*suspend) (struct pci_dev *dev, pm_message_t state);
  118. int (*resume) (struct pci_dev *dev);
  119. int (*enable_wake) (struct pci_dev *dev, pci_power_t state, int enable);
  120. suspend
  121. -------
  122. Usage:
  123. if (dev->driver && dev->driver->suspend)
  124. dev->driver->suspend(dev,state);
  125. A driver uses this function to actually transition the device into a low power
  126. state. This should include disabling I/O, IRQs, and bus-mastering, as well as
  127. physically transitioning the device to a lower power state; it may also include
  128. calls to pci_enable_wake().
  129. Bus mastering may be disabled by doing:
  130. pci_disable_device(dev);
  131. For devices that support the PCI PM Spec, this may be used to set the device's
  132. power state to match the suspend() parameter:
  133. pci_set_power_state(dev,state);
  134. The driver is also responsible for disabling any other device-specific features
  135. (e.g blanking screen, turning off on-card memory, etc).
  136. The driver should be sure to track the current state of the device, as it may
  137. obviate the need for some operations.
  138. The driver should update the current_state field in its pci_dev structure in
  139. this function, except for PM-capable devices when pci_set_power_state is used.
  140. resume
  141. ------
  142. Usage:
  143. if (dev->driver && dev->driver->suspend)
  144. dev->driver->resume(dev)
  145. The resume callback may be called from any power state, and is always meant to
  146. transition the device to the D0 state.
  147. The driver is responsible for reenabling any features of the device that had
  148. been disabled during previous suspend calls, such as IRQs and bus mastering,
  149. as well as calling pci_restore_state().
  150. If the device is currently in D3, it may need to be reinitialized in resume().
  151. * Some types of devices, like bus controllers, will preserve context in D3hot
  152. (using Vcc power). Their drivers will often want to avoid re-initializing
  153. them after re-entering D0 (perhaps to avoid resetting downstream devices).
  154. * Other kinds of devices in D3hot will discard device context as part of a
  155. soft reset when re-entering the D0 state.
  156. * Devices resuming from D3cold always go through a power-on reset. Some
  157. device context can also be preserved using Vaux power.
  158. * Some systems hide D3cold resume paths from drivers. For example, on PCs
  159. the resume path for suspend-to-disk often runs BIOS powerup code, which
  160. will sometimes re-initialize the device.
  161. To handle resets during D3 to D0 transitions, it may be convenient to share
  162. device initialization code between probe() and resume(). Device parameters
  163. can also be saved before the driver suspends into D3, avoiding re-probe.
  164. If the device supports the PCI PM Spec, it can use this to physically transition
  165. the device to D0:
  166. pci_set_power_state(dev,0);
  167. Note that if the entire system is transitioning out of a global sleep state, all
  168. devices will be placed in the D0 state, so this is not necessary. However, in
  169. the event that the device is placed in the D3 state during normal operation,
  170. this call is necessary. It is impossible to determine which of the two events is
  171. taking place in the driver, so it is always a good idea to make that call.
  172. The driver should take note of the state that it is resuming from in order to
  173. ensure correct (and speedy) operation.
  174. The driver should update the current_state field in its pci_dev structure in
  175. this function, except for PM-capable devices when pci_set_power_state is used.
  176. enable_wake
  177. -----------
  178. Usage:
  179. if (dev->driver && dev->driver->enable_wake)
  180. dev->driver->enable_wake(dev,state,enable);
  181. This callback is generally only relevant for devices that support the PCI PM
  182. spec and have the ability to generate a PME# (Power Management Event Signal)
  183. to wake the system up. (However, it is possible that a device may support
  184. some non-standard way of generating a wake event on sleep.)
  185. Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's
  186. PM Capabilities describe what power states the device supports generating a
  187. wake event from:
  188. +------------------+
  189. | Bit | State |
  190. +------------------+
  191. | 11 | D0 |
  192. | 12 | D1 |
  193. | 13 | D2 |
  194. | 14 | D3hot |
  195. | 15 | D3cold |
  196. +------------------+
  197. A device can use this to enable wake events:
  198. pci_enable_wake(dev,state,enable);
  199. Note that to enable PME# from D3cold, a value of 4 should be passed to
  200. pci_enable_wake (since it uses an index into a bitmask). If a driver gets
  201. a request to enable wake events from D3, two calls should be made to
  202. pci_enable_wake (one for both D3hot and D3cold).
  203. A reference implementation
  204. -------------------------
  205. .suspend()
  206. {
  207. /* driver specific operations */
  208. /* Disable IRQ */
  209. free_irq();
  210. /* If using MSI */
  211. pci_disable_msi();
  212. pci_save_state();
  213. pci_enable_wake();
  214. /* Disable IO/bus master/irq router */
  215. pci_disable_device();
  216. pci_set_power_state(pci_choose_state());
  217. }
  218. .resume()
  219. {
  220. pci_set_power_state(PCI_D0);
  221. pci_restore_state();
  222. /* device's irq possibly is changed, driver should take care */
  223. pci_enable_device();
  224. pci_set_master();
  225. /* if using MSI, device's vector possibly is changed */
  226. pci_enable_msi();
  227. request_irq();
  228. /* driver specific operations; */
  229. }
  230. This is a typical implementation. Drivers can slightly change the order
  231. of the operations in the implementation, ignore some operations or add
  232. more driver specific operations in it, but drivers should do something like
  233. this on the whole.
  234. 5. Resources
  235. ~~~~~~~~~~~~
  236. PCI Local Bus Specification
  237. PCI Bus Power Management Interface Specification
  238. http://www.pcisig.com