tech/mm/fastrpc: Refactor and add userspace buffer support #387
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FD list is part of meta buffer which is calculated during put args. Move fdlist to invoke context structure for better maintenance and to avoid code duplicacy for calculation of critical meta buffer contents that are used by fastrpc driver. Link: https://lore.kernel.org/all/20250901053336.3939595-2-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Current fastrpc message context uses a 12-bit mask where the upper 8 bits are context ID from idr_alloc_cyclic and the lower 4 bits represent PD type. This design works for normal fastrpc calls but doesn't work as expected for polling mode. To enable polling mode support from DSP(DSP writes to poll memory), DSP expects a 16-bit context where the upper 8 bits are context ID, the lower 4 bits are PD type and the 5th bit from the end denotes async mode(not yet upstreamed). If this bit is set, DSP disables polling. With the current design, odd context IDs set this bit, causing DSP to skip poll memory updates. Update the context mask to ensure a hole which won't get populated, ensuring polling mode works as expected. Link: https://lore.kernel.org/all/20250901053336.3939595-3-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
For any remote call to DSP, after sending an invocation message, fastRPC driver waits for glink response and during this time the CPU can go into low power modes. This adds latency to overall fastrpc call as CPU wakeup and scheduling latencies are included. Adding a polling mode support with which fastRPC driver will poll continuously on a memory after sending a message to remote subsystem which will eliminate CPU wakeup and scheduling latencies and reduce fastRPC overhead. Link: https://lore.kernel.org/all/20250901053336.3939595-4-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…unctions Refactor FastRPC mmap and munmap handling by introducing dedicated helper functions for DSP-side operations. This change improves code readability and separates DSP invocation logic from buffer allocation and cleanup. Link: https://lore.kernel.org/all/20251128103428.1119696-2-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
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. 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. Link: https://lore.kernel.org/all/20251128103428.1119696-3-ekansh.gupta@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Chennak-quic
previously approved these changes
Dec 2, 2025
Komal-Bajaj
dismissed
Chennak-quic’s stale review
The merge-base changed after approval.
Komal-Bajaj
force-pushed
the
tech/mm/fastrpc
branch
from
dba4eb2 to
844e24f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series improves the FastRPC driver by first refactoring mmap and
munmap logic into helper functions, and then adding support for mapping
userspace-allocated buffers to the DSP.
Patch 1 introduces helper functions for DSP-side operations, improving
code readability and preparing for future enhancements. Patch 2 builds
on this by enabling applications to share memory allocated in userspace
(via rpcmem or DMABUF) with the DSP through SMMU, improving flexibility
and performance.
No functional changes are introduced in the first patch; the second
patch adds the new feature.
Link: https://lore.kernel.org/all/20251128103428.1119696-1-ekansh.gupta@oss.qualcomm.com/