linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).