Hi Vinod,
Based on customer reports we have identified two issues with the UDMA driver:
TX completion (1st patch):
The scheduled work based workaround for checking for completion worked well for
UART, but it had significant impact on SPI performance.
The underlying issue is coming from the fact that we have split data movement
architecture.
In order to know that the transfer is really done we need to check the remote
end's (PDMA) byte counter.
RX channel teardown with stale data in PDMA (2nd patch):
If we try to stop the RX DMA channel (teardown) then PDMA is trying to flush the
data is might received from a peripheral, but if UDMA does not have a packet to
use for this draining than it is going to push back on the PDMA and the flush
will never completes.
The workaround is to use a dummy descriptor for flush purposes when the channel
is terminated and we did not have active transfer (no descriptor for UDMA).
This allows UDMA to drain the data and the teardown can complete.
The last two patch is to use common code to set up the TR parameters for
slave_sg, cyclic and memcpy. The setup code is the same as we used for memcpy
with the change we can handle 4.2GB sg elements and periods in case of cyclic.
It is also nice that we have single function to do the configuration.
Regards,
Peter
---
Peter Ujfalusi (3):
dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in
peer
dmaengine: ti: k3-udma: Move the TR counter calculation to helper
function
dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and
cyclic
Vignesh Raghavendra (1):
dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion
check
drivers/dma/ti/k3-udma.c | 452 +++++++++++++++++++++++++++++----------
1 file changed, 343 insertions(+), 109 deletions(-)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
