Wolfram Sang wrote: > > What you're assuming is that flow control was there to prevent overruns > > on the hardware receiver. That's not the way it works on these devices; > > flow control is entirely managed in software - there is no hardware > > assistance. > > > > The flow control implemented for non-FIFO and non-hardware assisted > > UARTs is purely to do with preventing the software buffer behind the > > UART from overflowing - it can't prevent the device's receiver buffering > > from overrunning. (Non-FIFO devices have the shift register and a > > buffer register - complete reception of a second character before the > > first is read causes an overrun condition.) > > > > If you have overruns on the receiver, that's an interrupt latency > > problem and its an error that's reported to the receiver side only. > > > > Yes, later devices have the ability in hardware to deassert RTS when > > the receiver FIFO gets above a certain threshold to /help/ prevent > > overruns occuring when there's high interrupt latency - but normal > > system operation should still ensure that the FIFO is emptied in a > > timely manner. > > > > They also gained the ability to stop the transmitter once CTS is > > deasserted, mainly because the transmitter FIFOs in these devices > > is soo large (maybe 32 to 128 bytes deep.) > > Russell, thanks for this explanation. Patch seems principally OK to me, then. I agree. -- Jamie -- 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
