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

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