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. |
For easier maintenance and better readability order all includes alphabetically. Link: https://lore.kernel.org/r/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>
Simplify locking across the driver with lock guards from cleanup.h. Link: https://lore.kernel.org/r/20251106-qcom-bam-dma-refactor-v1-2-0e2baaf3d81a@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
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://lore.kernel.org/r/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>
Instead of open coded variant let's use recently introduced helper. Link: https://lore.kernel.org/r/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>
…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>
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>
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
Test Matrix
|
Komal Bajaj (Komal-Bajaj)
previously approved these changes
Jul 24, 2026
Contributor
Vishnu Santhosh (@quic-vishsant) check dtb-check failure. |
Vishnu Santhosh (quic-vishsant)
force-pushed
the
for-shikra-bam-xpu-violation-2-0
branch
from
July 27, 2026 09:07
054863e to
942c1d7
Compare
PR #838 — validate-patchPR: #838
Final Summary
|
PR #838 — checker-log-analyzerPR: #838
Detailed report: Full report
|
Test Matrix
|
…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
July 27, 2026 14:35
942c1d7 to
6c95aef
Compare
PR #838 — validate-patchPR: #838
Final Summary
Overall Verdict:
|
PR #838 — checker-log-analyzerPR: #838
Detailed report: Full report
|
Author
Fixed with "FROMLIST: dt-bindings: remoteproc: qcom,shikra-pas: Allow bam-dmux subnode" binding change |
Test Matrix
|
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