[PATCH RFC v5 0/2] pmdomain: core: add support for domain hierarchies in DT

[PATCH RFC v5 0/2] pmdomain: core: add support for domain hierarchies in DT

[Kevin Hilman (TI)]

Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).

Add more generic support by creating an of_genpd helper which can
parse a nexus node map, and create domain hierarchy.

Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
Changes in v5:
- update subdomain language to parent/child
- add remove function to remove all children
- if any children in the map fail to add, remove them all
- Link to v4: https://patch.msgid.link/20251119-pmdomain-hierarchy-onecell-v4-0-f25a1d5022f8@baylibre.com

Changes in v4:
- use new OF iterator for parsing map. See:
  https://lore.kernel.org/r/20251119-topic-lpm-of-map-iterator-v6-18-v1-1-1f0075d771a3@baylibre.com
- instead of mapping on probe, create of_genpd helper to be called by providers
- Link to v3: https://lore.kernel.org/r/20250613-pmdomain-hierarchy-onecell-v3-0-5c770676fce7@baylibre.com

Changes in v3:
- use of_parse_phandle_with_args_map() instead of custom parsing
- probe when device is attatched to PM domain
- Link to v2: https://lore.kernel.org/r/20250528-pmdomain-hierarchy-onecell-v2-0-7885ae45e59c@baylibre.com

Changes in v2:
- Use nexus map instead of creating new property as suggested by Rob H.
- Link to v1: https://lore.kernel.org/r/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com

---
Kevin Hilman (TI) (2):
      pmdomain: core: support domain hierarchy via power-domain-map
      pmdomain: arm_scmi: add support for domain hierarchies

 drivers/pmdomain/arm/scmi_pm_domain.c |   5 +++++
 drivers/pmdomain/core.c               | 160 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h             |  16 ++++++++++++++++
 3 files changed, 181 insertions(+)
---
base-commit: 3e7f562e20ee87a25e104ef4fce557d39d62fa85
change-id: 20250528-pmdomain-hierarchy-onecell-a46fad47d855
prerequisite-change-id: 20251119-topic-lpm-of-map-iterator-v6-18-a61447423adc:v2
prerequisite-patch-id: e5697df059c17cf967fa6e4b1edb70874fee4ad3

Best regards,
--  
Kevin Hilman (TI) <khilman@baylibre.com>

[PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Kevin Hilman (TI)]

Add of_genpd_[add|remove]_subdomain_map() helper functions to support
hierarchical PM domains defined by using power-domains-map
property (c.f. nexus node maps in DT spec, section 2.5.1).

This enables PM domain providers with #power-domain-cells > 0 to
establish subdomain relationships via the power-domain-map property,
which was not previously possible.

These new helper functions:
- uses an OF helper to iterate to over entries in power-domain-map
- For each mapped entry: extracts child specifier, resolves parent phandle,
  extracts parent specifier args, and establishes subdomain relationship
- Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection

Example from k3-am62l.dtsi:

  scmi_pds: protocol@11 {
      #power-domain-cells = <1>;
      power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
                         <19 &WKUP_PD>;  /* WKUP_TIMER0 */
  };

  MAIN_PD: power-controller-main {
      #power-domain-cells = <0>;
  };

  WKUP_PD: power-controller-main {
      #power-domain-cells = <0>;
  };

This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
domain 19 to become a subdomain of WKUP_PD.

Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
 drivers/pmdomain/core.c   | 160 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h |  16 ++++++++++++++++
 2 files changed, 176 insertions(+)

diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index bf82775f6a67..cee7fbbda829 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3556,6 +3556,166 @@ static struct device_driver genpd_provider_drv = {
 	.suppress_bind_attrs = true,
 };
 
+/**
+ * of_genpd_remove_subdomain_map - Remove subdomain relationships from map
+ *
+ * @np: pointer to parent node containing map property
+ * @data: pointer to PM domain onecell data
+ *
+ * Iterate over entries in a power-domain-map, and remove the subdomain
+ * relationships that were previously established by of_genpd_add_subdomain_map().
+ * This allows cleanup during driver removal or error handling.
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+int of_genpd_remove_subdomain_map(struct device_node *np,
+				  struct genpd_onecell_data *data)
+{
+	struct generic_pm_domain *genpd, *parent_genpd;
+	struct of_phandle_args child_args, parent_args;
+	int index = 0;
+	int ret = 0;
+	u32 child_index;
+
+	if (!np || !data)
+		return -EINVAL;
+
+	/* Iterate through power-domain-map entries using the OF helper */
+	while (!of_parse_map_iter(np, "power-domain", &index,
+				   &child_args, &parent_args)) {
+		/* Extract the child domain index from the child specifier */
+		if (child_args.args_count < 1) {
+			of_node_put(parent_args.np);
+			continue;
+		}
+		child_index = child_args.args[0];
+
+		/* Validate child domain index */
+		if (child_index >= data->num_domains) {
+			of_node_put(parent_args.np);
+			continue;
+		}
+
+		genpd = data->domains[child_index];
+		if (!genpd) {
+			of_node_put(parent_args.np);
+			continue;
+		}
+
+		/* Get parent power domain from provider */
+		mutex_lock(&gpd_list_lock);
+
+		parent_genpd = genpd_get_from_provider(&parent_args);
+		if (IS_ERR(parent_genpd)) {
+			mutex_unlock(&gpd_list_lock);
+			of_node_put(parent_args.np);
+			dev_warn(&genpd->dev, "failed to get parent domain for removal\n");
+			continue;
+		}
+
+		/* Remove subdomain relationship */
+		ret = pm_genpd_remove_subdomain(parent_genpd, genpd);
+		mutex_unlock(&gpd_list_lock);
+		of_node_put(parent_args.np);
+
+		if (ret)
+			dev_warn(&genpd->dev, "failed to remove as subdomain of %s: %d\n",
+				 parent_genpd->name, ret);
+		else
+			dev_dbg(&genpd->dev, "removed as subdomain of %s\n",
+				parent_genpd->name);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_remove_subdomain_map);
+
+/**
+ * of_genpd_add_subdomain_map - Parse and map child PM domains
+ *
+ * @np: pointer to parent node containing map property
+ * @data: pointer to PM domain onecell data
+ *
+ * Iterate over entries in a power-domain-map, and add them as
+ * children of the parent domain. If any child fails to be added,
+ * all previously added children are removed to maintain atomicity.
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+int of_genpd_add_subdomain_map(struct device_node *np,
+			       struct genpd_onecell_data *data)
+{
+	struct generic_pm_domain *genpd, *parent_genpd;
+	struct of_phandle_args child_args, parent_args;
+	int index = 0;
+	int ret = 0;
+	u32 child_index;
+
+	if (!np || !data)
+		return -EINVAL;
+
+	/* Iterate through power-domain-map entries using the OF helper */
+	while (!of_parse_map_iter(np, "power-domain", &index,
+				   &child_args, &parent_args)) {
+		/* Extract the child domain index from the child specifier */
+		if (child_args.args_count < 1) {
+			of_node_put(parent_args.np);
+			ret = -EINVAL;
+			goto cleanup;
+		}
+		child_index = child_args.args[0];
+
+		/* Validate child domain index */
+		if (child_index >= data->num_domains) {
+			of_node_put(parent_args.np);
+			pr_debug("map's child index (%u) > number of domains (%u).  Skipping.\n",
+				 child_index, data->num_domains);
+			ret = -EINVAL;
+			goto cleanup;
+		}
+
+		genpd = data->domains[child_index];
+		if (!genpd) {
+			of_node_put(parent_args.np);
+			continue;
+		}
+
+		/* Get parent power domain from provider and establish subdomain relationship */
+		mutex_lock(&gpd_list_lock);
+
+		parent_genpd = genpd_get_from_provider(&parent_args);
+		if (IS_ERR(parent_genpd)) {
+			mutex_unlock(&gpd_list_lock);
+			of_node_put(parent_args.np);
+			ret = PTR_ERR(parent_genpd);
+			dev_err(&genpd->dev, "failed to get parent domain: %d\n", ret);
+			goto cleanup;
+		}
+
+		ret = genpd_add_subdomain(parent_genpd, genpd);
+		mutex_unlock(&gpd_list_lock);
+		of_node_put(parent_args.np);
+
+		if (ret) {
+			dev_err(&genpd->dev, "failed to add as subdomain of %s: %d\n",
+				parent_genpd->name, ret);
+			goto cleanup;
+		}
+
+		dev_dbg(&genpd->dev, "added as subdomain of %s\n",
+			parent_genpd->name);
+	}
+
+	return 0;
+
+cleanup:
+	/* Remove all successfully added subdomains using the removal function */
+	pr_err("rolling back child map additions due to error: %d\n", ret);
+	of_genpd_remove_subdomain_map(np, data);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_genpd_add_subdomain_map);
+
 static int __init genpd_bus_init(void)
 {
 	int ret;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 93ba0143ca47..3baf224e4f24 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -463,6 +463,10 @@ int of_genpd_add_subdomain(const struct of_phandle_args *parent_spec,
 int of_genpd_remove_subdomain(const struct of_phandle_args *parent_spec,
 			      const struct of_phandle_args *subdomain_spec);
 struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
+int of_genpd_add_subdomain_map(struct device_node *np,
+			       struct genpd_onecell_data *data);
+int of_genpd_remove_subdomain_map(struct device_node *np,
+				  struct genpd_onecell_data *data);
 int of_genpd_parse_idle_states(struct device_node *dn,
 			       struct genpd_power_state **states, int *n);
 void of_genpd_sync_state(struct device_node *np);
@@ -505,6 +509,18 @@ static inline int of_genpd_remove_subdomain(const struct of_phandle_args *parent
 	return -ENODEV;
 }
 
+static inline int of_genpd_add_subdomain_map(struct device_node *np,
+					     struct genpd_onecell_data *data)
+{
+	return -ENODEV;
+}
+
+static inline int of_genpd_remove_subdomain_map(struct device_node *np,
+						struct genpd_onecell_data *data)
+{
+	return -ENODEV;
+}
+
 static inline int of_genpd_parse_idle_states(struct device_node *dn,
 			struct genpd_power_state **states, int *n)
 {

-- 
2.51.0

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Rob Herring]

On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
> hierarchical PM domains defined by using power-domains-map

power-domain-map. No 's'.

> property (c.f. nexus node maps in DT spec, section 2.5.1).
> 
> This enables PM domain providers with #power-domain-cells > 0 to
> establish subdomain relationships via the power-domain-map property,
> which was not previously possible.
> 
> These new helper functions:
> - uses an OF helper to iterate to over entries in power-domain-map
> - For each mapped entry: extracts child specifier, resolves parent phandle,
>   extracts parent specifier args, and establishes subdomain relationship
> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
> 
> Example from k3-am62l.dtsi:
> 
>   scmi_pds: protocol@11 {
>       #power-domain-cells = <1>;
>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
>   };
> 
>   MAIN_PD: power-controller-main {
>       #power-domain-cells = <0>;
>   };
> 
>   WKUP_PD: power-controller-main {
>       #power-domain-cells = <0>;
>   };
> 
> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
> domain 19 to become a subdomain of WKUP_PD.

One concern I have here is generally *-map is transparent meaning when 
you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's 
also possible to have a map point to another map until you get to the 
final provider. The only way we have to support both behaviors is the 
consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs. 
of_parse_phandle_with_args()), but the consumer shouldn't really know 
this detail.

Maybe a transparent map of power-domains would never make sense. IDK. If 
so, then there's not really any issue since the pmdomain core handles 
everyone the same way.

Rob

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Kevin Hilman]

Rob Herring <robh@kernel.org> writes:

> On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
>> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
>> hierarchical PM domains defined by using power-domains-map
>
> power-domain-map. No 's'.
>
>> property (c.f. nexus node maps in DT spec, section 2.5.1).
>> 
>> This enables PM domain providers with #power-domain-cells > 0 to
>> establish subdomain relationships via the power-domain-map property,
>> which was not previously possible.
>> 
>> These new helper functions:
>> - uses an OF helper to iterate to over entries in power-domain-map
>> - For each mapped entry: extracts child specifier, resolves parent phandle,
>>   extracts parent specifier args, and establishes subdomain relationship
>> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
>> 
>> Example from k3-am62l.dtsi:
>> 
>>   scmi_pds: protocol@11 {
>>       #power-domain-cells = <1>;
>>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
>>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
>>   };
>> 
>>   MAIN_PD: power-controller-main {
>>       #power-domain-cells = <0>;
>>   };
>> 
>>   WKUP_PD: power-controller-main {
>>       #power-domain-cells = <0>;
>>   };
>> 
>> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
>> domain 19 to become a subdomain of WKUP_PD.
>
> One concern I have here is generally *-map is transparent meaning when 
> you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's 
> also possible to have a map point to another map until you get to the 
> final provider. The only way we have to support both behaviors is the 
> consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs. 
> of_parse_phandle_with_args()), but the consumer shouldn't really know 
> this detail.
>
> Maybe a transparent map of power-domains would never make sense. IDK. If 
> so, then there's not really any issue since the pmdomain core handles 
> everyone the same way.

