FROMLIST: Add missing bug fixes #535
Open
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
The fdlist is currently part of the meta buffer, computed during put_args. This leads to code duplication when preparing and reading critical meta buffer contents used by the FastRPC driver. Move fdlist to the invoke context structure to improve maintainability and reduce redundancy. This centralizes its handling and simplifies meta buffer preparation and reading logic. Link: https://lore.kernel.org/r/20251128050534.437755-2-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to improve readability and follow kernel bitfield conventions. Use FIELD_PREP and FIELD_GET instead of manual shifts for setting and extracting ctxid values. Link: https://lore.kernel.org/r/20251128050534.437755-3-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
…support Current FastRPC message context uses a 12-bit mask where the upper 8 bits represent the context ID from idr_alloc_cyclic and the lower 4 bits represent the PD type. This layout works for normal FastRPC calls but fails for polling mode because DSP expects a 16-bit context with an additional async mode bit. 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. This is not a bug and the change is added to support polling mode. Link: https://lore.kernel.org/r/20251128050534.437755-4-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. Add 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. Poll mode can be enabled by user by using FASTRPC_IOCTL_SET_OPTION ioctl request with FASTRPC_POLL_MODE request id. Link: https://lore.kernel.org/r/20251128050534.437755-5-ekansh.gupta@oss.qualcomm.com Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Jianping-Li
force-pushed
the
feature/qcs6490_remote_heap
branch
from
fcc978d to
b751911
Compare
Kaanapali introduces changes in DSP IOVA layout and CDSP DMA addressing that differ from previous SoCs. The SID field moves within the physical address, and CDSP now supports a wider DMA range, requiring updated sid_pos and DMA mask handling in the driver. Link: https://lore.kernel.org/all/20251226070534.602021-2-kumari.pallavi@oss.qualcomm.com/ Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
The fields buf->phys and map->phys currently store DMA addresses returned by dma_map_*() APIs, not physical addresses. This naming is misleading and may lead to incorrect assumptions about the address type and its translation. Rename these fields from phys to dma_addr to improve code clarity and align with kernel conventions for dma_addr_t usage. Link: https://lore.kernel.org/all/20251226070534.602021-3-kumari.pallavi@oss.qualcomm.com/ Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
Implement the new IOVA formatting required by the DSP architecture change on Kaanapali SoC. Place the SID for DSP DMA transactions at bit 56 in the physical address. This placement is necessary for the DSPs to correctly identify streams and operate as intended. To address this, set SID position to bit 56 via OF matching on the fastrpc node; otherwise, default to legacy 32-bit placement. This change ensures consistent SID placement across DSPs. Link: https://lore.kernel.org/all/20251226070534.602021-4-kumari.pallavi@oss.qualcomm.com/ Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…i SoC DSP currently supports 32-bit IOVA (32-bit PA + 4-bit SID) for both Q6 and user DMA (uDMA) access. This is being upgraded to 34-bit PA + 4-bit SID due to a hardware revision in CDSP for Kaanapali SoC, which expands the DMA addressable range. Update DMA bits configuration in the driver to support CDSP on Kaanapali SoC. Set the default `dma_bits` to 32-bit and update it to 34-bit based on CDSP and OF matching on the fastrpc node. Link: https://lore.kernel.org/all/20251226070534.602021-5-kumari.pallavi@oss.qualcomm.com/ Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
…t crash The fastrpc_buf_free function currently does not handle the case where the input buffer pointer (buf) is NULL. This can lead to a null pointer dereference, causing a crash or undefined behavior when the function attempts to access members of the buf structure. Add a NULL check to ensure safe handling of NULL pointers and prevent potential crashes. Link: https://lore.kernel.org/all/20260115082851.570-2-jianping.li@oss.qualcomm.com/ Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…emory pool The initially allocated memory is not properly included in the pool, leading to potential issues with memory management. The issue is actually a memory leak because the initial memory is never used by Audio PD. It will immediately make a remote heap request as no memory is added to the pool initially. Set the number of pages to one to ensure that the initially allocated memory is correctly added to the Audio PD memory pool. Link: https://lore.kernel.org/all/20260115082851.570-3-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…tion fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if any other thread removes the entry from list while unmap operation is ongoing. Remove the entry before calling unmap operation. Link: https://lore.kernel.org/all/20260115082851.570-4-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
… in probe The entire reserved-memory region is now assigned to DSP VMIDs during channel setup and stored in cctx->remote_heap. Memory is reclaimed in rpmsg_remove by revoking DSP permissions and freeing the buffer, tying heap lifecycle to the rpmsg channel. Link: https://lore.kernel.org/all/20260115082851.570-5-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Jianping-Li
force-pushed
the
feature/qcs6490_remote_heap
branch
from
b751911 to
036f305
Compare
ekanshibu
force-pushed
the
tech/mm/fastrpc
branch
from
f55ee11 to
a471773
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 patch series adds the listed bug fixes that have been missing in upstream fastRPC driver.
following fixes: