From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Re: [PATCH] drm/i915: Don't set min_cdclk in the initial crtc_state Date: Mon, 25 May 2026 19:40:27 +1000 Message-ID: In-Reply-To: References: X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: Re: [PATCH] drm/i915: Don't set min_cdclk in the initial crtc_state Author: Ville =3D?iso-8859-1?Q?Syrj=3DE4l=3DE4?=3D 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 co= rrect and the fix is sound. **The core problem**: `intel_modeset_readout_hw_state()` computes and store= s `crtc_state->min_cdclk` during initial hardware readout, and `intel_cdclk= _update_hw_state()` then copies that value into `cdclk_state->min_cdclk[pip= e]`. When the first atomic commit happens, `intel_atomic_check()` recompute= s `new_crtc_state->min_cdclk` to the same value. The comparison logic in `i= ntel_cdclk_update_crtc_min_cdclk()` (at `intel_cdclk.c:2941`) then sees `ne= w_min_cdclk =3D=3D old_min_cdclk` and returns 0 immediately =E2=80=94 no CD= CLK recalculation is triggered. If the BIOS/firmware left CDCLK at a freque= ncy lower than `min_cdclk` requires, the display stays garbled. **The fix**: By not setting `min_cdclk` during readout, both `old_crtc_stat= e->min_cdclk` and `cdclk_state->min_cdclk[pipe]` start at 0. The first atom= ic check then sees a genuine change (0 =E2=86=92 computed value), triggers = CDCLK recalculation, and the clock gets bumped to the required frequency. **Verdict**: The patch is correct and well-motivated. Minor observations be= low but nothing blocking. --- Generated by Claude Code Patch Reviewer