mbox series

[v2,0/3] PM / Domains: Add power on/off notifiers for genpd

Message ID 20200924110449.329523-1-ulf.hansson@linaro.org
Headers show
Series PM / Domains: Add power on/off notifiers for genpd | expand

Message

Ulf Hansson Sept. 24, 2020, 11:04 a.m. UTC
Changes in v2:
	- Improved error handling in patch3.

A device may have specific HW constraints that must be obeyed to, before its
corresponding PM domain (genpd) can be powered off - and vice verse at power
on. These constraints can't be managed through the regular runtime PM based
deployment for a device, because the access pattern for it, isn't always
request based. In other words, using the runtime PM callbacks to deal with the
constraints doesn't work for these cases.

For these reasons, this series introduces a power on/off notification mechanism
to genpd. To add/remove a notifier for a device, the device must already have
been attached to the genpd, which also means that it needs to be a part of the
PM domain topology.

The intent is to allow these genpd power on/off notifiers to replace the need
for the existing CPU_CLUSTER_PM_ENTER|EXIT notifiers. For example, those would
otherwise be needed in psci_pd_power_off() in cpuidle-psci-domain.c, when
powering off the CPU cluster.

Another series that enables drivers/soc/qcom/rpmh-rsc.c to make use of the new
genpd on/off notifiers, are soon to be posted. However, I would appreciate any
feedback on the approach taken, even before that series hits LKML.

Kind regards
Ulf Hansson


Ulf Hansson (3):
  PM / Domains: Rename power state enums for genpd
  PM / Domains: Allow to abort power off when no ->power_off() callback
  PM / Domains: Add support for PM domain on/off notifiers for genpd

 drivers/base/power/domain.c | 187 +++++++++++++++++++++++++++++-------
 include/linux/pm_domain.h   |  19 +++-
 2 files changed, 171 insertions(+), 35 deletions(-)

Comments

Ulf Hansson Sept. 28, 2020, 11:56 a.m. UTC | #1
Rafael,

On Thu, 24 Sep 2020 at 13:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Changes in v2:
>         - Improved error handling in patch3.
>
> A device may have specific HW constraints that must be obeyed to, before its
> corresponding PM domain (genpd) can be powered off - and vice verse at power
> on. These constraints can't be managed through the regular runtime PM based
> deployment for a device, because the access pattern for it, isn't always
> request based. In other words, using the runtime PM callbacks to deal with the
> constraints doesn't work for these cases.
>
> For these reasons, this series introduces a power on/off notification mechanism
> to genpd. To add/remove a notifier for a device, the device must already have
> been attached to the genpd, which also means that it needs to be a part of the
> PM domain topology.
>
> The intent is to allow these genpd power on/off notifiers to replace the need
> for the existing CPU_CLUSTER_PM_ENTER|EXIT notifiers. For example, those would
> otherwise be needed in psci_pd_power_off() in cpuidle-psci-domain.c, when
> powering off the CPU cluster.
>
> Another series that enables drivers/soc/qcom/rpmh-rsc.c to make use of the new
> genpd on/off notifiers, are soon to be posted. However, I would appreciate any
> feedback on the approach taken, even before that series hits LKML.
>
> Kind regards
> Ulf Hansson
>
>
> Ulf Hansson (3):
>   PM / Domains: Rename power state enums for genpd
>   PM / Domains: Allow to abort power off when no ->power_off() callback
>   PM / Domains: Add support for PM domain on/off notifiers for genpd
>
>  drivers/base/power/domain.c | 187 +++++++++++++++++++++++++++++-------
>  include/linux/pm_domain.h   |  19 +++-
>  2 files changed, 171 insertions(+), 35 deletions(-)
>
> --
> 2.25.1
>

I will need to iterate patch 3, potentially even a couple of more times.

As I expect patch 1 and patch2 to not get changed, may I suggest that
you pick up those so we can move focus to patch3?

Kind regards
Uffe
Rafael J. Wysocki Oct. 2, 2020, 5:17 p.m. UTC | #2
On Mon, Sep 28, 2020 at 1:57 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Rafael,
>
> On Thu, 24 Sep 2020 at 13:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > Changes in v2:
> >         - Improved error handling in patch3.
> >
> > A device may have specific HW constraints that must be obeyed to, before its
> > corresponding PM domain (genpd) can be powered off - and vice verse at power
> > on. These constraints can't be managed through the regular runtime PM based
> > deployment for a device, because the access pattern for it, isn't always
> > request based. In other words, using the runtime PM callbacks to deal with the
> > constraints doesn't work for these cases.
> >
> > For these reasons, this series introduces a power on/off notification mechanism
> > to genpd. To add/remove a notifier for a device, the device must already have
> > been attached to the genpd, which also means that it needs to be a part of the
> > PM domain topology.
> >
> > The intent is to allow these genpd power on/off notifiers to replace the need
> > for the existing CPU_CLUSTER_PM_ENTER|EXIT notifiers. For example, those would
> > otherwise be needed in psci_pd_power_off() in cpuidle-psci-domain.c, when
> > powering off the CPU cluster.
> >
> > Another series that enables drivers/soc/qcom/rpmh-rsc.c to make use of the new
> > genpd on/off notifiers, are soon to be posted. However, I would appreciate any
> > feedback on the approach taken, even before that series hits LKML.
> >
> > Kind regards
> > Ulf Hansson
> >
> >
> > Ulf Hansson (3):
> >   PM / Domains: Rename power state enums for genpd
> >   PM / Domains: Allow to abort power off when no ->power_off() callback
> >   PM / Domains: Add support for PM domain on/off notifiers for genpd
> >
> >  drivers/base/power/domain.c | 187 +++++++++++++++++++++++++++++-------
> >  include/linux/pm_domain.h   |  19 +++-
> >  2 files changed, 171 insertions(+), 35 deletions(-)
> >
> > --
> > 2.25.1
> >
>
> I will need to iterate patch 3, potentially even a couple of more times.
>
> As I expect patch 1 and patch2 to not get changed, may I suggest that
> you pick up those so we can move focus to patch3?

OK, [1-2/3] applied as 5.10 material with minor subject edits, thanks!