1. 06 7月, 2011 1 次提交
    • R
      PM: Limit race conditions between runtime PM and system sleep (v2) · 1e2ef05b
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NKevin Hilman <khilman@ti.com>
      1e2ef05b
  2. 02 7月, 2011 1 次提交
    • R
      PM / Domains: Rename struct dev_power_domain to struct dev_pm_domain · 564b905a
      Rafael J. Wysocki 提交于
      The naming convention used by commit 7538e3db6e015e890825fbd9f86599b
      (PM: Add support for device power domains), which introduced the
      struct dev_power_domain type for representing device power domains,
      evidently confuses some developers who tend to think that objects
      of this type must correspond to "power domains" as defined by
      hardware, which is not the case.  Namely, at the kernel level, a
      struct dev_power_domain object can represent arbitrary set of devices
      that are mutually dependent power management-wise and need not belong
      to one hardware power domain.  To avoid that confusion, rename struct
      dev_power_domain to struct dev_pm_domain and rename the related
      pointers in struct device and struct pm_clk_notifier_block from
      pwr_domain to pm_domain.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NKevin Hilman <khilman@ti.com>
      564b905a
  3. 22 6月, 2011 2 次提交
    • A
      PM: Fix async resume following suspend failure · 6d0e0e84
      Alan Stern 提交于
      The PM core doesn't handle suspend failures correctly when it comes to
      asynchronously suspended devices.  These devices are moved onto the
      dpm_suspended_list as soon as the corresponding async thread is
      started up, and they remain on the list even if they fail to suspend
      or the sleep transition is cancelled before they get suspended.  As a
      result, when the PM core unwinds the transition, it tries to resume
      the devices even though they were never suspended.
      
      This patch (as1474) fixes the problem by adding a new "is_suspended"
      flag to dev_pm_info.  Devices are resumed only if the flag is set.
      
      [rjw:
       * Moved the dev->power.is_suspended check into device_resume(),
         because we need to complete dev->power.completion and clear
         dev->power.is_prepared too for devices whose
         dev->power.is_suspended flags are unset.
       * Fixed __device_suspend() to avoid setting dev->power.is_suspended
         if async_error is different from zero.]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: stable@kernel.org
      6d0e0e84
    • A
      PM: Rename dev_pm_info.in_suspend to is_prepared · f76b168b
      Alan Stern 提交于
      This patch (as1473) renames the "in_suspend" field in struct
      dev_pm_info to "is_prepared", in preparation for an upcoming change.
      The new name is more descriptive of what the field really means.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: stable@kernel.org
      f76b168b
  4. 18 5月, 2011 1 次提交
    • R
      PM: Allow drivers to allocate memory from .prepare() callbacks safely · 91e7c75b
      Rafael J. Wysocki 提交于
      If device drivers allocate substantial amounts of memory (above 1 MB)
      in their hibernate .freeze() callbacks (or in their legacy suspend
      callbcks during hibernation), the subsequent creation of hibernate
      image may fail due to the lack of memory.  This is the case, because
      the drivers' .freeze() callbacks are executed after the hibernate
      memory preallocation has been carried out and the preallocated amount
      of memory may be too small to cover the new driver allocations.
      Unfortunately, the drivers' .prepare() callbacks also are executed
      after the hibernate memory preallocation has completed, so they are
      not suitable for allocating additional memory either.  Thus the only
      way a driver can safely allocate memory during hibernation is to use
      a hibernate/suspend notifier.  However, the notifiers are called
      before the freezing of user space and the drivers wanting to use them
      for allocating additional memory may not know how much memory needs
      to be allocated at that point.
      
      To let device drivers overcome this difficulty rework the hibernation
      sequence so that the memory preallocation is carried out after the
      drivers' .prepare() callbacks have been executed, so that the
      .prepare() callbacks can be used for allocating additional memory
      to be used by the drivers' .freeze() callbacks.  Update documentation
      to match the new behavior of the code.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      91e7c75b
  5. 29 4月, 2011 1 次提交
    • R
      PM: Make power domain callbacks take precedence over subsystem ones · 4d27e9dc
      Rafael J. Wysocki 提交于
      Change the PM core's behavior related to power domains in such a way
      that, if a power domain is defined for a given device, its callbacks
      will be executed instead of and not in addition to the device
      subsystem's PM callbacks.
      
      The idea behind the initial implementation of power domains handling
      by the PM core was that power domain callbacks would be executed in
      addition to subsystem callbacks, so that it would be possible to
      extend the subsystem callbacks by using power domains.  It turns out,
      however, that this wouldn't be really convenient in some important
      situations.
      
      For example, there are systems in which power can only be removed
      from entire power domains.  On those systems it is not desirable to
      execute device drivers' PM callbacks until it is known that power is
      going to be removed from the devices in question, which means that
      they should be executed by power domain callbacks rather then by
      subsystem (e.g. bus type) PM callbacks, because subsystems generally
      have no information about what devices belong to which power domain.
      Thus, for instance, if the bus type in question is the platform bus
      type, its PM callbacks generally should not be called in addition to
      power domain callbacks, because they run device drivers' callbacks
      unconditionally if defined.
      
      While in principle the default subsystem PM callbacks, or a subset of
      them, may be replaced with different functions, it doesn't seem
      correct to do so, because that would change the subsystem's behavior
      with respect to all devices in the system, regardless of whether or
      not they belong to any power domains.  Thus, the only remaining
      option is to make power domain callbacks take precedence over
      subsystem callbacks.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NKevin Hilman <khilman@ti.com>
      4d27e9dc
  6. 26 4月, 2011 1 次提交
    • R
      PM / Wakeup: Fix initialization of wakeup-related device sysfs files · 22110faf
      Rafael J. Wysocki 提交于
      It turns out that some PCI devices are only found to be
      wakeup-capable during registration, in which case, when
      device_set_wakeup_capable() is called, device_is_registered() already
      returns 'true' for the given device, but dpm_sysfs_add() hasn't been
      called for it yet.  This leads to situations in which the device's
      power.can_wakeup flag is not set as requested because of failing
      wakeup_sysfs_add() and its wakeup-related sysfs files are not
      created, although they should be present.  This is a post-2.6.38
      regression introduced by commit cb8f51bd
      (PM: Do not create wakeup sysfs files for devices that cannot wake
      up).
      
      To work around this problem initialize the device's power.entry
      field to an empty list head and make device_set_wakeup_capable()
      check if it is still empty before attempting to add the devices
      wakeup-related sysfs files with wakeup_sysfs_add().  Namely, if
      power.entry is still empty at this point, device_pm_add() hasn't been
      called yet for the device and its wakeup-related files will be
      created later, so device_set_wakeup_capable() doesn't have to create
      them.
      Reported-and-tested-by: NTino Keitel <tino.keitel@tikei.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      22110faf
  7. 12 4月, 2011 1 次提交
    • R
      PM / Hibernate: Introduce CONFIG_HIBERNATE_CALLBACKS · 1f112cee
      Rafael J. Wysocki 提交于
      Xen save/restore is going to use hibernate device callbacks for
      quiescing devices and putting them back to normal operations and it
      would need to select CONFIG_HIBERNATION for this purpose.  However,
      that also would cause the hibernate interfaces for user space to be
      enabled, which might confuse user space, because the Xen kernels
      don't support hibernation.  Moreover, it would be wasteful, as it
      would make the Xen kernels include a substantial amount of code that
      they would never use.
      
      To address this issue introduce new power management Kconfig option
      CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
      that is necessary for the hibernate device callbacks to work and make
      CONFIG_HIBERNATION select it.  Then, Xen save/restore will be able to
      select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
      hibernate code along with it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NShriram Rajagopalan <rshriram@cs.ubc.ca>
      1f112cee
  8. 15 3月, 2011 3 次提交
    • R
      PM: Make system-wide PM and runtime PM treat subsystems consistently · 9659cc06
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9659cc06
    • R
      PM: Add support for device power domains · 7538e3db
      Rafael J. Wysocki 提交于
      The platform bus type is often used to handle Systems-on-a-Chip (SoC)
      where all devices are represented by objects of type struct
      platform_device.  In those cases the same "platform" device driver
      may be used with multiple different system configurations, but the
      actions needed to put the devices it handles into a low-power state
      and back into the full-power state may depend on the design of the
      given SoC.  The driver, however, cannot possibly include all the
      information necessary for the power management of its device on all
      the systems it is used with.  Moreover, the device hierarchy in its
      current form also is not suitable for representing this kind of
      information.
      
      The patch below attempts to address this problem by introducing
      objects of type struct dev_power_domain that can be used for
      representing power domains within a SoC.  Every struct
      dev_power_domain object provides a sets of device power
      management callbacks that can be used to perform what's needed for
      device power management in addition to the operations carried out by
      the device's driver and subsystem.
      
      Namely, if a struct dev_power_domain object is pointed to by the
      pwr_domain field in a struct device, the callbacks provided by its
      ops member will be executed in addition to the corresponding
      callbacks provided by the device's subsystem and driver during all
      power transitions.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-and-acked-by: NKevin Hilman <khilman@ti.com>
      7538e3db
    • R
      PM: Allow pm_runtime_suspend() to succeed during system suspend · e8665002
      Rafael J. Wysocki 提交于
      The dpm_prepare() function increments the runtime PM reference
      counters of all devices to prevent pm_runtime_suspend() from
      executing subsystem-level callbacks.  However, this was supposed to
      guard against a specific race condition that cannot happen, because
      the power management workqueue is freezable, so pm_runtime_suspend()
      can only be called synchronously during system suspend and we can
      rely on subsystems and device drivers to avoid doing that
      unnecessarily.
      
      Make dpm_prepare() drop the runtime PM reference to each device
      after making sure that runtime resume is not pending for it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NKevin Hilman <khilman@ti.com>
      e8665002
  9. 24 12月, 2010 9 次提交
  10. 11 11月, 2010 1 次提交
    • R
      PM: Allow devices to be removed during late suspend and early resume · d08a5ace
      Rafael J. Wysocki 提交于
      Holding dpm_list_mtx across late suspend and early resume of devices
      is problematic for the PCMCIA subsystem and doesn't allow device
      objects to be removed by late suspend and early resume driver
      callbacks.  This appears to be overly restrictive, as drivers are
      generally allowed to remove device objects in other phases of suspend
      and resume.  Therefore rework dpm_{suspend|resume}_noirq() so that
      they don't have to hold dpm_list_mtx all the time.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d08a5ace
  11. 02 11月, 2010 1 次提交
  12. 17 10月, 2010 3 次提交
    • R
      PM: Fix potential issue with failing asynchronous suspend · 098dff73
      Rafael J. Wysocki 提交于
      There is a potential issue with the asynchronous suspend code that
      a device driver suspending asynchronously may not notice that it
      should back off.  There are two failing scenarions, (1) when the
      driver is waiting for a driver suspending synchronously to complete
      and that second driver returns error code, in which case async_error
      won't be set and the waiting driver will continue suspending and (2)
      after the driver has called device_pm_wait_for_dev() and the waited
      for driver returns error code, in which case the caller of
      device_pm_wait_for_dev() will not know that there was an error and
      will continue suspending.
      
      To fix this issue make __device_suspend() set async_error, so
      async_suspend() doesn't need to set it any more, and make
      device_pm_wait_for_dev() return async_error, so that its callers
      can check whether or not they should continue suspending.
      
      No more changes are necessary, since device_pm_wait_for_dev() is
      not used by any drivers' suspend routines.
      Reported-by: NColin Cross <ccross@android.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      098dff73
    • R
      PM / Wakeup: Introduce wakeup source objects and event statistics (v3) · 074037ec
      Rafael J. Wysocki 提交于
      Introduce struct wakeup_source for representing system wakeup sources
      within the kernel and for collecting statistics related to them.
      Make the recently introduced helper functions pm_wakeup_event(),
      pm_stay_awake() and pm_relax() use struct wakeup_source objects
      internally, so that wakeup statistics associated with wakeup devices
      can be collected and reported in a consistent way (the definition of
      pm_relax() is changed, which is harmless, because this function is
      not called directly by anyone yet).  Introduce new wakeup-related
      sysfs device attributes in /sys/devices/.../power for reporting the
      device wakeup statistics.
      
      Change the global wakeup events counters event_count and
      events_in_progress into atomic variables, so that it is not necessary
      to acquire a global spinlock in pm_wakeup_event(), pm_stay_awake()
      and pm_relax(), which should allow us to avoid lock contention in
      these functions on SMP systems with many wakeup devices.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      074037ec
    • K
      PM: Fix signed/unsigned warning in dpm_show_time() · 0702d9ee
      Kevin Cernekee 提交于
      Seen on MIPS32, gcc 4.4.3, 2.6.36-rc4:
      
      drivers/base/power/main.c: In function 'dpm_show_time':
      drivers/base/power/main.c:415: warning: comparison of distinct pointer types lacks a cast
      
      do_div() takes unsigned parameters:
      
      uint32_t do_div(uint64_t *n, uint32_t base);
      
      Using an unsigned variable for usecs64 should not cause any problems,
      because calltime >= starttime .
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      0702d9ee
  13. 09 9月, 2010 1 次提交
    • C
      PM: Prevent waiting forever on asynchronous resume after failing suspend · 152e1d59
      Colin Cross 提交于
      During suspend, the power.completion is expected to be set when a
      device has not yet started suspending.  Set it on init to fix a
      corner case where a device is resumed when its parent has never
      suspended.
      
      Consider three drivers, A, B, and C.  The parent of A is C, and C
      has async_suspend set.  On boot, C->power.completion is initialized
      to 0.
      
      During the first suspend:
      suspend_devices_and_enter(...)
       dpm_resume(...)
        device_suspend(A)
        device_suspend(B) returns error, aborts suspend
       dpm_resume_end(...)
         dpm_resume(...)
          device_resume(A)
           dpm_wait(A->parent == C)
            wait_for_completion(C->power.completion)
      
      The wait_for_completion will never complete, because
      complete_all(C->power.completion) will only be called from
      device_suspend(C) or device_resume(C), neither of which is called
      if suspend is aborted before C.
      
      After a successful suspend->resume cycle, where B doesn't abort
      suspend, C->power.completion is left in the completed state by the
      call to device_resume(C), and the same call path will work if B
      aborts suspend.
      Signed-off-by: NColin Cross <ccross@android.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      152e1d59
  14. 19 7月, 2010 1 次提交
    • R
      PM: Make it possible to avoid races between wakeup and system sleep · c125e96f
      Rafael J. Wysocki 提交于
      One of the arguments during the suspend blockers discussion was that
      the mainline kernel didn't contain any mechanisms making it possible
      to avoid races between wakeup and system suspend.
      
      Generally, there are two problems in that area.  First, if a wakeup
      event occurs exactly when /sys/power/state is being written to, it
      may be delivered to user space right before the freezer kicks in, so
      the user space consumer of the event may not be able to process it
      before the system is suspended.  Second, if a wakeup event occurs
      after user space has been frozen, it is not generally guaranteed that
      the ongoing transition of the system into a sleep state will be
      aborted.
      
      To address these issues introduce a new global sysfs attribute,
      /sys/power/wakeup_count, associated with a running counter of wakeup
      events and three helper functions, pm_stay_awake(), pm_relax(), and
      pm_wakeup_event(), that may be used by kernel subsystems to control
      the behavior of this attribute and to request the PM core to abort
      system transitions into a sleep state already in progress.
      
      The /sys/power/wakeup_count file may be read from or written to by
      user space.  Reads will always succeed (unless interrupted by a
      signal) and return the current value of the wakeup events counter.
      Writes, however, will only succeed if the written number is equal to
      the current value of the wakeup events counter.  If a write is
      successful, it will cause the kernel to save the current value of the
      wakeup events counter and to abort the subsequent system transition
      into a sleep state if any wakeup events are reported after the write
      has returned.
      
      [The assumption is that before writing to /sys/power/state user space
      will first read from /sys/power/wakeup_count.  Next, user space
      consumers of wakeup events will have a chance to acknowledge or
      veto the upcoming system transition to a sleep state.  Finally, if
      the transition is allowed to proceed, /sys/power/wakeup_count will
      be written to and if that succeeds, /sys/power/state will be written
      to as well.  Still, if any wakeup events are reported to the PM core
      by kernel subsystems after that point, the transition will be
      aborted.]
      
      Additionally, put a wakeup events counter into struct dev_pm_info and
      make these per-device wakeup event counters available via sysfs,
      so that it's possible to check the activity of various wakeup event
      sources within the kernel.
      
      To illustrate how subsystems can use pm_wakeup_event(), make the
      low-level PCI runtime PM wakeup-handling code use it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: Nmarkgross <markgross@thegnar.org>
      Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
      c125e96f
  15. 24 3月, 2010 1 次提交
  16. 08 3月, 2010 1 次提交
    • G
      Driver core: create lock/unlock functions for struct device · 8e9394ce
      Greg Kroah-Hartman 提交于
      In the future, we are going to be changing the lock type for struct
      device (once we get the lockdep infrastructure properly worked out)  To
      make that changeover easier, and to possibly burry the lock in a
      different part of struct device, let's create some functions to lock and
      unlock a device so that no out-of-core code needs to be changed in the
      future.
      
      This patch creates the device_lock/unlock/trylock() functions, and
      converts all in-tree users to them.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Magnus Damm <damm@igel.co.jp>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Alex Chiang <achiang@hp.com>
      Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrew Patterson <andrew.patterson@hp.com>
      Cc: Yu Zhao <yu.zhao@intel.com>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Wolfram Sang <w.sang@pengutronix.de>
      Cc: CHENG Renquan <rqcheng@smu.edu.sg>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: Frans Pop <elendil@planet.nl>
      Cc: David Vrabel <david.vrabel@csr.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      8e9394ce
  17. 27 2月, 2010 5 次提交
    • R
      PM: Allow device drivers to use dpm_wait() · f8824cee
      Rafael J. Wysocki 提交于
      There are some dependencies between devices (in particular, between
      EHCI USB controllers and their OHCI/UHCI siblings) which are not
      reflected by the structure of the device tree.  With synchronous
      suspend and resume these dependencies are taken into accout
      automatically, because the devices in question are always registered
      in the right order, but to meet these constraints with asynchronous
      suspend and resume the drivers of these devices will need to use
      dpm_wait() in their suspend/resume routines, so introduce a helper
      function allowing them to do that.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      f8824cee
    • R
      PM: Start asynchronous resume threads upfront · 97df8c12
      Rafael J. Wysocki 提交于
      It has been shown by testing that total device resume time can be
      reduced significantly (by as much as 50% or more) if the async
      threads executing some devices' resume routines are all started
      before the main resume thread starts to handle the "synchronous"
      devices.
      
      This is a consequence of the fact that the slowest devices tend to be
      located at the end of dpm_list, so their resume routines are started
      very late.  Consequently, they have to wait for all the preceding
      "synchronous" devices before their resume routines can be started
      by the main resume thread, even if they are "asynchronous".  By
      starting their async threads upfront we effectively move those
      devices towards the beginning of dpm_list, without breaking their
      ordering with respect to their parents and children.  As a result,
      their resume routines are started much earlier and we are able to
      save much more device resume time this way.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      97df8c12
    • R
      PM: Add a switch for disabling/enabling asynchronous suspend/resume · 0e06b4a8
      Rafael J. Wysocki 提交于
      Add sysfs attribute /sys/power/pm_async allowing the user space to
      disable/enable asynchronous suspend/resume of devices.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      0e06b4a8
    • R
      PM: Asynchronous suspend and resume of devices · 5af84b82
      Rafael J. Wysocki 提交于
      Theoretically, the total time of system sleep transitions (suspend
      to RAM, hibernation) can be reduced by running suspend and resume
      callbacks of device drivers in parallel with each other.  However,
      there are dependencies between devices such that we're not allowed
      to suspend the parent of a device before suspending the device
      itself.  Analogously, we're not allowed to resume a device before
      resuming its parent.
      
      The most straightforward way to take these dependencies into accout
      is to start the async threads used for suspending and resuming
      devices at the core level, so that async_schedule() is called for
      each suspend and resume callback supposed to be executed
      asynchronously.
      
      For this purpose, introduce a new device flag, power.async_suspend,
      used to mark the devices whose suspend and resume callbacks are to be
      executed asynchronously (ie. in parallel with the main suspend/resume
      thread and possibly in parallel with each other) and helper function
      device_enable_async_suspend() allowing one to set power.async_suspend
      for given device (power.async_suspend is unset by default for all
      devices).  For each device with the power.async_suspend flag set the
      PM core will use async_schedule() to execute its suspend and resume
      callbacks.
      
      The async threads started for different devices as a result of
      calling async_schedule() are synchronized with each other and with
      the main suspend/resume thread with the help of completions, in the
      following way:
      (1) There is a completion, power.completion, for each device object.
      (2) Each device's completion is reset before calling async_schedule()
          for the device or, in the case of devices with the
          power.async_suspend flags unset, before executing the device's
          suspend and resume callbacks.
      (3) During suspend, right before running the bus type, device type
          and device class suspend callbacks for the device, the PM core
          waits for the completions of all the device's children to be
          completed.
      (4) During resume, right before running the bus type, device type and
          device class resume callbacks for the device, the PM core waits
          for the completion of the device's parent to be completed.
      (5) The PM core completes power.completion for each device right
          after the bus type, device type and device class suspend (or
          resume) callbacks executed for the device have returned.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5af84b82
    • R
      PM: Add parent information to timing messages · 8cc6b39f
      Rafael J. Wysocki 提交于
      Add parent information to the messages printed by the suspend/resume
      core when initcall_debug is set.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8cc6b39f
  18. 12 1月, 2010 1 次提交
  19. 21 12月, 2009 1 次提交
    • A
      PM: Use pm_runtime_put_sync in system resume · aa0baaef
      Alan Stern 提交于
      This patch (as1317) fixes a bug in the PM core.  When a device is
      resumed following a system sleep, the core decrements the device's
      runtime PM usage counter but doesn't issue an idle notification if the
      counter reaches 0.  This could prevent an otherwise unused device from
      being runtime-suspended again after the system sleep.
      
      The fix is to call pm_runtime_put_sync() instead of
      pm_runtime_put_noidle().
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      aa0baaef
  20. 18 12月, 2009 2 次提交
    • R
      PM: Measure device suspend and resume times · ecf762b2
      Rafael J. Wysocki 提交于
      Measure and print the time of suspending and resuming all devices.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      ecf762b2
    • R
      PM: Make the initcall_debug style timing for suspend/resume complete · 875ab0b7
      Rafael J. Wysocki 提交于
      Commit f2511774
      (PM: Add initcall_debug style timing for suspend/resume) introduced
      basic timing instrumentation, needed for a scritps/bootgraph.pl
      equivalent or humans, but it missed the fact that bus types and
      device classes which haven't been switched to using struct dev_pm_ops
      objects yet need special handling.  As a result, the suspend/resume
      timing information is only available for devices whose bus types or
      device classes use struct dev_pm_ops objects, so the majority of
      devices is not covered.
      
      Fix this by adding basic suspend/resume timing instrumentation for
      devices whose bus types and device classes still don't use struct
      dev_pm_ops objects for power management.  To reduce code duplication
      move the timing code to helper functions.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      875ab0b7
  21. 16 12月, 2009 2 次提交