On Mon, 29 Jun 2026, "Nautiyal, Ankit K" <[email protected]> wrote: > 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 <[email protected]> >> --- >> v2: add an explicit DPCD_REV check like the neighbouring helpers >> have (Ville) >> v1: >> https://lore.kernel.org/r/[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 | 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; >> + > > This is the right thing to do. These come under Additional HDMI Link > Capability in the spec, so this needs a check for HDMI DFP. > > Thanks for the fix. > > Reviewed-by: Ankit Nautiyal <[email protected]>
I kicked CI to let this through. Please wait for the results before merging. Thanks. > > > >> buf = port_cap[2]; >> bw = buf & DP_PCON_MAX_FRL_BW; >> -- Jani Nikula, Intel
