[PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
Bibek Kumar Patro
bibek.patro at oss.qualcomm.com
Tue Aug 11 08:09:41 PDT 2026
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
More information about the linux-arm-kernel
mailing list