[PATCH 0/3] iommu: qcom: Fix the MSM GPU and display with DMA-address based mappings

[Rob Clark]

On Mon, Nov 2, 2026 at 1:58 AM Dmitry Baryshkov
<dmitry.baryshkov at oss.qualcomm.com> wrote:
>
> On Sat, Oct 31, 2026 at 08:33:06AM -0700, Rob Clark wrote:
> > On Fri, Oct 30, 2026 at 3:05 PM Dmitry Baryshkov
> > <dmitry.baryshkov at oss.qualcomm.com> wrote:
> > >
> > > Rob's drm/msm series [1] writes the addresses dma_map_sgtable() returns
> > > for the DRM device into the GPU and display page tables, so they have to
> > > be physical addresses, i.e. the device must not use iommu-dma. On DPU
> > > platforms that holds, the DRM device has no iommus of its own. On MDP5
> > > platforms it is the MDP5 device, which ends up with iommu-dma: the GPU
> > > then fails to start on db410c and sda660 and resets db820c. The last
> > > two patches give it an identity default domain in qcom_iommu and
> > > arm-smmu-qcom.
> > >
> > > The first patch fixes qcom_iommu's flush_iotlb_all, which never
> > > invalidated the TLB. Nothing relies on it today, but the series above
> > > does, hence no Fixes tag.
> > >
> > > The patches are independent of [1] and a no-op for the current drm/msm,
> > > but have to land before it. Tested on top of [1] on db410c, db820c and
> > > IFC6560 with and without these patches, and on Open-Q 835 (DPU) as a
> > > control.
> >
> > Thanks, this should mostly supersede my untested series[1], but I
> > think msm_iommu.c still needs the same treatment?  Hopefully just the
> > def_domain_type() part?
>
> The msm_iommu.c needed more fixes. I will refresh my old series and
> include fixes necessary for the dmabuf debug to work.

I guess if iommu/msm needs other fixes in the first place, that
shouldn't hold up the dmabuf-debug series

BR,
-R