Ben Widawsky | 25 May 2013 23:42

[PATCH] drm/i915: Fix error state memory leaks

Found with kmemleak.

Signed-off-by: Ben Widawsky <ben <at> bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_irq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6efe3b0..4df2b3f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
 <at>  <at>  -1564,11 +1564,13  <at>  <at>  i915_error_state_free(struct kref *error_ref)
 	for (i = 0; i < ARRAY_SIZE(error->ring); i++) {
 		i915_error_object_free(error->ring[i].batchbuffer);
 		i915_error_object_free(error->ring[i].ringbuffer);
+		i915_error_object_free(error->ring[i].ctx);
 		kfree(error->ring[i].requests);
 	}

 	kfree(error->active_bo);
 	kfree(error->overlay);
+	kfree(error->display);
 	kfree(error);
 }
 static void capture_bo(struct drm_i915_error_buffer *err,
--

-- 
1.8.2.3
Ben Widawsky | 25 May 2013 21:26

[PATCH 00/34] PPGTT prep part 2 (and unmerged part 1)

Hello.

I'm continuing to develop full PPGTT support for the i915 driver. This
series is a follow-up to the previously posted RFC [1]. This series
contains reworked versions of the unmerged patches (fingers crossed that
I didn't miss review comments). I've rebased this series to hell and
back, so I'm sure there are some lingering errors due to that. I've found
several, but my eyes are no longer capable of finding them. I've also added
some last minute fixups, which I always promise myself I'll never do because
they always have bugs.

To reiterate the steps I am planning to take which I did this in the
previous RFC [1], but it has changed a bit:

1. Make a link between contexts and PPGTT. Every context has  it's own
   address space implemented.
2. Create the VMA/VM, plumb through the driver.
3. Create a context per fd. This involves abstracting the notion of
   context to not just mean a HW context, but also an address space.
4. Switch address spaces on context switch.
5. Develop interfaces.

This patch series addresses steps 1 & 2. A lot of the future patches
should have much less room for debate on what color to paint the
bikeshed, so I feel this is a good point to submit for some review. I am
currently developing 3 & 4. I have some half baked patches which aren't
really ready, but do give me some notion that things will work.  Note
that The order of 3 and 4 really matter because if we start switching
page tables for applications not using contexts, everything will blow up
pretty badly.
(Continue reading)

Paulo Zanoni | 24 May 2013 16:59
Picon
Gravatar

[PATCH 0/5] Haswell watermarks

From: Paulo Zanoni <paulo.r.zanoni <at> intel.com>

Hi

This series is a new version of "drm/i915: replace snb_update_wm with
haswell_update_wm on HSW". Ville asked to split the series into smaller patches,
so here they are. I also implemented the other suggestions made by Ville.

After this series, the only thing missing for correctness of the Haswell
watermark register values will be to use the correct mode clock when calculating
linetime watermarks. I had a patch for this, but Daniel suggested to wait until
we merge "drm/i915: store adjust dotclock in adjustede_mode->clock". I can
already see us reaching PC7 state with this series on eDP 1920x1080 with
138.78MHz pixel clock.

Thanks,
Paulo

Paulo Zanoni (5):
  drm/i915: add "enable" argument to intel_update_sprite_watermarks
  drm/i915: add haswell_update_sprite_wm
  drm/i915: properly set HSW WM_PIPE registers
  drm/i915: properly set HSW WM_LP watermarks
  drm/i915: add support for 5/6 data buffer partitioning on Haswell

 drivers/gpu/drm/i915/i915_drv.h     |   3 +-
 drivers/gpu/drm/i915/i915_reg.h     |   7 +
 drivers/gpu/drm/i915/intel_drv.h    |  14 +-
 drivers/gpu/drm/i915/intel_pm.c     | 588 ++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_sprite.c |   8 +-
(Continue reading)

Jani Nikula | 24 May 2013 16:19
Picon
Favicon

[RFC PATCH] drm/i915: move limits, pll find functions to a new file

This was a quick patch to see if it would be easy to extract the limit
and pll stuff from intel_display.c to a separate file. Turns out it's
trivial, and reduces the size of overbloated intel_display.c nicely:

 drivers/gpu/drm/i915/Makefile        |    1 +
 drivers/gpu/drm/i915/intel_display.c |  645 +--------------------------------
 drivers/gpu/drm/i915/intel_drv.h     |    7 +
 drivers/gpu/drm/i915/intel_limits.c  |  648 ++++++++++++++++++++++++++++++++++
 4 files changed, 670 insertions(+), 631 deletions(-)

Opinions, bikesheds?

Signed-off-by: Jani Nikula <jani.nikula <at> intel.com>
---
 drivers/gpu/drm/i915/Makefile        |    1 +
 drivers/gpu/drm/i915/intel_display.c |  645 +--------------------------------
 drivers/gpu/drm/i915/intel_drv.h     |    7 +
 drivers/gpu/drm/i915/intel_limits.c  |  648 ++++++++++++++++++++++++++++++++++
 4 files changed, 670 insertions(+), 631 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_limits.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 40034ec..b9d7426 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
 <at>  <at>  -21,6 +21,7  <at>  <at>  i915-y := i915_drv.o i915_dma.o i915_irq.o \
 	  intel_crt.o \
 	  intel_lvds.o \
 	  intel_bios.o \
+	  intel_limits.o \
(Continue reading)

Chris Wilson | 24 May 2013 12:45
Picon

[PATCH] drm/i915: Suppress spurious EIO when moving away from the GPU domain

If reset fails, the GPU is declared wedged. This ideally should never
happen, but very rarely it does. After the GPU is declared wedged, we
must allow userspace to continue to use its mapping of bo in order to
recover its data (and in some cases in order for memory management to
continue unabated). Obviously after the GPU is wedged, no bo are
currently accessed by the GPU and so we can complete any waits or domain
transitions away from the GPU. Currently, we fail this essential task
and instead report EIO and send a SIGBUS to the affected process -
causing major loss of data (by killing X or compiz).

Fixes regression from
commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
Author: Daniel Vetter <daniel.vetter <at> ffwll.ch>
Date:   Thu Nov 15 17:17:22 2012 +0100

    drm/i915: clear up wedged transitions

v2: Add comments.

References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
Signed-off-by: Chris Wilson <chris <at> chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter <at> ffwll.ch>
Cc: Damien Lespiau <damien.lespiau <at> intel.com>
Cc: stable <at> vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem.c |   33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
(Continue reading)

Paulo Zanoni | 23 May 2013 23:30
Picon
Gravatar

[PATCH] drm/i915: Haswell FBC supports up to 4096x4096

From: Paulo Zanoni <paulo.r.zanoni <at> intel.com>

But only the first 2048 lines will be compressed. No problem.

With this I can finally see FBC on my 2560x1440 DP monitor, which
gives me a boost on the PC7 residency.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni <at> intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6fdfd1a..190bae5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
 <at>  <at>  -431,7 +431,7  <at>  <at>  void intel_disable_fbc(struct drm_device *dev)
  *   - no pixel mulitply/line duplication
  *   - no alpha buffer discard
  *   - no dual wide
- *   - framebuffer <= 2048 in width, 1536 in height
+ *   - framebuffer <= max_hdisplay in width, max_vdisplay in height
  *
  * We can't assume that any compression will take place (worst case),
  * so the compressed buffer has to be the same size as the uncompressed
 <at>  <at>  -449,6 +449,7  <at>  <at>  void intel_update_fbc(struct drm_device *dev)
 	struct intel_framebuffer *intel_fb;
 	struct drm_i915_gem_object *obj;
 	int enable_fbc;
+	unsigned int max_vdisplay, max_hdisplay;
(Continue reading)

Pedro Ribeiro | 23 May 2013 23:10
Picon

g45-h264 branch development - stopped for good?

Hi Haihao and rest of the list,

I've noticed that the g45 branch seems pretty dead and hasn't been synced with the main tree since October 2012. 

Are there any plans to continue further work in this branch and integrate this into the main one? From my experiments, it seems that 720p plays well, but 1080p is a bit choppy.

There are still thousands of laptops with gm45 laying around, and one of the best things about Linux is that it can breathe new life into old laptops...

Regards,
Pedro
_______________________________________________
Intel-gfx mailing list
Intel-gfx <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ville.syrjala | 23 May 2013 16:45
Picon

[PATCH] drm/i915: Attempt to fix FBC render tracking with hardware contexts

From: Ville Syrjälä <ville.syrjala <at> linux.intel.com>

Sadly the FBC_RT_BASE register is part of the hardware context. A
context switch can therefore restore a stale value to the register.
To fix things up, always add an LRI after MI_SET_CONTEXT to update
the register value.

There's still a problem though. If we flip to another buffer between
inserting the LRI to the ring, and the CS actually executing it, a stale
value will again be restored. To fix that, insert another LRI when
updating the FBC state. This won't allow the stale value to persist
indefinitely. So any rendering happening between restoring the stale value
and the LRI fixing it up, will use the stale value. But said rendering
can't be targetting the current front buffer anyway as that would imply
that we queued up some rendering to the new front buffer, and then failed
to wait for it to finish before the flip actually happened.

Signed-off-by: Ville Syrjälä <ville.syrjala <at> linux.intel.com>
---

Let's call this option a). The other options are:
b) Update FBC_RT_BASE at every execbuffer
c) Update all saved contexts manually just before we write FBC_RT_BASE
   The docs dicourage manually poking the contexts though
d) some other approach I didn't consider?

I didn't actually test this (it compiles though :). Would be nice to
have a test case that targets these problems...

I also plugged it into gen7 codepaths too, in case someone would want to
test it there.

 drivers/gpu/drm/i915/i915_drv.h         |  2 ++
 drivers/gpu/drm/i915/i915_gem_context.c | 30 ++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_pm.c         | 22 ++++++++++++++++++++--
 3 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 360b582..953b1c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
 <at>  <at>  -1005,6 +1005,7  <at>  <at>  typedef struct drm_i915_private {
 	unsigned int cfb_fb;
 	enum plane cfb_plane;
 	int cfb_y;
+	uint32_t cfb_rt_base;
 	struct intel_fbc_work *fbc_work;

 	struct intel_opregion opregion;
 <at>  <at>  -1733,6 +1734,7  <at>  <at>  struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
 void i915_gem_context_init(struct drm_device *dev);
 void i915_gem_context_fini(struct drm_device *dev);
 void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
+int i915_gem_update_fbc_rt_base(struct intel_ring_buffer *ring);
 int i915_switch_context(struct intel_ring_buffer *ring,
 			struct drm_file *file, int to_id);
 void i915_gem_context_free(struct kref *ctx_ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 64cb190..cf3ad01 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
 <at>  <at>  -311,6 +311,30  <at>  <at>  i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
 	return (struct i915_hw_context *)idr_find(&file_priv->context_idr, id);
 }

+int
+i915_gem_update_fbc_rt_base(struct intel_ring_buffer *ring)
+{
+	struct drm_device *dev = ring->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	int ret;
+
+	ret = intel_ring_begin(ring, 4);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+	if (INTEL_INFO(dev)->gen >= 7)
+		intel_ring_emit(ring, IVB_FBC_RT_BASE);
+	else
+		intel_ring_emit(ring, ILK_FBC_RT_BASE);
+	intel_ring_emit(ring, dev_priv->cfb_rt_base);
+	intel_ring_emit(ring, MI_NOOP);
+
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
 static inline int
 mi_set_context(struct intel_ring_buffer *ring,
 	       struct i915_hw_context *new_context,
 <at>  <at>  -356,6 +380,12  <at>  <at>  mi_set_context(struct intel_ring_buffer *ring,

 	intel_ring_advance(ring);

+	/*
+	 * FBC_RT_BASE is part of the context,
+	 * so reload it after each context switch.
+	 */
+	i915_gem_update_fbc_rt_base(ring);
+
 	return ret;
 }

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e198f38..9a8a381 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
 <at>  <at>  -217,7 +217,8  <at>  <at>  static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
 		   (stall_watermark << DPFC_RECOMP_STALL_WM_SHIFT) |
 		   (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT));
 	I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc->y);
-	I915_WRITE(ILK_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
+	dev_priv->cfb_rt_base = obj->gtt_offset | ILK_FBC_RT_VALID;
+	I915_WRITE(ILK_FBC_RT_BASE, dev_priv->cfb_rt_base);
 	/* enable it... */
 	I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);

 <at>  <at>  -226,6 +227,13  <at>  <at>  static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
 			   SNB_CPU_FENCE_ENABLE | obj->fence_reg);
 		I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
 		sandybridge_blit_fbc_update(dev);
