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

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

[Mikko Perttunen]

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.

Thank you
Mikko

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

[Robin Murphy]

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.

Re: 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