pm.h 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445
  1. /*
  2. * pm.h - Power management interface
  3. *
  4. * Copyright (C) 2000 Andrew Henroid
  5. *
  6. * This program is free software; you can redistribute it and/or modify
  7. * it under the terms of the GNU General Public License as published by
  8. * the Free Software Foundation; either version 2 of the License, or
  9. * (at your option) any later version.
  10. *
  11. * This program is distributed in the hope that it will be useful,
  12. * but WITHOUT ANY WARRANTY; without even the implied warranty of
  13. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  14. * GNU General Public License for more details.
  15. *
  16. * You should have received a copy of the GNU General Public License
  17. * along with this program; if not, write to the Free Software
  18. * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
  19. */
  20. #ifndef _LINUX_PM_H
  21. #define _LINUX_PM_H
  22. #include <linux/list.h>
  23. /*
  24. * Callbacks for platform drivers to implement.
  25. */
  26. extern void (*pm_idle)(void);
  27. extern void (*pm_power_off)(void);
  28. extern void (*pm_power_off_prepare)(void);
  29. /*
  30. * Device power management
  31. */
  32. struct device;
  33. typedef struct pm_message {
  34. int event;
  35. } pm_message_t;
  36. /**
  37. * struct pm_ops - device PM callbacks
  38. *
  39. * Several driver power state transitions are externally visible, affecting
  40. * the state of pending I/O queues and (for drivers that touch hardware)
  41. * interrupts, wakeups, DMA, and other hardware state. There may also be
  42. * internal transitions to various low power modes, which are transparent
  43. * to the rest of the driver stack (such as a driver that's ON gating off
  44. * clocks which are not in active use).
  45. *
  46. * The externally visible transitions are handled with the help of the following
  47. * callbacks included in this structure:
  48. *
  49. * @prepare: Prepare the device for the upcoming transition, but do NOT change
  50. * its hardware state. Prevent new children of the device from being
  51. * registered after @prepare() returns (the driver's subsystem and
  52. * generally the rest of the kernel is supposed to prevent new calls to the
  53. * probe method from being made too once @prepare() has succeeded). If
  54. * @prepare() detects a situation it cannot handle (e.g. registration of a
  55. * child already in progress), it may return -EAGAIN, so that the PM core
  56. * can execute it once again (e.g. after the new child has been registered)
  57. * to recover from the race condition. This method is executed for all
  58. * kinds of suspend transitions and is followed by one of the suspend
  59. * callbacks: @suspend(), @freeze(), or @poweroff().
  60. * The PM core executes @prepare() for all devices before starting to
  61. * execute suspend callbacks for any of them, so drivers may assume all of
  62. * the other devices to be present and functional while @prepare() is being
  63. * executed. In particular, it is safe to make GFP_KERNEL memory
  64. * allocations from within @prepare(). However, drivers may NOT assume
  65. * anything about the availability of the user space at that time and it
  66. * is not correct to request firmware from within @prepare() (it's too
  67. * late to do that). [To work around this limitation, drivers may
  68. * register suspend and hibernation notifiers that are executed before the
  69. * freezing of tasks.]
  70. *
  71. * @complete: Undo the changes made by @prepare(). This method is executed for
  72. * all kinds of resume transitions, following one of the resume callbacks:
  73. * @resume(), @thaw(), @restore(). Also called if the state transition
  74. * fails before the driver's suspend callback (@suspend(), @freeze(),
  75. * @poweroff()) can be executed (e.g. if the suspend callback fails for one
  76. * of the other devices that the PM core has unsuccessfully attempted to
  77. * suspend earlier).
  78. * The PM core executes @complete() after it has executed the appropriate
  79. * resume callback for all devices.
  80. *
  81. * @suspend: Executed before putting the system into a sleep state in which the
  82. * contents of main memory are preserved. Quiesce the device, put it into
  83. * a low power state appropriate for the upcoming system state (such as
  84. * PCI_D3hot), and enable wakeup events as appropriate.
  85. *
  86. * @resume: Executed after waking the system up from a sleep state in which the
  87. * contents of main memory were preserved. Put the device into the
  88. * appropriate state, according to the information saved in memory by the
  89. * preceding @suspend(). The driver starts working again, responding to
  90. * hardware events and software requests. The hardware may have gone
  91. * through a power-off reset, or it may have maintained state from the
  92. * previous suspend() which the driver may rely on while resuming. On most
  93. * platforms, there are no restrictions on availability of resources like
  94. * clocks during @resume().
  95. *
  96. * @freeze: Hibernation-specific, executed before creating a hibernation image.
  97. * Quiesce operations so that a consistent image can be created, but do NOT
  98. * otherwise put the device into a low power device state and do NOT emit
  99. * system wakeup events. Save in main memory the device settings to be
  100. * used by @restore() during the subsequent resume from hibernation or by
  101. * the subsequent @thaw(), if the creation of the image or the restoration
  102. * of main memory contents from it fails.
  103. *
  104. * @thaw: Hibernation-specific, executed after creating a hibernation image OR
  105. * if the creation of the image fails. Also executed after a failing
  106. * attempt to restore the contents of main memory from such an image.
  107. * Undo the changes made by the preceding @freeze(), so the device can be
  108. * operated in the same way as immediately before the call to @freeze().
  109. *
  110. * @poweroff: Hibernation-specific, executed after saving a hibernation image.
  111. * Quiesce the device, put it into a low power state appropriate for the
  112. * upcoming system state (such as PCI_D3hot), and enable wakeup events as
  113. * appropriate.
  114. *
  115. * @restore: Hibernation-specific, executed after restoring the contents of main
  116. * memory from a hibernation image. Driver starts working again,
  117. * responding to hardware events and software requests. Drivers may NOT
  118. * make ANY assumptions about the hardware state right prior to @restore().
  119. * On most platforms, there are no restrictions on availability of
  120. * resources like clocks during @restore().
  121. *
  122. * All of the above callbacks, except for @complete(), return error codes.
  123. * However, the error codes returned by the resume operations, @resume(),
  124. * @thaw(), and @restore(), do not cause the PM core to abort the resume
  125. * transition during which they are returned. The error codes returned in
  126. * that cases are only printed by the PM core to the system logs for debugging
  127. * purposes. Still, it is recommended that drivers only return error codes
  128. * from their resume methods in case of an unrecoverable failure (i.e. when the
  129. * device being handled refuses to resume and becomes unusable) to allow us to
  130. * modify the PM core in the future, so that it can avoid attempting to handle
  131. * devices that failed to resume and their children.
  132. *
  133. * It is allowed to unregister devices while the above callbacks are being
  134. * executed. However, it is not allowed to unregister a device from within any
  135. * of its own callbacks.
  136. */
  137. struct pm_ops {
  138. int (*prepare)(struct device *dev);
  139. void (*complete)(struct device *dev);
  140. int (*suspend)(struct device *dev);
  141. int (*resume)(struct device *dev);
  142. int (*freeze)(struct device *dev);
  143. int (*thaw)(struct device *dev);
  144. int (*poweroff)(struct device *dev);
  145. int (*restore)(struct device *dev);
  146. };
  147. /**
  148. * struct pm_ext_ops - extended device PM callbacks
  149. *
  150. * Some devices require certain operations related to suspend and hibernation
  151. * to be carried out with interrupts disabled. Thus, 'struct pm_ext_ops' below
  152. * is defined, adding callbacks to be executed with interrupts disabled to
  153. * 'struct pm_ops'.
  154. *
  155. * The following callbacks included in 'struct pm_ext_ops' are executed with
  156. * the nonboot CPUs switched off and with interrupts disabled on the only
  157. * functional CPU. They also are executed with the PM core list of devices
  158. * locked, so they must NOT unregister any devices.
  159. *
  160. * @suspend_noirq: Complete the operations of ->suspend() by carrying out any
  161. * actions required for suspending the device that need interrupts to be
  162. * disabled
  163. *
  164. * @resume_noirq: Prepare for the execution of ->resume() by carrying out any
  165. * actions required for resuming the device that need interrupts to be
  166. * disabled
  167. *
  168. * @freeze_noirq: Complete the operations of ->freeze() by carrying out any
  169. * actions required for freezing the device that need interrupts to be
  170. * disabled
  171. *
  172. * @thaw_noirq: Prepare for the execution of ->thaw() by carrying out any
  173. * actions required for thawing the device that need interrupts to be
  174. * disabled
  175. *
  176. * @poweroff_noirq: Complete the operations of ->poweroff() by carrying out any
  177. * actions required for handling the device that need interrupts to be
  178. * disabled
  179. *
  180. * @restore_noirq: Prepare for the execution of ->restore() by carrying out any
  181. * actions required for restoring the operations of the device that need
  182. * interrupts to be disabled
  183. *
  184. * All of the above callbacks return error codes, but the error codes returned
  185. * by the resume operations, @resume_noirq(), @thaw_noirq(), and
  186. * @restore_noirq(), do not cause the PM core to abort the resume transition
  187. * during which they are returned. The error codes returned in that cases are
  188. * only printed by the PM core to the system logs for debugging purposes.
  189. * Still, as stated above, it is recommended that drivers only return error
  190. * codes from their resume methods if the device being handled fails to resume
  191. * and is not usable any more.
  192. */
  193. struct pm_ext_ops {
  194. struct pm_ops base;
  195. int (*suspend_noirq)(struct device *dev);
  196. int (*resume_noirq)(struct device *dev);
  197. int (*freeze_noirq)(struct device *dev);
  198. int (*thaw_noirq)(struct device *dev);
  199. int (*poweroff_noirq)(struct device *dev);
  200. int (*restore_noirq)(struct device *dev);
  201. };
  202. /**
  203. * PM_EVENT_ messages
  204. *
  205. * The following PM_EVENT_ messages are defined for the internal use of the PM
  206. * core, in order to provide a mechanism allowing the high level suspend and
  207. * hibernation code to convey the necessary information to the device PM core
  208. * code:
  209. *
  210. * ON No transition.
  211. *
  212. * FREEZE System is going to hibernate, call ->prepare() and ->freeze()
  213. * for all devices.
  214. *
  215. * SUSPEND System is going to suspend, call ->prepare() and ->suspend()
  216. * for all devices.
  217. *
  218. * HIBERNATE Hibernation image has been saved, call ->prepare() and
  219. * ->poweroff() for all devices.
  220. *
  221. * QUIESCE Contents of main memory are going to be restored from a (loaded)
  222. * hibernation image, call ->prepare() and ->freeze() for all
  223. * devices.
  224. *
  225. * RESUME System is resuming, call ->resume() and ->complete() for all
  226. * devices.
  227. *
  228. * THAW Hibernation image has been created, call ->thaw() and
  229. * ->complete() for all devices.
  230. *
  231. * RESTORE Contents of main memory have been restored from a hibernation
  232. * image, call ->restore() and ->complete() for all devices.
  233. *
  234. * RECOVER Creation of a hibernation image or restoration of the main
  235. * memory contents from a hibernation image has failed, call
  236. * ->thaw() and ->complete() for all devices.
  237. *
  238. * The following PM_EVENT_ messages are defined for internal use by
  239. * kernel subsystems. They are never issued by the PM core.
  240. *
  241. * USER_SUSPEND Manual selective suspend was issued by userspace.
  242. *
  243. * USER_RESUME Manual selective resume was issued by userspace.
  244. *
  245. * REMOTE_WAKEUP Remote-wakeup request was received from the device.
  246. *
  247. * AUTO_SUSPEND Automatic (device idle) runtime suspend was
  248. * initiated by the subsystem.
  249. *
  250. * AUTO_RESUME Automatic (device needed) runtime resume was
  251. * requested by a driver.
  252. */
  253. #define PM_EVENT_ON 0x0000
  254. #define PM_EVENT_FREEZE 0x0001
  255. #define PM_EVENT_SUSPEND 0x0002
  256. #define PM_EVENT_HIBERNATE 0x0004
  257. #define PM_EVENT_QUIESCE 0x0008
  258. #define PM_EVENT_RESUME 0x0010
  259. #define PM_EVENT_THAW 0x0020
  260. #define PM_EVENT_RESTORE 0x0040
  261. #define PM_EVENT_RECOVER 0x0080
  262. #define PM_EVENT_USER 0x0100
  263. #define PM_EVENT_REMOTE 0x0200
  264. #define PM_EVENT_AUTO 0x0400
  265. #define PM_EVENT_SLEEP (PM_EVENT_SUSPEND | PM_EVENT_HIBERNATE)
  266. #define PM_EVENT_USER_SUSPEND (PM_EVENT_USER | PM_EVENT_SUSPEND)
  267. #define PM_EVENT_USER_RESUME (PM_EVENT_USER | PM_EVENT_RESUME)
  268. #define PM_EVENT_REMOTE_WAKEUP (PM_EVENT_REMOTE | PM_EVENT_RESUME)
  269. #define PM_EVENT_AUTO_SUSPEND (PM_EVENT_AUTO | PM_EVENT_SUSPEND)
  270. #define PM_EVENT_AUTO_RESUME (PM_EVENT_AUTO | PM_EVENT_RESUME)
  271. #define PMSG_ON ((struct pm_message){ .event = PM_EVENT_ON, })
  272. #define PMSG_FREEZE ((struct pm_message){ .event = PM_EVENT_FREEZE, })
  273. #define PMSG_QUIESCE ((struct pm_message){ .event = PM_EVENT_QUIESCE, })
  274. #define PMSG_SUSPEND ((struct pm_message){ .event = PM_EVENT_SUSPEND, })
  275. #define PMSG_HIBERNATE ((struct pm_message){ .event = PM_EVENT_HIBERNATE, })
  276. #define PMSG_RESUME ((struct pm_message){ .event = PM_EVENT_RESUME, })
  277. #define PMSG_THAW ((struct pm_message){ .event = PM_EVENT_THAW, })
  278. #define PMSG_RESTORE ((struct pm_message){ .event = PM_EVENT_RESTORE, })
  279. #define PMSG_RECOVER ((struct pm_message){ .event = PM_EVENT_RECOVER, })
  280. #define PMSG_USER_SUSPEND ((struct pm_messge) \
  281. { .event = PM_EVENT_USER_SUSPEND, })
  282. #define PMSG_USER_RESUME ((struct pm_messge) \
  283. { .event = PM_EVENT_USER_RESUME, })
  284. #define PMSG_REMOTE_RESUME ((struct pm_messge) \
  285. { .event = PM_EVENT_REMOTE_RESUME, })
  286. #define PMSG_AUTO_SUSPEND ((struct pm_messge) \
  287. { .event = PM_EVENT_AUTO_SUSPEND, })
  288. #define PMSG_AUTO_RESUME ((struct pm_messge) \
  289. { .event = PM_EVENT_AUTO_RESUME, })
  290. /**
  291. * Device power management states
  292. *
  293. * These state labels are used internally by the PM core to indicate the current
  294. * status of a device with respect to the PM core operations.
  295. *
  296. * DPM_ON Device is regarded as operational. Set this way
  297. * initially and when ->complete() is about to be called.
  298. * Also set when ->prepare() fails.
  299. *
  300. * DPM_PREPARING Device is going to be prepared for a PM transition. Set
  301. * when ->prepare() is about to be called.
  302. *
  303. * DPM_RESUMING Device is going to be resumed. Set when ->resume(),
  304. * ->thaw(), or ->restore() is about to be called.
  305. *
  306. * DPM_SUSPENDING Device has been prepared for a power transition. Set
  307. * when ->prepare() has just succeeded.
  308. *
  309. * DPM_OFF Device is regarded as inactive. Set immediately after
  310. * ->suspend(), ->freeze(), or ->poweroff() has succeeded.
  311. * Also set when ->resume()_noirq, ->thaw_noirq(), or
  312. * ->restore_noirq() is about to be called.
  313. *
  314. * DPM_OFF_IRQ Device is in a "deep sleep". Set immediately after
  315. * ->suspend_noirq(), ->freeze_noirq(), or
  316. * ->poweroff_noirq() has just succeeded.
  317. */
  318. enum dpm_state {
  319. DPM_INVALID,
  320. DPM_ON,
  321. DPM_PREPARING,
  322. DPM_RESUMING,
  323. DPM_SUSPENDING,
  324. DPM_OFF,
  325. DPM_OFF_IRQ,
  326. };
  327. struct dev_pm_info {
  328. pm_message_t power_state;
  329. unsigned can_wakeup:1;
  330. unsigned should_wakeup:1;
  331. enum dpm_state status; /* Owned by the PM core */
  332. #ifdef CONFIG_PM_SLEEP
  333. struct list_head entry;
  334. #endif
  335. };
  336. /*
  337. * The PM_EVENT_ messages are also used by drivers implementing the legacy
  338. * suspend framework, based on the ->suspend() and ->resume() callbacks common
  339. * for suspend and hibernation transitions, according to the rules below.
  340. */
  341. /* Necessary, because several drivers use PM_EVENT_PRETHAW */
  342. #define PM_EVENT_PRETHAW PM_EVENT_QUIESCE
  343. /*
  344. * One transition is triggered by resume(), after a suspend() call; the
  345. * message is implicit:
  346. *
  347. * ON Driver starts working again, responding to hardware events
  348. * and software requests. The hardware may have gone through
  349. * a power-off reset, or it may have maintained state from the
  350. * previous suspend() which the driver will rely on while
  351. * resuming. On most platforms, there are no restrictions on
  352. * availability of resources like clocks during resume().
  353. *
  354. * Other transitions are triggered by messages sent using suspend(). All
  355. * these transitions quiesce the driver, so that I/O queues are inactive.
  356. * That commonly entails turning off IRQs and DMA; there may be rules
  357. * about how to quiesce that are specific to the bus or the device's type.
  358. * (For example, network drivers mark the link state.) Other details may
  359. * differ according to the message:
  360. *
  361. * SUSPEND Quiesce, enter a low power device state appropriate for
  362. * the upcoming system state (such as PCI_D3hot), and enable
  363. * wakeup events as appropriate.
  364. *
  365. * HIBERNATE Enter a low power device state appropriate for the hibernation
  366. * state (eg. ACPI S4) and enable wakeup events as appropriate.
  367. *
  368. * FREEZE Quiesce operations so that a consistent image can be saved;
  369. * but do NOT otherwise enter a low power device state, and do
  370. * NOT emit system wakeup events.
  371. *
  372. * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring
  373. * the system from a snapshot taken after an earlier FREEZE.
  374. * Some drivers will need to reset their hardware state instead
  375. * of preserving it, to ensure that it's never mistaken for the
  376. * state which that earlier snapshot had set up.
  377. *
  378. * A minimally power-aware driver treats all messages as SUSPEND, fully
  379. * reinitializes its device during resume() -- whether or not it was reset
  380. * during the suspend/resume cycle -- and can't issue wakeup events.
  381. *
  382. * More power-aware drivers may also use low power states at runtime as
  383. * well as during system sleep states like PM_SUSPEND_STANDBY. They may
  384. * be able to use wakeup events to exit from runtime low-power states,
  385. * or from system low-power states such as standby or suspend-to-RAM.
  386. */
  387. #ifdef CONFIG_PM_SLEEP
  388. extern void device_pm_lock(void);
  389. extern void device_power_up(pm_message_t state);
  390. extern void device_resume(pm_message_t state);
  391. extern void device_pm_unlock(void);
  392. extern int device_power_down(pm_message_t state);
  393. extern int device_suspend(pm_message_t state);
  394. extern int device_prepare_suspend(pm_message_t state);
  395. extern void __suspend_report_result(const char *function, void *fn, int ret);
  396. #define suspend_report_result(fn, ret) \
  397. do { \
  398. __suspend_report_result(__FUNCTION__, fn, ret); \
  399. } while (0)
  400. #else /* !CONFIG_PM_SLEEP */
  401. static inline int device_suspend(pm_message_t state)
  402. {
  403. return 0;
  404. }
  405. #define suspend_report_result(fn, ret) do {} while (0)
  406. #endif /* !CONFIG_PM_SLEEP */
  407. /*
  408. * Global Power Management flags
  409. * Used to keep APM and ACPI from both being active
  410. */
  411. extern unsigned int pm_flags;
  412. #define PM_APM 1
  413. #define PM_ACPI 2
  414. #endif /* _LINUX_PM_H */