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
delay calculation(Ville).
== 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:
== 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)
Te
== 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:
pa
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 UTC integration manifest
>> >
>> > Test gem_storedw_lo
== 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:
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 UTC integration manifest
>> >
>> > Test gem_storedw_lo
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 address this one in previous mail. Thi
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 too, we can't afford to sprinkle warnings all over
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 a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i91
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
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 b/drivers/gpu/drm/i915/i915_reg.h
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 pre
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 5eb4eea..b8dbd2c 100644
--- a/driv
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
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5a2ad10..af95091 1006
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 wel
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 +
1 file changed, 5 insertions(+)
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 changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i
== 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 (bdw-
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.
>
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 no
== 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 dwarn:0
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 i2c controllers someone can use
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 @@ stati
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
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Sig
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 et
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 direc
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 reason for using this approach is
== 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 (bdw-
== 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 (bdw-
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 guarantees T12 delay
> >> compl
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 pre
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: John
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 t
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 spe
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
---
drivers/gpu/drm/i915/intel_lrc.c
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
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 creat
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 it's
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.
Y
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 when running the gem_reset_st
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 but
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,
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
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 was
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
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 conte
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
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 firing about
a double reserve
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
LRC lifetime is well def
== 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:
pa
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 usersp
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 Gordon
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i9
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 Deucher
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/tegra/dc.c
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 dpc
On 13/01/16 13:36, Imre Deak wrote:
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 wh
On 13/01/16 12:53, Chris Wilson wrote:
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_CH
This shouldn't be used by atomic drivers any more, it confuses the
state tracking.
Cc: Maxime Ripard
Cc: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/
On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
>
> On 13/01/16 13:36, Imre Deak wrote:
> >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, 20
On 12/01/16 16:19, Daniel Vetter wrote:
On Mon, Jan 11, 2016 at 09:51:38AM +, Tvrtko Ursulin wrote:
On 11/01/16 08:43, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 01:29:14PM +, Tvrtko Ursulin wrote:
On 08/01/16 11:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to catc
Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.
The clamping has been HDMI specific since its introduction in
commit 996a2239f93b03c597
On ke, 2016-01-13 at 14:32 +, Chris Wilson wrote:
> On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
> >
> > On 13/01/16 13:36, Imre Deak wrote:
> > > On ke, 2016-01-13 at 12:46 +, Tvrtko Ursulin wrote:
> > > > On 11/01/16 16:56, Chris Wilson wrote:
> > > > > On Mon, Jan 11,
Starting with Gen7 (IVB) Display PipeC can be fused off on some production
parts. When disabled, display hardware will prevent the pipe C register bit
from being set to 1.
Fixed by adjusting pipe_count to reflect this.
Signed-off-by: Gabriel Feceoru
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
On 13/01/16 14:41, Imre Deak wrote:
On ke, 2016-01-13 at 14:32 +, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
On 13/01/16 13:36, Imre Deak wrote:
On ke, 2016-01-13 at 12:46 +, Tvrtko Ursulin wrote:
On 11/01/16 16:56, Chris Wilson wrote:
On Mo
On Wed, Jan 13, 2016 at 04:46:43PM +0200, Gabriel Feceoru wrote:
> Starting with Gen7 (IVB) Display PipeC can be fused off on some production
> parts. When disabled, display hardware will prevent the pipe C register bit
> from being set to 1.
>
> Fixed by adjusting pipe_count to reflect this.
The
== Summary ==
Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly:
2016y-01m-13d-12h-32m-08s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass -> DMESG-WARN (bdw-
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> When created originally intel_dp_check_link_status()
> was supposed to handle only link training for short
> pulse but has grown into handler for short pulse itself.
> This patch cleans up this function by splitting it into
> two hal
Use hlist_for_each_entry() instead of hlist_for_each() to simplify
the code.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i91
Use kobj_to_dev() instead of open-coding it.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/i915/i915_sysfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 37e3f0d..c6188dd 100644
--- a/dr
On Wed, Jan 13, 2016 at 04:35:20PM +0200, Jani Nikula wrote:
> Per DP spec, the source device should fall back to 18 bpp, VESA range
> RGB when the sink capability is unknown. Fix the color depth
> clamping. 18 bpp color depth should ensure full color range in automatic
> mode.
>
> The clamping ha
On Wed, Jan 13, 2016 at 10:48:39PM +0800, Geliang Tang wrote:
> Use hlist_for_each_entry() instead of hlist_for_each() to simplify
> the code.
>
> Signed-off-by: Geliang Tang
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
== Summary ==
Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly:
2016y-01m-13d-12h-32m-08s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (hsw-gt2)
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS
On Wed, Jan 13, 2016 at 12:13:17PM -, Patchwork wrote:
> == Summary ==
>
> Built on 8da57dfe6c675c35109dac986e3f8b627cffab49 drm-intel-nightly:
> 2016y-01m-13d-10h-33m-04s UTC integration manifest
>
> Test gem_storedw_loop:
> Subgroup basic-render:
> pass -> DME
On ke, 2016-01-13 at 14:53 +, Tvrtko Ursulin wrote:
> On 13/01/16 14:41, Imre Deak wrote:
> > On ke, 2016-01-13 at 14:32 +, Chris Wilson wrote:
> > > On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
> > > >
> > > > On 13/01/16 13:36, Imre Deak wrote:
> > > > > On ke, 2016-01
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 whitelist. Userspace need write access to them to implement preemption
r
== Summary ==
Built on aa7ddea990dfc10c7e90ad10820e0121a9667453 drm-intel-nightly:
2016y-01m-13d-15h-05m-13s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
skip -> PASS (bdw-nuci7)
Subgroup nonblocking-crc-pipe-c:
On Wed, Jan 13, 2016 at 10:48:40PM +0800, Geliang Tang wrote:
> Use kobj_to_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
On Wed, Jan 13, 2016 at 08:24:52AM -, Patchwork wrote:
> == Summary ==
>
> Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly:
> 2016y-01m-12d-21h-16m-40s UTC integration manifest
>
> Test gem_storedw_loop:
> Subgroup basic-render:
> pass -> DME
On Wed, Jan 13, 2016 at 05:25:09PM +0200, Imre Deak wrote:
> On ke, 2016-01-13 at 14:53 +, Tvrtko Ursulin wrote:
> > On 13/01/16 14:41, Imre Deak wrote:
> > > On ke, 2016-01-13 at 14:32 +, Chris Wilson wrote:
> > > > On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
> > > > >
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 ivybridge
The existing code assumes a sequential mapping of panel fitters to pipes
(pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
uses pfit 0 and pipe C for eDP1 when the firmware boots in a non-16:10
resolution (the last
This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Signed-off-by: Emmanuel Gil Peyrot
---
include/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..59fc54d 100644
--- a/inclu
Am Montag, den 11.01.2016, 22:41 +0100 schrieb Daniel Vetter:
> So this one is special, since it tries to prevent races when userspace
> crashes simply by disabling the vblank machinery. Well except that imx
> always has vblanks enabled, and the disable_vblank hook actually just
> tries to cancel a
On Mon, 11 Jan 2016 22:41:06 +0100
Daniel Vetter wrote:
> The only thing this did was cancle pending flip events, and the core
> takes care of that now.
>
> Cc: Boris Brezillon
> Acked-by: Daniel Stone
> Reviewed-by: Alex Deucher
> Signed-off-by: Daniel Vetter
Acked-by: Boris Brezillon
>
On 13/01/2016 14:11, Dave Gordon wrote:
On 13/01/16 12:53, Chris Wilson wrote:
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
On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> The existing code assumes a sequential mapping of panel fitters to pipes
> (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
> uses pfit 0 and p
On Wed, Jan 13, 2016 at 05:13:31PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> > The existing code assumes a sequential mapping of panel fitters to pipes
> > (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> > arbitrarily assign a
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 interesting bits and values
in the engine and context structures.
Some usages are also removed where they are
On Wed, Jan 13, 2016 at 03:13:40PM -, Patchwork wrote:
> == Summary ==
>
> Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly:
> 2016y-01m-13d-12h-32m-08s UTC integration manifest
>
> Test gem_ctx_basic:
> pass -> FAIL (hsw-gt2)
This seems to be
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
It is beneficial to know the exact sw states of power wells
at the moment when unclaimed register access is detect.
When the backtrace has been printed to dmesg, it is
followed by a power well states, for example:
--[power wells, wakeref_count 2] --
Name sw statecount
display
On Wed, Jan 13, 2016 at 05:14:15PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 05:13:31PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> > > The existing code assumes a sequential mapping of panel fitters to pipes
> > > (pfit0-pipeA, pf
== Summary ==
Built on 0f3950521e4fd6b37f9d48d8484e2e0ce926ecca drm-intel-nightly:
2016y-01m-13d-15h-43m-52s UTC integration manifest
Test gem_basic:
Subgroup create-close:
dmesg-warn -> PASS (skl-i7k-2)
Test gem_cpu_reloc:
Subgroup basic:
dm
Hangcheck is run on irq context and might be active on a
completely different CPU that is submitting requests. And as
we have been very careful not to add locking to hangcheck to guard
against driver failures, we need to be careful with the coherency.
Update ring last seqno and add to request list
On Tue, Jan 12, 2016 at 09:08:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here's a repost of some already reviewed patches from my larger fb
> offsets[] series [1] from last year, for the sake of the CI system.
>
> [1] http://lists.freedesktop.org/archives/intel-g
From: Tomas Elf
GPU engine reset handshaking is something that is applicable to both full GPU
reset and engine reset, which is something that is part of the upcoming TDR
per-engine hang recovery patches. Break out the common engine reset
request/unrequest code (originally written by Mika Kuoppala
These patches were sent previously a while ago[1] so rebased on latest nightly
and resending again for feedback.
This patch series adds support for Per engine resets, watchdog timeout
reset. Please see [1] for detailed description.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/
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 this to the error handler. During hang
checking every engine is checked and the hang detection
From: Tomas Elf
Makes i915_gem_reset_ring_status() public for use from engine reset path in
order to replicate the same behavior as in full GPU reset but for a single
engine.
Signed-off-by: Tomas Elf
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/d
From: Tomas Elf
TDR = Timeout Detection and Recovery.
This change introduces support for TDR-style per-engine reset as an initial,
less intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. Initially we're only
supporting gen8
1 - 100 of 177 matches
Mail list logo
