[Bug 98214] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98214

--- Comment #10 from Paul Bolle <pebolle at tiscali.nl> ---
0) Partial copy of my message at
http://lkml.kernel.org/r/<1477342074.1872.24.camel@tiscali.nl> :

1) So I used the most reliable debugging tool that I actually
understand: printk():

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
intel_crtc_state *crtc_state
                return DRM_PLANE_HELPER_NO_SCALING;

        crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
-       cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+       if (WARN_ON_ONCE(!crtc_clock))
+               return DRM_PLANE_HELPER_NO_SCALING;

-       if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+       cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+       if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+               printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk,
crtc_clock);
                return DRM_PLANE_HELPER_NO_SCALING;
+       }
+
+       printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n",
cdclk, crtc_clock);

        /*
         * skl max scale is lower of:

2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 450000, but every now and then it briefly is 337500.

3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 450000, and a
roughly 300ms pause before the third call of that function. Example:

<7>[23758.501933] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250

This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.

4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20161026/1a6d0a2d/attachment.html>