Lines Matching refs:pm

271 Specifically, the pm field of the PCI subsystem's struct bus_type object,
369 driver has to provide a pm->runtime_suspend() callback (see below), which is
383 It is expected that the device driver's pm->runtime_suspend() callback will
391 driver provides a pm->runtime_resume() callback (see below).  However, before
407 and pm_request_idle(), executes the device driver's pm->runtime_idle()
415 pm->runtime_idle() callback.
442 driver's pm->prepare() callback if defined (i.e. if the driver's struct
452 bridges are ignored by this routine).  Next, the device driver's pm->suspend()
470 returns success.  Otherwise the device driver's pm->suspend_noirq() callback is
487 (pm->suspend() or pm->suspend_noirq()) saves the device's standard configuration
520 device driver's pm->resume_noirq() callback is executed, if defined, and its
530 its driver's pm->resume() callback is executed, if defined (the callback's
538 The pci_pm_complete() routine only executes the device driver's pm->complete()
564 the device driver's pm->freeze() callback, if defined, instead of pm->suspend(),
570 pci_pm_suspend_noirq(), but it calls the device driver's pm->freeze_noirq()
571 routine instead of pm->suspend_noirq().  It also doesn't attempt to prepare the
594 driver's pm->thaw_noirq() callback, if defined, instead of pm->resume_noirq().
597 driver's pm->thaw() callback instead of pm->resume().  It is executed
662 respectively, but they execute the device driver's pm->restore_noirq() and
663 pm->restore() callbacks, if available.
690 driver's struct dev_pm_ops object has to be assigned to the driver.pm field in