From owner-freebsd-hackers Wed Nov 12 13:55:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12766 for hackers-outgoing; Wed, 12 Nov 1997 13:55:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12753 for ; Wed, 12 Nov 1997 13:55:00 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id OAA07028; Wed, 12 Nov 1997 14:54:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd006993; Wed Nov 12 14:54:48 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA20137; Wed, 12 Nov 1997 14:54:42 -0700 (MST) From: Terry Lambert Message-Id: <199711122154.OAA20137@usr05.primenet.com> Subject: Re: Status of 650 UART support To: mouth@ibm.net (John Kelly) Date: Wed, 12 Nov 1997 21:54:42 +0000 (GMT) Cc: bde@zeta.org.au, hackers@FreeBSD.ORG In-Reply-To: <346d0534.56453013@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 12, 97 08:15:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >#ifdef COM_ESP > > if (com->esp) { > > /* > > * Set 16550 compatibility mode. > > * We don't use the ESP_MODE_SCALE bit to increase the > > * fifo trigger levels because we can't handle large > > * bursts of input. > > 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. > Yes, but I don't see why the design of the 650 would make you want to > handle it completely in hardware. If the 650 will merely raise RTS on > its own, telling the external device to stop streaming, that should > enhance the operation of sio.c without any negative side effects, as > far as I can see. > > >16+ below the 16650 fifo size of 32 is too many. 16+ below the 16654 > > fifo size of 64 is better. > > If I was trying to handle it completely in hardware, I could set FCR > bits 7 and 6 to "00" to give a 650 trigger level of 8, similar to a > 550, and also have 24 bytes of headroom. But I'm not trying to handle > it completely in hardware, I only want the hardware and sio.c to > cooperate. 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 instead of doing it via FASTINTR to reduce the amount of code you actually run at high spl. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.