Re: [PATCH v2 1/5] dt-bindings: clock: Document clock and reset unit of RK3528

["Heiko Stübner" <heiko@sntech.de>]

Am Donnerstag, 9. Januar 2025, 10:16:12 CET schrieb Yao Zi:
> 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@disroot.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@disroot.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

you could adjust the description to something like
	50MHz clock generated by PHY module only for gmac0
or so, to make it more clear where that signal goes to.

> > > +
> > > +  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?

I would agree here. Looking through the TRM registers, gmac0 gets _only_
supplied from that external input, while gmac1 only gets supplied from
a number of internal sources (different sources for gmac1-specific clocks)

Heiko