removed extra arguments in iocb functions starting from kernel 5.16

[vkomenda]

Fixes #149

Tested on 5.16 - it works.

[hmaarrfk]

Is that the correct error to remove?

Do you want to keep res or res2?

[vkomenda]

I removed the second argument, res, as you suggested. However I'm now having second thoughts since you asked.

[hmaarrfk]

Sorry. I meant the second result.

[hmaarrfk]

torvalds/linux@6b19b76

[vkomenda]

QDMA driver has some code duplication and can be updated in the same way.

[hmaarrfk]

I'm somewhat worried that the diff shows that they were worried that the USB drivers were using this.

It seems that the second parameter isn't always forcibly zero :/

[jrwagz]

I was able to build on 5.16.16-200.fc35.x86_64, HOWEVER when I ran my tests to validate our DMA write/read/verify functions, it doesn't work as expected. Perhaps it's an issue with the test scripts, but they work just fine in 5.15.16-200.fc35.x86_64

[hmaarrfk]

@jrwagz are you using XDMA or QDMA? Can you share the information about the test cases that are failing?

[jrwagz]

I'm using XDMA. while I can't share the source of the tests, I can say that they use dma_to_device and dma_from_device to launch several threads in parallel, all attempting to do write/read/verify to their own unique locations of RAM.

In particular, I can reduce the test to a single thread, and see that when they use a very large transfer count (10000), dma_to_device never returns. However, using lower transfer counts (1-10) it does pass.

The annoying thing is that the kernel module is hung up each time this happens, and requires a system reboot to get it back.

[jrwagz]

Each thread basically does the following:

write contents of a file to it's own ram location via dma_to_device (repeat for designated number of transfer counts)
read back that location via dma_from_device (repeat for designated number of transfer counts), save to file
compare the two files, give pass/fail status

[jrwagz]

having said all of that, I left the test running while typing this up, and it did eventually pass, however dma_to_device took WAY longer to complete that it does normally. I need to capture some numbers on that, but it was long enough that I thought it was stuck. I'm thinking my test typically executes in like 1-2min with well over 20 threads, but with this mod, a single thread with transfer count of 10000 took 10min or more.

I'm using XDMA, and loading the driver with poll_mode=1

[jrwagz]

Here are the test results: (reduced in size, but you'll still see the massive difference in speed.

kernel 5.15, without the proposed mods in this PR:

# uname -a
Linux 5.15.16-200.fc35.x86_64 #1 SMP Thu Jan 20 15:38:18 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
# time ./dma_to_device -d /dev/xdma0_h2c_0 -f ../tests/data/datafile0_4K.bin -s 128 -a 606208 -c 1000
/dev/xdma0_h2c_0 ** Average BW = 128, 10.393317

real    0m0.014s
user    0m0.000s
sys     0m0.010s

kernel 5.16, with the proposed mods in this PR:

# uname -a
Linux 5.16.16-200.fc35.x86_64 #1 SMP PREEMPT Sat Mar 19 13:52:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
# time ./dma_to_device -d /dev/xdma0_h2c_0 -f ../tests/data/datafile0_4K.bin -s 128 -a 606208 -c 1000
/dev/xdma0_h2c_0 ** Average BW = 128, 0.004008

real    0m31.941s
user    0m0.002s
sys     0m0.015s

[vkomenda]

@jrwagz I ran the same command on 5.16 with this PR and got similar results on Gen 4 x 8:

$ uname -v
#1 SMP PREEMPT Debian 5.16.18-1 (2022-03-29)

$ time ./dma_to_device -d /dev/xdma0_h2c_0 -f ../tests/data/datafile0_4K.bin -s 128 -a 606208 -c 1000 /dev/xdma0_h2c_0
/dev/xdma0_h2c_0 ** Average BW = 128, 8.475098

There is no major difference in speed. So maybe try the latest code? I rebased onto master.

[vkomenda]

Closing in favour of #238 .

Note that when @karenx-xilinx posted fixes for 5.16 to the master branch a few days ago 9cdc9e3, the field res2 was kept and not removed as it was done in this PR.