From nobody Thu Apr 9 09:40:38 2026 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 340F6399007 for ; Tue, 10 Mar 2026 03:20:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773112853; cv=none; b=uiLE2h5Jkce74xREGmJusIR57SxvBsR3+Zu99LN9A+6wKgkNSwNXwjLMeqobqgUVVTa6HIKgUfjiH+u2UXH0S1tHtCGt6XdQEkLLxog2q45iflkdG/IEdr+yMQwaJvBRlVfdBDemCjA0PJuFqeBbnqCARZcrOxn9Z+EklyELNKE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773112853; c=relaxed/simple; bh=rfD7Le/WZjv74zhcuW0yU+5NJ1RZ3lo7zccKLiSyBcI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VeGaYRfK43++/A7g2N0az9B3megjvEguGdZp3ZPYpPvVM8z+oEu+i5/z19cj7VvC8ov/7c/b6edcqpS1XBgxEZn1bHb2857hIUEcz3CAt3sH72P4DCAjPnOIho1MrMtiD9HirpqOvR0xDqM8wZtH6JehGqZwUlANShB/TKRUGtE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=bw0BvINm; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="bw0BvINm" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-3591cc98871so5542922a91.3 for ; Mon, 09 Mar 2026 20:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1773112851; x=1773717651; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Y1z9EtizHwE3LeSySxAXfxT/FNlt1Ydhsh1vDf6WdY0=; b=bw0BvINmRxUqKvFZxxABPzg8mHt1G3Hl54uOs8mWxf1W9ELzRmb7M4oSnParm7TKfQ 4mgwmHC2A8jE32JsTQAjQiV68I7uaQB6nydSEhgcjgqn+eze9L9HgwPQ3/qpVP9Hyzd7 ymacR4bIegBhmNLKWNA1sHduqmOItAZB8RMY0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773112851; x=1773717651; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Y1z9EtizHwE3LeSySxAXfxT/FNlt1Ydhsh1vDf6WdY0=; b=wI0QQ2mOXmVDa1j6/VFV1JPzLUY2DmNzzt2waZ2f7NOXr32QszjAi9dKe3o2fSa5hH kkRs7rd69R1zRVeEc3iqyylnVwmlMYFq09M3b4ldu1qO0Uz0Hi2t1FY2kYgNfDEHk/p7 eqwu0q1xFh5QQVGleNn4TqLd/XzL3LG28j0Gh7TVZlMc8PLDn7YBMN5Pea4rudhtTGvg VLbj3L8npALW7r8q7JAXPzDFmtj/X4QjCr3US+1ND/p2ZDyrTY2H9CBq3xBxBQEx74Vb AgvzsJFKpEL4D42zOcC5K1fx5mdX03uHlpV4eXRGMffjxH7rVegWtm6VkZqiHmZR/pTT NIUw== X-Forwarded-Encrypted: i=1; AJvYcCXidFb5aloAE0Aih4AWtM9JqphidWX8scdjFGTOsKMCeXHtm4TtHUgx6hMW+2mvziNiHLjlpba3aWOaDfc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw9riLoXBwUrvm9ekKKoNkyoe1spVXk7GP9Arz0X8TIZmpAuTm6 zQWztYYDvYn7+HLqwwLCljvIX6v+I1w3t297Swb4sfJYCzkbeNlgXInH31ZadGZOow== X-Gm-Gg: ATEYQzwGD61xUAcLpLlLsuZ4CLUkytPb999MZTWaK0gcB32QjH9sy8M9LwSe00lAkxx pZ6s6Gmldvxo5KBFfj5ns3YxUxE8Hui/Xd/by/ox08se9w9SzvzCd2mrTN7fWAJhAGOo4FTfJ0K KNSkMTnpflnjIf4Ji2/NcqQMru9YxtByYZ5d1qX1dt6IaICktCeYxhVEoGiGB/GnxiC48E40Oq0 Q1sqPIQ6JLqd3ei7QQy9jIlDoPFPg3oTvUZMM3z60cX2D4ovlneEjY76aSDujAGzeZ4wpLkVtD3 7s9H6hrNMJ3LeOKsTUmu0a4bzkOOiK0TxdDbHaSARTbTF7DiI8DZUpjcJS9J9tUFXOhtVZN9twp glgXGYOVxg/ijGHXrGiaBpadrJiynFsmGPnCL91a4EzE+THm8Cz8hDDY1sPX5tlCn8RwAQtk8Ku F9M7nrWrhPdLr/8vk8WaSDugF1Tdz240Z/C/ylpeBA+Bo3mNNT3mD9MEOYxyq0Fp4M9hO0Ev6hc pb5SOuw X-Received: by 2002:a17:90b:554f:b0:359:7b9a:2cec with SMTP id 98e67ed59e1d1-359be133b2fmr12308150a91.0.1773112851595; Mon, 09 Mar 2026 20:20:51 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2a00:79e0:201d:8:ee38:e01e:e888:6900]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359f06f79absm1154608a91.6.2026.03.09.20.20.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 20:20:51 -0700 (PDT) From: Chen-Yu Tsai To: Matthias Brugger , AngeloGioacchino Del Regno , Chun-Kuang Hu , Philipp Zabel , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Simona Vetter Cc: Chen-Yu Tsai , linux-sunxi@lists.linux.dev, Paul Kocialkowski , 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 Message-ID: <20260310032012.2542334-5-wenst@chromium.org> X-Mailer: git-send-email 2.53.0.473.g4a7958ca14-goog In-Reply-To: <20260310032012.2542334-1-wenst@chromium.org> References: <20260310032012.2542334-1-wenst@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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, str= uct device *master, dev_set_drvdata(dev, backend); spin_lock_init(&backend->frontend_lock); =20 - 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 =3D 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) =3D=3D drm->dev) + drm_dev_set_dma_dev(drm, dev); =20 backend->engine.node =3D dev->of_node; backend->engine.ops =3D &sun4i_backend_engine_ops; diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/su= n8i_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, struc= t device *master, mixer->engine.ops =3D &sun8i_engine_ops; mixer->engine.node =3D dev->of_node; =20 - 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 =3D 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) =3D=3D drm->dev) + drm_dev_set_dma_dev(drm, dev); =20 /* * While this function can fail, we shouldn't do anything --=20 2.53.0.473.g4a7958ca14-goog