From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
Linux PM list <linux-pm@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
Tomasz Figa <tomasz.figa@gmail.com>,
Philipp Zabel <philipp.zabel@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Mark Brown <broonie@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jack Dai <jack.dai@rock-chips.com>,
Jinkun Hong <jinkun.hong@rock-chips.com>
Subject: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)
Date: Tue, 7 Oct 2014 21:09:27 +0200 [thread overview]
Message-ID: <CAMuHMdUwbOEfLcu_UVKq_iHx5Qzn7ne1+cwt58C0ntTZBf1esg@mail.gmail.com> (raw)
Hi Ulf,
On Tue, Sep 30, 2014 at 2:43 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Instead, let's improve the situation, by preventing genpd from powering
> off any of the PM domains until late_init. At that point genpd already
> tries to power off unused PM domains, so it seems like a decent match.
Note that powering off unused PM domains is currently limited to
CONFIG_PM_RUNTIME=y.
If CONFIG_PM_RUNTIME is disabled, unused PM domains are not powered down,
and may even stay powered-up during system suspend.
With CONFIG_PM_RUNTIME=y, we have:
A1. All PM domains are powered up during initialization.
A2. After initialization, all unused PM domains are powered down by the
genpd_poweroff_unused() late_initcall.
"unused" means PM domains containing no active devices and no active
subdomains. I.e. PM domains containing (a) only suspended devices, or
(b) no[*] devices at all will be powered down.
A3. PM domains will be powered up or down, depending on devices moving from
inactive to active state, or vice versa. This includes system suspend,
which can be considered some form of devices moving to an inactive
state.
In contrast, with CONFIG_PM_RUNTIME=n, we have:
B1. All PM domains are powered up during initialization,
B2. After initialization, PM domains just stay powered up,
B3. PM domains will be powered down on system suspend, and powered up on
system resume, based on the dev_pm_ops of the PM domain each device
belongs to.
While operation A2 is PM domain-centric (it walks the list of genpd domains),
A3 and B3 are device-centric (A3 operates on one specific device, B3 walks the
list of devices).
Hence B3 never touches PM domains that don't contain any devices[*].
So these PM domains are kept powered-up if CONFIG_PM_RUNTIME=n, even on
system suspend.
Shouldn't PM domains without devices be powered down at some point?
When? In B2, or in B3?
Thanks for your suggestions!
[*] It may sound strange to have a PM domain without devices. However, this may
happen due to incomplete device trees, or for devices without existing
bindings or without Linux support.
Gr{oetje,eeting}s,
Geert
P.S. Will any of you be at ELC-E next week, for further PM domain discussions?
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next reply other threads:[~2014-10-07 19:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 19:09 Geert Uytterhoeven [this message]
2014-10-08 3:29 ` Powering down unused PM domains Kevin Hilman
2014-10-08 10:05 ` Mark Brown
2014-10-08 12:00 ` Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot) Ulf Hansson
2014-10-08 13:49 ` Rafael J. Wysocki
2014-10-10 8:55 ` Pavel Machek
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=CAMuHMdUwbOEfLcu_UVKq_iHx5Qzn7ne1+cwt58C0ntTZBf1esg@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jack.dai@rock-chips.com \
--cc=jinkun.hong@rock-chips.com \
--cc=khilman@linaro.org \
--cc=len.brown@intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=pavel@ucw.cz \
--cc=philipp.zabel@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=tomasz.figa@gmail.com \
--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).