linux/drivers/base/power, branch v3.4.2

PM / Runtime: don't forget to wake up waitqueue on failure

2012-03-26T20:46:52Z

This patch (as1535) fixes a bug in the runtime PM core. When a runtime suspend attempt completes, whether successfully or not, the device's power.wait_queue is supposed to be signalled. But this doesn't happen in the failure pathway of rpm_suspend() when another autosuspend attempt is rescheduled. As a result, a task can get stuck indefinitely on the wait queue (I have seen this happen in testing). The patch fixes the problem by moving the wake_up_all() call up near the start of the failure code. Signed-off-by: Alan Stern CC: Signed-off-by: Rafael J. Wysocki

Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

2012-03-24T17:41:37Z

Pull avoidance patches from Paul Gortmaker: "Nearly every subsystem has some kind of header with a proto like: void foo(struct device *dev); and yet there is no reason for most of these guys to care about the sub fields within the device struct. This allows us to significantly reduce the scope of headers including headers. For this instance, a reduction of about 40% is achieved by replacing the include with the simple fact that the device is some kind of a struct. Unlike the much larger module.h cleanup, this one is simply two commits. One to fix the implicit users, and then one to delete the device.h includes from the linux/include/ dir wherever possible." * tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: device.h: audit and cleanup users in main include dir device.h: cleanup users outside of linux/include (C files)

Merge branch 'pm-domains'

2012-03-19T09:39:04Z

* pm-domains: PM / Domains: Check domain status during hibernation restore of devices

PM / Domains: Check domain status during hibernation restore of devices

2012-03-19T09:38:14Z

Power domains that were off before hibernation shouldn't be turned on during device restore, so prevent that from happening. This change fixes up commit 65533bbf63b4f37723fdfedc73d0653958973323 PM / Domains: Fix hibernation restore of devices, v2 that didn't include it by mistake. Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-domains'

2012-03-16T20:50:08Z

* pm-domains: PM / shmobile: Make MTU2 driver use pm_genpd_dev_always_on() PM / shmobile: Make CMT driver use pm_genpd_dev_always_on() PM / shmobile: Make TMU driver use pm_genpd_dev_always_on() PM / Domains: Introduce "always on" device flag PM / Domains: Fix hibernation restore of devices, v2 PM / Domains: Fix handling of wakeup devices during system resume

Merge branch 'pm-qos'

2012-03-16T20:49:24Z

* pm-qos: sh_mmcif / PM: Use PM QoS latency constraint tmio_mmc / PM: Use PM QoS latency constraint PM / QoS: Make it possible to expose PM QoS latency constraints

PM / Domains: Introduce "always on" device flag

2012-03-16T20:44:59Z

The TMU device on the Mackerel board belongs to the A4R power domain and loses power when the domain is turned off. Unfortunately, the TMU driver is not prepared to cope with such situations and crashes the system when that happens. To work around this problem introduce a new helper function, pm_genpd_dev_always_on(), allowing a device driver to mark its device as "always on" in case it belongs to a PM domain, which will make the generic PM domains core code avoid powering off the domain containing the device, both at run time and during system suspend. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Acked-by: Paul Mundt Cc: stable@vger.kernel.org

PM / Domains: Fix hibernation restore of devices, v2

2012-03-16T20:44:48Z

During resume from hibernation pm_genpd_restore_noirq() should only power off domains whose suspend_power_off flags are set once and not every time it is called for a device in the given domain. Moreover, it shouldn't decrement genpd->suspended_count, because that field is not touched during device freezing and therefore it is always equal to 0 when pm_genpd_restore_noirq() runs for the first device in the given domain. This means pm_genpd_restore_noirq() may use genpd->suspended_count to determine whether or not it it has been called for the domain in question already in this cycle (it only needs to increment that field every time it runs for this purpose) and whether or not it should check if the domain needs to be powered off. For that to work, though, pm_genpd_prepare() has to clear genpd->suspended_count when it runs for the first device in the given domain (in which case that flag need not be cleared during domain initialization). Signed-off-by: Rafael J. Wysocki Cc: stable@vger.kernel.org

PM / Domains: Fix handling of wakeup devices during system resume

2012-03-16T20:44:41Z

During system suspend pm_genpd_suspend_noirq() checks if the given device is in a wakeup path (i.e. it appears to be needed for one or more wakeup devices to work or is a wakeup device itself) and if it needs to be "active" for wakeup to work. If that is the case, the function returns 0 without incrementing the device domain's counter of suspended devices and without executing genpd_stop_dev() for the device. In consequence, the device is not stopped (e.g. its clock isn't disabled) and power is always supplied to its domain in the resulting system sleep state. However, pm_genpd_resume_noirq() doesn't repeat that check and it runs genpd_start_dev() and decrements the domain's counter of suspended devices even for the wakeup device that weren't stopped by pm_genpd_suspend_noirq(). As a result, the start callback may be run unnecessarily for them and their domains' counters of suspended devices may become negative. Both outcomes aren't desirable, so fix pm_genpd_resume_noirq() to look for wakeup devices that might not be stopped by during system suspend. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Cc: stable@vger.kernel.org

PM / QoS: Make it possible to expose PM QoS latency constraints

2012-03-13T21:37:14Z

A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_resume_latency_us, allowing user space to specify the upper bound of the time necessary to bring the (runtime-suspended) device up after the resume of it has been requested. However, make that attribute appear only for the devices whose drivers declare support for it by calling the (new) dev_pm_qos_expose_latency_limit() helper function with the appropriate initial value of the attribute. Signed-off-by: Rafael J. Wysocki Reviewed-by: Kevin Hilman Reviewed-by: Mark Brown Acked-by: Linus Walleij