From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Maxime Ripard <mripard@kernel.org>, Dmitry Baryshkov <lumag@kernel.org>
Cc: "Simona Vetter" <simona@ffwll.ch>,
"Inki Dae" <inki.dae@samsung.com>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"Daniel Thompson" <danielt@kernel.org>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Paul Kocialkowski" <contact@paulk.fr>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Hervé Codina" <herve.codina@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-doc@vger.kernel.org,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>
Subject: Re: [PATCH v5 10/10] drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges
Date: Tue, 9 Sep 2025 17:39:33 +0200 [thread overview]
Message-ID: <20250909173933.20fc5d6a@booty> (raw)
In-Reply-To: <20250909172907.09157d70@booty>
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@bootlin.com> wrote:
> 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
prev parent reply other threads:[~2025-09-09 15:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-31 10:39 [PATCH v5 00/10] Add support for hot-pluggable DRM bridges Luca Ceresoli
2024-12-31 10:39 ` [PATCH v5 01/10] drm/bridge: allow bridges to be informed about added and removed bridges Luca Ceresoli
2024-12-31 10:39 ` [PATCH v5 02/10] drm/encoder: add drm_encoder_cleanup_from() Luca Ceresoli
2024-12-31 10:39 ` [PATCH v5 03/10] drm/bridge: add support for refcounted DRM bridges Luca Ceresoli
2024-12-31 11:11 ` Jani Nikula
2025-01-02 12:03 ` Luca Ceresoli
2025-01-03 9:36 ` Jani Nikula
2024-12-31 10:39 ` [PATCH v5 04/10] drm/bridge: add documentation of refcounted bridges Luca Ceresoli
2024-12-31 17:54 ` Randy Dunlap
2025-01-02 12:02 ` Luca Ceresoli
2025-01-06 10:39 ` Maxime Ripard
2025-01-06 12:24 ` Dmitry Baryshkov
2025-01-06 14:49 ` Maxime Ripard
2025-01-07 10:35 ` Dmitry Baryshkov
2025-01-07 15:12 ` Maxime Ripard
2025-01-08 15:24 ` Luca Ceresoli
2025-01-08 15:24 ` Luca Ceresoli
2025-01-08 16:02 ` Maxime Ripard
2025-01-22 16:12 ` Luca Ceresoli
2025-01-28 14:49 ` Maxime Ripard
2025-01-29 11:51 ` Luca Ceresoli
2025-01-29 12:22 ` Dmitry Baryshkov
2025-01-29 13:11 ` Luca Ceresoli
2024-12-31 10:39 ` [PATCH v5 05/10] drm/tests: bridge: add KUnit tests for DRM bridges (init and destroy) Luca Ceresoli
2024-12-31 10:40 ` [PATCH v5 06/10] drm/bridge: ti-sn65dsi83: use dynamic lifetime management Luca Ceresoli
2024-12-31 10:40 ` [PATCH v5 07/10] drm/bridge: panel: " Luca Ceresoli
2024-12-31 10:40 ` [PATCH v5 08/10] drm/bridge: samsung-dsim: use supporting variable for out_bridge Luca Ceresoli
2024-12-31 14:57 ` Dmitry Baryshkov
2025-01-02 12:01 ` Luca Ceresoli
2025-01-03 6:00 ` Dmitry Baryshkov
2025-01-10 10:58 ` Luca Ceresoli
2025-01-16 10:32 ` Luca Ceresoli
2025-01-16 10:56 ` Dmitry Baryshkov
2025-01-21 11:27 ` Luca Ceresoli
2025-01-21 11:57 ` Dmitry Baryshkov
2025-01-28 15:52 ` Maxime Ripard
2025-01-16 12:26 ` Maxime Ripard
2025-01-21 11:27 ` Luca Ceresoli
2025-01-28 15:09 ` Maxime Ripard
2025-01-29 11:51 ` Luca Ceresoli
2025-02-04 15:44 ` Maxime Ripard
2024-12-31 10:40 ` [PATCH v5 09/10] drm/bridge: samsung-dsim: refcount the out_bridge Luca Ceresoli
2024-12-31 14:58 ` Dmitry Baryshkov
2024-12-31 10:40 ` [PATCH v5 10/10] drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges Luca Ceresoli
2024-12-31 15:29 ` Dmitry Baryshkov
2025-01-02 12:01 ` Luca Ceresoli
2025-09-09 15:29 ` Luca Ceresoli
2025-09-09 15:39 ` Luca Ceresoli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250909173933.20fc5d6a@booty \
--to=luca.ceresoli@bootlin.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=catalin.marinas@arm.com \
--cc=contact@paulk.fr \
--cc=corbet@lwn.net \
--cc=danielt@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=inki.dae@samsung.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@pengutronix.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=paul.kocialkowski@bootlin.com \
--cc=rfoss@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.petazzoni@bootlin.com \
--cc=tzimmermann@suse.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.