From patchwork Wed Nov 5 15:13:27 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mika Kuoppala X-Patchwork-Id: 5235031 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 89FA49F295 for ; Wed, 5 Nov 2014 15:11:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9F2A420165 for ; Wed, 5 Nov 2014 15:11:25 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 0DE90201D3 for ; Wed, 5 Nov 2014 15:11:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 702CA6E95F; Wed, 5 Nov 2014 07:11:23 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTP id A01676E95D for ; Wed, 5 Nov 2014 07:11:22 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 05 Nov 2014 07:08:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,320,1413270000"; d="scan'208";a="602790014" Received: from rosetta.fi.intel.com (HELO rosetta) ([10.237.72.83]) by orsmga001.jf.intel.com with ESMTP; 05 Nov 2014 07:10:56 -0800 Received: by rosetta (Postfix, from userid 1000) id 7197980052; Wed, 5 Nov 2014 17:13:38 +0200 (EET) From: Mika Kuoppala To: intel-gfx@lists.freedesktop.org Date: Wed, 5 Nov 2014 17:13:27 +0200 Message-Id: <1415200407-27954-1-git-send-email-mika.kuoppala@intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <20141105082543.GS13658@nuc-i3427.alporthouse.com> References: <20141105082543.GS13658@nuc-i3427.alporthouse.com> MIME-Version: 1.0 Cc: "S, Deepak" , shuang.he@linux.intel.com Subject: [Intel-gfx] [PATCH] drm/i915: Wait old forcewake ack to clear on vlv 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-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable 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 with commit 5cb13c07dae73380d8b3ddc792740487b8742938 Author: Deepak S Date: Thu Sep 18 18:51:50 2014 +0530 drm/i915/vlv: Remove check for Old Ack during forcewake we didn't wait anymore for old ack bit clearing in basis of workaround WaRsDontPollForAckOnClearingFWBits. That WA says that driver sw should not wait for ack on clearing fw, as the clearing is done lazily. Only when all the the fws are cleared, the acks will clear. When in multibit fw use case. But as we only use one bit per engine, and the assumption in here is that engines are independant, our vlv/chv forcewake use case does not correlate with WaRsDontPollForAckOnClearingFWBits. So revert into waiting the ack to clear, because there is only one bit to wait. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85684 Tested-by: lu hua Cc: Chris Wilson Cc: Ville Syrjälä Cc: S, Deepak Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_uncore.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 9427641..e315bce 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -195,15 +195,22 @@ static void __vlv_force_wake_get(struct drm_i915_private *dev_priv, int fw_engine) { /* - * WaRsDontPollForAckOnClearingFWBits:vlv - * Hardware clears ack bits lazily (only when all ack - * bits become 0) so don't poll for individiual ack - * bits to be clear here like on other platforms. + * WaRsDontPollForAckOnClearingFWBits is not required + * here as we only do one bit per engine so, the lazy + * clearing of bits is not of our concern. + * + * XXX Even if we access multi-threaded forcewake registers, we + * use only one bit in it (another bit for userspace). Multibit access + * is broken on multiple gens (IVB, BDW). See WaRSForceSingleThreadFW. */ /* Check for Render Engine */ if (FORCEWAKE_RENDER & fw_engine) { + if (wait_for_atomic((__raw_i915_read32(dev_priv, FORCEWAKE_ACK_VLV) & + FORCEWAKE_KERNEL) == 0, FORCEWAKE_ACK_TIMEOUT_MS)) + DRM_ERROR("Timed out: waiting for old Render ack to clear.\n"); + __raw_i915_write32(dev_priv, FORCEWAKE_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL)); @@ -217,6 +224,11 @@ static void __vlv_force_wake_get(struct drm_i915_private *dev_priv, /* Check for Media Engine */ if (FORCEWAKE_MEDIA & fw_engine) { + if (wait_for_atomic((__raw_i915_read32(dev_priv, FORCEWAKE_ACK_MEDIA_VLV) & + FORCEWAKE_KERNEL) == 0, FORCEWAKE_ACK_TIMEOUT_MS)) + DRM_ERROR("Timed out: waiting for old media ack to clear.\n"); + + __raw_i915_write32(dev_priv, FORCEWAKE_MEDIA_VLV, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL));