Skip to content

L
linux
Switch branch/tag
  1. 06 Jul, 2011 2 commits
    • 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
    • Rafael J. Wysocki's avatar
      PCI / PM: Detect early wakeup in pci_pm_prepare() · eea3fc03
      Rafael J. Wysocki authored 
      A subsequent patch is going to move the invocation of
pm_runtime_barrier() from dpm_prepare() to __device_suspend().
Consequently, early wakeup events resulting from runtime resume
requests for wakeup devices queued up right before system suspend
will only be detected after all of the subsystem-level .prepare()
callbacks have run.  However, the PCI bus type calls
pm_runtime_get_sync() from its pci_pm_prepare() callback routine,
so it would destroy the early wakeup events information regarding PCI
devices.  To prevent this from happening add an early wakeup
detection mechanism, analogous to the one currently in dpm_prepare(),
to pci_pm_prepare().
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      eea3fc03
  3. 02 Jul, 2011 18 commits
    • Rafael J. Wysocki's avatar
      PM / Runtime: Return special error code if runtime PM is disabled · 632e270e
      Rafael J. Wysocki authored 
      Some callers of pm_runtime_get_sync() and other runtime PM helper
functions, scsi_autopm_get_host() and scsi_autopm_get_device() in
particular, need to distinguish error codes returned when runtime PM
is disabled (i.e. power.disable_depth is nonzero for the given
device) from error codes returned in other situations.  For this
reason, make the runtime PM helper functions return -EACCES when
power.disable_depth is nonzero and ensure that this error code
won't be returned by them in any other circumstances.  Modify
scsi_autopm_get_host() and scsi_autopm_get_device() to check the
error code returned by pm_runtime_get_sync() and ignore -EACCES.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      632e270e
    • Rafael J. Wysocki's avatar
      PM / Runtime: Update documentation of interactions with system sleep · 455716e9
      Rafael J. Wysocki authored 
      The documents describing the interactions between runtime PM and
system sleep generally refer to the model in which the system sleep
state is entered through a global firmware or hardware operation.
As a result, some recommendations given in there are not entirely
suitable for systems in which this is not the case.  Update the
documentation to take the existence of those systems into account.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      455716e9
    • Magnus Damm's avatar
      ARM: mach-shmobile: sh7372 A3SG support · c47586b6
      Magnus Damm authored 
      Add support for the sh7372 A3SG power domain. This domain contains
the SGX hardware block, but there is no open source driver available.
Signed-off-by: default avatarMagnus Damm <damm@opensource.se>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      c47586b6
    • Magnus Damm's avatar
      ARM: mach-shmobile: sh7372 A3RI support · 082517aa
      Magnus Damm authored 
      Add support for the sh7372 A3RI power domain. This domain contains
the ISP hardware block, but there is no driver available.
Signed-off-by: default avatarMagnus Damm <damm@opensource.se>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      082517aa
    • Magnus Damm's avatar
      ARM: mach-shmobile: sh7372 A3RV support · 33afebf3
      Magnus Damm authored 
      Add support for the sh7372 A3RV power domain and hook
up the VPU device.
Signed-off-by: default avatarMagnus Damm <damm@opensource.se>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      33afebf3
    • Magnus Damm's avatar
      ARM: mach-shmobile: sh7372 A4LC support for AP4EVB · 96f7934e
      Magnus Damm authored 
      The AP4EVB board is also using a sh7372 SoC, so tie in
A4LC support on that board as well.
Signed-off-by: default avatarMagnus Damm <damm@opensource.se>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      96f7934e
    • Rafael J. Wysocki's avatar
      ARM / shmobile: Support for I/O power domains for SH7372 (v9) · e3e01091
      Rafael J. Wysocki authored 
      Use the generic power domains support introduced by the previous
patch to implement support for power domains on SH7372.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      e3e01091
    • Rafael J. Wysocki's avatar
      PM: Rename clock management functions · 3d5c3036
      Rafael J. Wysocki authored 
      The common PM clock management functions may be used for system
suspend/resume as well as for runtime PM, so rename them
accordingly.  Modify kerneldoc comments describing these functions
and kernel messages printed by them, so that they refer to power
management in general rather that to runtime PM.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      3d5c3036
    • Rafael J. Wysocki's avatar
      PM: Allow the clocks management code to be used during system suspend · b7b95920
      Rafael J. Wysocki authored 
      The common clocks management code in drivers/base/power/clock_ops.c
is going to be used during system-wide power transitions as well as
for runtime PM, so it shouldn't depend on CONFIG_PM_RUNTIME.
However, the suspend/resume functions provided by it for
CONFIG_PM_RUNTIME unset, to be used during system-wide power
transitions, should not behave in the same way as their counterparts
defined for CONFIG_PM_RUNTIME set, because in that case the clocks
are managed differently at run time.

The names of the functions still contain the word "runtime" after
this change, but that is going to be modified by a separate patch
later.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      b7b95920
    • Rafael J. Wysocki's avatar
      PM / Domains: Wakeup devices support for system sleep transitions · d4f2d87a
      Rafael J. Wysocki authored 
      There is the problem how to handle devices set up to wake up the
system from sleep states during system-wide power transitions.
In some cases, those devices can be turned off entirely, because the
wakeup signals will be generated on their behalf anyway.  In some
other cases, they will generate wakeup signals if their clocks are
stopped, but only if power is not removed from them.  Finally, in
some cases, they can only generate wakeup signals if power is not
removed from them and their clocks are enabled.

