> > I miss a way to disable the transmit FIFO. > > From userspace or from within a kernel driver? >From userspace. > > UARTs that don't do hardware handshaking in hardware, but use a transmit > > FIFO, can only be used if the peer can deal with the delayed handshaking > > response. > > > > If slow peers can not receive at line rate, hardware handshaking will > > still cause overruns with Linux as sender, because Linux fills the > > transmit FIFO and transmission continues at worst for 16 characters with > > a 16550 after CTS was asserted. > > > > So, how can I fix hardware flow control response to the non-delayed > > behaviour as it worked with a 8250 or 16450 by disabling the transmit > > FIFO? > > So you are saying this used to work and now it doesn't? It used to work with old non-FIFO UARTs (8250, 16450) and does not work with the slightly newer FIFO-UARTs (16550 and up, probably excluding those that can do RTS/CTS flow control in hardware). A transmitter FIFO on a UART that can not do RTS/CTS flow control in hardware delays the flow control response by the size of the FIFO. By the time Linux notices CTS being set, the FIFO is already filled and the transmitter keeps sending, despite the peer asking to pause. It is desirable that flow control has minimal delays from seeing CTS to pausing the flow. Given a 16550 UART, you have to disable the transmitter FIFO for that. One could argue whether the default should be high throughput (use the FIFO and delay handshaking) or correct flow control (no FIFO and near instant handshaking). Most systems default to the first. The admin has to know if the peer allows delayed flow control and configure it for the affected UART ports. Windows allows exactly that and the MS knowledge base correctly describes that the FIFO size may cause data overruns, suggesting to reduce it until the problem goes away. A binary switch, as offered by BSD, probably suffices, though. Michael -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
