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 > 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
