Commit 67d7469a authored by Ville Syrjälä's avatar Ville Syrjälä

drm/edid: Clarify why we only accept the "range limits only" descriptor

The current comment fails to clarify why we only accept
the "range limits only" variant of the range descriptor.
Reword it to make some actual sense.

Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-2-ville.syrjala@linux.intel.com
parent 5e931c88
......@@ -6052,10 +6052,13 @@ void get_monitor_range(const struct detailed_timing *timing,
return;
/*
* Check for flag range limits only. If flag == 1 then
* no additional timing information provided.
* Default GTF, GTF Secondary curve and CVT are not
* supported
* These limits are used to determine the VRR refresh
* rate range. Only the "range limits only" variant
* of the range descriptor seems to guarantee that
* any and all timings are accepted by the sink, as
* opposed to just timings conforming to the indicated
* formula (GTF/GTF2/CVT). Thus other variants of the
* range descriptor are not accepted here.
*/
if (range->flags != DRM_EDID_RANGE_LIMITS_ONLY_FLAG)
return;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment