Hi All, I have been experimenting to support DMA with 8250_omap using 8250_dma flow. AM335x and AM437x use EDMA as dmaengine for UART DMA support. But it suffers from few bugs that make it difficult to use core 8250_dma tx and rx flow. Hence, I started using SDMA as dmaengine for UART DMA. SDMA is available on on DRA7xx and OMAP5, OMAP4 and OMAP3 platforms. SDMA currently lacks the ability to pause ongoing RX DMA transfer. But with patch [1] applied, it is possible to support RX DMA pause functionality on SDMA. Using SDMA with 8250 UART, it is possible to use core 8250_dma tx and rx flow. It _does not_ suffer from the limitations of EDMA such as OMAP_DMA_TX_KICK workaround, need to queue DMA transfer before data ready interrupt and spurious interrupts that are observed with EDMA. With SDMA, I am able to use 8250_dma serial8250_rx_dma_* and serial8250_tx_dma_* and get rid of custom handlers in 8250_omap. Hence, I propose to switch to SDMA as dmaengine for 8250_omap and do the appropriate changes. This means UART DMA cannot be supported on AM335x and AM437x that have only EDMA and no SDMA. But that seems like a reasonable middle ground to take rather than disabling DMA on all OMAP platforms altogether. I am aware that SDMA cannot support resume of paused DMA transaction. But I don't see any need for that feature at the moment. There are two problems that I see when using SDMA with 8250_omap and using core 8250_dma flow: 1. 8250_dma DMA sets up DMA RX transfer size to be PAGE_SIZE or 4K bytes. 8250_omap RX DMA trigger size is currently 48 bytes. Which means whenever there are 48 bytes in UART FIFO, DMA is triggered and data is taken out by DMA, this happens until 4K bytes are fetched and then DMA completion callback is invoked which pushes that data to tty layer. If number of bytes in FIFO <48 bytes then RX timeout is raised and data driver pushes the data to tty layer. But if the data received is multiple of 48 bytes but <4KB then, neither there is RX timeout(as data is taken out by DMA) nor DMA completion callback(as 4K bytes have not yet been received). This means the data is stuck in DMA destination forever. Now, I believe this is a generic problem for all 8250 UARTs using core 8250_dma. I am not sure how to workaround this. Any ideas?? 2. TX DMA stalls if UART_MCR register is written to(as part of set_termios call) when DMA is in progress. Currently, this is worked around by delaying termios change. This results in deviation from TX DMA flow. IMO, changing termios when transfer is in progress is not a real usecase and not recommended. So, either driver can error out in this condition or avoid touching UART_MCR register(which is mainly used to switch to Loopback mode and enable access to DMA trigger configuration register). So I propose to submit patches to allow 8250_omap to use 8250_dma for UART DMA support and remove UART DMA support for AM335x and AM437x that do not have SDMA. [1]https://patchwork.kernel.org/patch/6972961/ -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
