summaryrefslogtreecommitdiff
path: root/arch/arm/mach-versal2/include
AgeCommit message (Collapse)Author
4 daysarm64: versal2: Move board_early_init_r clock setup to mach codeMichal Simek
board_early_init_r() programmed the IOU switch clock and the system timestamp counter directly with readl()/writel() in board code. This is SoC register setup rather than board policy, and the same block is duplicated across the Xilinx SoCs. Move it into versal2_timer_setup() in arch/arm/mach-versal2 so the board hook only keeps the EL3 guard and calls the helper. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.1782219202.git.michal.simek@amd.com
4 daysarm64: versal2: Move bootmode decoding out of board codeMichal Simek
versal2_get_bootmode() lived in board code and accessed the CRP boot mode register with a direct readl(). To keep generic board code free of SoC register details and ready for firmware/SCMI based access, move the whole function, including the alt-shift and mask decoding, into arch/arm/mach-versal2 as a __weak default. Board code now simply calls versal2_get_bootmode(). When a firmware based implementation is available and tested it can provide a strong definition that overrides the weak one at link time; until then only the weak MMIO version is built. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/f3274ec77218373bc0452f6795a3ad6016be0058.1782219202.git.michal.simek@amd.com
4 daysarm64: versal2: Decouple multiboot register access from firmwareMichal Simek
versal2_multi_boot() in board code selected between the firmware call zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not carry firmware-specific ifdefs, and this becomes harder to maintain once SCMI introduces yet another access method. Introduce an overridable accessor versal2_pmc_multi_boot(). The weak default lives in arch/arm/mach-versal2 and performs the plain MMIO read (used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE is enabled, firmware-zynqmp.c provides a strong definition that issues the firmware call, falling back to the direct read at EL3 where the SMC path to firmware is unavailable. The shared MMIO read is factored into versal2_multi_boot_reg() so the firmware override does not duplicate it. versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply calls the accessor, so board code no longer references the firmware interface and the now unused zynqmp_firmware.h include is dropped. The firmware-vs-MMIO decision is selected at link time, and adding SCMI later only requires a third strong definition with no board-code changes. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com
4 daysarm: xilinx: Guard mach sys_proto.h against multiple inclusionMichal Simek
The Versal and Versal Gen 2 mach sys_proto.h headers lacked an include guard. mach-versal/sys_proto.h additionally defines enum tcm_mode, so including it twice in one translation unit fails to build with a redeclaration error. This is about to happen in firmware-zynqmp.c, which needs the SoC prototypes unconditionally for the upcoming weak/strong multiboot and bootmode accessors. Add the standard _ASM_ARCH_SYS_PROTO_H guard, as already used by mach-zynqmp, so the header can be included more than once. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com
2026-06-08arm64: xilinx: Add PMC PGGS3 and PGGS4 registersPadmarao Begari
Add PMC Global PGGS3 and PGGS4 register defines to Versal and Versal Gen 2 hardware headers. These registers hold boot index and boot metadata required for FWU multi-bank update support. Signed-off-by: Padmarao Begari <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2026-02-13arm64: versal2: Populate DRAM banks before page table size calculationPranav Sanwal
Move DRAM bank detection from fdtdec to custom implementation to ensure memory banks are populated before get_page_table_size() is called during MMU initialization. The current fdtdec-based approach populates gd->bd->bi_dram[] too late in the boot sequence, causing get_page_table_size() to be called with unpopulated DRAM information. This prevents dynamic page table sizing based on actual memory configuration. Parse /memory nodes in dram_init() to fill versal2_mem_map[] early enough for MMU setup. Supports up to CONFIG_NR_DRAM_BANKS (36) non-contiguous banks with high memory regions (>4GB) and use __weak get_page_table_size implementation to estimate page table size based on the populated DRAM banks. Signed-off-by: Pranav Sanwal <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2025-12-19arm64: versal2: Read and show multiboot valueMichal Simek
SOC can boot from different boot medias and also different offsets that's why by default show multiboot value to be aware which image system is booting out of. It is especially useful for systems with A/B update enabled. Also limit zynqmp_pm_get_pmc_multi_boot_reg() usage only for Versal and Versal Gen 2. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/fd7564ce2f51d965c273e939e98de01beb92e6f5.1764232124.git.michal.simek@amd.com
2025-04-16ufs: amd-versal2: Use raw read/write for SLCR/CACHE registersVenkatesh Yadav Abbarapu
Update the firmware driver UFS APIs zynqmp_pm_ufs_* to directly read/write to the pmc_iou_slcr and efuse_cache registers. Replace these raw reads/writes with the xilinx_pm_request() API with the correct arguments once the PM related changes are done. Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/ee2d1ad2e07e96f1948ab6ffe8f3c50a3b8f9be9.1742462001.git.michal.simek@amd.com
2025-04-16amd: versal2: Add the UFS boot mode supportVenkatesh Yadav Abbarapu
Add the UFS boot mode support and update the boot_targets with ufs mode. If the UFS device is not accessible from APU and running this is detected as a warning, as the device is not accessible. Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-03-03arm64: versal2: Show major and minor silicon versionMichal Simek
ES1 silicon is 0x10 (16) and production is 0x20 (32) but correct number to see are v1.0 or v2.0 instead of v16 or v32. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/20095339334fe07f373ffae3bdbfec51f5a00dc7.1739882585.git.michal.simek@amd.com
2024-06-17arm64: versal2: Add support for AMD Versal Gen 2Michal Simek
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2 cpu core each. A lot of IPs are shared with previous families. There are couple of new IP blocks where the most interesting from user point of view is UFS. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com