From nobody Tue Apr 7 23:42:42 2026 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 AD2E33BC67B for ; Wed, 11 Mar 2026 09:50:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773222613; cv=none; b=hkaYydS0DfXdvuhfToQjG+/IBfh3gF8osMRlJmef3JTMY2LGQ10idRhXrfsjJeVtgzYXAHOfnuLYSYJRVtPLKBF1oQrrkSOGSrZTHateL+GkKq+gbBglwiQNU7axeo3DbhLylBIiblQXIdIIH94m57npRcoeYwAwV67GqK8QR28= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773222613; c=relaxed/simple; bh=rfD7Le/WZjv74zhcuW0yU+5NJ1RZ3lo7zccKLiSyBcI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=khWSdiypJ5Aa4h7D76Uip9uV9CWMiGe0LuaQwvs7z+8XlvyZjchoZv/mlGkurjJ8J0pU6bO2UcJvYe1o+Ixm4Otdf8lONY0Z2sIsV8npd2uD6S2O/muENavM5jZwr2gh284WvEOUZmEgMisUrfE7rtHgfzsb81cElcn11pTy78I= 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=AxZU6EKK; arc=none smtp.client-ip=209.85.210.181 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="AxZU6EKK" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-8297310ce0aso4406076b3a.2 for ; Wed, 11 Mar 2026 02:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1773222610; x=1773827410; 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=AxZU6EKKoLLjneEjhFp6an/u+gvGCv4X2VafP4f//FEgM5e8fPsYzUaCjJIwLMz/jR eK53nEENq+6Lz5piEbxrCFWcKYkx5lC6fSnzphDbKMe5q2j2nxvCLkHEBYio3KwZuq8r FiAy+HNF77B13icvk7Um0YitiVqzUZSk4wma0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773222610; x=1773827410; 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=vlu8stqlWuOfSklsbWJ1TJE0h/SlVHoT3oMyezIYFUheT+cI90hYxHvN7IYDMaxWrI gQmFXTW0affS9X7oaOQofUgczTyOeV7uV8XZ7drX0pvcguiR7VtJbrw0hHsRWmmD2Z5F 2JeltFvPHsOTK9D+7aKa9dllhDjxLNu1F3aWGeCumXt+ZXU8SqU+e5speVaJ68wQ9iZx hsk4oAm8PrCr9Q3qPMGJIXegdUy2nyamgx+PCu6U9NSfhu/xdLlqQH/rLMJxTJEOm8WZ qDHvWGJ9g4FFg294LOQIjUyER2I3DtszVwYcGaf3TK0qXPMRwgQfuKWZG+l8kD1eHudh S4yQ== X-Forwarded-Encrypted: i=1; AJvYcCUk05vlJxqZEL51sNDTDDALCq3jEw8/7oxhpTCAre6h5MI6ZYeJA5qe5U+Zv8pchOa6zWe20Kp7TRCIJdM=@vger.kernel.org X-Gm-Message-State: AOJu0YyKyxYz/q0cDacfqzA2PE/voxOniGcGmIFvwtgzl2oseYJeNPtp pSEqD97Sc17XRClYCWERTJ1Ahejh9M159WBDz5vuZbYhJo6eo1ryjTAgDfOGmjMs9Q== X-Gm-Gg: ATEYQzw8jUAyYjZYrdbHIrg4F2NF2YWwMED9fBGQloGu1tlJ1EfWz9eOqwnnMvLmg7t 8Cu4d8yNJbt+g9nGvCvggO71ce0Ye7EdHI014A6nSatLAtFLlZUMv+n/YMLk1NdnyAWbtAQY7ZP 14JdyQ9azNJ7TkEOQb1028NHcuAOgTtDtnTQviP3WsB74ODUdEtqr2ul72haiPejNOSm65Y6qe8 rgNrOlPULS/mWTPLp+C5lUMhI8a+Gcg7g84Op/y9k1rNintvj5i70t8XzJQkQ13NtlayZ1hkZ7O 3l1UqoB9KIRTxKoJYUaY9pfaKAbjXifaj1QUeX0ChAdwaMk24Ijr1K8YAbp494vhnc61beSaefo zN7wMee1tsYJueMyZQfVV6/XxFJcG9XnIfqIgGSO+SxVerslAWf4Q4b9Y01D9wpL4FoFZhG+rqq 7xjDTfVmgkOgrtqAdTraEDbaM6He+leBo7vQvHU58kzz1voCGivnPdITAyiyjWBjRarVZ3E4hZ2 I0YOzpD X-Received: by 2002:a05:6a00:950c:b0:829:6f28:1d6 with SMTP id d2e1a72fcca58-829f6e7b408mr1826676b3a.13.1773222610050; Wed, 11 Mar 2026 02:50:10 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2a00:79e0:201d:8:805b:14e9:f783:bcae]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829f6e22f85sm1887598b3a.27.2026.03.11.02.50.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 02:50:09 -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 , David Airlie , 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 v2 4/4] drm/sun4i: Use backend/mixer as dedicated DMA device Date: Wed, 11 Mar 2026 17:49:28 +0800 Message-ID: <20260311094929.3393338-5-wenst@chromium.org> X-Mailer: git-send-email 2.53.0.473.g4a7958ca14-goog In-Reply-To: <20260311094929.3393338-1-wenst@chromium.org> References: <20260311094929.3393338-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 Acked-by: Jernej Skrabec --- 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