[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230425-commotion-prewashed-876247bed4ab@spud>
Date: Tue, 25 Apr 2023 17:56:57 +0100
From: Conor Dooley <conor@...nel.org>
To: Changhuang Liang <changhuang.liang@...rfivetech.com>
Cc: Conor Dooley <conor.dooley@...rochip.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Emil Renner Berthing <kernel@...il.dk>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Walker Chen <walker.chen@...rfivetech.com>,
Hal Feng <hal.feng@...rfivetech.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, vkoul@...nel.org,
linux-phy@...ts.infradead.org
Subject: Re: [RESEND v2 1/6] dt-bindings: power: Add JH7110 AON PMU support
On Tue, Apr 25, 2023 at 08:26:35PM +0800, Changhuang Liang wrote:
> On 2023/4/25 17:35, Conor Dooley wrote:
> > On Tue, Apr 25, 2023 at 05:18:10PM +0800, Changhuang Liang wrote:
> >> On 2023/4/25 16:19, Krzysztof Kozlowski wrote:
> >>> On 25/04/2023 09:57, Changhuang Liang wrote:
> >>>> Yes, "starfive,jh7110-aon-pmu" is a child-node of "starfive,jh7110-aon-syscon".
> >>>> In my opinion, "0x17010000" is "aon-syscon" on JH7110 SoC, and this "aon-pmu" is just
> >>>> a part of "aon-syscon" function, so I think it is inappropriate to make "aon-syscon"
> >>>> to a power domain controller. I think using the child-node description is closer to
> >>>> JH7110 SoC.
> >>>
> >>> Unfortunately, I do not see the correlation between these, any
> >>> connection. Why being a child of syscon block would mean that this
> >>> should no be power domain controller? Really, why? These are two
> >>> unrelated things.
> >>
> >> Let me summarize what has been discussed above.
> >>
> >> There has two ways to describe this "starfive,jh7110-aon-syscon"(0x17010000).
> >> 1. (0x17010000) is power-controller node:
> >>
> >> aon_pwrc: power-controller@...10000 {
> >> compatible = "starfive,jh7110-aon-pmu", "syscon";
> >> reg = <0x0 0x17010000 0x0 0x1000>;
> >> #power-domain-cells = <1>;
> >> };
> >>
> >>
> >> 2. (0x17010000) is syscon node, power-controller is child-node of syscon:
> >>
> >> aon_syscon: syscon@...10000 {
> >> compatible = "starfive,jh7110-aon-syscon", "syscon", "simple-mfd";
> >> reg = <0x0 0x17010000 0x0 0x1000>;
> >>
> >> aon_pwrc: power-controller {
> >> compatible = "starfive,jh7110-aon-pmu";
> >> #power-domain-cells = <1>;
> >> };
> >> };
> >
> > I thought that Rob was suggesting something like this:
> > aon_syscon: syscon@...10000 {
> > compatible = "starfive,jh7110-aon-syscon", ...
> > reg = <0x0 0x17010000 0x0 0x1000>;
> > #power-domain-cells = <1>;
> > };
> I see the kernel:
> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> this file line 42:
> it's power-controller also has no meaningful properties.
> What do you think?
I'm not sure that I follow. It has a bunch of child-nodes does it not,
each of which is a domain?
I didn't see such domains in your dts patch, they're defined directly in
the driver instead AFAIU. Assuming I have understood that correctly,
your situation is different to that mediatek one?
Cheers,
Conor.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists