From nobody Tue Feb 10 23:54:20 2026 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 B8F062C375A for ; Tue, 10 Feb 2026 09:34:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770716061; cv=none; b=b5mbk55Hmx5UYtc0YgN+lphUtJNA0ZJ+d63cwCr1/dD6JMlsWuo3YgPgOx2EtgSCtBSXjGhfaz8WEpA2a2/nK6JareaBgo9+091ySYZZegnXMPCmjA6QYJkm/A1+OpuKbgxp4+5VowoDTFSi+M/zNRw329DtpO/XW45JgpkvTbY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770716061; c=relaxed/simple; bh=t6aeId4VlqwVEnnNXhldHydFj+OWu8AHl8fbLO1CrMU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=b++ZQzKxNfOUWQfz5ALWCPFOXGIOBwd+OrbzMYfHdh0O+PbSD/cKkd+vEuPEyAI3RhGkw1LWsXj0D3Jw6MZjboTIgutSQc1AR8F2fWdnmQZLC3CMxOUvHK4TTLzCBSKfAOwj3Ae8iQFU2XB7cwl1f4DtCt3M1nFl+pJr5t+KmBU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=alxKqsj5; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="alxKqsj5" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4806dffc64cso46481955e9.1 for ; Tue, 10 Feb 2026 01:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770716058; x=1771320858; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/4pWXM8MAKWeYJmoBAYToovJi1wgFNm1p75GzaAUFNs=; b=alxKqsj5gv4ZtyB9oAEoPV0rc6ubJ0xtM0d9ZIxsqOdwzzStUEDjvk5KrUci/At787 8ts906KygSSI/lSvhh8JWHUHZrvsQ580nFlsV5Q2wfLAadbHX6aMNAtu3HYSAxNboKrj LuQiClnhPhmJVGhcaawxtFilgMA1Y6MLpZzHgQULJQ0nhqwUeZ6ZGjXPQSgXqxn4QtuY RGcxsyYyrcQzPXGu9RLbsLEt2Kq22gmTQ51APtaZkHQXtTka9rfHBHoB/iYT6sjMAd2p vwvvHxn7mgqvHdJyyXIrigjAbWdm2o9605A9CKy2vHZ5Fsbxho7Wid/wLl8KNob6tDe6 8E4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770716058; x=1771320858; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/4pWXM8MAKWeYJmoBAYToovJi1wgFNm1p75GzaAUFNs=; b=jHm39dM4ggptmb5TozOR3wj0Pit+cCCArPTG/PuSsDG6g3JYk/wBzJySK5itR47T6k cFXhhknNqTXM/zeoUqz+I6sKhgnRTlt1VP8rmM/NmDX/riU5fVceCqRY7S9bJkYlaOXx P2XePEfKjuuECOLdb7kPLTQIcRw7qBR5AbBYQvCjAB9tgasB3zsJVJrGdzQc8mLyFGKv JFFcSmd6pvHIQ4MYidG1WIWa3FGVn/jCiBdPZKbQ9Dh3TlzALSULDSkYM54mbr9e6m45 D6lECxZzd/mdxEocahA4IqeTVadryAHenORcOIfXl2jnXuRyFPZ3+5l76Gp7FEFzGkur wsAQ== X-Forwarded-Encrypted: i=1; AJvYcCXiSGkDIPo7YBrB7xsdDrZucIFyt2pmOMIFPIHVZut0/qBU0txIBpBAhKH8KFIceiWKahX5askoiT8cX70=@vger.kernel.org X-Gm-Message-State: AOJu0YzDqBj03kvwc9isiUszDjJivekJt8DX9CnvFsroGIZd3Q9wF22E R0s89kCoFzoH0cfmWBcTrtJi1kXmEdZ/VD6E3sNENjZejJnGbfqg7baz X-Gm-Gg: AZuq6aLCQMPF3OKkJUl2ATKaOhZyMFkoQ9BJd6EiC1zYzUBOgUXhRU0GjZLP+MJs3Ml wjACqcKGHUq2iJZ6ttOqhXXI/KlnhsOgkHy7SIrZrUDI39pm7fDaQQHTwVuKZGX+FJMjUdfytNx Sm05kD/7eQPC4Q2XvV0CMb3aw09xOzCkcxYx4KNsQpON8xFvLJjp7teQrVxO4XKw5oSu0RL2N1j zA3wlweMeq4H2wCqLpGkhlbA5mhFRIClnR/TI0GjRBC1pDjUTvgRGksNNJ2bVfN1IWAmTfbD1Gu d0ocM6alBPZO7nRMYBh99Er+aZIWdeuUkGk+g2G4W36Ka0L3OIQPNUpSLAOzNycjArXssSwKzz9 W9MAWty72oGj6PHC5iYoTYIHLuxrrOVSJc56w95i8jnlxTrju4/syLOdskVSGgKJO1geNMruDc6 mf8Q0vfZTmKcv8n7IV84o= X-Received: by 2002:a05:600c:621a:b0:47d:92bb:2723 with SMTP id 5b1f17b1804b1-48320928d7cmr202536005e9.3.1770716057605; Tue, 10 Feb 2026 01:34:17 -0800 (PST) Received: from luca-vm.lan ([154.61.61.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4376a78d796sm16571660f8f.20.2026.02.10.01.34.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 01:34:17 -0800 (PST) From: Luca Leonardo Scorcia To: linux-mediatek@lists.infradead.org Cc: Luca Leonardo Scorcia , Chun-Kuang Hu , Philipp Zabel , David Airlie , Simona Vetter , Matthias Brugger , AngeloGioacchino Del Regno , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC] drm/mediatek: Remove all conflicting aperture devices during probe Date: Tue, 10 Feb 2026 08:39:43 +0000 Message-ID: <20260210093333.5112-1-l.scorcia@gmail.com> X-Mailer: git-send-email 2.43.0 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" If a device has a framebuffer available it might be already used as display by simple-framebuffer or simpledrm when mediatek-drm is probed. This is actually helpful when porting to a new device as framebuffers are simple to setup in device trees and fbcon can be used to monitor the kernel boot process. When drm-mediatek loads a new fb device is initialized, however fbcon remains attached to the initial framebuffer which is no longer connected to the actual display - the early fb is never removed. We can gracefully transition from framebuffer handling to drm-managed display by calling aperture_remove_all_conflicting_devices as we probe mediatek-drm. This takes care of unloading other fb devices/drivers and disconnects fbcon which then automatically reconnects to mediatekdrmfb as soon as it's available. Signed-off-by: Luca Leonardo Scorcia --- This patch has been tested on Xiaomi Mi Smart Clock, however I'd like to get some feedback from more knowledgeable people, especially about those points: 1. Is aperture support on mtk-drm desired at all? 2. mtk-drm does not know about the fb address therefore as far=20 as I can see we can't use the more specific function aperture_remove_conflicting_devices. This means that all generic aperture drivers will be unloaded. It might not be a real world issue=20 as I can't see why one might want to load mtk-drm while keeping=20 other aperture device drivers active, but my experience is very limited. Thanks! drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/media= tek/mtk_drm_drv.c index a94c51a83261..17e45b93fe49 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -4,6 +4,7 @@ * Author: YT SHEN */ =20 +#include #include #include #include @@ -1116,6 +1117,11 @@ static int mtk_drm_probe(struct platform_device *pde= v) if (!private->all_drm_private) return -ENOMEM; =20 + /* Remove framebuffer owners, this will release fbcon if active */ + ret =3D aperture_remove_all_conflicting_devices(DRIVER_NAME); + if (ret < 0) + dev_err(dev, "Failed to remove conflicting aperture devices (%d)", ret); + /* Bringup ovl_adaptor */ if (mtk_drm_find_mmsys_comp(private, DDP_COMPONENT_DRM_OVL_ADAPTOR)) { ovl_adaptor =3D platform_device_register_data(dev, "mediatek-disp-ovl-ad= aptor", --=20 2.43.0