[PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC

[Michal Simek]

On 5/30/24 16:08, Tom Rini wrote:
> On Thu, May 30, 2024 at 08:04:07AM +0200, Michal Simek wrote:
>> Hi Tom,
>>
>> On 5/29/24 18:13, Tom Rini wrote:
>>> On Wed, May 29, 2024 at 04:47:57PM +0200, Michal Simek wrote:
>>>
>>>> Hi,
>>>>
>>>> I am sending patches for adding initial support for new AMD Versal Gen 2
>>>> SoC. If you want to find out more information please take a look at this
>>>> page:
>>>> https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html
>>>>
>>>> Thanks,
>>>> Michal
>>>>
>>>>
>>>> Michal Simek (4):
>>>>     arm64: versal2: Add support for AMD Versal Gen 2
>>>>     soc: versal2: Add SoC driver for AMD Versal Gen 2
>>>>     mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2
>>>>     spi: versal2: Enable spi drivers for Versal Gen 2
>>>
>>> My only concerns are name-related and not-blocking. First, should we
>>> perhaps instead have arch/arm/mach-versal/{gen2,net}/ (and presumably
>>> gen2-net down the line)?
>>
>> There are completely 3 different SOCs only names are similar
>> Versal is 2 cores a72
>> Versal NET 16 cores a78
>> Versal Gen 2 8 cores a78
>> with different features.
> 
> That's good to know.
> 
>> Creating subfolders under current mach-versal would be very confusing.
>> We can definitely try to make it as small as possible but still they are
>> separated families.
> 
> Again, I'm not nak'ing things based on the names but I'll point out that
> arch/arm/mach-k3/{am*,j7*}/ contain a good number of A53 and A72
> platforms of varying numbers of cores. But on the other hand, at some
> level they're all part of the "Keystone 3" generation / family, which is
> not how the Versal parts are handled.

For us it is completely new generation. There are some sub variants which can be 
handled like that. https://docs.amd.com/v/u/en-US/versal-ai-edge-gen2-psg

AI Edge, AI Core, Prime, Premium, HBM but we trying to handle it via 
common/shared target. If there is a difference we are trying to handle via DT 
and enable all drivers via generic defconfig.

We can definitely take a look if make sense to create mach-xilinx or mach-amd.
It would be best if we can pretty much get rid of all these folders but I don't 
think we get there anytime soon.


>> We tried to reuse existing platforms but it is hard to keep it in sync
>> that's why new platform is better way to go.
>> But as you know we are trying to reuse for example board/xilinx/common/
>> folder as much as possible that we don't have code duplication.
> 
> That's also good and reasonable.
> 
>>> Second, and I see I can't say we should follow
>>> the Linux kernel since there's no versal dts files upstream, should we
>>> still be "xilinx" and not "amd" ? I do see the kernel shoves all the
>>> imx8 (as an example of a modern part) stuff under
>>> arch/arm64/boot/dts/freescale/ and if nothing else we should be
>>> consistent between projects whenever possible. Thanks.
>>
>> I am not going to send DTSes to U-Boot and just push them to Linux kernel at
>> right time. And target is arch/arm64/boot/dts/amd which already exists for
>> old amd socs and elba (pensando). Versal Gen 2 should go there.
>>
>> It means Versal and Versal NET will be branded under Xilinx and Versal Gen 2
>> will be branded under AMD. Also we are going to stop to use xlnx, dt
>> prefixes for new IPs and will start to use amd, prefix.
> 
> My real only concern here is that we're consistent with whatever Linux
> Kernel people demand. It's bikeshedding I'm really not inclined to argue
> myself. :)

What we looked in past was if we can put together platforms with gicv2 and gicv3 
because there is low level GIC initialization when you run in EL3 but we didn't 
finish it.
I think the first step would be to get rid of include/configs/ files and then we 
can look at other parts.

Thanks,
Michal