From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Mikko Perttunen <mperttunen@nvidia.com>,
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>
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
Subject: Re: [PATCH v3 00/10] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC)
Date: Fri, 30 Oct 2026 11:36:52 +0100 [thread overview]
Message-ID: <6fb3327c-766c-433c-b49d-dc62470d7102@samsung.com> (raw)
In-Reply-To: <20261026-b4-arm32-iommu-dma-cookie-v3-0-3901d74b1ff2@nvidia.com>
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.
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-10-30 10:36 UTC|newest]
Thread overview: 14+ 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 [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=6fb3327c-766c-433c-b49d-dc62470d7102@samsung.com \
--to=m.szyprowski@samsung.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=matthias.bgg@gmail.com \
--cc=mperttunen@nvidia.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®