1. 16 Nov, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PM / runtime: Drop children check from __pm_runtime_set_status() · f8817f61
      Rafael J. Wysocki authored
      The check for "active" children in __pm_runtime_set_status(), when
      trying to set the parent device status to "suspended", doesn't
      really make sense, because in fact it is not invalid to set the
      status of a device with runtime PM disabled to "suspended" in any
      case.  It is invalid to enable runtime PM for a device with its
      status set to "suspended" while its child_count reference counter
      is nonzero, but the check in __pm_runtime_set_status() doesn't
      really cover that situation.
      
      For this reason, drop the children check from __pm_runtime_set_status()
      and add a check against child_count reference counters of "suspended"
      devices to pm_runtime_enable().
      
      Fixes: a8636c89 (PM / Runtime: Don't allow to suspend a device with an active child)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      f8817f61
  2. 12 Oct, 2017 1 commit
  3. 27 Jul, 2017 1 commit
  4. 27 Jun, 2017 1 commit
  5. 19 Apr, 2017 2 commits
    • Johan Hovold's avatar
      PM / runtime: Document autosuspend-helper side effects · bafdcde7
      Johan Hovold authored
      Document the fact that the autosuspend delay and enable helpers may
      change the power.usage_count and resume or suspend a device depending on
      the values of power.autosuspend_delay and power.use_autosuspend.
      
      Note that this means that a driver must disable autosuspend before
      disabling runtime pm on probe errors and on driver unbind if the device
      is to be suspended upon return (as a negative delay may otherwise keep
      the device resumed).
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bafdcde7
    • Johan Hovold's avatar
      PM / runtime: Fix autosuspend documentation · 72ec2e17
      Johan Hovold authored
      Update the autosuspend documentation which claimed that the autosuspend
      delay is not taken into account when using the non-autosuspend helper
      functions, something which is no longer true since commit d66e6db2
      ("PM / Runtime: Respect autosuspend when idle triggers suspend").
      
      This specifically means that drivers must now disable autosuspend before
      disabling runtime pm in probe error paths and remove callbacks if
      pm_runtime_put_sync was being used to suspend the device before
      returning. (If an idle callback can prevent suspend,
      pm_runtime_put_sync_suspend must be used instead of pm_runtime_put_sync
      as before.)
      
      Also remove the claim that the autosuspend helpers behave "just like
      the non-autosuspend counterparts", something which have never really
      been true as some of the latter use idle notifications.
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      72ec2e17
  6. 23 Feb, 2017 1 commit
  7. 24 Oct, 2016 1 commit
  8. 05 Apr, 2016 1 commit
  9. 21 Dec, 2015 1 commit
  10. 21 Jul, 2015 1 commit
  11. 12 May, 2015 1 commit
  12. 17 Nov, 2014 1 commit
  13. 08 Nov, 2014 1 commit
  14. 16 May, 2014 2 commits
  15. 26 Mar, 2014 5 commits
  16. 12 Nov, 2013 1 commit
  17. 16 Oct, 2013 1 commit
  18. 03 Jun, 2013 2 commits
  19. 25 Jan, 2013 1 commit
  20. 05 Jan, 2013 1 commit
    • Rafael J. Wysocki's avatar
      PM: Move disabling/enabling runtime PM to late suspend/early resume · 9f6d8f6a
      Rafael J. Wysocki authored
      Currently, the PM core disables runtime PM for all devices right
      after executing subsystem/driver .suspend() callbacks for them
      and re-enables it right before executing subsystem/driver .resume()
      callbacks for them.  This may lead to problems when there are
      two devices such that the .suspend() callback executed for one of
      them depends on runtime PM working for the other.  In that case,
      if runtime PM has already been disabled for the second device,
      the first one's .suspend() won't work correctly (and analogously
      for resume).
      
      To make those issues go away, make the PM core disable runtime PM
      for devices right before executing subsystem/driver .suspend_late()
      callbacks for them and enable runtime PM for them right after
      executing subsystem/driver .resume_early() callbacks for them.  This
      way the potential conflitcs between .suspend_late()/.resume_early()
      and their runtime PM counterparts are still prevented from happening,
      but the subtle ordering issues related to disabling/enabling runtime
      PM for devices during system suspend/resume are much easier to avoid.
      Reported-and-tested-by: default avatarJan-Matthias Braun <jan_braun@gmx.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Cc: 3.4+ <stable@vger.kernel.org>
      9f6d8f6a
  21. 21 Dec, 2011 1 commit
    • Rafael J. Wysocki's avatar
      PM: Run the driver callback directly if the subsystem one is not there · 35cd133c
      Rafael J. Wysocki authored
      Make the PM core execute driver PM callbacks directly if the
      corresponding subsystem callbacks are not present.
      
      There are three reasons for doing that.  First, it reflects the
      behavior of drivers/base/dd.c:really_probe() that runs the driver's
      .probe() callback directly if the bus type's one is not defined, so
      this change will remove one arbitrary difference between the PM core
      and the remaining parts of the driver core.  Second, it will allow
      some subsystems, whose PM callbacks don't do anything except for
      executing driver callbacks, to be simplified quite a bit by removing
      those "forward-only" callbacks.  Finally, it will allow us to remove
      one level of indirection in the system suspend and resume code paths
      where it is not necessary, which is going to lead to less debug noise
      with initcall_debug passed in the kernel command line (messages won't
      be printed for driverless devices whose subsystems don't provide
      PM callbacks among other things).
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      35cd133c
  22. 28 Nov, 2011 2 commits
  23. 04 Nov, 2011 1 commit
    • Alan Stern's avatar
      PM / Runtime: Automatically retry failed autosuspends · 886486b7
      Alan Stern authored
      Originally, the runtime PM core would send an idle notification
      whenever a suspend attempt failed.  The idle callback routine could
      then schedule a delayed suspend for some time later.
      
      However this behavior was changed by commit
      f71648d7 (PM / Runtime: Remove idle
      notification after failing suspend).  No notifications were sent, and
      there was no clear mechanism to retry failed suspends.
      
      This caused problems for the usbhid driver, because it fails
      autosuspend attempts as long as a key is being held down.  Therefore
      this patch (as1492) adds a mechanism for retrying failed
      autosuspends.  If the callback routine updates the last_busy field so
      that the next autosuspend expiration time is in the future, the
      autosuspend will automatically be rescheduled.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      886486b7
  24. 10 Oct, 2011 1 commit
  25. 21 Sep, 2011 1 commit
  26. 25 Aug, 2011 1 commit
  27. 14 Aug, 2011 1 commit
    • Colin Cross's avatar
      PM / Runtime: Add might_sleep() to runtime PM functions · 311aab73
      Colin Cross authored
      Some of the entry points to pm runtime are not safe to
      call in atomic context unless pm_runtime_irq_safe() has
      been called.  Inspecting the code, it is not immediately
      obvious that the functions sleep at all, as they run
      inside a spin_lock_irqsave, but under some conditions
      they can drop the lock and turn on irqs.
      
      If a driver incorrectly calls the pm_runtime apis, it can
      cause sleeping and irq processing when it expects to stay
      in atomic context.
      
      Add might_sleep_if to the majority of the __pm_runtime_* entry points
      to enforce correct usage.
      
      Add pm_runtime_put_sync_autosuspend to the list of
      functions that can be called in atomic context.
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      311aab73
  28. 05 Aug, 2011 1 commit
    • Kevin Hilman's avatar
      PM / Runtime: Allow _put_sync() from interrupts-disabled context · 02b26774
      Kevin Hilman authored
      Currently the use of pm_runtime_put_sync() is not safe from
      interrupts-disabled context because rpm_idle() will release the
      spinlock and enable interrupts for the idle callbacks.  This enables
      interrupts during a time where interrupts were expected to be
      disabled, and can have strange side effects on drivers that expected
      interrupts to be disabled.
      
      This is not a bug since the documentation clearly states that only
      _put_sync_suspend() is safe in IRQ-safe mode.
      
      However, pm_runtime_put_sync() could be made safe when in IRQ-safe
      mode by releasing the spinlock but not re-enabling interrupts, which
      is what this patch aims to do.
      
      Problem was found when using some buggy drivers that set
      pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
      context.
      Reported-by: default avatarColin Cross <ccross@google.com>
      Tested-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      02b26774
  29. 12 Jul, 2011 1 commit
  30. 06 Jul, 2011 3 commits
    • Rafael J. Wysocki's avatar
      PM / Runtime: Replace "run-time" with "runtime" in documentation · 62052ab1
      Rafael J. Wysocki authored
      The runtime PM documentation and kerneldoc comments sometimes spell
      "runtime" with a dash (i.e. "run-time").  Replace all of those
      instances with "runtime" to make the naming consistent.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      62052ab1
    • Rafael J. Wysocki's avatar
      PM / Runtime: Improve documentation of enable, disable and barrier · e358bad7
      Rafael J. Wysocki authored
      The runtime PM documentation in Documentation/power/runtime_pm.txt
      doesn't say that pm_runtime_enable() and pm_runtime_disable() work by
      operating on power.disable_depth, which is wrong, because the
      possibility of nesting disables doesn't follow from the description
      of these functions.  Also, there is no description of
      pm_runtime_barrier() at all in the document, which is confusing.
      Improve the documentation by fixing those issues.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      e358bad7
    • Rafael J. Wysocki's avatar
      PM: Limit race conditions between runtime PM and system sleep (v2) · 1e2ef05b
      Rafael J. Wysocki authored
      One of the roles of the PM core is to prevent different PM callbacks
      executed for the same device object from racing with each other.
      Unfortunately, after commit e8665002
      (PM: Allow pm_runtime_suspend() to succeed during system suspend)
      runtime PM callbacks may be executed concurrently with system
      suspend/resume callbacks for the same device.
      
      The main reason for commit e8665002
      was that some subsystems and device drivers wanted to use runtime PM
      helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
      particular, for carrying out the suspend of devices in their
      .suspend() callbacks.  However, as it's been determined recently,
      there are multiple reasons not to do so, inlcuding:
      
       * The caller really doesn't control the runtime PM usage counters,
         because user space can access them through sysfs and effectively
         block runtime PM.  That means using pm_runtime_suspend() or
         pm_runtime_get_sync() to suspend devices during system suspend
         may or may not work.
      
       * If a driver calls pm_runtime_suspend() from its .suspend()
         callback, it causes the subsystem's .runtime_suspend() callback to
         be executed, which leads to the call sequence:
      
         subsys->suspend(dev)
            driver->suspend(dev)
               pm_runtime_suspend(dev)
                  subsys->runtime_suspend(dev)
      
         recursive from the subsystem's point of view.  For some subsystems
         that may actually work (e.g. the platform bus type), but for some
         it will fail in a rather spectacular fashion (e.g. PCI).  In each
         case it means a layering violation.
      
       * Both the subsystem and the driver can provide .suspend_noirq()
         callbacks for system suspend that can do whatever the
         .runtime_suspend() callbacks do just fine, so it really isn't
         necessary to call pm_runtime_suspend() during system suspend.
      
       * The runtime PM's handling of wakeup devices is usually different
         from the system suspend's one, so .runtime_suspend() may simply be
         inappropriate for system suspend.
      
       * System suspend is supposed to work even if CONFIG_PM_RUNTIME is
         unset.
      
       * The runtime PM workqueue is frozen before system suspend, so if
         whatever the driver is going to do during system suspend depends
         on it, that simply won't work.
      
      Still, there is a good reason to allow pm_runtime_resume() to
      succeed during system suspend and resume (for instance, some
      subsystems and device drivers may legitimately use it to ensure that
      their devices are in full-power states before suspending them).
      Moreover, there is no reason to prevent runtime PM callbacks from
      being executed in parallel with the system suspend/resume .prepare()
      and .complete() callbacks and the code removed by commit
      e8665002 went too far in this
      respect.  On the other hand, runtime PM callbacks, including
      .runtime_resume(), must not be executed during system suspend's
      "late" stage of suspending devices and during system resume's "early"
      device resume stage.
      
      Taking all of the above into consideration, make the PM core
      acquire a runtime PM reference to every device and resume it if
      there's a runtime PM resume request pending right before executing
      the subsystem-level .suspend() callback for it.  Make the PM core
      drop references to all devices right after executing the
      subsystem-level .resume() callbacks for them.  Additionally,
      make the PM core disable the runtime PM framework for all devices
      during system suspend, after executing the subsystem-level .suspend()
      callbacks for them, and enable the runtime PM framework for all
      devices during system resume, right before executing the
      subsystem-level .resume() callbacks for them.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      1e2ef05b