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

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

Hello Dmitry, Maxime, DRM maintainers,

On Thu, 2 Jan 2025 13:01:40 +0100
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:

> Hi Dmitry,
> 
> On Tue, 31 Dec 2024 17:29:52 +0200
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> 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