[Intel-gfx] [PATCH 07/15] drm/i915: Add vlv_dport_to_phy()

From: Ville Syrjälä Add vlv_dport_to_phy() and fix up the return values of vlv_dport_to_channel() and vlv_pipe_to_channel() to use the appropriate enums. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_drv.h | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH 15/15] drm/i915: Add CHV PHY LDO power sanity checks

From: Ville Syrjälä At various points when changing the DPIO lane/phy power states, construct an expected value of the DISPLAY_PHY_STATUS register and compare it with the real thing. To construct the expected value we look at our shadow PHY_CONTROL register value (which should match what we've j

[Intel-gfx] [PATCH 01/15] drm/i915: Always program m2 fractional value on CHV

From: Ville Syrjälä When fractional m2 divider isn't used on CHV the fractional part is ignore by the hardware. Despite that, program the fractional value (0 in this case) to the hardware register just to keep things a bit more consistent. Might at least make register dumps a bit less confusing w

[Intel-gfx] [PATCH 02/15] drm/i915: Always program unique transition scale for CHV

From: Ville Syrjälä The docs give you the impression that the unique transition scale value shouldn't matter when unique transition scale is enabled. But as Imre found on BXT (and I verfied also on BSW) the value does matter. So from now on just program the same value 0x9a always. Cc: Imre Deak

[Intel-gfx] [PATCH 08/15] drm/i915: Implement PHY lane power gating for CHV

From: Ville Syrjälä Powergate the PHY lanes when they're not needed. For HDMI all four lanes are needed always, but for DP we can enable only the needed lanes. To power down the unused lanes we use some power down override bits in the DISPLAY_PHY_CONTROL register. Without the overrides it appears

[Intel-gfx] [PATCH 10/15] drm/i915: Force common lane on for the PPS kick on CHV

From: Ville Syrjälä With DPIO powergating active the DPLL can't be accessed unless something else is keeping the common lane in the channel on. That means the PPS kick procedure could fail to enable the PLL. Power up some data lanes to force the common lane to power up so that the PLL can be ena

[Intel-gfx] [PATCH 12/15] drm/i915: Force CL2 off in CHV x1 PHY

From: Ville Syrjälä We can choose to leave the display PHY CL2 powerdown up to some hardware signals, or we can force it. The BXT code forces the nonexistent CL2 in the x1 PHY to power down. Follow suit on CHV. Maybe it can still save some extra power by disabling some extra logic in CL1, or some

[Intel-gfx] [PATCH 09/15] drm/i915: Trick CL2 into life on CHV when using pipe B with port B

From: Ville Syrjälä Normmally the common lane in a PHY channel gets powered up when some of the data lanes get powered up. But when we're driving port B with pipe B we don't want to enabled any of the data lanes, and just want the DPLL in the common lane to be active. To make that happens we hav

[Intel-gfx] [PATCH 13/15] drm/i915: Clean up CHV lane soft reset programming

From: Ville Syrjälä Currently we relesar the lane soft reset before lane stagger settings have been programmed. I believe that means we don't actually do lane staggering. So move the soft reset deassert to happen after lane staggering has been programmed. The one confusing thing in this is that

[Intel-gfx] [PATCH 14/15] drm/i915: Add some CHV DPIO lane power state asserts

From: Ville Syrjälä Add some checks that the state of the DPIO lanes is more or less what we expect based on the overrides. The hardware only provides two bits per channel indicating whether all or some of the lanes are powered down, so we can't do an exact check. Additionally, CL2 powering dow

[Intel-gfx] [PATCH 0/6] More small FBC fixes

From: Paulo Zanoni Serve these while the others are still baking. Paulo Zanoni (6): drm/i915: make sure we're not changing the FBC CFB with FBC enabled drm/i915: fix the FBC work allocation failure path drm/i915: fix FBC for cases where crtc->base.y is non-zero drm/i915: set ILK_DPFC_FEN

[Intel-gfx] [PATCH 1/6] drm/i915: make sure we're not changing the FBC CFB with FBC enabled

From: Paulo Zanoni We used to have this bug in the past, but now that we properly track the size of the CFB, we don't have it anymore. Still, add the WARN just to make sure we don't go back to the bad state. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 2 ++ 1 file change

[Intel-gfx] [PATCH 2/6] drm/i915: fix the FBC work allocation failure path

From: Paulo Zanoni We were forgetting to set fbc.crtc, fbc.fb_id and fbc.y when the kzalloc call failed. Luckily, this is not a very common case, I hope. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 27 +-- 1 file changed, 17 insertions(+), 10 dele

[Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB

From: Paulo Zanoni The doc is pretty clear that this register should be set to 0 on SNB. We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --gi

[Intel-gfx] [PATCH 3/6] drm/i915: fix FBC for cases where crtc->base.y is non-zero

From: Paulo Zanoni I only tested this on BDW, but since the register description is the same ever since gen4, let's assume that all gens take the same register format. If that's not true, then hopefully someone will bisect a bug to this patch and we'll fix it. Notice that the wrong fence offset

[Intel-gfx] [PATCH 5/6] drm/i915: check for the supported strides on HSW+ FBC

From: Paulo Zanoni I could only find the restrictions for HSW+, but I think it's safe to assume that the older platforms also can't support the configurations HSW can't support. The older platforms probably have additional restrictions, so we need to figure out those and implement them later. Let

[Intel-gfx] [PATCH 6/6] drm/i915: try a little harder to find an FBC CRTC

From: Paulo Zanoni Keep searching in case the candidate has a NULL primary fb. This is only relevant for the platforms that don't have the pipe_a_only restriction. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff

[Intel-gfx] [PATCH 1/3] drm/i915: intel_frontbuffer_flush can now be static

From: Paulo Zanoni So make it static. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_drv.h | 3 --- drivers/gpu/drm/i915/intel_frontbuffer.c | 6 +++--- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/in

[Intel-gfx] [PATCH 3/3] drm/i915: fix intel_frontbuffer_flip documentation

From: Paulo Zanoni Reported by the kbuild test robot. Regression introduced by: commit fdbff9282c0f5f61ffc87d57461b04d943250910 Author: Daniel Vetter Date: Thu Jun 18 11:23:24 2015 +0200 drm/i915: Clear fb_tracking.busy_bits also for synchronous flips (I reviewed this commit, so it's als

[Intel-gfx] [PATCH 2/3] drm/i915: fix intel_fb_obj_flush documentation

From: Paulo Zanoni Reported by the kbuild test robot. Regression introduced by: commit de152b627eb3018de91ec5c5a50b38e17d80a88b Author: Rodrigo Vivi Date: Tue Jul 7 16:28:51 2015 -0700 drm/i915: Add origin to frontbuffer tracking flush (I reviewed this commit, so it's also my fault) Sig

Re: [Intel-gfx] [PATCH] drm/i915: Don't clear all watermarks when updating.

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6753 -Summary- Platform Delta drm-intel-nightly Series Applied ILK

Re: [Intel-gfx] [PATCH 2/6] drm/i915: fix the FBC work allocation failure path

On Wed, Jul 08, 2015 at 05:58:55PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > We were forgetting to set fbc.crtc, fbc.fb_id and fbc.y when the > kzalloc call failed. Luckily, this is not a very common case, I hope. That did not prepare me for the patch that lies ahead. "Always update t

[Intel-gfx] [PATCH] drm/i915: PSR: Flush means invalidate + flush

Since flush actually means invalidate + flush we need to force psr exit on PSR flush. On Core platforms there is no way to disable hw tracking and do the pure sw tracking so we simulate it by fully disable psr and reschedule a enable back. So a good idea is to minimize sequential disable/enable in

[Intel-gfx] [PATCH] drm/i915: dirty fb operation flushsing frontbuffer

Let's do a frontbuffer flush on dirty fb. To be used for DIRTYFB drm ioctl. This patch solves the biggest PSR known issue, that is missed screen updates during boot, mainly when there is a splash screen involved like Plymouth. Previously PSR was being invalidated by fbdev and Plymounth was taking

[Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer

fbdev_set_par is called when fbcon is taking over control. In the past frontbuffer was being invalidated on set_to_gtt_domain, but it moved to set_domain fixing that case, but left this behind. Commit that changed this fixing set_domain case was: commit 031b698a77a70a6c394568034437b5486a44e868 Au

[Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to invalidate frontbuffer

This fbdev restore mode was another corner case that was now calling frontbuffer flip and flush and making we miss screen updates with PSR enabled. So let's also add the invalidate hack here while we don't have a reliable dirty fbdev op. v2: As pointed by Paulo: removed seg fault risk, used fb_he

Re: [Intel-gfx] [PATCH 2/2] drm/i915: remove unused has_dma_mapping flag

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6754 -Summary- Platform Delta drm-intel-nightly Series Applied ILK

[Intel-gfx] Glamor support in intel drivers

Hi folks, I emailed the mailing list before and Chris Wilson said that (or at least seemed to suggest) GLAMOR support is independent of xf86-video-intel drivers. However, my experience seemed to suggest otherwise. If I just enable Glamor in Xorg-server, the intel driver seemed to ignore the Gl

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes trees

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commits: 63fef06ada94 ("drm/i915: Check crtc->active in intel_crtc_disable_planes") dec4f799d0a4 ("drm/i915: Use crtc_state->active in primary check_plane func") from th

[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/i915_gem_gtt.c between commit: 00245266b4be ("drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure path") from Linus' tree and commit: 567047be2a7e ("drm/i915/gtt: Use macros to acces

[Intel-gfx] New GTPin kit (5923)

GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing system for GT-Pin on Linux, we now have aligned kit release regularly. Please check wiki page for details and the link to download the kit. https://wiki.ith.intel.com/display/OTCGFXPERF/GT-Pin+for+Linux thanks. -- Op

Re: [Intel-gfx] New GTPin kit (5923)

On 2015.07.09 13:50:14 +0800, Zhenyu Wang wrote: > > GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing > system for GT-Pin on Linux, we now have aligned kit release regularly. > > Please check wiki page for details and the link to download the kit. > > https://wiki.ith

<    1   2