Re: [PATCH v2 26/27] drm/debugfs: Expose HDMI VRR in vrr_range debugfs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/debugfs: vrr_range_show() reports Max: 0 when HDMI VRRmax is 0
--

commit c20f012be0daea32ab333f3e4f526e77c8606b3b
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/debugfs: Expose HDMI VRR in vrr_range debugfs

This commit updates vrr_range_show() to report HDMI VRR limits from
display_info.hdmi.vrr_cap when HDMI VRR is supported, and protects access
to connector->status and connector->display_info with mode_config.mutex.

> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index a72f9723d3a97..476f44642ac3e 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -586,12 +586,26 @@ static ssize_t edid_write(struct file *file, const char __user *ubuf,
>  static int vrr_range_show(struct seq_file *m, void *data)
>  {
>  	struct drm_connector *connector = m->private;
> +	u16 min_vfreq, max_vfreq;
> +
> +	scoped_cond_guard(mutex_intr, return -EINTR,
> +			  &connector->dev->mode_config.mutex) {
> +		struct drm_display_info *info = &connector->display_info;
> +
> +		if (connector->status != connector_status_connected)
> +			return -ENODEV;
> +
> +		if (info->is_hdmi && info->hdmi.vrr_cap.supported) {
> +			min_vfreq = info->hdmi.vrr_cap.vrr_min;
> +			max_vfreq = info->hdmi.vrr_cap.vrr_max;
> +		} else {
> +			min_vfreq = info->monitor_range.min_vfreq;
> +			max_vfreq = info->monitor_range.max_vfreq;
> +		}

[Severity: Medium]
Can vrr_range_show() in drivers/gpu/drm/drm_debugfs.c report "Max: 0" when
an HDMI 2.1 sink advertises VRR support with VRRmax set to 0 in its HF-VSDB?

In drivers/gpu/drm/drm_edid.c, drm_parse_hdmi_gaming_info() sets
vrr->supported = true even when vrr->vrr_max is 0 (either because byte 10
of the HF-VSDB is omitted or because the 10-bit VRRmax field is 0, which
HDMI 2.1 uses when the upper refresh limit is below 100 Hz or defined by
the video mode / EDID monitor range):

	vrr->vrr_min = db[9] & DRM_EDID_VRR_MIN_MASK;
	vrr->supported = (vrr->vrr_min > 0 && vrr->vrr_min <= 48);

	if (cea_db_payload_len(db) < 10)
		return;

	vrr->vrr_max = (db[9] & DRM_EDID_VRR_MAX_UPPER_MASK) << 2 | db[10];
	vrr->supported &= (vrr->vrr_max == 0 || vrr->vrr_max >= 100);

Drivers such as amdgpu handle vrr_cap.vrr_max == 0 in
amdgpu_dm_update_freesync_caps() in
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_connector.c by falling back
to connector->display_info.monitor_range.max_vfreq (or the highest mode
refresh rate, AMD FreeSync VSDB, and panel quirks) and storing the resolved
bounds back into connector->display_info.monitor_range:

		if (vrr_cap->supported && vrr_cap->vrr_min > 0) {
			amdgpu_dm_connector->min_vfreq = vrr_cap->vrr_min;
			amdgpu_dm_connector->max_vfreq = vrr_cap->vrr_max ?
				vrr_cap->vrr_max :
				connector->display_info.monitor_range.max_vfreq;

By checking info->is_hdmi && info->hdmi.vrr_cap.supported first and
unconditionally reading info->hdmi.vrr_cap.vrr_max, won't vrr_range_show()
bypass info->monitor_range and output "Max: 0" whenever VRRmax is 0?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-vrr-limiter-uapi-v2-0-55f4215be2c2@collabora.com?part=26