Commit | Line | Data |
---|---|---|
b10d9117 | 1 | Suspend notifiers |
91e7c75b RW |
2 | (C) 2007-2011 Rafael J. Wysocki <rjw@sisk.pl>, GPL |
3 | ||
4 | There are some operations that subsystems or drivers may want to carry out | |
5 | before hibernation/suspend or after restore/resume, but they require the system | |
6 | to be fully functional, so the drivers' and subsystems' .suspend() and .resume() | |
7 | or even .prepare() and .complete() callbacks are not suitable for this purpose. | |
8 | For example, device drivers may want to upload firmware to their devices after | |
9 | resume/restore, but they cannot do it by calling request_firmware() from their | |
10 | .resume() or .complete() routines (user land processes are frozen at these | |
11 | points). The solution may be to load the firmware into memory before processes | |
12 | are frozen and upload it from there in the .resume() routine. | |
13 | A suspend/hibernation notifier may be used for this purpose. | |
14 | ||
15 | The subsystems or drivers having such needs can register suspend notifiers that | |
16 | will be called upon the following events by the PM core: | |
b10d9117 | 17 | |
6bc08ed0 BP |
18 | PM_HIBERNATION_PREPARE The system is going to hibernate, tasks will be frozen |
19 | immediately. This is different from PM_SUSPEND_PREPARE | |
20 | below because here we do additional work between notifiers | |
21 | and drivers freezing. | |
b10d9117 RW |
22 | |
23 | PM_POST_HIBERNATION The system memory state has been restored from a | |
91e7c75b RW |
24 | hibernation image or an error occurred during |
25 | hibernation. Device drivers' restore callbacks have | |
b10d9117 RW |
26 | been executed and tasks have been thawed. |
27 | ||
c3e94d89 | 28 | PM_RESTORE_PREPARE The system is going to restore a hibernation image. |
91e7c75b | 29 | If all goes well, the restored kernel will issue a |
c3e94d89 AS |
30 | PM_POST_HIBERNATION notification. |
31 | ||
91e7c75b RW |
32 | PM_POST_RESTORE An error occurred during restore from hibernation. |
33 | Device drivers' restore callbacks have been executed | |
c3e94d89 AS |
34 | and tasks have been thawed. |
35 | ||
91e7c75b | 36 | PM_SUSPEND_PREPARE The system is preparing for suspend. |
b10d9117 | 37 | |
25985edc | 38 | PM_POST_SUSPEND The system has just resumed or an error occurred during |
91e7c75b RW |
39 | suspend. Device drivers' resume callbacks have been |
40 | executed and tasks have been thawed. | |
b10d9117 RW |
41 | |
42 | It is generally assumed that whatever the notifiers do for | |
43 | PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously, | |
44 | operations performed for PM_SUSPEND_PREPARE should be reversed for | |
45 | PM_POST_SUSPEND. Additionally, all of the notifiers are called for | |
46 | PM_POST_HIBERNATION if one of them fails for PM_HIBERNATION_PREPARE, and | |
47 | all of the notifiers are called for PM_POST_SUSPEND if one of them fails for | |
48 | PM_SUSPEND_PREPARE. | |
49 | ||
50 | The hibernation and suspend notifiers are called with pm_mutex held. They are | |
51 | defined in the usual way, but their last argument is meaningless (it is always | |
52 | NULL). To register and/or unregister a suspend notifier use the functions | |
53 | register_pm_notifier() and unregister_pm_notifier(), respectively, defined in | |
54 | include/linux/suspend.h . If you don't need to unregister the notifier, you can | |
55 | also use the pm_notifier() macro defined in include/linux/suspend.h . |