All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports
Date: Wed, 22 Dec 2021 11:47:03 +0200	[thread overview]
Message-ID: <87zgotx97s.fsf@intel.com> (raw)
In-Reply-To: <20211217155403.31477-7-ville.syrjala@linux.intel.com>

On Fri, 17 Dec 2021, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Lots of machines these days seem to have a crappy type1 DP dual
> mode adaptor chip slapped onto the motherboard. Based on the
> DP dual mode spec we currently limit those to 165MHz max TMDS
> clock.
>
> Windows OTOH ignores DP dual mode adaptors when the VBT
> indicates that the port is not actually DP++, so we can
> perhaps assume that the vendors did intend that the 165MHz
> clock limit doesn't apply here. Though it would be much
> nicer if they actually declared an explicit limit through
> VBT, but that doesn't seem to be happening either.
>
> So in order to match Windows behaviour let's ignore the
> DP dual mode adaptor's TMDS clock limit for ports that
> don't look like DP++ in VBT.
>
> Unfortunately many older VBTs misdelcare their DP++ ports
> as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB
> Lenovo ThinkPad X220). So we can't really do this universally
> without risking black screens. I suppose a sensible cutoff
> is HSW+ since that's when 4k became a thing and one might
> assume that the machines have been tested to work with higher
> TMDS clock rates.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Out of curiousity, on the machines where we are currently too strict on
the limitation, do we actually read and get a valid limit from the
adaptor in drm_dp_dual_mode_max_tmds_clock(), or is it the fallback 165
MHz that's too strict? If the latter, should the fallback policy be
moved out of drm_dp_dual_mode_max_tmds_clock() instead?

Anyway, seems that currently we're erring too far to lower limits to
avoid black screens, so seems okay to relax this a bit. ISTR we've had
quite a few bug reports about this.

Acked-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 3b5b9e7b05b7..9f0557d9e9a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2359,6 +2359,14 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
>  		    "DP dual mode adaptor (%s) detected (max TMDS clock: %d kHz)\n",
>  		    drm_dp_get_dual_mode_type_name(type),
>  		    hdmi->dp_dual_mode.max_tmds_clock);
> +
> +	/* Older VBTs are often buggy and can't be trusted :( Play it safe. */
> +	if ((DISPLAY_VER(dev_priv) >= 8 || IS_BROADWELL(dev_priv)) &&
> +	    !intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
> +		drm_dbg_kms(&dev_priv->drm,
> +			    "Ignoring DP dual mode adaptor max TMDS clock for native HDMI port\n");
> +		hdmi->dp_dual_mode.max_tmds_clock = 0;
> +	}
>  }
>  
>  static bool

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2021-12-22  9:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 15:53 [Intel-gfx] [PATCH 0/6] drm/i915: Extend parse_ddi_port() to all g4x+ platforms Ville Syrjala
2021-12-17 15:53 ` [Intel-gfx] [PATCH 1/6] drm/i915/bios: Introduce has_ddi_port_info() Ville Syrjala
2021-12-22  8:48   ` Jani Nikula
2021-12-17 15:53 ` [Intel-gfx] [PATCH 2/6] drm/i915/bios: Use i915->vbt.ports[] on CHV Ville Syrjala
2021-12-22  9:05   ` Jani Nikula
2021-12-22 12:49     ` Ville Syrjälä
2021-12-22  9:13   ` Jani Nikula
2021-12-17 15:54 ` [Intel-gfx] [PATCH 3/6] drm/i915/bios: Use i915->vbt.ports[] for all g4x+ Ville Syrjala
2021-12-22  9:19   ` Jani Nikula
2021-12-17 15:54 ` [Intel-gfx] [PATCH 4/6] drm/i915/bios: Throw out the !has_ddi_port_info() codepaths Ville Syrjala
2021-12-22  9:25   ` Jani Nikula
2021-12-17 15:54 ` [Intel-gfx] [PATCH 5/6] drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS Ville Syrjala
2021-12-22  9:34   ` Jani Nikula
2021-12-22 12:53     ` Ville Syrjälä
2021-12-17 15:54 ` [Intel-gfx] [PATCH 6/6] drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports Ville Syrjala
2021-12-22  9:47   ` Jani Nikula [this message]
2021-12-22 12:46     ` Ville Syrjälä
2021-12-22 15:38   ` Ville Syrjälä
2021-12-22 16:17   ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2021-12-17 17:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend parse_ddi_port() to all g4x+ platforms Patchwork
2021-12-17 19:56 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-12-22 17:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend parse_ddi_port() to all g4x+ platforms (rev2) Patchwork
2021-12-22 20:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-01-19 22:21 ` [Intel-gfx] [PATCH 0/6] drm/i915: Extend parse_ddi_port() to all g4x+ platforms Ville Syrjälä
2022-01-20 10:14   ` Jani Nikula

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=87zgotx97s.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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.