Why ack interrupt before calling handler?

Why ack interrupt before calling handler?

[Kent Borg]

I am confused by something in ppc_irq_dispatch_handler().  It looks to
me that the interrupt is ack-ed before the handler is called.  Maybe I
am misunderstanding, but doesn't the ack only reset the interrupt
controller?  If so, the interrupting hardware could still be
presenting a level-triggered interrupt.  Wouldn't it make more sense
to let the interrupt routine get service the hardware first, then
reset the interrupt controller?

Thanks,

-kb

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

Re: Why ack interrupt before calling handler?

[Kenneth Johansson]

On Fri, 2003-06-06 at 20:29, Kent Borg wrote:
>
> I am confused by something in ppc_irq_dispatch_handler().  It looks to
> me that the interrupt is ack-ed before the handler is called.  Maybe I
> am misunderstanding, but doesn't the ack only reset the interrupt
> controller?  If so, the interrupting hardware could still be
> presenting a level-triggered interrupt.  Wouldn't it make more sense
> to let the interrupt routine get service the hardware first, then
> reset the interrupt controller?
>

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.

ps. and never ever use edge triggered interrupts

--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsvägen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken@switchboard.ericsson.se


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

Re: Why ack interrupt before calling handler?

[Wolfgang Denk]

In message <1055327622.26152.70.camel@spawn> you wrote:
>
> ps. and never ever use edge triggered interrupts

Oops? Why not?

We use them all the time, and find  that  they  are  much  easier  to
handle than level triggered interrupts.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
How many QA engineers does it take to screw in a lightbulb? 3:  1  to
screw it in and 2 to say "I told you so" when it doesn't work.

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

Re: Why ack interrupt before calling handler?

[eric lescouet]

Kent,

The acq_irq() routine called at the beginning of ppc_irq_dispatch_handler() is
mapped to the associated routine of the PIC driver that handles the irq.
Typically such routine would mask the interrupt source at PIC level, than
acknowledge the PIC in some way, if required (any kind of EOI).
This would prevent a level triggered interrupt to be raised again when enabling
interrupts at processor level, until the called handler clear the interrupt
condition on the device.
The, the interrupt source unmasked after processing by the handler.

Any way, note that these routines called from irq.c are PIC driver specific,
thus allowing such drivers to implement different policies depending on the
underlaying hardware capabilities:
- edge vs level triggered interrupts,
- relative priority schemes,
- "in service" interrupt management internal capability, or required explicit
masking (of currently in service interrupt).
... etc

Regards,

	Eric Lescouet.

Kenneth Johansson wrote:
> On Fri, 2003-06-06 at 20:29, Kent Borg wrote:
>
>>I am confused by something in ppc_irq_dispatch_handler().  It looks to
>>me that the interrupt is ack-ed before the handler is called.  Maybe I
>>am misunderstanding, but doesn't the ack only reset the interrupt
>>controller?  If so, the interrupting hardware could still be
>>presenting a level-triggered interrupt.  Wouldn't it make more sense
>>to let the interrupt routine get service the hardware first, then
>>reset the interrupt controller?
>>
>
>
> 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.
>
> ps. and never ever use edge triggered interrupts


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

Re: Why ack interrupt before calling handler?

[Kent Borg]

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/

Re: Why ack interrupt before calling handler?

[Kent Borg]

On Wed, Jun 11, 2003 at 02:24:23PM +0200, eric lescouet wrote:
> This would prevent a level triggered interrupt to be raised again when enabling
> interrupts at processor level, until the called handler clear the interrupt
> condition on the device.

And it occurs to me that unless an interrupt can be "queued" between
the time the handler has checked (one last time) for all pending work
and the PPC code re-enables the interrupt at the PIC level, this would
be a window in which an edge-triggered interrupt could be lost.

> Any way, note that these routines called from irq.c are PIC driver
> specific,

Yes.  I have one set of PIC code that is for an interrupt controller
that is on-chip with the CPU, and I have a second set of PIC code for
a cascaded interrupt controller that is implemented in an off-chip
FPGA.  It is kind of cool that such nested complexity can be so nicely
represented to the kernel by simply having a single flat list of IRQs.
(I didn't spot that simple solution, Dale Farnsworth had to point it
out to me.)


Thanks,

-kb, the Kent who is willing to learn from others.

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

Re: Why ack interrupt before calling handler?

[Kenneth Johansson]

On Wed, 2003-06-11 at 14:39, Kent Borg wrote:
> On Wed, Jun 11, 2003 at 12:33:42PM +0200, Kenneth Johansson wrote:

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

Hopefully this ack only happens if the interrupt is level triggered
otherwise you have a problem.

> 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.

Thats right.

--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsvägen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken@switchboard.ericsson.se


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