[Intel-gfx] [PATCH 7/8] drm/i915/skl: Enable Per context Preemption granularity control

Per context preemption granularity control is only available from SKL:E0+ Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms:

[Intel-gfx] [PATCH] drm/i915: Init power domains early in driver load

Since commit ac9b8236551d1177fd07b56aef9b565d1864420d Author: Ville Syrjälä Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the

[Intel-gfx] [PATCH] drm/omap: Nuke close hooks

Again since the core takes care of this we can remove them. While at it also remove the postclose hook, it's empty. v2: Laurent pointed me at even more code to delete. v3: Remove unused flags (Tomi). Cc: Laurent Pinchart Cc: Tomi Valkeinen

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

Daniel Vetter writes: > On Mon, Jan 11, 2016 at 02:50:28PM +0200, Mika Kuoppala wrote: >> Patchwork writes: >> >> > == Summary == >> > >> > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: >> > 2016y-01m-11d-07h-30m-16s

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

Argh, actually add Annie/Jesse! -Daniel On Wed, Jan 13, 2016 at 10:39 AM, Daniel Vetter wrote: > On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala > wrote: >>> But what with all the pass->dmesg-warn changes above? That's considered >>> BAT failure

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala wrote: >> But what with all the pass->dmesg-warn changes above? That's considered >> BAT failure too, we can't afford to sprinkle warnings all over ... And >> it's a bunch of different machines. >> > > Forgot to

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on dd4a7926b4118f72b7ae0f7b97e9644172df472c drm-intel-nightly: 2016y-01m-13d-09h-05m-34s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE pass -> DMESG-WARN

Re: [Intel-gfx] [PATCH 16/22] drm/omap: Nuke close hooks

Hi Daniel, On 11/01/16 23:41, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c > b/drivers/gpu/drm/omapdrm/omap_drv.c > index dfafdb602ad2..603a65498b40 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -175,17 +175,6 @@

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms:

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra)

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

Daniel Vetter writes: > On Mon, Jan 11, 2016 at 02:50:28PM +0200, Mika Kuoppala wrote: >> Patchwork writes: >> >> > == Summary == >> > >> > Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly: >> > 2016y-01m-11d-07h-30m-16s

[Intel-gfx] [PATCH 2/8] drm/i915/gen9: Add GEN8_CS_CHICKEN1 to HW whitelist

Required for WaEnablePreemptionGranularityControlByUMD:skl,bxt Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 6 ++ 2 files changed, 8 insertions(+) diff --git

[Intel-gfx] [PATCH 6/8] drm/i915/skl: Add GEN8_L3SQCREG4 to HW whitelist

Required for WaDisableLSQCROPERFforOCL:skl Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index

[Intel-gfx] [PATCH 8/8] drm/i915/gen9: Add WaOCLCoherentLineFlush

This is mainly required for preemption. Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 4/8] drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist

Required for, WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt WaDisableObjectLevelPreemptionForInstancedDraw:bxt WaDisableObjectLevelPreemtionForInstanceId:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares the same GT these are extended for A1 as

[Intel-gfx] [PATCH 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

Some of the HW registers are privileged and cannot be written to from a non-privileged batch buffers coming from userspace unless they are on whitelist. Userspace need write access to them to implement preemption related WA. The reason for using this approach is, the register bits that control

[Intel-gfx] [PATCH 0/8] Gen9 HW whitelist and Preemption WA patches

Set of patches that add HW whitelist framework and Preemption WA patches. HW whitelist patch is already sent to list and reviewed[1], it is just rebased in this version. This was not merged before as there was no user; this is still the case but since Preemption patches[2] are already on the list

[Intel-gfx] [PATCH 3/8] drm/i915/gen9: Add HDC_CHICKEN1 to HW whitelist

Required for WaAllowUMDToModifyHDCChicken1:skl,bxt Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH 5/8] drm/i915/bxt: Add GEN8_L3SQCREG4 to HW whitelist

Required for WaDisableLSQCROPERFforOCL:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares the same GT these are extended for A1 as well. Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +

Re: [Intel-gfx] [PATCH 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Wed, Jan 13, 2016 at 10:06:26AM +, Arun Siluvery wrote: > Some of the HW registers are privileged and cannot be written to from a > non-privileged batch buffers coming from userspace unless they are on > whitelist. > Userspace need write access to them to implement preemption related WA. >

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on dd4a7926b4118f72b7ae0f7b97e9644172df472c drm-intel-nightly: 2016y-01m-13d-09h-05m-34s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE bdw-nuci7total:138 pass:129

[Intel-gfx] [PATCH] drm/i915: Expose exec parameter to force non IA-Coherent for Gen9+

Starting from Gen9 we can use IA-Coherent caches. Coherence may be not required in certain cases and can be disabled in an easy way. To do this we can set HDC_FORCE_NON_COHERENT bit in HDC_CHICKEN0 register. This register is part of HW context, however it is private and cannot be programmed from

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: > intel_dp_detect() is called for not just detection but > during modes enumeration as well. Repeating the whole > sequence during each of these calls is wasteful and > time consuming. > This patch moves probing for panel, DPCD read

Re: [Intel-gfx] [PATCH v4] drm/i915: edp resume/On time optimization.

On 01/13/2016 07:27 AM, abhay.ku...@intel.com wrote: From: Abhay Kumar Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly: 2016y-01m-12d-21h-16m-40s UTC integration manifest Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (skl-i5k-2) Test gem_cpu_reloc: Subgroup basic:

Re: [Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

On 12/01/16 17:12, Daniel Vetter wrote: > Different approaches to the same problem: > > - omap just unlinks the event from fpriv and still process it normally. > But then before sending it out it checks whether the fpriv is still > there or not and either sends it, or deletes the event

[Intel-gfx] [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

Some of the HW registers are privileged and cannot be written to from a non-privileged batch buffers coming from userspace unless they are on whitelist. Userspace need write access to them to implement preemption related WA. The reason for using this approach is, the register bits that control

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v3.

On Mon, Jan 11, 2016 at 01:27:42PM +0100, Maarten Lankhorst wrote: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by

Re: [Intel-gfx] [PATCH v4 10/38] drm/i915: Force MMIO flips when scheduler enabled

On Wed, Jan 13, 2016 at 12:37:44PM +, John Harrison wrote: > On 12/01/2016 21:53, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 03:07:03PM +0100, Daniel Vetter wrote: > >>On Tue, Jan 12, 2016 at 11:19:26AM +, John Harrison wrote: > >>>On 11/01/2016 22:16, Chris Wilson wrote: > On Mon,

Re: [Intel-gfx] [PATCH 7/7] drm/i915: GEM operations need to be done under the big lock

On ke, 2016-01-13 at 12:46 +, Tvrtko Ursulin wrote: > On 11/01/16 16:56, Chris Wilson wrote: > > On Mon, Jan 11, 2016 at 05:36:46PM +0200, Ville Syrjälä wrote: > > > On Mon, Jan 11, 2016 at 03:16:16PM +, Tvrtko Ursulin wrote: > > > > Don't know, I leave this one to whoever grabbed the lock

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly: 2016y-01m-13d-12h-32m-08s UTC integration manifest Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (skl-i5k-2) Test gem_cpu_reloc: Subgroup basic:

[Intel-gfx] ✗ warning: Fi.CI.BAT

== Summary == Built on 8da57dfe6c675c35109dac986e3f8b627cffab49 drm-intel-nightly: 2016y-01m-13d-10h-33m-04s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH v4 10/38] drm/i915: Force MMIO flips when scheduler enabled

On 12/01/2016 21:53, Chris Wilson wrote: On Tue, Jan 12, 2016 at 03:07:03PM +0100, Daniel Vetter wrote: On Tue, Jan 12, 2016 at 11:19:26AM +, John Harrison wrote: On 11/01/2016 22:16, Chris Wilson wrote: On Mon, Jan 11, 2016 at 06:42:39PM +, john.c.harri...@intel.com wrote: From:

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Wed, Jan 13, 2016 at 12:28:17PM +, Arun Siluvery wrote: > Some of the HW registers are privileged and cannot be written to from a > non-privileged batch buffers coming from userspace unless they are on > whitelist. > Userspace need write access to them to implement preemption related WA.

Re: [Intel-gfx] [PATCH 19/22] drm/tegra: Stop cancelling page flip events

On Mon, Jan 11, 2016 at 10:41:13PM +0100, Daniel Vetter wrote: > The core takes care of that now. > > v2: Fixup misplaced hunk. > > Cc: Thierry Reding > Cc: Terje Bergström > Acked-by: Daniel Stone > Reviewed-by: Alex

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: tidy up a few leftovers

On 12/01/16 13:53, Daniel Vetter wrote: On Thu, Jan 07, 2016 at 10:20:52AM +, Dave Gordon wrote: There are a few bits of code which the transformations implemented by the previous patch reveal to be suboptimal, once the notion of a per- ring default context has gone away. So this tidies up

[Intel-gfx] [PATCH] drm/i915: Fix for reserved space WARN_ON when ring begin fails

From: John Harrison The reserved space code was not cleaning up properly in the case where the intel_ring_begin() call failed. This led to WARN_ONs firing about a double reserve call when running the gem_reset_stats IGT test. Signed-off-by: John Harrison

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote: > On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: > > intel_dp_detect() is called for not just detection but > > during modes enumeration as well. Repeating the whole > > sequence during each of these calls is

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on 8da57dfe6c675c35109dac986e3f8b627cffab49 drm-intel-nightly: 2016y-01m-13d-10h-33m-04s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH 7/7] drm/i915: GEM operations need to be done under the big lock

On 11/01/16 16:56, Chris Wilson wrote: On Mon, Jan 11, 2016 at 05:36:46PM +0200, Ville Syrjälä wrote: On Mon, Jan 11, 2016 at 03:16:16PM +, Tvrtko Ursulin wrote: Don't know, I leave this one to whoever grabbed the lock around intel_init_gt_powersave in the first place. Maybe there was a

Re: [Intel-gfx] vsync + vaapi question

Hi, On Thu, Dec 24, 2015 at 08:42:01PM +0100, Lukas Hejtmanek wrote: > > Hard? The fault isn't in libva this time at least. > > applied patch results in hard lockup when playing a movie (short sound loop > and even sysrq keys are not working). I thought that driver would reset gpu > eventualy

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On 12/01/16 14:27, Chris Wilson wrote: On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote: But we were removing the engine->default_context as it complicated the rest of the code. I strongly prefer keeping the contexts explicit as context separation should be first and foremost in the

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On 13/01/2016 13:03, Chris Wilson wrote: On Wed, Jan 13, 2016 at 12:28:17PM +, Arun Siluvery wrote: Some of the HW registers are privileged and cannot be written to from a non-privileged batch buffers coming from userspace unless they are on whitelist. Userspace need write access to them to

Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: Cache LRC state page in the context

On 12/01/16 16:45, Dave Gordon wrote: On 12/01/16 13:11, Chris Wilson wrote: On Tue, Jan 12, 2016 at 12:54:25PM +, Tvrtko Ursulin wrote: On 12/01/16 12:12, Chris Wilson wrote: On Tue, Jan 12, 2016 at 11:56:11AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH] drm/i915: Fix for reserved space WARN_ON when ring begin fails

On 13/01/2016 13:09, Chris Wilson wrote: On Wed, Jan 13, 2016 at 12:52:40PM +, john.c.harri...@intel.com wrote: From: John Harrison The reserved space code was not cleaning up properly in the case where the intel_ring_begin() call failed. This led to WARN_ONs

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Cleaning up intel_dp_hpd_pulse

On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: > Current DP detection has DPCD operations split across > intel_dp_hpd_pulse and intel_dp_detect which contains > duplicates as well. Also intel_dp_detect is called > during modes enumeration as well which will result > in multiple

Re: [Intel-gfx] [PATCH] drm/i915: reboot notifier delay for eDP panels

On Tue, Jan 12, 2016 at 09:06:24AM -0800, Clint Taylor wrote: > On 01/12/2016 05:21 AM, Ville Syrjälä wrote: > > On Mon, Jan 11, 2016 at 01:52:17PM -0800, clinton.a.tay...@intel.com wrote: > >> From: Clint Taylor > >> > >> Add reboot notifier for all platforms. This

Re: [Intel-gfx] [PATCH] drm/i915: Fix for reserved space WARN_ON when ring begin fails

On Wed, Jan 13, 2016 at 12:52:40PM +, john.c.harri...@intel.com wrote: > From: John Harrison > > The reserved space code was not cleaning up properly in the case where > the intel_ring_begin() call failed. This led to WARN_ONs firing about > a double reserve call

Re: [Intel-gfx] [PATCH 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

Arun Siluvery writes: > Some of the HW registers are privileged and cannot be written to from a > non-privileged batch buffers coming from userspace unless they are on > whitelist. > Userspace need write access to them to implement preemption related WA. > > The

Re: [Intel-gfx] [PATCH] drm/i915: Expose exec parameter to force non IA-Coherent for Gen9+

On Wed, Jan 13, 2016 at 11:44:39AM +0100, Artur Harasimiuk wrote: > Starting from Gen9 we can use IA-Coherent caches. Coherence may be not > required in certain cases and can be disabled in an easy way. To do this > we can set HDC_FORCE_NON_COHERENT bit in HDC_CHICKEN0 register. This > register is

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Remove intel_crtc->atomic.disable_ips.

On Mon, Jan 11, 2016 at 01:27:43PM +0100, Maarten Lankhorst wrote: > This is a revert of commit 066cf55b9ce3 "drm/i915: Fix IPS related flicker". > intel_pre_disable_primary already handles this, and now everything > goes through the atomic path there's no need to try to disable ips twice. If

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote: > On 12/01/16 14:27, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote: > >>But we were removing the engine->default_context as it complicated the > >>rest of the code. I strongly prefer keeping the

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Wed, Jan 13, 2016 at 01:41:47PM +, Arun Siluvery wrote: > On 13/01/2016 13:03, Chris Wilson wrote: > >On Wed, Jan 13, 2016 at 12:28:17PM +, Arun Siluvery wrote: > >>Some of the HW registers are privileged and cannot be written to from a > >>non-privileged batch buffers coming from

[Intel-gfx] [PATCH v2] drm/i915: Only grab timestamps when needed

From: Tvrtko Ursulin No need to call ktime_get_raw_ns twice per unlimited wait and can also elimate a local variable. v2: Added comment about silencing the compiler warning. (Daniel Vetter) Signed-off-by: Tvrtko Ursulin Reviewed-by: Dave

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On 12/01/16 23:17, yu@intel.com wrote: From: Alex Dai During driver unloading, the guc_client created for command submission needs to be released to avoid memory leak. The struct_mutex needs to be held before tearing down GuC. v1: Move i915_guc_submission_disable out of

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On 01/13/2016 10:15 AM, Dave Gordon wrote: On 12/01/16 23:17, yu@intel.com wrote: > From: Alex Dai > > During driver unloading, the guc_client created for command submission > needs to be released to avoid memory leak. > > The struct_mutex needs to be held before tearing

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On 13/01/16 18:17, Yu Dai wrote: On 01/13/2016 10:15 AM, Dave Gordon wrote: On 12/01/16 23:17, yu@intel.com wrote: > From: Alex Dai > > During driver unloading, the guc_client created for command submission > needs to be released to avoid memory leak. > > The

Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback

This version resolved the issue (kernel bug check in intel_lr_context_clean_ring) I reported on previous versions. Verified by igt drv_module_reload_basic, gem_close_race and -t basic tests. Reviewed-by: Alex Dai On 01/13/2016 08:19 AM, Nick Hoath wrote: Use the first

Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Wed, Jan 13, 2016 at 07:14:56PM +, Arun Siluvery wrote: > On 13/01/2016 19:01, Chris Wilson wrote: > >On Wed, Jan 13, 2016 at 03:38:15PM +, Arun Siluvery wrote: > >>Some of the HW registers are privileged and cannot be written to from > >>non-privileged batch buffers coming from

Re: [Intel-gfx] [PATCH 004/190] drm/i915: Fix some invalid requests cancellations

On Tue, Jan 12, 2016 at 06:16:21PM +, Dave Gordon wrote: > On 11/01/16 09:16, Chris Wilson wrote: > >As we add the VMA to the request early, it may be cancelled during > >execbuf reservation. This will leave the context object pointing to a > >dangling request; i915_wait_request() simply skips

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Extending i915_gem_check_wedge to check engine reset in progress

On Wed, Jan 13, 2016 at 05:28:17PM +, Arun Siluvery wrote: > From: Tomas Elf > > i915_gem_wedge now returns a non-zero result in three different cases: > > 1. Legacy: A hang has been detected and full GPU reset is in progress. > > 2. Per-engine recovery: > > a.

Re: [Intel-gfx] [PATCH 03/20] drm/i915: TDR / per-engine hang recovery support for gen8.

On Wed, Jan 13, 2016 at 05:28:15PM +, Arun Siluvery wrote: > @@ -596,6 +598,16 @@ static int i915_drm_suspend(struct drm_device *dev) > + atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG, > + _priv->gpu_error.reset_counter); This could be its own little patch as we could apply

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On 13/01/16 13:41, Chris Wilson wrote: On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote: On 12/01/16 14:27, Chris Wilson wrote: On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote: But we were removing the engine->default_context as it complicated the rest of the code. I

[Intel-gfx] [PATCH v2] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

