[PATCH v5 0/6] arm64: Introduce CIX P1 (SKY1) SoC

[PATCH v5 0/6] arm64: Introduce CIX P1 (SKY1) SoC

[Peter Chen]

Cixtech P1 (internal name sky1) is high performance generic Armv9 SoC.
Orion O6 is the world's first open source Arm V9 Motherboard built by
Radxa. You could find brief introduction for SoC and related boards at:
https://radxa.com/products/orion/o6#overview

In this series, we add initial SoC and board support for Kernel building.
Patch 1-2: add dt-binding doc for CIX and its sky1 SoC
Patch 3-4: add Arm64 build support
Patch 5: add initial dts support for SoC and Orion O6 board
Patch 6: add MAINTAINERS entry

To run upstream kernel at Orion O6 board, you need to use BIOS
released by Radxa:
https://docs.radxa.com/en/orion/o6/bios/install-bios

Changes for v5:
- Patch 5: Delete pmu-spe node which need to refine, and add it in future
- Patch 6: Refine MAINTAINERS for all CIX SoC and adding code tree location

Changes for v4:
- Move add MAINTAINERS entry patch to the last, and add two dts files entry in it. 
- Add three Krzysztof Kozlowski's Reviewed-by Tags
- For sky1.dtsi, makes below changes:
	- Add ppi-partition entry for gic-v3 node, and let pmu-a520 and pmu-a720's interrupt entry
	get its handle
	- Remove gic-v3's #redistributor-regions and redistributor-stride properties
	- Change gic-v3's #interrupt-cells as 4, and change all interrupt specifiers accordingly
	- Remove "arm,no-tick-in-suspend" for timer due to global counter is at always-on power domain
	- Remove timer's clock frequency due to firmware has already set it

Changes for v3:
- Patch 1: Add Krzysztof Kozlowski's Acked-by Tag
- Patch 2: Add Krzysztof Kozlowski's Reviewed-by Tag
- Patch 6: Fix two dts coding sytle issues

Changes for v2:
- Pass dts build check with below commands:
make O=$OUTKNL dt_binding_check DT_SCHEMA_FILES=vendor-prefixes.yaml
make O=$OUTKNL dt_binding_check DT_SCHEMA_FILES=arm/cix.yaml
make O=$OUTKNL CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb
- Re-order the patch set, and move vendor-perfixes to the 1st patch.
- Patch 4: Ordered Kconfig config entry by alpha-numerically
- Patch 5: Corrects the Ack tag's name
- Patch 6: see below.
1) Corrects the SoF tag's name
2) Fix several coding sytle issues
3) move linux,cma node to dts file
4) delete memory node, memory size is passed by firmware
5) delete uart2 node which will be added in future patches
6) Improve for pmu and cpu node to stands for more specific cpu model
7) Improve the timer node and add hypervisor virtual timer irq

Fugang Duan (1):
  arm64: Kconfig: add ARCH_CIX for cix silicons

Peter Chen (5):
  dt-bindings: vendor-prefixes: Add CIX Technology Group Co., Ltd.
  dt-bindings: arm: add CIX P1 (SKY1) SoC
  arm64: defconfig: Enable CIX SoC
  arm64: dts: cix: add initial CIX P1(SKY1) dts support
  MAINTAINERS: Add CIX SoC maintainer entry

 .../devicetree/bindings/arm/cix.yaml          |  26 +++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |  11 +
 arch/arm64/Kconfig.platforms                  |   6 +
 arch/arm64/boot/dts/Makefile                  |   1 +
 arch/arm64/boot/dts/cix/Makefile              |   2 +
 arch/arm64/boot/dts/cix/sky1-orion-o6.dts     |  26 +++
 arch/arm64/boot/dts/cix/sky1.dtsi             | 217 ++++++++++++++++++
 arch/arm64/configs/defconfig                  |   1 +
 9 files changed, 292 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cix.yaml
 create mode 100644 arch/arm64/boot/dts/cix/Makefile
 create mode 100644 arch/arm64/boot/dts/cix/sky1-orion-o6.dts
 create mode 100644 arch/arm64/boot/dts/cix/sky1.dtsi

-- 
2.25.1

[PATCH v5 1/6] dt-bindings: vendor-prefixes: Add CIX Technology Group Co., Ltd.

[Peter Chen]

CIX Technology Group Co., Ltd. is a high performance Arm SoC design
company. Link: https://www.cixtech.com/.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 5079ca6ce1d1..5e76223e4570 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -302,6 +302,8 @@ patternProperties:
     description: Cirrus Logic, Inc.
   "^cisco,.*":
     description: Cisco Systems, Inc.
+  "^cix,.*":
+    description: CIX Technology Group Co., Ltd.
   "^clockwork,.*":
     description: Clockwork Tech LLC
   "^cloos,.*":
-- 
2.25.1

[PATCH v5 2/6] dt-bindings: arm: add CIX P1 (SKY1) SoC

[Peter Chen]

Add device tree bindings for CIX P1 (Internal name sky1) Arm SoC,
it consists several SoC models like CP8180, CD8180, etc.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
 .../devicetree/bindings/arm/cix.yaml          | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cix.yaml

diff --git a/Documentation/devicetree/bindings/arm/cix.yaml b/Documentation/devicetree/bindings/arm/cix.yaml
new file mode 100644
index 000000000000..114dab4bc4d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cix.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CIX platforms
+
+maintainers:
+  - Peter Chen <peter.chen@cixtech.com>
+  - Fugang Duan <fugang.duan@cixtech.com>
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Radxa Orion O6
+        items:
+          - const: radxa,orion-o6
+          - const: cix,sky1
+
+additionalProperties: true
+
+...
-- 
2.25.1

[PATCH v5 3/6] arm64: Kconfig: add ARCH_CIX for cix silicons

[Peter Chen]

From: Fugang Duan <fugang.duan@cixtech.com>

Add ARCH_CIX for CIX SoC series support.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 02f9248f7c84..abe41db9b9b3 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -106,6 +106,12 @@ config ARCH_BLAIZE
 	help
 	  This enables support for the Blaize SoC family
 
+config ARCH_CIX
+	bool "Cixtech SoC family"
+	help
+	  This enables support for the Cixtech SoC family,
+	  like P1(sky1).
+
 config ARCH_EXYNOS
 	bool "Samsung Exynos SoC family"
 	select COMMON_CLK_SAMSUNG
-- 
2.25.1

[PATCH v5 4/6] arm64: defconfig: Enable CIX SoC

[Peter Chen]

Enable CIX SoC support at ARM64 defconfig

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index cb7da4415599..1dd46d200401 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -45,6 +45,7 @@ CONFIG_ARCH_BCMBCA=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_BLAIZE=y
+CONFIG_ARCH_CIX=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_SPARX5=y
 CONFIG_ARCH_K3=y
-- 
2.25.1

[PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

CIX SKY1 SoC is high performance Armv9 SoC designed by Cixtech,
and Orion O6 is open source motherboard launched by Radxa.
See below for detail:
https://docs.radxa.com/en/orion/o6/getting-started/introduction

In this commit, it only adds limited components for running initramfs
at Orion O6.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
Changes for v5:
- Delete pmu-spe node which need to refine, and add it in future

Changes for v4:
- Add ppi-partition entry for gic-v3 node, and let pmu-a520 and pmu-a720's interrupt entry
get its handle
- Remove gic-v3's #redistributor-regions and redistributor-stride properties
- Change gic-v3's #interrupt-cells as 4, and change all interrupt specifiers accordingly
- Remove "arm,no-tick-in-suspend" for timer due to global counter is at always-on power domain
- Remove timer's clock frequency due to firmware has already set it
- Add Krzysztof Kozlowski's reviewed-by

Changes for v3:
- Fix two dts coding sytle issues 

Changes for v2:
- Corrects the SoF tag's name
- Fix several coding sytle issues
- move linux,cma node to dts file
- delete memory node, memory size is passed by firmware
- delete uart2 node which will be added in future patches
- Improve for pmu and cpu node to stands for more specific cpu model
- Improve the timer node and add hypervisor virtual timer irq
- Pass "make O=$OUTKNL CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb"

 arch/arm64/boot/dts/Makefile              |   1 +
 arch/arm64/boot/dts/cix/Makefile          |   2 +
 arch/arm64/boot/dts/cix/sky1-orion-o6.dts |  26 +++
 arch/arm64/boot/dts/cix/sky1.dtsi         | 217 ++++++++++++++++++++++
 4 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/boot/dts/cix/Makefile
 create mode 100644 arch/arm64/boot/dts/cix/sky1-orion-o6.dts
 create mode 100644 arch/arm64/boot/dts/cix/sky1.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 79b73a21ddc2..8e7ccd0027bd 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -13,6 +13,7 @@ subdir-y += bitmain
 subdir-y += blaize
 subdir-y += broadcom
 subdir-y += cavium
+subdir-y += cix
 subdir-y += exynos
 subdir-y += freescale
 subdir-y += hisilicon
diff --git a/arch/arm64/boot/dts/cix/Makefile b/arch/arm64/boot/dts/cix/Makefile
new file mode 100644
index 000000000000..ed3713982012
--- /dev/null
+++ b/arch/arm64/boot/dts/cix/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_CIX) += sky1-orion-o6.dtb
diff --git a/arch/arm64/boot/dts/cix/sky1-orion-o6.dts b/arch/arm64/boot/dts/cix/sky1-orion-o6.dts
new file mode 100644
index 000000000000..78f4fcd87216
--- /dev/null
+++ b/arch/arm64/boot/dts/cix/sky1-orion-o6.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright 2025 Cix Technology Group Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "sky1.dtsi"
+/ {
+	model = "Radxa Orion O6";
+	compatible = "radxa,orion-o6", "cix,sky1";
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		linux,cma {
+			compatible = "shared-dma-pool";
+			reusable;
+			size = <0x0 0x28000000>;
+			linux,cma-default;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/cix/sky1.dtsi b/arch/arm64/boot/dts/cix/sky1.dtsi
new file mode 100644
index 000000000000..5bfeeea454e0
--- /dev/null
+++ b/arch/arm64/boot/dts/cix/sky1.dtsi
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright 2025 Cix Technology Group Co., Ltd.
+ *
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "arm,cortex-a520";
+			enable-method = "psci";
+			reg = <0x0 0x0>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <403>;
+		};
+
+		cpu1: cpu@100 {
+			compatible = "arm,cortex-a520";
+			enable-method = "psci";
+			reg = <0x0 0x100>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <403>;
+		};
+
+		cpu2: cpu@200 {
+			compatible = "arm,cortex-a520";
+			enable-method = "psci";
+			reg = <0x0 0x200>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <403>;
+		};
+
+		cpu3: cpu@300 {
+			compatible = "arm,cortex-a520";
+			enable-method = "psci";
+			reg = <0x0 0x300>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <403>;
+		};
+
+		cpu4: cpu@400 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x400>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu5: cpu@500 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x500>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu6: cpu@600 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x600>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu7: cpu@700 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x700>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu8: cpu@800 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x800>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu9: cpu@900 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0x900>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu10: cpu@a00 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0xa00>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu11: cpu@b00 {
+			compatible = "arm,cortex-a720";
+			enable-method = "psci";
+			reg = <0x0 0xb00>;
+			device_type = "cpu";
+			capacity-dmips-mhz = <1024>;
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+				core4 {
+					cpu = <&cpu4>;
+				};
+				core5 {
+					cpu = <&cpu5>;
+				};
+				core6 {
+					cpu = <&cpu6>;
+				};
+				core7 {
+					cpu = <&cpu7>;
+				};
+				core8 {
+					cpu = <&cpu8>;
+				};
+				core9 {
+					cpu = <&cpu9>;
+				};
+				core10 {
+					cpu = <&cpu10>;
+				};
+				core11 {
+					cpu = <&cpu11>;
+				};
+			};
+		};
+	};
+
+	pmu-a520 {
+		compatible = "arm,cortex-a520-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW &ppi_partition0>;
+	};
+
+	pmu-a720 {
+		compatible = "arm,cortex-a720-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW &ppi_partition1>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	soc@0 {
+		compatible = "simple-bus";
+		ranges = <0 0 0 0 0x20 0>;
+		dma-ranges;
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		gic: interrupt-controller@e010000 {
+			compatible = "arm,gic-v3";
+			reg = <0x0 0x0e010000 0 0x10000>,	/* GICD */
+			      <0x0 0x0e090000 0 0x300000>;       /* GICR * 12 */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW 0>;
+			#interrupt-cells = <4>;
+			interrupt-controller;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			gic_its: msi-controller@e050000 {
+				compatible = "arm,gic-v3-its";
+				reg = <0x0 0x0e050000 0x0 0x30000>;
+				msi-controller;
+				#msi-cells = <1>;
+			};
+
+			ppi-partitions {
+				ppi_partition0: interrupt-partition-0 {
+					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
+				};
+
+				ppi_partition1: interrupt-partition-1 {
+					affinity = <&cpu4 &cpu5 &cpu6 &cpu7 &cpu8 &cpu9 &cpu10 &cpu11>;
+				};
+			};
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
+			     <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
+	};
+};
-- 
2.25.1

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Marc Zyngier]

