bperez77 / xilinx_axidma

A zero-copy Linux driver and a userspace interface library for Xilinx's AXI DMA and VDMA IP blocks. These serve as bridges for communication between the processing system and FPGA programmable logic fabric, through one of the DMA ports on the Zynq processing system. Distributed under the MIT License.
MIT License
450 stars 225 forks source link

Get actual receive transaction length [Question] #109

Open antts opened 4 years ago

antts commented 4 years ago

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!

GOOD-Stuff commented 4 years ago

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.

antts commented 4 years ago

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!

chipgeek commented 4 years ago

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?