On Tue, 17 Dec 2002, Dominic Sweetman wrote: > > 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. An EOI command (be it the specific or the non-specific version) is used to clear a bit in the ISR (unless the AEOI mode is activated; I'm not sure why Linux doesn't use it as some code could be trimmed down -- probably due to a historical reason) to permit further interrupts from the respective input. But a bit in the ISR is only copied from the IRR upon an ACK. Otherwise the i8259A still considers the IRQ pending. The EOI command has to arrive at the i8259A bus as a write cycle (i.e. with both CS# and WR# active) -- for i8080 and x86 systems a write cycle to a system-specific location in the I/O address space of these processors is typically the most convenient way, but memory-mapping is just fine, too. Also the i8080 has no "return from interrupt" instruction -- the usual sequence is "ei; ret" (this is safe as "ei" defers enabling interrupt acceptance until after the following instruction). It's possible there were systems that incorporated additional glue logic for detecting this sequence of instructions (I haven't met any) and doing writes to an i8259A, but I wouldn't believe they would be capable of sending specific EOIs. Non-specific ones -- certainly, but only for systems with a single i8259A (you can have up to 9 i8259As per an i8080/x86 system for 64 IRQ inputs without additional glue logic or special arrangements). > 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. It shouldn't be necessary for our handling model (but wouldn't hurt either, even for the i386). As we use almost unmodified code from the i386 implementation, there is only a small window when interrupts are marked "in service" by the i8259As -- mask_and_ack_8259A() sends an EOI to the chips before dispatching handlers. As a result there are no masked interrupts with their ISR bits set. > 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. Do they ever need to "know"? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
