Re: [Intel-gfx] [PATCH] [v3] drm/i915/bdw: Always issue a force restore

On Wed, May 28, 2014 at 10:54:21PM -0700, Ben Widawsky wrote: > On Wed, May 28, 2014 at 04:06:58PM -0700, Ben Widawsky wrote: > > The PDPs seem to get screwed up otherwise, specifically PDP0. I am not > > really clear why this is required, it just works with full PPGTT. > > > > v2: Only do it for

Re: [Intel-gfx] [PATCH] [v3] drm/i915/bdw: Always issue a force restore

On Wed, May 28, 2014 at 04:06:58PM -0700, Ben Widawsky wrote: > The PDPs seem to get screwed up otherwise, specifically PDP0. I am not > really clear why this is required, it just works with full PPGTT. > > v2: Only do it for gen8, to limit regression potential > > v3: Fix the bugzilla links I s

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

On 28.05.2014 20:19, Ville Syrjälä wrote: > On Wed, May 28, 2014 at 06:12:54PM +0900, Michel Dänzer wrote: >> >> Digging out an ooold post of Daniel's... >> >> On 04.03.2014 18:13, Daniel Vetter wrote: >>> On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote: When the pre/post-mo

Re: [Intel-gfx] [PATCH] drm/i915: Support pf CRC source on haswell transcoder edp

