ISA vs PCI interrupt handling

ISA vs PCI interrupt handling

[Krzysztof Halasa]

Hi,

A simple question: there are drivers for ISA and PCI devices. The IRQ
handlers are registered with request_irq(flags = 0) or
request_irq(SA_SHIRQ) for PCI.

In both cases, the device raises an IRQ line and the handler is called.
Does the handler have to make sure the device has lowered the IRQ?
I mean, in situation where the handler terminates with the IRQ line
being still active, will the handler be called again, or will the
driver deadlock? Does is behave differently on ISA and PCI?


Many network drivers use something like this:

static void
net_rx(struct net_device *dev)
{
        int boguscount = 10;
        do {
                do_something();
        } while (--boguscount);
}

Will such an IRQ handler work correctly after boguscount reaches 0?
Or is it just a protection against runaway devices, and it's normal
that they die from it (possibly recovering through a timer)?


My experiments with ISA devices show that after the handler terminates
without i.e. handling all requests, the IRQ line is stuck at +5V
(= logical "active" level) and the handler isn't called anymore.

Or does that mean the IRQ is edge-triggered, and the handler is being
called just once a low-to-high edge is detected?
-- 
Krzysztof Halasa
Network Administrator

Re: ISA vs PCI interrupt handling

[Alan Cox]

On Iau, 2003-04-03 at 00:20, Krzysztof Halasa wrote:
> Hi,
> 
> A simple question: there are drivers for ISA and PCI devices. The IRQ
> handlers are registered with request_irq(flags = 0) or
> request_irq(SA_SHIRQ) for PCI.
> 
> In both cases, the device raises an IRQ line and the handler is called.
> Does the handler have to make sure the device has lowered the IRQ?
> I mean, in situation where the handler terminates with the IRQ line
> being still active, will the handler be called again, or will the
> driver deadlock? Does is behave differently on ISA and PCI?

For PCI at least you must mask the IRQ on your device in that situation.
It must also be masked on the device not via disable_irq

Re: ISA vs PCI interrupt handling

[Krzysztof Halasa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> For PCI at least you must mask the IRQ on your device in that situation.
> It must also be masked on the device not via disable_irq

Thanks.
Looks like it's even more important on ISA.
-- 
Krzysztof Halasa
Network Administrator

Re: ISA vs PCI interrupt handling

[Jonathan Lundell]

At 1:20am +0200 4/3/03, Krzysztof Halasa wrote:
>I mean, in situation where the handler terminates with the IRQ line
>being still active, will the handler be called again, or will the
>driver deadlock? Does is behave differently on ISA and PCI?
>...
>My experiments with ISA devices show that after the handler terminates
>without i.e. handling all requests, the IRQ line is stuck at +5V
>(= logical "active" level) and the handler isn't called anymore.
>
>Or does that mean the IRQ is edge-triggered, and the handler is being
>called just once a low-to-high edge is detected?

The "legacy" ISA interrupt controller has various modes, but the 
legacy mode is to be edge-sensitive. Edge-sensitivity here isn't 
quite what a hardware engineer would mean by it, but it does mean 
that, once an interrupt has been triggered, it has to go low before 
another interrupt can be recognized. That's consistent with your 
experiments. In general, an ISA interrupt service loop needs to be of 
the form: while (device is interrupting) { service the interrupt }

Shared interrupts (eg PCI) are different, of course. Because they're 
shared, the interrupt controller can't be edge-sensitive. One problem 
would be that another (interrupt sharing) device can hold the 
interrupt line active (low for PCI), so two devices could in 
principle interrupt alternately and the interrupt line itself never 
go inactive, and no edges would be seen by the interrupt controller.

The same service loop should work just fine, but the penalty for not 
servicing a PCI interrupt should just be that the ISR will get 
invoked again. Of course, that will go on forever unless the 
interrupt *is* serviced, but you can get away with servicing one at a 
time, and taking an interrupt for each event. Not necessarily 
efficient, but it should work.

Depending on the interrupt controller, an interrupt may need to be 
ACKed; this is definitely true for legacy ISA interrupt controllers. 
That's not typically a driver function, as I recall.
-- 
/Jonathan Lundell.