I was regularly getting information about lost data when transferring data over all four UARTs of my MAX14830 without any flow control. That was on a Solidrun Clearfog Base (Armada 388) with SPI clocked at 26 MHz. Because I think that a dual-core multi-GHz machine should handle eight streams at 112.5kbps each, I started digging. There is still room for improvement; I have an unposted hacky patch which profiles the sizes of the read operations, and I'm still getting a *lot* of one-byte SPI reads. I plan to fix that later by only letting the IRQ happen if there are more bytes in the RX FIFO already, hoping that the reduced overhead will lead to lower average latencies and fewer lost bytes. The HW should be capable enough to also interrupt when there's too much "stale data" in the FIFO. Comments are welcome. Jan Kundrát (7): serial: max310x: Do not hard-code the IRQ type serial: max310x: Use level-triggered interrupts serial: max310x: Support IRQ sharing with other devices serial: max310x: Document clock setup serial: max310x: use a batch write op for UART transmit serial: max310x: Use batched reads when reasonably safe serial: max310x: Reduce RX work starvation .../devicetree/bindings/serial/maxim,max310x.txt | 18 +- drivers/tty/serial/max310x.c | 211 ++++++++++++++------- 2 files changed, 157 insertions(+), 72 deletions(-) -- 2.14.3 -- 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
