dt-bindings/dmaengine/net: qcom: BAM XPU violation fixes for Shikra#838
Open
Vishnu Santhosh (quic-vishsant) wants to merge 9 commits into
Open
Conversation
For easier maintenance and better readability order all includes alphabetically. Link: https://patch.msgid.link/20251106-qcom-bam-dma-refactor-v1-1-0e2baaf3d81a@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Simplify locking across the driver with lock guards from cleanup.h. Link: https://patch.msgid.link/20251106-qcom-bam-dma-refactor-v1-2-0e2baaf3d81a@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Sometimes the user needs to split each entry on the mapped scatter list due to DMA length constrains. This helper returns a number of entities assuming that each of them is not bigger than supplied maximum length. Link: https://patch.msgid.link/20260108105619.3513561-2-andriy.shevchenko@linux.intel.com Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Instead of open coded variant let's use recently introduced helper. Link: https://patch.msgid.link/20260108105619.3513561-11-andriy.shevchenko@linux.intel.com Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
…ompatible On platforms where the modem DMAs into the BAM-DMUX RX data buffers and the XPU enforces per-region access control, each individually DMA-mapped RX buffer consumes an XPU resource group. With only ~16 groups available, the per-buffer mappings exhaust the table and inbound transfers fault. Add qcom,shikra-bam-dmux as an additional compatible for the Shikra SoC, paired with the generic qcom,bam-dmux fallback, so the driver can match on it via its of_device_id table. Link: https://lore.kernel.org/r/20260714-qcom-bam-dmux-vmid-ext-v1-1-3f29da7cca76@oss.qualcomm.com Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
…rent block On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 / NAV) is the AXI master for BAM-DMUX RX transfers and the XPU enforces per-region access control, each individually DMA-mapped RX buffer requires its own XPU resource group (RG). With ~16 RGs available, the 32 per-buffer dma_map_single() calls exhaust the table and the first inbound transfer faults with an XPU violation. BAM-DMUX is a singleton (exactly one instance per SoC), so the destination VMID does not need to be a DT property; it is looked up from the compatible string's match data instead. Add struct bam_dmux_data with a single vmid field, and a shikra_data instance hardcoding QCOM_SCM_VMID_NAV for qcom,shikra-bam-dmux. When match data is present, allocate all BAM_DMUX_NUM_SKB RX buffers as a single contiguous dma_alloc_coherent() block and SCM-assign that block to HLOS plus the VMID once at probe. This reduces RG consumption from 32 to 1. The block is never reclaimed across a modem power cycle (bam_dmux_power_off() does not touch it), so the probe-time assignment covers every subsequent restart without re-assigning or reclaiming. It is reclaimed to HLOS only once, at remove or on a probe error, and if that reclaim fails it is leaked rather than returned to the page allocator. Each rx_skbs[] slot is pre-assigned its virtual and DMA address from the block, so no per-buffer mapping is needed at power-on. Because the coherent block is not page-backed, received payload is copied into a regular netdev skb before handoff to the network stack; this is an unavoidable extra copy on the XPU-enforced RX path. Platforms without match data are unaffected: rx_virt stays NULL, no coherent memory is allocated, and the per-buffer dma_map_single() path is unchanged. Link: https://lore.kernel.org/r/20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
…erty A SoC can have multiple BAM DMA instances. Some of these BAMs are powered by a remote processor that enforces XPU (eXternal Protection Unit) access control and reads the per-channel descriptor FIFOs as an AXI master under that remote processor's execution environment, so their FIFOs must be accessible to the remote processor's VMID; other BAM instances on the same SoC are not behind such a remote processor and must not have this property set. Add an optional qcom,vmid property listing the destination VMID(s) that the affected BAM instance's descriptor FIFOs must be accessible to. HLOS is always the source owner and must not be listed. Link: https://lore.kernel.org/r/20260714-qcom-bam-dma-vmid-ext-v1-1-cef87c57b7dc@oss.qualcomm.com Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
…remote VMID
On Qualcomm SoCs where the BAM is powered by a remote processor that
enforces XPU access control (e.g. the mDSP on Shikra, VMID 43 / NAV),
the BAM reads the descriptor FIFO as an AXI master under the remote
execution environment. Without an SCM grant for the remote VMID, the
first descriptor enqueue faults with an XPU violation.
Parse the optional qcom,vmid DT property as a list of destination
VMIDs. When present, SCM-assign each channel's descriptor FIFO to HLOS
plus the listed VMIDs; num_vmids being non-zero is derived purely from
qcom,vmid, a board-integration property, not from the per-SoC IP data,
and is distinct from qcom,powered-remotely.
A BAM with configured VMIDs has two properties that shape the channel
lifecycle:
1. The remote firmware owns the BAM's power and reset. It may remove
power during error recovery before the driver releases its
channels, so any pipe/block register access at teardown can raise
a synchronous external abort, and a local reset is redundant as
the remote re-initialises the hardware on the next power-on.
2. TZ does not revoke the SCM grant when the remote powers down. A
FIFO assigned once stays assigned across every power cycle, and
re-assigning or reclaiming it while the remote is mid-teardown is
rejected by TZ with -EINVAL.
Handle both by keeping the descriptor FIFO as a persistent resource on
such BAMs: allocate and SCM-assign it once on the first
bam_alloc_chan(), keep it (and its grant) across power cycles, and
reclaim it to HLOS and free it only once in bam_dma_remove(). If the
final reclaim fails the remote still has access, so the buffer is
leaked rather than returned to the page allocator; the source-VMID
bitmask stored by qcom_scm_assign_mem() drives that reclaim.
bam_free_chan() on such a BAM therefore only drops local channel state
(clear ->initialized, decrement active_channels) with no MMIO and no
SCM call, so the block and pipe are re-initialised on the next
power-on while power is present. The bam_chan_init_hw() pipe reset in
bam_dma_terminate_all() is likewise skipped. reclaiming the FIFO is an
SCM call, not a register access, so bam_dma_remove() stays safe.
Platforms that do not set qcom,vmid keep num_vmids 0, make no SCM
call, and leave the alloc/free and register-access paths unchanged.
Link: https://lore.kernel.org/r/20260714-qcom-bam-dma-vmid-ext-v1-2-cef87c57b7dc@oss.qualcomm.com
Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
On the Qualcomm Shikra SoC the mDSP (VMID 43 / QCOM_SCM_VMID_NAV) is the AXI master for BAM descriptor FIFO accesses. The XPU enforces per-region access control; without an SCM assignment granting NAV access, the first DMA transfer triggers an XPU violation. Add qcom,vmid = <QCOM_SCM_VMID_NAV> to the bam_dmux_dma controller node so bam_dma SCM-assigns each channel descriptor FIFO at allocation. BAM-DMUX itself is a singleton and no longer needs a DT property for its destination VMID: the driver now selects QCOM_SCM_VMID_NAV internally via the qcom,shikra-bam-dmux compatible's match data. Link: https://lore.kernel.org/r/20260714-b4-qcom-shikra-dts-bam-dmux-vmid-ext-v1-1-5b19da8d7735@oss.qualcomm.com Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Vishnu Santhosh (quic-vishsant)
requested review from
a team,
Amit Kucheria (idlethread),
knaveen-qc and
yijiyang
July 17, 2026 10:13
PR #838 — validate-patchPR: #838
Final Summary
|
PR #838 — checker-log-analyzerPR: #838
Detailed report: Full report
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
On Qualcomm Shikra SoC the mDSP (VMID 43 / QCOM_SCM_VMID_NAV) is the AXI
master for both BAM-DMUX RX data buffers and BAM descriptor FIFOs. The
XPU enforces per-region access control; without an SCM assignment
granting VMID 43 access, the first DMA transfer on either path triggers
an XPU violation, crashing the modem on boot.
Two independent issues, each with a binding + driver patch:
BAM-DMUX RX buffers: each individually DMA-mapped RX buffer consumes
one XPU resource group. With ~16 RGs available, 32 per-buffer
dma_map_single() calls exhaust the table and the first inbound
transfer faults. Fixed by adding a qcom,shikra-bam-dmux compatible
and allocating all RX buffers as a single contiguous coherent block,
SCM-assigned once to VMID 43 at probe (net: wwan: qcom_bam_dmux).
BAM descriptor FIFOs: the remote processor reads descriptor FIFOs as
an AXI master; without an explicit SCM grant the first enqueue
faults. Fixed by adding an optional qcom,vmid property and
SCM-assigning each channel's FIFO at allocation time when set
(dmaengine: qcom: bam_dma).
Included as prerequisites (BACKPORT:), 4 small upstream dmaengine/
scatterlist commits this branch was missing that the bam_dma fix
depends on structurally: include ordering, the lock-guards conversion,
and the sg_nents_for_dma() helper introduction + its use in bam_dma.
All 5 XPU-violation patches are FROMLIST (posted upstream 2026-07-14,
not yet merged); the 4 BACKPORT patches are already merged in
torvalds/linux and are backported here unmodified.
CRs-Fixed: 4609260