| Message ID | 20250324062420.360289-6-peter.chen@cixtech.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: Introduce CIX P1 (SKY1) SoC | expand |
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.
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/
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.
> > > > 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/
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
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
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. >
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
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.
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/
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
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
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>; + }; +};