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.ceres...@bootlin.com> wrote: > Hello Dmitry, Maxime, DRM maintainers, > > On Thu, 2 Jan 2025 13:01:40 +0100 > Luca Ceresoli <luca.ceres...@bootlin.com> wrote: > > > Hi Dmitry, > > > > On Tue, 31 Dec 2024 17:29:52 +0200 > > Dmitry Baryshkov <dmitry.barysh...@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
