On 16/08/2022 10:17, Heiko Stübner wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Am Montag, 15. August 2022, 18:56:23 CEST schrieb Conor.Dooley@xxxxxxxxxxxxx: >> On 15/08/2022 06:08, Samuel Holland wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> Allwinner manufactures the sunxi family of application processors. This >>> includes the "sun8i" series of ARMv7 SoCs, the "sun50i" series of ARMv8 >>> SoCs, and now the "sun20i" series of 64-bit RISC-V SoCs. >>> >>> The first SoC in the sun20i series is D1, containing a single T-HEAD >>> C906 core. D1s is a low-pin-count variant of D1 with co-packaged DRAM. >>> >>> Most peripherals are shared across the entire chip family. In fact, the >>> ARMv7 T113 SoC is pin-compatible and almost entirely register-compatible >>> with the D1s. >>> >>> This means many existing device drivers can be reused. To facilitate >>> this reuse, name the symbol ARCH_SUNXI, since that is what the existing >>> drivers have as their dependency. >> >> Hey Samuel, >> I think this and patch 12/12 with the defconfig changes should be >> deferred until post LPC (which still leaves plenty of time for >> making the 6.1 merge window). We already have like 4 different >> approaches between the existing SOC_FOO symbols & two more when >> D1 stuff and the Renesas stuff is considered. > > On the other hand, I don't really think it's that hard to change things > after the fact? I.e. ARCH_SUNXI is pretty much set in stone anyway, > so there isn't very much that _could_ change without affecting most > driver subsystems in the kernel. > > So I don't think we'd actually need to wait with the Allwinner symbol. True, but it'd be the same release anyway most likely so I don't think that there'd really be any waiting involved. I /like/ the idea of using ARCH_FOO rather than SOC_FOO as it's far more consistent across the kernel - it's more a question of not doing one thing here and another with the Renesas stuff to me. > > > Heiko > >> Plan is to decide at LPC on one approach for what to do with >> Kconfig.socs & to me it seems like a good idea to do what's being >> done here - it's likely that further arm vendors will move and >> keeping the common symbols makes a lot of sense to me... >> >> Thanks, >> Conor. >> >>> >>> Signed-off-by: Samuel Holland <samuel@xxxxxxxxxxxx> >>> --- >>> >>> arch/riscv/Kconfig.socs | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs >>> index 69774bb362d6..1caacbfac1a5 100644 >>> --- a/arch/riscv/Kconfig.socs >>> +++ b/arch/riscv/Kconfig.socs >>> @@ -1,5 +1,14 @@ >>> menu "SoC selection" >>> >>> +config ARCH_SUNXI >>> + bool "Allwinner sun20i SoCs" >>> + select ERRATA_THEAD if MMU && !XIP_KERNEL >>> + select SIFIVE_PLIC >>> + select SUN4I_TIMER >>> + help >>> + This enables support for Allwinner sun20i platform hardware, >>> + including boards based on the D1 and D1s SoCs. >>> + >>> config SOC_MICROCHIP_POLARFIRE >>> bool "Microchip PolarFire SoCs" >>> select MCHP_CLK_MPFS >>> -- >>> 2.35.1 >>> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/linux-riscv >> > > > >
