Linux kernel -stable discussions
 help / color / mirror / Atom feed
* [PATCH] drm/i915/cdclk: Ignore SWF18 in SKL CDCLK sanitization
@ 2026-11-05 12:47 Ville Syrjala
  2026-11-05 18:30 ` Ville Syrjälä
  0 siblings, 1 reply; 2+ messages in thread
From: Ville Syrjala @ 2026-11-05 12:47 UTC (permalink / raw)
  To: intel-gfx; +Cc: intel-xe, stable

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.

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


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-05 18:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-05 12:47 [PATCH] drm/i915/cdclk: Ignore SWF18 in SKL CDCLK sanitization Ville Syrjala
2026-11-05 18:30 ` Ville Syrjälä

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox