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?
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.
> 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].
[0] https://lore.kernel.org/all/[email protected]/
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
