[PATCH 05/12] riscv: Add the Allwinner SoC family Kconfig option

[Conor.Dooley at microchip.com]

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 at microchip.com:
>> 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 at sholland.org>
>>> ---
>>>
>>>   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 at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
> 
> 
> 
>