All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: mei.fan.liou@intel.com, Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"LIOU, Mei Fan" <mei.fan.liou@intel.com>
Subject: Re: [PATCH] drm/i915: add disable_edp module parameter to skip phantom eDP init
Date: Tue, 30 Jun 2026 13:47:01 +0300	[thread overview]
Message-ID: <50700395af210f0e5ca0c5e8306cda41b077f43a@intel.com> (raw)
In-Reply-To: <20260630102845.2678707-1-mei.fan.liou@intel.com>

On Tue, 30 Jun 2026, mei.fan.liou@intel.com wrote:
> From: "LIOU, Mei Fan" <mei.fan.liou@intel.com>
>
> Some platforms have BIOS/VBT that declares an eDP panel present while
> no physical panel is connected. This causes intel_edp_init_connector()
> to spend ~6 seconds waiting on PPS power sequencer and AUX channel
> timeouts before failing gracefully.

Which platforms? This should not be the case.

> Introduce a new boolean module parameter 'disable_edp' (default: false)
> that allows users to skip eDP connector initialization entirely. When
> set, the driver logs an informational message and returns false early
> from intel_edp_init_connector(), bypassing all PPS/AUX probing.

I'm fine with adding module parameters for *debugging*. I'm not fine
with adding module parameters for regular use cases. If there are issues
out there, they should be root caused and fixed, worst case with a
quirk, but roughly never with a new module parameter.

You can also disable connectors using the video= parameter and connector
name, e.g. video=eDP-1:d or something. Making this work (if it doesn't)
should be preferred over adding new module parameters. And even here,
root causing and fixing is preferred.

> This is modeled after the existing 'disable_display' parameter and
> is intended as a workaround for headless or display-less deployments
> where the BIOS incorrectly advertises an internal panel.

"headless" and "display-less" are super ambiguous, given the amount of
possible alternatives. You might not have display IP at all, or you
could have everything except a display connected, or everything in
between. But VBT advertizing eDP but it not being connected is not a
scenario that we should have, and either the VBT or the whole setup is
bonkers.

Please file a bug as described at [1], and be sure to attach the dmesg
with debugs, and the VBT.


BR,
Jani.


[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html


>
> Signed-off-by: LIOU, Mei Fan <mei.fan.liou@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++
>  drivers/gpu/drm/i915/display/intel_display_params.h | 1 +
>  drivers/gpu/drm/i915/display/intel_dp.c             | 7 +++++++
>  3 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c b/drivers/gpu/drm/i915/display/intel_display_params.c
> index 2aed110c5b09..8d47d19b1667 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.c
> @@ -102,6 +102,9 @@ intel_display_param_named_unsafe(force_reset_modeset_test, bool, 0400,
>  intel_display_param_named(disable_display, bool, 0400,
>  	"Disable display (default: false)");
>  
> +intel_display_param_named(disable_edp, bool, 0400,
> +	"Disable eDP panel init, skips PPS/AUX probing when VBT declares eDP but no panel is present (default: false)");
> +
>  intel_display_param_named(verbose_state_checks, bool, 0400,
>  	"Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions.");
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h b/drivers/gpu/drm/i915/display/intel_display_params.h
> index b95ecf728daa..98ab0d753dab 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_params.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_params.h
> @@ -41,6 +41,7 @@ struct drm_printer;
>  	param(bool, load_detect_test, false, 0600) \
>  	param(bool, force_reset_modeset_test, false, 0600) \
>  	param(bool, disable_display, false, 0400) \
> +	param(bool, disable_edp, false, 0400) \
>  	param(bool, verbose_state_checks, true, 0400) \
>  	param(bool, nuclear_pageflip, false, 0400) \
>  	param(bool, enable_dp_mst, true, 0600) \
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 85d3aa3b9894..c6293a1b3840 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -7214,6 +7214,13 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>  	if (!intel_dp_is_edp(intel_dp))
>  		return true;
>  
> +	if (display->params.disable_edp) {
> +		drm_info(display->drm,
> +			 "[ENCODER:%d:%s] eDP disabled by module parameter, skipping init\n",
> +			 encoder->base.base.id, encoder->base.name);
> +		return false;
> +	}
> +
>  	/*
>  	 * On IBX/CPT we may get here with LVDS already registered. Since the
>  	 * driver uses the only internal power sequencer available for both

-- 
Jani Nikula, Intel

  reply	other threads:[~2026-06-30 10:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 10:28 [PATCH] drm/i915: add disable_edp module parameter to skip phantom eDP init mei.fan.liou
2026-06-30 10:28 ` mei.fan.liou
2026-06-30 10:47 ` Jani Nikula [this message]
2026-07-02 11:07   ` Liou, Mei Fan
2026-07-02 11:48     ` Jani Nikula
2026-06-30 11:24 ` ✗ CI.checkpatch: warning for " Patchwork
2026-06-30 11:26 ` ✓ CI.KUnit: success " Patchwork
2026-06-30 12:09 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-30 13:47 ` ✓ i915.CI.BAT: " Patchwork
2026-06-30 23:13 ` ✗ i915.CI.Full: failure " Patchwork
2026-07-01  1:51 ` ✓ Xe.CI.FULL: success " Patchwork

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=50700395af210f0e5ca0c5e8306cda41b077f43a@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mei.fan.liou@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=tursulin@ursulin.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.