Re: [PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Bibek Kumar Patro
Date: Tue Aug 11 2026 - 11:13:13 EST
On 7/20/2026 8:10 PM, Dmitry Baryshkov wrote:
On Mon, Jul 20, 2026 at 07:41:35PM +0530, Bibek Kumar Patro wrote:
On 7/8/2026 8:48 PM, Bjorn Andersson wrote:
On Wed, Jul 08, 2026 at 08:22:00PM +0530, Bibek Kumar Patro wrote:
On 7/7/2026 10:12 PM, Dmitry Baryshkov wrote:
On Tue, Jul 07, 2026 at 06:06:59PM +0530, Bibek Kumar Patro wrote:
On 7/6/2026 11:09 PM, Dmitry Baryshkov wrote:
On Mon, Jul 06, 2026 at 10:26:34PM +0530, Bibek Kumar Patro wrote:
Some SoC implementations require a bandwidth vote on an interconnect
path before the SMMU register space is accessible. Add the optional
Why is it limited only to those SoCs? Is it also applicable to other
Qualcomm SoCs?
I was hoping to keep this series focused on the core infrastructure
changes: the bindings, base ICC bandwidth-voting support, and DT
interconnect properties for the platforms currently supported on
Qualcomm Linux and have been validated so far.
The additional targets have not been tested yet, so I'd prefer
to add their support in a separate follow-up series once validation
is complete, rather than growing this series further. WDYT?
Then it should be a part of the commit message. All SoCs since SDM12345
need to vote on the interconnect (and then, in the cover letter mention
that you convert only a few of the SoCs). We possibly can help with
testing on other platforms.
Ack, sounds reasonable.
I'll add the first platform onwards which interconnect voting is required in
commit description.
But to what degree is this related to a specific set of platforms? If we
look ahead, aren't we expecting the list to grow to include all
platforms in the end - resulting in a lot of noise and churn.
We have seen this issue consistently on SM8750 and later platforms, along
with at least one customer-reported instance on SM8550. As a result,
downstream Android implementations already vote for the required
interconnect bandwidth explicitly on these platforms.
On Qualcomm Linux targets, we have observed similar issues on Kodiak, with a
few occurrences on Talos as well.
My understanding is that the interconnects property remains optional, but in
practice it is needed for Adreno SMMU operation on these platforms.
So, it goes back to Kodiak and Talos. What about SM8150? SDM845? Earlier
platforms? Is it limited to MMU-500? A6xx+?
Thanks for waiting this long for response,
I rechecked all the legacy platforms which are present in upstream.
As per the design it will be applicable to all targets with MMU-500,
(Even though issue hasn't been reported for all the targets on MMU-500,
e.g sm8650/sm8250 but the nodes will still be needed).
It's independent of adreno version i.e A6xx+/A5xx+.
Reason being the design difference on
how TCU works in QSMMU (SMMU-v2) vs SMMU-500
QSMMU (SMMU-v2) — SM6250 / SDM845 era
──────────────────────────────────────────────────────────────
The TCU is NOT a separate hardware master.
It is integrated INSIDE the SMMU-v2 block itself.
GPU SS
┌──────────────────────────────────┐
│ QSMMU (SMMU-v2 @ 0x5040000) │
│ ┌────────────────────────────┐ │
│ │ TCU (integrated, no │ │
│ │ separate AXI master port) │ │
│ └────────────┬───────────────┘ │
│ │ page table walk │
│ │ issued on same │
│ │ AXI port as GPU │
└───────────────┼──────────────────┘
│
│ qxm_gpu0 / qxm_gpu1
│ (GPU data + TCU walks share same NOC master)
▼
GEM_NOC
│
▼ qns_llcc0
LLCC → MC → DDR
SMMU-500 — SM8150+ / SA8775P / SC7280 etc.
──────────────────────────────────────────────────────────────
The TCU is a SEPARATE hardware block with its OWN AXI master.
GPU SS
┌──────────────────────────────────┐
│ ┌─────────────┐ ┌───────────┐ │
│ │ GPU Core │ │ GPU TCU │ │ ← distinct HW block
│ │ (rendering)│ │ + DVM │ │
│ └──────┬──────┘ └─────┬─────┘ │
└─────────┼───────────────┼────────┘
│ │
qnm_gpu0/1 alm_gpu_tcu ← separate NOC master port
│ │
└───────┬───────┘
▼
GEM_NOC
│
▼ qns_llcc0/1/2/3/4/5
LLCC → MC → DDR
---
Why this matters for the ICC vote
SMMU TCU hardware NOC master ICC vote?
--------- -------------------- ---------------- -------------------
QSMMU Integrated inside Shares qxm_gpu0/ No — GPU data
(SMMU-v2) SMMU, no separate 1 with GPU data traffic implicitly
AXI master keeps path alive
SMMU-500 Separate GPU TCU+DVM Dedicated Yes — TCU can be
block with own alm_gpu_tcu the only active
AXI master port on GEM_NOC master on wakeup;
no implicit vote
from GPU data
On SMMU-v2 platforms the TCU never needs an
independent vote because it physically cannot be active without the GPU
data path also being active.
On SMMU-500 the TCU has its own master port — it can be active (e.g
possible page table walks during wakeup) while the GPU data path is
idle, leaving GEM_NOC without any other voter. Hence the explicit
MASTER_GPU_TCU → SLAVE_EBI1 vote is required.
Following are the targets which I found out available in upstream with qsmmu/smmu-v2 and mmu-500 respectively
Adreno SMMU — upstream Qualcomm targets
SMMU-v2 (QSMMU)
Platform Compatible
--------- ------------------------------------
MSM8996 qcom,msm8996-smmu-v2, qcom,adreno-smmu
SDM670 qcom,sdm670-smmu-v2, qcom,adreno-smmu
SDM845 qcom,sdm845-smmu-v2, qcom,adreno-smmu
SC7180 qcom,sc7180-smmu-v2, qcom,adreno-smmu
SM6350 qcom,sm6350-smmu-v2, qcom,adreno-smmu
SM7150 qcom,sm7150-smmu-v2, qcom,adreno-smmu
SM6375 qcom,sm6375-smmu-v2 (apps only, no adreno-smmu node)
MSM8998 qcom,msm8998-smmu-v2 (apps only, no adreno-smmu node)
SDM630 qcom,sdm630-smmu-v2 (adreno binding to be fixed)
SMMU-500 (MMU-500) — with qcom,adreno-smmu
Platform Compatible
--------- ------------------------------------
SM6115 qcom,sm6115-smmu-500, qcom,adreno-smmu
QCM2290 qcom,qcm2290-smmu-500, qcom,adreno-smmu
SM8150 qcom,sm8150-smmu-500, qcom,adreno-smmu
SM8250 qcom,sm8250-smmu-500, qcom,adreno-smmu
SC8180x qcom,sc8180x-smmu-500, qcom,adreno-smmu
SM8350 qcom,sm8350-smmu-500, qcom,adreno-smmu
SC7280 qcom,sc7280-smmu-500, qcom,adreno-smmu ← our patch series
SM8450 qcom,sm8450-smmu-500, qcom,adreno-smmu
SC8280xp qcom,sc8280xp-smmu-500, qcom,adreno-smmu
QCS615 qcom,qcs615-smmu-500, qcom,adreno-smmu ← our patch series
SM8550 qcom,sm8550-smmu-500, qcom,adreno-smmu
SA8775P qcom,sa8775p-smmu-500, qcom,adreno-smmu ← our patch series
SM8650 qcom,sm8650-smmu-500, qcom,adreno-smmu
QCS8300 qcom,qcs8300-smmu-500, qcom,adreno-smmu ← our patch series
SAR2130P qcom,sar2130p-smmu-500, qcom,adreno-smmu
X1E80100 qcom,x1e80100-smmu-500, qcom,adreno-smmu
Glymur qcom,glymur-smmu-500, qcom,adreno-smmu
Milos qcom,milos-smmu-500, qcom,adreno-smmu
SMMU-500 — without qcom,adreno-smmu (apps SMMU only)
SDM670 qcom,sdm670-smmu-500 (apps)
SDM845 qcom,sdm845-smmu-500 (apps)
SC7180 qcom,sc7180-smmu-500 (apps)
SM6350 qcom,sm6350-smmu-500 (apps)
SM8450 qcom,sm8450-smmu-500 (apps)
SC8280xp qcom,sc8280xp-smmu-500 (apps)
SM8750 qcom,sm8750-smmu-500 (adreno-smmu not available yet)
Thanks & regards,
Bibek