Subject: Re: Interrupts
To: Michael <macallan18@earthlink.net>
From: Neil Ludban <nludban@columbus.rr.com>
List: port-macppc
Date: 12/06/2004 09:59:12
Michael wrote:
> Hello,
> 
> 
>>But NetBSD calls gc_enable_irq() _before_ calling the pending interrupt handlers.
> 
> Yes, when processing pending interrupts it takes one, enables the corresponding IRQ and then calls the handler(s).
> 
> 
>>For unintelligent interrupt controllers, this is correct for edge-sensitive and
>>unshared level-sensitive interrupts.  A race condition exists for shared level-
>>sensitive interrupts: when two devices have pending interrupts, the interrupt line
>>is never deasserted if the first device gets another interrupt before the second
>>device is handled.
> 
> Hmm, I'm not sure I got this right - the current code calls all handlers associated
 > with an IRQ before proceeding. If another one comes in it gets deferred, marked as
 > pending and the IRQ gets disabled again, so in the next loop it will see the interrupt
 > again and should get through to the 2nd device eventually - as far as I can tell it
 > always calls all handlers for a given IRQ.

I'm making assumptions about the GC implementation, but from the code:

Level signaling means that each device holds the line asserted until it has been
serviced - they are effectively OR'd together.  Another interrupt won't be generated
until the interrupt is deasserted, which only happens when all devices sharing the
IRQ are simultaneously not asserting it.  This is not guaranteed to happen at any
time since each handler can only clear one of the inputs to the "OR gate".  Polling
the line and seeing it deasserted is the only way to ensure the GC's latch has been
reset so it can generate the interrupt again.

-Neil