more on the HFC saga

[John Macdonald]

In article <1991Jun1.113531.5096 at blilly.UUCP> bruce at balilly (Bruce Lilly) writes:
|In article <1991May31.185952.4619 at eci386.uucp> jmm at eci386.UUCP (John Macdonald) writes:
|>
|>    (2) When to quit?
|>	This can have such possibilities as: quit after the first
|>	driver has processed an interrupt, quit after all drivers
|>	have been polled once, quit after all drivers have denied
|>	having an outstanding interrupt.
|>
|>(DISCLAIMER: I don't know how these issues were resolved for the
|>3b1 - I've looked into them for other Unix kernels on similar
|>hardware.)
|
|Quitting after the first driver has processed an interrupt does not
|gracefully handle the case where two or more devices have pending
|interrupts at the same interrupt level.

As I said, it is a design decision - i.e. there is no right answer,
just the answer that best matches the circumstances.  Quitting after
the first driver has processed an interrupt causes an immediate new
interrupt to occur and another (full) scan of the list of device [in
the case where there are multiple simultaneous equal level interrupts].
Whether this is a good choice depends upon how often multiple shared
interrupts occur on that particular system/interrupt.  If never, then
the immediate return is a clear win - interrupt processing will take
less time in many cases, and never take more.  If rarely, then it may
still be worth taking the immediate return - the increased delay when
simultaneous interrupts occur may be small compared to the savings
when they don't, as long as there is no danger of losing interrupts
or taking too long to respond when they do occur.

Unless I am remembering wrong, there is no way to check which interrupt
lines are still pending on the 68000 family (unless there is an interrupt
controller chip driving the lines that can be explicitly interrogated),
so the various choices I outlined are the alternatives available.  (You
could view the immediate return method as a way of checking the interrupt
lines - return form interrupt if the line is clear, restart interrupt
processing if the line is still set.)

|The 68000 series interrupt hardware/software uses 3 interrupt lines to
|encode an interrupt priority level (7 possible, as well as a no-interrupt
|condition). When a device, such as a serial interface controller chip,
|wishes to generate an interrupt, it typically drives one of its pins low.
|This signal then usually goes to an interrupt controller, which coverts
|that one signal into the three which the CPU uses. In the 3B1, according
|to the Device Driver Guide, only two interrupt levels are used, so the
|interrupt level encoder might not be required. When the interrupting
|device had had its interrupt serviced, as in reading the data register on
|a serial controller, that device's interrupt output pin is no longer
|driven. If there is another device at the same interrupt level, the CPU
|will still see an interrupt condition. If all devices at the same level
|with pending interrupts have been serviced, the interrupt priority visible
|to the CPU will have changed (if there are no pending interrupts at any
|priority, the CPU will see a no-interrupt condition -- if a higher-pririty
|group of interrupts has been serviced, and there exists one or more
|devices with pending interrupts at a lower priority, the CPU will see the
|lower priority).

Yep, the 68000 family uses level triggered interrupts - some other systems
use edge triggered interrupts.  This is a factor in the design choices.
With edge triggered interrupts, it is necessary to check all devices in
case more than one has triggered the interrupt.  With level triggered
interrupts, there is the option of the immediate return because any device
that simultaneously triggered the interrupt will *continue* to hold the
level set until it gets properly handled.

Such hardware design considerations lead to many software people having
a distinct preference for Motorola processors over Intel.

|Assuming the interrupt servicing code in the kernel does things in a
|logical manner, service routines in the interrupt handling chain need only
|be polled until there are no more pending interrupts at the priority level
|of the chain. If the 3B1's kernel continues throught the chain, that could
|be a source of poor interrupt response time when many device drivers are
|loaded (it could also be fixed).

How do you tell if there is another pending interrupt?  I don't recall
any processor status bits showing the state of those lines.  Either you
poll devices until you think you must have gotten em all, or you return
from the interrupt processing and let another interrupt come in again
immediately if there is another outstanding.  (Polling all devices is
not guarantee there will be not be such an immediate interrupt - you
can have a device raise its interrupt line *after* you have polled it,
while you are still polling a later device...)
-- 
Usenet is [like] the group of people who visit the  | John Macdonald
park on a Sunday afternoon. [...] luckily, most of  |   jmm at eci386
the people are staying on the paths and not pissing |
on the flowers - Gene Spafford