Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline

[Maxime Ripard]

On Tue, Jun 09, 2026 at 10:23:24AM +0200, Luca Ceresoli wrote:
> Hi Maxime,
> 
> thanks for the review of this long series!
> 
> On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote:
> ...
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
> >>  	int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
> >>  		      enum drm_bridge_attach_flags flags);
> >>
> >> +	/**
> >> +	 * @is_tail:
> >> +	 *
> >> +	 * Returns true if this is a tail bridge, i.e. it does not need a
> >> +	 * next bridge to work. E.g. a panel_bridge is a tail bridge, a
> >> +	 * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
> >> +	 * next bridge is present or not).
> >
> > Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
> > next, right?
> 
> Uhm, good point, but I'd say it can be a tail bridge or not: in the
> ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most
> likely), no?

Yeah, I think it cannot (always) be a blanket statement from the driver.
For drivers that do not support ATTACH_NO_CONNECTOR, then it's always
going to be a tail, but if the driver supports it, we should use a
helper because it's going to depend on the DT, basically.

> However this is possibly irrelevant as the whole .is_tail is meant to
> disappear in v2, see below.
>
> >> +	 * The @is_tail callback is optional but it is required if the
> >> +	 * bridge is part of a pipeline with hot-pluggable components.
> >> +	 */
> >> +	bool (*is_tail)(struct drm_bridge *bridge);
> >> +
> >
> > I don't think that's the right way to think about it, if only because
> > you never really know at the driver level if you're supposed to be last
> > or not. A DSI-to-LVDS bridge might just as well be chained with an
> > LVDS-to-eDP bridge, or feed the panel directly without any additional
> > bridge.
> >
> > I *think* that what you're trying to find out here is whether the chain
> > is complete or not.
> 
> You nailed it.
> 
> That was the main point discussed during the Display Next Hackfest 2026
> (see the report [0]) and we all agreed the .is_tail along with the
> -EPROBE_DEFER changes (patches 20+35) are not a good approach.
> 
> This is actually the most crucial aspect of the whole work still not having
> no well-defined solution.

Ok

> > I think you can get the same information by checking
> > whether you have a connector for that bridge chain. If you don't, you
> > know the chain isn't complete, and if you do, it's supposed to be.
> 
> There's a checken-egg problem here. Knowing whether the pipeline is
> complete or not is needed to know whether we have to create a
> connector. See patch 36:
> 
>   +  if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
>   +          drm_bridge_connector_add_connector(bridge_connector);
> 
> So the question is still open, what I need the most right now is comments
> on the overall architecture of this aspecs. Maybe replying to [0] can be
> more effective than here.
> 
> In a nutshell what we need is:
> 
>  * when a bridge needs a following element (a bridge, or a panel which
>    however might/should have a panel_bridge), but that element is not
>    present, instead of deferring the whole card probe the card should be
>    allowed to probe but without a connector
> 
>  * when something is added to an incomplete pipeline we need to know
>    whether the pipeline has become complete (in order to create the
>    connector)
> 
> How to implement this is still an open point. I'll welcome proposals in
> addition to the ones in [0].

Thanks for the notes, I think I largely agree with the discussion.
Reading through it, I thought it would be nice for a new callback called
get_next_bridge or something that would return either an error, NULL or a
(refcounted) pointer to the next bridge in the chain. And have some kind
of special error (ENODEV?) when the bridge should be there but isn't
(and thus the chain isn't complete).

Maxime

Attachment: signature.asc
Description: PGP signature