[RFC] Switching 8250_omap to use 8250_dma RX and TX flow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux