On Sat, 2023-03-25 at 18:05 +0100, Stefan Wahren wrote: > Am 25.03.23 um 16:11 schrieb Uwe Kleine-König: > > So on an UP system the problem should occur also on a non-console port? > > This is less likely, because UART applications usually need some kind of > flow control (either from hardware or protocol side). For a non-console > application the receiver usually wait until the end and then starts to > transmit. > > Sure you can flood the UART with characters and it's only a question of > time until the RX FIFO is full and data get lost. But i think we should > focus on the real use case and don't try find the perfect solution. At > the end it's always a compromise between latency and throughput. If you enable DMA on the UART then you are extremely unlikely to hit overflow. To some degree the DMA can be seen as "extended" RX FIFO. Unfortunately DMA cannot be used for imx console UART. > > That makes me wonder if the error doesn't relate to the UART being a > > console port, but the UART being used without DMA?! (So the patch above > > fixes the problem for you because on the console port no DMA is used?) > > As i said the issue only occured on the console. My problem is that the > other UARTs on Tarragon are used for RS485 which means they are just > half duplex. > > According to these lines in imx.c DMA is never used for console: > > /* Can we enable the DMA support? */ > if (!uart_console(port) && imx_uart_dma_init(sport) == 0) > dma_is_inited = 1; > > At the end the patch above only restores the old console behavior, but > keep Tomasz Moń's optimization for non-console (which was indented for). Setting RXTL to 1 is essentially making the irq raised a bit earlier, i.e. when the RX FIFO can hold 31 more characters. With RXTL set to 8 and data burst, the irq is raised when RX FIFO can hold 24 more characters. Therefore with RXTL set to 1 (instead of 8) the maximum acceptable RX interrupt latency (i.e. before you losing incoming characters) is 7 characters time longer. Best Regards, Tomasz Moń
