XDMA: timeouts/signal delivery during xdma_xfer_submit breaks subsequent dma.

[xilinx]

XDMA: timeouts/signal delivery during xdma_xfer_submit breaks subsequent dma.

[X-Ryl669]

I've the same issue and tried your workaround and it did not work for me. I think I've found two workaround.

Workaround 1

Make sure your buffer size is a multiple of a power of 2 (mine was 0x96000 and it failed, but once set to 0x100000 it worked flawlessly, with 0x100000 = 2¹⁰).

Workaround 2

This requires a bit more work on your code. Typically when it fails, the driver times out. You do get this information from user space since read returns a cryptic 512 error.

So first, I've changed the timeout to something very small (via ioctl IOCTL_XDMA_TIMEOUT_SET on /dev/xdma0_c2h_0) so it's not noticeable.

It must be a bit longer than the expected transfer time (you are in guesswhatwonderland here).
Then when it fails, I'm issuing 2 ioctl on the /dev/xdma0_control, the former with XDMA_IOCOFFLINE and the latter with XDMA_IOCONLINE.

This has for effect of resetting the driver's state to some known state (without resetting the PCIe device) and it's very fast. Then you can resume the failing transfer and it'll complete correctly up to the next time.

Obviously, the first workaround is preferred but anyway...

[jberaud]

Is fixed by #68

[jberaud]

But the message could be fixed because when interrupting a transfer, we could check that wait_event_interruptible has been interrupted by a signal before printing a trace that we have a timeout (which is not true).

[hmaarrfk]

Hello,

My name is Mark Harfouche. I am not affiliated with Xilinx in any way. Over the
years of using QDMA, I've been wanted better community organization.

I've created a fork of dma_ip_drivers which I intend to maintain and work with the
community at large to improve.

The fork can be found https://github.com/hmaarrfk/dma_ip_drivers

For now, I am stating the main goals of the repository in
hmaarrfk#2

If you are interested in working together, feel free to open an issue or PR to
my fork.

Best,

Mark