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
