From owner-freebsd-hackers Sun Nov 23 20:48:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03311 for hackers-outgoing; Sun, 23 Nov 1997 20:48:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03300 for ; Sun, 23 Nov 1997 20:48:25 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-93.ca.us.ibm.net (slip129-37-53-93.ca.us.ibm.net [129.37.53.93]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id EAA71270; Mon, 24 Nov 1997 04:47:49 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Mon, 24 Nov 1997 05:48:49 GMT Message-ID: <347901e5.3980414@smtp-gw01.ny.us.ibm.net> References: <199711230739.SAA19794@godzilla.zeta.org.au> In-Reply-To: <199711230739.SAA19794@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 UAA03301 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 23 Nov 1997 18:39:28 +1100, Bruce Evans wrote: >>After emptying the block, you could leave any remaining characters in >>the FIFO, and simply get them on the next interrupt >Here is some (low quality, old and unfinished) code for doing this. >It has some interface changes (void *vcom, and siointr1() called >directly from XintrN()) that won't work in -current. I applied the patch to 2.2.5 sio.c -- the first hunk failed but the rest succeeded. Just curious, what is vcom all about? In any case, after starting to analyze the patch vs. sio.c I have many questions of a more urgent nature. In siointr I read the following comment: >/* > * Loop until there is no activity on any port. This is necessary > * to get an interrupt edge more than to avoid another interrupt. > * If the IRQ signal is just an OR of the IRQ signals from several > * devices, then the edge from one may be lost because another is > * on. > */ I believe this is untrue. If so, that may call certain aspects of siointr into question. On an ISA bus, several devices cannot OR their IRQ lines at all, unless you are willing to heat up a soldering iron, or purchase a multiport card with hardware logic for IRQ sharing. Otherwise, the totem pole output of any one device holding its line low will sink the output of all others to ground and you will never see an interrupt from any of the ORed devices. Any device which is active *must* either pull the line to ground or drive it high. An active device cannot float its output, because a transition from floating to high will not guarantee a rising edge. The transition *must* be from ground to high. Without soldering techniques or extra hardware logic, the only type of ISA bus IRQ ORing possible is where the devices have tri-state outputs and only one is active while the rest float. An example is the classic case of COM1/COM3 where both try to use the same IRQ line, but not simultaneously. They "share" the IRQ line like you and I might share a book -- we can't both use it at the same time. Incidentally, there is some code in sioprobe which floats the IRQ output of all UARTs, attempting to find all which may be "sharing" an IRQ in the COM1/COM3 manner. I would change that and force users to set up their COM ports correctly (at least for UNIX). ;-) I changed my own copy of sioprobe to drive the IRQ output, letting each UART pull its line to ground during sioprobe. I had to do that because I built a homebrewed OR gate for all the serial cards in one of my test machines, and I forgot to use a pull down resistor on each input and there wasn't enough room left on my proto board to add them after I was finished. It was much quicker to change that one line of code in sioprobe than throw out my custom design and start all over. Anyway, I want to purse this issue of whether looping in siointr is "necessary to get an interrupt edge," because it has a direct impact on how siointr might be improved with UART burst mode input. I wrote a code fragment in Turbo C which implements a highly optimized framework (not a finished product) for UART receiver burst mode if you want to see it. It also handles the case of FIFO timeout where you need to read characters in the usual way, one at a time. I tested it in a small terminal program and it works well. I would like to integrate it with sio.c, but I'm never satisfied with my C code until I've eliminated all goto statements. Extracting the many from sio.c might take a long time, and I don't know if I'm ready to jump into that snakepit. John