From: Conor Dooley <conor@kernel.org>
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: 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>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset bindings
Date: Wed, 17 Jun 2026 17:11:20 +0100 [thread overview]
Message-ID: <20260617-camcorder-profile-03c1b89b8a1c@spud> (raw)
In-Reply-To: <20260616-zx29clk-v4-2-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]
On Tue, Jun 16, 2026 at 11:26:22PM +0300, Stefan Dösinger wrote:
> I 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.
This type of commentary FWIW can go below the --- line and instead just
write a normal commit message.
I do appreciate though that you put the information in the individual
patch.
> The syscon is used to generate the regmap shared between the clock and
> auxiliary reset drivers. The register space also contains at least one
> extra block of functionality, hardware spinlocks, that I expect will be
> necessary to communicate correctly with the LTE DSP firmware blob.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + topclk: clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
This should be removed from here, the tooling will satisfy the topclk
references, just as it has done for osc26m and osc32k. The example
should just contain the node the binding documents (and its children).
pw-bot: changes-requested
Looks fine otherwise.
Cheers,
Conor.
> +
> + clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-06-17 16:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 20:26 [PATCH RFC v4 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-06-16 20:26 ` [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings Stefan Dösinger
2026-06-16 20:32 ` sashiko-bot
2026-06-17 16:08 ` Conor Dooley
2026-06-17 17:47 ` Stefan Dösinger
2026-06-16 20:26 ` [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-06-17 16:11 ` Conor Dooley [this message]
2026-06-16 20:26 ` [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-06-16 20:34 ` sashiko-bot
2026-06-17 16:12 ` Conor Dooley
2026-06-16 20:26 ` [PATCH RFC v4 04/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-06-16 20:38 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 05/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-06-16 20:43 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 06/12] clk: zte: Add regmap based clocks Stefan Dösinger
2026-06-16 20:39 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 07/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-06-16 20:43 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 08/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-06-16 20:37 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 09/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-06-16 20:38 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-06-16 20:26 ` [PATCH RFC v4 11/12] ARM: dts: zte: Declare zx297520v3 clock device nodes Stefan Dösinger
2026-06-16 20:38 ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 12/12] ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards Stefan Dösinger
2026-06-16 20:42 ` sashiko-bot
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=20260617-camcorder-profile-03c1b89b8a1c@spud \
--to=conor@kernel.org \
--cc=bmasney@redhat.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 \
--cc=stefandoesinger@gmail.com \
/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