linux-stable.git/drivers/base/power, branch linux-2.6.36.y

PM: Prevent waiting forever on asynchronous resume after failing suspend

2010-09-08T22:49:43+00:00

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: Colin Cross 
Signed-off-by: Rafael J. Wysocki

PM / Runtime: Add runtime PM statistics (v3)

2010-07-19T00:01:06+00:00

In order for PowerTOP to be able to report how well the new runtime PM is
working for the various drivers, the kernel needs to export some basic
statistics in sysfs.

This patch adds two sysfs files in the runtime PM domain that expose the
total time a device has been active, and the time a device has been
suspended.

With this PowerTOP can compute the activity percentage

Active %age = 100 * (delta active) / (delta active + delta suspended)

and present the information to the user.

I've written the PowerTOP code (slated for version 1.12) already, and the
output looks like this:

Runtime Device Power Management statistics
Active  Device name
 10.0%	06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller

[version 2: fix stat update bugs noticed by Alan Stern]
[version 3: rebase to -next and move the sysfs declaration]

Signed-off-by: Arjan van de Ven 
Signed-off-by: Rafael J. Wysocki

PM / Runtime: Make runtime_status attribute not debug-only (v. 2)

2010-07-19T00:00:36+00:00

This patch (as1404b) makes the runtime_status sysfs attribute available
even in the absence of CONFIG_PM_ADVANCED_DEBUG, and it changes the
routine to display "unsupported" when runtime PM is disabled for a
device.  Although not strictly 100% accurate, this will almost always
be correct.

Signed-off-by: Alan Stern 
Acked-by: Dominik Brodowski 
Signed-off-by: Rafael J. Wysocki

PM: Do not use dynamically allocated objects in pm_wakeup_event()

2010-07-19T00:00:35+00:00

Originally, pm_wakeup_event() uses struct delayed_work objects,
allocated with GFP_ATOMIC, to schedule the execution of pm_relax()
in future.  However, as noted by Alan Stern, it is not necessary to
do that, because all pm_wakeup_event() calls can use one static timer
that will always be set to expire at the latest time passed to
pm_wakeup_event().

The modifications are based on the example code posted by Alan.

Signed-off-by: Rafael J. Wysocki

PM: Make it possible to avoid races between wakeup and system sleep

2010-07-18T23:58:48+00:00

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: Rafael J. Wysocki 
Acked-by: Jesse Barnes 
Acked-by: Greg Kroah-Hartman 
Acked-by: markgross 
Reviewed-by: Alan Stern

PM / Runtime: Add sysfs debug files

2010-05-10T21:08:17+00:00

Add a few sysfs files relating to runtime power management for
advanced debug purposes:

runtime_enabled: is runtime PM enabled for this device? States
	are "enabled", "disabled", "forbidden" or a combination
	of the latter two.

runtime_status:	what state is the device in currently? E.g., it
	reports "suspended" for runtime-suspended devices, and
        "active" for active devices. NOTE: if runtime_enabled
	returns "disabled", the value of this file may not
	reflect its physical state.

runtime_usage: the runtime PM usage count of a device

runtime_active_kids: the runtime PM children usage count of a device, or
	0 if the ignore_children flag is set.

Also, CONFIG_PM_SLEEP_ADVANCED_DEBUG is not defined in any Kconfig
file, so replace it with CONFIG_PM_ADVANCED_DEBUG.

Signed-off-by: Dominik Brodowski 
Acked-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki

PM: Allow runtime_suspend methods to call pm_schedule_suspend()

2010-05-10T21:08:16+00:00

This patch (as1361) changes the runtime PM interface slightly; it
allows suspend requests to be scheduled while the runtime_suspend
method is running.  If the method succeeds then the scheduled request
is cancelled, whereas if the method fails then an idle notification is
sent only if no request was scheduled.

Being able to schedule suspend requests from within a runtime_suspend
method is useful for drivers that need to test for idleness and
suspend the device all while holding a single spinlock, or for drivers
that want to check for idleness by polling.

Signed-off-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki

power: support _noirq actions on device types and classes

2010-03-24T10:00:02+00:00

The new-style dev_pm_ops provide callbacks for both IRQs enabled
and disabled. However, the _noirq variants were only called for
buses registered with a device, not for classes and types.

In order to properly use dev_pm_ops in class pcmcia_socket_class,
support _noirq actions also on classes and types.

Signed-off-by: Dominik Brodowski 
Acked-by: Rafael J. Wysocki

Driver core: create lock/unlock functions for struct device

2010-03-08T01:04:52+00:00

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 
Cc: Jean Delvare 
Cc: Dave Young 
Cc: Ming Lei 
Cc: Jiri Kosina 
Cc: Phil Carmody 
Cc: Arjan van de Ven 
Cc: Cornelia Huck 
Cc: Rafael J. Wysocki 
Cc: Pavel Machek 
Cc: Len Brown 
Cc: Magnus Damm 
Cc: Alan Stern 
Cc: Randy Dunlap 
Cc: Stefan Richter 
Cc: David Brownell 
Cc: Vegard Nossum 
Cc: Jesse Barnes 
Cc: Alex Chiang 
Cc: Kenji Kaneshige 
Cc: Andrew Morton 
Cc: Andrew Patterson 
Cc: Yu Zhao 
Cc: Dominik Brodowski 
Cc: Samuel Ortiz 
Cc: Wolfram Sang 
Cc: CHENG Renquan 
Cc: Oliver Neukum 
Cc: Frans Pop 
Cc: David Vrabel 
Cc: Kay Sievers 
Cc: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

PM: Provide generic subsystem-level callbacks

2010-03-06T20:28:37+00:00

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: Rafael J. Wysocki