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/
