From owner-freebsd-hackers Sat Nov 29 14:00:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23066 for hackers-outgoing; Sat, 29 Nov 1997 14:00:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23061 for ; Sat, 29 Nov 1997 14:00:33 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-46.cetlink.net [209.54.58.46]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id RAA16448; Sat, 29 Nov 1997 17:00:17 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Date: Sat, 29 Nov 1997 23:01:21 GMT Message-ID: <348095b5.441871@mail.cetlink.net> References: <199711292017.HAA16179@godzilla.zeta.org.au> In-Reply-To: <199711292017.HAA16179@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA23062 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Nov 1997 07:17:23 +1100, Bruce Evans wrote: >>then exit the ISR. How can you be sure that sio1 does not reinterrupt >>before you exit cleanly? >Well, it can't interrupt the CPU since CPU interrupts are masked. That's not what I meant by a new interrupt. Perhaps I should have said "interrupt request presented to the 8259." >New interrupts only get as far as the IRR in the ICU. That's what I meant. >power fails, etc.). This implies that if there is no interrupt pending >on any of the UARTs when they are looked at in the loop, there must have >been no interrupt pending at the start of the loop, so the edge latch >must have been inactive at that time and any subsequent interrupt will >be seen by the ICU and we will get interrupted after we return. OK, I see it now. I did not realize that a complete pass with no interrupt proves that when starting the pass all were low. But as the number of ports per shared IRQ increases, so does the overhead of using that technique. I would like to find a more efficient means if possible. I now see the value of the UNIX status register (which SIO ignores) on my shared interrupt multiport board. The board maker did not even document how it works, but I would guess that for each UART it has a bit which follows the state of the UART's INT output. I may poke around on the board to see if that's true. You could simply read the status register to see if all eight were low and then safely exit the ISR. And you could also avoid checking every UART every time you enter the ISR. John