From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
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
Subject: Re: [PATCH] drm/i915/dp: Add byte-by-byte fallback for broken USB-C adapters
Date: Thu, 27 Nov 2025 23:40:54 +0200 [thread overview]
Message-ID: <aSjFZhZQLVb7czsh@intel.com> (raw)
In-Reply-To: <20251127044406.618543-1-acelan.kao@canonical.com>
On Thu, Nov 27, 2025 at 12:44:06PM +0800, Chia-Lin Kao (AceLan) wrote:
> Some USB-C hubs and adapters have buggy firmware where multi-byte AUX
> reads from DPCD address 0x00000 consistently timeout, while single-byte
> reads from the same address work correctly.
>
> Known affected devices that exhibit this issue:
> - Lenovo USB-C to VGA adapter (VIA VL817 chipset)
> idVendor=17ef, idProduct=7217
> - Dell DA310 USB-C mobile adapter hub
> idVendor=413c, idProduct=c010
>
> Analysis of the failure pattern shows:
> - Single-byte probes to 0xf0000 (LTTPR) succeed
> - Single-byte probes to 0x00102 (TRAINING_AUX_RD_INTERVAL) succeed
> - 15-byte reads from 0x00000 (DPCD capabilities) timeout with -ETIMEDOUT
> - Retrying does not help - the failure is consistent across all attempts
I thought we changed that to the more sensible 16 bytes.
Anyone know what happened to that patch?
Anyways, does 16 bytes work better than 15 bytes?
>
> The issue appears to be a firmware bug in the AUX transaction handling
> that specifically affects multi-byte reads from the base DPCD address.
>
> Add a fallback mechanism that attempts byte-by-byte reading when the
> normal multi-byte drm_dp_read_dpcd_caps() fails. This workaround only
> activates for adapters that fail the standard read path, ensuring no
> impact on correctly functioning hardware.
>
> The byte-by-byte read uses drm_dp_dpcd_readb() to read each of the 15
> DPCD capability bytes individually, working around the firmware bug
> while maintaining compatibility with all other adapters.
>
> Tested with:
> - Lenovo USB-C to VGA adapter (VIA VL817) - now works with fallback
> - Dell DA310 USB-C hub - now works with fallback
> - Dell/Analogix Slimport adapter - continues to work with normal path
>
> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
> ---
> .../drm/i915/display/intel_dp_link_training.c | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index aad5fe14962f..738a5bb4adb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -213,6 +213,7 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEI
> int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> struct intel_display *display = to_intel_display(intel_dp);
> + int ret, i;
>
> if (intel_dp_is_edp(intel_dp))
> return 0;
> @@ -226,7 +227,25 @@ int intel_dp_read_dprx_caps(struct intel_dp *intel_dp, u8 dpcd[DP_RECEIVER_CAP_S
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> return -EIO;
>
> - if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
> + ret = drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd);
> + if (ret == 0)
> + return 0;
> +
> + /*
> + * Workaround for USB-C hubs/adapters with buggy firmware that fail
> + * multi-byte AUX reads from DPCD address 0x00000 but work with
> + * single-byte reads. Known affected devices:
> + * - Lenovo USB-C to VGA adapter (VIA VL817, idVendor=17ef, idProduct=7217)
> + * - Dell DA310 USB-C hub (idVendor=413c, idProduct=c010)
> + * Read the DPCD capabilities byte-by-byte as a fallback.
> + */
> + for (i = 0; i < DP_RECEIVER_CAP_SIZE; i++) {
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_DPCD_REV + i, &dpcd[i]);
> + if (ret < 0)
> + return -EIO;
> + }
Doing this in i915 specific code doesn't make sense.
> +
> + if (dpcd[DP_DPCD_REV] == 0)
> return -EIO;
>
> return 0;
> --
> 2.43.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-11-27 21:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 4:44 [PATCH] drm/i915/dp: Add byte-by-byte fallback for broken USB-C adapters Chia-Lin Kao (AceLan)
2025-11-27 4:51 ` ✓ CI.KUnit: success for " Patchwork
2025-11-27 5:40 ` ✓ i915.CI.BAT: " Patchwork
2025-11-27 5:53 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-27 6:46 ` ✓ Xe.CI.Full: " Patchwork
2025-11-27 9:07 ` ✓ i915.CI.Full: " Patchwork
2025-11-27 21:40 ` Ville Syrjälä [this message]
2025-12-04 2:29 ` [PATCH] " Chia-Lin Kao (AceLan)
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=aSjFZhZQLVb7czsh@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=acelan.kao@canonical.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--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.