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 <[email protected]> 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/[email protected]?part=1
