Re: [PATCH v2 00/15] accel/qda: Qualcomm DSP Accelerator driver

[Krzysztof Kozlowski <krzk@kernel.org>]

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/20260519-qda-series-v1-0-b2d984c297f8@oss.qualcomm.com/
> RFC: https://lore.kernel.org/dri-devel/20260224-qda-firstpost-v1-0-fe46a9c1a046@oss.qualcomm.com/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/245d602f-3037-4ae3-9af9-d98f37258aae@oss.qualcomm.com/
> 
> 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