AM6548: UDMA uart rx write latency

Ryan,

Could you indicate what is the FIFOCNT and ELEMENT Size setting that you are using in the PDMA settings. Have you tried setting the FIFCNT to 0 and the Element size to the TX/RX size. The UART driver in PDK uses UDMA in PDMA mode. My understand is that this setting in the PDMA results in no packet delineation in PDMA and all framing is controlled via the UDMA TR similar to EDMA implementation.

If you are looking at PDK implementation of the UART driver, the UART driver uses the same implementation as previous SItara devices but uses the soc/dma/v2 version for configuring the DMA were you can check the PDMA configuration for transferring data from UART FIFO to application defined buffers. The trigger levels are set using configuration structures in UART_soc.c. 

For write transfer:

pdmaPrms.elemSize = 0; /* each data element is 8-bit byte*/
pdmaPrms. elemCnt= hwAttrs->txTrigLvl; /* # of bytes to transfer for each DMA FIFO trigger event */
pdmaPrms.fifoCnt    = 0U; /* # of DMA FIFO trigger events, don’t care for write, since the total txSize is set in the descriptor */

For read transfer:

pdmaPrms.elemSize = 0; /* each data element is 8-bit byte*/
pdmaPrms. elemCnt= hwAttrs->rxTrigLvl; /* # of bytes to transfer for each DMA FIFO trigger event */
pdmaPrms.fifoCnt    = rxSize / hwAttrs->rxTrigLvl; /* # of DMA FIFO trigger events */

Regards,
Rahul

PS: Can you also please clarify why you are unable to use the UART and UDMA LLD in the PDK for your application development. 

elemSize=0;

elemCnt=1;

fifocCnt=0,1,or sizeof(buffer).

When 1 it ends the TR and I get 1 byte but no more bytes.

When 0 or sizeof(buffer) writes occur at 64bytes or less if sizeof(buffer) is <64.

Did you find anything that might help resolve this?

That best  design I have found for our varying platforms running anywhere from 9600 to mbits is to setup a circular DMA that writes each byte to a large(16-64kby) buffer and disable RX irqs. I avoid IRQs on our RTOS because each task has a fixed time slot it runs in. If I service  IRQs then it eats into that time slot and it is also non deterministic. The buffer is large enough that even with extremely large(100s milliseconds) latency it doesn't overflow. You can map the buffer to sram to get around the ddr page thrashing at higher speeds.

I only see a couple ways to use UDMA with a uart rxing packet data of random sizes vs just a steady stream like mcasp. Even with mcasp the 64byte latency might be too large so I might not be able to use UDMA.

1)generate a new TR every byte. just using fifo would be better

2)creating a udma desc for each byte. now for my 16kby buffer I have 48*16k. The dma is also reading 48 and writing 1 bytes per byte. 

3)setup the 16kby dma but do a teardown to flush the queue every time I read it and submit new tr. not a great solution

I don't think either of these are viable. I am guessing I might try option 3 or dedicate a pru or cortexr core to do the equivalent of dma. 

Our product won't be using am65xx. This work is just to get ready for your next cpu. Hopefully it will have a fix.

Part Number: AM6548

j7 udma ip was updated to support the issue that is documented in https://e2e.ti.com/support/processors/f/791/p/751871/2806066#2806066. 

Is the new bit I am suppose to use PDMA_PSILCFG_REG_STATIC_TR_Z[31].eol . 

What should the other values be in the tr desc. I have been able to get it to write each byte as it comes in but I haven't seen a way to get a infinite loop. I saw the STATIC bit 4 but that is for type 8 and 9 block move trs.

What register can I read to let me know the current buffer index that is flushed to ram?