[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e196e9c-c942-4026-8d6c-69c9930bebd5@kernel.org>
Date: Sat, 22 Feb 2025 10:52:02 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Haylen Chu <heylenay@....org>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Haylen Chu <heylenay@...look.com>,
Yixun Lan <dlan@...too.org>, linux-riscv@...ts.infradead.org,
linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Inochi Amaoto <inochiama@...look.com>,
Chen Wang <unicornxdotw@...mail.com>, Jisheng Zhang <jszhang@...nel.org>,
Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>
Subject: Re: [PATCH v4 2/4] dt-bindings: soc: spacemit: Add spacemit,k1-syscon
On 15/02/2025 09:41, Haylen Chu wrote:
>
>>> };
>>>
>>> For the other two clock controllers (APBS and APBC), syscons are really
>>> unnecessary and it's simple to fold them.
>>
>>
>> I don't follow. Do we talk about children or syscon compatible?
>
> APBS region contains only clock (PLL) bits and APBC region contains only
> reset and clock bits, so I was thinking about dropping the syscon nodes
> and changing their compatible to spacemit,k1-plls and
> spacemit,k1-cru-apbc.
>
> In summary, my plan is,
>
> - For MPMU, APMU and APBC region, keep the binding in soc/spacemit.
> They'll be reset, clock and power controllers, with compatible
> "spacemit,k1-syscon-*".
> - For APBS region, write a new binding clock/spacemit,k1-plls, as it
> contains only PLL-related bits. It acts as clock controller.
> - All split children will be eliminated, there'll be only four device
> nodes, one for each region, matching the datasheet.
> - Put all clock-related binding definition of SpacemiT K1 in
> dt-bindings/clock/spacemit,k1-ccu.h
>
> Is it fine for you?
>
That did not explain hardware to me. You assume that some way, maybe
through magical crystal ball, I know your hardware and will tell you
what to do.
No.
I have dozens of other patches in my inbox. It's you who should explain
the hardware in simple, concise way so we can judge whether DT
description is correct.
Again: define what is the actual device, what is its address space, what
are its possible *separate* and *distinctive* children.
Best regards,
Krzysztof
Powered by blists - more mailing lists