From: Jani Nikula <jani.nikula@linux.intel.com>
To: Paul Bolle <pebolle@tiscali.nl>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Daniel Vetter <daniel.vetter@intel.com>,
        David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
In-Reply-To: <1477342074.1872.24.camel@tiscali.nl>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <1476266167.7439.8.camel@tiscali.nl> <1476270522.2817.12.camel@linux.intel.com> <1476273998.9670.4.camel@tiscali.nl> <1477342074.1872.24.camel@tiscali.nl>
Date: Tue, 25 Oct 2016 11:37:20 +0300
Message-ID: <87lgxcomdb.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3001
Lines: 77

On Mon, 24 Oct 2016, Paul Bolle <pebolle@tiscali.nl> wrote:
> [Detailed post, but please give it a quick scan.]

Please file the information in the bug you filed. Please attach dmesg
(again, on the bug) with drm.debug=14 and running your patch.

BR,
Jani.

>
> On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
>> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> > start.
>> 
>> That would be between v4.7 and v4.8. (I guess my report was
>> ambiguous.)
>> 
>> That might take some time. Because bisecting always takes a long time
>> and especially since hitting this WARNING sometimes takes over an hour.
>> Anyhow, please prod me if I stay silent for too long.
>
> 0) So I've lost my courage to do a bisect when my first attempt landed
> me in v4.6-rc3. This is about for issue popping up between v4.7 and
> v4.8-rc1.
>
> 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?
>
> To be continued,
>
>
> Paul Bolle

-- 
Jani Nikula, Intel Open Source Technology Center