Hi,
I am sending version 3 of my zx297520v3 clock patch. The major change is
that I have merged the top and matrix clocks into one device because
the interface between them is unclear in the hardware.
There are still a few open questions though:
1) The clk-reset interaction: Both clocks and resets are in the same IO
space, sometimes in the same registers. I see a number of clk drivers
that register a reset control. I noticed Yu-Chun Lin's RTD1625 clock
submission added an aux device and placed the reset code in
drivers/reset instead. Is there a preference for either way or any
guideline of which way to use in which circumstances?
2) Unused clocks: I looked at recently introduced clk drivers
(mediatek,mt8196-clock.h, sun55i-a523-mcu-ccu.h) and they do add all a
lot of clocks that do not have an active consumer - which in a way means
unused ABI. Please let me know if you prefer to add clocks one by one as
their consumers are added.
That said, there are a lot of clocks that I want to define for the sole
purpose of shutting them off. The boot loader leaves pretty much every
device enabled, including proprietary timers that I don't even plan to
write a driver for. Registering their clocks in the kernel will allow
the kernel to shut them off, so they aren't entirely unused.
3) I took some naming from the old zx2967 code. In particular, each
device has two clocks: "WCLK" for the device operation and "PCLK" for
register access. Are there more standard names for them? Likewise I took
some device names from ZTE's downstream sources and I am open to better
suggestions.
My impression so far is that "PCLK" is fairly common. There is no agreed
name name prefix/suffix for the other clock. If anything, just nothing.
(i.e. "UART0_PCLK" and "UART0"). On prefix vs suffix, (PCLK_UART0 vs
UART0_PCLK) the existing drivers seem to be all over the place.
4) I took care to test unbinding and rebinding my clock driver to the
hardware and also tested building it as a module - but in practise, the
board will be pretty useless without the clock driver and I have to jump
through some hoops to even test it. Should I even bother, or just set
suppress_bind_attrs = true and make the config a boolean?
Wrt clock name strings vs struct clk / clk_hw pointers for parents:
Using string names seems like the only viable choice in practise.
I think the list of clocks in my driver is fairly complete; It is
certainly a lot better than what the downstream ZTE drivers have. I
deduced a lot of it by trial and error. I am sure there are some clocks
missing that will need to be added to the binding later. Afaiu adding
clocks is not an issue, but removing or reordering them is an ABI break.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
v2: Fix build issues introduced by checkpatch.pl fixes that I didn't
spot earlier.
Changes in v3:
Model top and matrix clocks as one device
Add PLL driver
Fixed a few issues found by Sashiko: register lock, some missing devm_,
error handling
---
Stefan Dösinger (5):
dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings.
dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings.
clk: zte: Introduce a driver for zx297520v3 top clocks and resets.
clk: zte: Introduce a driver for zx297520v3 LSP clocks and resets.
ARM: dts: zte: Declare a zx297520v3 clock device nodes
.../bindings/clock/zte,zx297520v3-lspclk.yaml | 119 +++
.../bindings/clock/zte,zx297520v3-topclk.yaml | 95 ++
MAINTAINERS | 3 +
arch/arm/boot/dts/zte/zx297520v3.dtsi | 55 +-
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/zte/Kconfig | 18 +
drivers/clk/zte/Makefile | 5 +
drivers/clk/zte/clk-zx297520v3.c | 1003 ++++++++++++++++++++
drivers/clk/zte/pll.c | 450 +++++++++
drivers/clk/zte/pll.h | 23 +
include/dt-bindings/clock/zte,zx297520v3-clk.h | 179 ++++
12 files changed, 1944 insertions(+), 8 deletions(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260510-zx29clk-2e4d39e3128c
Best regards,
--
Stefan Dösinger <stefandoesinger@gmail.com>