From: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Ying Liu <victor.liu@nxp.com>, Frank Li <frank.li@oss.nxp.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
linux-clk@vger.kernel.org, imx@lists.linux.dev,
devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v10 2/9] drm/bridge: fsl-ldb: Get the next non-panel bridge
Date: Fri, 30 Oct 2026 12:16:33 +0200 [thread overview]
Message-ID: <auRsorXM4UQJzoWF@vm> (raw)
In-Reply-To: <179334897994.680709.5849266352850173475.b4-review@b4>
Hi Luca,
Thanks for looking over this patch.
On Fri, Oct 30, 2026 at 09:29:39AM +0100, Luca Ceresoli wrote:
> Hello Laurentiu,
>
> > The next bridge in bridge chain could be a panel bridge or a non-panel
> > bridge. Use devm_drm_of_get_bridge() to replace the combination
> > function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
> > to get either a panel bridge or a non-panel bridge, instead of getting
> > a panel bridge only.
>
> Since commit b7797081ccfe ("drm/panel: embed a drm_bridge into every
> drm_panel") there is no such thing as a panel_bridge. Now every panel just
> embeds a bridge, and there is no reason to use the panel_bridge API. All
> bridges/encoders/whoever needing to interact with "the next component, be
> it a bridge or a panel" should just use the bridge API.
>
> The old panel_bridge APIs are deprecated [0] and by now they are just
> complicated wrappers to the bridge API.
>
> I'm addressing the conversion to bridge API and eventual removal of the
> deprecated panel_bridge API as time permits (but pathces would be
> welcome). This driver has already been converted by commit 802372cf316a
> ("drm/bridge: fsl-ldb: don't create a panel_bridge"), so this patch is
> basically not changing anything: it's still getting a pointer to the next
> bridge, but switches to a slightly more complicated implementation.
>
> So I'd drop this patch.
Agreed
>
> Still it's good to get rid of the obsolete "panel" wording because now we
> don't interact with a panel aymore, see below.
OK, I'll replace this patch with one addressing your comments below.
>
> [0] https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/Documentation/gpu/todo.rst#remove-panel_bridge-api-functions
>
> >
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> >
> > diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> > index 7ec84c81cd78..52ae7f5b63c7 100644
> > --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> > +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> > @@ -294,8 +294,8 @@ static const struct drm_bridge_funcs funcs = {
> > static int fsl_ldb_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > - struct device_node *panel_node;
>
> This could be renamed remote_bridge, or next_bridge_node, or the like.
>
> > struct device_node *remote1, *remote2;
> > + struct drm_bridge *next_bridge;
> > struct fsl_ldb *fsl_ldb;
> > int dual_link;
> >
> > @@ -318,19 +318,16 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> > if (IS_ERR(fsl_ldb->regmap))
> > return PTR_ERR(fsl_ldb->regmap);
> >
> > - /* Locate the remote ports and the panel node */
> > + /* Locate the remote ports. */
>
> This is OK.
>
> > remote1 = of_graph_get_remote_node(dev->of_node, 1, 0);
> > remote2 = of_graph_get_remote_node(dev->of_node, 2, 0);
> > fsl_ldb->ch0_enabled = (remote1 != NULL);
> > fsl_ldb->ch1_enabled = (remote2 != NULL);
> > - panel_node = of_node_get(remote1 ? remote1 : remote2);
>
> I'd leave it as is, it's just less code (and more efficient FWIW)
> than... see below (*)
>
> > of_node_put(remote1);
> > of_node_put(remote2);
> >
> > - if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled) {
> > - of_node_put(panel_node);
> > - return dev_err_probe(dev, -ENXIO, "No panel node found");
> > - }
> > + if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
> > + return dev_err_probe(dev, -ENXIO, "No next bridge node found");
>
> This can be simplified by using a clenaup action on panel_node (or whatever
> the new name will be), so the of_node_put() would disappear. See for
> example commit 23bc92902edd ("drm/mxsfb/lcdif: simplify ep pointer
> management using __free").
>
>
> > @@ -339,10 +336,14 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> > if (of_property_present(dev->of_node, "nxp,enable-termination-resistor"))
> > fsl_ldb->use_termination_resistor = true;
> >
> > - fsl_ldb->bridge.next_bridge = of_drm_find_and_get_bridge(panel_node);
> > - of_node_put(panel_node);
> > - if (!fsl_ldb->bridge.next_bridge)
> > - return -ENODEV;
> > + next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node,
> > + fsl_ldb->ch0_enabled ? 1 : 2,
> > + 0);
>
> (*) ...this code.
>
> > + if (IS_ERR(next_bridge))
> > + return dev_err_probe(dev, PTR_ERR(next_bridge),
> > + "failed to get next bridge\n");
> > +
> > + fsl_ldb->bridge.next_bridge = next_bridge;
> >
> > if (fsl_ldb_is_dual(fsl_ldb)) {
> > struct device_node *port1, *port2;
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
--
Thanks,
Laurentiu
next prev parent reply other threads:[~2026-10-30 10:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 12:21 [PATCH v10 0/9] Add support for i.MX94 DCIF Laurentiu Palcu
2026-10-06 12:21 ` [PATCH v10 1/9] dt-bindings: display: fsl,ldb: Add i.MX94 LDB Laurentiu Palcu
2026-10-06 12:21 ` [PATCH v10 2/9] drm/bridge: fsl-ldb: Get the next non-panel bridge Laurentiu Palcu
2026-10-30 8:29 ` Luca Ceresoli
2026-10-30 10:16 ` Laurentiu Palcu [this message]
2026-10-06 12:21 ` [PATCH v10 3/9] drm/bridge: fsl-ldb: Add support for i.MX94 Laurentiu Palcu
2026-10-30 8:29 ` Luca Ceresoli
2026-10-06 12:21 ` [PATCH v10 4/9] dt-bindings: display: imx: Add i.MX94 DCIF Laurentiu Palcu
2026-10-06 12:22 ` [PATCH v10 5/9] drm/imx: Add support for " Laurentiu Palcu
2026-10-12 11:18 ` Uwe Kleine-König
2026-10-06 12:22 ` [PATCH v10 6/9] dt-bindings: clock: nxp,imx95-blk-ctl: Add ldb child node Laurentiu Palcu
2026-10-07 13:12 ` Conor Dooley
2026-10-07 13:57 ` Laurentiu Palcu
2026-10-07 14:02 ` Conor Dooley
2026-10-06 12:22 ` [PATCH v10 7/9] arm64: dts: imx94: Add display pipeline nodes Laurentiu Palcu
2026-10-06 12:22 ` [PATCH v10 8/9] arm64: dts: imx943-evk: Add display support using IT6263 Laurentiu Palcu
2026-10-06 12:22 ` [PATCH v10 9/9] MAINTAINERS: Add entry for i.MX94 DCIF driver Laurentiu Palcu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=auRsorXM4UQJzoWF@vm \
--to=laurentiu.palcu@oss.nxp.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frank.li@oss.nxp.com \
--cc=imx@lists.linux.dev \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=victor.liu@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox