Documentation/power/pci.txt

52 delivering the PME from the device to the CPU and the operating system kernel.
138 system-specific.  However, if the system in question is compliant with the
151 on the system design in a system-specific fashion.
182 system-wide transition into a sleep state or back into the working state.  ACPI
183 defines four system sleep states, S1, S2, S3, and S4, and denotes the system
184 working state as S0.  In general, the target system sleep (or working) state
188 If the device is required to wake up the system from the target sleep state, the
190 target state of the system.  The kernel is then supposed to use the device's
200 appropriate.  If they are sent while the system is in the working state
203 events that triggered them.  In turn, if they are sent while the system is
204 sleeping, they should cause the system's core logic to trigger wakeup.
208 from the system core logic generated in response to various events that need to
212 and event sources is recorded in the system's ACPI BIOS from where it can be
215 If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE
219 example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be
222 A GPE may be triggered when the system is sleeping (i.e. when it is in one of
223 the ACPI S1-S4 states), in which case system wakeup is started by its core logic
224 (the device that was the source of the signal causing the system wakeup to occur
228 Usually, however, GPEs are also triggered when the system is in the working
229 state (ACPI S0) and in that case the system's core logic generates a System
234 events occurring while the system is in the working state are referred to as
243 may be routed directly to the system's core logic), but for PCI Express devices
256 systems along with the GPEs, but to use it the kernel has to ask the system's
347 during system-wide transitions to a sleep state and back to the working state.
377 system-dependent and is determined by the PCI subsystem on the basis of the
417 2.4. System-Wide Power Transitions
419 There are a few different types of system-wide power transitions, described in
427 2.4.1. System Suspend
429 When the system is going into a sleep state in which the contents of memory will
478 state from which it can signal wakeup while the system is in the target sleep
480 signaling wakeup is system-dependent and determined by the PCI subsystem, which
481 is also responsible for preparing the device to signal wakeup from the system's
494 2.4.2. System Resume
496 When the system is undergoing a transition from a sleep state in which the
541 2.4.3. System Hibernation
543 System hibernation is more complicated than system suspend, because it requires
544 a system image to be created and written into a persistent storage medium.  The
549 the time of this writing the image creation requires at least 50% of system RAM
560 This means that the prepare phase is exactly the same as for system suspend.
601 The complete phase it the same as for system resume.
603 After saving the image, devices need to be powered down before the system can
609 where the prepare phase is exactly the same as for system suspend.  The other
620 2.4.4. System Restore
622 System restore requires a hibernation image to be loaded into memory and the
623 pre-hibernation memory contents to be restored before the pre-hibernation system
647 responsible for bringing the system back to the working state.  To achieve this,
665 The complete phase is carried out in exactly the same way as during system
702 The prepare() callback is executed during system suspend, during hibernation
704 saving a hibernation image and during system restore, when a hibernation image
720 The suspend() callback is only executed during system suspend, after prepare()
721 callbacks have been executed for all devices in the system.
726 configuration registers of the device, prepare it for waking up the system, or
733 registers, to prepare it for system wakeup (if necessary), and to put it into a
746 The suspend_noirq() callback is only executed during system suspend, after
747 suspend() callbacks have been executed for all devices in the system and
759 in preparation for the creation of a system image, and during restore,
760 after a system image has been loaded into memory from persistent storage and the
768 In that cases the freeze() callback should not prepare the device system wakeup
776 devices in preparation for the creation of a system image, and during restore,
777 after a system image has been loaded into memory and after prepare() and
790 The poweroff() callback is hibernation-specific.  It is executed when the system
800 pci_set_power_state() to prepare the device for system wakeup and to put it
807 poweroff() callbacks have been executed for all devices in the system.
818 The resume_noirq() callback is only executed during system resume, after the
824 state in the resume_noirq phase of system resume and restores their standard
831 The resume() callback is only executed during system resume, after
832 resume_noirq() callbacks have been executed for all devices in the system and
842 system image has been created and the non-boot CPUs have been enabled by the PM
844 loading of a hibernation image fails during system restore (it is then executed
856 callbacks have been executed for all devices in the system and after device
880 restore_noirq() callbacks have been executed for all devices in the system and
893   - during system resume, after resume() callbacks have been executed for all
895   - during hibernation, before saving the system image, after thaw() callbacks
897   - during system restore, when the system is going back to its pre-hibernation