summaryrefslogtreecommitdiffstats
path: root/drivers/target
diff options
context:
space:
mode:
authorUlf Hansson <ulf.hansson@linaro.org>2015-10-13 16:10:28 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2015-10-14 02:34:43 +0200
commita98f1b78ecf325bf29c9d3d1eb38cbc9340000af (patch)
tree796360c6c35034ed8dc59558954ef8ef05dae25c /drivers/target
parent25cb62b76430a91cc6195f902e61c2cb84ade622 (diff)
downloadlinux-a98f1b78ecf325bf29c9d3d1eb38cbc9340000af.tar.bz2
PM / Domains: Fix validation of latency constraints in genpd governor
Commit ba2bbfbf6307 (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: ba2bbfbf6307 (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>
Diffstat (limited to 'drivers/target')
0 files changed, 0 insertions, 0 deletions