1. 21 Sep, 2011 1 commit
  2. 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
  3. 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
  4. 12 Jul, 2011 1 commit
  5. 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
  6. 02 Jul, 2011 5 commits
  7. 21 Jun, 2011 1 commit
  8. 14 Mar, 2011 1 commit
    • Rafael J. Wysocki's avatar
      PM: Make system-wide PM and runtime PM treat subsystems consistently · 9659cc06
      Rafael J. Wysocki authored
      The code handling system-wide power transitions (eg. suspend-to-RAM)
      can in theory execute callbacks provided by the device's bus type,
      device type and class in each phase of the power transition.  In
      turn, the runtime PM core code only calls one of those callbacks at
      a time, preferring bus type callbacks to device type or class
      callbacks and device type callbacks to class callbacks.
      
      It seems reasonable to make them both behave in the same way in that
      respect.  Moreover, even though a device may belong to two subsystems
      (eg. bus type and device class) simultaneously, in practice power
      management callbacks for system-wide power transitions are always
      provided by only one of them (ie. if the bus type callbacks are
      defined, the device class ones are not and vice versa).  Thus it is
      possible to modify the code handling system-wide power transitions
      so that it follows the core runtime PM code (ie. treats the
      subsystem callbacks as mutually exclusive).
      
      On the other hand, the core runtime PM code will choose to execute,
      for example, a runtime suspend callback provided by the device type
      even if the bus type's struct dev_pm_ops object exists, but the
      runtime_suspend pointer in it happens to be NULL.  This is confusing,
      because it may lead to the execution of callbacks from different
      subsystems during different operations (eg. the bus type suspend
      callback may be executed during runtime suspend of the device, while
      the device type callback will be executed during system suspend).
      
      Make all of the power management code treat subsystem callbacks in
      a consistent way, such that:
      (1) If the device's type is defined (eg. dev->type is not NULL)
          and its pm pointer is not NULL, the callbacks from dev->type->pm
          will be used.
      (2) If dev->type is NULL or dev->type->pm is NULL, but the device's
          class is defined (eg. dev->class is not NULL) and its pm pointer
          is not NULL, the callbacks from dev->class->pm will be used.
      (3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
          NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
          will be used provided that both dev->bus and dev->bus->pm are
          not NULL.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9659cc06
  9. 24 Dec, 2010 1 commit
    • Alan Stern's avatar
      PM / Runtime: Add synchronous runtime interface for interrupt handlers (v3) · c7b61de5
      Alan Stern authored
      This patch (as1431c) makes the synchronous runtime-PM interface
      suitable for use in interrupt handlers.  Subsystems can call the new
      pm_runtime_irq_safe() function to tell the PM core that a device's
      runtime_suspend and runtime_resume callbacks should be invoked with
      interrupts disabled and the spinlock held.  This permits the
      pm_runtime_get_sync() and the new pm_runtime_put_sync_suspend()
      routines to be called from within interrupt handlers.
      
      When a device is declared irq-safe in this way, the PM core increments
      the parent's usage count, so the parent will never be runtime
      suspended.  This prevents difficult situations in which an irq-safe
      device can't resume because it is forced to wait for its non-irq-safe
      parent.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      c7b61de5
  10. 16 Dec, 2010 1 commit
    • Rafael J. Wysocki's avatar
      PM / Runtime: Fix pm_runtime_suspended() · f08f5a0a
      Rafael J. Wysocki authored
      There are some situations (e.g. in __pm_generic_call()), where
      pm_runtime_suspended() is used to decide whether or not to execute
      a device's (system) ->suspend() callback.  The callback is not
      executed if pm_runtime_suspended() returns true, but it does so
      for devices that don't even support runtime PM, because the
      power.disable_depth device field is ignored by it.  This leads to
      problems (i.e. devices are not suspened when they should), so rework
      pm_runtime_suspended() so that it returns false if the device's
      power.disable_depth field is different from zero.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Cc: stable@kernel.org
      f08f5a0a
  11. 16 Oct, 2010 2 commits
    • Alan Stern's avatar
      PM / Runtime: Implement autosuspend support · 15bcb91d
      Alan Stern authored
      This patch (as1427) implements the "autosuspend" facility for runtime
      PM.  A few new fields are added to the dev_pm_info structure and
      several new PM helper functions are defined, for telling the PM core
      whether or not a device uses autosuspend, for setting the autosuspend
      delay, and for marking periods of device activity.
      
      Drivers that do not want to use autosuspend can continue using the
      same helper functions as before; their behavior will not change.  In
      addition, drivers supporting autosuspend can also call the old helper
      functions to get the old behavior.
      
      The details are all explained in Documentation/power/runtime_pm.txt
      and Documentation/ABI/testing/sysfs-devices-power.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      15bcb91d
    • Alan Stern's avatar
      PM / Runtime: Add no_callbacks flag · 7490e442
      Alan Stern authored
      Some devices, such as USB interfaces, cannot be power-managed
      independently of their parents, i.e., they cannot be put in low power
      while the parent remains at full power.  This patch (as1425) creates a
      new "no_callbacks" flag, which tells the PM core not to invoke the
      runtime-PM callback routines for the such devices but instead to
      assume that the callbacks always succeed.  In addition, the
      non-debugging runtime-PM sysfs attributes for the devices are removed,
      since they are pretty much meaningless.
      
      The advantage of this scheme comes not so much from avoiding the
      callbacks themselves, but rather from the fact that without the need
      for a process context in which to run the callbacks, more work can be
      done in interrupt context.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      7490e442
  12. 06 Mar, 2010 2 commits
    • Rafael J. Wysocki's avatar
      PM: Provide generic subsystem-level callbacks · d690b2cd
      Rafael J. Wysocki authored
      There are subsystems whose power management callbacks only need to
      invoke the callbacks provided by device drivers.  Still, their system
      sleep PM callbacks should play well with the runtime PM callbacks,
      so that devices suspended at run time can be left in that state for
      a system sleep transition.
      
      Provide a set of generic PM callbacks for such subsystems and
      define convenience macros for populating dev_pm_ops structures.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      d690b2cd
    • Rafael J. Wysocki's avatar
      PM / Runtime: Document power.runtime_auto and related functions · 87d1b3e6
      Rafael J. Wysocki authored
      The power.runtime_auto device flag and the helper functions
      pm_runtime_allow() and pm_runtime_forbid() used to modify it are a
      part of the run-time power management framework and therefore they
      should be described in Documentation/power/runtime_pm.txt.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      87d1b3e6
  13. 05 Feb, 2010 1 commit
  14. 22 Dec, 2009 2 commits
  15. 06 Dec, 2009 2 commits
  16. 22 Aug, 2009 1 commit
    • Rafael J. Wysocki's avatar
      PM: Introduce core framework for run-time PM of I/O devices (rev. 17) · 5e928f77
      Rafael J. Wysocki authored
      Introduce a core framework for run-time power management of I/O
      devices.  Add device run-time PM fields to 'struct dev_pm_info'
      and device run-time PM callbacks to 'struct dev_pm_ops'.  Introduce
      a run-time PM workqueue and define some device run-time PM helper
      functions at the core level.  Document all these things.
      
      Special thanks to Alan Stern for his help with the design and
      multiple detailed reviews of the pereceding versions of this patch
      and to Magnus Damm for testing feedback.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarMagnus Damm <damm@igel.co.jp>
      5e928f77