diff mbox

[7/3] drm/i915: remove wait_for_vblank argument form intel_enable_pipe

Message ID 1389973873-2005-4-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni Jan. 17, 2014, 3:51 p.m. UTC 
From: Paulo Zanoni <paulo.r.zanoni@intel.com>

Add a nice comment explaining why we shouldn't wait for a vblank on
all cases, wait based on the HW gen, and add a comment saying we
should probably skip that wait on some of the previous HW gens.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

Comments

Lespiau, Damien Feb. 10, 2014, 2:33 p.m. UTC | #1 
On Fri, Jan 17, 2014 at 01:51:12PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> Add a nice comment explaining why we shouldn't wait for a vblank on
> all cases, wait based on the HW gen, and add a comment saying we
> should probably skip that wait on some of the previous HW gens.
> 
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>


Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>

Looking at BSpec for info on this, I didn't find any mention of having
to wait of a vblank indeed. There's a nice workaround we don't seem to
implement though (underrun when switching from one to multi-pipes,
display buffer related). I'm sure that's somewhere in a TODO list :)
Ville Syrjälä Feb. 10, 2014, 2:59 p.m. UTC | #2 
On Mon, Feb 10, 2014 at 02:33:07PM +0000, Damien Lespiau wrote:
> On Fri, Jan 17, 2014 at 01:51:12PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > 
> > Add a nice comment explaining why we shouldn't wait for a vblank on
> > all cases, wait based on the HW gen, and add a comment saying we
> > should probably skip that wait on some of the previous HW gens.
> > 
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> 
> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
> 
> Looking at BSpec for info on this, I didn't find any mention of having
> to wait of a vblank indeed. There's a nice workaround we don't seem to
> implement though (underrun when switching from one to multi-pipes,
> display buffer related). I'm sure that's somewhere in a TODO list :)

We implement something for HSW, but I'm not sure it's quite enough.
In any case I have patches lined up for disabling LP1+ watermarks when
doing one<->many pipes switch for PCH platforms. Which reminds I need
to stop slacking off and get those posted soon.
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b110da8..9f356f9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1745,12 +1745,11 @@  static void lpt_disable_pch_transcoder(struct drm_i915_private *dev_priv)
 /**
  * intel_enable_pipe - enable a pipe, asserting requirements
  * @crtc: crtc responsible for the pipe
- * @wait_for_vblank: whether we should for a vblank or not after enabling it
  *
  * Enable @crtc's pipe, making sure that various hardware specific requirements
  * are met, if applicable, e.g. PLL enabled, LVDS pairs enabled, etc.
  */
-static void intel_enable_pipe(struct intel_crtc *crtc, bool wait_for_vblank)
+static void intel_enable_pipe(struct intel_crtc *crtc)
 {
 	struct drm_device *dev = crtc->base.dev;
 	struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1797,7 +1796,15 @@  static void intel_enable_pipe(struct intel_crtc *crtc, bool wait_for_vblank)
 
 	I915_WRITE(reg, val | PIPECONF_ENABLE);
 	POSTING_READ(reg);
-	if (wait_for_vblank)
+
+	/*
+	 * There's no guarantee the pipe will really start running now. It
+	 * depends on the Gen, the output type and the relative order between
+	 * pipe and plane enabling. Avoid waiting on HSW+ since it's not
+	 * necessary.
+	 * TODO: audit the previous gens.
+	 */
+	if (INTEL_INFO(dev)->gen <= 7 && !IS_HASWELL(dev))
 		intel_wait_for_vblank(dev_priv->dev, pipe);
 }
 
@@ -3561,7 +3568,7 @@  static void ironlake_crtc_enable(struct drm_crtc *crtc)
 	intel_crtc_load_lut(crtc);
 
 	intel_update_watermarks(crtc);
-	intel_enable_pipe(intel_crtc, true);
+	intel_enable_pipe(intel_crtc);
 	intel_enable_primary_plane(dev_priv, plane, pipe);
 	intel_enable_planes(crtc);
 	intel_crtc_update_cursor(crtc, true);
@@ -3706,7 +3713,7 @@  static void haswell_crtc_enable(struct drm_crtc *crtc)
 	intel_ddi_enable_transcoder_func(crtc);
 
 	intel_update_watermarks(crtc);
-	intel_enable_pipe(intel_crtc, false);
+	intel_enable_pipe(intel_crtc);
 
 	if (intel_crtc->config.has_pch_encoder)
 		lpt_pch_enable(crtc);
@@ -4131,7 +4138,7 @@  static void valleyview_crtc_enable(struct drm_crtc *crtc)
 	intel_crtc_load_lut(crtc);
 
 	intel_update_watermarks(crtc);
-	intel_enable_pipe(intel_crtc, true);
+	intel_enable_pipe(intel_crtc);
 	intel_enable_primary_plane(dev_priv, plane, pipe);
 	intel_enable_planes(crtc);
 	intel_crtc_update_cursor(crtc, true);
@@ -4169,7 +4176,7 @@  static void i9xx_crtc_enable(struct drm_crtc *crtc)
 	intel_crtc_load_lut(crtc);
 
 	intel_update_watermarks(crtc);
-	intel_enable_pipe(intel_crtc, true);
+	intel_enable_pipe(intel_crtc);
 	intel_enable_primary_plane(dev_priv, plane, pipe);
 	intel_enable_planes(crtc);
 	/* The fixup needs to happen before cursor is enabled */