Path: utzoo!attcan!uunet!mcvax!ukc!newcastle.ac.uk!systime!jms
From: jms@systime.UUCP (John Skelton)
Newsgroups: comp.os.minix
Subject: Re:  PS/2 level-triggered interrupts
Message-ID: <401@systime.UUCP>
Date: 23 Jan 89 15:17:51 GMT
Reply-To: jms@systime.UUCP (John Skelton)
Organization: Systime Computers Ltd.,Leeds,UK
Lines: 81

In article <1907@ast.cs.vu.nl> you write:
>I suspect what they are trying to say is that if the EOI is issued when the
>level-triggered interrupt is still asserted, you get another interrupt.

This is correct.

Approximately the opposite occurs with edge-triggered interrupts.
In an interrupt routine, if you do nothing to remove the interrupt request
from the I/O device, issue an EOI, and return (IRET, most likely)...
Result: no more interrupts from that device, unless/until the device removes
its interrupt request and re-asserts it.

The Intel/NEC data sheets for the 8272/765 mention using Sense Interrupt Status
multiple times until you get an error (value 0x80, I recall).  This is
so that you know that the chip has told you of every event it had
outstanding -- including any that happened while you were in your interrupt
routine.  Given that at some time the chip had no more to say, it will have
removed its interrupt request.  Another event may, of course, happen while
you are finishing off processing in your interrupt routine.  So long as
you get the software handling the interaction between 765 and 8259A right
things will work, whether another event occurs before your IRET or not.
(If another event does occur, another interrupt will come in after you
leave your interrupt routine.  Well, actually, the request will be pending
as soon as the event occurs... you'll get the interrupt when you re-enable
interrupts, which is normally done by the IRET.)

The problem is getting the interaction between 765 and 8259A right. 

With edge-triggering, it's usually enough to issue a non-specific EOI as
soon as the interrupt routine starts; you don't need to persuade the I/O
device to remove its interrupt request until later.  If there can be
multiple reasons for the interrupt (e.g. several I/O events recognised by
one device, or several I/O devices sharing an interrupt line -- OR'ed
together, that is), you *MAY* need to service every event.  The *MAY* is
there to allow for devices which dutifully lower and raise their interrupt
request every time you service ONE event.  Note that the 765 does NOT do
this -- if it has several things to tell you about, it just leaves its
request outstanding.  In fact, many chips used with Intel micros leave
their interrupt requests raised in just this way.

Level-triggering is better/worse/different...  What you certainly must
*NOT* do is to issue the EOI before servicing the device.  Doing this
is likely to result in the 8259A seeing what it thinks is a new request.
Worse, this request will probably vanish when you service the actual I/O
device.  The 8259A issues a type 7 interrupt in this situation -- in
theory (i.e. as if the device attached to its interrupt request 7 pin
had interrupted).

It is possible to get these type 7 interrupts in edge-triggering, but
not quite so easy :-).  An example would be doing I/O with interrupts
temporarily disabled, and re-enabling at just the wrong time.  This
would be when the non-interrupt-driven code had nearly finished servicing
the cause of the interrupt request (i.e. has just satisfied the I/O
hardware), and then re-enables interrupts very promptly.  Normally,
this possibility can be ignored, but devices with high interrupt rates
(e.g. RS232) can be the cause, as can very fast CPU's.

The "in theory" above is because the 8259A doesn't do much in the way of
latching interrupt requests.  In fact, I think it ONLY latches requests
when it sees the CPU circuitry issuing Interrupt Acknowledge cycles.
In a sense, the 8259A is a priority-encoder asking the CPU for an interrupt
sequence.  The Intel '86 family CPU's don't latch interrupt request, so if
the 8259A experiences an interrupt request which vanishes, the CPU will
never notice it if its interrupt recognition was disabled at the time.  If,
however, the CPU does "see" and act on the interrupt request from the
8259, it will do some special hardware Interrupt Acknowledge cycles.
The 8259A *HAS* to respond to these with *SOMETHING*.  In the sad case
where you caused a transient interrupt request to the 8259A from some I/O
device, and no other device on that particular 8259A happens to need an
interrupt servicing at the instant when the Interrupt Acknowledge cycles
come in, the 8259A just pretends that it was a type 7 interrupt.

Personally, I don't like the way Intel do interrupts; the PDP-11 was
much nicer.  However, the Intel way does work 100% given exactly correct
code.  It's such a shame that the code is hard to get right, and that the
data sheets for such devices as the 8259A and NEC 765 / Intel 8272 are
so bad!!

Enough.  Sorry.  Hope this is some use.  I have Intel-produced flowchart(s)
of sense interrupt status, etc. code somewhere if you want copies.