From: Chen-Yu Tsai <wenst@chromium.org>
To: Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej@kernel.org>,
Samuel@freedesktop.org, "Holland <samuel"@sholland.or,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>
Cc: Chen-Yu Tsai <wenst@chromium.org>,
linux-sunxi@lists.linux.dev,
Paul Kocialkowski <paulk@sys-base.io>,
linux-mediatek@lists.infradead.org,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 4/4] drm/sun4i: Use backend/mixer as dedicated DMA device
Date: Tue, 10 Mar 2026 11:20:07 +0800 [thread overview]
Message-ID: <20260310032012.2542334-5-wenst@chromium.org> (raw)
In-Reply-To: <20260310032012.2542334-1-wenst@chromium.org>
The sun4i DRM driver deals with DMA constraints in a peculiar way.
Instead of using the actual DMA device in various helpers, it justs
reconfigures the DMA constraints of the virtual display device using
the DMA device's device tree node by calling of_dma_configure().
Turns out of_dma_configure() should only be called from bus code.
Lately this also triggers a big warning through of_iommu_configure()
and ultimately __iommu_probe_device():
late IOMMU probe at driver bind, something fishy here!
Now that the GEM DMA helpers have proper support for allocating
and mapping buffers with a dedicated DMA device, switch over to
it as the proper solution.
The mixer change was tested on a Pine H64 model B. The backend change
was only compile tested. Though I don't expect any issues, help testing
on an older device would be appreciated.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 27 +++++++++++++++------------
drivers/gpu/drm/sun4i/sun8i_mixer.c | 27 +++++++++++++++------------
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 6391bdc94a5c..a57fb5151def 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -798,18 +798,21 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
dev_set_drvdata(dev, backend);
spin_lock_init(&backend->frontend_lock);
- if (of_property_present(dev->of_node, "interconnects")) {
- /*
- * This assume we have the same DMA constraints for all our the
- * devices in our pipeline (all the backends, but also the
- * frontends). This sounds bad, but it has always been the case
- * for us, and DRM doesn't do per-device allocation either, so
- * we would need to fix DRM first...
- */
- ret = of_dma_configure(drm->dev, dev->of_node, true);
- if (ret)
- return ret;
- }
+ /*
+ * This assume we have the same DMA constraints for all our the
+ * devices in our pipeline (all the backends, but also the
+ * frontends). This sounds bad, but it has always been the case
+ * for us, and DRM doesn't do per-device allocation either, so
+ * we would need to fix DRM first...
+ *
+ * Always use the first bound backend as the DMA device. While
+ * our device trees always have all backends enabled, some in
+ * the wild may actually have the first one disabled. If both
+ * are enabled, the order in which they are bound is guaranteed
+ * since the driver adds components in order.
+ */
+ if (drm_dev_dma_dev(drm) == drm->dev)
+ drm_dev_set_dma_dev(drm, dev);
backend->engine.node = dev->of_node;
backend->engine.ops = &sun4i_backend_engine_ops;
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 02acc7cbdb97..4071ab38b4ae 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -536,18 +536,21 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master,
mixer->engine.ops = &sun8i_engine_ops;
mixer->engine.node = dev->of_node;
- if (of_property_present(dev->of_node, "iommus")) {
- /*
- * This assume we have the same DMA constraints for
- * all our the mixers in our pipeline. This sounds
- * bad, but it has always been the case for us, and
- * DRM doesn't do per-device allocation either, so we
- * would need to fix DRM first...
- */
- ret = of_dma_configure(drm->dev, dev->of_node, true);
- if (ret)
- return ret;
- }
+ /*
+ * This assume we have the same DMA constraints for all our the
+ * devices in our pipeline (all the backends, but also the
+ * frontends). This sounds bad, but it has always been the case
+ * for us, and DRM doesn't do per-device allocation either, so
+ * we would need to fix DRM first...
+ *
+ * Always use the first bound backend as the DMA device. While
+ * our device trees always have all backends enabled, some in
+ * the wild may actually have the first one disabled. If both
+ * are enabled, the order in which they are bound is guaranteed
+ * since the driver adds components in order.
+ */
+ if (drm_dev_dma_dev(drm) == drm->dev)
+ drm_dev_set_dma_dev(drm, dev);
/*
* While this function can fail, we shouldn't do anything
--
2.53.0.473.g4a7958ca14-goog
next prev parent reply other threads:[~2026-03-10 3:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 3:20 [PATCH 0/4] drm/gem-dma: Support dedicated DMA device for allocation Chen-Yu Tsai
2026-03-10 3:20 ` [PATCH 1/4] drm/prime: Limit scatter list size with dedicated DMA device Chen-Yu Tsai
2026-03-11 3:48 ` Claude review: " Claude Code Review Bot
2026-03-10 3:20 ` [PATCH 2/4] drm/gem-dma: Support dedicated DMA device for allocation and mapping Chen-Yu Tsai
2026-03-11 3:48 ` Claude review: " Claude Code Review Bot
2026-03-10 3:20 ` [PATCH 3/4] drm/mediatek: Set dedicated DMA device and drop custom GEM callbacks Chen-Yu Tsai
2026-03-11 3:48 ` Claude review: " Claude Code Review Bot
2026-03-10 3:20 ` Chen-Yu Tsai [this message]
2026-03-11 3:48 ` Claude review: drm/sun4i: Use backend/mixer as dedicated DMA device Claude Code Review Bot
2026-03-11 3:48 ` Claude review: drm/gem-dma: Support dedicated DMA device for allocation Claude Code Review Bot
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=20260310032012.2542334-5-wenst@chromium.org \
--to=wenst@chromium.org \
--cc=Samuel@freedesktop.org \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=paulk@sys-base.io \
--cc=samuel"@sholland.or \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=wens@kernel.org \
/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