Re: Why ack interrupt before calling handler?

[Kent Borg <kentborg@borg.org>]

On Wed, Jun 11, 2003 at 12:33:42PM +0200, Kenneth Johansson wrote:
> I don't know what code you are looking at but generally you want to
> first ack to avoid the race condition that would otherwise be present if
> you first run your interrupt routine then ack. How would you know that
> it was in fact not a new interrupt condition that you have not taken
> care of you just removed.

In my case I have a level-triggered interrupt that is latched by the
hardware.

So the first ack tells the interrupt controller to forget about it,
but as the interrupting hardware has not yet been serviced, the
level-triggered interrupt is still being asserted, so that ack becomes
a nop.

Now the specific handler gets called, it deals with the specifics of
the situation, removing the cause of the interrupt, and returns.

Finally the interrupt end gets called, which acks and enables the
interrupt.  This ack actually does something for me.

I am thinking that the general purpose PPC code does the early
ack for edge-triggered circumstances.  For latched level-triggered
cases there is no harm in the extra early ack.


Thanks,

-kb, the Kent whose nose has been closely in that code because he has
been chasing a spurious interrupt problem.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/