Basic device tree support for StarFive JH7110 RISC-V SoC

From: Emil Renner Berthing <[email protected]>

Add device tree bindings for the StarFive JH7110 RISC-V SoC and the VisionFive 2 board equipped with it.

VisionFive 2 board has version A and version B, which are different in gmac and phy chip. The version A board has one 1000Mbps and one 100Mbps Ethernet ports while the version B board has two 1000Mbps Ethernet ports.

Link https://doc-en.rvspace.org/Doc_Center/jh7110.html

Link https://doc-en.rvspace.org/Doc_Center/visionfive_2.html

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

Quoted 10 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add device tree bindings for the StarFive JH7110 RISC-V SoC and the VisionFive 2 board equipped with it.

VisionFive 2 board has version A and version B, which are different in gmac and phy chip. The version A board has one 1000Mbps and one 100Mbps Ethernet ports while the version B board has two 1000Mbps Ethernet ports.

Quoted 4 lines

Link https://doc-en.rvspace.org/Doc_Center/jh7110.html

Link https://doc-en.rvspace.org/Doc_Center/visionfive_2.html

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

I assume you did not add my tag because of changes?

Acked-by Krzysztof Kozlowski <[email protected]>

From: Emil Renner Berthing <[email protected]>

Add device tree bindings for the StarFive JH7110 RISC-V SoC and the VisionFive 2 board equipped with it.

VisionFive 2 board has version A and version B, which are different in gmac and phy chip. The version A board has one 1000Mbps and one 100Mbps Ethernet ports while the version B board has two 1000Mbps Ethernet ports.

Link https://doc-en.rvspace.org/Doc_Center/jh7110.html

Link https://doc-en.rvspace.org/Doc_Center/visionfive_2.html

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

Quoted 10 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add device tree bindings for the StarFive JH7110 RISC-V SoC and the VisionFive 2 board equipped with it.

VisionFive 2 board has version A and version B, which are different in gmac and phy chip. The version A board has one 1000Mbps and one 100Mbps Ethernet ports while the version B board has two 1000Mbps Ethernet ports.

Quoted 4 lines

Link https://doc-en.rvspace.org/Doc_Center/jh7110.html

Link https://doc-en.rvspace.org/Doc_Center/visionfive_2.html

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

Unless Emil objects, I'll queue this for 6.3 once -rc1 has been tagged.

From: Emil Renner Berthing <[email protected]>

This cache controller is also used on the StarFive JH7110 SoC.

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 .../devicetree/bindings/riscv/sifive,ccache0.yaml        | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

From: Emil Renner Berthing <[email protected]>

This adds support for the StarFive JH7110 SoC which also features this SiFive cache controller.

Signed-off-by Emil Renner Berthing <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 drivers/soc/Makefile       | 2 +-
 drivers/soc/sifive/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/soc/Makefile +1 -1

index 69ba6508cf2c..534669840858 100644
@@ -26,7 +26,7 @@ obj-y				+= qcom/
 obj-y				+= renesas/
 obj-y				+= rockchip/
 obj-$(CONFIG_SOC_SAMSUNG)	+= samsung/
-obj-$(CONFIG_SOC_SIFIVE)	+= sifive/
+obj-y				+= sifive/
 obj-y				+= sunxi/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-y				+= ti/

drivers/soc/sifive/Kconfig +1 -1

index ed4c571f8771..e86870be34c9 100644
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
-if SOC_SIFIVE
+if SOC_SIFIVE || SOC_STARFIVE
 
 config SIFIVE_CCACHE
 	bool "Sifive Composable Cache controller"

Signature · 1 line

2.38.1

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +166 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <16384>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imac";
+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu1_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_2: cpu@2 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <2>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu2_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_3: cpu@3 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <3>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu3_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_4: cpu@4 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <4>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu4_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&S76_0>;
+				};
+
+				core1 {
+					cpu = <&U74_1>;
+				};
+
+				core2 {
+					cpu = <&U74_2>;
+				};
+
+				core3 {
+					cpu = <&U74_3>;

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +47 -0

+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac0_rgmii_rxin: gmac0_rgmii_rxin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac1_rmii_refin: gmac1_rmii_refin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac1_rgmii_rxin: gmac1_rgmii_rxin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2stx_bclk_ext: i2stx_bclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2stx_lrck_ext: i2stx_lrck_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2srx_bclk_ext: i2srx_bclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2srx_lrck_ext: i2srx_lrck_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	tdm_ext: tdm_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	mclk_ext: mclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +27 -0

+			compatible = "starfive,jh7110-plic", "sifive,plic-1.0.0";
+			reg = <0x0 0xc000000 0x0 0x4000000>;
+			interrupts-extended = <&cpu0_intc 11>,
+					      <&cpu1_intc 11>, <&cpu1_intc 9>,
+					      <&cpu2_intc 11>, <&cpu2_intc 9>,
+					      <&cpu3_intc 11>, <&cpu3_intc 9>,
+					      <&cpu4_intc 11>, <&cpu4_intc 9>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			#address-cells = <0>;
+			riscv,ndev = <136>;
+		};
+
+		ccache: cache-controller@2010000 {
+			compatible = "starfive,jh7110-ccache", "sifive,ccache0", "cache";
+			reg = <0x0 0x2010000 0x0 0x4000>;
+			interrupts = <1>, <3>, <4>, <2>;
+			cache-block-size = <64>;
+			cache-level = <2>;
+			cache-sets = <2048>;
+			cache-size = <2097152>;
+			cache-unified;
+		};
+
+		uart0: serial@10000000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x10000000 0x0 0x10000>;

Quoted 192 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +171 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <16384>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imac";
+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu1_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_2: cpu@2 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <2>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu2_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_3: cpu@3 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <3>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu3_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_4: cpu@4 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <4>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";
+			tlb-split;
+
+			cpu4_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&S76_0>;
+				};
+
+				core1 {
+					cpu = <&U74_1>;
+				};
+
+				core2 {
+					cpu = <&U74_2>;
+				};
+
+				core3 {
+					cpu = <&U74_3>;
+				};
+
+				core4 {
+					cpu = <&U74_4>;
+				};

arch/riscv/boot/dts/starfive/jh7110.dtsi line 176

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+			};
+		};
+	};
+
+	osc: osc {

Node names should be generic, so why this is "osc" and other oscillators are not "osc"?

arch/riscv/boot/dts/starfive/jh7110.dtsi line 181

Quoted 7 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	rtc_osc: rtc_osc {

No underscores in node names. Generic node names (so each of them starting or ending with clock).

arch/riscv/boot/dts/starfive/jh7110.dtsi line 186

Quoted 6 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac0_rmii_refin: gmac0_rmii_refin {

Same problem... and actually you have way too many fixed clocks which do

nothing. It looks like you avoid to define proper clock controller. What's the point for all these clocks? These are no-op.

Quoted 53 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +52 -0

+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac0_rgmii_rxin: gmac0_rgmii_rxin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac1_rmii_refin: gmac1_rmii_refin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	gmac1_rgmii_rxin: gmac1_rgmii_rxin {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2stx_bclk_ext: i2stx_bclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2stx_lrck_ext: i2stx_lrck_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2srx_bclk_ext: i2srx_bclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	i2srx_lrck_ext: i2srx_lrck_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	tdm_ext: tdm_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	mclk_ext: mclk_ext {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&plic>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 243

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		clint: clint@2000000 {

Node names should be generic.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

arch/riscv/boot/dts/starfive/jh7110.dtsi line 253

Quoted 11 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+			compatible = "starfive,jh7110-clint", "sifive,clint0";
+			reg = <0x0 0x2000000 0x0 0x10000>;
+			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
+					      <&cpu1_intc 3>, <&cpu1_intc 7>,
+					      <&cpu2_intc 3>, <&cpu2_intc 7>,
+					      <&cpu3_intc 3>, <&cpu3_intc 7>,
+					      <&cpu4_intc 3>, <&cpu4_intc 7>;
+		};
+
+		plic: plic@c000000 {

Node names should be generic, so interrupt-controller
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

Quoted 13 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +12 -0

+			compatible = "starfive,jh7110-plic", "sifive,plic-1.0.0";
+			reg = <0x0 0xc000000 0x0 0x4000000>;
+			interrupts-extended = <&cpu0_intc 11>,
+					      <&cpu1_intc 11>, <&cpu1_intc 9>,
+					      <&cpu2_intc 11>, <&cpu2_intc 9>,
+					      <&cpu3_intc 11>, <&cpu3_intc 9>,
+					      <&cpu4_intc 11>, <&cpu4_intc 9>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			#address-cells = <0>;
+			riscv,ndev = <136>;
+		};

	gmac0_rmii_refin: clock {
		...
	};

	gmac0_rgmii_rxin: clock {
		...
	};
	...

Quoted 2 lines

nothing. It looks like you avoid to define proper clock controller. What's the point for all these clocks? These are no-op.

These are all external fixed rate clocks inputted to the SoC. They are the root

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 179

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +3 -0

+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +16 -0

+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&S76_0>;
+				};
+
+				core1 {
+					cpu = <&U74_1>;
+				};
+
+				core2 {
+					cpu = <&U74_2>;
+				};
+
+				core3 {
+					cpu = <&U74_3>;

Quoted 11 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---

FWIW, this cpu-map is now the default in linux, so you no longer *need* to add it for that purpose - but there's obviously no harm in being explicit for other operating systems etc. (IOW, don't remove it!)

Quoted 16 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +16 -0

+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&S76_0>;
+				};
+
+				core1 {
+					cpu = <&U74_1>;
+				};
+
+				core2 {
+					cpu = <&U74_2>;
+				};
+
+				core3 {
+					cpu = <&U74_3>;

arch/riscv/boot/dts/starfive/jh7110.dtsi

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +9 -0

+				};
+
+				core4 {
+					cpu = <&U74_4>;
+				};
+			};
+		};
+	};
 
+		syscrg: clock-controller@13020000 {

For obvious reasons, I cannot apply this until both the clock & pinctrl bindings are in my tree - but you know that already.

arch/riscv/boot/dts/starfive/jh7110.dtsi line 363

Quoted 7 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +7 -0

+			compatible = "starfive,jh7110-syscrg";
+			reg = <0x0 0x13020000 0x0 0x10000>;
+			clocks = <&osc>, <&gmac1_rmii_refin>,
+				 <&gmac1_rgmii_rxin>,
+				 <&i2stx_bclk_ext>, <&i2stx_lrck_ext>,
+				 <&i2srx_bclk_ext>, <&i2srx_lrck_ext>,
+				 <&tdm_ext>, <&mclk_ext>;

As Krzk asked - are these clocks really all inputs to the SoC?

Quoted 11 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+			clock-names = "osc", "gmac1_rmii_refin",
+				      "gmac1_rgmii_rxin",
+				      "i2stx_bclk_ext", "i2stx_lrck_ext",
+				      "i2srx_bclk_ext", "i2srx_lrck_ext",
+				      "tdm_ext", "mclk_ext";
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+		};
+
+		gpio: gpio@13040000 {

arch/riscv/boot/dts/starfive/jh7110.dtsi line 400

Quoted 1 line

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +1 -0

+		gpioa: gpio@17020000 {

Out of curiousity, why gpio & gpioa?

Quoted 12 lines · Conor Dooley

Quoted 11 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 400

Quoted 3 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +2 -0

+		gpio: gpio@13040000 {
 
+		gpioa: gpio@17020000 {

Out of curiousity, why gpio & gpioa?

Oh, is it easier to read if I change "gpio" and "gpioa" to "sysgpio" and "aongpio"? Thanks.

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +17 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;

Hey,

Quoted 34 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411
+++++++++++++++++++++++

 1 file changed, 411 insertions(+)

 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+       compatible = "starfive,jh7110";
+       #address-cells = <2>;
+       #size-cells = <2>;
+
+       cpus {
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               S76_0: cpu@0 {
+                       compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc. Which is correct? Your docs say S7 and S76, so I would imagine that it
is actually an S76?

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+                       reg = <0>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <8192>;
+                       d-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 36

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <16384>;
+                       i-tlb-sets = <1>;
+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>;
+                       riscv,isa = "rv64imac";

While I was poking around trying to see if there was some logic behind
that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here?

Quoted 23 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+                       tlb-split;
+                       status = "disabled";
+
+                       cpu0_intc: interrupt-controller {
+                               compatible = "riscv,cpu-intc";
+                               interrupt-controller;
+                               #interrupt-cells = <1>;
+                       };
+               };
+
+               U74_1: cpu@1 {
+                       compatible = "sifive,u74-mc", "riscv";
+                       reg = <1>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <32768>;
+                       d-tlb-sets = <1>;
+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <32768>;
+                       i-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>;
+                       riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Thanks,
Conor.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Quoted 98 lines · 在 2022-12-28星期三的 22:48 +0000，Conor Dooley写道：

Hey,

Quoted 34 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411
+++++++++++++++++++++++

 1 file changed, 411 insertions(+)

 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+       compatible = "starfive,jh7110";
+       #address-cells = <2>;
+       #size-cells = <2>;
+
+       cpus {
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               S76_0: cpu@0 {
+                       compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc. Which is correct? Your docs say S7 and S76, so I would imagine that it
is actually an S76?

Quoted 5 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+                       reg = <0>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <8192>;
+                       d-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 36

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <16384>;
+                       i-tlb-sets = <1>;
+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>;
+                       riscv,isa = "rv64imac";

While I was poking around trying to see if there was some logic behind
that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here?

Quoted 23 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+                       tlb-split;
+                       status = "disabled";
+
+                       cpu0_intc: interrupt-controller {
+                               compatible = "riscv,cpu-intc";
+                               interrupt-controller;
+                               #interrupt-cells = <1>;
+                       };
+               };
+
+               U74_1: cpu@1 {
+                       compatible = "sifive,u74-mc", "riscv";
+                       reg = <1>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <32768>;
+                       d-tlb-sets = <1>;
+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <32768>;
+                       i-tlb-sets = <1>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>;
+                       riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

It supports RV64GCZbaZbb.

B is not a well-defined thing by specifications, so it should be prevented here.

Hey Icenowy, Hal

Quoted 4 lines · Icenowy Zheng

Quoted 3 lines · 在 2022-12-28星期三的 22:48 +0000，Conor Dooley写道：

Hey,

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

Quoted 18 lines

Quoted 18 lines

Quoted 17 lines

+               U74_1: cpu@1 {
+                       compatible = "sifive,u74-mc", "riscv"; +                       reg = <1>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <32768>;
+                       d-tlb-sets = <1>;
+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <32768>;
+                       i-tlb-sets = <1>;
+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>; +                       riscv,isa = "rv64imafdc";

Quoted 5 lines

Quoted 3 lines

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

It supports RV64GCZbaZbb.

Sweet, thanks.

Quoted 2 lines

B is not a well-defined thing by specifications, so it should be prevented here.

Yah, don't worry - my next question was going to be which bits were supported :)

Hal, can you update the isa string in the next version please?

Quoted 3 lines · 在 2022-12-28星期三的 22:48 +0000，Conor Dooley写道：

Hey,

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

Quoted 18 lines

Quoted 17 lines

+               U74_1: cpu@1 {
+                       compatible = "sifive,u74-mc", "riscv"; +                       reg = <1>;
+                       d-cache-block-size = <64>;
+                       d-cache-sets = <64>;
+                       d-cache-size = <32768>;
+                       d-tlb-sets = <1>;
+                       d-tlb-size = <40>;
+                       device_type = "cpu";
+                       i-cache-block-size = <64>;
+                       i-cache-sets = <64>;
+                       i-cache-size = <32768>;
+                       i-tlb-sets = <1>;
+                       i-tlb-size = <40>;
+                       mmu-type = "riscv,sv39";
+                       next-level-cache = <&ccache>; +                       riscv,isa = "rv64imafdc";

Quoted 3 lines

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

It supports RV64GCZbaZbb.

B is not a well-defined thing by specifications, so it should be prevented here.

Hey,

Quoted 36 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +15 -0

new file mode 100644
index 000000000000..64d260ea1f29
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
+#include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 6 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +6 -0

+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

Quoted 13 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +12 -0

+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <16384>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 36

Quoted 3 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +3 -0

+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imac";

While I was poking around trying to see if there was some logic behind that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here?

Quoted 24 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Quoted 15 lines · Conor Dooley

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 11 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

[1] https://www.sifive.com/cores/essential

Quoted 13 lines

Quoted 13 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +12 -0

+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <16384>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 36

Quoted 3 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +3 -0

+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imac";

While I was poking around trying to see if there was some logic behind that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here?

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Quoted 23 lines

Quoted 23 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Actually, U74 doesn't support the full B extension, and the SiFive doc [1]

describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes "IMAFD".

"_Zba_Zbb_Sscofpmf" is not shown in other device trees such as jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.

[1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

Quoted 22 lines · Hal Feng

Quoted 15 lines · Conor Dooley

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 11 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

Quoted 3 lines

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

I'm less worried about the label & more interested in the compatible. hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7" compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml and using that here instead?

Quoted 26 lines

[1] https://www.sifive.com/cores/essential

Quoted 21 lines

Quoted 6 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +5 -0

+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <8192>;
+			d-tlb-sets = <1>;

arch/riscv/boot/dts/starfive/jh7110.dtsi line 36

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +10 -0

+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <16384>;
+			i-tlb-sets = <1>;
+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imac";

While I was poking around trying to see if there was some logic behind that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here?

Quoted 2 lines

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Cool, thanks.

Quoted 33 lines

Quoted 24 lines

Quoted 24 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Quoted 1 line

Actually, U74 doesn't support the full B extension, and the SiFive doc [1]

Yeah, I knew asking that question that the "RV64GBC" in SiFive's online documentation was using outdated terminology. Also, that is not the doc for your core complex as far as I can tell. That is the document for impid 0x0621_1222, whereas (IIRC) your core is 0x0421_0427. Jess and I had a look one evening but could not find the 21G1.02.00 revision of this document, which is the one corresponding to 0x421_0427. See Table 92 for more details.

Quoted 3 lines

describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes "IMAFD".

I could not find the 21G1.02.00 version of this document online, but I was able to find the 21G1.01.00 version of it & that version does not support the Sscofpmf extension (but does have Zba/Zbb support).

Quoted 2 lines

"_Zba_Zbb_Sscofpmf" is not shown in other device trees such as jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.

Just because other devicetrees omit them, doesn't mean that you should too!
This compatible should be an accurate description of your hardware, so you should add what you actually have.

If you have Zba and Zbb, then add them.
I would double check against your internal documentation for 21G2.02.00 as to whether you do have Sscofpmf, and if you do, add that too!

That way, whenever support for those extensions lands, the jh7110 will automatically pick it up, rather than needing to have them retrofitted.

Quoted 1 line

[1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

Quoted 27 lines · Conor Dooley

Quoted 25 lines · Hal Feng

Quoted 15 lines · Conor Dooley

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 11 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

Quoted 4 lines

I'm less worried about the label & more interested in the compatible. hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7" compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml and using that here instead?

First of all, it's my fault that I didn't check the revision of U74-MC manual, so most of my previous replies might not make sense.

If we add a new compatible string for S7, should we change the compatibles of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc". I'm not sure about this.

Quoted 4 lines

Quoted 2 lines

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Cool, thanks.

Now I think it might be another version of S76.

Quoted 34 lines

Quoted 32 lines

Quoted 23 lines

Quoted 23 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Quoted 1 line

Actually, U74 doesn't support the full B extension, and the SiFive doc [1]

Quoted 7 lines

Yeah, I knew asking that question that the "RV64GBC" in SiFive's online documentation was using outdated terminology. Also, that is not the doc for your core complex as far as I can tell. That is the document for impid 0x0621_1222, whereas (IIRC) your core is 0x0421_0427. Jess and I had a look one evening but could not find the 21G1.02.00 revision of this document, which is the one corresponding to 0x421_0427. See Table 92 for more details.

I found the 21G1.02.00 revision on StarFive internal net, but I'm not sure whether I can make it public and I am checking this.

This revision records
that the ISA of 21G1.02.00 U74 is "RV64GCB" and ISA of 21G1.02.00 S7 is "RV64IMACB". I am asking someone to check with SiFive whether both 21G1.02.00 U74 and S7 support the full B extension.

Quoted 10 lines

Quoted 2 lines

describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes "IMAFD".

I could not find the 21G1.02.00 version of this document online, but I was able to find the 21G1.01.00 version of it & that version does not support the Sscofpmf extension (but does have Zba/Zbb support).

Quoted 2 lines

"_Zba_Zbb_Sscofpmf" is not shown in other device trees such as jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.

Quoted 4 lines

Just because other devicetrees omit them, doesn't mean that you should too!
This compatible should be an accurate description of your hardware, so you should add what you actually have.

Will keep it in mind. Thank you.

Quoted 8 lines

If you have Zba and Zbb, then add them.
I would double check against your internal documentation for 21G2.02.00 as to whether you do have Sscofpmf, and if you do, add that too!

That way, whenever support for those extensions lands, the jh7110 will automatically pick it up, rather than needing to have them retrofitted.

Quoted 1 line

[1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

Quoted 4 lines · Hal Feng

Quoted 3 lines · Conor Dooley

Quoted 2 lines · Hal Feng

Quoted 1 line · Conor Dooley

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

FWIW, the deadline for getting material in for v6.3 has already passed, so you can send the next version of this series without waiting for clarification on the compatibles & ISA string. We should have plenty of time to get those fixed up before the series gets applied.

Quoted 10 lines · Conor Dooley

Quoted 4 lines · Hal Feng

Quoted 3 lines · Conor Dooley

Quoted 2 lines · Hal Feng

Quoted 1 line · Conor Dooley

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

FWIW, the deadline for getting material in for v6.3 has already passed, so you can send the next version of this series without waiting for clarification on the compatibles & ISA string. We should have plenty of time to get those fixed up before the series gets applied.

Also, as it looks like the pinctrl driver is going to land in time for v6.3, that leaves just this series and the clock driver required for base support.

In the original submission, you sent the clock driver and dt in the same series & I think it might make the process a bit faster if you sent them both together for the next version again.

That way, both the drivers and dts can go together as their have an inter dependence.

That's my opinion anyway, will make trying to sequence things between trees easier.

Quoted 20 lines · Conor Dooley

Quoted 10 lines · Conor Dooley

Quoted 4 lines · Hal Feng

Quoted 3 lines · Conor Dooley

Quoted 2 lines · Hal Feng

Quoted 1 line · Conor Dooley

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

FWIW, the deadline for getting material in for v6.3 has already passed, so you can send the next version of this series without waiting for clarification on the compatibles & ISA string. We should have plenty of time to get those fixed up before the series gets applied.

Also, as it looks like the pinctrl driver is going to land in time for v6.3, that leaves just this series and the clock driver required for base support.

In the original submission, you sent the clock driver and dt in the same series & I think it might make the process a bit faster if you sent them both together for the next version again.

Quoted 5 lines

That way, both the drivers and dts can go together as their have an inter dependence.

That's my opinion anyway, will make trying to sequence things between trees easier.

Good idea. But how can I write the change log if we do so? Will it make the history confused? Thanks.

Quoted 21 lines · Hal Feng

Quoted 20 lines · Conor Dooley

Quoted 10 lines · Conor Dooley

Quoted 4 lines · Hal Feng

Quoted 3 lines · Conor Dooley

Quoted 2 lines · Hal Feng

Quoted 1 line · Conor Dooley

On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:

FWIW, the deadline for getting material in for v6.3 has already passed, so you can send the next version of this series without waiting for clarification on the compatibles & ISA string. We should have plenty of time to get those fixed up before the series gets applied.

Also, as it looks like the pinctrl driver is going to land in time for v6.3, that leaves just this series and the clock driver required for base support.

In the original submission, you sent the clock driver and dt in the same series & I think it might make the process a bit faster if you sent them both together for the next version again.

Quoted 8 lines

Quoted 5 lines

That way, both the drivers and dts can go together as their have an inter dependence.

That's my opinion anyway, will make trying to sequence things between trees easier.

Good idea. But how can I write the change log if we do so? Will it make the history confused? Thanks.

I'm not sure what you mean w.r.t. history.
Both series are on V3 I think, so just make the next version v4 title it something like "Basic clock, reset & dt support..."
For the changelogs, just mention you merged the two series again in the cover letter & add the changelogs that you would have made for each series to the cover as a single changelog.
Say somewhere in the cover that I suggested merging the series together so that they could go via the same tree as the dt-binding headers are required by both driver & devicetree.

Quoted 28 lines · Hal Feng

Quoted 27 lines · Conor Dooley

Quoted 25 lines · Hal Feng

Quoted 15 lines · Conor Dooley

arch/riscv/boot/dts/starfive/jh7110.dtsi line 21

Quoted 11 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

Quoted 7 lines

Quoted 4 lines

I'm less worried about the label & more interested in the compatible. hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7" compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml and using that here instead?

First of all, it's my fault that I didn't check the revision of U74-MC manual, so most of my previous replies might not make sense.

No that's fine. The manual stuff confused me too when I went looking initially, and I still get get mixed up by the fact that there are core-complex manuals but not core manuals.

Quoted 4 lines

If we add a new compatible string for S7, should we change the compatibles of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc". I'm not sure about this.

[...]

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Cool, thanks.

Now I think it might be another version of S76.

The SiFive docs describe the u74-mc core complex, which AFAIU you have, as being 1x S7 & 4x U7.

I'd be happy with new binding for "sifive,s7" & then we use that here. If you're sure it's S76, we can also use that. S76 is described, in what docs I can see, as a core complex containing an S7, so S7 seems likely to be correct?

u7, u74 & u74-mc are valid compatibles, added by SiFive, in commit 75e6d7248efc ("dt-bindings: riscv: Update DT binding docs to support SiFive FU740 SoC"). Unfortunately, they never actually *used* those compatibles for anything, and just used "sifive,bullet0" for the fu740.

I'll accept any of u7, u74 or u74-mc for those harts.

Quoted 42 lines

Quoted 34 lines

Quoted 32 lines

Quoted 23 lines

Quoted 23 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +23 -0

+			tlb-split;
+			status = "disabled";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		U74_1: cpu@1 {
+			compatible = "sifive,u74-mc", "riscv";
+			reg = <1>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <64>;
+			d-cache-size = <32768>;
+			d-tlb-sets = <1>;
+			d-tlb-size = <40>;
+			device_type = "cpu";
+			i-cache-block-size = <64>;
+			i-cache-sets = <64>;
+			i-cache-size = <32768>;
+			i-tlb-sets = <1>;

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi line 63

Quoted 4 lines

arch/riscv/boot/dts/starfive/jh7110.dtsi new file +4 -0

+			i-tlb-size = <40>;
+			mmu-type = "riscv,sv39";
+			next-level-cache = <&ccache>;
+			riscv,isa = "rv64imafdc";

That also begs the question:
Do your u74s support RV64GBC, as the (current) SiFive documentation suggests?

Quoted 1 line

Actually, U74 doesn't support the full B extension, and the SiFive doc [1]

Quoted 7 lines

Yeah, I knew asking that question that the "RV64GBC" in SiFive's online documentation was using outdated terminology. Also, that is not the doc for your core complex as far as I can tell. That is the document for impid 0x0621_1222, whereas (IIRC) your core is 0x0421_0427. Jess and I had a look one evening but could not find the 21G1.02.00 revision of this document, which is the one corresponding to 0x421_0427. See Table 92 for more details.

Quoted 2 lines

I found the 21G1.02.00 revision on StarFive internal net, but I'm not sure whether I can make it public and I am checking this.

Yeah, certainly don't do anything without cross-checking!

Quoted 4 lines

This revision records
that the ISA of 21G1.02.00 U74 is "RV64GCB" and ISA of 21G1.02.00 S7 is "RV64IMACB". I am asking someone to check with SiFive whether both 21G1.02.00 U74 and S7 support the full B extension.

Having cross-checked a 21G1.01.00 document against a 21G2.01.00 one, I'm 99% sure that you have _Zba_Zbb.
The G2.01 document says _Zba_Zbb & has the same instructions listed as supported as the G1.02 one.
I've also tried the Zbb support patches posted by Heiko [2] on a VisionFive V2 and had them work - which is why a definitive statement on the version of Zbb supported would be really great to have!

[2] - https://lore.kernel.org/linux-riscv/[email protected]/

Quoted 11 lines

Quoted 11 lines

Quoted 3 lines

describes the ISA of U74 is "RV64GC_Zba_Zbb_Sscofpmf" which "G" includes "IMAFD".

I could not find the 21G1.02.00 version of this document online, but I was able to find the 21G1.01.00 version of it & that version does not support the Sscofpmf extension (but does have Zba/Zbb support).

Quoted 2 lines

"_Zba_Zbb_Sscofpmf" is not shown in other device trees such as jh7100.dtsi and fu740-c000.dtsi, so I didn't show them here.

Quoted 6 lines

Quoted 4 lines

Just because other devicetrees omit them, doesn't mean that you should too!
This compatible should be an accurate description of your hardware, so you should add what you actually have.

Will keep it in mind. Thank you.

FWIW, the deadline for getting material in for v6.3 has already passed, so you can send the next version of this series without waiting for clarification on the compatibles & ISA string. We should have plenty of time to get those fixed up before the series gets applied.

Thanks,
Conor.

Quoted 8 lines

Quoted 8 lines

If you have Zba and Zbb, then add them.
I would double check against your internal documentation for 21G2.02.00 as to whether you do have Sscofpmf, and if you do, add that too!

That way, whenever support for those extensions lands, the jh7110 will automatically pick it up, rather than needing to have them retrofitted.

Quoted 1 line

[1] https://sifive.cdn.prismic.io/sifive/2dd11994-693c-4360-8aea-5453d8642c42_u74mc_core_complex_manual_21G3.pdf

Quoted 55 lines · Conor Dooley

Quoted 28 lines · Hal Feng

Quoted 27 lines · Conor Dooley

Quoted 25 lines · Hal Feng

Quoted 15 lines · Conor Dooley

Review

Quoted 11 lines · Hal Feng

(quoted diff) +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

Quoted 7 lines

Quoted 4 lines

I'm less worried about the label & more interested in the compatible. hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7" compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml and using that here instead?

First of all, it's my fault that I didn't check the revision of U74-MC manual, so most of my previous replies might not make sense.

No that's fine. The manual stuff confused me too when I went looking initially, and I still get get mixed up by the fact that there are core-complex manuals but not core manuals.

Quoted 4 lines

If we add a new compatible string for S7, should we change the compatibles of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc". I'm not sure about this.

[...]

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Cool, thanks.

Now I think it might be another version of S76.

Quoted 7 lines

The SiFive docs describe the u74-mc core complex, which AFAIU you have, as being 1x S7 & 4x U7.

I'd be happy with new binding for "sifive,s7" & then we use that here. If you're sure it's S76, we can also use that. S76 is described, in what docs I can see, as a core complex containing an S7, so S7 seems likely to be correct?

I will add a new binding for "sifive,s7" and modify the code as follows.

	S7_0: cpu@0 {
		compatible = "sifive,s7", "riscv";
		...
		riscv,isa = "rv64imac_zicsr_zba_zbb";

Hey Hal!

Quoted 66 lines · Hal Feng

Quoted 55 lines · Conor Dooley

Quoted 28 lines · Hal Feng

Quoted 27 lines · Conor Dooley

Quoted 25 lines · Hal Feng

Quoted 15 lines · Conor Dooley

Review

Quoted 11 lines · Hal Feng

(quoted diff) +11 -0

+/ {
+	compatible = "starfive,jh7110";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		S76_0: cpu@0 {
+			compatible = "sifive,u74-mc", "riscv";

The label here says S76 but the compatible says u74-mc.

U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.

Quoted 2 lines

Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76?

I found SiFive website [1] call it S76, but call it S7 in other places. So I misunderstood this. Considering the ISA difference you described as below, I think it's proper to change the label to "S7_0".

Quoted 7 lines

Quoted 4 lines

I'm less worried about the label & more interested in the compatible. hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7" compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml and using that here instead?

First of all, it's my fault that I didn't check the revision of U74-MC manual, so most of my previous replies might not make sense.

No that's fine. The manual stuff confused me too when I went looking initially, and I still get get mixed up by the fact that there are core-complex manuals but not core manuals.

Quoted 4 lines

If we add a new compatible string for S7, should we change the compatibles of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc". I'm not sure about this.

[...]

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a S7-series core, not S76.

Cool, thanks.

Now I think it might be another version of S76.

Quoted 7 lines

The SiFive docs describe the u74-mc core complex, which AFAIU you have, as being 1x S7 & 4x U7.

I'd be happy with new binding for "sifive,s7" & then we use that here. If you're sure it's S76, we can also use that. S76 is described, in what docs I can see, as a core complex containing an S7, so S7 seems likely to be correct?

I will add a new binding for "sifive,s7" and modify the code as follows.

Quoted 4 lines

	S7_0: cpu@0 {
		compatible = "sifive,s7", "riscv";
		...
		riscv,isa = "rv64imac_zicsr_zba_zbb";

I'm not sure that I'd bother with the zicsr, it gets added automagically by the Makefile if needed:

| # Newer binutils versions default to ISA spec version 20191213 which moves some
| # instructions from the I extension to the Zicsr and Zifencei extensions.
| toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
| riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei

Otherwise, thanks for the actual confirmation of zba/zbb!

Thanks,
Conor.

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

Quoted 10 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

Quoted 4 lines

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

I wanna add i2c nodes (i2c0-6) in the next version, so someone else can use them when they submit i2c driver patches.

Quoted 16 lines · Hal Feng

Quoted 14 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

Quoted 2 lines

I wanna add i2c nodes (i2c0-6) in the next version, so someone else can use them when they submit i2c driver patches.

All of the other series depend on this one for enablement,
so unless the binding for i2c is already upstream I'd advise keeping it separate.

Quoted 20 lines · Conor Dooley

Quoted 18 lines · Hal Feng

Quoted 10 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add initial device tree for the JH7110 RISC-V SoC by StarFive Technology Ltd.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

Quoted 4 lines

---
 arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi

I wanna add i2c nodes (i2c0-6) in the next version, so someone else can use them when they submit i2c driver patches.

Quoted 2 lines

All of the other series depend on this one for enablement,
so unless the binding for i2c is already upstream I'd advise keeping it separate.

The i2c IP of JH7110 is from Synopsys and the same as the i2c IP in JH7100. The binding and driver for i2c are already upstream. It works as long as we add the i2c nodes and configure pins for i2c in device tree. It will simplify the dependency if we do that.

By the way, I am checking the ISA of U74-MC on JH7110 with someone else. I will reply you today.

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/Makefile         |   1 +
 .../jh7110-starfive-visionfive-2-va.dts       |  13 ++
 .../jh7110-starfive-visionfive-2-vb.dts       |  13 ++
 .../jh7110-starfive-visionfive-2.dtsi         | 111 ++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

arch/riscv/boot/dts/starfive/Makefile +0 -0

index 0ea1bc15ab30..79e925a4a227 100644

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +17 -0

new file mode 100644
index 000000000000..c60280b89c73
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110.dtsi"
+#include "jh7110-pinfunc.h"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {

Quoted 21 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/Makefile         |   1 +
 .../jh7110-starfive-visionfive-2-va.dts       |  13 ++
 .../jh7110-starfive-visionfive-2-vb.dts       |  13 ++
 .../jh7110-starfive-visionfive-2.dtsi         | 111 ++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

arch/riscv/boot/dts/starfive/Makefile line 3

Quoted 8 lines

arch/riscv/boot/dts/starfive/Makefile +1 -0

index 0ea1bc15ab30..79e925a4a227 100644
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb jh7110-starfive-visionfive-2-vb.dtb

Could you rebase on top of v6.2-rc1 when you submit your next version

squash this in please (unless Emil hates it):

arch/riscv/boot/dts/starfive/Makefile +4 -2

index c38a9ade7f48..b3744420253a 100644
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb jh7100-starfive-visionfive-v1.dtb
-dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb jh7110-starfive-visionfive-2-vb.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7100-starfive-visionfive-v1.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-vb.dtb

I'd rather have more, but easier to read lines than long ones.

Quoted 28 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +21 -0

new file mode 100644
index 000000000000..c60280b89c73
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110.dtsi"
+#include "jh7110-pinfunc.h"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	cpus {

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi line 27

Quoted 6 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +6 -0

+		timebase-frequency = <4000000>;
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x0 0x40000000 0x1 0x0>;

Is this a good idea when you have SKUs with 2, 4 & 8 GiB of DDR?

Anyways, I can't review this as I've got neither board nor documentation, so with the above stuff sorted out:

Acked-by Conor Dooley <[email protected]>

I'll not apply it until the clock binding header is in my tree.

Quoted 41 lines · Conor Dooley

Quoted 40 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +21 -0

new file mode 100644
index 000000000000..c60280b89c73
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110.dtsi"
+#include "jh7110-pinfunc.h"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	cpus {

Quoted 8 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi line 27

Quoted 6 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +6 -0

+		timebase-frequency = <4000000>;
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x0 0x40000000 0x1 0x0>;

Is this a good idea when you have SKUs with 2, 4 & 8 GiB of DDR?

The VisionFive 2 board only has 4GB version and 8GB version now. Before linux startup, we will change this property in dtb through u-boot to make sure the board can boot up with the correct memory size.

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi line 19

Quoted 7 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +7 -0

+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};

So I think this is wrong, and the stdout-path should be uart3 instead. Per the QSG [0], GPIO5/6 are the suggested UART Tx/Rx to use. This appears to map to uart3 rather than uart0.
FWIW, uart3 is also the stdout-path for the v1, see:
arch/riscv/boot/dts/starfive/jh7100-common.dtsi

At least, that change is what I needed to do in order to use the JH7110_VisionFive2_upstream branch, AFAICT matches what you've got in this series.

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/Makefile         |   1 +
 .../jh7110-starfive-visionfive-2-va.dts       |  13 ++
 .../jh7110-starfive-visionfive-2-vb.dts       |  13 ++
 .../jh7110-starfive-visionfive-2.dtsi         | 111 ++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

arch/riscv/boot/dts/starfive/Makefile +1 -0

index 0ea1bc15ab30..79e925a4a227 100644
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb jh7110-starfive-visionfive-2-vb.dtb

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts new file +13 -0

new file mode 100644
index 000000000000..188d3fddbe88
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110-starfive-visionfive-2.dtsi"
+
+/ {
+       model = "StarFive VisionFive 2 VA";
+       compatible = "starfive,visionfive-2-va", "starfive,jh7110";
+};

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +2 -0

new file mode 100644
index 000000000000..f75c10536f84
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +1 -0

+};

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi new file +111 -1

new file mode 100644
index 000000000000..c60280b89c73
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110.dtsi"
+#include "jh7110-pinfunc.h"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+       aliases {
+               serial0 = &uart0;
+       };
+
+       chosen {
+               stdout-path = "serial0:115200n8";
+       };
+
+       cpus {
+               timebase-frequency = <4000000>;
+       };
+
+       memory@40000000 {
+               device_type = "memory";
+               reg = <0x0 0x40000000 0x1 0x0>;
+       };
+
+       gpio-restart {
+               compatible = "gpio-restart";
+               gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
+               priority = <224>;
+       };
+};
+
+&osc {
+       clock-frequency = <24000000>;
+};
+
+&rtc_osc {
+       clock-frequency = <32768>;
+};
+
+&gmac0_rmii_refin {
+       clock-frequency = <50000000>;
+};
+
+&gmac0_rgmii_rxin {
+       clock-frequency = <125000000>;
+};
+
+&gmac1_rmii_refin {
+       clock-frequency = <50000000>;
+};
+
+&gmac1_rgmii_rxin {
+       clock-frequency = <125000000>;
+};
+
+&i2stx_bclk_ext {
+       clock-frequency = <12288000>;
+};
+
+&i2stx_lrck_ext {
+       clock-frequency = <192000>;
+};
+
+&i2srx_bclk_ext {
+       clock-frequency = <12288000>;
+};
+
+&i2srx_lrck_ext {
+       clock-frequency = <192000>;
+};
+
+&tdm_ext {
+       clock-frequency = <49152000>;
+};
+
+&mclk_ext {
+       clock-frequency = <12288000>;
+};
+
+&uart0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&uart0_pins>;
+       status = "okay";
+};
+
+&gpio {
+       uart0_pins: uart0-0 {
+               tx-pins {
+                       pinmux = <GPIOMUX(5, GPOUT_SYS_UART0_TX, GPOEN_ENABLE, GPI_NONE)>;
+                       bias-disable;
+                       drive-strength = <12>;
+                       input-disable;
+                       input-schmitt-disable;
+                       slew-rate = <0>;
+               };
+
+               rx-pins {
+                       pinmux = <GPIOMUX(6, GPOUT_LOW, GPOEN_DISABLE, GPI_SYS_UART0_RX)>;
+                       bias-disable; /* external pull-up */
+                       drive-strength = <2>;
+                       input-enable;
+                       input-schmitt-enable;
+                       slew-rate = <0>;
+               };
+       };
+};
--

2.38.1

Quoted 57 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/Makefile         |   1 +
 .../jh7110-starfive-visionfive-2-va.dts       |  13 ++
 .../jh7110-starfive-visionfive-2-vb.dts       |  13 ++
 .../jh7110-starfive-visionfive-2.dtsi         | 111 ++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

arch/riscv/boot/dts/starfive/Makefile +1 -0

index 0ea1bc15ab30..79e925a4a227 100644
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb jh7110-starfive-visionfive-2-vb.dtb

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts new file +13 -0

new file mode 100644
index 000000000000..188d3fddbe88
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110-starfive-visionfive-2.dtsi"
+
+/ {
+       model = "StarFive VisionFive 2 VA";
+       compatible = "starfive,visionfive-2-va", "starfive,jh7110";
+};

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +2 -0

new file mode 100644
index 000000000000..f75c10536f84
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts line 12

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +10 -0

+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110-starfive-visionfive-2.dtsi"
+
+/ {
+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

Quoted 82 lines · Emil Renner Berthing

Quoted 57 lines · Hal Feng

From: Emil Renner Berthing <[email protected]>

Add a minimal device tree for StarFive JH7110 VisionFive 2 board which has version A and version B. Support booting and basic clock/reset/pinctrl/uart drivers.

Signed-off-by Emil Renner Berthing <[email protected]>

Co-developed-by Jianlong Huang <[email protected]>

Signed-off-by Jianlong Huang <[email protected]>

Co-developed-by Hal Feng <[email protected]>

Signed-off-by Hal Feng <[email protected]>

---
 arch/riscv/boot/dts/starfive/Makefile         |   1 +
 .../jh7110-starfive-visionfive-2-va.dts       |  13 ++
 .../jh7110-starfive-visionfive-2-vb.dts       |  13 ++
 .../jh7110-starfive-visionfive-2.dtsi         | 111 ++++++++++++++++++
 4 files changed, 138 insertions(+)
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts
 create mode 100644 arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi

arch/riscv/boot/dts/starfive/Makefile +1 -0

index 0ea1bc15ab30..79e925a4a227 100644
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_SOC_STARFIVE) += jh7100-beaglev-starlight.dtb
+dtb-$(CONFIG_SOC_STARFIVE) += jh7110-starfive-visionfive-2-va.dtb jh7110-starfive-visionfive-2-vb.dtb

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-va.dts new file +13 -0

new file mode 100644
index 000000000000..188d3fddbe88
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110-starfive-visionfive-2.dtsi"
+
+/ {
+       model = "StarFive VisionFive 2 VA";
+       compatible = "starfive,visionfive-2-va", "starfive,jh7110";
+};

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +2 -0

new file mode 100644
index 000000000000..f75c10536f84
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts line 12

Quoted 10 lines

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +10 -0

+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ * Copyright (C) 2022 Emil Renner Berthing <[email protected]>
+ */
+
+/dts-v1/;
+#include "jh7110-starfive-visionfive-2.dtsi"
+
+/ {
+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

Quoted 5 lines

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

The version A board has reached the end of life. As far as I know, the version B board will not update also unless there are some important requirements and StarFive decides to update. Furthermore, it's too late to change the compatible as patch 1 was already accepted. Will it be easier to read if I modify it as below?

        model = "StarFive VisionFive 2 vB";
        compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Best regards,
Hal

Quoted 31 lines · Hal Feng

Quoted 18 lines · Emil Renner Berthing

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts line 12

Quoted 2 lines · Hal Feng

arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-vb.dts new file +2 -0

+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

Quoted 5 lines

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

The version A board has reached the end of life. As far as I know, the version B board will not update also unless there are some important requirements and StarFive decides to update. Furthermore, it's too late to change the compatible as patch 1 was already accepted. Will it be easier to read if I modify it as below?

Quoted 2 lines

        model = "StarFive VisionFive 2 vB";
        compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Oh, that's sad that the kernel will now end up calling the boards something that's used nowhere else, even by StarFive :/ But yeah, I guess vA and vB are a little easier to read.

Quoted 32 lines · Emil Renner Berthing

Quoted 31 lines · Hal Feng

Quoted 18 lines · Emil Renner Berthing

Review

Quoted 2 lines · Hal Feng

(quoted diff) +2 -0

+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

Quoted 5 lines

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

The version A board has reached the end of life. As far as I know, the version B board will not update also unless there are some important requirements and StarFive decides to update. Furthermore, it's too late to change the compatible as patch 1 was already accepted. Will it be easier to read if I modify it as below?

Quoted 6 lines

Quoted 2 lines

        model = "StarFive VisionFive 2 vB";
        compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Oh, that's sad that the kernel will now end up calling the boards something that's used nowhere else, even by StarFive :/ But yeah, I guess vA and vB are a little easier to read.

Nothing has been released with that name so AFAIU we can change it still. If you sort it out today/tomorrow I'll try get it to Arnd before the merge window opens...

I might've jumped the gun a bit here, I thought that it'd been changed to what you (Emil) had suggested.

Quoted 40 lines · Conor Dooley

Quoted 38 lines · Emil Renner Berthing

Quoted 25 lines · Hal Feng

Quoted 18 lines · Emil Renner Berthing

Review

Quoted 2 lines · Hal Feng

(quoted diff) +2 -0

+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

Quoted 5 lines

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

Quoted 8 lines

The version A board has reached the end of life. As far as I know, the version B board will not update also unless there are some important requirements and StarFive decides to update. Furthermore, it's too late to change the compatible as patch 1 was already accepted. Will it be easier to read if I modify it as below?

        model = "StarFive VisionFive 2 vB";
        compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Oh, that's sad that the kernel will now end up calling the boards something that's used nowhere else, even by StarFive :/ But yeah, I guess vA and vB are a little easier to read.

Quoted 6 lines

Nothing has been released with that name so AFAIU we can change it still. If you sort it out today/tomorrow I'll try get it to Arnd before the merge window opens...

I might've jumped the gun a bit here, I thought that it'd been changed to what you (Emil) had suggested.

-- >8 --
From 4d44e8a83716d1caa314f25a95bd21ac8904909e Mon Sep 17 00:00:00 2001
From: Conor Dooley <[email protected]>
Date: Thu, 16 Feb 2023 09:58:22 +0000
Subject: [PATCH] dt-bindings: riscv: correct starfive visionfive 2 compatibles

Using "va" and "vb" doesn't match what's written on the board, or the communications from StarFive.
Switching to using the silkscreened version number will ease confusion & the risk of another spin of the board containing a "conflicting" version identifier.

Suggested-by Emil Renner Berthing <[email protected]>

Fixes 97b7ed072784 ("dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board")

Signed-off-by Conor Dooley <[email protected]>

---
 Documentation/devicetree/bindings/riscv/starfive.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/riscv/starfive.yaml +2 -3

index 60c7c03fcdce..cc4d92f0a1bf 100644
@@ -26,8 +26,8 @@ properties:
 
       - items:
           - enum:
-              - starfive,visionfive-2-va
-              - starfive,visionfive-2-vb
+              - starfive,visionfive-2-v1.2a
+              - starfive,visionfive-2-v1.3b
           - const: starfive,jh7110
 
 additionalProperties: true
--

2.39.0

Quoted 46 lines · Conor Dooley

Quoted 44 lines · Conor Dooley

Quoted 32 lines · Emil Renner Berthing

Quoted 31 lines · Hal Feng

Quoted 18 lines · Emil Renner Berthing

Review

Quoted 2 lines · Hal Feng

(quoted diff) +2 -0

+       model = "StarFive VisionFive 2 VB";
+       compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Hi Hal,

I just want to double check, is "VisionFive 2 VA" / "visoinfive-2-va" and "VisionFive 2 VB" / "visionfive-2-vb" really what you want? I still think having these names match what is printed on the silkscreen makes it a lot easier for everybody. Even your own releases calls the boards "v1.2A" and "v1.3B":
https://github.com/starfive-tech/VisionFive2/releases/

So I'd suggest
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";

Quoted 5 lines

I haven't seen these "VA" and "VB" anywhere else, so if you don't want the version numbers and can promise that there will be no incompatible future revisions of the boards then maybe just drop the "V". Eg. model = "StarFive VisionFive 2 B";
compatible = "starfive,visionfive-2-b", "starfive,jh7110";

The version A board has reached the end of life. As far as I know, the version B board will not update also unless there are some important requirements and StarFive decides to update. Furthermore, it's too late to change the compatible as patch 1 was already accepted. Will it be easier to read if I modify it as below?

Quoted 6 lines

Quoted 2 lines

        model = "StarFive VisionFive 2 vB";
        compatible = "starfive,visionfive-2-vb", "starfive,jh7110";

Oh, that's sad that the kernel will now end up calling the boards something that's used nowhere else, even by StarFive :/ But yeah, I guess vA and vB are a little easier to read.

Nothing has been released with that name so AFAIU we can change it still. If you sort it out today/tomorrow I'll try get it to Arnd before the merge window opens...

Quoted 2 lines

Quoted 2 lines

I might've jumped the gun a bit here, I thought that it'd been changed to what you (Emil) had suggested.

No, I'm sorry for being late here. The below definitely looks better to me.

Hal, would you be fine with this change?

Quoted 40 lines

-- >8 --
From 4d44e8a83716d1caa314f25a95bd21ac8904909e Mon Sep 17 00:00:00 2001
From: Conor Dooley <[email protected]>
Date: Thu, 16 Feb 2023 09:58:22 +0000
Subject: [PATCH] dt-bindings: riscv: correct starfive visionfive 2 compatibles

Using "va" and "vb" doesn't match what's written on the board, or the communications from StarFive.
Switching to using the silkscreened version number will ease confusion & the risk of another spin of the board containing a "conflicting" version identifier.

Suggested-by Emil Renner Berthing <[email protected]>

Fixes 97b7ed072784 ("dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board")

Signed-off-by Conor Dooley <[email protected]>

---
 Documentation/devicetree/bindings/riscv/starfive.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/riscv/starfive.yaml +2 -3

index 60c7c03fcdce..cc4d92f0a1bf 100644
@@ -26,8 +26,8 @@ properties:
 
       - items:
           - enum:
-              - starfive,visionfive-2-va
-              - starfive,visionfive-2-vb
+              - starfive,visionfive-2-v1.2a
+              - starfive,visionfive-2-v1.3b
           - const: starfive,jh7110
 
 additionalProperties: true
--

2.39.0

Quoted 6 lines · Emil Renner Berthing

On Thu, 16 Feb 2023 at 11:09, Conor Dooley <[email protected]> wrote:

No, I'm sorry for being late here. The below definitely looks better to me.

Hal, would you be fine with this change?

I'm fine with this. It will be more exact. Thanks.

Quoted 38 lines

Quoted 38 lines

-- >8 --
From 4d44e8a83716d1caa314f25a95bd21ac8904909e Mon Sep 17 00:00:00 2001
From: Conor Dooley <[email protected]>
Date: Thu, 16 Feb 2023 09:58:22 +0000
Subject: [PATCH] dt-bindings: riscv: correct starfive visionfive 2 compatibles

Using "va" and "vb" doesn't match what's written on the board, or the communications from StarFive.
Switching to using the silkscreened version number will ease confusion & the risk of another spin of the board containing a "conflicting" version identifier.

Suggested-by Emil Renner Berthing <[email protected]>

Fixes 97b7ed072784 ("dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board")

Signed-off-by Conor Dooley <[email protected]>

---
 Documentation/devicetree/bindings/riscv/starfive.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/riscv/starfive.yaml +2 -3

index 60c7c03fcdce..cc4d92f0a1bf 100644
@@ -26,8 +26,8 @@ properties:
 
       - items:
           - enum:
-              - starfive,visionfive-2-va
-              - starfive,visionfive-2-vb
+              - starfive,visionfive-2-v1.2a
+              - starfive,visionfive-2-v1.3b
           - const: starfive,jh7110
 
 additionalProperties: true
--

2.39.0

This patch series adds basic device tree support for StarFive JH7110 SoC. This patch series depends on series [1] and [2]. You can simply get or review the patches at the link [3].
Emil Renner Berthing (7):
dt-bindings: riscv: Add StarFive JH7110 SoC and VisionFive 2 board

dt-bindings: timer: Add StarFive JH7110 clint
dt-bindings: interrupt-controller: Add StarFive JH7110 plic

dt-bindings: sifive,ccache0: Support StarFive JH7110 SoC
soc: sifive: ccache: Add StarFive JH7110 support

riscv: dts: starfive: Add initial StarFive JH7110 device tree
riscv: dts: starfive: Add StarFive JH7110 VisionFive 2 board device
tree

On Tue, Dec 20, 2022 at 09:12:40AM +0800, Hal Feng wrote:
The DT is waiting for the clock/reset & pinctrl binding headers anyway,

Quoted 2 lines · Conor Dooley

On Tue, Dec 20, 2022 at 09:12:40AM +0800, Hal Feng wrote:
The DT is waiting for the clock/reset & pinctrl binding headers anyway,

Which were sent with build warnings/errors...