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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C8B78FF886D for ; Tue, 28 Apr 2026 14:11:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:MIME-Version: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Date:Cc:To:From :Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XwiqsOpR23ShlfylRkZ2Fb1ig1xeGogp5lQf7doEuds=; b=XvXuQsSiDWKRJjI5tpB0pOL0jQ fNWTdgUgSqYV+XENWGtp9VmbN+vcmFdyTGuXsZhuG8AbIkIikPAqnhb3fUJ95+fZRbS5ZAFlg8NGu CL0DisrOtSf52TAeSOa/Dh81Joy+oXBvJd6zGnEK5XnezF541tF1OjZC/XE2USF4NKrSaJ4xwWgx0 9hWItTL1oZShRZDaqtdoLEekeC+QT8Kz/vMsC1Jk30u8qerjXTKG0obczL3EA2zTQ8jM3YrSiBTv3 O8dRKAHA7vZRtFo0ZSQsfzVWSW9S617Z0BhTgKKNj66blEE2mE/oSMk+dhiqgTDbrhMwD33FnLrxg xbPJMIDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHjAE-00000001can-2RkH; Tue, 28 Apr 2026 14:11:50 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHjAD-00000001caR-1LsS; Tue, 28 Apr 2026 14:11:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=MIME-Version:Content-Transfer-Encoding :Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=XwiqsOpR23ShlfylRkZ2Fb1ig1xeGogp5lQf7doEuds=; b=j7eAS/9lmzXSkKi+VB76UcGtDA IZm9hW7Z48aF/JE/CszfTf3JS8c8YZl9lnUT7IDmtEghrLWJWUz/L4JKjN6c9oGa74y5wT4s/OBH9 8CMNKy57F27sj5KBcIM1taayduYCC2+BZPdcj12cGSxWsrXF43Y4VSN8U8DCcg3a0sUeRyC/bnVoz BvsT8+iIQghp5g3ydNzuf1gr+fm2xS8ecPV7EW8dPuMFic0Ywj3XwTueeIjzoZntdz/CzCZwDDjZt KM+Lxf9bNvWn312KcjqPjljfWM9qpu151lcDcYV5YqqhGInSu+Y2KIQMe90FuubNHBn/wKZHNST6x Jvz2X+Ew==; Received: from smtp81.cstnet.cn ([159.226.251.81] helo=cstnet.cn) by desiato.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHjA8-00000003Ht3-3FUU; Tue, 28 Apr 2026 14:11:48 +0000 Received: from edelgard.fodlan.icenowy.me (unknown [112.94.102.122]) by APP-03 (Coremail) with SMTP id rQCowADX79bQv_BpQaZ1Dw--.2120S2; Tue, 28 Apr 2026 22:10:28 +0800 (CST) Message-ID: <7d9086ff60e5e98117aeeb40a085dcde2c29de65.camel@iscas.ac.cn> Subject: Re: [PATCH v2 00/41] drm/display: bridge-connector: attach encoder to the connector From: Icenowy Zheng To: Luca Ceresoli , Dmitry Baryshkov , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sasha Finkelstein , Janne Grunau , Liu Ying , Douglas Anderson , Laurentiu Palcu , Lucas Stach , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Philipp Zabel , Paul Cercueil , Anitha Chrisanthus , Chun-Kuang Hu , Matthias Brugger , AngeloGioacchino Del Regno , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , Tomi Valkeinen , Sandy Huang , Heiko =?ISO-8859-1?Q?St=FCbner?= , Andy Yan , Thierry Reding , Mikko Perttunen , Jonathan Hunter , Jingoo Han , Inki Dae , Seung-Woo Kim , Kyungmin Park , Krzysztof Kozlowski , Alim Akhtar , Laurent Pinchart , Tomi Valkeinen , Kieran Bingham , Geert Uytterhoeven , Magnus Damm , Biju Das , Marek Vasut , Stefan Agner , Jyri Sarha , Michal Simek Cc: Hui Pu , Ian Ray , Thomas Petazzoni , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-renesas-soc@vger.kernel.org Date: Tue, 28 Apr 2026 22:10:18 +0800 In-Reply-To: References: <20260423-drm-bridge-connector-attach_encoder-v2-0-2ae6ca69b390@bootlin.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 MIME-Version: 1.0 X-CM-TRANSID: rQCowADX79bQv_BpQaZ1Dw--.2120S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtw4DGF1UKFWUtry7tFWxCrg_yoW7WFWDpF Wjga12kr4kXryrAws2vF15Za4FvrWDJr45Jr1qgw4SkaykuF18AFW7tFs8uasrAFWrW3Wj qr4YqrWxuF15AaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvGb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1l c7CjxVAaw2AFwI0_ZF0_GFyUMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r 4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF 67AKxVWrXVW8Jr1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa 73UjIFyTuYvjxUyPr4UUUUU X-Originating-IP: [112.94.102.122] X-CM-SenderInfo: x2kh0wp0lqwv3d6l2u1dvotugofq/ X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260428_151145_533877_050D32CE X-CRM114-Status: GOOD ( 44.89 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org =E5=9C=A8 2026-04-28=E4=BA=8C=E7=9A=84 15:39 +0200=EF=BC=8CLuca Ceresoli=E5= =86=99=E9=81=93=EF=BC=9A > Hello Icenowy, >=20 > On Sat Apr 25, 2026 at 5:22 PM CEST, Icenowy Zheng wrote: > > =E5=9C=A8 2026-04-23=E5=9B=9B=E7=9A=84 11:16 +0200=EF=BC=8CLuca Ceresol= i=E5=86=99=E9=81=93=EF=BC=9A > > > This series simplifies using the bridge-connector by removing the > > > need to > > > attach the newly created connector to the encoder. > > >=20 > > > =3D=3D Series description > > >=20 > > > Currently all users of the bridge-connector must call > > > drm_connector_attach_encoder() immediately after a successful > > > drm_bridge_connector_init(). > > >=20 > > > This is an unnecessary burden for users. Move the call to the end > > > of > > > drm_bridge_connector_init() so all callers can be simplified. > > >=20 > > > =C2=A0* Patch 1 adds a drm_connector_attach_encoder() call at the end > > > of > > > =C2=A0=C2=A0 drm_bridge_connector_init() > > > =C2=A0* The other patches remove drm_connector_attach_encoder() after > > > all > > > =C2=A0=C2=A0 drm_bridge_connector_init() calls, ordered from the simp= lest > > > ones > > > =C2=A0=C2=A0 (only the last one is somewhat non-obvious) > > >=20 > > > The Cc list is huge due to the many drivers touched. I sent v1 to > > > a > > > reduced > > > Cc list to ensure there is an agreement about the overall idea. > > > That > > > seems > > > to be the case, so now it's time to copy all drivers maintainers. > > >=20 > > > It would be nice to apply all of this series at once to avoid > > > duplicated > > > calls to drm_connector_attach_encoder() in the interim. That > > > would be > > > harmless beacuse drm_connector_attach_encoder() is idempotent, > > > but > > > unpleasant. > > >=20 > > > =3D=3D Additional rationale (for the curious) > > >=20 > > > Besides making the usage of the bridge-connector a bit simpler, > > > this > > > series > > > is in preparation for DRM bridge hotplug. Here's why, feel free > > > to > > > skip if > > > you don't care. > > >=20 > > > The old bridge hotplug proposals I have sent in the past [1] were > > > based on > > > a hotplug-bridge driver to sit between the last fixed bridge and > > > the > > > first > > > hotplugged bridge. Discussion with the community led to the need > > > of > > > removing the hotplug-bridge and let common DRM code handle > > > hotplug. > > > The > > > common place of code that appears the most suitable for hotplug > > > handling is > > > the bridge-connector, which is by now the recommended way to > > > handle > > > connector instantiation after a bridge chain. > > >=20 > > > So I'm in the process of extending the bridge-connector to be the > > > central > > > point to handle bridge hotplug. Turns out the need to call > > > drm_connector_attach_encoder() after drm_bridge_connector_init() > > > has > > > returned is adding big headaches to such work. So I'm send this > > > long > > > but > > > simple series to both simplify bridge-connector usage and remove > > > one > > > obstacle from the bridge hotplug work. This series is relevant by > > > itself > > > anyway. > > >=20 > > > [1] > > > https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-26-9d6f2c= 9c3058@bootlin.com/ > > >=20 > > > =3D=3D Grand plan > > >=20 > > > This is part of the work to support hotplug of DRM bridges. The > > > grand > > > plan > > > was discussed in [0]. > >=20 > > Just see the bridge hotplugging thing, is it possible for DRM > > drivers > > to declare bridges attached to themselves after this? > >=20 > > Loongson 7A1000 PCH can only output DPI signals, so nearly all > > products > > with it are shipping with some kind of external bridges, but > > currently > > drm/loongson does not support them (all display connectors are now > > seen > > as DPI ones, and connectors behind non-transparent bridges won't > > work). > >=20 > > The bridges are going to be accessed by the DDC I2C busses of > > 7A1000, > > and are not declared with device tree (systems with 7A1000 never > > ship > > with device trees, and Linux currently matches a built-in device > > tree). > > (Bridges being on the DDC I2C also introduces some dependency for > > them > > to depend on the drm/loongson driver.) > >=20 > > Loongson have defined some kind of VBIOS declaring what bridge is > > behind, and their non-mainline driver just contains driver codes > > for > > all possible bridges. (Sui Jingfeng previously tried to mainline > > such > > practice, and of course it's rejected because of code duplicity.) >=20 > I'm afraid your question goes a bit beyond my knowledge, the hotplug > work > I'm carrying on is focuses on DT platforms. >=20 > My limited understading of non-DT platforms is that a card driver > must > instantiate all components and tie them together, which assumes it > has to > know them somehow (ACPI, hardcoded, whatever). Others can probably > comment > better about this. Yes, there's some proprietary way defined by Loongson to declare which device is attached. The problem here is just to instantiate the attached devices (although parsing of the Loongson VBIOS data is also a TODO now) and prevent dependency loop. Thanks, Icenowy >=20 > As a general principle, when devices can be mixed and matched by the > board > designer, hardcoding them is a bad design choice. Think of bad old > board > files written in C, which were unmanageable and got replaced exactly > by > device tree. So my opinion is that DRM encoders and bridges should > know as > little as possible about the following bridge, connector or panel > that > follows them. >=20 > Luca >=20 > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com