Message ID | 1701277940-25645-1-git-send-email-lizhi.hou@amd.com (mailing list archive) |
---|---|
Headers | show |
Series | AMD QDMA driver | expand |
Hi Mark, The QDMA driver has been restructured for upstreaming. And the first QDMA patchset supports only AXI4-MM DMA transfers (mentioned in cover letter). Directly comparing code with QDMA git repo will not work well. After QDMA driver patchset is merged, I believe you may submit a fix patch to dmaengine for any issue you encounter. We will review your patch and verify it with our hardware. I do not work on the QDMA git repo or forum. I am not the right person for questions about QDMA git repo. Hopefully, this helps. Thanks, Lizhi On 1/14/24 09:54, Mark Harfouche wrote: > On Wed, Nov 29, 2023 at 12:13 PM Lizhi Hou <lizhi.hou@amd.com> wrote: > > > Comparing to AMD/Xilinx XDMA subsystem, > https://lore.kernel.org/lkml/Y+XeKt5yPr1nGGaq@matsya/ > the QDMA subsystem is a queue based, configurable scatter-gather DMA > implementation which provides thousands of queues, support for > multiple > physical/virtual functions with single-root I/O virtualization > (SR-IOV), > and advanced interrupt support. In this mode the IP provides > AXI4-MM and > AXI4-Stream user interfaces which may be configured on a per-queue > basis. > [...] > This patch series is to provide the platform driver for AMD QDMA > subsystem > to support AXI4-MM DMA transfers. More functions, such as AXI4-Stream > and SR-IOV, will be supported by future patches. > > > Hello, > > My name is Mark Harfouche and I've been following the kernel mailing > for some time. I'm sorry if this message is coming months after the > initial post. Please let me know if there is a more appropriate venue > for this kind of message. > > Since 2018 we use QDMA, and continue to build the driver ourselves > (with some patches). > I am really excited to see QDMA mature and become part of the linux > kernel. > > I wanted to share my experience with the QDMA driver and how I (and > other users) feel of how they react to feedback. > > Early in its development, the QDMA code base was constantly changing, > often breaking the userland code that we were writing to interface > with it. > Beyond this, during our testing, we found it was full of unsafe usage > of string operations (for example, sprintf being used in the kernel > code without checking the validity of inputs). > The most breaking changes often included the insertion of variables in > enum definitions in the netlink interface (which does not seem > included in this original set of patches). > > The community of users (beyond just me) has tried in many cases to > communicate small compatibility issues between kernel versions, and > suggested in many cases fixes in the form of small patches. All of > which were met with utter silence. Numerous examples on > https://github.com/Xilinx/dma_ip_drivers/pulls > Some examples of breaking changes to enums (the interface between the > kernel code and the userland applications using netlink) can be found > between 2020 and today by looking at diffs in the qdma_nl.h (again > this file seems absent from the patches) > https://github.com/Xilinx/dma_ip_drivers/compare/2020.2...master#diff-4497b037af6c3a4f9ac917e639b58a1fa155feb4b62b7fe66741a42ed74cdfd6 > > While I understand that in 2018-2022 the driver was not considered > stable, I am wondering what kind of mechanism for user feedback will > be available now that these patches are being submitted to the linux > kernel. Will the community be able to submit patches that resolve the > issues we find? Is AMD/Xilinx willing to stand behind their API moving > forward? > > Thank you for your time, > > Mark > > PS. I may have posted on various Xilinx/AMD/Github forums. My handle > there is often mark_ramona or hmaarrfk