From owner-freebsd-current  Tue May 27 06:35:28 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id GAA13462
          for current-outgoing; Tue, 27 May 1997 06:35:28 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13452;
          Tue, 27 May 1997 06:35:19 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA10911; Tue, 27 May 1997 23:32:26 +1000
Date: Tue, 27 May 1997 23:32:26 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705271332.XAA10911@godzilla.zeta.org.au>
To: bde@zeta.org.au, se@freebsd.org
Subject: Re: cvs commit: src/sys/sys interrupt.h src/sys/kern kern_intr.c
Cc: current@freebsd.org, gurney_j@resnet.uoregon.edu
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> >[Edge sensitive share interrupts]

>> No, the loop is best done in individual drivers.  The low level

>But it doesn't suffice, that each driver loops as long 
>as is responsible for the activation of the interrupt line.

I assumed only one driver per interrupt line.

>I had been hoping that the low level code could be made 
>to check a flag, which if set would require the ICU to be
>queried about the interrupt pin state. But I've got to
>admit, that it has been too long since I programmed an 8259, 
>and that I don't remember if you could read out the level 
>applied to some edge triggered IRQ pin ... (And you seem
>to tell me, that there is no way to do this ... Too bad!)

You can read the state of the IRQ pin from the request latch
if the edge latch is not set.  Otherwise the request latch
is 0.  There is no way to read or write the edge latch
(other than reinitializing the 8259).  Thus the request latch
is perfectly unusable for recovering from edge triggering
braindamage.  It can only be used to determine the IRQ state
of masked interrupts.

>How about adding a second type of interrupt multiplexer,
>which does expect the device's handler to return a status
>indicating whether this device caused the interrupt ...
>This multiplexer would only be installed for edge-triggered
>IRQ lines, and the faster one that just does a single poll
>pass over all devices would be used for PCI/EISA with level
>triggered interrupts ... ?

This can be now done without changing all drivers by returning
the status in the interrupt descriptor instead of directly.

Bruce