[Intel-gfx] [QA 09/19 ww38] Testing report for `drm-intel-testing` (was: Updated -next)

Summary We covered the platform: Broadwell, Baytrail-M, Haswell (mobile, desktop and ULT), Ivybridge, SandyBridge, IronLake. In this circle, 2 new bugs are filed. Bug 84071 - [BYT]System output ERROR, when machine resume from S3 Bug 84031

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Remove check for Old Ack during forcewake

On Thursday 18 September 2014 02:09 PM, Ville Syrjälä wrote: On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote: From: Deepak S Based on the HW team inputs. We can should not wait for the old ack, Waiting for old ack might fail, when other forcewake came before the prese

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Remove check for Old Ack during forcewake

On Thursday 18 September 2014 06:38 PM, Ville Syrjälä wrote: On Thu, Sep 18, 2014 at 01:53:13PM +0200, Daniel Vetter wrote: On Thu, Sep 18, 2014 at 11:39:25AM +0300, Ville Syrjälä wrote: On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote: From: Deepak S Based on the HW

[Intel-gfx] [PATCH 5/8] drm/i915: Add the display switch logic for vgpu in i915 driver

From: Yu Zhang Display switch logic is added to notify the vgt mediator that current vgpu have a valid surface to show. It does so by writing the display_ready field in PV INFO page, and then will be handled in vgt mediator. This is useful to avoid trickiness when the VM's framebuffer is being ac

[Intel-gfx] [PATCH 7/8] drm/i915: Create vgpu specific write MMIO to reduce traps

From: Yu Zhang In the virtualized environment, forcewake operations are not necessory for the driver, because mmio accesses will be trapped and emulated by the host side, and real forcewake operations are also done in the host. New mmio write handlers are added to directly call the __raw_i915_wri

[Intel-gfx] [PATCH 3/8] drm/i915: Partition the fence registers for vgpu in i915 driver

From: Yu Zhang In XenGT, the fence registers are partitioned by multiple vgpu instances in different VMs. Routine i915_gem_load() is modified to reset the num_fence_regs, when the driver detects it's runing in a VM. And the allocated fence numbers is provided in PV INFO page structure. Signed-of

[Intel-gfx] [PATCH 8/8] drm/i915: Support alias ppgtt in VM if ppgtt is enabled

From: Yu Zhang The current XenGT only supports alias ppgtt. And the emulation is done in XenGT host by first trapping PP_DIR_BASE mmio accesses. Updating PP_DIR_BASE by using instructions such as MI_LOAD_REGISTER_IMM are hard to emulate and are not supported in current XenGT. Therefore this patch

[Intel-gfx] [PATCH 2/8] drm/i915: Adds graphic address space ballooning logic

From: Yu Zhang In XenGT, the global graphic memory space is partitioned by multiple vgpu instances in different VMs. The ballooning code is added in i915_gem_setup_global_gtt(), utilizing the drm mm allocator APIs to mark the graphic address space which are partitioned out to other vgpus as reser

[Intel-gfx] [PATCH 6/8] drm/i915: Disable power management for i915 driver in VM

From: Yu Zhang In XenGT, GPU power management is controlled by host i915 driver, so there is no need to provide virtualized GPU PM support. In the future it might be useful to gather VM input for freq boost, but now let's disable it simply. Signed-off-by: Yu Zhang Signed-off-by: Jike Song ---

