xilinx_axidma icon indicating copy to clipboard operation
xilinx_axidma copied to clipboard

Get actual receive transaction length [Question]

Open antts opened this issue 4 years ago • 3 comments

The Xilinx DMA Core may finish a transaction earlier than expected/programmed due to a TLAST on the input slave AXI Stream.

In this case, how can we know the actual transaction length in user-space when the callback is called?

I have tried setting the receive size larger than the actually performed transaction and it indeed works, but I do not know what the real packet length was. It seems that the DMA Core exports this in the S2MM_STATUS register Xilinx forums.

Is this available in the API somewhere? (I may just be missing it..) If not can anyone suggest a workaround to get this info after a transaction?

Thanks!

antts avatar Aug 30 '19 09:08 antts

Hello! You should to look at this issue #60 and #41 tl;dr: API doesn't provide any information about received transaction length because Xilinx DMA framework doesn't process it. You may try to use mmap and get access (via offset) to descriptor's registers and calculate transaction's length, but you may not have time to get it before Xilinx AXI DMA driver process transaction.

GOOD-Stuff avatar Sep 02 '19 06:09 GOOD-Stuff

According to those two issues this seems non-trivial to do through this driver due to non support from the Xilinx driver. I might try to read S2MM_STATUS with mmap unto /dev/mem, thank you for your help!

antts avatar Sep 03 '19 08:09 antts

I have the same requirement - I have packets of varying length coming in and I'd like to know the length without having to parse the packet in SW.

Looking at the product guide (PG021 June 14, 2019), it appears that in SG mode, the DMA updates the SG descriptor upon completion of the transfer, and sets the S2MM_STATUS field to the actual transfer count. It seems to me that if this discriptor is preserved, that it should be accessible after the transfer is complete and the DMA moves on to the next.

So, is the descriptor preserved at least long enough to query it? If so is there an existing API to retrieve the descriptor? I'm thinking the completion call-back should be able to retrieve the descriptor and get the bytes transferred that way.

What am I missing?

chipgeek avatar Sep 12 '19 16:09 chipgeek