[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Use major_minor version for filename

== Series Details == Series: drm/i915/guc: Use major_minor version for filename URL : https://patchwork.freedesktop.org/series/6293/ State : failure == Summary == Series 6293v1 drm/i915/guc: Use major_minor version for filename

[Intel-gfx] [PATCH 01/19] drm/core: Add drm_accurate_vblank_count, v5.

This function is useful for gen2 intel devices which have no frame counter, but need a way to determine the current vblank count without racing with the vblank interrupt handler. intel_pipe_update_start checks if no vblank interrupt will occur during vblank evasion, but cannot check whether the

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/19] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr

== Series Details == Series: series starting with [01/19] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr URL : https://patchwork.freedesktop.org/series/6017/ State : warning == Summary == Series 6017v1 Series without cover letter

[Intel-gfx] [PATCH 4/4] drm/i915/bxt: Tune L3 SQC credits based on actual latencies

BSpec says we need to fine tune these values, so comply. I checked this with random GPU benchmarks and it does seem to improve things. Note that I considered to program this from the ring as part of the context specific workarounds there, I decided against that for the following reasons: - It's

[Intel-gfx] [PATCH 2/4] drm/i915: Clean up L3 SQC register field definitions

No need for hard-coding the register value, the corresponding fields are defined properly in BSpec. No functional change. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_reg.h | 3 ++- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 2 files changed, 4 insertions(+), 2

[Intel-gfx] [PATCH 1/4] drm/i915/bdw: Add missing delay during L3 SQC credit programming

BSpec requires us to wait ~100 clocks before re-enabling clock gating, so make sure we do this. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On Mon, Apr 25, 2016 at 03:23:21PM +0300, Imre Deak wrote: > Setting a write-back cache policy in the MOCS entry definition also > implies snooping, which has a considerable overhead. This is > unexpected for a few reasons: > - From user-space's point of view since it didn't want a coherent >

[Intel-gfx] [PATCH 3/4] drm/i915/chv: Tune L3 SQC credits based on actual latencies

While browsing BSpec I bumped into a note saying we need to tune these values based on actual measurements done after initial enabling. I've checked that it indeed improves things on BXT. I haven't checked this on CHV, but here it is if someone wants to give it a go. CC: Ville Syrjälä

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_busy: Fix passing invalid fd for basic-parallel-* tests.

On Mon, Apr 25, 2016 at 03:25:00PM +0300, Marius Vlad wrote: > Caught by check target. > > Signed-off-by: Marius Vlad Ugh, gcc-6 and -Windent for me I guess. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On ma, 2016-04-25 at 13:37 +0100, Chris Wilson wrote: > On Mon, Apr 25, 2016 at 03:23:21PM +0300, Imre Deak wrote: > > Setting a write-back cache policy in the MOCS entry definition also > > implies snooping, which has a considerable overhead. This is > > unexpected for a few reasons: > > - From

Re: [Intel-gfx] [PATCH 1/3] drm/i915/hda: Add audio component stub

On Thu, 07 Apr 2016 14:30:45 +0200, Imre Deak wrote: > > On to, 2016-04-07 at 14:55 +0300, Ville Syrjälä wrote: > > On Thu, Apr 07, 2016 at 12:57:22PM +0200, Takashi Iwai wrote: > > > From: Imre Deak > > > > > > User may pass nomodeset or i915.modeset=0 option to disable

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On Mon, Apr 25, 2016 at 03:39:54PM +0300, Imre Deak wrote: > On ma, 2016-04-25 at 13:37 +0100, Chris Wilson wrote: > > On Mon, Apr 25, 2016 at 03:23:21PM +0300, Imre Deak wrote: > > > Setting a write-back cache policy in the MOCS entry definition also > > > implies snooping, which has a

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gen9: Clean up MOCS table definitions

== Series Details == Series: series starting with [1/2] drm/i915/gen9: Clean up MOCS table definitions URL : https://patchwork.freedesktop.org/series/6249/ State : failure == Summary == Series 6249v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On ma, 2016-04-25 at 13:49 +0100, Chris Wilson wrote: > On Mon, Apr 25, 2016 at 03:39:54PM +0300, Imre Deak wrote: > > On ma, 2016-04-25 at 13:37 +0100, Chris Wilson wrote: > > > On Mon, Apr 25, 2016 at 03:23:21PM +0300, Imre Deak wrote: > > > > Setting a write-back cache policy in the MOCS entry

[Intel-gfx] [PATCH i-g-t] tests/gem_busy: Fix passing invalid fd for basic-parallel-* tests.

Caught by check target. Signed-off-by: Marius Vlad --- tests/gem_busy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gem_busy.c b/tests/gem_busy.c index d81604d..af634c5 100644 --- a/tests/gem_busy.c +++ b/tests/gem_busy.c @@ -407,8 +407,8

[Intel-gfx] [PATCH 1/2] drm/i915/gen9: Clean up MOCS table definitions

Use named struct initializers for clarity. Also fix the target cache definition to reflect its role in GEN9 onwards. On GEN8 a TC value of 0 meant ELLC but on GEN9+ it means the TC and LRU controls are taken from the PTE. No functional change. Signed-off-by: Imre Deak ---

Re: [Intel-gfx] [PATCH 01/19] drm/core: Add drm_accurate_vblank_count, v4.

On Mon, Apr 25, 2016 at 06:35:48AM +0200, Mario Kleiner wrote: > Sorry for the late review, but see below... > > On 04/19/2016 09:52 AM, Maarten Lankhorst wrote: > > This function is useful for gen2 intel devices which have no frame > > counter, but need a way to determine the current vblank

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: Clean up MOCS table definitions

On Mon, Apr 25, 2016 at 03:23:20PM +0300, Imre Deak wrote: > Use named struct initializers for clarity. Also fix the target cache > definition to reflect its role in GEN9 onwards. On GEN8 a TC value of 0 > meant ELLC but on GEN9+ it means the TC and LRU controls are taken from > the PTE. > > No

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Remove i915_gem_obj_size

On 25/04/16 09:29, Dave Gordon wrote: On 23/04/16 16:58, Patchwork wrote: == Series Details == Series: series starting with [1/4] drm/i915: Remove i915_gem_obj_size URL : https://patchwork.freedesktop.org/series/6060/ State : warning == Summary == Series 6060v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: rename i915_gem_alloc_object() to i915_gem_object_create()

On 25/04/16 09:14, Dave Gordon wrote: On 24/04/16 10:23, Patchwork wrote: == Series Details == Series: drm/i915: rename i915_gem_alloc_object() to i915_gem_object_create() URL : https://patchwork.freedesktop.org/series/6183/ State : warning == Summary == Series 6183v1 drm/i915: rename

Re: [Intel-gfx] [PATCH v6 00/34] GPU scheduler for i915 driver

On 25/04/2016 10:54, Chris Wilson wrote: On Wed, Apr 20, 2016 at 06:13:18PM +0100, john.c.harri...@intel.com wrote: From: John Harrison Implemented a batch buffer submission scheduler for the i915 DRM driver. The general theory of operation is that when batch

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/atomic: Always allow async support for the atomic ioctl.

== Series Details == Series: drm/atomic: Always allow async support for the atomic ioctl. URL : https://patchwork.freedesktop.org/series/6245/ State : failure == Summary == Series 6245v1 drm/atomic: Always allow async support for the atomic ioctl.

[Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

Setting a write-back cache policy in the MOCS entry definition also implies snooping, which has a considerable overhead. This is unexpected for a few reasons: - From user-space's point of view since it didn't want a coherent surface (it didn't set the buffer as such via the set caching IOCTL). -

[Intel-gfx] [PATCH] drm/i915: Propagate error from drm_gem_object_init()

From: Chris Wilson Propagate the real error from drm_gem_object_init(). Note this also fixes some confusion in the error return from i915_gem_alloc_object... v2: (Matthew Auld) - updated new users of gem_alloc_object from latest drm-nightly - replaced occurrences

<    1   2