To allow platform-specific code to decide whether or not to put
wakeup devices (and their PM domains) into low-power state during
system-wide transitions, such as system suspend, introduce a new
generic PM domain callback, .active_wakeup(), that will be used
during the "noirq" phase of system suspend and hibernation (after
image creation) to decide what to do with wakeup devices.
Specifically, if this callback is present and returns "true", the
generic PM domain code will not execute .stop_device() for the
given wakeup device and its PM domain won't be powered off.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarKevin Hilman <khilman@ti.com>
      d4f2d87a
    • Rafael J. Wysocki's avatar
      PM / Domains: System-wide transitions support for generic domains (v5) · 596ba34b
      Rafael J. Wysocki authored 
      Make generic PM domains support system-wide power transitions
(system suspend and hibernation).  Add suspend, resume, freeze, thaw,
poweroff and restore callbacks to be associated with struct
generic_pm_domain objects and make pm_genpd_init() use them as
appropriate.

The new callbacks do nothing for devices belonging to power domains
that were powered down at run time (before the transition).  For the
other devices the action carried out depends on the type of the
transition.  During system suspend the power domain .suspend()
callback executes pm_generic_suspend() for the device, while the
PM domain .suspend_noirq() callback runs pm_generic_suspend_noirq()
for it, stops it and eventually removes power from the PM domain it
belongs to (after all devices in the domain have been stopped and its
subdomains have been powered off).

During system resume the PM domain .resume_noirq() callback
restores power to the PM domain (when executed for it first time),
starts the device and executes pm_generic_resume_noirq() for it,
while the .resume() callback executes pm_generic_resume() for the
device.  Finally, the .complete() callback executes pm_runtime_idle()
for the device which should put it back into the suspended state if
its runtime PM usage count is equal to zero at that time.

The actions carried out during hibernation and resume from it are
analogous to the ones described above.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      596ba34b
    • Rafael J. Wysocki's avatar
      PM / Domains: Move code from under #ifdef CONFIG_PM_RUNTIME (v2) · 5248051b
      Rafael J. Wysocki authored 
      There is some code in drivers/base/power/domain.c that will be useful
for both runtime PM and system-wide power transitions, so make it
depend on CONFIG_PM instead of CONFIG_PM_RUNTIME.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      5248051b
    • Rafael J. Wysocki's avatar
      PM: Introduce generic "noirq" callback routines for subsystems (v2) · e5291928
      Rafael J. Wysocki authored 
      Introduce generic "noirq" power management callback routines for
subsystems in addition to the "regular" generic PM callback routines.

The new routines will be used, among other things, for implementing
system-wide PM transitions support for generic PM domains.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      e5291928
    • Rafael J. Wysocki's avatar
      PM / Domains: Support for generic I/O PM domains (v8) · f721889f
      Rafael J. Wysocki authored 
      Introduce common headers, helper functions and callbacks allowing
platforms to use simple generic power domains for runtime power
management.

Introduce struct generic_pm_domain to be used for representing
power domains that each contain a number of devices and may be
parent domains or subdomains with respect to other power domains.
Among other things, this structure includes callbacks to be
provided by platforms for performing specific tasks related to
power management (i.e. ->stop_device() may disable a device's
clocks, while ->start_device() may enable them, ->power_off() is
supposed to remove power from the entire power domain
and ->power_on() is supposed to restore it).

Introduce functions that can be used as power domain runtime PM
callbacks, pm_genpd_runtime_suspend() and pm_genpd_runtime_resume(),
as well as helper functions for the initialization of a power
domain represented by a struct generic_power_domain object,
adding a device to or removing a device from it and adding or
removing subdomains.

Introduce configuration option CONFIG_PM_GENERIC_DOMAINS to be
selected by the platforms that want to use the new code.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      f721889f
    • Rafael J. Wysocki's avatar
      PM: subsys_data in struct dev_pm_info need not depend on RM_RUNTIME · dc6e4e56
      Rafael J. Wysocki authored 
      The subsys_data field of struct dev_pm_info, introduced by commit
1d2b71f6 (PM / Runtime: Add subsystem
data field to struct dev_pm_info), is going to be used even if
CONFIG_PM_RUNTIME is not set, so move it from under the #ifdef.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      dc6e4e56
    • Rafael J. Wysocki's avatar
      PM / Domains: Rename struct dev_power_domain to struct dev_pm_domain · 564b905a
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarKevin Hilman <khilman@ti.com>
      564b905a
    • Rafael J. Wysocki's avatar
      PM / Runtime: Update documentation regarding driver removal · f5da24db
      Rafael J. Wysocki authored 
      Commit e1866b33 (PM / Runtime: Rework
runtime PM handling during driver removal) forgot to update the
documentation in Documentation/power/runtime_pm.txt to match the new
code in drivers/base/dd.c.  Update that documentation to match the
code it describes.
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      f5da24db
    • Kevin Hilman's avatar
      PM: Documentation: fix typo: pm_runtime_idle_sync() doesn't exist. · 5efb54cc
      Kevin Hilman authored 
      Replace reference to pm_runtime_idle_sync() in the driver core with
pm_runtime_put_sync() which is used in the code.
Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      5efb54cc
  5. 01 Jul, 2011 4 commits
  7. 30 Jun, 2011 16 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7