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

[Icenowy Zheng]

在 2026-04-28二的 15:39 +0200，Luca Ceresoli写道：
> 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.

Yes, there's some proprietary way defined by Loongson to declare which
device is attached.

The problem here is just to instantiate the attached devices (although
parsing of the Loongson VBIOS data is also a TODO now) and prevent
dependency loop.

Thanks,
Icenowy

> 
> 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