mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Andy Yan" <andyshrk@163.com>
To: "Simona Vetter" <simona.vetter@ffwll.ch>
Cc: "Maxime Ripard" <mripard@kernel.org>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"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>,
	"Douglas Anderson" <dianders@chromium.org>,
	"Herve Codina" <herve.codina@bootlin.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re:Re:Re: [PATCH v5 04/16] drm/atomic: Introduce helper to lookup connector by encoder
Date: Fri, 7 Mar 2025 15:30:41 +0800 (CST)	[thread overview]
Message-ID: <2e1a98a6.69b3.1956f837872.Coremail.andyshrk@163.com> (raw)
In-Reply-To: <35189f31.c6a.1956e25d8c9.Coremail.andyshrk@163.com>


Hi All,
At 2025-03-07 09:08:48, "Andy Yan" <andyshrk@163.com> wrote:
>Hi All,
>
>At 2025-03-06 23:41:24, "Simona Vetter" <simona.vetter@ffwll.ch> wrote:
>>On Thu, Mar 06, 2025 at 08:10:16AM +0100, Maxime Ripard wrote:
>>> On Thu, Mar 06, 2025 at 09:16:24AM +0800, Andy Yan wrote:
>>> > 
>>> > Hi Maxime and Dmitry:
>>> > 
>>> > At 2025-03-06 04:13:53, "Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> wrote:
>>> > >On Wed, Mar 05, 2025 at 02:19:36PM +0100, Maxime Ripard wrote:
>>> > >> 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@kernel.org> 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@linaro.org>
>>> > >> > >Co-developed-by: Simona Vetter <simona.vetter@ffwll.ch>
>>> > >> > >Signed-off-by: Maxime Ripard <mripard@kernel.org>
>>> > >> > >---
>>> > >> > > 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.
>>> > >
>>> > >Andy, that probably means that you should use .detect_ctx() and pass the
>>> > >context to drm_atomic_get_connector_for_encoder().
>>> > 
>>> > Unfortunately, the drm_bridge_funcs does not have a .detect_ctx()  version .
>>> > The call chain is:
>>> >  drm_helper_probe_detect 
>>> >  --> drm_bridge_connector_detect(struct drm_connector *connector, bool force)
>>> > --> drm_bridge_funcs.detect(bridge)
>>> > The ctx got dropped when drm_helper_probe_detect call  drm_bridge_connector_detect
>>> > The connector got dropped  when connector call it's bridege.detect
>>> > 
>>> > So I think the simplest solution is to have drm_bridge_funcs.detect
>>> > directly pass the connector
>>> 
>>> I don't disagree on principle, but I think a better first step would be
>>> to provide a detect_ctx hook to bridges.
>>
>>Yup. There's other reasons you really want to get at the locking context
>>in detect callbacks, doing this special case by passing something for
>>everyone doesn't sound like the right approach to me.
>
>Ok, I will add a detect_ctx  hook for bridge. Thanks for your advice.
>
>Just confirm that can I send this add detect_ctx hook patch alone first? 
>I think this patch will be easy to merge,  so it can help my WIP DP driver stay light on dependencies。

When I try to add the detect_ctx hook to bridge, I found that there is still a case that there is no ctx to
pass to detect_ctx:

int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
                                            uint32_t maxX, uint32_t maxY)
{
        ...............
        struct drm_modeset_acquire_ctx ctx;

        WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));

        drm_modeset_acquire_init(&ctx, 0);

        drm_dbg_kms(dev, "[CONNECTOR:%d:%s]\n", connector->base.id,
                    connector->name);

retry:
        ret = drm_modeset_lock(&dev->mode_config.connection_mutex, &ctx);
        ...................
       ret = drm_helper_probe_detect(connector, &ctx, true);
       ......................................

     count = drm_helper_probe_get_modes(connector);

Then in drm_bridge_connector_get_modes:

static int drm_bridge_connector_get_modes(struct drm_connector *connector)
{
        struct drm_bridge_connector *bridge_connector =
                to_drm_bridge_connector(connector);
        struct drm_bridge *bridge;

   ...........................................
        /*
         * If display exposes EDID, then we parse that in the normal way to
         * build table of supported modes.
         */
        bridge = bridge_connector->bridge_edid;
        if (bridge)
                return drm_bridge_connector_get_modes_edid(connector, bridge);

static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
                                               struct drm_bridge *bridge)
{
        enum drm_connector_status status;
        const struct drm_edid *drm_edid;
        int n;

        status = drm_bridge_connector_detect(connector, false);

......................

-drm_bridge_connector_detect(struct drm_connector *connector, bool force)
+drm_bridge_connector_detect(struct drm_connector *connector,
+                           struct drm_modeset_acquire_ctx *ctx,
+                           bool force)
 {
        struct drm_bridge_connector *bridge_connector =
                to_drm_bridge_connector(connector);
@@ -186,7 +188,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force)
        enum drm_connector_status status;
 
        if (detect) {
               status = detect->funcs->detect(detect, ctx);

There is still no ctx in this call chain.

So there will be deadlock if I use drm_atomic_get_new_connector_for_encoder to find connector in
my bridge detect_ctx hook.



>
>
>>-Sima
>>-- 
>>Simona Vetter
>>Software Engineer, Intel Corporation
>>http://blog.ffwll.ch

  reply	other threads:[~2025-03-07  7:31 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04 11:10 [PATCH v5 00/16] drm/bridge: Various quality of life improvements Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 01/16] drm/bridge: Add encoder parameter to drm_bridge_funcs.attach Maxime Ripard
2025-03-05 13:04   ` Luca Ceresoli
2025-03-04 11:10 ` [PATCH v5 02/16] drm/bridge: Provide a helper to retrieve current bridge state Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 03/16] drm/tests: Add kunit tests for bridges Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 04/16] drm/atomic: Introduce helper to lookup connector by encoder Maxime Ripard
2025-03-05 11:55   ` Andy Yan
2025-03-05 13:19     ` [PATCH " Maxime Ripard
2025-03-05 20:13       ` Dmitry Baryshkov
2025-03-06  1:16         ` Andy Yan
2025-03-06  7:10           ` Maxime Ripard
2025-03-06 15:41             ` Simona Vetter
2025-03-07  1:08               ` Andy Yan
2025-03-07  7:30                 ` Andy Yan [this message]
2025-03-07 13:25                   ` Simona Vetter
2025-03-11  6:42                     ` Andy Yan
2025-03-13  8:09     ` Andy Yan
2025-03-13 11:55       ` [PATCH " Maxime Ripard
2025-03-14  0:50         ` Andy Yan
2025-03-14  5:52           ` Dmitry Baryshkov
2025-03-14  7:45             ` Maxime Ripard
2025-03-14  7:59               ` Dmitry Baryshkov
2025-03-14 17:40                 ` Maxime Ripard
2025-03-14 18:28                   ` Dmitry Baryshkov
2025-03-18 15:51                     ` Maxime Ripard
2025-03-18 19:00                       ` Dmitry Baryshkov
2025-03-19  7:21                         ` Andy Yan
2025-03-21  9:46                         ` Maxime Ripard
2025-03-23  2:22                           ` Dmitry Baryshkov
2025-04-08  3:44                             ` Andy Yan
2025-05-24  8:09                             ` Dmitry Baryshkov
2025-06-19 13:09                               ` Maxime Ripard
2025-07-01  6:21                                 ` Andy Yan
2025-07-01  7:16                                   ` Dmitry Baryshkov
2025-03-06  8:21   ` Herve Codina
2025-03-06 15:44   ` Simona Vetter
2025-03-04 11:10 ` [PATCH v5 05/16] drm/tests: helpers: Create new helper to enable output Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 06/16] drm/tests: hdmi_state_helpers: Switch to new helper Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 07/16] drm/tests: Create tests for drm_atomic Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 08/16] drm/bridge: Add helper to reset bridge pipeline Maxime Ripard
2025-03-06  8:12   ` Herve Codina
2025-03-06 15:46   ` Simona Vetter
2025-03-04 11:10 ` [PATCH v5 09/16] drm/tests: bridge: Provide tests for drm_bridge_helper_reset_crtc Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 10/16] drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc Maxime Ripard
2025-03-06  8:09   ` Herve Codina
2025-03-04 11:10 ` [PATCH v5 11/16] drm/bridge: Introduce drm_bridge_is_atomic() helper Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 12/16] drm/bridge: cdns-csi: Switch to atomic helpers Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 13/16] drm/bridge: tc358775: Switch to atomic commit Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 14/16] drm/bridge: tc358768: Stop disabling when failing to enable Maxime Ripard
2025-03-06 15:48   ` Simona Vetter
2025-03-04 11:10 ` [PATCH v5 15/16] drm/bridge: tc358768: Convert to atomic helpers Maxime Ripard
2025-03-04 11:10 ` [PATCH v5 16/16] drm/bridge: ti-sn65dsi86: Remove drm_encoder->crtc use 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=2e1a98a6.69b3.1956f837872.Coremail.andyshrk@163.com \
    --to=andyshrk@163.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=herve.codina@bootlin.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®