Message-Id: <DF0CCD6EW5DR.3CYNK65T1GSAO@bootlin.com>
Date: Wed, 17 Dec 2025 09:15:48 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.com>
To: "Martin Blumenstingl" <martin.blumenstingl@...glemail.com>
Cc: "Andrzej Hajda" <andrzej.hajda@...el.com>, "Neil Armstrong"
 <neil.armstrong@...aro.org>, "Robert Foss" <rfoss@...nel.org>, "Laurent
 Pinchart" <Laurent.pinchart@...asonboard.com>, "Jonas Karlman"
 <jonas@...boo.se>, "Jernej Skrabec" <jernej.skrabec@...il.com>, "Maarten
 Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard"
 <mripard@...nel.org>, "Thomas Zimmermann" <tzimmermann@...e.de>, "David
 Airlie" <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>, "Jonathan
 Corbet" <corbet@....net>, "Alexey Brodkin" <abrodkin@...opsys.com>, "Phong
 LE" <ple@...libre.com>, "Liu Ying" <victor.liu@....com>, "Shawn Guo"
 <shawnguo@...nel.org>, "Sascha Hauer" <s.hauer@...gutronix.de>,
 "Pengutronix Kernel Team" <kernel@...gutronix.de>, "Fabio Estevam"
 <festevam@...il.com>, "Adrien Grassein" <adrien.grassein@...il.com>,
 "Laurent Pinchart" <laurent.pinchart+renesas@...asonboard.com>, "Tomi
 Valkeinen" <tomi.valkeinen+renesas@...asonboard.com>, "Kieran Bingham"
 <kieran.bingham+renesas@...asonboard.com>, "Geert Uytterhoeven"
 <geert+renesas@...der.be>, "Magnus Damm" <magnus.damm@...il.com>, "Kevin
 Hilman" <khilman@...libre.com>, "Jerome Brunet" <jbrunet@...libre.com>,
 "Chun-Kuang Hu" <chunkuang.hu@...nel.org>, "Philipp Zabel"
 <p.zabel@...gutronix.de>, "Matthias Brugger" <matthias.bgg@...il.com>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 "Anitha Chrisanthus" <anitha.chrisanthus@...el.com>, "Inki Dae"
 <inki.dae@...sung.com>, "Seung-Woo Kim" <sw0312.kim@...sung.com>, "Kyungmin
 Park" <kyungmin.park@...sung.com>, "Krzysztof Kozlowski" <krzk@...nel.org>,
 "Alim Akhtar" <alim.akhtar@...sung.com>, "Hui Pu"
 <Hui.Pu@...ealthcare.com>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>, "Louis Chauvet"
 <louis.chauvet@...tlin.com>, <dri-devel@...ts.freedesktop.org>,
 <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
 <imx@...ts.linux.dev>, <linux-arm-kernel@...ts.infradead.org>,
 <linux-renesas-soc@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
 <linux-mediatek@...ts.infradead.org>, <linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH v2 17/26] drm/meson: encoder_*: use
 devm_of_drm_get_bridge() to put the next bridge

Hello Martin,

On Wed Dec 17, 2025 at 1:01 AM CET, Martin Blumenstingl wrote:
> Hi Luca,
>
> On Tue, Dec 16, 2025 at 1:46 PM Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> [...]
>> > What I'm not sure about is how this series interacts with
>> > devm_drm_of_get_bridge() which is why I'm asking before cooking a
>> > patch.
>>
>> Apologies for the long delay in getting back to you. You might have noticed
>> some discussion about the overall approach, and I waited for it to settle.
> That hasn't gone unnoticed!
>
>> About devm_drm_of_get_bridge(), it is a very different function so it does
>> not affect this series. The name similarity is confusing indeed, but
>> devm_of_drm_get_bridge() has been removed from my approach, so one less
>> source of confusion.
> I have to confess that I'm still confused. drivers/gpu/drm/drm_bridge.c states:
> "Display drivers are responsible for linking encoders with the first bridge
>  in the chains. This is done by acquiring the appropriate bridge with
>  devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached to the
>  encoder with a call to drm_bridge_attach().
>
>  Bridges are responsible for linking themselves with the next bridge in the
>  chain, if any. This is done the same way as for encoders, with the call to
>  drm_bridge_attach() occurring in the &drm_bridge_funcs.attach operation."
> Does this mean your series effectively deprecates devm_drm_of_get_bridge()?

Well spotted! I theory yes, my series kind of implicitly deprecates other
functions based on it, including drm_of_find_panel_or_bridge() and
*_of_get_bridge(), which are problematic in case of bridge removal. But
before explicitly deprecating them we need a good alternative. Which in
turn depends on the rework of the panel_bridge lifetime, which was also
discussed with Maxime in the same thread.

Bottom line: for now *_of_get_bridge() usage is still OK, but stay
tuned. :-)

>> I'm soon sending v3, and I have updated my patch to
>> eson_encoder_{cvbs,dsi,hdmi}.c, actually splitting it in 3. I'd be grateful
>> if you could reviewd and/ot test them when I send v3. But I don't think
>> there is a need for you to send any patches related to this topic.
> Regardless of the questions I still have around
> devm_drm_of_get_bridge(): I'll give your patches a go in the next
> days.

Thank you, v3 is there awaiting you!

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists