Re: [PATCH 06/12] iommu: qcom_iommu: support non-TZ-managed instances

On 8/9/26 10:15 PM, Dmitry Baryshkov wrote:
> The GPU on MSM8974 has never been usable upstream because its IOMMU
> cannot be driven: unlike the MSM8916-style instances this driver
> supports, where the secure world owns the SMMU global register space
> and the OS programs just the context banks after a restore_sec_cfg SCM
> call, the MSM8974 GPU IOMMU is not managed by TZ at all. Nobody sets
> up its stream mapping, so attaching a domain leaves every transaction
> unmatched and the GPU faults on its first memory access. Verified on
> the APQ8074 dragonboard: restore_sec_cfg is only accepted for the
> secured instances, while the GPU instance exposes its ID registers to
> the OS (IDR0 0x78034404 / IDR1 0x10000003).
> 
> Add a non-secure programming mode, derived from the downstream
> msm_iommu-v1.c driver. When qcom,iommu-secure-id is absent, reset and
> program the global space at runtime resume instead of calling into TZ:
> clear sACR/sCR2 and the global fault state, invalidate the TLB and all
> SMRs, install the per-instance stream mapping (SMR/S2CR/CBAR, with the
> downstream MEMATTR/NSCFG/VMID/IRPTNDX values) and enable the SMMU with
> fault reporting enabled and stalling disabled (sCR0.STALLD, matching
> the downstream terminate model). The stream ID map is per-instance
> configuration data since it is not discoverable from the hardware; the
> SMR index allocation keeps ASID == context bank index, which this
> hardware requires (downstream msm-3.10 commit 4d92ea10aac3 ("iommu:
> msm: Use CB index as ASID")). Also set CB_ACTLR to redirect cacheable
> requests to the L2 slave port, as the downstream driver does for every
> context on this IP generation - on MSM8916 TZ owns CB_ACTLR, so the
> driver never needed to touch it before.

At this point, would it make more sense to retrofit this atop
arm-smmu-qcom.c given all of the differences vs 8916?

Konrad