All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [PATCH] drm/i915: PSR: Flush means invalidate + flush
Date: Wed,  8 Jul 2015 16:21:31 -0700	[thread overview]
Message-ID: <1436397691-2480-1-git-send-email-rodrigo.vivi@intel.com> (raw)
In-Reply-To: <CA+gsUGTAJfeHB_FWm4mPhTmf4HyUX7yitpWgDR+Yv+rWXR=Q=Q@mail.gmail.com>

Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.

On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracking like when flush has been originated by a flip.
Also flip had just invalidated it already.

It also uses origin to minimize the a bit the amount of
disable/enabled, mainly when flip already had invalidated.

With this patch in place it is possible to do a flush on dirty areas
properly in a following patch.

v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_drv.h         |  3 ++-
 drivers/gpu/drm/i915/intel_frontbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_psr.c         | 40 +++++++++++++++++---------------
 3 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index beeb4d3..c863511 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1329,7 +1329,8 @@ void intel_psr_disable(struct intel_dp *intel_dp);
 void intel_psr_invalidate(struct drm_device *dev,
 			  unsigned frontbuffer_bits);
 void intel_psr_flush(struct drm_device *dev,
-		     unsigned frontbuffer_bits);
+		     unsigned frontbuffer_bits,
+		     enum fb_op_origin origin);
 void intel_psr_init(struct drm_device *dev);
 void intel_psr_single_frame_update(struct drm_device *dev,
 				   unsigned frontbuffer_bits);
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
index cb5a6f0..e73d2ff0 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -128,7 +128,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
 		return;
 
 	intel_edp_drrs_flush(dev, frontbuffer_bits);
-	intel_psr_flush(dev, frontbuffer_bits);
+	intel_psr_flush(dev, frontbuffer_bits, origin);
 	intel_fbc_flush(dev_priv, frontbuffer_bits);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d79ba58..6db043f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -680,6 +680,7 @@ void intel_psr_invalidate(struct drm_device *dev,
  * intel_psr_flush - Flush PSR
  * @dev: DRM device
  * @frontbuffer_bits: frontbuffer plane tracking bits
+ * @origin: which operation caused the flush
  *
  * Since the hardware frontbuffer tracking has gaps we need to integrate
  * with the software frontbuffer tracking. This function gets called every
@@ -689,7 +690,7 @@ void intel_psr_invalidate(struct drm_device *dev,
  * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
  */
 void intel_psr_flush(struct drm_device *dev,
-		     unsigned frontbuffer_bits)
+		     unsigned frontbuffer_bits, enum fb_op_origin origin)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_crtc *crtc;
@@ -707,24 +708,25 @@ void intel_psr_flush(struct drm_device *dev,
 	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
 	dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
-	/*
-	 * On Haswell sprite plane updates don't result in a psr invalidating
-	 * signal in the hardware. Which means we need to manually fake this in
-	 * software for all flushes, not just when we've seen a preceding
-	 * invalidation through frontbuffer rendering.
-	 */
-	if (IS_HASWELL(dev) &&
-	    (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe)))
-		intel_psr_exit(dev);
-
-	/*
-	 * On Valleyview and Cherryview we don't use hardware tracking so
-	 * any plane updates or cursor moves don't result in a PSR
-	 * invalidating. Which means we need to manually fake this in
-	 * software for all flushes, not just when we've seen a preceding
-	 * invalidation through frontbuffer rendering. */
-	if (frontbuffer_bits && !HAS_DDI(dev))
-		intel_psr_exit(dev);
+	if (HAS_DDI(dev)) {
+		/*
+		 * By definition every flush should mean invalidate + flush,
+		 * however on core platforms let's minimize the
+		 * disable/re-enable so we can avoid the invalidate when flip
+		 * originated the flush.
+		 */
+		if (frontbuffer_bits && origin != ORIGIN_FLIP)
+			intel_psr_exit(dev);
+	} else {
+		/*
+		 * On Valleyview and Cherryview we don't use hardware tracking
+		 * so any plane updates or cursor moves don't result in a PSR
+		 * invalidating. Which means we need to manually fake this in
+		 * software for all flushes.
+		 */
+		if (frontbuffer_bits)
+			intel_psr_exit(dev);
+	}
 
 	if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
 		schedule_delayed_work(&dev_priv->psr.work,
-- 
2.1.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-07-08 23:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 23:28 [PATCH 1/7] drm/i915: Add origin to frontbuffer tracking flush Rodrigo Vivi
2015-07-07 23:28 ` [PATCH 2/7] drm/i915: PSR: Flush means invalidate + flush Rodrigo Vivi
2015-07-08 13:58   ` Paulo Zanoni
2015-07-08 23:21     ` Rodrigo Vivi [this message]
2015-07-09 12:58       ` [PATCH] " Paulo Zanoni
2015-07-07 23:28 ` [PATCH 3/7] drm/i915: PSR: dirty fb operation flushsing frontbuffer Rodrigo Vivi
2015-07-08  9:47   ` Daniel Vetter
2015-07-08 14:15     ` Paulo Zanoni
2015-07-08 23:22       ` [PATCH] drm/i915: " Rodrigo Vivi
2015-07-09 13:04         ` Paulo Zanoni
2015-07-09 15:25           ` Daniel Vetter
2015-07-07 23:28 ` [PATCH 4/7] drm/i915: PSR: Remove Low Power HW tracking mask Rodrigo Vivi
2015-07-08 14:26   ` Paulo Zanoni
2015-07-07 23:28 ` [PATCH 5/7] drm/i915: PSR: Increase idle_frames Rodrigo Vivi
2015-07-08 14:32   ` Paulo Zanoni
2015-07-07 23:28 ` [PATCH 6/7] drm/i915: fbdev_set_par reliably invalidating frontbuffer Rodrigo Vivi
2015-07-08  9:44   ` Daniel Vetter
2015-07-08 23:24     ` [PATCH] " Rodrigo Vivi
2015-07-09 13:10       ` Paulo Zanoni
2015-07-09 16:47         ` Vivi, Rodrigo
2015-07-09 16:56         ` Rodrigo Vivi
2015-07-09 18:46           ` Paulo Zanoni
2015-07-09 19:56             ` Daniel Vetter
2015-07-09 20:40               ` Vivi, Rodrigo
2015-07-07 23:28 ` [PATCH 7/7] drm/i915: fbdev restore mode needs to invalidate frontbuffer Rodrigo Vivi
2015-07-08 15:04   ` shuang.he
2015-07-08 18:05   ` Paulo Zanoni
2015-07-08 23:25     ` [PATCH] " Rodrigo Vivi
2015-07-09 13:19       ` shuang.he
2015-07-09 18:54       ` Paulo Zanoni
2015-07-09 19:00         ` Vivi, Rodrigo
2015-07-09 19:51           ` Daniel Vetter
2015-07-09 15:26     ` [PATCH 7/7] " Daniel Vetter
2015-07-09 17:08       ` [PATCH igt] tests: add kms_fbcon_fbt Paulo Zanoni
2015-07-08 13:41 ` [PATCH 1/7] drm/i915: Add origin to frontbuffer tracking flush Paulo Zanoni
2015-07-08 15:29   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1436397691-2480-1-git-send-email-rodrigo.vivi@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.