1. 19 7月, 2012 2 次提交
  2. 11 7月, 2012 1 次提交
    • P
      PM / cpuidle: System resume hang fix with cpuidle · 8651f97b
      Preeti U Murthy 提交于
      On certain bios, resume hangs if cpus are allowed to enter idle states
      during suspend [1].
      
      This was fixed in apci idle driver [2].But intel_idle driver does not
      have this fix. Thus instead of replicating the fix in both the idle
      drivers, or in more platform specific idle drivers if needed, the
      more general cpuidle infrastructure could handle this.
      
      A suspend callback in cpuidle_driver could handle this fix. But
      a cpuidle_driver provides only basic functionalities like platform idle
      state detection capability and mechanisms to support entry and exit
      into CPU idle states. All other cpuidle functions are found in the
      cpuidle generic infrastructure for good reason that all cpuidle
      drivers, irrepective of their platforms will support these functions.
      
      One option therefore would be to register a suspend callback in cpuidle
      which handles this fix. This could be called through a PM_SUSPEND_PREPARE
      notifier. But this is too generic a notfier for a driver to handle.
      
      Also, ideally the job of cpuidle is not to handle side effects of suspend.
      It should expose the interfaces which "handle cpuidle 'during' suspend"
      or any other operation, which the subsystems call during that respective
      operation.
      
      The fix demands that during suspend, no cpus should be allowed to enter
      deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
      ensures that. Not just that it also kicks all the cpus which are already
      in idle out of their idle states which was being done during cpu hotplug
      through a CPU_DYING_FROZEN callbacks.
      
      Now the question arises about when during suspend should
      cpuidle_uninstall_idle_handler() be called. Since we are dealing with
      drivers it seems best to call this function during dpm_suspend().
      Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
      before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
      operations. In dpm_suspend_noirq(), it would be wise to place this call
      before suspend_device_irqs() to avoid ugly interactions with the same.
      
      Ananlogously, during resume.
      
      References:
      [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
      [2] http://marc.info/?l=linux-pm&m=133958534231884&w=2Reported-and-tested-by: NDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8651f97b
  3. 01 7月, 2012 2 次提交
  4. 25 6月, 2012 1 次提交
  5. 02 5月, 2012 1 次提交
  6. 30 1月, 2012 1 次提交
    • R
      PM / Sleep: Introduce "late suspend" and "early resume" of devices · cf579dfb
      Rafael J. Wysocki 提交于
      The current device suspend/resume phases during system-wide power
      transitions appear to be insufficient for some platforms that want
      to use the same callback routines for saving device states and
      related operations during runtime suspend/resume as well as during
      system suspend/resume.  In principle, they could point their
      .suspend_noirq() and .resume_noirq() to the same callback routines
      as their .runtime_suspend() and .runtime_resume(), respectively,
      but at least some of them require device interrupts to be enabled
      while the code in those routines is running.
      
      It also makes sense to have device suspend-resume callbacks that will
      be executed with runtime PM disabled and with device interrupts
      enabled in case someone needs to run some special code in that
      context during system-wide power transitions.
      
      Apart from this, .suspend_noirq() and .resume_noirq() were introduced
      as a workaround for drivers using shared interrupts and failing to
      prevent their interrupt handlers from accessing suspended hardware.
      It appears to be better not to use them for other porposes, or we may
      have to deal with some serious confusion (which seems to be happening
      already).
      
      For the above reasons, introduce new device suspend/resume phases,
      "late suspend" and "early resume" (and analogously for hibernation)
      whose callback will be executed with runtime PM disabled and with
      device interrupts enabled and whose callback pointers generally may
      point to runtime suspend/resume routines.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      cf579dfb
  7. 22 12月, 2011 2 次提交
    • R
      PM: Run the driver callback directly if the subsystem one is not there · 35cd133c
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      35cd133c
    • R
      PM / Sleep: Make pm_op() and pm_noirq_op() return callback pointers · 9cf519d1
      Rafael J. Wysocki 提交于
      Make the pm_op() and pm_noirq_op() functions return pointers to
      appropriate callbacks instead of executing those callbacks and
      returning their results.
      
      This change is required for a subsequent modification that will
      execute the corresponding driver callback if the subsystem
      callback returned by either pm_op(), or pm_noirq_op() is NULL.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      9cf519d1
  8. 07 12月, 2011 1 次提交
  9. 24 11月, 2011 2 次提交
  10. 18 11月, 2011 1 次提交
    • R
      PM Sleep: Do not extend wakeup paths to devices with ignore_children set · 8b258cc8
      Rafael J. Wysocki 提交于
      Commit 4ca46ff3 (PM / Sleep: Mark
      devices involved in wakeup signaling during suspend) introduced
      the power.wakeup_path field in struct dev_pm_info to mark devices
      whose children are enabled to wake up the system from sleep states,
      so that power domains containing the parents that provide their
      children with wakeup power and/or relay their wakeup signals are not
      turned off.  Unfortunately, that introduced a PM regression on SH7372
      whose power consumption in the system "memory sleep" state increased
      as a result of it, because it prevented the power domain containing
      the I2C controller from being turned off when some children of that
      controller were enabled to wake up the system, although the
      controller was not necessary for them to signal wakeup.
      
      To fix this issue use the observation that devices whose
      power.ignore_children flag is set for runtime PM should be treated
      analogously during system suspend.  Namely, they shouldn't be
      included in wakeup paths going through their children.  Since the
      SH7372 I2C controller's power.ignore_children flag is set, doing so
      will restore the previous behavior of that SOC.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8b258cc8
  11. 01 11月, 2011 1 次提交
  12. 22 10月, 2011 1 次提交
    • R
      PM / Sleep: Mark devices involved in wakeup signaling during suspend · 4ca46ff3
      Rafael J. Wysocki 提交于
      The generic PM domains code in drivers/base/power/domain.c has
      to avoid powering off domains that provide power to wakeup devices
      during system suspend.  Currently, however, this only works for
      wakeup devices directly belonging to the given domain and not for
      their children (or the children of their children and so on).
      Thus, if there's a wakeup device whose parent belongs to a power
      domain handled by the generic PM domains code, the domain will be
      powered off during system suspend preventing the device from
      signaling wakeup.
      
      To address this problem introduce a device flag, power.wakeup_path,
      that will be set during system suspend for all wakeup devices,
      their parents, the parents of their parents and so on.  This way,
      all wakeup paths in the device hierarchy will be marked and the
      generic PM domains code will only need to avoid powering off
      domains containing devices whose power.wakeup_path is set.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      4ca46ff3
  13. 17 10月, 2011 1 次提交
    • S
      PM / Suspend: Add statistics debugfs file for suspend to RAM · 2a77c46d
      ShuoX Liu 提交于
      Record S3 failure time about each reason and the latest two failed
      devices' names in S3 progress.
      We can check it through 'suspend_stats' entry in debugfs.
      
      The motivation of the patch:
      
      We are enabling power features on Medfield. Comparing with PC/notebook,
      a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
      more frequently. If it can't enter suspend-2-ram in time, the power
      might be used up soon.
      
      We often find sometimes, a device suspend fails. Then, system retries
      s3 over and over again. As display is off, testers and developers
      don't know what happens.
      
      Some testers and developers complain they don't know if system
      tries suspend-2-ram, and what device fails to suspend. They need
      such info for a quick check. The patch adds suspend_stats under
      debugfs for users to check suspend to RAM statistics quickly.
      
      If not using this patch, we have other methods to get info about
      what device fails. One is to turn on  CONFIG_PM_DEBUG, but users
      would get too much info and testers need recompile the system.
      
      In addition, dynamic debug is another good tool to dump debug info.
      But it still doesn't match our utilization scenario closely.
      1) user need write a user space parser to process the syslog output;
      2) Our testing scenario is we leave the mobile for at least hours.
         Then, check its status. No serial console available during the
         testing. One is because console would be suspended, and the other
         is serial console connecting with spi or HSU devices would consume
         power. These devices are powered off at suspend-2-ram.
      Signed-off-by: NShuoX Liu <shuox.liu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      2a77c46d
  14. 05 10月, 2011 1 次提交
    • R
      PM / QoS: Add function dev_pm_qos_read_value() (v3) · 1a9a9152
      Rafael J. Wysocki 提交于
      To read the current PM QoS value for a given device we need to
      make sure that the device's power.constraints object won't be
      removed while we're doing that.  For this reason, put the
      operation under dev->power.lock and acquire the lock
      around the initialization and removal of power.constraints.
      
      Moreover, since we're using the value of power.constraints to
      determine whether or not the object is present, the
      power.constraints_state field isn't necessary any more and may be
      removed.  However, dev_pm_qos_add_request() needs to check if the
      device is being removed from the system before allocating a new
      PM QoS constraints object for it, so make it use the
      power.power_state field of struct device for this purpose.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      1a9a9152
  15. 25 8月, 2011 1 次提交
    • J
      PM QoS: Implement per-device PM QoS constraints · 91ff4cb8
      Jean Pihet 提交于
      Implement the per-device PM QoS constraints by creating a device
      PM QoS API, which calls the PM QoS constraints management core code.
      
      The per-device latency constraints data strctures are stored
      in the device dev_pm_info struct.
      
      The device PM code calls the init and destroy of the per-device constraints
      data struct in order to support the dynamic insertion and removal of the
      devices in the system.
      
      To minimize the data usage by the per-device constraints, the data struct
      is only allocated at the first call to dev_pm_qos_add_request.
      The data is later free'd when the device is removed from the system.
      A global mutex protects the constraints users from the data being
      allocated and free'd.
      Signed-off-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      91ff4cb8
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 24 12月, 2010 9 次提交
  25. 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