2019-04-04 06:04:43 +08:00
|
|
|
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
|
2017-02-02 08:38:54 +08:00
|
|
|
=============================
|
|
|
|
|
Suspend/Hibernation Notifiers
|
|
|
|
|
=============================
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
Copyright (c) 2016 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
|
|
|
|
|
|
There are some operations that subsystems or drivers may want to carry out
|
|
|
|
|
before hibernation/suspend or after restore/resume, but they require the system
|
|
|
|
|
to be fully functional, so the drivers' and subsystems' ``->suspend()`` and
|
|
|
|
|
``->resume()`` or even ``->prepare()`` and ``->complete()`` callbacks are not
|
|
|
|
|
suitable for this purpose.
|
|
|
|
|
|
|
|
|
|
For example, device drivers may want to upload firmware to their devices after
|
|
|
|
|
resume/restore, but they cannot do it by calling :c:func:`request_firmware()`
|
|
|
|
|
from their ``->resume()`` or ``->complete()`` callback routines (user land
|
|
|
|
|
processes are frozen at these points). The solution may be to load the firmware
|
|
|
|
|
into memory before processes are frozen and upload it from there in the
|
|
|
|
|
``->resume()`` routine. A suspend/hibernation notifier may be used for that.
|
|
|
|
|
|
|
|
|
|
Subsystems or drivers having such needs can register suspend notifiers that
|
|
|
|
|
will be called upon the following events by the PM core:
|
|
|
|
|
|
|
|
|
|
``PM_HIBERNATION_PREPARE``
|
|
|
|
|
The system is going to hibernate, tasks will be frozen immediately. This
|
|
|
|
|
is different from ``PM_SUSPEND_PREPARE`` below, because in this case
|
|
|
|
|
additional work is done between the notifiers and the invocation of PM
|
|
|
|
|
callbacks for the "freeze" transition.
|
|
|
|
|
|
|
|
|
|
``PM_POST_HIBERNATION``
|
|
|
|
|
The system memory state has been restored from a hibernation image or an
|
|
|
|
|
error occurred during hibernation. Device restore 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 image kernel will issue a ``PM_POST_HIBERNATION``
|
|
|
|
|
notification.
|
|
|
|
|
|
|
|
|
|
``PM_POST_RESTORE``
|
|
|
|
|
An error occurred during restore from hibernation. Device restore
|
|
|
|
|
callbacks have been executed and tasks have been thawed.
|
|
|
|
|
|
|
|
|
|
``PM_SUSPEND_PREPARE``
|
|
|
|
|
The system is preparing for suspend.
|
|
|
|
|
|
|
|
|
|
``PM_POST_SUSPEND``
|
|
|
|
|
The system has just resumed or an error occurred during suspend. Device
|
|
|
|
|
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 carried out for ``PM_SUSPEND_PREPARE`` should be
|
|
|
|
|
reversed for ``PM_POST_SUSPEND``.
|
|
|
|
|
|
|
|
|
|
Moreover, if one of the notifiers fails for the ``PM_HIBERNATION_PREPARE`` or
|
|
|
|
|
``PM_SUSPEND_PREPARE`` event, the notifiers that have already succeeded for that
|
|
|
|
|
event will be called for ``PM_POST_HIBERNATION`` or ``PM_POST_SUSPEND``,
|
|
|
|
|
respectively.
|
|
|
|
|
|
|
|
|
|
The hibernation and suspend notifiers are called with :c:data:`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
|
|
|
|
|
:c:func:`register_pm_notifier()` and :c:func:`unregister_pm_notifier()`,
|
|
|
|
|
respectively (both defined in :file:`include/linux/suspend.h`). If you don't
|
|
|
|
|
need to unregister the notifier, you can also use the :c:func:`pm_notifier()`
|
|
|
|
|
macro defined in :file:`include/linux/suspend.h`.
|
