kernel/linux.git/drivers/base/power/runtime.c, branch linux-2.6.35.y

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

PM / Runtime: Add sysfs switch for disabling device run-time PM

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

Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of the devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern

PM / Runtime: Use device type and device class callbacks

2009-12-22T19:43:17+00:00

The power management of some devices is handled through device types and device classes rather than through bus types. Since these devices may also benefit from using the run-time power management core, extend it so that the device type and device class run-time PM callbacks can be taken into consideration by it if the bus type callback is not defined. Update the run-time PM core documentation to reflect this change. Signed-off-by: Rafael J. Wysocki

PM: allow for usage_count > 0 in pm_runtime_get()

2009-12-15T19:42:06+00:00

This patch (as1308c) fixes __pm_runtime_get(). Currently the routine will resume a device if the prior usage count was 0. But this isn't right; thanks to pm_runtime_get_noresume() the usage count can be positive even while the device is suspended. Signed-off-by: Alan Stern Signed-off-by: Rafael J. Wysocki

PM / Runtime: Remove unnecessary braces in __pm_runtime_set_status()

2009-12-06T15:17:57+00:00

Some braces in __pm_runtime_set_status() are not necessary, so remove them. Signed-off-by: Rafael J. Wysocki

PM / Runtime: Ensure timer_expires is nonzero in pm_schedule_suspend()

2009-12-06T15:17:56+00:00

The runtime PM core code assumes that dev->power.timer_expires is nonzero when the timer is scheduled, but it may become zero incidentally in pm_schedule_suspend(). Prevent this from happening by bumping dev->power.timer_expires up to 1 if it's 0 before calling mod_timer(). Signed-off-by: Rafael J. Wysocki Reported-by: Alan Stern

PM / Runtime: Use deferred_resume flag in pm_request_resume

2009-12-06T15:17:56+00:00

This patch (as1307) adds a small optimization to __pm_request_resume(). If the device is currently being suspended, there's no need to queue a work routine to resume it. Setting the deferred_resume flag will suffice. (There's also a minor improvement to the function's code layout: An unnecessary "else" is removed.) Also, the patch clarifies the usage of the deferred_resume flag. It is meaningful only while a suspend is in progress, so it should be cleared just before a suspend starts, not just after one ends. Signed-off-by: Alan Stern Signed-off-by: Rafael J. Wysocki

PM / Runtime: Fix lockdep warning in __pm_runtime_set_status()

2009-12-06T15:17:56+00:00

Lockdep complains about taking the parent lock in __pm_runtime_set_status(), so mark it as nested. Signed-off-by: Rafael J. Wysocki Reported-by: Alan Stern Cc: stable@kernel.org

PM: fix irq enable/disable in runtime PM code

2009-11-29T15:51:27+00:00

This patch (as1305) fixes a bug in the irq-enable settings and removes some related overhead in the runtime PM code. In __pm_runtime_resume(), within the scope of the original spin_lock_irq(), we know that irqs are disabled. There's no reason to go through a pair of enable/disable cycles when acquiring and releasing the parent's lock. In __pm_runtime_set_status(), irqs are already disabled when the parent's lock is acquired, and they must remain disabled when it is released. Signed-off-by: Alan Stern Signed-off-by: Rafael J. Wysocki

PM: Remove some debug messages producing too much noise

2009-11-03T10:18:18+00:00

pm_runtime_idle() is somewhat noisy. Remove debug prints. Signed-off-by: Pavel Machek Signed-off-by: Rafael J. Wysocki