From: Maxime Ripard <maxime@cerno.tech>
To: Sam Ravnborg <sam@ravnborg.org>,
Daniel Vetter <daniel.vetter@intel.com>,
David Airlie <airlied@linux.ie>,
Thierry Reding <thierry.reding@gmail.com>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Maxime Ripard <maxime@cerno.tech>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Neil Armstrong <narmstrong@baylibre.com>,
Andrzej Hajda <a.hajda@samsung.com>,
Jonas Karlman <jonas@kwiboo.se>,
Robert Foss <robert.foss@linaro.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: [PATCH v2 4/8] drm/bridge: Document the probe issue with MIPI-DSI bridges
Date: Wed, 28 Jul 2021 15:32:25 +0200 [thread overview]
Message-ID: <20210728133229.2247965-5-maxime@cerno.tech> (raw)
In-Reply-To: <20210728133229.2247965-1-maxime@cerno.tech>
Interactions between bridges, panels, MIPI-DSI host and the component
framework are not trivial and can lead to probing issues when
implementing a display driver. Let's document the various cases we need
too consider, and the solution to support all the cases.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/gpu/drm-kms-helpers.rst | 6 +++
drivers/gpu/drm/drm_bridge.c | 60 +++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index 10f8df7aecc0..ec2f65b31930 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -157,6 +157,12 @@ Display Driver Integration
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: display driver integration
+Special Care with MIPI-DSI bridges
+----------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+ :doc: special care dsi
+
Bridge Operations
-----------------
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 71d3370ce209..fd01f1ce7976 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -94,6 +94,66 @@
* documentation of bridge operations for more details).
*/
+/**
+ * DOC: special care dsi
+ *
+ * The interaction between the bridges and other frameworks involved in
+ * the probing of the display driver and the bridge driver can be
+ * challenging. Indeed, there's multiple cases that needs to be
+ * considered:
+ *
+ * - The display driver doesn't use the component framework and isn't a
+ * MIPI-DSI host. In this case, the bridge driver will probe at some
+ * point and the display driver should try to probe again by returning
+ * EPROBE_DEFER as long as the bridge driver hasn't probed.
+ *
+ * - The display driver doesn't use the component framework, but is a
+ * MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
+ * controlled. In this case, the bridge device is a child of the
+ * display device and when it will probe it's assured that the display
+ * device (and MIPI-DSI host) is present. The display driver will be
+ * assured that the bridge driver is connected between the
+ * &mipi_dsi_host_ops.attach and &mipi_dsi_host_ops.detach operations.
+ * Therefore, it must run mipi_dsi_host_register() in its probe
+ * function, and then run drm_bridge_attach() in its
+ * &mipi_dsi_host_ops.attach hook.
+ *
+ * - The display driver uses the component framework and is a MIPI-DSI
+ * host. The bridge device uses the MIPI-DCS commands to be
+ * controlled. This is the same situation than above, and can run
+ * mipi_dsi_host_register() in either its probe or bind hooks.
+ *
+ * - The display driver uses the component framework and is a MIPI-DSI
+ * host. The bridge device uses a separate bus (such as I2C) to be
+ * controlled. In this case, there's no correlation between the probe
+ * of the bridge and display drivers, so care must be taken to avoid
+ * an endless EPROBE_DEFER loop, with each driver waiting for the
+ * other to probe.
+ *
+ * The ideal pattern to cover the last item (and all the others in the
+ * display driver case) is to split the operations like this:
+ *
+ * - In the display driver must run mipi_dsi_host_register() and
+ * component_add in its probe hook. It will make sure that the
+ * MIPI-DSI host sticks around, and that the driver's bind can be
+ * called.
+ *
+ * - In its probe hook, the bridge driver must not try to find its
+ * MIPI-DSI host or register as a MIPI-DSI device. As far as the
+ * framework is concerned, it must only call drm_bridge_add().
+ *
+ * - In its bind hook, the display driver must try to find the bridge
+ * and return -EPROBE_DEFER if it doesn't find it. If it's there, it
+ * must call drm_bridge_attach(). The MIPI-DSI host is now functional.
+ *
+ * - In its &drm_bridge_funcs.attach hook, the bridge driver can now try
+ * to find its MIPI-DSI host and can register as a MIPI-DSI device.
+ *
+ * At this point, we're now certain that both the display driver and the
+ * bridge driver are functional and we can't have a deadlock-like
+ * situation when probing.
+ */
+
static DEFINE_MUTEX(bridge_lock);
static LIST_HEAD(bridge_list);
--
2.31.1
next prev parent reply other threads:[~2021-07-28 13:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 13:32 [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 1/8] Revert "drm/vc4: dsi: Only register our component once a DSI device is attached" Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 2/8] drm/bridge: Add a function to abstract away panels Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 3/8] drm/bridge: Add documentation sections Maxime Ripard
2021-07-28 13:32 ` Maxime Ripard [this message]
2021-07-28 13:32 ` [PATCH v2 5/8] drm/panel: Create attach and detach callbacks Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 6/8] drm/vc4: dsi: Switch to drm_of_get_bridge Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 7/8] drm/panel: raspberrypi-touchscreen: Use the attach hook Maxime Ripard
2021-07-28 13:32 ` [PATCH v2 8/8] drm/panel: raspberrypi-touchscreen: Remove MIPI-DSI driver Maxime Ripard
[not found] ` <CGME20210804140941eucas1p2d4d4ec491074530c714797523aec05ea@eucas1p2.samsung.com>
2021-08-04 14:09 ` [PATCH v2 0/8] drm/bridge: Make panel and bridge probe order consistent a.hajda
2021-08-09 8:00 ` Jagan Teki
2021-08-09 12:03 ` Andrzej Hajda
2021-08-20 16:49 ` Maxime Ripard
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=20210728133229.2247965-5-maxime@cerno.tech \
--to=maxime@cerno.tech \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=narmstrong@baylibre.com \
--cc=robert.foss@linaro.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
--cc=tzimmermann@suse.de \
/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.