> 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. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
