Hello Greg, On Thu, 18 Feb 2021 08:11:33 +0100 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > What aspects need configuring and why is this uart so unique from all > others that it can't use the normal configuration methods? What makes is stand out from other UARTs is that it is over SPI. So accessing every single register of the UART is much more expensive than with UART controllers on MMIO. As explained in commit fce3c5c1a2d9cd888f2987662ce17c0c651916b2, in its original state, the driver was configuring the UART to get an interrupt for every single byte being received, causing a huge CPU load (25% in my use case) for a very simple workload that consists in receiving 20 bytes every 16ms. What fce3c5c1a2d9cd888f2987662ce17c0c651916b2 does it to configure the UART controller to not interrupt at every byte being received, but only when the RX FIFO has reached a certain threshold *or* after some time without receiving data. Clearly, this is trading throughput against latency. So what needs to be configured are two aspects: * How many bytes the UART will receive before triggering an interrupt and delivering data to the TTY layer/userspace. * How much time with no data received before the UART triggers and interrupt, and received data is delivered to the TTY layer/userspace. Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
