Re: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune modes that require HDMI2.1 FRL

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

On 7/19/2022 8:45 AM, Murthy, Arun R wrote:
>> -----Original Message-----
>> From: Nautiyal, Ankit K <ankit.k.nautiyal@intel.com>
>> Sent: Friday, July 8, 2022 3:36 PM
>> To: Murthy, Arun R <arun.r.murthy@intel.com>; intel-
>> gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune modes that require
>> HDMI2.1 FRL
>>
>> Hi Arun,
>>
>> Thanks for the comments.
>>
>> Please find my response inline.
>>
>> On 7/8/2022 9:30 AM, Murthy, Arun R wrote:
>>>> -----Original Message-----
>>>> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf
>>>> Of Ankit Nautiyal
>>>> Sent: Thursday, July 7, 2022 10:57 AM
>>>> To: intel-gfx@lists.freedesktop.org
>>>> Subject: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune modes that require
>>>> HDMI2.1 FRL
>>>>
>>>> HDMI2.1 requires some higher resolution video modes to be enumerated
>>>> only if HDMI2.1 Fixed Rate Link (FRL) is supported.
>>>> Current platforms do not support FRL transmission so prune modes that
>>>> require HDMI2.1 FRL.
>>>>
>>> If the hardware doesn't support FRL then it basically blocks HDMI2.1
>> feature.
>>> Then it wont be possible to use any resolution above 4k60 is it?
>>
>> Yes right. As I understand, the HDMI2.1a supersedes HDMI2.0b, and so the
>>
>> platforms  supporting HDMI2.0 must now pass the HDMI2.1 CTS.
>> The HDMI2.1a spec introduces Marketing Feature names for 4K100, 4K120,
>> 8k@50, 8k@60 with suffix A, and B.
>> Suffix A meaning mode supported without compression, and B meaning,
>> mode supported with compression.
>>
>> There are CTS tests that expect these modes not to be enumerated, if the
>> source does support the given requirements.
>>
>>
> Thanks for the clarification.
>
>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/display/intel_hdmi.c | 21
>> +++++++++++++++++++++
>>>>    1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
>>>> b/drivers/gpu/drm/i915/display/intel_hdmi.c
>>>> index ebd91aa69dd2..93c00b61795f 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>>>> @@ -1974,6 +1974,20 @@ intel_hdmi_mode_clock_valid(struct
>>>> drm_connector *connector, int clock,
>>>>    	return status;
>>>>    }
>>>>
>>>> +/*
>>>> + * HDMI2.1 requires higher resolution modes like 8k60, 4K120 to be
>>>> + * enumerated only if FRL is supported. Platforms not supporting FRL
>>>> + * must prune these modes.
>>>> + */
>>>> +static bool
>>>> +hdmi21_frl_quirk(int dotclock, bool frl_supported) {
>>>> +	if (dotclock >= 600000 && !frl_supported)
>>>> +		return true;
>>>> +
>>>> +	return false;
>>>> +}
>>>> +
>>>>    static enum drm_mode_status
>>>>    intel_hdmi_mode_valid(struct drm_connector *connector,
>>>>    		      struct drm_display_mode *mode) @@ -2001,6 +2015,13
>> @@
>>>> intel_hdmi_mode_valid(struct drm_connector *connector,
>>>>    		clock *= 2;
>>>>    	}
>>>>
>>>> +	/*
>>>> +	 * Current Platforms do not support HDMI2.1 FRL mode of
>>>> transmission,
>>>> +	 * so prune the modes that require FRL.
>>>> +	 */
>>>> +	if (hdmi21_frl_quirk(clock, false))
>>>> +		return MODE_BAD;
>>>> +
>>> Instead of setting this frl_supported as false, can we get this info
>>> from hardware, so that when our hardware supports it later it would be
>> easy to enable this.
>>
>> We can have something like:
>>
>> src_supports_frl()
>>
>> {
>>
>> /* FRL not supported in
>>
>> return false;
>>
>> }
>>
> Yes something like this looks good. It would be a good design to judge this based on the
> Display version.

I do agree, we need to have this check when we have HDMI2.1 support for 
any platform.

In future patches, when FRL transmission will be enabled, at that time 
it would make sense to check for display version, and parse from VBT 
about what rate it allows  etc.

But currently, since we do not support this yet, the function 
src_supports_frl can only return false.


Regards,

Ankit

>
> Thanks and Regards,
> Arun R Murthy
> --------------------