On Mon, Aug 17, 2026 at 10:38:45AM +0530, Ekansh Gupta wrote: > Add DRM_IOCTL_QDA_REMOTE_MUNMAP, which removes a mapping previously > established with DRM_IOCTL_QDA_REMOTE_MAP from the DSP address space of > the calling process. > > Mirroring the map path, the DSP exposes two unmap operations, both > reachable through this IOCTL and selected by the request field of > struct drm_qda_mem_unmap: > > QDA_REQUEST_MUNMAP unmaps a region by the DSP address that the > corresponding map call returned. It uses the vaddrout and size fields. > > QDA_REQUEST_MEM_UNMAP unmaps a region by buffer identity, using the > GEM handle, the DSP virtual address and the size.
Why do we need two different operations? Can you just pass the GEM handle to the IOCTL? Also, what happens if the buffer is still in use on the DSP side? Will the DSP crash? Will the whole board crash? > > Each request type has its own argument builder in qda_fastrpc.c, > documented with the packed argument layout the DSP expects. Unknown > request types are rejected with -EINVAL. > > Assisted-by: Claude:claude-sonnet-5 > Signed-off-by: Ekansh Gupta <[email protected]> > --- > drivers/accel/qda/qda_drv.c | 1 + > drivers/accel/qda/qda_fastrpc.c | 119 > ++++++++++++++++++++++++++++++++++++++++ > drivers/accel/qda/qda_fastrpc.h | 34 ++++++++++++ > drivers/accel/qda/qda_ioctl.c | 22 ++++++++ > drivers/accel/qda/qda_ioctl.h | 1 + > include/uapi/drm/qda_accel.h | 39 ++++++++++++- > 6 files changed, 215 insertions(+), 1 deletion(-) > > -- With best wishes Dmitry