+
+		/*
+		 * There may be FBC_RT_BASE LRI in the ring with
+		 * a stale value. Put in another one to make things
+		 * right.
+		 */
+		i915_gem_update_fbc_rt_base(&dev_priv->ring[RCS]);
 	}

 	DRM_DEBUG_KMS("enabled fbc on plane %c\n", plane_name(intel_crtc->plane));
 <at>  <at>  -254,6 +262,8  <at>  <at>  static void ironlake_disable_fbc(struct drm_device *dev)
 				   I915_READ(HSW_CLKGATE_DISABLE_PART_1) &
 				   ~HSW_DPFC_GATING_DISABLE);

+		dev_priv->cfb_rt_base = 0;
+
 		DRM_DEBUG_KMS("disabled FBC\n");
 	}
 }
 <at>  <at>  -274,7 +284,8  <at>  <at>  static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
 	struct drm_i915_gem_object *obj = intel_fb->obj;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);

-	I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
+	dev_priv->cfb_rt_base = obj->gtt_offset | ILK_FBC_RT_VALID;
+	I915_WRITE(IVB_FBC_RT_BASE, dev_priv->cfb_rt_base);

 	I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
 		   IVB_DPFC_CTL_FENCE_EN |
 <at>  <at>  -303,6 +314,13  <at>  <at>  static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned long interval)

 	sandybridge_blit_fbc_update(dev);

