Re: [PATCH 00/11] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC)

[Mikko Perttunen <mperttunen@nvidia.com>]

On Saturday, September 26, 2026 12:20 AM Marek Szyprowski wrote:
> On 15.09.2026 04:14, Mikko Perttunen wrote:
> > Depending on the probe ordering, TegraDRM does not currently probe on 
> > kernels with CONFIG_ARM_DMA_USE_IOMMU enabled, such as with 
> > multi_v7_defconfig. The Tegra SMMU puts several display and 2D/3D 
> > clients into one IOMMU group, and the legacy 32-bit ARM DMA API path 
> > creates one UNMANAGED domain per device and attaches it with 
> > iommu_attach_device(). That only works for one device per group, so 
> > every client after the first fails to attach, 
> > iommu_device_use_default_domain() rejects the group with -EBUSY, and the 
> > driver goes down with it. tegra_defconfig is currently working by virtue 
> > of not enabling CONFIG_ARM_DMA_USE_IOMMU.
> >
> > Robin suggested [1] that instead of teaching the legacy path about 
> > groups, we should explore modernizing the 32-bit ARM DMA code a bit by 
> > making it use domain cookies and have the core code own the domains, as 
> > is the case on other architectures. Still, ARM's own DMA code is kept to 
> > support existing drivers and APIs that expect it, and because dma-iommu 
> > is considered too big and unnecessary for 32-bit ARM.
> 
> 
> I agree that such little modernization is the right step to unify a bit
> ARM 32bit with modern archs and get rid of some workaround in the drivers.

Yes -- certainly TegraDRM's memory management paths have grown to be 
rather cumbersome.

> 
> It was me who raised the concern about the drivers depending on the first-fit
> allocation algorithm used in the32-bit ARM DMA code. This is an issue for some
> legacy Samsung Exynos drivers. I not aware of any other driver used on ARM 32bit
> SoCs that depends on this behavior.
> 
> If one is still interested in switching ARM 32bit to generic IOMMU-DMA code I
> can prepare a workaround for those Exynos drivers. I still have it on my todo
> list, but in meantime there was no interest in updating ARM 32bit DMA code.
> 

While I don't see any immediate need to touch the allocation algorithm, 
being able to get rid of some or all of the arm_iommu_* functions would 
be nice. At least for create/attach, there aren't very many callers. 
Most drivers just get rid of the ARM mapping.

Thank you!
Mikko

> 
> > The series is in four parts:
> >
> > - Patches 1-2 are preparation in the IOMMU core:
> >   1. Add iommu_teardown_dma_ops, counterpart to iommu_setup_dma_ops.
> >   2. Add cookie type for ARM's DMA domains.
> > - Patches 3-6 implement the DMA API side on 32-bit ARM:
> >   3. Split up domain and address space management code in arch/arm/.
> >   4. Implement parallel dma_ops / cookie APIs on ARM side.
> >   5. Avoid domain allocation when IOMMU core does it.
> >   6. Support foreign-allocated sg_tables.
> > - Patch 7 enables 32-bit ARM IOMMU drivers to provide a DMA default 
> >   domain.
> > - Patches 8-11 convert Tegra:
> >   8. Allows deferring translation enable until driver handshake for
> >      selected devices.
> >   9-10. Removes code detaching ARM UNMANAGED DMA domains in
> >         Host1x/TegraDRM.
> >   11. Enables DMA default domain for selected Tegra devices.
> >
> > None of this should have any functional effect on any device other than 
> > the Tegra devices enabled in patches 8-11. Other IOMMU drivers can opt 
> > in later. The new DMA default domains are enabled only when the IOMMU 
> > driver explicitly specifies a DMA domain type, just returning 0 for the 
> > default is not enough (unlike on arm64), keeping the current behavior.
> >
> > Patches 8-11 are provided for demonstration but we can deal with them 
> > separately if the rest of the series is accepted.
> >
> > Patches 1,2,3 are applicable independently.
> > Patches 4,5 depend on the previous patches.
> > Patch 6 can be applied independently but is only required once
> >   the whole series lands (by TegraDRM).
> > Patch 7 depends on patch 4.
> >
> > Patches 1-7 only touch drivers/iommu/ and arch/arm/mm/ and associated 
> > headers.
> >
> > Best regards,
> > Mikko
> >
> > [1] https://lore.kernel.org/linux-tegra/910d1492-ad3b-4201-93c6-208be1dcde7d@arm.com/
> >
> > ---
> > Mikko Perttunen (11):
> >       iommu: Add iommu_teardown_dma_ops
> >       iommu: Add cookie type for ARM_DMA_USE_IOMMU
> >       ARM: dma-mapping: Split mapping allocation from domain allocation
> >       ARM: dma-mapping: Implement and expose DMA setup functions
> >       ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains
> >       ARM: dma-mapping: Handle foreign buffers in arm_iommu_get_sgtable
> >       iommu: Let 32-bit ARM drivers opt into a DMA API default domain
> >       iommu/tegra-smmu: Defer display client translation to driver handover
> >       gpu: host1x: Drop release of legacy 32-bit ARM DMA domain
> >       drm/tegra: Drop release of legacy 32-bit ARM DMA domain
> >       iommu/tegra-smmu: Use a DMA API default domain per swgroup
> >
> >  arch/arm/include/asm/dma-iommu.h |  17 ++++
> >  arch/arm/mm/dma-mapping.c        | 209 ++++++++++++++++++++++++++++++++-------
> >  drivers/gpu/drm/tegra/dc.c       |   8 ++
> >  drivers/gpu/drm/tegra/drm.c      |  15 ---
> >  drivers/gpu/host1x/dev.c         |  15 ---
> >  drivers/iommu/Kconfig            |   1 +
> >  drivers/iommu/dma-iommu.c        |   5 +
> >  drivers/iommu/dma-iommu.h        |  52 +++++++---
> >  drivers/iommu/iommu.c            |  24 ++---
> >  drivers/iommu/tegra-smmu.c       | 109 +++++++++++++++++++-
> >  drivers/memory/tegra/tegra114.c  |  15 ++-
> >  drivers/memory/tegra/tegra124.c  |  12 ++-
> >  drivers/memory/tegra/tegra210.c  |   6 +-
> >  drivers/memory/tegra/tegra30.c   |  18 ++--
> >  include/linux/iommu.h            |   3 +
> >  include/soc/tegra/mc.h           |  20 ++++
> >  16 files changed, 410 insertions(+), 119 deletions(-)
> > ---
> > base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff
> > change-id: 20260728-b4-arm32-iommu-dma-cookie-3170e07f9125
> >
> >
> Best regards
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
> 
>