Hi Andy,
On Wed, Mar 05, 2025 at 07:55:19PM +0800, Andy Yan wrote:
> At 2025-03-04 19:10:47, "Maxime Ripard" <mripard@xxxxxxxxxx> wrote:
> >With the bridges switching over to drm_bridge_connector, the direct
> >association between a bridge driver and its connector was lost.
> >
> >This is mitigated for atomic bridge drivers by the fact you can access
> >the encoder, and then call drm_atomic_get_old_connector_for_encoder() or
> >drm_atomic_get_new_connector_for_encoder() with drm_atomic_state.
> >
> >This was also made easier by providing drm_atomic_state directly to all
> >atomic hooks bridges can implement.
> >
> >However, bridge drivers don't have a way to access drm_atomic_state
> >outside of the modeset path, like from the hotplug interrupt path or any
> >interrupt handler.
> >
> >Let's introduce a function to retrieve the connector currently assigned
> >to an encoder, without using drm_atomic_state, to make these drivers'
> >life easier.
> >
> >Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> >Co-developed-by: Simona Vetter <simona.vetter@xxxxxxxx>
> >Signed-off-by: Maxime Ripard <mripard@xxxxxxxxxx>
> >---
> > drivers/gpu/drm/drm_atomic.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
> > include/drm/drm_atomic.h | 3 +++
> > 2 files changed, 48 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >index 9ea2611770f43ce7ccba410406d5f2c528aab022..b926b132590e78f8d41d48eb4da4bccf170ee236 100644
> >--- a/drivers/gpu/drm/drm_atomic.c
> >+++ b/drivers/gpu/drm/drm_atomic.c
> >@@ -985,10 +985,55 @@ drm_atomic_get_new_connector_for_encoder(const struct drm_atomic_state *state,
> >
> > return NULL;
> > }
> > EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
> >
> >+/**
> >+ * drm_atomic_get_connector_for_encoder - Get connector currently assigned to an encoder
> >+ * @encoder: The encoder to find the connector of
> >+ * @ctx: Modeset locking context
> >+ *
> >+ * This function finds and returns the connector currently assigned to
> >+ * an @encoder.
> >+ *
> >+ * Returns:
> >+ * The connector connected to @encoder, or an error pointer otherwise.
> >+ * When the error is EDEADLK, a deadlock has been detected and the
> >+ * sequence must be restarted.
> >+ */
> >+struct drm_connector *
> >+drm_atomic_get_connector_for_encoder(const struct drm_encoder *encoder,
> >+ struct drm_modeset_acquire_ctx *ctx)
> >+{
> >+ struct drm_connector_list_iter conn_iter;
> >+ struct drm_connector *out_connector = ERR_PTR(-EINVAL);
> >+ struct drm_connector *connector;
> >+ struct drm_device *dev = encoder->dev;
> >+ int ret;
> >+
> >+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> >+ if (ret)
> >+ return ERR_PTR(ret);
>
> It seems that this will cause a deadlock when called from a hotplug
> handling path, I have a WIP DP diver[0], which suggested by Dmitry to
> use this API from a &drm_bridge_funcs.detect callback to get the
> connector, as detect is called by drm_helper_probe_detect, which will
> hold connection_mutex first, so the deaklock happens:
>
> drm_helper_probe_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> bool force)
> {
> const struct drm_connector_helper_funcs *funcs = connector->helper_private;
> struct drm_device *dev = connector->dev;
> int ret;
>
> if (!ctx)
> return drm_helper_probe_detect_ctx(connector, force);
>
> ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> if (ret)
> return ret;
>
> if (funcs->detect_ctx)
> ret = funcs->detect_ctx(connector, ctx, force);
> else if (connector->funcs->detect)
> ret = connector->funcs->detect(connector, force);
> else
> ret = connector_status_connected;
>
> if (ret != connector->status)
> connector->epoch_counter += 1;
>
> So I wonder can we let drm_bridge_funcs.detect pass a connector for
> this case ?
Do you actually see a deadlock occurring? AFAIK, drm_modeset_lock is
fine with reentrancy from the same context, so it should work just fine.
Maxime
Attachment:
signature.asc
Description: PGP signature
