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

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 29 Jun 2026, "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com> 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 <alexander.kaplan@sms-medipool.de>
>> ---
>> 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;
>> +
>
> 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 <ankit.k.nautiyal@intel.com>

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