Hi Varun,
Out of curiosity, I'm trying to understand how far this change is generic or a specific chipset workaround? In other words, how does this deviate from the Arm architecture?... Is this a common practise to disable PEs but leave their MPIDR identification into the GIC?
The redistributor probing implemented in Hafnium is very much the same pattern as in the TF-A GIC driver. In the Hafnium case, would it be nicer to walk the list of cpus declared in the spmc manifest, and match the corresponding MPIDR from redistributor?
Regards, Olivier.
________________________________________ From: Varun Wadekar via Hafnium hafnium@lists.trustedfirmware.org Sent: 14 February 2022 19:04 To: hafnium@lists.trustedfirmware.org Cc: Bo Yan Subject: [Hafnium] GICR discovery
Hello team,
Currently the amount of memory allocated for GICR frames is determined by the number of supported CPUs. However, the GIC redistributor might have more frames than the number of PEs. In such a case, it is possible that the core index constructed from GICR_TYPER register points to a non-existent PE. For such a case, the GIC discovery and init sequence should move to the next redistributor frame. Today, the code asserts if there are holes in the CPU topology or if GICR_FRAMES > MAX_CPUS.
Downstream Tegra platforms provide more GICR frames than number of CPUs and require the support posted to gerrit [1]. Request the team to review and post feedback.
Thanks.
[1] topic:"gicv3-gicr-frames" (status:open OR status:merged) * Gerrit Code Review (trustedfirmware.org)https://review.trustedfirmware.org/q/topic:%22gicv3-gicr-frames%22+(status:open%20OR%20status:merged) -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org