€•Ç     Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ/translations/zh_CN/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ/translations/zh_TW/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ/translations/it_IT/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ/translations/ja_JP/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ/translations/ko_KR/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ/translations/sp_SP/power/pci”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒPCI Power Management”h]”hŒPCI Power Management”…””}”(hh¨hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hh£hžhhŸŒ7/var/lib/git/docbuild/linux/Documentation/power/pci.rst”h KubhŒ	paragraph”“”)”}”(hŒ?Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.”h]”(hŒ&Copyright (c) 2010 Rafael J. Wysocki <”…””}”(hh¹hžhhŸNh NubhŒ	reference”“”)”}”(hŒrjw@sisk.pl”h]”hŒrjw@sisk.pl”…””}”(hhÃhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:rjw@sisk.pl”uh1hÁhh¹ubhŒ>, Novell Inc.”…””}”(hh¹hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khh£hžhubh¸)”}”(hŒ©An overview of concepts and the Linux kernel's interfaces related to PCI power
management.  Based on previous work by Patrick Mochel <mochel@transmeta.com>
(and others).”h]”(hŒˆAn overview of concepts and the Linux kernelâ€™s interfaces related to PCI power
management.  Based on previous work by Patrick Mochel <”…””}”(hhÝhžhhŸNh NubhÂ)”}”(hŒmochel@transmeta.com”h]”hŒmochel@transmeta.com”…””}”(hhåhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:mochel@transmeta.com”uh1hÁhhÝubhŒ>
(and others).”…””}”(hhÝhžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khh£hžhubh¸)”}”(hX  This document only covers the aspects of power management specific to PCI
devices.  For general description of the kernel's interfaces related to device
power management refer to Documentation/driver-api/pm/devices.rst and
Documentation/power/runtime_pm.rst.”h]”hX  This document only covers the aspects of power management specific to PCI
devices.  For general description of the kernelâ€™s interfaces related to device
power management refer to Documentation/driver-api/pm/devices.rst and
Documentation/power/runtime_pm.rst.”…””}”(hhÿhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khh£hžhubhŒcomment”“”)”}”(hŒ©contents:

1. Hardware and Platform Support for PCI Power Management
2. PCI Subsystem and Device Power Management
3. PCI Device Drivers and Power Management
4. Resources”h]”hŒ©contents:

