public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/probe-helper: honour connector->force in drm_helper_probe_detect()
Date: Tue, 26 May 2026 19:58:59 +0300	[thread overview]
Message-ID: <f167bfecbf7054005ec67eebd96044846812ae8c@intel.com> (raw)
In-Reply-To: <20260526152025.12530-2-pmenzel@molgen.mpg.de>

On Tue, 26 May 2026, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> With `video=DP-2:d drm.debug=0x04` the connectors are correctly forced
> off at init time:
>
>     [9.742468] [drm] forcing DP-2 connector off
>
> but `intel_dp_detect()` is still called immediately after:
>
>     [9.908738] [drm:intel_dp_detect] [CONNECTOR:130:DP-2]
>     [9.912982] [drm:intel_hotplug_detect_connector] [CONNECTOR:130:DP-2] status updated from unknown to unknown (epoch counter 0->1)
>
> `drm_helper_probe_single_connector_modes()` already short-circuits when
> `connector->force` is set, returning the forced status without calling
> any detect callbacks.  `drm_helper_probe_detect()` however has no such
> guard, so callers that go through it directly – such as i915's
> `intel_hotplug_detect_connector()` – still run the full hardware probe
> (AUX DPCD read, GMBus DDC transaction, …) even when the user has
> forced a connector off via the `video=` command-line parameter.

Note that drm_helper_probe_single_connector_modes() still calls the
->force hook, which is crucial.

Returning early for force off may be fine, but force on will still need
to try to read the EDID. And the EDID reads return early for force off.

Side note, please drop the excessive backticks and the ellipsis from
commit messages.

BR,
Jani.

>
> Add the same connector->force check at the top of
> `drm_helper_probe_detect()`, so that the hardware probe is skipped
> regardless of the entry point.  This makes `video=<connector>:d`
> effective at boot time, not just for userspace `GETCONNECTOR` ioctls.
>
> This is tested on a Dell XPS 13 9360 (Intel Kaby Lake-U GT2 [HD Graphics
> 620] [8086:5916]). With `video=DP-2:d drm.debug=0x04`, Linux logs:
>
>     [   11.701243] [drm] forcing DP-2 connector off
>     [   11.701245] [drm:drm_connector_init_only [drm]] cmdline mode for connector DP-2  0x0@60Hz
>     […]
>     [   12.102009] i915 0000:00:02.0: [drm:drm_helper_probe_detect [drm_kms_helper]] [CONNECTOR:130:DP-2] force=1, skipping detect
>
> Assisted-by: Claude Sonnet 4.6
> Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index d4dc8cb45bce..bc513f24bc28 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -401,6 +401,17 @@ drm_helper_probe_detect(struct drm_connector *connector,
>  	struct drm_device *dev = connector->dev;
>  	int ret;
>  
> +	if (connector->force) {
> +		drm_dbg_kms(dev, "[CONNECTOR:%d:%s] force=%d, skipping detect\n",
> +			     connector->base.id, connector->name,
> +			     connector->force);
> +		if (connector->force == DRM_FORCE_ON ||
> +		    connector->force == DRM_FORCE_ON_DIGITAL)
> +			return connector_status_connected;
> +		else
> +			return connector_status_disconnected;
> +	}
> +
>  	if (!ctx)
>  		return drm_helper_probe_detect_ctx(connector, force);

-- 
Jani Nikula, Intel

  reply	other threads:[~2026-05-26 16:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 15:20 [PATCH] drm/probe-helper: honour connector->force in drm_helper_probe_detect() Paul Menzel
2026-05-26 16:58 ` Jani Nikula [this message]
2026-05-27  4:37 ` Claude review: " Claude Code Review Bot
2026-05-27  4:37 ` Claude Code Review Bot

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=f167bfecbf7054005ec67eebd96044846812ae8c@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --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