I don't really know enough about potential usage of maps to know if
there's ever a usecase for transparent maps.  However, the problem I'm
trying to solve is less about transparent maps, and more about
describing hierarchy in a situation where "leaf" domains of the same
type (e.g. SCMI) can have different parent domains.

When I first proposed this[1], I didn't use a map, but you suggested I
try using a map[2].  So I'm not sure if I misunderstood what you
proposed, or if now that you see it implemented, you're second guessing if
the map is the right approach.

Kevin

[1] https://lore.kernel.org/r/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com
[2] https://lore.kernel.org/r/20250528203532.GA704342-robh@kernel.org

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Geert Uytterhoeven]

Hi Kevin,

Thanks for your series! I became aware of it only recently, and read
it and its history with great interest...

On Wed, 4 Feb 2026 at 00:13, Kevin Hilman <khilman@baylibre.com> wrote:
> Rob Herring <robh@kernel.org> writes:
> > On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
> >> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
> >> hierarchical PM domains defined by using power-domains-map
> >
> > power-domain-map. No 's'.
> >
> >> property (c.f. nexus node maps in DT spec, section 2.5.1).
> >>
> >> This enables PM domain providers with #power-domain-cells > 0 to
> >> establish subdomain relationships via the power-domain-map property,
> >> which was not previously possible.
> >>
> >> These new helper functions:
> >> - uses an OF helper to iterate to over entries in power-domain-map
> >> - For each mapped entry: extracts child specifier, resolves parent phandle,
> >>   extracts parent specifier args, and establishes subdomain relationship
> >> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
> >>
> >> Example from k3-am62l.dtsi:
> >>
> >>   scmi_pds: protocol@11 {
> >>       #power-domain-cells = <1>;
> >>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
> >>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
> >>   };
> >>
> >>   MAIN_PD: power-controller-main {
> >>       #power-domain-cells = <0>;
> >>   };
> >>
> >>   WKUP_PD: power-controller-main {
> >>       #power-domain-cells = <0>;
> >>   };
> >>
> >> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
> >> domain 19 to become a subdomain of WKUP_PD.
> >
> > One concern I have here is generally *-map is transparent meaning when
> > you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's
> > also possible to have a map point to another map until you get to the
> > final provider. The only way we have to support both behaviors is the
> > consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs.
> > of_parse_phandle_with_args()), but the consumer shouldn't really know
> > this detail.

This is also the first thing I was worried about, when I noticed you are
not doing transparent mapping, but add an explicit hierarchy instead,
based on the map.

> > Maybe a transparent map of power-domains would never make sense. IDK. If
> > so, then there's not really any issue since the pmdomain core handles
> > everyone the same way.

AFAIUI, SCMI is not limited to the SoC, but may be used for the whole
hardware platform, so it could control power to external devices, too.
Once we need to map a power domain through a connector, we need
support for transparent mapping through a nexus node.

> I don't really know enough about potential usage of maps to know if
> there's ever a usecase for transparent maps.  However, the problem I'm
> trying to solve is less about transparent maps, and more about
> describing hierarchy in a situation where "leaf" domains of the same
> type (e.g. SCMI) can have different parent domains.

Hierarchy is indeed something that cannot be described with the current
SCMI power domain management protocol.  This includes external hierarchy
(your use case), and internal hierarchy: AFAIK, Linux cannot be made
aware of the hierarchical relationship among the different power
domains controlled through SCMI either.

Gr{oetje,eeting}s,

                        Geert

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

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Kevin,
>
> Thanks for your series! I became aware of it only recently, and read
> it and its history with great interest...
>
> On Wed, 4 Feb 2026 at 00:13, Kevin Hilman <khilman@baylibre.com> wrote:
>> Rob Herring <robh@kernel.org> writes:
>> > On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
>> >> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
>> >> hierarchical PM domains defined by using power-domains-map
>> >
>> > power-domain-map. No 's'.
>> >
>> >> property (c.f. nexus node maps in DT spec, section 2.5.1).
>> >>
>> >> This enables PM domain providers with #power-domain-cells > 0 to
>> >> establish subdomain relationships via the power-domain-map property,
>> >> which was not previously possible.
>> >>
>> >> These new helper functions:
>> >> - uses an OF helper to iterate to over entries in power-domain-map
>> >> - For each mapped entry: extracts child specifier, resolves parent phandle,
>> >>   extracts parent specifier args, and establishes subdomain relationship
>> >> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
>> >>
>> >> Example from k3-am62l.dtsi:
>> >>
>> >>   scmi_pds: protocol@11 {
>> >>       #power-domain-cells = <1>;
>> >>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
>> >>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
>> >>   };
>> >>
>> >>   MAIN_PD: power-controller-main {
>> >>       #power-domain-cells = <0>;
>> >>   };
>> >>
>> >>   WKUP_PD: power-controller-main {
>> >>       #power-domain-cells = <0>;
>> >>   };
>> >>
>> >> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
>> >> domain 19 to become a subdomain of WKUP_PD.
>> >
>> > One concern I have here is generally *-map is transparent meaning when
>> > you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's
>> > also possible to have a map point to another map until you get to the
>> > final provider. The only way we have to support both behaviors is the
>> > consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs.
>> > of_parse_phandle_with_args()), but the consumer shouldn't really know
>> > this detail.
>
> This is also the first thing I was worried about, when I noticed you are
> not doing transparent mapping, but add an explicit hierarchy instead,
> based on the map.

Yeah, the map wasn't my original idea, and TBH, I had never really even
heard of nexus node maps before it was suggested by Rob[1] that I could
use it to describe hierarchy.

But... I'm gathering from Rob's and your recent feedback that my current
approach to using a map is an abuse/misuse of the map because it's just
being used to describe hierarchy, and because it's not transparent.

I'm still waiting to hear from Rob to see if I understood that right,
but your feedback is making me think that's the case.

If so, I'm honestly not sure where to go next.

>> > Maybe a transparent map of power-domains would never make sense. IDK. If
>> > so, then there's not really any issue since the pmdomain core handles
>> > everyone the same way.
>
> AFAIUI, SCMI is not limited to the SoC, but may be used for the whole
> hardware platform, so it could control power to external devices, too.
> Once we need to map a power domain through a connector, we need
> support for transparent mapping through a nexus node.
>
>> I don't really know enough about potential usage of maps to know if
>> there's ever a usecase for transparent maps.  However, the problem I'm
>> trying to solve is less about transparent maps, and more about
>> describing hierarchy in a situation where "leaf" domains of the same
>> type (e.g. SCMI) can have different parent domains.
>
> Hierarchy is indeed something that cannot be described with the current
> SCMI power domain management protocol.  This includes external hierarchy
> (your use case), and internal hierarchy: AFAIK, Linux cannot be made
> aware of the hierarchical relationship among the different power
> domains controlled through SCMI either.

Yes, the limitations of SCMI (both the protocol, and the Linux
implementation) are the root cause here.  In case you didn't see it,
before I posted the original version of this series, I started a thread
on the arm-scmi list to discuss implementation options[2]

So since this is primarily and SCMI limitation, maybe I should just go
back to the original proposal of using power-domains-child-ids[3]?

I'm definitely open to suggestions here as I'm a bit out of my depth
here.

Kevin

[1] https://lore.kernel.org/r/20250528203532.GA704342-robh@kernel.org
[2] https://lore.kernel.org/arm-scmi/7hecy3h7ky.fsf@baylibre.com/
[3] https://lore.kernel.org/all/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com/

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Ulf Hansson]

On Wed, 25 Feb 2026 at 00:11, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
> > Hi Kevin,
> >
> > Thanks for your series! I became aware of it only recently, and read
> > it and its history with great interest...
> >
> > On Wed, 4 Feb 2026 at 00:13, Kevin Hilman <khilman@baylibre.com> wrote:
> >> Rob Herring <robh@kernel.org> writes:
> >> > On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
> >> >> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
> >> >> hierarchical PM domains defined by using power-domains-map
> >> >
> >> > power-domain-map. No 's'.
> >> >
> >> >> property (c.f. nexus node maps in DT spec, section 2.5.1).
> >> >>
> >> >> This enables PM domain providers with #power-domain-cells > 0 to
> >> >> establish subdomain relationships via the power-domain-map property,
> >> >> which was not previously possible.
> >> >>
> >> >> These new helper functions:
> >> >> - uses an OF helper to iterate to over entries in power-domain-map
> >> >> - For each mapped entry: extracts child specifier, resolves parent phandle,
> >> >>   extracts parent specifier args, and establishes subdomain relationship
> >> >> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
> >> >>
> >> >> Example from k3-am62l.dtsi:
> >> >>
> >> >>   scmi_pds: protocol@11 {
> >> >>       #power-domain-cells = <1>;
> >> >>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
> >> >>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
> >> >>   };
> >> >>
> >> >>   MAIN_PD: power-controller-main {
> >> >>       #power-domain-cells = <0>;
> >> >>   };
> >> >>
> >> >>   WKUP_PD: power-controller-main {
> >> >>       #power-domain-cells = <0>;
> >> >>   };
> >> >>
> >> >> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
> >> >> domain 19 to become a subdomain of WKUP_PD.
> >> >
> >> > One concern I have here is generally *-map is transparent meaning when
> >> > you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's
> >> > also possible to have a map point to another map until you get to the
> >> > final provider. The only way we have to support both behaviors is the
> >> > consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs.
> >> > of_parse_phandle_with_args()), but the consumer shouldn't really know
> >> > this detail.
> >
> > This is also the first thing I was worried about, when I noticed you are
> > not doing transparent mapping, but add an explicit hierarchy instead,
> > based on the map.
>
> Yeah, the map wasn't my original idea, and TBH, I had never really even
> heard of nexus node maps before it was suggested by Rob[1] that I could
> use it to describe hierarchy.
>
> But... I'm gathering from Rob's and your recent feedback that my current
> approach to using a map is an abuse/misuse of the map because it's just
> being used to describe hierarchy, and because it's not transparent.
>
> I'm still waiting to hear from Rob to see if I understood that right,
> but your feedback is making me think that's the case.
>
> If so, I'm honestly not sure where to go next.
>
> >> > Maybe a transparent map of power-domains would never make sense. IDK. If
> >> > so, then there's not really any issue since the pmdomain core handles
> >> > everyone the same way.
> >
> > AFAIUI, SCMI is not limited to the SoC, but may be used for the whole
> > hardware platform, so it could control power to external devices, too.
> > Once we need to map a power domain through a connector, we need
> > support for transparent mapping through a nexus node.
> >
> >> I don't really know enough about potential usage of maps to know if
> >> there's ever a usecase for transparent maps.  However, the problem I'm
> >> trying to solve is less about transparent maps, and more about
> >> describing hierarchy in a situation where "leaf" domains of the same
> >> type (e.g. SCMI) can have different parent domains.
> >
> > Hierarchy is indeed something that cannot be described with the current
> > SCMI power domain management protocol.  This includes external hierarchy
> > (your use case), and internal hierarchy: AFAIK, Linux cannot be made
> > aware of the hierarchical relationship among the different power
> > domains controlled through SCMI either.
>
> Yes, the limitations of SCMI (both the protocol, and the Linux
> implementation) are the root cause here.  In case you didn't see it,
> before I posted the original version of this series, I started a thread
> on the arm-scmi list to discuss implementation options[2]
>
> So since this is primarily and SCMI limitation, maybe I should just go
> back to the original proposal of using power-domains-child-ids[3]?
>
> I'm definitely open to suggestions here as I'm a bit out of my depth
> here.