[Intel-gfx] [PATCH 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g.

From: Yu Zhang Introduce a PV INFO structure, to facilitate the Intel GVT-g technology, which is a GPU virtualization solution with mediated pass-through(previously known as XenGT). This page contains the shared information between i915 driver and the mediator. For now, this structure utilizes an

[Intel-gfx] [PATCH 4/8] drm/i915: Disable framebuffer compression for i915 driver in VM

From: Yu Zhang Framebuffer compression is disabled when driver detects it's running in XenGT VM, because XenGT does not provide emulations for FBC related operations, and we do not expose stolen memory to the VM. Signed-off-by: Yu Zhang Signed-off-by: Jike Song Signed-off-by: Zhiyuan Lv ---

[Intel-gfx] [PATCH 0/8] Add enlightenments for vGPU

Intel GVT-g (previously known as XenGT), is a complete GPU virtualization solution with mediated pass-through for 4th generation Intel Core processors - Haswell platform. This technology presents a virtual full-fledged GPU to each Virtual Machine (VM). VMs can directly access performance-critical r

[Intel-gfx] [PATCH 1/2] drm/i915: Re-enable the command parser when using PPGTT

From: Brad Volkin In commit commit 896ab1a5d54269b463a24194c2e4a369103b46d8 Author: Daniel Vetter Date: Wed Aug 6 15:04:51 2014 +0200 drm/i915: Fix up checks for aliasing ppgtt it looks like we accidentally inverted the check that the command parser should only run when the driver enabl

[Intel-gfx] [PATCH 2/2] drm/i915: Log a message when rejecting LRM to OACONTROL

From: Brad Volkin The other paths in the command parser that reject a batch all log a message indicating the reason. We simply missed this one. Signed-off-by: Brad Volkin --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/g

Re: [Intel-gfx] [PATCH] drm/i915: Avoid reading fbc registers in vain when fbc was never enabled.

2014-09-18 15:42 GMT-03:00 Rodrigo Vivi : > > > On Thu, Sep 18, 2014 at 4:39 AM, Daniel Vetter wrote: >> >> On Thu, Sep 18, 2014 at 07:28:48AM +0100, Chris Wilson wrote: >> > On Wed, Sep 17, 2014 at 04:59:20PM -0400, Rodrigo Vivi wrote: >> > > If it wasn't never enabled by kernel parameter or plat

[Intel-gfx] [PATCH] drm/i915: Minimize the huge amount of unecessary fbc sw cache clean.

The sw cache clean on BDW is a tempoorary workaround because we cannot set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw. However we are doing much more than needed. Not only when using blt ring. So, with this extra w/a we minimize the ammount of cache cleans an

[Intel-gfx] [PATCH 5/5] drm/i915: remove intel_pipe_set_base()

From: Gustavo Padovan After some refactor intel_primary_plane_setplane() does the same as intel_pipe_set_base() so we can get rid of it and replace the calls with intel_primary_plane_setplane(). Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 79 --

[Intel-gfx] [PATCH 2/5] drm/i915: move checks of intel_crtc_cursor_set_obj() out

From: Gustavo Padovan Move checks inside intel_crtc_cursor_set_obj() to intel_check_cursor_plane(), we only use they there so move them out to make the merge of intel_crtc_cursor_set_obj() into intel_check_cursor_plane() easier. This is another step toward the atomic modesetting support and unif

[Intel-gfx] [PATCH 1/5] drm/i915: Merge of visible and !visible paths for primary planes

From: Gustavo Padovan Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved to the check() stage) v2: take Vi

[Intel-gfx] [PATCH 4/5] drm/i915: split intel_crtc_page_flip() into check() and commit()

