power.rst 9.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245
  1. ================
  2. Power Management
  3. ================
  4. .. todo::
  5. This needs to be updated to account for the different governors
  6. besides the activity-based one.
  7. NuttX supports a simple power management (PM) sub-system which:
  8. - Monitors activity from drivers (and from other parts of the
  9. system), and
  10. - Provides hooks to place drivers (and the whole system) into
  11. reduce power modes of operation.
  12. |figure|
  13. The PM sub-system integrates the MCU idle loop with a collection
  14. of device drivers to support:
  15. - Reports of relevant driver or other system activity.
  16. - Registration and callback mechanism to interface with
  17. individual device drivers.
  18. - IDLE time polling of overall driver activity.
  19. - Coordinated, global, system-wide transitions to lower power
  20. usage states.
  21. **Low Power Consumption States**. Various "sleep" and low power
  22. consumption states have various names and are sometimes used in
  23. conflicting ways. In the NuttX PM logic, we will use the following
  24. terminology:
  25. ``NORMAL``
  26. The normal, full power operating mode.
  27. ``IDLE``
  28. This is still basically normal operational mode, the system is,
  29. however, ``IDLE`` and some simple simple steps to reduce power
  30. consumption provided that they do not interfere with normal
  31. Operation. Simply dimming the a backlight might be an example
  32. some that that would be done when the system is idle.
  33. ``STANDBY``
  34. Standby is a lower power consumption mode that may involve more
  35. extensive power management steps such has disabling clocking or
  36. setting the processor into reduced power consumption modes. In
  37. this state, the system should still be able to resume normal
  38. activity almost immediately.
  39. ``SLEEP``
  40. The lowest power consumption mode. The most drastic power
  41. reduction measures possible should be taken in this state. It
  42. may require some time to get back to normal operation from
  43. ``SLEEP`` (some MCUs may even require going through reset).
  44. .. c:enum:: pm_state_e
  45. These various states are represented with type :c:enum:`pm_state_e`
  46. in ``include/nuttx/power/pm.h``.
  47. **Power Management Domains**. Each PM interfaces includes a
  48. integer *domain* number. By default, only a single power domain is
  49. supported (``CONFIG_PM_NDOMAINS=1``). But that is configurable;
  50. any number of PM domains can be supported. Multiple PM domains
  51. might be useful, for example, if you would want to control power
  52. states associated with a network separately from power states
  53. associated with a user interface.
  54. Interfaces
  55. ==========
  56. All PM interfaces are declared in the file ``include/nuttx/power/pm.h``.
  57. .. c:function:: void pm_initialize(void)
  58. Called by MCU-specific one-time logic
  59. at power-on-reset in order to initialize the power management
  60. capabilities. This function must be called *very* early in the
  61. initialization sequence *before* any other device drivers are
  62. initialized (since they may attempt to register with the power
  63. management subsystem).
  64. .. c:function:: int pm_register(FAR struct pm_callback_s *callbacks)
  65. Called by a device driver in
  66. order to register to receive power management event callbacks.
  67. Refer to the :ref:`components/power:Callbacks` section for more
  68. details.
  69. :param callbacks:
  70. An instance of :c:struct:`pm_callback_s`
  71. providing the driver callback functions.
  72. :return:
  73. Zero (``OK``) on success; otherwise a negated
  74. ``errno`` value is returned.
  75. .. c:function:: int pm_unregister(FAR struct pm_callback_s *callbacks)
  76. Called by a device driver in
  77. order to unregister previously registered power management event
  78. callbacks. Refer to the :ref:`components/power:Callbacks` section for
  79. more details.
  80. **Input Parameters:**
  81. :param callbacks:
  82. An instance of :c:struct:`pm_callback_s`
  83. providing the driver callback functions.
  84. :return:
  85. Zero (``OK``) on success; otherwise a negated
  86. ``errno`` value is returned.
  87. .. c:function:: void pm_activity(int domain, int priority)
  88. Called by a device driver to
  89. indicate that it is performing meaningful activities (non-idle).
  90. This increment an activity count and/or will restart a idle timer
  91. and prevent entering reduced power states.
  92. :param domain: Identifies the domain of the new PM activity
  93. :param priority:
  94. Activity priority, range 0-9. Larger values correspond to
  95. higher priorities. Higher priority activity can prevent the
  96. system from entering reduced power states for a longer period
  97. of time. As an example, a button press might be higher priority
  98. activity because it means that the user is actively interacting
  99. with the device.
  100. **Assumptions:** This function may be called from an interrupt
  101. handler (this is the ONLY PM function that may be called from an
  102. interrupt handler!).
  103. .. c:function:: enum pm_state_e pm_checkstate(int domain)
  104. Called from the MCU-specific
  105. IDLE loop to monitor the power management conditions. This
  106. function returns the "recommended" power management state based on
  107. the PM configuration and activity reported in the last sampling
  108. periods. The power management state is not automatically changed,
  109. however. The IDLE loop must call :c:func:`pm_changestate` in order to
  110. make the state change.
  111. These two steps are separated because the platform-specific IDLE
  112. loop may have additional situational information that is not
  113. available to the PM sub-system. For example, the IDLE loop may
  114. know that the battery charge level is very low and may force lower
  115. power states even if there is activity.
  116. NOTE: That these two steps are separated in time and, hence, the
  117. IDLE loop could be suspended for a long period of time between
  118. calling :c:func:`pm_checkstate` and :c:func:`pm_changestate`. The IDLE
  119. loop may need to make these calls atomic by either disabling
  120. interrupts until the state change is completed.
  121. :param domain: Identifies the PM domain to check
  122. :return: The recommended power management state.
  123. .. c:function:: int pm_changestate(int domain, enum pm_state_e newstate)
  124. This function is used by platform-specific power
  125. management logic. It will announce the power management power
  126. management state change to all drivers that have registered for
  127. power management event callbacks.
  128. :param domain: Identifies the domain of the new PM state
  129. :param newstate: Identifies the new PM state
  130. :return:
  131. 0 (``OK``) means that the callback function
  132. for all registered drivers returned ``OK`` (meaning that they
  133. accept the state change). Non-zero means that one of the drivers
  134. refused the state change. In this case, the system will revert to
  135. the preceding state.
  136. **Assumptions:** It is assumed that interrupts are disabled when
  137. this function is called. This function is probably called from the
  138. IDLE loop... the lowest priority task in the system. Changing
  139. driver power management states may result in renewed system
  140. activity and, as a result, can suspend the IDLE thread before it
  141. completes the entire state change unless interrupts are disabled
  142. throughout the state change.
  143. Callbacks
  144. =========
  145. .. c:struct:: pm_callback_s
  146. This struct includes the pointers to the driver
  147. callback functions. This structure is defined
  148. ``include/nuttx/power/pm.h``. These callback functions can be used
  149. to provide power management information to the driver.
  150. .. c:var:: int (*prepare)(FAR struct pm_callback_s *cb, int domain, enum pm_state_e pmstate)
  151. Request the driver to prepare for a new power
  152. state. This is a warning that the system is about to enter into a
  153. new power state. The driver should begin whatever operations that
  154. may be required to enter power state. The driver may abort the
  155. state change mode by returning a non-zero value from the callback
  156. function.
  157. :param cb:
  158. Returned to the driver. The driver version of the callback
  159. structure may include additional, driver-specific state data at
  160. the end of the structure.
  161. :param domain:
  162. Identifies the activity domain of the state change
  163. :param pmstate:
  164. Identifies the new PM state
  165. :return:
  166. Zero (``OK``) means the event was successfully
  167. processed and that the driver is prepared for the PM state change.
  168. Non-zero means that the driver is not prepared to perform the
  169. tasks needed achieve this power setting and will cause the state
  170. change to be aborted. NOTE: The ``prepare()`` method will also be
  171. called when reverting from lower back to higher power consumption
  172. modes (say because another driver refused a lower power state
  173. change). Drivers are not permitted to return non-zero values when
  174. reverting back to higher power consumption modes!
  175. .. c:var:: void (*notify)(FAR struct pm_callback_s *cb, int domain, enum pm_state_e pmstate)
  176. Notify the driver of new power state. This
  177. callback is called after all drivers have had the opportunity to
  178. prepare for the new power state.
  179. :param cb:
  180. Returned to the driver. The driver version of the callback
  181. structure may include additional, driver-specific state data at
  182. the end of the structure.
  183. :param domain:
  184. Identifies the activity domain of the state change
  185. :param pmstate:
  186. Identifies the new PM state
  187. The driver already agreed to transition
  188. to the low power consumption state when when it returned ``OK`` to
  189. the :c:var:`prepare` call.
  190. .. |figure| image:: pm.png