| Suspend notifiers |
| (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL |
| |
| There are some operations that device drivers may want to carry out in their |
| .suspend() routines, but shouldn't, because they can cause the hibernation or |
| suspend to fail. For example, a driver may want to allocate a substantial amount |
| of memory (like 50 MB) in .suspend(), but that shouldn't be done after the |
| swsusp's memory shrinker has run. |
| |
| Also, there may be some operations, that subsystems want to carry out before a |
| hibernation/suspend or after a restore/resume, requiring the system to be fully |
| functional, so the drivers' .suspend() and .resume() routines are not suitable |
| for this purpose. For example, device drivers may want to upload firmware to |
| their devices after a restore from a hibernation image, but they cannot do it by |
| calling request_firmware() from their .resume() routines (user land processes |
| are frozen at this point). The solution may be to load the firmware into |
| memory before processes are frozen and upload it from there in the .resume() |
| routine. Of course, a hibernation notifier may be used for this purpose. |
| |
| The subsystems that have such needs can register suspend notifiers that will be |
| called upon the following events by the suspend core: |
| |
| PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will |
| be frozen immediately. |
| |
| PM_POST_HIBERNATION The system memory state has been restored from a |
| hibernation image or an error occured during the |
| hibernation. Device drivers' .resume() callbacks have |
| been executed and tasks have been thawed. |
| |
| PM_RESTORE_PREPARE The system is going to restore a hibernation image. |
| If all goes well the restored kernel will issue a |
| PM_POST_HIBERNATION notification. |
| |
| PM_POST_RESTORE An error occurred during the hibernation restore. |
| Device drivers' .resume() callbacks have been executed |
| and tasks have been thawed. |
| |
| PM_SUSPEND_PREPARE The system is preparing for a suspend. |
| |
| PM_POST_SUSPEND The system has just resumed or an error occured during |
| the suspend. Device drivers' .resume() callbacks have |
| been executed and tasks have been thawed. |
| |
| It is generally assumed that whatever the notifiers do for |
| PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously, |
| operations performed for PM_SUSPEND_PREPARE should be reversed for |
| PM_POST_SUSPEND. Additionally, all of the notifiers are called for |
| PM_POST_HIBERNATION if one of them fails for PM_HIBERNATION_PREPARE, and |
| all of the notifiers are called for PM_POST_SUSPEND if one of them fails for |
| PM_SUSPEND_PREPARE. |
| |
| The hibernation and suspend notifiers are called with pm_mutex held. They are |
| defined in the usual way, but their last argument is meaningless (it is always |
| NULL). To register and/or unregister a suspend notifier use the functions |
| register_pm_notifier() and unregister_pm_notifier(), respectively, defined in |
| include/linux/suspend.h . If you don't need to unregister the notifier, you can |
| also use the pm_notifier() macro defined in include/linux/suspend.h . |