[Intel-gfx] ✗ Fi.CI.BAT: failure for PSR link standby x link force off changes.

== Summary == Series 2991v1 PSR link standby x link force off changes. 2016-02-01T18:49:22.338593 http://patchwork.freedesktop.org/api/1.0/series/2991/revisions/1/mbox/ Applying: drm/i915: PSR simplify port and link standby checks. Using index info to reconstruct a base tree... M drivers/gp

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

Hello all, > On 01 Feb 2016, at 23:49, Lukas Wunner wrote: > > Hi, > >> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: >> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > This series hasn't seen any reviews or acks unfortunately. > Any takers? > > Mergi

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations

On Mon, Feb 01, 2016 at 04:22:22PM +0200, Ville Syrjälä wrote: > On Mon, Feb 01, 2016 at 01:26:14AM -0800, Matt Roper wrote: > > Due to our lack of two-step watermark programming, our driver has > > historically pretended that the cursor plane is always on for the > > purpose of watermark calculati

[Intel-gfx] SKL GT4e can not hit the max frequency

We have two kinds of GT4e machines: One has the maximum frequency of 800MHZ and the actual freq only hits 600MHZ. The other has maximum frequency of 950MHZ and the actual freq only hits only hits 800MHZ. Even if the gt_min_freq_mhz is set to the same value as gt_max_freq_mhz, the actual freq cann

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

On 2 February 2016 at 11:10, Dave Airlie wrote: > On 2 February 2016 at 08:49, Lukas Wunner wrote: >> Hi, >> >> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: >>> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. >> >> This series hasn't seen any reviews or acks

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

On 2 February 2016 at 08:49, Lukas Wunner wrote: > Hi, > > On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: >> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > This series hasn't seen any reviews or acks unfortunately. > Any takers? Has the tree this depends

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

Hi, On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. This series hasn't seen any reviews or acks unfortunately. Any takers? Merging this would allow fdo #61115 to be closed (currently assigned to intel-gfx). FW

Re: [Intel-gfx] [PATCH 2/5] drm/i915/error: capture ringbuffer pointed to by START

On 29/01/2016 11:47, Chris Wilson wrote: On Thu, Jan 28, 2016 at 07:01:21PM +, Arun Siluvery wrote: From: Dave Gordon For: VIZ-2021 Signed-off-by: Dave Gordon What information does this actually provide over and above the hw is not executing the ring we expect? How have you used this, h

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Instrument PSR parameter for debuging with link standby x link off.

Em Seg, 2016-02-01 às 10:49 -0800, Rodrigo Vivi escreveu: > 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 parameter

[Intel-gfx] [PATCH 1/3] drm/i915: PSR simplify port and link standby checks.

Current code not just block link_standby for non DDI platforms but also block PSR from work on other ports B/C/D/E. So, besides change any behaviour let's just fix the mess a bit here and reuse HSW check to block the other ports and reduce the second if only to link stadnby request. Cc: Paulo Zan

[Intel-gfx] [PATCH 3/3] drm/i915: Instrument PSR parameter for debuging with link standby x link off.

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 parameter in a way that we can identify different panels out there that might

[Intel-gfx] [PATCH 2/3] drm/i915: Add PSR main link standby support back

Link standby support has been deprecated with 'commit 89251b177 ("drm/i915: PSR: deprecate link_standby support for core platforms.")' The reason for that is that main link in full off offers more power savings and on HSW and BDW implementations on source side had known bugs with link standby. Ho

[Intel-gfx] [PATCH 0/3] PSR link standby x link force off changes.

Durring last attempt to enable PSR we found one Skylake that required link standby mode and on Skylake we don't have the link standby issues we faced on HSW and BDW. So let's put link standby support back and instrument i915.enable_psr to force link standby and link force off for debug purposes. M

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

On Mon, Feb 01, 2016 at 05:44:42PM +, Tvrtko Ursulin wrote: > > On 01/02/16 17:16, Zanoni, Paulo R wrote: > > Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: > >> On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: > >>> The interesting thing is that if we don't do this, w

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

On 01/02/16 17:16, Zanoni, Paulo R wrote: Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: The interesting thing is that if we don't do this, we still get a Y tiled framebuffer, but there won't be a fence around it, which

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

