From patchwork Mon Oct 24 20:47:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paul Bolle X-Patchwork-Id: 9393257 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1FEAF6077A for ; Mon, 24 Oct 2016 20:48:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 11B6A28F9E for ; Mon, 24 Oct 2016 20:48:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 060E428FBE; Mon, 24 Oct 2016 20:48:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 75FF328FA8 for ; Mon, 24 Oct 2016 20:48:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BC78A6E19D; Mon, 24 Oct 2016 20:48:01 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) by gabe.freedesktop.org (Postfix) with ESMTPS id 011AE6E1AD for ; Mon, 24 Oct 2016 20:47:59 +0000 (UTC) Received: from localhost-localdomain ([83.160.161.190]) by smtp-cloud3.xs4all.net with ESMTP id zYnu1t00446mmVf01YnwWA; Mon, 24 Oct 2016 22:47:57 +0200 Message-ID: <1477342074.1872.24.camel@tiscali.nl> From: Paul Bolle To: Joonas Lahtinen , Daniel Vetter , Jani Nikula , David Airlie Date: Mon, 24 Oct 2016 22:47:54 +0200 In-Reply-To: <1476273998.9670.4.camel@tiscali.nl> References: <1476266167.7439.8.camel@tiscali.nl> <1476270522.2817.12.camel@linux.intel.com> <1476273998.9670.4.camel@tiscali.nl> X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 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) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP [Detailed post, but please give it a quick scan.] 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(): 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 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: