Lines Matching full:s
7 An overview of concepts and the Linux kernel's interfaces related to PCI power
12 devices. For general description of the kernel's interfaces related to device
48 used by the kernel to change the device's power state.
152 stored in the machine's BIOS. The kernel loads them from the BIOS and executes
192 device's _SxD control method (where x is a number between 0 and 4 inclusive).
195 target state of the system. The kernel is then supposed to use the device's
197 use the device's _PRW control method to learn which power resources need to be
210 sleeping, they should cause the system's core logic to trigger wakeup.
218 and event sources is recorded in the system's ACPI BIOS from where it can be
221 If a PCI device known to the system's ACPI BIOS signals wakeup, the GPE
225 example, native PCI PMEs from devices unknown to the system's ACPI BIOS may be
235 state (ACPI S0) and in that case the system's core logic generates a System
249 may be routed directly to the system's core logic), but for PCI Express devices
255 recorded in one of the root port's configuration registers from where it may be
262 systems along with the GPEs, but to use it the kernel has to ask the system's
278 Specifically, the pm field of the PCI subsystem's struct bus_type object,
333 The PCI subsystem's first task related to device power management is to
339 and if that's the case the offset of its power management capability structure
340 in the configuration space is stored in the pm_cap field of the device's struct
343 native PCI PMEs. The power management fields of the device's struct pci_dev and
350 device's struct pci_dev and uses the firmware-provided method to prevent the
377 pci_pm_runtime_suspend() to do the actual job. For this to work, the device's
379 run by pci_pm_runtime_suspend() as the first action. If the driver's callback
380 returns successfully, the device's standard configuration registers are saved,
389 PCI subsystem can use the platform firmware as well as the device's native PCI
392 It is expected that the device driver's pm->runtime_suspend() callback will
399 pci_pm_runtime_resume() for PCI devices. Again, this only works if the device's
401 the driver's callback is executed, pci_pm_runtime_resume() brings the device
403 state and restores its standard configuration registers. Thus the driver's
407 situations. First, it may be called at the request of the device's driver, for
416 and pm_request_idle(), executes the device driver's pm->runtime_idle()
423 suspended, so it lets the device's driver decide by running its
444 The following PCI bus type's callbacks, respectively, are used in these phases::
452 driver's pm->prepare() callback if defined (i.e. if the driver's struct
455 The pci_pm_suspend() routine first checks if the device's driver implements
456 legacy PCI suspend routines (see Section 3), in which case the driver's legacy
458 the device's driver doesn't provide a struct dev_pm_ops object (containing
459 pointers to the driver's callbacks), pci_pm_default_suspend() is called, which
460 simply turns off the device's bus master capability and runs
462 bridges are ignored by this routine). Next, the device driver's pm->suspend()
473 been called, which means that the device driver's interrupt handler won't be
474 invoked while this routine is running. It first checks if the device's driver
477 configuration registers of the device are saved if the driver's callback hasn't
478 done that). Second, if the device driver's struct dev_pm_ops object is not
479 present, the device's standard configuration registers are saved and the routine
480 returns success. Otherwise the device driver's pm->suspend_noirq() callback is
482 device's standard configuration registers haven't been saved yet (one of the
483 device driver's callbacks executed before might do that), pci_pm_suspend_noirq()
491 is also responsible for preparing the device to signal wakeup from the system's
496 into low-power states. However, if one of the driver's suspend callbacks
497 (pm->suspend() or pm->suspend_noirq()) saves the device's standard configuration
513 The following PCI bus type's callbacks, respectively, are executed in these
523 unconditionally, regardless of whether or not the device's driver implements
529 callbacks (see Section 3) are implemented by the device's driver, the legacy
531 device driver's pm->resume_noirq() callback is executed, if defined, and its
534 The pci_pm_resume() routine first checks if the device's standard configuration
535 registers have been restored and restores them if that's not the case (this
538 device's driver implements legacy PCI power management callbacks (see
539 Section 3), the driver's legacy resume callback is executed and its result is
540 returned. Otherwise, the device's wakeup signaling mechanisms are blocked and
541 its driver's pm->resume() callback is executed, if defined (the callback's
549 The pci_pm_complete() routine only executes the device driver's pm->complete()
566 that correspond to the PCI bus type's callbacks::
576 the device driver's pm->freeze() callback, if defined, instead of pm->suspend(),
582 pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq()
585 the device's standard configuration registers if they haven't been saved by one
586 of the driver's callbacks.
595 using the following PCI bus type's callbacks::
605 configuration registers. It also executes the device driver's pm->thaw_noirq()
609 driver's pm->thaw() callback instead of pm->resume(). It is executed
629 although they don't attempt to save the device's standard configuration
675 respectively, but they execute the device driver's pm->restore_noirq() and
689 executed by the PCI subsystem's power management routines described above and by
703 the PCI subsystem's PM routines in various circumstances. A pointer to the
704 driver's struct dev_pm_ops object has to be assigned to the driver.pm field in
722 This callback is only necessary if the driver's device has children that in
741 not recommended) that a PCI driver's suspend() callback save the standard
744 care of by the PCI subsystem, without the driver's participation.
748 pci_set_power_state() should be used to save the device's standard configuration
755 While the suspend() callback is being executed, the driver's interrupt handler
757 operations relying on the driver's ability to handle interrupts should be
767 The difference between suspend_noirq() and suspend() is that the driver's
788 save the device's standard configuration registers using pci_save_state().
817 the device's registers. In particular, if the driver wants to put the device
821 into a low-power state, respectively, but it need not save the device's standard
832 contents of the device's registers.
841 PM core has enabled the non-boot CPUs. The driver's interrupt handler will not
869 after enabling the non-boot CPUs). The driver's interrupt handler will not be
875 contents of the device's registers.
892 the image kernel and the non-boot CPUs have been enabled by the image kernel's
940 (runtime PM). It is executed by the PM core's runtime PM framework when the
952 by the PM core's runtime PM framework when the device is about to be resumed
965 by the PM core's runtime PM framework whenever it may be desirable to suspend
966 the device according to the PM core's information. In particular, it is
972 cause the driver's runtime_suspend() callback to be executed.
1019 The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driver's
1035 situations. If the PM core determines that the driver's "noirq" and "early"
1065 probe callback provided by the device's driver.
1069 to decrement the device's runtime PM usage counter in its probe callback
1078 It is important to remember that the driver's runtime_suspend() callback
1090 When the driver's remove callback runs, it has to balance the decrementation
1091 of the device's runtime PM usage counter at the probe time. For this reason,
1094 out a runtime resume of the device and bumps up the device's usage counter
1095 before running the driver's remove callback, the runtime PM of the device
1097 runtime PM helper functions incrementing the device's usage counter are