Documentation/admin-guide/pm/suspend-flows.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/pm/suspend-flows.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/pm/suspend-flows.rst
Extension
.rst
Size
11801 bytes
Lines
271
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>

=========================
System Suspend Code Flows
=========================

:Copyright: |copy| 2020 Intel Corporation

:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

At least one global system-wide transition needs to be carried out for the
system to get from the working state into one of the supported
:doc:`sleep states <sleep-states>`.  Hibernation requires more than one
transition to occur for this purpose, but the other sleep states, commonly
referred to as *system-wide suspend* (or simply *system suspend*) states, need
only one.

For those sleep states, the transition from the working state of the system into
the target sleep state is referred to as *system suspend* too (in the majority
of cases, whether this means a transition or a sleep state of the system should
be clear from the context) and the transition back from the sleep state into the
working state is referred to as *system resume*.

The kernel code flows associated with the suspend and resume transitions for
different sleep states of the system are quite similar, but there are some
significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
:ref:`standby <standby>` sleep states.

The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
cannot be implemented without platform support and the difference between them
boils down to the platform-specific actions carried out by the suspend and
resume hooks that need to be provided by the platform driver to make them
available.  Apart from that, the suspend and resume code flows for these sleep
states are mostly identical, so they both together will be referred to as
*platform-dependent suspend* states in what follows.


.. _s2idle_suspend:

Suspend-to-idle Suspend Code Flow
=================================

The following steps are taken in order to transition the system from the working
state to the :ref:`suspend-to-idle <s2idle>` sleep state:

 1. Invoking system-wide suspend notifiers.

    Kernel subsystems can register callbacks to be invoked when the suspend
    transition is about to occur and when the resume transition has finished.

    That allows them to prepare for the change of the system state and to clean
    up after getting back to the working state.

 2. Freezing tasks.

    Tasks are frozen primarily in order to avoid unchecked hardware accesses
    from user space through MMIO regions or I/O registers exposed directly to
    it and to prevent user space from entering the kernel while the next step
    of the transition is in progress (which might have been problematic for
    various reasons).

    All user space tasks are intercepted as though they were sent a signal and
    put into uninterruptible sleep until the end of the subsequent system resume
    transition.

    The kernel threads that choose to be frozen during system suspend for
    specific reasons are frozen subsequently, but they are not intercepted.
    Instead, they are expected to periodically check whether or not they need

Annotation

Implementation Notes