On Wed, Jun 10, 2026 at 07:48:19PM +0200, Alexander Kaplan wrote:
> The PCON max FRL bandwidth field lives in byte 2 of the DFP Detailed
> Capability Info (DPCD 0x82 for the first DFP).
> The DP standard defines the meaning of descriptor bytes 1-3 strictly
> per DFP type, and for a DisplayPort type DFP all of them are
> reserved, with "read all 0s" semantics (DP v2.0, section 2.12.3,
> Table 2-183).
> The FRL bandwidth field is an HDMI DFP extension added by the VESA
> DP-to-HDMI PCON specification.
> drm_dp_get_pcon_max_frl_bw() however parses the byte without checking
> the DFP type, the branch presence or DETAILED_CAP_INFO_AVAILABLE.
> Without the latter the port descriptors are one byte wide and
> port_cap[2] is not even the right register.
>
> All neighbouring helpers parsing the same descriptor are scoped by
> the DFP type already, see for instance drm_dp_downstream_max_bpc()
> reading the same byte and returning 0 for a DP type DFP.
> amdgpu's DC parses the field only for HDMI(/DP++) detailed types as
> well.
>
> This is not theoretical.
> A Synaptics VMM7100 based USB-C to HDMI adapter with a macOS targeted
> firmware advertises a DisplayPort type DFP with the type byte
> replicated across the whole descriptor (08 08 08 08).
> i915 decodes that as "PCON limited to 18 Gbps FRL" and prunes every
> mode above ~750 MHz dotclock, including all the 4k@100/120 modes the
> sink EDID offers, while macOS drives 4k@120 through the same adapter
> just fine via DP DSC (and amdgpu's type-scoped parser would ignore
> the bogus field as well).
>
> Only parse the field for an HDMI DFP behind a branch device that
> reports detailed cap info, matching the type-scoped field layout of
> the spec and the rest of the helpers.
>
> Fixes: ce32a6239de6 ("drm/dp_helper: Add Helpers for FRL Link Training
> support for DP-HDMI2.1 PCON")
> Signed-off-by: Alexander Kaplan <[email protected]>
> ---
> This patch is part of a set of independent fixes for the USB-C to DP
> to HDMI 2.1 protocol converter (PCON) path, found and verified on an
> ASUS NUC 16 Pro (Panther Lake, xe) with Synaptics VMM7100 based
> adapters.
> Each part stands on its own and can be merged independently.
> The other parts:
> [1]
> https://lore.kernel.org/r/[email protected]
> [2]
> https://lore.kernel.org/r/[email protected]
> drivers/gpu/drm/display/drm_dp_helper.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 9c31e14cc413..3328909c8db4 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3686,6 +3686,15 @@ int drm_dp_get_pcon_max_frl_bw(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> int bw;
> u8 buf;
>
> + if (!drm_dp_is_branch(dpcd))
> + return 0;
> +
I'd also add a DPCD_REV check because none of this stuff exists for
DPCD v1.0. Granted, the DP_DETAILED_CAP_INFO_AVAILABLE bit should be
zero there (assuming any DPCD v1.0 devices even exists), but I'd
rather have the explicit check anyway so I don't have to think so
much when reading the code.
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
> == 0)
> + return 0;
> +
> + if ((port_cap[0] & DP_DS_PORT_TYPE_MASK) != DP_DS_PORT_TYPE_HDMI)
> + return 0;
> +
> buf = port_cap[2];
> bw = buf & DP_PCON_MAX_FRL_BW;
>
> --
> 2.54.0
>
--
Ville Syrjälä
Intel
