Re: [PATCH RFC] pmdomain: core: add hierarchy support for onecell providers

[Rob Herring <robh@kernel.org>]

On Wed, May 28, 2025 at 01:03:43PM -0700, Kevin Hilman wrote:
> Currently, PM domains can only support hierarchy for simple
> providers (e.g. ones with #power-domain-cells = 0).
> 
> Add support for oncell providers as well by adding a new property
> `power-domains-child-ids` to describe the parent/child relationship.
> 
> For example, an SCMI PM domain provider might be a subdomain of
> multiple parent domains. In this example, the parent domains are
> MAIN_PD and WKUP_PD:
> 
>     scmi_pds: protocol@11 {
>         reg = <0x11>;
>         #power-domain-cells = <1>;
>         power-domains = <&MAIN_PD>, <&WKUP_PD>;
>         power-domains-child-ids = <15>, <19>;
>     };
> 
> With the new property, child domain 15 (scmi_pds 15) becomes a
> subdomain of MAIN_PD, and child domain 19 (scmi_pds 19) becomes a
> subdomain of WKUP_PD.
> 
> Note: this idea was previously discussed on the arm-scmi mailing
> list[1] where this approach was proposed by Ulf.  This is my initial
> attempt at implementing it for discussion.  I'm definitely a noob at
> adding support new DT properties, so I got some help from an AI friend
> named Claude in writing this code, so feedback on the apprach is
> welcomed.
> 
> [1] https://lore.kernel.org/arm-scmi/CAPDyKFo_P129sVirHHYjOQT+QUmpymcRJme9obzKJeRgO7B-1A@mail.gmail.com/
> 
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
>  Documentation/devicetree/bindings/power/power-domain.yaml |  39 ++++++++++++++++++++++++++++++++
>  drivers/pmdomain/core.c                                   | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 150 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index 8fdb529d560b..1db82013e407 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -68,6 +68,21 @@ properties:
>        by the given provider should be subdomains of the domain specified
>        by this binding.
>  
> +  power-domains-child-ids:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description:
> +      An array of child domain IDs that correspond to the power-domains
> +      property. This property is only applicable to power domain providers
> +      with #power-domain-cells > 0 (i.e., providers that supply multiple
> +      power domains). It specifies which of the provider's child domains
> +      should be associated with each parent domain listed in the power-domains
> +      property. The number of elements in this array must match the number of
> +      phandles in the power-domains property. Each element specifies the child
> +      domain ID (index) that should be made a subdomain of the corresponding
> +      parent domain. This enables hierarchical power domain structures where
> +      different child domains from the same provider can have different
> +      parent domains.
> +
>  required:
>    - "#power-domain-cells"
>  
> @@ -133,3 +148,27 @@ examples:
>              min-residency-us = <7000>;
>          };
>      };
> +
> +  - |
> +    // Example of power-domains-child-ids usage
> +    MAIN_PD: main-power-controller {
> +        compatible = "foo,main-power-controller";
> +        #power-domain-cells = <0>;
> +    };
> +
> +    WKUP_PD: wkup-power-controller {
> +        compatible = "foo,wkup-power-controller";
> +        #power-domain-cells = <0>;
> +    };
> +
> +    scmi_pds: protocol@11 {
> +        reg = <0x11>;
> +        #power-domain-cells = <1>;
> +        power-domains = <&MAIN_PD>, <&WKUP_PD>;
> +        power-domains-child-ids = <15>, <19>;
> +    };

This all looks like a nexus map which is defined in the DT spec. To 
date, the only ones are interrupt-map and gpio-map. Here that would look 
like this:

power-domain-map = <15 &MAIN_PD>,
                   <19 &WKUP_PD>;

Quite simple in this case, but the general form of each entry is:
<<child address> <provider specifier cells> <parent provider> <parent provider specifier cells>>

<child address> is specific to interrupts dating back to the days when 
interrupt and bus hierarchies were the same (e.g. ISA).

For the existing cases, there's no s/w involvement by the child 
provider. For example, with an interrupt, the device ends up with the 
parent provider interrupt and there's no involvement by the child 
provider to enable/disable/ack interrupts. That doesn't have to be the 
case here if that's not desired.

Rob