Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

Hi, Thanks for the feedback. I'll update the commit title. I will also separate this patch into 5 patches. For now I want to keep the "ifdef dance" in igt_fbc.c. If we want to split the file up, that should be a new commit/patch. (I think we should get the fbc tests building on Android first

[Intel-gfx] [PATCH v2] drm/i915: Support to enable TRTT on GEN9

From: Akash Goel Gen9 has an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra level of abstraction over PPGTT. This is useful for mapping Sparse/Tiled texture resources. Sparse resources are created

[Intel-gfx] [PATCH v2] igt/gem_trtt: Exercise the TRTT hardware

From: Akash Goel This patch provides the testcase to exercise the TRTT hardware. Some platforms have an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra level of abstraction over PPGTT. This is

Re: [Intel-gfx] [PATCH 2/6] drm: introduce color correction properties

On Fri, Jan 22, 2016 at 12:12:08PM +, Lionel Landwerlin wrote: > v2: Register LUT size properties as range > > Signed-off-by: Lionel Landwerlin Probably should have noticed/commented on this on your previous iteration, but should we also restrict these new

Re: [Intel-gfx] [PATCH v2] igt/gem_trtt: Exercise the TRTT hardware

On Fri, Jan 22, 2016 at 09:07:47PM +0530, akash.g...@intel.com wrote: > +static int emit_store_dword(int fd, uint32_t *cmd_buf, uint32_t dw_offset, > + uint64_t vaddr, uint32_t data) > +{ > + cmd_buf[dw_offset++] = MI_STORE_DWORD_IMM; > + cmd_buf[dw_offset++] =

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

commit 033908aed5a596f6202c848c6bbc8a40fb1a8490 Author: Dave Gordon Date: Thu Dec 10 18:51:23 2015 + drm/i915: mark GEM object pages dirty when mapped & written by the CPU introduced a check into i915_gem_object_get_dirty_pages() that returned a NULL pointer

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: resize the GuC WOPCM for rc6

Reply inline. On Thu, 21 Jan 2016, Jeff McGee wrote: On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote: This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: Clean up locks in GuC

On 03/12/15 00:56, yu@intel.com wrote: > From: Alex Dai > > For now, remove the spinlocks that protected the GuC's > statistics block and work queue; they are only accessed > by code that already holds the global struct_mutex, and > so are redundant (until the big

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

Hi, On Fri, Jan 22, 2016 at 07:43:14AM +0200, Palleti, Avinash Reddy wrote: > Thanks Matt for pointing me to this. > > Vlad, It's Marius :-). > As Matt mentioned, we are also working on this to get atomic support in > i-g-t. Last week we finalized the design with Matt. I am putting the design

[Intel-gfx] ✗ Fi.CI.BAT: warning for Add drm_dp_aux chardev support. (rev5)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) Subgroup basic-flip-vs-modeset:

Re: [Intel-gfx] [PATCH 2/6] drm: introduce color correction properties

On 21/01/16 19:20, Matt Roper wrote: On Thu, Jan 21, 2016 at 03:03:49PM +, Lionel Landwerlin wrote: ... diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 351e801..d2f682c 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@

Re: [Intel-gfx] [PATCH 1/4] drm/i915: handle teardown of HWSP when context is freed

Dave Gordon writes: > Existing code did a kunmap() on the wrong page, and didn't account for the > fact that the HWSP and the default context are different offsets within the > same GEM object. > Just to note here that usually we try to split bug fixes early in the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Gen9 HW whitelist and Preemption WA patches (rev3)

On 22/01/2016 08:51, Patchwork wrote: == Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (skl-i5k-2)

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/fbdev-helper: Explain how to debug console_lock fun

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

[Intel-gfx] [PATCH] drm/i915: Y/Yf Tiling Workaround for BXT/SKL

BXT/SKL Bspec specifies a workaround of setting a bit of CHICKEN_DCPR_1 register when one of the plane is enabled with a Y or Yf tiled buffer. This patch implements this workaround Signed-off-by: Mayuresh Gharpure --- drivers/gpu/drm/i915/i915_drv.h | 6

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Y/Yf Tiling Workaround for BXT/SKL

== Summary == drivers/gpu/drm/i915/intel_display.c: In function 'skl_handle_ytile_wa': drivers/gpu/drm/i915/intel_display.c:16352:50: error: 'CHICKEN_DCPR_1' undeclared (first use in this function) I915_WRITE(CHICKEN_DCPR_1, I915_READ(CHICKEN_DCPR_1)

[Intel-gfx] [PATCH v2 6/6] drm/i915: consolidate LRC mode HWSP setup & teardown

In legacy ringbuffer mode, the HWSP is a separate GEM object with its own pinning and reference counts. In LRC mode, however, it's not; instead its part of the default context object. The LRC-mode setup & teardown code therefore needs to handle this specially; the presence of the two bugs just

[Intel-gfx] [PATCH v2 4/6] drm/i915: unmap the correct page in intel_logical_ring_cleanup()

The kunmap() call here didn't match the corresponding kmap(). The kmapping was changed with the introduction of the GuC-compatible layout of context objects and the introduction of "LRC_PPHWSP_PN", in d167519 drm/i915: Integrate GuC-based command submission but the corresponding kunmap()

[Intel-gfx] [PATCH] drm/i915/guc: Decouple GuC engine id from ring id

From: Alex Dai Previously GuC uses ring id as engine id because of same definition. But this is not true since this commit: commit de1add360522c876c25ef2ab1c94bdb509ab Author: Tvrtko Ursulin Date: Fri Jan 15 15:12:50 2016 + drm/i915:

[Intel-gfx] [PATCH v2 2/6] drm/i915: tidy up initialisation failure paths (GEM & LRC)

1. add call to i915_gem_context_fini() to deallocate the default context(s) if the call to init_rings() fails, so that we don't leak the context in that situation. 2. remove useless code in intel_logical_ring_cleanup(), presumably copypasted from legacy ringbuffer version at creation.

[Intel-gfx] [PATCH v2 3/6] drm/i915: tidy up initialisation failure paths (legacy)

1. Fix intel_cleanup_ring_buffer() to handle the error cleanup case where the ringbuffer has been allocated but map-and-pin failed. Unpin it iff it's previously been mapped-and-pinned. 2. Fix the error path in intel_init_ring_buffer(), which already called

[Intel-gfx] [PATCH v2 1/6] drm/i915: fix context/engine cleanup order

From: Nick Hoath Swap the order of context & engine cleanup, so that contexts are cleaned up first, and *then* engines. This is a more sensible order anyway, but in particular has become necessary since the 'intel_ring_initialized() must be simple and inline' patch,

[Intel-gfx] [PATCH v2 5/6] drm/i915: HWSP should be unmapped earlier in LRC teardown sequence

In LRC mode, the HWSP is part of the default context object, and therefore does not exist independently. Worse, it doesn't contribute to the refcount on the default context object either. Currently, the default context is deallocated in intel_lr_context_free(), but the HWSP kmapping is not torn

[Intel-gfx] [PATCH v2 0/6] A collection of cleanups

Various things can go wrong during initialisation and teardown, but they usually don't, so the error-handling paths go largely untested. This collection of patches fixes some things I recently noticed. Some might lead to a kernel OOPS, but mostly they're leaks and other inconsistencies. Includes

[Intel-gfx] ✗ Fi.CI.BAT: warning for Gen9 HW whitelist and Preemption WA patches (rev3)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (skl-i5k-2) pass -> DMESG-WARN (ilk-hp8440p)

[Intel-gfx] ✗ Fi.CI.BAT: failure for FBC crtc/fb locking + smaller fixes (rev3)

== Summary == HEAD is now at 8fe9e78 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Applying: drm/i915/fbc: wait for a vblank instead of 50ms when enabling Applying: drm/i915/fbc: extract intel_fbc_can_activate() Applying: drm/i915/fbc: extract intel_fbc_can_enable()

Re: [Intel-gfx] [PATCH] drm/i915: Add DPI FIFO empty status check

On Wed, 09 Dec 2015, Ville Syrjälä wrote: > On Wed, Dec 09, 2015 at 05:05:52PM +0530, Deepak M wrote: >> From: Gaurav K Singh >> >> Before sending TURN ON packet,check the DPI >> FIFO empty status. >> >> v2: Change in commit message >>

[Intel-gfx] [PATCH v4] 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 enable bit in PIPE_CONF register (for Pipe C) 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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Sanitize up DMC/CSR ucode cleanup code

On Tue, Jan 19, 2016 at 03:26:26PM +0200, Imre Deak wrote: > commit ebae38d061df3deffa7c17b030ea14a5216ee55f > Author: Animesh Manna > Date: Wed Oct 28 23:58:55 2015 +0200 > > drm/i915/gen9: csr_init after runtime pm enable > > moved the DMC/CSR initialization

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Sanitize GEM shrinker init and clean-up

On Tue, Jan 19, 2016 at 03:26:28PM +0200, Imre Deak wrote: > Factor out the common GEM shrinker clean-up code and call the shrinker > init function from the same function from where the corresponding > shrinker clean-up function is called. Also add sanity checking to the > shrinker and OOM

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Move allocation of various workqueues earlier during init

On Tue, Jan 19, 2016 at 03:26:30PM +0200, Imre Deak wrote: > Workqueue initalization doesn't depend on any other device specific > resource, so move it close to the beginning, so we don't need to > consider them when thinking about dependencies for other resources. > > Also factor out things to

[Intel-gfx] [PATCH] Fix pointer tests in error-handling paths

In the error-handling paths of i915_gem_do_execbuffer() and intel_crtc_page_flip(), the local pointer-to-request variables were expected to be either valid pointers or NULL. Since 2682708 drm/i915: simplify allocation of driver-internal requests they could also be ERR_PTR() values, so the

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Introduce i915_dbg macro

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (ivb-t430s) bdw-nuci7total:140 pass:131

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

On 19/01/16 19:02, Dave Gordon wrote: > There are a number of places where the driver needs a request, but isn't > working on behalf of any specific user or in a specific context. At > present, we associate them with the per-engine default context. A future > patch will abolish those per-engine

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Y/Yf Tiling Workaround for BXT/SKL

== Summary == CC [M] drivers/gpu/drm/i915/dvo_ch7017.o CC [M] drivers/gpu/drm/i915/dvo_ch7xxx.o CC [M] drivers/gpu/drm/i915/dvo_ivch.o CC [M] drivers/gpu/drm/i915/dvo_ns2501.o CC [M] drivers/gpu/drm/i915/dvo_sil164.o CC [M] drivers/gpu/drm/i915/dvo_tfp410.o CC [M]

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for FBC crtc/fb locking + smaller fixes

On Thu, Jan 21, 2016 at 08:14:34PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-01-19 às 14:50 +, Patchwork escreveu: > > == Summary == > > > > Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly: > > 2016y-01m-19d-13h-31m-46s UTC integration manifest > > > > Test kms_flip: >

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle PipeC fused off on HSW (rev4)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

[Intel-gfx] [PATCH i-g-t 1/4] lib: kms: add crtc_id to igt_pipe_t

Signed-off-by: Lionel Landwerlin --- lib/igt_kms.c | 1 + lib/igt_kms.h | 1 + 2 files changed, 2 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 497118a..f5eef82 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1004,6 +1004,7 @@ void

[Intel-gfx] [PATCH i-g-t 4/4] tests/kms_color: New test for pipe level color management

This test enables testing of : * degamma LUTs * csc matrix * gamma LUTs * legacy gamma LUTs v2: turn assert into require to skip on platform not supporting color management Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1

[Intel-gfx] [PATCH i-g-t 2/4] lib: kms: add helpers for color management properties on pipes

Signed-off-by: Lionel Landwerlin --- lib/igt_kms.c | 74 +++ lib/igt_kms.h | 17 +- 2 files changed, 90 insertions(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index

[Intel-gfx] [PATCH i-g-t 3/4] lib: fb: add igt_paint_color_gradient_range

This is a helper to draw a gradient between 2 colors. Signed-off-by: Lionel Landwerlin --- lib/igt_fb.c | 34 ++ lib/igt_fb.h | 3 +++ 2 files changed, 37 insertions(+) diff --git a/lib/igt_fb.c b/lib/igt_fb.c index

[Intel-gfx] [PATCH i-g-t 0/4] New pipe level color management tests V2

Hi, Quick update here too, we need igt_require and not igt_assert for platforms that do not support color management. Cheers, Lionel Lionel Landwerlin (4): lib: kms: add crtc_id to igt_pipe_t lib: kms: add helpers for color management properties on pipes lib: fb: add

[Intel-gfx] [PATCH] drm/i915: More use of the cached LRC state

From: Tvrtko Ursulin Since: commit 82352e908acd36d7244c75a008c9f27a2ced44d5 Author: Tvrtko Ursulin Date: Fri Jan 15 17:12:45 2016 + drm/i915: Cache LRC state page in the context and: commit

Re: [Intel-gfx] [PATCH] Fix pointer tests in error-handling paths

On Fri, Jan 22, 2016 at 12:19:32PM +, Dave Gordon wrote: > In the error-handling paths of i915_gem_do_execbuffer() and > intel_crtc_page_flip(), the local pointer-to-request variables > were expected to be either valid pointers or NULL. Since > > 2682708 drm/i915: simplify allocation of

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

On Fri, 11 Dec 2015, Rodrigo Vivi wrote: > Unfortunately we don't know all panels and platforms out there and we > found internal prototypes without VBT proper set but where only > link in standby worked well. > > So, before enable PSR by default let's instrument the PSR

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Sanitize i915_get_bridge_dev() error path

On Tue, Jan 19, 2016 at 03:26:27PM +0200, Imre Deak wrote: > Clarify the name of the label on the error path, making it clear what's > being cleaned up. The kmem_cache_destroy() calls are NOPs on the > corresponding error path. > > Signed-off-by: Imre Deak Reviewed-by:

[Intel-gfx] [PATCH] drm/i915: Introduce i915_dbg macro

From: Akash Goel Added a new macro i915_dbg, which is a wrapper over dev_dbg macro. dev_dbg allows use of dynamic debug framework, so offers a number of advantages over DRM_DEBUG to debug user space startup issues. Like provides more fine grain control by allowing to

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Sanitize i915_gem_load() init and clean-up

On Tue, Jan 19, 2016 at 03:26:29PM +0200, Imre Deak wrote: > Factor out common clean-up code for the GEM load time init function. > Also rename i915_gem_load() to i915_gem_load_init() to have a better > match with its new clean-up function. > > No functional change. > > Signed-off-by: Imre Deak

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Move stolen memory initialization earlier during loading

On Tue, Jan 19, 2016 at 03:26:32PM +0200, Imre Deak wrote: > The only device specific dependency of the stolen memory setup is the > MMIO mapping and the stolen memory size. Both are already available in > i915_gtt_init(), so move the stolen initialization to there. The > clean-up code for

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Move MCHBAR setup earlier during init

On Tue, Jan 19, 2016 at 03:26:31PM +0200, Imre Deak wrote: > Move the MCHBAR setup right after the MMIO setup, since the two things > are logically related and the MCHBAR setup code doesn't depend on any > other device specific resource. We'll also need MCHBAR to be ready > earlier in an upcoming

Re: [Intel-gfx] [PATCH] Fix pointer tests in error-handling paths

On 22/01/16 12:19, Dave Gordon wrote: In the error-handling paths of i915_gem_do_execbuffer() and intel_crtc_page_flip(), the local pointer-to-request variables were expected to be either valid pointers or NULL. Since 2682708 drm/i915: simplify allocation of driver-internal requests they

Re: [Intel-gfx] [PATCH 02/20] drm/i915: Generalise common GPU engine reset request/unrequest code

Arun Siluvery writes: > 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

[Intel-gfx] [PATCH 0/6] Pipe level color management V2

Hi, Just a quick update to fix the warnings in the BAT due to missing property type flag. Also prevent GAMMA_MODE register read when committing the crtc state (as reported by Daniel Stone). Cheers, Lionel Lionel Landwerlin (6): drm/i915: Extract out gamma table and CSC to their own file

[Intel-gfx] [PATCH 1/6] drm/i915: Extract out gamma table and CSC to their own file

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/intel_color.c | 174 +++ drivers/gpu/drm/i915/intel_display.c | 163 +++-

[Intel-gfx] [PATCH 3/6] drm/i915: enable CSC for pipe C

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_reg.h | 40 +++- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 2/6] drm: introduce color correction properties

v2: Register LUT size properties as range Signed-off-by: Lionel Landwerlin --- Documentation/DocBook/gpu.tmpl | 50 +- drivers/gpu/drm/drm_atomic.c| 102 +++- drivers/gpu/drm/drm_atomic_helper.c | 10

[Intel-gfx] [PATCH 4/6] drm/i915: enable legacy palette for pipe C

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_reg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 63c4283..46143f8 100644 ---

[Intel-gfx] [PATCH 5/6] drm/i915: Implement color management on bdw/skl/bxt/kbl

v2: do not read GAMMA_MODE register to figure what mode we're in Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.c | 24 ++- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/i915_reg.h | 22 +++

[Intel-gfx] [PATCH 6/6] drm/i915: Implement color management on chv

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.c| 3 + drivers/gpu/drm/i915/i915_reg.h| 40 +++ drivers/gpu/drm/i915/intel_color.c | 139 - 3 files changed, 180 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PATCH] drm/i915: Introduce i915_dbg macro

On 22/01/2016 12:24, akash.g...@intel.com wrote: From: Akash Goel Added a new macro i915_dbg, which is a wrapper over dev_dbg macro. dev_dbg allows use of dynamic debug framework, so offers a number of advantages over DRM_DEBUG to debug user space startup issues. Like

[Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

We are reading at most sizeof(data) bytes, but then data may not contain a terminating '\0', at least in theory, so strstr() may overflow the stack allocated array. Make sure that data always contains at least one '\0'. Signed-off-by: Damien Lespiau --- xf86drm.c | 3

Re: [Intel-gfx] [PATCH] drm/i915: More use of the cached LRC state

On Fri, Jan 22, 2016 at 12:42:47PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Since: > > commit 82352e908acd36d7244c75a008c9f27a2ced44d5 > Author: Tvrtko Ursulin > Date: Fri Jan 15 17:12:45 2016 + > > drm/i915: Cache

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allow i915_gem_object_get_page() on userptr as well (rev2)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) Subgroup basic-flip-vs-modeset:

[Intel-gfx] ✓ Fi.CI.BAT: success for A collection of cleanups

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest bdw-nuci7total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

On Thu, Jan 21, 2016 at 09:43:14PM -0800, Palleti, Avinash Reddy wrote: > Thanks Matt for pointing me to this. > > Vlad, > As Matt mentioned, we are also working on this to get atomic support in > i-g-t. Last week we finalized the design with Matt. I am putting the design > we discussed here

Re: [Intel-gfx] [RFC 06/22] drm/i915/slpc: If using SLPC, do not set frequency

On Wed, Jan 20, 2016 at 06:26:08PM -0800, tom.orou...@intel.com wrote: > From: Tom O'Rourke > > When frequency requests are made by SLPC, host driver > should not attempt to make frequency requests due to > potential conflicts. > > Host-based turbo operations are already

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

Hi, With regards to the additional NULL argument to drmModeSetPlane on Android. Apparently, there was a previous attempt to make a wrapper for it. Would it be possible to upstream that? Devon -Original Message- From: Davies, Devon Sent: Friday, January 22, 2016 3:18 PM To: Zanoni,

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Add support for GuC-based SLPC

On Thu, Jan 21, 2016 at 03:16:42PM -0800, O'Rourke, Tom wrote: > On Thu, Jan 21, 2016 at 01:50:34PM +, Patchwork wrote: > > == Summary == > > > > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: > > 2016y-01m-21d-11h-02m-42s UTC integration manifest > > > > Test

Re: [Intel-gfx] [PATCH 0/6] Pipe level color management

Hi, On 22 January 2016 at 16:21, Daniel Vetter wrote: > On Fri, Jan 22, 2016 at 04:06:15PM +, Lionel Landwerlin wrote: >> On 22/01/16 15:04, Daniel Stone wrote: >> >Now with everything just using split-gamma mode, I'm much happier with >> >how this is looking. I took a look

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

On Fri, Jan 22, 2016 at 05:02:07PM +, Davies, Devon wrote: > Hi, > > With regards to the additional NULL argument to drmModeSetPlane on Android. > > Apparently, there was a previous attempt to make a wrapper for it. > Would it be possible to upstream that? No. Whoever has done that private

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

On Fri, Jan 22, 2016 at 03:18:15PM +, Davies, Devon wrote: > Hi, > > Thanks for the feedback. > > I'll update the commit title. I will also separate this patch into 5 patches. > > For now I want to keep the "ifdef dance" in igt_fbc.c. If we want to split > the file up, that should be a new

Re: [Intel-gfx] [RFC 14/22] drm/i915/slpc: Notification of Display mode change

On Wed, Jan 20, 2016 at 06:26:16PM -0800, tom.orou...@intel.com wrote: > From: Sagar Arun Kamble > > GuC SLPC need to be sent data related to Active pipes, refresh rates, > widi pipes, fullscreen pipes related via host to GuC display mode > change event. > This patch

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

On Fri, Jan 22, 2016 at 05:02:07PM +, Davies, Devon wrote: > Hi, > > With regards to the additional NULL argument to drmModeSetPlane on Android. > > Apparently, there was a previous attempt to make a wrapper for it. > Would it be possible to upstream that? How about fix it in Android with

