Re: High CPU load when using MAX14830 SPI UART controller

["Jan Kundrát" <jan.kundrat@cesnet.cz>]

> 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