From: Mikko Perttunen <mperttunen@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Heiko Stuebner <heiko@sntech.de>,
Thierry Reding <thierry.reding@kernel.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Jonathan Hunter <jonathanh@nvidia.com>,
Krishna Reddy <vdumpa@nvidia.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-tegra@vger.kernel.org
Cc: Peter Griffin <peter.griffin@linaro.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Yong Wu <yong.wu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v3 00/10] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC)
Date: Mon, 02 Nov 2026 17:33:09 +0900 [thread overview]
Message-ID: <8hhoVlFLRDu49GHajB8t6A@nvidia.com> (raw)
In-Reply-To: <6fb3327c-766c-433c-b49d-dc62470d7102@samsung.com>
On Friday, October 30, 2026 7:36 PM Marek Szyprowski wrote:
> On 26.10.2026 10:19, 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.
> >
> > 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 mapping alloc and init (bitmap alloc) code to separate
> > functions.
> > 4. Implement parallel dma_ops / cookie APIs on ARM side.
> > 5. Avoid domain allocation when IOMMU core does it.
> > 6. Check upper DMA range limit during IOVA allocation.
> > - Patch 7 removes the forced IDENTITY default domain in core IOMMU
> > code and adds explicit IDENTITY defaults to a few individual IOMMU
> > drivers.
> > - Patches 8-10 convert Tegra:
> > 8. Fixes device parameter in calls to dma_get_sgtable.
> > 9. Allows deferring translation enable until driver handshake for
> > selected devices.
> > 10. Switches to DMA default domain for selected Tegra devices.
> >
> > This moves 32-bit ARM devices from the unmanaged IOMMU DMA domain to the
> > core-owned default DMA domain except for mtk_iommu_v1, ipmmu-vmsa,
> > omap-iommu, and msm_iommu. (tegra-smmu also stays on the legacy path
> > until the last patch in the series.) See commit 7 for further
> > information. Existing drivers are intended to continue working without
> > changes.
> >
> > Patches 8-10 are provided for demonstration; we can deal with them
> > separately if the rest of the series is accepted.
> >
> > Patches 1,2,3,6 are applicable independently.
> > Patches 4,5 depend on the previous patches.
> > Patch 7 requires the prior patches to be in place.
> >
> > Patches 1-7 only touch drivers/iommu/ and arch/arm/mm/ and associated
> > headers.
>
>
> I've tested this patchset on ARM 32bit based Exynos boards and it works
> fine, although I get the following warnings during boot:
>
> platform 13400000.codec: Adding to iommu group 0
> iommu: Failed to allocate default IOMMU domain of type 0 for group (null) - Falling back to IOMMU_DOMAIN_DMA
> platform 11840000.jpeg-codec: Adding to iommu group 1
> iommu: Failed to allocate default IOMMU domain of type 0 for group (null) - Falling back to IOMMU_DOMAIN_DMA
>
> This looks like an issue in iommu core, which doesn't expect devices with
> iommu to come up so early.
Excellent, thanks for testing. I'll take a look at the warnings.
Mikko
>
>
> LLM proposes the following fix for it:
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 197a8f70c6de..612933306684 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -225,10 +225,8 @@ static const char *iommu_domain_type_str(unsigned int t)
> }
> }
>
> -static int __init iommu_subsys_init(void)
> +static void __init iommu_init_def_domain_type(void)
> {
> - struct notifier_block *nb;
> -
> if (!(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API)) {
> if (IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH))
> iommu_set_default_passthrough(false);
> @@ -254,6 +252,11 @@ static int __init iommu_subsys_init(void)
> iommu_dma_strict ? "strict" : "lazy",
> (iommu_cmd_line & IOMMU_CMD_LINE_STRICT) ?
> " (set via kernel command line)" : "");
> +}
> +
> +static int __init iommu_subsys_init(void)
> +{
> + struct notifier_block *nb;
>
> nb = kzalloc_objs(*nb, ARRAY_SIZE(iommu_buses));
> if (!nb)
> @@ -2939,6 +2942,12 @@ EXPORT_SYMBOL_GPL(report_iommu_fault);
>
> static int __init iommu_init(void)
> {
> + /*
> + * Select the default domain type before any IOMMU driver can register
> + * and create groups, which may happen before subsys_initcall.
> + */
> + iommu_init_def_domain_type();
> +
> iommu_group_kset = kset_create_and_add("iommu_groups",
> NULL, kernel_kobj);
> BUG_ON(!iommu_group_kset);
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
prev parent reply other threads:[~2026-11-02 8:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261026092047eucas1p2686ac1a0ce893a16711cf7a137d081ce@eucas1p2.samsung.com>
2026-10-26 9:19 ` Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 01/10] iommu: Add iommu_teardown_dma_ops Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 02/10] iommu: Add cookie type for ARM_DMA_USE_IOMMU Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 03/10] ARM: dma-mapping: Split mapping initialization from allocation Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 04/10] ARM: dma-mapping: Implement and expose DMA setup functions Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 05/10] ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 06/10] ARM: dma-mapping: Bound IOVA allocation by device DMA limits Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 07/10] iommu: Enable DMA default domains on (most) 32-bit ARM platforms Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 08/10] drm/tegra: Fix device parameter to dma_get_sgtable Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 09/10] iommu/tegra-smmu: Defer display client translation to driver handover Mikko Perttunen
2026-10-26 9:19 ` [PATCH v3 10/10] iommu/tegra-smmu: Use a DMA API default domain per swgroup Mikko Perttunen
2026-10-29 12:03 ` [PATCH v3 00/10] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC) Christoph Hellwig
2026-10-30 2:37 ` Mikko Perttunen
2026-10-30 10:36 ` Marek Szyprowski
2026-11-02 8:33 ` Mikko Perttunen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8hhoVlFLRDu49GHajB8t6A@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=airlied@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert+renesas@glider.be \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux.dev \
--cc=jernej.skrabec@gmail.com \
--cc=jgg@ziepe.ca \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=matthias.bgg@gmail.com \
--cc=peter.griffin@linaro.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=samuel@sholland.org \
--cc=simona@ffwll.ch \
--cc=thierry.reding@kernel.org \
--cc=vdumpa@nvidia.com \
--cc=wens@kernel.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®