[PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree

* [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree
@ 2021-10-27 16:54 Michael Walle
  2021-10-27 16:54 ` [PATCH 1/2] Revert "arm64: Layerscape: Survive LPI one-way reset workaround" Michael Walle
                   ` (3 more replies)
  0 siblings, 4 replies; 28+ messages in thread
From: Michael Walle @ 2021-10-27 16:54 UTC (permalink / raw)
  To: u-boot
  Cc: Vladimir Oltean, Hou Zhiqiang, Bharat Gooty, Rayagonda Kokatanur,
	Simon Glass, Priyanka Jain, Tom Rini, Marc Zyngier,
	Michael Walle

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@broadcom.com/
[3] https://lore.kernel.org/u-boot/20200610104120.30668-10-rayagonda.kokatanur@broadcom.com/
[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(-)

-- 
2.30.2

^ permalink raw reply	[flat|nested] 28+ messages in thread