From: Alex Dai During driver unloading, the guc_client created for command submission needs to be released to avoid memory leak. The struct_mutex needs to be held before tearing down GuC. v1: Move i915_guc_submission_disable out of i915_guc_submission_fini and take

Re: [Intel-gfx] [PATCH v3] drm/i915: Do not call API requiring struct_mutex where it is not available

On Wed, Jan 13, 2016 at 04:16:21PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > LRC code was calling GEM API like i915_gem_obj_ggtt_offset from > places where the struct_mutex cannot be grabbed (irq handlers). > > To avoid that this patch caches some

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

On Wed, Jan 13, 2016 at 06:46:08PM +, Dave Gordon wrote: > On 13/01/16 13:41, Chris Wilson wrote: > >On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote: > >>On 12/01/16 14:27, Chris Wilson wrote: > >>>On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote: > But we were

Re: [Intel-gfx] [PATCH 04/20] drm/i915: TDR / per-engine hang detection

On Wed, Jan 13, 2016 at 05:28:16PM +, Arun Siluvery wrote: > From: Tomas Elf > > With the per-engine hang recovery path already in place this patch adds > per-engine hang detection by letting the periodic hang checker detect hangs on > individual engines and communicate

Re: [Intel-gfx] [PATCH 07/20] drm/i915: Watchdog timeout: Hang detection integration into error handler

On Wed, Jan 13, 2016 at 05:28:19PM +, Arun Siluvery wrote: > /* i915_irq.c */ > void i915_queue_hangcheck(struct drm_device *dev); > -__printf(4, 5) > -void i915_handle_error(struct drm_device *dev, u32 engine_mask, bool wedged, > -const char *fmt, ...); > +__printf(5, 6)

Re: [Intel-gfx] [PATCH 03/20] drm/i915: TDR / per-engine hang recovery support for gen8.

On Wed, Jan 13, 2016 at 05:28:15PM +, Arun Siluvery wrote: > diff --git a/drivers/gpu/drm/i915/i915_params.c > b/drivers/gpu/drm/i915/i915_params.c > index 8d90c25..5cf9c11 100644 > --- a/drivers/gpu/drm/i915/i915_params.c > +++ b/drivers/gpu/drm/i915/i915_params.c > @@ -37,6 +37,8 @@ struct

Re: [Intel-gfx] [RFC 2/9] staging/android/sync: add sync_fence_create_dma

Hi John, 2016-01-13 john.c.harri...@intel.com : > From: Maarten Lankhorst > > This allows users of dma fences to create a android fence. > > v0.2: Added kerneldoc. (Tvrtko Ursulin). > > v0.4: Updated comments from review feedback by

Re: [Intel-gfx] [PATCH 06/20] drm/i915: Reinstate hang recovery work queue.

On Wed, Jan 13, 2016 at 05:28:18PM +, Arun Siluvery wrote: > From: Tomas Elf > > There used to be a work queue separating the error handler from the hang > recovery path, which was removed a while back in this commit: > > commit

Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL

On Wed, Jan 13, 2016 at 05:57:32PM +, john.c.harri...@intel.com wrote: > static int > i915_gem_do_execbuffer(struct drm_device *dev, void *data, > struct drm_file *file, > @@ -1428,6 +1465,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > *data, > u32

Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging

Hi John, 2016-01-13 john.c.harri...@intel.com : > From: John Harrison > > The sync framework is now used by the i915 driver. Therefore it can be > moved out of staging and into the regular tree. Also, the public > interfaces can actually be

Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging

2016-01-13 john.c.harri...@intel.com : > From: John Harrison > > The sync framework is now used by the i915 driver. Therefore it can be > moved out of staging and into the regular tree. Also, the public > interfaces can actually be made

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On 13/01/16 19:01, yu@intel.com wrote: From: Alex Dai During driver unloading, the guc_client created for command submission needs to be released to avoid memory leak. The struct_mutex needs to be held before tearing down GuC. v1: Move i915_guc_submission_disable out of

Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Wed, Jan 13, 2016 at 03:38:15PM +, Arun Siluvery wrote: > Some of the HW registers are privileged and cannot be written to from > non-privileged batch buffers coming from userspace unless they are added to > the HW whitelist. This whitelist is maintained by HW and it is different from > SW

Re: [Intel-gfx] [PATCH] drm/i915: Allow i915_gem_object_get_page() on userptr as well

On 12/01/16 23:49, Chris Wilson wrote: On Tue, Jan 12, 2016 at 11:40:06PM +, Chris Wilson wrote: struct drm_i915_gem_object_ops { + const unsigned int flags; Bleh, const is redundant as the definitions should be const themselves. -Chris Yeah, the const-ness attaches to the

Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.

Tested-by: Mark Janes Francisco Jerez writes: > We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee > that writes performed via the HDC are visible in memory. Fixes an > intermittent failure in a Piglit test that writes to a BO

Re: [Intel-gfx] [PATCH] drm/omap: Nuke close hooks

Hi Daniel, Thank you for the patch. On Wednesday 13 January 2016 12:05:14 Daniel Vetter wrote: > Again since the core takes care of this we can remove them. While at > it also remove the postclose hook, it's empty. > > v2: Laurent pointed me at even more code to delete. > > v3: Remove unused

[Intel-gfx] [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace

From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever there is a failure in object allocation. This patch helps user to

[Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast

From: Ankitprasad Sharma In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, we try a nonblocking pin for the whole object (since that is fastest if reused), then failing that we try to grab one page in the mappable aperture. It also allows us

[Intel-gfx] [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages

From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like evicting objects to free up enough contiguous space in the vma when

[Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

From: Ankitprasad Sharma Some modules, like i915.ko, needs to detect when certain ACPI features are active inorder to prevent corruption on contended resources. In particular, use of BIOS RapidStart Technology may corrupt the contents of the reserved graphics

[Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects

From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be

[Intel-gfx] [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation

From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and promptly hanging the GPU on resume. We want to utilise stolen for

[Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated over to access the whole object by using space as meagre as page

[Intel-gfx] [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address()

From: Chris Wilson This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with any page within the object. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v14 0/11] Support for creating/using Stolen memory backed objects

From: Ankitprasad Sharma This patch series adds support for creating/using Stolen memory backed objects. Despite being a unified memory architecture (UMA) some bits of memory are more equal than others. In particular we have the thorny issue of stolen memory,

[Intel-gfx] [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects

From: Ankitprasad Sharma This patch adds support for extending the pread/pwrite functionality for objects not backed by shmem. The access will be made through gtt interface. This will cover objects backed by stolen memory as well as other non-shmem backed objects.

Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.

On Thu, 14 Jan 2016, Francisco Jerez wrote: > We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee > that writes performed via the HDC are visible in memory. Fixes an > intermittent failure in a Piglit test that writes to a BO from a > shader using GL atomic

[Intel-gfx] [PATCH 11/11] drm/i915: Disable use of stolen area by User when Intel RST is present

From: Ankitprasad Sharma The BIOS RapidStartTechnology may corrupt the stolen memory across S3 suspend due to unalarmed hibernation, in which case we will not be able to preserve the User data stored in the stolen region. Hence this patch tries to identify

[Intel-gfx] [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT

From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only for buffers allocated from stolen region. v2: Added kernel doc

Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging

On Wed, Jan 13, 2016 at 05:57:29PM +, john.c.harri...@intel.com wrote: > From: John Harrison > > The sync framework is now used by the i915 driver. Therefore it can be > moved out of staging and into the regular tree. Also, the public > interfaces can actually be

[Intel-gfx] ✓ success: Fi.CI.BAT

== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (skl-i7k-2)

[Intel-gfx] ✗ failure: Fi.CI.BAT

== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_ctx_param_basic: Subgroup non-root-set: pass ->

[Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

When we stop the sink CRC calculation we wait a while until the counter is reset to zero and return -ETIMEDOUT. However the sink crc was calculated already by this point so we just ignore this return at the main function. So, let's also ignore the message and put it as a debug message instead of

[Intel-gfx] [PATCH] drm-intel: add notes about handling -nightly rebuilds

Also try to polish the formatting a bit. Signed-off-by: Daniel Vetter --- drm-intel.rst | 60 ++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/drm-intel.rst b/drm-intel.rst index

[Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.

We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee that writes performed via the HDC are visible in memory. Fixes an intermittent failure in a Piglit test that writes to a BO from a shader using GL atomic counters (implemented as HDC untyped atomics) and then expects the memory to

[Intel-gfx] [PATCH v3] drm/i915: Handle PipeC fused off on IVB/HSW/BDW

Some Gen7/8 production parts may have the Display Pipe C fused off. In this case, the display hardware will prevent the Pipe C register bit from being set to 1. Fixed by adjusting pipe_count to reflect this. v2: Rename HSW_PIPE_C_DISABLE to IVB_PIPE_C_DISABLE as it already exists on

  1   2   >