On 17/08/2026 06:47, Ekansh Gupta wrote: > This patch series introduces the Qualcomm DSP Accelerator (QDA) driver, > a DRM-based accelerator driver for Qualcomm DSPs. The driver provides a > standardized interface for offloading computational tasks to DSPs found > on Qualcomm SoCs, supporting all DSP domains. > > The QDA driver implements the FastRPC protocol over the DRM accel > subsystem. It uses the same device-tree node structure as the existing > fastrpc driver in drivers/misc/. The approach for binding the QDA driver > to device-tree nodes while coexisting with the fastrpc driver is an open > item described below.
No. Grow/replace/improve existing driver instead of coming with a duplicate. That's a standard upstream requirement, basically given on every upstreaming guide. Please watch old talk from Greg - "I Don’t Want Your Code!". > > v1: > https://lore.kernel.org/all/[email protected]/ > RFC: > https://lore.kernel.org/dri-devel/[email protected]/T/ > > Changes since v1 > ================ > > The v1 review raised two architectural objections and one correctness > issue; all three are resolved in v2: > > * Christian König (dma-buf maintainer) pointed out that the imported- > buffer path silently assumed the IOMMU maps every buffer as a single > contiguous range, which is not guaranteed. v2 walks the scatterlist > and cleanly rejects non-contiguous imports; contiguous imports (e.g. > CMA DMA-buf heap) are accepted. (patch 11) > > * Dmitry Baryshkov objected to three different buffer-passing formats > in the invoke IOCTL (DMA-BUF fd, direct/inline, DMA handle). v2 > passes only GEM handles; userspace imports any fd to a GEM handle > with DRM_IOCTL_PRIME_FD_TO_HANDLE before invoking. Packing and > overlap handling are left to userspace. (patch 12) > > * The memory manager (patch 07) used a fixed 16-entry array without > justification and leaked the device descriptor on teardown. v2 > allocates the array from the DT context-bank count (as Dmitry > suggested) and frees it correctly. > > User-space staging branch > ========================= > https://github.com/qualcomm/fastrpc/tree/accel/staging > > Key Features > ============ > > * Standard DRM accelerator interface via /dev/accel/accelN > * GEM-based buffer management with DMA-BUF import (PRIME) > * IOMMU-based memory isolation using per-process context banks > * FastRPC protocol implementation for DSP communication > * RPMsg transport layer for reliable message passing > * Support for all DSP domains (ADSP, CDSP, SDSP, GDSP) > * DRM IOCTL interface for DSP session management, buffer allocation, > and remote procedure invocation > > Architecture > ============ > > 1. DRM Accelerator Framework Integration > The driver registers as a DRM accel device, exposing a standard > /dev/accel/accelN character device node. This provides established > DRM infrastructure for device management, file operations, and > IOCTL dispatch. > > 2. Memory Management > Buffers are managed as GEM objects with PRIME support for DMA-BUF > import. This enables buffer sharing with other DRM drivers (GPU, > camera, video) using standard kernel mechanisms. Only contiguous > imports are accepted; the driver verifies contiguity at import time > rather than assuming it. > > 3. IOMMU Context Bank Management > IOMMU context banks (CBs) are represented as proper struct device > instances on a custom virtual bus (qda-compute-cb). Each CB device > is registered with the IOMMU subsystem and receives its own IOMMU > domain, enabling per-session address space isolation. The custom > bus was introduced because IOMMU context banks are synthetic > constructs — not real platform devices — and to ensure CB device > lifetime is strictly subordinate to the parent QDA device. > See also: > https://lore.kernel.org/all/[email protected]/ > > 4. Memory Manager Architecture > The memory manager maintains a registry of IOMMU devices in an > array sized to the number of context banks described in the device > tree, and coordinates per-process device assignment with reference- > counted lifetime management. The DMA-coherent backend allocates > buffers with SID-prefixed DMA addresses for DSP firmware > compatibility. > > 5. Transport Layer > RPMsg communication is handled in a dedicated transport layer > (qda_rpmsg.c), separate from the core DRM driver logic. > > 6. Code Organization > The driver is organized across multiple files (~4800 lines total): > * qda_drv.c: Core driver and DRM integration > * qda_rpmsg.c: RPMsg transport layer > * qda_cb.c: Context bank device management > * qda_compute_bus.c: Custom virtual bus for CB devices > * qda_gem.c: GEM object management > * qda_prime.c: DMA-BUF import (PRIME) > * qda_memory_manager.c: IOMMU device registry and allocation > * qda_memory_dma.c: DMA-coherent allocation backend > * qda_fastrpc.c: FastRPC protocol implementation > * qda_ioctl.c: IOCTL dispatch > > 7. UAPI Design > The driver exposes DRM-style IOCTLs defined in > include/uapi/drm/qda_accel.h, following DRM UAPI conventions > (__u32/__u64 types, C++ guard, GPL-2.0-only WITH Linux-syscall-note). > Buffer arguments are identified by GEM handles; the driver never > accepts DMA-BUF fds directly in any IOCTL. > > Patch Series Organization > ========================== > > Patch 01: MAINTAINERS entry > Patch 02: Driver documentation (Documentation/accel/qda/) > Patches 03-04: Core driver skeleton and compute bus > Patch 05: iommu: Register qda-compute-cb bus with IOMMU subsystem > Patches 06-07: CB device enumeration and memory manager > Patch 08: QUERY IOCTL and UAPI header > Patches 09-11: GEM buffer management and PRIME import > Patches 12-15: FastRPC protocol (invoke, session create/release, > map/unmap) > > Open Items > =========== > > 1. Device-Tree Compatible String > The QDA driver uses the same device-tree node structure and > properties as the existing fastrpc driver in drivers/misc/. A > mechanism is needed to allow the QDA driver to bind to its device > node independently of the fastrpc driver. > > The intended coexistence model is: platforms that require the > complete fastrpc feature set continue to use "qcom,fastrpc"; new > platforms where QDA's feature set is sufficient use a QDA-specific > compatible string. New feature development is directed toward QDA. > > The options under consideration are: > > a) Add a new "qcom,qda" compatible string to the existing > qcom,fastrpc.yaml binding, since the DT node structure and > properties are identical. No > > b) Introduce a separate qcom,qda.yaml binding that references or > inherits the fastrpc binding properties. No > > Seeking guidance from DT binding maintainers on the preferred > approach. Grow existing driver. You do not get new driver, you do not get new bindings. Best regards, Krzysztof
