> -----Original Message----- > From: Intel-gfx <[email protected]> On Behalf Of Ville > Syrjälä > Sent: Thursday, 5 November 2026 20.31 > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [PATCH] drm/i915/cdclk: Ignore SWF18 in SKL CDCLK sanitization > > On Thu, Nov 05, 2026 at 02:47:37PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä <[email protected]> > > > > 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: [email protected] > > 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
Dropping the SWF18 check fixes the issue so, Reviewed-by: Mika Kahola <[email protected]> > > Signed-off-by: Ville Syrjälä <[email protected]> > > --- > > 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
