Date: Wed, 12 Nov 1997 23:29:39 GMT From: mouth@ibm.net (John Kelly) To: Terry Lambert <tlambert@primenet.com> Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <346b36af.1755787@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711122154.OAA20137@usr05.primenet.com> References: <199711122154.OAA20137@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Nov 1997 21:54:42 +0000 (GMT), Terry Lambert <tlambert@primenet.com> wrote: >> Why can't we handle large bursts of input? > >Bruce can correct me, but I believe it's because the FASTINTR code >expects to run to completion, and that expectation means that it >can't take more than a small amount of time to process the interrupt. >Processing the additional caharacters puts it over the limit. Anybody know how high the limit is? >> Yes, but I don't see why the design of the 650 would make you want to >> handle it completely in hardware. >I don't think you can split interrupt types for this. I think the >reason the code is FASTINTR code is so that it can deal with the >characters and prevent an input overflow. If you can do that in >hardware, you should The 650 auto RTS function is "automatic" -- the chip knows when to raise RTS and suspend the input stream from the external device. In that sense, we would be "doing it in hardware." But that does not mean doing it "all" in hardware. My reason for wanting to use 650 auto RTS is to guarantee that interrupt latency will never cause the UART to be overrun and sio.c report silo overflows. I don't see that it matters whether it's ever invoked or not -- sio.c should be able to work pretty much the way it always has. > instead of doing it via FASTINTR to reduce the amount of code you > actually run at high spl. I don't want to split interrupt types. The serial ISR running at high privilege level can continue working the way it always has. The 650 auto RTS should work transparently to sio.c, with perhaps a few minor changes to accommodate the auto RTS/CTS and larger FIFO buffers. Someone has already tried to do this in sio.c, but it's not working right yet -- with auto RTS/CTS enabled, interrupt-level overflows occur. I'm trying to understand why so I can hack mine to make it work right. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346b36af.1755787>