Date: Mon, 24 Nov 1997 05:48:49 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <347901e5.3980414@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711230739.SAA19794@godzilla.zeta.org.au> References: <199711230739.SAA19794@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Nov 1997 18:39:28 +1100, Bruce Evans <bde@zeta.org.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?347901e5.3980414>