On Mon, 24 Mar 2025 06:24:19 +0000,
Peter Chen <peter.chen@cixtech.com> wrote:
> 
> CIX SKY1 SoC is high performance Armv9 SoC designed by Cixtech,
> and Orion O6 is open source motherboard launched by Radxa.
> See below for detail:
> https://docs.radxa.com/en/orion/o6/getting-started/introduction
> 
> In this commit, it only adds limited components for running initramfs
> at Orion O6.
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Acked-by: Fugang Duan <fugang.duan@cixtech.com>
> Signed-off-by: Peter Chen <peter.chen@cixtech.com>
> ---
> Changes for v5:
> - Delete pmu-spe node which need to refine, and add it in future
> 
> Changes for v4:
> - Add ppi-partition entry for gic-v3 node, and let pmu-a520 and pmu-a720's interrupt entry
> get its handle
> - Remove gic-v3's #redistributor-regions and redistributor-stride properties
> - Change gic-v3's #interrupt-cells as 4, and change all interrupt specifiers accordingly
> - Remove "arm,no-tick-in-suspend" for timer due to global counter is at always-on power domain
> - Remove timer's clock frequency due to firmware has already set it
> - Add Krzysztof Kozlowski's reviewed-by
> 
> Changes for v3:
> - Fix two dts coding sytle issues 
> 
> Changes for v2:
> - Corrects the SoF tag's name
> - Fix several coding sytle issues
> - move linux,cma node to dts file
> - delete memory node, memory size is passed by firmware
> - delete uart2 node which will be added in future patches
> - Improve for pmu and cpu node to stands for more specific cpu model
> - Improve the timer node and add hypervisor virtual timer irq
> - Pass "make O=$OUTKNL CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb"
> 
>  arch/arm64/boot/dts/Makefile              |   1 +
>  arch/arm64/boot/dts/cix/Makefile          |   2 +
>  arch/arm64/boot/dts/cix/sky1-orion-o6.dts |  26 +++
>  arch/arm64/boot/dts/cix/sky1.dtsi         | 217 ++++++++++++++++++++++
>  4 files changed, 246 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/cix/Makefile
>  create mode 100644 arch/arm64/boot/dts/cix/sky1-orion-o6.dts
>  create mode 100644 arch/arm64/boot/dts/cix/sky1.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 79b73a21ddc2..8e7ccd0027bd 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -13,6 +13,7 @@ subdir-y += bitmain
>  subdir-y += blaize
>  subdir-y += broadcom
>  subdir-y += cavium
> +subdir-y += cix
>  subdir-y += exynos
>  subdir-y += freescale
>  subdir-y += hisilicon
> diff --git a/arch/arm64/boot/dts/cix/Makefile b/arch/arm64/boot/dts/cix/Makefile
> new file mode 100644
> index 000000000000..ed3713982012
> --- /dev/null
> +++ b/arch/arm64/boot/dts/cix/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_CIX) += sky1-orion-o6.dtb
> diff --git a/arch/arm64/boot/dts/cix/sky1-orion-o6.dts b/arch/arm64/boot/dts/cix/sky1-orion-o6.dts
> new file mode 100644
> index 000000000000..78f4fcd87216
> --- /dev/null
> +++ b/arch/arm64/boot/dts/cix/sky1-orion-o6.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright 2025 Cix Technology Group Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "sky1.dtsi"
> +/ {
> +	model = "Radxa Orion O6";
> +	compatible = "radxa,orion-o6", "cix,sky1";
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		linux,cma {
> +			compatible = "shared-dma-pool";
> +			reusable;
> +			size = <0x0 0x28000000>;
> +			linux,cma-default;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/cix/sky1.dtsi b/arch/arm64/boot/dts/cix/sky1.dtsi
> new file mode 100644
> index 000000000000..5bfeeea454e0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/cix/sky1.dtsi
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright 2025 Cix Technology Group Co., Ltd.
> + *
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu@0 {
> +			compatible = "arm,cortex-a520";
> +			enable-method = "psci";
> +			reg = <0x0 0x0>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <403>;
> +		};
> +
> +		cpu1: cpu@100 {
> +			compatible = "arm,cortex-a520";
> +			enable-method = "psci";
> +			reg = <0x0 0x100>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <403>;
> +		};
> +
> +		cpu2: cpu@200 {
> +			compatible = "arm,cortex-a520";
> +			enable-method = "psci";
> +			reg = <0x0 0x200>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <403>;
> +		};
> +
> +		cpu3: cpu@300 {
> +			compatible = "arm,cortex-a520";
> +			enable-method = "psci";
> +			reg = <0x0 0x300>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <403>;
> +		};
> +
> +		cpu4: cpu@400 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x400>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu5: cpu@500 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x500>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu6: cpu@600 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x600>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu7: cpu@700 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x700>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu8: cpu@800 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x800>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu9: cpu@900 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0x900>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu10: cpu@a00 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0xa00>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu11: cpu@b00 {
> +			compatible = "arm,cortex-a720";
> +			enable-method = "psci";
> +			reg = <0x0 0xb00>;
> +			device_type = "cpu";
> +			capacity-dmips-mhz = <1024>;
> +		};
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +				core2 {
> +					cpu = <&cpu2>;
> +				};
> +				core3 {
> +					cpu = <&cpu3>;
> +				};
> +				core4 {
> +					cpu = <&cpu4>;
> +				};
> +				core5 {
> +					cpu = <&cpu5>;
> +				};
> +				core6 {
> +					cpu = <&cpu6>;
> +				};
> +				core7 {
> +					cpu = <&cpu7>;
> +				};
> +				core8 {
> +					cpu = <&cpu8>;
> +				};
> +				core9 {
> +					cpu = <&cpu9>;
> +				};
> +				core10 {
> +					cpu = <&cpu10>;
> +				};
> +				core11 {
> +					cpu = <&cpu11>;
> +				};
> +			};
> +		};
> +	};
> +
> +	pmu-a520 {
> +		compatible = "arm,cortex-a520-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW &ppi_partition0>;
> +	};
> +
> +	pmu-a720 {
> +		compatible = "arm,cortex-a720-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW &ppi_partition1>;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	soc@0 {
> +		compatible = "simple-bus";
> +		ranges = <0 0 0 0 0x20 0>;
> +		dma-ranges;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		gic: interrupt-controller@e010000 {
> +			compatible = "arm,gic-v3";
> +			reg = <0x0 0x0e010000 0 0x10000>,	/* GICD */
> +			      <0x0 0x0e090000 0 0x300000>;       /* GICR * 12 */
> +			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW 0>;
> +			#interrupt-cells = <4>;
> +			interrupt-controller;
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +
> +			gic_its: msi-controller@e050000 {
> +				compatible = "arm,gic-v3-its";
> +				reg = <0x0 0x0e050000 0x0 0x30000>;
> +				msi-controller;
> +				#msi-cells = <1>;
> +			};
> +
> +			ppi-partitions {
> +				ppi_partition0: interrupt-partition-0 {
> +					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> +				};
> +
> +				ppi_partition1: interrupt-partition-1 {
> +					affinity = <&cpu4 &cpu5 &cpu6 &cpu7 &cpu8 &cpu9 &cpu10 &cpu11>;
> +				};
> +			};
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
> +			     <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
> +	};
> +};

