Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal

["Ashish Singhal" <ashishsingha@nvidia.com>]

From: Marc Zyngier <maz@kernel.org>
Sent: Tuesday, October 12, 2021 9:44 AM
To: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Ard Biesheuvel <ardb@kernel.org>; edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@nuviainc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal 
 
External email: Use caution opening links or attachments


Ashish,

Please don't top post, and please use plain text.

On Tue, 12 Oct 2021 15:56:58 +0100,
Ashish Singhal <ashishsingha@nvidia.com> wrote:
>
> Marc,
>
> In the document ARM062-1010708621-30 (AArch64 Programmer's Guides
> Generic Timer), towards the end of section 3.4 it says: "When
> writing an interrupt handler for the timers, it is important that
> software clears the interrupt before deactivating the interrupt in
> the GIC. Otherwise, the GIC will re-signal the same interrupt
> again."

This document is a waste of valuable bits, unfortunately, and isn't an
architecture reference.

> My change was in accordance with this. We only clear the interrupt
> when we update the compare value but were signaling EOI before that
> going against the guidance in the document.

There is no such requirement in the GIC architecture, as it makes no
guarantee on how much time it takes for a change of level to be
observed. Given that, this change is pretty much immaterial.

        M.

--
Without deviation from the norm, progress is not possible.

Marc,

What do you suggest should be the proper fix for getting timer interrupts even when ISTATUS bit is not set? Should we ignore them the way it is in current implementation? I am OK to file a bug for this if you think that is a better way to discuss this.

Shanker,

Any thoughts on this?

Thanks
Ashish