From patchwork Thu Jun 21 00:08:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Souza, Jose" X-Patchwork-Id: 10478895 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 805F960230 for ; Thu, 21 Jun 2018 00:09:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7052528E5B for ; Thu, 21 Jun 2018 00:09:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6483D28F4A; Thu, 21 Jun 2018 00:09:40 +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=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, 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 F3BFE28E5B for ; Thu, 21 Jun 2018 00:09:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F42266E831; Thu, 21 Jun 2018 00:09:38 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 58C666E831 for ; Thu, 21 Jun 2018 00:09:37 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2018 17:09:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,249,1526367600"; d="scan'208";a="234273058" Received: from josouza-mobl.jf.intel.com ([10.24.11.40]) by orsmga005.jf.intel.com with ESMTP; 20 Jun 2018 17:09:34 -0700 From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= To: intel-gfx@lists.freedesktop.org Date: Wed, 20 Jun 2018 17:08:27 -0700 Message-Id: <20180621000827.28301-2-jose.souza@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180621000827.28301-1-jose.souza@intel.com> References: <20180621000827.28301-1-jose.souza@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paulo Zanoni Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP A simple page flip can cause the CFB required size to increase and if it is bigger than the currently allocated CFB it needs to be resized to activate FBC again. Until now this case was not being handled but CI is starting to get some of this errors. So here it will free the old CFB and try to allocate the required CFB in the schedule activation work, it will happen after one vblank so is guarantee that FBC was completed disabled and is not using CFB. Cc: Paulo Zanoni Signed-off-by: José Roberto de Souza Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683 --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_fbc.c | 45 ++++++++++++++++++++------------ 2 files changed, 31 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 735f695cb889..5a5c3b9e421e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -586,6 +586,8 @@ struct intel_fbc { } work; const char *no_fbc_reason; + + bool cfb_try_resize; }; /* diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index eb0f95390968..62f0c99d45c2 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -41,6 +41,9 @@ #include "intel_drv.h" #include "i915_drv.h" +static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv); +static int intel_fbc_alloc_cfb(struct intel_crtc *crtc); + static inline bool fbc_supported(struct drm_i915_private *dev_priv) { return HAS_FBC(dev_priv); @@ -446,6 +449,15 @@ static void intel_fbc_work_fn(struct work_struct *__work) goto retry; } + if (fbc->cfb_try_resize) { + fbc->cfb_try_resize = false; + __intel_fbc_cleanup_cfb(dev_priv); + if (intel_fbc_alloc_cfb(crtc)) { + fbc->no_fbc_reason = "not enough stolen memory"; + goto out; + } + } + intel_fbc_hw_activate(dev_priv); work->scheduled = false; @@ -846,22 +858,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc) return false; } - /* It is possible for the required CFB size change without a - * crtc->disable + crtc->enable since it is possible to change the - * stride without triggering a full modeset. Since we try to - * over-allocate the CFB, there's a chance we may keep FBC enabled even - * if this happens, but if we exceed the current CFB size we'll have to - * disable FBC. Notice that it would be possible to disable FBC, wait - * for a frame, free the stolen node, then try to reenable FBC in case - * we didn't get any invalidate/deactivate calls, but this would require - * a lot of tracking just for a specific case. If we conclude it's an - * important case, we can implement it later. */ - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) > - fbc->compressed_fb.size * fbc->threshold) { - fbc->no_fbc_reason = "CFB requirements changed"; - return false; - } - /* * Work around a problem on GEN9+ HW, where enabling FBC on a plane * having a Y offset that isn't divisible by 4 causes FIFO underrun @@ -873,6 +869,22 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc) return false; } + if (!drm_mm_node_allocated(&fbc->compressed_fb)) + return false; + + /* It is possible for the required CFB size change without a + * crtc->disable + crtc->enable since it is possible to change the + * stride without triggering a full modeset. Since we try to + * over-allocate the CFB, there's a chance we may keep FBC enabled even + * if this happens, but if we exceed the current CFB size we'll have to + * resize CFB. + */ + if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) > + (fbc->compressed_fb.size * fbc->threshold)) { + fbc->cfb_try_resize = true; + DRM_DEBUG_KMS("CFB memory requirements have changed"); + } + return true; } @@ -1204,6 +1216,7 @@ void intel_fbc_enable(struct intel_crtc *crtc, fbc->enabled = true; fbc->crtc = crtc; + fbc->cfb_try_resize = false; out: mutex_unlock(&fbc->lock); }