Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> writes: > On Mon, Jun 03, 2019 at 03:08:06PM +0300, Sergey Organov wrote: >> Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> writes: >> >> [...] >> >> > If we want the kernel to stop reading the FIFO, we would have to add >> > additional complexity to a lot of serial drivers, and a capability >> > which tells the kernel that they support this behaviour - why do we >> > want individual drivers to have to implement this? >> >> How does it work when no handshake is configured? Drivers continue to >> read FIFOs/TxDs and drop data when software buffers are full, spending >> CPU cycles on nothing? > > I assume what you mean by "no handshake" is "no flow control", Yes, "no flow control" I mean, thanks for clarifying! > then yes, the CPU continues to read the FIFO and drops the received > characters on the floor. This is a surprise and the core source of my misunderstanding of how system works. The only remaining question (now unrelated to the patch) is why it works this way, see below. > When no flow control is configured, it means there is no way to signal > to the remote end that there is congestion at the receiving end, and > if there is no buffer space available, where would you expect the > received characters to be stored? They would be dropped by hardware, exactly the way you are describing: > If the CPU were to stop reading the FIFO, the result would be that the > FIFO fills, and then any further characters received get discarded by > the hardware (instead of the CPU) and the hardware marks an overrun > error. That's what would happen indeed. What's the problem, exactly? Why CPU needs to spend its cycles performing this work when hardware happily does it at no cost? -- Sergey
