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>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"Stefan Dösinger" <stefandoesinger@gmail.com>
Subject: [PATCH RFC v2 4/4] clk: zte: Introduce a driver for zx297520v3 LSP clocks and resets.
Date: Mon, 11 May 2026 00:49:53 +0300 [thread overview]
Message-ID: <20260511-zx29clk-v2-4-29f0edc300f5@gmail.com> (raw)
In-Reply-To: <20260511-zx29clk-v2-0-29f0edc300f5@gmail.com>
"LSP" is ZTE's term for this part of the SoC, I suspect it stands for
"low speed peripherals". The main UART is here, together with the flash
controller and more surplus proprietary timers.
It also has two more I2C controllers that supposedly connect to a
battery charger, SPI for displays and I2S for analog telephones. The
boards I have don't have any of these components though.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/clk/zte/clk-zx297520v3.c | 183 +++++++++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
index d4b683cb6354..05b02c8f266b 100644
--- a/drivers/clk/zte/clk-zx297520v3.c
+++ b/drivers/clk/zte/clk-zx297520v3.c
@@ -791,6 +791,189 @@ static struct platform_driver clk_zx297520v3_matrixclk = {
};
module_platform_driver(clk_zx297520v3_matrixclk);
+/* LSP clock entries have a common pattern: Bit 0 for PCLK, Bit 1 for WCLK. Bit 4 (and sometimes
+ * more) for WCLK mux.
+ *
+ * Bit 8 and 9 are reset bits. I don't know the difference between the two, but they both
+ * need to be set to deassert the reset.
+ *
+ * Bits 12-16 can be a divisor, but not all clocks have it. Some clocks have a divisor in 16-20.
+ *
+ * The ID given in this table is the first register in the device's MMIO space. ZTE's drivers
+ * usually call this a version register, but it looks more like a device identifier.
+ *
+ * It looks like the registers map to devices like this:
+ *
+ * Timer reg function div dev offset(lsp + xxxx) ID
+ * 0x0: Read-only, probably device identifier 0x00752100
+ * 0x4: timer_l1 Y 0x1000 0x02020000
+ * 0x8: watchdog_l2 Y 0x2000 0x02020000
+ * 0xc: watchdog_l3 Y 0x3000 0x02020000
+ * 0x10: i2c1 N 0x4000 0x01020000
+ * 0x14: i2s0 Yh 0x5000 0x01030000
+ * 0x18: always 0 N -
+ * 0x1c: i2s1 Yh 0x6000 0x01030000
+ * 0x20: always 0 N -
+ * 0x24: qspi N 0x7000 0x01040000
+ * 0x28: uart1 N 0x8000 0x01060000
+ * 0x2c: i2c2 N 0x9000 0x01020000
+ * 0x30: spi0 Y 0xa000 0x01040000
+ * 0x34: timer_lb Y 0xb000 0x02020000
+ * 0x38: timer_lc Y 0xc000 0x02020000
+ * 0x3c: uart2 N 0xd000 0x01060000
+ * 0x40: watchdog_le Y 0xe000 0x02020000
+ * 0x44: timer_lf Y 0xf000 0x02020000
+ * 0x48: spi1 Y 0x10000 0x01040000
+ * 0x4c: timer_l11 Y 0x11000 0x02020000
+ * 0x50: tdm Y 0x12000 0x01040000
+ *
+ * Registers 0x58, 0x5c, 0x60, 0x64, 0x68 seem to contain more controls for i2s and tdm.
+ */
+
+static const char * const timer_lsp_sel[] = {
+ "lsp_osc32k",
+ "lsp_osc26m",
+};
+
+static const char * const uart_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d6",
+};
+
+static const char * const i2s_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_dpll_d4",
+ "lsp_mpll_d6",
+ /* Unknown */
+};
+
+static const char * const tdm_lsp_sel[] = {
+ "lsp_tdm_wclk",
+};
+
+static const char * const spi_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d4",
+ "lsp_mpll_d6",
+ /* Unknown */
+};
+
+static const char * const qspi_lsp_sel[] = {
+ "lsp_osc26m",
+ "lsp_mpll_d4",
+ "lsp_mpll_d5",
+ "lsp_mpll_d6",
+ "lsp_mpll_d8",
+ "lsp_mpll_d12",
+ "lsp_osc26m",
+ "lsp_osc26m",
+};
+
+#define LSP_CLOCK(offset, name, mux, div_shift, div_size) {\
+ ZX297520V3_##name##_RESET, ZX297520V3_##name##_WCLK, ZX297520V3_##name##_PCLK,\
+ #name, offset, 8, offset, 0, 1, "lsp_pclk", offset, 4, 4, mux, ARRAY_SIZE(mux),\
+ offset, div_shift, div_size, 0}
+
+static const struct zx297520v3_composite lsp_clocks[] = {
+ LSP_CLOCK(0x4, TIMER_L1, timer_lsp_sel, 0, 0),
+ LSP_CLOCK(0x8, WDT_L2, timer_lsp_sel, 0, 0),
+ LSP_CLOCK(0xc, WDT_L3, timer_lsp_sel, 0, 0),
+ LSP_CLOCK(0x10, I2C1, uart_lsp_sel, 0, 0),
+ LSP_CLOCK(0x14, I2S0, i2s_lsp_sel, 16, 4),
+ LSP_CLOCK(0x1c, I2S1, i2s_lsp_sel, 16, 4),
+ LSP_CLOCK(0x24, QSPI, qspi_lsp_sel, 0, 0),
+ LSP_CLOCK(0x28, UART1, uart_lsp_sel, 0, 0),
+ LSP_CLOCK(0x2C, I2C2, uart_lsp_sel, 0, 0),
+ LSP_CLOCK(0x30, SPI0, spi_lsp_sel, 12, 4),
+ LSP_CLOCK(0x34, TIMER_LB, timer_lsp_sel, 12, 4),
+ LSP_CLOCK(0x38, TIMER_LC, timer_lsp_sel, 12, 4),
+ LSP_CLOCK(0x3c, UART2, uart_lsp_sel, 0, 0),
+ LSP_CLOCK(0x40, WDT_LE, timer_lsp_sel, 12, 4),
+ LSP_CLOCK(0x44, TIMER_LF, timer_lsp_sel, 12, 4),
+ LSP_CLOCK(0x48, SPI1, spi_lsp_sel, 12, 4),
+ LSP_CLOCK(0x4c, TIMER_L11, timer_lsp_sel, 12, 4),
+ LSP_CLOCK(0x50, TDM, tdm_lsp_sel, 16, 4),
+};
+
+#undef LSP_CLOCK
+
+static int zx297520_lspclk_probe(struct platform_device *pdev)
+{
+ static const char * const parent_names[] = { "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8",
+ "mpll_d12", "osc26m", "osc32k", "pclk" };
+
+ struct zx29_clk_controller *lsp;
+ struct device *dev = &pdev->dev;
+ struct clk *parent;
+ unsigned int i;
+ int res;
+
+ dev_info(dev, "Registering zx297520v3 LSP clocks and resets\n");
+
+ lsp = devm_kzalloc(dev, offsetof(struct zx29_clk_controller,
+ resets[ZX297520V3_LSPRST_END]), GFP_KERNEL);
+ if (!lsp)
+ return -ENOMEM;
+
+ lsp->clocks = devm_kzalloc(dev, struct_size(lsp->clocks, hws,
+ ZX297520V3_LSPCLK_END), GFP_KERNEL);
+ if (!lsp->clocks)
+ return -ENOMEM;
+ lsp->clocks->num = ZX297520V3_LSPCLK_END;
+
+ lsp->base = devm_platform_ioremap_resource(pdev, 0);
+ WARN_ON(!lsp->base);
+
+ /* TODO: Technically we can disable the pclk if all LSP devices are shut down, but that
+ * needs custom clk ops to tiptoe around a disabled LSP pclk before attempting to access
+ * the actual clock. In normal operation it is unlikely that all LSP devices are shut down
+ * simultaneously though as UART and NAND are located here.
+ */
+ parent = devm_clk_get_enabled(dev, "pclk");
+ if (IS_ERR(parent)) {
+ dev_err(dev, "failed to find lsp pclk\n");
+ return PTR_ERR(parent);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(parent_names); ++i) {
+ parent = devm_clk_get(dev, parent_names[i]);
+ if (IS_ERR(parent)) {
+ dev_err(dev, "failed to find lsp %s clock\n", parent_names[i]);
+ return PTR_ERR(parent);
+ }
+ }
+
+ res = zx297520v3_composite(dev, lsp->base, lsp->clocks, lsp->resets,
+ lsp_clocks, ARRAY_SIZE(lsp_clocks));
+ if (res)
+ return res;
+
+ res = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get, lsp->clocks);
+ if (res)
+ return res;
+
+ lsp->rcdev.owner = THIS_MODULE;
+ lsp->rcdev.nr_resets = ZX297520V3_LSPRST_END;
+ lsp->rcdev.ops = &zx297520v3_rst_ops;
+ lsp->rcdev.of_node = dev->of_node;
+ return devm_reset_controller_register(dev, &lsp->rcdev);
+}
+
+static const struct of_device_id of_match_zx297520v3_lspclk[] = {
+ { .compatible = "zte,zx297520v3-lspclk"},
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_match_zx297520v3_lspclk);
+
+static struct platform_driver zx297520v3_lspclk = {
+ .probe = zx297520_lspclk_probe,
+ .driver = {
+ .name = "clk-zx297520v3-lspclk",
+ .of_match_table = of_match_zx297520v3_lspclk,
+ },
+};
+module_platform_driver(zx297520v3_lspclk);
+
MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
MODULE_DESCRIPTION("ZTE zx297520v3 clock driver");
MODULE_LICENSE("GPL");
--
2.53.0
prev parent reply other threads:[~2026-05-10 21:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 21:49 [PATCH RFC v2 0/4] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-05-10 21:49 ` [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings Stefan Dösinger
2026-05-10 21:49 ` [PATCH RFC v2 2/4] clk: zte: Introduce a driver for zx297520v3 top clocks and resets Stefan Dösinger
2026-05-10 21:49 ` [PATCH RFC v2 3/4] clk: zte: Introduce a driver for zx297520v3 matrix " Stefan Dösinger
2026-05-10 21:49 ` Stefan Dösinger [this message]
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=20260511-zx29clk-v2-4-29f0edc300f5@gmail.com \
--to=stefandoesinger@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@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