FWIW, I favor re-trying the "power-domains-child-ids" [3] approach.

The main reason is that we already have the "power-domains" property,
which allows us to describe parents using a list of phandles.

To me, it seems more sensible to extend this with a new
"power-domains-child-ids" property, which can be used when needed,
rather than inventing an entirely new property, that would replace the
existing one.

Kind regards
Uffe

>
> [1] https://lore.kernel.org/r/20250528203532.GA704342-robh@kernel.org
> [2] https://lore.kernel.org/arm-scmi/7hecy3h7ky.fsf@baylibre.com/
> [3] https://lore.kernel.org/all/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com/

Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

[Kevin Hilman]

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On Wed, 25 Feb 2026 at 00:11, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>
>> > Hi Kevin,
>> >
>> > Thanks for your series! I became aware of it only recently, and read
>> > it and its history with great interest...
>> >
>> > On Wed, 4 Feb 2026 at 00:13, Kevin Hilman <khilman@baylibre.com> wrote:
>> >> Rob Herring <robh@kernel.org> writes:
>> >> > On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
>> >> >> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
>> >> >> hierarchical PM domains defined by using power-domains-map
>> >> >
>> >> > power-domain-map. No 's'.
>> >> >
>> >> >> property (c.f. nexus node maps in DT spec, section 2.5.1).
>> >> >>
>> >> >> This enables PM domain providers with #power-domain-cells > 0 to
>> >> >> establish subdomain relationships via the power-domain-map property,
>> >> >> which was not previously possible.
>> >> >>
>> >> >> These new helper functions:
>> >> >> - uses an OF helper to iterate to over entries in power-domain-map
>> >> >> - For each mapped entry: extracts child specifier, resolves parent phandle,
>> >> >>   extracts parent specifier args, and establishes subdomain relationship
>> >> >> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
>> >> >>
>> >> >> Example from k3-am62l.dtsi:
>> >> >>
>> >> >>   scmi_pds: protocol@11 {
>> >> >>       #power-domain-cells = <1>;
>> >> >>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
>> >> >>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
>> >> >>   };
>> >> >>
>> >> >>   MAIN_PD: power-controller-main {
>> >> >>       #power-domain-cells = <0>;
>> >> >>   };
>> >> >>
>> >> >>   WKUP_PD: power-controller-main {
>> >> >>       #power-domain-cells = <0>;
>> >> >>   };
>> >> >>
>> >> >> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
>> >> >> domain 19 to become a subdomain of WKUP_PD.
>> >> >
>> >> > One concern I have here is generally *-map is transparent meaning when
>> >> > you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's
>> >> > also possible to have a map point to another map until you get to the
>> >> > final provider. The only way we have to support both behaviors is the
>> >> > consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs.
>> >> > of_parse_phandle_with_args()), but the consumer shouldn't really know
>> >> > this detail.
>> >
>> > This is also the first thing I was worried about, when I noticed you are
>> > not doing transparent mapping, but add an explicit hierarchy instead,
>> > based on the map.
>>
>> Yeah, the map wasn't my original idea, and TBH, I had never really even
>> heard of nexus node maps before it was suggested by Rob[1] that I could
>> use it to describe hierarchy.
>>
>> But... I'm gathering from Rob's and your recent feedback that my current
>> approach to using a map is an abuse/misuse of the map because it's just
>> being used to describe hierarchy, and because it's not transparent.
>>
>> I'm still waiting to hear from Rob to see if I understood that right,
>> but your feedback is making me think that's the case.
>>
>> If so, I'm honestly not sure where to go next.
>>
>> >> > Maybe a transparent map of power-domains would never make sense. IDK. If
>> >> > so, then there's not really any issue since the pmdomain core handles
>> >> > everyone the same way.
>> >
>> > AFAIUI, SCMI is not limited to the SoC, but may be used for the whole
>> > hardware platform, so it could control power to external devices, too.
>> > Once we need to map a power domain through a connector, we need
>> > support for transparent mapping through a nexus node.
>> >
>> >> I don't really know enough about potential usage of maps to know if
>> >> there's ever a usecase for transparent maps.  However, the problem I'm
>> >> trying to solve is less about transparent maps, and more about
>> >> describing hierarchy in a situation where "leaf" domains of the same
>> >> type (e.g. SCMI) can have different parent domains.
>> >
>> > Hierarchy is indeed something that cannot be described with the current
>> > SCMI power domain management protocol.  This includes external hierarchy
>> > (your use case), and internal hierarchy: AFAIK, Linux cannot be made
>> > aware of the hierarchical relationship among the different power
>> > domains controlled through SCMI either.
>>
>> Yes, the limitations of SCMI (both the protocol, and the Linux
>> implementation) are the root cause here.  In case you didn't see it,
>> before I posted the original version of this series, I started a thread
>> on the arm-scmi list to discuss implementation options[2]
>>
>> So since this is primarily and SCMI limitation, maybe I should just go
>> back to the original proposal of using power-domains-child-ids[3]?
>>
>> I'm definitely open to suggestions here as I'm a bit out of my depth
>> here.
>
> FWIW, I favor re-trying the "power-domains-child-ids" [3] approach.
>
> The main reason is that we already have the "power-domains" property,
> which allows us to describe parents using a list of phandles.
>
> To me, it seems more sensible to extend this with a new
> "power-domains-child-ids" property, which can be used when needed,
> rather than inventing an entirely new property, that would replace the
> existing one.