I don't think there is anything wrong here, but it is also a pretty
useless DT. There isn't even a UART to interact with the machine and
find out whether it has actually booted.

I reckon this should be part of the initial DT, as this otherwise
serves little purpose.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

On 25-03-25 10:52:10, Marc Zyngier wrote:
> > +     timer {
> > +             compatible = "arm,armv8-timer";
> > +             interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
> > +             interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
> > +                          <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
> > +                          <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
> > +                          <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
> > +                          <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
> > +     };
> > +};
> 
> I don't think there is anything wrong here, but it is also a pretty
> useless DT. There isn't even a UART to interact with the machine and
> find out whether it has actually booted.
> 

UEFI uses the same UART, so we could see all kernel boot logs until
switch to use kernel UART driver for printk. If you would like boot
to the console at initramfs, just add uart node like patchset v1.

> I reckon this should be part of the initial DT, as this otherwise
> serves little purpose.
> 

Without this initial support, we can't add some base drivers, like
mailbox. The dt_binding_check will report warnings/errors [1].

Full UART support depends on clock, clock control needs mailbox
to talk with FW using SCMI protocol.

There is no any support for CIX SoC, so we had to add one small step by
step.

[1] https://lore.kernel.org/lkml/174290730775.1655008.14031380406017771195.robh@kernel.org/

-- 

Best regards,
Peter

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Marc Zyngier]

On Wed, 26 Mar 2025 03:26:08 +0000,
Peter Chen <peter.chen@cixtech.com> wrote:
> 
> On 25-03-25 10:52:10, Marc Zyngier wrote:
> > > +     timer {
> > > +             compatible = "arm,armv8-timer";
> > > +             interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
> > > +             interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
> > > +                          <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
> > > +                          <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
> > > +                          <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
> > > +                          <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
> > > +     };
> > > +};
> > 
> > I don't think there is anything wrong here, but it is also a pretty
> > useless DT. There isn't even a UART to interact with the machine and
> > find out whether it has actually booted.
> > 
> 
> UEFI uses the same UART, so we could see all kernel boot logs until
> switch to use kernel UART driver for printk. If you would like boot
> to the console at initramfs, just add uart node like patchset v1.

What's the point in upstreaming something that requires extra changes
just to boot it? It only outlines these patches are not useful as they
stand.

>
> > I reckon this should be part of the initial DT, as this otherwise
> > serves little purpose.
> > 
> 
> Without this initial support, we can't add some base drivers, like
> mailbox. The dt_binding_check will report warnings/errors [1].

Of course you can. You just add additional patches to this series,
making it something that is actually useful. So far, this series only
serves as marketing material.

> Full UART support depends on clock, clock control needs mailbox
> to talk with FW using SCMI protocol.

Then do it. You obviously have existing DT support for it already.

> There is no any support for CIX SoC, so we had to add one small step by
> step.

No, you are deliberately choosing to make this platform useless.

That's a bit sad, and a waste of everybody's time.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

> >
> > On 25-03-25 10:52:10, Marc Zyngier wrote:
> > > > +     timer {
> > > > +             compatible = "arm,armv8-timer";
> > > > +             interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
> > > > +             interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
> > > > +                          <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
> > > > +                          <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
> > > > +                          <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
> > > > +                          <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
> > > > +     };
> > > > +};
> > >
> > > I don't think there is anything wrong here, but it is also a pretty
> > > useless DT. There isn't even a UART to interact with the machine and
> > > find out whether it has actually booted.
> > >
> >
> > UEFI uses the same UART, so we could see all kernel boot logs until
> > switch to use kernel UART driver for printk. If you would like boot
> > to the console at initramfs, just add uart node like patchset v1.
> 
> What's the point in upstreaming something that requires extra changes
> just to boot it? It only outlines these patches are not useful as they
> stand.
> 
> >
> > > I reckon this should be part of the initial DT, as this otherwise
> > > serves little purpose.
> > >
> >
> > Without this initial support, we can't add some base drivers, like
> > mailbox. The dt_binding_check will report warnings/errors [1].
> 
> Of course you can. You just add additional patches to this series,
> making it something that is actually useful. So far, this series only
> serves as marketing material.
> 
> > Full UART support depends on clock, clock control needs mailbox
> > to talk with FW using SCMI protocol.
> 
> Then do it. You obviously have existing DT support for it already.
> 
> > There is no any support for CIX SoC, so we had to add one small step by
> > step.
> 
> No, you are deliberately choosing to make this platform useless.
> 
> That's a bit sad, and a waste of everybody's time.
> 

Hi Marc,

Thanks for your interesting of our platform, and your comments
help us a lot. But I don't think it wastes reviewers and maintainers
time, a clean patch set saves everyone's time during upstream process.

For how to organize the patch set for SoC, Krzysztof gave good summary
at [1]. We are going on upstream [2], this patch set is just a start
and base but not like you said for marketing purpose.

[1] https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
[2] https://lore.kernel.org/lkml/20250325101807.2202758-1-guomin.chen@cixtech.com/

-- 

Best regards,
Peter

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Krzysztof Kozlowski]

On 27/03/2025 07:44, Peter Chen wrote:
>>>
>>> On 25-03-25 10:52:10, Marc Zyngier wrote:
>>>>> +     timer {
>>>>> +             compatible = "arm,armv8-timer";
>>>>> +             interrupt-names = "sec-phys", "phys", "virt", "hyp-phys", "hyp-virt";
>>>>> +             interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW 0>,
>>>>> +                          <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW 0>,
>>>>> +                          <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW 0>,
>>>>> +                          <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW 0>,
>>>>> +                          <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW 0>;
>>>>> +     };
>>>>> +};
>>>>
>>>> I don't think there is anything wrong here, but it is also a pretty
>>>> useless DT. There isn't even a UART to interact with the machine and
>>>> find out whether it has actually booted.
>>>>
>>>
>>> UEFI uses the same UART, so we could see all kernel boot logs until
>>> switch to use kernel UART driver for printk. If you would like boot
>>> to the console at initramfs, just add uart node like patchset v1.
>>
>> What's the point in upstreaming something that requires extra changes
>> just to boot it? It only outlines these patches are not useful as they
>> stand.
>>
>>>
>>>> I reckon this should be part of the initial DT, as this otherwise
>>>> serves little purpose.
>>>>
>>>
>>> Without this initial support, we can't add some base drivers, like
>>> mailbox. The dt_binding_check will report warnings/errors [1].
>>
>> Of course you can. You just add additional patches to this series,
>> making it something that is actually useful. So far, this series only
>> serves as marketing material.
>>
>>> Full UART support depends on clock, clock control needs mailbox
>>> to talk with FW using SCMI protocol.
>>
>> Then do it. You obviously have existing DT support for it already.
>>
>>> There is no any support for CIX SoC, so we had to add one small step by
>>> step.
>>
>> No, you are deliberately choosing to make this platform useless.
>>
>> That's a bit sad, and a waste of everybody's time.
>>
> 
> Hi Marc,
> 
> Thanks for your interesting of our platform, and your comments
> help us a lot. But I don't think it wastes reviewers and maintainers
> time, a clean patch set saves everyone's time during upstream process.
> 
> For how to organize the patch set for SoC, Krzysztof gave good summary
> at [1]. We are going on upstream [2], this patch set is just a start
> and base but not like you said for marketing purpose.


