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

[Robin Murphy <robin.murphy@arm.com>]

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.