Date: Wed, 12 Nov 1997 20:15:45 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <346d0534.56453013@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711120647.RAA10782@godzilla.zeta.org.au> References: <199711120647.RAA10782@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Nov 1997 17:47:08 +1100, Bruce Evans <bde@zeta.org.au>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346d0534.56453013>