On 18-08-2026 09:12, Dmitry Baryshkov wrote: > On Mon, Aug 17, 2026 at 10:17:44AM +0530, Ekansh Gupta wrote: >> Introduce DMA-coherent buffer management for the QDA driver, wiring >> together the GEM subsystem, the IOMMU memory manager, and a DMA >> allocation backend. >> >> qda_gem.c / qda_gem.h >> Implements the GEM object lifecycle for QDA buffers. Each buffer is >> represented by a qda_gem_obj which embeds a drm_gem_object and >> carries the kernel virtual address, DMA address, and a pointer to >> the IOMMU device that performed the allocation. The .free callback >> delegates to the memory manager, and the .mmap callback uses >> dma_mmap_coherent() via the DMA backend. >> >> qda_memory_dma.c / qda_memory_dma.h >> DMA coherent allocation backend. qda_dma_alloc() calls >> dma_alloc_coherent() on the CB device and encodes the stream ID >> (SID) in the upper 32 bits of the returned DMA address, following >> the Qualcomm FastRPC convention for IOMMU address space tagging. >> qda_dma_free() strips the SID prefix before calling >> dma_free_coherent(). >> >> qda_memory_manager.c >> Adds process-to-device assignment: each DRM file (process) is >> assigned one IOMMU context bank device for the lifetime of the >> session. qda_memory_manager_assign_device() first checks whether >> the process already has a device (reusing it with a refcount >> increment), then falls back to claiming an unassigned device. >> qda_memory_manager_alloc() and qda_memory_manager_free() delegate >> to the DMA backend after resolving the correct CB device for the >> calling process. >> >> qda_drv.c / qda_drv.h >> qda_file_priv gains an assigned_iommu_dev pointer and a pid field. >> The .postclose callback decrements the IOMMU device refcount and >> clears the process assignment when the last reference is dropped. > > This provides a nice summary of the patch, which is pretty useless. I'll fix this for all patches.> Please teach your AI instead to describe the reasons and the design > decisions instead of just assessing what the code does. Why do you need > memory manager? Why can't you use existing GEM helpers? I'll add more details for this in commit message: The DSP requires each buffer's DMA address to carry the stream ID of the context bank that owns it (SID << 32 | IOVA). The memory manager tracks which CB is assigned to which process and ensures all allocations for a process go through that device.
`drm_gem_dma_create()` and friends allocate from `dev`, the DRM device itself. QDA needs to allocate from one of N child CB devices (each with its own IOMMU domain), selected per-process. There's no existing GEM helper that takes a per-allocation device argument. //Ekansh > >> >> Assisted-by: Claude:claude-sonnet-5 >> Signed-off-by: Ekansh Gupta <[email protected]> >> --- >> Changes in v2: >> - Adapt to the dynamically-sized device array introduced in patch 07 >> (kcalloc'd from DT node count, replaces fixed QDA_IOMMU_DEVICES_MAX) >> - Protect register/unregister with the process_assignment_lock mutex so >> the device-assignment and device-registration paths are serialised >> - No functional changes requested by reviewers on this patch >> --- >> drivers/accel/qda/Makefile | 2 + >> drivers/accel/qda/qda_drv.c | 4 + >> drivers/accel/qda/qda_drv.h | 4 + >> drivers/accel/qda/qda_gem.c | 134 ++++++++++++++++++ >> drivers/accel/qda/qda_gem.h | 52 +++++++ >> drivers/accel/qda/qda_memory_dma.c | 82 +++++++++++ >> drivers/accel/qda/qda_memory_dma.h | 17 +++ >> drivers/accel/qda/qda_memory_manager.c | 239 >> ++++++++++++++++++++++++++++++++- >> drivers/accel/qda/qda_memory_manager.h | 30 +++++ >> 9 files changed, 559 insertions(+), 5 deletions(-) >> >
