On Wed, Feb 25, 2026 at 07:47:08PM +0530, Ekansh Gupta wrote:
On 2/24/2026 9:03 AM, Trilok Soni wrote:
On 2/23/2026 11:08 AM, Ekansh Gupta wrote:
Add initial documentation for the Qualcomm DSP Accelerator (QDA) driver integrated in the DRM accel subsystem.
The new docs introduce QDA as a DRM/accel-based implementation of Hexagon DSP offload that is intended as a modern alternative to the legacy FastRPC driver in drivers/misc. The text describes the driver motivation, high-level architecture and interaction with IOMMU context banks, GEM-based buffer management and the RPMsg transport.
The user-space facing section documents the main QDA IOCTLs used to establish DSP sessions, manage GEM buffer objects and invoke remote procedures using the FastRPC protocol, along with a typical lifecycle example for applications.
Finally, the driver is wired into the Compute Accelerators documentation index under Documentation/accel, and a brief debugging section shows how to enable dynamic debug for the QDA implementation.
So existing applications written over character device UAPI needs to be rewritten over new UAPI and it will be broken once this driver gets merged? Are we going to keep both the drivers in the Linux kernel and not deprecate the /char device one?
Is Qualcomm going to provide the wrapper library in the userspace so that existing applications by our customers and developers keep working w/ the newer kernel if the char interface based driver gets deprecated? It is not clear from your text above.
Thanks for raising this, Trilok.
This is one of the open items that I have. I'm not exactly sure what would be the acceptable way for this.
As you mentioned, applications that rely on /dev/fastrpc* might not work on QDA without modification.
I was thinking in the same lines as you have mentioned and having some shim/compat driver to translate FastRPC UAPI to QDA. The compat driver would expose the existing character devices and route the calls to QDA. The compat driver could be built via Kconfig.
This is a fundamental requirement, you need to address this in order for this to move forward.
Which makes me wonder if it would be possible to reach an accel driver through incremental transition of the current driver, instead of just dropping in a few thousand lines of new code/design.
However, I haven’t encountered an example of such a UAPI‑translation driver in the kernel before, so I would want guidance from maintainers on whether this is an acceptable model or not.
Regarding your question about library, all the APIs exposed by github/fastrpc library are kept unchanged in terms of definitions and expectation. The same project can be build for both FastRPC and QDA based on configure options. So, the applications using github/fastrpc should not face any problem if the libs is built with proper configure options.
You're assuming that the kernel and userspace are a unified piece of software, they are not. It must be possible for me to install a new kernel package without having to replace the userspace libraries.
Regards, Bjorn
I have noted your point regarding the doc not providing clear details, I have added interface compatibility information in cover letter and will try pulling the same to Doc.
---Trilok Soni