OK, in the absence of any feedback from the DT maintainers, I'll go back
to the original approach of using `power-domain-child-ids`.

Kevin

[PATCH RFC v5 2/2] pmdomain: arm_scmi: add support for domain hierarchies

[Kevin Hilman (TI)]

After primary SCMI pmdomain is created, use new of_genpd helper to
check if there are any child domain mappings defined by
power-domain-map, and create domain hierarchy.  Also remove any child
domain mappings when SCMI domain is removed.

Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
 drivers/pmdomain/arm/scmi_pm_domain.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index b5e2ffd5ea64..a52387c45d88 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -114,8 +114,12 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
 
 	dev_set_drvdata(dev, scmi_pd_data);
 
+	/* check for (optional) subdomain mapping with power-domain-map */
+	of_genpd_add_subdomain_map(np, scmi_pd_data);
+
 	return 0;
 err_rm_genpds:
+	of_genpd_remove_subdomain_map(np, scmi_pd_data);
 	for (i = num_domains - 1; i >= 0; i--)
 		pm_genpd_remove(domains[i]);
 
@@ -132,6 +136,7 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
 	of_genpd_del_provider(np);
 
 	scmi_pd_data = dev_get_drvdata(dev);
+	of_genpd_remove_subdomain_map(np, scmi_pd_data);
 	for (i = 0; i < scmi_pd_data->num_domains; i++) {
 		if (!scmi_pd_data->domains[i])
 			continue;

-- 
2.51.0