Date: Thu, 13 Nov 1997 20:35:53 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <199711130935.UAA06342@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>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?
Yes.
>>#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?
Buffer sizes are finite.
>>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."
Neither do I :-). I should have said "with the tx fifo size set to match
the 16x5x variant".
>>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.
It is 16 for the 16550 if the fifos are enabled, and surely at least
as large for later variants. You probably want to use 64 instead of
32 if possible.
>>The interrupt latency is low enough for auto flow control to be
>>unnecessary in most cases (and there is another 6 character times of
>...
>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.
Apparently it does.
>>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.
Auto CTS only helps if the sender has it or something else that allows
it to stop soon. 8250 senders can stop sooner than 16550 senders :-).
>>The receiver must have a rx fifo trigger level 16+ below the fifo size
>> to handle this completely in hardware (+ =3D 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
It's because OS's that can't guarantee a (serial) interrupt latency of
<= 2 to 8 character times also have problems guaranteeing an interrupt
latency of 100's of character times. It would be nice for hardware
flow control to completely handle this case.
>>>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?
No. Only the termios line discpline uses them. This also makes RTS flow
control much less important with pppd.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711130935.UAA06342>