Claude review: Re: [PATCH] drm/i915: Don't set min_cdclk in the initial crtc_state

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: Re: [PATCH] drm/i915: Don't set min_cdclk in the initial crtc_state
Author: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Patches: 3
Reviewed: 2026-05-25T19:40:27.434712

---

This is a single-patch fix for a real display corruption bug on Gemini Lake (specifically an IdeaPad Duet 3). The analysis in the commit message is correct and the fix is sound.

**The core problem**: `intel_modeset_readout_hw_state()` computes and stores `crtc_state->min_cdclk` during initial hardware readout, and `intel_cdclk_update_hw_state()` then copies that value into `cdclk_state->min_cdclk[pipe]`. When the first atomic commit happens, `intel_atomic_check()` recomputes `new_crtc_state->min_cdclk` to the same value. The comparison logic in `intel_cdclk_update_crtc_min_cdclk()` (at `intel_cdclk.c:2941`) then sees `new_min_cdclk == old_min_cdclk` and returns 0 immediately — no CDCLK recalculation is triggered. If the BIOS/firmware left CDCLK at a frequency lower than `min_cdclk` requires, the display stays garbled.

**The fix**: By not setting `min_cdclk` during readout, both `old_crtc_state->min_cdclk` and `cdclk_state->min_cdclk[pipe]` start at 0. The first atomic check then sees a genuine change (0 → computed value), triggers CDCLK recalculation, and the clock gets bumped to the required frequency.

**Verdict**: The patch is correct and well-motivated. Minor observations below but nothing blocking.

---
Generated by Claude Code Patch Reviewer