Re: Fixing TegraDRM on multi_v7_defconfig / Enabling DMA API with tegra-smmu

On Monday, July 27, 2026 11:51=E2=80=AFPM Robin Murphy wrote:
> On 24/07/2026 8:35 am, Mikko Perttunen wrote:
> > Greetings everyone.
> >=20
> > I've been looking at enabling more CI for 32-bit Tegra platforms
> > recently, and I ran into a problem with TegraDRM not probing on
> > tegra30-cardhu, but only on multi_v7_defconfig.
> >=20
> > I traced the issue to the following sequence of events:
> >=20
> > 1. On multi_v7_defconfig, CONFIG_ARM_DMA_USE_IOMMU is enabled, while on
> >     tegra_defconfig it is not. This causes arm_setup_iommu_dma_ops to r=
un
> >     on TegraDRM devices.
> >=20
> > 2. Some of these devices will be placed in a single IOMMU group by the
> >     tegra-smmu driver. When arm_setup_iommu_dma_ops is called, dependin=
g
> >     on probe deferrals, the group may have only the currently probing
> >     device, or a previously deferred device and the new device.
> >=20
> >     arm_setup_iommu_dma_ops calls iommu_attach_device. If the device is
> >     alone in its group, this succeeds. If not, this fails. If
> >     iommu_attach_device fails for every device in the group, everything
> >     is "fine" and TegraDRM goes to probe and work fine. Hence let's
> >     assume we have one device that succeeded the attach.
> >=20
> > 3. iommu_device_use_default_domain gets called and succeeds on the firs=
t
> >     device in the group. On the second device in the group, it fails
> >     since group->owner_cnt was already 1. The custom ARM DMA IOMMU
> >     implementation uses a custom UNMANAGED domain so the domain !=3D
> >     default_domain check evaluates to true.
> >=20
> > 4. Devices fail to probe which leads TegraDRM overall not to probe.
> >=20
> > I've thought of the following options to fix this:
> >=20
> > 1. Match behavior with tegra_defconfig: Figure out a way to not run
> >     arm_setup_iommu_dma_ops for this situation (ideally any multi-devic=
e
> >     group situation). However, I'd also like to enable DMA API with
> >     tegra-smmu to get rid of the manual IOMMU API code paths in TegraDR=
M,
> >     so this is not a particularly satisfying route.
> >=20
> > 2. Improve the legacy path: Fix the ARM IOMMU DMA code to support
> >     groups, and add an exception in iommu_device_use_default_domain. Bu=
t
> >     I presume we don't want such non-trivial modifications to that code
> >     at this point.
> >=20
> > 3. Modernize: Support CONFIG_IOMMU_DMA on ARM -- since there is an issu=
e
> >     with per-SoC quirks, I think this should be done one SoC at a time.
> >     So come up with a way to dynamically pick between the legacy and
> >     IOMMU_DMA paths. Perhaps if the SMMU driver explicitly requests the
> >     DMA domain type, use the modern path. Currently, CONFIG_IOMMU_DMA a=
nd
> >     CONFIG_ARM_DMA_USE_IOMMU are mutually exclusive so that has to be
> >     changed.
> >=20
> > FWIW, if we are to move to using DMA API with TegraDRM, one blocker
> > would have to be resolved: boot splashes scanning out while the DMA
> > domain is being set up. Since we cannot really use the iommu-addresses
> > reserved-region device tree bindings with these old devices, my thought
> > is to leave the display memory clients in bypass in tegra-smmu until th=
e
> > display driver has quiesced the hardware and can then call into
> > tegra-smmu to enable translation.
> >=20
> > Please let me know what you think and whom I missed in the To/Cc fields=
.
>=20
> TBH I rather feel like the time for converting ARM to iommu-dma has=20
> passed - there are drivers which rely on specific behaviours of the ARM=20
> IOVA allocator which iommu-dma does not match, and meanwhile iommu-dma=20
> continues to grow more server-specific features which would be nothing=20
> but bloat on ARMv7 systems with <=3D2GB of RAM and no virtualisation. At=
=20
> this point I'm inclined to treat the existing DMA ops as legacy code=20
> like with alpha/sparc/etc.
>=20
> While there is technically an option 4, to have tegra-smmu do what=20
> ipmmu-vmsa and mtk_iommu_v1 do and go coercing the ARM dma_iommu_mapping=
=20
> into groups behind the arch code's back, I am also still hoping to get=20
> rid of that and the messy probe_finalize step altogether. FWIW my=20
> preference would be some form of option 2 - off-hand I imagine you could=
=20
> probably get most of the way there by propagating the ARM mapping=20
> through group->iommudata (ironically tegra-smmu being the only driver in=
=20
> the way of that - looks like it could probably do its internal group=20
> accounting explicitly in release_device instead), plus one or two=20
> special cases to recognise ARM DMA domains in the core code as you say.=20
> The more involved, but ultimately neater, option would be to turn the=20
> ARM mapping inside-out and make it a proper domain cookie type with the=20
> ARM code providing its own definitions of iommu_{get,put}_dma_cookie()=20
> and iommu_setup_dma_ops(), so it could then work as a proper=20
> IOMMU_DOMAIN_DMA default domain, and we can lose the current=20
> ARM-specific identity domain bodges as well. I reckon the impact of that=
=20
> to core code shouldn't be much worse than the existing special-cases it=20
> would replace, while on the arch side it should effectively only really=20
> redistribute the current arm_setup_iommu_dma_ops() path, so functionally=
=20
> pretty low risk as well. It's just liable to be fiddly to do in=20
> manageable steps rather than one giant patch changing everything at once.=
..
>=20
> Cheers,
> Robin.
>=20

Thanks Robin! I'll take a look at both option 2 and the 'proper' option=20
and hopefully come back with some patches :)

Mikko