Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
module which is powered by T-HEAD's light(a.k.a TH1520) SoC. Add
minimal device tree files for the core module and the development
board.
Support basic uart/gpio/dmac drivers, so supports booting to a basic
shell.
Jisheng Zhang (5):
irqchip/sifive-plic: Support T-HEAD's C910 PLIC
riscv: Add the T-HEAD SoC family Kconfig option
riscv: dts: add initial T-HEAD light SoC device tree
riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
MAINTAINERS: add entry for T-HEAD RISC-V SoC
.../sifive,plic-1.0.0.yaml | 4 +
MAINTAINERS | 6 +
arch/riscv/Kconfig.socs | 6 +
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/thead/Makefile | 2 +
.../dts/thead/light-lichee-module-4a.dtsi | 38 ++
.../boot/dts/thead/light-lichee-pi-4a.dts | 32 ++
arch/riscv/boot/dts/thead/light.dtsi | 454 ++++++++++++++++++
drivers/irqchip/irq-sifive-plic.c | 1 +
9 files changed, 544 insertions(+)
create mode 100644 arch/riscv/boot/dts/thead/Makefile
create mode 100644 arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
create mode 100644 arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
create mode 100644 arch/riscv/boot/dts/thead/light.dtsi
--
2.40.0
The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
access from S-mode, but it doesn't need the edge quirk.
Signed-off-by: Jisheng Zhang <[email protected]>
---
.../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4 ++++
drivers/irqchip/irq-sifive-plic.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index f75736a061af..64b43a3c3748 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -62,6 +62,10 @@ properties:
- starfive,jh7110-plic
- canaan,k210-plic
- const: sifive,plic-1.0.0
+ - items:
+ - enum:
+ - thead,light-plic
+ - const: thead,c910-plic
- items:
- enum:
- allwinner,sun20i-d1-plic
diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index e1484905b7bd..71afa2a584d9 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -569,6 +569,7 @@ static int __init plic_init(struct device_node *node,
}
IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
+IRQCHIP_DECLARE(thead_c910_plic, "thead,c910-plic", plic_init);
IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
static int __init plic_edge_init(struct device_node *node,
--
2.40.0
Add initial device tree for the light(a.k.a TH1520) RISC-V SoC by
T-HEAD.
Signed-off-by: Jisheng Zhang <[email protected]>
---
arch/riscv/boot/dts/thead/light.dtsi | 454 +++++++++++++++++++++++++++
1 file changed, 454 insertions(+)
create mode 100644 arch/riscv/boot/dts/thead/light.dtsi
diff --git a/arch/riscv/boot/dts/thead/light.dtsi b/arch/riscv/boot/dts/thead/light.dtsi
new file mode 100644
index 000000000000..cdf6d8b04d22
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/light.dtsi
@@ -0,0 +1,454 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Alibaba Group Holding Limited.
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+/ {
+ compatible = "thead,light";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <3000000>;
+
+ c910_0: cpu@0 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <0>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu0_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_1: cpu@1 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <1>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu1_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_2: cpu@2 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <2>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu2_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ c910_3: cpu@3 {
+ compatible = "thead,c910", "riscv";
+ device_type = "cpu";
+ riscv,isa = "rv64imafdc";
+ reg = <3>;
+ i-cache-block-size = <64>;
+ i-cache-size = <65536>;
+ i-cache-sets = <512>;
+ d-cache-block-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-sets = <512>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu3_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&c910_0>;
+ };
+
+ core1 {
+ cpu = <&c910_1>;
+ };
+
+ core2 {
+ cpu = <&c910_2>;
+ };
+
+ core3 {
+ cpu = <&c910_3>;
+ };
+ };
+ };
+
+ l2_cache: l2-cache {
+ compatible = "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-size = <1048576>;
+ cache-sets = <1024>;
+ cache-unified;
+ };
+ };
+
+ osc: oscillator {
+ compatible = "fixed-clock";
+ clock-output-names = "osc_24m";
+ #clock-cells = <0>;
+ };
+
+ osc_32k: 32k-oscillator {
+ compatible = "fixed-clock";
+ clock-output-names = "osc_32k";
+ #clock-cells = <0>;
+ };
+
+ apb_clk: apb-clk-clock {
+ compatible = "fixed-clock";
+ clock-output-names = "apb_clk";
+ #clock-cells = <0>;
+ };
+
+ uart_sclk: uart-sclk-clock {
+ compatible = "fixed-clock";
+ clock-output-names = "uart_sclk";
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&plic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ reset: reset-sample {
+ compatible = "thead,reset-sample";
+ entry-reg = <0xff 0xff019050>;
+ entry-cnt = <4>;
+ control-reg = <0xff 0xff015004>;
+ control-val = <0x1c>;
+ csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
+ };
+
+ plic: interrupt-controller@ffd8000000 {
+ compatible = "thead,c910-plic";
+ reg = <0xff 0xd8000000 0x0 0x01000000>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
+ <&cpu1_intc 11>, <&cpu1_intc 9>,
+ <&cpu2_intc 11>, <&cpu2_intc 9>,
+ <&cpu3_intc 11>, <&cpu3_intc 9>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ riscv,ndev = <240>;
+ };
+
+ clint: timer@ffdc000000 {
+ compatible = "thead,c900-clint";
+ reg = <0xff 0xdc000000 0x0 0x00010000>;
+ 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>;
+ };
+
+ uart0: serial@ffe7014000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7014000 0x0 0x4000>;
+ interrupts = <36>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart1: serial@ffe7f00000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7f00000 0x0 0x4000>;
+ interrupts = <37>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart3: serial@ffe7f04000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xe7f04000 0x0 0x4000>;
+ interrupts = <39>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ gpio2: gpio@ffe7f34000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xe7f34000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portc: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <58>;
+ };
+ };
+
+ gpio3: gpio@ffe7f38000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xe7f38000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portd: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <59>;
+ };
+ };
+
+ gpio0: gpio@ffec005000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xec005000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ porta: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <56>;
+ };
+ };
+
+ gpio1: gpio@ffec006000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xec006000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portb: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <57>;
+ };
+ };
+
+ uart2: serial@ffec010000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xec010000 0x0 0x4000>;
+ interrupts = <38>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ dmac0: dmac@ffefc00000 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0xff 0xefc00000 0x0 0x1000>;
+ interrupts = <27>;
+ clocks = <&apb_clk>, <&apb_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ snps,block-size = <65536 65536 65536 65536>;
+ snps,priority = <0 1 2 3>;
+ snps,dma-masters = <1>;
+ snps,data-width = <4>;
+ snps,axi-max-burst-len = <16>;
+ status = "disabled";
+ };
+
+ timer0: timer@ffefc32000 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32000 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <16>;
+ status = "disabled";
+ };
+
+ timer1: timer@ffefc32014 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32014 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <17>;
+ status = "disabled";
+ };
+
+ timer2: timer@ffefc32028 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc32028 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <18>;
+ status = "disabled";
+ };
+
+ timer3: timer@ffefc3203c {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xefc3203c 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <19>;
+ status = "disabled";
+ };
+
+ uart4: serial@fff7f08000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xf7f08000 0x0 0x4000>;
+ interrupts = <40>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart5: serial@fff7f0c000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xff 0xf7f0c000 0x0 0x4000>;
+ interrupts = <41>;
+ clocks = <&uart_sclk>;
+ clock-names = "baudclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ timer4: timer@ffffc33000 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33000 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <20>;
+ status = "disabled";
+ };
+
+ timer5: timer@ffffc33014 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33014 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <21>;
+ status = "disabled";
+ };
+
+ timer6: timer@ffffc33028 {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc33028 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <22>;
+ status = "disabled";
+ };
+
+ timer7: timer@ffffc3303c {
+ compatible = "snps,dw-apb-timer";
+ reg = <0xff 0xffc3303c 0x0 0x14>;
+ clocks = <&apb_clk>;
+ clock-names = "timer";
+ interrupts = <23>;
+ status = "disabled";
+ };
+
+ ao_gpio0: gpio@fffff41000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xfff41000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ porte: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <76>;
+ };
+ };
+
+ ao_gpio1: gpio@fffff52000 {
+ compatible = "snps,dw-apb-gpio";
+ reg = <0xff 0xfff52000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ portf: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <55>;
+ };
+ };
+ };
+};
--
2.40.0
I would like to temporarily maintain the T-HEAD RISC-V SoC support.
Signed-off-by: Jisheng Zhang <[email protected]>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e0b87d5aa2e..e1e51accec4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18155,6 +18155,12 @@ T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
F: Documentation/devicetree/bindings/riscv/
F: arch/riscv/boot/dts/
+RISC-V THEAD SoC SUPPORT
+M: Jisheng Zhang <[email protected]>
+L: [email protected]
+S: Maintained
+F: arch/riscv/boot/dts/thead/
+
RNBD BLOCK DRIVERS
M: Md. Haris Iqbal <[email protected]>
M: Jack Wang <[email protected]>
--
2.40.0
Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
module which is powered by T-HEAD's light(a.k.a TH1520) SoC. Add
minimal device tree files for the core module and the development
board.
Support basic uart/gpio/dmac drivers, so supports booting to a basic
shell.
Signed-off-by: Jisheng Zhang <[email protected]>
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/thead/Makefile | 2 +
.../dts/thead/light-lichee-module-4a.dtsi | 38 +++++++++++++++++++
.../boot/dts/thead/light-lichee-pi-4a.dts | 32 ++++++++++++++++
4 files changed, 73 insertions(+)
create mode 100644 arch/riscv/boot/dts/thead/Makefile
create mode 100644 arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
create mode 100644 arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index f0d9f89054f8..1e884868ccba 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -2,6 +2,7 @@
subdir-y += allwinner
subdir-y += sifive
subdir-y += starfive
+subdir-y += thead
subdir-y += canaan
subdir-y += microchip
subdir-y += renesas
diff --git a/arch/riscv/boot/dts/thead/Makefile b/arch/riscv/boot/dts/thead/Makefile
new file mode 100644
index 000000000000..9e00acc714cc
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_THEAD) += light-lichee-pi-4a.dtb
diff --git a/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
new file mode 100644
index 000000000000..24c9971e0fb5
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "light.dtsi"
+
+/ {
+ model = "Sipeed Lichee Module 4A";
+ compatible = "sipeed,lichee-module-4a", "thead,light";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x00000000 0x2 0x00000000>;
+ };
+};
+
+&osc {
+ clock-frequency = <24000000>;
+};
+
+&osc_32k {
+ clock-frequency = <32768>;
+};
+
+&apb_clk {
+ clock-frequency = <62500000>;
+};
+
+&uart_sclk {
+ clock-frequency = <100000000>;
+};
+
+&dmac0 {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
new file mode 100644
index 000000000000..4f0ba2149d2d
--- /dev/null
+++ b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang <[email protected]>
+ */
+
+#include "light-lichee-module-4a.dtsi"
+
+/ {
+ model = "Sipeed Lichee Pi 4A";
+ compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", "thead,light";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ gpio3 = &gpio3;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.40.0
The first SoC in the T-HEAD series is light(a.k.a th1520), containing
quad T-HEAD C910 cores.
Signed-off-by: Jisheng Zhang <[email protected]>
---
arch/riscv/Kconfig.socs | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 1cf69f958f10..ce10a38dff37 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -41,6 +41,12 @@ config ARCH_SUNXI
This enables support for Allwinner sun20i platform hardware,
including boards based on the D1 and D1s SoCs.
+config ARCH_THEAD
+ bool "T-HEAD RISC-V SoCs"
+ select ERRATA_THEAD
+ help
+ This enables support for the RISC-V based T-HEAD SoCs.
+
config ARCH_VIRT
def_bool SOC_VIRT
--
2.40.0
On Mon, May 08, 2023 at 02:23:01AM +0800, Jisheng Zhang wrote:
> The first SoC in the T-HEAD series is light(a.k.a th1520), containing
> quad T-HEAD C910 cores.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> arch/riscv/Kconfig.socs | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index 1cf69f958f10..ce10a38dff37 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -41,6 +41,12 @@ config ARCH_SUNXI
> This enables support for Allwinner sun20i platform hardware,
> including boards based on the D1 and D1s SoCs.
>
> +config ARCH_THEAD
Could you please add a defconfig patch, adding this option, so that we
build support for this platform by default?
Thanks,
Conor.
> + bool "T-HEAD RISC-V SoCs"
> + select ERRATA_THEAD
> + help
> + This enables support for the RISC-V based T-HEAD SoCs.
> +
> config ARCH_VIRT
> def_bool SOC_VIRT
>
> --
> 2.40.0
>
Hey Jisheng,
On Mon, May 08, 2023 at 02:23:00AM +0800, Jisheng Zhang wrote:
> The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
> access from S-mode, but it doesn't need the edge quirk.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4 ++++
> drivers/irqchip/irq-sifive-plic.c | 1 +
dt-bindings changes need to be in their own patch.
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index f75736a061af..64b43a3c3748 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -62,6 +62,10 @@ properties:
> - starfive,jh7110-plic
> - canaan,k210-plic
> - const: sifive,plic-1.0.0
> + - items:
> + - enum:
> + - thead,light-plic
If "light" is a code name, but "TH1520" is what this is known as to the
wider world, I think we should use thead,th1520-plic here.
Thanks,
Conor.
> + - const: thead,c910-plic
> - items:
> - enum:
> - allwinner,sun20i-d1-plic
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index e1484905b7bd..71afa2a584d9 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -569,6 +569,7 @@ static int __init plic_init(struct device_node *node,
> }
>
> IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> +IRQCHIP_DECLARE(thead_c910_plic, "thead,c910-plic", plic_init);
> IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
>
> static int __init plic_edge_init(struct device_node *node,
> --
> 2.40.0
>
Hey Jisheng,
On Mon, May 08, 2023 at 02:23:04AM +0800, Jisheng Zhang wrote:
> I would like to temporarily maintain the T-HEAD RISC-V SoC support.
What does "temporarily" mean?
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7e0b87d5aa2e..e1e51accec4f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18155,6 +18155,12 @@ T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> F: Documentation/devicetree/bindings/riscv/
> F: arch/riscv/boot/dts/
>
> +RISC-V THEAD SoC SUPPORT
Miniscule nit, "T-HEAD"?
Cheers,
Conor.
> +M: Jisheng Zhang <[email protected]>
> +L: [email protected]
> +S: Maintained
> +F: arch/riscv/boot/dts/thead/
> +
> RNBD BLOCK DRIVERS
> M: Md. Haris Iqbal <[email protected]>
> M: Jack Wang <[email protected]>
> --
> 2.40.0
>
Hey Jisheng,
On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> + c910_0: cpu@0 {
> + compatible = "thead,c910", "riscv";
> + device_type = "cpu";
> + riscv,isa = "rv64imafdc";
Does this support more than "rv64imafdc"?
I assume there's some _xtheadfoo extensions that it does support,
although I am not sure how we are proceeding with those - Heiko might
have a more nuanced take.
> + reset: reset-sample {
> + compatible = "thead,reset-sample";
What is a "reset-sample"?
> + entry-reg = <0xff 0xff019050>;
> + entry-cnt = <4>;
> + control-reg = <0xff 0xff015004>;
> + control-val = <0x1c>;
> + csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
> + };
> +
> + plic: interrupt-controller@ffd8000000 {
> + compatible = "thead,c910-plic";
> + reg = <0xff 0xd8000000 0x0 0x01000000>;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> + <&cpu1_intc 11>, <&cpu1_intc 9>,
> + <&cpu2_intc 11>, <&cpu2_intc 9>,
> + <&cpu3_intc 11>, <&cpu3_intc 9>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + riscv,ndev = <240>;
> + };
> +
> + clint: timer@ffdc000000 {
> + compatible = "thead,c900-clint";
"c900"? That a typo or intentional. Hard to tell since this compatible
is undocumented ;)
> + reg = <0xff 0xdc000000 0x0 0x00010000>;
> + 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>;
> + };
> +
> + uart0: serial@ffe7014000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff 0xe7014000 0x0 0x4000>;
> + interrupts = <36>;
> + clocks = <&uart_sclk>;
> + clock-names = "baudclk";
dtbs_check complains about this clock name.
> +
> + dmac0: dmac@ffefc00000 {
dma-controller@
As I mentioned in the other patch, please clean up the dtbs_check
complaints for v2.
Cheers,
Conor.
Hey Jisheng,
On Mon, May 08, 2023 at 02:23:03AM +0800, Jisheng Zhang wrote:
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's light(a.k.a TH1520) SoC. Add
> minimal device tree files for the core module and the development
> board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
There are quite a lot of dtbs_check warnings etc produced by this patch.
RISC-V is *almost* W=1 clean for dtbs_check & I'd like to get that to
clean once the non-coherent DMA situation for Renesas is sorted out.
That said, I think some of the issues I noticed will crop up at the
default warning level too.
Please fix all of the W=1 complaints from dtbs_check, which will require
the creation of some additional dt-bindings.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/thead/Makefile | 2 +
> .../dts/thead/light-lichee-module-4a.dtsi | 38 +++++++++++++++++++
> .../boot/dts/thead/light-lichee-pi-4a.dts | 32 ++++++++++++++++
> 4 files changed, 73 insertions(+)
> create mode 100644 arch/riscv/boot/dts/thead/Makefile
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
As I mentioned in one of the earlier patches, I don't think using
"light" here is all that great. I would much rather see "th1520" used
instead.
Thanks,
Conor.
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index f0d9f89054f8..1e884868ccba 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -2,6 +2,7 @@
> subdir-y += allwinner
> subdir-y += sifive
> subdir-y += starfive
> +subdir-y += thead
> subdir-y += canaan
> subdir-y += microchip
> subdir-y += renesas
> diff --git a/arch/riscv/boot/dts/thead/Makefile b/arch/riscv/boot/dts/thead/Makefile
> new file mode 100644
> index 000000000000..9e00acc714cc
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_THEAD) += light-lichee-pi-4a.dtb
> diff --git a/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> new file mode 100644
> index 000000000000..24c9971e0fb5
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang <[email protected]>
> + */
> +
> +/dts-v1/;
> +
> +#include "light.dtsi"
> +
> +/ {
> + model = "Sipeed Lichee Module 4A";
> + compatible = "sipeed,lichee-module-4a", "thead,light";
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x00000000 0x2 0x00000000>;
> + };
> +};
> +
> +&osc {
> + clock-frequency = <24000000>;
> +};
> +
> +&osc_32k {
> + clock-frequency = <32768>;
> +};
> +
> +&apb_clk {
> + clock-frequency = <62500000>;
> +};
> +
> +&uart_sclk {
> + clock-frequency = <100000000>;
> +};
> +
> +&dmac0 {
> + status = "okay";
> +};
> diff --git a/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
> new file mode 100644
> index 000000000000..4f0ba2149d2d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang <[email protected]>
> + */
> +
> +#include "light-lichee-module-4a.dtsi"
> +
> +/ {
> + model = "Sipeed Lichee Pi 4A";
> + compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", "thead,light";
> +
> + aliases {
> + gpio0 = &gpio0;
> + gpio1 = &gpio1;
> + gpio2 = &gpio2;
> + gpio3 = &gpio3;
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + serial4 = &uart4;
> + serial5 = &uart5;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> --
> 2.40.0
>
在 2023-05-08星期一的 02:23 +0800，Jisheng Zhang写道：
> The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
> access from S-mode, but it doesn't need the edge quirk.
No, the PLIC controller seems to be the same between C906 and C910,
which has level/edge selectable via external signal.
See openc906 and openc910 repositories, especially the documents with
it: 玄铁C9{06,10}集成手册.pdf .
In addition, such problem won't arise when the system uses only level-
triggered interrupts.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4
> ++++
> drivers/irqchip/irq-sifive-plic.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.yaml
> b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-
> 1.0.0.yaml
> index f75736a061af..64b43a3c3748 100644
> --- a/Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.yaml
> @@ -62,6 +62,10 @@ properties:
> - starfive,jh7110-plic
> - canaan,k210-plic
> - const: sifive,plic-1.0.0
> + - items:
> + - enum:
> + - thead,light-plic
> + - const: thead,c910-plic
> - items:
> - enum:
> - allwinner,sun20i-d1-plic
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-
> sifive-plic.c
> index e1484905b7bd..71afa2a584d9 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -569,6 +569,7 @@ static int __init plic_init(struct device_node
> *node,
> }
>
> IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> +IRQCHIP_DECLARE(thead_c910_plic, "thead,c910-plic", plic_init);
> IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for
> legacy systems */
>
> static int __init plic_edge_init(struct device_node *node,
在 2023-05-07星期日的 22:35 +0100，Conor Dooley写道：
> Hey Jisheng,
>
> On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
>
> > + c910_0: cpu@0 {
> > + compatible = "thead,c910", "riscv";
> > + device_type = "cpu";
> > + riscv,isa = "rv64imafdc";
>
> Does this support more than "rv64imafdc"?
> I assume there's some _xtheadfoo extensions that it does support,
> although I am not sure how we are proceeding with those - Heiko might
> have a more nuanced take.
>
> > + reset: reset-sample {
> > + compatible = "thead,reset-sample";
>
> What is a "reset-sample"?
>
> > + entry-reg = <0xff 0xff019050>;
> > + entry-cnt = <4>;
> > + control-reg = <0xff 0xff015004>;
> > + control-val = <0x1c>;
> > + csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3
> > 0x7c5 0x7cc>;
> > + };
> > +
> > + plic: interrupt-controller@ffd8000000 {
> > + compatible = "thead,c910-plic";
> > + reg = <0xff 0xd8000000 0x0 0x01000000>;
> > + interrupts-extended = <&cpu0_intc 11>,
> > <&cpu0_intc 9>,
> > + <&cpu1_intc 11>,
> > <&cpu1_intc 9>,
> > + <&cpu2_intc 11>,
> > <&cpu2_intc 9>,
> > + <&cpu3_intc 11>,
> > <&cpu3_intc 9>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + riscv,ndev = <240>;
> > + };
> > +
> > + clint: timer@ffdc000000 {
> > + compatible = "thead,c900-clint";
>
> "c900"? That a typo or intentional. Hard to tell since this
> compatible
> is undocumented ;)
Intentional, for supporting both C906 and C910.
However, as we discussed in some binding patches, there should be a DT
binding string per chip.
So here should be "thead,light-clint", "thead,c900-clint".
(Or use th1520, the marketing name, instead of light, the codename)
P.S. which one is preferred by DT binding maintainers, the marketing
name or the codename?
>
> > + reg = <0xff 0xdc000000 0x0 0x00010000>;
> > + 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>;
> > + };
> > +
> > + uart0: serial@ffe7014000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0xff 0xe7014000 0x0 0x4000>;
> > + interrupts = <36>;
> > + clocks = <&uart_sclk>;
> > + clock-names = "baudclk";
>
> dtbs_check complains about this clock name.
> > +
> > + dmac0: dmac@ffefc00000 {
>
> dma-controller@
>
> As I mentioned in the other patch, please clean up the dtbs_check
> complaints for v2.
>
> Cheers,
> Conor.
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
F.Y.I Wei Fu <[email protected]>
On Mon, May 8, 2023 at 2:34 AM Jisheng Zhang <[email protected]> wrote:
>
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's light(a.k.a TH1520) SoC. Add
> minimal device tree files for the core module and the development
> board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
>
> Jisheng Zhang (5):
> irqchip/sifive-plic: Support T-HEAD's C910 PLIC
> riscv: Add the T-HEAD SoC family Kconfig option
> riscv: dts: add initial T-HEAD light SoC device tree
> riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
> MAINTAINERS: add entry for T-HEAD RISC-V SoC
>
> .../sifive,plic-1.0.0.yaml | 4 +
> MAINTAINERS | 6 +
> arch/riscv/Kconfig.socs | 6 +
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/thead/Makefile | 2 +
> .../dts/thead/light-lichee-module-4a.dtsi | 38 ++
> .../boot/dts/thead/light-lichee-pi-4a.dts | 32 ++
> arch/riscv/boot/dts/thead/light.dtsi | 454 ++++++++++++++++++
> drivers/irqchip/irq-sifive-plic.c | 1 +
> 9 files changed, 544 insertions(+)
> create mode 100644 arch/riscv/boot/dts/thead/Makefile
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
> create mode 100644 arch/riscv/boot/dts/thead/light.dtsi
>
> --
> 2.40.0
>
--
Best Regards
Guo Ren
On Mon, May 8, 2023 at 2:34 AM Jisheng Zhang <[email protected]> wrote:
>
> I would like to temporarily maintain the T-HEAD RISC-V SoC support.
Wei Fu is working on TH1520, and maybe you could have a discussion
with him? Thx.
F.Y.I
Wei Fu <[email protected]>
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7e0b87d5aa2e..e1e51accec4f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18155,6 +18155,12 @@ T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> F: Documentation/devicetree/bindings/riscv/
> F: arch/riscv/boot/dts/
>
> +RISC-V THEAD SoC SUPPORT
> +M: Jisheng Zhang <[email protected]>
> +L: [email protected]
> +S: Maintained
> +F: arch/riscv/boot/dts/thead/
> +
> RNBD BLOCK DRIVERS
> M: Md. Haris Iqbal <[email protected]>
> M: Jack Wang <[email protected]>
> --
> 2.40.0
>
--
Best Regards
Guo Ren
On Mon, May 8, 2023 at 2:34 AM Jisheng Zhang <[email protected]> wrote:
>
> The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
> access from S-mode, but it doesn't need the edge quirk.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4 ++++
> drivers/irqchip/irq-sifive-plic.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index f75736a061af..64b43a3c3748 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -62,6 +62,10 @@ properties:
> - starfive,jh7110-plic
> - canaan,k210-plic
> - const: sifive,plic-1.0.0
> + - items:
> + - enum:
> + - thead,light-plic
> + - const: thead,c910-plic
> - items:
> - enum:
> - allwinner,sun20i-d1-plic
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index e1484905b7bd..71afa2a584d9 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -569,6 +569,7 @@ static int __init plic_init(struct device_node *node,
> }
>
> IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> +IRQCHIP_DECLARE(thead_c910_plic, "thead,c910-plic", plic_init);
> IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
>
> static int __init plic_edge_init(struct device_node *node,
> --
> 2.40.0
>
opensbi needs thead,c900-plic, and we could put multi compatible name
in the dts. So, it's no need here.
Another question, Could we change the name of Sifive to RISC-V when
"cat /proc/interrupts" ?
diff --git a/drivers/irqchip/irq-sifive-plic.c
b/drivers/irqchip/irq-sifive-plic.c
index ff47bd0dec45..b5844d784bfa 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -177,7 +177,7 @@ static int plic_set_affinity(struct irq_data *d,
#endif
static struct irq_chip plic_edge_chip = {
- .name = "SiFive PLIC",
+ .name = "RISC-V PLIC",
.irq_enable = plic_irq_enable,
.irq_disable = plic_irq_disable,
.irq_ack = plic_irq_eoi,
@@ -192,7 +192,7 @@ static struct irq_chip plic_edge_chip = {
};
static struct irq_chip plic_chip = {
- .name = "SiFive PLIC",
+ .name = "RISC-V PLIC",
.irq_enable = plic_irq_enable,
.irq_disable = plic_irq_disable,
.irq_mask = plic_irq_mask,
--
Best Regards
Guo Ren
On Mon, May 08, 2023 at 02:42:10PM +0800, Guo Ren wrote:
> On Mon, May 8, 2023 at 5:22 AM Conor Dooley <[email protected]> wrote:
> >
> > On Mon, May 08, 2023 at 02:23:01AM +0800, Jisheng Zhang wrote:
> > > The first SoC in the T-HEAD series is light(a.k.a th1520), containing
> > > quad T-HEAD C910 cores.
> > >
> > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > ---
> > > arch/riscv/Kconfig.socs | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > index 1cf69f958f10..ce10a38dff37 100644
> > > --- a/arch/riscv/Kconfig.socs
> > > +++ b/arch/riscv/Kconfig.socs
> > > @@ -41,6 +41,12 @@ config ARCH_SUNXI
> > > This enables support for Allwinner sun20i platform hardware,
> > > including boards based on the D1 and D1s SoCs.
> > >
> > > +config ARCH_THEAD
> >
> > Could you please add a defconfig patch, adding this option, so that we
> > build support for this platform by default?
> Yes, but it's another patch, see: 'commit eb20e7cb91ba ("riscv:
> defconfig: Enable the Allwinner D1 platform and drivers")'
But that's ARCH_SUNXI for the Allwinner D1. If the TH1520 is a
first-party SoC, and not an Allwinner product, it needs a new Kconfig
entry etc.
If it is an Allwinner, then the dts etc should be in the Allwinner
directory too.
Cheers,
Conor.
On Mon, May 8, 2023 at 2:34 AM Jisheng Zhang <[email protected]> wrote:
>
> Sipeed's Lichee Pi 4A development board uses Lichee Module 4A core
> module which is powered by T-HEAD's light(a.k.a TH1520) SoC. Add
No light, just th1520.
> minimal device tree files for the core module and the development
> board.
>
> Support basic uart/gpio/dmac drivers, so supports booting to a basic
> shell.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/thead/Makefile | 2 +
> .../dts/thead/light-lichee-module-4a.dtsi | 38 +++++++++++++++++++
> .../boot/dts/thead/light-lichee-pi-4a.dts | 32 ++++++++++++++++
> 4 files changed, 73 insertions(+)
> create mode 100644 arch/riscv/boot/dts/thead/Makefile
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> create mode 100644 arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index f0d9f89054f8..1e884868ccba 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -2,6 +2,7 @@
> subdir-y += allwinner
> subdir-y += sifive
> subdir-y += starfive
> +subdir-y += thead
> subdir-y += canaan
> subdir-y += microchip
> subdir-y += renesas
> diff --git a/arch/riscv/boot/dts/thead/Makefile b/arch/riscv/boot/dts/thead/Makefile
> new file mode 100644
> index 000000000000..9e00acc714cc
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_THEAD) += light-lichee-pi-4a.dtb
> diff --git a/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> new file mode 100644
> index 000000000000..24c9971e0fb5
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/light-lichee-module-4a.dtsi
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang <[email protected]>
> + */
> +
> +/dts-v1/;
> +
> +#include "light.dtsi"
> +
> +/ {
> + model = "Sipeed Lichee Module 4A";
> + compatible = "sipeed,lichee-module-4a", "thead,light";
no light, th1520
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x00000000 0x2 0x00000000>;
> + };
> +};
> +
> +&osc {
> + clock-frequency = <24000000>;
> +};
> +
> +&osc_32k {
> + clock-frequency = <32768>;
> +};
> +
> +&apb_clk {
> + clock-frequency = <62500000>;
> +};
> +
> +&uart_sclk {
> + clock-frequency = <100000000>;
> +};
> +
> +&dmac0 {
> + status = "okay";
> +};
> diff --git a/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
> new file mode 100644
> index 000000000000..4f0ba2149d2d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/light-lichee-pi-4a.dts
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang <[email protected]>
> + */
> +
> +#include "light-lichee-module-4a.dtsi"
> +
> +/ {
> + model = "Sipeed Lichee Pi 4A";
> + compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", "thead,light";
no light, th1520
> +
> + aliases {
> + gpio0 = &gpio0;
> + gpio1 = &gpio1;
> + gpio2 = &gpio2;
> + gpio3 = &gpio3;
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + serial4 = &uart4;
> + serial5 = &uart5;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> --
> 2.40.0
>
--
Best Regards
Guo Ren
On Mon, May 8, 2023 at 5:22 AM Conor Dooley <[email protected]> wrote:
>
> On Mon, May 08, 2023 at 02:23:01AM +0800, Jisheng Zhang wrote:
> > The first SoC in the T-HEAD series is light(a.k.a th1520), containing
> > quad T-HEAD C910 cores.
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > ---
> > arch/riscv/Kconfig.socs | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > index 1cf69f958f10..ce10a38dff37 100644
> > --- a/arch/riscv/Kconfig.socs
> > +++ b/arch/riscv/Kconfig.socs
> > @@ -41,6 +41,12 @@ config ARCH_SUNXI
> > This enables support for Allwinner sun20i platform hardware,
> > including boards based on the D1 and D1s SoCs.
> >
> > +config ARCH_THEAD
>
> Could you please add a defconfig patch, adding this option, so that we
> build support for this platform by default?
Yes, but it's another patch, see: 'commit eb20e7cb91ba ("riscv:
defconfig: Enable the Allwinner D1 platform and drivers")'
>
> Thanks,
> Conor.
>
> > + bool "T-HEAD RISC-V SoCs"
> > + select ERRATA_THEAD
> > + help
> > + This enables support for the RISC-V based T-HEAD SoCs.
> > +
> > config ARCH_VIRT
> > def_bool SOC_VIRT
> >
> > --
> > 2.40.0
> >
--
Best Regards
Guo Ren
On Mon, May 08, 2023 at 11:32:17AM +0800, Icenowy Zheng wrote:
> P.S. which one is preferred by DT binding maintainers, the marketing
> name or the codename?
I don't see the benefit of using internal product codenames (even if it
did appear on their gitee) over the name by which it'll appear in board
datasheets etc etc.
Cheers,
Conor.
On Mon, May 8, 2023 at 2:53 PM Conor Dooley <[email protected]> wrote:
>
> On Mon, May 08, 2023 at 02:42:10PM +0800, Guo Ren wrote:
> > On Mon, May 8, 2023 at 5:22 AM Conor Dooley <[email protected]> wrote:
> > >
> > > On Mon, May 08, 2023 at 02:23:01AM +0800, Jisheng Zhang wrote:
> > > > The first SoC in the T-HEAD series is light(a.k.a th1520), containing
> > > > quad T-HEAD C910 cores.
> > > >
> > > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > > ---
> > > > arch/riscv/Kconfig.socs | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > > index 1cf69f958f10..ce10a38dff37 100644
> > > > --- a/arch/riscv/Kconfig.socs
> > > > +++ b/arch/riscv/Kconfig.socs
> > > > @@ -41,6 +41,12 @@ config ARCH_SUNXI
> > > > This enables support for Allwinner sun20i platform hardware,
> > > > including boards based on the D1 and D1s SoCs.
> > > >
> > > > +config ARCH_THEAD
> > >
> > > Could you please add a defconfig patch, adding this option, so that we
> > > build support for this platform by default?
>
> > Yes, but it's another patch, see: 'commit eb20e7cb91ba ("riscv:
> > defconfig: Enable the Allwinner D1 platform and drivers")'
>
> But that's ARCH_SUNXI for the Allwinner D1. If the TH1520 is a
> first-party SoC, and not an Allwinner product, it needs a new Kconfig
> entry etc.
> If it is an Allwinner, then the dts etc should be in the Allwinner
> directory too.
Do you mean?
config ARCH_THEAD
def_bool SOC_THEAD
config SOC_THEAD
bool "T-HEAD SoCs"
In defconfig:
+CONFIG_SOC_THEAD=y
>
> Cheers,
> Conor.
--
Best Regards
Guo Ren
On Mon, May 08, 2023 at 02:58:02PM +0800, Guo Ren wrote:
> On Mon, May 8, 2023 at 2:53 PM Conor Dooley <[email protected]> wrote:
> >
> > On Mon, May 08, 2023 at 02:42:10PM +0800, Guo Ren wrote:
> > > On Mon, May 8, 2023 at 5:22 AM Conor Dooley <[email protected]> wrote:
> > > >
> > > > On Mon, May 08, 2023 at 02:23:01AM +0800, Jisheng Zhang wrote:
> > > > > The first SoC in the T-HEAD series is light(a.k.a th1520), containing
> > > > > quad T-HEAD C910 cores.
> > > > >
> > > > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > > > ---
> > > > > arch/riscv/Kconfig.socs | 6 ++++++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > > > index 1cf69f958f10..ce10a38dff37 100644
> > > > > --- a/arch/riscv/Kconfig.socs
> > > > > +++ b/arch/riscv/Kconfig.socs
> > > > > @@ -41,6 +41,12 @@ config ARCH_SUNXI
> > > > > This enables support for Allwinner sun20i platform hardware,
> > > > > including boards based on the D1 and D1s SoCs.
> > > > >
> > > > > +config ARCH_THEAD
> > > >
> > > > Could you please add a defconfig patch, adding this option, so that we
> > > > build support for this platform by default?
> >
> > > Yes, but it's another patch, see: 'commit eb20e7cb91ba ("riscv:
> > > defconfig: Enable the Allwinner D1 platform and drivers")'
> >
> > But that's ARCH_SUNXI for the Allwinner D1. If the TH1520 is a
> > first-party SoC, and not an Allwinner product, it needs a new Kconfig
> > entry etc.
> > If it is an Allwinner, then the dts etc should be in the Allwinner
> > directory too.
> Do you mean?
> config ARCH_THEAD
> def_bool SOC_THEAD
>
> config SOC_THEAD
> bool "T-HEAD SoCs"
>
> In defconfig:
> +CONFIG_SOC_THEAD=y
No, this patch is okay as-is. CONFIG_ARCH_THEAD=y would go into
defconfig in another patch.
Cheers,
Conor.
On Mon, May 08, 2023 at 02:52:29PM +0800, Guo Ren wrote:
> Another question, Could we change the name of Sifive to RISC-V when
> "cat /proc/interrupts" ?
Previously NAKed by Marc as it is ABI:
https://lore.kernel.org/all/[email protected]
Cheers,
Conor.
Am Montag, 8. Mai 2023, 05:32:17 CEST schrieb Icenowy Zheng:
> 在 2023-05-07星期日的 22:35 +0100，Conor Dooley写道：
> > Hey Jisheng,
> >
> > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> >
> > > + c910_0: cpu@0 {
> > > + compatible = "thead,c910", "riscv";
> > > + device_type = "cpu";
> > > + riscv,isa = "rv64imafdc";
> >
> > Does this support more than "rv64imafdc"?
> > I assume there's some _xtheadfoo extensions that it does support,
> > although I am not sure how we are proceeding with those - Heiko might
> > have a more nuanced take.
I guess the interesting question still is, are these part of the isa
string or more of an errata?
The binding currently says
Identifies the specific RISC-V instruction set architecture
supported by the hart. These are documented in the RISC-V
User-Level ISA document, available from
https://riscv.org/specifications/
I guess if we decide to make them part of the isa-string the binding
then should get a paragraph mention _xfoo vendor-extensions too.
Personally, making these part of the ISA string definitly sounds like
the best solution though :-) .
> > > + reset: reset-sample {
> > > + compatible = "thead,reset-sample";
> >
> > What is a "reset-sample"?
> >
> > > + entry-reg = <0xff 0xff019050>;
> > > + entry-cnt = <4>;
> > > + control-reg = <0xff 0xff015004>;
> > > + control-val = <0x1c>;
> > > + csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3
> > > 0x7c5 0x7cc>;
> > > + };
> > > +
> > > + plic: interrupt-controller@ffd8000000 {
> > > + compatible = "thead,c910-plic";
> > > + reg = <0xff 0xd8000000 0x0 0x01000000>;
> > > + interrupts-extended = <&cpu0_intc 11>,
> > > <&cpu0_intc 9>,
> > > + <&cpu1_intc 11>,
> > > <&cpu1_intc 9>,
> > > + <&cpu2_intc 11>,
> > > <&cpu2_intc 9>,
> > > + <&cpu3_intc 11>,
> > > <&cpu3_intc 9>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <1>;
> > > + riscv,ndev = <240>;
> > > + };
> > > +
> > > + clint: timer@ffdc000000 {
> > > + compatible = "thead,c900-clint";
> >
> > "c900"? That a typo or intentional. Hard to tell since this
> > compatible
> > is undocumented ;)
>
> Intentional, for supporting both C906 and C910.
>
> However, as we discussed in some binding patches, there should be a DT
> binding string per chip.
>
> So here should be "thead,light-clint", "thead,c900-clint".
>
> (Or use th1520, the marketing name, instead of light, the codename)
I'm definitly confused now :-)
c900 as well as something like c9xx should not be part of dt-bindings.
Binding-names should always denote _actual_ component names.
So you can do
"thead,c906-clint"
and for example
"thead,c910-clint", "thead,c906-clint"
to describe that the clint in the c910 is compatible with the one in c906
I don't think there should be a "thead,light-clint" ... the clint is part
of the cpu core itself so the soc itself shouldn't introduce any changes?
Heiko
On Mon, May 08, 2023 at 10:23:02AM +0200, Heiko Stübner wrote:
> Am Montag, 8. Mai 2023, 05:32:17 CEST schrieb Icenowy Zheng:
> > 在 2023-05-07星期日的 22:35 +0100，Conor Dooley写道：
> > > Hey Jisheng,
> > >
> > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > >
> > > > + c910_0: cpu@0 {
> > > > + compatible = "thead,c910", "riscv";
> > > > + device_type = "cpu";
> > > > + riscv,isa = "rv64imafdc";
> > >
> > > Does this support more than "rv64imafdc"?
> > > I assume there's some _xtheadfoo extensions that it does support,
> > > although I am not sure how we are proceeding with those - Heiko might
> > > have a more nuanced take.
>
> I guess the interesting question still is, are these part of the isa
> string or more of an errata?
Yeah, I dunno. That's possible a policy decision more than anything
else. I don't remember if it was one of your patchsets or elsewhere, but
I do recall a split between xtheadba etc and vector, where xtheadba was
defined as a vendor extension, whereas vector is not. Their extension
spec repo <https://github.com/T-head-Semi/thead-extension-spec> appears
to be aligned with that view, apart from the CMOs that we have already
called an erratum.
> The binding currently says
> Identifies the specific RISC-V instruction set architecture
> supported by the hart. These are documented in the RISC-V
> User-Level ISA document, available from
> https://riscv.org/specifications/
>
>
> I guess if we decide to make them part of the isa-string the binding
> then should get a paragraph mention _xfoo vendor-extensions too.
I have an idea in the works that may allow dealing with this kind of
thing, but it's a bit of a departure from the existing binding.
I will hopefully post an early RFC of it later today.
That said, the binding does currently allow you to put in _xfoo vendor
extensions as-is.
> Personally, making these part of the ISA string definitly sounds like
> the best solution though :-) .
You would say that wouldn't you! In general, I'd rather we filled in as
much information as possible here, even if it is not currently in use,
to avoid having to retrofit as support becomes available.
On 07/05/2023 20:23, Jisheng Zhang wrote:
> Add initial device tree for the light(a.k.a TH1520) RISC-V SoC by
> T-HEAD.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> arch/riscv/boot/dts/thead/light.dtsi | 454 +++++++++++++++++++++++++++
> 1 file changed, 454 insertions(+)
> create mode 100644 arch/riscv/boot/dts/thead/light.dtsi
>
> diff --git a/arch/riscv/boot/dts/thead/light.dtsi b/arch/riscv/boot/dts/thead/light.dtsi
> new file mode 100644
> index 000000000000..cdf6d8b04d22
> --- /dev/null
> +++ b/arch/riscv/boot/dts/thead/light.dtsi
> @@ -0,0 +1,454 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2021 Alibaba Group Holding Limited.
> + * Copyright (C) 2023 Jisheng Zhang <[email protected]>
> + */
> +
> +/ {
> + compatible = "thead,light";
Undocumented compatible.
Please run scripts/checkpatch.pl and fix reported warnings.
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus: cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <3000000>;
> +
> + c910_0: cpu@0 {
> + compatible = "thead,c910", "riscv";
Probably the same.
(...)
> + soc {
> + compatible = "simple-bus";
> + interrupt-parent = <&plic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + reset: reset-sample {
Node names should be generic.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compatible = "thead,reset-sample";
Undocumented compatible.
Please run scripts/checkpatch.pl and fix reported warnings.
> + entry-reg = <0xff 0xff019050>;
> + entry-cnt = <4>;
> + control-reg = <0xff 0xff015004>;
> + control-val = <0x1c>;
> + csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
> + };
> +
> + plic: interrupt-controller@ffd8000000 {
> + compatible = "thead,c910-plic";
> + reg = <0xff 0xd8000000 0x0 0x01000000>;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> + <&cpu1_intc 11>, <&cpu1_intc 9>,
> + <&cpu2_intc 11>, <&cpu2_intc 9>,
> + <&cpu3_intc 11>, <&cpu3_intc 9>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + riscv,ndev = <240>;
> + };
> +
> + clint: timer@ffdc000000 {
> + compatible = "thead,c900-clint";
Undocumented compatible.
Please run scripts/checkpatch.pl and fix reported warnings.
> + reg = <0xff 0xdc000000 0x0 0x00010000>;
> + 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>;
> + };
> +
> + uart0: serial@ffe7014000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff 0xe7014000 0x0 0x4000>;
> + interrupts = <36>;
> + clocks = <&uart_sclk>;
> + clock-names = "baudclk";
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
> + uart1: serial@ffe7f00000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff 0xe7f00000 0x0 0x4000>;
> + interrupts = <37>;
> + clocks = <&uart_sclk>;
> + clock-names = "baudclk";
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
> + uart3: serial@ffe7f04000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff 0xe7f04000 0x0 0x4000>;
> + interrupts = <39>;
> + clocks = <&uart_sclk>;
> + clock-names = "baudclk";
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
> + gpio2: gpio@ffe7f34000 {
> + compatible = "snps,dw-apb-gpio";
> + reg = <0xff 0xe7f34000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + portc: gpio-controller@0 {
> + compatible = "snps,dw-apb-gpio-port";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <32>;
> + reg = <0>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <58>;
> + };
> + };
> +
> + gpio3: gpio@ffe7f38000 {
> + compatible = "snps,dw-apb-gpio";
> + reg = <0xff 0xe7f38000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + portd: gpio-controller@0 {
> + compatible = "snps,dw-apb-gpio-port";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <32>;
> + reg = <0>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <59>;
> + };
> + };
> +
> + gpio0: gpio@ffec005000 {
> + compatible = "snps,dw-apb-gpio";
> + reg = <0xff 0xec005000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + porta: gpio-controller@0 {
> + compatible = "snps,dw-apb-gpio-port";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <32>;
> + reg = <0>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <56>;
> + };
> + };
> +
> + gpio1: gpio@ffec006000 {
> + compatible = "snps,dw-apb-gpio";
> + reg = <0xff 0xec006000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + portb: gpio-controller@0 {
> + compatible = "snps,dw-apb-gpio-port";
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <32>;
> + reg = <0>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <57>;
> + };
> + };
> +
> + uart2: serial@ffec010000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff 0xec010000 0x0 0x4000>;
> + interrupts = <38>;
> + clocks = <&uart_sclk>;
> + clock-names = "baudclk";
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
> + dmac0: dmac@ffefc00000 {
Does not look like you tested the DTS against bindings. Please run `make
dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst
for instructions).
Best regards,
Krzysztof
On 07/05/2023 20:23, Jisheng Zhang wrote:
> The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
> access from S-mode, but it doesn't need the edge quirk.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4 ++++
> drivers/irqchip/irq-sifive-plic.c | 1 +
Bindings are always separate patches.
Please run scripts/checkpatch.pl and fix reported warnings.
Best regards,
Krzysztof
Am Montag, 8. Mai 2023, 10:35:38 CEST schrieb Conor Dooley:
> On Mon, May 08, 2023 at 10:23:02AM +0200, Heiko Stübner wrote:
> > Am Montag, 8. Mai 2023, 05:32:17 CEST schrieb Icenowy Zheng:
> > > 在 2023-05-07星期日的 22:35 +0100，Conor Dooley写道：
> > > > Hey Jisheng,
> > > >
> > > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > > >
> > > > > + c910_0: cpu@0 {
> > > > > + compatible = "thead,c910", "riscv";
> > > > > + device_type = "cpu";
> > > > > + riscv,isa = "rv64imafdc";
> > > >
> > > > Does this support more than "rv64imafdc"?
> > > > I assume there's some _xtheadfoo extensions that it does support,
> > > > although I am not sure how we are proceeding with those - Heiko might
> > > > have a more nuanced take.
> >
> > I guess the interesting question still is, are these part of the isa
> > string or more of an errata?
>
> Yeah, I dunno. That's possible a policy decision more than anything
> else. I don't remember if it was one of your patchsets or elsewhere, but
> I do recall a split between xtheadba etc and vector, where xtheadba was
> defined as a vendor extension, whereas vector is not. Their extension
> spec repo <https://github.com/T-head-Semi/thead-extension-spec> appears
> to be aligned with that view, apart from the CMOs that we have already
> called an erratum.
I think the CMO stuff came a bit before that repo actually existed ;-) .
I guess another argument for riscv,isa would be that we don't have to
trust MVENDORID, and especially values in MARCHID and MIMPID.
Somehow part of me doesn't have enough trust that these values will
always be suitably different when they are baked into the hardware ;-) .
I guess vector is somewhat special, with it implementing version 0.7.1
it's not a t-head invention but also not the real RISCV "v" .
So I _guess_ the jury might still be out on how to handle that everywhere.
> > The binding currently says
> > Identifies the specific RISC-V instruction set architecture
> > supported by the hart. These are documented in the RISC-V
> > User-Level ISA document, available from
> > https://riscv.org/specifications/
> >
> >
> > I guess if we decide to make them part of the isa-string the binding
> > then should get a paragraph mention _xfoo vendor-extensions too.
>
> I have an idea in the works that may allow dealing with this kind of
> thing, but it's a bit of a departure from the existing binding.
> I will hopefully post an early RFC of it later today.
> That said, the binding does currently allow you to put in _xfoo vendor
> extensions as-is.
>
> > Personally, making these part of the ISA string definitly sounds like
> > the best solution though :-) .
>
> You would say that wouldn't you! In general, I'd rather we filled in as
> much information as possible here, even if it is not currently in use,
> to avoid having to retrofit as support becomes available.
yep definitively.
Especially as switching to expecting _xfoo later on then causes of course
compatiblity issues. The fun part will be though to get vendors,
toolchains and friends to agree on the naming.
Heiko
On Mon, May 08, 2023 at 02:52:29PM +0800, Guo Ren wrote:
> On Mon, May 8, 2023 at 2:34 AM Jisheng Zhang <[email protected]> wrote:
> >
> > The T-HEAD's C910 PLIC still needs the delegation bit settingto allow
> > access from S-mode, but it doesn't need the edge quirk.
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > ---
> > .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 4 ++++
> > drivers/irqchip/irq-sifive-plic.c | 1 +
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > index f75736a061af..64b43a3c3748 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > @@ -62,6 +62,10 @@ properties:
> > - starfive,jh7110-plic
> > - canaan,k210-plic
> > - const: sifive,plic-1.0.0
> > + - items:
> > + - enum:
> > + - thead,light-plic
> > + - const: thead,c910-plic
> > - items:
> > - enum:
> > - allwinner,sun20i-d1-plic
> > diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> > index e1484905b7bd..71afa2a584d9 100644
> > --- a/drivers/irqchip/irq-sifive-plic.c
> > +++ b/drivers/irqchip/irq-sifive-plic.c
> > @@ -569,6 +569,7 @@ static int __init plic_init(struct device_node *node,
> > }
> >
> > IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> > +IRQCHIP_DECLARE(thead_c910_plic, "thead,c910-plic", plic_init);
> > IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
> >
> > static int __init plic_edge_init(struct device_node *node,
> > --
> > 2.40.0
> >
> opensbi needs thead,c900-plic, and we could put multi compatible name
> in the dts. So, it's no need here.
Thanks, I misunderstood the PLIC edge quirk. This patch isn't needed any
more.
On Sun, May 07, 2023 at 10:21:26PM +0100, Conor Dooley wrote:
> Hey Jisheng,
Hi Conor,
>
> On Mon, May 08, 2023 at 02:23:04AM +0800, Jisheng Zhang wrote:
> > I would like to temporarily maintain the T-HEAD RISC-V SoC support.
>
> What does "temporarily" mean?
I got a Lichee Pi 4A board, and want to mainline its support. Sending
the new dts patches needs to touch MAINTAINERS entry, so I added it.
But I expected an experienced people from T-HEAD, with many
kernel contribuitions in the past, will take the maintainership
finally, for example, Ren Guo. He knew this SoC better than me.
On Tue, May 09, 2023 at 12:26:10AM +0800, Jisheng Zhang wrote:
> On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> >
> > > + c910_0: cpu@0 {
> > > + compatible = "thead,c910", "riscv";
> > > + device_type = "cpu";
> > > + riscv,isa = "rv64imafdc";
> >
> > Does this support more than "rv64imafdc"?
> > I assume there's some _xtheadfoo extensions that it does support,
> > although I am not sure how we are proceeding with those - Heiko might
> > have a more nuanced take.
> >
> > > + reset: reset-sample {
> > > + compatible = "thead,reset-sample";
> >
> > What is a "reset-sample"?
>
> This node is only for opensbi. The compatible string is already in
> opensbi. Do we also need to add dt-binding for it in linux?
If it's to be included in the kernel's dts, then yes, you do need a
dt-binding. If you remove it, then you don't :)
That said, "thead,reset-sample" is a strangely named compatible, so if
you do keep it it may end up needing a rename!
Cheers,
Conor.
On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> Hey Jisheng,
>
> On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
>
> > + c910_0: cpu@0 {
> > + compatible = "thead,c910", "riscv";
> > + device_type = "cpu";
> > + riscv,isa = "rv64imafdc";
>
> Does this support more than "rv64imafdc"?
> I assume there's some _xtheadfoo extensions that it does support,
> although I am not sure how we are proceeding with those - Heiko might
> have a more nuanced take.
>
> > + reset: reset-sample {
> > + compatible = "thead,reset-sample";
>
> What is a "reset-sample"?
This node is only for opensbi. The compatible string is already in
opensbi. Do we also need to add dt-binding for it in linux?
>
> > + entry-reg = <0xff 0xff019050>;
> > + entry-cnt = <4>;
> > + control-reg = <0xff 0xff015004>;
> > + control-val = <0x1c>;
> > + csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
> > + };
> > +
> > + plic: interrupt-controller@ffd8000000 {
> > + compatible = "thead,c910-plic";
> > + reg = <0xff 0xd8000000 0x0 0x01000000>;
> > + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> > + <&cpu1_intc 11>, <&cpu1_intc 9>,
> > + <&cpu2_intc 11>, <&cpu2_intc 9>,
> > + <&cpu3_intc 11>, <&cpu3_intc 9>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + riscv,ndev = <240>;
> > + };
> > +
> > + clint: timer@ffdc000000 {
> > + compatible = "thead,c900-clint";
>
> "c900"? That a typo or intentional. Hard to tell since this compatible
> is undocumented ;)
Per my understanding, this node is only for opensbi too. Add will add
dt-binding in v2.
>
> > + reg = <0xff 0xdc000000 0x0 0x00010000>;
> > + 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>;
> > + };
> > +
> > + uart0: serial@ffe7014000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0xff 0xe7014000 0x0 0x4000>;
> > + interrupts = <36>;
> > + clocks = <&uart_sclk>;
> > + clock-names = "baudclk";
>
> dtbs_check complains about this clock name.
> > +
> > + dmac0: dmac@ffefc00000 {
>
> dma-controller@
>
> As I mentioned in the other patch, please clean up the dtbs_check
> complaints for v2.
>
Thanks for the reminding.
Am Montag, 8. Mai 2023, 18:44:04 CEST schrieb Conor Dooley:
> On Tue, May 09, 2023 at 12:26:10AM +0800, Jisheng Zhang wrote:
> > On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > >
> > > > + c910_0: cpu@0 {
> > > > + compatible = "thead,c910", "riscv";
> > > > + device_type = "cpu";
> > > > + riscv,isa = "rv64imafdc";
> > >
> > > Does this support more than "rv64imafdc"?
> > > I assume there's some _xtheadfoo extensions that it does support,
> > > although I am not sure how we are proceeding with those - Heiko might
> > > have a more nuanced take.
> > >
> > > > + reset: reset-sample {
> > > > + compatible = "thead,reset-sample";
> > >
> > > What is a "reset-sample"?
> >
> > This node is only for opensbi. The compatible string is already in
> > opensbi. Do we also need to add dt-binding for it in linux?
>
> If it's to be included in the kernel's dts, then yes, you do need a
> dt-binding. If you remove it, then you don't :)
>
> That said, "thead,reset-sample" is a strangely named compatible, so if
> you do keep it it may end up needing a rename!
and you'll need to justify that this describes actual hardware
(dt-maintainers iterate all the time that dt is a hardware description, not
a configuration scheme).
The question also would be if this is part of upstream opensbi at all.
In general though, openSBI does something similar with their perf-counter
description. Describing the mapping and eventids usable in which counter
via a structure passed from u-boot to openSBI.
The difference here is, that openSBI then removes the relevant nodes from
the dt, so that the kernel never sees them [0] .
As you reset-sample seems to fall into a similar category, I guess
it would be better suited in an a foo-u-boot.dtsi ?
[0] https://github.com/riscv-software-src/opensbi/blob/master/lib/utils/fdt/fdt_pmu.c#L42
On Tue, May 09, 2023 at 12:17:52AM +0800, Jisheng Zhang wrote:
> On Sun, May 07, 2023 at 10:21:26PM +0100, Conor Dooley wrote:
> > Hey Jisheng,
>
> Hi Conor,
>
> >
> > On Mon, May 08, 2023 at 02:23:04AM +0800, Jisheng Zhang wrote:
> > > I would like to temporarily maintain the T-HEAD RISC-V SoC support.
> >
> > What does "temporarily" mean?
>
> I got a Lichee Pi 4A board, and want to mainline its support. Sending
> the new dts patches needs to touch MAINTAINERS entry, so I added it.
> But I expected an experienced people from T-HEAD, with many
> kernel contribuitions in the past, will take the maintainership
> finally, for example, Ren Guo. He knew this SoC better than me.
I see. I don't mind applying the patches for the platform for now, it's
not too much more on top of the other vendors that I am doing as things
are still low enough volume, as long as someone is willing to review
them as they come in.
Cheers,
Conor.
On Tue, May 9, 2023 at 12:44 AM Conor Dooley <[email protected]> wrote:
>
> On Tue, May 09, 2023 at 12:26:10AM +0800, Jisheng Zhang wrote:
> > On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > >
> > > > + c910_0: cpu@0 {
> > > > + compatible = "thead,c910", "riscv";
> > > > + device_type = "cpu";
> > > > + riscv,isa = "rv64imafdc";
> > >
> > > Does this support more than "rv64imafdc"?
> > > I assume there's some _xtheadfoo extensions that it does support,
> > > although I am not sure how we are proceeding with those - Heiko might
> > > have a more nuanced take.
> > >
> > > > + reset: reset-sample {
> > > > + compatible = "thead,reset-sample";
> > >
> > > What is a "reset-sample"?
> >
> > This node is only for opensbi. The compatible string is already in
> > opensbi. Do we also need to add dt-binding for it in linux?
>
> If it's to be included in the kernel's dts, then yes, you do need a
> dt-binding. If you remove it, then you don't :)
>
> That said, "thead,reset-sample" is a strangely named compatible, so if
> you do keep it it may end up needing a rename!
How about compatible = "thead,reset-th1520" ?
>
> Cheers,
> Conor.
>
--
Best Regards
Guo Ren
On Sun, May 21, 2023 at 11:37:58PM +0800, Guo Ren wrote:
> On Tue, May 9, 2023 at 12:44 AM Conor Dooley <[email protected]> wrote:
> >
> > On Tue, May 09, 2023 at 12:26:10AM +0800, Jisheng Zhang wrote:
> > > On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> > > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > > >
> > > > > + c910_0: cpu@0 {
> > > > > + compatible = "thead,c910", "riscv";
> > > > > + device_type = "cpu";
> > > > > + riscv,isa = "rv64imafdc";
> > > >
> > > > Does this support more than "rv64imafdc"?
> > > > I assume there's some _xtheadfoo extensions that it does support,
> > > > although I am not sure how we are proceeding with those - Heiko might
> > > > have a more nuanced take.
> > > >
> > > > > + reset: reset-sample {
> > > > > + compatible = "thead,reset-sample";
> > > >
> > > > What is a "reset-sample"?
> > >
> > > This node is only for opensbi. The compatible string is already in
> > > opensbi. Do we also need to add dt-binding for it in linux?
> >
> > If it's to be included in the kernel's dts, then yes, you do need a
> > dt-binding. If you remove it, then you don't :)
> >
> > That said, "thead,reset-sample" is a strangely named compatible, so if
> > you do keep it it may end up needing a rename!
> How about compatible = "thead,reset-th1520" ?
"vendor,soc-function" is more typical, but "reset" is usually used for
reset controllers of which this isn't as far as I can tell.
I commented on the v2, hoping that you might actually know what the IP
block' full/proper name is:
https://lore.kernel.org/all/20230518-driving-secluding-793b3192776e@spud/
Do you?
Cheers,
Conor.
On Mon, May 22, 2023 at 1:08 AM Conor Dooley <[email protected]> wrote:
>
> On Sun, May 21, 2023 at 11:37:58PM +0800, Guo Ren wrote:
> > On Tue, May 9, 2023 at 12:44 AM Conor Dooley <[email protected]> wrote:
> > >
> > > On Tue, May 09, 2023 at 12:26:10AM +0800, Jisheng Zhang wrote:
> > > > On Sun, May 07, 2023 at 10:35:12PM +0100, Conor Dooley wrote:
> > > > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:
> > > > >
> > > > > > + c910_0: cpu@0 {
> > > > > > + compatible = "thead,c910", "riscv";
> > > > > > + device_type = "cpu";
> > > > > > + riscv,isa = "rv64imafdc";
> > > > >
> > > > > Does this support more than "rv64imafdc"?
> > > > > I assume there's some _xtheadfoo extensions that it does support,
> > > > > although I am not sure how we are proceeding with those - Heiko might
> > > > > have a more nuanced take.
> > > > >
> > > > > > + reset: reset-sample {
> > > > > > + compatible = "thead,reset-sample";
> > > > >
> > > > > What is a "reset-sample"?
> > > >
> > > > This node is only for opensbi. The compatible string is already in
> > > > opensbi. Do we also need to add dt-binding for it in linux?
> > >
> > > If it's to be included in the kernel's dts, then yes, you do need a
> > > dt-binding. If you remove it, then you don't :)
> > >
> > > That said, "thead,reset-sample" is a strangely named compatible, so if
> > > you do keep it it may end up needing a rename!
>
> > How about compatible = "thead,reset-th1520" ?
>
> "vendor,soc-function" is more typical, but "reset" is usually used for
> reset controllers of which this isn't as far as I can tell.
> I commented on the v2, hoping that you might actually know what the IP
> block' full/proper name is:
> https://lore.kernel.org/all/20230518-driving-secluding-793b3192776e@spud/
Oh, sorry, I focused on s64ilp32 these days and missed that. I would
reply to that thread.
>
> Do you?
>
> Cheers,
> Conor.
--
Best Regards
Guo Ren