Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h
diff --git a/include/dt-bindings/clock/amlogic,t7-scmi.h b/include/dt-bindings/clock/amlogic,t7-scmi.h
new file mode 100644
index 000000000000..27bd257bd4ea
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,t7-scmi.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
+/*
+ * Copyright (C) 2024-2025 Amlogic, Inc. All rights reserved
+ */
+
+#ifndef __T7_SCMI_CLKC_H
+#define __T7_SCMI_CLKC_H
+
+#define CLKID_DDR_PLL_OSC 0
+#define CLKID_AUD_PLL_OSC 1
+#define CLKID_TOP_PLL_OSC 2
+#define CLKID_TCON_PLL_OSC 3
+#define CLKID_USB_PLL0_OSC 4
+#define CLKID_USB_PLL1_OSC 5
+#define CLKID_MCLK_PLL_OSC 6
+#define CLKID_PCIE_OSC 7
+#define CLKID_ETH_PLL_OSC 8
+#define CLKID_PCIE_REFCLK_PLL_OSC 9
+#define CLKID_EARC_OSC 10
+#define CLKID_SYS1_PLL_OSC 11
+#define CLKID_HDMI_PLL_OSC 12
+#define CLKID_SYS_CLK 13
+#define CLKID_AXI_CLK 14
+#define CLKID_FIXED_PLL_DCO 15
+#define CLKID_FIXED_PLL 16
+#define CLKID_FCLK_DIV2_DIV 17
+#define CLKID_FCLK_DIV2 18
+#define CLKID_FCLK_DIV2P5_DIV 19
+#define CLKID_FCLK_DIV2P5 20
+#define CLKID_FCLK_DIV3_DIV 21
+#define CLKID_FCLK_DIV3 22
+#define CLKID_FCLK_DIV4_DIV 23
+#define CLKID_FCLK_DIV4 24
+#define CLKID_FCLK_DIV5_DIV 25
+#define CLKID_FCLK_DIV5 26
+#define CLKID_FCLK_DIV7_DIV 27
+#define CLKID_FCLK_DIV7 28
+#define CLKID_FCLK_50M_DIV 29
+#define CLKID_FCLK_50M 30
+#define CLKID_CPU_CLK 31
+#define CLKID_A73_CLK 32
+#define CLKID_CPU_CLK_DIV16_DIV 33
+#define CLKID_CPU_CLK_DIV16 34
+#define CLKID_A73_CLK_DIV16_DIV 35
+#define CLKID_A73_CLK_DIV16 36
+
+#endif /* __T7_SCMI_CLKC_H */
--
2.47.1On Thu, Dec 04, 2025 at 01:36:31PM +0800, Jian Hu wrote: > Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family. > > Signed-off-by: Jian Hu <jian.hu@amlogic.com> > Acked-by: Rob Herring (Arm) <robh@kernel.org> > --- > include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h > Where is any binding doc for this? Why is this a separate patch? Best regards, Krzysztof
Hi, Krzysztof Thans for your review. On 12/8/2025 2:17 PM, Krzysztof Kozlowski wrote: > [ EXTERNAL EMAIL ] > > On Thu, Dec 04, 2025 at 01:36:31PM +0800, Jian Hu wrote: >> Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family. >> >> Signed-off-by: Jian Hu <jian.hu@amlogic.com> >> Acked-by: Rob Herring (Arm) <robh@kernel.org> >> --- >> include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++ >> 1 file changed, 47 insertions(+) >> create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h >> > Where is any binding doc for this? Why is this a separate patch? The ARM SCMI device tree binding specification is located at ./Documentation/devicetree/bindings/firmware/arm,scmi.yaml. Certain secure clocks on the T7 rely on the ARM SCMI driver stack, which is officially supported by ARM. The kernel-side SCMI client implementation resides in ./drivers/firmware/arm_scmi/. To enable ARM SCMI on T7, three components are needed: - Kernel-side definition of ARM SCMI clock indices (this patch addresses this component); - SCMI server implementation in the ARM Trusted Firmware (ATF) running at Exception Level 3 (EL3), which has been integrated into the bootloader; - Device Tree Source (DTS) configuration for ARM SCMI clock nodes (the DTS changes will be submitted after the T7 clock driver patches are merged upstream). > > Best regards, > Krzysztof >
On 08/12/2025 09:40, Jian Hu wrote: > Hi, Krzysztof > > > Thans for your review. > > On 12/8/2025 2:17 PM, Krzysztof Kozlowski wrote: >> [ EXTERNAL EMAIL ] >> >> On Thu, Dec 04, 2025 at 01:36:31PM +0800, Jian Hu wrote: >>> Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family. >>> >>> Signed-off-by: Jian Hu <jian.hu@amlogic.com> >>> Acked-by: Rob Herring (Arm) <robh@kernel.org> >>> --- >>> include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++ >>> 1 file changed, 47 insertions(+) >>> create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h >>> >> Where is any binding doc for this? Why is this a separate patch? > > > The ARM SCMI device tree binding specification is located at > ./Documentation/devicetree/bindings/firmware/arm,scmi.yaml. Then git grep for the file name - there is no such compatible. Are you sure you follow writing bindings doc? Think how are you going to use these values. You will have phandle, yes? To some controller, yes? Which one? > > Certain secure clocks on the T7 rely on the ARM SCMI driver stack, which > is officially supported by ARM. > > The kernel-side SCMI client implementation resides in > ./drivers/firmware/arm_scmi/. > > To enable ARM SCMI on T7, three components are needed: > > - Kernel-side definition of ARM SCMI clock indices (this patch addresses > this component); > - SCMI server implementation in the ARM Trusted Firmware (ATF) running > at Exception Level 3 (EL3), which has been integrated into the bootloader; > - Device Tree Source (DTS) configuration for ARM SCMI clock nodes (the > DTS changes will be submitted after the T7 clock driver patches are > merged upstream). So silently you keep the users hidden? No, I want to see the users. Best regards, Krzysztof
On Tue 09 Dec 2025 at 07:01, Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 08/12/2025 09:40, Jian Hu wrote: >> Hi, Krzysztof >> >> >> Thans for your review. >> >> On 12/8/2025 2:17 PM, Krzysztof Kozlowski wrote: >>> [ EXTERNAL EMAIL ] >>> >>> On Thu, Dec 04, 2025 at 01:36:31PM +0800, Jian Hu wrote: >>>> Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family. >>>> >>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com> >>>> Acked-by: Rob Herring (Arm) <robh@kernel.org> >>>> --- >>>> include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++ >>>> 1 file changed, 47 insertions(+) >>>> create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h >>>> >>> Where is any binding doc for this? Why is this a separate patch? >> >> >> The ARM SCMI device tree binding specification is located at >> ./Documentation/devicetree/bindings/firmware/arm,scmi.yaml. > > Then git grep for the file name - there is no such compatible. Are you > sure you follow writing bindings doc? > > Think how are you going to use these values. You will have phandle, yes? > To some controller, yes? Which one? For the C3 (I believe the T7 is the same), the compatible being used is "arm,scmi-smc". It is a generic one documented here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml?h=v6.18#n202 The phandle used is a subnode of that, to clock protocol: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi?h=v6.18#n116 Same things is done on imx, stm and rockchip platforms from what I can see. Jian is just adding the arbitrary IDs used to identify the clocks in the FW. I don't think there is anything out of the ordirnary here. Is there something else Rob and I missed reviewing this ? > >> >> Certain secure clocks on the T7 rely on the ARM SCMI driver stack, which >> is officially supported by ARM. >> >> The kernel-side SCMI client implementation resides in >> ./drivers/firmware/arm_scmi/. >> >> To enable ARM SCMI on T7, three components are needed: >> >> - Kernel-side definition of ARM SCMI clock indices (this patch addresses >> this component); >> - SCMI server implementation in the ARM Trusted Firmware (ATF) running >> at Exception Level 3 (EL3), which has been integrated into the bootloader; >> - Device Tree Source (DTS) configuration for ARM SCMI clock nodes (the >> DTS changes will be submitted after the T7 clock driver patches are >> merged upstream). > > So silently you keep the users hidden? No, I want to see the users. > Is there a new requirement to submit the DTS file changes along with the driver changes now ? This has never been case before, especially since the changes are merged through different trees. > > Best regards, > Krzysztof -- Jerome
On 09/12/2025 11:16, Jerome Brunet wrote: > On Tue 09 Dec 2025 at 07:01, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> On 08/12/2025 09:40, Jian Hu wrote: >>> Hi, Krzysztof >>> >>> >>> Thans for your review. >>> >>> On 12/8/2025 2:17 PM, Krzysztof Kozlowski wrote: >>>> [ EXTERNAL EMAIL ] >>>> >>>> On Thu, Dec 04, 2025 at 01:36:31PM +0800, Jian Hu wrote: >>>>> Add DT bindings for the SCMI clock controller of the Amlogic T7 SoC family. >>>>> >>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com> >>>>> Acked-by: Rob Herring (Arm) <robh@kernel.org> >>>>> --- >>>>> include/dt-bindings/clock/amlogic,t7-scmi.h | 47 +++++++++++++++++++++ >>>>> 1 file changed, 47 insertions(+) >>>>> create mode 100644 include/dt-bindings/clock/amlogic,t7-scmi.h >>>>> >>>> Where is any binding doc for this? Why is this a separate patch? >>> >>> >>> The ARM SCMI device tree binding specification is located at >>> ./Documentation/devicetree/bindings/firmware/arm,scmi.yaml. >> >> Then git grep for the file name - there is no such compatible. Are you >> sure you follow writing bindings doc? >> >> Think how are you going to use these values. You will have phandle, yes? >> To some controller, yes? Which one? > > For the C3 (I believe the T7 is the same), the compatible being used is > "arm,scmi-smc". It is a generic one documented here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml?h=v6.18#n202 > > The phandle used is a subnode of that, to clock protocol: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi?h=v6.18#n116 > > Same things is done on imx, stm and rockchip platforms from what I can > see. I see, thanks for explanation, it's fine. > > Jian is just adding the arbitrary IDs used to identify the clocks in the > FW. I don't think there is anything out of the ordirnary here. > > Is there something else Rob and I missed reviewing this ? > >> >>> >>> Certain secure clocks on the T7 rely on the ARM SCMI driver stack, which >>> is officially supported by ARM. >>> >>> The kernel-side SCMI client implementation resides in >>> ./drivers/firmware/arm_scmi/. >>> >>> To enable ARM SCMI on T7, three components are needed: >>> >>> - Kernel-side definition of ARM SCMI clock indices (this patch addresses >>> this component); >>> - SCMI server implementation in the ARM Trusted Firmware (ATF) running >>> at Exception Level 3 (EL3), which has been integrated into the bootloader; >>> - Device Tree Source (DTS) configuration for ARM SCMI clock nodes (the >>> DTS changes will be submitted after the T7 clock driver patches are >>> merged upstream). >> >> So silently you keep the users hidden? No, I want to see the users. >> > > Is there a new requirement to submit the DTS file changes along with the > driver changes now ? > > This has never been case before, especially since the changes are merged > through different trees. There is no such requirement, but "has never been case before" is clearly not accurate, because I raised this question multiple times last two-three years. There is no reasonable way to hold publishing of DTS, therefore if someone uses arguments like above with waiting for driver, I usually got suspicious. Also note, that many contributions from various people (not saying that this one here is) were bad quality and badly designed but without seeing DTS it takes me significantly more time to understand that design. So yes, publish your DTS solving all of the questions and making reviewing easier. Or don't and receive questions... Best regards, Krzysztof
On Thu 11 Dec 2025 at 07:16, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> Is there a new requirement to submit the DTS file changes along with the >> driver changes now ? >> >> This has never been case before, especially since the changes are merged >> through different trees. > > There is no such requirement, but "has never been case before" is > clearly not accurate, because I raised this question multiple times last > two-three years. > > There is no reasonable way to hold publishing of DTS, therefore if > someone uses arguments like above with waiting for driver, I usually got > suspicious. > > Also note, that many contributions from various people (not saying that > this one here is) were bad quality and badly designed but without seeing > DTS it takes me significantly more time to understand that design. So > yes, publish your DTS solving all of the questions and making reviewing > easier. Or don't and receive questions... > That's fair. Thanks for clarifying. > > Best regards, > Krzysztof -- Jerome
© 2016 - 2025 Red Hat, Inc.