On Wednesday 14 September 2016 10:41 PM, Tony Lindgren wrote: > * Vignesh R <vigneshr@xxxxxx> [160914 04:58]: >> Hence, I propose to switch to SDMA as dmaengine for 8250_omap and do the >> appropriate changes. ^^^ Sorry, I meant "use SDMA as dmaengine back end provider for 8250_omap". >>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. > > Sounds like it should be configurable from the dts file and kernel > cmdline for which dmaengine back end to use. > I think I haven't given enough history here, let me clarify: Currently UART DMA support is disabled on all OMAP platforms and am335x and am437x when using 8250_omap driver. Couple of reasons for this: 1. SDMA does not support pause of ongoing DMA RX transaction. 2. EDMA requires a bunch of workarounds that makes it impossible to use baseline 8250_dma tx and rx flow. Peter Hurley asked[1] whether its possible to support DMA on any TI UART design with just baseline 8250_dma.c (i.e w/o all the DMA related code in 8250_omap.c). From my experiments, I have been able to verify that it is possible to use baseline 8250_dma with SDMA as dmaengine back end (but not with EDMA). This requires a patch to support RX pause on SDMA [2]. So, instead of disabling UART DMA on all platforms lets enable this feature on OMAP devices that have SDMA. Hence, my proposal is to keep UART DMA disabled on AM335x and AM437x based on compatible property as these SoCs have only EDMA. Resubmit patch[2], remove DMA related code from 8250_omap and enable UART DMA for OMAP3/4/5/DRA7 that have SDMA and make use baseline 8250_dma code. [1]https://lkml.org/lkml/2016/4/11/856 [2]https://patchwork.kernel.org/patch/6972961/ -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
