Different semantics for enable/disable IRQs

Oleg Subbotin (oleg@rtlinux.cs.nmt.edu)
Mon, 30 Mar 1998 19:14:13 -0700 (MST)


Why is there a different semantics for enable/disable irq (in the case
of SMP) for the old 8259A interrupt controller and for IOAPIC?.

In the case of 8259:
a) A call to disable_irq will increment the disabled_irq[irq_nr] counter
and will hard mask the irq.
b) A call to enable_irq will decrement the disabled_irq[irq_nr] counter
and will hard unmask the irq.

This takes into account multiple calls to disable and enable by
hard enabling the irq whenever the first enable_irq is called.

In the case of io_apic:
a) A call to disable_irq will increment the disabled_irq[irq_nr] counter
b) A call to enable_irq will decrement the counter and olny when the
counter gets to zero does the software emulate all the pending interrupts.

The logic seems different when compared to the 8259

Take this scenario

8259A CASE:
TIME CPU0 CPU1
1:disable_irq
2: disable_irq
3:enable_irq

**** AT THIS POINT IRQ IS ENABLED AND THE HARDWARE UNPENDS ALL THE PENDING
INTERRUPTS

4: enable_irq (decrements the counter and does
nothing else)

IOAPIC CASE:
TIME CPU0 CPU1
1:disable_irq
2: disable_irq
3:enable_irq (decrements the counter but nothing else happens)
4: enable_irq ( ALl the interrupts are unpended by
enable_irq)

Only at Time 4 units does the interrupts get unpended( by the software),
while for 8259a at Time 3 units interrupts get unpended (by the hardware).

Is there something we are missing here, does 8259a controller work
differently?

Thanks in advance for your input

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu