From: Yixun Lan <dlan@kernel.org>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, linux-kernel@vger.kernel.org,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>
Subject: Re: [PATCH 1/4] riscv: dts: spacemit: k3: add clock tree
Date: Fri, 20 Mar 2026 18:03:09 +0800 [thread overview]
Message-ID: <20260320100309-GKC525649@kernel.org> (raw)
In-Reply-To: <b885158f-3859-4bfa-96b0-39c274a856cf@sifive.com>
Hi Samuel,
On 09:13 Sat 14 Mar , Samuel Holland wrote:
> Hi Yixun,
>
> On 2026-03-14 3:52 AM, Yixun Lan wrote:
> > On 20:44 Fri 13 Mar , Samuel Holland wrote:
> >> On 2026-03-04 1:36 AM, Yixun Lan wrote:
> >>> Add clock support to SpacemiT K3 SoC, the clock tree consist of several
> >>> blocks which are APBC, APMU, DCIU, MPUM.
> >>>
> >>> Signed-off-by: Yixun Lan <dlan@kernel.org>
> >>> ---
> >>> arch/riscv/boot/dts/spacemit/k3.dtsi | 75 ++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 75 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> >>> index b69cf81b5d55..e3d7f3102fd5 100644
> >>> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> >>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> >>> @@ -4,6 +4,7 @@
> >>> * Copyright (c) 2026 Guodong Xu <guodong@riscstar.com>
> >>> */
> >>>
> >>> +#include <dt-bindings/clock/spacemit,k3-clocks.h>
> >>> #include <dt-bindings/interrupt-controller/irq.h>
> >>>
> >>> /dts-v1/;
> >>> @@ -398,6 +399,36 @@ core3 {
> >>> };
> >>> };
> >>>
> >>> + clocks {
> >>> + vctcxo_1m: clock-1m {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <1000000>;
> >>> + clock-output-names = "vctcxo_1m";
> >>> + #clock-cells = <0>;
> >>> + };
> >>> +
> >>> + vctcxo_24m: clock-24m {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <24000000>;
> >>> + clock-output-names = "vctcxo_24m";
> >>> + #clock-cells = <0>;
> >>> + };
> >>> +
> >>> + vctcxo_3m: clock-3m {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <3000000>;
> >>> + clock-output-names = "vctcxo_3m";
> >>> + #clock-cells = <0>;
> >>> + };
> >>> +
> >>> + osc_32k: clock-32k {
> >>> + compatible = "fixed-clock";
> >>> + clock-frequency = <32000>;
> >>> + clock-output-names = "osc_32k";
> >>> + #clock-cells = <0>;
> >>> + };
> >>
> >> Are these clocks provided by SoC or by the board? Usually there's a crystal
> >> external to the SoC that provides the root of the clock tree. If these clocks
> >> are provided by the board, they (or at least the clock-frequency property)
> >> should be in the board DT, not the SoC dtsi.
> >>
> > It's true, as a quick check, osc_32k provided by P1 PMU, while vctcxo_24m is
> > a crystal, vctcxo_1m and vctcxo_3m are also marked as external in the clock
> > tree, but I would confirm them later..
>
> In that case, osc_32k should ideally be a reference to the P1 PMU clock
> provider, not a fixed-clock. But this may be infeasible if it creates dependency
> loops (PMU depends on I2C, I2C depends on clocks, clocks depend on PMU).
>
Yes, in an ideal case, not only there is dependency loop, but need to
implement a clock tree for P1..
Currently, I'd leave it as fixed-clock as is, since the 32k clock is
always on from P1 since power up
Also, for vctcxo_1m and vctcxo_3m, they are clocks derived from vctcxo_24m which
unable to be gate off, so I think it's ok to leave them as fixed-clock.
> > I agree to move them out of SoC dtsi file - k3.dtsi, while due to all boards share
> > the same clock topology, what if I creating a k3-clock.dtsi and making it shared
> > between all board dts file? to avoid massive DTS duplication
>
> Yes, it is common practice to create a .dtsi file for things shared among
> several boards for a SoC (for example if they are all based on a reference
> platform). You may want to name it something more generic if more than just
> clocks can be shared (like k3-common.dtsi, compare jh7110-common.dtsi).
>
k3-common.dtsi sounds good to me
> >> Also, the /clocks node is out of order.
> >>
> > I will move osc_32k before vtccxo_1m, assuming it's the problem you
> > refered to?
>
> I mean that /clocks sorts alphabetically before /cpus. Your ordering of the
> fixed-clocks nodes themselves is fine.
>
ok, I got
> Regards,
> Samuel
>
>
--
Yixun Lan (dlan)
next prev parent reply other threads:[~2026-03-20 10:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 7:36 [PATCH 0/4] riscv: spacemit: k3: Add more resource to UART Yixun Lan
2026-03-04 7:36 ` [PATCH 1/4] riscv: dts: spacemit: k3: add clock tree Yixun Lan
2026-03-14 1:44 ` Samuel Holland
2026-03-14 8:52 ` Yixun Lan
2026-03-14 14:13 ` Samuel Holland
2026-03-20 10:03 ` Yixun Lan [this message]
2026-03-04 7:36 ` [PATCH 2/4] riscv: dts: spacemit: k3: add pinctrl support Yixun Lan
2026-03-04 7:36 ` [PATCH 3/4] riscv: dts: spacemit: k3: add GPIO support Yixun Lan
2026-03-04 7:36 ` [PATCH 4/4] riscv: dts: spacemit: k3: add full resource to UART Yixun Lan
2026-03-13 13:26 ` [PATCH 0/4] riscv: spacemit: k3: Add more " Yixun Lan
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=20260320100309-GKC525649@kernel.org \
--to=dlan@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robh@kernel.org \
--cc=samuel.holland@sifive.com \
--cc=spacemit@lists.linux.dev \
/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