linux/drivers/base/power/runtime.c, branch v4.9

PM / runtime: Use _rcuidle for runtime suspend tracepoints

2016-09-16T00:59:58Z

Further testing with false negatives suppressed by commit 293e2421fe25 ("rcu: Remove superfluous versions of rcu_read_lock_sched_held()") identified a few more unprotected uses of RCU from the idle loop. Because RCU actively ignores idle-loop code (for energy-efficiency reasons, among other things), using RCU from the idle loop can result in too-short grace periods, in turn resulting in arbitrary misbehavior. The affected function is rpm_suspend(). The resulting lockdep-RCU splat is as follows: ------------------------------------------------------------------------ Warning from omap3 =============================== [ INFO: suspicious RCU usage. ] 4.6.0-rc5-next-20160426+ #1112 Not tainted ------------------------------- include/trace/events/rpm.h:63 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! 1 lock held by swapper/0/0: #0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_suspend+0x54/0x84 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1112 Hardware name: Generic OMAP36xx (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xb0/0xe4) [] (dump_stack) from [] (rpm_suspend+0x604/0x7e4) [] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84) [] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70) [] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244) [] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec) [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4) [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0) [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8) [] (start_kernel) from [<8000807c>] (0x8000807c) ------------------------------------------------------------------------ Reported-by: Tony Lindgren Signed-off-by: Paul E. McKenney Tested-by: Tony Lindgren Tested-by: Guenter Roeck [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki

PM / runtime: Add _rcuidle suffix to allow rpm_idle() use from idle

2016-08-31T01:00:59Z

This commit appends a few _rcuidle suffixes to fix the following RCU-used-from-idle bug: > =============================== > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1116 Not tainted > ------------------------------- > include/trace/events/rpm.h:95 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > > RCU used illegally from idle CPU! > rcu_scheduler_active = 1, debug_locks = 0 > RCU used illegally from extended quiescent state! > 1 lock held by swapper/0/0: > #0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __rpm_callback+0x58/0x60 > > stack backtrace: > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1116 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0xb0/0xe4) > [] (dump_stack) from [] (rpm_suspend+0x580/0x768) > [] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84) > [] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70) > [] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244) > [] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec) > [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4) > [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0) > [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8) > [] (start_kernel) from [<8000807c>] (0x8000807c) In the immortal words of Steven Rostedt, "*Whack* *Whack* *Whack*!!!" Reported-by: Tony Lindgren Signed-off-by: Paul E. McKenney Tested-by: Tony Lindgren Tested-by: Guenter Roeck WhACKED-by: Steven Rostedt Signed-off-by: Rafael J. Wysocki

PM / runtime: Add _rcuidle suffix to allow rpm_resume() to be called from idle

2016-08-31T00:59:20Z

This commit applies another _rcuidle suffix to fix an RCU use from idle. > =============================== > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1122 Not tainted > ------------------------------- > include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > > RCU used illegally from idle CPU! > rcu_scheduler_active = 1, debug_locks = 0 > RCU used illegally from extended quiescent state! > 1 lock held by swapper/0/0: > #0: (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_resume+0x3c/0x64 > > stack backtrace: > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1122 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0xb0/0xe4) > [] (dump_stack) from [] (rpm_resume+0x5cc/0x7f4) > [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > [] (__pm_runtime_resume) from [] (omap2_gpio_resume_after_idle+0x54/0x68) > [] (omap2_gpio_resume_after_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec) > [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4) > [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0) > [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8) > [] (start_kernel) from [<8000807c>] (0x8000807c) Reported-by: Tony Lindgren Signed-off-by: Paul E. McKenney Tested-by: Tony Lindgren Tested-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-core', 'pm-clk', 'pm-domains' and 'pm-pci'

2016-07-25T11:45:27Z

* pm-core: PM / runtime: Asynchronous "idle" in pm_runtime_allow() PM / runtime: print error when activating a child to unactive parent * pm-clk: PM / clk: Add support for adding a specific clock from device-tree PM / clk: export symbols for existing pm_clk_<...> API fcns * pm-domains: PM / Domains: Convert pm_genpd_init() to return an error code PM / Domains: Stop/start devices during system PM suspend/resume in genpd PM / Domains: Allow runtime PM during system PM phases PM / Runtime: Avoid resuming devices again in pm_runtime_force_resume() PM / Domains: Remove redundant pm_request_idle() call in genpd PM / Domains: Remove redundant wrapper functions for system PM PM / Domains: Allow genpd to power on during system PM phases * pm-pci: PCI / PM: check all fields in pci_set_platform_pm()

PM / runtime: Asynchronous "idle" in pm_runtime_allow()

2016-07-01T23:50:39Z

