dt-bindings/dmaengine/net: qcom: BAM XPU violation fixes for Shikra - #838
Open
Vishnu Santhosh (quic-vishsant) wants to merge 13 commits into
Open
Conversation
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
|
|
Merge Check Failed: CR Not Eligible for Merge CR 4609260 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
1 similar comment
|
Merge Check Failed: CR Not Eligible for Merge CR 4609260 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
Vishnu Santhosh (quic-vishsant)
force-pushed
the
for-shikra-bam-xpu-violation-2-0
branch
from
July 21, 2026 15:26
6754ebc to
2546101
Compare
|
Merge Check Failed: CR Not Eligible for Merge CR 4609260 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
PR #838 — validate-patchPR: #838
Final Summary
|
PR #838 — checker-log-analyzerPR: #838
Detailed report: Full report
|
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 22, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 22, 2026
Test Matrix
|
Vishnu Santhosh (quic-vishsant)
force-pushed
the
for-shikra-bam-xpu-violation-2-0
branch
from
July 24, 2026 08:20
2546101 to
054863e
Compare
PR #838 — validate-patchPR: #838
Final Summary
|
PR #838 — checker-log-analyzerPR: #838
Detailed report: Full report
|
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Jul 24, 2026
…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>
…le coherent block On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 / NAV) is the AXI master for BAM-DMUX RX and TX transfers and the XPU enforces per-region access control, each individually DMA-mapped RX or TX buffer requires its own XPU resource group (RG). With ~16 RGs available, the 64 per-buffer dma_map_single() calls (32 RX + 32 TX) exhaust the table and the first inbound or outbound transfer faults with an XPU violation. This A2 BAM instance on Shikra is not currently behind the SMMU, so DMA buffers are not covered by an IOMMU mapping; SCM-assigning the buffers to the remote VMID is the interim mechanism to grant the modem access without exhausting XPU RGs. SMMU coverage for this BAM instance is being tracked separately with the hardware team. 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 RX and TX buffers from a single contiguous dma_alloc_coherent() block and SCM-assign that block to HLOS plus the VMID once at probe, with one qcom_scm_assign_mem() call covering both directions. This reduces RG consumption from 64 to 1. The block is laid out as BAM_DMUX_NUM_SKB RX slots (BAM_DMUX_BUFFER_SIZE each) followed by BAM_DMUX_NUM_SKB TX slots (BAM_DMUX_TX_BUFFER_SIZE each); each region is independently PAGE_ALIGN()ed, both because qcom_scm_assign_mem() rejects a non-page-aligned mem_sz with -EINVAL, and so that a future size change to either slot size cannot perturb the other region's offset. 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[]/tx_skbs[] slot is pre-assigned its virtual and DMA address from the block, so no per-buffer mapping is needed. Because the coherent block is not page-backed, received payload is copied into a regular netdev skb before handoff to the network stack, and transmit payload is copied from the prepared skb into the pre-assigned TX slot in bam_dmux_skb_dma_map(); this is an unavoidable extra copy on the XPU-enforced path in both directions. A TX frame carries the qcom,shikra-bam-dmux header plus up to dev->max_mtu bytes plus up to sizeof(u32) bytes of word-alignment padding (see bam_dmux_tx_prepare_skb()), so each TX slot is sized BAM_DMUX_BUFFER_SIZE + sizeof(u32) rather than BAM_DMUX_BUFFER_SIZE, and bam_dmux_skb_dma_map() rejects an oversized TX skb rather than overflowing the slot. Platforms without match data are unaffected: 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>
Some Qualcomm SoCs using the generic PAS remoteproc driver (e.g. Shikra) implement the BAM-DMUX protocol on the modem remoteproc to expose network data channels. The hardware/firmware resources required by the BAM-DMUX driver are described in an extra device tree node below the modem remoteproc, with the compatible "qcom,bam-dmux". qcom_q6v5_mss.c already creates a platform device for this node (commit 59983c7 ("remoteproc: qcom_q6v5_mss: Create platform device for BAM-DMUX")), but qcom_q6v5_pas.c has no equivalent logic, so the bam-dmux node never probes on SoCs handled by this driver. Mirror the qcom_q6v5_mss.c approach: create a platform device specifically for the "qcom,bam-dmux" child node on probe, and destroy it on remove. of_get_compatible_child() returns NULL when the node is absent, and of_platform_device_create()/of_node_put() are NULL-safe, so this is a no-op for the many PAS-based SoCs that have no bam-dmux child. Link: https://lore.kernel.org/r/20260711-qcom-q6v5-pas-bam-dmux-v1-1-1e9231143b79@oss.qualcomm.com Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
v2 of this series moves the bam-dmux node below the modem remoteproc (remoteproc_mpss) instead of at the root, so that userspace can associate the resulting network interfaces with the owning remoteproc via udev/sysfs. Reverting the v1 placement here to pick v2 on top. This reverts commit a4a9273. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
…bnode The BAM-DMUX node lives as a direct child of the modem PAS remoteproc node, but qcom,shikra-pas.yaml has unevaluatedProperties: false and does not list bam-dmux, so any DT adding this subnode fails schema validation. Add an optional bam-dmux property referencing qcom,bam-dmux.yaml, mirroring qcom,msm8916-mss-pil.yaml. 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> Link: https://lore.kernel.org/r/20260727-shikra-pas-bam-dmux-binding-v1-1-c0159c7c3ed4@oss.qualcomm.com
Add required nodes to enable the upstream BAM-DMUX WWAN driver on Qualcomm Shikra SoC. The SMSM (Shared Memory State Machine) node provides the power control signaling between the AP and modem for BAM-DMUX. The BAM DMA controller node describes the A2 modem BAM hardware as a standard DMA controller. The BAM-DMUX node references the DMA channels and the pc/pc-ack interrupt lines from the modem SMSM entry for power control signaling. The BAM-DMUX node is placed below the modem remoteproc so that userspace can associate the resulting network interfaces with the owning remoteproc via udev/sysfs, matching how qcom_q6v5_mss.c already handles the equivalent node on older SoCs. Link: https://lore.kernel.org/r/20260711-qcom-shikra-dts-bam-dmux-v2-1-d5b33ee32138@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)
force-pushed
the
for-shikra-bam-xpu-violation-2-0
branch
from
August 31, 2026 15:19
c94444e to
1bd0da2
Compare
Test Matrix
|
Contributor
|
why this commit is PENDING ? Do we have QLI Jira approval for this ? |
Author
This is the equivalent of the patch send upstream https://lore.kernel.org/all/20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com/ which included the RX buffer change, that itself was asked by Maintainer Stephen to rewrite in a specific way and also include TX block. Since that rewrite is in progress and yet to be validated (Need a setup with W1 SIM - this is being used by the data team), I integrated the TX logic also into the existing patch to unblock the team so kept the flag PENDING. Once tested, we will be sending the v2 which takes some time. So, can I keep it FROMLIST then for this to be unblocked, if PENDING needs JIRA? |
Vishnu Santhosh (quic-vishsant)
force-pushed
the
for-shikra-bam-xpu-violation-2-0
branch
from
September 1, 2026 06:39
1bd0da2 to
2bed6ca
Compare
Test Matrix
|
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
Deepak Kumar Singh (quic-deesin)
approved these changes
Sep 1, 2026
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
7 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