On Fri, Jan 30, 2026 at 05:27:37PM +0530, Ekansh Gupta wrote: > > > On 1/30/2026 7:59 AM, Dmitry Baryshkov wrote: > > 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. > I'm assuming fastrpc_map_create is sort of importing the buffer by calling > dma_buf_map_attachment. Is this not the correct understanding? This assumption > is based on the existing part inside fastrpc_get_args, where > fastrpc_map_create is > getting called for each of user passed DMA-BUF.
I was thinking about dma_buf_attach() rather than dma_buf_map_attachment(). > > Moving to accel based driver is going to standardize this as the > .gem_prime_import > implementation is going to handle this case. > > //Ekansh > > > > >>>> Signed-off-by: Ekansh Gupta <[email protected]> > >>>> --- > >>>> drivers/misc/fastrpc.c | 97 +++++++++++++++++++++++++++++++++++++----- > >>>> 1 file changed, 86 insertions(+), 11 deletions(-) > >>>> > -- With best wishes Dmitry
