* [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
* Re: [PATCH] drm/i915/cdclk: Ignore SWF18 in SKL CDCLK sanitization
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ä
0 siblings, 0 replies; 2+ messages in thread
From: Ville Syrjälä @ 2026-11-05 18:30 UTC (permalink / raw)
To: intel-gfx; +Cc: intel-xe, stable
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
^ permalink raw reply [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