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
