Re: [PATCH v2 00/41] drm/display: bridge-connector: attach encoder to the connector

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hello Icenowy,

On Sat Apr 25, 2026 at 5:22 PM CEST, Icenowy Zheng wrote:
> 在 2026-04-23四的 11:16 +0200，Luca Ceresoli写道：
>> This series simplifies using the bridge-connector by removing the
>> need to
>> attach the newly created connector to the encoder.
>>
>> == 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.
>>
>>  * Patch 1 adds a drm_connector_attach_encoder() call at the end of
>>    drm_bridge_connector_init()
>>  * The other patches remove drm_connector_attach_encoder() after all
>>    drm_bridge_connector_init() calls, ordered from the simplest ones
>>    (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.
>>
>> == 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-9d6f2c9c3058@bootlin.com/
>>
>> == 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