[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3107512.vfdyTQepKt@diego>
Date: Fri, 01 Apr 2022 09:55:55 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Johan Jonker <jbx6244@...il.com>, zhangqing@...k-chips.com,
Stephen Boyd <sboyd@...nel.org>
Cc: robh+dt@...nel.org, krzk+dt@...nel.org, mturquette@...libre.com,
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 v3 1/2] dt-bindings: clock: convert rockchip,rk3188-cru.txt to YAML
Hi Stephen,
Am Freitag, 1. April 2022, 00:51:32 CEST schrieb Stephen Boyd:
> Quoting Johan Jonker (2022-03-29 04:13:22)
> > diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml
> > new file mode 100644
> > index 000000000..ddd7e46af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml
> > @@ -0,0 +1,78 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/rockchip,rk3188-cru.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip RK3188/RK3066 Clock and Reset Unit (CRU)
> > +
> > +maintainers:
> > + - Elaine Zhang <zhangqing@...k-chips.com>
> > + - Heiko Stuebner <heiko@...ech.de>
> > +
> > +description: |
> > + The RK3188/RK3066 clock controller generates and supplies clocks to various
> > + controllers within the SoC and also implements a reset controller for SoC
> > + peripherals.
> > + Each clock is assigned an identifier and client nodes can use this identifier
> > + to specify the clock which they consume. All available clocks are defined as
> > + preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
> > + dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
> > + Similar macros exist for the reset sources in these files.
> > + There are several clocks that are generated outside the SoC. It is expected
> > + that they are defined using standard clock bindings with following
> > + clock-output-names:
> > + - "xin24m" - crystal input - required
> > + - "xin32k" - RTC clock - optional
> > + - "xin27m" - 27mhz crystal input on RK3066 - optional
> > + - "ext_hsadc" - external HSADC clock - optional
> > + - "ext_cif0" - external camera clock - optional
> > + - "ext_rmii" - external RMII clock - optional
> > + - "ext_jtag" - external JTAG clock - optional
>
> I'd expect all these clks here to be inputs to this node.
The optional clocks are all part of a circular dependency.
So for example xin32k normally is generated by the pmic and fed
back into the system, so to get xin32k, we need the pmic to probe,
which needs i2c, which in turn already needs the clock controller.
Or optional clocks may not be available at all.
So for the past years we already relied on the clock-system's
self adaptation if a clock becomes available at some point
during later boot and hence do not have those in a clocks-property.
Heiko
Powered by blists - more mailing lists