On Thu, May 29, 2014 at 12:27:55AM +0200, Daniel Vetter wrote: > - if (IS_HASWELL(dev) && > intel_crtc->config.pch_pfit.enabled) > + if (IS_HASWELL(dev) && > intel_crtc->config.pch_pfit.enabled || > + intel_crtc->config.pch_pfit.forc

[Intel-gfx] [PATCH] [v3] drm/i915/bdw: Always issue a force restore

The PDPs seem to get screwed up otherwise, specifically PDP0. I am not really clear why this is required, it just works with full PPGTT. v2: Only do it for gen8, to limit regression potential v3: Fix the bugzilla links Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891 Bugzilla: https:

[Intel-gfx] [PATCH] [v2] drm/i915/bdw: Always issue a force restore

The PDPs seem to get screwed up otherwise, specifically PDP0. I am not really clear why this is required, it just works with full PPGTT. v2: Only do it for gen8, to limit regression potential Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891 Bugzilla: https://bugs.freedesktop.org/show_

[Intel-gfx] [PATCH] drm/i915/bdw: Always issue a force restore

The PDPs seem to get screwed up otherwise, specifically PDP0. I am not really clear why this is required, it just works with full PPGTT. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78934 Bugzilla: https://bugs.freedesktop.org/

[Intel-gfx] [PATCH] drm/i915: Support pf CRC source on haswell transcoder edp

The always-on power well pixel path on haswell is routed such that it bypasses the panel fitter when we use is. Which means the pfit CRC source won't work in that configuration. Add a new disallow-bypass flags to the pfit pipe config state and set it when we want to use the pf CRC. Results in a bi

[Intel-gfx] [PATCH] drm/i915/vlv: enable PPGTT

Need testing and possibly disabling on earlier steppings, but looks ok here on my B3. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index ec5f6f

Re: [Intel-gfx] [PATCH] drm/i915: Only check PPGTT bits when using PPGTT

On Wed, May 28, 2014 at 02:45:26PM -0700, Volkin, Bradley D wrote: > On Wed, May 28, 2014 at 02:29:34PM -0700, Daniel Vetter wrote: > > Jesse reportedly has a patch somewhere to (finally!) enable ppgtt on > > vlv. Would we still need any part of this with ppgtt support on vlv? > > -Daniel > > Of c

Re: [Intel-gfx] [PATCH] drm/i915: make fbdev initialization asynchronous v2

On Wed, 28 May 2014 23:40:47 +0200 Daniel Vetter wrote: > On Wed, May 28, 2014 at 02:39:03PM -0700, Jesse Barnes wrote: > > This gets us out of our init code and out to userspace quite a bit > > faster, but does open us up to some bugs given the state of our init > > time locking. > > > > v2: sw

Re: [Intel-gfx] [PATCH] drm/i915: Only check PPGTT bits when using PPGTT

On Wed, May 28, 2014 at 02:29:34PM -0700, Daniel Vetter wrote: > Jesse reportedly has a patch somewhere to (finally!) enable ppgtt on > vlv. Would we still need any part of this with ppgtt support on vlv? > -Daniel Of course, as soon as I accept that it'll never happen... :) Off the top of my hea

Re: [Intel-gfx] [PATCH] drm/i915: make fbdev initialization asynchronous v2

On Wed, May 28, 2014 at 02:39:03PM -0700, Jesse Barnes wrote: > This gets us out of our init code and out to userspace quite a bit > faster, but does open us up to some bugs given the state of our init > time locking. > > v2: switch to async_schedule (Chris) > check with lockdep, seems happy (

[Intel-gfx] [PATCH] drm/i915: make fbdev initialization asynchronous v2

This gets us out of our init code and out to userspace quite a bit faster, but does open us up to some bugs given the state of our init time locking. v2: switch to async_schedule (Chris) check with lockdep, seems happy (Jesse) move hotplug enable flag set to fbdev_initial_config (Jesse) S

Re: [Intel-gfx] [PATCH] drm/i915: Only check PPGTT bits when using PPGTT

Jesse reportedly has a patch somewhere to (finally!) enable ppgtt on vlv. Would we still need any part of this with ppgtt support on vlv? -Daniel On Wed, May 28, 2014 at 10:47 PM, wrote: > From: Brad Volkin > > This extends use of the command parser to VLV. > > Note that the patch checks that t

[Intel-gfx] [PATCH] drm/i915: Only check PPGTT bits when using PPGTT

From: Brad Volkin This extends use of the command parser to VLV. Note that the patch checks that the PPGTT bit is set appropriately when PPGTT is enabled but ignores it when PPGTT is disabled. It would be awkward to correctly invert the expected value to check that the bit is set appropriately i

Re: [Intel-gfx] [PATCH 4/6] kms_pipe_crc_basic: Bump the number of collected CRCs to 60

On Wed, May 28, 2014 at 07:24:02PM +0100, Damien Lespiau wrote: > So we have a change to see something on the screen, while still being > relatively short (~1s per sub-test). > > Signed-off-by: Damien Lespiau igt_wait_for_keypress is geared at such use-cases ... Maybe we should have a default ti

Re: [Intel-gfx] [PATCH 6/6] lib: Add a --igt-debug command line option

On Wed, May 28, 2014 at 07:24:04PM +0100, Damien Lespiau wrote: > Sometimes it's practical to be able to set the logging level to debug > from the command line arguments. > > Signed-off-by: Damien Lespiau The problem with this is that it won't work with simple igt tests which don't use this for

Re: [Intel-gfx] [PATCH] drm/i915: Don't WARN about ring idle bit on gen2

On Wed, May 28, 2014 at 05:15:13PM +0100, Chris Wilson wrote: > On Wed, May 28, 2014 at 07:12:13PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register, > > so don't go spewing warnings about the state o

[Intel-gfx] [PATCH 2/6] kms_pipe_crc_basic: Cycle between 2 differently colored buffer

Instead of just testing if the CRCs are stable, we also test 2 different fbs to make sure that the CRC is actually changing. Signed-off-by: Damien Lespiau --- tests/kms_pipe_crc_basic.c | 95 +- 1 file changed, 61 insertions(+), 34 deletions(-) diff -

[Intel-gfx] [PATCH 1/6] kms_pipe_crc_basic: Split the main test function a bit more

Let's put the per-output test in its own function to get rid of 1 level of indentation. We'll need it to cycle through 2 different framebuffers to make sure we compute different CRCs if the fbs are different. Signed-off-by: Damien Lespiau --- tests/kms_pipe_crc_basic.c | 101

[Intel-gfx] [PATCH 4/6] kms_pipe_crc_basic: Bump the number of collected CRCs to 60

So we have a change to see something on the screen, while still being relatively short (~1s per sub-test). Signed-off-by: Damien Lespiau --- tests/kms_pipe_crc_basic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c inde

[Intel-gfx] [PATCH 3/6] kms_pipe_crc_basic: Make the number of CRCs a parameter

Let's make the test a bit more generic and have the number of CRCs we're collecting a define so it can be changed easily. Signed-off-by: Damien Lespiau --- tests/kms_pipe_crc_basic.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tests/kms_pipe_crc_b

[Intel-gfx] [PATCH 6/6] lib: Add a --igt-debug command line option

Sometimes it's practical to be able to set the logging level to debug from the command line arguments. Signed-off-by: Damien Lespiau --- lib/igt_core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/igt_core.c b/lib/igt_core.c index 6e553cf..9d59ab4 100644 --- a/lib/igt_core.c +++

[Intel-gfx] [PATCH i-g-t 0/6] Make kms_pipe_crc_basic cover pipe A + eDP on HSW

We currenly have a bug on HSW where asking for the panel fitter CRC when the power well is down returns 0x, but kms_pipe_crc_basic passes as it only tests that the CRCs obtained for a FB are consistent over time. We consistently read 0x, so the test was passing. With this series we

[Intel-gfx] [PATCH 5/6] kms_pipe_crc_basic: Add a bit a debugging output

Signed-off-by: Damien Lespiau --- tests/kms_pipe_crc_basic.c | 9 + 1 file changed, 9 insertions(+) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index c4abdf7..5727b61 100644 --- a/tests/kms_pipe_crc_basic.c +++ b/tests/kms_pipe_crc_basic.c @@ -127,8 +127,13 @@ te

Re: [Intel-gfx] [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status

On Wed, 28 May 2014 21:09:27 +0300 Imre Deak wrote: > On Wed, 2014-05-28 at 09:50 -0700, Jesse Barnes wrote: > > This saves many ms per call on my BYT by eliminating Punit communication > > from the hw readout paths. > > > > Signed-off-by: Jesse Barnes > > --- > > drivers/gpu/drm/i915/intel_pm

Re: [Intel-gfx] [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status

On Wed, 2014-05-28 at 09:50 -0700, Jesse Barnes wrote: > This saves many ms per call on my BYT by eliminating Punit communication > from the hw readout paths. > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/intel_pm.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) >

[Intel-gfx] [PATCH 2/2] drm/i915: rename is_enabled to hw_state

Mainly useful for catching all the callers in the previous patch. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- drivers/gpu/drm/i915/intel_pm.c | 22 +++--- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv

[Intel-gfx] [PATCH 1/2] drm/i915: use power well count instead of reading hw state when checking status

This saves many ms per call on my BYT by eliminating Punit communication from the hw readout paths. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_pm.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/i

Re: [Intel-gfx] [PATCH] drm/i915: Don't WARN about ring idle bit on gen2

On Wed, May 28, 2014 at 07:12:13PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register, > so don't go spewing warnings about the state of those bits. > > Signed-off-by: Ville Syrjälä My mistake, forgot abo

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Check for a NULL shared dpll before dereferencing

On Wed, May 28, 2014 at 04:16:42PM +0100, Chris Wilson wrote: > This doesn't look possible but a little extra defense against the > improbable is worth it - an oops here could lockup the machine. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_display.c |3 +++ > 1 file ch

[Intel-gfx] [PATCH] drm/i915: Don't WARN about ring idle bit on gen2

From: Ville Syrjälä Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register, so don't go spewing warnings about the state of those bits. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

[Intel-gfx] 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0a)

Hello there, I am not very good in linux stuff but, i would like to know if is there any possibility to get this device work. here is a result of lspci: 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0a) Or it is even planned? Thanks -- ANDRIAMILAMINA Monge sYSaDM

[Intel-gfx] [PATCH 1/2] drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent object

If the user tries to mmap through the GTT an object that is marked as snooped, we report an error rather than allow the GPU to hang the machine. The choice of EINVAL, however, was unfortunate as we turn that into a WARN rather than a quiet SIGBUS. Signed-off-by: Chris Wilson --- drivers/gpu/drm/

[Intel-gfx] [PATCH 2/2] drm/i915: Check for a NULL shared dpll before dereferencing

This doesn't look possible but a little extra defense against the improbable is worth it - an oops here could lockup the machine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b

[Intel-gfx] [PATCH] NEWS: Don't forget the runtime pm helpers!

--- NEWS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS b/NEWS index c07269444e64..05a0c7d6cc2d 100644 --- a/NEWS +++ b/NEWS @@ -25,6 +25,8 @@ Release 1.7 (-XX-XX) - Make swig an optional depency (Damien). +- Helpers for runtime pm tests in igt_aux. + Release 1.6 (2014-03-13)

[Intel-gfx] [PATCH] NEWS: Updates ...

--- NEWS | 8 1 file changed, 8 insertions(+) diff --git a/NEWS b/NEWS index a03f20607dc6..c07269444e64 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,14 @@ Release 1.7 (-XX-XX) - Support for building libcairo based tests on Android. Set ANDROID_HAS_CAIRO=1 in the build enviroment whe

[Intel-gfx] [PATCH i-g-t] build: Don't fail if SWIG isn't found

People from distros have reported that packaging the newer versions is more difficult because we now depend on SWIG. We don't have to, it's needed for the python dumper and is an optional build dependency. Signed-off-by: Damien Lespiau --- configure.ac | 8 +++- 1 file changed, 7 insertions(

Re: [Intel-gfx] [PATCH] drm/i915: Make intel_dsi_init() return void

On Wed, May 28, 2014 at 12:30:56PM +0100, Damien Lespiau wrote: > Functions that can't fail are such a bliss to work with, it'd be shame > to miss the occasion. The "failure" mode is the DSI connector not being > created, the rest of the initialization can carry on happily. > > We weren't even che

Re: [Intel-gfx] [PATCH] drm/i915: Update PSR on resume.

On Tue, May 27, 2014 at 04:50:14PM -0700, Rodrigo Vivi wrote: > Some registers set during setup might not be persistent after suspend/resume. > This was causing bugs for some people that was unable to get PSR entry state > after resume cycle. > > v2: Adding some comments and better commit message

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Gen2/3 C3 wakeup stuff

On Wed, May 28, 2014 at 09:19:05AM +0100, Chris Wilson wrote: > On Tue, Feb 25, 2014 at 03:13:37PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I tried to fix the C3 vs. vblank interrupt issues reportd in [1], but > > it looks like the AGPBUSY# stuff doesn't help th

Re: [Intel-gfx] [PATCH] drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset

On Tue, May 27, 2014 at 09:33:09PM +0300, ville.syrj...@linux.intel.com wrote: > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 94ac51f..cb9dd8e 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@

Re: [Intel-gfx] [PATCH] [RFC] drm: Split connection_mutex out of mode_config.mutex

On Tue, May 27, 2014 at 5:59 PM, Daniel Vetter wrote: > After the split-out of crtc locks from the big mode_config.mutex > there's still two major areas it protects: > - Various connector probe states, like connector->status, EDID > properties, probed mode lists and similar information. > - The

[Intel-gfx] [PATCH] drm/i915: Make intel_dsi_init() return void

Functions that can't fail are such a bliss to work with, it'd be shame to miss the occasion. The "failure" mode is the DSI connector not being created, the rest of the initialization can carry on happily. We weren't even checking that value anyway. Suggested-by: Ville Syrjälä Suggested-by: Shobh

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

On Wed, May 28, 2014 at 06:12:54PM +0900, Michel Dänzer wrote: > > Digging out an ooold post of Daniel's... > > On 04.03.2014 18:13, Daniel Vetter wrote: > > On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote: > >> > >> When the pre/post-modeset hooks were originally added, it worked

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Gen2/3 C3 wakeup stuff

On Wed, May 28, 2014 at 12:46:12PM +0300, Ville Syrjälä wrote: > On Wed, May 28, 2014 at 09:19:05AM +0100, Chris Wilson wrote: > > The slow vblank delivery issue remains iirc though. > > Yeah supposedly that's the case on gen3. This series does fix my 855 > though. Unfortunately I've not come acro

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Default to mmio flips on VLV

On Wed, May 28, 2014 at 12:42:02PM +0530, sourab.gu...@intel.com wrote: > From: Sourab Gupta > > This patch is for using mmio flips by default on VLV. > The module parameter controlling use of MMIO flips allows us to > control the default behaviour, which is set true for VLV and false > elsewhere

Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/vlv: Added a rendering specific Hw WA 'WaSendDummy3dPrimitveAfterSetContext'

On Mon, 2014-04-14 at 09:45 +, Gupta, Sourab wrote: > From: Akash Goel > > This workaround is needed on VLV for the HW context feature. > It is used after adding the mi_set_context command in ring buffer > for Hw context switch. As per the spec > "The software must send a pipe_control with a

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Gen2/3 C3 wakeup stuff

On Wed, May 28, 2014 at 09:19:05AM +0100, Chris Wilson wrote: > On Tue, Feb 25, 2014 at 03:13:37PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > I tried to fix the C3 vs. vblank interrupt issues reportd in [1], but > > it looks like the AGPBUSY# stuff doesn't help th

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replaced Blitter ring based flips with MMIO flips

On Wed, 2014-05-28 at 07:30 +, Chris Wilson wrote: > On Wed, May 28, 2014 at 12:42:01PM +0530, sourab.gu...@intel.com wrote: > > +static int intel_postpone_flip(struct drm_i915_gem_object *obj) > > +{ > > + int ret; > > + > > + if (!obj->ring) > > + return 0; > > + > > + if (i91

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

Digging out an ooold post of Daniel's... On 04.03.2014 18:13, Daniel Vetter wrote: > On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote: >> >> When the pre/post-modeset hooks were originally added, it worked like >> this: the pre-modeset hook enabled the vblank interrupt, which update

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Gen2/3 C3 wakeup stuff

On Tue, Feb 25, 2014 at 03:13:37PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I tried to fix the C3 vs. vblank interrupt issues reportd in [1], but > it looks like the AGPBUSY# stuff doesn't help there for some reason. I > guess either the board isn't wired correctly, o

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replaced Blitter ring based flips with MMIO flips

On Wed, May 28, 2014 at 08:31:52AM +0100, Chris Wilson wrote: > On Wed, May 28, 2014 at 12:42:01PM +0530, sourab.gu...@intel.com wrote: > > +static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > > +{ > > + struct drm_device *dev = intel_crtc->base.dev; > > + struct drm_i915_private *d

Re: [Intel-gfx] [PATCH 1/6] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3

On Tue, May 27, 2014 at 10:24:14PM +0200, Daniel Vetter wrote: > On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote: > > On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote: > > > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > > > that it resets the whole

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replaced Blitter ring based flips with MMIO flips

On Wed, May 28, 2014 at 12:42:01PM +0530, sourab.gu...@intel.com wrote: > +static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > +{ > + struct drm_device *dev = intel_crtc->base.dev; > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct intel_framebuffer *intel_

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replaced Blitter ring based flips with MMIO flips

On Wed, May 28, 2014 at 12:42:01PM +0530, sourab.gu...@intel.com wrote: > +static int intel_postpone_flip(struct drm_i915_gem_object *obj) > +{ > + int ret; > + > + if (!obj->ring) > + return 0; > + > + if (i915_seqno_passed(obj->ring->get_seqno(obj->ring, true), > +

[Intel-gfx] [PATCH 1/2] drm/i915: Replaced Blitter ring based flips with MMIO flips

From: Sourab Gupta Using MMIO based flips on Gen5+. The MMIO flips are useful for the Media power well residency optimization. These maybe enabled on architectures where Render and Blitter engines reside in different power wells. The blitter ring is currently being used just for command streamer

[Intel-gfx] [PATCH 2/2] drm/i915: Default to mmio flips on VLV

From: Sourab Gupta This patch is for using mmio flips by default on VLV. The module parameter controlling use of MMIO flips allows us to control the default behaviour, which is set true for VLV and false elsewhere. Signed-off-by: Sourab Gupta --- drivers/gpu/drm/i915/i915_params.c | 5 +++--

[Intel-gfx] [PATCH v3 0/2] Replace Blitter ring based flips with MMIO flips

From: Sourab Gupta This patch series replaces Blitter ring based flips with MMIO based flips. This is useful for Media power well residency optimization. These may be enabled on architectures where Render and Blitter engines reside in different power wells. The blitter ring is currently being use