From: "Stefan Dösinger" <stefandoesinger@gmail.com>
To: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Brian Masney <bmasney@redhat.com>, Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Russell King <linux@armlinux.org.uk>, Lee Jones <lee@kernel.org>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, mfd@lists.linux.dev,
"Stefan Dösinger" <stefandoesinger@gmail.com>
Subject: [PATCH v8 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller
Date: Mon, 27 Jul 2026 21:24:17 +0300 [thread overview]
Message-ID: <20260727-zx29clk-v8-2-7a107b00f1dd@gmail.com> (raw)
In-Reply-To: <20260727-zx29clk-v8-0-7a107b00f1dd@gmail.com>
This controller contains clocks and resets for high speed devices on the
zx297520v3 board and hardware spinlocks that I expect will be necessary
to communicate correctly with the LTE DSP firmware blob.
I don't know much about the hwlocks yet other than that they exist, so
there is no header yet adding meaning to their indices. Presumably that
meaning doesn't exist in hardware and is de facto defined by ZTE's
firmware blobs running on the rprocs.
The zte-zx297520v3-crm driver will instantiate separate MFD children for
clocks and resets, which are handled by separate clock and reset
drivers.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
v7->v8:
*) Start clock indices at 0
*) Fix indentation
*) Add a prose note about discovered registers that allow writing
CNTVAL. I am not exposing them in any way because for now I see no need
to use this functionality. It is possible that the counter resets to 0
during standby, which means someone needs to fix it up using those
registers.
Nevertheless, no syscon yet for these reasons: I have no idea how CNTVAL
behaves during standby. It might be just fine. Standby very likely needs
firmware handling running on the Cortex M0, which can restore CNTVAL if
necessary. If Linux needs to do it, it can probably be done by the clock
or MFD parent driver. Given what I've learned so far I'd rather add
syscon later than put it in place without a clear user.
Details of how to manipulate CNTVAL will be in the matrix clk driver.
*) A non-change in the binding text, but worth mentioning: Register
0x118 contains gates that gate off matrix-synthesized PLL fixed
dividers. They reinforce the understanding of the top->matrix interface
and the adequacy of the bindings.
v6->v7:
*) Moved it back to clock/
*) Remove syscon compatible again. I looked into remaining unknown
registers and I am convinced that there is no odd misc register left
that can't be exposed as a proper subsystem provider.
The controls in 0x100 that ZTE's DRAM reading code exercises are auto
clock gating controls and the actual mailbox is in a different
controller.
Unknown registers in 0x120-0x12c are a frequency voting mechanism for
the AXI bus clock. The driver will participate in that voting rather
than set the frequency via 0x0. If need be it could be exposed
as #interconnect-cells, but it won't necessitate "syscon".
*) Reduce the number of input clocks to match register controls in
topclk's input control that affect matrix and LSP.
*) Add DDR mux and gates. Not to change them, but to make sure CCF knows
about which PLL is feeding the sysmem memory
Changes
v5->v6:
Add syscon compatible - Conor suggested this after v4 and I forgot it in v5.
v4->v5:
Move binding to soc/zte
Remove topclk from the example
Add #hwlock-cells for hw spinlock registers
Add more clocks I stumbled into: sram0 and another LTE related device
v3->v4:
Split matrixclk into its own controller again because syscon/regmap
deals poorly with device nodes that have more than one memory region. As
a consequence I am passing all PLL outputs generated on Topclk down to
Matrixclk.
---
.../bindings/clock/zte,zx297520v3-matrixcrm.yaml | 96 ++++++++++++++++++++++
MAINTAINERS | 1 +
include/dt-bindings/clock/zte,zx297520v3-clk.h | 41 +++++++++
include/dt-bindings/reset/zte,zx297520v3-reset.h | 12 +++
4 files changed, 150 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-matrixcrm.yaml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-matrixcrm.yaml
new file mode 100644
index 000000000000..d96f9f374447
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-matrixcrm.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/zte,zx297520v3-matrixcrm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx297520v3 SoC matrix clock and reset controller
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+description: |
+ This controller contains clock and reset controls for high speed devices on
+ the zx297520v3 board: The CPU, RAM, SDIO and Ethernet clocks and resets are
+ found here. This controller requires PLL-generated clocks from Topcrm as well
+ as the fixed 26 MHz and 32 kHz oscillators found on this board.
+
+ This controller also contains hardware mutex registers for synchronization
+ with different processors on this board.
+
+ An additional curiosity are registers that allow setting (but not reading) the
+ ARM architected timer's CNTVAL. This is not exposed in the binding because
+ there shouldn't be a need to access it.
+
+ All available clocks are defined as preprocessor macros in the
+ "include/dt-bindings/clock/zte,zx297520v3-clk.h" header. Resets are defined in
+ the "include/dt-bindings/reset/zte,zx297520v3-reset.h" header.
+
+properties:
+ compatible:
+ const: zte,zx297520v3-matrixcrm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: 26 MHz external oscillator
+ - description: 32 kHz external oscillator
+ - description: Main PLL output from topcrm (usually 624 MHz)
+ - description: Main PLL subdivision factor 5
+ - description: Dpll output from topcrm (usually 491.52 MHz)
+ - description: Gpll output from topcrm (usually 200 MHz)
+ - description: Gpll subdivision factor 2
+ - description: osc26m work clock from topcrm
+
+ clock-names:
+ items:
+ - const: osc26m
+ - const: osc32k
+ - const: mpll
+ - const: mpll-d5
+ - const: dpll
+ - const: gpll
+ - const: gpll-d2
+ - const: wclk-osc26m
+
+ "#clock-cells":
+ const: 1
+
+ "#hwlock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - "#hwlock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/zte,zx297520v3-clk.h>
+ #include <dt-bindings/reset/zte,zx297520v3-reset.h>
+
+ clock-controller@1306000 {
+ compatible = "zte,zx297520v3-matrixcrm";
+ reg = <0x01306000 0x400>;
+ clocks = <&osc26m>, <&osc32k>,
+ <&topcrm ZX297520V3_MPLL>, <&topcrm ZX297520V3_MPLL_D5>,
+ <&topcrm ZX297520V3_DPLL>, <&topcrm ZX297520V3_GPLL>,
+ <&topcrm ZX297520V3_GPLL_D2>,
+ <&topcrm ZX297520V3_GATED_OSC26M>;
+ clock-names = "osc26m", "osc32k", "mpll", "mpll-d5", "dpll", "gpll",
+ "gpll-d2", "wclk-osc26m";
+ #clock-cells = <1>;
+ #hwlock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 36619a9ff8fc..dc2972ade70f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3878,6 +3878,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Odd fixes
F: Documentation/arch/arm/zte/
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: Documentation/devicetree/bindings/clock/zte,zx297520v3-matrixcrm.yaml
F: Documentation/devicetree/bindings/clock/zte,zx297520v3-topcrm.yaml
F: arch/arm/boot/dts/zte/
F: arch/arm/mach-zte/
diff --git a/include/dt-bindings/clock/zte,zx297520v3-clk.h b/include/dt-bindings/clock/zte,zx297520v3-clk.h
index 3aed94ccc26f..a8477e9b2a14 100644
--- a/include/dt-bindings/clock/zte,zx297520v3-clk.h
+++ b/include/dt-bindings/clock/zte,zx297520v3-clk.h
@@ -63,4 +63,45 @@
#define ZX297520V3_HSIC_WCLK 54
#define ZX297520V3_HSIC_PCLK 55
+#define ZX297520V3_SYS_TIMER_WCLK 0
+#define ZX297520V3_CPU_WCLK 1
+#define ZX297520V3_CPU_PCLK 2
+#define ZX297520V3_ZSP_WCLK 3
+#define ZX297520V3_DDR_CTRL_PCLK 4
+#define ZX297520V3_DDR_CTRL_WCLK 5
+#define ZX297520V3_EDCP_WCLK 6
+#define ZX297520V3_EDCP_PCLK 7
+#define ZX297520V3_SD0_WCLK 8
+#define ZX297520V3_SD0_PCLK 9
+#define ZX297520V3_SD0_CDET 10
+#define ZX297520V3_SD1_WCLK 11
+#define ZX297520V3_SD1_PCLK 12
+#define ZX297520V3_SD1_CDET 13
+#define ZX297520V3_NAND_WCLK 14
+#define ZX297520V3_NAND_PCLK 15
+#define ZX297520V3_DMA_PCLK 16
+#define ZX297520V3_MBOX_PCLK 17
+#define ZX297520V3_PDCFG_WCLK 18
+#define ZX297520V3_PDCFG_PCLK 19
+#define ZX297520V3_SSC_WCLK 20
+#define ZX297520V3_SSC_PCLK 21
+#define ZX297520V3_AXI_WCLK 22
+#define ZX297520V3_GMAC_WCLK 23
+#define ZX297520V3_GMAC_PCLK 24
+#define ZX297520V3_GMAC_AHB 25
+#define ZX297520V3_VOU_WCLK 26
+#define ZX297520V3_VOU_PCLK 27
+#define ZX297520V3_LSP_MPLL_D5_WCLK 28
+#define ZX297520V3_LSP_MPLL_D4_WCLK 29
+#define ZX297520V3_LSP_MPLL_D6_WCLK 30
+#define ZX297520V3_LSP_MPLL_D8_WCLK 31
+#define ZX297520V3_LSP_MPLL_D12_WCLK 32
+#define ZX297520V3_LSP_OSC26M_WCLK 33
+#define ZX297520V3_LSP_OSC32K_WCLK 34
+#define ZX297520V3_LSP_PCLK 35
+#define ZX297520V3_LSP_TDM_WCLK 36
+#define ZX297520V3_LSP_DPLL_D4_WCLK 37
+#define ZX297520V3_SRAM0_PCLK 38
+#define ZX297520V3_GSM_CFG_PCLK 39
+
#endif /* __DT_BINDINGS_CLOCK_ZX297520V3_H */
diff --git a/include/dt-bindings/reset/zte,zx297520v3-reset.h b/include/dt-bindings/reset/zte,zx297520v3-reset.h
index 43db72bb59de..4682d4a599c6 100644
--- a/include/dt-bindings/reset/zte,zx297520v3-reset.h
+++ b/include/dt-bindings/reset/zte,zx297520v3-reset.h
@@ -29,4 +29,16 @@
#define ZX297520V3_HSIC_PHY_RESET 20
#define ZX297520V3_HSIC_RESET 21
+#define ZX297520V3_CPU_RESET 0
+#define ZX297520V3_DDR_CTRL_RESET 1
+#define ZX297520V3_EDCP_RESET 2
+#define ZX297520V3_SD0_RESET 3
+#define ZX297520V3_SD1_RESET 4
+#define ZX297520V3_NAND_RESET 5
+#define ZX297520V3_PDCFG_RESET 6
+#define ZX297520V3_SSC_RESET 7
+#define ZX297520V3_GMAC_RESET 8
+#define ZX297520V3_VOU_RESET 9
+#define ZX297520V3_LSP_RESET 10
+
#endif /* __DT_BINDINGS_RESET_ZX297520V3_H */
--
2.54.0
next prev parent reply other threads:[~2026-07-27 18:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 18:24 [PATCH v8 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller Stefan Dösinger
2026-07-28 6:27 ` Krzysztof Kozlowski
2026-07-27 18:24 ` Stefan Dösinger [this message]
2026-07-28 6:31 ` [PATCH v8 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix " Krzysztof Kozlowski
2026-07-27 18:24 ` [PATCH v8 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 04/12] mfd: zx297520v3: Add a clock and reset MFD driver Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 05/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-07-28 13:38 ` Brian Masney
2026-07-28 13:53 ` Brian Masney
2026-07-27 18:24 ` [PATCH v8 06/12] clk: zte: Add regmap-based clocks Stefan Dösinger
2026-07-28 13:42 ` Brian Masney
2026-07-27 18:24 ` [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 09/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 10/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 11/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 12/12] ARM: dts: zte: Declare zx297520v3 CRM device nodes Stefan Dösinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260727-zx29clk-v8-2-7a107b00f1dd@gmail.com \
--to=stefandoesinger@gmail.com \
--cc=bmasney@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mfd@lists.linux.dev \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox