mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Andy Yan" <andyshrk@163.com>
To: "Maxime Ripard" <mripard@kernel.org>
Cc: "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,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	lumag@kernel.org
Subject: Re:Re:[PATCH v5 04/16] drm/atomic: Introduce helper to lookup connector by encoder
Date: Thu, 13 Mar 2025 16:09:54 +0800 (CST)	[thread overview]
Message-ID: <608c01c.7716.1958e8d879f.Coremail.andyshrk@163.com> (raw)
In-Reply-To: <5180089f.a640.19566290538.Coremail.andyshrk@163.com>



Hi Maxime,

At 2025-03-05 19:55:19, "Andy Yan" <andyshrk@163.com> wrote:
>
>
>Hi Maxime,
>
>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 ?
>
>
>
>[0]https://lore.kernel.org/linux-rockchip/047EECFC-7E55-44EC-896F-13FE04333E4D@gmail.com/T/#m25bc53b79f5cc7bddfcb7aae5656f68df396f094
>>+
>>+	drm_connector_list_iter_begin(dev, &conn_iter);
>>+	drm_for_each_connector_iter(connector, &conn_iter) {
>>+		if (!connector->state)
>>+			continue;
>>+
>>+		if (encoder == connector->state->best_encoder) {
>>+			out_connector = connector;


When try to use this patch in my bridge driver,  I found that the connector->state->best_encoder 
 maybe NULL when   drm_bridge_funcs.detect or drm_bridge_funcs.detect_ctx is  called:

[   52.713030] Invalid return value -22 for connector detection
[   52.713539] WARNING: CPU: 7 PID: 288 at drivers/gpu/drm/drm_probe_helper.c:602 drm_helper_probe_single_connector_modes+0x5e0/
0x63c
[   52.714568] Modules linked in:

[   52.724546] Call trace:
[   52.724762]  drm_helper_probe_single_connector_modes+0x5e0/0x63c (P)
[   52.725319]  drm_mode_getconnector+0x2a4/0x488
[   52.725711]  drm_ioctl_kernel+0xb4/0x11c
[   52.726057]  drm_ioctl+0x22c/0x544
[   52.726358]  __arm64_sys_ioctl+0xac/0xe0
[   52.726706]  invoke_syscall+0x44/0x100
[   52.727039]  el0_svc_common.constprop.0+0x3c/0xd4

This is because  best_encoder is set by set_best_encoder, which is called from
drm_atomic_helper_check_modeset. When we call drm_mode_getconnector 
for the first time, the functions mentioned above have not been called yet,
then we can't match the encoder from connector->state->best_encoder for this case.



>>+			break;
>>+		}
>>+	}
>>+	drm_connector_list_iter_end(&conn_iter);
>>+	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>>+
>>+	return out_connector;
>>+}
>>+EXPORT_SYMBOL(drm_atomic_get_connector_for_encoder);
>>+
>>+
>> /**

  parent reply	other threads:[~2025-03-13  8:10 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
2025-03-07 13:25                   ` Simona Vetter
2025-03-11  6:42                     ` Andy Yan
2025-03-13  8:09     ` Andy Yan [this message]
2025-03-13 11:55       ` 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=608c01c.7716.1958e8d879f.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=lumag@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®