Re: [PATCH v2 01/56] drm/i915/hdmi: Parse FRL max link rate from VBT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm: hardcoded platform check disables FRL on newer hardware
- [High] drm/hdmi: FRL incorrectly disabled when VBT specifies platform default rate
--

commit df17bdb1a2102d3ca65a52512220409d6c6fe624
Author: Vandita Kulkarni <vandita.kulkarni@intel.com>

drm/i915/hdmi: Parse FRL max link rate from VBT

Parse the maximum FRL link rate from VBT and store it for use
during FRL mode selection and link training.

> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> index 7b6a6f8c3cf19..7181237508b3a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
[ ... ]
> @@ -2788,12 +2788,45 @@ static bool is_port_valid(struct intel_display *display, enum port port)
>  	return true;
>  }
>  
> +int intel_bios_hdmi_max_frl_rate(const struct intel_bios_encoder_data *devdata)
> +{
> +	struct intel_display *display = devdata->display;
> +
> +	if (display->vbt.version < 237)
> +		return 0;
> +
> +	/*
> +	 * When hdmi_max_frl_rate_valid is 0 the VBT does not specify a maximum
> +	 * FRL rate, so don't use it to limit the FRL rate on FRL-capable
> +	 * platforms.
> +	 */
> +	if (!devdata->child.hdmi_max_frl_rate_valid)
> +		return display->platform.meteorlake ? 12000000 : 0;

[Severity: High]
Does this hardcoded check disable FRL on newer hardware?

By restricting the fallback rate exclusively to Meteorlake, 0 is returned
for all newer FRL-capable platforms (e.g., Lunar Lake, Panther Lake) when
the VBT lacks a valid max FRL rate.

Downstream callers like intel_hdmi_compute_config() in intel_hdmi.c use
the return value as a boolean condition:

    if (HAS_HDMI_FRL(display) && intel_bios_hdmi_max_frl_rate(encoder->devdata) && ...)
        enable_frl = true;

Returning 0 causes enable_frl to evaluate to false, which means FRL will
never be enabled on newer hardware architectures under these conditions.

> +
> +	switch (devdata->child.hdmi_max_frl_rate) {
> +	default:
> +	case HDMI_MAX_FRL_RATE_PLATFORM:
> +		return 0;

[Severity: High]
Does returning 0 here inadvertently disable FRL when the VBT specifies
the platform default rate?

Although the comment above mentions that a missing VBT specification
should not limit the FRL rate, returning 0 signals callers to completely
disable FRL rather than applying a platform fallback.

Later in the series, the caller logic in intel_hdmi_compute_config()
treats 0 as a strict boolean requirement and cap:

    if (HAS_HDMI_FRL(display) &&
        intel_bios_hdmi_max_frl_rate(encoder->devdata) &&
        intel_hdmi->has_sink_hdmi_21)
        enable_frl = true;

Because intel_bios_hdmi_max_frl_rate() returns 0, enable_frl stays false
and the rate cap becomes 0. This completely disables HDMI 2.1 Fixed
Rate Link capabilities on any platform where the VBT is configured to use
the platform's native default or if the VBT is older than version 237.

> +	case HDMI_MAX_FRL_RATE_3G:
> +		return 3000000;
> +	case HDMI_MAX_FRL_RATE_6G:
> +		return 6000000;
> +	case HDMI_MAX_FRL_RATE_8G:
> +		return 8000000;
> +	case HDMI_MAX_FRL_RATE_10G:
> +		return 10000000;
> +	case HDMI_MAX_FRL_RATE_12G:
> +		return 12000000;
> +	}
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012035806.3361439-1-ankit.k.nautiyal@intel.com?part=1