cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sktpin
Adventurer
Adventurer
603 Views
Registered: ‎09-11-2018

AXI DMA & Linux dma-proxy - almost works - tips for debugging?

Hello,

using a design with a Xilinx DMA IP in a Zynq Ultrascale+, a 3-way data switch between "real data" FIFO, Traffic Generator, Loopback,
and the Xilinx wiki dma-proxy driver example, using DMAengine to bridge Linux user space to the Xilinx mainline kernel DMA driver, I got this far:

  • endless Loopback transfer by repeatedly setting up transfers of a useful block size from user space works
  • endless reading of data from the Traffic Generator with settings to (roughly) approximate the "real data" time behavior also works
  • the first transfer for reading the "real data" works, the second always has a DMA TIMEOUT (i.e. the waiting for the Linux completion mechanism timed out after 3000 millisecs)
    • so the DMAengine seems to be waiting for something which is, for some reason, not fulfilled, even though the internal FIFO in the FPGA is being filled all the time and TLAST events seem to be raised

I guess that doing a loop in userspace which starts a transfer within an endless loop is not the most efficient way of doing a driver like this.
But seeing the CPU load in htop affecting almost only 1 CPU core, being busy with 10..30%, it seems that this, for now, should at least not be a (or THE) show stopper for it working at all, esp. seeing that it works fine for the traffic generator.
(since I have very little experience with Linux drivers, I'm trying not to blur what's going on by "optimizing" the driver)

There are no concurrent transfers *to* the FPGA, other than when in Loopback mode. Otherwise, only reading data from FPGA is required.
So this is only about getting continuous reading to work for the "real data" produced in another part of the FPGA with a regular clock, shoving it into a small FIFO which forwards it to the DMA.
I have tried different speeds for this clock, incl. very low ones, to see whether maybe timing is critical somewhere, but from sub kHz to 100 kHz speeds, the behavior is the same: 1st transfer works, subsequent get DMAengine timeout.

I have a script that reads out some DMA status flags via devmem, and none of the error flags are on.
(I confirmed the script at least partially works by once providing a bad address, and then it went to "SG internal error")

Does anyone have any tips on how/where to debug for what it is that the DMAengine is waiting for and why it's not happening (at the right time maybe)?

Regards,
SK

0 Kudos
Reply
2 Replies
sabankocal
Voyager
Voyager
591 Views
Registered: ‎08-02-2019

Hi @sktpin ,

There is similar thread with yours and solved by increasing "Width of Buffer Length Register" on DMA Ip Core.

Maybe you can also try different dma sizes to transfer.

Saban

 

<--- If reply is helpful, please feel free to give Kudos, and close if it answers your question --->
0 Kudos
Reply
sktpin
Adventurer
Adventurer
576 Views
Registered: ‎09-11-2018

The link points to the wrong thread.

If it was about wrong buffer length bits, then I should not be able to read from the traffic generator block, requesting the same transfer size?

What would help would be pointers as to how to go about diagnosing this. I don't assume there's a perfectly fitting answer to my problem description (unless this is something frequently occurring with all sorts of people's designs)
 
(it seemed to work as described in an earlier thread, but that turned out to not be accurate)

0 Kudos
Reply