Hi,
In a typical interrupt handling sequence we do
1-Read IAR
2-Do interrupt handling
3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC
>> I am suggesting a need of DSB here in case of GICv3 +.
4-Write to GIC cpu interface to do EOI.
Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The
Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be
generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from
core till peripheral which has to be dealt separately as per SOC.
Query: I understand GICv3 system interface accesses are not over this protocol and core will not
follow the ordering rule ?
I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in
RTOS environment where I have a primitive GICv3 driver but I wonder why things does
not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace
due to other device register writes then I would suggest to have one in the EOI clearing API itself.
RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
Thanks
Sandeep