Lines Matching refs:that

41 approach, that is referred to as the native PCI power management (native PCI PM)
44 approach requires the platform firmware to provide special methods that may be
50 to put the device that sent it into the full-power state.  However, the PCI Bus
53 It is assumed that the platform firmware will perform this task and therefore,
60 preparing the device to generate wakeup signals.  In that case, however, it
63 that.
83 in that state.  However, the higher the number, the longer the latency for
88 programmed to go into it.  The second one, D3cold, is the state that PCI devices
97 Note that every PCI device can be in the full-power state (D0) or in D3cold,
99 that, if the PCI PM Spec is implemented by the device, it must support D3hot
124 the device (i.e. power is restored).  In that case the device returns to D0 with
144 methods" that may be executed by the kernel to perform specific tasks, such as
148 them as needed using an AML interpreter that translates the AML byte code into
153 ACPI control methods may be divided into global control methods, that are not
154 associated with any particular devices, and device control methods, that have
156 the platform.  This means, in particular, that ACPI device control methods can
157 only be used to handle devices that the BIOS writer knew about in advance.  The
158 ACPI methods used for device power management fall into that category.
160 The ACPI specification assumes that devices can be in one of four power states
161 labeled as D0, D1, D2, and D3 that roughly correspond to the native PCI PM
164 set of power resources that have to be enabled for the device to be put into
165 that state.  These power resources are controlled (i.e. enabled or disabled)
166 with the help of their own control methods, _ON and _OFF, that have to be
172 _PSx control method defined for the device.  In addition to that, if the device
174 wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI
176 resources that are not required by the device in the target power state and are
191 _SxW control method to obtain the number of that state.  It also is supposed to
201 (ACPI S0), they should be translated into interrupts so that the kernel can
203 events that triggered them.  In turn, if they are sent while the system is
208 from the system core logic generated in response to various events that need to
224 (the device that was the source of the signal causing the system wakeup to occur
229 state (ACPI S0) and in that case the system's core logic generates a System
231 handler identifies the GPE that caused the interrupt to be generated which,
232 in turn, allows the kernel to identify the source of the event (that may be
238 conventional PCI devices on systems that are not ACPI-based, but there is one
244 they are in-band messages that have to pass through the PCI Express hierarchy,
248 The PCI Express Requester ID of the device that sent the PME message is then
259 and if it doesn't do that, the kernel must not modify their contents.  Of course
260 the native PCI Express PME signaling cannot be used by the kernel in that case.
298 involving some standard configuration registers of PCI devices that device
302 that these callbacks operate on:
320 They also indirectly use some fields of the struct device that is embedded in
331 and if that's the case the offset of its power management capability structure
340 the help of the platform firmware, such as the ACPI BIOS.  If that is the case,
360 that are executed by the core runtime PM routines.  It also implements the
383 It is expected that the device driver's pm->runtime_suspend() callback will
386 that has all of the information necessary to perform them.
393 back into the full-power state, prevents it from signaling wakeup while in that
397 Note that generally pci_pm_runtime_resume() may be called in two different
408 callback, if defined, and if that callback doesn't return error code (or is not
412 cases it is expected to suspend the device if that makes sense.  Usually,
422 callbacks for this purpose.  They are executed in phases such that each phase
443 dev_pm_ops object is present and the prepare pointer in that object is valid).
457 Note that the suspend phase is carried out asynchronously for PCI devices, so
459 devices that don't depend on each other in a known way (i.e. none of the paths
463 been called, which means that the device driver's interrupt handler won't be
468 done that).  Second, if the device driver's struct dev_pm_ops object is not
473 device driver's callbacks executed before might do that), pci_pm_suspend_noirq()
484 PCI device drivers (that don't implement legacy power management callbacks) are
488 registers, pci_pm_suspend_noirq() will assume that the device has been prepared
491 this purpose).  PCI device drivers are not encouraged to do that, but in some
492 rare cases doing that in the driver may be the optimum approach.
524 registers have been restored and restores them if that's not the case (this
534 suspend phase described above, which means that if two PCI devices don't depend
545 image is created atomically and all devices are quiesced, or frozen, before that
554 that correspond to the PCI bus type's callbacks:
560 This means that the prepare phase is exactly the same as for system suspend.
566 asynchronously for different PCI devices that don't depend on each other in a
598 asynchronously for different PCI devices that don't depend on each other in a
642 thaw_noirq, thaw, and complete phases (that will only affect the devices having
687 It is recommended that all PCI device drivers define a struct dev_pm_ops object
688 containing pointers to power management (PM) callbacks that will be executed by
691 its struct pci_driver object.  Once that has happened, the "legacy" PM callbacks
707 This callback is only necessary if the driver's device has children that in
708 general may be registered at any time.  In that case the role of the prepare()
712 In addition to that the prepare() callback may carry out some operations
725 not recommended) that a PCI driver's suspend() callback save the standard
750 The difference between suspend_noirq() and suspend() is that the driver's
752 suspend_noirq() can carry out operations that would cause race conditions to
768 In that cases the freeze() callback should not prepare the device system wakeup
798 into a low-power state itself instead of allowing the PCI subsystem to do that,
821 operations that might race with the interrupt handler.
826 it should only be used for performing operations that would lead to race
849 difference between these two callbacks is that thaw_noirq() is executed after
860 the device, so that it will work in a usual way after thaw() has returned.
869 This callback is analogous to resume_noirq() with the exception that it cannot
871 generally the platform firmware) is known to preserve that state over a
900 (in that case it is run after thaw() callbacks have been executed for all
901 devices that have drivers in the boot kernel).
904 prepare() callback performs operations that need to be reversed.
946 a few convenience macros that can be used for this purpose.
960 dev_pm_ops to indicate that one suspend routine is to be pointed to by the
970 The PCI device runtime PM is optional, but it is recommended that PCI device
972 verifying that the device is not used (like when the network cable is detached
980 device should really be suspended and return -EAGAIN if that is not the case).
983 pci_pm_init() that runs the pm_runtime_forbid() helper function.  If a PCI
989 platform-specific code to do that (user space can do it via sysfs), although
992 (which may happen at any time).  [It also is possible that user space causes
999 subsequently request that they be suspended).  These requests are represented
1011 drivers that use helper functions provided by the PM core for this purpose.