With the sending of 20 bytes data frames every 16 ms, it means data is
send ~62.5 per seconds.
Looking at /proc/interrupts, I get ~260 interrupts per second on the
MAX14830, which means that the "batch reading" implemented in
2b4bac48c10848ccffd484e7cd025dc085c1bd32 is effective but not to the
point where I have a single interrupt per received frame.
Hi,
I was getting something similar when I first wrote that patch. The TL;DR
version is that even though this UART has 128 byte FIFO per each direction
of each UART, I wanted my patch to stay conservative and only batch reads
in an opportunistic manner -- I wanted not to risk a possible RX FIFO
overflow. That's why the IRQ handler is eager to trigger as soon as there
are some data in the RX FIFO. Our setup has no HW flow control (no RTS/CTS,
no software flow control), so one has to hope that the IRQ latency is low
enough...
The MAX14830 supports also another mode of operation where the interrupt
fires only when the RX buffer gets filled over a configurable minimal
threshold. This can be combined with yet another interrupt which fires
whenever there's some data in the RX FIFO for "too long". Unfortunately,
this timer starts over again upon reception of any additional data, so it's
the *youngest* byte in the RX FIFO that controls triggering of this delayed
interrupt.
I am not sure how to balance the latency ("how soon is userspace notified
about this byte") with CPU utilization ("don't read data byte-by-byte from
this 128 byte buffer"). If there's some cross-driver support for "something
like that" in the TTY layer, I'm sure that max310x.c could be adopted to
make use of that. Otherwise, we could always add a pair of DT properties
for controling:
a) the "start reading from RX FIFO" timeout,
b) "allow up to X bytes in the RX FIFO, I know that my platform has enough
CPU and SPI bandwidth to finish reading that before the RX FIFO overflows"
BTW, there are also real SPI bus throughput limitations, see
2258761213cb239e5e6c11b4ec9b1700fcb4fdcd for some numbers from my platform.
The chip supports up to 26 MHz (but not all bus masters have clock
granularities fine enough to use this), that's 3.25 MBps of raw throughput
divided among four UARTs. Reading each register takes at least two bytes,
one has to check the top-level IRQ status register (to decide which UART to
check), then read per-UART IRQ registers, and only then start reading the
data. Also, batched reading can only happen if userspace explicitly ignores
framing errors, parity errors, etc, otherwise the driver will have to read
byte-by-byte, and check the line status register, etc.
Anyway, I'll be happy to review and test any patches you might have; we're
using these chips and we are interested in their performance and error-free
operation.
With kind regards,
Jan
