linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)
@ 2014-10-07 19:09 Geert Uytterhoeven
  2014-10-08  3:29 ` Powering down unused PM domains Kevin Hilman
  2014-10-08 12:00 ` Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot) Ulf Hansson
  0 siblings, 2 replies; 6+ messages in thread
From: Geert Uytterhoeven @ 2014-10-07 19:09 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Linux PM list,
	Kevin Hilman, Tomasz Figa, Philipp Zabel, Russell King,
	Mark Brown, Greg Kroah-Hartman, Jack Dai, Jinkun Hong

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-10-10  8:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-07 19:09 Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot) Geert Uytterhoeven
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

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