[PATCH 1/2] Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"

Nautiyal, Ankit K ankit.k.nautiyal at intel.com
Wed May 14 11:33:04 UTC 2025


On 5/14/2025 4:17 PM, Jani Nikula wrote:
> On Wed, 14 May 2025, Jani Nikula <jani.nikula at linux.intel.com> wrote:
>> On Wed, 14 May 2025, Ankit Nautiyal <ankit.k.nautiyal at intel.com> wrote:
>>> This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6.
>>>
>>> Some eDP panels support HBR3 but not TPS4 and rely on a fixed mode that
>>> requires HBR3. After the original commit, these panels go blank due to
>>> the rejection of HBR3.
>>>
>>> To restore functionality for such panels, this commit reverts the change.
>> Which panels? References? Bugs?
> Regardless, on another reading of the specs, I think the commit being
> reverted was misguided. TPS4 seems to be required for HBR3 on DPRX, but
> not eDPRX.

Yeah TPS4_Supported bit seems to be not defined for eDP.

For the gitlab issue 5969 [1], the rejecting of HBR3 rate avoided the 
10bpc which I guess is not supported for the panel mentioned in the issue.

 From logs, the VBT had capped the bpp to 18, but GOP used 24 bpp. Edid 
advertised support for 36 bpp.

Without the commit, 30 bpp gets picked up and the issue was seen.

With the commit (After rejecting HBR3) 24 bpp was used and the issue was 
resolved.

I am wondering if we should limit bpp or the rate for the panel 
mentioned in gitlab issue 5969[1].

Also should this be an i915 specific quirk? Or something like quirk 
introduced in patch#2 [2] of the series?

[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969

[2] https://patchwork.freedesktop.org/patch/653510/?series=149005&rev=1

Regards,

Ankit

>
>
> BR,
> Jani.
>
>>> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969
>> This is a reference to a bug that got closed by the commit being
>> reverted. This now breaks it again, can't use the Closes: tag here.
>>
>> Since the original commit was backported to stable, I think we're
>> probably going to be screwed if we do the revert + fix in two
>> steps. Maybe we want a fix in one go, and backport that to stable. Idk.
>>
>> BR,
>> Jani.
>>
>>
>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/display/intel_dp.c | 49 ++++---------------------
>>>   1 file changed, 7 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>>> index 91a34d474463..97cf80372264 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -175,28 +175,10 @@ int intel_dp_link_symbol_clock(int rate)
>>>   
>>>   static int max_dprx_rate(struct intel_dp *intel_dp)
>>>   {
>>> -	struct intel_display *display = to_intel_display(intel_dp);
>>> -	struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>>> -	int max_rate;
>>> -
>>>   	if (intel_dp_tunnel_bw_alloc_is_enabled(intel_dp))
>>> -		max_rate = drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
>>> -	else
>>> -		max_rate = drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>>> +		return drm_dp_tunnel_max_dprx_rate(intel_dp->tunnel);
>>>   
>>> -	/*
>>> -	 * Some broken eDP sinks illegally declare support for
>>> -	 * HBR3 without TPS4, and are unable to produce a stable
>>> -	 * output. Reject HBR3 when TPS4 is not available.
>>> -	 */
>>> -	if (max_rate >= 810000 && !drm_dp_tps4_supported(intel_dp->dpcd)) {
>>> -		drm_dbg_kms(display->drm,
>>> -			    "[ENCODER:%d:%s] Rejecting HBR3 due to missing TPS4 support\n",
>>> -			    encoder->base.base.id, encoder->base.name);
>>> -		max_rate = 540000;
>>> -	}
>>> -
>>> -	return max_rate;
>>> +	return drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>>>   }
>>>   
>>>   static int max_dprx_lane_count(struct intel_dp *intel_dp)
>>> @@ -4272,9 +4254,6 @@ static void intel_edp_mso_init(struct intel_dp *intel_dp)
>>>   static void
>>>   intel_edp_set_sink_rates(struct intel_dp *intel_dp)
>>>   {
>>> -	struct intel_display *display = to_intel_display(intel_dp);
>>> -	struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>>> -
>>>   	intel_dp->num_sink_rates = 0;
>>>   
>>>   	if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
>>> @@ -4285,7 +4264,10 @@ intel_edp_set_sink_rates(struct intel_dp *intel_dp)
>>>   				 sink_rates, sizeof(sink_rates));
>>>   
>>>   		for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
>>> -			int rate;
>>> +			int val = le16_to_cpu(sink_rates[i]);
>>> +
>>> +			if (val == 0)
>>> +				break;
>>>   
>>>   			/* Value read multiplied by 200kHz gives the per-lane
>>>   			 * link rate in kHz. The source rates are, however,
>>> @@ -4293,24 +4275,7 @@ intel_edp_set_sink_rates(struct intel_dp *intel_dp)
>>>   			 * back to symbols is
>>>   			 * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
>>>   			 */
>>> -			rate = le16_to_cpu(sink_rates[i]) * 200 / 10;
>>> -
>>> -			if (rate == 0)
>>> -				break;
>>> -
>>> -			/*
>>> -			 * Some broken eDP sinks illegally declare support for
>>> -			 * HBR3 without TPS4, and are unable to produce a stable
>>> -			 * output. Reject HBR3 when TPS4 is not available.
>>> -			 */
>>> -			if (rate >= 810000 && !drm_dp_tps4_supported(intel_dp->dpcd)) {
>>> -				drm_dbg_kms(display->drm,
>>> -					    "[ENCODER:%d:%s] Rejecting HBR3 due to missing TPS4 support\n",
>>> -					    encoder->base.base.id, encoder->base.name);
>>> -				break;
>>> -			}
>>> -
>>> -			intel_dp->sink_rates[i] = rate;
>>> +			intel_dp->sink_rates[i] = (val * 200) / 10;
>>>   		}
>>>   		intel_dp->num_sink_rates = i;
>>>   	}


More information about the Intel-gfx mailing list