-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
High
-
Linux Core SDK
-
LCPD-45149
-
-
11.02
-
Customer is reporting this issue with BCDMA. They reported that the code that sets bstcnt value is incorrect and have also attached a patch to resolve.
The “bstcnt “ is based on a single TR, however the driver in udma_prep_dma_cyclic_tr() may generate one or two TR per cycle based on the size when calling udma_get_tr_counters()
Ref patch and also address the below two queries:
- Is there a performance impact when the transfer is broken into two transfer requests and the second request is only 8 bytes?
- For the application of McASP to PDMA to BCDMA where is the packet length (period_len in k3-udma.c) of 64kB set?
E2E:
Patch code:
Workaround for bug in commit 67d5b24398155d07376b04dd8b3d858d049a5e17 Original commit title: dmaengine: ti: k3-udma: Fix teardown for cyclic RX with PDMAThe original commit sets EOP at the end of BCDMA transfer and sets bstcnt based on the contents of transmit resquest (TR) #0. The driver, however, will use two TRs when transfer size is >=64k bytes with EOP set on the second TR. In this case bstcnt should equal the total bytes for both TRs.diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c index 4291bbf998ab..81b62df45be2 100644 --- a/drivers/dma/ti/k3-udma.c +++ b/drivers/dma/ti/k3-udma.c @@ -3220,6 +3220,11 @@ static int udma_configure_statictr(struct udma_chan *uc, struct udma_desc *d, d->static_tr.bstcnt = (tr_req->icnt0 * tr_req->icnt1) / dev_width; + + // Data may be in two TR if >=64k + if( !(tr_req->flags & CPPI5_TR_CSF_EOP) ){ + d->static_tr.bstcnt += (tr_req[1].icnt0 * tr_req[1].icnt1) / dev_width; + } } else { d->static_tr.bstcnt = 0; }
