Linux and dmaengine - problem with checking the number of bytes transferred in a segment

Hi,

I'm writing a driver for the device, that transferrs data via AXI Stream in terface in packets with variable length (however the maximum length of the packet is known). The data should be transferred to the buffers allocated in the application and accessed by the kernel via get_user_pages. The application allocates a buffer for each packet and submits it to the dr iver via ioctl call. The driver prepares it for dma using the:

1) get_user_pages_fast 2) sg_alloc_table_from_user_pages 3) dma_map_sg

When the transfer is started, each buffer is

1) synced with dma_sync_sg_for_device 2) converted to dma_async_tx_descriptor with dmaengine_prep_slave_sg 3) configured with proper callback and parameters 4) submitted via descriptor's tx_submit method.

When all buffers are submitted, the transfer is started with dma_async_issu e_pending

After each packet is transmitted and tlast is asserted, the callback is exe cuted. And here is the problem:

There is no way to find how many bytes has been transferred. Of course I can work it around by zeroing the whole buffer before the trans fer and requesting, that the device sends the "end of packet" magic word at the end, but this is definitely a suboptimal solution.

OK. I can avoid zeroing the buffer if I require sending the header with the packet's sequential number at the begining, and magic EOP with the same se quential number at the end (So I'll avoid a situation, when the packet is i nterrupted in the middle, but EOP from the previous one is still in the buf fer - of course I'm going to reuse the buffers).

I'm absolutely surprised, that dmaengine does not offer such fundamental fu nctionality as finding the length of the completed transfer. The problem was noticed in 2013 for USB devices:

however it seems that the solution proposed at t he end, based on using the dmaengine_tx_status does not work for completed transfers.

Have I overlooked something?

TIA & Regards, Wojtek

PS. I have prepared a simple code, which demonstrates the problem for a sin gle packet:

, the "axi_dma_prj1" subdirectory. PS2. The problem was also reported to the Xilinx forum: and to the stackoverflow: