kernel/linux.git/drivers/base/power/main.c, branch linux-2.6.34.y

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: Allow device drivers to use dpm_wait()

2010-02-26T19:39:11+00:00

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

PM: Start asynchronous resume threads upfront

2010-02-26T19:39:11+00:00

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

PM: Add a switch for disabling/enabling asynchronous suspend/resume

2010-02-26T19:39:10+00:00

Add sysfs attribute /sys/power/pm_async allowing the user space to disable/enable asynchronous suspend/resume of devices. Signed-off-by: Rafael J. Wysocki

PM: Asynchronous suspend and resume of devices

2010-02-26T19:39:09+00:00

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

PM: Add parent information to timing messages

2010-02-26T19:39:09+00:00

Add parent information to the messages printed by the suspend/resume core when initcall_debug is set. Signed-off-by: Rafael J. Wysocki

power: fix kernel-doc notation

2010-01-11T17:34:06+00:00

Warning(drivers/base/power/main.c:453): No description found for parameter 'dev' Warning(drivers/base/power/main.c:453): No description found for parameter 'cb' Warning(drivers/base/power/main.c:719): No description found for parameter 'dev' Warning(drivers/base/power/main.c:719): No description found for parameter 'state' Warning(drivers/base/power/main.c:719): No description found for parameter 'cb' Signed-off-by: Randy Dunlap Cc: Rafael J. Wysocki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PM: Use pm_runtime_put_sync in system resume

2009-12-21T01:46:11+00:00

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

PM: Measure device suspend and resume times

2009-12-18T00:57:47+00:00

Measure and print the time of suspending and resuming all devices. Signed-off-by: Rafael J. Wysocki