[Top] [All Lists]

Re: [PATCH] add dispatch_i8259_irq() to i8259.c

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Dominic Sweetman <>
Date: Tue, 17 Dec 2002 14:35:22 +0000
Cc: Jun Sun <>, Ralf Baechle <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
>  The i8259A doesn't work this way.  With your proposed code the IRR
> is never cleared (which is a problem for edge-triggered interrupts
> -- such an interrupt gets signalled again once it's unmasked, until
> deasserted by a device).  The i8259A only clears a bit in the IRR
> when it receives an ACK (it then copies the bit to the corresponding
> bit of the ISR) or when an interrupt goes away (a device deasserts
> it).

Just a few comments on the hardware:

As I recall, you can clear a stored edge-triggered interrupt using a
"specific EOI".  In the 8080 microprocessor for which the 8259 was
designed, this command was magically communicated to the 8259 when the
CPU ran its "return from interrupt" instruction.  I think even in the
8086 this had to be replaced with an explicit I/O cycle.

People not using x86 CPUs should consider putting the i8259 into
"special mask mode".  Then it behaves simply and predictably,
providing an interrupt on any active unmasked input.  You lose the
i8259 interrupt priority stuff, but this is only one of the
advantages.  You'd need to be reasonably knowledgeable about the Linux
interrupt system to make this clean and compatible with the x86
versions, but then these troubles would be over for ever and you'd be
a Hero, First Class.

Alternatively, many MIPS systems have a hardware feature which enables
them to generate imitation-x86 interrupt acknowledge cycles, so you
can keep the 8259s in complete ignorance that they're not being
controlled by an x86.  

Dominic Sweetman
MIPS Technologies

<Prev in Thread] Current Thread [Next in Thread>