Re: [PATCH] drm/i915/cdclk: Ignore SWF18 in SKL CDCLK sanitization

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 05, 2026 at 02:47:37PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Currently on SKL/derivatives we are checking whether
> the VBIOS/GOP programmed the SWF18 scratch register
> appropriately. Based on the original commit, and the
> set of bits checked, the code actually wanted to check
> SWF06 instead. Looks like it's just completely confused
> whether the register offset should be 0x6*4 vs. 0x18 vs.
> 0x18*4. SWF06 is where the VBIOS/GOP should stuff some
> information about what outputs it enabled. SWF18 is
> where the VBIOS/GOP is supposed to stuff the maximum
> CDCLK frequency.

Actually it's me who is confused. SWF06 is the CDCLK thing
and SWF18 is the pipe/output thing. So I guess it was checking
the right register after all. Oh well, that doesn't change the
fact that it doesn't work on chromebooks.

> 
> I suppose either of these scratch registers are part
> of the expected protocol between the VBIOS/GOP and
> driver, but it looks like at least some coreboot
> based systems don't set them up.
> 
> SWF18 not being populated leads us to reprogram the
> CDCLK PLL during driver initialization, while the
> display pipes are still potentially active. We also
> set CDCLK to its minimum frequency, under the
> assumption that nothing actually needs a higher
> CDCLK frequency when it hasn't even been correctly
> initialized.
> 
> Due to some other changes in the code we may no longer
> force a full CDCLK recalculation and reprogramming upon
> the first atomic commit, so CDCLK can remain at a
> potentially too low a frequency indefinitely.
> 
> To fix this let's just stop looking at SWF18 completely.
> The code is anyway confused about which register
> it's actually looking at, and we don't look at that
> register on any other platform either. We also do an
> actual readout of the CDCLK state from the hardware
> so we should be able to spot if anything is wrong
> enough to need reprogramming.
> 
> Cc: stable@vger.kernel.org
> Fixes: ba91b9eecb47 ("drm/i915/cdclk: Decouple cdclk from state->modeset")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16595
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17423
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +------------
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 92e6fca861f6..0f2f693c78d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1269,18 +1269,7 @@ static void skl_set_cdclk(struct intel_display *display,
>  
>  static void skl_sanitize_cdclk(struct intel_display *display)
>  {
> -	u32 cdctl, expected, swf18;
> -
> -	/*
> -	 * check if the pre-os initialized the display
> -	 * There is SWF18 scratchpad register defined which is set by the
> -	 * pre-os which can be used by the OS drivers to check the status
> -	 */
> -	swf18 = intel_de_read(display, SWF_ILK(0x18));
> -	if ((swf18 & 0x00FFFFFF) == 0) {
> -		drm_dbg_kms(display->drm, "Sanitizing CDCLK due to SWF18 0x%x\n", swf18);
> -		goto sanitize;
> -	}
> +	u32 cdctl, expected;
>  
>  	intel_update_cdclk(display);
>  	intel_cdclk_dump_config(display, &display->cdclk.hw, "Current CDCLK");
> -- 
> 2.56.0

-- 
Ville Syrjälä
Intel