On Thu, Jan 29, 2026 at 04:09:41PM +0530, Ekansh Gupta wrote: > > > On 1/6/2026 8:21 AM, Dmitry Baryshkov wrote: > > On Tue, Dec 30, 2025 at 04:32:25PM +0530, Ekansh Gupta wrote: > >> Currently, FastRPC only supports mapping buffers allocated by the > >> kernel. This limits flexibility for applications that allocate memory > >> in userspace using rpcmem or DMABUF and need to share it with the DSP. > > Hmm, for DMABUF we need _import_ support rather than support for mapping > > of userspace-allocated buffers. > > > >> Add support for mapping and unmapping userspace-allocated buffers to > >> the DSP through SMMU. This includes handling map requests for rpcmem > >> and DMABUF-backed memory and providing corresponding unmap > >> functionality. > > For me this definitely looks like a step back. For drm/accel we are > > going to have GEM-managed buffers only. Why do we need to handle > > userspace-allocated buffers here? > That's correct, GEM-PRIME will handle it properly. Here, the reason to add > this > change is to enable routing of DSP logs to HLOS which is done by using a > shared > buffer between userspace process and DSP PD. The buffer can be allocated from > both fastrpc driver's DMA-BUF or DMABUF heap(eg. system heap). > > So this shared buffer is getting mapped to both process's IOMMU device and > DSP PD > with this change.
So, you have the DMA-BUF buffer. Instead of mapping it from userspace with unclean semantics, please import the buffer. > > > >> Signed-off-by: Ekansh Gupta <[email protected]> > >> --- > >> drivers/misc/fastrpc.c | 97 +++++++++++++++++++++++++++++++++++++----- > >> 1 file changed, 86 insertions(+), 11 deletions(-) > >> -- With best wishes Dmitry
