From: Dmitry Osipenko <digetx@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
linux-pm@vger.kernel.org
Cc: Kevin Hilman <khilman@kernel.org>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Rajendra Nayak <rnayak@codeaurora.org>,
Dong Aisheng <aisheng.dong@nxp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM: domains: Prevent power off for parent unless child is in deepest state
Date: Mon, 31 Jan 2022 21:29:06 +0300 [thread overview]
Message-ID: <b33ceac4-506a-65c8-7c80-b1b0a67ce65e@gmail.com> (raw)
In-Reply-To: <20220131113743.52265-1-ulf.hansson@linaro.org>
31.01.2022 14:37, Ulf Hansson пишет:
> A PM domain managed by genpd may support multiple idlestates. During
> genpd_power_off() a genpd governor may be asked to select one of the
> idlestates based upon the dev PM QoS constraints, for example.
>
> However, there is a problem with the behaviour around this in genpd. More
> precisely, a parent-domain is allowed to be powered off, no matter of what
> idlestate that has been selected for the child-domain.
>
> So far, we have not received any reports about errors, possibly because
> there might not be platform with this hierarchical configuration, yet.
> Nevertheless, it seems reasonable to change the behaviour into preventing
> the parent-domain from being powered off, unless the deepest idlestate has
> been selected for the child-domain, so let's do that.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 5db704f02e71..7f97c5cabdc2 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -636,6 +636,17 @@ static int genpd_power_off(struct generic_pm_domain *genpd, bool one_dev_on,
> atomic_read(&genpd->sd_count) > 0)
> return -EBUSY;
>
> + /*
> + * The children must be in their deepest states to allow the parent to
> + * be powered off. Note that, there's no need for additional locking, as
> + * powering on a child, requires the parent's lock to be acquired first.
> + */
> + list_for_each_entry(link, &genpd->parent_links, parent_node) {
> + struct generic_pm_domain *child = link->child;
> + if (child->state_idx < child->state_count - 1)
> + return -EBUSY;
> + }
> +
> list_for_each_entry(pdd, &genpd->dev_list, list_node) {
> enum pm_qos_flags_status stat;
>
> @@ -1073,6 +1084,13 @@ static void genpd_sync_power_off(struct generic_pm_domain *genpd, bool use_lock,
> || atomic_read(&genpd->sd_count) > 0)
> return;
>
> + /* Check that the children are in their deepest state. */
> + list_for_each_entry(link, &genpd->parent_links, parent_node) {
> + struct generic_pm_domain *child = link->child;
> + if (child->state_idx < child->state_count - 1)
> + return;
> + }
> +
> /* Choose the deepest state when suspending */
> genpd->state_idx = genpd->state_count - 1;
> if (_genpd_power_off(genpd, false))
Hello Ulf,
Is this needed by a concrete SoC? It needs to be clarified in the commit
message, otherwise looks like this patch wasn't tested and it's unclear
whether this change is really needed.
next prev parent reply other threads:[~2022-01-31 18:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 11:37 [PATCH] PM: domains: Prevent power off for parent unless child is in deepest state Ulf Hansson
2022-01-31 18:29 ` Dmitry Osipenko [this message]
2022-02-04 9:43 ` Ulf Hansson
2022-02-04 19:10 ` Dmitry Osipenko
2022-02-07 8:43 ` Ulf Hansson
2022-02-13 12:14 ` Dmitry Osipenko
2022-02-14 9:22 ` Ulf Hansson
2022-02-15 21:49 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b33ceac4-506a-65c8-7c80-b1b0a67ce65e@gmail.com \
--to=digetx@gmail.com \
--cc=aisheng.dong@nxp.com \
--cc=alexandre.torgue@foss.st.com \
--cc=geert+renesas@glider.be \
--cc=khilman@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rnayak@codeaurora.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).