[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z4KdNGPVpZxJXqxa@pie>
Date: Sat, 11 Jan 2025 16:32:52 +0000
From: Yao Zi <ziyao@...root.org>
To: Krzysztof Kozlowski <krzk@...nel.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>,
Heiko Stuebner <heiko@...ech.de>,
Philipp Zabel <p.zabel@...gutronix.de>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] dt-bindings: clock: Document clock and reset unit
of RK3528
On Fri, Jan 10, 2025 at 08:42:40AM +0100, Krzysztof Kozlowski wrote:
> On 09/01/2025 10:16, Yao Zi wrote:
> > On Thu, Jan 09, 2025 at 09:59:25AM +0100, Krzysztof Kozlowski wrote:
> >> On Wed, Jan 08, 2025 at 11:46:02AM +0000, Yao Zi wrote:
> >>> There are two types of clocks in RK3528 SoC, CRU-managed and
> >>> SCMI-managed. Independent IDs are assigned to them.
> >>>
> >>> For the reset part, differing from previous Rockchip SoCs and
> >>> downstream bindings which embeds register offsets into the IDs, gapless
> >>> numbers starting from zero are used.
> >>>
> >>> Signed-off-by: Yao Zi <ziyao@...root.org>
> >>> ---
> >>> .../bindings/clock/rockchip,rk3528-cru.yaml | 67 +++
> >>> .../dt-bindings/clock/rockchip,rk3528-cru.h | 453 ++++++++++++++++++
> >>> .../dt-bindings/reset/rockchip,rk3528-cru.h | 241 ++++++++++
> >>> 3 files changed, 761 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml
> >>> create mode 100644 include/dt-bindings/clock/rockchip,rk3528-cru.h
> >>> create mode 100644 include/dt-bindings/reset/rockchip,rk3528-cru.h
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml
> >>> new file mode 100644
> >>> index 000000000000..19dbda858172
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml
> >>> @@ -0,0 +1,67 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/clock/rockchip,rk3528-cru.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Rockchip RK3528 Clock and Reset Controller
> >>> +
> >>> +maintainers:
> >>> + - Yao Zi <ziyao@...root.org>
> >>> +
> >>> +description: |
> >>> + The RK3528 clock controller generates the clock and also implements a reset
> >>> + controller for SoC peripherals. For example, it provides SCLK_UART0 and
> >>> + PCLK_UART0 as well as SRST_P_UART0 and SRST_S_UART0 for the first UART
> >>> + module.
> >>> + Each clock is assigned an identifier, consumer nodes can use it to specify
> >>> + the clock. All available clock and reset IDs are defined in dt-binding
> >>> + headers.
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + const: rockchip,rk3528-cru
> >>> +
> >>> + reg:
> >>> + maxItems: 1
> >>> +
> >>> + assigned-clocks: true
> >>> +
> >>> + assigned-clock-rates: true
> >>
> >> Drop both, totally redundant.
> >
> > Okay, will fix in next version.
> >
> >>> +
> >>> + clocks:
> >>> + items:
> >>> + - description: External 24MHz oscillator clock
> >>> + - description: 50MHz clock generated by PHY module
> >>> +
> >>> + clock-names:
> >>> + items:
> >>> + - const: xin24m
> >>> + - const: gmac0
> >>
> >> gmac
> >> (unless you have gmac1 here as well but then please add it now)
> >
> > RK3528 comes with two onchip gmacs. This input clock is only used for
> > the first one and I think keeping the number would give the reader an
> > extra hint. What do you think about it?
> You don't get the point. What clock is from this module perspective? gmac.
I'm not sure what "from this module perspective" means. If it's about
the source of the input clock, it's also gmac0 and gmac1 has nothing to
do with it. Pointing this out explicitly brings us (and the later
reader) only extra information.
And in the previous series, Conor mentioned[1],
> clocks should be named after how they're used in the IP in question,
> not the name of the source of that clock in the SoC.
Since its usage is exactly to generate clocks required by gmac0, as
confirmed by Heiko, I consider gmac0 appropriate and am willing to
make its description more clear.
Further explanation will be appreciated, thanks for your review.
Best regards,
Yao Zi
[1]: https://lore.kernel.org/linux-rockchip/20241001-name-stooge-7a939f71a08e@spud/
Powered by blists - more mailing lists