[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANAwSgQGoeyy3V9hBNcxFynRgR-rUanUzVN41uFxu0-_OqKKZg@mail.gmail.com>
Date: Wed, 10 Jul 2024 08:32:57 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Heiko Stuebner <heiko@...ech.de>
Cc: mturquette@...libre.com, sboyd@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, quentin.schulz@...rry.de,
linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH 0/6] Binding and driver for "dumb" clock generators
Hi Heiko,
On Tue, 9 Jul 2024 at 18:02, Heiko Stuebner <heiko@...ech.de> wrote:
>
> Rockchip boards with PCIe3 controllers inside the soc (rk3568, rk3588) have
> external clock generators on the board to generate the needed 100MHz
> reference clock the PCIe3 controller needs.
>
> Often these clock generators need supplies to be enabled to run.
>
> Modelling this clock has taken a number of shapes:
> - The rk3568 Rock-3a modelled the generator-regulator as "phy-supply" [0]
> &pcie30phy {
> phy-supply = <&vcc3v3_pi6c_03>;
> status = "okay";
> };
> which is of course not part of the binding
>
> - On the Rock-5-ITX the supply of the clock generator is controlled by
> the same gpio as the regulator supplying the the port connected to the
> pcie30x4 controller, so if this controller probes first, both
> controllers will just run. But if the pcie30x2 controller probes first
> (which has a different supply), the controller will stall at the first
> dbi read.
>
> - Recent Theobroma-Systems boards (Jaguar and Tiger) modelled their
> generator as a combination of fixed clock and gpio-gate, which works
> because the generator's vdd-supply is always on and only the output-
> enable pin needs to be toggled.
>
>
> So this series attempts to improve the situation by allowing to model
> these clock generators as actual entities in the devicetree, to not have
> them just accidentially work or break bindings.
>
I was wondering if these changes apply to Radxa Rock 5b SbC, it does not have
pi6c557 clock generator but the schematic supports GEN_CLK_100MHZ is
input to CLKin0 which is generated via the VCC3V3_PI6C_05 (100MHz,3.3V,3225)
regulator.
[1] https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock5b_v13_sch.pdf
Thanks
-Anand
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts#n605
>
> Heiko Stuebner (6):
> dt-bindings: clocks: add binding for generic clock-generators
> clk: add driver for generic clock generators
> arm64: dts: rockchip: fix the pcie clock generator on Rock 5 ITX
> arm64: dts: rockchip: use clock-generator for pcie-refclk on
> rk3588-jaguar
> arm64: dts: rockchip: use clock-generator for pcie-refclk on
> rk3588-tiger
> arm64: dts: rockchip: add pinctrl for clk-generator gpio on
> rk3588-tiger
>
> .../bindings/clock/clock-generator.yaml | 62 ++++++++
> .../arm64/boot/dts/rockchip/rk3588-jaguar.dts | 13 +-
> .../boot/dts/rockchip/rk3588-rock-5itx.dts | 34 ++++-
> .../arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 21 +--
> drivers/clk/Kconfig | 7 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-generator.c | 133 ++++++++++++++++++
> 7 files changed, 251 insertions(+), 20 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/clock-generator.yaml
> create mode 100644 drivers/clk/clk-generator.c
>
> --
> 2.39.2
>
>
Powered by blists - more mailing lists