+	/*
+	 * There may be FBC_RT_BASE LRI in the ring with
+	 * a stale value. Put in another one to make things
+	 * right.
+	 */
+	i915_gem_update_fbc_rt_base(&dev_priv->ring[RCS]);
+
 	DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
 }

--

-- 
1.8.1.5

_______________________________________________
Intel-gfx mailing list
Intel-gfx <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Chris Wilson | 23 May 2013 14:57
Picon

[PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op

If none of the CRTC parameters change along with the framebuffer, we can
forgo rewriting the register and waiting for a vblank. There are a few
calls made by the display managers as they start up which tend to end up
performing no-ops on the current CRTC settings.

Signed-off-by: Chris Wilson <chris <at> chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_display.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 981549c..f4450f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
 <at>  <at>  -2286,6 +2286,11  <at>  <at>  intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
 		return -EINVAL;
 	}

+	if (fb == crtc->fb && crtc->x == x && crtc->y == y) {
+		DRM_DEBUG_KMS("skipping reset of current fb");
+		return 0;
+	}
+
 	mutex_lock(&dev->struct_mutex);
 	ret = intel_pin_and_fence_fb_obj(dev,
 					 to_intel_framebuffer(fb)->obj,
--

-- 
1.7.10.4
Daniel Vetter | 23 May 2013 14:03
Picon
Gravatar

[PULL] drm-intel-fixes

Hi Dave,

A few fixes, nothing shocking:
- More Haswell pci ids. Includes a pile of marketing spare ids (which
  despite the spare moniker show up all over the place).
- Fix a regression in handling modeset failures, resulting in black
  screens on 3 pipe setups when we've run out of pch plls (Chris).
- Fix up the setcrtc semantics to unconditionally enable the outputs.
  Juding from git digging that has (kinda) always been the case and neatly
  fixes a few long-standing (i.e. forever) bug reports (Imre).
- jiffies_timeout + 1 patches from Imre. They partially fix spurious
  wait_event failures in the interrupt-driven dp aux/i2c code. The other
  part is a core patch for the wait_event macros going in through -mm. A
  few patches more than strictly required since Imre is pushing for a
  general solution in 3.11.

Cheers, Daniel

The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:

  Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b:

  drm/i915: avoid premature DP AUX timeouts (2013-05-22 13:51:26 +0200)

----------------------------------------------------------------
Chris Wilson (1):
      drm/i915: Propagate errors back from fb set-base

Imre Deak (5):
      drm/i915: force full modeset if the connector is in DPMS OFF mode
      drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
      drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
      drm/i915: avoid premature timeouts in __wait_seqno()
      drm/i915: avoid premature DP AUX timeouts

Rodrigo Vivi (1):
      drm/i915: Adding more reserved PCI IDs for Haswell.

 drivers/gpu/drm/i915/i915_drv.c      |   46 +++++++++++++++++++++++--------
 drivers/gpu/drm/i915/i915_drv.h      |   15 +++++++++++
 drivers/gpu/drm/i915/i915_gem.c      |    2 +-
 drivers/gpu/drm/i915/intel_display.c |   49 ++++++++++++++++++++++------------
 drivers/gpu/drm/i915/intel_dp.c      |    2 +-
 drivers/gpu/drm/i915/intel_i2c.c     |    5 ++--
 6 files changed, 87 insertions(+), 32 deletions(-)
--

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Rodrigo Vivi | 22 May 2013 19:23
Picon
Gravatar

[PATCH] drm/i915: WA: FBC Render Nuke.

According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC.
Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that
follows each render submission."

v2: Chris noticed that flush_domains check was missing here and also suggested to do
    LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the
    module parameter check.

Cc: Chris Wilson <chris <at> chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi <at> gmail.com>
---
 drivers/gpu/drm/i915/i915_reg.h         |  2 ++
 drivers/gpu/drm/i915/intel_pm.c         |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc4c223..81ac584 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
 <at>  <at>  -977,6 +977,8  <at>  <at> 
 /* Framebuffer compression for Ivybridge */
 #define IVB_FBC_RT_BASE			0x7020

+#define MSG_FBC_REND_STATE	0x50380
+#define   FBC_REND_NUKE		(1<<2)

 #define _HSW_PIPE_SLICE_CHICKEN_1_A	0x420B0
 #define _HSW_PIPE_SLICE_CHICKEN_1_B	0x420B4
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1879188..e830a9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
 <at>  <at>  -274,7 +274,7  <at>  <at>  static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
 	struct drm_i915_gem_object *obj = intel_fb->obj;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);

