Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jan 1997 15:39:13 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        grog@lemis.de, msmith@atrad.adelaide.edu.au
Cc:        hackers@freebsd.org
Subject:   Re: Ints (fwd)
Message-ID:  <199701060439.PAA27615@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> The problem with this is that the gate drives the IRQ line at all
>> times, which isn't what tri-state is all about.  The correct thing
>
>The IRQ lines were never specified as tri-state; see my other mail with
>references to Solari.  The use of the 125 and the OUT2* signal mean
>that if the UART doesn't have interrupts enabled, another device can
>use the IRQ line.  This is sensible design, given the context.

Just about every optional device does it similarly.  It looks like
there has to be a third state to me (when the device isn't driving the
IRQ line).  One interesting side effect is that when the last device
disconnects from an IRQ line, the line usually floats high, and the
edge for this causes an interrupt.  Thus "disabling" interrupts using
the tri-state control usually causes an interrupt.

>> I thought the interrupt was just a pulse.  It certainly was on the
>> 8251.

Not for an 8250, or any device suitable for driving sensible (level
triggered) interrupts directly.

>It works like this (Bruce, if you can be bothered, please correct me if I
>get this wrong) :
>
> 1) Device asserts IRQ signal.
> 2) 8259 detects edge, interrupts CPU
> 3) CPU performs interrupt acknowledge cycle, 8259 latches interrupt 
>    inputs.
> 4) CPU reads 8259, determines interrupting device
> 5) Interrupt handler manipulates peripheral, clears IRQ signal.

>The reason for the latching in step 3) is that the time between 2) and 3)
>can be arbitrarily large (if the CPU has interrupts off, for example), and
>another, higher-priority interrupt may come along in the meantime.

But latching in step 3) doesn't help here.

>If the input goes away between 2) and 3), you get a spurious interrupt (the
>8259 reports it as IRQ 7).  If the input never goes away, there's no
>way for another edge to occur, so 2) never happens.

No, the spurious interrupt is only generated if the interrupt goes away
during the interrupt ack cycle.  Interrupts that go up and down while
they are masked have no effect (unless you watch them).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701060439.PAA27615>