From: Daniel Stone Start the work of splitting the intel_crtc_page_flip() for later use by the atomic modesetting API. Signed-off-by: Daniel Stone Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 51 ++-- 1 file changed, 37 insertions(+

[Intel-gfx] [PATCH 3/5] drm/i915: remove intel_crtc_cursor_set_obj()

From: Gustavo Padovan Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane() and merge both

Re: [Intel-gfx] turn off lowmemorykiller when running IGT on Android?

On Thu, Sep 18, 2014 at 5:42 PM, Gore, Tim wrote: > Hi All. >After some pain trying to resolve an IGT test getting killed by the Android > Lowmemorykiller, it seems to me that in the context of the IGT tests we > just don't need (or want) the android low memory killer. The Linux memory > mana

Re: [Intel-gfx] [PATCH] drm/i915: Avoid reading fbc registers in vain when fbc was never enabled.

On Thu, Sep 18, 2014 at 4:39 AM, Daniel Vetter wrote: > On Thu, Sep 18, 2014 at 07:28:48AM +0100, Chris Wilson wrote: > > On Wed, Sep 17, 2014 at 04:59:20PM -0400, Rodrigo Vivi wrote: > > > If it wasn't never enabled by kernel parameter or platform default > > > we can avoid reading registers so

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

On Thu, Sep 18, 2014 at 06:54:15PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Thu, Sep 18, 2014 at 05:58:32PM +0300, Mika Kuoppala wrote: > >> Render context on gen8 is not guaranteed to be loaded (active) > >> at the instant when forcewake ack shows up. So we need extra > >> ste

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

On Thu, Sep 18, 2014 at 06:54:15PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Thu, Sep 18, 2014 at 05:58:32PM +0300, Mika Kuoppala wrote: > >> Render context on gen8 is not guaranteed to be loaded (active) > >> at the instant when forcewake ack shows up. So we need extra > >> ste

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

Chris Wilson writes: > On Thu, Sep 18, 2014 at 05:58:32PM +0300, Mika Kuoppala wrote: >> Render context on gen8 is not guaranteed to be loaded (active) >> at the instant when forcewake ack shows up. So we need extra >> steps to get it in before we access specific registers. >> >> We could do reg

[Intel-gfx] turn off lowmemorykiller when running IGT on Android?

Hi All. After some pain trying to resolve an IGT test getting killed by the Android Lowmemorykiller, it seems to me that in the context of the IGT tests we just don't need (or want) the android low memory killer. The Linux memory management and oom functions are perfectly adequate. Rob Becket k

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Reinitialize default context after reset

On Thu, Sep 18, 2014 at 05:58:30PM +0300, Mika Kuoppala wrote: > We don't know in what shape the default context was before reset. > The reset also dropped our changes that were done in > ring->init_context. > > Mark our default context as uninitialized for it to be properly > setup up on reset re

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

On Thu, Sep 18, 2014 at 05:58:32PM +0300, Mika Kuoppala wrote: > Render context on gen8 is not guaranteed to be loaded (active) > at the instant when forcewake ack shows up. So we need extra > steps to get it in before we access specific registers. > > We could do register white listing to do the

[Intel-gfx] [PATCH] tests/gem_workarounds: adapt to constant wa list from driver

Read and verify workaround list before and after the reset/resume. Signed-off-by: Mika Kuoppala --- tests/gem_workarounds.c | 123 +--- 1 file changed, 64 insertions(+), 59 deletions(-) diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c in

[Intel-gfx] [PATCH 2/6] drm/i915: Reinitialize default context after resume

We have lost our ring and default context state on suspend, including workarounds. Setup default context state like we do in module load. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers

[Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

Render context on gen8 is not guaranteed to be loaded (active) at the instant when forcewake ack shows up. So we need extra steps to get it in before we access specific registers. We could do register white listing to do the extra dance only on specific render context access. However the main conc

[Intel-gfx] [PATCH 1/6] drm/i915: Reinitialize default context after reset

We don't know in what shape the default context was before reset. The reset also dropped our changes that were done in ring->init_context. Mark our default context as uninitialized for it to be properly setup up on reset recovery . Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debu

[Intel-gfx] [PATCH 4/6] drm/i915: Build workaround list in ring initialization

to disassociate workaround list init from the actual writing of values. This is needed as not workarounds will be masked bit enables and we want full control on when the read part of RMW will happen. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 18 +-- drivers/gpu/

[Intel-gfx] [PATCH 5/6] drm/i915: Add ivb workarounds into the wa list.

So that we write them at ring initialization and thus have them applied correctly after reset/resume. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 61 +-- drivers/gpu/drm/i915/intel_ringbuffer.c | 10

[Intel-gfx] [PATCH 0/6] RFC: Persistent workarounds across reset/resume

Hi, The current reality is that after gpu hang or after first suspend/resume cycle, we have lost all our workarounds. It is somewhat troubling to think that what ghosts we have been hunting and what effort we have wasted on the testruns that have had unrelated single hang at some point of the 10k

[Intel-gfx] [PATCH 6/6] drm/i915: Check workaround status on dfs read time

As the workaround list has the value as initialization time constant, we can do the simple checking on the go. For the user that doesn't have igt at hand and still server the igt's needs. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 14 +++--- 1 file changed, 7

Re: [Intel-gfx] [PATCH 69/89] drm/i915/skl: Adding power domains for AUX controllers

On Thu, Sep 18, 2014 at 05:23:14PM +0300, Imre Deak wrote: > On Thu, 2014-09-18 at 14:56 +0100, Damien Lespiau wrote: > > > > #define VLV_DPIO_TX_B_LANES_01_POWER_DOMAINS ( \ > > > > BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) | \ > > > > BIT(POWER_DOMAIN_PORT_DDI_B_4_LANES) | \ > > >

Re: [Intel-gfx] [PATCH 69/89] drm/i915/skl: Adding power domains for AUX controllers

On Thu, 2014-09-18 at 14:56 +0100, Damien Lespiau wrote: > Hi Imre, > > I actually had some question there as well: > > On Tue, Sep 16, 2014 at 03:35:15PM +0300, Imre Deak wrote: > > > @@ -7685,24 +7689,32 @@ EXPORT_SYMBOL_GPL(i915_get_cdclk_freq); > > > BIT(POWER_DOMAIN_PORT_DDI_C_2_LANES) |

Re: [Intel-gfx] [PATCH 69/89] drm/i915/skl: Adding power domains for AUX controllers

Hi Imre, I actually had some question there as well: On Tue, Sep 16, 2014 at 03:35:15PM +0300, Imre Deak wrote: > > @@ -7685,24 +7689,32 @@ EXPORT_SYMBOL_GPL(i915_get_cdclk_freq); > > BIT(POWER_DOMAIN_PORT_DDI_C_2_LANES) | \ > > BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) | \ > > BIT(POWER

Re: [Intel-gfx] [RFC PATCH] drm/i915: add new intel audio file to group DP/HDMI audio

On Thu, Sep 18, 2014 at 3:37 PM, Jani Nikula wrote: > On Thu, 18 Sep 2014, Daniel Vetter wrote: >> lgtm, but I think to make code extraction into new files really worth >> it this should be followed up with a small patch to add an overview >> DOC section and kerneldoc for the non-static functions

Re: [Intel-gfx] [RFC PATCH] drm/i915: add new intel audio file to group DP/HDMI audio

On Thu, 18 Sep 2014, Daniel Vetter wrote: > lgtm, but I think to make code extraction into new files really worth > it this should be followed up with a small patch to add an overview > DOC section and kerneldoc for the non-static functions. Plus pulling > it all in at a neat place into our driver

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Remove check for Old Ack during forcewake

On Thu, Sep 18, 2014 at 01:53:13PM +0200, Daniel Vetter wrote: > On Thu, Sep 18, 2014 at 11:39:25AM +0300, Ville Syrjälä wrote: > > On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote: > > > From: Deepak S > > > > > > Based on the HW team inputs. We can should not wait for th

Re: [Intel-gfx] [RFC PATCH] drm/i915: add new intel audio file to group DP/HDMI audio

lgtm, but I think to make code extraction into new files really worth it this should be followed up with a small patch to add an overview DOC section and kerneldoc for the non-static functions. Plus pulling it all in at a neat place into our driver docs. -Daniel On Wed, Sep 17, 2014 at 7:26 PM, Ja

Re: [Intel-gfx] [PATCH] intel: Adding locks for drm objects synchronization.

On Tue, Aug 05, 2014 at 02:51:38PM -0400, Rafal Sapala wrote: > The changes make sure that members of the bufmgr_gem and bo_gem > name lists are sychronized between threads > when using the create from prime and create from name methods. > > Signed-off-by: Rafal Sapala > --- > intel/intel_bufmgr

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, a couple of small display fixes for 3.17. There was another bdw ips fix that I'd already pushed, but I had to drop it just now as it regressed. We'll need to come back to that later, details at https://bugs.freedesktop.org/show_bug.cgi?id=83497. BR, Jani. The following changes since c

Re: [Intel-gfx] YABT - pipe_off wait timed out

On Wed, Sep 17, 2014 at 01:38:21PM +1000, Dave Airlie wrote: > [1.396361] [ cut here ] > [1.396396] WARNING: CPU: 2 PID: 108 at > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:997 > intel_disable_pipe+0x2ae/0x2c0 [i915]() > [1.396397] p

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't enable IPS when pixel rate exceeds 95% of cdclk

On Wed, 17 Sep 2014, Ville Syrjälä wrote: > On Wed, Sep 17, 2014 at 11:10:48AM -0300, Paulo Zanoni wrote: >> 2014-09-17 11:05 GMT-03:00 Paulo Zanoni : >> > 2014-09-15 4:22 GMT-03:00 Jani Nikula : >> >> On Fri, 12 Sep 2014, Ville Syrjälä wrote: >> >>> On Fri, Sep 12, 2014 at 04:42:33PM +0100, Chri

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Remove check for Old Ack during forcewake

On Thu, Sep 18, 2014 at 11:39:25AM +0300, Ville Syrjälä wrote: > On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote: > > From: Deepak S > > > > Based on the HW team inputs. We can should not wait for the old ack, > > Waiting for old ack might fail, when other forcewake came

Re: [Intel-gfx] [PATCH] drm/i915: Flush the PTEs after updating them before suspend

On Thu, Sep 18, 2014 at 07:03:32AM +0100, Chris Wilson wrote: > As we use WC updates of the PTE, we are responsible for notifying the > hardware when to flush its TLBs. Do so after we zap all the PTEs before > suspend (and the BIOS tries to read our GTT). > > Bugzilla: https://bugs.freedesktop.org

Re: [Intel-gfx] External monitor issues with 3.17-rc4 and i915 module

On Thu, 18 Sep 2014, "Carlos R. Mafra" wrote: > On Wed, 17 Sep 2014 at 11:39:57 +0300, Jani Nikula wrote: >> On Tue, 16 Sep 2014, "Carlos R. Mafra" wrote: >> > Hi, the same happens with 3.17-rc5. The kernel is unfortunately >> > unusable with my external monitor because after some plug, unplug >>

Re: [Intel-gfx] [PATCH] drm/i915: Avoid reading fbc registers in vain when fbc was never enabled.

On Thu, Sep 18, 2014 at 07:28:48AM +0100, Chris Wilson wrote: > On Wed, Sep 17, 2014 at 04:59:20PM -0400, Rodrigo Vivi wrote: > > If it wasn't never enabled by kernel parameter or platform default > > we can avoid reading registers so many times in vain > > Nak. Well I've merged this for now to r

Re: [Intel-gfx] External monitor issues with 3.17-rc4 and i915 module

On Wed, 17 Sep 2014 at 11:39:57 +0300, Jani Nikula wrote: > On Tue, 16 Sep 2014, "Carlos R. Mafra" wrote: > > Hi, the same happens with 3.17-rc5. The kernel is unfortunately > > unusable with my external monitor because after some plug, unplug > > and suspend to RAM cycles the behaviour is not goo

Re: [Intel-gfx] [PATCH] lib/core: Check for kernel error messages and FAIL if any are found

Oh, just noticed that I've added the wrong Thomas ;-) -Daniel On Thu, Sep 18, 2014 at 10:34 AM, Daniel, Thomas wrote: >> -Original Message- >> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of >> Daniel Vetter >> Sent: Wednesday, September 17, 2014 5:14 PM >> To: C

Re: [Intel-gfx] [PATCH] lib/core: Check for kernel error messages and FAIL if any are found

On Thu, Sep 18, 2014 at 10:34 AM, Daniel, Thomas wrote: >> -Original Message- >> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of >> Daniel Vetter >> Sent: Wednesday, September 17, 2014 5:14 PM >> To: Chris Wilson; Daniel Vetter; intel-gfx; Daniel, Thomas >> Subjec

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Remove check for Old Ack during forcewake

On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote: > From: Deepak S > > Based on the HW team inputs. We can should not wait for the old ack, > Waiting for old ack might fail, when other forcewake came before the > present one is desserted. > > for example, if forcewake bit

Re: [Intel-gfx] [PATCH] lib/core: Check for kernel error messages and FAIL if any are found

> -Original Message- > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Wednesday, September 17, 2014 5:14 PM > To: Chris Wilson; Daniel Vetter; intel-gfx; Daniel, Thomas > Subject: Re: [Intel-gfx] [PATCH] lib/core: Check for kernel error mes

[Intel-gfx] [PATCH] drm/i915: Make hangcheck logging more compact

When we detect a GPU hang, we emit a loud bang with the reason. But in the process, we also log each ring that hangs and then lose that information in the reason. Combine the two so that an accurate reason why we triggered the GPU hang is logged in the error state and so that we no longer need to e

Re: [Intel-gfx] [PATCH] drm/i915/chv: Implement Wa4x4STCOptimizationDisable:chv

On Thu, Sep 18, 2014 at 11:08:23AM +0300, Ville Syrjälä wrote: > On Wed, Sep 17, 2014 at 05:03:02AM -0700, Rodrigo Vivi wrote: > > Cc: Ville Syrjälä > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/intel_ringbuffer.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --g

Re: [Intel-gfx] [PATCH] drm/i915/chv: Implement Wa4x4STCOptimizationDisable:chv

On Wed, Sep 17, 2014 at 05:03:02AM -0700, Rodrigo Vivi wrote: > Cc: Ville Syrjälä > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ri