Am 2021-10-28 13:35, schrieb Bharat Gooty:
On Thu, Oct 28, 2021 at 4:52 PM Michael Walle michael@walle.cc wrote:
Am 2021-10-28 11:20, schrieb Bharat Gooty:
On Thu, Oct 28, 2021 at 2:33 PM Marc Zyngier maz@kernel.org
wrote:
For GIC V3, once the LPI tables are programmed, we can not update
it,
unless we do a reset. For the kexec kernel, where the reboot does not happen, in this
case,
during the new kernel boot, the new LPI tables address will not be updated.
kexec.. this should have really gone into both the commit message _and_ the kconfig menu. In fact, it is really just a workaround for the kexec case. If I understand it correctly, the kernel is able to communicate the reserved memory area, but only if you have EFI support. So, as a workaround, the bootloader can pre-allocate the memory and put it in the device tree, which is then passed from the old to the new kernel and the reservation is preserved. Correct, Marc?
If EFI support is enabled, that's true, Pre-allocate the memory and Kernel can get that memory using EFI. What if EFI support is not enabled, like in a Broadcom NS3 or NXP platform? What is your suggestion for solving the kexec problem?
Iff that is correct what I've said above, then (1) rename the config symbol (I'm not sure, Tom?) and provide a better help text (2) drop the device tree node. after all you only have to allocate the node (3) keep most of the current code, but instead of reading the address from the device tree. Just allocate memory (within the alignment restrictions or whatever) and mark it as reserve it in the device tree. If I understood Marc correct, you can read the number of redistributors from the current gic-v3 binding.
Now, how and if this will fit into the u-boot device model, that's up to you.
In the meantime, it would be great if you can have a look at these two patches and trying to get them work for the ns3, so I can move forward with the device tree sync.
-michael