1. Hardware and Platform Support for PCI Power Management
2. PCI Subsystem and Device Power Management
3. PCI Device Drivers and Power Management
4. Resources”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1j  hh£hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ91. Hardware and Platform Support for PCI Power Management”h]”hŒ91. Hardware and Platform Support for PCI Power Management”…””}”(hj"  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ/1.1. Native and Platform-Based Power Management”h]”hŒ/1.1. Native and Platform-Based Power Management”…””}”(hj3  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj0  hžhhŸh¶h Kubh¸)”}”(hŒËIn general, power management is a feature allowing one to save energy by putting
devices into states in which they draw less power (low-power states) at the
price of reduced functionality or performance.”h]”hŒËIn general, power management is a feature allowing one to save energy by putting
devices into states in which they draw less power (low-power states) at the
price of reduced functionality or performance.”…””}”(hjA  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khj0  hžhubh¸)”}”(hXŸ  Usually, a device is put into a low-power state when it is underutilized or
completely inactive.  However, when it is necessary to use the device once
again, it has to be put back into the "fully functional" state (full-power
state).  This may happen when there are some data for the device to handle or
as a result of an external event requiring the device to be active, which may
be signaled by the device itself.”h]”hX£  Usually, a device is put into a low-power state when it is underutilized or
completely inactive.  However, when it is necessary to use the device once
again, it has to be put back into the â€œfully functionalâ€ state (full-power
state).  This may happen when there are some data for the device to handle or
as a result of an external event requiring the device to be active, which may
be signaled by the device itself.”…””}”(hjO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K"hj0  hžhubh¸)”}”(hXY  PCI devices may be put into low-power states in two ways, by using the device
capabilities introduced by the PCI Bus Power Management Interface Specification,
or with the help of platform firmware, such as an ACPI BIOS.  In the first
approach, that is referred to as the native PCI power management (native PCI PM)
in what follows, the device power state is changed as a result of writing a
specific value into one of its standard configuration registers.  The second
approach requires the platform firmware to provide special methods that may be
used by the kernel to change the device's power state.”h]”hX[  PCI devices may be put into low-power states in two ways, by using the device
capabilities introduced by the PCI Bus Power Management Interface Specification,
or with the help of platform firmware, such as an ACPI BIOS.  In the first
approach, that is referred to as the native PCI power management (native PCI PM)
in what follows, the device power state is changed as a result of writing a
specific value into one of its standard configuration registers.  The second
approach requires the platform firmware to provide special methods that may be
used by the kernel to change the deviceâ€™s power state.”…””}”(hj]  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K)hj0  hžhubh¸)”}”(hXò  Devices supporting the native PCI PM usually can generate wakeup signals called
Power Management Events (PMEs) to let the kernel know about external events
requiring the device to be active.  After receiving a PME the kernel is supposed
to put the device that sent it into the full-power state.  However, the PCI Bus
Power Management Interface Specification doesn't define any standard method of
delivering the PME from the device to the CPU and the operating system kernel.
It is assumed that the platform firmware will perform this task and therefore,
even though a PCI device is set up to generate PMEs, it also may be necessary to
prepare the platform firmware for notifying the CPU of the PMEs coming from the
device (e.g. by generating interrupts).”h]”hXô  Devices supporting the native PCI PM usually can generate wakeup signals called
Power Management Events (PMEs) to let the kernel know about external events
requiring the device to be active.  After receiving a PME the kernel is supposed
to put the device that sent it into the full-power state.  However, the PCI Bus
Power Management Interface Specification doesnâ€™t define any standard method of
delivering the PME from the device to the CPU and the operating system kernel.
It is assumed that the platform firmware will perform this task and therefore,
even though a PCI device is set up to generate PMEs, it also may be necessary to
prepare the platform firmware for notifying the CPU of the PMEs coming from the
device (e.g. by generating interrupts).”…””}”(hjk  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K2hj0  hžhubh¸)”}”(hXŠ  In turn, if the methods provided by the platform firmware are used for changing
the power state of a device, usually the platform also provides a method for
preparing the device to generate wakeup signals.  In that case, however, it
often also is necessary to prepare the device for generating PMEs using the
native PCI PM mechanism, because the method provided by the platform depends on
that.”h]”hXŠ  In turn, if the methods provided by the platform firmware are used for changing
the power state of a device, usually the platform also provides a method for
preparing the device to generate wakeup signals.  In that case, however, it
often also is necessary to prepare the device for generating PMEs using the
native PCI PM mechanism, because the method provided by the platform depends on
that.”…””}”(hjy  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K=hj0  hžhubh¸)”}”(hŒ—Thus in many situations both the native and the platform-based power management
mechanisms have to be used simultaneously to obtain the desired result.”h]”hŒ—Thus in many situations both the native and the platform-based power management
mechanisms have to be used simultaneously to obtain the desired result.”…””}”(hj‡  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KDhj0  hžhubeh}”(h]”Œ*native-and-platform-based-power-management”ah ]”h"]”Œ/1.1. native and platform-based power management”ah$]”h&]”uh1h¡hj  hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ 1.2. Native PCI Power Management”h]”hŒ 1.2. Native PCI Power Management”…””}”(hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h KHubh¸)”}”(hŒáThe PCI Bus Power Management Interface Specification (PCI PM Spec) was
introduced between the PCI 2.1 and PCI 2.2 Specifications.  It defined a
standard interface for performing various operations related to power
management.”h]”hŒáThe PCI Bus Power Management Interface Specification (PCI PM Spec) was
introduced between the PCI 2.1 and PCI 2.2 Specifications.  It defined a
standard interface for performing various operations related to power
management.”…””}”(hj®  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KJhj  hžhubh¸)”}”(hXd  The implementation of the PCI PM Spec is optional for conventional PCI devices,
but it is mandatory for PCI Express devices.  If a device supports the PCI PM
Spec, it has an 8 byte power management capability field in its PCI
configuration space.  This field is used to describe and control the standard
features related to the native PCI power management.”h]”hXd  The implementation of the PCI PM Spec is optional for conventional PCI devices,
but it is mandatory for PCI Express devices.  If a device supports the PCI PM
Spec, it has an 8 byte power management capability field in its PCI
configuration space.  This field is used to describe and control the standard
features related to the native PCI power management.”…””}”(hj¼  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KOhj  hžhubh¸)”}”(hX3  The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses
(B0-B3).  The higher the number, the less power is drawn by the device or bus
in that state.  However, the higher the number, the longer the latency for
the device or bus to return to the full-power state (D0 or B0, respectively).”h]”hX3  The PCI PM Spec defines 4 operating states for devices (D0-D3) and for buses
(B0-B3).  The higher the number, the less power is drawn by the device or bus
in that state.  However, the higher the number, the longer the latency for
the device or bus to return to the full-power state (D0 or B0, respectively).”…””}”(hjÊ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KUhj  hžhubh¸)”}”(hX   There are two variants of the D3 state defined by the specification.  The first
one is D3hot, referred to as the software accessible D3, because devices can be
programmed to go into it.  The second one, D3cold, is the state that PCI devices
are in when the supply voltage (Vcc) is removed from them.  It is not possible
to program a PCI device to go into D3cold, although there may be a programmable
interface for putting the bus the device is on into a state in which Vcc is
removed from all devices on the bus.”h]”hX   There are two variants of the D3 state defined by the specification.  The first
one is D3hot, referred to as the software accessible D3, because devices can be
programmed to go into it.  The second one, D3cold, is the state that PCI devices
are in when the supply voltage (Vcc) is removed from them.  It is not possible
to program a PCI device to go into D3cold, although there may be a programmable
interface for putting the bus the device is on into a state in which Vcc is
removed from all devices on the bus.”…””}”(hjØ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KZhj  hžhubh¸)”}”(hŒ•PCI bus power management, however, is not supported by the Linux kernel at the
time of this writing and therefore it is not covered by this document.”h]”hŒ•PCI bus power management, however, is not supported by the Linux kernel at the
time of this writing and therefore it is not covered by this document.”…””}”(hjæ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kbhj  hžhubh¸)”}”(hX-  Note that every PCI device can be in the full-power state (D0) or in D3cold,
regardless of whether or not it implements the PCI PM Spec.  In addition to
that, if the PCI PM Spec is implemented by the device, it must support D3hot
as well as D0.  The support for the D1 and D2 power states is optional.”h]”hX-  Note that every PCI device can be in the full-power state (D0) or in D3cold,
regardless of whether or not it implements the PCI PM Spec.  In addition to
that, if the PCI PM Spec is implemented by the device, it must support D3hot
as well as D0.  The support for the D1 and D2 power states is optional.”…””}”(hjô  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kehj  hžhubh¸)”}”(hXf  PCI devices supporting the PCI PM Spec can be programmed to go to any of the
supported low-power states (except for D3cold).  While in D1-D3hot the
standard configuration registers of the device must be accessible to software
(i.e. the device is required to respond to PCI configuration accesses), although
its I/O and memory spaces are then disabled.  This allows the device to be
programmatically put into D0.  Thus the kernel can switch the device back and
forth between D0 and the supported low-power states (except for D3cold) and the
possible power state transitions the device can undergo are the following:”h]”hXf  PCI devices supporting the PCI PM Spec can be programmed to go to any of the
supported low-power states (except for D3cold).  While in D1-D3hot the
standard configuration registers of the device must be accessible to software
(i.e. the device is required to respond to PCI configuration accesses), although
its I/O and memory spaces are then disabled.  This allows the device to be
programmatically put into D0.  Thus the kernel can switch the device back and
forth between D0 and the supported low-power states (except for D3cold) and the
possible power state transitions the device can undergo are the following:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kjhj  hžhubhŒtable”“”)”}”(hhh]”hŒtgroup”“”)”}”(hhh]”(hŒcolspec”“”)”}”(hhh]”h}”(h]”h ]”h"]”h$]”h&]”Œcolwidth”Kuh1j  hj  ubhŒtbody”“”)”}”(hhh]”(hŒrow”“”)”}”(hhh]”hŒentry”“”)”}”(hhh]”h¸)”}”(hŒCurrent State | New State”h]”hŒCurrent State | New State”…””}”(hj5  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kthj2  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj-  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j+  hj(  ubj,  )”}”(hhh]”j1  )”}”(hhh]”h¸)”}”(hŒD0            | D1, D2, D3”h]”hŒD0            | D1, D2, D3”…””}”(hjU  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KvhjR  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjO  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j+  hj(  ubj,  )”}”(hhh]”j1  )”}”(hhh]”h¸)”}”(hŒD1            | D2, D3”h]”hŒD1            | D2, D3”…””}”(hju  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kxhjr  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjo  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j+  hj(  ubj,  )”}”(hhh]”j1  )”}”(hhh]”h¸)”}”(hŒD2            | D3”h]”hŒD2            | D3”…””}”(hj•  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kzhj’  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j+  hj(  ubj,  )”}”(hhh]”j1  )”}”(hhh]”h¸)”}”(hŒD1, D2, D3    | D0”h]”hŒD1, D2, D3    | D0”…””}”(hjµ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K|hj²  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj¯  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j+  hj(  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j&  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”Œcols”Kuh1j  hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  hžhhŸh¶h Nubh¸)”}”(hX  The transition from D3cold to D0 occurs when the supply voltage is provided to
the device (i.e. power is restored).  In that case the device returns to D0 with
a full power-on reset sequence and the power-on defaults are restored to the
device by hardware just as at initial power up.”h]”hX  The transition from D3cold to D0 occurs when the supply voltage is provided to
the device (i.e. power is restored).  In that case the device returns to D0 with
a full power-on reset sequence and the power-on defaults are restored to the
device by hardware just as at initial power up.”…””}”(hjâ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khj  hžhubh¸)”}”(hXœ  PCI devices supporting the PCI PM Spec can be programmed to generate PMEs
while in any power state (D0-D3), but they are not required to be capable
of generating PMEs from all supported power states.  In particular, the
capability of generating PMEs from D3cold is optional and depends on the
presence of additional voltage (3.3Vaux) allowing the device to remain
sufficiently active to generate a wakeup signal.”h]”hXœ  PCI devices supporting the PCI PM Spec can be programmed to generate PMEs
while in any power state (D0-D3), but they are not required to be capable
of generating PMEs from all supported power states.  In particular, the
capability of generating PMEs from D3cold is optional and depends on the
presence of additional voltage (3.3Vaux) allowing the device to remain
sufficiently active to generate a wakeup signal.”…””}”(hjð  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K„hj  hžhubeh}”(h]”Œnative-pci-power-management”ah ]”h"]”Œ 1.2. native pci power management”ah$]”h&]”uh1h¡hj  hžhhŸh¶h KHubh¢)”}”(hhh]”(h§)”}”(hŒ!1.3. ACPI Device Power Management”h]”hŒ!1.3. ACPI Device Power Management”…””}”(hj	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h KŒubh¸)”}”(hXY  The platform firmware support for the power management of PCI devices is
system-specific.  However, if the system in question is compliant with the
Advanced Configuration and Power Interface (ACPI) Specification, like the
majority of x86-based systems, it is supposed to implement device power
management interfaces defined by the ACPI standard.”h]”hXY  The platform firmware support for the power management of PCI devices is
system-specific.  However, if the system in question is compliant with the
Advanced Configuration and Power Interface (ACPI) Specification, like the
majority of x86-based systems, it is supposed to implement device power
management interfaces defined by the ACPI standard.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KŽhj  hžhubh¸)”}”(hX–  For this purpose the ACPI BIOS provides special functions called "control
methods" that may be executed by the kernel to perform specific tasks, such as
putting a device into a low-power state.  These control methods are encoded
using special byte-code language called the ACPI Machine Language (AML) and
stored in the machine's BIOS.  The kernel loads them from the BIOS and executes
them as needed using an AML interpreter that translates the AML byte code into
computations and memory or I/O space accesses.  This way, in theory, a BIOS
writer can provide the kernel with a means to perform actions depending
on the system design in a system-specific fashion.”h]”hXœ  For this purpose the ACPI BIOS provides special functions called â€œcontrol
methodsâ€ that may be executed by the kernel to perform specific tasks, such as
putting a device into a low-power state.  These control methods are encoded
using special byte-code language called the ACPI Machine Language (AML) and
stored in the machineâ€™s BIOS.  The kernel loads them from the BIOS and executes
them as needed using an AML interpreter that translates the AML byte code into
computations and memory or I/O space accesses.  This way, in theory, a BIOS
writer can provide the kernel with a means to perform actions depending
on the system design in a system-specific fashion.”…””}”(hj%  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K”hj  hžhubh¸)”}”(hXÒ  ACPI control methods may be divided into global control methods, that are not
associated with any particular devices, and device control methods, that have
to be defined separately for each device supposed to be handled with the help of
the platform.  This means, in particular, that ACPI device control methods can
only be used to handle devices that the BIOS writer knew about in advance.  The
ACPI methods used for device power management fall into that category.”h]”hXÒ  ACPI control methods may be divided into global control methods, that are not
associated with any particular devices, and device control methods, that have
to be defined separately for each device supposed to be handled with the help of
the platform.  This means, in particular, that ACPI device control methods can
only be used to handle devices that the BIOS writer knew about in advance.  The
ACPI methods used for device power management fall into that category.”…””}”(hj3  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kžhj  hžhubh¸)”}”(hX>  The ACPI specification assumes that devices can be in one of four power states
labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
D0-D3 states (although the difference between D3hot and D3cold is not taken
into account by ACPI).  Moreover, for each power state of a device there is a
set of power resources that have to be enabled for the device to be put into
that state.  These power resources are controlled (i.e. enabled or disabled)
with the help of their own control methods, _ON and _OFF, that have to be
defined individually for each of them.”h]”hX>  The ACPI specification assumes that devices can be in one of four power states
labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
D0-D3 states (although the difference between D3hot and D3cold is not taken
into account by ACPI).  Moreover, for each power state of a device there is a
set of power resources that have to be enabled for the device to be put into
that state.  These power resources are controlled (i.e. enabled or disabled)
with the help of their own control methods, _ON and _OFF, that have to be
defined individually for each of them.”…””}”(hjA  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K¥hj  hžhubh¸)”}”(hX2  To put a device into the ACPI power state Dx (where x is a number between 0 and
3 inclusive) the kernel is supposed to (1) enable the power resources required
by the device in this state using their _ON control methods and (2) execute the
_PSx control method defined for the device.  In addition to that, if the device
is going to be put into a low-power state (D1-D3) and is supposed to generate
wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI
3.0) control method defined for it has to be executed before _PSx.  Power
resources that are not required by the device in the target power state and are
not required any more by any other device should be disabled (by executing their
_OFF control methods).  If the current power state of the device is D3, it can
only be put into D0 this way.”h]”hX2  To put a device into the ACPI power state Dx (where x is a number between 0 and
3 inclusive) the kernel is supposed to (1) enable the power resources required
by the device in this state using their _ON control methods and (2) execute the
_PSx control method defined for the device.  In addition to that, if the device
is going to be put into a low-power state (D1-D3) and is supposed to generate
wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI
3.0) control method defined for it has to be executed before _PSx.  Power
resources that are not required by the device in the target power state and are
not required any more by any other device should be disabled (by executing their
_OFF control methods).  If the current power state of the device is D3, it can
only be put into D0 this way.”…””}”(hjO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K®hj  hžhubh¸)”}”(hXÞ  However, quite often the power states of devices are changed during a
system-wide transition into a sleep state or back into the working state.  ACPI
defines four system sleep states, S1, S2, S3, and S4, and denotes the system
working state as S0.  In general, the target system sleep (or working) state
determines the highest power (lowest number) state the device can be put
into and the kernel is supposed to obtain this information by executing the
device's _SxD control method (where x is a number between 0 and 4 inclusive).
If the device is required to wake up the system from the target sleep state, the
lowest power (highest number) state it can be put into is also determined by the
target state of the system.  The kernel is then supposed to use the device's
_SxW control method to obtain the number of that state.  It also is supposed to
use the device's _PRW control method to learn which power resources need to be
enabled for the device to be able to generate wakeup signals.”h]”hXä  However, quite often the power states of devices are changed during a
system-wide transition into a sleep state or back into the working state.  ACPI
defines four system sleep states, S1, S2, S3, and S4, and denotes the system
working state as S0.  In general, the target system sleep (or working) state
determines the highest power (lowest number) state the device can be put
into and the kernel is supposed to obtain this information by executing the
deviceâ€™s _SxD control method (where x is a number between 0 and 4 inclusive).
If the device is required to wake up the system from the target sleep state, the
lowest power (highest number) state it can be put into is also determined by the
target state of the system.  The kernel is then supposed to use the deviceâ€™s
_SxW control method to obtain the number of that state.  It also is supposed to
use the deviceâ€™s _PRW control method to learn which power resources need to be
enabled for the device to be able to generate wakeup signals.”…””}”(hj]  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kºhj  hžhubeh}”(h]”Œacpi-device-power-management”ah ]”h"]”Œ!1.3. acpi device power management”ah$]”h&]”uh1h¡hj  hžhhŸh¶h KŒubh¢)”}”(hhh]”(h§)”}”(hŒ1.4. Wakeup Signaling”h]”hŒ1.4. Wakeup Signaling”…””}”(hjv  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjs  hžhhŸh¶h KÉubh¸)”}”(hXU  Wakeup signals generated by PCI devices, either as native PCI PMEs, or as
a result of the execution of the _DSW (or _PSW) ACPI control method before
putting the device into a low-power state, have to be caught and handled as
appropriate.  If they are sent while the system is in the working state
(ACPI S0), they should be translated into interrupts so that the kernel can
put the devices generating them into the full-power state and take care of the
events that triggered them.  In turn, if they are sent while the system is
sleeping, they should cause the system's core logic to trigger wakeup.”h]”hXW  Wakeup signals generated by PCI devices, either as native PCI PMEs, or as
a result of the execution of the _DSW (or _PSW) ACPI control method before
putting the device into a low-power state, have to be caught and handled as
appropriate.  If they are sent while the system is in the working state
(ACPI S0), they should be translated into interrupts so that the kernel can
put the devices generating them into the full-power state and take care of the
events that triggered them.  In turn, if they are sent while the system is
sleeping, they should cause the systemâ€™s core logic to trigger wakeup.”…””}”(hj„  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KËhjs  hžhubh¸)”}”(hX3  On ACPI-based systems wakeup signals sent by conventional PCI devices are
converted into ACPI General-Purpose Events (GPEs) which are hardware signals
from the system core logic generated in response to various events that need to
be acted upon.  Every GPE is associated with one or more sources of potentially
interesting events.  In particular, a GPE may be associated with a PCI device
capable of signaling wakeup.  The information on the connections between GPEs
and event sources is recorded in the system's ACPI BIOS from where it can be
read by the kernel.”h]”hX5  On ACPI-based systems wakeup signals sent by conventional PCI devices are
converted into ACPI General-Purpose Events (GPEs) which are hardware signals
from the system core logic generated in response to various events that need to
be acted upon.  Every GPE is associated with one or more sources of potentially
interesting events.  In particular, a GPE may be associated with a PCI device
capable of signaling wakeup.  The information on the connections between GPEs
and event sources is recorded in the systemâ€™s ACPI BIOS from where it can be
read by the kernel.”…””}”(hj’  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÔhjs  hžhubh¸)”}”(hX‘  If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE
associated with it (if there is one) is triggered.  The GPEs associated with PCI
bridges may also be triggered in response to a wakeup signal from one of the
devices below the bridge (this also is the case for root bridges) and, for
example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be
handled this way.”h]”hX•  If a PCI device known to the systemâ€™s ACPI BIOS signals wakeup, the GPE
associated with it (if there is one) is triggered.  The GPEs associated with PCI
bridges may also be triggered in response to a wakeup signal from one of the
devices below the bridge (this also is the case for root bridges) and, for
example, native PCI PMEs from devices unknown to the systemâ€™s ACPI BIOS may be
handled this way.”…””}”(hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÝhjs  hžhubh¸)”}”(hXK  A GPE may be triggered when the system is sleeping (i.e. when it is in one of
the ACPI S1-S4 states), in which case system wakeup is started by its core logic
(the device that was the source of the signal causing the system wakeup to occur
may be identified later).  The GPEs used in such situations are referred to as
wakeup GPEs.”h]”hXK  A GPE may be triggered when the system is sleeping (i.e. when it is in one of
the ACPI S1-S4 states), in which case system wakeup is started by its core logic
(the device that was the source of the signal causing the system wakeup to occur
may be identified later).  The GPEs used in such situations are referred to as
wakeup GPEs.”…””}”(hj®  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kähjs  hžhubh¸)”}”(hX  Usually, however, GPEs are also triggered when the system is in the working
state (ACPI S0) and in that case the system's core logic generates a System
Control Interrupt (SCI) to notify the kernel of the event.  Then, the SCI
handler identifies the GPE that caused the interrupt to be generated which,
in turn, allows the kernel to identify the source of the event (that may be
a PCI device signaling wakeup).  The GPEs used for notifying the kernel of
events occurring while the system is in the working state are referred to as
runtime GPEs.”h]”hX!  Usually, however, GPEs are also triggered when the system is in the working
state (ACPI S0) and in that case the systemâ€™s core logic generates a System
Control Interrupt (SCI) to notify the kernel of the event.  Then, the SCI
handler identifies the GPE that caused the interrupt to be generated which,
in turn, allows the kernel to identify the source of the event (that may be
a PCI device signaling wakeup).  The GPEs used for notifying the kernel of
events occurring while the system is in the working state are referred to as
runtime GPEs.”…””}”(hj¼  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kêhjs  hžhubh¸)”}”(hX  Unfortunately, there is no standard way of handling wakeup signals sent by
conventional PCI devices on systems that are not ACPI-based, but there is one
for PCI Express devices.  Namely, the PCI Express Base Specification introduced
a native mechanism for converting native PCI PMEs into interrupts generated by
root ports.  For conventional PCI devices native PMEs are out-of-band, so they
are routed separately and they need not pass through bridges (in principle they
may be routed directly to the system's core logic), but for PCI Express devices
they are in-band messages that have to pass through the PCI Express hierarchy,
including the root port on the path from the device to the Root Complex.  Thus
it was possible to introduce a mechanism by which a root port generates an
interrupt whenever it receives a PME message from one of the devices below it.
The PCI Express Requester ID of the device that sent the PME message is then
recorded in one of the root port's configuration registers from where it may be
read by the interrupt handler allowing the device to be identified.  [PME
messages sent by PCI Express endpoints integrated with the Root Complex don't
pass through root ports, but instead they cause a Root Complex Event Collector
(if there is one) to generate interrupts.]”h]”hX  Unfortunately, there is no standard way of handling wakeup signals sent by
conventional PCI devices on systems that are not ACPI-based, but there is one
for PCI Express devices.  Namely, the PCI Express Base Specification introduced
a native mechanism for converting native PCI PMEs into interrupts generated by
root ports.  For conventional PCI devices native PMEs are out-of-band, so they
are routed separately and they need not pass through bridges (in principle they
may be routed directly to the systemâ€™s core logic), but for PCI Express devices
they are in-band messages that have to pass through the PCI Express hierarchy,
including the root port on the path from the device to the Root Complex.  Thus
it was possible to introduce a mechanism by which a root port generates an
interrupt whenever it receives a PME message from one of the devices below it.
The PCI Express Requester ID of the device that sent the PME message is then
recorded in one of the root portâ€™s configuration registers from where it may be
read by the interrupt handler allowing the device to be identified.  [PME
messages sent by PCI Express endpoints integrated with the Root Complex donâ€™t
pass through root ports, but instead they cause a Root Complex Event Collector
(if there is one) to generate interrupts.]”…””}”(hjÊ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kóhjs  hžhubh¸)”}”(hXÚ  In principle the native PCI Express PME signaling may also be used on ACPI-based
systems along with the GPEs, but to use it the kernel has to ask the system's
ACPI BIOS to release control of root port configuration registers.  The ACPI
BIOS, however, is not required to allow the kernel to control these registers
and if it doesn't do that, the kernel must not modify their contents.  Of course
the native PCI Express PME signaling cannot be used by the kernel in that case.”h]”hXÞ  In principle the native PCI Express PME signaling may also be used on ACPI-based
systems along with the GPEs, but to use it the kernel has to ask the systemâ€™s
ACPI BIOS to release control of root port configuration registers.  The ACPI
BIOS, however, is not required to allow the kernel to control these registers
and if it doesnâ€™t do that, the kernel must not modify their contents.  Of course
the native PCI Express PME signaling cannot be used by the kernel in that case.”…””}”(hjØ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjs  hžhubeh}”(h]”Œwakeup-signaling”ah ]”h"]”Œ1.4. wakeup signaling”ah$]”h&]”uh1h¡hj  hžhhŸh¶h KÉubeh}”(h]”Œ6hardware-and-platform-support-for-pci-power-management”ah ]”h"]”Œ91. hardware and platform support for pci power management”ah$]”h&]”uh1h¡hh£hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ,2. PCI Subsystem and Device Power Management”h]”hŒ,2. PCI Subsystem and Device Power Management”…””}”(hjù  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjö  hžhhŸh¶h Mubh¢)”}”(hhh]”(h§)”}”(hŒ&2.1. Device Power Management Callbacks”h]”hŒ&2.1. Device Power Management Callbacks”…””}”(hj
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h Mubh¸)”}”(hX¬  The PCI Subsystem participates in the power management of PCI devices in a
number of ways.  First of all, it provides an intermediate code layer between
the device power management core (PM core) and PCI device drivers.
Specifically, the pm field of the PCI subsystem's struct bus_type object,
pci_bus_type, points to a struct dev_pm_ops object, pci_dev_pm_ops, containing
pointers to several device power management callbacks::”h]”hX­  The PCI Subsystem participates in the power management of PCI devices in a
number of ways.  First of all, it provides an intermediate code layer between
the device power management core (PM core) and PCI device drivers.
Specifically, the pm field of the PCI subsystemâ€™s struct bus_type object,
pci_bus_type, points to a struct dev_pm_ops object, pci_dev_pm_ops, containing
pointers to several device power management callbacks:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  hžhubhŒliteral_block”“”)”}”(hXÀ  const struct dev_pm_ops pci_dev_pm_ops = {
      .prepare = pci_pm_prepare,
      .complete = pci_pm_complete,
      .suspend = pci_pm_suspend,
      .resume = pci_pm_resume,
      .freeze = pci_pm_freeze,
      .thaw = pci_pm_thaw,
      .poweroff = pci_pm_poweroff,
      .restore = pci_pm_restore,
      .suspend_noirq = pci_pm_suspend_noirq,
      .resume_noirq = pci_pm_resume_noirq,
      .freeze_noirq = pci_pm_freeze_noirq,
      .thaw_noirq = pci_pm_thaw_noirq,
      .poweroff_noirq = pci_pm_poweroff_noirq,
      .restore_noirq = pci_pm_restore_noirq,
      .runtime_suspend = pci_pm_runtime_suspend,
      .runtime_resume = pci_pm_runtime_resume,
      .runtime_idle = pci_pm_runtime_idle,
};”h]”hXÀ  const struct dev_pm_ops pci_dev_pm_ops = {
      .prepare = pci_pm_prepare,
      .complete = pci_pm_complete,
      .suspend = pci_pm_suspend,
      .resume = pci_pm_resume,
      .freeze = pci_pm_freeze,
      .thaw = pci_pm_thaw,
      .poweroff = pci_pm_poweroff,
      .restore = pci_pm_restore,
      .suspend_noirq = pci_pm_suspend_noirq,
      .resume_noirq = pci_pm_resume_noirq,
      .freeze_noirq = pci_pm_freeze_noirq,
      .thaw_noirq = pci_pm_thaw_noirq,
      .poweroff_noirq = pci_pm_poweroff_noirq,
      .restore_noirq = pci_pm_restore_noirq,
      .runtime_suspend = pci_pm_runtime_suspend,
      .runtime_resume = pci_pm_runtime_resume,
      .runtime_idle = pci_pm_runtime_idle,
};”…””}”hj(  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h Mhj  hžhubh¸)”}”(hXY  These callbacks are executed by the PM core in various situations related to
device power management and they, in turn, execute power management callbacks
provided by PCI device drivers.  They also perform power management operations
involving some standard configuration registers of PCI devices that device
drivers need not know or care about.”h]”hXY  These callbacks are executed by the PM core in various situations related to
device power management and they, in turn, execute power management callbacks
provided by PCI device drivers.  They also perform power management operations
involving some standard configuration registers of PCI devices that device
drivers need not know or care about.”…””}”(hj6  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M.hj  hžhubh¸)”}”(hŒrThe structure representing a PCI device, struct pci_dev, contains several fields
that these callbacks operate on::”h]”hŒqThe structure representing a PCI device, struct pci_dev, contains several fields
that these callbacks operate on:”…””}”(hjD  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M4hj  hžhubj'  )”}”(hX6  struct pci_dev {
      ...
      pci_power_t     current_state;  /* Current operating state. */
      int             pm_cap;         /* PM capability offset in the
                                         configuration space */
      unsigned int    pme_support:5;  /* Bitmask of states from which PME#
                                         can be generated */
      unsigned int    pme_poll:1;     /* Poll device's PME status bit */
      unsigned int    d1_support:1;   /* Low power state D1 is supported */
      unsigned int    d2_support:1;   /* Low power state D2 is supported */
      unsigned int    no_d1d2:1;      /* D1 and D2 are forbidden */
      unsigned int    wakeup_prepared:1;  /* Device prepared for wake up */
      unsigned int    d3hot_delay;    /* D3hot->D0 transition time in ms */
      ...
};”h]”hX6  struct pci_dev {
      ...
      pci_power_t     current_state;  /* Current operating state. */
      int             pm_cap;         /* PM capability offset in the
                                         configuration space */
      unsigned int    pme_support:5;  /* Bitmask of states from which PME#
                                         can be generated */
      unsigned int    pme_poll:1;     /* Poll device's PME status bit */
      unsigned int    d1_support:1;   /* Low power state D1 is supported */
      unsigned int    d2_support:1;   /* Low power state D2 is supported */
      unsigned int    no_d1d2:1;      /* D1 and D2 are forbidden */
      unsigned int    wakeup_prepared:1;  /* Device prepared for wake up */
      unsigned int    d3hot_delay;    /* D3hot->D0 transition time in ms */
      ...
};”…””}”hjR  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h M7hj  hžhubh¸)”}”(hŒ]They also indirectly use some fields of the struct device that is embedded in
struct pci_dev.”h]”hŒ]They also indirectly use some fields of the struct device that is embedded in
struct pci_dev.”…””}”(hj`  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MGhj  hžhubeh}”(h]”Œ!device-power-management-callbacks”ah ]”h"]”Œ&2.1. device power management callbacks”ah$]”h&]”uh1h¡hjö  hžhhŸh¶h Mubh¢)”}”(hhh]”(h§)”}”(hŒ2.2. Device Initialization”h]”hŒ2.2. Device Initialization”…””}”(hjy  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjv  hžhhŸh¶h MKubh¸)”}”(hX  The PCI subsystem's first task related to device power management is to
prepare the device for power management and initialize the fields of struct
pci_dev used for this purpose.  This happens in two functions defined in
drivers/pci/, pci_pm_init() and pci_acpi_setup().”h]”hX  The PCI subsystemâ€™s first task related to device power management is to
prepare the device for power management and initialize the fields of struct
pci_dev used for this purpose.  This happens in two functions defined in
drivers/pci/, pci_pm_init() and pci_acpi_setup().”…””}”(hj‡  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MMhjv  hžhubh¸)”}”(hXA  The first of these functions checks if the device supports native PCI PM
and if that's the case the offset of its power management capability structure
in the configuration space is stored in the pm_cap field of the device's struct
pci_dev object.  Next, the function checks which PCI low-power states are
supported by the device and from which low-power states the device can generate
native PCI PMEs.  The power management fields of the device's struct pci_dev and
the struct device embedded in it are updated accordingly and the generation of
PMEs by the device is disabled.”h]”hXG  The first of these functions checks if the device supports native PCI PM
and if thatâ€™s the case the offset of its power management capability structure
in the configuration space is stored in the pm_cap field of the deviceâ€™s struct
pci_dev object.  Next, the function checks which PCI low-power states are
supported by the device and from which low-power states the device can generate
native PCI PMEs.  The power management fields of the deviceâ€™s struct pci_dev and
the struct device embedded in it are updated accordingly and the generation of
PMEs by the device is disabled.”…””}”(hj•  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MRhjv  hžhubh¸)”}”(hXQ  The second function checks if the device can be prepared to signal wakeup with
the help of the platform firmware, such as the ACPI BIOS.  If that is the case,
the function updates the wakeup fields in struct device embedded in the
device's struct pci_dev and uses the firmware-provided method to prevent the
device from signaling wakeup.”h]”hXS  The second function checks if the device can be prepared to signal wakeup with
the help of the platform firmware, such as the ACPI BIOS.  If that is the case,
the function updates the wakeup fields in struct device embedded in the
deviceâ€™s struct pci_dev and uses the firmware-provided method to prevent the
device from signaling wakeup.”…””}”(hj£  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M[hjv  hžhubh¸)”}”(hŒìAt this point the device is ready for power management.  For driverless devices,
however, this functionality is limited to a few basic operations carried out
during system-wide transitions to a sleep state and back to the working state.”h]”hŒìAt this point the device is ready for power management.  For driverless devices,
however, this functionality is limited to a few basic operations carried out
during system-wide transitions to a sleep state and back to the working state.”…””}”(hj±  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mahjv  hžhubeh}”(h]”Œdevice-initialization”ah ]”h"]”Œ2.2. device initialization”ah$]”h&]”uh1h¡hjö  hžhhŸh¶h MKubh¢)”}”(hhh]”(h§)”}”(hŒ$2.3. Runtime Device Power Management”h]”hŒ$2.3. Runtime Device Power Management”…””}”(hjÊ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjÇ  hžhhŸh¶h Mfubh¸)”}”(hX  The PCI subsystem plays a vital role in the runtime power management of PCI
devices.  For this purpose it uses the general runtime power management
(runtime PM) framework described in Documentation/power/runtime_pm.rst.
Namely, it provides subsystem-level callbacks::”h]”hX
  The PCI subsystem plays a vital role in the runtime power management of PCI
devices.  For this purpose it uses the general runtime power management
(runtime PM) framework described in Documentation/power/runtime_pm.rst.
Namely, it provides subsystem-level callbacks:”…””}”(hjØ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MhhjÇ  hžhubj'  )”}”(hŒFpci_pm_runtime_suspend()
pci_pm_runtime_resume()
pci_pm_runtime_idle()”h]”hŒFpci_pm_runtime_suspend()
pci_pm_runtime_resume()
pci_pm_runtime_idle()”…””}”hjæ  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h MmhjÇ  hžhubh¸)”}”(hXE  that are executed by the core runtime PM routines.  It also implements the
entire mechanics necessary for handling runtime wakeup signals from PCI devices
in low-power states, which at the time of this writing works for both the native
PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in
Section 1.”h]”hXE  that are executed by the core runtime PM routines.  It also implements the
entire mechanics necessary for handling runtime wakeup signals from PCI devices
in low-power states, which at the time of this writing works for both the native
PCI Express PME signaling and the ACPI GPE-based wakeup signaling described in
Section 1.”…””}”(hjô  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MqhjÇ  hžhubh¸)”}”(hX?  First, a PCI device is put into a low-power state, or suspended, with the help
of pm_schedule_suspend() or pm_runtime_suspend() which for PCI devices call
pci_pm_runtime_suspend() to do the actual job.  For this to work, the device's
driver has to provide a pm->runtime_suspend() callback (see below), which is
run by pci_pm_runtime_suspend() as the first action.  If the driver's callback
returns successfully, the device's standard configuration registers are saved,
the device is prepared to generate wakeup signals and, finally, it is put into
the target low-power state.”h]”hXE  First, a PCI device is put into a low-power state, or suspended, with the help
of pm_schedule_suspend() or pm_runtime_suspend() which for PCI devices call
pci_pm_runtime_suspend() to do the actual job.  For this to work, the deviceâ€™s
driver has to provide a pm->runtime_suspend() callback (see below), which is
run by pci_pm_runtime_suspend() as the first action.  If the driverâ€™s callback
returns successfully, the deviceâ€™s standard configuration registers are saved,
the device is prepared to generate wakeup signals and, finally, it is put into
the target low-power state.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MwhjÇ  hžhubh¸)”}”(hXö  The low-power state to put the device into is the lowest-power (highest number)
state from which it can signal wakeup.  The exact method of signaling wakeup is
system-dependent and is determined by the PCI subsystem on the basis of the
reported capabilities of the device and the platform firmware.  To prepare the
device for signaling wakeup and put it into the selected low-power state, the
PCI subsystem can use the platform firmware as well as the device's native PCI
PM capabilities, if supported.”h]”hXø  The low-power state to put the device into is the lowest-power (highest number)
state from which it can signal wakeup.  The exact method of signaling wakeup is
system-dependent and is determined by the PCI subsystem on the basis of the
reported capabilities of the device and the platform firmware.  To prepare the
device for signaling wakeup and put it into the selected low-power state, the
PCI subsystem can use the platform firmware as well as the deviceâ€™s native PCI
PM capabilities, if supported.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M€hjÇ  hžhubh¸)”}”(hX  It is expected that the device driver's pm->runtime_suspend() callback will
not attempt to prepare the device for signaling wakeup or to put it into a
low-power state.  The driver ought to leave these tasks to the PCI subsystem
that has all of the information necessary to perform them.”h]”hX   It is expected that the device driverâ€™s pm->runtime_suspend() callback will
not attempt to prepare the device for signaling wakeup or to put it into a
low-power state.  The driver ought to leave these tasks to the PCI subsystem
that has all of the information necessary to perform them.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MˆhjÇ  hžhubh¸)”}”(hXh  A suspended device is brought back into the "active" state, or resumed,
with the help of pm_request_resume() or pm_runtime_resume() which both call
pci_pm_runtime_resume() for PCI devices.  Again, this only works if the device's
driver provides a pm->runtime_resume() callback (see below).  However, before
the driver's callback is executed, pci_pm_runtime_resume() brings the device
back into the full-power state, prevents it from signaling wakeup while in that
state and restores its standard configuration registers.  Thus the driver's
callback need not worry about the PCI-specific aspects of the device resume.”h]”hXr  A suspended device is brought back into the â€œactiveâ€ state, or resumed,
with the help of pm_request_resume() or pm_runtime_resume() which both call
pci_pm_runtime_resume() for PCI devices.  Again, this only works if the deviceâ€™s
driver provides a pm->runtime_resume() callback (see below).  However, before
the driverâ€™s callback is executed, pci_pm_runtime_resume() brings the device
back into the full-power state, prevents it from signaling wakeup while in that
state and restores its standard configuration registers.  Thus the driverâ€™s
callback need not worry about the PCI-specific aspects of the device resume.”…””}”(hj,  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MhjÇ  hžhubh¸)”}”(hX!  Note that generally pci_pm_runtime_resume() may be called in two different
situations.  First, it may be called at the request of the device's driver, for
example if there are some data for it to process.  Second, it may be called
as a result of a wakeup signal from the device itself (this sometimes is
referred to as "remote wakeup").  Of course, for this purpose the wakeup signal
is handled in one of the ways described in Section 1 and finally converted into
a notification for the PCI subsystem after the source device has been
identified.”h]”hX'  Note that generally pci_pm_runtime_resume() may be called in two different
situations.  First, it may be called at the request of the deviceâ€™s driver, for
example if there are some data for it to process.  Second, it may be called
as a result of a wakeup signal from the device itself (this sometimes is
referred to as â€œremote wakeupâ€).  Of course, for this purpose the wakeup signal
is handled in one of the ways described in Section 1 and finally converted into
a notification for the PCI subsystem after the source device has been
identified.”…””}”(hj:  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M–hjÇ  hžhubh¸)”}”(hX¾  The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle()
and pm_request_idle(), executes the device driver's pm->runtime_idle()
callback, if defined, and if that callback doesn't return error code (or is not
present at all), suspends the device with the help of pm_runtime_suspend().
Sometimes pci_pm_runtime_idle() is called automatically by the PM core (for
example, it is called right after the device has just been resumed), in which
cases it is expected to suspend the device if that makes sense.  Usually,
however, the PCI subsystem doesn't really know if the device really can be
suspended, so it lets the device's driver decide by running its
pm->runtime_idle() callback.”h]”hXÆ  The pci_pm_runtime_idle() function, called for PCI devices by pm_runtime_idle()
and pm_request_idle(), executes the device driverâ€™s pm->runtime_idle()
callback, if defined, and if that callback doesnâ€™t return error code (or is not
present at all), suspends the device with the help of pm_runtime_suspend().
Sometimes pci_pm_runtime_idle() is called automatically by the PM core (for
example, it is called right after the device has just been resumed), in which
cases it is expected to suspend the device if that makes sense.  Usually,
however, the PCI subsystem doesnâ€™t really know if the device really can be
suspended, so it lets the deviceâ€™s driver decide by running its
pm->runtime_idle() callback.”…””}”(hjH  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MŸhjÇ  hžhubeh}”(h]”Œruntime-device-power-management”ah ]”h"]”Œ$2.3. runtime device power management”ah$]”h&]”uh1h¡hjö  hžhhŸh¶h Mfubh¢)”}”(hhh]”(h§)”}”(hŒ"2.4. System-Wide Power Transitions”h]”hŒ"2.4. System-Wide Power Transitions”…””}”(hja  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj^  hžhhŸh¶h M«ubh¸)”}”(hXú  There are a few different types of system-wide power transitions, described in
Documentation/driver-api/pm/devices.rst.  Each of them requires devices to be
handled in a specific way and the PM core executes subsystem-level power
management callbacks for this purpose.  They are executed in phases such that
each phase involves executing the same subsystem-level callback for every device
belonging to the given subsystem before the next phase begins.  These phases
always run after tasks have been frozen.”h]”hXú  There are a few different types of system-wide power transitions, described in
Documentation/driver-api/pm/devices.rst.  Each of them requires devices to be
handled in a specific way and the PM core executes subsystem-level power
management callbacks for this purpose.  They are executed in phases such that
each phase involves executing the same subsystem-level callback for every device
belonging to the given subsystem before the next phase begins.  These phases
always run after tasks have been frozen.”…””}”(hjo  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¬hj^  hžhubh¢)”}”(hhh]”(h§)”}”(hŒ2.4.1. System Suspend”h]”hŒ2.4.1. System Suspend”…””}”(hj€  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj}  hžhhŸh¶h Mµubh¸)”}”(hŒšWhen the system is going into a sleep state in which the contents of memory will
be preserved, such as one of the ACPI sleep states S1-S3, the phases are:”h]”hŒšWhen the system is going into a sleep state in which the contents of memory will
be preserved, such as one of the ACPI sleep states S1-S3, the phases are:”…””}”(hjŽ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M·hj}  hžhubhŒblock_quote”“”)”}”(hŒ!prepare, suspend, suspend_noirq.
”h]”h¸)”}”(hŒ prepare, suspend, suspend_noirq.”h]”hŒ prepare, suspend, suspend_noirq.”…””}”(hj¢  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mºhjž  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h Mºhj}  hžhubh¸)”}”(hŒPThe following PCI bus type's callbacks, respectively, are used in these phases::”h]”hŒQThe following PCI bus typeâ€™s callbacks, respectively, are used in these phases:”…””}”(hj¶  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¼hj}  hžhubj'  )”}”(hŒ8pci_pm_prepare()
pci_pm_suspend()
pci_pm_suspend_noirq()”h]”hŒ8pci_pm_prepare()
pci_pm_suspend()
pci_pm_suspend_noirq()”…””}”hjÄ  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h M¾hj}  hžhubh¸)”}”(hX/  The pci_pm_prepare() routine first puts the device into the "fully functional"
state with the help of pm_runtime_resume().  Then, it executes the device
driver's pm->prepare() callback if defined (i.e. if the driver's struct
dev_pm_ops object is present and the prepare pointer in that object is valid).”h]”hX7  The pci_pm_prepare() routine first puts the device into the â€œfully functionalâ€
state with the help of pm_runtime_resume().  Then, it executes the device
driverâ€™s pm->prepare() callback if defined (i.e. if the driverâ€™s struct
dev_pm_ops object is present and the prepare pointer in that object is valid).”…””}”(hjÒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÂhj}  hžhubh¸)”}”(hX  The pci_pm_suspend() routine first checks if the device's driver implements
legacy PCI suspend routines (see Section 3), in which case the driver's legacy
suspend callback is executed, if present, and its result is returned.  Next, if
the device's driver doesn't provide a struct dev_pm_ops object (containing
pointers to the driver's callbacks), pci_pm_default_suspend() is called, which
simply turns off the device's bus master capability and runs
pcibios_disable_device() to disable it, unless the device is a bridge (PCI
bridges are ignored by this routine).  Next, the device driver's pm->suspend()
callback is executed, if defined, and its result is returned if it fails.
Finally, pci_fixup_device() is called to apply hardware suspend quirks related
to the device if necessary.”h]”hX  The pci_pm_suspend() routine first checks if the deviceâ€™s driver implements
legacy PCI suspend routines (see Section 3), in which case the driverâ€™s legacy
suspend callback is executed, if present, and its result is returned.  Next, if
the deviceâ€™s driver doesnâ€™t provide a struct dev_pm_ops object (containing
pointers to the driverâ€™s callbacks), pci_pm_default_suspend() is called, which
simply turns off the deviceâ€™s bus master capability and runs
pcibios_disable_device() to disable it, unless the device is a bridge (PCI
bridges are ignored by this routine).  Next, the device driverâ€™s pm->suspend()
callback is executed, if defined, and its result is returned if it fails.
Finally, pci_fixup_device() is called to apply hardware suspend quirks related
to the device if necessary.”…””}”(hjà  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÇhj}  hžhubh¸)”}”(hX;  Note that the suspend phase is carried out asynchronously for PCI devices, so
the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
devices that don't depend on each other in a known way (i.e. none of the paths
in the device tree from the root bridge to a leaf device contains both of them).”h]”hX=  Note that the suspend phase is carried out asynchronously for PCI devices, so
the pci_pm_suspend() callback may be executed in parallel for any pair of PCI
devices that donâ€™t depend on each other in a known way (i.e. none of the paths
in the device tree from the root bridge to a leaf device contains both of them).”…””}”(hjî  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÓhj}  hžhubh¸)”}”(hX  The pci_pm_suspend_noirq() routine is executed after suspend_device_irqs() has
been called, which means that the device driver's interrupt handler won't be
invoked while this routine is running.  It first checks if the device's driver
implements legacy PCI suspends routines (Section 3), in which case the legacy
late suspend routine is called and its result is returned (the standard
configuration registers of the device are saved if the driver's callback hasn't
done that).  Second, if the device driver's struct dev_pm_ops object is not
present, the device's standard configuration registers are saved and the routine
returns success.  Otherwise the device driver's pm->suspend_noirq() callback is
executed, if present, and its result is returned if it fails.  Next, if the
device's standard configuration registers haven't been saved yet (one of the
device driver's callbacks executed before might do that), pci_pm_suspend_noirq()
saves them, prepares the device to signal wakeup (if necessary) and puts it into
a low-power state.”h]”hX!  The pci_pm_suspend_noirq() routine is executed after suspend_device_irqs() has
been called, which means that the device driverâ€™s interrupt handler wonâ€™t be
invoked while this routine is running.  It first checks if the deviceâ€™s driver
implements legacy PCI suspends routines (Section 3), in which case the legacy
late suspend routine is called and its result is returned (the standard
configuration registers of the device are saved if the driverâ€™s callback hasnâ€™t
done that).  Second, if the device driverâ€™s struct dev_pm_ops object is not
present, the deviceâ€™s standard configuration registers are saved and the routine
returns success.  Otherwise the device driverâ€™s pm->suspend_noirq() callback is
executed, if present, and its result is returned if it fails.  Next, if the
deviceâ€™s standard configuration registers havenâ€™t been saved yet (one of the
device driverâ€™s callbacks executed before might do that), pci_pm_suspend_noirq()
saves them, prepares the device to signal wakeup (if necessary) and puts it into
a low-power state.”…””}”(hjü  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MØhj}  hžhubh¸)”}”(hX«  The low-power state to put the device into is the lowest-power (highest number)
state from which it can signal wakeup while the system is in the target sleep
state.  Just like in the runtime PM case described above, the mechanism of
signaling wakeup is system-dependent and determined by the PCI subsystem, which
is also responsible for preparing the device to signal wakeup from the system's
target sleep state as appropriate.”h]”hX­  The low-power state to put the device into is the lowest-power (highest number)
state from which it can signal wakeup while the system is in the target sleep
state.  Just like in the runtime PM case described above, the mechanism of
signaling wakeup is system-dependent and determined by the PCI subsystem, which
is also responsible for preparing the device to signal wakeup from the systemâ€™s
target sleep state as appropriate.”…””}”(hj
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mçhj}  hžhubh¸)”}”(hXµ  PCI device drivers (that don't implement legacy power management callbacks) are
generally not expected to prepare devices for signaling wakeup or to put them
into low-power states.  However, if one of the driver's suspend callbacks
(pm->suspend() or pm->suspend_noirq()) saves the device's standard configuration
registers, pci_pm_suspend_noirq() will assume that the device has been prepared
to signal wakeup and put into a low-power state by the driver (the driver is
then assumed to have used the helper functions provided by the PCI subsystem for
this purpose).  PCI device drivers are not encouraged to do that, but in some
rare cases doing that in the driver may be the optimum approach.”•½     h]”hX»  PCI device drivers (that donâ€™t implement legacy power management callbacks) are
generally not expected to prepare devices for signaling wakeup or to put them
into low-power states.  However, if one of the driverâ€™s suspend callbacks
(pm->suspend() or pm->suspend_noirq()) saves the deviceâ€™s standard configuration
registers, pci_pm_suspend_noirq() will assume that the device has been prepared
to signal wakeup and put into a low-power state by the driver (the driver is
then assumed to have used the helper functions provided by the PCI subsystem for
this purpose).  PCI device drivers are not encouraged to do that, but in some
rare cases doing that in the driver may be the optimum approach.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mîhj}  hžhubeh}”(h]”Œsystem-suspend”ah ]”h"]”Œ2.4.1. system suspend”ah$]”h&]”uh1h¡hj^  hžhhŸh¶h Mµubh¢)”}”(hhh]”(h§)”}”(hŒ2.4.2. System Resume”h]”hŒ2.4.2. System Resume”…””}”(hj1  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj.  hžhhŸh¶h Mùubh¸)”}”(hŒÐWhen the system is undergoing a transition from a sleep state in which the
contents of memory have been preserved, such as one of the ACPI sleep states
S1-S3, into the working state (ACPI S0), the phases are:”h]”hŒÐWhen the system is undergoing a transition from a sleep state in which the
contents of memory have been preserved, such as one of the ACPI sleep states
S1-S3, into the working state (ACPI S0), the phases are:”…””}”(hj?  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mûhj.  hžhubj  )”}”(hŒ resume_noirq, resume, complete.
”h]”h¸)”}”(hŒresume_noirq, resume, complete.”h]”hŒresume_noirq, resume, complete.”…””}”(hjQ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÿhjM  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h Mÿhj.  hžhubh¸)”}”(hŒTThe following PCI bus type's callbacks, respectively, are executed in these
phases::”h]”hŒUThe following PCI bus typeâ€™s callbacks, respectively, are executed in these
phases:”…””}”(hje  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj.  hžhubj'  )”}”(hŒ7pci_pm_resume_noirq()
pci_pm_resume()
pci_pm_complete()”h]”hŒ7pci_pm_resume_noirq()
pci_pm_resume()
pci_pm_complete()”…””}”hjs  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h Mhj.  hžhubh¸)”}”(hX«  The pci_pm_resume_noirq() routine first puts the device into the full-power
state, restores its standard configuration registers and applies early resume
hardware quirks related to the device, if necessary.  This is done
unconditionally, regardless of whether or not the device's driver implements
legacy PCI power management callbacks (this way all PCI devices are in the
full-power state and their standard configuration registers have been restored
when their interrupt handlers are invoked for the first time during resume,
which allows the kernel to avoid problems with the handling of shared interrupts
by drivers whose devices are still suspended).  If legacy PCI power management
callbacks (see Section 3) are implemented by the device's driver, the legacy
early resume callback is executed and its result is returned.  Otherwise, the
device driver's pm->resume_noirq() callback is executed, if defined, and its
result is returned.”h]”hX±  The pci_pm_resume_noirq() routine first puts the device into the full-power
state, restores its standard configuration registers and applies early resume
hardware quirks related to the device, if necessary.  This is done
unconditionally, regardless of whether or not the deviceâ€™s driver implements
legacy PCI power management callbacks (this way all PCI devices are in the
full-power state and their standard configuration registers have been restored
when their interrupt handlers are invoked for the first time during resume,
which allows the kernel to avoid problems with the handling of shared interrupts
by drivers whose devices are still suspended).  If legacy PCI power management
callbacks (see Section 3) are implemented by the deviceâ€™s driver, the legacy
early resume callback is executed and its result is returned.  Otherwise, the
device driverâ€™s pm->resume_noirq() callback is executed, if defined, and its
result is returned.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj.  hžhubh¸)”}”(hX|  The pci_pm_resume() routine first checks if the device's standard configuration
registers have been restored and restores them if that's not the case (this
only is necessary in the error path during a failing suspend).  Next, resume
hardware quirks related to the device are applied, if necessary, and if the
device's driver implements legacy PCI power management callbacks (see
Section 3), the driver's legacy resume callback is executed and its result is
returned.  Otherwise, the device's wakeup signaling mechanisms are blocked and
its driver's pm->resume() callback is executed, if defined (the callback's
result is then returned).”h]”hXŠ  The pci_pm_resume() routine first checks if the deviceâ€™s standard configuration
registers have been restored and restores them if thatâ€™s not the case (this
only is necessary in the error path during a failing suspend).  Next, resume
hardware quirks related to the device are applied, if necessary, and if the
deviceâ€™s driver implements legacy PCI power management callbacks (see
Section 3), the driverâ€™s legacy resume callback is executed and its result is
returned.  Otherwise, the deviceâ€™s wakeup signaling mechanisms are blocked and
its driverâ€™s pm->resume() callback is executed, if defined (the callbackâ€™s
result is then returned).”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj.  hžhubh¸)”}”(hX  The resume phase is carried out asynchronously for PCI devices, like the
suspend phase described above, which means that if two PCI devices don't depend
on each other in a known way, the pci_pm_resume() routine may be executed for
the both of them in parallel.”h]”hX  The resume phase is carried out asynchronously for PCI devices, like the
suspend phase described above, which means that if two PCI devices donâ€™t depend
on each other in a known way, the pci_pm_resume() routine may be executed for
the both of them in parallel.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M hj.  hžhubh¸)”}”(hŒdThe pci_pm_complete() routine only executes the device driver's pm->complete()
callback, if defined.”h]”hŒfThe pci_pm_complete() routine only executes the device driverâ€™s pm->complete()
callback, if defined.”…””}”(hj«  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M%hj.  hžhubeh}”(h]”Œsystem-resume”ah ]”h"]”Œ2.4.2. system resume”ah$]”h&]”uh1h¡hj^  hžhhŸh¶h Mùubh¢)”}”(hhh]”(h§)”}”(hŒ2.4.3. System Hibernation”h]”hŒ2.4.3. System Hibernation”…””}”(hjÄ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjÁ  hžhhŸh¶h M)ubh¸)”}”(hŒùSystem hibernation is more complicated than system suspend, because it requires
a system image to be created and written into a persistent storage medium.  The
image is created atomically and all devices are quiesced, or frozen, before that
happens.”h]”hŒùSystem hibernation is more complicated than system suspend, because it requires
a system image to be created and written into a persistent storage medium.  The
image is created atomically and all devices are quiesced, or frozen, before that
happens.”…””}”(hjÒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M+hjÁ  hžhubh¸)”}”(hŒÈThe freezing of devices is carried out after enough memory has been freed (at
the time of this writing the image creation requires at least 50% of system RAM
to be free) in the following three phases:”h]”hŒÈThe freezing of devices is carried out after enough memory has been freed (at
the time of this writing the image creation requires at least 50% of system RAM
to be free) in the following three phases:”…””}”(hjà  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M0hjÁ  hžhubj  )”}”(hŒprepare, freeze, freeze_noirq
”h]”h¸)”}”(hŒprepare, freeze, freeze_noirq”h]”hŒprepare, freeze, freeze_noirq”…””}”(hjò  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M4hjî  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h M4hjÁ  hžhubh¸)”}”(hŒ1that correspond to the PCI bus type's callbacks::”h]”hŒ2that correspond to the PCI bus typeâ€™s callbacks:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M6hjÁ  hžhubj'  )”}”(hŒ6pci_pm_prepare()
pci_pm_freeze()
pci_pm_freeze_noirq()”h]”hŒ6pci_pm_prepare()
pci_pm_freeze()
pci_pm_freeze_noirq()”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h M8hjÁ  hžhubh¸)”}”(hŒzThis means that the prepare phase is exactly the same as for system suspend.
The other two phases, however, are different.”h]”hŒzThis means that the prepare phase is exactly the same as for system suspend.
The other two phases, however, are different.”…””}”(hj"  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M<hjÁ  hžhubh¸)”}”(hXA  The pci_pm_freeze() routine is quite similar to pci_pm_suspend(), but it runs
the device driver's pm->freeze() callback, if defined, instead of pm->suspend(),
and it doesn't apply the suspend-related hardware quirks.  It is executed
asynchronously for different PCI devices that don't depend on each other in a
known way.”h]”hXG  The pci_pm_freeze() routine is quite similar to pci_pm_suspend(), but it runs
the device driverâ€™s pm->freeze() callback, if defined, instead of pm->suspend(),
and it doesnâ€™t apply the suspend-related hardware quirks.  It is executed
asynchronously for different PCI devices that donâ€™t depend on each other in a
known way.”…””}”(hj0  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M?hjÁ  hžhubh¸)”}”(hX  The pci_pm_freeze_noirq() routine, in turn, is similar to
pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq()
routine instead of pm->suspend_noirq().  It also doesn't attempt to prepare the
device for signaling wakeup and put it into a low-power state.  Still, it saves
the device's standard configuration registers if they haven't been saved by one
of the driver's callbacks.”h]”hXš  The pci_pm_freeze_noirq() routine, in turn, is similar to
pci_pm_suspend_noirq(), but it calls the device driverâ€™s pm->freeze_noirq()
routine instead of pm->suspend_noirq().  It also doesnâ€™t attempt to prepare the
device for signaling wakeup and put it into a low-power state.  Still, it saves
the deviceâ€™s standard configuration registers if they havenâ€™t been saved by one
of the driverâ€™s callbacks.”…””}”(hj>  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MEhjÁ  hžhubh¸)”}”(hX9  Once the image has been created, it has to be saved.  However, at this point all
devices are frozen and they cannot handle I/O, while their ability to handle
I/O is obviously necessary for the image saving.  Thus they have to be brought
back to the fully functional state and this is done in the following phases:”h]”hX9  Once the image has been created, it has to be saved.  However, at this point all
devices are frozen and they cannot handle I/O, while their ability to handle
I/O is obviously necessary for the image saving.  Thus they have to be brought
back to the fully functional state and this is done in the following phases:”…””}”(hjL  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MLhjÁ  hžhubj  )”}”(hŒthaw_noirq, thaw, complete
”h]”h¸)”}”(hŒthaw_noirq, thaw, complete”h]”hŒthaw_noirq, thaw, complete”…””}”(hj^  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MQhjZ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h MQhjÁ  hžhubh¸)”}”(hŒ.using the following PCI bus type's callbacks::”h]”hŒ/using the following PCI bus typeâ€™s callbacks:”…””}”(hjr  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MShjÁ  hžhubj'  )”}”(hŒ3pci_pm_thaw_noirq()
pci_pm_thaw()
pci_pm_complete()”h]”hŒ3pci_pm_thaw_noirq()
pci_pm_thaw()
pci_pm_complete()”…””}”hj€  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h MUhjÁ  hžhubh¸)”}”(hŒrespectively.”h]”hŒrespectively.”…””}”(hjŽ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MYhjÁ  hžhubh¸)”}”(hX  The first of them, pci_pm_thaw_noirq(), is analogous to pci_pm_resume_noirq().
It puts the device into the full power state and restores its standard
configuration registers.  It also executes the device driver's pm->thaw_noirq()
callback, if defined, instead of pm->resume_noirq().”h]”hX  The first of them, pci_pm_thaw_noirq(), is analogous to pci_pm_resume_noirq().
It puts the device into the full power state and restores its standard
configuration registers.  It also executes the device driverâ€™s pm->thaw_noirq()
callback, if defined, instead of pm->resume_noirq().”…””}”(hjœ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M[hjÁ  hžhubh¸)”}”(hŒîThe pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device
driver's pm->thaw() callback instead of pm->resume().  It is executed
asynchronously for different PCI devices that don't depend on each other in a
known way.”h]”hŒòThe pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device
driverâ€™s pm->thaw() callback instead of pm->resume().  It is executed
asynchronously for different PCI devices that donâ€™t depend on each other in a
known way.”…””}”(hjª  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M`hjÁ  hžhubh¸)”}”(hŒ4The complete phase is the same as for system resume.”h]”hŒ4The complete phase is the same as for system resume.”…””}”(hj¸  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MehjÁ  hžhubh¸)”}”(hŒ«After saving the image, devices need to be powered down before the system can
enter the target sleep state (ACPI S4 for ACPI-based systems).  This is done in
three phases:”h]”hŒ«After saving the image, devices need to be powered down before the system can
enter the target sleep state (ACPI S4 for ACPI-based systems).  This is done in
three phases:”…””}”(hjÆ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MghjÁ  hžhubj  )”}”(hŒ"prepare, poweroff, poweroff_noirq
”h]”h¸)”}”(hŒ!prepare, poweroff, poweroff_noirq”h]”hŒ!prepare, poweroff, poweroff_noirq”…””}”(hjØ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MkhjÔ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h MkhjÁ  hžhubh¸)”}”(hŒÔwhere the prepare phase is exactly the same as for system suspend.  The other
two phases are analogous to the suspend and suspend_noirq phases, respectively.
The PCI subsystem-level callbacks they correspond to::”h]”hŒÓwhere the prepare phase is exactly the same as for system suspend.  The other
two phases are analogous to the suspend and suspend_noirq phases, respectively.
The PCI subsystem-level callbacks they correspond to:”…””}”(hjì  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MmhjÁ  hžhubj'  )”}”(hŒ)pci_pm_poweroff()
pci_pm_poweroff_noirq()”h]”hŒ)pci_pm_poweroff()
pci_pm_poweroff_noirq()”…””}”hjú  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h MqhjÁ  hžhubh¸)”}”(hŒ¢work in analogy with pci_pm_suspend() and pci_pm_suspend_noirq(), respectively,
although they don't attempt to save the device's standard configuration
registers.”h]”hŒ¦work in analogy with pci_pm_suspend() and pci_pm_suspend_noirq(), respectively,
although they donâ€™t attempt to save the deviceâ€™s standard configuration
registers.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MthjÁ  hžhubeh}”(h]”Œsystem-hibernation”ah ]”h"]”Œ2.4.3. system hibernation”ah$]”h&]”uh1h¡hj^  hžhhŸh¶h M)ubh¢)”}”(hhh]”(h§)”}”(hŒ2.4.4. System Restore”h]”hŒ2.4.4. System Restore”…””}”(hj!  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h Myubh¸)”}”(hŒ¶System restore requires a hibernation image to be loaded into memory and the
pre-hibernation memory contents to be restored before the pre-hibernation system
activity can be resumed.”h]”hŒ¶System restore requires a hibernation image to be loaded into memory and the
pre-hibernation memory contents to be restored before the pre-hibernation system
activity can be resumed.”…””}”(hj/  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M{hj  hžhubh¸)”}”(hX  As described in Documentation/driver-api/pm/devices.rst, the hibernation image
is loaded into memory by a fresh instance of the kernel, called the boot kernel,
which in turn is loaded and run by a boot loader in the usual way.  After the
boot kernel has loaded the image, it needs to replace its own code and data with
the code and data of the "hibernated" kernel stored within the image, called the
image kernel.  For this purpose all devices are frozen just like before creating
the image during hibernation, in the”h]”hX	  As described in Documentation/driver-api/pm/devices.rst, the hibernation image
is loaded into memory by a fresh instance of the kernel, called the boot kernel,
which in turn is loaded and run by a boot loader in the usual way.  After the
boot kernel has loaded the image, it needs to replace its own code and data with
the code and data of the â€œhibernatedâ€ kernel stored within the image, called the
image kernel.  For this purpose all devices are frozen just like before creating
the image during hibernation, in the”…””}”(hj=  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  hžhubj  )”}”(hŒprepare, freeze, freeze_noirq
”h]”h¸)”}”(hŒprepare, freeze, freeze_noirq”h]”hŒprepare, freeze, freeze_noirq”…””}”(hjO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M‡hjK  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h M‡hj  hžhubh¸)”}”(hŒÁphases described above.  However, the devices affected by these phases are only
those having drivers in the boot kernel; other devices will still be in whatever
state the boot loader left them.”h]”hŒÁphases described above.  However, the devices affected by these phases are only
those having drivers in the boot kernel; other devices will still be in whatever
state the boot loader left them.”…””}”(hjc  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M‰hj  hžhubh¸)”}”(hX(  Should the restoration of the pre-hibernation memory contents fail, the boot
kernel would go through the "thawing" procedure described above, using the
thaw_noirq, thaw, and complete phases (that will only affect the devices having
drivers in the boot kernel), and then continue running normally.”h]”hX,  Should the restoration of the pre-hibernation memory contents fail, the boot
kernel would go through the â€œthawingâ€ procedure described above, using the
thaw_noirq, thaw, and complete phases (that will only affect the devices having
drivers in the boot kernel), and then continue running normally.”…””}”(hjq  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  hžhubh¸)”}”(hXŒ  If the pre-hibernation memory contents are restored successfully, which is the
usual situation, control is passed to the image kernel, which then becomes
responsible for bringing the system back to the working state.  To achieve this,
it must restore the devices' pre-hibernation functionality, which is done much
like waking up from the memory sleep state, although it involves different
phases:”h]”hXŽ  If the pre-hibernation memory contents are restored successfully, which is the
usual situation, control is passed to the image kernel, which then becomes
responsible for bringing the system back to the working state.  To achieve this,
it must restore the devicesâ€™ pre-hibernation functionality, which is done much
like waking up from the memory sleep state, although it involves different
phases:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M’hj  hžhubj  )”}”(hŒ!restore_noirq, restore, complete
”h]”h¸)”}”(hŒ restore_noirq, restore, complete”h]”hŒ restore_noirq, restore, complete”…””}”(hj‘  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M™hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h M™hj  hžhubh¸)”}”(hŒ£The first two of these are analogous to the resume_noirq and resume phases
described above, respectively, and correspond to the following PCI subsystem
callbacks::”h]”hŒ¢The first two of these are analogous to the resume_noirq and resume phases
described above, respectively, and correspond to the following PCI subsystem
callbacks:”…””}”(hj¥  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M›hj  hžhubj'  )”}”(hŒ'pci_pm_restore_noirq()
pci_pm_restore()”h]”hŒ'pci_pm_restore_noirq()
pci_pm_restore()”…””}”hj³  sbah}”(h]”h ]”h"]”h$]”h&]”j  j  uh1j&  hŸh¶h MŸhj  hžhubh¸)”}”(hŒÁThese callbacks work in analogy with pci_pm_resume_noirq() and pci_pm_resume(),
respectively, but they execute the device driver's pm->restore_noirq() and
pm->restore() callbacks, if available.”h]”hŒÃThese callbacks work in analogy with pci_pm_resume_noirq() and pci_pm_resume(),
respectively, but they execute the device driverâ€™s pm->restore_noirq() and
pm->restore() callbacks, if available.”…””}”(hjÁ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¢hj  hžhubh¸)”}”(hŒRThe complete phase is carried out in exactly the same way as during system
resume.”h]”hŒRThe complete phase is carried out in exactly the same way as during system
resume.”…””}”(hjÏ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¦hj  hžhubeh}”(h]”Œsystem-restore”ah ]”h"]”Œ2.4.4. system restore”ah$]”h&]”uh1h¡hj^  hžhhŸh¶h Myubeh}”(h]”Œsystem-wide-power-transitions”ah ]”h"]”Œ"2.4. system-wide power transitions”ah$]”h&]”uh1h¡hjö  hžhhŸh¶h M«ubeh}”(h]”Œ)pci-subsystem-and-device-power-management”ah ]”h"]”Œ,2. pci subsystem and device power management”ah$]”h&]”uh1h¡hh£hžhhŸh¶h Mubh¢)”}”(hhh]”(h§)”}”(hŒ*3. PCI Device Drivers and Power Management”h]”hŒ*3. PCI Device Drivers and Power Management”…””}”(hjø  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjõ  hžhhŸh¶h M«ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1. Power Management Callbacks”h]”hŒ3.1. Power Management Callbacks”…””}”(hj		  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj	  hžhhŸh¶h M®ubh¸)”}”(hŒÛPCI device drivers participate in power management by providing callbacks to be
executed by the PCI subsystem's power management routines described above and by
controlling the runtime power management of their devices.”h]”hŒÝPCI device drivers participate in power management by providing callbacks to be
executed by the PCI subsystemâ€™s power management routines described above and by
controlling the runtime power management of their devices.”…””}”(hj	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M°hj	  hžhubh¸)”}”(hX3  At the time of this writing there are two ways to define power management
callbacks for a PCI device driver, the recommended one, based on using a
dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and
the "legacy" one, in which the .suspend() and .resume() callbacks from struct
pci_driver are used.  The legacy approach, however, doesn't allow one to define
runtime power management callbacks and is not really suitable for any new
drivers.  Therefore it is not covered by this document (refer to the source code
to learn more about it).”h]”hX9  At the time of this writing there are two ways to define power management
callbacks for a PCI device driver, the recommended one, based on using a
dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and
the â€œlegacyâ€ one, in which the .suspend() and .resume() callbacks from struct
pci_driver are used.  The legacy approach, however, doesnâ€™t allow one to define
runtime power management callbacks and is not really suitable for any new
drivers.  Therefore it is not covered by this document (refer to the source code
to learn more about it).”…””}”(hj%	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M´hj	  hžhubh¸)”}”(hXÉ  It is recommended that all PCI device drivers define a struct dev_pm_ops object
containing pointers to power management (PM) callbacks that will be executed by
the PCI subsystem's PM routines in various circumstances.  A pointer to the
driver's struct dev_pm_ops object has to be assigned to the driver.pm field in
its struct pci_driver object.  Once that has happened, the "legacy" PM callbacks
in struct pci_driver are ignored (even if they are not NULL).”h]”hXÑ  It is recommended that all PCI device drivers define a struct dev_pm_ops object
containing pointers to power management (PM) callbacks that will be executed by
the PCI subsystemâ€™s PM routines in various circumstances.  A pointer to the
driverâ€™s struct dev_pm_ops object has to be assigned to the driver.pm field in
its struct pci_driver object.  Once that has happened, the â€œlegacyâ€ PM callbacks
in struct pci_driver are ignored (even if they are not NULL).”…””}”(hj3	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M½hj	  hžhubh¸)”}”(hX=  The PM callbacks in struct dev_pm_ops are not mandatory and if they are not
defined (i.e. the respective fields of struct dev_pm_ops are unset) the PCI
subsystem will handle the device in a simplified default manner.  If they are
defined, though, they are expected to behave as described in the following
subsections.”h]”hX=  The PM callbacks in struct dev_pm_ops are not mandatory and if they are not
defined (i.e. the respective fields of struct dev_pm_ops are unset) the PCI
subsystem will handle the device in a simplified default manner.  If they are
defined, though, they are expected to behave as described in the following
subsections.”…””}”(hjA	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÄhj	  hžhubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.1. prepare()”h]”hŒ3.1.1. prepare()”…””}”(hjR	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjO	  hžhhŸh¶h MËubh¸)”}”(hX  The prepare() callback is executed during system suspend, during hibernation
(when a hibernation image is about to be created), during power-off after
saving a hibernation image and during system restore, when a hibernation image
has just been loaded into memory.”h]”hX  The prepare() callback is executed during system suspend, during hibernation
(when a hibernation image is about to be created), during power-off after
saving a hibernation image and during system restore, when a hibernation image
has just been loaded into memory.”…””}”(hj`	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÍhjO	  hžhubh¸)”}”(hX6  This callback is only necessary if the driver's device has children that in
general may be registered at any time.  In that case the role of the prepare()
callback is to prevent new children of the device from being registered until
one of the resume_noirq(), thaw_noirq(), or restore_noirq() callbacks is run.”h]”hX8  This callback is only necessary if the driverâ€™s device has children that in
general may be registered at any time.  In that case the role of the prepare()
callback is to prevent new children of the device from being registered until
one of the resume_noirq(), thaw_noirq(), or restore_noirq() callbacks is run.”…””}”(hjn	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÒhjO	  hžhubh¸)”}”(hXY  In addition to that the prepare() callback may carry out some operations
preparing the device to be suspended, although it should not allocate memory
(if additional memory is required to suspend the device, it has to be
preallocated earlier, for example in a suspend/hibernate notifier as described
in Documentation/driver-api/pm/notifiers.rst).”h]”hXY  In addition to that the prepare() callback may carry out some operations
preparing the device to be suspended, although it should not allocate memory
(if additional memory is required to suspend the device, it has to be
preallocated earlier, for example in a suspend/hibernate notifier as described
in Documentation/driver-api/pm/notifiers.rst).”…””}”(hj|	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M×hjO	  hžhubeh}”(h]”Œprepare”ah ]”h"]”Œ3.1.1. prepare()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MËubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.2. suspend()”h]”hŒ3.1.2. suspend()”…””}”(hj•	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj’	  hžhhŸh¶h MÞubh¸)”}”(hŒŠThe suspend() callback is only executed during system suspend, after prepare()
callbacks have been executed for all devices in the system.”h]”hŒŠThe suspend() callback is only executed during system suspend, after prepare()
callbacks have been executed for all devices in the system.”…””}”(hj£	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Màhj’	  hžhubh¸)”}”(hXÇ  This callback is expected to quiesce the device and prepare it to be put into a
low-power state by the PCI subsystem.  It is not required (in fact it even is
not recommended) that a PCI driver's suspend() callback save the standard
configuration registers of the device, prepare it for waking up the system, or
put it into a low-power state.  All of these operations can very well be taken
care of by the PCI subsystem, without the driver's participation.”h]”hXË  This callback is expected to quiesce the device and prepare it to be put into a
low-power state by the PCI subsystem.  It is not required (in fact it even is
not recommended) that a PCI driverâ€™s suspend() callback save the standard
configuration registers of the device, prepare it for waking up the system, or
put it into a low-power state.  All of these operations can very well be taken
care of by the PCI subsystem, without the driverâ€™s participation.”…””}”(hj±	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mãhj’	  hžhubh¸)”}”(hX5  However, in some rare case it is convenient to carry out these operations in
a PCI driver.  Then, pci_save_state(), pci_prepare_to_sleep(), and
pci_set_power_state() should be used to save the device's standard configuration
registers, to prepare it for system wakeup (if necessary), and to put it into a
low-power state, respectively.  Moreover, if the driver calls pci_save_state(),
the PCI subsystem will not execute either pci_prepare_to_sleep(), or
pci_set_power_state() for its device, so the driver is then responsible for
handling the device as appropriate.”h]”hX7  However, in some rare case it is convenient to carry out these operations in
a PCI driver.  Then, pci_save_state(), pci_prepare_to_sleep(), and
pci_set_power_state() should be used to save the deviceâ€™s standard configuration
registers, to prepare it for system wakeup (if necessary), and to put it into a
low-power state, respectively.  Moreover, if the driver calls pci_save_state(),
the PCI subsystem will not execute either pci_prepare_to_sleep(), or
pci_set_power_state() for its device, so the driver is then responsible for
handling the device as appropriate.”…””}”(hj¿	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mêhj’	  hžhubh¸)”}”(hX  While the suspend() callback is being executed, the driver's interrupt handler
can be invoked to handle an interrupt from the device, so all suspend-related
operations relying on the driver's ability to handle interrupts should be
carried out in this callback.”h]”hX  While the suspend() callback is being executed, the driverâ€™s interrupt handler
can be invoked to handle an interrupt from the device, so all suspend-related
operations relying on the driverâ€™s ability to handle interrupts should be
carried out in this callback.”…””}”(hjÍ	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Móhj’	  hžhubeh}”(h]”Œsuspend”ah ]”h"]”Œ3.1.2. suspend()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MÞubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.3. suspend_noirq()”h]”hŒ3.1.3. suspend_noirq()”…””}”(hjæ	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjã	  hžhhŸh¶h Mùubh¸)”}”(hŒÎThe suspend_noirq() callback is only executed during system suspend, after
suspend() callbacks have been executed for all devices in the system and
after device interrupts have been disabled by the PM core.”h]”hŒÎThe suspend_noirq() callback is only executed during system suspend, after
suspend() callbacks have been executed for all devices in the system and
after device interrupts have been disabled by the PM core.”…””}”(hjô	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mûhjã	  hžhubh¸)”}”(hX  The difference between suspend_noirq() and suspend() is that the driver's
interrupt handler will not be invoked while suspend_noirq() is running.  Thus
suspend_noirq() can carry out operations that would cause race conditions to
arise if they were performed in suspend().”h]”hX  The difference between suspend_noirq() and suspend() is that the driverâ€™s
interrupt handler will not be invoked while suspend_noirq() is running.  Thus
suspend_noirq() can carry out operations that would cause race conditions to
arise if they were performed in suspend().”…””}”(hj
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mÿhjã	  hžhubeh}”(h]”Œsuspend-noirq”ah ]”h"]”Œ3.1.3. suspend_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mùubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.4. freeze()”h]”hŒ3.1.4. freeze()”…””}”(hj
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj
  hžhhŸh¶h Mubh¸)”}”(hXq  The freeze() callback is hibernation-specific and is executed in two situations,
during hibernation, after prepare() callbacks have been executed for all devices
in preparation for the creation of a system image, and during restore,
after a system image has been loaded into memory from persistent storage and the
prepare() callbacks have been executed for all devices.”h]”hXq  The freeze() callback is hibernation-specific and is executed in two situations,
during hibernation, after prepare() callbacks have been executed for all devices
in preparation for the creation of a system image, and during restore,
after a system image has been loaded into memory from persistent storage and the
prepare() callbacks have been executed for all devices.”…””}”(hj)
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj
  hžhubh¸)”}”(hŒðThe role of this callback is analogous to the role of the suspend() callback
described above.  In fact, they only need to be different in the rare cases when
the driver takes the responsibility for putting the device into a low-power
state.”h]”hŒðThe role of this callback is analogous to the role of the suspend() callback
described above.  In fact, they only need to be different in the rare cases when
the driver takes the responsibility for putting the device into a low-power
state.”…””}”(hj7
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj
  hžhubh¸)”}”(hŒçIn that cases the freeze() callback should not prepare the device system wakeup
or put it into a low-power state.  Still, either it or freeze_noirq() should
save the device's standard configuration registers using pci_save_state().”h]”hŒéIn that cases the freeze() callback should not prepare the device system wakeup
or put it into a low-power state.  Still, either it or freeze_noirq() should
save the deviceâ€™s standard configuration registers using pci_save_state().”…””}”(hjE
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj
  hžhubeh}”(h]”Œfreeze”ah ]”h"]”Œ3.1.4. freeze()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.5. freeze_noirq()”h]”hŒ3.1.5. freeze_noirq()”…””}”(hj^
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj[
  hžhhŸh¶h Mubh¸)”}”(hX»  The freeze_noirq() callback is hibernation-specific.  It is executed during
hibernation, after prepare() and freeze() callbacks have been executed for all
devices in preparation for the creation of a system image, and during restore,
after a system image has been loaded into memory and after prepare() and
freeze() callbacks have been executed for all devices.  It is always executed
after device interrupts have been disabled by the PM core.”h]”hX»  The freeze_noirq() callback is hibernation-specific.  It is executed during
hibernation, after prepare() and freeze() callbacks have been executed for all
devices in preparation for the creation of a system image, and during restore,
after a system image has been loaded into memory and after prepare() and
freeze() callbacks have been executed for all devices.  It is always executed
after device interrupts have been disabled by the PM core.”…””}”(hjl
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj[
  hžhubh¸)”}”(hŒœThe role of this callback is analogous to the role of the suspend_noirq()
callback described above and it very rarely is necessary to define
freeze_noirq().”h]”hŒœThe role of this callback is analogous to the role of the suspend_noirq()
callback described above and it very rarely is necessary to define
freeze_noirq().”…””}”(hjz
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M hj[
  hžhubh¸)”}”(hŒxThe difference between freeze_noirq() and freeze() is analogous to the
difference between suspend_noirq() and suspend().”h]”hŒxThe difference between freeze_noirq() and freeze() is analogous to the
difference between suspend_noirq() and suspend().”…””}”(hjˆ
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M$hj[
  hžhubeh}”(h]”Œfreeze-noirq”ah ]”h"]”Œ3.1.5. freeze_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.6. poweroff()”h]”hŒ3.1.6. poweroff()”…””}”(hj¡
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjž
  hžhhŸh¶h M(ubh¸)”}”(hŒôThe poweroff() callback is hibernation-specific.  It is executed when the system
is about to be powered off after saving a hibernation image to a persistent
storage.  prepare() callbacks are executed for all devices before poweroff() is
called.”h]”hŒôThe poweroff() callback is hibernation-specific.  It is executed when the system
is about to be powered off after saving a hibernation image to a persistent
storage.  prepare() callbacks are executed for all devices before poweroff() is
called.”…””}”(hj¯
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M*hjž
  hžhubh¸)”}”(hX/  The role of this callback is analogous to the role of the suspend() and freeze()
callbacks described above, although it does not need to save the contents of
the device's registers.  In particular, if the driver wants to put the device
into a low-power state itself instead of allowing the PCI subsystem to do that,
the poweroff() callback should use pci_prepare_to_sleep() and
pci_set_power_state() to prepare the device for system wakeup and to put it
into a low-power state, respectively, but it need not save the device's standard
configuration registers.”h]”hX3  The role of this callback is analogous to the role of the suspend() and freeze()
callbacks described above, although it does not need to save the contents of
the deviceâ€™s registers.  In particular, if the driver wants to put the device
into a low-power state itself instead of allowing the PCI subsystem to do that,
the poweroff() callback should use pci_prepare_to_sleep() and
pci_set_power_state() to prepare the device for system wakeup and to put it
into a low-power state, respectively, but it need not save the deviceâ€™s standard
configuration registers.”…””}”(hj½
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M/hjž
  hžhubeh}”(h]”Œpoweroff”ah ]”h"]”Œ3.1.6. poweroff()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h M(ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.7. poweroff_noirq()”h]”hŒ3.1.7. poweroff_noirq()”…””}”(hjÖ
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjÓ
  hžhhŸh¶h M9ubh¸)”}”(hŒ“The poweroff_noirq() callback is hibernation-specific.  It is executed after
poweroff() callbacks have been executed for all devices in the system.”h]”hŒ“The poweroff_noirq() callback is hibernation-specific.  It is executed after
poweroff() callbacks have been executed for all devices in the system.”…””}”(hjä
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M;hjÓ
  hžhubh¸)”}”(hŒ¼The role of this callback is analogous to the role of the suspend_noirq() and
freeze_noirq() callbacks described above, but it does not need to save the
contents of the device's registers.”h]”hŒ¾The role of this callback is analogous to the role of the suspend_noirq() and
freeze_noirq() callbacks described above, but it does not need to save the
contents of the deviceâ€™s registers.”…””}”(hjò
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M>hjÓ
  hžhubh¸)”}”(hŒ|The difference between poweroff_noirq() and poweroff() is analogous to the
difference between suspend_noirq() and suspend().”h]”hŒ|The difference between poweroff_noirq() and poweroff() is analogous to the
difference between suspend_noirq() and suspend().”…””}”(hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MBhjÓ
  hžhubeh}”(h]”Œpoweroff-noirq”ah ]”h"]”Œ3.1.7. poweroff_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h M9ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.8. resume_noirq()”h]”hŒ3.1.8. resume_noirq()”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h MFubh¸)”}”(hX  The resume_noirq() callback is only executed during system resume, after the
PM core has enabled the non-boot CPUs.  The driver's interrupt handler will not
be invoked while resume_noirq() is running, so this callback can carry out
operations that might race with the interrupt handler.”h]”hX   The resume_noirq() callback is only executed during system resume, after the
PM core has enabled the non-boot CPUs.  The driverâ€™s interrupt handler will not
be invoked while resume_noirq() is running, so this callback can carry out
operations that might race with the interrupt handler.”…””}”(hj'  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MHhj  hžhubh¸)”}”(hXW  Since the PCI subsystem unconditionally puts all devices into the full power
state in the resume_noirq phase of system resume and restores their standard
configuration registers, resume_noirq() is usually not necessary.  In general
it should only be used for performing operations that would lead to race
conditions if carried out by resume().”h]”hXW  Since the PCI subsystem unconditionally puts all devices into the full power
state in the resume_noirq phase of system resume and restores their standard
configuration registers, resume_noirq() is usually not necessary.  In general
it should only be used for performing operations that would lead to race
conditions if carried out by resume().”…””}”(hj5  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MMhj  hžhubeh}”(h]”Œresume-noirq”ah ]”h"]”Œ3.1.8. resume_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MFubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.9. resume()”h]”hŒ3.1.9. resume()”…””}”(hjN  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjK  hžhhŸh¶h MTubh¸)”}”(hŒÄThe resume() callback is only executed during system resume, after
resume_noirq() callbacks have been executed for all devices in the system and
device interrupts have been enabled by the PM core.”h]”hŒÄThe resume() callback is only executed during system resume, after
resume_noirq() callbacks have been executed for all devices in the system and
device interrupts have been enabled by the PM core.”…””}”(hj\  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MVhjK  hžhubh¸)”}”(hŒàThis callback is responsible for restoring the pre-suspend configuration of the
device and bringing it back to the fully functional state.  The device should be
able to process I/O in a usual way after resume() has returned.”h]”hŒàThis callback is responsible for restoring the pre-suspend configuration of the
device and bringing it back to the fully functional state.  The device should be
able to process I/O in a usual way after resume() has returned.”…””}”(hjj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MZhjK  hžhubeh}”(h]”Œresume”ah ]”h"]”Œ3.1.9. resume()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MTubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.10. thaw_noirq()”h]”hŒ3.1.10. thaw_noirq()”…””}”(hjƒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj€  hžhhŸh¶h M_ubh¸)”}”(hX®  The thaw_noirq() callback is hibernation-specific.  It is executed after a
system image has been created and the non-boot CPUs have been enabled by the PM
core, in the thaw_noirq phase of hibernation.  It also may be executed if the
loading of a hibernation image fails during system restore (it is then executed
after enabling the non-boot CPUs).  The driver's interrupt handler will not be
invoked while thaw_noirq() is running.”h]”hX°  The thaw_noirq() callback is hibernation-specific.  It is executed after a
system image has been created and the non-boot CPUs have been enabled by the PM
core, in the thaw_noirq phase of hibernation.  It also may be executed if the
loading of a hibernation image fails during system restore (it is then executed
after enabling the non-boot CPUs).  The driverâ€™s interrupt handler will not be
invoked while thaw_noirq() is running.”…””}”(hj‘  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mahj€  hžhubh¸)”}”(hX  The role of this callback is analogous to the role of resume_noirq().  The
difference between these two callbacks is that thaw_noirq() is executed after
freeze() and freeze_noirq(), so in general it does not need to modify the
contents of the device's registers.”h]”hX  The role of this callback is analogous to the role of resume_noirq().  The
difference between these two callbacks is that thaw_noirq() is executed after
freeze() and freeze_noirq(), so in general it does not need to modify the
contents of the deviceâ€™s registers.”…””}”(hjŸ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhhj€  hžhubeh}”(h]”Œ
thaw-noirq”ah ]”h"]”Œ3.1.10. thaw_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h M_ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.11. thaw()”h]”hŒ3.1.11. thaw()”…””}”(hj¸  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjµ  hžhhŸh¶h Mnubh¸)”}”(hŒÈThe thaw() callback is hibernation-specific.  It is executed after thaw_noirq()
callbacks have been executed for all devices in the system and after device
interrupts have been enabled by the PM core.”h]”hŒÈThe thaw() callback is hibernation-specific.  It is executed after thaw_noirq()
callbacks have been executed for all devices in the system and after device
interrupts have been enabled by the PM core.”…””}”(hjÆ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mphjµ  hžhubh¸)”}”(hŒ•This callback is responsible for restoring the pre-freeze configuration of
the device, so that it will work in a usual way after thaw() has returned.”h]”hŒ•This callback is responsible for restoring the pre-freeze configuration of
the device, so that it will work in a usual way after thaw() has returned.”…””}”(hjÔ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mthjµ  hžhubeh}”(h]”Œthaw”ah ]”h"]”Œ3.1.11. thaw()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mnubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.12. restore_noirq()”h]”hŒ3.1.12. restore_noirq()”…””}”(hjí  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjê  hžhhŸh¶h Mxubh¸)”}”(hŒóThe restore_noirq() callback is hibernation-specific.  It is executed in the
restore_noirq phase of hibernation, when the boot kernel has passed control to
the image kernel and the non-boot CPUs have been enabled by the image kernel's
PM core.”h]”hŒõThe restore_noirq() callback is hibernation-specific.  It is executed in the
restore_noirq phase of hibernation, when the boot kernel has passed control to
the image kernel and the non-boot CPUs have been enabled by the image kernelâ€™s
PM core.”…””}”(hjû  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mzhjê  hžhubh¸)”}”(hŒúThis callback is analogous to resume_noirq() with the exception that it cannot
make any assumption on the previous state of the device, even if the BIOS (or
generally the platform firmware) is known to preserve that state over a
suspend-resume cycle.”h]”hŒúThis callback is analogous to resume_noirq() with the exception that it cannot
make any assumption on the previous state of the device, even if the BIOS (or
generally the platform firmware) is known to preserve that state over a
suspend-resume cycle.”…””}”(hj	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjê  hžhubh¸)”}”(hŒnFor the vast majority of PCI device drivers there is no difference between
resume_noirq() and restore_noirq().”h]”hŒnFor the vast majority of PCI device drivers there is no difference between
resume_noirq() and restore_noirq().”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M„hjê  hžhubeh}”(h]”Œrestore-noirq”ah ]”h"]”Œ3.1.12. restore_noirq()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mxubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.13. restore()”h]”hŒ3.1.13. restore()”…””}”(hj0  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj-  hžhhŸh¶h Mˆubh¸)”}”(hŒäThe restore() callback is hibernation-specific.  It is executed after
restore_noirq() callbacks have been executed for all devices in the system and
after the PM core has enabled device drivers' interrupt handlers to be invoked.”h]”hŒæThe restore() callback is hibernation-specific.  It is executed after
restore_noirq() callbacks have been executed for all devices in the system and
after the PM core has enabled device driversâ€™ interrupt handlers to be invoked.”…””}”(hj>  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MŠhj-  hžhubh¸)”}”(hŒéThis callback is analogous to resume(), just like restore_noirq() is analogous
to resume_noirq().  Consequently, the difference between restore_noirq() and
restore() is analogous to the difference between resume_noirq() and resume().”h]”hŒéThis callback is analogous to resume(), just like restore_noirq() is analogous
to resume_noirq().  Consequently, the difference between restore_noirq() and
restore() is analogous to the difference between resume_noirq() and resume().”…””}”(hjL  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MŽhj-  hžhubh¸)”}”(hŒbFor the vast majority of PCI device drivers there is no difference between
resume() and restore().”h]”hŒbFor the vast majority of PCI device drivers there is no difference between
resume() and restore().”…””}”(hjZ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M’hj-  hžhubeh}”(h]”Œrestore”ah ]”h"]”Œ3.1.13. restore()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mˆubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.14. complete()”h]”hŒ3.1.14. complete()”…””}”(hjs  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjp  hžhhŸh¶h M–ubh¸)”}”(hŒ@The complete() callback is executed in the following situations:”h]”hŒ@The complete() callback is executed in the following situations:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M˜hjp  hžhubj  )”}”(hX_  - during system resume, after resume() callbacks have been executed for all
  devices,
- during hibernation, before saving the system image, after thaw() callbacks
  have been executed for all devices,
- during system restore, when the system is going back to its pre-hibernation
  state, after restore() callbacks have been executed for all devices.
”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒRduring system resume, after resume() callbacks have been executed for all
devices,”h]”h¸)”}”(hŒRduring system resume, after resume() callbacks have been executed for all
devices,”h]”hŒRduring system resume, after resume() callbacks have been executed for all
devices,”…””}”(hjž  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mšhjš  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j˜  hj•  ubj™  )”}”(hŒnduring hibernation, before saving the system image, after thaw() callbacks
have been executed for all devices,”h]”h¸)”}”(hŒnduring hibernation, before saving the system image, after thaw() callbacks
have been executed for all devices,”h]”hŒnduring hibernation, before saving the system image, after thaw() callbacks
have been executed for all devices,”…””}”(hj¶  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mœhj²  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j˜  hj•  ubj™  )”}”(hŒ‘during system restore, when the system is going back to its pre-hibernation
state, after restore() callbacks have been executed for all devices.
”h]”h¸)”}”(hŒduring system restore, when the system is going back to its pre-hibernation
state, after restore() callbacks have been executed for all devices.”h]”hŒduring system restore, when the system is going back to its pre-hibernation
state, after restore() callbacks have been executed for all devices.”…””}”(hjÎ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MžhjÊ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j˜  hj•  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j“  hŸh¶h Mšhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hŸh¶h Mšhjp  hžhubh¸)”}”(hŒÈIt also may be executed if the loading of a hibernation image into memory fails
(in that case it is run after thaw() callbacks have been executed for all
devices that have drivers in the boot kernel).”h]”hŒÈIt also may be executed if the loading of a hibernation image into memory fails
(in that case it is run after thaw() callbacks have been executed for all
devices that have drivers in the boot kernel).”…””}”(hjð  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¡hjp  hžhubh¸)”}”(hŒˆThis callback is entirely optional, although it may be necessary if the
prepare() callback performs operations that need to be reversed.”h]”hŒˆThis callback is entirely optional, although it may be necessary if the
prepare() callback performs operations that need to be reversed.”…””}”(hjþ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¥hjp  hžhubeh}”(h]”Œcomplete”ah ]”h"]”Œ3.1.14. complete()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h M–ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.15. runtime_suspend()”h]”hŒ3.1.15. runtime_suspend()”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h M©ubh¸)”}”(hŒöThe runtime_suspend() callback is specific to device runtime power management
(runtime PM).  It is executed by the PM core's runtime PM framework when the
device is about to be suspended (i.e. quiesced and put into a low-power state)
at run time.”h]”hŒøThe runtime_suspend() callback is specific to device runtime power management
(runtime PM).  It is executed by the PM coreâ€™s runtime PM framework when the
device is about to be suspended (i.e. quiesced and put into a low-power state)
at run time.”…””}”(hj%  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M«hj  hžhubh¸)”}”(hŒÛThis callback is responsible for freezing the device and preparing it to be
put into a low-power state, but it must allow the PCI subsystem to perform all
of the PCI-specific actions necessary for suspending the device.”h]”hŒÛThis callback is responsible for freezing the device and preparing it to be
put into a low-power state, but it must allow the PCI subsystem to perform all
of the PCI-specific actions necessary for suspending the device.”…””}”(hj3  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M°hj  hžhubeh}”(h]”Œruntime-suspend”ah ]”h"]”Œ3.1.15. runtime_suspend()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h M©ubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.16. runtime_resume()”h]”hŒ3.1.16. runtime_resume()”…””}”(hjL  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjI  hžhhŸh¶h Mµubh¸)”}”(hŒõThe runtime_resume() callback is specific to device runtime PM.  It is executed
by the PM core's runtime PM framework when the device is about to be resumed
(i.e. put into the full-power state and programmed to process I/O normally) at
run time.”h]”hŒ÷The runtime_resume() callback is specific to device runtime PM.  It is executed
by the PM coreâ€™s runtime PM framework when the device is about to be resumed
(i.e. put into the full-power state and programmed to process I/O normally) at
run time.”…””}”(hjZ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M·hjI  hžhubh¸)”}”(hŒþThis callback is responsible for restoring the normal functionality of the
device after it has been put into the full-power state by the PCI subsystem.
The device is expected to be able to process I/O in the usual way after
runtime_resume() has returned.”h]”hŒþThis callback is responsible for restoring the normal functionality of the
device after it has been put into the full-power state by the PCI subsystem.
The device is expected to be able to process I/O in the usual way after
runtime_resume() has returned.”…””}”(hjh  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¼hjI  hžhubeh}”(h]”Œruntime-resume”ah ]”h"]”Œ3.1.16. runtime_resume()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mµubh¢)”}”(hhh]”(h§)”}”(hŒ3.1.17. runtime_idle()”h]”hŒ3.1.17. runtime_idle()”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj~  hžhhŸh¶h MÂubh¸)”}”(hXt  The runtime_idle() callback is specific to device runtime PM.  It is executed
by the PM core's runtime PM framework whenever it may be desirable to suspend
the device according to the PM core's information.  In particular, it is
automatically executed right after runtime_resume() has returned in case the
resume of the device has happened as a result of a spurious event.”h]”hXx  The runtime_idle() callback is specific to device runtime PM.  It is executed
by the PM coreâ€™s runtime PM framework whenever it may be desirable to suspend
the device according to the PM coreâ€™s information.  In particular, it is
automatically executed right after runtime_resume() has returned in case the
resume of the device has happened as a result of a spurious event.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÄhj~  hžhubh¸)”}”(hŒÝThis callback is optional, but if it is not implemented or if it returns 0, the
PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
cause the driver's runtime_suspend() callback to be executed.”h]”hŒßThis callback is optional, but if it is not implemented or if it returns 0, the
PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
cause the driverâ€™s runtime_suspend() callback to be executed.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÊhj~  hžhubeh}”(h]”Œruntime-idle”ah ]”h"]”Œ3.1.17. runtime_idle()”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MÂubh¢)”}”(hhh]”(h§)”}”(hŒ:3.1.18. Pointing Multiple Callback Pointers to One Routine”h]”hŒ:3.1.18. Pointing Multiple Callback Pointers to One Routine”…””}”(hj¶  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj³  hžhhŸh¶h MÏubh¸)”}”(hX  Although in principle each of the callbacks described in the previous
subsections can be defined as a separate function, it often is convenient to
point two or more members of struct dev_pm_ops to the same routine.  There are
a few convenience macros that can be used for this purpose.”h]”hX  Although in principle each of the callbacks described in the previous
subsections can be defined as a separate function, it often is convenient to
point two or more members of struct dev_pm_ops to the same routine.  There are
a few convenience macros that can be used for this purpose.”…””}”(hjÄ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÑhj³  hžhubh¸)”}”(hX3  The DEFINE_SIMPLE_DEV_PM_OPS() declares a struct dev_pm_ops object with one
suspend routine pointed to by the .suspend(), .freeze(), and .poweroff()
members and one resume routine pointed to by the .resume(), .thaw(), and
.restore() members.  The other function pointers in this struct dev_pm_ops are
unset.”h]”hX3  The DEFINE_SIMPLE_DEV_PM_OPS() declares a struct dev_pm_ops object with one
suspend routine pointed to by the .suspend(), .freeze(), and .poweroff()
members and one resume routine pointed to by the .resume(), .thaw(), and
.restore() members.  The other function pointers in this struct dev_pm_ops are
unset.”…””}”(hjÒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÖhj³  hžhubh¸)”}”(hŒßThe DEFINE_RUNTIME_DEV_PM_OPS() is similar to DEFINE_SIMPLE_DEV_PM_OPS(), but it
additionally sets the .runtime_resume() pointer to pm_runtime_force_resume()
and the .runtime_suspend() pointer to pm_runtime_force_suspend().”h]”hŒßThe DEFINE_RUNTIME_DEV_PM_OPS() is similar to DEFINE_SIMPLE_DEV_PM_OPS(), but it
additionally sets the .runtime_resume() pointer to pm_runtime_force_resume()
and the .runtime_suspend() pointer to pm_runtime_force_suspend().”…””}”(hjà  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÜhj³  hžhubh¸)”}”(hX  The SYSTEM_SLEEP_PM_OPS() can be used inside of a declaration of struct
dev_pm_ops to indicate that one suspend routine is to be pointed to by the
.suspend(), .freeze(), and .poweroff() members and one resume routine is to
be pointed to by the .resume(), .thaw(), and .restore() members.”h]”hX  The SYSTEM_SLEEP_PM_OPS() can be used inside of a declaration of struct
dev_pm_ops to indicate that one suspend routine is to be pointed to by the
.suspend(), .freeze(), and .poweroff() members and one resume routine is to
be pointed to by the .resume(), .thaw(), and .restore() members.”…””}”(hjî  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Màhj³  hžhubeh}”(h]”Œ2pointing-multiple-callback-pointers-to-one-routine”ah ]”h"]”Œ:3.1.18. pointing multiple callback pointers to one routine”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h MÏubh¢)”}”(hhh]”(h§)”}”(hŒ)3.1.19. Driver Flags for Power Management”h]”hŒ)3.1.19. Driver Flags for Power Management”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj  hžhhŸh¶h Mæubh¸)”}”(hXY  The PM core allows device drivers to set flags that influence the handling of
power management for the devices by the core itself and by middle layer code
including the PCI bus type.  The flags should be set once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should not
be updated directly afterwards.”h]”hXY  The PM core allows device drivers to set flags that influence the handling of
power management for the devices by the core itself and by middle layer code
including the PCI bus type.  The flags should be set once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should not
be updated directly afterwards.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mèhj  hžhubh¸)”}”(hXN  The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
direct-complete mechanism allowing device suspend/resume callbacks to be skipped
if the device is in runtime suspend when the system suspend starts.  That also
affects all of the ancestors of the device, so this flag should only be used if
absolutely necessary.”h]”hXN  The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
direct-complete mechanism allowing device suspend/resume callbacks to be skipped
if the device is in runtime suspend when the system suspend starts.  That also
affects all of the ancestors of the device, so this flag should only be used if
absolutely necessary.”…””}”(hj#  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mîhj  hžhubh¸)”}”(hXe  The DPM_FLAG_SMART_PREPARE flag causes the PCI bus type to return a positive
value from pci_pm_prepare() only if the ->prepare callback provided by the
driver of the device returns a positive value.  That allows the driver to opt
out from using the direct-complete mechanism dynamically (whereas setting
DPM_FLAG_NO_DIRECT_COMPLETE means permanent opt-out).”h]”hXe  The DPM_FLAG_SMART_PREPARE flag causes the PCI bus type to return a positive
value from pci_pm_prepare() only if the ->prepare callback provided by the
driver of the device returns a positive value.  That allows the driver to opt
out from using the direct-complete mechanism dynamically (whereas setting
DPM_FLAG_NO_DIRECT_COMPLETE means permanent opt-out).”…””}”(hj1  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Môhj  hžhubh¸)”}”(hXÜ  The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driver's
perspective the device can be safely left in runtime suspend during system
suspend.  That causes pci_pm_suspend(), pci_pm_freeze() and pci_pm_poweroff()
to avoid resuming the device from runtime suspend unless there are PCI-specific
reasons for doing that.  Also, it causes pci_pm_suspend_late/noirq() and
pci_pm_poweroff_late/noirq() to return early if the device remains in runtime
suspend during the "late" phase of the system-wide transition under way.
Moreover, if the device is in runtime suspend in pci_pm_resume_noirq() or
pci_pm_restore_noirq(), its runtime PM status will be changed to "active" (as it
is going to be put into D0 going forward).”h]”hXæ  The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driverâ€™s
perspective the device can be safely left in runtime suspend during system
suspend.  That causes pci_pm_suspend(), pci_pm_freeze() and pci_pm_poweroff()
to avoid resuming the device from runtime suspend unless there are PCI-specific
reasons for doing that.  Also, it causes pci_pm_suspend_late/noirq() and
pci_pm_poweroff_late/noirq() to return early if the device remains in runtime
suspend during the â€œlateâ€ phase of the system-wide transition under way.
Moreover, if the device is in runtime suspend in pci_pm_resume_noirq() or
pci_pm_restore_noirq(), its runtime PM status will be changed to â€œactiveâ€ (as it
is going to be put into D0 going forward).”…””}”(hj?  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Múhj  hžhubh¸)”}”(hXÂ  Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its
"noirq" and "early" resume callbacks to be skipped if the device can be left
in suspend after a system-wide transition into the working state.  This flag is
taken into consideration by the PM core along with the power.may_skip_resume
status bit of the device which is set by pci_pm_suspend_noirq() in certain
situations.  If the PM core determines that the driver's "noirq" and "early"
resume callbacks should be skipped, the dev_pm_skip_resume() helper function
will return "true" and that will cause pci_pm_resume_noirq() and
pci_pm_resume_early() to return upfront without touching the device and
executing the driver callbacks.”•ó>      h]”hXØ  Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its
â€œnoirqâ€ and â€œearlyâ€ resume callbacks to be skipped if the device can be left
in suspend after a system-wide transition into the working state.  This flag is
taken into consideration by the PM core along with the power.may_skip_resume
status bit of the device which is set by pci_pm_suspend_noirq() in certain
situations.  If the PM core determines that the driverâ€™s â€œnoirqâ€ and â€œearlyâ€
resume callbacks should be skipped, the dev_pm_skip_resume() helper function
will return â€œtrueâ€ and that will cause pci_pm_resume_noirq() and
pci_pm_resume_early() to return upfront without touching the device and
executing the driver callbacks.”…””}”(hjM  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  hžhubeh}”(h]”Œ!driver-flags-for-power-management”ah ]”h"]”Œ)3.1.19. driver flags for power management”ah$]”h&]”uh1h¡hj	  hžhhŸh¶h Mæubeh}”(h]”Œpower-management-callbacks”ah ]”h"]”Œ3.1. power management callbacks”ah$]”h&]”uh1h¡hjõ  hžhhŸh¶h M®ubh¢)”}”(hhh]”(h§)”}”(hŒ$3.2. Device Runtime Power Management”h]”hŒ$3.2. Device Runtime Power Management”…””}”(hjn  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjk  hžhhŸh¶h Mubh¸)”}”(hŒ©In addition to providing device power management callbacks PCI device drivers
are responsible for controlling the runtime power management (runtime PM) of
their devices.”h]”hŒ©In addition to providing device power management callbacks PCI device drivers
are responsible for controlling the runtime power management (runtime PM) of
their devices.”…””}”(hj|  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjk  hžhubh¸)”}”(hX7  The PCI device runtime PM is optional, but it is recommended that PCI device
drivers implement it at least in the cases where there is a reliable way of
verifying that the device is not used (like when the network cable is detached
from an Ethernet adapter or there are no devices attached to a USB controller).”h]”hX7  The PCI device runtime PM is optional, but it is recommended that PCI device
drivers implement it at least in the cases where there is a reliable way of
verifying that the device is not used (like when the network cable is detached
from an Ethernet adapter or there are no devices attached to a USB controller).”…””}”(hjŠ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjk  hžhubh¸)”}”(hX½  To support the PCI runtime PM the driver first needs to implement the
runtime_suspend() and runtime_resume() callbacks.  It also may need to implement
the runtime_idle() callback to prevent the device from being suspended again
every time right after the runtime_resume() callback has returned
(alternatively, the runtime_suspend() callback will have to check if the
device should really be suspended and return -EAGAIN if that is not the case).”h]”hX½  To support the PCI runtime PM the driver first needs to implement the
runtime_suspend() and runtime_resume() callbacks.  It also may need to implement
the runtime_idle() callback to prevent the device from being suspended again
every time right after the runtime_resume() callback has returned
(alternatively, the runtime_suspend() callback will have to check if the
device should really be suspended and return -EAGAIN if that is not the case).”…””}”(hj˜  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjk  hžhubh¸)”}”(hXœ  The runtime PM of PCI devices is enabled by default by the PCI core.  PCI
device drivers do not need to enable it and should not attempt to do so.
However, it is blocked by pci_pm_init() that runs the pm_runtime_forbid()
helper function.  In addition to that, the runtime PM usage counter of
each PCI device is incremented by local_pci_probe() before executing the
probe callback provided by the device's driver.”h]”hXž  The runtime PM of PCI devices is enabled by default by the PCI core.  PCI
device drivers do not need to enable it and should not attempt to do so.
However, it is blocked by pci_pm_init() that runs the pm_runtime_forbid()
helper function.  In addition to that, the runtime PM usage counter of
each PCI device is incremented by local_pci_probe() before executing the
probe callback provided by the deviceâ€™s driver.”…””}”(hj¦  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M#hjk  hžhubh¸)”}”(hXÑ  If a PCI driver implements the runtime PM callbacks and intends to use the
runtime PM framework provided by the PM core and the PCI subsystem, it needs
to decrement the device's runtime PM usage counter in its probe callback
function.  If it doesn't do that, the counter will always be different from
zero for the device and it will never be runtime-suspended.  The simplest
way to do that is by calling pm_runtime_put_noidle(), but if the driver
wants to schedule an autosuspend right away, for example, it may call
pm_runtime_put_autosuspend() instead for this purpose.  Generally, it
just needs to call a function that decrements the devices usage counter
from its probe routine to make runtime PM work for the device.”h]”hXÕ  If a PCI driver implements the runtime PM callbacks and intends to use the
runtime PM framework provided by the PM core and the PCI subsystem, it needs
to decrement the deviceâ€™s runtime PM usage counter in its probe callback
function.  If it doesnâ€™t do that, the counter will always be different from
zero for the device and it will never be runtime-suspended.  The simplest
way to do that is by calling pm_runtime_put_noidle(), but if the driver
wants to schedule an autosuspend right away, for example, it may call
pm_runtime_put_autosuspend() instead for this purpose.  Generally, it
just needs to call a function that decrements the devices usage counter
from its probe routine to make runtime PM work for the device.”…””}”(hj´  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M*hjk  hžhubh¸)”}”(hXJ  It is important to remember that the driver's runtime_suspend() callback
may be executed right after the usage counter has been decremented, because
user space may already have caused the pm_runtime_allow() helper function
unblocking the runtime PM of the device to run via sysfs, so the driver must
be prepared to cope with that.”h]”hXL  It is important to remember that the driverâ€™s runtime_suspend() callback
may be executed right after the usage counter has been decremented, because
user space may already have caused the pm_runtime_allow() helper function
unblocking the runtime PM of the device to run via sysfs, so the driver must
be prepared to cope with that.”…””}”(hjÂ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M5hjk  hžhubh¸)”}”(hXl  The driver itself should not call pm_runtime_allow(), though.  Instead, it
should let user space or some platform-specific code do that (user space can
do it via sysfs as stated above), but it must be prepared to handle the
runtime PM of the device correctly as soon as pm_runtime_allow() is called
(which may happen at any time, even before the driver is loaded).”h]”hXl  The driver itself should not call pm_runtime_allow(), though.  Instead, it
should let user space or some platform-specific code do that (user space can
do it via sysfs as stated above), but it must be prepared to handle the
runtime PM of the device correctly as soon as pm_runtime_allow() is called
(which may happen at any time, even before the driver is loaded).”…””}”(hjÐ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M;hjk  hžhubh¸)”}”(hX‹  When the driver's remove callback runs, it has to balance the decrementation
of the device's runtime PM usage counter at the probe time.  For this reason,
if it has decremented the counter in its probe callback, it must run
pm_runtime_get_noresume() in its remove callback.  [Since the core carries
out a runtime resume of the device and bumps up the device's usage counter
before running the driver's remove callback, the runtime PM of the device
is effectively disabled for the duration of the remove execution and all
runtime PM helper functions incrementing the device's usage counter are
then effectively equivalent to pm_runtime_get_noresume().]”h]”hX•  When the driverâ€™s remove callback runs, it has to balance the decrementation
of the deviceâ€™s runtime PM usage counter at the probe time.  For this reason,
if it has decremented the counter in its probe callback, it must run
pm_runtime_get_noresume() in its remove callback.  [Since the core carries
out a runtime resume of the device and bumps up the deviceâ€™s usage counter
before running the driverâ€™s remove callback, the runtime PM of the device
is effectively disabled for the duration of the remove execution and all
runtime PM helper functions incrementing the deviceâ€™s usage counter are
then effectively equivalent to pm_runtime_get_noresume().]”…””}”(hjÞ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MAhjk  hžhubh¸)”}”(hX  The runtime PM framework works by processing requests to suspend or resume
devices, or to check if they are idle (in which cases it is reasonable to
subsequently request that they be suspended).  These requests are represented
by work items put into the power management workqueue, pm_wq.  Although there
are a few situations in which power management requests are automatically
queued by the PM core (for example, after processing a request to resume a
device the PM core automatically queues a request to check if the device is
idle), device drivers are generally responsible for queuing power management
requests for their devices.  For this purpose they should use the runtime PM
helper functions provided by the PM core, discussed in
Documentation/power/runtime_pm.rst.”h]”hX  The runtime PM framework works by processing requests to suspend or resume
devices, or to check if they are idle (in which cases it is reasonable to
subsequently request that they be suspended).  These requests are represented
by work items put into the power management workqueue, pm_wq.  Although there
are a few situations in which power management requests are automatically
queued by the PM core (for example, after processing a request to resume a
device the PM core automatically queues a request to check if the device is
idle), device drivers are generally responsible for queuing power management
requests for their devices.  For this purpose they should use the runtime PM
helper functions provided by the PM core, discussed in
Documentation/power/runtime_pm.rst.”…””}”(hjì  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MKhjk  hžhubh¸)”}”(hŒßDevices can also be suspended and resumed synchronously, without placing a
request into pm_wq.  In the majority of cases this also is done by their
drivers that use helper functions provided by the PM core for this purpose.”h]”hŒßDevices can also be suspended and resumed synchronously, without placing a
request into pm_wq.  In the majority of cases this also is done by their
drivers that use helper functions provided by the PM core for this purpose.”…””}”(hjú  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MWhjk  hžhubh¸)”}”(hŒ^For more information on the runtime PM of devices refer to
Documentation/power/runtime_pm.rst.”h]”hŒ^For more information on the runtime PM of devices refer to
Documentation/power/runtime_pm.rst.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M[hjk  hžhubeh}”(h]”Œdevice-runtime-power-management”ah ]”h"]”Œ$3.2. device runtime power management”ah$]”h&]”uh1h¡hjõ  hžhhŸh¶h Mubeh}”(h]”Œ'pci-device-drivers-and-power-management”ah ]”h"]”Œ*3. pci device drivers and power management”ah$]”h&]”uh1h¡hh£hžhhŸh¶h M«ubh¢)”}”(hhh]”(h§)”}”(hŒ4. Resources”h]”hŒ4. Resources”…””}”(hj)  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj&  hžhhŸh¶h M`ubh¸)”}”(hŒ%PCI Local Bus Specification, Rev. 3.0”h]”hŒ%PCI Local Bus Specification, Rev. 3.0”…””}”(hj7  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mbhj&  hžhubh¸)”}”(hŒ:PCI Bus Power Management Interface Specification, Rev. 1.2”h]”hŒ:PCI Bus Power Management Interface Specification, Rev. 1.2”…””}”(hjE  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mdhj&  hžhubh¸)”}”(hŒJAdvanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b”h]”hŒJAdvanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b”…””}”(hjS  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mfhj&  hžhubh¸)”}”(hŒ(PCI Express Base Specification, Rev. 2.0”h]”hŒ(PCI Express Base Specification, Rev. 2.0”…””}”(hja  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhhj&  hžhubh¸)”}”(hŒ'Documentation/driver-api/pm/devices.rst”h]”hŒ'Documentation/driver-api/pm/devices.rst”…””}”(hjo  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mjhj&  hžhubh¸)”}”(hŒ"Documentation/power/runtime_pm.rst”h]”hŒ"Documentation/power/runtime_pm.rst”…””}”(hj}  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mlhj&  hžhubeh}”(h]”Œ	resources”ah ]”h"]”Œ4. resources”ah$]”h&]”uh1h¡hh£hžhhŸh¶h M`ubeh}”(h]”Œpci-power-management”ah ]”h"]”Œpci power management”ah$]”h&]”uh1h¡hhhžhhŸh¶h Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”h¶uh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(h¦NŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”j0  Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j½  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”h¶Œ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(j˜  j•  jó  jð  jš  j—  j  j   jp  jm  jë  jè  jò  jï  js  jp  jÄ  jÁ  j[  jX  jê  jç  j+  j(  j¾  j»  j  j  jâ  jß  j#  j   jh  je  j	  jŒ	  jà	  jÝ	  j
  j
  jX
  jU
  j›
  j˜
  jÐ
  jÍ
  j  j  jH  jE  j}  jz  j²  j¯  jç  jä  j*  j'  jm  jj  j  j  jF  jC  j{  jx  j°  j­  j  jþ  j`  j]  j  j  j  j  uŒ	nametypes”}”(j˜  ‰jó  ‰jš  ‰j  ‰jp  ‰jë  ‰jò  ‰js  ‰jÄ  ‰j[  ‰jê  ‰j+  ‰j¾  ‰j  ‰jâ  ‰j#  ‰jh  ‰j	  ‰jà	  ‰j
  ‰jX
  ‰j›
  ‰jÐ
  ‰j  ‰jH  ‰j}  ‰j²  ‰jç  ‰j*  ‰jm  ‰j  ‰jF  ‰j{  ‰j°  ‰j  ‰j`  ‰j  ‰j  ‰uh}”(j•  h£jð  j  j—  j0  j   j  jm  j  jè  js  jï  jö  jp  j  jÁ  jv  jX  jÇ  jç  j^  j(  j}  j»  j.  j  jÁ  jß  j  j   jõ  je  j	  jŒ	  jO	  jÝ	  j’	  j
  jã	  jU
  j
  j˜
  j[
  jÍ
  jž
  j  jÓ
  jE  j  jz  jK  j¯  j€  jä  jµ  j'  jê  jj  j-  j  jp  jC  j  jx  jI  j­  j~  jþ  j³  j]  j  j  jk  j  j&  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nhžhub.