Date: Mon, 24 Nov 1997 19:06:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mouth@ibm.net (John Kelly) Cc: bde@zeta.org.au, hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <199711241906.MAA14773@usr01.primenet.com> In-Reply-To: <347901e5.3980414@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 24, 97 05:48:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >/* > > * 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. I think this is specifically for the 4 port "Comtrol Hostess" boards. > 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). ;-) Actually, it's possible for DOS machines to be perfectly happy in switching interrupt driven input from COM1 (to say a terminal server) to COM3 (to say a modem). UNIX systems should be able to function on the same hardware Windows95 can function on, I think. At the very worst, there should be an open interlock on the devices, but both should remain accessible in the general sense of allowing me to close one to open the other (ie: alternate the interrupt programming based on the open). At best, both devices should be queriable and function simultaneously (as in the loop you question, above). Philosophically, you should buy good hardware. But also philosophically, you should work on the hardware you're given. > 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. Is this one of those "take an interrupt, then poll like hell" type drivers? 8-). > 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. The more code, the merrier. 8-). > 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. This is typically handled using a line discipline to drop the FIFO trigger level (ie: for serial mice, etc.). I believe there's also a timeout based trigger for long packet protocols that really need the FIFO to reduce service overhead (ie: for high speed ppp and slip). Are you using a different approach? > 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. Please, don't. The compiler will put the jump instructions back in, anyway, and all you'll have done is increase the code path by one or more tests, slowing the thing down. A goto is a perfectly reasonable way to handle an exception, and it's much easier to find the target of a "goto" than a "break", especially given stylistic differences over placement of squiggly brackets. 8-(. I think Bruce's code is already pretty optimal (FASTINTR is his baby); that's not to say that you shouldn't integrate what you have (maybe you should; I haven't seen it, hence my question marks, above), but be careful. Not all of the reasons for a particular approach are documented (ie: you knew there was a loop, and what it putatively claimed to do, but there wasn't a reason *why* included in the comment, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711241906.MAA14773>