On Mon, Feb 01, 2016 at 05:16:25PM +, Zanoni, Paulo R wrote: > Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: > > On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: > > > The interesting thing is that if we don't do this, we still get a > > > Y tiled framebuffer, but ther

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: > On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: > > The interesting thing is that if we don't do this, we still get a > > Y tiled framebuffer, but there won't be a fence around it, which > > makes > > the GTT mmaps less inte

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use atomic state to obtain load detection crtc.

On Mon, Feb 01, 2016 at 02:43:57PM +0100, Maarten Lankhorst wrote: > Instead of restoring dpms and a flag for whether a temp fb is allocated > duplicate > the old plane_state and crtc_state, and restore the members we potentially > touched. > > Signed-off-by: Maarten Lankhorst > --- > drivers/

Re: [Intel-gfx] [PATCH] drm/i915/skl: Fix DMC load on Skylake J0 and K0

On Mon, 2016-02-01 at 08:01 -0800, Mat Martineau wrote: > Rodrigo and Daniel - > > On Thu, 28 Jan 2016, Vivi, Rodrigo wrote: > > > > > Reviewed-by: Rodrigo Vivi > > > > I've checked with DMC folks that DMC 1.23 that we are currently > > using > > and the following releases support J0 and K0.

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Do not wait atomically for display clocks

On Mon, Feb 01, 2016 at 04:27:47PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like this code does not need to wait atomically since it > otherwise takes the mutex. But did it rely on on the requested > 1us wait actually being up to 1ms? Bspec says 1 us, so it *should* be fine.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Add wait_for_us

== Summary == Series 2990v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/2990/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-edid: pass -> SKIP (snb-dellxps) Test kms_pipe_crc_basic: Subgroup suspend-read

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations

I can confirm that the proposed patch fixes the flicker problem on my system (openSuse Factory kernel 4.4.0-2-default), even though I had to slightly modify it to apply it to the current openSuse Factory sources). On 02/01/2016 02:22 PM, Ville Syrjälä wrote: On Mon, Feb 01, 2016 at 01:26:14A

[Intel-gfx] [PATCH 4/6] drm/i915/lrc: Do not wait atomically when stopping engines

From: Tvrtko Ursulin I do not see that this needs to be done atomically and up to one second is quite a long time to busy loop. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.

[Intel-gfx] [PATCH 3/6] drm/i915/guc: Do not wait for firmware load atomically

From: Tvrtko Ursulin It does not look like this code needs to wait atomically? Higher in the call chain it calls the GEM API and I do not see that the section is under any spin locks or such. Signed-off-by: Tvrtko Ursulin Cc: Alex Dai --- drivers/gpu/drm/i915/intel_guc_loader.c | 6 +++--- 1

[Intel-gfx] [PATCH 2/6] drm/i915: Do not wait atomically for display clocks

From: Tvrtko Ursulin Looks like this code does not need to wait atomically since it otherwise takes the mutex. But did it rely on on the requested 1us wait actually being up to 1ms? Signed-off-by: Tvrtko Ursulin Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 8 1 file c

Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.99.917

Bump for February When is Intel going to release stable xorg driver? Maybe they are going to develop driver only for internal purposes and this is the main cause of not releasing stable driver for distributions and end users? ___ Intel-gfx mailing list I

[Intel-gfx] [PATCH 6/6] drm/i915: Do not lie about atomic wait granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so micro-second granularity is really supported and not just in the name of the macro. v2: * Warn when used fr

[Intel-gfx] [PATCH 1/6] drm/i915: Add wait_for_us

From: Tvrtko Ursulin This is for callers who want micro-second precision but are not waiting from the atomic context. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_dp.c | 3 +-- drivers/gpu/drm/i915/intel_drv.h | 9 + drivers/gpu/drm/i915/intel_psr.c | 2 +- 3 files cha

[Intel-gfx] [PATCH 5/6] drm/i915: Kconfig for extra driver debugging

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 051eab33e4c7..7636bf918d97 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/driv

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use atomic state to obtain load detection crtc.

On Mon, Feb 01, 2016 at 02:43:57PM +0100, Maarten Lankhorst wrote: > Instead of restoring dpms and a flag for whether a temp fb is allocated > duplicate > the old plane_state and crtc_state, and restore the members we potentially > touched. > > Signed-off-by: Maarten Lankhorst > --- > drivers/

Re: [Intel-gfx] [PATCH] drm/i915/skl: Fix DMC load on Skylake J0 and K0

Rodrigo and Daniel - On Thu, 28 Jan 2016, Vivi, Rodrigo wrote: Reviewed-by: Rodrigo Vivi I've checked with DMC folks that DMC 1.23 that we are currently using and the following releases support J0 and K0. With this patch we are covering all SKL steppings we know so far, but besides being c

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

== Summary == Series 2720v3 Pipe level color management http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/3/mbox/ Test gem_sync: Subgroup basic-blt: pass -> DMESG-FAIL (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a:

[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 dd4ca45..22996d5 100644 --- a/lib/igt_kms.c ++

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

Hi, This series enables testing pipe level color management using kernel patches from this serie : https://patchwork.freedesktop.org/series/2720/ Most of the tests use pipe CRCs to check the results by comparing the output with the expected output drawn using cairo. Cheers, Lionel Lionel Land

[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 v3: add invalid blob ids tests Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources |

[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 5f23136..bbafcd9 100644 --- a/lib/igt_fb.c +++

[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 90c8da7..dd4ca45 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1047,6 +1047,7 @@ void igt_display_init(igt_display_t *display, int

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

Patch based on a previous serie by Shashank Sharma. 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 insertio

Re: [Intel-gfx] Linux 4.5-rc2

Gerd Hoffmann [2016-02-01 15:18]: > n Mo, 2016-02-01 at 14:19 +0100, Harald Arnesen wrote: >> I still get the blank screen than Bjørn Mork reported and bisected when >> 4.5-rc1 was released. > > Fix[1] is already queued by Jani Nikula, I suspect it simply missed the > boat because there was no drm

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

Patch based on a previous serie by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM_MATRIX Signed-off-by: Lionel Landwerlin --

[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 65e32a3..683e6b5 100644 --- a/drivers/gpu/drm

[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 683e6b5..fdae374 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i9

[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 +++- drivers/gpu/drm/i915/intel_drv.h | 10 ++ 4 files ch

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

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 of a previous set of patches by Shashank Sharma and takes into account comments by Daniel Stone & Daniel Vetter. Che

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

Patch based on a previous serie by Shashank Sharma. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used Signed-off-by: Lionel Landwerlin --- Documentation/DocBook/gpu.tmpl | 58

Re: [Intel-gfx] [PATCH] drm/i915: Do not lie about atomic wait granularity

On 01/02/16 14:15, Tvrtko Ursulin wrote: On 01/02/16 13:30, Chris Wilson wrote: On Mon, Feb 01, 2016 at 01:17:35PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small

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

On Fri, Jan 22, 2016 at 01:28:45PM +0200, Gabriel Feceoru wrote: > 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 ref

[Intel-gfx] [PATCH i-g-t] tests/gem_exec_params: test all valid execution flags

From: Daniele Ceraolo Spurio The control subtest has been extended to check the execution flags for all the rings that are present in the HW. Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio --- tests/gem_exec_params.c | 39 --- 1 file changed, 32 ins

Re: [Intel-gfx] Linux 4.5-rc2

On Mo, 2016-02-01 at 14:19 +0100, Harald Arnesen wrote: > I still get the blank screen than Bjørn Mork reported and bisected when > 4.5-rc1 was released. > > Reverting this commit fixes it: > > HEAD is now at 39bfcd5235e0 drm/i915: more virtual south bridge detection > 39bfcd5235e07e95ad3e70eab8e

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations

On Mon, Feb 01, 2016 at 01:26:14AM -0800, Matt Roper wrote: > Due to our lack of two-step watermark programming, our driver has > historically pretended that the cursor plane is always on for the > purpose of watermark calculations; this helps avoid serious flickering > when the cursor turns off/on

Re: [Intel-gfx] [PATCH] drm/i915: Do not lie about atomic wait granularity

On 01/02/16 13:30, Chris Wilson wrote: On Mon, Feb 01, 2016 at 01:17:35PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so mic

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

On 27/01/16 16:57, Chris Wilson wrote: Currently emit-request starts writing to the ring and reserves space for a workaround to be emitted later whilst submitting the request. It is easier to read if the caller only allocates sufficient space for its access (then the reader can quickly verify tha

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Do not lie about atomic wait granularity

== Summary == Series 2979v1 drm/i915: Do not lie about atomic wait granularity http://patchwork.freedesktop.org/api/1.0/series/2979/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-c: pass -> DMESG-WARN (skl-i5k-2) Subgroup suspend-read-

[Intel-gfx] [PATCH 6/6] drm/i915: Use atomic state in intel_fb_initial_config.

This is another step in removing legacy state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_fbdev.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 09840f4380f

[Intel-gfx] [IGT PATCH 5/6] kms_force_connector_basic: Add force-load-detect test

Signed-off-by: Maarten Lankhorst --- diff --git a/tests/kms_force_connector_basic.c b/tests/kms_force_connector_basic.c index bd80caeffd82..f827d0008f7b 100644 --- a/tests/kms_force_connector_basic.c +++ b/tests/kms_force_connector_basic.c @@ -52,6 +52,8 @@ static void reset_connectors(void)

[Intel-gfx] [PATCH 4/6] drm/i915: Use correct dpms for intel_enable_crt.

With the conversion to atomic only on/off are still supported. The rest is mapped to one of those, and when enable is called DPMS_ON should be true. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/driver

[Intel-gfx] [PATCH 1/6] drm/i915: Use atomic state to obtain load detection crtc.

Instead of restoring dpms and a flag for whether a temp fb is allocated duplicate the old plane_state and crtc_state, and restore the members we potentially touched. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 128 --- drivers/gpu

[Intel-gfx] [PATCH 0/6] Use more atomic state in i915.

Use atomic state for load detection, stop use of obsolete connector->dpms and use atomic in intel_fb_initial_config. Maarten Lankhorst (6): drm/i915: Use atomic state to obtain load detection crtc. drm/i915: Use atomic state for load detect in crt. drm/i915: Use atomic state in tv load detec

[Intel-gfx] [PATCH 2/6] drm/i915: Use atomic state in crt load detection.

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 9c89df1af036..8b37bfa6bbb3 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/

[Intel-gfx] [PATCH 3/6] drm/i915: Use atomic state in tv load detection.

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_tv.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index 948cbff6c62e..643f52184d2f 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Keep the per-object list of VMAs under control

On Mon, Feb 01, 2016 at 01:29:16PM +, Tvrtko Ursulin wrote: > > On 01/02/16 11:12, Chris Wilson wrote: > >On Mon, Feb 01, 2016 at 11:00:08AM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Where objects are shared across contexts and heavy rendering > >>is in progress, execlist

[Intel-gfx] [PATCH v3] drm/i915: add WaIncreaseDefaultTLBEntries

From: Tim Gore WaIncreaseDefaultTLBEntries increases the number of TLB entries available for GPGPU workloads and gives significant ( > 10% ) performance gain for some OCL benchmarks. Put this in a new function that can be a place for workarounds that are GT related but not required per ring. This

Re: [Intel-gfx] [PATCH] drm/i915: Do not lie about atomic wait granularity

On Mon, Feb 01, 2016 at 01:17:35PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Currently the wait_for_atomic_us only allows for a millisecond > granularity which is not nice towards callers requesting small > micro-second waits. > > Re-implement it so micro-second granularity is real

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Keep the per-object list of VMAs under control

On 01/02/16 11:12, Chris Wilson wrote: On Mon, Feb 01, 2016 at 11:00:08AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Where objects are shared across contexts and heavy rendering is in progress, execlist retired request queue will grow unbound until the GPU is idle enough for the retire

[Intel-gfx] [PATCHv2 1/4] drm/i915/dp: Export enable/disable_shared_dpll methods

This patch exports the intel_{enable/disable}_shared_dpll methods so that they can be called from other files also. Subsequent patches need to call this from intel_ddi.c Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 f

[Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a generic function

Looping over the crtc list and finding an unused crtc has users other than load_detect(). Hence move it to a common function so that we can re-use the logic. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_display.c | 37 ++-- drivers/gpu/drm/i915/intel_

[Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel can support more lanes. To address these sce

[Intel-gfx] [PATCHv2 3/4] drm/i915/dp: Use legacy get_crtc_encoder in non-atomic paths

This patch makes intel_crtc_get_new_crtc_encoder use get_crtc_encoder when called from non-atomic paths. This helps when intel_get_shared_dpll is called from non-atomic context. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_ddi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a

[Intel-gfx] [PATCHv2 0/4] Add USB typeC based DP support for BXT platform

This patch series adds upfront link training support to enable USB type C based DP on BXT platform. To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes

Re: [Intel-gfx] Linux 4.5-rc2

I still get the blank screen than Bjørn Mork reported and bisected when 4.5-rc1 was released. Reverting this commit fixes it: HEAD is now at 39bfcd5235e0 drm/i915: more virtual south bridge detection 39bfcd5235e07e95ad3e70eab8e0b85db181de9e is the first bad commit commit 39bfcd5235e07e95ad3e70eab

[Intel-gfx] [PATCH] drm/i915: Do not lie about atomic wait granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so micro-second granularity is really supported and not just in the name of the macro. Signed-off-by: Tvrtko Urs

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] > > "Sarvela, Tomi P" writes: > > > > In the result box there is no SKL-I5K column at all. You're looking at HSW- > GT2? > > > > Yes I was looking at wrong column. My bad. I can see that this might be confusing. Reason why it looks l

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

"Sarvela, Tomi P" writes: >> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] >> >> Ok. Then the rendering of the Patchwork_1328 report is somehow wrong as >> in that picture the HANG box is in the nightly base column. > > In the result box there is no SKL-I5K column at all. You're loo

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] > > Ok. Then the rendering of the Patchwork_1328 report is somehow wrong as > in that picture the HANG box is in the nightly base column. In the result box there is no SKL-I5K column at all. You're looking at HSW-GT2? Tomi __

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

"Sarvela, Tomi P" writes: >> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] >> >> Patchwork writes: >> >> > Series 2919v2 drm/i915/skl: Add missing SKL GT3 id >> > http://patchwork.freedesktop.org/api/1.0/series/2919/revisions/2/mbox/ >> > >> > Test kms_pipe_crc_basic: >> >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

== Summary == Series 2978v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/2978/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: incomplete -> PASS (hsw-gt2) Subgroup suspend-read-crc-pipe-c:

[Intel-gfx] [PATCH 3/5] drm/i915: Reorganizing intel_dp_check_link_status

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 halves. First intel_dp_short_pulse() is called, which will be entry point and

[Intel-gfx] [PATCH 4/5] drm/i915: Save sink_count for tracking changes to it and read sink_count dpcd always

This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the

[Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count change

This patch checks for changes in sink count between short pulse hpds and forces full detect when there is a change. This will allow both detection of hotplug and unplug of panels through dongles that give only short pulse for such events. v2: changed variable type from u8 to bool (Jani) retur

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

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 etc done in intel_dp_detect() to a new function intel_dp_long_pulse(). Note

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

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 dpcd operations. So this patch tries to solve both these by bringing all DPCD

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Sanity check DP AUX message buffer and size

On ma, 2016-02-01 at 11:42 +0530, Thulasimani, Sivakumar wrote: > > On 1/29/2016 6:22 PM, Imre Deak wrote: > > While we are calling intel_dp_aux_transfer() with msg->size=0 > > whenever > > msg->buffer is NULL, passing NULL to memcpy() is undefined > > according to > > the ISO C standard. I haven'

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com] > > Patchwork writes: > > > Series 2919v2 drm/i915/skl: Add missing SKL GT3 id > > http://patchwork.freedesktop.org/api/1.0/series/2919/revisions/2/mbox/ > > > > Test kms_pipe_crc_basic: > > Subgroup suspend-read-crc-pipe-a: > >

Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Add missing SKL ids

Michał Winiarski writes: > Used by production devices: > Intel(R) HD Graphics 510 (Skylake GT1) > Intel(R) Iris Graphics 540 (Skylake GT3e) > Intel(R) Iris Graphics 550 (Skylake GT3e) > > v2: More ids > > Cc: Mika Kuoppala > Signed-off-by: Michał Winiarski Reviewed-by: Mika Kuoppal

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Add missing SKL GT3 id (rev2)

Patchwork writes: > == Summary == > > Series 2919v2 drm/i915/skl: Add missing SKL GT3 id > http://patchwork.freedesktop.org/api/1.0/series/2919/revisions/2/mbox/ > > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-a: > incomplete -> PASS (hsw-gt2) >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] dmr/i915: Use appropriate spinlock flavour

== Summary == Series 2977v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/2977/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) bdw-ultratotal:159 pass:147 dwarn:0 d

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Keep the per-object list of VMAs under control

On Mon, Feb 01, 2016 at 11:00:08AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Where objects are shared across contexts and heavy rendering > is in progress, execlist retired request queue will grow > unbound until the GPU is idle enough for the retire worker > to run and call intel_e

[Intel-gfx] [PATCH 1/2] dmr/i915: Use appropriate spinlock flavour

From: Tvrtko Ursulin We know this never runs from interrupt context so don't need to use the flags variant. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/

[Intel-gfx] [PATCH 2/2] drm/i915: Keep the per-object list of VMAs under control

From: Tvrtko Ursulin Where objects are shared across contexts and heavy rendering is in progress, execlist retired request queue will grow unbound until the GPU is idle enough for the retire worker to run and call intel_execlists_retire_requests. With some workloads, like for example gem_close_r

Re: [Intel-gfx] [PATCH] drm/i915/bxt: update list of PCIIDs

On su, 2016-01-31 at 16:20 -0800, Matt Roper wrote: > On Thu, Jan 28, 2016 at 04:04:12PM +0200, Imre Deak wrote: > > Add PCIIDs for new versions of the SOC, based on BSpec. Also add > > the > > name of the versions as code comment where this is available. The > > new > > versions don't have any cha

Re: [Intel-gfx] Fwd: [linux] drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2) (43d59ed)

On Sat, Jan 30, 2016 at 07:50:03PM -0800, Daniel Vetter wrote: > It's a github comment so pretty hopeless to follow up with the reporter, > but it sounds like we have a culprit for the ilk wm issues/fifo underruns. > -Daniel I think this is the flickering regression that we expected to come back w

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Pretend cursor is always on for ILK-style WM calculations

== Summary == Series 2975v1 drm/i915: Pretend cursor is always on for ILK-style WM calculations http://patchwork.freedesktop.org/api/1.0/series/2975/revisions/1/mbox/ Test drv_module_reload_basic: pass -> DMESG-WARN (ilk-hp8440p) Test kms_flip: Subgroup basic-flip-v

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

On 30/01/16 11:28, Chris Wilson wrote: On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote: On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote: 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

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915: tidy up initialisation failure paths (legacy)

On 30/01/16 10:50, Chris Wilson wrote: On Fri, Jan 29, 2016 at 07:19:26PM +, Dave Gordon wrote: 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.

[Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations

Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different screen)

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

On Mon, 2016-02-01 at 11:50 +0530, Thulasimani, Sivakumar wrote: > > On 1/29/2016 5:33 PM, Ander Conselvan De Oliveira wrote: > > On Fri, 2016-01-29 at 14:31 +0530, Shubhangi Shrivastava wrote: > > > On Tuesday 26 January 2016 06:52 PM, Ander Conselvan De Oliveira wrote: > > > > On Tue, 2016-01-19

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: don't deactivate FBC at skylake_disable_primary_plane

== Summary == Series 2935v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/2935/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test kms_pipe_crc_basic: Subgroup suspend-r

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

== Summary == Series 2932v1 A collection of cleanups, version 4 http://patchwork.freedesktop.org/api/1.0/series/2932/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: incomplete -> PASS (hsw-gt2) Subgroup suspend-read-crc-pipe-c:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v2) (rev2)

== Summary == Series 2679v2 drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v2) 2016-01-29T18:01:25.652420 http://patchwork.freedesktop.org/api/1.0/series/2679/revisions/2/mbox/ Applying: drm/i915: Rename the rotated gtt view member to 'rotated' Using index in

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 (rev3)

== Summary == Series 2497v3 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/2497/revisions/3/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: incomplete -> PASS (hsw-gt2) Subgroup suspend-read-crc-pipe-c:

  1   2   >