On Thu, Feb 18, 2021 at 08:20:51AM +0100, Thomas Petazzoni wrote: > 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. Odds are, this is already an ioctl for the tty layer given that this seems like a common thing even for "normal" uarts. Has anyone looked? > * How much time with no data received before the UART triggers and > interrupt, and received data is delivered to the TTY layer/userspace. Again, that should already be an option we support, if not, I would be surprised. I don't have the time to dig through the kernel/documentation at the moment, but if someone that cares about this can, I would appreciate it :) thanks, greg k-h
