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

[Mikko Perttunen]

On Monday, July 27, 2026 11:51 PM Robin Murphy wrote:
> On 24/07/2026 8:35 am, Mikko Perttunen wrote:
> > Greetings everyone.
> > 
> > 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.
> > 
> > I traced the issue to the following sequence of events:
> > 
> > 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 run
> >     on TegraDRM devices.
> > 
> > 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, depending
> >     on probe deferrals, the group may have only the currently probing
> >     device, or a previously deferred device and the new device.
> > 
> >     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.
> > 
> > 3. iommu_device_use_default_domain gets called and succeeds on the first
> >     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 !=
> >     default_domain check evaluates to true.
> > 
> > 4. Devices fail to probe which leads TegraDRM overall not to probe.
> > 
> > I've thought of the following options to fix this:
> > 
> > 1. Match behavior with tegra_defconfig: Figure out a way to not run
> >     arm_setup_iommu_dma_ops for this situation (ideally any multi-device
> >     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 TegraDRM,
> >     so this is not a particularly satisfying route.
> > 
> > 2. Improve the legacy path: Fix the ARM IOMMU DMA code to support
> >     groups, and add an exception in iommu_device_use_default_domain. But
> >     I presume we don't want such non-trivial modifications to that code
> >     at this point.
> > 
> > 3. Modernize: Support CONFIG_IOMMU_DMA on ARM -- since there is an issue
> >     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 and
> >     CONFIG_ARM_DMA_USE_IOMMU are mutually exclusive so that has to be
> >     changed.
> > 
> > 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 the
> > display driver has quiesced the hardware and can then call into
> > tegra-smmu to enable translation.
> > 
> > Please let me know what you think and whom I missed in the To/Cc fields.
> 
> TBH I rather feel like the time for converting ARM to iommu-dma has 
> passed - there are drivers which rely on specific behaviours of the ARM 
> IOVA allocator which iommu-dma does not match, and meanwhile iommu-dma 
> continues to grow more server-specific features which would be nothing 
> but bloat on ARMv7 systems with <=2GB of RAM and no virtualisation. At 
> this point I'm inclined to treat the existing DMA ops as legacy code 
> like with alpha/sparc/etc.
> 
> While there is technically an option 4, to have tegra-smmu do what 
> ipmmu-vmsa and mtk_iommu_v1 do and go coercing the ARM dma_iommu_mapping 
> into groups behind the arch code's back, I am also still hoping to get 
> rid of that and the messy probe_finalize step altogether. FWIW my 
> preference would be some form of option 2 - off-hand I imagine you could 
> probably get most of the way there by propagating the ARM mapping 
> through group->iommudata (ironically tegra-smmu being the only driver in 
> the way of that - looks like it could probably do its internal group 
> accounting explicitly in release_device instead), plus one or two 
> special cases to recognise ARM DMA domains in the core code as you say. 
> The more involved, but ultimately neater, option would be to turn the 
> ARM mapping inside-out and make it a proper domain cookie type with the 
> ARM code providing its own definitions of iommu_{get,put}_dma_cookie() 
> and iommu_setup_dma_ops(), so it could then work as a proper 
> IOMMU_DOMAIN_DMA default domain, and we can lose the current 
> ARM-specific identity domain bodges as well. I reckon the impact of that 
> to core code shouldn't be much worse than the existing special-cases it 
> would replace, while on the arch side it should effectively only really 
> redistribute the current arm_setup_iommu_dma_ops() path, so functionally 
> pretty low risk as well. It's just liable to be fiddly to do in 
> manageable steps rather than one giant patch changing everything at once...
> 
> Cheers,
> Robin.
> 

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

Mikko