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

Conor.Dooley
2022-08-16T10:10:11Z

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@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@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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>
>
>
>