From owner-freebsd-hackers Wed Nov 12 11:16:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29238 for hackers-outgoing; Wed, 12 Nov 1997 11:16:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29233 for ; Wed, 12 Nov 1997 11:16:05 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-195-100.nc.us.ibm.net (slip129-37-195-100.nc.us.ibm.net [129.37.195.100]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id TAA24812; Wed, 12 Nov 1997 19:14:30 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Wed, 12 Nov 1997 20:15:45 GMT Message-ID: <346d0534.56453013@smtp-gw01.ny.us.ibm.net> References: <199711120647.RAA10782@godzilla.zeta.org.au> In-Reply-To: <199711120647.RAA10782@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 LAA29234 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997 17:47:08 +1100, Bruce Evans wrote: >A 64-byte fifo probably won't work unless the fifo trigger level is >reduced (defeating the point of the larger fifo). There may be just >enough margin if the default (highest) trigger level is enough below >64. Why won't a 64-byte FIFO work? Is it for the same reason as stated in the following excerpt from sio.c? >#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? >I think the best available setup is to use 16550 mode with the tx fifo >size set to match the flow control. I do not understand "tx fifo size set to match the flow control." >The 16650 configuration is too specific - it forces 16650 flow > control and a 32 byte tx fifo size. As mentioned in my earlier response, transmit FIFO can be set independently of receive FIFO. And by default, transmit FIFO is set to one byte like the 550. I don't see why that is bad. >The interrupt latency is low enough for auto flow control to be >unnecessary in most cases (and there is another 6 character times of >slop available by reducing the 16550 trigger level from 14 to 8 to >handle overloaded cases). Perhaps true, but it won't hurt to have hardware insurance against interrupt latency. I already paid for the insurance when I bought the 650. I would like to use it, as long as it does not cause any loss of efficiency. >Another problem with auto flow control is that it doesn't actually >work if the sender can't stop soon enough. E.g., if the sender is >a 16550, then it can't reasonably stop before sending 16 characters >if it has 16 characters in its tx fifo. Why not? When auto CTS is activated with EFR bit 7, the 650 will stop sending if the external device drops CTS, even with bytes remaining in the transmit FIFO. That should have no adverse impact on sio.c, should it? It's all internal to the chip itself. >The receiver must have a rx fifo trigger level 16+ below the fifo size > to handle this completely in hardware (+ = a few more to give the > interrupt handler time to run before flow control is actually invoked). 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'm learning much from this discussion. I only want to be sure I have an accurate understanding of what you are saying. >>I increased the software buffer size from 256 to 512, and that seemed >>to reduce the number of overflows, but a burst of disk activity would >>still trigger one even with the larger buffer. > >That breaks the watermarks in the tty buffer unless the tty buffer size >(TTYHOG) is increased too. I'm only testing with PPPD. Does it use tty buffers? John