Ulf Hansson [off-list ref] writes:

On Wed, 25 Feb 2026 at 00:11, Kevin Hilman [off-list ref] wrote:

quoted

Geert Uytterhoeven [off-list ref] writes:

quoted

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 [off-list ref] wrote:

quoted

Rob Herring [off-list ref] writes:

quoted

On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:

quoted

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

quoted

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.

quoted

quoted

quoted

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.

quoted

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