]> git.baikalelectronics.ru Git - kernel.git/commit
PM / Domains: Fix validation of latency constraints in genpd governor
authorUlf Hansson <ulf.hansson@linaro.org>
Tue, 13 Oct 2015 14:10:28 +0000 (16:10 +0200)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Wed, 14 Oct 2015 00:34:43 +0000 (02:34 +0200)
commit1740b9416dfc6d9b90dc55db9217230e8cecea90
tree796360c6c35034ed8dc59558954ef8ef05dae25c
parent186f6599ed5cde61c9827a5391f6e95cc77b81bf
PM / Domains: Fix validation of latency constraints in genpd governor

Commit 108c9d422a2a (PM / Domains: Remove intermediate states from the
power off sequence) changed the power off sequence in genpd. That also
required some updates regarding the validation of latency constraints in
the genpd governor. Unfortunate that wasn't covered, so let's fix this.

From a runtime PM and latency point of view, we need to consider the worst
case scenario while validating latency constraints. That's typically when
a call to pm_runtime_get_sync() needs to wait for a ongoing runtime
suspend operation to be carried out, as it then also needs to wait for the
device to be runtime resumed again.

The above mentioned commit made the genpd governor's ->stop_ok() callback
responsible of validating genpd's device's runtime suspend/resume latency.
In other words, the constraint needs to be validated towards the relevant
latencies present in genpd's ->runtime_suspend|resume() callbacks.

Earlier, that included latencies from the ->stop|start() callbacks, but as
->save|restore_state() are now also being invoked from genpd's
->runtime_suspend|resume() and to comply with the worst case scenario,
let's take also those latencies into account.

Fixes: 108c9d422a2a (PM / Domains: Remove intermediate states from the power off sequence)
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/base/power/domain_governor.c