I do not think I suggested in [1] to ever send new SoC containing only
CPUs and interrupt controller, without even serial. My instruction [1]
was how to organize it. The DTS can be even fully complete, see the
upstreaming example I have been using all the time - Qualcomm SM8650:

https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/

Entire SoC sent to mailing list on the day one of public release of that
flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
picture, except few trickier pieces... but it even has full display and
GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
patchset references all other bindings with their state, so SoC
maintainers can understand what is the overall progress and what will be
the result in DT schema checks, if they apply the patchset.

The minimum, absolute minimum submission is with the serial nodes. I
would prefer to have some storage or any other interface as well, but
that's fine.


> 
> [1] https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
> [2] https://lore.kernel.org/lkml/20250325101807.2202758-1-guomin.chen@cixtech.com/
> 


Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Arnd Bergmann]

On Thu, Mar 27, 2025, at 08:16, Krzysztof Kozlowski wrote:
> On 27/03/2025 07:44, Peter Chen wrote:
>>>> On 25-03-25 10:52:10, Marc Zyngier wrote:
>> 
>> Thanks for your interesting of our platform, and your comments
>> help us a lot. But I don't think it wastes reviewers and maintainers
>> time, a clean patch set saves everyone's time during upstream process.
>> 
>> For how to organize the patch set for SoC, Krzysztof gave good summary
>> at [1]. We are going on upstream [2], this patch set is just a start
>> and base but not like you said for marketing purpose.
>
>
> I do not think I suggested in [1] to ever send new SoC containing only
> CPUs and interrupt controller, without even serial. My instruction [1]
> was how to organize it. The DTS can be even fully complete, see the
> upstreaming example I have been using all the time - Qualcomm SM8650:
>
> https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/

It is easier if there are other SoCs in the same family that are
already supported than an entire new platform, but we have certainly
done it for new SoC families as well.

> Entire SoC sent to mailing list on the day one of public release of that
> flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
> picture, except few trickier pieces... but it even has full display and
> GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
> patchset references all other bindings with their state, so SoC
> maintainers can understand what is the overall progress and what will be
> the result in DT schema checks, if they apply the patchset.
>
> The minimum, absolute minimum submission is with the serial nodes. I
> would prefer to have some storage or any other interface as well, but
> that's fine.

Agreed. The usual arrangement for a new SoC family is to have
the minimum set of drivers (uart, clk, pinctrl, regulator,
iommu, irqchip) along with the DT bindings and the dts files
in one branch and have that go through the SoC tree as part of
the soc/newsoc branch. It sounds like in this case we only need
uart and a mailbox since the rest are shared with existing
firmware based drivers, so this isn't even the worst case
but still requires some coordination between subsystem maintainers
to ensure that all patches have been properly reviewed before
I merge them.

Any peripheral drivers that are not essential for booting
(typically mmc, ufs, spi, i2c, gpu, sound, pci) can get
submitted at the same time, as there is no dependency on
the platform being merged first.

     Arnd

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

On 25-03-27 09:18:42, Arnd Bergmann wrote:
> 
> On Thu, Mar 27, 2025, at 08:16, Krzysztof Kozlowski wrote:
> > On 27/03/2025 07:44, Peter Chen wrote:
> >>>> On 25-03-25 10:52:10, Marc Zyngier wrote:
> >>
> >> Thanks for your interesting of our platform, and your comments
> >> help us a lot. But I don't think it wastes reviewers and maintainers
> >> time, a clean patch set saves everyone's time during upstream process.
> >>
> >> For how to organize the patch set for SoC, Krzysztof gave good summary
> >> at [1]. We are going on upstream [2], this patch set is just a start
> >> and base but not like you said for marketing purpose.
> >
> >
> > I do not think I suggested in [1] to ever send new SoC containing only
> > CPUs and interrupt controller, without even serial. My instruction [1]
> > was how to organize it. The DTS can be even fully complete, see the
> > upstreaming example I have been using all the time - Qualcomm SM8650:
> >
> > https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/
> 
> It is easier if there are other SoCs in the same family that are
> already supported than an entire new platform, but we have certainly
> done it for new SoC families as well.
> 
> > Entire SoC sent to mailing list on the day one of public release of that
> > flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
> > picture, except few trickier pieces... but it even has full display and
> > GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
> > patchset references all other bindings with their state, so SoC
> > maintainers can understand what is the overall progress and what will be
> > the result in DT schema checks, if they apply the patchset.
> >
> > The minimum, absolute minimum submission is with the serial nodes. I
> > would prefer to have some storage or any other interface as well, but
> > that's fine.
> 
> Agreed. The usual arrangement for a new SoC family is to have
> the minimum set of drivers (uart, clk, pinctrl, regulator,
> iommu, irqchip) along with the DT bindings and the dts files
> in one branch and have that go through the SoC tree as part of
> the soc/newsoc branch. It sounds like in this case we only need
> uart and a mailbox since the rest are shared with existing
> firmware based drivers, so this isn't even the worst case
> but still requires some coordination between subsystem maintainers
> to ensure that all patches have been properly reviewed before
> I merge them.

So, in this case, we should add mailbox driver support in this
series, and once the mailbox maintainer has reviewed mailbox
driver, all the patches could go your tree?

> 
> Any peripheral drivers that are not essential for booting
> (typically mmc, ufs, spi, i2c, gpu, sound, pci) can get
> submitted at the same time, as there is no dependency on
> the platform being merged first.
> 

Thanks for telling us this.

-- 

Best regards,
Peter

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Arnd Bergmann]

On Thu, Mar 27, 2025, at 10:31, Peter Chen wrote:
> On 25-03-27 09:18:42, Arnd Bergmann wrote:
>> Agreed. The usual arrangement for a new SoC family is to have
>> the minimum set of drivers (uart, clk, pinctrl, regulator,
>> iommu, irqchip) along with the DT bindings and the dts files
>> in one branch and have that go through the SoC tree as part of
>> the soc/newsoc branch. It sounds like in this case we only need
>> uart and a mailbox since the rest are shared with existing
>> firmware based drivers, so this isn't even the worst case
>> but still requires some coordination between subsystem maintainers
>> to ensure that all patches have been properly reviewed before
>> I merge them.
>
> So, in this case, we should add mailbox driver support in this
> series, and once the mailbox maintainer has reviewed mailbox
> driver, all the patches could go your tree?

Yes, exactly. Just make sure you describe this in the submission
for the mailbox driver to make sure everyone understands the
plan. I don't think we've had a mailbox driver as the critical
path for a new platform before, so they would usually go through
the mailbox subsystem tree.

     Arnd

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

On 25-03-27 08:16:33, Krzysztof Kozlowski wrote:
> >>
> >> No, you are deliberately choosing to make this platform useless.
> >>
> >> That's a bit sad, and a waste of everybody's time.
> >>
> >
> > Hi Marc,
> >
> > Thanks for your interesting of our platform, and your comments
> > help us a lot. But I don't think it wastes reviewers and maintainers
> > time, a clean patch set saves everyone's time during upstream process.
> >
> > For how to organize the patch set for SoC, Krzysztof gave good summary
> > at [1]. We are going on upstream [2], this patch set is just a start
> > and base but not like you said for marketing purpose.
> 
> 
> I do not think I suggested in [1] to ever send new SoC containing only
> CPUs and interrupt controller, without even serial. My instruction [1]
> was how to organize it. The DTS can be even fully complete, see the
> upstreaming example I have been using all the time - Qualcomm SM8650:
> 
> https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/
> 
> Entire SoC sent to mailing list on the day one of public release of that
> flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
> picture, except few trickier pieces... but it even has full display and
> GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
> patchset references all other bindings with their state, so SoC
> maintainers can understand what is the overall progress and what will be
> the result in DT schema checks, if they apply the patchset.
> 

Hi Krzysztof,

Like I said in this thread before, without this initial support,
we can't even add mailbox binding that the dt_binding_check will
report warnings/errors [1], the reason is "cix" has not existed
at vendor-prefixes binding. How we handle this dependency?

I thought we need to move one step and step before, and keep clean
and avoid warning and error for every submission, but it seems not
the way you prefer. 

If we follow the example you said at [2], we just send dt-binding
patch but without considering its warning, and go on reference the
submission at this patchset cover letter. If it is the prefer way,
we will add serial node, clock node, mailbox node and necessary
header files to satisfy the minimum submission requirement.

> The minimum, absolute minimum submission is with the serial nodes. I
> would prefer to have some storage or any other interface as well, but
> that's fine.
> 

-- 

Best regards,
Peter

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Krzysztof Kozlowski]

On 27/03/2025 09:35, Peter Chen wrote:
> On 25-03-27 08:16:33, Krzysztof Kozlowski wrote:
>>>>
>>>> No, you are deliberately choosing to make this platform useless.
>>>>
>>>> That's a bit sad, and a waste of everybody's time.
>>>>
>>>
>>> Hi Marc,
>>>
>>> Thanks for your interesting of our platform, and your comments
>>> help us a lot. But I don't think it wastes reviewers and maintainers
>>> time, a clean patch set saves everyone's time during upstream process.
>>>
>>> For how to organize the patch set for SoC, Krzysztof gave good summary
>>> at [1]. We are going on upstream [2], this patch set is just a start
>>> and base but not like you said for marketing purpose.
>>
>>
>> I do not think I suggested in [1] to ever send new SoC containing only
>> CPUs and interrupt controller, without even serial. My instruction [1]
>> was how to organize it. The DTS can be even fully complete, see the
>> upstreaming example I have been using all the time - Qualcomm SM8650:
>>
>> https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/
>>
>> Entire SoC sent to mailing list on the day one of public release of that
>> flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
>> picture, except few trickier pieces... but it even has full display and
>> GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
>> patchset references all other bindings with their state, so SoC
>> maintainers can understand what is the overall progress and what will be
>> the result in DT schema checks, if they apply the patchset.
>>
> 
> Hi Krzysztof,
> 
> Like I said in this thread before, without this initial support,
> we can't even add mailbox binding that the dt_binding_check will
> report warnings/errors [1], the reason is "cix" has not existed
> at vendor-prefixes binding. How we handle this dependency?

Not different than all other SoCs. There is no dependency, you just send
your patch and tell where the bindings are. Just like I asked in the [1]
you linked on samsung-soc. Just like all Qualcomm upstreaming goes, e.g.
SM8650 I linked here.

Just like maintainer-soc profiles are explaining. I told you to read
them on IRC.

