From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 74D75FCC9AD for ; Tue, 10 Mar 2026 03:20:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CBC3610E62F; Tue, 10 Mar 2026 03:20:52 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="AWmFbjbU"; dkim-atps=neutral Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1A1B110E631 for ; Tue, 10 Mar 2026 03:20:52 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-3591cc98871so5542925a91.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=lists.freedesktop.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=AWmFbjbU4wqQPLN8oh+qzycw9WvalT4c9RZxtOryapMOSp1K4G83ut/W7KRwsFP42Q TJwMAbcQBAtvGFkXaoMUSGPXb53BuC/CF0GmRnmb+6KIN6TxCwIf76bHawG6f11c0tbm ZgIPXvcdGWgPTIxG35o1aJKLvwtt3ESefab1c= 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=koCcN13gAQ72TrDp2uFPQuaRJab2XEH8Nk6bg6PMo7iC277VGHsarkuvuGNnIa5FsJ 3PCBCywo14Lrzbx/GzukhqaygQWlOnNQTQV8A9C5VjLs7MiO/FMyAXx9LgC9Y3QM1PHb PE7NoiWJfdww9y1zsyhc1z+q7l98d6hN6Zr8d7HHHZIbLiozvOuXsW6wPdmGEA/C6SZM uUFu5j8vQeGU7XlC6AYKqPrDbmYcacMQG7Ba74VpL+oDSxYteiBuGL4Al4BstFuHw35J C638sZfGY58sMeG2Sx2xZGZYF5xRd/U9f/IiV1CJ9QdXNh7bjMTTx4aEZch36tM0C/qg RCXA== X-Forwarded-Encrypted: i=1; AJvYcCVTBnWOLmxOMF1s4fp83npt9CSS8SuVLYgD+BtJc57iWGBgHB/GIx3gg27qPDy7o2skHWmAnuYp76U=@lists.freedesktop.org X-Gm-Message-State: AOJu0YzhLrQf1vi6LpPHFFxtgIETrky4PETsURLCl9y9zBq0cR68tzE9 vknWwYiIMhvqAiAMGlAQwpJCLIRH+nfX+AKty/P5sOD9mUWwF5IOCa6/vdVDgIRdj6H54eHLvOE 06rQ= X-Gm-Gg: ATEYQzwrFkzqsKEVBAqTN8UUUfYCt/BWsC5vxqH/IEEyMbWl6lN1KwVQcPVVbFstVn1 HnDlbZVyrIeY6FiNYF6SjXWPYdd/017LC1R0X5iW8RScx1boD5JgAl0YU+S+KybIvQD/H6hdLkQ Cv5RUOXmRCzJzkdpWyKY56Sm+ziBqrpoxoQHJBMiRg06GhijaxG1YXsRtyWDmvBybNOUjKh7yeS KETYfJgy/QMjjZ7vkoOOepGaWobzlfma6HJlHIm2baN/Lxlvoj/AOjCScU5gTiC+7wNdCSV7TRe L+qJRmgno++jJdFaYRyxMO4p6FYva2o8yvlERa2SZ6HdeOEGgBaYRXRKuWTJvUFWoRC9kJkuJd0 Mx8WHzWSN59Dzi+CczBoxR4jFfvTD2nmnVdar8I3N4yV+SwGpYmZ4jqXDiMJTpgYkebqWzodoHp xDXCdyURtMrdRv73T0T4omHTkHfPB/9Zd+MWxbmquzB7cLTWYswxwfzwbluKx003hdMTc4w9aLB 4ob2zyM 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@freedesktop.org, "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> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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, 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