Re: [PATCH] drm/edid: Read the monitor range from the DisplayID Adaptive-Sync block

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/edid: Signed-off-by trailer uses handle instead of full
  real name
--

commit ccbdbf24ebcae6dbb6cf32b1e44947510278e9c5
Author: ElXreno <elxreno@gmail.com>

> drm/edid: Read the monitor range from the DisplayID Adaptive-Sync block
>
> A DisplayID 2.x Adaptive-Sync data block (tag 0x2b) lists the refresh
> rate ranges a display supports with an adaptive vertical total. Some
> panels advertise their variable refresh range only there, and some
> keep a narrower one in the base block range limits. The BOE
> NE180QA1-MM1 is of the second kind: the range limits descriptor says
> 48-120 Hz, the Adaptive-Sync block has three descriptors,
>
>  27 00 30 ef 00 00
>  27 00 30 77 00 00
>  27 00 30 3b 00 00
>
> for 48-240, 48-120 and 48-60 Hz. A driver that checks a mode against
> monitor_range then refuses VRR for the 240 Hz timing of that panel.
>
> Use the block in both cases. Without a range from the base block take
> the range from the descriptors. With one, keep its minimum and only
> raise the maximum, and only from descriptors that reach down into it,
> so that the result never goes below what the base block promises.
>
> monitor_range stays one range per connector. Only descriptors for the
> native panel range that declare the adaptive vertical total operation
> mode count: a descriptor for fixed average vertical total alone does
> not describe a range to pick a vertical total from. Where several
> count, the highest minimum and the highest maximum are used. Without
> a base range every rate in the result is then within the descriptor
> that reaches highest. With one, every rate is within the base range
> or within that descriptor, which overlaps it.
>
> The layout is taken from edid-decode (parse_displayid_adaptive_sync()
> in utils/edid-decode/parse-displayid-block.cpp of v4l-utils), not
> from the DisplayID text: a descriptor is 6 bytes plus the count in
> bits 6:4 of the block revision, byte 0 has the native panel range
> flag in bit 0 and the operation mode in bits 3:2 (1 for fixed average
> and adaptive vertical total), byte 2 is the minimum refresh rate,
> bytes 3-4 hold the maximum refresh rate minus one in ten bits. The
> block is read from any section of structure version 2.0 or later,
> which is what the panel above declares.
>
> This reaches every driver that reads monitor_range. A display with
> such a block and no base block range now has a range where it had
> none, which is the point for i915 and xe (their other VRR conditions
> still apply). amdgpu scans DisplayID tag 0x25 on its own when the
> minimum or the maximum is zero, and with a range from the
> Adaptive-Sync block that scan is no longer reached. When the display
> has no AMD VSDB, amdgpu takes monitor_range as its refresh rate
> range, so it follows the raised maximum, and a DP or eDP display that
> has only the Adaptive-Sync block can now pass its FreeSync test (a
> range wider than 10 Hz and a sink that ignores the MSA timing). With
> a VSDB that advertises FreeSync the range still comes from there.
>
> Signed-off-by: ElXreno <elxreno@gmail.com>

[Severity: High]
Could the Author header and Signed-off-by trailer use a full real name
instead of the handle ElXreno?  Documentation/process/submitting-patches.rst
requires a real name for the Developer's Certificate of Origin and does
not permit pseudonyms or handles.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114010749.1949247-1-elxreno@gmail.com?part=1