summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorUlf Hansson <ulf.hansson@linaro.org>2020-06-17 17:16:13 +0200
committerUlf Hansson <ulf.hansson@linaro.org>2020-06-18 13:09:41 +0200
commitba384df2898841b29d92249c4a55f7927a4b9987 (patch)
tree56ef69b23db91c9be6a4cc926b7ed82fe50ce93d
parente9deea03c62c2a353a483bf29aac263a6ae8ece9 (diff)
PM / Domains: Always consider to bail out in genpd_power_off()
In genpd_power_off(), we may decide to bail out, even after the genpd governor is okay with powering off the PM domain. This makes sense, as running the genpd_power_off() path with the lock held, may take some time. During this time, it's perfectly possible that a subdomain is requested to be powered on, hence it wouldn't be efficient to power off the master, to then immediately after, have to power it on again. However, the bail out point is currently considered only if the genpd in question has a valid ->power_off() callback. This is unnecessary limiting, especially if the master has master of its own, for example. Therefore, let's drop this limitation. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-rw-r--r--drivers/base/power/domain.c24
1 files changed, 7 insertions, 17 deletions
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0a01df608849..b1634228def2 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -497,6 +497,7 @@ static int genpd_power_off(struct generic_pm_domain *genpd, bool one_dev_on,
struct pm_domain_data *pdd;
struct gpd_link *link;
unsigned int not_suspended = 0;
+ int ret;
/*
* Do not try to power off the domain in the following situations:
@@ -544,24 +545,13 @@ static int genpd_power_off(struct generic_pm_domain *genpd, bool one_dev_on,
if (!genpd->gov)
genpd->state_idx = 0;
- if (genpd->power_off) {
- int ret;
-
- if (atomic_read(&genpd->sd_count) > 0)
- return -EBUSY;
+ /* Bail out and don't power off, if a subdomain wants power on. */
+ if (atomic_read(&genpd->sd_count) > 0)
+ return -EBUSY;
- /*
- * If sd_count > 0 at this point, one of the subdomains hasn't
- * managed to call genpd_power_on() for the master yet after
- * incrementing it. In that case genpd_power_on() will wait
- * for us to drop the lock, so we can call .power_off() and let
- * the genpd_power_on() restore power for us (this shouldn't
- * happen very often).
- */
- ret = _genpd_power_off(genpd, true);
- if (ret)
- return ret;
- }
+ ret = _genpd_power_off(genpd, true);
+ if (ret)
+ return ret;
genpd->status = GPD_STATE_POWER_OFF;
genpd_update_accounting(genpd);