Re: [PATCH 00/12] iommu: qcom_iommu: implement support for instances on MSM8974

[Dmitry Baryshkov]

On Thu, Sep 17, 2026 at 10:11:27AM +0200, Luca Weiss wrote:
> On Thu Sep 10, 2026 at 4:20 PM CEST, Dmitry Baryshkov wrote:
> > On Thu, 10 Sept 2026 at 13:38, Luca Weiss <luca.weiss@xxxxxxxxxxxxx> wrote:
> >>
> >> Hi Dmitry,
> >>
> >> On Tue Sep 8, 2026 at 3:28 PM CEST, Dmitry Baryshkov wrote:
> >> > On Mon, Aug 24, 2026 at 12:04:57PM +0200, Luca Weiss wrote:
> >> >> Hi Dmitry,
> >> >>
> >> >> On Tue Aug 11, 2026 at 2:43 PM CEST, Dmitry Baryshkov wrote:
> >> >> > On Mon, Aug 10, 2026 at 12:16:19PM +0200, Luca Weiss wrote:
> >> >> >> Hi Dmitry,
> >> >> >>
> >> >> >> Many thanks for working on this and sending this patch series!
> >> >> >>
> >> >> >> On Sun Aug 9, 2026 at 10:15 PM CEST, Dmitry Baryshkov wrote:
> >> >> >> > Qualcomm MSM8974 platform has five SMMU instances, used by display, GPU,
> >> >> >> > Venus, VFE (camera) and JPEG encoder. Each of them follows ARM SMMU v1
> >> >> >> > spec, however they differ from other Qualcomm platforms in the
> >> >> >> > implementation-specific registers and also in interaction with TZ.
> >> >> >> > Venus, MDP and VFE SMMUs are secured and require programming only of
> >> >> >> > CBs, while GPU and JPEG require full programming.
> >> >> >> >
> >> >> >> > This series skips IOMMUs which can't be tested right now (VFE and JPEG),
> >> >> >> > and adds only MDP, GPU and Venus (although untested, it is required for
> >> >> >> > display to work) SMMU instances.
> >> >> >>
> >> >> >> I do have a patch series (sent years ago to the mailing lists as well)
> >> >> >> for CAMSS so I can definitely test this in the future.
> >> >> >
> >> >> > Ok, let's land these first, unless VFE IOMMU blocks display on your
> >> >> > platform (Venus was blocking display on APQ8074 DragonBoard).
> >> >> >
> >> >> >> > Note, to get display to work properly one fix is necessary, [1]
> >> >> >> >
> >> >> >> > [1] https://patch.msgid.link/20260809-msm8974-mmcc-fix-v1-1-50f2dcf18d2e@xxxxxxxxxxxxxxxx
> >> >> >>
> >> >> >> I've applied this series on v7.2-rc7, with the extra commits between
> >> >> >> that and linux-next for qcom_iommu.c backported so that your series
> >> >> >> applies without conflicts.
> >> >> >>
> >> >> >> So far I'm stuck with the GPU not being able to probe, adding some
> >> >> >> printk's shows that in msm_iommu_new() the call for
> >> >> >> iommu_attach_device() is failing.
> >> >> >>
> >> >> >> [    5.971154] msm_mdp fd900100.display-controller: failed to load adreno gpu
> >> >> >> [    5.972991] msm_mdp fd900100.display-controller: failed to bind fdb00000.gpu (ops a3xx_ops [msm]): -16
> >> >> >> [    5.974073] msm_mdp fd900100.display-controller: adev bind failed: -16
> >> >> >> [    5.974152] panel-s6d6fa1 fd922800.dsi.0: error -EBUSY: Failed to attach to DSI host
> >> >> >> [    5.974230] panel-s6d6fa1 fd922800.dsi.0: probe with driver panel-s6d6fa1 failed with error -16
> >> >> >
> >> >> > See the patch [1], it's picked up for 7.3
> >> >>
> >> >> I missed replying to you, with this patch the display lights up again!
> >> >>
> >> >> Unfortunately the GPU still seems to have issues, I don't have a log
> >> >> right now (I think even SSH was dropping then with a bunch of log lines
> >> >> appearing in kernel log on screen). I assume kmscube + more complex
> >> >> workloads worked fine for you?
> >> >
> >> > I was mostly using kmscube, but I can try running the CTS once I get
> >> > back to it, sorry for the delays.
> >>
> >> Yeah, kmscube doesn't even work for me.
> >>
> >> Bootup works to a tty with screen on (mdss doesn't seem to have any
> >> problems for me), but then as soon as I run kmscube the device shows a
> >> few errors on the tty0 on the screen (USB stops working apparently since
> >> my "dmesg -w" doesn't show anything) and a few seconds later the device
> >> reboots.
> >
> > Interesting. I wonder if it's TZ tripping on the VFE IOMMU.
> 
> Do you have any suggestions for me to try?

I don't think the issue is on the SMMU side. I don't see any significant
downstream difference between 8974 and 8974pro in respect to SMMUs.

Try adding GENPD_FLAG_NO_STAY_ON to (both) oxili GDSCs. Also try
manually enforcing the vote on VDDGFX (e.g. add a dummy node with random
compat and power-domain pointing to VDDGFX).

> 
> >
> >>
> >> dmesg: https://public.lucaweiss.eu/tmp/fp2-iommu-dmesg.txt
> >>
> >> The SoC in my device should be MSM8974PRO-AA (a.k.a. MSM8974AB-AA).
> >>
> >> I know there are some differences for some bits between MSM8974
> >> (Snapdragon 800) and MSM8974PRO (Snapdragon 801), which variant do you
> >> have? Maybe that's relevant, also since downstream splits devicetree
> >> based on 8974 and 8974pro.
> >
> > Mine is APQ8074, not sure if there were revisions.
> 
> Maybe /sys/devices/soc0/* or /sys/kernel/debug/qcom_socinfo/* has info
> about the revision? But maybe it's also not useful. I checked a bit more
> before and all msm8974-v2 downstream seem to have the same IOMMU config,
> just msm8974-v1 (which was barely shipped?) has different configs. So
> hopefully the SoC revisions shouldn't make a difference here.

-- 
With best wishes
Dmitry