summaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorUlf Hansson <ulf.hansson@linaro.org>2020-09-24 13:04:48 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2020-10-02 19:15:16 +0200
commitf63816e43d90442684cd2fd74f602cf3c5fae69c (patch)
tree2a3450e9b51602930b988d82ed2a5a1cfd30dcec /drivers
parent49f618e1b669ef0e26a8d8d7f8fafc7b8fd31531 (diff)
downloadlinux-f63816e43d90442684cd2fd74f602cf3c5fae69c.tar.bz2
PM: domains: Allow to abort power off when no ->power_off() callback
In genpd_power_off() we may decide to abort the power off of the PM domain, even beyond the point when the governor would accept it. The abort is done if it turns out that a child domain has been requested to be powered on, which means it's waiting for the lock of the parent to be released. However, the abort is currently only considered if the genpd in question has a ->power_off() callback assigned. This is unnecessary limiting, especially if the genpd would have a parent of its own. Let's remove the limitation and make the behaviour consistent. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers')
-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 23aa2feced77..0198af358503 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;
+ /* Don't power off, if a child domain is waiting to 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 parent 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 = GENPD_STATE_OFF;
genpd_update_accounting(genpd);