On Tue, Mar 26, 2024 at 05:28:14PM +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 devices, 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.
>
> This implementation supports a MIPI DSI bus only, but it 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 provide facilities to add and remove the hot-pluggable
> components from the kernel: this needs to be done by other means
> (e.g. device tree overlay runtime insertion and removal). The
> hotplug-bridge gets notified of hot-plugging by the DRM bridge notifier
> callbacks after they get added or before they get 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)
> * expose the "add-on connected/disconnected" status via the DRM connector
> connected/disconnected status, so that users of the DRM pipeline know
> when they can render output on the display
>
> However some aspects make it a bit more complex than that. Most notably:
>
> * the next bridge can be probed and removed at any moment and all probing
> sequences need to be handled
> * the DSI host/device registration process, which adds to the DRM bridge
> attach process, makes the initial card registration tricky
> * the need to register and deregister the following bridges at runtime
> without tearing down the whole DRM card prevents using the functions
> that are normally recommended
> * the automatic mechanism to call the appropriate .get_modes operation
> (typically provided by the panel bridge) cannot work as the panel can
> disappear and reappear as a different model, so an ad-hoc lookup is
> needed
There's several additional hurdles there:
- You mentioned the connector in your ideal scenario. But as soon as
you remove the last bridge, the connector will probably go away too.
There's two scenarii here then:
- The driver is ok, and it will stay there until the last user its to
the main DRM device. Which means that if you create a new one,
you'll have the old one and the new one together, but you can't
tell which one you're supposed to use.
- If the driver isn't ok, the connector will be freed immediately.
There's plenty of lingering pointers in the framework, and
especially the states though, leading to use-after-free errors.
- So far, we told everyone that the graphics pipeline wasn't going to
change. How do you expect applications to deal with a connector going
away without any regression? I guess the natural thing here would be
to emit a uevent just like we do when the connection status change,
but the thing is: we're doing that for the connector, and the
connector is gone.
Between the userspace expectations and the memory-safety issue plaguing
way too many drivers, I'm not sure this approach can work.
I guess one way to somewhat achieve what you're trying to do would be to
introduce the connection status at the bridge level, reflect the
aggregate connection status of all bridges on the connector, and make
each bridge driver probe its device in the connect hook through DCS or
I2C.
We wouldn't be able to change the bridge halfway through the system's
life, but like I said, KMS cannot hotplug connectors at the moment and
doing so requires far more work.
Maxime
Attachment:
signature.asc
Description: PGP signature
