Hi Sandeep,
gicv3_end_of_interrupt_sel1 is a static access helper macro. Its naming precisely tells what it does at gicv3 module level. It is called from the weak plat_ic_end_of_interrupt function for BL32 image.
I tend to think it is the driver responsibility to ensure the module interrupt acknowledge register write is reaching HW in order (or "be visible to all observers"). Also I suspect adding a dsb might not be required generically for all kind of IP. Adding a barrier in generic code might incur an unnecessary bottleneck.
Thus wouldn't it be better to add the barrier to the overridden platform function rather than in generic gicv3 code?
I have a put a comment in the review, we can continue the discussion there.
Regards, Olivier.
________________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Sandeep Tripathy via TF-A tf-a@lists.trustedfirmware.org Sent: 05 June 2020 19:43 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] GICV3: system interface EOI ordering RFC
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