Re: [PATCH v5 10/10] drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges

[Luca Ceresoli]

Hello,

+Cc: Dmitry's current e-mail address

I replied to such an old thread that is had an old address for Dmitry.

On Tue, 9 Sep 2025 17:29:07 +0200
Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx> wrote:

> Hello Dmitry, Maxime, DRM maintainers,
> 
> On Thu, 2 Jan 2025 13:01:40 +0100
> Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx> wrote:
> 
> > Hi Dmitry,
> > 
> > On Tue, 31 Dec 2024 17:29:52 +0200
> > Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote:
> >   
> > > On Tue, Dec 31, 2024 at 11:40:04AM +0100, Luca Ceresoli wrote:    
> > > > This driver implements the point of a DRM pipeline where a connector allows
> > > > removal of all the following bridges up to the panel.
> > > > 
> > > > The DRM subsystem currently allows hotplug of the monitor but not preceding
> > > > components. However there are embedded devices where the "tail" of the DRM
> > > > pipeline, including one or more bridges, can be physically removed:
> > > > 
> > > >  .------------------------.
> > > >  |   DISPLAY CONTROLLER   |
> > > >  | .---------.   .------. |
> > > >  | | ENCODER |<--| CRTC | |
> > > >  | '---------'   '------' |
> > > >  '------|-----------------'
> > > >         |
> > > >         |               HOTPLUG
> > > >         V              CONNECTOR
> > > >    .---------.        .--.    .-.        .---------.         .-------.
> > > >    | 0 to N  |        | _|   _| |        | 1 to N  |         |       |
> > > >    | BRIDGES |--DSI-->||_   |_  |--DSI-->| BRIDGES |--LVDS-->| PANEL |
> > > >    |         |        |  |    | |        |         |         |       |
> > > >    '---------'        '--'    '-'        '---------'         '-------'
> > > > 
> > > >  [--- fixed components --]  [----------- removable add-on -----------]
> > > > 
> > > > This driver supports such a device, where the final segment of a MIPI DSI
> > > > bus, including one or more bridges, can be physically disconnected and
> > > > reconnected at runtime, possibly with a different model.
> > > > 
> > > > The add-on supported by this driver has a MIPI DSI bus traversing the
> > > > hotplug connector and a DSI to LVDS bridge and an LVDS panel on the add-on.
> > > > Hovever this driver is designed to be as far as possible generic and
> > > > extendable to other busses that have no native hotplug and model ID
> > > > discovery.
> > > > 
> > > > This driver does not itself add and remove the bridges or panel on the
> > > > add-on: this needs to be done by other means, e.g. device tree overlay
> > > > runtime insertion and removal. The hotplug-bridge gets notified by the DRM
> > > > bridge core after a removable bridge gets added or before it is removed.
> > > > 
> > > > The hotplug-bridge role is to implement the "hot-pluggable connector" in
> > > > the bridge chain. In this position, what the hotplug-bridge should ideally
> > > > do is:
> > > > 
> > > >  * communicate with the previous component (bridge or encoder) so that it
> > > >    believes it always has a connected bridge following it and the DRM card
> > > >    is always present
> > > >  * be notified of the addition and removal of the following bridge and
> > > >    attach/detach to/from it
> > > >  * communicate with the following bridge so that it will attach and detach
> > > >    using the normal procedure (as if the entire pipeline were being created
> > > >    or destroyed, not only the tail)
> > > >  * instantiate two DRM connectors (similarly to what the DisplayPort MST
> > > >    code does):
> > > >    - a DSI connector representing the video lines of the hotplug connector;
> > > >      the status is always "disconnected" (no panel is ever attached
> > > >      directly to it)
> > > >    - an LSVD connector representing the classic connection to the panel;
> > > >      this gets added/removed whenever the add-on gets
> > > >      connected/disconnected; the status is always "connected" as the panel
> > > >      is always connected to the preceding bridge      
> > > 
> > > I'd rather have just a single connector. MST connectors can be added and
> > > gone as there is fit, so should be your LVDS panel-related connector.    
> > 
> > The plan we discussed at LPC 2024 is to eventually get rid of the first
> > connector (see "Roadmap and current status" in the cover letter), so
> > you can consider this legacy code. However the current implementation
> > won't work without this connector, so it is still there for the time
> > being. Pointing this out in a note in the commit message of this patch
> > would probably be useful to avoid future misunderstanding, so I'm
> > adding one for v6.  
> 
> Reviving this old thread for a specific question I need to clarify.
> Before starting a work that I consider far from trivial I'd like to
> make sure the requirement is clear.
> 
> There was a precise request by both Dmitry and (IIRC) Maxime to remove
> the "always present, never connected" DSI connector.
> 
> [Recap of previous discussion: skip if unneeded]
> 
> The current status is that the hotplug-bridge, which can start without
> an add-on plugged, adds a DSI connector unconditionally:
> 
>   # modetest -c  | grep -i '^[a-z0-9]'
>   Connectors:
>   id    encoder status          name        size (mm)     modes   encoders
>   38    0       disconnected    DSI-1       0x0           0       37
> 
> That DSI connector status is always "unconnected" (in my implementation
> at least) because it does never a panel _directly_ attached, only a
> further bridge.
> 
> Then when the add-on is plugged, which contains a DSI-to-LVDS bridge, a
> new LVDS connector is added:
> 
>   # modetest -c  | grep -i '^[a-z0-9]'
>   Connectors:
>   id    encoder status          name        size (mm)     modes   encoders
>   38    0       disconnected    DSI-1       0x0           0       37
>   39    0       connected       LVDS-1      344x194       1       37
> 
> The LVDS connector has a panel attached and provides the modes, so it
> is "the connector" in the DRM logic. It is always in "connected" status
> because it drives a panel that is always tied to the DSI-to-LVDS bridge.
> It is removed when the add-on is removed and so the removable bridge(s)
> disappear(s).
> 
> The request is to get rid of the DSI connector, because it is not a DRM
> connector in the classic DRM sense (DRM connector ~= a modes +
> connection status provider). That would mean without addon plugged
> there is no DRM connector at all.
> 
> However for user space to be able to always have a card we need the
> card to be populated even before the addon is plugged and to persist
> after its removal. So, a card without any connectors.
> 
> [End of recap of previous discussion]
> 
> Now comes the question!
> 
> Based on the above, I understand that:
> 
>  * Current DRM code won't populate a card without at least a DRM
>    connector
>  * We now need to change the DRM code to allow populating a card,
>    and expose it to user space, without a DRM connector
>  * The previous bullet is a prerequisite to get rid of DSI connector as
>    requested
> 
> Is my understanding correct?
> 
> Best regards,
> Luca
> 



-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com