Am 2021-10-28 13:35, schrieb Bharat Gooty:
On Thu, Oct 28, 2021 at 4:52 PM Michael Walle <mich...@walle.cc>
wrote:
Am 2021-10-28 11:20, schrieb Bharat Gooty:
On Thu, Oct 28, 2021 at 2:33 PM Marc Zyngier <m...@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
