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@xxxxxxxxxxxx> wrote:
> Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxxxxxxx

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