Please stop throwing every ad-hoc information in the device tree. Use the official bindings (or maybe some bindings which will get approved soon).
On the quest of syncing the device tree used in u-boot with the one used in linux, there is this nice piece:
gic_lpi_base: syscon@0x80000000 { compatible = "gic-lpi-base"; reg = <0x0 0x80000000 0x0 0x100000>; max-gic-redistributors = <2>; };
There is no offical binding for it. Also, the chances that there will be one are virtually zero. We need to get rid of it. In fact, most information there are already known or can be deduced via the offical binding.
More than a month ago NXP [1] said they will look into it and try to get the bindings together. I don't think this will happen. Actually, I don't think the culprit is that commit, but rather the one which introduced that broken binding in the first place [2]. Therefore, revert it, too.
The funny thing is, I don't even know why this is needed at all. Linux will happily setup the LPI for us. At least for the LS1028A (but I guess also for all other layerscape SoC) the u-boot LPI setup code is only called right before we jump to linux. So u-boot doesn't even seem to use the interrupts. Now I can't speak of the Broadcom NS3 SoC where this 'feature' was introduced in the first place [3]. Unfortunately, it's not mentioned in the commit log *why* it was introduced. But this also seem to have crept into the layerscape SoCs [4]. All layerscape boards have CONFIG_GIC_V3_ITS enabled, well except for one; mine, the kontron_sl28 (which has a LS1028A). I haven't noticed anything out of the ordinary, though. Why is CONFIG_GIC_V3_ITS needed?
I briefly tested this on my board with CONFIG_GIC_V3_ITS enabled, at least linux prints: [ 0.000000] GICv3: Using preallocated redistributor tables
and there will be a reserved memory area: reserved-memory { #address-cells = <0x02>; #size-cells = <0x02>; ranges;
gic-rd-tables@20,fff00000 { reg = <0x20 0xfff00000 0x00 0x100000>; }; };
Also please note, that the reverts needed some manual adjustments because there were changes in the meantime.
While this will hopefully not break the layerscape boards, it will definetly break the Broadcom NS3, because the gic_lpi_tables_init() is called without arguments. But, these information are also not available in u-boot't device tree for the ns3. Soooo..
[1] https://lore.kernel.org/all/20210825210510.24766-1-trini@konsulko.com/ [2] https://lore.kernel.org/u-boot/20200726170733.30214-1-rayagonda.kokatanur@br... [3] https://lore.kernel.org/u-boot/20200610104120.30668-10-rayagonda.kokatanur@b... [4] https://lore.kernel.org/u-boot/20200428021935.27659-1-Zhiqiang.Hou@nxp.com/
Michael Walle (1): Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"
Tom Rini (1): Revert "arm64: Layerscape: Survive LPI one-way reset workaround"
arch/arm/Kconfig | 2 - arch/arm/cpu/armv8/fsl-layerscape/soc.c | 41 +++++++++------ arch/arm/dts/fsl-ls1028a.dtsi | 6 --- arch/arm/dts/fsl-ls1088a.dtsi | 6 --- arch/arm/dts/fsl-ls2080a.dtsi | 6 --- arch/arm/dts/fsl-lx2160a.dtsi | 6 --- arch/arm/include/asm/gic-v3.h | 4 +- arch/arm/lib/gic-v3-its.c | 66 +++---------------------- 8 files changed, 35 insertions(+), 102 deletions(-)