From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9BBB43DA39; Tue, 28 Apr 2026 13:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777383614; cv=none; b=qhVweuokkDPGwAeu2U5tf7H8QHEInJiaEK4QOpq6CQxlUzweuVh7iHfkF2NXZ0QxLfGvKtZZqsdiNfEOw/nOO7EJY0qFJ4vGdBz6z7WQ2STIrHMFCFKZmKlpke+//4CbeOxi5lko/pKg/wOLe5uX/8biz7Kkvwvj7sUUnkudo8g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777383614; c=relaxed/simple; bh=DY37OnpoYjjW+GFpmDYkzr+BXySsTF4/pHUAAopHjvA=; h=Mime-Version:Content-Type:Date:Message-Id:From:Subject:Cc:To: References:In-Reply-To; b=slL67D5Pb0oXGXNGd6GcDGDQ9SiSh4NCwHbWwmTxOvDwJzawFlIIiZwHrdRw6kNf+MF0tNQrguXOv/sOlQyFZud0kgNFQDTOGbLi4pnGrvUMtf2/PqEQdoXFadmgtWo9dRb7Stl2PP/lPNXthvDdP2tcREiR9paYYoV2kDr6Fpw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=qRLoVPjW; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="qRLoVPjW" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 445ED4E42B5C; Tue, 28 Apr 2026 13:40:10 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 026AB601DF; Tue, 28 Apr 2026 13:40:10 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C6AAE10728BFF; Tue, 28 Apr 2026 15:39:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1777383605; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=DY37OnpoYjjW+GFpmDYkzr+BXySsTF4/pHUAAopHjvA=; b=qRLoVPjWicMlOER4CBoXDyZ31IS3N9wzfHFsgyWbAAFF/gci+qsFmTs0vCeqFcMtumISls Tj3oY/2Cdf6m/7gztcQrTJLdN0ggRvFVqgt+JH8FxO2/nx+GfiibBB7tr9VdYd2pRAyZX1 XAXF0QiFbh370lTIQPb7xonACEwx2kQTWqUUcXxmMBeCKnlqHPelpK3fTwkngZn/4NCD/d KE58A7C2KizgbREMj4kyFapvuVzo03ASQ8lKHF89cbbYlD9WTUWuW4Ve1tF5Yw+ztjpBH4 MjEA//3NGYT7/zO8OOYAeAWTnaFj1l+B1bRPPqqwsMjaj7jeo7/wmSi84hXibw== 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 Date: Tue, 28 Apr 2026 15:39:43 +0200 Message-Id: From: "Luca Ceresoli" Subject: Re: [PATCH v2 00/41] drm/display: bridge-connector: attach encoder to the connector Cc: "Hui Pu" , "Ian Ray" , "Thomas Petazzoni" , , , , , , , , , , , , , , To: "Icenowy Zheng" , "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" , =?utf-8?q?Heiko_St=C3=BCbner?= , "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" X-Mailer: aerc 0.20.1 References: <20260423-drm-bridge-connector-attach_encoder-v2-0-2ae6ca69b390@bootlin.com> In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 Hello Icenowy, 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 Ceresoli= =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. >> >> =3D=3D Series description >> >> Currently all users of the bridge-connector must call >> drm_connector_attach_encoder() immediately after a successful >> drm_bridge_connector_init(). >> >> This is an unnecessary burden for users. Move the call to the end of >> drm_bridge_connector_init() so all callers can be simplified. >> >> =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 al= l >> =C2=A0=C2=A0 drm_bridge_connector_init() calls, ordered from the simples= t ones >> =C2=A0=C2=A0 (only the last one is somewhat non-obvious) >> >> 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. >> >> 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. >> >> =3D=3D Additional rationale (for the curious) >> >> 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. >> >> 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. >> >> 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. >> >> [1] >> https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-26-9d6f2c9c3= 058@bootlin.com/ >> >> =3D=3D Grand plan >> >> This is part of the work to support hotplug of DRM bridges. The grand >> plan >> was discussed in [0]. > > Just see the bridge hotplugging thing, is it possible for DRM drivers > to declare bridges attached to themselves after this? > > 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). > > 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.) > > 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.) I'm afraid your question goes a bit beyond my knowledge, the hotplug work I'm carrying on is focuses on DT platforms. 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. 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. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com