Re: [PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property

[Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>]

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