Message-ID: <7h8qmgpf88.fsf@baylibre.com>
Date: Wed, 28 May 2025 15:01:11 -0700
From: Kevin Hilman <khilman@...libre.com>
To: Rob Herring <robh@...nel.org>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, "Rafael J.
 Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 arm-scmi@...r.kernel.org
Subject: Re: [PATCH RFC] pmdomain: core: add hierarchy support for onecell
 providers

Hi Rob,

Rob Herring <robh@...nel.org> writes:

> 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@...libre.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.

Hmm, very interesting.  I wasn't aware of these nexus node map things.

I have respun a v2 using the nexus map:
https://lore.kernel.org/linux-pm/20250528-pmdomain-hierarchy-onecell-v2-0-7885ae45e59c@baylibre.com/T/#t

Thanks for the review & suggestion,

Kevin

Powered by blists - more mailing lists