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

[Kevin Hilman]

Geert Uytterhoeven <geert at 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 at baylibre.com> wrote:
>> Rob Herring <robh at 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 at 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/