1. 13 Nov, 2017 1 commit
  2. 11 Nov, 2017 2 commits
  3. 10 Nov, 2017 1 commit
  4. 09 Nov, 2017 1 commit
  5. 08 Nov, 2017 6 commits
  6. 07 Nov, 2017 7 commits
  7. 06 Nov, 2017 3 commits
    • Rafael J. Wysocki's avatar
      PCI / PM: Take SMART_SUSPEND driver flag into account · c4b65157
      Rafael J. Wysocki authored
      Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its
      system-wide PM callbacks and make sure that all code that should not
      run in parallel with pci_pm_runtime_resume() is executed in the "late"
      phases of system suspend, freeze and poweroff transitions.
      [Note that the pm_runtime_suspended() check in pci_dev_keep_suspended()
      is an optimization, because if is not passed, all of the subsequent
      checks may be skipped and some of them are much more overhead in
      Also use the observation that if the device is in runtime suspend
      at the beginning of the "late" phase of a system-wide suspend-like
      transition, its state cannot change going forward (runtime PM is
      disabled for it at that time) until the transition is over and the
      subsequent system-wide PM callbacks should be skipped for it (as
      they generally assume the device to not be suspended), so add checks
      for that in pci_pm_suspend_late/noirq(), pci_pm_freeze_late/noirq()
      and pci_pm_poweroff_late/noirq().
      Moreover, if pci_pm_resume_noirq() or pci_pm_restore_noirq() is
      called during the subsequent system-wide resume transition and if
      the device was left in runtime suspend previously, its runtime PM
      status needs to be changed to "active" as it is going to be put
      into the full-power state, so add checks for that too to these
      In turn, if pci_pm_thaw_noirq() runs after the device has been
      left in runtime suspend, the subsequent "thaw" callbacks need
      to be skipped for it (as they may not work correctly with a
      suspended device), so set the power.direct_complete flag for the
      device then to make the PM core skip those callbacks.
      In addition to the above add a core helper for checking if
      DPM_FLAG_SMART_SUSPEND is set and the device runtime PM status is
      "suspended" at the same time, which is done quite often in the new
      code (and will be done elsewhere going forward too).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Rafael J. Wysocki's avatar
      PM / core: Add SMART_SUSPEND driver flag · 0eab11c9
      Rafael J. Wysocki authored
      Define and document a SMART_SUSPEND flag to instruct bus types and PM
      domains that the system suspend callbacks provided by the driver can
      cope with runtime-suspended devices, so from the driver's perspective
      it should be safe to leave devices in runtime suspend during system
      Setting that flag may also cause middle-layer code (bus types,
      PM domains etc.) to skip invocations of the ->suspend_late and
      ->suspend_noirq callbacks provided by the driver if the device
      is in runtime suspend at the beginning of the "late" phase of
      the system-wide suspend transition, in which case the driver's
      system-wide resume callbacks may be invoked back-to-back with
      its ->runtime_suspend callback, so the driver has to be able to
      cope with that too.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
    • Rafael J. Wysocki's avatar
      PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags · 08810a41
      Rafael J. Wysocki authored
      The motivation for this change is to provide a way to work around
      a problem with the direct-complete mechanism used for avoiding
      system suspend/resume handling for devices in runtime suspend.
      The problem is that some middle layer code (the PCI bus type and
      the ACPI PM domain in particular) returns positive values from its
      system suspend ->prepare callbacks regardless of whether the driver's
      ->prepare returns a positive value or 0, which effectively prevents
      drivers from being able to control the direct-complete feature.
      Some drivers need that control, however, and the PCI bus type has
      grown its own flag to deal with this issue, but since it is not
      limited to PCI, it is better to address it by adding driver flags at
      the core level.
      To that end, add a driver_flags field to struct dev_pm_info for flags
      that can be set by device drivers at the probe time to inform the PM
      core and/or bus types, PM domains and so on on the capabilities and/or
      preferences of device drivers.  Also add two static inline helpers
      for setting that field and testing it against a given set of flags
      and make the driver core clear it automatically on driver remove
      and probe failures.
      Define and document two PM driver flags related to the direct-
      complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
      respectively, to indicate to the PM core that the direct-complete
      mechanism should never be used for the device and to inform the
      middle layer code (bus types, PM domains etc) that it can only
      request the PM core to use the direct-complete mechanism for
      the device (by returning a positive value from its ->prepare
      callback) if it also has been requested by the driver.
      While at it, make the core check pm_runtime_suspended() when
      setting power.direct_complete so that it doesn't need to be
      checked by ->prepare callbacks.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
  8. 05 Nov, 2017 7 commits
  9. 04 Nov, 2017 2 commits
  10. 03 Nov, 2017 6 commits
  11. 02 Nov, 2017 4 commits