This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM623: AM623x BCDMA questions

Part Number: AM623

Hello,

Can the team please assist with the questions below?

1. CQ callbacks having high latency, is there a way to avoid this latency or is there a more efficient way?

2. When does the actual udma transfer happens, either during the push of trpd or during the ring of doorbell register?

   Background: The data is unknown till the interrupt occurs(source address, destination address and length are unknown), so having a trpd ready before the interrupt occurs or data available.

3. How many bcdma channels can the AM623 device support?

  • Hello Todd Solak,

    Current Implementation: Callbacks are interrupt-driven through the completion queue (CQ), triggered when the TRPD response is written to the completion ring.
    I don't think there is other methods to reduce this latency .

    TRPD Push only queues the descriptor in the free queue ring—it does not initiate the actual DMA transfer.

    Actual DMA Transfer happens when you ring the doorbell register.

    The doorbell operation kicks off the actual data transfer. The response returns in the completion queue after transfer completes.

    AM623 supports 82 total BCDMA channels:
    - 32 Block-Copy (BC) channels 
    - 22 Split Transmit (TX) channels 
    - 28 Split Receive (RX) channels 

    Regards,

    Anil.

  • We have two use cases to consider. I believe we've covered the first.

    In the second case, we can assert known sequential addresses and a known size for each transfer. We want to know if there is a clear performance improvement between using a queued 1-d TRPD (with indirect addressing) configured to repeat and suppress event generation, and a 2-d transfer that stalls between transfers. In the first case, we'd use the doorbell to activate the TRPD, and we'd expect it to clear the hardware between transfers. In the second, we'd use a trigger and keep the TRPD stalled between transfers. We have enough channels to manage this.

    At the core, I'm asking if the latency to generate a doorbell is roughly equivalent to the latency to generate a local trigger event.

  • Hi Daniel,

    We had a discussion internally on this.

    Reducing latencies for the api's are not possible.

    Based on the internal discussion the software overhead can't be reduced by the following methods mentioned.

    We want more details on the requirement.

    What is the GPMC interface and did they connect to nand , nor, psram or fpga?

    How frequent the data has to be triggered?

    If the UDMA triggers auto transfers for every x sec this would be sufficient for your use case?

    You can auto trigger the udma transfer by local events thus reducing the software overhead.

    Regards,
    Vaibhav