Your way is contradictory to three sources describing process and two of
these sources - my samsung-soc posting and maintainers-soc-clean-dts
profile - are known to you.

> 
> I thought we need to move one step and step before, and keep clean
> and avoid warning and error for every submission, but it seems not
> the way you prefer. 

No, from where did you get such impression? Maintainers-soc-clean-dts
explicitly covers this case and I WROTE IT, so how can I prefer
something else?

Follow SM8650 style or what's written in maintainer soc profiles.

Best regards,
Krzysztof

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Peter Chen]

On 25-03-27 09:40:10, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL
> 
> On 27/03/2025 09:35, Peter Chen wrote:
> > On 25-03-27 08:16:33, Krzysztof Kozlowski wrote:
> >>>>
> >>>> No, you are deliberately choosing to make this platform useless.
> >>>>
> >>>> That's a bit sad, and a waste of everybody's time.
> >>>>
> >>>
> >>> Hi Marc,
> >>>
> >>> Thanks for your interesting of our platform, and your comments
> >>> help us a lot. But I don't think it wastes reviewers and maintainers
> >>> time, a clean patch set saves everyone's time during upstream process.
> >>>
> >>> For how to organize the patch set for SoC, Krzysztof gave good summary
> >>> at [1]. We are going on upstream [2], this patch set is just a start
> >>> and base but not like you said for marketing purpose.
> >>
> >>
> >> I do not think I suggested in [1] to ever send new SoC containing only
> >> CPUs and interrupt controller, without even serial. My instruction [1]
> >> was how to organize it. The DTS can be even fully complete, see the
> >> upstreaming example I have been using all the time - Qualcomm SM8650:
> >>
> >> https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/
> >>
> >> Entire SoC sent to mailing list on the day one of public release of that
> >> flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
> >> picture, except few trickier pieces... but it even has full display and
> >> GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
> >> patchset references all other bindings with their state, so SoC
> >> maintainers can understand what is the overall progress and what will be
> >> the result in DT schema checks, if they apply the patchset.
> >>
> >
> > Hi Krzysztof,
> >
> > Like I said in this thread before, without this initial support,
> > we can't even add mailbox binding that the dt_binding_check will
> > report warnings/errors [1], the reason is "cix" has not existed
> > at vendor-prefixes binding. How we handle this dependency?
> 
> Not different than all other SoCs. There is no dependency, you just send
> your patch and tell where the bindings are. Just like I asked in the [1]
> you linked on samsung-soc. Just like all Qualcomm upstreaming goes, e.g.
> SM8650 I linked here.
> 
> Just like maintainer-soc profiles are explaining. I told you to read
> them on IRC.
> 
> Your way is contradictory to three sources describing process and two of
> these sources - my samsung-soc posting and maintainers-soc-clean-dts
> profile - are known to you.
> 
> >
> > I thought we need to move one step and step before, and keep clean
> > and avoid warning and error for every submission, but it seems not
> > the way you prefer.
> 
> No, from where did you get such impression? Maintainers-soc-clean-dts
> explicitly covers this case and I WROTE IT, so how can I prefer
> something else?
> 

Krzysztof, I did not mean soc dts, I mean the mailbox binding checking
warning which depends on this patch set.

https://lore.kernel.org/lkml/174290730775.1655008.14031380406017771195.robh@kernel.org/

-- 

Best regards,
Peter

Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Krzysztof Kozlowski]

On 27/03/2025 10:47, Peter Chen wrote:
>>
>>>
>>> I thought we need to move one step and step before, and keep clean
>>> and avoid warning and error for every submission, but it seems not
>>> the way you prefer.
>>
>> No, from where did you get such impression? Maintainers-soc-clean-dts
>> explicitly covers this case and I WROTE IT, so how can I prefer
>> something else?
>>
> 
> Krzysztof, I did not mean soc dts, I mean the mailbox binding checking
> warning which depends on this patch set.
> 
> https://lore.kernel.org/lkml/174290730775.1655008.14031380406017771195.robh@kernel.org/
Ah, right, true and usual solution is:

https://www.kernel.org/doc/html/latest/process/maintainer-soc.html#submitting-patches-to-the-main-soc-maintainers

point 3, but heh, I am repeating myself.


Best regards,
Krzysztof

[PATCH v5 6/6] MAINTAINERS: Add CIX SoC maintainer entry

[Peter Chen]

Using this entry as the maintainers information for CIX SoCs.

Acked-by: Fugang Duan <fugang.duan@cixtech.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
Changes for v5:
- Refine MAINTAINERS for all CIX SoC
- Add T for code tree location
- Add K for Content regex

Changes for v4:
- Add two dts files as maintained files

 MAINTAINERS | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index efee40ea589f..f400e2de573b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2354,6 +2354,17 @@ F:	arch/arm/boot/compressed/misc-ep93xx.h
 F:	arch/arm/mach-ep93xx/
 F:	drivers/iio/adc/ep93xx_adc.c
 
+ARM/CIX SOC SUPPORT
+M:	Peter Chen <peter.chen@cixtech.com>
+M:	Fugang Duan <fugang.duan@cixtech.com>
+R:	CIX Linux Kernel Upstream Group <cix-kernel-upstream@cixtech.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git
+F:	Documentation/devicetree/bindings/arm/cix.yaml
+F:	arch/arm64/boot/dts/cix/
+K:	\bcix\b
+
 ARM/CLKDEV SUPPORT
 M:	Russell King <linux@armlinux.org.uk>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-- 
2.25.1