Re: [PATCH v2] drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

["Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>]

On 6/11/2026 1:08 AM, 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 DPCD 1.1+ 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 <alexander.kaplan@sms-medipool.de>

Thanks for the patch.

Added : Cc: <stable@vger.kernel.org> # v5.12+ and pushed to drm-misc-fixes.


Regards,

Ankit



> ---
> v2: add an explicit DPCD_REV check like the neighbouring helpers
>      have (Ville)
> v1: https://lore.kernel.org/r/20260610174819.6258-1-alexander.kaplan@sms-medipool.de
>
> 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/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
> [2] https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
>   drivers/gpu/drm/display/drm_dp_helper.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 9c31e14cc413..e623ccb4c1d8 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3686,6 +3686,18 @@ 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;
> +
> +	if (dpcd[DP_DPCD_REV] < 0x11)
> +		return 0;
> +
> +	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;
>