On Tue, Aug 18, 2026 at 11:55:50AM +0530, Ekansh Gupta wrote:
> On 18-08-2026 09:25, Dmitry Baryshkov wrote:
> > On Mon, Aug 17, 2026 at 10:17:46AM +0530, Ekansh Gupta wrote:
> >> Allow user-space to import DMA-BUF file descriptors from other
> >> subsystems (GPU, camera, video) into the QDA driver via the standard
> >> DRM PRIME interface.
> >>
> >> qda_prime.c
> >> Implements qda_gem_prime_import(), which is set as the driver's
> >> .gem_prime_import callback. On import it:
> >> 1. Short-circuits self-import: if the dma_buf was exported by this
> >> device and is not itself an import, the existing GEM object is
> >> returned with an incremented reference count.
> >> 2. Attaches to the dma_buf and maps it with DMA_BIDIRECTIONAL via
> >> dma_buf_map_attachment_unlocked(), obtaining an sg_table whose
> >> DMA addresses are IOMMU virtual addresses in the CB device's
> >> address space.
> >> 3. Calls qda_memory_manager_alloc() to record the mapping and encode
> >> the SID in the upper bits of the DMA address, matching the
> >> convention used for natively allocated buffers.
> >>
> >> qda_prime_fd_to_handle() wraps drm_gem_prime_fd_to_handle() under
> >> qdev->import_lock, storing the calling file_priv in
> >
> > Why do you need a separate lock?
> Will add details in commit message,
> The lock serialises the `fd_to_handle → gem_prime_import` call so that
> `current_import_file_priv` is valid for the duration of the import.
> Without it, two concurrent imports could race and each see the other's
> `file_priv`.
What is different from other DRM drivers which can use
drm_gem_prime_fd_to_handle() directly?
> >
> >> qdev->current_import_file_priv so that qda_gem_prime_import() can
> >> retrieve it (the .gem_prime_import callback does not receive
> >> file_priv directly, but the context bank to attach to is per-process).
> >>
> >> qda_gem.c
> >> qda_gem_free_object() is extended to handle the imported-buffer
> >> teardown path: unmap the sg_table, detach from the dma_buf, and
> >> release the dma_buf reference.
> >> qda_gem_mmap_obj() rejects mmap requests on imported objects, which
> >> must be mapped through the exporter instead.
> >>
> >> qda_memory_manager.c
> >> The DSP is given a single base address per buffer, so only buffers
> >> that are mapped as one contiguous range can be described to it.
> >
> > Is there no IOMMU in front of the DSP? Can we remap the buffer to a
> > linear are inside the DSP map?
> The DSP firmware's buffer descriptor format carries a single
> {base_address, size} pair per buffer and it does not support
> scatter-gather or multi-entry page tables on its side. This is a
> firmware interface constraint that we cannot change from the kernel. So
> imported buffers must present as one contiguous IOVA range, and
> non-contiguous ones are rejected.
I think the main part of the question ended up being ignored. Can we use
_IOMMU_ in front of the DSP to make buffer scattered through the
multiple pages to look linear? Or maybe I'm misunderstanding what you
wrote. If I have a buffer spanning three non-contiguous pages PA, PB and
PC, can we still use that buffer with the DSP?
>
> Will add this information in commit message and during the check.>
--
With best wishes
Dmitry