Re: [Intel-gfx] [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun

Hi Daniel, Thanks for the tip. I just enabled fb.lockless_register_fb=1 and still cannot see any debug messages after the console_lock... :( Regards, C.Palminha On 22-01-2016 07:53, Daniel Vetter wrote: Every new KMS driver writer seems to run into this and wonder how exactly

Re: [Intel-gfx] [RFC 06/22] drm/i915/slpc: If using SLPC, do not set frequency

On Fri, Jan 22, 2016 at 05:53:29PM +0100, Daniel Vetter wrote: > On Wed, Jan 20, 2016 at 06:26:08PM -0800, tom.orou...@intel.com wrote: > > From: Tom O'Rourke > > > > When frequency requests are made by SLPC, host driver > > should not attempt to make frequency requests

Re: [Intel-gfx] [PATCH] drm/i915: Introduce i915_dbg macro

On Fri, Jan 22, 2016 at 12:49:01PM +, Arun Siluvery wrote: > On 22/01/2016 12:24, akash.g...@intel.com wrote: > >From: Akash Goel > > > >Added a new macro i915_dbg, which is a wrapper over dev_dbg macro. > >dev_dbg allows use of dynamic debug framework, so offers a

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev2)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

Re: [Intel-gfx] [PATCH] Fix pointer tests in error-handling paths

On Fri, Jan 22, 2016 at 01:17:44PM +, Tvrtko Ursulin wrote: > > On 22/01/16 13:01, Chris Wilson wrote: > >On Fri, Jan 22, 2016 at 12:19:32PM +, Dave Gordon wrote: > >>In the error-handling paths of i915_gem_do_execbuffer() and > >>intel_crtc_page_flip(), the local pointer-to-request

Re: [Intel-gfx] [PATCH 19/20] drm/i915: drm/i915 changes to simulated hangs

On Fri, Oct 23, 2015 at 02:32:41AM +0100, Tomas Elf wrote: > From: Tim Gore > > Simulated hangs, as used by drv_hangman and some other IGT tests, are not > handled correctly with the new per-engine hang recovery mode. This patch fixes > several issues needed to get them

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: More use of the cached LRC state

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest bdw-nuci7total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6

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

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: [Intel-gfx] [PATCH 19/20] drm/i915: drm/i915 changes to simulated hangs

On 22/01/2016 13:43, Chris Wilson wrote: On Fri, Oct 23, 2015 at 02:32:41AM +0100, Tomas Elf wrote: From: Tim Gore Simulated hangs, as used by drv_hangman and some other IGT tests, are not handled correctly with the new per-engine hang recovery mode. This patch fixes

Re: [Intel-gfx] [PATCH 10/20] drm/i915: Watchdog timeout: DRM kernel interface enablement

On Fri, Oct 23, 2015 at 02:32:32AM +0100, Tomas Elf wrote: > Final enablement patch for GPU hang recovery using watchdog timeout. > Added execbuf flag for watchdog timeout in DRM kernel interface. Usual argument: per-batch or per-context flag? What's the use case being consider that would favour

Re: [Intel-gfx] [PATCH 10/20] drm/i915: Watchdog timeout: DRM kernel interface enablement

On 22/01/2016 13:59, Chris Wilson wrote: On Fri, Oct 23, 2015 at 02:32:32AM +0100, Tomas Elf wrote: Final enablement patch for GPU hang recovery using watchdog timeout. Added execbuf flag for watchdog timeout in DRM kernel interface. Usual argument: per-batch or per-context flag? What's the

Re: [Intel-gfx] [PATCH] Fix pointer tests in error-handling paths

On 22/01/16 13:01, Chris Wilson wrote: On Fri, Jan 22, 2016 at 12:19:32PM +, Dave Gordon wrote: In the error-handling paths of i915_gem_do_execbuffer() and intel_crtc_page_flip(), the local pointer-to-request variables were expected to be either valid pointers or NULL. Since 2682708

[Intel-gfx] [PATCH] drm-intel: Document sob requirements better

Yeah dim apply-patch could probably autofudge this, but it's too close to w/e time for me to figure out how to do that. Noticed since a few folks forgot this when pushing other people's patches. Signed-off-by: Daniel Vetter --- drm-intel.rst | 3 +++ 1 file changed, 3

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Fix premature LRC unpin in GuC mode

On Fri, Jan 22, 2016 at 04:33:18PM +, Tvrtko Ursulin wrote: > I was confused by the current code which does the reset after unpinning: > > ... > i915_gem_reset(dev); > > simulated = dev_priv->gpu_error.stop_rings != 0; > > ret = intel_gpu_reset(dev); > ... > > > What is

Re: [Intel-gfx] [PATCH] drm/fbdev-helper: Explain how to debug console_lock fun

On Fri, Jan 22, 2016 at 11:50:06AM +, Carlos Palminha wrote: > Hi Daniel, > > Thanks for the tip. > I just enabled fb.lockless_register_fb=1 and still cannot see any debug > messages after the console_lock... :( If this works there shouldn't be any console_lock call from initial_config().

Re: [Intel-gfx] [PATCH] drm/i915: Improve handling of overlapping objects

On Thu, Jan 21, 2016 at 05:32:43PM +, Chris Wilson wrote: > The generic interval tree we use to speed up range invalidation is an > augmented rbtree that can report all overlapping intervals for a given > range. Therefore we do not need to degrade to a linear list if we find > overlapping

Re: [Intel-gfx] [PATCH 0/6] Pipe level color management

> -Original Message- > From: Daniel Stone [mailto:dan...@fooishbar.org] > Sent: Friday, January 22, 2016 10:05 AM > To: Lionel Landwerlin > Cc: intel-gfx; Thierry Reding; Deucher, Alexander; dri-devel > Subject: Re: [Intel-gfx] [PATCH 0/6] Pipe level color management > > Hi Lionel, > >

Re: [Intel-gfx] [PATCH 0/6] Pipe level color management

On Fri, Jan 22, 2016 at 04:06:15PM +, Lionel Landwerlin wrote: > On 22/01/16 15:04, Daniel Stone wrote: > >Hi Lionel, > > > >On 21 January 2016 at 15:03, Lionel Landwerlin > > wrote: > >>Hi, > >> > >>This serie introduces pipe level color management through a set

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrote: > From: Tom O'Rourke > > SLPC (Single Loop Power Controller) is a replacement for > some host-based power management features. The SLPC > implemenation runs in firmware on GuC. > > This series is a

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

On Thu, 21 Jan 2016, "Adebisi, YetundeX" wrote: > Hi, > > I got this message in reply to this patch > (https://patchwork.freedesktop.org/patch/60736/). > > It looks like most of the warnings are related to 'PWM1 enabled' > warnings that happen when the hardware is

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Extend LRC pinning to cover GPU context writeback (rev7)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

Re: [Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

On Fri, Jan 22, 2016 at 12:51:23PM +, Damien Lespiau wrote: > We are reading at most sizeof(data) bytes, but then data may not contain > a terminating '\0', at least in theory, so strstr() may overflow the > stack allocated array. > > Make sure that data always contains at least one '\0'. >

Re: [Intel-gfx] [PATCH 1/4] drm/i915: handle teardown of HWSP when context is freed

On 22/01/16 10:28, Mika Kuoppala wrote: Dave Gordon writes: Existing code did a kunmap() on the wrong page, and didn't account for the fact that the HWSP and the default context are different offsets within the same GEM object. Just to note here that usually we

Re: [Intel-gfx] [PATCH 0/6] Pipe level color management

Hi Lionel, On 21 January 2016 at 15:03, Lionel Landwerlin wrote: > Hi, > > This serie introduces pipe level color management through a set of properties > attached to the CRTC. It also provides an implementation for some Intel > platforms. > > This serie is based

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: handle teardown of HWSP when context is freed

On 22/01/16 07:42, Patchwork wrote: == Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a-frame-sequence: pass -> DMESG-WARN

Re: [Intel-gfx] [PATCH v2] drm/i915: Support to enable TRTT on GEN9

Hi Akash, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160122] [cannot apply to v4.4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/akash-goel-intel

Re: [Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

On Fri, Jan 22, 2016 at 04:48:05PM +0200, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 12:51:23PM +, Damien Lespiau wrote: > > We are reading at most sizeof(data) bytes, but then data may not contain > > a terminating '\0', at least in theory, so strstr() may overflow the > > stack allocated

  1   2   >