[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b89aed0-f9b7-fdba-16d8-a8bd9e2d7437@marcan.st>
Date: Thu, 7 Oct 2021 00:59:37 +0900
From: Hector Martin <marcan@...can.st>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
linux-arm-kernel@...ts.infradead.org
Cc: Marc Zyngier <maz@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Arnd Bergmann <arnd@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mark Kettenis <mark.kettenis@...all.nl>,
Philipp Zabel <p.zabel@...gutronix.de>,
"Rafael J. Wysocki" <rafael@...nel.org>,
devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
linux-serial@...r.kernel.org
Subject: Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding
On 06/10/2021 16.05, Krzysztof Kozlowski wrote:
>> + IP cores belonging to a power domain should contain a
>> + "power-domains" property that is a phandle for the
>> + power domain node representing the domain.
>
> Skip this last paragraph - it is obvious in usage of power domains.
> Specific bindings should not duplicate generic knowledge.
Ack, I'll drop it.
>> +properties:
>> + $nodename:
>> + pattern: "^power-controller@[0-9a-f]+$"
>
> Usually we call nodes as power-domain.
I had it as that originally, but these aren't power domains. These are
power management domains (they can clock *and* power gate separately,
where supported) plus also do reset management. So I wasn't sure if it
was really fair calling them "power-domain" at that point.
>> + power-domains:
>> + description:
>> + Reference to parent power domains. A domain may have multiple parents,
>> + and all will be powered up when it is powered.
>
> How many items?
One or more (if there are none the property should not exist). I guess
that should be encoded.
>> +
>> + apple,domain-name:
>
> Use existing binding "label".
Ah, I'd missed that one! I'm glad there's an existing binding for this
already.
> Your parent schema should include this one for evaluating children.
Yup, I'll do it like that for v2.
Thanks!
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists