On Fri, May 31, 2019 at 06:48:48PM +0200, Uwe Kleine-König wrote: > On Fri, May 31, 2019 at 07:15:21PM +0300, Sergey Organov wrote: > > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > > > The first (and only) driver I checked does. (sa1100.c) > > > > I think I'd rather take 8250 as reference implementation, as being most > > widely used. Can anybody please tell how 8250 code handles this? Does it > > attempt to drain Tx FIFO on termios changes? > > Well, there are so many 8250 variants that the driver is rather > complicated. Also the original 8250 doesn't have a FIFO at all. > > Given that it might not be so easy to judge if a given driver drains the > FIFO and transmitter without consulting the reference manual I'd rather > rely on an authority for the serial core. (Apart from that I bet we're > finding examples for both variants.) > > @gregkh, rmk: What do you think? Let me also clarify something above. Yes, sa1100.c is good to use as a reference driver - it was carefully converted to serial_core by me along with 8250, and I made sure the semantics in the driver were correct for what the hardware supports. The key thing is "what the hardware supports" though - the serial block has no hardware flow control signals, and it is expected that GPIOs or other arrangements would be made where such signals were necessary: Modem control signals (RTS, CTS, DTR, and DSR) are not implemented in this block, but can be implemented using the general-purpose I/O port (GPIO) pins. See Chapter 9, ■System Control Module■. So, there's no way for the CTS signal input to actually stop the transmitter from draining its FIFO - much like 16550A devices. We are pretty much guaranteed that the transmitter will drain, and given that is likely to be a short time (it's only 8 characters deep) we wait for it. However, we do not wait for the data queued in the kernel buffers to also be sent. This is the only way to ensure that we perform a clean change of termios settings *on this hardware* without provoking errors at the receiver in the case of a TCSANOW change where none of the hardware parameters that affect transmission are actually changing, since disabling the transmitter will immediately stops transmission, whether it is mid-character or not. POSIX does not define whether "immediately" means mid-character or at a character boundary, but quality of implementation and real use (eg, as a serial console) shows that this achieves the best result, rather than ending up with stuff like the console text turning into graphics characters by the terminal receiving garbage. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
