Xilinx
[xdma] alonbl's stable patchset
Xilinx developers do not maintain the xdma driver and does not cooperate on github as well, I collected stable fixes of the xdma driver for people use and review.
WARNING: The xdma driver is far from being production grade, it crashes the kernel when aio is used, crashes when readv/writev is used, it have fundamental issues that are solved in this series, it loses sync at random time splitting buffers into parts, it also does not respect small buffer boundary.
XDMA DMA engine was merged into mainline since linux-6.3, staging is at https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/tree/drivers/dma/xilinx/xdma.c a user bridge is missing so we can switch.
The following patchset at least provides some sanity for EOP and stream based synchronous continues allocation operations.
Thanks for all contributors.
Notice
The name of the module is renamed from xdma.ko to xdma-chr.ko due to a conflict with latest merge of xdma.ko dmaengine into upstream.
Patchset includes
| Reference | Description |
|---|---|
| xdma: rename module to xdma-chr | |
| xdma: build improvements | |
| #319 | xdma: cdev_events: Do not leak ERESTARTSYS leak to userspace |
| #144 | xdma: explicitly stop engine on transfer completion |
| #161 | xdma: fix decs_cmpl and flush when eop received |
| #190 | xdma: fixed PCIe domain and bus values in info ioctl |
| #92 | xdma: simplify next_adj setting |
| #158 | xmda: set module parameter timeouts as milliseconds |
| #313 | xdma: libxdma: handle ERESTARTSYS for both wait_ and swait_*, with and without timeout |
| #315 | xdma: libxdma: engine_status_dump: avoid buffer overflow |
| xdma: libxdma: fix resource free on open | |
| #226 | xdma: cdev_ctrl: use resource_size_t for pci_resource_start() |
| #218 | xdma: correct typos in xdma_mod.c |
| #315 | libxdma: improve messages |
| #315 | libxdma: fix message typo |
I remember when I was looking at options for XDMA, I ran into https://gitlab.com/WZab/Artix-DMA1
We have been maintaining a significant set of patches for QDMA (not XDMA), at the time required to avoid crashes, and kernel panics.
Over the many years, Xilinx did address some of the crashes, we still avoid things like aoi, and maybe preadv.
Xilinx also tended to break compatibility by changing the order inside enums. This has caused us great headaches with backward compatibility. Ultimately, we have decided to simply undo their ordering changing, for our own compatibility purposes.
We periodically rebase with Xilinx's patches, but their refusal to acknowledge anything posted here has been very frustrating.
Thank you @hmaarrfk, Thank you for your insights, yes, Xilinx is doing a very bad job in supporting their own product, I am unsure what they gain provided it simply does not work. Alon
Working in a small company, and I presume the team in charge of support is quite small, I believe there is a directive to simply ignore whatever is posted here.
They do however, monitor their forum. That isn't to say it is particularly amazing advice they gave, mostly due to the fact that sharing code, designs, and environment is inherently hard with hardware, but I have been able to get replies from people that were knowledgeable about the problems by posting there.
Its juts a shame that they won't take a look here when specific resolutions, less than 10 lines long each, would fix real problems in the code.
Hi Alon, Thanks a lot for maintaining your fork! Can I suggest that you avoid using forced-push and simply commit in a conventional way? When you force push the commit hashes change. This make it harder for someone who wants to keep up with the new changes and just cherry pick them.
@eniv this is a downstream patchset, it is not a development, the patchset is a set of patches each is performing a specific change on top of upstream, it will always be rebased (forced push) and ordered by the most trivial to the most intrusive to ease upstream merge. this behavior is same as any downstream distribution/subsystem/maintainer.