-	I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
+	I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset);

 	if (!intel_edp_is_psr_enabled(dev))
 		I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3d2c236..905d372 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 <at>  <at>  -280,6 +280,30  <at>  <at>  gen7_render_ring_cs_stall_wa(struct intel_ring_buffer *ring)
 	return 0;
 }

+static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring)
+{
+	struct drm_device *dev = ring->dev;
+	int ret;
+
+	if (i915_enable_fbc == 0)
+		return 0;
+
+	if (i915_enable_fbc < 0 && !IS_HASWELL(dev))
+		return 0;
+
+	ret = intel_ring_begin(ring, 4);
+	if (ret)
+		return ret;
+
+	intel_ring_emit(ring, MI_NOOP);
+	intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+	intel_ring_emit(ring, MSG_FBC_REND_STATE);
+	intel_ring_emit(ring, FBC_REND_NUKE);
+	intel_ring_advance(ring);
+
+	return 0;
+}
+
 static int
 gen7_render_ring_flush(struct intel_ring_buffer *ring,
 		       u32 invalidate_domains, u32 flush_domains)
 <at>  <at>  -336,6 +360,9  <at>  <at>  gen7_render_ring_flush(struct intel_ring_buffer *ring,
 	intel_ring_emit(ring, 0);
 	intel_ring_advance(ring);

+	if (flush_domains)
+		return gen7_ring_fbc_flush(ring);
+
 	return 0;
 }

 <at>  <at>  -1623,6 +1650,7  <at>  <at>  gen6_ring_dispatch_execbuffer(struct intel_ring_buffer *ring,
 static int blt_ring_flush(struct intel_ring_buffer *ring,
 			  u32 invalidate, u32 flush)
 {
+	struct drm_device *dev = ring->dev;
 	uint32_t cmd;
 	int ret;

 <at>  <at>  -1645,6 +1673,10  <at>  <at>  static int blt_ring_flush(struct intel_ring_buffer *ring,
 	intel_ring_emit(ring, 0);
 	intel_ring_emit(ring, MI_NOOP);
 	intel_ring_advance(ring);
+
+	if (IS_GEN7(dev))
+		return gen7_ring_fbc_flush(ring);
+
 	return 0;
 }

--

-- 
1.8.1.4

Gmane