Re: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)

Re: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)

[Ulf Hansson]

On 7 October 2014 21:09, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 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.

Right. That's obviously not an acceptable behaviour, we can do better.

>
> 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?

I agree with Rafael and Sylwester, that it would be an advantage if PM
domains can be initialized in powered off state. Simply because, those
may then be left in powered off state all the time, if they are
unused.

That's been my long term approach, but let's see if we can get there
without the intermediate step proposed in this patchset...

Now, to support the above and to solve the race conditions, we need to
be able to power up the PM domain, prior probing of a device. I am
thinking of a solution aimed to affect subsystem level code (buses)
and not drivers, since we need keep the impact on a reasonable level.

Let's see what I will come up with. I have some ideas that I am trying out...

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

I understand.

I guess another valid argument is the kernel configuration. The
corresponding driver which normally would handle the device may
intentionally not even been build into the kernel. Certainly we must
not leave those unused PM domains in powered up state.

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> P.S. Will any of you be at ELC-E next week, for further PM domain discussions?

That would have been great, but I won't be there. Unless I schedule a
last minute trip. :-)

Kind regards
Uffe

Re: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)

[Rafael J. Wysocki]

On Wednesday, October 08, 2014 02:00:50 PM Ulf Hansson wrote:
> On 7 October 2014 21:09, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > 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.
> 
> Right. That's obviously not an acceptable behaviour, we can do better.
> 
> >
> > 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?
> 
> I agree with Rafael and Sylwester, that it would be an advantage if PM
> domains can be initialized in powered off state. Simply because, those
> may then be left in powered off state all the time, if they are
> unused.
> 
> That's been my long term approach, but let's see if we can get there
> without the intermediate step proposed in this patchset...
> 
> Now, to support the above and to solve the race conditions, we need to
> be able to power up the PM domain, prior probing of a device. I am
> thinking of a solution aimed to affect subsystem level code (buses)
> and not drivers, since we need keep the impact on a reasonable level.

That sounds like a good approach to me.

Also that should work regardless of whether or not the drivers in question
implement runtime PM callbacks.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)

[Pavel Machek]

Hi!

> > 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?
> 
> I agree with Rafael and Sylwester, that it would be an advantage if PM
> domains can be initialized in powered off state. Simply because, those
> may then be left in powered off state all the time, if they are
> unused.

Also... powering up all the domains at the same time is quite harsh at
the battery. Even if they are powered down "soon", it still causes
spike in current which may trip the battery (especially when battery
is old and nearly discharged).

> > P.S. Will any of you be at ELC-E next week, for further PM domain discussions?
> 
> That would have been great, but I won't be there. Unless I schedule a
> last minute trip. :-)

I should be there.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html