Arjan reports that it takes a relatively long time to enable runtime PM for multiple devices at system startup, because all writes to the "control" attribute in sysfs are handled synchronously and if the device is suspended as a result of the write, it will block until that operation is complete. That may be avoided by passing the RPM_ASYNC flag to rpm_idle() in pm_runtime_allow() which will make it execute the device's "idle" callback asynchronously, so writes to "control" changing it from "on" to "auto" will return without waiting. Reported-by: Arjan van de Ven Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Reviewed-by: Ulf Hansson Reviewed-by: Kevin Hilman

PM / runtime: print error when activating a child to unactive parent

2016-06-27T22:40:30Z

The code currently silently bails out with -EBUSY if you try to activate a child to an inactive parent. This typically happens when you have a runtime suspended parent and runtime resume your child, but forgot to set .ignore_children on the parent to true with pm_suspend_ignore_children(dev). Silently ignoring this error is not good as it gives rise to other strange behaviour like double-resume of devices after silently bailing out of the .runtime_resume() callback. Signed-off-by: Linus Walleij Signed-off-by: Rafael J. Wysocki

PM / Runtime: Avoid resuming devices again in pm_runtime_force_resume()

2016-06-16T13:14:36Z

If the runtime PM status of the device isn't RPM_SUSPENDED, prevent the pm_runtime_force_resume() from invoking the ->runtime_resume() callback for the device, as it's not the expected behaviour from the subsystem/driver. Signed-off-by: Ulf Hansson Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-04-21T17:31:11Z

As pm_runtime_set_active() may fail because the device's parent isn't active, we can end up executing the ->runtime_resume() callback for the device when it isn't allowed. Fix this by invoking pm_runtime_set_active() before running the callback and let's also deal with the error code. Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions) Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki

PM / runtime: Add new helper for conditional usage count incrementation

2015-12-21T02:11:12Z

Introduce a new runtime PM function, pm_runtime_get_if_in_use(), that will increment the device's runtime PM usage counter and return 1 if its status is RPM_ACTIVE and its usage counter is greater than 0 at the same time (0 will be returned otherwise). This is useful for things that should only be done if the device is active (from the runtime PM perspective) and used by somebody (as indicated by the usage counter) already and they are not worth bothering otherwise. Requested-by: Imre Deak Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / runtime: Re-init runtime PM states at probe error and driver unbind

2015-11-30T13:50:05Z

There are two common expectations among several subsystems/drivers that deploys runtime PM support, but which isn't met by the driver core. Expectation 1) At ->probe() the subsystem/driver expects the runtime PM status of the device to be RPM_SUSPENDED, which is the initial status being assigned at device registration. This expectation is especially common among some of those subsystems/ drivers that manages devices with an attached PM domain, as those requires the ->runtime_resume() callback at the PM domain level to be invoked during ->probe(). Moreover these subsystems/drivers entirely relies on runtime PM resources being managed at the PM domain level, thus don't implement their own set of runtime PM callbacks. These are two scenarios that suffers from this unmet expectation. i) A failed ->probe() sequence requests probe deferral: ->probe() ... pm_runtime_enable() pm_runtime_get_sync() ... err: pm_runtime_put() pm_runtime_disable() ... As there are no guarantees that such sequence turns the runtime PM status of the device into RPM_SUSPENDED, the re-trying ->probe() may start with the status in RPM_ACTIVE. In such case the runtime PM core won't invoke the ->runtime_resume() callback because of a pm_runtime_get_sync(), as it considers the device to be already runtime resumed. ii) A driver re-bind sequence: At driver unbind, the subsystem/driver's >remove() callback invokes a sequence of runtime PM APIs, to undo actions during ->probe() and to put the device into low power state. ->remove() ... pm_runtime_put() pm_runtime_disable() ... Similar as in the failing ->probe() case, this sequence don't guarantee the runtime PM status of the device to turn into RPM_SUSPENDED. Trying to re-bind the driver thus causes the same issue as when re-trying ->probe(), in the probe deferral scenario. Expectation 2) Drivers that invokes the pm_runtime_irq_safe() API during ->probe(), triggers the runtime PM core to increase the usage count for the device's parent and permanently make it runtime resumed. The usage count is only dropped at device removal, which also allows it to be runtime suspended again. A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus once more triggers the usage count of the device's parent to be increased. This leads to not only an imbalance issue of the usage count of the device's parent, but also to keep it runtime resumed permanently even if ->probe() fails. To address these issues, let's change the policy of the driver core to meet these expectations. More precisely, at ->probe() failures and driver unbind, restore the initial states of runtime PM. Although to still allow subsystem's to control PM for devices that doesn't ->probe() successfully, don't restore the initial states unless runtime PM is disabled. Signed-off-by: Ulf Hansson Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki