[RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[Conor Svensson]

Reconnecting an Anker 565 A8388 USB-C hub with a DisplayPort monitor
attached can leave the branch reporting a DVI downstream descriptor
with 25-165 MHz TMDS limits. On a ThinkPad L14 Gen 4 Intel with a Dell
S3422DWG, this removes the native 3440x1440 mode from the connector's
mode list even though the EDID still contains it. An explicit native
modeline works with the same hardware state.

Ignore the derived TMDS limits only for the captured branch identity,
firmware and downstream descriptor when EDID 1.4 identifies a digital
DisplayPort input. Retain the raw descriptor and other mode checks.
Do not restrict the match to a particular monitor or laptop model.

With otherwise matching upstream Linux 7.2.5 control/patched builds,
the control loses native modes after USB-C reconnect, while the patched
kernel selects 3440x1440 at 59.973 Hz automatically. Repeated reconnects,
both USB-C ports, suspend/resume, undocking while asleep and docked boot
pass. HDMI also works and does not activate the workaround. Periodic
picture cycling observed on the control stops with the patch.

The branch identity is not proven unique to this retail adapter. This
is an experimental workaround for review, not an explanation of why the
branch reports inconsistent capabilities. Other adapters and monitors
have not been tested.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180
Assisted-by: LLM
Signed-off-by: Conor Svensson <conor10@gmail.com>
---
RFC: is this best handled as a branch quirk here, or in the common DP
helpers? The captured identity and descriptor match is deliberately narrow;
there is no monitor/laptop model restriction. The informational log marker
is retained to show exactly when this experimental workaround executes.
The commit introducing the underlying problem has not been identified, so
there is no speculative Fixes tag.

Hardware A/B testing used upstream Linux 7.2.5 with otherwise identical
configurations. This RFC applies the same 48 added lines to drm-tip at the
base commit below. This drm-tip revision has not been boot-tested. The affected intel_dp.o
compiles successfully here with no compiler warnings; strict checkpatch
passes (human sign-off pending), and 426 predicate boundary cases pass
with ASan/UBSan. These predicate tests are not DRM integration tests.

Results: three USB-C reconnects, alternate USB-C port, docked s2idle
resume plus reconnect, undock while asleep/wake/reconnect, and docked
DisplayPort reboot all passed. HDMI also passed without activating the
workaround. The control lost native modes and showed periodic picture
cycling; that cycling stopped on the patched kernel. No custom modeline
was used in either test kernel. Other hardware and higher refresh rates
remain untested.

AI assistance: Codex (GPT-6) helped investigate the reported hotplug
failure, wrote the match/limit-clearing change, prepared the predicate
tests, collected diagnostics and drafted this message. The human reporter
performed the physical reconnect, suspend and reboot tests and confirmed
the visible results. The assistance arose from an extended troubleshooting
session, rather than a single code-generation prompt.

Evidence and detailed test results:
https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3677750

This is my first kernel patch submission. I'd appreciate feedback on
whether this belongs here or in the common DP helpers, and whether the
matching criteria are appropriate.

Thanks,
Conor

 drivers/gpu/drm/i915/display/intel_dp.c | 48 +++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ffddf4b33..6d6767ca7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6153,6 +6153,39 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
 	return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc);
 }
 
+static bool
+intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp,
+				 const struct drm_edid *drm_edid)
+{
+	static const struct drm_dp_dpcd_ident branch = {
+		.oui = { 0x90, 0xcc, 0x24 },
+		.device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 },
+		.hw_rev = 0x10,
+		.sw_major_rev = 0x06,
+		.sw_minor_rev = 0x05,
+	};
+	static const u8 downstream_ports[] = {
+		0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+	};
+	const struct edid *edid = drm_edid_raw(drm_edid);
+
+	if (intel_dp_is_edp(intel_dp) || intel_dp->is_mst ||
+	    !drm_dp_is_branch(intel_dp->dpcd) || !edid)
+		return false;
+
+	/* HDMI and DVI inputs must retain their downstream limits. */
+	if (edid->version != 1 || edid->revision < 4 ||
+	    !(edid->input & DRM_EDID_INPUT_DIGITAL) ||
+	    (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) != DRM_EDID_DIGITAL_TYPE_DP)
+		return false;
+
+	return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) &&
+		!memcmp(intel_dp->downstream_ports, downstream_ports,
+			sizeof(downstream_ports)) &&
+		intel_dp->dfp.min_tmds_clock == 25000 &&
+		intel_dp->dfp.max_tmds_clock == 165000;
+}
+
 static void
 intel_dp_update_dfp(struct intel_dp *intel_dp,
 		    const struct drm_edid *drm_edid)
@@ -6181,6 +6214,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
 		drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
 					   intel_dp->downstream_ports);
 
+	/*
+	 * Experimental workaround for the branch observed in an Anker A8388.
+	 * USB-C hotplug can expose a DVI descriptor for the DP output. The
+	 * monitor's native timing works when requested explicitly, despite
+	 * the reported 165 MHz limit. Keep the captured identity and failure
+	 * signature checks narrow until the underlying cause is understood.
+	 */
+	if (intel_dp_has_anker_tmds_mismatch(intel_dp, drm_edid)) {
+		intel_dp->dfp.min_tmds_clock = 0;
+		intel_dp->dfp.max_tmds_clock = 0;
+		drm_info(display->drm,
+			 "[CONNECTOR:%d:%s] experimental Anker DP TMDS limit workaround\n",
+			 connector->base.base.id, connector->base.name);
+	}
+
 	drm_dbg_kms(display->drm,
 		    "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS clock %d-%d, PCON Max FRL BW %dGbps\n",
 		    connector->base.base.id, connector->base.name,

base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04
-- 
2.55.0

Re: [RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] drm/i915/dp: incomplete downstream ports signature match
--

commit 025075775ae9b93d6ea2089caff0dfbc102027cd
Author: Conor Svensson <conor10@gmail.com>

drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

This commit adds an experimental workaround to clear derived TMDS limits
for a specific Anker DP branch device that reports inconsistent capabilities
when hotplugged, which can cause the loss of native modes.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180

> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0cd5e6b5034cf..beba989860056 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
[ ... ]
> +static bool
> +intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp,
> +				 const struct drm_edid *drm_edid)
> +{
> +	static const struct drm_dp_dpcd_ident branch = {
> +		.oui = { 0x90, 0xcc, 0x24 },
> +		.device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 },
> +		.hw_rev = 0x10,
> +		.sw_major_rev = 0x06,
> +		.sw_minor_rev = 0x05,
> +	};
> +	static const u8 downstream_ports[] = {
> +		0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	};
[ ... ]
> +	return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) &&
> +		!memcmp(intel_dp->downstream_ports, downstream_ports,
> +			sizeof(downstream_ports)) &&

[Severity: Low]
Does this comparison in intel_dp_has_anker_tmds_mismatch() strictly validate
the entire downstream port state as intended?

Because the local downstream_ports array is defined with only 8 elements,
sizeof(downstream_ports) evaluates to 8. However, intel_dp->downstream_ports
is a 16-byte array (DP_MAX_DOWNSTREAM_PORTS).

This partial match could theoretically trigger the quirk on a different device
that shares the same firmware and first 8 bytes of port capabilities but
differs in the remaining 8 bytes, which seems contrary to the deliberately
narrow intent described in the commit message.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923221018.42133-1-conor10@gmail.com?part=1

Re: [RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[Jani Nikula]

On Wed, 23 Sep 2026, Conor Svensson <conor10@gmail.com> wrote:
> Reconnecting an Anker 565 A8388 USB-C hub with a DisplayPort monitor
> attached can leave the branch reporting a DVI downstream descriptor
> with 25-165 MHz TMDS limits. On a ThinkPad L14 Gen 4 Intel with a Dell
> S3422DWG, this removes the native 3440x1440 mode from the connector's
> mode list even though the EDID still contains it. An explicit native
> modeline works with the same hardware state.
>
> Ignore the derived TMDS limits only for the captured branch identity,
> firmware and downstream descriptor when EDID 1.4 identifies a digital
> DisplayPort input. Retain the raw descriptor and other mode checks.
> Do not restrict the match to a particular monitor or laptop model.
>
> With otherwise matching upstream Linux 7.2.5 control/patched builds,
> the control loses native modes after USB-C reconnect, while the patched
> kernel selects 3440x1440 at 59.973 Hz automatically. Repeated reconnects,
> both USB-C ports, suspend/resume, undocking while asleep and docked boot
> pass. HDMI also works and does not activate the workaround. Periodic
> picture cycling observed on the control stops with the patch.
>
> The branch identity is not proven unique to this retail adapter. This
> is an experimental workaround for review, not an explanation of why the
> branch reports inconsistent capabilities. Other adapters and monitors
> have not been tested.
>
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180
> Assisted-by: LLM
> Signed-off-by: Conor Svensson <conor10@gmail.com>
> ---
> RFC: is this best handled as a branch quirk here, or in the common DP
> helpers? The captured identity and descriptor match is deliberately narrow;
> there is no monitor/laptop model restriction. The informational log marker
> is retained to show exactly when this experimental workaround executes.
> The commit introducing the underlying problem has not been identified, so
> there is no speculative Fixes tag.
>
> Hardware A/B testing used upstream Linux 7.2.5 with otherwise identical
> configurations. This RFC applies the same 48 added lines to drm-tip at the
> base commit below. This drm-tip revision has not been boot-tested. The affected intel_dp.o
> compiles successfully here with no compiler warnings; strict checkpatch
> passes (human sign-off pending), and 426 predicate boundary cases pass
> with ASan/UBSan. These predicate tests are not DRM integration tests.
>
> Results: three USB-C reconnects, alternate USB-C port, docked s2idle
> resume plus reconnect, undock while asleep/wake/reconnect, and docked
> DisplayPort reboot all passed. HDMI also passed without activating the
> workaround. The control lost native modes and showed periodic picture
> cycling; that cycling stopped on the patched kernel. No custom modeline
> was used in either test kernel. Other hardware and higher refresh rates
> remain untested.
>
> AI assistance: Codex (GPT-6) helped investigate the reported hotplug
> failure, wrote the match/limit-clearing change, prepared the predicate
> tests, collected diagnostics and drafted this message. The human reporter
> performed the physical reconnect, suspend and reboot tests and confirmed
> the visible results. The assistance arose from an extended troubleshooting
> session, rather than a single code-generation prompt.
>
> Evidence and detailed test results:
> https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3677750
>
> This is my first kernel patch submission. I'd appreciate feedback on
> whether this belongs here or in the common DP helpers, and whether the
> matching criteria are appropriate.

Thanks for the patch. Please let's first root cause the issue (on the
gitlab issue) before jumping into quirking specific devices.

Regardless, a few comments below.

>
> Thanks,
> Conor
>
>  drivers/gpu/drm/i915/display/intel_dp.c | 48 +++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index ffddf4b33..6d6767ca7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6153,6 +6153,39 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
>  	return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc);
>  }
>  
> +static bool
> +intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp,
> +				 const struct drm_edid *drm_edid)
> +{
> +	static const struct drm_dp_dpcd_ident branch = {
> +		.oui = { 0x90, 0xcc, 0x24 },
> +		.device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 },
> +		.hw_rev = 0x10,
> +		.sw_major_rev = 0x06,
> +		.sw_minor_rev = 0x05,
> +	};
> +	static const u8 downstream_ports[] = {
> +		0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	};

intel_dp->downstream_ports is read from DPCD address 0x80, and it
dynamically reflects the downstream port information, i.e. what's
currently connected to the branch device. Having a fixed comparison like
this will only work for a specific type of downstream device connected
to a specific downstream port.

> +	const struct edid *edid = drm_edid_raw(drm_edid);

No new drm_edid_raw() calls are to be added.

> +
> +	if (intel_dp_is_edp(intel_dp) || intel_dp->is_mst ||
> +	    !drm_dp_is_branch(intel_dp->dpcd) || !edid)
> +		return false;
> +
> +	/* HDMI and DVI inputs must retain their downstream limits. */
> +	if (edid->version != 1 || edid->revision < 4 ||
> +	    !(edid->input & DRM_EDID_INPUT_DIGITAL) ||
> +	    (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) != DRM_EDID_DIGITAL_TYPE_DP)
> +		return false;
> +
> +	return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) &&
> +		!memcmp(intel_dp->downstream_ports, downstream_ports,
> +			sizeof(downstream_ports)) &&
> +		intel_dp->dfp.min_tmds_clock == 25000 &&
> +		intel_dp->dfp.max_tmds_clock == 165000;
> +}

We have intel_quirks.c with various structured mechanisms for
identifying quirks. If we end up needing a quirk for this, the existing
mechanisms need to be used instead of adding a bunch of code inline like
this.

Again, please let's first root cause and debug the issue instead of
trying to fix the patch.

BR,
Jani.


> +
>  static void
>  intel_dp_update_dfp(struct intel_dp *intel_dp,
>  		    const struct drm_edid *drm_edid)
> @@ -6181,6 +6214,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
>  		drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
>  					   intel_dp->downstream_ports);
>  
> +	/*
> +	 * Experimental workaround for the branch observed in an Anker A8388.
> +	 * USB-C hotplug can expose a DVI descriptor for the DP output. The
> +	 * monitor's native timing works when requested explicitly, despite
> +	 * the reported 165 MHz limit. Keep the captured identity and failure
> +	 * signature checks narrow until the underlying cause is understood.
> +	 */
> +	if (intel_dp_has_anker_tmds_mismatch(intel_dp, drm_edid)) {
> +		intel_dp->dfp.min_tmds_clock = 0;
> +		intel_dp->dfp.max_tmds_clock = 0;
> +		drm_info(display->drm,
> +			 "[CONNECTOR:%d:%s] experimental Anker DP TMDS limit workaround\n",
> +			 connector->base.base.id, connector->base.name);
> +	}
> +
>  	drm_dbg_kms(display->drm,
>  		    "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS clock %d-%d, PCON Max FRL BW %dGbps\n",
>  		    connector->base.base.id, connector->base.name,
>
> base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04

-- 
Jani Nikula, Intel

Re: [RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[Conor Svensson]

[-- Attachment #1: Type: text/plain, Size: 9058 bytes --]

Hi Jani,

Thanks for the guidance. I've set the quirk revision aside and attached the
full, uncompressed boot-to-failure dmesg from the unpatched control kernel,
with the requested DRM debug parameters:

https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3678430

The failure reproduced at 1920x1080, with the native 3440x1440 mode
missing. Only identifying strings were redacted; no log lines were removed.

I'll continue the root-cause investigation on the GitLab issue and use
those findings to guide a revised patch.

Best,

Conor

On Thu, 24 Sept 2026 at 09:03, Jani Nikula <jani.nikula@linux.intel.com>
wrote:

> On Wed, 23 Sep 2026, Conor Svensson <conor10@gmail.com> wrote:
> > Reconnecting an Anker 565 A8388 USB-C hub with a DisplayPort monitor
> > attached can leave the branch reporting a DVI downstream descriptor
> > with 25-165 MHz TMDS limits. On a ThinkPad L14 Gen 4 Intel with a Dell
> > S3422DWG, this removes the native 3440x1440 mode from the connector's
> > mode list even though the EDID still contains it. An explicit native
> > modeline works with the same hardware state.
> >
> > Ignore the derived TMDS limits only for the captured branch identity,
> > firmware and downstream descriptor when EDID 1.4 identifies a digital
> > DisplayPort input. Retain the raw descriptor and other mode checks.
> > Do not restrict the match to a particular monitor or laptop model.
> >
> > With otherwise matching upstream Linux 7.2.5 control/patched builds,
> > the control loses native modes after USB-C reconnect, while the patched
> > kernel selects 3440x1440 at 59.973 Hz automatically. Repeated reconnects,
> > both USB-C ports, suspend/resume, undocking while asleep and docked boot
> > pass. HDMI also works and does not activate the workaround. Periodic
> > picture cycling observed on the control stops with the patch.
> >
> > The branch identity is not proven unique to this retail adapter. This
> > is an experimental workaround for review, not an explanation of why the
> > branch reports inconsistent capabilities. Other adapters and monitors
> > have not been tested.
> >
> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180
> > Assisted-by: LLM
> > Signed-off-by: Conor Svensson <conor10@gmail.com>
> > ---
> > RFC: is this best handled as a branch quirk here, or in the common DP
> > helpers? The captured identity and descriptor match is deliberately
> narrow;
> > there is no monitor/laptop model restriction. The informational log
> marker
> > is retained to show exactly when this experimental workaround executes.
> > The commit introducing the underlying problem has not been identified, so
> > there is no speculative Fixes tag.
> >
> > Hardware A/B testing used upstream Linux 7.2.5 with otherwise identical
> > configurations. This RFC applies the same 48 added lines to drm-tip at
> the
> > base commit below. This drm-tip revision has not been boot-tested. The
> affected intel_dp.o
> > compiles successfully here with no compiler warnings; strict checkpatch
> > passes (human sign-off pending), and 426 predicate boundary cases pass
> > with ASan/UBSan. These predicate tests are not DRM integration tests.
> >
> > Results: three USB-C reconnects, alternate USB-C port, docked s2idle
> > resume plus reconnect, undock while asleep/wake/reconnect, and docked
> > DisplayPort reboot all passed. HDMI also passed without activating the
> > workaround. The control lost native modes and showed periodic picture
> > cycling; that cycling stopped on the patched kernel. No custom modeline
> > was used in either test kernel. Other hardware and higher refresh rates
> > remain untested.
> >
> > AI assistance: Codex (GPT-6) helped investigate the reported hotplug
> > failure, wrote the match/limit-clearing change, prepared the predicate
> > tests, collected diagnostics and drafted this message. The human reporter
> > performed the physical reconnect, suspend and reboot tests and confirmed
> > the visible results. The assistance arose from an extended
> troubleshooting
> > session, rather than a single code-generation prompt.
> >
> > Evidence and detailed test results:
> >
> https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3677750
> >
> > This is my first kernel patch submission. I'd appreciate feedback on
> > whether this belongs here or in the common DP helpers, and whether the
> > matching criteria are appropriate.
>
> Thanks for the patch. Please let's first root cause the issue (on the
> gitlab issue) before jumping into quirking specific devices.
>
> Regardless, a few comments below.
>
> >
> > Thanks,
> > Conor
> >
> >  drivers/gpu/drm/i915/display/intel_dp.c | 48 +++++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index ffddf4b33..6d6767ca7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -6153,6 +6153,39 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
> >       return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc);
> >  }
> >
> > +static bool
> > +intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp,
> > +                              const struct drm_edid *drm_edid)
> > +{
> > +     static const struct drm_dp_dpcd_ident branch = {
> > +             .oui = { 0x90, 0xcc, 0x24 },
> > +             .device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 },
> > +             .hw_rev = 0x10,
> > +             .sw_major_rev = 0x06,
> > +             .sw_minor_rev = 0x05,
> > +     };
> > +     static const u8 downstream_ports[] = {
> > +             0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +     };
>
> intel_dp->downstream_ports is read from DPCD address 0x80, and it
> dynamically reflects the downstream port information, i.e. what's
> currently connected to the branch device. Having a fixed comparison like
> this will only work for a specific type of downstream device connected
> to a specific downstream port.
>
> > +     const struct edid *edid = drm_edid_raw(drm_edid);
>
> No new drm_edid_raw() calls are to be added.
>
> > +
> > +     if (intel_dp_is_edp(intel_dp) || intel_dp->is_mst ||
> > +         !drm_dp_is_branch(intel_dp->dpcd) || !edid)
> > +             return false;
> > +
> > +     /* HDMI and DVI inputs must retain their downstream limits. */
> > +     if (edid->version != 1 || edid->revision < 4 ||
> > +         !(edid->input & DRM_EDID_INPUT_DIGITAL) ||
> > +         (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) !=
> DRM_EDID_DIGITAL_TYPE_DP)
> > +             return false;
> > +
> > +     return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) &&
> > +             !memcmp(intel_dp->downstream_ports, downstream_ports,
> > +                     sizeof(downstream_ports)) &&
> > +             intel_dp->dfp.min_tmds_clock == 25000 &&
> > +             intel_dp->dfp.max_tmds_clock == 165000;
> > +}
>
> We have intel_quirks.c with various structured mechanisms for
> identifying quirks. If we end up needing a quirk for this, the existing
> mechanisms need to be used instead of adding a bunch of code inline like
> this.
>
> Again, please let's first root cause and debug the issue instead of
> trying to fix the patch.
>
> BR,
> Jani.
>
>
> > +
> >  static void
> >  intel_dp_update_dfp(struct intel_dp *intel_dp,
> >                   const struct drm_edid *drm_edid)
> > @@ -6181,6 +6214,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
> >               drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
> >                                          intel_dp->downstream_ports);
> >
> > +     /*
> > +      * Experimental workaround for the branch observed in an Anker
> A8388.
> > +      * USB-C hotplug can expose a DVI descriptor for the DP output. The
> > +      * monitor's native timing works when requested explicitly, despite
> > +      * the reported 165 MHz limit. Keep the captured identity and
> failure
> > +      * signature checks narrow until the underlying cause is
> understood.
> > +      */
> > +     if (intel_dp_has_anker_tmds_mismatch(intel_dp, drm_edid)) {
> > +             intel_dp->dfp.min_tmds_clock = 0;
> > +             intel_dp->dfp.max_tmds_clock = 0;
> > +             drm_info(display->drm,
> > +                      "[CONNECTOR:%d:%s] experimental Anker DP TMDS
> limit workaround\n",
> > +                      connector->base.base.id, connector->base.name);
> > +     }
> > +
> >       drm_dbg_kms(display->drm,
> >                   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d,
> TMDS clock %d-%d, PCON Max FRL BW %dGbps\n",
> >                   connector->base.base.id, connector->base.name,
> >
> > base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04
>
> --
> Jani Nikula, Intel
>


-- 

*Conor Svensson*

Schedule a Meeting <https://calendar.app.google/qwPdNGAewy95Bmbn9>

+44 (0) 7497 376 365

LinkedIn <https://www.linkedin.com/in/conorsvensson/>  X (Twitter)
<https://twitter.com/conorsvensson>  Telegram <https://t.me/conor10>

[-- Attachment #2: Type: text/html, Size: 12618 bytes --]

Re: [RFC PATCH] drm/i915/dp: Ignore inconsistent TMDS limits on an Anker DP branch

[Conor Svensson]

[-- Attachment #1: Type: text/plain, Size: 9122 bytes --]

Hi Jani (resending due to accidental embedded HTML on previous message),

Thanks for the guidance. I've set the quirk revision aside and attached the
full, uncompressed boot-to-failure dmesg from the unpatched control kernel,
with the requested DRM debug parameters:

https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3678430

The failure reproduced at 1920x1080, with the native 3440x1440 mode
missing. Only identifying strings were redacted; no log lines were removed.

I'll continue the root-cause investigation on the GitLab issue and use
those findings to guide a revised patch.

Best,

Conor

On Thu, 24 Sept 2026 at 09:03, Jani Nikula <jani.nikula@linux.intel.com>
wrote:

> On Wed, 23 Sep 2026, Conor Svensson <conor10@gmail.com> wrote:
> > Reconnecting an Anker 565 A8388 USB-C hub with a DisplayPort monitor
> > attached can leave the branch reporting a DVI downstream descriptor
> > with 25-165 MHz TMDS limits. On a ThinkPad L14 Gen 4 Intel with a Dell
> > S3422DWG, this removes the native 3440x1440 mode from the connector's
> > mode list even though the EDID still contains it. An explicit native
> > modeline works with the same hardware state.
> >
> > Ignore the derived TMDS limits only for the captured branch identity,
> > firmware and downstream descriptor when EDID 1.4 identifies a digital
> > DisplayPort input. Retain the raw descriptor and other mode checks.
> > Do not restrict the match to a particular monitor or laptop model.
> >
> > With otherwise matching upstream Linux 7.2.5 control/patched builds,
> > the control loses native modes after USB-C reconnect, while the patched
> > kernel selects 3440x1440 at 59.973 Hz automatically. Repeated reconnects,
> > both USB-C ports, suspend/resume, undocking while asleep and docked boot
> > pass. HDMI also works and does not activate the workaround. Periodic
> > picture cycling observed on the control stops with the patch.
> >
> > The branch identity is not proven unique to this retail adapter. This
> > is an experimental workaround for review, not an explanation of why the
> > branch reports inconsistent capabilities. Other adapters and monitors
> > have not been tested.
> >
> > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180
> > Assisted-by: LLM
> > Signed-off-by: Conor Svensson <conor10@gmail.com>
> > ---
> > RFC: is this best handled as a branch quirk here, or in the common DP
> > helpers? The captured identity and descriptor match is deliberately
> narrow;
> > there is no monitor/laptop model restriction. The informational log
> marker
> > is retained to show exactly when this experimental workaround executes.
> > The commit introducing the underlying problem has not been identified, so
> > there is no speculative Fixes tag.
> >
> > Hardware A/B testing used upstream Linux 7.2.5 with otherwise identical
> > configurations. This RFC applies the same 48 added lines to drm-tip at
> the
> > base commit below. This drm-tip revision has not been boot-tested. The
> affected intel_dp.o
> > compiles successfully here with no compiler warnings; strict checkpatch
> > passes (human sign-off pending), and 426 predicate boundary cases pass
> > with ASan/UBSan. These predicate tests are not DRM integration tests.
> >
> > Results: three USB-C reconnects, alternate USB-C port, docked s2idle
> > resume plus reconnect, undock while asleep/wake/reconnect, and docked
> > DisplayPort reboot all passed. HDMI also passed without activating the
> > workaround. The control lost native modes and showed periodic picture
> > cycling; that cycling stopped on the patched kernel. No custom modeline
> > was used in either test kernel. Other hardware and higher refresh rates
> > remain untested.
> >
> > AI assistance: Codex (GPT-6) helped investigate the reported hotplug
> > failure, wrote the match/limit-clearing change, prepared the predicate
> > tests, collected diagnostics and drafted this message. The human reporter
> > performed the physical reconnect, suspend and reboot tests and confirmed
> > the visible results. The assistance arose from an extended
> troubleshooting
> > session, rather than a single code-generation prompt.
> >
> > Evidence and detailed test results:
> >
> https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3677750
> >
> > This is my first kernel patch submission. I'd appreciate feedback on
> > whether this belongs here or in the common DP helpers, and whether the
> > matching criteria are appropriate.
>
> Thanks for the patch. Please let's first root cause the issue (on the
> gitlab issue) before jumping into quirking specific devices.
>
> Regardless, a few comments below.
>
> >
> > Thanks,
> > Conor
> >
> >  drivers/gpu/drm/i915/display/intel_dp.c | 48 +++++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index ffddf4b33..6d6767ca7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -6153,6 +6153,39 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
> >       return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc);
> >  }
> >
> > +static bool
> > +intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp,
> > +                              const struct drm_edid *drm_edid)
> > +{
> > +     static const struct drm_dp_dpcd_ident branch = {
> > +             .oui = { 0x90, 0xcc, 0x24 },
> > +             .device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 },
> > +             .hw_rev = 0x10,
> > +             .sw_major_rev = 0x06,
> > +             .sw_minor_rev = 0x05,
> > +     };
> > +     static const u8 downstream_ports[] = {
> > +             0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +     };
>
> intel_dp->downstream_ports is read from DPCD address 0x80, and it
> dynamically reflects the downstream port information, i.e. what's
> currently connected to the branch device. Having a fixed comparison like
> this will only work for a specific type of downstream device connected
> to a specific downstream port.
>
> > +     const struct edid *edid = drm_edid_raw(drm_edid);
>
> No new drm_edid_raw() calls are to be added.
>
> > +
> > +     if (intel_dp_is_edp(intel_dp) || intel_dp->is_mst ||
> > +         !drm_dp_is_branch(intel_dp->dpcd) || !edid)
> > +             return false;
> > +
> > +     /* HDMI and DVI inputs must retain their downstream limits. */
> > +     if (edid->version != 1 || edid->revision < 4 ||
> > +         !(edid->input & DRM_EDID_INPUT_DIGITAL) ||
> > +         (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) !=
> DRM_EDID_DIGITAL_TYPE_DP)
> > +             return false;
> > +
> > +     return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) &&
> > +             !memcmp(intel_dp->downstream_ports, downstream_ports,
> > +                     sizeof(downstream_ports)) &&
> > +             intel_dp->dfp.min_tmds_clock == 25000 &&
> > +             intel_dp->dfp.max_tmds_clock == 165000;
> > +}
>
> We have intel_quirks.c with various structured mechanisms for
> identifying quirks. If we end up needing a quirk for this, the existing
> mechanisms need to be used instead of adding a bunch of code inline like
> this.
>
> Again, please let's first root cause and debug the issue instead of
> trying to fix the patch.
>
> BR,
> Jani.
>
>
> > +
> >  static void
> >  intel_dp_update_dfp(struct intel_dp *intel_dp,
> >                   const struct drm_edid *drm_edid)
> > @@ -6181,6 +6214,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
> >               drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
> >                                          intel_dp->downstream_ports);
> >
> > +     /*
> > +      * Experimental workaround for the branch observed in an Anker
> A8388.
> > +      * USB-C hotplug can expose a DVI descriptor for the DP output. The
> > +      * monitor's native timing works when requested explicitly, despite
> > +      * the reported 165 MHz limit. Keep the captured identity and
> failure
> > +      * signature checks narrow until the underlying cause is
> understood.
> > +      */
> > +     if (intel_dp_has_anker_tmds_mismatch(intel_dp, drm_edid)) {
> > +             intel_dp->dfp.min_tmds_clock = 0;
> > +             intel_dp->dfp.max_tmds_clock = 0;
> > +             drm_info(display->drm,
> > +                      "[CONNECTOR:%d:%s] experimental Anker DP TMDS
> limit workaround\n",
> > +                      connector->base.base.id, connector->base.name);
> > +     }
> > +
> >       drm_dbg_kms(display->drm,
> >                   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d,
> TMDS clock %d-%d, PCON Max FRL BW %dGbps\n",
> >                   connector->base.base.id, connector->base.name,
> >
> > base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04
>
> --
> Jani Nikula, Intel
>


-- 

*Conor Svensson*

Schedule a Meeting <https://calendar.app.google/qwPdNGAewy95Bmbn9>

+44 (0) 7497 376 365

LinkedIn <https://www.linkedin.com/in/conorsvensson/>  X (Twitter)
<https://twitter.com/conorsvensson>  Telegram <https://t.me/conor10>

[-- Attachment #2: Type: text/html, Size: 12644 bytes --]

[PATCH] drm/i915/dp: Configure protocol converter only for TMDS outputs

[Conor Svensson]

intel_dp_configure_protocol_converter() currently writes the HDMI/DVI
output-selection control for every DP 1.3+ branch. The write is only
meaningful for a TMDS downstream output; a native DisplayPort output should
not be switched to the HDMI/DVI protocol-converter mode.

An Anker 565 branch (Synaptics OUI 90:cc:24) changes its downstream port
descriptor from DisplayPort to DVI immediately after this write. i915 then
derives a 165 MHz TMDS limit on the next hotplug probe and drops the
monitor's native modes. Skipping the write for non-TMDS outputs prevents
the transition.

The existing dfp.min_tmds_clock classification is nonzero for HDMI/DVI
outputs and zero for native DisplayPort outputs, so retain the write for
the protocol-converter cases that need it. Colour-conversion controls are
unchanged.

Tested on a ThinkPad L14 Gen 4 with an Anker 565 A8388 hub and a Dell
S3422DWG:

- native 3440x1440@59.973 after DP recovery
- three USB-C reconnects on the first USB-C port
- one test on the second USB-C port
- suspend/resume on the second port
- HDMI through the hub at 3440x1440@59.973, with HDMI-specific modes
  present

On the unpatched control kernel, the live descriptor changed from
08 f0 01 1e 00 00 00 00 to 0a 42 00 00 00 00 00 00 across the 0x3050 write.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180

Root-cause findings and validation details were added to the linked issue.

Assisted-by: LLM Codex GPT-6

Signed-off-by: Conor Svensson <conor10@gmail.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ffddf4b33..cdc3d7786 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4422,14 +4422,17 @@ void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
 	if (!drm_dp_is_branch(intel_dp->dpcd))
 		return;
 
-	tmp = intel_dp_has_hdmi_sink(intel_dp) ? DP_HDMI_DVI_OUTPUT_CONFIG : 0;
+	/* HDMI/DVI output selection only applies to TMDS downstream ports. */
+	if (intel_dp->dfp.min_tmds_clock) {
+		tmp = intel_dp_has_hdmi_sink(intel_dp) ? DP_HDMI_DVI_OUTPUT_CONFIG : 0;
 
-	ret = drm_dp_dpcd_write_byte(&intel_dp->aux,
-				     DP_PROTOCOL_CONVERTER_CONTROL_0, tmp);
-	if (ret < 0)
-		drm_dbg_kms(display->drm,
-			    "Failed to %s protocol converter HDMI mode\n",
-			    str_enable_disable(intel_dp_has_hdmi_sink(intel_dp)));
+		ret = drm_dp_dpcd_write_byte(&intel_dp->aux,
+					     DP_PROTOCOL_CONVERTER_CONTROL_0, tmp);
+		if (ret < 0)
+			drm_dbg_kms(display->drm,
+				    "Failed to %s protocol converter HDMI mode\n",
+				    str_enable_disable(intel_dp_has_hdmi_sink(intel_dp)));
+	}
 
 	if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
 		switch (crtc_state->output_format) {

base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04
-- 
2.55.0

Re: [PATCH] drm/i915/dp: Configure protocol converter only for TMDS outputs

[Conor Svensson]

Hi Jani,

A gentle follow-up on this patch. Following your advice on the
original RFC, I investigated the root cause and posted the findings
and testing results to the GitLab issue:

https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3679658

The revised patch replaces the device-specific quirk with a change to
the protocol-converter configuration. Feedback on the approach and
whether this belongs in i915 or the DP helper would be appreciated.

Thanks for your time,

Conor


On Thu, 24 Sept 2026 at 22:19, Conor Svensson <conor10@gmail.com> wrote:
>
> intel_dp_configure_protocol_converter() currently writes the HDMI/DVI
> output-selection control for every DP 1.3+ branch. The write is only
> meaningful for a TMDS downstream output; a native DisplayPort output should
> not be switched to the HDMI/DVI protocol-converter mode.
>
> An Anker 565 branch (Synaptics OUI 90:cc:24) changes its downstream port
> descriptor from DisplayPort to DVI immediately after this write. i915 then
> derives a 165 MHz TMDS limit on the next hotplug probe and drops the
> monitor's native modes. Skipping the write for non-TMDS outputs prevents
> the transition.
>
> The existing dfp.min_tmds_clock classification is nonzero for HDMI/DVI
> outputs and zero for native DisplayPort outputs, so retain the write for
> the protocol-converter cases that need it. Colour-conversion controls are
> unchanged.
>
> Tested on a ThinkPad L14 Gen 4 with an Anker 565 A8388 hub and a Dell
> S3422DWG:
>
> - native 3440x1440@59.973 after DP recovery
> - three USB-C reconnects on the first USB-C port
> - one test on the second USB-C port
> - suspend/resume on the second port
> - HDMI through the hub at 3440x1440@59.973, with HDMI-specific modes
>   present
>
> On the unpatched control kernel, the live descriptor changed from
> 08 f0 01 1e 00 00 00 00 to 0a 42 00 00 00 00 00 00 across the 0x3050 write.
>
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180
>
> Root-cause findings and validation details were added to the linked issue.
>
> Assisted-by: LLM Codex GPT-6
>
> Signed-off-by: Conor Svensson <conor10@gmail.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index ffddf4b33..cdc3d7786 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4422,14 +4422,17 @@ void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
>         if (!drm_dp_is_branch(intel_dp->dpcd))
>                 return;
>
> -       tmp = intel_dp_has_hdmi_sink(intel_dp) ? DP_HDMI_DVI_OUTPUT_CONFIG : 0;
> +       /* HDMI/DVI output selection only applies to TMDS downstream ports. */
> +       if (intel_dp->dfp.min_tmds_clock) {
> +               tmp = intel_dp_has_hdmi_sink(intel_dp) ? DP_HDMI_DVI_OUTPUT_CONFIG : 0;
>
> -       ret = drm_dp_dpcd_write_byte(&intel_dp->aux,
> -                                    DP_PROTOCOL_CONVERTER_CONTROL_0, tmp);
> -       if (ret < 0)
> -               drm_dbg_kms(display->drm,
> -                           "Failed to %s protocol converter HDMI mode\n",
> -                           str_enable_disable(intel_dp_has_hdmi_sink(intel_dp)));
> +               ret = drm_dp_dpcd_write_byte(&intel_dp->aux,
> +                                            DP_PROTOCOL_CONVERTER_CONTROL_0, tmp);
> +               if (ret < 0)
> +                       drm_dbg_kms(display->drm,
> +                                   "Failed to %s protocol converter HDMI mode\n",
> +                                   str_enable_disable(intel_dp_has_hdmi_sink(intel_dp)));
> +       }
>
>         if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
>                 switch (crtc_state->output_format) {
>
> base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04
> --
> 2.55.0
>


--

Conor Svensson

Schedule a Meeting

+44 (0) 7497 376 365

LinkedIn  X (Twitter)