From nobody Mon Jun 8 20:53:15 2026 Received: from mx3.molgen.mpg.de (mx3.molgen.mpg.de [141.14.17.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E385F318B9D for ; Tue, 26 May 2026 19:21:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=141.14.17.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779823306; cv=none; b=PO0DGYDOoTQ+954XBYgF2MsapE8mDAtQDLZMGjflhoy/P3FHlRSDQ1jHmzBoQ3cQ/45IkC3nUZWv6HZ7qEdL7nVNbLEpQa9FJrLH1Qg/ZYlX7SOo/vbXrRRq6vQdT3V+oSSXvcWKFyRh1siYEkJ0Ax8T0Pow9qxuSV3cjt6EXpk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779823306; c=relaxed/simple; bh=k+B9kg/HKkOlv22rF9yhTdZSyVuGXlPhoNxruVgF8zE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Koqde7xNhGb8chfwfTuZ1lCmjNv1YXFiFJDwHSUCb6b5UhS4ee+RWtbOad+q2Tl/aOGTLhDQtH5GVat5Dib/w1LLgT26s97yoLyJtm1So5tlgXfc5g6lGuBMsE/qsOSEi2JIqXYkGec5DPVgLmEDKpuJ60O7t8vtRewoCbBbDT0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=molgen.mpg.de; spf=pass smtp.mailfrom=molgen.mpg.de; arc=none smtp.client-ip=141.14.17.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=molgen.mpg.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=molgen.mpg.de Received: from abreu (ip5f5af0d1.dynamic.kabel-deutschland.de [95.90.240.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id CBF084C1511A9A; Tue, 26 May 2026 21:21:09 +0200 (CEST) From: Paul Menzel To: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Cc: Paul Menzel , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] drm/probe-helper: honour connector->force in drm_helper_probe_detect() Date: Tue, 26 May 2026 21:18:11 +0200 Message-ID: <20260526191812.30542-2-pmenzel@molgen.mpg.de> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable With `video=3DDP-2:d drm.debug=3D0x04` 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] st= atus 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 =E2=80=93 such as i915=E2=80=99s intel_hotplug_detect_connector() =E2=80=93 still run the full hardware prob= e (AUX DPCD read, GMBus DDC transaction, ...) even when the user has forced a connector off via the `video=3D` command-line parameter. Add the same connector->force check for forced off connectors at the top of drm_helper_probe_detect(), so that the hardware probe is skipped regardless of the entry point. This makes video=3D:d effective at boot tim= e, not just for userspace GETCONNECTOR ioctls. DRM_FORCE_ON and DRM_FORCE_ON_DIGITAL are intentionally not short- circuited here: for those cases the detect callback must still run to initialise sink capabilities such as DPCD link rate and lane count. Tested on a Dell XPS 13 9360 (Intel Kaby Lake-U GT2 [HD Graphics 620] [8086:5916]). With `video=3DDP-2:d drm.debug=3D0x04, Linux logs: [ 11.701243] [drm] forcing DP-2 connector off [...] [ 12.102009] i915 0000:00:02.0: [drm:drm_helper_probe_detect [drm_kms= _helper]] [CONNECTOR:130:DP-2] forced off, skipping detect v2: Do not return early for DRM_FORCE_ON and DRM_FORCE_ON_DIGITAL (Jani, gemini/gemini-3.1-pro-preview) Assisted-by: Claude Sonnet 4.6 Signed-off-by: Paul Menzel --- drivers/gpu/drm/drm_probe_helper.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe= _helper.c index d4dc8cb45bce..b657ae109f98 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -401,6 +401,12 @@ drm_helper_probe_detect(struct drm_connector *connecto= r, struct drm_device *dev =3D connector->dev; int ret; =20 + if (connector->force) { + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] forced off, skipping detect\n", + connector->base.id, connector->name); + return connector_status_disconnected; + } + if (!ctx) return drm_helper_probe_detect_ctx(connector, force); =20 --=20 2.53.0