From patchwork Thu Sep 10 21:38:53 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jesse Barnes X-Patchwork-Id: 7155921 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 30D90BEEC1 for ; Thu, 10 Sep 2015 21:39:16 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3D5102082C for ; Thu, 10 Sep 2015 21:39:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id ED86B2082A for ; Thu, 10 Sep 2015 21:39:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5A2776E202; Thu, 10 Sep 2015 14:39:13 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by gabe.freedesktop.org (Postfix) with SMTP id D8C0C6E202 for ; Thu, 10 Sep 2015 14:39:11 -0700 (PDT) Received: (qmail 24897 invoked by uid 0); 10 Sep 2015 21:39:08 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 10 Sep 2015 21:39:08 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Ffex1r00E2UhLwi01ff056; Thu, 10 Sep 2015 21:39:07 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=TBVoxVdAAAAA:8 a=GhZ5P8ky69gA:10 a=noBwr2J6l1kA:10 a=ff-B7xzCdYMA:10 a=e5mUnYsNAAAA:8 a=qt1y_Qsm3mV13CiWxvYA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuousgeek.org; s=default; h=References:In-Reply-To:Message-Id:Date:Subject:To:From; bh=B2pEj69/pRqU01vPUoyfHV4QbsUDE96gbsT8+riZQH4=; b=lfOyWRbRDJkT0lOmAIISZ+0B1o3/Mm+YR1zpIkL7Pr+9+RTdi9MhoWPnLHMn5WKT7OB9lbbayZm/gsratXaN5uDMgPcaG0/oqCMkjGDIfuq0XAwruU0S5/yO1CKLGCw4; Received: from [67.161.37.189] (port=37126 helo=localhost.localdomain) by box514.bluehost.com with esmtpsa (TLSv1.2:AES128-SHA256:128) (Exim 4.84) (envelope-from ) id 1Za9YY-0002s7-8J for intel-gfx@lists.freedesktop.org; Thu, 10 Sep 2015 15:38:58 -0600 From: Jesse Barnes To: intel-gfx@lists.freedesktop.org Date: Thu, 10 Sep 2015 14:38:53 -0700 Message-Id: <1441921133-3381-1-git-send-email-jbarnes@virtuousgeek.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1441899263-12986-1-git-send-email-jbarnes@virtuousgeek.org> References: <1441899263-12986-1-git-send-email-jbarnes@virtuousgeek.org> X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org} {sentby:smtp auth 67.161.37.189 authed with jbarnes@virtuousgeek.org} Subject: [Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v2 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: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On HSW at least (still testing other platforms, but should be harmless elsewhere), the DSL reg reads back as 0 when read around vblank start time. This ends up confusing the atomic start/end checking code, since it causes the update to appear as if it crossed a frame count boundary. Avoid the problem by making sure we don't return scanline_offset from the get_crtc_scanline function. In moving the code there, I add to add an additional delay since it could be called and have a legitimate 0 result for some time (depending on the pixel clock). v2: move hsw dsl read hack to get_crtc_scanline (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Signed-off-by: Jesse Barnes Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 90bc6c2..97e5d52 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -697,6 +697,27 @@ static int __intel_get_crtc_scanline(struct intel_crtc *crtc) position = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & DSL_LINEMASK_GEN3; /* + * On HSW, the DSL reg (0x70000) appears to return 0 if we + * read it right around the start of vblank. So try it again + * so we don't accidentally end up spanning a vblank frame + * increment, causing the pipe_update_end() code to squak at us. + */ + if (IS_HASWELL(dev) && !position) { + int i, temp; + + for (i = 0; i < 100; i++) { + udelay(1); + temp = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & + DSL_LINEMASK_GEN3; + if (temp != position) { + position = temp; + goto out; + } + } + } + +out: + /* * See update_scanline_offset() for the details on the * scanline_offset adjustment. */