Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Tvrtko Ursulin]

On 06/10/15 11:39, Chris Wilson wrote:

Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".

To keep Daniel happy with the prospect of being able to reuse these
fields in the next decade, continue to ensure that current userspace is
not passing garbage in through the dead fields.

v2: Fix the cliprects_ptr check

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 


Don't know anything about the DRI1 history but the removal looks fine to 
me, so:


Reviewed-by: Tvrtko Ursulin 

Would it also make sense to rename the related fields in 
drm_i915_gem_execbuffer2 to reserved?


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 11/12] drm/i915/ivb: Use mmio workarounds in init clock gating

[Mika Kuoppala]

Use workarounds written in ivybridge's init clock gating path,
use mmio workaround list to ensure proper setup after
reset/resume.

This way we don't lose _3DCHICKEN and GEN7_FF_THREAD_MODE register
contents on reset/suspend.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c | 83 +++--
 2 files changed, 40 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a7c9e8c..573e7d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5911,7 +5911,7 @@ enum skl_disp_power_wells {
 
 /* GEN7 chicken */
 #define GEN7_COMMON_SLICE_CHICKEN1 0x7010
-# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
+# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC (1<<10)
 # define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
 #define COMMON_SLICE_CHICKEN2  0x7014
 # define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE  (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b2626c2..8bc1d3b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6370,11 +6370,11 @@ static void cpt_init_clock_gating(struct drm_device 
*dev)
 * gating for the panel power sequencer or it will fail to
 * start up when no ports are active.
 */
-   I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE |
-  PCH_DPLUNIT_CLOCK_GATE_DISABLE |
-  PCH_CPUNIT_CLOCK_GATE_DISABLE);
-   I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) |
-  DPLS_EDP_PPS_FIX_DIS);
+   WA_WRITE(MMIO, SOUTH_DSPCLK_GATE_D,
+PCH_DPLSUNIT_CLOCK_GATE_DISABLE |
+PCH_DPLUNIT_CLOCK_GATE_DISABLE |
+PCH_CPUNIT_CLOCK_GATE_DISABLE);
+   WA_SET_BIT(MMIO, SOUTH_CHICKEN2, DPLS_EDP_PPS_FIX_DIS);
/* The below fixes the weird display corruption, a few pixels shifted
 * downward, on (only) LVDS of some HP laptops with IVY.
 */
@@ -6387,12 +6387,12 @@ static void cpt_init_clock_gating(struct drm_device 
*dev)
val &= ~TRANS_CHICKEN2_FRAME_START_DELAY_MASK;
val &= ~TRANS_CHICKEN2_DISABLE_DEEP_COLOR_COUNTER;
val &= ~TRANS_CHICKEN2_DISABLE_DEEP_COLOR_MODESWITCH;
-   I915_WRITE(TRANS_CHICKEN2(pipe), val);
+   WA_WRITE(MMIO, TRANS_CHICKEN2(pipe), val);
}
/* WADP0ClockGatingDisable */
for_each_pipe(dev_priv, pipe) {
-   I915_WRITE(TRANS_CHICKEN1(pipe),
-  TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
+   WA_WRITE(MMIO, TRANS_CHICKEN1(pipe),
+TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
}
 }
 
@@ -6519,7 +6519,7 @@ static void gen7_setup_fixed_func_scheduler(struct 
drm_i915_private *dev_priv)
reg |= GEN7_FF_VS_SCHED_HW;
reg |= GEN7_FF_DS_SCHED_HW;
 
-   I915_WRITE(GEN7_FF_THREAD_MODE, reg);
+   WA_WRITE(MMIO, GEN7_FF_THREAD_MODE, reg);
 }
 
 static void lpt_init_clock_gating(struct drm_device *dev)
@@ -6659,60 +6659,55 @@ static void ivybridge_init_clock_gating(struct 
drm_device *dev)
 
ilk_init_lp_watermarks(dev);
 
-   I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
+   WA_WRITE(MMIO, ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
 
/* WaDisableEarlyCull:ivb */
-   I915_WRITE(_3D_CHICKEN3,
-  _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
+   WA_SET_BIT_MASKED(MMIO, _3D_CHICKEN3,
+ _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
 
/* WaDisableBackToBackFlipFix:ivb */
-   I915_WRITE(IVB_CHICKEN3,
-  CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE |
-  CHICKEN3_DGMG_DONE_FIX_DISABLE);
+   WA_WRITE(MMIO, IVB_CHICKEN3, CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE |
+CHICKEN3_DGMG_DONE_FIX_DISABLE);
 
/* WaDisablePSDDualDispatchEnable:ivb */
if (IS_IVB_GT1(dev))
-   I915_WRITE(GEN7_HALF_SLICE_CHICKEN1,
-  
_MASKED_BIT_ENABLE(GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE));
+   WA_SET_BIT_MASKED(MMIO, GEN7_HALF_SLICE_CHICKEN1,
+ GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
 
/* WaDisable_RenderCache_OperationalFlush:ivb */
-   I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
+   WA_CLR_BIT_MASKED(MMIO, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
 
/* Apply the WaDisableRHWOOptimizationForRenderHang:ivb workaround. */
-   I915_WRITE(GEN7_COMMON_SLICE_CHICKEN1,
-  GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC);
+   WA_SET_BIT_MASKED(MMIO, GEN7_COMMON_SLICE_CHICKEN1,
+ GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC);
 
/* WaApplyL3ControlAndL3ChickenMode:ivb */
-   

[Intel-gfx] [PATCH 07/12] drm/i915: Write mmio workarounds after gpu reset

[Mika Kuoppala]

From: Mika Kuoppala 

Rewrite everything in mmio workaround list right after
gpu reset. This ensures that we start the reinitialization
with proper mmio workarounds in place, before we
start the rings.

This commit just adds the mechanism, the list itself
is still empty. Following commits will add registers.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/i915_irq.c |  2 ++
 drivers/gpu/drm/i915/intel_pm.c | 20 
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 12 
 5 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ae5b6b3..d41808a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2732,6 +2732,7 @@ void intel_uncore_forcewake_get__locked(struct 
drm_i915_private *dev_priv,
 void intel_uncore_forcewake_put__locked(struct drm_i915_private *dev_priv,
enum forcewake_domains domains);
 void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
+void assert_forcewakes_active(struct drm_i915_private *dev_priv);
 static inline bool intel_vgpu_active(struct drm_device *dev)
 {
return to_i915(dev)->vgpu.active;
@@ -3545,7 +3546,14 @@ static inline void i915_trace_irq_get(struct 
intel_engine_cs *ring,
 #define WA_CLR_BIT(t, addr, mask) \
WA_REG_##t(addr, mask, I915_READ((addr)) & ~(mask))
 
+static inline void intel_wa_init(struct i915_workarounds *w)
+{
+   w->count = 0;
+}
+
 int intel_wa_add(struct i915_workarounds *w,
 const u32 addr, const u32 mask, const u32 val);
 
+void intel_wa_write_mmio(struct drm_i915_private *dev_priv,
+const struct i915_workarounds *w);
 #endif
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8ca772d..e686f78 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2441,6 +2441,8 @@ static void i915_reset_and_wakeup(struct drm_device *dev)
 */
ret = i915_reset(dev);
 
+   intel_wa_write_mmio(dev_priv, _priv->mmio_workarounds);
+
intel_finish_reset(dev);
 
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 60d120c..e97f271 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -52,6 +52,22 @@
 #define INTEL_RC6p_ENABLE  (1<<1)
 #define INTEL_RC6pp_ENABLE (1<<2)
 
+void intel_wa_write_mmio(struct drm_i915_private *dev_priv,
+const struct i915_workarounds *w)
+{
+   int i;
+
+   if (WARN_ON_ONCE(w->count == 0))
+   return;
+
+   assert_forcewakes_active(dev_priv);
+
+   for (i = 0; i < w->count; i++)
+   I915_WRITE_FW(w->reg[i].addr, w->reg[i].value);
+
+   DRM_DEBUG_DRIVER("Number of Workarounds written: %d\n", w->count);
+}
+
 static void gen9_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -6973,8 +6989,12 @@ void intel_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   intel_wa_init(_priv->mmio_workarounds);
+
if (dev_priv->display.init_clock_gating)
dev_priv->display.init_clock_gating(dev);
+
+   intel_wa_write_mmio(dev_priv, _priv->mmio_workarounds);
 }
 
 void intel_suspend_hw(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c9d3489e..3667dd9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1074,7 +1074,7 @@ int init_workarounds_ring(struct intel_engine_cs *ring)
 
WARN_ON(ring->id != RCS);
 
-   dev_priv->lri_workarounds.count = 0;
+   intel_wa_init(_priv->lri_workarounds);
 
if (IS_BROADWELL(dev))
return bdw_init_workarounds(ring);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b43c6d0..3f8d1f6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -524,6 +524,18 @@ void assert_forcewakes_inactive(struct drm_i915_private 
*dev_priv)
WARN_ON(domain->wake_count);
 }
 
+void assert_forcewakes_active(struct drm_i915_private *dev_priv)
+{
+   struct intel_uncore_forcewake_domain *domain;
+   enum forcewake_domain_id id;
+
+   if (!dev_priv->uncore.funcs.force_wake_get)
+   return;
+
+   for_each_fw_domain(domain, dev_priv, id)
+   WARN_ON(domain->wake_count == 0);
+}
+
 /* We give fast paths for the really cool registers */
 #define 

[Intel-gfx] [PATCH 09/12] drm/i915/bdw: Use mmio workarounds in init clock gating

[Mika Kuoppala]

For workarounds written in broadwell's init clock gating path,
use mmio workaround list.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_pm.c | 59 -
 2 files changed, 38 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d41808a..a225d55 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3546,6 +3546,9 @@ static inline void i915_trace_irq_get(struct 
intel_engine_cs *ring,
 #define WA_CLR_BIT(t, addr, mask) \
WA_REG_##t(addr, mask, I915_READ((addr)) & ~(mask))
 
+#define WA_WRITE(t, addr, val) \
+   WA_REG_##t(addr, 0x, val)
+
 static inline void intel_wa_init(struct i915_workarounds *w)
 {
w->count = 0;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 61136e1..7e01ef7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -62,9 +62,26 @@ void intel_wa_write_mmio(struct drm_i915_private *dev_priv,
 
assert_forcewakes_active(dev_priv);
 
-   for (i = 0; i < w->count; i++)
+   for (i = 0; i < w->count; i++) {
+   u32 misccpctl;
+
+   /* WaTempDisableDOPClkGating:bdw */
+   const bool need_dop_clkgate =
+   w->reg[i].addr == GEN8_L3SQCREG1 &&
+   IS_BROADWELL(dev_priv->dev);
+
+   if (need_dop_clkgate) {
+   misccpctl = I915_READ(GEN7_MISCCPCTL);
+   I915_WRITE_FW(GEN7_MISCCPCTL,
+ misccpctl & ~GEN7_DOP_CLOCK_GATE_ENABLE);
+   }
+
I915_WRITE_FW(w->reg[i].addr, w->reg[i].value);
 
+   if (need_dop_clkgate)
+   I915_WRITE_FW(GEN7_MISCCPCTL, misccpctl);
+   }
+
DRM_DEBUG_DRIVER("Number of Workarounds written: %d\n", w->count);
 }
 
@@ -6514,10 +6531,14 @@ static void lpt_init_clock_gating(struct drm_device 
*dev)
 * disabled when not needed anymore in order to save power.
 */
if (HAS_PCH_LPT_LP(dev))
-   I915_WRITE(SOUTH_DSPCLK_GATE_D,
-  I915_READ(SOUTH_DSPCLK_GATE_D) |
+   WA_SET_BIT(MMIO, SOUTH_DSPCLK_GATE_D,
   PCH_LP_PARTITION_LEVEL_DISABLE);
 
+   /* XXX: This register is volatile with bdw. After
+* reset you get weird values and after writing,
+* the value you get is 0x1000 so read/modify/write
+* is dangerous
+*/
/* WADPOClockGatingDisable:hsw */
I915_WRITE(TRANS_CHICKEN1(PIPE_A),
   I915_READ(TRANS_CHICKEN1(PIPE_A)) |
@@ -6540,52 +6561,42 @@ static void broadwell_init_clock_gating(struct 
drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
-   uint32_t misccpctl;
 
ilk_init_lp_watermarks(dev);
 
/* WaSwitchSolVfFArbitrationPriority:bdw */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
+   WA_SET_BIT(MMIO, GAM_ECOCHK, HSW_ECOCHK_ARB_PRIO_SOL);
 
/* WaPsrDPAMaskVBlankInSRD:bdw */
-   I915_WRITE(CHICKEN_PAR1_1,
-  I915_READ(CHICKEN_PAR1_1) | DPA_MASK_VBLANK_SRD);
+   WA_SET_BIT(MMIO, CHICKEN_PAR1_1, DPA_MASK_VBLANK_SRD);
 
/* WaPsrDPRSUnmaskVBlankInSRD:bdw */
for_each_pipe(dev_priv, pipe) {
-   I915_WRITE(CHICKEN_PIPESL_1(pipe),
-  I915_READ(CHICKEN_PIPESL_1(pipe)) |
+   WA_SET_BIT(MMIO, CHICKEN_PIPESL_1(pipe),
   BDW_DPRS_MASK_VBLANK_SRD);
}
 
/* WaVSRefCountFullforceMissDisable:bdw */
/* WaDSRefCountFullforceMissDisable:bdw */
-   I915_WRITE(GEN7_FF_THREAD_MODE,
-  I915_READ(GEN7_FF_THREAD_MODE) &
-  ~(GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME));
+   WA_CLR_BIT(MMIO, GEN7_FF_THREAD_MODE,
+  GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME);
 
-   I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
-  _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
+   WA_SET_BIT_MASKED(MMIO, GEN6_RC_SLEEP_PSMI_CONTROL,
+ GEN8_RC_SEMA_IDLE_MSG_DISABLE);
 
/* WaDisableSDEUnitClockGating:bdw */
-   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
+   WA_SET_BIT(MMIO, GEN8_UCGCTL6,
   GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
 
-   /*
-* WaProgramL3SqcReg1Default:bdw
-* WaTempDisableDOPClkGating:bdw
-*/
-   misccpctl = I915_READ(GEN7_MISCCPCTL);
-   I915_WRITE(GEN7_MISCCPCTL, misccpctl & ~GEN7_DOP_CLOCK_GATE_ENABLE);
-   I915_WRITE(GEN8_L3SQCREG1, BDW_WA_L3SQCREG1_DEFAULT);
-   I915_WRITE(GEN7_MISCCPCTL, misccpctl);
+   /* WaProgramL3SqcReg1Default:bdw */
+   

[Intel-gfx] [PATCH 03/12] drm/i915: Don't return inside WA_REG macro

[Mika Kuoppala]

It is considered a very bad practice to return inside
a macro. Instead of returning, emit a warning.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 71b4fac..bc8a8e2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -783,8 +783,7 @@ static int wa_add(struct i915_workarounds *w,
 #define WA_REG(addr, mask, val) do { \
const int r = wa_add(_priv->lri_workarounds, \
 (addr), (mask), (val)); \
-   if (r) \
-   return r; \
+   WARN_ON(r); \
} while (0)
 
 #define WA_SET_BIT_MASKED(addr, mask) \
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/12] drm/i915: Raise the amount of workarounds one list has

[Mika Kuoppala]

As we move towards of adding mmio register setup to
use workaround list, raise the maximum amount of available
registers in list.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aa38d1e..1883847 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1669,7 +1669,7 @@ struct i915_wa_reg {
u32 mask;
 };
 
-#define I915_MAX_WA_REGS 16
+#define I915_MAX_WA_REGS 32
 
 struct i915_workarounds {
struct i915_wa_reg reg[I915_MAX_WA_REGS];
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Chris Wilson]

On Tue, Oct 06, 2015 at 03:29:20PM +0100, Dave Gordon wrote:
> On 06/10/15 11:39, Chris Wilson wrote:
> >Passing cliprects into the kernel for it to re-execute the batch buffer
> >with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> >removed from the kernel, we can now simply reject any execbuf trying to
> >use this "feature".
> >
> >To keep Daniel happy with the prospect of being able to reuse these
> >fields in the next decade, continue to ensure that current userspace is
> >not passing garbage in through the dead fields.
> >
> >v2: Fix the cliprects_ptr check
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Daniel Vetter 
> >---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 154 
> > ++---
> >  drivers/gpu/drm/i915/intel_lrc.c   |  15 ---
> >  2 files changed, 31 insertions(+), 138 deletions(-)
> 
> This will cause John Harrison & myself a certain amount of pain
> (because the changes collide with the scheduler's reorganisation of
> the execbuffer path), but I'm all in favour of getting rid of the
> legacy crud cluttering up this code, so ...

Oh, don't worry I'm completely rewriting it and will nak anything that
adds a cycle of latency to execbuffer.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Chris Wilson]

On Tue, Oct 06, 2015 at 03:19:36PM +0100, Tvrtko Ursulin wrote:
> 
> On 06/10/15 11:39, Chris Wilson wrote:
> >Passing cliprects into the kernel for it to re-execute the batch buffer
> >with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> >removed from the kernel, we can now simply reject any execbuf trying to
> >use this "feature".
> >
> >To keep Daniel happy with the prospect of being able to reuse these
> >fields in the next decade, continue to ensure that current userspace is
> >not passing garbage in through the dead fields.
> >
> >v2: Fix the cliprects_ptr check
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Daniel Vetter 
> 
> Don't know anything about the DRI1 history but the removal looks
> fine to me, so:
> 
> Reviewed-by: Tvrtko Ursulin 
> 
> Would it also make sense to rename the related fields in
> drm_i915_gem_execbuffer2 to reserved?

In our heads, yes. Renaming structs in uapi.h is harder than it looks.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Dave Gordon]

On 06/10/15 11:39, Chris Wilson wrote:

Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".

To keep Daniel happy with the prospect of being able to reuse these
fields in the next decade, continue to ensure that current userspace is
not passing garbage in through the dead fields.

v2: Fix the cliprects_ptr check

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 154 ++---
  drivers/gpu/drm/i915/intel_lrc.c   |  15 ---
  2 files changed, 31 insertions(+), 138 deletions(-)


This will cause John Harrison & myself a certain amount of pain (because 
the changes collide with the scheduler's reorganisation of the 
execbuffer path), but I'm all in favour of getting rid of the legacy 
crud cluttering up this code, so ...


Reviewed-by: Dave Gordon 

Perhaps we could get rid of relative-constants-mode next :)


diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 75a0c8b5305b..045a7631faa0 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -947,7 +947,21 @@ i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 
*exec)
if (exec->flags & __I915_EXEC_UNKNOWN_FLAGS)
return false;

-   return ((exec->batch_start_offset | exec->batch_len) & 0x7) == 0;
+   /* Kernel clipping was a DRI1 misfeature */
+   if (exec->num_cliprects || exec->cliprects_ptr)
+   return false;
+
+   if (exec->DR4 == 0x) {
+   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   exec->DR4 = 0;
+   }
+   if (exec->DR1 || exec->DR4)
+   return false;
+
+   if ((exec->batch_start_offset | exec->batch_len) & 0x7)
+   return false;
+
+   return true;
  }

  static int
@@ -,47 +1125,6 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return 0;
  }

-static int
-i915_emit_box(struct drm_i915_gem_request *req,
- struct drm_clip_rect *box,
- int DR1, int DR4)
-{
-   struct intel_engine_cs *ring = req->ring;
-   int ret;
-
-   if (box->y2 <= box->y1 || box->x2 <= box->x1 ||
-   box->y2 <= 0 || box->x2 <= 0) {
-   DRM_ERROR("Bad box %d,%d..%d,%d\n",
- box->x1, box->y1, box->x2, box->y2);
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(ring->dev)->gen >= 4) {
-   ret = intel_ring_begin(req, 4);
-   if (ret)
-   return ret;
-
-   intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO_I965);
-   intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
-   intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
<< 16);
-   intel_ring_emit(ring, DR4);
-   } else {
-   ret = intel_ring_begin(req, 6);
-   if (ret)
-   return ret;
-
-   intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO);
-   intel_ring_emit(ring, DR1);
-   intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
-   intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
<< 16);
-   intel_ring_emit(ring, DR4);
-   intel_ring_emit(ring, 0);
-   }
-   intel_ring_advance(ring);
-
-   return 0;
-}
-
  static struct drm_i915_gem_object*
  i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
  struct drm_i915_gem_exec_object2 *shadow_exec_entry,
@@ -1210,65 +1183,21 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas)
  {
-   struct drm_clip_rect *cliprects = NULL;
struct drm_device *dev = params->dev;
struct intel_engine_cs *ring = params->ring;
struct drm_i915_private *dev_priv = dev->dev_private;
u64 exec_start, exec_len;
int instp_mode;
u32 instp_mask;
-   int i, ret = 0;
-
-   if (args->num_cliprects != 0) {
-   if (ring != _priv->ring[RCS]) {
-   DRM_DEBUG("clip rectangles are only valid with the render 
ring\n");
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(dev)->gen >= 5) {
-   DRM_DEBUG("clip rectangles are only valid on 
pre-gen5\n");
-   return -EINVAL;
-   }
-
-   if (args->num_cliprects > UINT_MAX / sizeof(*cliprects)) {
-   DRM_DEBUG("execbuf with %u cliprects\n",
-  

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position

[Matt Roper]

On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> 
> On 10/04/15 10:07, Sonika Jindal wrote:
> >Signed-off-by: Sonika Jindal 
> >Reviewed-by: Matt Roper 
> >---
> >  drivers/gpu/drm/i915/intel_display.c |7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >b/drivers/gpu/drm/i915/intel_display.c
> >index ceb2e61..f0bbc22 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -12150,16 +12150,21 @@ intel_check_primary_plane(struct drm_plane *plane,
> > struct drm_rect *dest = >dst;
> > struct drm_rect *src = >src;
> > const struct drm_rect *clip = >clip;
> >+bool can_position = false;
> > int ret;
> >
> > crtc = crtc ? crtc : plane->crtc;
> > intel_crtc = to_intel_crtc(crtc);
> >
> >+if (INTEL_INFO(dev)->gen >= 9)
> >+can_position = true;
> >+
> > ret = drm_plane_helper_check_update(plane, crtc, fb,
> > src, dest, clip,
> > DRM_PLANE_HELPER_NO_SCALING,
> > DRM_PLANE_HELPER_NO_SCALING,
> >-false, true, >visible);
> >+can_position, true,
> >+>visible);
> > if (ret)
> > return ret;
> >
> >
> 
> I have discovered today that, while this allows SetCrtc and SetPlane
> ioctls to work with frame buffers which do not cover the plane, page
> flips are not that lucky and fail roughly with:
> 
> [drm:drm_crtc_check_viewport] Invalid fb size 1080x1080 for CRTC
> viewport 1920x1080+0+0.

Maybe I'm misunderstanding your explanation, but a framebuffer is always
required to fill/cover the plane scanning out of it.  What this patch is
supposed to be allowing is for the primary plane to not cover the entire
CRTC (since that's something that only became possible for Intel
hardware on the gen9+ platforms).  I.e., the primary plane is now
allowed to positioned and resized to cover a subset of the CRTC area,
just like "sprite" planes have always been able to.

If you've got a 1080x1080 framebuffer, then it's legal to have a
1080x1080 primary plane while running in 1920x1080 mode on SKL/BXT.
However it is not legal to size the primary plane as 1920x1080 and use
this same 1080x1080 framebuffer with any of our interfaces (setplane,
setcrtc, pageflip, or atomic).

Are you using ioctls/libdrm directly or are you using igt_kms helpers?
IIRC, the IGT helpers will try to be extra helpful and automatically
size the plane to match the framebuffer (unless you override that
behavior), so that might be what's causing the confusion here.


Matt

> 
> I have posted a quick IGT exerciser for this as "kms_rotation_crc:
> Excercise page flips with 90 degree rotation". May not be that great
> but shows the failure.
> 
> I am not that hot on meddling with this code, nor do I feel
> competent to even try on my own at least. :/ Maybe just because the
> atomic and plane related rewrites have been going on for so long,
> and have multiple people involved, it all sounds pretty scary and
> fragile.
> 
> But I think some sort of plan on how to fix this could be in order?
> 
> Regards,
> 
> Tvrtko

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Move the mb() following release-mmap into release-mmap

[Tvrtko Ursulin]

Hi,

On 06/10/15 12:58, Chris Wilson wrote:

As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release_mmap().

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b8ed7a2faab..642644f12295 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1877,11 +1877,21 @@ out:
  void
  i915_gem_release_mmap(struct drm_i915_gem_object *obj)
  {
+   /* Serialisation between user GTT access and our code depends upon
+* revoking the CPU's PTE whilst the mutex is held. The next user
+* pagefault then has to wait until we release the mutex.
+*/
+   lockdep_assert_held(>base.dev->struct_mutex);
+
if (!obj->fault_mappable)
return;

drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
+
+   /* Ensure that the CPU's PTE are revoked before we return */
+   mb();
+


smp_mb() or smp_wmb() would not suffice? Is it needed on uniprocessor?

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/12] drm/i915: Introduce mmio workaround list

[Mika Kuoppala]

Introduce another workaround list for mmio write type of
workarounds. No users yet.

Cc: Arun Siluvery 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
 drivers/gpu/drm/i915/i915_drv.h | 14 ++
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index af44808..0c4e6bc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3095,7 +3095,8 @@ static int i915_shared_dplls_info(struct seq_file *m, 
void *unused)
 }
 
 static void print_wa_regs(struct seq_file *m,
- const struct i915_workarounds *w)
+ const struct i915_workarounds *w,
+ const char *type)
 {
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
@@ -3111,8 +3112,8 @@ static void print_wa_regs(struct seq_file *m,
value = w->reg[i].value;
read = I915_READ(addr);
ok = (value & mask) == (read & mask);
-   seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x, 
status: %s\n",
-  addr, value, mask, read, ok ? "OK" : "FAIL");
+   seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x, type: 
%s, status: %s\n",
+  addr, value, mask, read, type, ok ? "OK" : "FAIL");
}
 }
 
@@ -3130,8 +3131,11 @@ static int i915_wa_registers(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
 
seq_printf(m, "Workarounds applied: %d\n",
-  dev_priv->lri_workarounds.count);
-   print_wa_regs(m, _priv->lri_workarounds);
+  dev_priv->lri_workarounds.count +
+  dev_priv->mmio_workarounds.count);
+
+   print_wa_regs(m, _priv->lri_workarounds,  " LRI");
+   print_wa_regs(m, _priv->mmio_workarounds, "MMIO");
 
intel_runtime_pm_put(dev_priv);
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0ed790c..ae5b6b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1845,6 +1845,7 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
 
struct i915_workarounds lri_workarounds;
+   struct i915_workarounds mmio_workarounds;
 
/* Reclocking support */
bool render_reclock_avail;
@@ -3519,12 +3520,17 @@ static inline void i915_trace_irq_get(struct 
intel_engine_cs *ring,
 }
 
 /* Workaround register lists */
-#define WA_REG_LRI(addr, mask, val) do { \
-   const int r = intel_wa_add(_priv->lri_workarounds, \
-  (addr), (mask), (val)); \
-   WARN_ON(r); \
+#define WA_REG(wlist, addr, mask, val) do { \
+   const int r = intel_wa_add((wlist), (addr), (mask), (val)); \
+   WARN_ON(r); \
} while (0)
 
+#define WA_REG_LRI(addr, mask, val) \
+   WA_REG(_priv->lri_workarounds, (addr), (mask), (val))
+
+#define WA_REG_MMIO(addr, mask, val) \
+   WA_REG(_priv->mmio_workarounds, (addr), (mask), (val))
+
 #define WA_SET_BIT_MASKED(t, addr, mask) \
WA_REG_##t(addr, (mask), _MASKED_BIT_ENABLE(mask))
 
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/12] drm/i915/ivb: Simplify row chicken setup logic

[Mika Kuoppala]

We always write the ROW_CHICKEN2. Make this more clear
by writing it unconditionally.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8bc1d3b..ec77e04 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6685,16 +6685,13 @@ static void ivybridge_init_clock_gating(struct 
drm_device *dev)
WA_WRITE(MMIO, GEN7_L3CNTLREG1, GEN7_WA_FOR_GEN7_L3_CONTROL);
WA_WRITE(MMIO, GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE);
 
-   if (IS_IVB_GT1(dev))
-   WA_SET_BIT_MASKED(MMIO, GEN7_ROW_CHICKEN2,
- DOP_CLOCK_GATING_DISABLE);
-   else {
-   /* must write both registers */
-   WA_SET_BIT_MASKED(MMIO, GEN7_ROW_CHICKEN2,
- DOP_CLOCK_GATING_DISABLE);
+   WA_SET_BIT_MASKED(MMIO, GEN7_ROW_CHICKEN2,
+ DOP_CLOCK_GATING_DISABLE);
+
+   /* must write both registers */
+   if (!IS_IVB_GT1(dev))
WA_SET_BIT_MASKED(MMIO, GEN7_ROW_CHICKEN2_GT2,
  DOP_CLOCK_GATING_DISABLE);
-   }
 
/* WaForceL3Serialization:ivb */
WA_CLR_BIT(MMIO, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/12] drm/i915: Prepare for multiple workaround lists

[Mika Kuoppala]

In preparation to have separate workaround lists
for both LRI and MMIO written workarounds, parametrize the
register addition and printing of wa lists.

Cc: Arun Siluvery 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 39 +
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 19 
 4 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3f2a7a7..af44808 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3094,33 +3094,44 @@ static int i915_shared_dplls_info(struct seq_file *m, 
void *unused)
return 0;
 }
 
-static int i915_wa_registers(struct seq_file *m, void *unused)
+static void print_wa_regs(struct seq_file *m,
+ const struct i915_workarounds *w)
 {
-   int i;
-   int ret;
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   int i;
 
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   intel_runtime_pm_get(dev_priv);
-
-   seq_printf(m, "Workarounds applied: %d\n", dev_priv->workarounds.count);
-   for (i = 0; i < dev_priv->workarounds.count; ++i) {
+   for (i = 0; i < w->count; ++i) {
u32 addr, mask, value, read;
bool ok;
 
-   addr = dev_priv->workarounds.reg[i].addr;
-   mask = dev_priv->workarounds.reg[i].mask;
-   value = dev_priv->workarounds.reg[i].value;
+   addr = w->reg[i].addr;
+   mask = w->reg[i].mask;
+   value = w->reg[i].value;
read = I915_READ(addr);
ok = (value & mask) == (read & mask);
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x, 
status: %s\n",
   addr, value, mask, read, ok ? "OK" : "FAIL");
}
+}
+
+static int i915_wa_registers(struct seq_file *m, void *unused)
+{
+   int ret;
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
+   intel_runtime_pm_get(dev_priv);
+
+   seq_printf(m, "Workarounds applied: %d\n",
+  dev_priv->lri_workarounds.count);
+   print_wa_regs(m, _priv->lri_workarounds);
 
intel_runtime_pm_put(dev_priv);
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51eea29..aa38d1e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1844,7 +1844,7 @@ struct drm_i915_private {
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
 
-   struct i915_workarounds workarounds;
+   struct i915_workarounds lri_workarounds;
 
/* Reclocking support */
bool render_reclock_avail;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 825fa7a..b9c7d23 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1095,7 +1095,7 @@ static int intel_logical_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
struct intel_ringbuffer *ringbuf = req->ringbuf;
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct i915_workarounds *w = _priv->workarounds;
+   struct i915_workarounds *w = _priv->lri_workarounds;
 
if (WARN_ON_ONCE(w->count == 0))
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c82c74c..71b4fac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -715,7 +715,7 @@ static int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
struct intel_engine_cs *ring = req->ring;
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct i915_workarounds *w = _priv->workarounds;
+   struct i915_workarounds *w = _priv->lri_workarounds;
 
if (WARN_ON_ONCE(w->count == 0))
return 0;
@@ -763,25 +763,26 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request 
*req)
return ret;
 }
 
-static int wa_add(struct drm_i915_private *dev_priv,
+static int wa_add(struct i915_workarounds *w,
  const u32 addr, const u32 mask, const u32 val)
 {
-   

[Intel-gfx] [PATCH 04/12] drm/i915: Move workaround macros to i915_drv.h

[Mika Kuoppala]

The plan is to allow workaround list usage outside of
intel_ringbuffer.c, mainly in intel_pm.c where we setup assortment
of workaround registers as part of intel_init_clock_gating().

Move macros to i915_drv.h and export intel_wa_add().
Remove WA_WRITE macro as there are no users of it as of now.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 22 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 24 ++--
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1883847..5a04948 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3518,4 +3518,26 @@ static inline void i915_trace_irq_get(struct 
intel_engine_cs *ring,
i915_gem_request_assign(>trace_irq_req, req);
 }
 
+/* Workaround register lists */
+#define WA_REG(addr, mask, val) do { \
+   const int r = intel_wa_add(_priv->lri_workarounds, \
+  (addr), (mask), (val)); \
+   WARN_ON(r); \
+   } while (0)
+
+#define WA_SET_BIT_MASKED(addr, mask) \
+   WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
+
+#define WA_CLR_BIT_MASKED(addr, mask) \
+   WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
+
+#define WA_SET_FIELD_MASKED(addr, mask, value) \
+   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
+
+#define WA_SET_BIT(addr, mask) WA_REG(addr, mask, I915_READ((addr)) | (mask))
+#define WA_CLR_BIT(addr, mask) WA_REG(addr, mask, I915_READ((addr)) & ~(mask))
+
+int intel_wa_add(struct i915_workarounds *w,
+const u32 addr, const u32 mask, const u32 val);
+
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index bc8a8e2..29ae97e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -763,8 +763,8 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request 
*req)
return ret;
 }
 
-static int wa_add(struct i915_workarounds *w,
- const u32 addr, const u32 mask, const u32 val)
+int intel_wa_add(struct i915_workarounds *w,
+const u32 addr, const u32 mask, const u32 val)
 {
const u32 idx = w->count;
 
@@ -780,26 +780,6 @@ static int wa_add(struct i915_workarounds *w,
return 0;
 }
 
-#define WA_REG(addr, mask, val) do { \
-   const int r = wa_add(_priv->lri_workarounds, \
-(addr), (mask), (val)); \
-   WARN_ON(r); \
-   } while (0)
-
-#define WA_SET_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-
-#define WA_CLR_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-
-#define WA_SET_FIELD_MASKED(addr, mask, value) \
-   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-
-#define WA_SET_BIT(addr, mask) WA_REG(addr, mask, I915_READ(addr) | (mask))
-#define WA_CLR_BIT(addr, mask) WA_REG(addr, mask, I915_READ(addr) & ~(mask))
-
-#define WA_WRITE(addr, val) WA_REG(addr, 0x, val)
-
 static int gen8_init_workarounds(struct intel_engine_cs *ring)
 {
struct drm_device *dev = ring->dev;
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/12] drm/i915/hsw: Use mmio workarounds in init clock gating

[Mika Kuoppala]

For workarounds written in haswells's init clock gating path,
use mmio workaround list.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7e01ef7..b2626c2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6608,29 +6608,26 @@ static void haswell_init_clock_gating(struct drm_device 
*dev)
ilk_init_lp_watermarks(dev);
 
/* L3 caching of data atomics doesn't work -- disable it. */
-   I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
-   I915_WRITE(HSW_ROW_CHICKEN3,
-  
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
+   WA_WRITE(MMIO, HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+   WA_SET_BIT_MASKED(MMIO, HSW_ROW_CHICKEN3,
+ HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE);
 
/* This is required by WaCatErrorRejectionIssue:hsw */
-   I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
-   I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
-   GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
+   WA_SET_BIT(MMIO, GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
+  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
 
/* WaVSRefCountFullforceMissDisable:hsw */
-   I915_WRITE(GEN7_FF_THREAD_MODE,
-  I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
+   WA_CLR_BIT(MMIO, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
 
/* WaDisable_RenderCache_OperationalFlush:hsw */
-   I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
+   WA_CLR_BIT_MASKED(MMIO, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
 
/* enable HiZ Raw Stall Optimization */
-   I915_WRITE(CACHE_MODE_0_GEN7,
-  _MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
+   WA_CLR_BIT_MASKED(MMIO, CACHE_MODE_0_GEN7, HIZ_RAW_STALL_OPT_DISABLE);
 
/* WaDisable4x2SubspanOptimization:hsw */
-   I915_WRITE(CACHE_MODE_1,
-  _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE));
+   WA_SET_BIT_MASKED(MMIO, CACHE_MODE_1,
+ PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
 
/*
 * BSpec recommends 8x4 when MSAA is used,
@@ -6640,19 +6637,17 @@ static void haswell_init_clock_gating(struct drm_device 
*dev)
 * disable bit, which we don't touch here, but it's good
 * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
 */
-   I915_WRITE(GEN7_GT_MODE,
-  _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
+   WA_SET_FIELD_MASKED(MMIO, GEN7_GT_MODE,
+   GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4);
 
/* WaSampleCChickenBitEnable:hsw */
-   I915_WRITE(HALF_SLICE_CHICKEN3,
-  _MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE));
+   WA_SET_BIT_MASKED(MMIO, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE);
 
/* WaSwitchSolVfFArbitrationPriority:hsw */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
+   WA_SET_BIT(MMIO, GAM_ECOCHK, HSW_ECOCHK_ARB_PRIO_SOL);
 
/* WaRsPkgCStateDisplayPMReq:hsw */
-   I915_WRITE(CHICKEN_PAR1_1,
-  I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
+   WA_SET_BIT(MMIO, CHICKEN_PAR1_1, FORCE_ARB_IDLE_PLANES);
 
lpt_init_clock_gating(dev);
 }
-- 
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/12] drm/i915: Use mmio workaround list for skl/bxt

[Mika Kuoppala]

Some registers are, naturally, lost in gpu reset/suspend cycle.
And some registers, for example in display domain and are not subject
to gpu reset so they retain their contents.

As hang recovery triggers a reset, recoverable gpu hang can currently
flush out essential workarounds and cause havoc later on.

When register GEN8_GARBNTL is missing the WaEnableGapsTsvCreditFix:skl,
it can cause random system hangs [1]. This workaround was added in:
commit 245d96670d26 ("drm/i915:skl: Add WaEnableGapsTsvCreditFix").
But another set of system hangs were observed and the failure pattern
indicated that there was random gpu hang preceding the system hang [2].
This lead to the realization that we lose this workaround and BDW_SCRATCH1
on reset.

Add workarounds in skl/bxt init clock gating path to mmio workaround
list. This exposes these registers to the same testing mechanism in use
with the lri workarounds, gem_workarounds.

References: [1] https://bugs.freedesktop.org/show_bug.cgi?id=90854
References: https://bugs.freedesktop.org/show_bug.cgi?id=92315
Testcase: igt/gem_workarounds
Reported-by: Tomi Sarvela 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e97f271..61136e1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -73,12 +73,11 @@ static void gen9_init_clock_gating(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
 
/* WaEnableLbsSlaRetryTimerDecrement:skl */
-   I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
+   WA_SET_BIT(MMIO, BDW_SCRATCH1,
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
 
/* WaDisableKillLogic:bxt,skl */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  ECOCHK_DIS_TLB);
+   WA_SET_BIT(MMIO, GAM_ECOCHK, ECOCHK_DIS_TLB);
 }
 
 static void skl_init_clock_gating(struct drm_device *dev)
@@ -89,12 +88,11 @@ static void skl_init_clock_gating(struct drm_device *dev)
 
if (INTEL_REVID(dev) <= SKL_REVID_D0) {
/* WaDisableHDCInvalidation:skl */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  BDW_DISABLE_HDC_INVALIDATION);
+   WA_SET_BIT(MMIO, GAM_ECOCHK, BDW_DISABLE_HDC_INVALIDATION);
 
/* WaDisableChickenBitTSGBarrierAckForFFSliceCS:skl */
-   I915_WRITE(FF_SLICE_CS_CHICKEN2,
-  _MASKED_BIT_ENABLE(GEN9_TSG_BARRIER_ACK_DISABLE));
+   WA_SET_BIT_MASKED(MMIO, FF_SLICE_CS_CHICKEN2,
+ GEN9_TSG_BARRIER_ACK_DISABLE);
}
 
/* GEN8_L3SQCREG4 has a dependency with WA batch so any new changes
@@ -102,13 +100,12 @@ static void skl_init_clock_gating(struct drm_device *dev)
 */
if (INTEL_REVID(dev) <= SKL_REVID_E0)
/* WaDisableLSQCROPERFforOCL:skl */
-   I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
-  GEN8_LQSC_RO_PERF_DIS);
+   WA_SET_BIT(MMIO, GEN8_L3SQCREG4, GEN8_LQSC_RO_PERF_DIS);
 
/* WaEnableGapsTsvCreditFix:skl */
if (IS_SKYLAKE(dev) && (INTEL_REVID(dev) >= SKL_REVID_C0)) {
-   I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
-  GEN9_GAPS_TSV_CREDIT_DISABLE));
+   WA_SET_BIT(MMIO, GEN8_GARBCNTL,
+  GEN9_GAPS_TSV_CREDIT_DISABLE);
}
 }
 
@@ -119,25 +116,23 @@ static void bxt_init_clock_gating(struct drm_device *dev)
gen9_init_clock_gating(dev);
 
/* WaDisableSDEUnitClockGating:bxt */
-   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
-  GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+   WA_SET_BIT(MMIO, GEN8_UCGCTL6, GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
 
/*
 * FIXME:
 * GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ applies on 3x6 GT SKUs only.
 */
-   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
-  GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ);
+   WA_SET_BIT(MMIO, GEN8_UCGCTL6, GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ);
 
/* WaStoreMultiplePTEenable:bxt */
/* This is a requirement according to Hardware specification */
if (INTEL_REVID(dev) == BXT_REVID_A0)
-   I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_TLBPF);
+   WA_SET_BIT(MMIO, TILECTL, TILECTL_TLBPF);
 
/* WaSetClckGatingDisableMedia:bxt */
if (INTEL_REVID(dev) == BXT_REVID_A0) {
-   I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) &
-   ~GEN8_DOP_CLOCK_GATE_MEDIA_ENABLE));
+   WA_CLR_BIT(MMIO, GEN7_MISCCPCTL,
+  GEN8_DOP_CLOCK_GATE_MEDIA_ENABLE);
 

[Intel-gfx] [PATCH 0/4] lrc lifecycle cleanups

[Nick Hoath]

These changes are a result of the requests made in VIZ-4277.
Make the lrc path more like the legacy submission path.
Attach the CPU mappings to vma (un)bind, so that the shrinker
also cleans those up.
Pin the CPU mappings while context is busy (pending bbs), so
that the mappings aren't released/made continuously as this is
an expensive process.

Nick Hoath (4):
  drm/i915: Unify execlist and legacy request life-cycles
  drm/i915: Improve dynamic management/eviction of lrc backing objects
  drm/i915: Add the CPU mapping of the hw context to the pinned items.
  drm/i915: Only update ringbuf address when necessary

 drivers/gpu/drm/i915/i915_debugfs.c |  14 ++--
 drivers/gpu/drm/i915/i915_drv.h |  14 +++-
 drivers/gpu/drm/i915/i915_gem.c |  70 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |   8 ++
 drivers/gpu/drm/i915/i915_irq.c |  81 +---
 drivers/gpu/drm/i915/intel_lrc.c| 131 ++--
 drivers/gpu/drm/i915/intel_lrc.h|   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  71 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |   4 -
 9 files changed, 250 insertions(+), 145 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position

[Ville Syrjälä]

On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
> On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> > 
> > On 10/04/15 10:07, Sonika Jindal wrote:
> > >Signed-off-by: Sonika Jindal 
> > >Reviewed-by: Matt Roper 
> > >---
> > >  drivers/gpu/drm/i915/intel_display.c |7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > >b/drivers/gpu/drm/i915/intel_display.c
> > >index ceb2e61..f0bbc22 100644
> > >--- a/drivers/gpu/drm/i915/intel_display.c
> > >+++ b/drivers/gpu/drm/i915/intel_display.c
> > >@@ -12150,16 +12150,21 @@ intel_check_primary_plane(struct drm_plane 
> > >*plane,
> > >   struct drm_rect *dest = >dst;
> > >   struct drm_rect *src = >src;
> > >   const struct drm_rect *clip = >clip;
> > >+  bool can_position = false;
> > >   int ret;
> > >
> > >   crtc = crtc ? crtc : plane->crtc;
> > >   intel_crtc = to_intel_crtc(crtc);
> > >
> > >+  if (INTEL_INFO(dev)->gen >= 9)
> > >+  can_position = true;
> > >+
> > >   ret = drm_plane_helper_check_update(plane, crtc, fb,
> > >   src, dest, clip,
> > >   DRM_PLANE_HELPER_NO_SCALING,
> > >   DRM_PLANE_HELPER_NO_SCALING,
> > >-  false, true, >visible);
> > >+  can_position, true,
> > >+  >visible);
> > >   if (ret)
> > >   return ret;
> > >
> > >
> > 
> > I have discovered today that, while this allows SetCrtc and SetPlane
> > ioctls to work with frame buffers which do not cover the plane, page
> > flips are not that lucky and fail roughly with:
> > 
> > [drm:drm_crtc_check_viewport] Invalid fb size 1080x1080 for CRTC
> > viewport 1920x1080+0+0.
> 
> Maybe I'm misunderstanding your explanation, but a framebuffer is always
> required to fill/cover the plane scanning out of it.  What this patch is
> supposed to be allowing is for the primary plane to not cover the entire
> CRTC (since that's something that only became possible for Intel
> hardware on the gen9+ platforms).  I.e., the primary plane is now
> allowed to positioned and resized to cover a subset of the CRTC area,
> just like "sprite" planes have always been able to.
> 
> If you've got a 1080x1080 framebuffer, then it's legal to have a
> 1080x1080 primary plane while running in 1920x1080 mode on SKL/BXT.
> However it is not legal to size the primary plane as 1920x1080 and use
> this same 1080x1080 framebuffer with any of our interfaces (setplane,
> setcrtc, pageflip, or atomic).
> 
> Are you using ioctls/libdrm directly or are you using igt_kms helpers?
> IIRC, the IGT helpers will try to be extra helpful and automatically
> size the plane to match the framebuffer (unless you override that
> behavior), so that might be what's causing the confusion here.

The problem is clear as day in drm_mode_page_flip_ioctl():
ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y, >mode, fb);
if (ret)
goto out;

The fix should be easy; just extract the current src coordinates from
the plane state and check those against the new fb size. And then hope
that the plane state is really up to date.

And I'm sure rotated cases will go boom in some other ways. Probably
we should just switch over to using the full plane update for mmio
flips to fix it.

> 
> 
> Matt
> 
> > 
> > I have posted a quick IGT exerciser for this as "kms_rotation_crc:
> > Excercise page flips with 90 degree rotation". May not be that great
> > but shows the failure.
> > 
> > I am not that hot on meddling with this code, nor do I feel
> > competent to even try on my own at least. :/ Maybe just because the
> > atomic and plane related rewrites have been going on for so long,
> > and have multiple people involved, it all sounds pretty scary and
> > fragile.
> > 
> > But I think some sort of plan on how to fix this could be in order?
> > 
> > Regards,
> > 
> > Tvrtko
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position

[Matt Roper]

On Tue, Oct 06, 2015 at 05:42:42PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
> > On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 10/04/15 10:07, Sonika Jindal wrote:
> > > >Signed-off-by: Sonika Jindal 
> > > >Reviewed-by: Matt Roper 
> > > >---
> > > >  drivers/gpu/drm/i915/intel_display.c |7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > >b/drivers/gpu/drm/i915/intel_display.c
> > > >index ceb2e61..f0bbc22 100644
> > > >--- a/drivers/gpu/drm/i915/intel_display.c
> > > >+++ b/drivers/gpu/drm/i915/intel_display.c
> > > >@@ -12150,16 +12150,21 @@ intel_check_primary_plane(struct drm_plane 
> > > >*plane,
> > > > struct drm_rect *dest = >dst;
> > > > struct drm_rect *src = >src;
> > > > const struct drm_rect *clip = >clip;
> > > >+bool can_position = false;
> > > > int ret;
> > > >
> > > > crtc = crtc ? crtc : plane->crtc;
> > > > intel_crtc = to_intel_crtc(crtc);
> > > >
> > > >+if (INTEL_INFO(dev)->gen >= 9)
> > > >+can_position = true;
> > > >+
> > > > ret = drm_plane_helper_check_update(plane, crtc, fb,
> > > > src, dest, clip,
> > > > DRM_PLANE_HELPER_NO_SCALING,
> > > > DRM_PLANE_HELPER_NO_SCALING,
> > > >-false, true, 
> > > >>visible);
> > > >+can_position, true,
> > > >+>visible);
> > > > if (ret)
> > > > return ret;
> > > >
> > > >
> > > 
> > > I have discovered today that, while this allows SetCrtc and SetPlane
> > > ioctls to work with frame buffers which do not cover the plane, page
> > > flips are not that lucky and fail roughly with:
> > > 
> > > [drm:drm_crtc_check_viewport] Invalid fb size 1080x1080 for CRTC
> > > viewport 1920x1080+0+0.
> > 
> > Maybe I'm misunderstanding your explanation, but a framebuffer is always
> > required to fill/cover the plane scanning out of it.  What this patch is
> > supposed to be allowing is for the primary plane to not cover the entire
> > CRTC (since that's something that only became possible for Intel
> > hardware on the gen9+ platforms).  I.e., the primary plane is now
> > allowed to positioned and resized to cover a subset of the CRTC area,
> > just like "sprite" planes have always been able to.
> > 
> > If you've got a 1080x1080 framebuffer, then it's legal to have a
> > 1080x1080 primary plane while running in 1920x1080 mode on SKL/BXT.
> > However it is not legal to size the primary plane as 1920x1080 and use
> > this same 1080x1080 framebuffer with any of our interfaces (setplane,
> > setcrtc, pageflip, or atomic).
> > 
> > Are you using ioctls/libdrm directly or are you using igt_kms helpers?
> > IIRC, the IGT helpers will try to be extra helpful and automatically
> > size the plane to match the framebuffer (unless you override that
> > behavior), so that might be what's causing the confusion here.
> 
> The problem is clear as day in drm_mode_page_flip_ioctl():
> ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y, >mode, fb);
> if (ret)
>   goto out;
> 
> The fix should be easy; just extract the current src coordinates from
> the plane state and check those against the new fb size. And then hope
> that the plane state is really up to date.

Yep, that's the conclusion we came to once Tvrtko explained what he was
seeing on IRC.  I'm not sure whether non-atomic drivers have enough
state setup by the default helpers to work properly.  Worst case we'll
just assume that a non-atomic driver won't support primary plane
windowing (since none have in the past) and fall back to looking at the
mode for legacy non-atomic drivers.

> 
> And I'm sure rotated cases will go boom in some other ways. Probably
> we should just switch over to using the full plane update for mmio
> flips to fix it.

Yeah; the core looks at a drm_plane->invert_dimensions field that's only
set by omap.  That should probably be updated to look at the state's
rotation on atomic-capable drivers.


Matt

> 
> > 
> > 
> > Matt
> > 
> > > 
> > > I have posted a quick IGT exerciser for this as "kms_rotation_crc:
> > > Excercise page flips with 90 degree rotation". May not be that great
> > > but shows the failure.
> > > 
> > > I am not that hot on meddling with this code, nor do I feel
> > > competent to even try on my own at least. :/ Maybe just because the
> > > atomic and plane related rewrites have been going on for so long,
> > > and have multiple people involved, it all sounds pretty scary and
> > > fragile.
> > > 
> > > But I think some sort of plan on how to fix this could be in order?
> > > 

Re: [Intel-gfx] [PATCH] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state

[Jani Nikula]

On Thu, 01 Oct 2015, Matt Roper  wrote:
> When watermark calculation was moved up to the atomic check phase, the
> code was updated to calculate based on in-flight atomic state rather
> than already-committed state.  However the hsw_compute_linetime_wm()
> didn't get updated and continued to pull values out of the
> currently-committed CRTC state.  On platforms that call this function
> (HSW/BDW only), this will cause problems when we go to enable the CRTC
> since we'll pull the current mode (off) rather than the mode we're
> calculating for and wind up with a divide by zero error.
>
> This was an oversight in commit:
>
> commit a28170f3389f4e42db95e595b0d86384a79de696
> Author: Matt Roper 
> Date:   Thu Sep 24 15:53:16 2015 -0700
>
> drm/i915: Calculate ILK-style watermarks during atomic check (v3)
>
> Cc: Jani Nikula 
> Signed-off-by: Matt Roper 

Matt, current nightly + "drm/i915: Sanitize watermarks after hardware
state readout" + this still oopses my BDW at boot. dmesg attached.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.3.0-rc4-bisect-00536-g400a6b9 (jani@nukke) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #86 SMP Wed Oct 7 01:27:22 EEST 2015
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc4-bisect-00536-g400a6b9 
root=UUID=181461f1-6b98-43c3-8984-05f81ca9f77e ro log_buf_len=4M drm.debug=14 
quiet
[0.00] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100
[0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 0x340 
bytes, using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xd132efff] usable
[0.00] BIOS-e820: [mem 0xd132f000-0xd1809fff] reserved
[0.00] BIOS-e820: [mem 0xd180a000-0xd9324fff] usable
[0.00] BIOS-e820: [mem 0xd9325000-0xd9383fff] reserved
[0.00] BIOS-e820: [mem 0xd9384000-0xd93a6fff] ACPI data
[0.00] BIOS-e820: [mem 0xd93a7000-0xd9cd6fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xd9cd7000-0xd9fa2fff] reserved
[0.00] BIOS-e820: [mem 0xd9fa3000-0xd9ffefff] type 20
[0.00] BIOS-e820: [mem 0xd9fff000-0xd9ff] usable
[0.00] BIOS-e820: [mem 0xdb00-0xdf7f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021f7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi:  ACPI=0xd938b000  ACPI 2.0=0xd938b000  SMBIOS=0xf05b0  
MPS=0xfd640 
[0.00] SMBIOS 2.8 present.
[0.00] DMI: 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/NUC5i3RYB,
 BIOS RYBDWi35.86A.0130.2014.1203.1639 12/03/2014
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 

[Intel-gfx] [PATCH 2/4] drm/i915: Improve dynamic management/eviction of lrc backing objects

[Nick Hoath]

Shovel all context related objects through the active queue and obj
management.

- Added callback in vma_(un)bind to add CPU (un)mapping at same time
  if desired
- Inserted LRC hw context & ringbuf to vma active list

Issue: VIZ-4277
Signed-off-by: Nick Hoath 
---
 drivers/gpu/drm/i915/i915_drv.h |  4 ++
 drivers/gpu/drm/i915/i915_gem.c |  3 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c |  8 
 drivers/gpu/drm/i915/intel_lrc.c| 28 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 71 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 --
 6 files changed, 79 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d217f9..d660ee3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2169,6 +2169,10 @@ struct drm_i915_gem_object {
struct work_struct *work;
} userptr;
};
+
+   /** Support for automatic CPU side mapping of object */
+   int (*mmap)(struct drm_i915_gem_object *obj, bool unmap);
+   void *mappable;
 };
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc82171..56e0e00 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3262,6 +3262,9 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
if (vma->pin_count)
return -EBUSY;
 
+   if (obj->mmap)
+   obj->mmap(obj, true);
+
BUG_ON(obj->pages == NULL);
 
if (wait) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 620d57e..786ec4b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3495,6 +3495,14 @@ int i915_vma_bind(struct i915_vma *vma, enum 
i915_cache_level cache_level,
 
vma->bound |= bind_flags;
 
+   if (vma->obj->mmap) {
+   ret = vma->obj->mmap(vma->obj, false);
+   if (ret) {
+   i915_vma_unbind(vma);
+   return ret;
+   }
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e8f5b6c..b807928 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -723,6 +723,18 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
 
intel_logical_ring_advance(request->ringbuf);
 
+   /* Push the hw context on to the active list */
+   i915_vma_move_to_active(
+   i915_gem_obj_to_ggtt(
+   request->ctx->engine[ring->id].state),
+   request);
+
+   /* Push the ringbuf on to the active list */
+   i915_vma_move_to_active(
+   i915_gem_obj_to_ggtt(
+   request->ctx->engine[ring->id].ringbuf->obj),
+   request);
+
request->tail = request->ringbuf->tail;
 
if (intel_ring_stopped(ring))
@@ -1006,10 +1018,15 @@ static int intel_lr_context_do_pin(struct 
intel_engine_cs *ring,
if (ret)
return ret;
 
-   ret = intel_pin_and_map_ringbuffer_obj(ring->dev, ringbuf);
+   ret = i915_gem_obj_ggtt_pin(ringbuf->obj, PAGE_SIZE,
+   PIN_MAPPABLE);
if (ret)
goto unpin_ctx_obj;
 
+   ret = i915_gem_object_set_to_gtt_domain(ringbuf->obj, true);
+   if (ret)
+   goto unpin_rb_obj;
+
ctx_obj->dirty = true;
 
/* Invalidate GuC TLB. */
@@ -1018,6 +1035,8 @@ static int intel_lr_context_do_pin(struct intel_engine_cs 
*ring,
 
return ret;
 
+unpin_rb_obj:
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
 unpin_ctx_obj:
i915_gem_object_ggtt_unpin(ctx_obj);
 
@@ -1052,7 +1071,7 @@ void intel_lr_context_unpin(struct drm_i915_gem_request 
*rq)
if (ctx_obj) {
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
if (--rq->ctx->engine[ring->id].pin_count == 0) {
-   intel_unpin_ringbuffer_obj(ringbuf);
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
i915_gem_object_ggtt_unpin(ctx_obj);
}
}
@@ -2369,7 +2388,7 @@ void intel_lr_context_free(struct intel_context *ctx)
struct intel_engine_cs *ring = ringbuf->ring;
 
if (ctx == ring->default_context) {
-   intel_unpin_ringbuffer_obj(ringbuf);
+   i915_gem_object_ggtt_unpin(ringbuf->obj);
i915_gem_object_ggtt_unpin(ctx_obj);
}
WARN_ON(ctx->engine[ring->id].pin_count);
@@ -2536,5 +2555,8 @@ void 

[Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles

[Nick Hoath]

There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support.  As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.

Added a context complete flag to a request which gets set during the
context switch interrupt.

Added a function i915_gem_request_retireable().  A request is considered
retireable if its seqno passed (i.e. the request has completed) and either
it was never submitted to the ELSP or its context completed.  This ensures
that context save is carried out before the last request for a context is
considered retireable.  retire_requests_ring() now uses
i915_gem_request_retireable() rather than request_complete() when deciding
which requests to retire. Requests that were not waiting for a context
switch interrupt (either as a result of being merged into a following
request or by being a legacy request) will be considered retireable as
soon as their seqno has passed.

Removed the extra request reference held for the execlist request.

Removed intel_execlists_retire_requests() and all references to
intel_engine_cs.execlist_retired_req_list.

Moved context unpinning into retire_requests_ring() for now.  Further work
is pending for the context pinning - this patch should allow us to use the
active list to track context and ring buffer objects later.

Changed gen8_cs_irq_handler() so that notify_ring() is called when
contexts complete as well as when a user interrupt occurs so that
notification happens when a request is complete and context save has
finished.

v2: Rebase over the read-read optimisation changes

v3: Reworked IRQ handler after removing IRQ handler cleanup patch

v4: Fixed various pin leaks

Issue: VIZ-4277
Signed-off-by: Thomas Daniel 
Signed-off-by: Nick Hoath 
---
 drivers/gpu/drm/i915/i915_drv.h |  6 +++
 drivers/gpu/drm/i915/i915_gem.c | 67 +--
 drivers/gpu/drm/i915/i915_irq.c | 81 +
 drivers/gpu/drm/i915/intel_lrc.c| 43 +++--
 drivers/gpu/drm/i915/intel_lrc.h|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 6 files changed, 118 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fbf0ae9..3d217f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2262,6 +2262,12 @@ struct drm_i915_gem_request {
/** Execlists no. of times this request has been sent to the ELSP */
int elsp_submitted;
 
+   /**
+* Execlists: whether this requests's context has completed after
+* submission to the ELSP
+*/
+   bool ctx_complete;
+
 };
 
 int i915_gem_request_alloc(struct intel_engine_cs *ring,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 52642af..fc82171 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1386,6 +1386,24 @@ __i915_gem_request_retire__upto(struct 
drm_i915_gem_request *req)
   typeof(*tmp), list);
 
i915_gem_request_retire(tmp);
+
+   if (i915.enable_execlists) {
+   struct intel_context *ctx = tmp->ctx;
+   struct drm_i915_private *dev_priv =
+   engine->dev->dev_private;
+   unsigned long flags;
+   struct drm_i915_gem_object *ctx_obj =
+   ctx->engine[engine->id].state;
+
+   spin_lock_irqsave(>execlist_lock, flags);
+
+   if (ctx_obj && (ctx != engine->default_context))
+   intel_lr_context_unpin(tmp);
+
+   intel_runtime_pm_put(dev_priv);
+   spin_unlock_irqrestore(>execlist_lock, flags);
+   }
+
} while (tmp != req);
 
WARN_ON(i915_verify_lists(engine->dev));
@@ -2359,6 +2377,12 @@ void i915_vma_move_to_active(struct i915_vma *vma,
list_move_tail(>mm_list, >vm->active_list);
 }
 
+static bool i915_gem_request_retireable(struct drm_i915_gem_request *req)
+{
+   return (i915_gem_request_completed(req, true) &&
+   (!req->elsp_submitted || req->ctx_complete));
+}
+
 static void
 i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
 {
@@ -2829,10 +2853,28 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
*ring)
   struct drm_i915_gem_request,
   list);
 
-   if (!i915_gem_request_completed(request, true))
+   if (!i915_gem_request_retireable(request))
break;
 
i915_gem_request_retire(request);
+
+   if 

[Intel-gfx] [PATCH 3/4] drm/i915: Add the CPU mapping of the hw context to the pinned items.

[Nick Hoath]

Pin the hw ctx mapping so that it is not mapped/unmapped per bb
when doing GuC submission.

Issue: VIZ-4277
Cc: David Gordon 
Signed-off-by: Nick Hoath 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 --
 drivers/gpu/drm/i915/i915_drv.h |  4 ++-
 drivers/gpu/drm/i915/intel_lrc.c| 56 +++--
 3 files changed, 50 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3f2a7a7..e68cf5fa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1970,10 +1970,9 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
 
 static void i915_dump_lrc_obj(struct seq_file *m,
  struct intel_engine_cs *ring,
- struct drm_i915_gem_object *ctx_obj)
+ struct drm_i915_gem_object *ctx_obj,
+ uint32_t *reg_state)
 {
-   struct page *page;
-   uint32_t *reg_state;
int j;
unsigned long ggtt_offset = 0;
 
@@ -1996,17 +1995,13 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
-   if (!WARN_ON(page == NULL)) {
-   reg_state = kmap_atomic(page);
-
+   if (!WARN_ON(reg_state == NULL)) {
for (j = 0; j < 0x600 / sizeof(u32) / 4; j += 4) {
seq_printf(m, "\t[0x%08lx] 0x%08x 0x%08x 0x%08x 
0x%08x\n",
   ggtt_offset + 4096 + (j * 4),
   reg_state[j], reg_state[j + 1],
   reg_state[j + 2], reg_state[j + 3]);
}
-   kunmap_atomic(reg_state);
}
 
seq_putc(m, '\n');
@@ -2034,7 +2029,8 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
for_each_ring(ring, dev_priv, i) {
if (ring->default_context != ctx)
i915_dump_lrc_obj(m, ring,
- ctx->engine[i].state);
+ ctx->engine[i].state,
+ ctx->engine[i].reg_state);
}
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d660ee3..b49fd12 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,8 +879,10 @@ struct intel_context {
} legacy_hw_ctx;
 
/* Execlists */
-   struct {
+   struct intel_context_engine {
struct drm_i915_gem_object *state;
+   uint32_t *reg_state;
+   struct page *page;
struct intel_ringbuffer *ringbuf;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b807928..55a4de56 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -360,16 +360,13 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
struct drm_i915_gem_object *rb_obj = rq->ringbuf->obj;
-   struct page *page;
-   uint32_t *reg_state;
+   uint32_t *reg_state = rq->ctx->engine[ring->id].reg_state;
 
BUG_ON(!ctx_obj);
+   WARN_ON(!reg_state);
WARN_ON(!i915_gem_obj_is_pinned(ctx_obj));
WARN_ON(!i915_gem_obj_is_pinned(rb_obj));
 
-   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
-   reg_state = kmap_atomic(page);
-
reg_state[CTX_RING_TAIL+1] = rq->tail;
reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(rb_obj);
 
@@ -385,8 +382,6 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
ASSIGN_CTX_PDP(ppgtt, reg_state, 0);
}
 
-   kunmap_atomic(reg_state);
-
return 0;
 }
 
@@ -1004,7 +999,31 @@ int logical_ring_flush_all_caches(struct 
drm_i915_gem_request *req)
return 0;
 }
 
-static int intel_lr_context_do_pin(struct intel_engine_cs *ring,
+static int intel_mmap_hw_context(struct drm_i915_gem_object *obj,
+   bool unmap)
+{
+   int ret = 0;
+   struct intel_context_engine *ice =
+   (struct intel_context_engine *)obj->mappable;
+   struct page *page;
+   uint32_t *reg_state;
+
+   if (unmap) {
+   kunmap(ice->page);
+   ice->reg_state = NULL;
+   ice->page = NULL;
+   } else {
+   page = i915_gem_object_get_page(obj, LRC_STATE_PN);
+   reg_state = kmap(page);
+   ice->reg_state = reg_state;
+   ice->page = page;
+   }

[Intel-gfx] [PATCH 4/4] drm/i915: Only update ringbuf address when necessary

[Nick Hoath]

We now only need to update the address of the ringbuf object in the
hw context when it is pinned, and the hw context is first CPU mapped

Issue: VIZ-4277
Cc: David Gordon 
Signed-off-by: Nick Hoath 
---
 drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 55a4de56..92a0ece 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -368,7 +368,6 @@ static int execlists_update_context(struct 
drm_i915_gem_request *rq)
WARN_ON(!i915_gem_obj_is_pinned(rb_obj));
 
reg_state[CTX_RING_TAIL+1] = rq->tail;
-   reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(rb_obj);
 
if (ppgtt && !USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
/* True 32b PPGTT with dynamic page allocation: update PDP
@@ -1046,6 +1045,9 @@ static int intel_lr_context_do_pin(
if (ret)
goto unpin_rb_obj;
 
+   ctx->engine[ring->id].reg_state[CTX_RING_BUFFER_START+1] =
+   i915_gem_obj_ggtt_offset(ringbuf->obj);
+
ctx_obj->dirty = true;
 
/* Invalidate GuC TLB. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] periodic wakeup from DPMS suspend

[Alex Deucher]

On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach  wrote:
> Hi,
>
> I have a NEC EA244WMi monitor connected to an Asus P8H77-V
> mainboard with Ivy Bridge Core i5-3550 via DVI.
> If DPMS suspend is enabled (by xscreensaver, or for testing by
> "xset dpms force off/suspend/standby"), the monitor
> enters standby mode but wakes up every 10...30 seconds for
> 6 seconds to display a "DVI-D: no signal" message.
>
> How can I find out if this is an issue of the NEC monitor
> or the Intel graphics?
>
> - when I pull the DVI cable the monitor stays in suspend
>
> - I tried to use drm.debug=6 and ftrace to see if something
>   is periodically accessing DDC or similar, but it didn't
>   reveal anything to me, but then I know nothing about
>   graphics drivers and probably didn't do it right
>
> I noticed there is some hotplug detection code,
> my initial thought was that this could cause the
> wakeup.  But since the period is somewhat irregular
> maybe it is some floating signal line causing the
> monitor to misdetect activity?
>
> Currently I'm running 4.2.3, but the same issue
> happens with older kernels, I tried 3.17+.
>
> Let me know if you have any ideas what to try.

Some monitors periodically scan all of their inputs if they are not
actively being driven by anything to try and automatically switch to
the connected input.  When the monitor scans the DVI input, it sees
load on the pins and turns on, only to realize it's not getting a
signal and then turns off.  If your monitor has an option to turn off
input probing, that might help.

Alex


>
>
>
>
>
> BTW, in sysfs the output shows up as HDMI-A-2:
> (the board has VGA, DVI, HDMI and DP)
>
> $ find /sys -name edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-1/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-3/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-1/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-2/edid
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3/edid
>
> Another observation is that the HDMI-A-* outputs don't
> have an i2c node to link the matching DDC channel,
> while the DP outputs have?
>
> $ grep . /sys/class/i2c-dev/i2c-*/name
> /sys/class/i2c-dev/i2c-0/name:i915 gmbus ssc
> /sys/class/i2c-dev/i2c-1/name:i915 gmbus vga
> /sys/class/i2c-dev/i2c-2/name:i915 gmbus panel
> /sys/class/i2c-dev/i2c-3/name:i915 gmbus dpc
> /sys/class/i2c-dev/i2c-4/name:i915 gmbus dpb
> /sys/class/i2c-dev/i2c-5/name:i915 gmbus dpd
> /sys/class/i2c-dev/i2c-6/name:DPDDC-B
> /sys/class/i2c-dev/i2c-7/name:DPDDC-C
> /sys/class/i2c-dev/i2c-8/name:DPDDC-D
>
> The monitor brightness can be controlled via
> /dev/i2c-3 with ddccontrol.
>
>
> TIA,
> Johannes
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915/bxt: Set time interval unit to 0.833us

[Imre Deak]

On pe, 2015-09-18 at 23:39 +0530, Sagar Arun Kamble wrote:
> From: Akash Goel 
> 
> Signed-off-by: Ankitprasad Sharma 
> Signed-off-by: Akash Goel 
> Signed-off-by: Sagar Arun Kamble 

The comment about units in gen6_set_rps_thresholds() is outdated, so you
could update that while at it. In any case this looks ok, so:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 67bf205..6b1998c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2802,8 +2802,11 @@ enum skl_disp_power_wells {
>  
>  #define INTERVAL_1_28_US(us) (((us) * 100) >> 7)
>  #define INTERVAL_1_33_US(us) (((us) * 3)   >> 2)
> +#define INTERVAL_0_833_US(us)(((us) * 6) / 5)
>  #define GT_INTERVAL_FROM_US(dev_priv, us) (IS_GEN9(dev_priv) ? \
> - INTERVAL_1_33_US(us) : \
> + (IS_BROXTON(dev_priv) ? \
> + INTERVAL_0_833_US(us) : \
> + INTERVAL_1_33_US(us)) : \
>   INTERVAL_1_28_US(us))
>  
>  /*


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

[Ville Syrjälä]

On Tue, Oct 06, 2015 at 04:43:11PM +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Ville Syrjälä  wrote:
> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> >> Prefer inclusive ranges for revision checks rather than "below B0". Per
> >> specs A2 is not used, so revid <= A1 matches revid < B0.
> >
> > The w/a db would say UNTIL_B0 etc., so might be easier to check against
> > it if we keep to the same convention.
> 
> So I wanted to double check what the convention is. I picked
> WaRsDisableCoarsePowerGating.
> 
> KBL - SIWA_FOREVER
> BXT - SI_WA_BEFORE(BXT_REV_ID_B0)
> SKL - SIWA_UNTIL_SKL_E0
> 
> Description "Disable coarse power gating for GT4 until GT F0 stepping."
> 
> *rolls eyes*
> 
> So is that "until" there inclusive or non-inclusive? The db is
> contradicting itself...

Hmm. My recollection was that it's exclusive, but now that I look at
your findings and some other workarounds, it does look a bit more like
inclusive.

I would think the exclusive thing would be easier to maintain since
the hsd specifies the stepping in which stuff got fixed, and the
exclusive convention would then have the same stepping listed. Eg. if
the hsd says fixed in E0, but the w/a db says UNTIL_D0, then one is
left wondering about D1+ But perhaps such steppings didn't even exist.

Well, in reality it's all over the place. Eg. looking at the BDW UNTIL_D0
stuff, some are fixed in E0, some are fixed in D0, and at least one was
fixed in B0 according to hsd. So I'm starting to think that the meaning
of the tag depends entirely on the person who pushed the change.

> Cc: Sarah who has also looked at workarounds
> recently.
> 
> Rodrigo, for one thing, I'll want workarounds for SKL and KBL in
> different conditions instead of conflated into SKL!
> 
> But what about this non-inclusive end of range? It'll matter in patch
> 3/3. It's not so much a problem for ranges, but rather for specific
> revisions, where you'd have to include a revision not mentioned in the
> spec at all, e.g. for B0 only:
> 
>   IS_SKL_REVID(dev, SKL_REVID_B0, SKL_REVID_C0)
> 
> instead of the current proposal:
> 
>   IS_SKL_REVID(dev, SKL_REVID_B0, SKL_REVID_B0)
> 
> I'm not really fond of adding separate macros for checking specific
> vs. ranges.
> 
> Thoughts?
> 
> BR,
> Jani.
> 
> 
> 
> 
> 
> >
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h| 1 +
> >>  drivers/gpu/drm/i915/i915_gem.c| 2 +-
> >>  drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> >>  drivers/gpu/drm/i915/intel_ddi.c   | 2 +-
> >>  drivers/gpu/drm/i915/intel_dp.c| 2 +-
> >>  drivers/gpu/drm/i915/intel_hdmi.c  | 2 +-
> >>  drivers/gpu/drm/i915/intel_lrc.c   | 8 
> >>  drivers/gpu/drm/i915/intel_pm.c| 6 +++---
> >>  drivers/gpu/drm/i915/intel_ringbuffer.c| 6 +++---
> >>  9 files changed, 16 insertions(+), 15 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index a3b137715604..9833a2055930 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2509,6 +2509,7 @@ struct drm_i915_cmd_table {
> >>  #define SKL_REVID_F0  0x5
> >>  
> >>  #define BXT_REVID_A0  0x0
> >> +#define BXT_REVID_A1  0x1
> >>  #define BXT_REVID_B0  0x3
> >>  #define BXT_REVID_C0  0x9
> >>  
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index f0cfbb9ee12c..fd2d880656b2 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -3757,7 +3757,7 @@ int i915_gem_set_caching_ioctl(struct drm_device 
> >> *dev, void *data,
> >> * cacheline, whereas normally such cachelines would get
> >> * invalidated.
> >> */
> >> -  if (IS_BROXTON(dev) && INTEL_REVID(dev) < BXT_REVID_B0)
> >> +  if (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A1)
> >>return -ENODEV;
> >>  
> >>level = I915_CACHE_LLC;
> >> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >> b/drivers/gpu/drm/i915/i915_guc_submission.c
> >> index 036b42bae827..863aa5c82466 100644
> >> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >> @@ -161,7 +161,7 @@ static int host2guc_sample_forcewake(struct intel_guc 
> >> *guc,
> >>data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
> >>/* WaRsDisableCoarsePowerGating:skl,bxt */
> >>if (!intel_enable_rc6(dev_priv->dev) ||
> >> -  (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
> >> +  (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_A1)) ||
> >>(IS_SKL_GT3(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)) ||
> >>(IS_SKL_GT4(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0)))
> >>data[1] = 0;
> 

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Jani Nikula]

On Mon, 05 Oct 2015, Imre Deak  wrote:
> On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
>> Mostly reuse what is programmed by pre-os, but in case there is no
>> pre-os initialization, init the cdclk with the default value.
>> 
>> Cc: Imre Deak 
>> Signed-off-by: Shobhit Kumar 
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 2d3cc82..675c60d 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
>>  
>>  cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
>>  dev_priv->skl_boot_cdclk = cdclk_freq;
>> -if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
>> -DRM_ERROR("LCPLL1 is disabled\n");
>> -else
>> -intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
>> +
>> +skl_init_cdclk(dev_priv);
>
> How does this prevent changing the clock if BIOS did enable some output?
> We shouldn't change the clock in that case.

Random comment from the back, what about intentional cdclk change on
module load? We're supposed to have that for bdw [1] but last I checked
it failed... [2].

BR,
Jani.

[1] http://mid.gmane.org/145514-4156-8-git-send-email-mika.kah...@intel.com
[2] http://mid.gmane.org/87bngf4xk3@intel.com


>
>>  } else if (IS_BROXTON(dev)) {
>>  broxton_init_cdclk(dev);
>>  broxton_ddi_phy_init(dev);
>
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BXT MIPI PATCH v5 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

[Jani Nikula]

On Mon, 05 Oct 2015, "Shankar, Uma"  wrote:
>>-Original Message-
>>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>>Sent: Friday, October 2, 2015 6:05 PM
>>To: Shankar, Uma
>>Cc: intel-gfx@lists.freedesktop.org; Kumar, Shobhit
>>Subject: Re: [Intel-gfx] [BXT MIPI PATCH v5 05/14] drm/i915/bxt: DSI encoder
>>support in CRTC modeset
>>
>>On Thu, Oct 01, 2015 at 10:23:49PM +0530, Uma Shankar wrote:
>>> From: Shashank Sharma 
>>>
>>> SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
>>> functions are re-used for modeset sequence. But DDI interface doesn't
>>> include support for DSI.
>>> This patch adds:
>>> 1. cases for DSI encoder, in those modeset functions and allows
>>>a CRTC modeset
>>> 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
>>>needs to be done as such in CRTC for DSI encoder, as PLL, clock
>>>and and transcoder programming will be taken care in encoder's
>>>pre_enable and pre_pll_enable function.
>>>
>>> v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
>>> encoder like DSI for platforms having HAS_DDI as true.
>>>
>>> v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
>>> encoder.
>>>
>>> v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion.
>>> Fixed the sequence for pre_pll_enable.
>>>
>>> v5: Protected DDI code paths in case of DSI encoder calls.
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Uma Shankar 
>>
>>Ok, after this patch we get stuff like this:
>>
>>  for_each_encoder_on_crtc(dev, crtc, encoder) {
>>  if (encoder->pre_pll_enable)
>>  encoder->pre_pll_enable(encoder);
>>  if (encoder->pre_enable)
>>  encoder->pre_enable(encoder);
>>  }
>>
>>  if (intel_crtc->config->has_pch_encoder) {
>>  intel_set_pch_fifo_underrun_reporting(dev_priv,
>>TRANSCODER_A,
>>true);
>>  dev_priv->display.fdi_link_train(crtc);
>>  }
>>
>>  if (!is_dsi)
>>  intel_ddi_enable_pipe_clock(intel_crtc);
>>
>>1. Please remove pre_pll_enable again, we don't need 2 callbacks in exactly 
>>the
>>same spot. Yes this might mean that you need special bxt_ versions of that in 
>>the
>>dsi encoder, we have that everywhere.
>>
>>2. the has_pch_encoder is already something encoder-specific (it's exclusively
>>used by the HSW LPT CRT encoder). Now we have another one of those for the
>>!is_dsi case. These special-cases should be moved into the
>>encoder->pre_enable callbacks, that's what they're for.
>>
>>I'm not going to block these patches are (18months is already ridiculous), 
>>but I
>>want this cleanup done. Uma, can you pls own this? If you can't do it yourself
>>please escalate to Indranil so he can find someone.
>>
>>Thanks, Daniel
>>
>
> Hi Daniel,
> I will discuss with Indranil and will get this done. 
>
> Thanks for your support in getting the video mode patches merged.

I'll do the cleanups, don't worry about it.

BR,
Jani.


>
> Regards,
> Uma Shankar
>
>>> ---
>>>  drivers/gpu/drm/i915/intel_ddi.c  |7 +--
>>>  drivers/gpu/drm/i915/intel_display.c  |   21 +++--
>>>  drivers/gpu/drm/i915/intel_opregion.c |9 +++--
>>>  3 files changed, 27 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index cacb07b..7b7f544 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -390,8 +390,10 @@ void intel_prepare_ddi(struct drm_device *dev)
>>> enum port port;
>>> bool supports_hdmi;
>>>
>>> -   ddi_get_encoder_port(intel_encoder, _dig_port, );
>>> +   if (intel_encoder->type == INTEL_OUTPUT_DSI)
>>> +   continue;
>>>
>>> +   ddi_get_encoder_port(intel_encoder, _dig_port, );
>>> if (visited[port])
>>> continue;
>>>
>>> @@ -1779,7 +1781,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder
>>> *encoder,  void intel_ddi_enable_pipe_clock(struct intel_crtc
>>> *intel_crtc)  {
>>> struct drm_crtc *crtc = _crtc->base;
>>> -   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
>>> +   struct drm_device *dev = crtc->dev;
>>> +   struct drm_i915_private *dev_priv = dev->dev_private;
>>> struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
>>> enum port port = intel_ddi_get_encoder_port(intel_encoder);
>>> enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index b8e0310..ea0f533 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/kbl: Kabylake A0 is based on Skylake H0.

[Rodrigo Vivi]

cc'ing Ben to get his opinion...

On Tue, Oct 6, 2015 at 10:43 AM Vivi, Rodrigo 
wrote:

> On Tue, 2015-10-06 at 12:24 +0300, Jani Nikula wrote:
> > On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> > > Kabylake is gen 9.5 derivated from Skylake H0 stepping.
> > >
> > > So we don't need pre-production Skylake workaround and also
> > > firmware loading will use SKL H0 offsets.
> > >
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 7374a0d..580c005 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2436,7 +2436,6 @@ struct drm_i915_cmd_table {
> > >  })
> > >  #define INTEL_INFO(p)  (&__I915__(p)->info)
> > >  #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
> > > -#define INTEL_REVID(p) (__I915__(p)->dev->pdev->revision)
> > >
> > >  #define IS_I830(dev)   (INTEL_DEVID(dev) == 0x3577)
> > >  #define IS_845G(dev)   (INTEL_DEVID(dev) == 0x2562)
> > > @@ -2508,6 +2507,9 @@ struct drm_i915_cmd_table {
> > >
> > >  #define IS_PRELIMINARY_HW(intel_info) ((intel_info)
> > > ->is_preliminary)
> > >
> > > +#define INTEL_REVID(p) (__I915__(p)->dev->pdev->revision +
> > > \
> > > +IS_KABYLAKE(p) ? 7 : 0)
> > > +
> >
> > I am not fond of this at all. It will be really confusing that
> > ->revision is different from INTEL_REVID when checking the
> > workarounds,
> > and that you'll be using SKL_REVID_* to match KBL revision
> > ids.
>
> this is exactly one of the reasons why I did this sum in this way so
> they never match...
>
> > Additionally, we'll probably want to start removing SKL workarounds
> > before KBL workarounds.
>
> I believe this is another discussion... On HSW BDW I remember I was
> removing old Wa as it was no longer needed, but on SKL I saw this REVID
> and I believed the idea was to let them there since some devs might be
> using preliminary platforms yet for other reasons... I don't see a
> problem of letting the old W/a there.
>
> >
> > Others may disagree, but I'd like KBL revid checks be different from
> > SKL.
> >
> > >  #define SKL_REVID_A0   (0x0)
> > >  #define SKL_REVID_B0   (0x1)
> > >  #define SKL_REVID_C0   (0x2)
> > > @@ -2515,6 +2517,9 @@ struct drm_i915_cmd_table {
> > >  #define SKL_REVID_E0   (0x4)
> > >  #define SKL_REVID_F0   (0x5)
> > >
> > > +/* KBL A0 is based on SKL H0 */
> > > +#define KBL_REVID_A0   (0x7)
> >
> > You can't compare this against INTEL_REVID() now can you...? Or is
> > this
> > not the one in the spec? Confused already.
>
> Yes, this is confusing indeed. It seems that we have many levels of
> steppings (according to platform guys) and this platform stepping
> returning 0 is our KBL A0, but this correspond to our internal gpu
> stepping H0 (same going to skl h0).
>
> Like dmc firmware loading for instance we need to load the firmware for
> stepping 7.
>
> So yes, this definition matches BSPec KBL A0.
>
> >
> > BR,
> > Jani.
> >
> > > +
> > >  #define BXT_REVID_A0   (0x0)
> > >  #define BXT_REVID_B0   (0x3)
> > >  #define BXT_REVID_C0   (0x9)
> > > --
> > > 2.4.3
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [DMC_REDESIGN_V2 07/14] drm/i915/gen9: Simplify csr loading failure printing.

[Marc Herbert]

On 30/09/15 07:28, Imre Deak wrote:

On ke, 2015-08-26 at 16:58 +0530, Animesh Manna wrote:


-void i915_firmware_load_error_print(const char *fw_path, int err)
-{
-   DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
-
-   /*
-* If the reason is not known assume -ENOENT since that's the most
-* usual failure mode.
-*/
-   if (!err)
-   err = -ENOENT;
-
-   if (!(IS_BUILTIN(CONFIG_DRM_I915) && err == -ENOENT))
-   return;
-
-   DRM_ERROR(
- "The driver is built-in, so to load the firmware you need to\n"
- "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE) or\n"
- "in your initrd/initramfs image.\n");
-}
-


The point here was to clarify the reason why the loading failed, since
that caused quite a confusion. It was a separate function since the same
could've been called from the GuC loader too. I think the error message
would be still useful.


Agreed 100%. The code of this function was a bit confusing, however this 
error message has proved very useful "on the field" many times already. 
Please preserve the message.



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915/kbl: Add Kabylake PCI ID

[Ville Syrjälä]

On Tue, Oct 06, 2015 at 12:09:17PM +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> > From: Deepak S 
> >
> > v2: separate out device info into different GT (Damien)
> > v3: Add is_kabylake to the KBL gt3 structuer (Damien)
> > Sort the platforms in older -> newer order (Damien)
> >
> > Reviewed-by: Damien Lespiau 
> > Signed-off-by: Deepak S 
> > Signed-off-by: Damien Lespiau 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 33 -
> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
> >  include/drm/i915_pciids.h   | 29 +
> >  3 files changed, 63 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1cb6b82..f42102d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -394,6 +394,34 @@ static const struct intel_device_info 
> > intel_broxton_info = {
> > IVB_CURSOR_OFFSETS,
> >  };
> >  
> > +static const struct intel_device_info intel_kabylake_info = {
> > +   .is_preliminary = 1,
> > +   .is_skylake = 1,
> 
> Now's the time to call the shots, is this really a good idea or not? See
> VLV vs. CHV, we (okay, the royal we) still confuse ourselves with
> IS_VALLEYVIEW.
> 
> Granted, 74 call sites for IS_SKYLAKE(), all of those would need to be
> patched. We'd need something like "is skylake family" including SKL and
> KBL.

That would be just gen>=9 in most case, with potentially BXT handled
first as the special case. So maybe not much better than IS_SKYLAKE
being true for KBL.

Maybe it's best to just have IS_KABYLAKE and go through all the
IS_SKYLAKE checks and add BKL where needed (or change to gen>=9 if
that's OK).

I'm pretty sure I once did a patch to split IS_CHERRYVIEW from
IS_VALLEYVIEW, but I'm not sure where I stashed the work. Maybe I
should dig it up to get rid of the bad example?

> Some of them might be changed to be more like feature flags, which
> is something we've decided we need to do more anyway.

I've also thought about adding a chipset/platform enum or something where
the platforms would sit in some sort of logical order. So mostly a .gen
except we could actually tell apart the .5 gens and whatnot. Might make
the code a bit nicer since we would say eg. '>= HSW' instead of
'gen >= 8 || HSW', but maybe it wouldn't do much else for us. VLV/CHV
would still be fairly problematic since the display gen is so different
from the gt gen.

> 
> BR,
> Jani.
> 
> 
> > +   .is_kabylake = 1,
> > +   .gen = 9, .num_pipes = 3,
> > +   .need_gfx_hws = 1, .has_hotplug = 1,
> > +   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> > +   .has_llc = 1,
> > +   .has_ddi = 1,
> > +   .has_fbc = 1,
> > +   GEN_DEFAULT_PIPEOFFSETS,
> > +   IVB_CURSOR_OFFSETS,
> > +};
> > +
> > +static const struct intel_device_info intel_kabylake_gt3_info = {
> > +   .is_preliminary = 1,
> > +   .is_skylake = 1,
> > +   .is_kabylake = 1,
> > +   .gen = 9, .num_pipes = 3,
> > +   .need_gfx_hws = 1, .has_hotplug = 1,
> > +   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> > +   .has_llc = 1,
> > +   .has_ddi = 1,
> > +   .has_fbc = 1,
> > +   GEN_DEFAULT_PIPEOFFSETS,
> > +   IVB_CURSOR_OFFSETS,
> > +};
> > +
> >  /*
> >   * Make sure any device matches here are from most specific to most
> >   * general.  For example, since the Quanta match is based on the subsystem
> > @@ -434,7 +462,10 @@ static const struct intel_device_info 
> > intel_broxton_info = {
> > INTEL_SKL_GT1_IDS(_skylake_info), \
> > INTEL_SKL_GT2_IDS(_skylake_info), \
> > INTEL_SKL_GT3_IDS(_skylake_gt3_info), \
> > -   INTEL_BXT_IDS(_broxton_info)
> > +   INTEL_BXT_IDS(_broxton_info), \
> > +   INTEL_KBL_GT1_IDS(_kabylake_info),\
> > +   INTEL_KBL_GT2_IDS(_kabylake_info),\
> > +   INTEL_KBL_GT3_IDS(_kabylake_gt3_info)
> >  
> >  static const struct pci_device_id pciidlist[] = {  /* aka */
> > INTEL_PCI_IDS,
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 824e724..f7e9d7e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -765,6 +765,7 @@ struct intel_csr {
> > func(is_valleyview) sep \
> > func(is_haswell) sep \
> > func(is_skylake) sep \
> > +   func(is_kabylake) sep \
> > func(is_preliminary) sep \
> > func(has_fbc) sep \
> > func(has_pipe_cxsr) sep \
> > @@ -2464,6 +2465,7 @@ struct drm_i915_cmd_table {
> >  #define IS_BROADWELL(dev)  (!INTEL_INFO(dev)->is_valleyview && 
> > IS_GEN8(dev))
> >  #define IS_SKYLAKE(dev)(INTEL_INFO(dev)->is_skylake)
> >  #define IS_BROXTON(dev)(!INTEL_INFO(dev)->is_skylake && IS_GEN9(dev))
> > +#define IS_KABYLAKE(dev)   

Re: [Intel-gfx] [PATCH 3/5] drm/i915/kbl: Kabylake A0 is based on Skylake H0.

[Ben Widawsky]

On Tue, Oct 06, 2015 at 08:51:13PM +, Rodrigo Vivi wrote:
> cc'ing Ben to get his opinion...
> 

Of course anything is possible wrt the delta of KBL features vs SKL. With the
knowledge we have, we can make a pretty educated guess that there will be no
changes, and with an equally high level of confidence say that if there are
changes, they will be very minor and self contained.

I am in favor of this minimalistic patch myself. I think both the result, and
reduced amount of churn make this patch favorable to the requested alternative.
Some finer comments below.

> On Tue, Oct 6, 2015 at 10:43 AM Vivi, Rodrigo 
> wrote:
> 
> > On Tue, 2015-10-06 at 12:24 +0300, Jani Nikula wrote:
> > > On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> > > > Kabylake is gen 9.5 derivated from Skylake H0 stepping.

Don't call it 9.5... some people don't like that... Just say it's a SKL
derivative.

> > > >
> > > > So we don't need pre-production Skylake workaround and also
> > > > firmware loading will use SKL H0 offsets.

In fact we know some of these workarounds to be harmful.

> > > >
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 7374a0d..580c005 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2436,7 +2436,6 @@ struct drm_i915_cmd_table {
> > > >  })
> > > >  #define INTEL_INFO(p)  (&__I915__(p)->info)
> > > >  #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
> > > > -#define INTEL_REVID(p) (__I915__(p)->dev->pdev->revision)
> > > >
> > > >  #define IS_I830(dev)   (INTEL_DEVID(dev) == 0x3577)
> > > >  #define IS_845G(dev)   (INTEL_DEVID(dev) == 0x2562)
> > > > @@ -2508,6 +2507,9 @@ struct drm_i915_cmd_table {
> > > >
> > > >  #define IS_PRELIMINARY_HW(intel_info) ((intel_info)
> > > > ->is_preliminary)
> > > >
> > > > +#define INTEL_REVID(p) (__I915__(p)->dev->pdev->revision +
> > > > \
> > > > +IS_KABYLAKE(p) ? 7 : 0)
> > > > +
> > >
> > > I am not fond of this at all. It will be really confusing that
> > > ->revision is different from INTEL_REVID when checking the
> > > workarounds,
> > > and that you'll be using SKL_REVID_* to match KBL revision
> > > ids.
> >
> > this is exactly one of the reasons why I did this sum in this way so
> > they never match...
> >

Jani, I do understand your distaste with this patch. However, I think this is a
very reasonable, and more importantly, readable wart in the code. It's very
obvious what and why the macro does what it does.

> > > Additionally, we'll probably want to start removing SKL workarounds
> > > before KBL workarounds.
> >

I don't see a reason for this. Maybe you have thought of something I haven't?
We're not using any of the early SKL workarounds on KBL as a result of this
patch, so it shouldn't matter.

> > I believe this is another discussion... On HSW BDW I remember I was
> > removing old Wa as it was no longer needed, but on SKL I saw this REVID
> > and I believed the idea was to let them there since some devs might be
> > using preliminary platforms yet for other reasons... I don't see a
> > problem of letting the old W/a there.
> >

I'm very much in favor of killing pre-production support (not that anyone
asked).

> > >
> > > Others may disagree, but I'd like KBL revid checks be different from
> > > SKL.
> > >
> > > >  #define SKL_REVID_A0   (0x0)
> > > >  #define SKL_REVID_B0   (0x1)
> > > >  #define SKL_REVID_C0   (0x2)
> > > > @@ -2515,6 +2517,9 @@ struct drm_i915_cmd_table {
> > > >  #define SKL_REVID_E0   (0x4)
> > > >  #define SKL_REVID_F0   (0x5)
> > > >
> > > > +/* KBL A0 is based on SKL H0 */
> > > > +#define KBL_REVID_A0   (0x7)
> > >
> > > You can't compare this against INTEL_REVID() now can you...? Or is
> > > this
> > > not the one in the spec? Confused already.
> >
> > Yes, this is confusing indeed. It seems that we have many levels of
> > steppings (according to platform guys) and this platform stepping
> > returning 0 is our KBL A0, but this correspond to our internal gpu
> > stepping H0 (same going to skl h0).
> >
> > Like dmc firmware loading for instance we need to load the firmware for
> > stepping 7.
> >
> > So yes, this definition matches BSPec KBL A0.
> >

Maybe amend the comment to say that the actual PCI header has revid 0 (or
whatever it was). With that, it's pretty clear - and yes, it is a value which
can and should be used to compare with INTEL_REVID, but as stated above, the
comparison isn't needed, and if/when it is, we can/should revisit the more
intrusive change you're suggesting.

___
Intel-gfx mailing 

Re: [Intel-gfx] [RFC 3/8] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check

[Daniel Vetter]

On Fri, Oct 02, 2015 at 06:03:57PM +0200, Egbert Eich wrote:
> Regarding commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b
> 
> On Wed, Jul 01, 2015 at 07:25:56PM -0700, Matt Roper wrote:
> > Determine whether we need to apply this workaround at atomic check time
> > and just set a flag that will be used by the main watermark update
> > routine.
> > 
> > Moving this workaround into the atomic framework reduces
> > ilk_update_sprite_wm() to just a standard watermark update, so drop it
> > completely and just ensure that ilk_update_wm() is called whenever a
> > sprite plane is updated in a way that would affect watermarks.
> > 
> > Signed-off-by: Matt Roper 
> 
> 
> This patch causes intel_update_watermarks() to be called much more
> frequently although the watermark values don't change. 
> The change responsible for this is:
> 
> > index 5de1ded..46ef981 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11560,23 +11560,38 @@ retry:
> >  static bool intel_wm_need_update(struct drm_plane *plane,
> >  struct drm_plane_state *state)
> >  {
> > -   /* Update watermarks on tiling changes. */
> > +   struct intel_plane_state *new = to_intel_plane_state(state);
> > +   struct intel_plane_state *cur = to_intel_plane_state(plane->state);
> > +
> > +   /* Update watermarks on tiling or size changes. */
> > if (!plane->state->fb || !state->fb ||
> > plane->state->fb->modifier[0] != state->fb->modifier[0] ||
> > -   plane->state->rotation != state->rotation)
> > -   return true;
> > -
> 
> > -   if (plane->state->crtc_w != state->crtc_w)
> 
> A quick look thru intel_pm.c reveals that this is  relevant for
> WM caluclations for gen=4 and any chipsets for which is_g4x is true.
> Should this really be removed?
> 
> > +   plane->state->rotation != state->rotation ||
> 
> > +   drm_rect_width(>src) != drm_rect_width(>src) ||
> > +   drm_rect_height(>src) != drm_rect_height(>src) ||
> > +   drm_rect_width(>dst) != drm_rect_width(>dst) ||
> > +   drm_rect_height(>dst) != drm_rect_height(>dst))
> 
> these values seem to be used only for watermark calculations on gen < 9 when
> HAS_PCH_SPLIT() is true.
> 
> Still these are responsible for most of the watermark recalculations (when 
> the mouse
> cursor is moved towards the edge for example). On the system I'm looking at 
> the moment
> (Q35) changes in these values don't change the WMs.
> 
> Since WM calculation is very chip generation specific and differs 
> considerably between
> generations, wouldn't it make sense to either have chipset specific functions 
> to determin
> whether a recalculation is needed - or even perfrom this in the update_wm() 
> function
> itself?

The chipset-specific functions to recalc wm values should check for any
real changes and no-op out if none of the registers have changed. The idea
is that wm calculations are really complex and trying to keep both the "do
we need to recalc" and the actual calculations perfectly in sync is a hard
problem. Hence why we recalc aggressively to avoid hard-to-find bugs where
wm values are stale. So overhead should be just a bit of wasted cpu time.
Do you see bad things happening because of all these recalculations?

I guess if it's real trouble we can make a special case for cursors on
pre-gen9 on plane window changes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Skip CHV PHY asserts until PHY has been fully reset

[Daniel Vetter]

On Mon, Oct 05, 2015 at 03:57:45PM +0530, Deepak wrote:
> 
> 
> On Tuesday 08 September 2015 08:35 PM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä 
> >
> >The BIOS can leave the CHV display PHY in some odd state where
> >some of the LDOs/lanes won't power down fully when unused. This
> >will trigger a host of asserts that were added in:
> >30142273a3e83936fd7b45aa5339311a9295ca51 drm/i915: Add CHV PHY LDO power 
> >sanity checks
> >6669e39f95b5530ca8cb9137703ceb5e83e5d648 drm/i915: Add some CHV DPIO lane 
> >power state asserts
> >
> >To avoid that, skip the asserts until the PHY power well has been
> >disabled at least once. That will fully reset the PHY, and once
> >brought back up, the dynamic power down features will work correctly.
> >
> >Signed-off-by: Ville Syrjälä 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h |  3 +++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 46 
> > -
> >  2 files changed, 48 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 503dff5..cf1880e 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -1956,6 +1956,9 @@ struct drm_i915_private {
> > bool edp_low_vswing;
> >+/* perform PHY state sanity checks? */
> >+bool chv_phy_assert[2];
> >+
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> >  * will be rejected. Instead look for a better place.
> >diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> >b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >index 3f682a1..a0a2e6d 100644
> >--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >@@ -987,8 +987,29 @@ static void assert_chv_phy_status(struct 
> >drm_i915_private *dev_priv)
> > lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_D);
> > u32 phy_control = dev_priv->chv_phy_control;
> > u32 phy_status = 0;
> >+u32 phy_status_mask = 0x;
> > u32 tmp;
> >+/*
> >+ * The BIOS can leave the PHY is some weird state
> >+ * where it doesn't fully power down some parts.
> >+ * Disable the asserts until the PHY has been fully
> >+ * reset (ie. the power well has been disabled at
> >+ * least once).
> >+ */
> >+if (!dev_priv->chv_phy_assert[DPIO_PHY0])
> >+phy_status_mask &= ~(PHY_STATUS_CMN_LDO(DPIO_PHY0, DPIO_CH0) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY0, DPIO_CH0, 
> >0) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY0, DPIO_CH0, 
> >1) |
> >+ PHY_STATUS_CMN_LDO(DPIO_PHY0, DPIO_CH1) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY0, DPIO_CH1, 
> >0) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY0, DPIO_CH1, 
> >1));
> >+
> >+if (!dev_priv->chv_phy_assert[DPIO_PHY1])
> >+phy_status_mask &= ~(PHY_STATUS_CMN_LDO(DPIO_PHY1, DPIO_CH0) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY1, DPIO_CH0, 
> >0) |
> >+ PHY_STATUS_SPLINE_LDO(DPIO_PHY1, DPIO_CH0, 
> >1));
> >+
> > if (cmn_bc->ops->is_enabled(dev_priv, cmn_bc)) {
> > phy_status |= PHY_POWERGOOD(DPIO_PHY0);
> >@@ -1049,11 +1070,13 @@ static void assert_chv_phy_status(struct 
> >drm_i915_private *dev_priv)
> > phy_status |= PHY_STATUS_SPLINE_LDO(DPIO_PHY1, 
> > DPIO_CH0, 1);
> > }
> >+phy_status &= phy_status_mask;
> >+
> > /*
> >  * The PHY may be busy with some initial calibration and whatnot,
> >  * so the power state can take a while to actually change.
> >  */
> >-if (wait_for((tmp = I915_READ(DISPLAY_PHY_STATUS)) == phy_status, 10))
> >+if (wait_for((tmp = I915_READ(DISPLAY_PHY_STATUS) & phy_status_mask) == 
> >phy_status, 10))
> > WARN(phy_status != tmp,
> >  "Unexpected PHY_STATUS 0x%08x, expected 0x%08x 
> > (PHY_CONTROL=0x%08x)\n",
> >  tmp, phy_status, dev_priv->chv_phy_control);
> >@@ -1146,6 +1169,9 @@ static void chv_dpio_cmn_power_well_disable(struct 
> >drm_i915_private *dev_priv,
> > DRM_DEBUG_KMS("Disabled DPIO PHY%d (PHY_CONTROL=0x%08x)\n",
> >   phy, dev_priv->chv_phy_control);
> >+/* PHY is fully reset now, so we can enable the PHY state asserts */
> >+dev_priv->chv_phy_assert[phy] = true;
> >+
> > assert_chv_phy_status(dev_priv);
> >  }
> >@@ -1155,6 +1181,16 @@ static void assert_chv_phy_powergate(struct 
> >drm_i915_private *dev_priv, enum dpi
> > enum pipe pipe = phy == DPIO_PHY0 ? PIPE_A : PIPE_C;
> > u32 reg, val, expected, actual;
> >+/*
> >+ * The BIOS can leave the PHY is some weird state
> >+ * where it doesn't fully power down some parts.
> >+ * Disable the asserts until the PHY has been 

Re: [Intel-gfx] [PATCH] drm/i915: Add GEN7_GPGPU_DISPATCHDIMX/Y/Z to the register whitelist

[Daniel Vetter]

On Fri, Oct 02, 2015 at 08:33:45AM -0700, Jordan Justen wrote:
> On 2015-10-02 01:06:01, Daniel Vetter wrote:
> > On Thu, Oct 01, 2015 at 11:09:58PM -0700, Jordan Justen wrote:
> > > This is required to support glDispatchComputeIndirect for gen7.
> > > 
> > > Signed-off-by: Jordan Justen 
> > > Reviewed-by: Kristian Høgsberg 
> > 
> > Do you have a link to the mesa patches? As soon as those are r-b'ed I'll
> > pull this in.
> 
> The patch that uses these registers in mesa is already upstream.
> 
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=ebbe6cdad7ab082d2b191fe6c7c0eaa6921d55de

This tends to royally piss of Dave, and last time around mesa was merged
before the kernel Dave just reverted everything and broke the mesa build.

Please never commit mesa patches before the kernel side has landed, ever.

I've pulled this one in here meanwhile to cover this up.
Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 3/3] gem_memory_bandwidth: Add test

[Daniel Vetter]

On Mon, Oct 05, 2015 at 02:42:25PM +0300, Antti Koskipaa wrote:
> This is a benchmark for testing the GPU read and write bandwidth.
> 
> Issue: VIZ-5664
> Signed-off-by: Antti Koskipaa 
> ---
>  tests/.gitignore |   1 +
>  tests/Makefile.sources   |   1 +
>  tests/gem_memory_bandwidth.c | 209 
> +++
>  3 files changed, 211 insertions(+)
>  create mode 100644 tests/gem_memory_bandwidth.c
> 
> diff --git a/tests/.gitignore b/tests/.gitignore
> index dc8bb53..2ea4107 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -65,6 +65,7 @@ gem_linear_blits
>  gem_lut_handle
>  gem_madvise
>  gem_media_fill
> +gem_memory_bandwidth
>  gem_mmap
>  gem_mmap_gtt
>  gem_mmap_offset_exhaustion
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 2e2e088..4429c29 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -36,6 +36,7 @@ TESTS_progs_M = \
>   gem_flink_race \
>   gem_linear_blits \
>   gem_madvise \
> + gem_memory_bandwidth \
>   gem_mmap \
>   gem_mmap_gtt \
>   gem_mmap_wc \
> diff --git a/tests/gem_memory_bandwidth.c b/tests/gem_memory_bandwidth.c
> new file mode 100644
> index 000..a44987e
> --- /dev/null
> +++ b/tests/gem_memory_bandwidth.c
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright © 2013-2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Antti Koskip?? 
> + *Damien Lespiau 
> + */
> +
> +/*
> + * We need a way to test memory bandwidth bottlenecks and understand better
> + * where they are. This test bypasses Mesa and uses the kernel GEM interface
> + * directly.
> + *
> + * Say there is a performance regression. Where is it, Mesa or kernel? Just
> + * compare the results of this test to the Mesa bandwidth results. If they 
> are
> + * similar, the problem is in the kernel. If Mesa is much slower than this 
> test,
> + * the problem is in Mesa.
> + */
> +
> +#include "igt.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "intel_bufmgr.h"
> +
> +IGT_TEST_DESCRIPTION("GPU memory bandwidth benchmark.");
> +
> +/* Each test block is 1 meg. */
> +#define WIDTH 512
> +#define STRIDE (WIDTH*4)
> +#define HEIGHT 512
> +#define SIZE (HEIGHT*STRIDE)
> +/* Run this many times. 10240 = 10 gigabytes are copied. 1024 was too small,
> + * giving too much variance. */
> +#define LOOPS 10240
> +/* How many buffers to allocate for main memory speed testing.
> + * Must be large enough to thrash the caches.
> + */
> +#define NBUFS 512
> +
> +#define SRC_COLOR0x00ff
> +#define DST_COLOR0xfff0ff00
> +
> +typedef struct {
> + int fd;
> + uint32_t devid;
> + drm_intel_bufmgr *bufmgr;
> + struct intel_batchbuffer *batch;
> + igt_render_copyfunc_t render_copy;
> + igt_render_copyfunc_t render_read;
> + igt_render_copyfunc_t render_write;
> + uint32_t linear[WIDTH * HEIGHT];
> +} data_t;
> +
> +static void data_init(data_t *data)
> +{
> + data->fd = drm_open_driver(DRIVER_INTEL);
> + data->devid = intel_get_drm_devid(data->fd);
> +
> + data->bufmgr = drm_intel_bufmgr_gem_init(data->fd, 4096);
> + igt_assert(data->bufmgr);
> +
> + data->render_copy = igt_get_render_copyfunc(data->devid);
> + igt_require_f(data->render_copy,
> +   "no render-copy function\n");
> + data->render_write = igt_get_render_writefunc(data->devid);
> + igt_require_f(data->render_write,
> +   "no render-write function\n");
> + data->render_read = igt_get_render_readfunc(data->devid);
> + igt_require_f(data->render_read,
> +   "no 

Re: [Intel-gfx] [PATCH 1/5] drm/i915/kbl: Add Kabylake PCI ID

[Jani Nikula]

On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> From: Deepak S 
>
> v2: separate out device info into different GT (Damien)
> v3: Add is_kabylake to the KBL gt3 structuer (Damien)
> Sort the platforms in older -> newer order (Damien)
>
> Reviewed-by: Damien Lespiau 
> Signed-off-by: Deepak S 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 33 -
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  include/drm/i915_pciids.h   | 29 +
>  3 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1cb6b82..f42102d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -394,6 +394,34 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   IVB_CURSOR_OFFSETS,
>  };
>  
> +static const struct intel_device_info intel_kabylake_info = {
> + .is_preliminary = 1,
> + .is_skylake = 1,

Now's the time to call the shots, is this really a good idea or not? See
VLV vs. CHV, we (okay, the royal we) still confuse ourselves with
IS_VALLEYVIEW.

Granted, 74 call sites for IS_SKYLAKE(), all of those would need to be
patched. We'd need something like "is skylake family" including SKL and
KBL. Some of them might be changed to be more like feature flags, which
is something we've decided we need to do more anyway.

BR,
Jani.


> + .is_kabylake = 1,
> + .gen = 9, .num_pipes = 3,
> + .need_gfx_hws = 1, .has_hotplug = 1,
> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> + .has_llc = 1,
> + .has_ddi = 1,
> + .has_fbc = 1,
> + GEN_DEFAULT_PIPEOFFSETS,
> + IVB_CURSOR_OFFSETS,
> +};
> +
> +static const struct intel_device_info intel_kabylake_gt3_info = {
> + .is_preliminary = 1,
> + .is_skylake = 1,
> + .is_kabylake = 1,
> + .gen = 9, .num_pipes = 3,
> + .need_gfx_hws = 1, .has_hotplug = 1,
> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> + .has_llc = 1,
> + .has_ddi = 1,
> + .has_fbc = 1,
> + GEN_DEFAULT_PIPEOFFSETS,
> + IVB_CURSOR_OFFSETS,
> +};
> +
>  /*
>   * Make sure any device matches here are from most specific to most
>   * general.  For example, since the Quanta match is based on the subsystem
> @@ -434,7 +462,10 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   INTEL_SKL_GT1_IDS(_skylake_info), \
>   INTEL_SKL_GT2_IDS(_skylake_info), \
>   INTEL_SKL_GT3_IDS(_skylake_gt3_info), \
> - INTEL_BXT_IDS(_broxton_info)
> + INTEL_BXT_IDS(_broxton_info), \
> + INTEL_KBL_GT1_IDS(_kabylake_info),\
> + INTEL_KBL_GT2_IDS(_kabylake_info),\
> + INTEL_KBL_GT3_IDS(_kabylake_gt3_info)
>  
>  static const struct pci_device_id pciidlist[] = {/* aka */
>   INTEL_PCI_IDS,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 824e724..f7e9d7e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -765,6 +765,7 @@ struct intel_csr {
>   func(is_valleyview) sep \
>   func(is_haswell) sep \
>   func(is_skylake) sep \
> + func(is_kabylake) sep \
>   func(is_preliminary) sep \
>   func(has_fbc) sep \
>   func(has_pipe_cxsr) sep \
> @@ -2464,6 +2465,7 @@ struct drm_i915_cmd_table {
>  #define IS_BROADWELL(dev)(!INTEL_INFO(dev)->is_valleyview && 
> IS_GEN8(dev))
>  #define IS_SKYLAKE(dev)  (INTEL_INFO(dev)->is_skylake)
>  #define IS_BROXTON(dev)  (!INTEL_INFO(dev)->is_skylake && IS_GEN9(dev))
> +#define IS_KABYLAKE(dev) (INTEL_INFO(dev)->is_kabylake)
>  #define IS_MOBILE(dev)   (INTEL_INFO(dev)->is_mobile)
>  #define IS_HSW_EARLY_SDV(dev)(IS_HASWELL(dev) && \
>(INTEL_DEVID(dev) & 0xFF00) == 0x0C00)
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 17c4456..2e7a159 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -291,4 +291,33 @@
>   INTEL_VGA_DEVICE(0x1A84, info), \
>   INTEL_VGA_DEVICE(0x5A84, info)
>  
> +#define INTEL_KBL_GT1_IDS(info)  \
> + INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> + INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> + INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> + INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
> + INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
> +
> +#define INTEL_KBL_GT2_IDS(info)  \
> + INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
> + 

Re: [Intel-gfx] [PATCH v4] drm/i915: Clean up associated VMAs on context destruction

[Chris Wilson]

On Tue, Oct 06, 2015 at 10:58:01AM +0200, Daniel Vetter wrote:
> On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > Prevent leaking VMAs and PPGTT VMs when objects are imported
> > via flink.
> > 
> > Scenario is that any VMAs created by the importer will be left
> > dangling after the importer exits, or destroys the PPGTT context
> > with which they are associated.
> > 
> > This is caused by object destruction not running when the
> > importer closes the buffer object handle due the reference held
> > by the exporter. This also leaks the VM since the VMA has a
> > reference on it.
> > 
> > In practice these leaks can be observed by stopping and starting
> > the X server on a kernel with fbcon compiled in. Every time
> > X server exits another VMA will be leaked against the fbcon's
> > frame buffer object.
> > 
> > Also on systems where flink buffer sharing is used extensively,
> > like Android, this leak has even more serious consequences.
> > 
> > This version is takes a general approach from the  earlier work
> > by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
> > destruction) and tries to incorporate the subsequent discussion
> > between Chris Wilson and Daniel Vetter.
> > 
> > v2:
> > 
> > Removed immediate cleanup on object retire - it was causing a
> > recursive VMA unbind via i915_gem_object_wait_rendering. And
> > it is in fact not even needed since by definition context
> > cleanup worker runs only after the last context reference has
> > been dropped, hence all VMAs against the VM belonging to the
> > context are already on the inactive list.
> > 
> > v3:
> > 
> > Previous version could deadlock since VMA unbind waits on any
> > rendering on an object to complete. Objects can be busy in a
> > different VM which would mean that the cleanup loop would do
> > the wait with the struct mutex held.
> > 
> > This is an even simpler approach where we just unbind VMAs
> > without waiting since we know all VMAs belonging to this VM
> > are idle, and there is nothing in flight, at the point
> > context destructor runs.
> > 
> > v4:
> > 
> > Double underscore prefix for __915_vma_unbind_no_wait and a
> > commit message typo fix. (Michel Thierry)
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
> > Reviewed-by: Michel Thierry 
> > Cc: Daniel Vetter 
> > Cc: Chris Wilson 
> > Cc: Rafael Barbalho 
> > Cc: Michel Thierry 
> 
> Queued for -next, thanks for the patch.

Please no, it's an awful patch and does not even fix the root cause of
the leak (that the vma are not closed when the handle is).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

[Daniel Vetter]

On Fri, Oct 02, 2015 at 10:16:26PM +, Boyer, Wayne wrote:
> On 8/26/15, 1:23 AM, Deepak  wrote:
> 
> 
> >
> >
> >On 08/25/2015 10:18 PM, Chris Wilson wrote:
> >> A long time ago (before 3.14) we relied on a permanent pinning of the
> >> ifbdev to lock the fb in place inside the GGTT. However, the
> >> introduction of stealing the BIOS framebuffer and reusing its address in
> >> the GGTT for the fbdev has muddied waters and we use an inherited fb.
> >> However, the inherited fb is only pinned whilst it is active and we no
> >> longer have an explicit pin for the info->system_base mmapping used by
> >> the fbdev. The result is that after some aperture pressure the fbdev may
> >> be evicted, but we continue to write the fbcon into the same GGTT
> >> address - overwriting anything else that may be put into that offset.
> >> The effect is most pronounced across suspend/resume as
> >> intel_fbdev_set_suspend() does a full clear over the whole scanout.
> >
> >Yup this is a critical fix :) by keeping the internal FB pinned we avoid
> >alloc of buffer within same FB GTT offset
> >Reviewed-by: Deepak S 
> 
> Daniel,
> 
> Is there anything else that needs to happen before this gets pulled in?

Someone needs to send out the rebased-on-upstream version. The patches
have been merged but then had to be dropped again since they where based
on top of Chris' tree.
-Daniel

> 
> Thanks,
> Wayne
> 
> >
> >> Signed-off-by: Chris Wilson 
> >> Cc: "Goel, Akash" 
> >> Cc: Daniel Vetter 
> >> Cc: Jesse Barnes 
> >> Cc: sta...@vger.kernel.org
> >> ---
> >>   drivers/gpu/drm/i915/intel_fbdev.c | 15 +++
> >>   1 file changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> >>b/drivers/gpu/drm/i915/intel_fbdev.c
> >> index 96476d7d7ed2..082f2938ec97 100644
> >> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> >> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> >> @@ -215,6 +215,16 @@ static int intelfb_create(struct drm_fb_helper
> >>*helper,
> >>obj = intel_fb->obj;
> >>size = obj->base.size;
> >>   
> >> +  /* The fb constructor will have already pinned us (or inherited a
> >> +   * GGTT region from the BIOS) suitable for a scanout, so
> >> +   * this should just be a no-op and increment the pin count for the
> >> +   * fbdev mmapping. It does have a useful side-effect of validating
> >> +   * the pin for fbdev's use via a GGTT mmapping.
> >> +   */
> >> +  ret = i915_gem_object_ggtt_pin(obj, NULL, 0, PIN_MAPPABLE);
> >> +  if (ret)
> >> +  goto out_unlock;
> >> +
> >>info = drm_fb_helper_alloc_fbi(helper);
> >>if (IS_ERR(info)) {
> >>ret = PTR_ERR(info);
> >> @@ -274,6 +284,9 @@ static int intelfb_create(struct drm_fb_helper
> >>*helper,
> >>   out_destroy_fbi:
> >>drm_fb_helper_release_fbi(helper);
> >>   out_unpin:
> >> +  /* Once for info->screen_base mmaping... */
> >> +  i915_gem_object_ggtt_unpin(obj);
> >> +  /* ...and once for the intel_fb */
> >>i915_gem_object_ggtt_unpin(obj);
> >>drm_gem_object_unreference(>base);
> >>   out_unlock:
> >> @@ -514,6 +527,8 @@ static const struct drm_fb_helper_funcs
> >>intel_fb_helper_funcs = {
> >>   static void intel_fbdev_destroy(struct drm_device *dev,
> >>struct intel_fbdev *ifbdev)
> >>   {
> >> +  /* Release the pinning for the info->screen_base mmaping. */
> >> +  i915_gem_object_ggtt_unpin(ifbdev->fb->obj);
> >>   
> >>drm_fb_helper_unregister_fbi(>helper);
> >>drm_fb_helper_release_fbi(>helper);
> >
> >___
> >Intel-gfx mailing list
> >Intel-gfx@lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add hot_plug hook for hdmi encoder

[Daniel Vetter]

On Mon, Oct 05, 2015 at 04:43:15PM +0530, Sonika Jindal wrote:
> This patch adds a separate probe function for HDMI
> EDID read over DDC channel. This function has been
> registered as a .hot_plug handler for HDMI encoder.
> 
> The current implementation of hdmi_detect()
> function re-sets the cached HDMI edid (in connector->detect_edid) in
> every detect call.This function gets called many times, sometimes
> directly from userspace probes, forcing drivers to read EDID every
> detect function call.This causes several problems like:
> 
> 1. Race conditions in multiple hot_plug / unplug cases, between
>interrupts bottom halves and userspace detections.
> 2. Many Un-necessary EDID reads for single hotplug/unplug
> 3. HDMI complaince failures which expects only one EDID read per hotplug
> 
> This function will be serving the purpose of really reading the EDID
> by really probing the DDC channel, and updating the cached EDID.
> 
> The plan is to:
> 1. i915 IRQ handler bottom half function already calls
>intel_encoder->hotplug() function. Adding This probe function which
>will read the EDID only in case of a hotplug / unplug.
> 2. During init_connector this probe will be called to read the edid
> 3. Reuse the cached EDID in hdmi_detect() function.
> 
> The "< gen7" check is there because this was tested only for >=gen7
> platforms. For older platforms the hotplug/reading edid path remains same.
> 
> v2: Calling set_edid instead of hdmi_probe during init.
> Also, for platforms having DDI, intel_encoder for DP and HDMI is same
> (taken from intel_dig_port), so for DP also, hot_plug function gets called
> which is not intended here. So, check for HDMI in intel_hdmi_probe
> Rely on HPD for updating edid only for platforms gen > 8 and also for VLV.
> 
> v3: Dropping the gen < 8 || !VLV  check. Now all platforms should rely on
> hotplug or init for updating the edid.(Daniel)
> Also, calling hdmi_probe in init instead of set_edid
> 
> v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug.
> Also calling this hotplug handler from intel_hpd_init to take care of init
> resume scenarios.
> 
> v5: Moved the call to encoder hotplug during init to separate patch(Daniel)
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 

I merged the first patch in this series, but I have a quick question on
this one here. Can you pls ping me on irc?

Thanks, Daniel
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c |   54 
> +
>  1 file changed, 43 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index bb33c66..9c1a308 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1369,18 +1369,16 @@ intel_hdmi_set_edid(struct drm_connector *connector, 
> bool force)
>   return connected;
>  }
>  
> -static enum drm_connector_status
> -intel_hdmi_detect(struct drm_connector *connector, bool force)
> +void intel_hdmi_hot_plug(struct intel_encoder *intel_encoder)
>  {
> - enum drm_connector_status status;
> - struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> - struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi =
> + enc_to_intel_hdmi(_encoder->base);
> + struct intel_connector *intel_connector =
> + intel_hdmi->attached_connector;
> + struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
>   bool live_status = false;
>   unsigned int retry = 3;
>  
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> -   connector->base.id, connector->name);
> -
>   while (!live_status && --retry) {
>   live_status = intel_digital_port_connected(dev_priv,
>   hdmi_to_dig_port(intel_hdmi));
> @@ -1390,15 +1388,48 @@ intel_hdmi_detect(struct drm_connector *connector, 
> bool force)
>   if (!live_status)
>   DRM_DEBUG_KMS("Live status not up!");
>  
> - intel_hdmi_unset_edid(connector);
> + /*
> +  * We are here, means there is a hotplug or a force
> +  * detection. Clear the cached EDID and probe the
> +  * DDC bus to check the current status of HDMI.
> +  */
> + intel_hdmi_unset_edid(_connector->base);
> + if (intel_hdmi_set_edid(_connector->base, live_status))
> + DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
> + else
> + DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
> +}
>  
> - if (intel_hdmi_set_edid(connector, live_status)) {
> +static enum drm_connector_status
> +intel_hdmi_detect(struct drm_connector *connector, bool force)
> +{
> + enum drm_connector_status status;
> + struct intel_connector *intel_connector =
> + to_intel_connector(connector);
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> +   

Re: [Intel-gfx] [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Evan Foss]

On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
> Hi,
>
> I've also pushed this series to GitHub now to ease reviewing:
> https://github.com/l1k/linux/commits/mbp_switcheroo_v3

So to test this all someone has to do is pull this and try it? No
patching required?

> Thanks,
>
> Lukas
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Pierre Moreau]

The repo is a fork of Linus' tree, with the patches on top of it. So you just 
need to build that modified version of the kernel and boot it. :-)

Pierre

> On 05 Oct 2015, at 16:15, Evan Foss  wrote:
> 
>> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
>> Hi,
>> 
>> I've also pushed this series to GitHub now to ease reviewing:
>> https://github.com/l1k/linux/commits/mbp_switcheroo_v3
> 
> So to test this all someone has to do is pull this and try it? No
> patching required?
> 
>> Thanks,
>> 
>> Lukas
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> 
> 
> 
> -- 
> Home
> http://evanfoss.googlepages.com/
> Work
> http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro

[Evan Foss]

On Mon, Oct 5, 2015 at 11:17 AM, Lukas Wunner  wrote:
> Hi Evan,
>
> On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote:
>> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner  wrote:
>> > I've also pushed this series to GitHub now to ease reviewing:
>> > https://github.com/l1k/linux/commits/mbp_switcheroo_v3
>>
>> So to test this all someone has to do is pull this and try it? No
>> patching required?
>
> Yes. But if you don't already have a kernel git repo, this will be
> a > 1 GByte download.

2012
Macbook Pro 9,2

$ dmesg|grep Apple
[0.00] efi: EFI v1.10 by Apple
[0.00] DMI: Apple Inc. MacBookPro9,1/Mac-
4B7AC7E43945597E,
BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012

> Which MacBook Pro model do you want to test this on? As noted in the
> cover letter, this will only work on pre-retinas and only if the
> apple-gmux module loads before the DRM drivers. You can try to ensure
> the latter by editing modules.dep, or grab this tarball which contains
> reprobing patches on top:
> http://wunner.de/mbp_switcheroo_v3_reprobe_4.3-rc4pre.tar.gz

Ok thanks

> Best regards,
>
> Lukas

Evan

-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

[Daniel Vetter]

On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> On 10/5/2015 5:36 PM, Dave Gordon wrote:
> >On 02/10/15 14:16, Michel Thierry wrote:
> >>We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
> >>range pt in gen6_for_each_pde").
> >>
> >>But the static analyzer still complains that, just before we break due
> >>to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an
> >>iter value that is bigger than I915_PDES. Of course, this isn't really
> >>a problem since no one uses pt outside the macro. Still, every single
> >>new usage of the macro will create a new issue for us to mark as a
> >>false positive.
> >>
> >>Also, Paulo re-started the discussion a while ago [1], but didn't end up
> >>implemented.
> >>
> >>In order to "solve" this "problem", this patch takes the ideas from
> >>Chris and Dave, but that check would change the desired behavior of the
> >>code, because the object (for example pdp->page_directory[iter]) can be
> >>null during init/alloc, and C would take this as false, breaking the for
> >>loop immediately.
> >>
> >>This has been already verified with "static analysis tools".
> >>
> >>[1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html
> >>
> >>v2: Make it a single statement, while preventing the common subexpression
> >>elimination (Chris)
> >>
> >>Cc: Paulo Zanoni 
> >>Cc: Chris Wilson 
> >>Cc: Dave Gordon 
> >>Signed-off-by: Michel Thierry 
> >>---
> >>  drivers/gpu/drm/i915/i915_gem_gtt.h | 14 --
> >>  1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>index 9fbb07d..a216397 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >>@@ -394,7 +394,8 @@ struct i915_hw_ppgtt {
> >>   */
> >>  #define gen6_for_each_pde(pt, pd, start, length, temp, iter) \
> >>  for (iter = gen6_pde_index(start); \
> >>- pt = (pd)->page_table[iter], length > 0 && iter < I915_PDES; \
> >>+ length > 0 && iter < I915_PDES ? \
> >>+(pt = (pd)->page_table[iter]), 1 : 0; \
> >>   iter++, \
> >>   temp = ALIGN(start+1, 1 << GEN6_PDE_SHIFT) - start, \
> >>   temp = min_t(unsigned, temp, length), \
> >>@@ -459,7 +460,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)
> >>   */
> >>  #define gen8_for_each_pde(pt, pd, start, length, temp, iter)\
> >>  for (iter = gen8_pde_index(start); \
> >>- pt = (pd)->page_table[iter], length > 0 && iter <
> >>I915_PDES;\
> >>+ length > 0 && iter < I915_PDES ? \
> >>+(pt = (pd)->page_table[iter]), 1 : 0; \
> >>   iter++,\
> >>   temp = ALIGN(start+1, 1 << GEN8_PDE_SHIFT) - start,\
> >>   temp = min(temp, length),\
> >>@@ -467,8 +469,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)
> >>
> >>  #define gen8_for_each_pdpe(pd, pdp, start, length, temp, iter)\
> >>  for (iter = gen8_pdpe_index(start); \
> >>- pd = (pdp)->page_directory[iter], \
> >>- length > 0 && (iter < I915_PDPES_PER_PDP(dev)); \
> >>+ length > 0 && (iter < I915_PDPES_PER_PDP(dev)) ? \
> >>+(pd = (pdp)->page_directory[iter]), 1 : 0; \
> >>   iter++,\
> >>   temp = ALIGN(start+1, 1 << GEN8_PDPE_SHIFT) - start,\
> >>   temp = min(temp, length),\
> >>@@ -476,8 +478,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)
> >>
> >>  #define gen8_for_each_pml4e(pdp, pml4, start, length, temp, iter)\
> >>  for (iter = gen8_pml4e_index(start);\
> >>- pdp = (pml4)->pdps[iter], \
> >>- length > 0 && iter < GEN8_PML4ES_PER_PML4; \
> >>+ length > 0 && iter < GEN8_PML4ES_PER_PML4 ? \
> >>+(pdp = (pml4)->pdps[iter]), 1 : 0; \
> >
> >this won't compile -- see below
> 
> Hmm, it compiled (also got rid of of the "analysis tool error" and didn't
> see any behavior change).
> 
> >
> >>   iter++,\
> >>   temp = ALIGN(start+1, 1ULL << GEN8_PML4E_SHIFT) - start,\
> >>   temp = min(temp, length),\
> >
> >The man page for C operators tells us:
> >
> >Operator Associativity
> >() [] -> .   left to right
> >! ~ ++ -- + - (type) * & sizeof  right to left
> >* / %left to right
> >+ -  left to right
> ><< >>left to right
> >< <= > >=left to right
> >== !=left to right
> >&left to right
> >^   

Re: [Intel-gfx] [PATCH v4] drm/i915: Clean up associated VMAs on context destruction

[Daniel Vetter]

On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Prevent leaking VMAs and PPGTT VMs when objects are imported
> via flink.
> 
> Scenario is that any VMAs created by the importer will be left
> dangling after the importer exits, or destroys the PPGTT context
> with which they are associated.
> 
> This is caused by object destruction not running when the
> importer closes the buffer object handle due the reference held
> by the exporter. This also leaks the VM since the VMA has a
> reference on it.
> 
> In practice these leaks can be observed by stopping and starting
> the X server on a kernel with fbcon compiled in. Every time
> X server exits another VMA will be leaked against the fbcon's
> frame buffer object.
> 
> Also on systems where flink buffer sharing is used extensively,
> like Android, this leak has even more serious consequences.
> 
> This version is takes a general approach from the  earlier work
> by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
> destruction) and tries to incorporate the subsequent discussion
> between Chris Wilson and Daniel Vetter.
> 
> v2:
> 
> Removed immediate cleanup on object retire - it was causing a
> recursive VMA unbind via i915_gem_object_wait_rendering. And
> it is in fact not even needed since by definition context
> cleanup worker runs only after the last context reference has
> been dropped, hence all VMAs against the VM belonging to the
> context are already on the inactive list.
> 
> v3:
> 
> Previous version could deadlock since VMA unbind waits on any
> rendering on an object to complete. Objects can be busy in a
> different VM which would mean that the cleanup loop would do
> the wait with the struct mutex held.
> 
> This is an even simpler approach where we just unbind VMAs
> without waiting since we know all VMAs belonging to this VM
> are idle, and there is nothing in flight, at the point
> context destructor runs.
> 
> v4:
> 
> Double underscore prefix for __915_vma_unbind_no_wait and a
> commit message typo fix. (Michel Thierry)
> 
> Signed-off-by: Tvrtko Ursulin 
> Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
> Reviewed-by: Michel Thierry 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: Rafael Barbalho 
> Cc: Michel Thierry 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h |  5 +
>  drivers/gpu/drm/i915/i915_gem.c | 20 
>  drivers/gpu/drm/i915/i915_gem_context.c | 24 
>  3 files changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 824e7245044d..58afa1bb2957 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2840,6 +2840,11 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object 
> *obj,
>  int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
> u32 flags);
>  int __must_check i915_vma_unbind(struct i915_vma *vma);
> +/*
> + * BEWARE: Do not use the function below unless you can _absolutely_
> + * _guarantee_ VMA in question is _not in use_ anywhere.
> + */
> +int __must_check __i915_vma_unbind_no_wait(struct i915_vma *vma);
>  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
>  void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
>  void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f0cfbb9ee12c..52642aff1dab 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3208,7 +3208,7 @@ static void i915_gem_object_finish_gtt(struct 
> drm_i915_gem_object *obj)
>   old_write_domain);
>  }
>  
> -int i915_vma_unbind(struct i915_vma *vma)
> +static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
>  {
>   struct drm_i915_gem_object *obj = vma->obj;
>   struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> @@ -3227,9 +3227,11 @@ int i915_vma_unbind(struct i915_vma *vma)
>  
>   BUG_ON(obj->pages == NULL);
>  
> - ret = i915_gem_object_wait_rendering(obj, false);
> - if (ret)
> - return ret;
> + if (wait) {
> + ret = i915_gem_object_wait_rendering(obj, false);
> + if (ret)
> + return ret;
> + }
>  
>   if (i915_is_ggtt(vma->vm) &&
>   vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
> @@ -3274,6 +3276,16 @@ int i915_vma_unbind(struct i915_vma *vma)
>   return 0;
>  }
>  
> +int i915_vma_unbind(struct i915_vma *vma)
> +{
> + return __i915_vma_unbind(vma, true);
> +}
> +
> +int __i915_vma_unbind_no_wait(struct i915_vma *vma)
> +{
> + return 

Re: [Intel-gfx] [RFC PATCH drm-intel] drm/i915/bxt: vlv_dsi_reset_clocks() can be static

[Daniel Vetter]

On Mon, Oct 05, 2015 at 02:57:57PM +0300, Jani Nikula wrote:
> On Mon, 05 Oct 2015, kbuild test robot  wrote:
> > Signed-off-by: Fengguang Wu 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel

> 
> 
> > ---
> >  intel_dsi_pll.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
> > b/drivers/gpu/drm/i915/intel_dsi_pll.c
> > index c9a38f4..d85f1eaf 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> > @@ -384,7 +384,7 @@ u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int 
> > pipe_bpp)
> > return pclk;
> >  }
> >  
> > -void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
> > +static void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port 
> > port)
> >  {
> > u32 temp;
> > struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > @@ -542,7 +542,7 @@ void intel_disable_dsi_pll(struct intel_encoder 
> > *encoder)
> > bxt_disable_dsi_pll(encoder);
> >  }
> >  
> > -void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
> > +static void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port 
> > port)
> >  {
> > u32 tmp;
> > struct drm_device *dev = encoder->base.dev;
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH ddx] Add Kabylake PCI IDs

[Chris Wilson]

On Mon, Oct 05, 2015 at 03:48:42PM -0700, Rodrigo Vivi wrote:
> Also, following kernel definition Kabylake is Skylake.

Wait for kernel inclusion, copy from kernel/i915_pciids.h and reference
upstream commit.

> Signed-off-by: Rodrigo Vivi 
> ---
>  src/i915_pciids.h  | 29 +
>  src/intel_module.c |  1 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/src/i915_pciids.h b/src/i915_pciids.h
> index 17c4456..9d76672 100644
> --- a/src/i915_pciids.h
> +++ b/src/i915_pciids.h
> @@ -286,6 +286,35 @@
>   INTEL_SKL_GT2_IDS(info), \
>   INTEL_SKL_GT3_IDS(info)
>  
> +#define INTEL_KBL_GT1_IDS(info)\
> + INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> + INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> + INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> + INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
> + INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
> +
> +#define INTEL_KBL_GT2_IDS(info)\
> + INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
> + INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
> + INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
> + INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
> + INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
> + INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
> + INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
> +
> +#define INTEL_KBL_GT3_IDS(info) \
> + INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> + INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
> + INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
> +
> +#define INTEL_KBL_IDS(info) \
> + INTEL_KBL_GT1_IDS(info), \
> + INTEL_KBL_GT2_IDS(info), \
> + INTEL_KBL_GT3_IDS(info)
> +
>  #define INTEL_BXT_IDS(info) \
>   INTEL_VGA_DEVICE(0x0A84, info), \
>   INTEL_VGA_DEVICE(0x1A84, info), \
> diff --git a/src/intel_module.c b/src/intel_module.c
> index d3dca83..6ebbf85 100644
> --- a/src/intel_module.c
> +++ b/src/intel_module.c
> @@ -326,6 +326,7 @@ static const struct pci_id_match intel_device_match[] = {
>   INTEL_CHV_IDS(_cherryview_info),
>  
>   INTEL_SKL_IDS(_skylake_info),
> + INTEL_KBL_IDS(_skylake_info),

Don't resuse skylake_info, but create kabylake_info with .gen=111;
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Add host2guc notification for suspend and resume

[Daniel Vetter]

On Fri, Oct 02, 2015 at 09:49:13PM +0530, Kamble, Sagar A wrote:
> Reviewed-by: Sagar Arun Kamble 
> 
> On 9/30/2015 10:16 PM, yu@intel.com wrote:
> >From: Alex Dai 
> >
> >Add host2guc interface to notify GuC power state changes when
> >enter or resume from power saving state.
> >
> >v3: Move intel_guc_suspend to i915_drm_suspend for consistency.
> >
> >v2: Add GuC suspend/resume to runtime suspend/resume too
> >
> >v1: Change to a more flexible way when fill host to GuC scratch
> >data in order to remove hard coding.
> >
> >Signed-off-by: Alex Dai 

Queued for -next, thanks for the patch.
-Daniel

> >---
> >  drivers/gpu/drm/i915/i915_drv.c|  8 +
> >  drivers/gpu/drm/i915/i915_guc_submission.c | 50 
> > ++
> >  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
> >  drivers/gpu/drm/i915/intel_guc_fwif.h  |  8 +
> >  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++-
> >  5 files changed, 71 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >b/drivers/gpu/drm/i915/i915_drv.c
> >index 1cb6b82..760e0ce 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -638,6 +638,8 @@ static int i915_drm_suspend(struct drm_device *dev)
> > return error;
> > }
> >+intel_guc_suspend(dev);
> >+
> > intel_suspend_gt_powersave(dev);
> > /*
> >@@ -767,6 +769,8 @@ static int i915_drm_resume(struct drm_device *dev)
> > }
> > mutex_unlock(>struct_mutex);
> >+intel_guc_resume(dev);
> >+
> > intel_modeset_init_hw(dev);
> > spin_lock_irq(_priv->irq_lock);
> >@@ -1500,6 +1504,8 @@ static int intel_runtime_suspend(struct device *device)
> > i915_gem_release_all_mmaps(dev_priv);
> > mutex_unlock(>struct_mutex);
> >+intel_guc_suspend(dev);
> >+
> > intel_suspend_gt_powersave(dev);
> > intel_runtime_pm_disable_interrupts(dev_priv);
> >@@ -1559,6 +1565,8 @@ static int intel_runtime_resume(struct device *device)
> > intel_opregion_notify_adapter(dev, PCI_D0);
> > dev_priv->pm.suspended = false;
> >+intel_guc_resume(dev);
> >+
> > if (IS_GEN6(dev_priv))
> > intel_init_pch_refclk(dev);
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index 0b1797f..036b42b 100644
> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >@@ -923,3 +923,53 @@ void i915_guc_submission_fini(struct drm_device *dev)
> > gem_release_guc_obj(guc->ctx_pool_obj);
> > guc->ctx_pool_obj = NULL;
> >  }
> >+
> >+/**
> >+ * intel_guc_suspend() - notify GuC entering suspend state
> >+ * @dev:drm device
> >+ */
> >+int intel_guc_suspend(struct drm_device *dev)
> >+{
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+struct intel_guc *guc = _priv->guc;
> >+struct intel_context *ctx;
> >+u32 data[3];
> >+
> >+if (!i915.enable_guc_submission)
> >+return 0;
> >+
> >+ctx = dev_priv->ring[RCS].default_context;
> >+
> >+data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
> >+/* any value greater than GUC_POWER_D0 */
> >+data[1] = GUC_POWER_D1;
> >+/* first page is shared data with GuC */
> >+data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
> >+
> >+return host2guc_action(guc, data, ARRAY_SIZE(data));
> >+}
> >+
> >+
> >+/**
> >+ * intel_guc_resume() - notify GuC resuming from suspend state
> >+ * @dev:drm device
> >+ */
> >+int intel_guc_resume(struct drm_device *dev)
> >+{
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+struct intel_guc *guc = _priv->guc;
> >+struct intel_context *ctx;
> >+u32 data[3];
> >+
> >+if (!i915.enable_guc_submission)
> >+return 0;
> >+
> >+ctx = dev_priv->ring[RCS].default_context;
> >+
> >+data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
> >+data[1] = GUC_POWER_D0;
> >+/* first page is shared data with GuC */
> >+data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
> >+
> >+return host2guc_action(guc, data, ARRAY_SIZE(data));
> >+}
> >diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> >b/drivers/gpu/drm/i915/intel_guc.h
> >index 63e73f3..5ba5866 100644
> >--- a/drivers/gpu/drm/i915/intel_guc.h
> >+++ b/drivers/gpu/drm/i915/intel_guc.h
> >@@ -116,6 +116,8 @@ extern void intel_guc_ucode_init(struct drm_device *dev);
> >  extern int intel_guc_ucode_load(struct drm_device *dev);
> >  extern void intel_guc_ucode_fini(struct drm_device *dev);
> >  extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status 
> > status);
> >+extern int intel_guc_suspend(struct drm_device *dev);
> >+extern int intel_guc_resume(struct drm_device *dev);
> >  /* i915_guc_submission.c */
> >  int i915_guc_submission_init(struct drm_device *dev);
> >diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9: Add HDC_CHICKEN1 to HW whitelist

[Daniel Vetter]

On Fri, Oct 02, 2015 at 02:19:40PM +0100, Arun Siluvery wrote:
> Required for WaAllowUMDToModifyHDCChicken1:skl,bxt
> 
> Cc: Mika Kuoppala 
> Cc: Nick Hoath 
> Signed-off-by: Arun Siluvery 

Usual maintainer request: Needs the corresponding mesa patches reviewed
before I can pull this in.
-Daniel

> ---
>  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/i915/i915_reg.h
> index 797c74e..dc84072 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5937,6 +5937,8 @@ enum skl_disp_power_wells {
>  #define  HDC_FORCE_NON_COHERENT  (1<<4)
>  #define  HDC_BARRIER_PERFORMANCE_DISABLE (1<<10)
>  
> +#define HDC_CHICKEN1 0x7304
> +
>  /* GEN9 chicken */
>  #define SLICE_ECO_CHICKEN0   0x7308
>  #define   PIXEL_MASK_CAMMING_DISABLE (1 << 14)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 64b2754..a091e9e 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -921,6 +921,7 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *ring)
>   struct drm_device *dev = ring->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint32_t tmp;
> + int ret;
>  
>   /* WaDisablePartialInstShootdown:skl,bxt */
>   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
> @@ -979,6 +980,11 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *ring)
>   tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
>   WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
>  
> + /* WaAllowUMDToModifyHDCChicken1:skl,bxt */
> + ret = wa_ring_whitelist_reg(ring, HDC_CHICKEN1);
> + if (ret)
> + return ret;
> +
>   /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt */
>   if (IS_SKYLAKE(dev) ||
>   (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_B0)) {
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915/kbl: Add Kabylake PCI ID

[Jani Nikula]

On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> From: Deepak S 
>
> v2: separate out device info into different GT (Damien)
> v3: Add is_kabylake to the KBL gt3 structuer (Damien)
> Sort the platforms in older -> newer order (Damien)
>
> Reviewed-by: Damien Lespiau 
> Signed-off-by: Deepak S 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 33 -
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  include/drm/i915_pciids.h   | 29 +
>  3 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1cb6b82..f42102d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -394,6 +394,34 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   IVB_CURSOR_OFFSETS,
>  };
>  
> +static const struct intel_device_info intel_kabylake_info = {
> + .is_preliminary = 1,
> + .is_skylake = 1,
> + .is_kabylake = 1,
> + .gen = 9, .num_pipes = 3,
> + .need_gfx_hws = 1, .has_hotplug = 1,
> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> + .has_llc = 1,
> + .has_ddi = 1,
> + .has_fbc = 1,
> + GEN_DEFAULT_PIPEOFFSETS,
> + IVB_CURSOR_OFFSETS,
> +};
> +
> +static const struct intel_device_info intel_kabylake_gt3_info = {
> + .is_preliminary = 1,
> + .is_skylake = 1,
> + .is_kabylake = 1,
> + .gen = 9, .num_pipes = 3,
> + .need_gfx_hws = 1, .has_hotplug = 1,
> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> + .has_llc = 1,
> + .has_ddi = 1,
> + .has_fbc = 1,
> + GEN_DEFAULT_PIPEOFFSETS,
> + IVB_CURSOR_OFFSETS,
> +};
> +
>  /*
>   * Make sure any device matches here are from most specific to most
>   * general.  For example, since the Quanta match is based on the subsystem
> @@ -434,7 +462,10 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   INTEL_SKL_GT1_IDS(_skylake_info), \
>   INTEL_SKL_GT2_IDS(_skylake_info), \
>   INTEL_SKL_GT3_IDS(_skylake_gt3_info), \
> - INTEL_BXT_IDS(_broxton_info)
> + INTEL_BXT_IDS(_broxton_info), \
> + INTEL_KBL_GT1_IDS(_kabylake_info),\
> + INTEL_KBL_GT2_IDS(_kabylake_info),\
> + INTEL_KBL_GT3_IDS(_kabylake_gt3_info)
>  
>  static const struct pci_device_id pciidlist[] = {/* aka */
>   INTEL_PCI_IDS,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 824e724..f7e9d7e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -765,6 +765,7 @@ struct intel_csr {
>   func(is_valleyview) sep \
>   func(is_haswell) sep \
>   func(is_skylake) sep \
> + func(is_kabylake) sep \
>   func(is_preliminary) sep \
>   func(has_fbc) sep \
>   func(has_pipe_cxsr) sep \
> @@ -2464,6 +2465,7 @@ struct drm_i915_cmd_table {
>  #define IS_BROADWELL(dev)(!INTEL_INFO(dev)->is_valleyview && 
> IS_GEN8(dev))
>  #define IS_SKYLAKE(dev)  (INTEL_INFO(dev)->is_skylake)
>  #define IS_BROXTON(dev)  (!INTEL_INFO(dev)->is_skylake && IS_GEN9(dev))
> +#define IS_KABYLAKE(dev) (INTEL_INFO(dev)->is_kabylake)
>  #define IS_MOBILE(dev)   (INTEL_INFO(dev)->is_mobile)
>  #define IS_HSW_EARLY_SDV(dev)(IS_HASWELL(dev) && \
>(INTEL_DEVID(dev) & 0xFF00) == 0x0C00)
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 17c4456..2e7a159 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -291,4 +291,33 @@
>   INTEL_VGA_DEVICE(0x1A84, info), \
>   INTEL_VGA_DEVICE(0x5A84, info)
>  
> +#define INTEL_KBL_GT1_IDS(info)  \
> + INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
> + INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> + INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> + INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> + INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
> + INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
> +
> +#define INTEL_KBL_GT2_IDS(info)  \
> + INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
> + INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \

This will match IS_SKL_GT3, making it a good example of just how
confusing it will be to have IS_SKYLAKE match Kabylake.

> + INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
> + INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
> + INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
> + INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
> + INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
> +

Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

[Vivi, Rodrigo]

On Tue, 2015-10-06 at 16:43 +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Ville Syrjälä  
> wrote:
> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> > > Prefer inclusive ranges for revision checks rather than "below 
> > > B0". Per
> > > specs A2 is not used, so revid <= A1 matches revid < B0.
> > 
> > The w/a db would say UNTIL_B0 etc., so might be easier to check 
> > against
> > it if we keep to the same convention.
> 
> So I wanted to double check what the convention is. I picked
> WaRsDisableCoarsePowerGating.
> 
> KBL - SIWA_FOREVER
> BXT - SI_WA_BEFORE(BXT_REV_ID_B0)
> SKL - SIWA_UNTIL_SKL_E0
> 
> Description "Disable coarse power gating for GT4 until GT F0 
> stepping."
> 
> *rolls eyes*
> 
> So is that "until" there inclusive or non-inclusive? The db is
> contradicting itself... Cc: Sarah who has also looked at workarounds
> recently.
> 
> Rodrigo, for one thing, I'll want workarounds for SKL and KBL in
> different conditions instead of conflated into SKL!

I agree with Ville that <= REVID matches the spec in sense of "until"
certain stepping and I like this.

Also KBL W/A doesn't conflict with SKL W/as in they way they were
derivated...

> 
> But what about this non-inclusive end of range? It'll matter in patch
> 3/3. It's not so much a problem for ranges, but rather for specific
> revisions, where you'd have to include a revision not mentioned in 
> the
> spec at all, e.g. for B0 only:
> 
>   IS_SKL_REVID(dev, SKL_REVID_B0, SKL_REVID_C0)
> 
> instead of the current proposal:
> 
>   IS_SKL_REVID(dev, SKL_REVID_B0, SKL_REVID_B0)
> 
> I'm not really fond of adding separate macros for checking specific
> vs. ranges.
> 
> Thoughts?
> 
> BR,
> Jani.
> 
> 
> 
> 
> 
> > 
> > > 
> > > Signed-off-by: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h| 1 +
> > >  drivers/gpu/drm/i915/i915_gem.c| 2 +-
> > >  drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> > >  drivers/gpu/drm/i915/intel_ddi.c   | 2 +-
> > >  drivers/gpu/drm/i915/intel_dp.c| 2 +-
> > >  drivers/gpu/drm/i915/intel_hdmi.c  | 2 +-
> > >  drivers/gpu/drm/i915/intel_lrc.c   | 8 
> > >  drivers/gpu/drm/i915/intel_pm.c| 6 +++---
> > >  drivers/gpu/drm/i915/intel_ringbuffer.c| 6 +++---
> > >  9 files changed, 16 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index a3b137715604..9833a2055930 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2509,6 +2509,7 @@ struct drm_i915_cmd_table {
> > >  #define SKL_REVID_F0 0x5
> > >  
> > >  #define BXT_REVID_A0 0x0
> > > +#define BXT_REVID_A1 0x1
> > >  #define BXT_REVID_B0 0x3
> > >  #define BXT_REVID_C0 0x9
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index f0cfbb9ee12c..fd2d880656b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3757,7 +3757,7 @@ int i915_gem_set_caching_ioctl(struct 
> > > drm_device *dev, void *data,
> > >* cacheline, whereas normally such cachelines 
> > > would get
> > >* invalidated.
> > >*/
> > > - if (IS_BROXTON(dev) && INTEL_REVID(dev) < 
> > > BXT_REVID_B0)
> > > + if (IS_BROXTON(dev) && INTEL_REVID(dev) <= 
> > > BXT_REVID_A1)
> > >   return -ENODEV;
> > >  
> > >   level = I915_CACHE_LLC;
> > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> > > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > index 036b42bae827..863aa5c82466 100644
> > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > @@ -161,7 +161,7 @@ static int host2guc_sample_forcewake(struct 
> > > intel_guc *guc,
> > >   data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
> > >   /* WaRsDisableCoarsePowerGating:skl,bxt */
> > >   if (!intel_enable_rc6(dev_priv->dev) ||
> > > - (IS_BROXTON(dev) && (INTEL_REVID(dev) < 
> > > BXT_REVID_B0)) ||
> > > + (IS_BROXTON(dev) && (INTEL_REVID(dev) <= 
> > > BXT_REVID_A1)) ||
> > >   (IS_SKL_GT3(dev) && (INTEL_REVID(dev) <= 
> > > SKL_REVID_E0)) ||
> > >   (IS_SKL_GT4(dev) && (INTEL_REVID(dev) <= 
> > > SKL_REVID_E0)))
> > >   data[1] = 0;
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index b25e99a432fb..b80e0f5ec5dc 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3247,7 +3247,7 @@ void intel_ddi_init(struct drm_device *dev, 
> > > enum port port)
> > >* On BXT A0/A1, sw needs to activate DDIA HPD 
> > > logic and
> > >* interrupts to check the external panel 
> > > connection.
> > >

[Intel-gfx] [PATCH] igt/kms_addfb_basic: New subtest to check for fb modifier and tiling mode mismatch

[Vivek Kasireddy]

This new subtest will validate a Y-tiled object's tiling mode against
its associated fb modifier.

Cc: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
 tests/kms_addfb_basic.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index d466e4d..7ca1add 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -373,6 +373,15 @@ static void addfb25_ytile(int fd, int gen)
f.handles[0] = gem_bo;
}
 
+   igt_subtest("addfb25-Y-tiled-X-modifier-mismatch") {
+   igt_require(gen >= 9);
+   igt_require_fb_modifiers(fd);
+   gem_set_tiling(fd, gem_bo, I915_TILING_Y, 1024*4);
+
+   f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
+   igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, ) < 0 && 
errno == EINVAL);
+   }
+
igt_subtest("addfb25-Y-tiled") {
igt_require_fb_modifiers(fd);
 
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Check fb against plane size rather than CRTC mode for pageflip

[Matt Roper]

The legacy pageflip ioctl calls drm_crtc_check_viewport() to determine
whether the framebuffer being flipped is big enough to fill the display
it is being flipped to.  However some drivers support "windowing" of
their primary planes (i.e., a primary plane that does not cover the
entire CRTC dimensions); in such situations we can wind up rejecting
valid pageflips of buffers that are smaller than the display mode, but
still large enough to fill the entire primary plane.

What we really want to be comparing against for pageflips is the size of
the primary plane, which can be found in crtc->primary->state for atomic
drivers (and drivers in the process of transitioning to atomic).  There
are no non-atomic drivers that support primary plane windowing at the
moment, so we'll continue to use the current behavior of looking at the
CRTC mode size on drivers that don't have a crtc->primary->state.  We'll
also continue to use the existing logic for SetCrtc, which is the other
callsite for drm_crtc_check_viewport(), since legacy modesets reprogram
the primary plane and remove windowing.

Note that the existing code was checking a crtc->invert_dimensions field
to determine whether the width/height of the mode needed to be swapped.
A bonus of checking plane size is that the source width/height we get
already take rotation into account so that check is no longer necessary
when using the plane size.

Testcase: igt/universal-plane-gen9-features-pipe-#
Reported-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c | 87 +-
 1 file changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e600a5f..35cd4dc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2534,9 +2534,76 @@ void drm_crtc_get_hv_timing(const struct 
drm_display_mode *mode,
 }
 EXPORT_SYMBOL(drm_crtc_get_hv_timing);
 
+static int check_viewport(int hdisplay,
+ int vdisplay,
+ int x,
+ int y,
+ bool invert_dimensions,
+ const struct drm_framebuffer *fb)
+{
+   if (invert_dimensions)
+   swap(hdisplay, vdisplay);
+
+   if (hdisplay > fb->width ||
+   vdisplay > fb->height ||
+   x > fb->width - hdisplay ||
+   y > fb->height - vdisplay) {
+   DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay, x, y,
+ invert_dimensions ? " (inverted)" : "");
+   return -ENOSPC;
+   }
+
+   return 0;
+}
+
+/**
+ * drm_plane_check_viewport - Checks that a framebuffer is big enough for the
+ * plane's viewport
+ * @plane: Plane that framebuffer will be displayed on
+ * @x: x panning
+ * @y: y panning
+ * @fb: framebuffer to check size of
+ *
+ * Atomic drivers (or transitioning drivers that support proper plane state)
+ * may call this function on any plane.  Non-atomic drivers may only call this
+ * for the primary plane while the CRTC is active (we'll assume that the
+ * primary plane covers the entire CRTC in that case).
+ */
+int drm_plane_check_viewport(const struct drm_plane *plane,
+int x,
+int y,
+const struct drm_framebuffer *fb)
+
+{
+   struct drm_crtc *crtc = plane->crtc;
+   int hdisplay, vdisplay;
+
+   if (WARN_ON(plane->state == NULL &&
+   plane->type != DRM_PLANE_TYPE_PRIMARY))
+   return -EINVAL;
+
+   /*
+* Non-atomic drivers may not have valid plane state to look at.  But
+* those drivers also don't support windowing of the primary plane, so
+* we can fall back to looking at the mode of the owning CRTC.
+*/
+   if (plane->state) {
+   hdisplay = plane->state->src_w >> 16;
+   vdisplay = plane->state->src_h >> 16;
+   } else if (WARN_ON(!crtc)) {
+   hdisplay = vdisplay = 0;
+   } else {
+   drm_crtc_get_hv_timing(>mode, , );
+   }
+
+   return check_viewport(hdisplay, vdisplay, x, y, false, fb);
+}
+EXPORT_SYMBOL(drm_plane_check_viewport);
+
 /**
  * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
- * CRTC viewport
+ * CRTC viewport when running in the specified mode
  * @crtc: CRTC that framebuffer will be displayed on
  * @x: x panning
  * @y: y panning
@@ -2553,20 +2620,8 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 
drm_crtc_get_hv_timing(mode, , );
 
-   if (crtc->invert_dimensions)
-   swap(hdisplay, vdisplay);
-
-   if 

[Intel-gfx] [PATCH i-g-t] kms_universal_plane: Add gen9-specific test

[Matt Roper]

Gen9 adds some new capabilities not present on previous platforms
(primary plane windowing, 90/270 rotation, etc.).  Add a new subtest to
check how these new features interact with the use of the universal
plane API.

For now we just check whether pageflips work as expected in a windowed
setting.  We may want to add some rotation testing in future patches.

Signed-off-by: Matt Roper 
---
 tests/kms_universal_plane.c | 107 
 1 file changed, 107 insertions(+)

diff --git a/tests/kms_universal_plane.c b/tests/kms_universal_plane.c
index b233166..b06b51e 100644
--- a/tests/kms_universal_plane.c
+++ b/tests/kms_universal_plane.c
@@ -54,6 +54,13 @@ typedef struct {
struct igt_fb red_fb, blue_fb;
 } pageflip_test_t;
 
+typedef struct {
+   data_t *data;
+   int x, y;
+   int w, h;
+   struct igt_fb biggreen_fb, smallred_fb, smallblue_fb;
+} gen9_test_t;
+
 static void
 functional_test_init(functional_test_t *test, igt_output_t *output, enum pipe 
pipe)
 {
@@ -637,6 +644,101 @@ cursor_leak_test_pipe(data_t *data, enum pipe pipe, 
igt_output_t *output)
 }
 
 static void
+gen9_test_init(gen9_test_t *test, igt_output_t *output, enum pipe pipe)
+{
+   data_t *data = test->data;
+   drmModeModeInfo *mode;
+
+   igt_output_set_pipe(output, pipe);
+
+   mode = igt_output_get_mode(output);
+   test->w = mode->hdisplay / 2;
+   test->h = mode->vdisplay / 2;
+   test->x = mode->hdisplay / 4;
+   test->y = mode->vdisplay / 4;
+
+   /* Initial framebuffer of full CRTC size */
+   igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+   DRM_FORMAT_XRGB,
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   0.0, 1.0, 0.0,
+   >biggreen_fb);
+
+   /* Framebuffers that only cover a quarter of the CRTC size */
+   igt_create_color_fb(data->drm_fd, test->w, test->h,
+   DRM_FORMAT_XRGB,
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   1.0, 0.0, 0.0,
+   >smallred_fb);
+   igt_create_color_fb(data->drm_fd, test->w, test->h,
+   DRM_FORMAT_XRGB,
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   0.0, 0.0, 1.0,
+   >smallblue_fb);
+}
+
+static void
+gen9_test_fini(gen9_test_t *test, igt_output_t *output)
+{
+   igt_remove_fb(test->data->drm_fd, >biggreen_fb);
+   igt_remove_fb(test->data->drm_fd, >smallred_fb);
+   igt_remove_fb(test->data->drm_fd, >smallblue_fb);
+
+   igt_output_set_pipe(output, PIPE_ANY);
+   igt_display_commit2(>data->display, COMMIT_LEGACY);
+}
+
+/*
+ * Test features specific to gen9+ platforms (i.e., primary plane
+ * windowing)
+ */
+static void
+gen9_test_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+   gen9_test_t test = { .data = data };
+   igt_plane_t *primary;
+
+   int ret = 0;
+
+   igt_skip_on(data->gen < 9);
+   igt_skip_on(pipe >= data->display.n_pipes);
+
+   igt_output_set_pipe(output, pipe);
+
+   gen9_test_init(, output, pipe);
+
+   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+
+   /* Start with a full-screen primary plane */
+   igt_plane_set_fb(primary, _fb);
+   igt_display_commit2(>display, COMMIT_LEGACY);
+
+   /* Set primary to windowed size/position */
+   igt_plane_set_fb(primary, _fb);
+   igt_plane_set_position(primary, test.x, test.y);
+   igt_plane_set_size(primary, test.w, test.h);
+   igt_display_commit2(>display, COMMIT_UNIVERSAL);
+
+   /*
+* SetPlane update to another framebuffer of the same size
+* should succeed
+*/
+   igt_plane_set_fb(primary, _fb);
+   igt_plane_set_position(primary, test.x, test.y);
+   igt_plane_set_size(primary, test.w, test.h);
+   igt_display_commit2(>display, COMMIT_UNIVERSAL);
+
+   /* PageFlip should also succeed */
+   ret = drmModePageFlip(data->drm_fd, output->config.crtc->crtc_id,
+ test.smallblue_fb.fb_id, 0, NULL);
+   igt_assert_eq(ret, 0);
+
+   igt_plane_set_fb(primary, NULL);
+   igt_plane_set_position(primary, 0, 0);
+   gen9_test_fini(, output);
+}
+
+static void
 run_tests_for_pipe(data_t *data, enum pipe pipe)
 {
igt_output_t *output;
@@ -660,6 +762,11 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
  kmstest_pipe_name(pipe))
for_each_connected_output(>display, output)
cursor_leak_test_pipe(data, pipe, output);
+
+   igt_subtest_f("universal-plane-gen9-features-pipe-%s",
+ kmstest_pipe_name(pipe))
+   for_each_connected_output(>display, output)
+   gen9_test_pipe(data, pipe, output);
 }
 
 static 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/kbl: Kabylake A0 is based on Skylake H0.

[Jani Nikula]

On Tue, 06 Oct 2015, Rodrigo Vivi  wrote:
> Kabylake is gen 9.5 derivated from Skylake H0 stepping.
>
> So we don't need pre-production Skylake workaround and also
> firmware loading will use SKL H0 offsets.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7374a0d..580c005 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2436,7 +2436,6 @@ struct drm_i915_cmd_table {
>  })
>  #define INTEL_INFO(p)(&__I915__(p)->info)
>  #define INTEL_DEVID(p)   (INTEL_INFO(p)->device_id)
> -#define INTEL_REVID(p)   (__I915__(p)->dev->pdev->revision)
>  
>  #define IS_I830(dev) (INTEL_DEVID(dev) == 0x3577)
>  #define IS_845G(dev) (INTEL_DEVID(dev) == 0x2562)
> @@ -2508,6 +2507,9 @@ struct drm_i915_cmd_table {
>  
>  #define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
>  
> +#define INTEL_REVID(p)   (__I915__(p)->dev->pdev->revision + \
> +  IS_KABYLAKE(p) ? 7 : 0)
> +

I am not fond of this at all. It will be really confusing that
->revision is different from INTEL_REVID when checking the workarounds,
and that you'll be using SKL_REVID_* to match KBL revision
ids. Additionally, we'll probably want to start removing SKL workarounds
before KBL workarounds.

Others may disagree, but I'd like KBL revid checks be different from
SKL.

>  #define SKL_REVID_A0 (0x0)
>  #define SKL_REVID_B0 (0x1)
>  #define SKL_REVID_C0 (0x2)
> @@ -2515,6 +2517,9 @@ struct drm_i915_cmd_table {
>  #define SKL_REVID_E0 (0x4)
>  #define SKL_REVID_F0 (0x5)
>  
> +/* KBL A0 is based on SKL H0 */
> +#define KBL_REVID_A0 (0x7)

You can't compare this against INTEL_REVID() now can you...? Or is this
not the one in the spec? Confused already.

BR,
Jani.

> +
>  #define BXT_REVID_A0 (0x0)
>  #define BXT_REVID_B0 (0x3)
>  #define BXT_REVID_C0 (0x9)
> -- 
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: Add framework to whitelist specific GPU registers

[Mika Kuoppala]

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 mainly preemption related WA 
> and
> also some general WA.
>
> The reason for using this approach is, the register bits that control 
> preemption
> granularity at the HW level are not context save/restored; so even if we set 
> these
> bits always in kernel they are going to change once the context is switched 
> out.
> We can consider making them non-privileged by default but these registers also
> contain other chicken bits which should not be allowed to be modified.
>
> In the later revisions controlling bits are save/restored at context level but
> in the existing revisions these are exported via other debug registers and 
> should
> be on the whitelist. This patch adds changes to provide HW with a list of 
> registers
> to be whitelisted. HW checks this list during execution and provides access 
> accordingly.
>
> HW imposes a limit on the number of registers on whitelist and it is 
> per-engine.
> At this point we are only enabling whitelist for RCS and we don't foresee any
> requirement for other engines.
>
> The registers to be whitelisted are added using generic workaround list 
> mechanism,
> even these are only enablers for userspace workarounds. But by sharing this
> mechanism we get some test assets without additional cost (Mika).
>
> Cc: Mika Kuoppala 
> Cc: Nick Hoath 
> Signed-off-by: Arun Siluvery 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  9 -
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
>  3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9c10270..44fbd1d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1674,11 +1674,18 @@ struct i915_wa_reg {
>   u32 mask;
>  };
>  
> -#define I915_MAX_WA_REGS 16
> +/*
> + * RING_MAX_NONPRIV_SLOTS is per-engine but at this point we are only
> + * allowing it for RCS as we don't foresee any requirement of having
> + * a whitelist for other engines. When it is really required for
> + * other engines then the limit need to be increased.
> + */
> +#define I915_MAX_WA_REGS (16 + RING_MAX_NONPRIV_SLOTS)
>  
>  struct i915_workarounds {
>   struct i915_wa_reg reg[I915_MAX_WA_REGS];
>   u32 count;
> + u32 hw_whitelist_index[I915_NUM_RINGS];
>  };
>  

I have plans to allow multiple workaround lists. So we could then
have dedicated one for whitelists too, simplifying this.

Reviewed-by: Mika Kuoppala 

>  struct i915_virtual_gpu {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 05c8621..797c74e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1578,6 +1578,8 @@ enum skl_disp_power_wells {
>  #define   RING_WAIT_I8XX (1<<0) /* gen2, PRBx_HEAD */
>  #define   RING_WAIT  (1<<11) /* gen3+, PRBx_CTL */
>  #define   RING_WAIT_SEMAPHORE(1<<10) /* gen6+ */
> +#define RING_FORCE_TO_NONPRIV(base) ((base)+0x4D0)
> +#define   RING_MAX_NONPRIV_SLOTS  12
>  
>  #define GEN7_TLB_RD_ADDR 0x4700
>  
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c82c74c..64b2754 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -800,6 +800,22 @@ static int wa_add(struct drm_i915_private *dev_priv,
>  
>  #define WA_WRITE(addr, val) WA_REG(addr, 0x, val)
>  
> +static inline int wa_ring_whitelist_reg(struct intel_engine_cs *ring,
> +  uint32_t reg_addr)
> +{
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + struct i915_workarounds *wa = _priv->workarounds;
> + const uint32_t index = wa->hw_whitelist_index[ring->id];
> +
> + if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
> + return -EINVAL;
> +
> + WA_WRITE(RING_FORCE_TO_NONPRIV(ring->mmio_base) + index * 4, reg_addr);
> + wa->hw_whitelist_index[ring->id]++;
> +
> + return 0;
> +}
> +
>  static int gen8_init_workarounds(struct intel_engine_cs *ring)
>  {
>   struct drm_device *dev = ring->dev;
> @@ -1094,6 +1110,7 @@ int init_workarounds_ring(struct intel_engine_cs *ring)
>   WARN_ON(ring->id != RCS);
>  
>   dev_priv->workarounds.count = 0;
> + dev_priv->workarounds.hw_whitelist_index[ring->id] = 0;
>  
>   if (IS_BROADWELL(dev))
>   return bdw_init_workarounds(ring);
> -- 
> 1.9.1
>
> ___
> Intel-gfx mailing list
> 

Re: [Intel-gfx] [PATCH v4] drm/i915: Clean up associated VMAs on context destruction

[Chris Wilson]

On Tue, Oct 06, 2015 at 11:28:49AM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 10:04:31AM +0100, Chris Wilson wrote:
> > On Tue, Oct 06, 2015 at 10:58:01AM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin 
> > > > 
> > > > Prevent leaking VMAs and PPGTT VMs when objects are imported
> > > > via flink.
> > > > 
> > > > Scenario is that any VMAs created by the importer will be left
> > > > dangling after the importer exits, or destroys the PPGTT context
> > > > with which they are associated.
> > > > 
> > > > This is caused by object destruction not running when the
> > > > importer closes the buffer object handle due the reference held
> > > > by the exporter. This also leaks the VM since the VMA has a
> > > > reference on it.
> > > > 
> > > > In practice these leaks can be observed by stopping and starting
> > > > the X server on a kernel with fbcon compiled in. Every time
> > > > X server exits another VMA will be leaked against the fbcon's
> > > > frame buffer object.
> > > > 
> > > > Also on systems where flink buffer sharing is used extensively,
> > > > like Android, this leak has even more serious consequences.
> > > > 
> > > > This version is takes a general approach from the  earlier work
> > > > by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
> > > > destruction) and tries to incorporate the subsequent discussion
> > > > between Chris Wilson and Daniel Vetter.
> > > > 
> > > > v2:
> > > > 
> > > > Removed immediate cleanup on object retire - it was causing a
> > > > recursive VMA unbind via i915_gem_object_wait_rendering. And
> > > > it is in fact not even needed since by definition context
> > > > cleanup worker runs only after the last context reference has
> > > > been dropped, hence all VMAs against the VM belonging to the
> > > > context are already on the inactive list.
> > > > 
> > > > v3:
> > > > 
> > > > Previous version could deadlock since VMA unbind waits on any
> > > > rendering on an object to complete. Objects can be busy in a
> > > > different VM which would mean that the cleanup loop would do
> > > > the wait with the struct mutex held.
> > > > 
> > > > This is an even simpler approach where we just unbind VMAs
> > > > without waiting since we know all VMAs belonging to this VM
> > > > are idle, and there is nothing in flight, at the point
> > > > context destructor runs.
> > > > 
> > > > v4:
> > > > 
> > > > Double underscore prefix for __915_vma_unbind_no_wait and a
> > > > commit message typo fix. (Michel Thierry)
> > > > 
> > > > Signed-off-by: Tvrtko Ursulin 
> > > > Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
> > > > Reviewed-by: Michel Thierry 
> > > > Cc: Daniel Vetter 
> > > > Cc: Chris Wilson 
> > > > Cc: Rafael Barbalho 
> > > > Cc: Michel Thierry 
> > > 
> > > Queued for -next, thanks for the patch.
> > 
> > Please no, it's an awful patch and does not even fix the root cause of
> > the leak (that the vma are not closed when the handle is).
> 
> It's a lose-lose situation for me as maintainer (and this holds in general
> really, not just for this patch):
> - Either I wield my considerable maintainer powers and force proper
>   solution, which will piss of a lot of people.
> - Or I just merge intermediate stuff and piss of another set of people
>   (including likely our all future selves because we're slowly digging a
>   tech debt grave).
> 
> What I can't do with maintainer fu is force collaboration, I can only try
> to piss off everyone equally. And today the die rolled a "merge".

Pity it didn't roll "what's the impact and where is the bugzilla?" :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

[Chris Wilson]

On Tue, Oct 06, 2015 at 10:38:22AM +0200, Daniel Vetter wrote:
> On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> > On 10/5/2015 5:36 PM, Dave Gordon wrote:
> > >On 02/10/15 14:16, Michel Thierry wrote:
> > >>We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
> > >>range pt in gen6_for_each_pde").
> > >>
> > >>But the static analyzer still complains that, just before we break due
> > >>to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an
> > >>iter value that is bigger than I915_PDES. Of course, this isn't really
> > >>a problem since no one uses pt outside the macro. Still, every single
> > >>new usage of the macro will create a new issue for us to mark as a
> > >>false positive.
> > >>
> > >>Also, Paulo re-started the discussion a while ago [1], but didn't end up
> > >>implemented.
> > >>
> > >>In order to "solve" this "problem", this patch takes the ideas from
> > >>Chris and Dave, but that check would change the desired behavior of the
> > >>code, because the object (for example pdp->page_directory[iter]) can be
> > >>null during init/alloc, and C would take this as false, breaking the for
> > >>loop immediately.
> > >>
> > >>This has been already verified with "static analysis tools".
> > >>
> > >>[1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html
> > >>
> > >>v2: Make it a single statement, while preventing the common subexpression
> > >>elimination (Chris)
> > >>
> > >>Cc: Paulo Zanoni 
> > >>Cc: Chris Wilson 
> > >>Cc: Dave Gordon 
> > >>Signed-off-by: Michel Thierry 

> Yeah, since ?: is a ternary operator parsing implicitly adds the () in the
> middle and always parses it as a ? (b) : c. If lower-level operators in
> the middle could split the ternary operator then it would result in
> parsing fail (sinc ? without the : is just useless). So lgtm. Someone
> willing to smack an r-b onto the patch?

I think it's good enough.
Reviewed-by: Chris Wilson 

Something to consider is that ppgtt_insert is 10x slower than
ppgtt_clear, and that some workloads (admittedly not 48b!) spend a
disproportionate amount of time changing PTE. If you have ideas for
spending up insertion, feel free to experiment!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Clean up associated VMAs on context destruction

[Tvrtko Ursulin]

On 06/10/15 10:34, Chris Wilson wrote:

On Tue, Oct 06, 2015 at 11:28:49AM +0200, Daniel Vetter wrote:

On Tue, Oct 06, 2015 at 10:04:31AM +0100, Chris Wilson wrote:

On Tue, Oct 06, 2015 at 10:58:01AM +0200, Daniel Vetter wrote:

On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.

Scenario is that any VMAs created by the importer will be left
dangling after the importer exits, or destroys the PPGTT context
with which they are associated.

This is caused by object destruction not running when the
importer closes the buffer object handle due the reference held
by the exporter. This also leaks the VM since the VMA has a
reference on it.

In practice these leaks can be observed by stopping and starting
the X server on a kernel with fbcon compiled in. Every time
X server exits another VMA will be leaked against the fbcon's
frame buffer object.

Also on systems where flink buffer sharing is used extensively,
like Android, this leak has even more serious consequences.

This version is takes a general approach from the  earlier work
by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
destruction) and tries to incorporate the subsequent discussion
between Chris Wilson and Daniel Vetter.

v2:

Removed immediate cleanup on object retire - it was causing a
recursive VMA unbind via i915_gem_object_wait_rendering. And
it is in fact not even needed since by definition context
cleanup worker runs only after the last context reference has
been dropped, hence all VMAs against the VM belonging to the
context are already on the inactive list.

v3:

Previous version could deadlock since VMA unbind waits on any
rendering on an object to complete. Objects can be busy in a
different VM which would mean that the cleanup loop would do
the wait with the struct mutex held.

This is an even simpler approach where we just unbind VMAs
without waiting since we know all VMAs belonging to this VM
are idle, and there is nothing in flight, at the point
context destructor runs.

v4:

Double underscore prefix for __915_vma_unbind_no_wait and a
commit message typo fix. (Michel Thierry)

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
Reviewed-by: Michel Thierry 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Rafael Barbalho 
Cc: Michel Thierry 


Queued for -next, thanks for the patch.


Please no, it's an awful patch and does not even fix the root cause of
the leak (that the vma are not closed when the handle is).


It's a lose-lose situation for me as maintainer (and this holds in general
really, not just for this patch):
- Either I wield my considerable maintainer powers and force proper
   solution, which will piss of a lot of people.
- Or I just merge intermediate stuff and piss of another set of people
   (including likely our all future selves because we're slowly digging a
   tech debt grave).

What I can't do with maintainer fu is force collaboration, I can only try
to piss off everyone equally. And today the die rolled a "merge".


Pity it didn't roll "what's the impact and where is the bugzilla?" :)


There is this one:

https://bugs.freedesktop.org/show_bug.cgi?id=87729

And I could raise another one for leaking VMAs on X.org restart? :)

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fixup! drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3) [regression]

[Daniel Vetter]

Another regression for Jairo to track. Also this one is bisected too
(although not 100% confirmed).
-Daniel

On Fri, Oct 2, 2015 at 8:43 PM, Zanoni, Paulo R  
wrote:
> Em Qui, 2015-10-01 às 16:03 -0700, Matt Roper escreveu:
>> Cc: Paulo Zanoni 
>> Signed-off-by: Matt Roper 
>> ---
>> Paulo, I'm not positive that this is the cause of the issues you're
>> seeing, but
>> I did find this unwanted behavior change while re-reading all the SKL
>> watermark
>> code.  Could you give this a try and see if it improves your
>> situation at all?
>
> Thanks for the patch, but unfortunately this doesn't solve the problems
> I'm seeing.
>
> For my normal work activities I'm carrying a patch that reverts the
> following commits:
>
> drm/i915: Calculate watermark configuration during atomic check (v2)
> drm/i915: Don't set plane visible during HW readout if CRTC is off
> drm/i915: Calculate ILK-style watermarks during atomic check (v3)
> drm/i915: Calculate pipe watermarks into CRTC state (v3)
> drm/i915: Refactor ilk_update_wm (v3)
> drm/i915: Drop intel_update_sprite_watermarks
>
> So I guess the sprite update thing is very likely the first bad commit.
> I'm also noticing that the screen stays black for _way_ too much time
> during boot, but I'm not sure it's caused by the watermark series:
> might be something else on -nightly.
>
> Thanks,
> Paulo
>
>>
>>  drivers/gpu/drm/i915/intel_pm.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 3857592..22c97f2 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -2951,6 +2951,9 @@ skl_get_total_relative_data_rate(const struct
>> intel_crtc_state *cstate)
>>   if (pstate->fb == NULL)
>>   continue;
>>
>> + if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR)
>> + continue;
>> +
>>   /* packed/uv */
>>   total_data_rate +=
>> skl_plane_relative_data_rate(cstate,
>>   psta
>> te,
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Clean up associated VMAs on context destruction

[Daniel Vetter]

On Tue, Oct 06, 2015 at 10:04:31AM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 10:58:01AM +0200, Daniel Vetter wrote:
> > On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Prevent leaking VMAs and PPGTT VMs when objects are imported
> > > via flink.
> > > 
> > > Scenario is that any VMAs created by the importer will be left
> > > dangling after the importer exits, or destroys the PPGTT context
> > > with which they are associated.
> > > 
> > > This is caused by object destruction not running when the
> > > importer closes the buffer object handle due the reference held
> > > by the exporter. This also leaks the VM since the VMA has a
> > > reference on it.
> > > 
> > > In practice these leaks can be observed by stopping and starting
> > > the X server on a kernel with fbcon compiled in. Every time
> > > X server exits another VMA will be leaked against the fbcon's
> > > frame buffer object.
> > > 
> > > Also on systems where flink buffer sharing is used extensively,
> > > like Android, this leak has even more serious consequences.
> > > 
> > > This version is takes a general approach from the  earlier work
> > > by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
> > > destruction) and tries to incorporate the subsequent discussion
> > > between Chris Wilson and Daniel Vetter.
> > > 
> > > v2:
> > > 
> > > Removed immediate cleanup on object retire - it was causing a
> > > recursive VMA unbind via i915_gem_object_wait_rendering. And
> > > it is in fact not even needed since by definition context
> > > cleanup worker runs only after the last context reference has
> > > been dropped, hence all VMAs against the VM belonging to the
> > > context are already on the inactive list.
> > > 
> > > v3:
> > > 
> > > Previous version could deadlock since VMA unbind waits on any
> > > rendering on an object to complete. Objects can be busy in a
> > > different VM which would mean that the cleanup loop would do
> > > the wait with the struct mutex held.
> > > 
> > > This is an even simpler approach where we just unbind VMAs
> > > without waiting since we know all VMAs belonging to this VM
> > > are idle, and there is nothing in flight, at the point
> > > context destructor runs.
> > > 
> > > v4:
> > > 
> > > Double underscore prefix for __915_vma_unbind_no_wait and a
> > > commit message typo fix. (Michel Thierry)
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
> > > Reviewed-by: Michel Thierry 
> > > Cc: Daniel Vetter 
> > > Cc: Chris Wilson 
> > > Cc: Rafael Barbalho 
> > > Cc: Michel Thierry 
> > 
> > Queued for -next, thanks for the patch.
> 
> Please no, it's an awful patch and does not even fix the root cause of
> the leak (that the vma are not closed when the handle is).

It's a lose-lose situation for me as maintainer (and this holds in general
really, not just for this patch):
- Either I wield my considerable maintainer powers and force proper
  solution, which will piss of a lot of people.
- Or I just merge intermediate stuff and piss of another set of people
  (including likely our all future selves because we're slowly digging a
  tech debt grave).

What I can't do with maintainer fu is force collaboration, I can only try
to piss off everyone equally. And today the die rolled a "merge".

Oh well.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 3/3] gem_memory_bandwidth: Add test

[Chris Wilson]

On Mon, Oct 05, 2015 at 02:42:25PM +0300, Antti Koskipaa wrote:
> This is a benchmark for testing the GPU read and write bandwidth.

I don't see any pass/fail logic so why put in amongst the regression
tests?

Please don't advertise this as gem_memory_bandwidth either, it is just a
rendercopy speed test. Note that LOOPS is critical here, setting it to 1
and we measure dispatch overhead (also v. important), setting it to
10,000 we saturate the RCS ring, force RPS boosting etc. Similarly,
measuring performance at min/max clocks is also interesting. There are a
lot of implicit variables here at play that are not taken account of.

I would like to have a set of perf tests as regression tests. What I
have in mind is basically doing a fixed workload inside igt and have the
core automatically compare the runtime of a subtest against a local
database of results and s/PASS/SLOW/ (or outright FAIL) if it exceeds
some threshold. 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH libdrm] intel/kbl: Add Kabylake PCI IDs

[Chris Wilson]

On Mon, Oct 05, 2015 at 03:50:12PM -0700, Rodrigo Vivi wrote:
> Also, following kernel definition Kabylake is Skylake.
> 
> Signed-off-by: Rodrigo Vivi 

Once upon a time we had a plan to migrate everyone over to using
i915_pciids.h from the kernel (so that we have a single authority).

I guess we are not progressing very well...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Kumar, Shobhit]

On 10/05/2015 09:05 PM, Imre Deak wrote:

On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:

Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.

Cc: Imre Deak 
Signed-off-by: Shobhit Kumar 
---
  drivers/gpu/drm/i915/intel_ddi.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2d3cc82..675c60d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+
+   skl_init_cdclk(dev_priv);


How does this prevent changing the clock if BIOS did enable some output?
We shouldn't change the clock in that case.


In that case it will try to re-apply the same clock that BIOS enabled. 
Not sure if this is allowed, but I checked the cdclock change sequence 
and it is mostly followed in skl_init_cdclk. In my tests where BIOS does 
enable this, I faced no issues in initializing again in driver. I have 
noticed on some pre-os this value is programmed correctly except for the 
decimal part. That causes AUX transactions to fail on SKl. That is what 
triggered this patch actually. So other way is to completely validate 
the value in get_display_clock_speed instead of bit[28:26] and then if 
wrong then only do the cdclk init.


Regards
Shobhit




} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Kumar, Shobhit]

On 10/06/2015 12:05 PM, Jani Nikula wrote:

On Mon, 05 Oct 2015, Imre Deak  wrote:

On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:

Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.

Cc: Imre Deak 
Signed-off-by: Shobhit Kumar 
---
  drivers/gpu/drm/i915/intel_ddi.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2d3cc82..675c60d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+
+   skl_init_cdclk(dev_priv);


How does this prevent changing the clock if BIOS did enable some output?
We shouldn't change the clock in that case.


Random comment from the back, what about intentional cdclk change on
module load? We're supposed to have that for bdw [1] but last I checked
it failed... [2].


Yes. We will require cdclk change run time as well say if we hot plug a 
DP 4k@60. So this capability is something that might really be needed.


Regards
Shobhit



BR,
Jani.

[1] http://mid.gmane.org/145514-4156-8-git-send-email-mika.kah...@intel.com
[2] http://mid.gmane.org/87bngf4xk3@intel.com





} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);






___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

[Daniel Vetter]

On Tue, Oct 06, 2015 at 10:43:48AM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 10:38:22AM +0200, Daniel Vetter wrote:
> > On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> > > On 10/5/2015 5:36 PM, Dave Gordon wrote:
> > > >On 02/10/15 14:16, Michel Thierry wrote:
> > > >>We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
> > > >>range pt in gen6_for_each_pde").
> > > >>
> > > >>But the static analyzer still complains that, just before we break due
> > > >>to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an
> > > >>iter value that is bigger than I915_PDES. Of course, this isn't really
> > > >>a problem since no one uses pt outside the macro. Still, every single
> > > >>new usage of the macro will create a new issue for us to mark as a
> > > >>false positive.
> > > >>
> > > >>Also, Paulo re-started the discussion a while ago [1], but didn't end up
> > > >>implemented.
> > > >>
> > > >>In order to "solve" this "problem", this patch takes the ideas from
> > > >>Chris and Dave, but that check would change the desired behavior of the
> > > >>code, because the object (for example pdp->page_directory[iter]) can be
> > > >>null during init/alloc, and C would take this as false, breaking the for
> > > >>loop immediately.
> > > >>
> > > >>This has been already verified with "static analysis tools".
> > > >>
> > > >>[1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html
> > > >>
> > > >>v2: Make it a single statement, while preventing the common 
> > > >>subexpression
> > > >>elimination (Chris)
> > > >>
> > > >>Cc: Paulo Zanoni 
> > > >>Cc: Chris Wilson 
> > > >>Cc: Dave Gordon 
> > > >>Signed-off-by: Michel Thierry 
> 
> > Yeah, since ?: is a ternary operator parsing implicitly adds the () in the
> > middle and always parses it as a ? (b) : c. If lower-level operators in
> > the middle could split the ternary operator then it would result in
> > parsing fail (sinc ? without the : is just useless). So lgtm. Someone
> > willing to smack an r-b onto the patch?
> 
> I think it's good enough.
> Reviewed-by: Chris Wilson 

Queued for -next, thanks for the patch.

> Something to consider is that ppgtt_insert is 10x slower than
> ppgtt_clear, and that some workloads (admittedly not 48b!) spend a
> disproportionate amount of time changing PTE. If you have ideas for
> spending up insertion, feel free to experiment!

Hm, where do we waste all that time? 10x slower is pretty impressive since
on a quick look I can only see the sg table walk as the additional bit of
memory traversals insert does on top of clear ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 7/8] drm/i915: BDW clock change support [regression]

[Daniel Vetter]

On Tue, Jun 16, 2015 at 04:07:40PM +0300, Jani Nikula wrote:
> On Tue, 16 Jun 2015, Jani Nikula  wrote:
> > On Wed, 03 Jun 2015, Mika Kahola  wrote:
> >> From: Ville Syrjälä 
> >>
> >> Add support for changing cdclk frequency during runtime on BDW. The
> >> procedure is quite a bit different on BDW from the one on HSW, so
> >> add a separate function for it.
> >>
> >> Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
> >> so take that into account when computing the max pixel rate.
> >>
> >> v2: Grab rps.hw_lock around sandybridge_pcode_write()
> >> v3: Rebase due to power well vs. .global_resources() reordering
> >> v4: Rebased to the latest
> >> v5: Rebased to the latest
> >> v6: Patch order shuffle so that Broadwell CD clock change is
> >> applied before the patch for Haswell CD clock change
> >> v7: Fix for patch style problems
> >>
> >> Signed-off-by: Ville Syrjälä 
> >> Signed-off-by: Mika Kahola 
> >
> > This patch hard hangs my BDW NUC at boot when both DP and HDMI are
> > connected. Either DP or HDMI alone are good, same with hotplugging the
> > other afterwards. Booting to grub with both connected, and unplugging
> > HDMI before loading the kernel also reproduces the issue.
> >
> > It looks like the problem boils down to the BIOS setting up a smaller
> > resolution on the DP display when both are connected, and this patch
> > fails to cope with that on i915 load.
> 
> By "this patch" I obviously refer to
> 
> commit b432e5cfd5e92127ad2dd83bfc3083f1dbce43fb
> Author: Ville Syrjälä 
> Date:   Wed Jun 3 15:45:13 2015 +0300
> 
> drm/i915: BDW clock change support
> 
> and everything works for the commit before that.

Another regression for Jairo to track. Jairo please add the bisect result
to the bugzilla and mark it as bisected too.

Thanks, Daniel

> 
> BR,
> Jani.
> 
> 
> 
> 
> 
> >
> > BR,
> > Jani.
> >
> >
> >
> >>
> >> Author:Ville Syrjälä 
> >> ---
> >>  drivers/gpu/drm/i915/i915_reg.h  |   2 +
> >>  drivers/gpu/drm/i915/intel_display.c | 216 
> >> +--
> >>  2 files changed, 208 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 7213224..0f72c0e 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -6705,6 +6705,7 @@ enum skl_disp_power_wells {
> >>  #define GEN6_PCODE_READ_RC6VIDS   0x5
> >>  #define GEN6_ENCODE_RC6_VID(mv)   (((mv) - 245) / 5)
> >>  #define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) + 245)
> >> +#define   BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ   0x18
> >>  #define   GEN9_PCODE_READ_MEM_LATENCY 0x6
> >>  #define GEN9_MEM_LATENCY_LEVEL_MASK   0xFF
> >>  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> >> @@ -7170,6 +7171,7 @@ enum skl_disp_power_wells {
> >>  #define  LCPLL_CLK_FREQ_337_5_BDW (2<<26)
> >>  #define  LCPLL_CLK_FREQ_675_BDW   (3<<26)
> >>  #define  LCPLL_CD_CLOCK_DISABLE   (1<<25)
> >> +#define  LCPLL_ROOT_CD_CLOCK_DISABLE  (1<<24)
> >>  #define  LCPLL_CD2X_CLOCK_DISABLE (1<<23)
> >>  #define  LCPLL_POWER_DOWN_ALLOW   (1<<22)
> >>  #define  LCPLL_CD_SOURCE_FCLK (1<<21)
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index c3f01aa..b1e2069 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -5751,7 +5751,22 @@ static void intel_update_max_cdclk(struct 
> >> drm_device *dev)
> >>  {
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>  
> >> -  if (IS_VALLEYVIEW(dev)) {
> >> +  if (IS_BROADWELL(dev))  {
> >> +  /*
> >> +   * FIXME with extra cooling we can allow
> >> +   * 540 MHz for ULX and 675 Mhz for ULT.
> >> +   * How can we know if extra cooling is
> >> +   * available? PCI ID, VTB, something else?
> >> +   */
> >> +  if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
> >> +  dev_priv->max_cdclk_freq = 45;
> >> +  else if (IS_BDW_ULX(dev))
> >> +  dev_priv->max_cdclk_freq = 45;
> >> +  else if (IS_BDW_ULT(dev))
> >> +  dev_priv->max_cdclk_freq = 54;
> >> +  else
> >> +  dev_priv->max_cdclk_freq = 675000;
> >> +  } else if (IS_VALLEYVIEW(dev)) {
> >>dev_priv->max_cdclk_freq = 40;
> >>} else {
> >>/* otherwise assume cdclk is fixed */
> >> @@ -6621,13 +6636,11 @@ static bool pipe_config_supports_ips(struct 
> >> drm_i915_private *dev_priv,
> >>return true;
> >>  
> >>/*
> >> -   * FIXME if we compare against max we should then
> >> 

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

[Chris Wilson]

On Tue, Oct 06, 2015 at 12:09:51PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 10:43:48AM +0100, Chris Wilson wrote:
> > On Tue, Oct 06, 2015 at 10:38:22AM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> > > > On 10/5/2015 5:36 PM, Dave Gordon wrote:
> > > > >On 02/10/15 14:16, Michel Thierry wrote:
> > > > >>We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
> > > > >>range pt in gen6_for_each_pde").
> > > > >>
> > > > >>But the static analyzer still complains that, just before we break due
> > > > >>to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an
> > > > >>iter value that is bigger than I915_PDES. Of course, this isn't really
> > > > >>a problem since no one uses pt outside the macro. Still, every single
> > > > >>new usage of the macro will create a new issue for us to mark as a
> > > > >>false positive.
> > > > >>
> > > > >>Also, Paulo re-started the discussion a while ago [1], but didn't end 
> > > > >>up
> > > > >>implemented.
> > > > >>
> > > > >>In order to "solve" this "problem", this patch takes the ideas from
> > > > >>Chris and Dave, but that check would change the desired behavior of 
> > > > >>the
> > > > >>code, because the object (for example pdp->page_directory[iter]) can 
> > > > >>be
> > > > >>null during init/alloc, and C would take this as false, breaking the 
> > > > >>for
> > > > >>loop immediately.
> > > > >>
> > > > >>This has been already verified with "static analysis tools".
> > > > >>
> > > > >>[1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html
> > > > >>
> > > > >>v2: Make it a single statement, while preventing the common 
> > > > >>subexpression
> > > > >>elimination (Chris)
> > > > >>
> > > > >>Cc: Paulo Zanoni 
> > > > >>Cc: Chris Wilson 
> > > > >>Cc: Dave Gordon 
> > > > >>Signed-off-by: Michel Thierry 
> > 
> > > Yeah, since ?: is a ternary operator parsing implicitly adds the () in the
> > > middle and always parses it as a ? (b) : c. If lower-level operators in
> > > the middle could split the ternary operator then it would result in
> > > parsing fail (sinc ? without the : is just useless). So lgtm. Someone
> > > willing to smack an r-b onto the patch?
> > 
> > I think it's good enough.
> > Reviewed-by: Chris Wilson 
> 
> Queued for -next, thanks for the patch.
> 
> > Something to consider is that ppgtt_insert is 10x slower than
> > ppgtt_clear, and that some workloads (admittedly not 48b!) spend a
> > disproportionate amount of time changing PTE. If you have ideas for
> > spending up insertion, feel free to experiment!
> 
> Hm, where do we waste all that time? 10x slower is pretty impressive since
> on a quick look I can only see the sg table walk as the additional bit of
> memory traversals insert does on top of clear ...

The sg_page_iter claims top spot, followed by the memory dereferences
(at a guess, it doesn't seem the individual sg struct isn't dense enough
to be cache friendly or maybe we should just cachealign it?). We can make
substantial improvement by opencoding the page iter (under the assumption
that we do not have page coallescing) like:

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly=f9baf155c3096058ef9aeeb39b586713291efc56

with that and eliminating the ivb_pte_encode() indirection gets us to
only be ~5x slower than clearing. It is not pretty (and is rather
cavalier about the last page), but at that point it seems to be memory bound.

However, in this particular benchmark where inserting ppgtt dominates
the kernel profile, we are GPU bound and improving the insert is lost in
the noise. (Unless we disable the GPU load and assume an infinitely fast
GPU like Skylake!)
-Chris


-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Chris Wilson]

Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".

To keep Daniel happy with the prospect of being able to reuse these
fields in the next decade, continue to ensure that current userspace is
not passing garbage in through the dead fields.

v2: Fix the cliprects_ptr check

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 154 ++---
 drivers/gpu/drm/i915/intel_lrc.c   |  15 ---
 2 files changed, 31 insertions(+), 138 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 75a0c8b5305b..045a7631faa0 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -947,7 +947,21 @@ i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 
*exec)
if (exec->flags & __I915_EXEC_UNKNOWN_FLAGS)
return false;
 
-   return ((exec->batch_start_offset | exec->batch_len) & 0x7) == 0;
+   /* Kernel clipping was a DRI1 misfeature */
+   if (exec->num_cliprects || exec->cliprects_ptr)
+   return false;
+
+   if (exec->DR4 == 0x) {
+   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   exec->DR4 = 0;
+   }
+   if (exec->DR1 || exec->DR4)
+   return false;
+
+   if ((exec->batch_start_offset | exec->batch_len) & 0x7)
+   return false;
+
+   return true;
 }
 
 static int
@@ -,47 +1125,6 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return 0;
 }
 
-static int
-i915_emit_box(struct drm_i915_gem_request *req,
- struct drm_clip_rect *box,
- int DR1, int DR4)
-{
-   struct intel_engine_cs *ring = req->ring;
-   int ret;
-
-   if (box->y2 <= box->y1 || box->x2 <= box->x1 ||
-   box->y2 <= 0 || box->x2 <= 0) {
-   DRM_ERROR("Bad box %d,%d..%d,%d\n",
- box->x1, box->y1, box->x2, box->y2);
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(ring->dev)->gen >= 4) {
-   ret = intel_ring_begin(req, 4);
-   if (ret)
-   return ret;
-
-   intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO_I965);
-   intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
-   intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
<< 16);
-   intel_ring_emit(ring, DR4);
-   } else {
-   ret = intel_ring_begin(req, 6);
-   if (ret)
-   return ret;
-
-   intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO);
-   intel_ring_emit(ring, DR1);
-   intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
-   intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
<< 16);
-   intel_ring_emit(ring, DR4);
-   intel_ring_emit(ring, 0);
-   }
-   intel_ring_advance(ring);
-
-   return 0;
-}
-
 static struct drm_i915_gem_object*
 i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
  struct drm_i915_gem_exec_object2 *shadow_exec_entry,
@@ -1210,65 +1183,21 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas)
 {
-   struct drm_clip_rect *cliprects = NULL;
struct drm_device *dev = params->dev;
struct intel_engine_cs *ring = params->ring;
struct drm_i915_private *dev_priv = dev->dev_private;
u64 exec_start, exec_len;
int instp_mode;
u32 instp_mask;
-   int i, ret = 0;
-
-   if (args->num_cliprects != 0) {
-   if (ring != _priv->ring[RCS]) {
-   DRM_DEBUG("clip rectangles are only valid with the 
render ring\n");
-   return -EINVAL;
-   }
-
-   if (INTEL_INFO(dev)->gen >= 5) {
-   DRM_DEBUG("clip rectangles are only valid on 
pre-gen5\n");
-   return -EINVAL;
-   }
-
-   if (args->num_cliprects > UINT_MAX / sizeof(*cliprects)) {
-   DRM_DEBUG("execbuf with %u cliprects\n",
- args->num_cliprects);
-   return -EINVAL;
-   }
-
-   cliprects = kcalloc(args->num_cliprects,
-   sizeof(*cliprects),
-   GFP_KERNEL);
-   if (cliprects == NULL) {
-   ret = -ENOMEM;
-   goto error;
-   }
-
-   if 

[Intel-gfx] [PATCH 2/2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level

[Chris Wilson]

Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. So we can safely replace i915_gem_object_is_pinned()
here with a plain obj->pin_display check. During rebinding, we will check
sanity checks in case vma->pin_count is erroneously set.

At the same time, we can micro-optimise GTT mmap() behaviour since we
only need to relinquish the mmaps before Sandybridge.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 40 
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d4a3bdf0c5b6..2b8ed7a2faab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3629,31 +3629,34 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
 {
struct drm_device *dev = obj->base.dev;
struct i915_vma *vma, *next;
+   bool bound = false;
int ret = 0;
 
if (obj->cache_level == cache_level)
goto out;
 
-   if (i915_gem_obj_is_pinned(obj)) {
-   DRM_DEBUG("can not change the cache level of pinned objects\n");
-   return -EBUSY;
-   }
-
list_for_each_entry_safe(vma, next, >vma_list, vma_link) {
+   if (!drm_mm_node_allocated(>node))
+   continue;
+
+   if (vma->pin_count) {
+   DRM_DEBUG("can not change the cache level of pinned 
objects\n");
+   return -EBUSY;
+   }
+
if (!i915_gem_valid_gtt_space(vma, cache_level)) {
ret = i915_vma_unbind(vma);
if (ret)
return ret;
-   }
+   } else
+   bound = true;
}
 
-   if (i915_gem_obj_bound_any(obj)) {
+   if (bound) {
ret = i915_gem_object_wait_rendering(obj, false);
if (ret)
return ret;
 
-   i915_gem_object_finish_gtt(obj);
-
/* Before SandyBridge, you could not use tiling or fence
 * registers with snooped memory, so relinquish any fences
 * currently pointing to our region in the aperture.
@@ -3664,13 +3667,18 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
return ret;
}
 
-   list_for_each_entry(vma, >vma_list, vma_link)
-   if (drm_mm_node_allocated(>node)) {
-   ret = i915_vma_bind(vma, cache_level,
-   PIN_UPDATE);
-   if (ret)
-   return ret;
-   }
+   /* Access to snoopable pages through the GTT is incoherent. */
+   if (cache_level != I915_CACHE_NONE && !HAS_LLC(dev))
+   i915_gem_release_mmap(obj);
+
+   list_for_each_entry(vma, >vma_list, vma_link) {
+   if (!drm_mm_node_allocated(>node))
+   continue;
+
+   ret = i915_vma_bind(vma, cache_level, PIN_UPDATE);
+   if (ret)
+   return ret;
+   }
}
 
list_for_each_entry(vma, >vma_list, vma_link)
-- 
2.6.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Imre Deak]

On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> On 10/05/2015 09:05 PM, Imre Deak wrote:
> > On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> >> Mostly reuse what is programmed by pre-os, but in case there is no
> >> pre-os initialization, init the cdclk with the default value.
> >>
> >> Cc: Imre Deak 
> >> Signed-off-by: Shobhit Kumar 
> >> ---
> >>   drivers/gpu/drm/i915/intel_ddi.c | 6 ++
> >>   1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 2d3cc82..675c60d 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> >>
> >>cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
> >>dev_priv->skl_boot_cdclk = cdclk_freq;
> >> -  if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> >> -  DRM_ERROR("LCPLL1 is disabled\n");
> >> -  else
> >> -  intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> >> +
> >> +  skl_init_cdclk(dev_priv);
> >
> > How does this prevent changing the clock if BIOS did enable some output?
> > We shouldn't change the clock in that case.
> 
> In that case it will try to re-apply the same clock that BIOS enabled. 
> Not sure if this is allowed, but I checked the cdclock change sequence 
> and it is mostly followed in skl_init_cdclk.
> In my tests where BIOS does enable this, I faced no issues in
> initializing again in driver.

The first step in that sequence:
"Disable all display engine functions using the full mode set disable
sequence on all pipes, ports, and planes."

So the problem is not that the PLL itself may be enabled here (as BIOS
left it), but that some output is also enabled.

> I have noticed on some pre-os this value is programmed correctly except
> for the decimal part. That causes AUX transactions to fail on SKl. That
> is what triggered this patch actually. So other way is to completely
> validate the value in get_display_clock_speed instead of bit[28:26] and
> then if wrong then only do the cdclk init.

I think we'd need to detect at this point if outputs are enabled and
only attempt to work around the above BIOS problem if this is not the
case. Alternatively you could also disable the active outputs as a first
step.

> 
> Regards
> Shobhit
> 
> >
> >>} else if (IS_BROXTON(dev)) {
> >>broxton_init_cdclk(dev);
> >>broxton_ddi_phy_init(dev);
> >
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Make the link training test for same voltage smaller

[Ander Conselvan de Oliveira]

It makes it slightly easier to read.

v2: Add missing word in patch title. (Ander)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 8b20970..ba640b7 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -186,14 +186,13 @@ clock_recovery_voltage_step(struct intel_dp *intel_dp)
break;
 
/* Check to see if we've tried the same voltage 5 times */
-   if (intel_dp_get_train_voltage(intel_dp) == voltage) {
-   ++voltage_tries;
-   if (voltage_tries == 5) {
-   DRM_ERROR("too many voltage retries, give 
up\n");
-   break;
-   }
-   } else
+   if (intel_dp_get_train_voltage(intel_dp) != voltage) {
voltage_tries = 0;
+   } else if (++voltage_tries == 5) {
+   DRM_ERROR("too many voltage retries, give up\n");
+   break;
+   }
+
voltage = intel_dp_get_train_voltage(intel_dp);
 
/* Update training set as requested by target */
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[Chris Wilson]

In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the number of nodes in the range manager as opposed to O(N).
Insertion however gains an extra O(lg(N)) step for all nodes
irrespective of whether the interval tree is in use. For future i915
patches, eliminating the linear walk is a significant improvement.

Signed-off-by: Chris Wilson 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/Kconfig  |  1 +
 drivers/gpu/drm/drm_mm.c | 71 
 include/drm/drm_mm.h |  5 
 3 files changed, 54 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 06ae5008c5ed..e25050a5a843 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select INTERVAL_TREE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 04de6fd88f8c..e3acd860f738 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -153,6 +153,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
INIT_LIST_HEAD(>hole_stack);
list_add(>node_list, _node->node_list);
 
+   node->it.start = node->start;
+   node->it.last = node->start + size - 1;
+   interval_tree_insert(>it, >interval_tree);
+
BUG_ON(node->start + node->size > adj_end);
 
node->hole_follows = 0;
@@ -178,39 +182,53 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
  */
 int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
 {
-   struct drm_mm_node *hole;
u64 end = node->start + node->size;
-   u64 hole_start;
-   u64 hole_end;
-
-   BUG_ON(node == NULL);
+   struct interval_tree_node *it;
+   struct drm_mm_node *hole;
+   u64 hole_start, hole_end;
 
/* Find the relevant hole to add our node to */
-   drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
-   if (hole_start > node->start || hole_end < end)
-   continue;
+   it = interval_tree_iter_first(>interval_tree,
+ node->start, (u64)-1);
+   if (it == NULL) {
+   hole = list_last_entry(>head_node.node_list,
+  struct drm_mm_node, node_list);
+   } else {
+   hole = container_of(it, typeof(*hole), it);
+   if (hole->start <= node->start)
+   return -ENOSPC;
+
+   hole = list_last_entry(>node_list,
+  struct drm_mm_node, node_list);
+   }
 
-   node->mm = mm;
-   node->allocated = 1;
+   hole_start = drm_mm_hole_node_start(hole);
+   hole_end = drm_mm_hole_node_end(hole);
+   if (hole_start > node->start || hole_end < end)
+   return -ENOSPC;
 
-   INIT_LIST_HEAD(>hole_stack);
-   list_add(>node_list, >node_list);
+   node->mm = mm;
+   node->allocated = 1;
 
-   if (node->start == hole_start) {
-   hole->hole_follows = 0;
-   list_del_init(>hole_stack);
-   }
+   INIT_LIST_HEAD(>hole_stack);
+   list_add(>node_list, >node_list);
 
-   node->hole_follows = 0;
-   if (end != hole_end) {
-   list_add(>hole_stack, >hole_stack);
-   node->hole_follows = 1;
-   }
+   node->it.start = node->start;
+   node->it.last = node->start + node->size - 1;
+   interval_tree_insert(>it, >interval_tree);
 
-   return 0;
+   if (node->start == hole_start) {
+   hole->hole_follows = 0;
+   list_del_init(>hole_stack);
}
 
-   return -ENOSPC;
+   node->hole_follows = 0;
+   if (end != hole_end) {
+   list_add(>hole_stack, >hole_stack);
+   node->hole_follows = 1;
+   }
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_mm_reserve_node);
 
@@ -300,6 +318,10 @@ static void drm_mm_insert_helper_range(struct drm_mm_node 
*hole_node,
INIT_LIST_HEAD(>hole_stack);
list_add(>node_list, _node->node_list);
 
+   node->it.start = node->start;
+   node->it.last = node->start + node->size - 1;
+   interval_tree_insert(>it, >interval_tree);
+
BUG_ON(node->start < start);
BUG_ON(node->start < adj_start);
BUG_ON(node->start + node->size > adj_end);
@@ -388,6 +410,7 @@ void 

[Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

[Chris Wilson]

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary
and fixed objects within the same batch

Signed-off-by: Chris Wilson 
Cc: "Daniel, Thomas" 
---
 drivers/gpu/drm/i915/i915_dma.c|  3 ++
 drivers/gpu/drm/i915/i915_drv.h| 10 +++--
 drivers/gpu/drm/i915/i915_gem.c| 68 +-
 drivers/gpu/drm/i915/i915_gem_evict.c  | 61 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  9 +++-
 drivers/gpu/drm/i915/i915_trace.h  | 23 ++
 include/uapi/drm/i915_drm.h|  4 +-
 7 files changed, 151 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d1121be8..cd79ef114b8e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -170,6 +170,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_RESOURCE_STREAMER:
value = HAS_RESOURCE_STREAMER(dev);
break;
+   case I915_PARAM_HAS_EXEC_SOFTPIN:
+   value = 1;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a0ce011a5dc0..7d351d991022 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2778,10 +2778,11 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
 #define PIN_NONBLOCK   (1<<1)
 #define PIN_GLOBAL (1<<2)
 #define PIN_OFFSET_BIAS(1<<3)
-#define PIN_USER   (1<<4)
-#define PIN_UPDATE (1<<5)
-#define PIN_ZONE_4G(1<<6)
-#define PIN_HIGH   (1<<7)
+#define PIN_OFFSET_FIXED (1<<4)
+#define PIN_USER   (1<<5)
+#define PIN_UPDATE (1<<6)
+#define PIN_ZONE_4G(1<<7)
+#define PIN_HIGH   (1<<8)
 #define PIN_OFFSET_MASK (~4095)
 int __must_check
 i915_gem_object_pin(struct drm_i915_gem_object *obj,
@@ -3127,6 +3128,7 @@ int __must_check i915_gem_evict_something(struct 
drm_device *dev,
  unsigned long start,
  unsigned long end,
  unsigned flags);
+int __must_check i915_gem_evict_for_vma(struct i915_vma *vma, unsigned flags);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
 
 /* belongs in i915_gem_gtt.h */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8fe3df0cdcb8..82efd6a6dee0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3334,7 +3334,6 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u64 start, end;
-   u32 search_flag, alloc_flag;
struct i915_vma *vma;
int ret;
 
@@ -3409,30 +3408,53 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
if (IS_ERR(vma))
goto err_unpin;
 
-   if (flags & PIN_HIGH) {
-   search_flag = DRM_MM_SEARCH_BELOW;
-   alloc_flag = DRM_MM_CREATE_TOP;
+   if (flags & PIN_OFFSET_FIXED) {
+   uint64_t offset = flags & PIN_OFFSET_MASK;
+   if (offset & (alignment - 1) || offset + size > end) {
+   vma = ERR_PTR(-EINVAL);
+   goto err_free_vma;
+   }
+   vma->node.start = offset;
+   vma->node.size = size;
+   vma->node.color = obj->cache_level;
+   ret = drm_mm_reserve_node(>mm, >node);
+   if (ret) {
+   ret = i915_gem_evict_for_vma(vma, flags);
+   if (ret == 0)
+   ret = drm_mm_reserve_node(>mm, >node);
+   }
+   if (ret) {
+   vma = ERR_PTR(ret);
+   goto err_free_vma;
+   }
} else {
-   search_flag = DRM_MM_SEARCH_DEFAULT;
-   alloc_flag = DRM_MM_CREATE_DEFAULT;
-   }
+   u32 search_flag, alloc_flag;
+
+   if (flags & PIN_HIGH) {
+   search_flag = DRM_MM_SEARCH_BELOW;
+   alloc_flag = DRM_MM_CREATE_TOP;
+   } else {
+   search_flag = DRM_MM_SEARCH_DEFAULT;
+   alloc_flag = DRM_MM_CREATE_DEFAULT;
+   }
 
 search_free:
-   ret = 

[Intel-gfx] [PATCH 2/3] drm/i915: Allow the user to pass a context to any ring

[Chris Wilson]

With full-ppgtt, we want the user to have full control over their memory
layout, with a separate instance per context. Forcing them to use a
shared memory layout for !RCS not only duplicates the amount of work we
have to do, but also defeats the memory segregation on offer.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a01c1ebe47ca..19dd6b05ee1d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1033,18 +1033,13 @@ static struct intel_context *
 i915_gem_validate_context(struct drm_device *dev, struct drm_file *file,
  struct intel_engine_cs *ring, const u32 ctx_id)
 {
-   struct intel_context *ctx = NULL;
-   struct i915_ctx_hang_stats *hs;
-
-   if (ring->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
-   return ERR_PTR(-EINVAL);
+   struct intel_context *ctx;
 
ctx = i915_gem_context_get(file->driver_priv, ctx_id);
if (IS_ERR(ctx))
return ctx;
 
-   hs = >hang_stats;
-   if (hs->banned) {
+   if (ctx->hang_stats.banned) {
DRM_DEBUG("Context %u tried to submit while banned\n", ctx_id);
return ERR_PTR(-EIO);
}
-- 
2.6.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Kumar, Shobhit]

On 10/06/2015 04:11 PM, Imre Deak wrote:

On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:

On 10/05/2015 09:05 PM, Imre Deak wrote:

On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:

Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.

Cc: Imre Deak 
Signed-off-by: Shobhit Kumar 
---
   drivers/gpu/drm/i915/intel_ddi.c | 6 ++
   1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2d3cc82..675c60d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+
+   skl_init_cdclk(dev_priv);


How does this prevent changing the clock if BIOS did enable some output?
We shouldn't change the clock in that case.


In that case it will try to re-apply the same clock that BIOS enabled.
Not sure if this is allowed, but I checked the cdclock change sequence
and it is mostly followed in skl_init_cdclk.
In my tests where BIOS does enable this, I faced no issues in
initializing again in driver.


The first step in that sequence:
"Disable all display engine functions using the full mode set disable
sequence on all pipes, ports, and planes."


Oh, yeah, I again made mistake of assuming that display is not enabled 
in the first place. You are right, though it works if I change the clock 
again.




So the problem is not that the PLL itself may be enabled here (as BIOS
left it), but that some output is also enabled.


Yes.




I have noticed on some pre-os this value is programmed correctly except
for the decimal part. That causes AUX transactions to fail on SKl. That
is what triggered this patch actually. So other way is to completely
validate the value in get_display_clock_speed instead of bit[28:26] and
then if wrong then only do the cdclk init.


I think we'd need to detect at this point if outputs are enabled and
only attempt to work around the above BIOS problem if this is not the
case. Alternatively you could also disable the active outputs as a first
step.


Ok, let me detect if any output is enabled by BIOS and accordingly 
initialize cdclk.


Regards
Shobhit





Regards
Shobhit




} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[Daniel Vetter]

On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookups for a particular address will then be O(lg(N)), where N
> is the number of nodes in the range manager as opposed to O(N).
> Insertion however gains an extra O(lg(N)) step for all nodes
> irrespective of whether the interval tree is in use. For future i915
> patches, eliminating the linear walk is a significant improvement.
> 
> Signed-off-by: Chris Wilson 
> Cc: dri-de...@lists.freedesktop.org

For the vma manager David Herrman put the interval tree outside of drm_mm.
Whichever way we pick, but I think we should be consistent about this.
-Daniel

> ---
>  drivers/gpu/drm/Kconfig  |  1 +
>  drivers/gpu/drm/drm_mm.c | 71 
> 
>  include/drm/drm_mm.h |  5 
>  3 files changed, 54 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 06ae5008c5ed..e25050a5a843 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -12,6 +12,7 @@ menuconfig DRM
>   select I2C
>   select I2C_ALGOBIT
>   select DMA_SHARED_BUFFER
> + select INTERVAL_TREE
>   help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 04de6fd88f8c..e3acd860f738 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -153,6 +153,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>   INIT_LIST_HEAD(>hole_stack);
>   list_add(>node_list, _node->node_list);
>  
> + node->it.start = node->start;
> + node->it.last = node->start + size - 1;
> + interval_tree_insert(>it, >interval_tree);
> +
>   BUG_ON(node->start + node->size > adj_end);
>  
>   node->hole_follows = 0;
> @@ -178,39 +182,53 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>   */
>  int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
>  {
> - struct drm_mm_node *hole;
>   u64 end = node->start + node->size;
> - u64 hole_start;
> - u64 hole_end;
> -
> - BUG_ON(node == NULL);
> + struct interval_tree_node *it;
> + struct drm_mm_node *hole;
> + u64 hole_start, hole_end;
>  
>   /* Find the relevant hole to add our node to */
> - drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
> - if (hole_start > node->start || hole_end < end)
> - continue;
> + it = interval_tree_iter_first(>interval_tree,
> +   node->start, (u64)-1);
> + if (it == NULL) {
> + hole = list_last_entry(>head_node.node_list,
> +struct drm_mm_node, node_list);
> + } else {
> + hole = container_of(it, typeof(*hole), it);
> + if (hole->start <= node->start)
> + return -ENOSPC;
> +
> + hole = list_last_entry(>node_list,
> +struct drm_mm_node, node_list);
> + }
>  
> - node->mm = mm;
> - node->allocated = 1;
> + hole_start = drm_mm_hole_node_start(hole);
> + hole_end = drm_mm_hole_node_end(hole);
> + if (hole_start > node->start || hole_end < end)
> + return -ENOSPC;
>  
> - INIT_LIST_HEAD(>hole_stack);
> - list_add(>node_list, >node_list);
> + node->mm = mm;
> + node->allocated = 1;
>  
> - if (node->start == hole_start) {
> - hole->hole_follows = 0;
> - list_del_init(>hole_stack);
> - }
> + INIT_LIST_HEAD(>hole_stack);
> + list_add(>node_list, >node_list);
>  
> - node->hole_follows = 0;
> - if (end != hole_end) {
> - list_add(>hole_stack, >hole_stack);
> - node->hole_follows = 1;
> - }
> + node->it.start = node->start;
> + node->it.last = node->start + node->size - 1;
> + interval_tree_insert(>it, >interval_tree);
>  
> - return 0;
> + if (node->start == hole_start) {
> + hole->hole_follows = 0;
> + list_del_init(>hole_stack);
>   }
>  
> - return -ENOSPC;
> + node->hole_follows = 0;
> + if (end != hole_end) {
> + list_add(>hole_stack, >hole_stack);
> + node->hole_follows = 1;
> + }
> +
> + return 0;
>  }
>  EXPORT_SYMBOL(drm_mm_reserve_node);
>  
> @@ -300,6 +318,10 @@ static void drm_mm_insert_helper_range(struct 
> drm_mm_node *hole_node,
>   INIT_LIST_HEAD(>hole_stack);
>   list_add(>node_list, 

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Kumar, Shobhit]

On 10/06/2015 05:49 PM, Daniel Vetter wrote:

On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:

On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:

On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:

On 10/06/2015 04:11 PM, Imre Deak wrote:

On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:

On 10/05/2015 09:05 PM, Imre Deak wrote:

On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:

Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cdclk with the default value.

Cc: Imre Deak 
Signed-off-by: Shobhit Kumar 
---
   drivers/gpu/drm/i915/intel_ddi.c | 6 ++
   1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2d3cc82..675c60d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)

cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
dev_priv->skl_boot_cdclk = cdclk_freq;
-   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
-   DRM_ERROR("LCPLL1 is disabled\n");
-   else
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+
+   skl_init_cdclk(dev_priv);


How does this prevent changing the clock if BIOS did enable some output?
We shouldn't change the clock in that case.


In that case it will try to re-apply the same clock that BIOS enabled.
Not sure if this is allowed, but I checked the cdclock change sequence
and it is mostly followed in skl_init_cdclk.
In my tests where BIOS does enable this, I faced no issues in
initializing again in driver.


The first step in that sequence:
"Disable all display engine functions using the full mode set disable
sequence on all pipes, ports, and planes."


Oh, yeah, I again made mistake of assuming that display is not enabled in
the first place. You are right, though it works if I change the clock again.



So the problem is not that the PLL itself may be enabled here (as BIOS
left it), but that some output is also enabled.


Yes.




I have noticed on some pre-os this value is programmed correctly except
for the decimal part. That causes AUX transactions to fail on SKl. That
is what triggered this patch actually. So other way is to completely
validate the value in get_display_clock_speed instead of bit[28:26] and
then if wrong then only do the cdclk init.


I think we'd need to detect at this point if outputs are enabled and
only attempt to work around the above BIOS problem if this is not the
case. Alternatively you could also disable the active outputs as a first
step.


Ok, let me detect if any output is enabled by BIOS and accordingly
initialize cdclk.


These kind of fixiups should be done after the hw state readout. We
already have sanitize_crtc/pll/encoder functions, probably best if we add
a sanitize_cdclk or similar for this at the very end of the hw state
sanitize sequence.


Can't be done if we already need a somewhat sane cdclk for the
eDP AUX probing and whatnot.

For actually enabling the cdclk for pushing pixels, we wouldn't need
to do anything except actually plug ia a calc_cdclk for SKL. No idea
why we're not doing that currently. Some extra care may be needed
due to the eDP DPLL0 usag IIRC.


Hm right, cdlck is in the top-level power domain. Added fun is that with
dmc the firmware is supposed to handle it. Messy :(


Yes, exactly. How about just adding verify_cdclk and calling in 
get_display_clock_speed to check if cdclk is programmed correctly along 
with related DPLL0 VCO settings for now. If all looks good, then skip 
else initialize. Now in that case if we have to initialize where do we 
get the cdclock to initialize with at this point ? Any default in VBT ? 
Or go with minimum by default and it can be bumped up later if needed.


Regards
Shobhit


-Daniel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Chris Wilson]

On Tue, Oct 06, 2015 at 01:21:25PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:39:55AM +0100, Chris Wilson wrote:
> > Passing cliprects into the kernel for it to re-execute the batch buffer
> > with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> > removed from the kernel, we can now simply reject any execbuf trying to
> > use this "feature".
> > 
> > To keep Daniel happy with the prospect of being able to reuse these
> > fields in the next decade, continue to ensure that current userspace is
> > not passing garbage in through the dead fields.
> > 
> > v2: Fix the cliprects_ptr check
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> 
> igt subtest seems to be missing to ensure we enforce this. Yay otherwise!

Looking at gem_exec_params/cliprects-invalid, presumably all you want to
do is to remove the igt_require(). To be more precise you would need to
a flag to tell when the wicked witch is dead and you could expect the
execbuf to fail with any cliprect garbage.
-Chris
> -Da 

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Avoid GPU stalls from kswapd

[Daniel Vetter]

On Thu, Oct 01, 2015 at 12:18:29PM +0100, Chris Wilson wrote:
> Exclude active GPU pages from the purview of the background shrinker
> (kswapd), as these cause uncontrollable GPU stalls. Given that the
> shrinker is rerun until the freelists are satisfied, we should have
> opportunity in subsequent passes to recover the pages once idle. If the
> machine does run out of memory entirely, we have the forced idling in the
> oom-notifier as a means of releasing all the pages we can before an oom
> is prematurely executed.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Damien Lespiau 

lgtm, but imo we should move the retire_requests from an earlier patch to
this one.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 1 +
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 9 +++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 64b8929acdf2..a443310a3598 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3159,6 +3159,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private 
> *dev_priv,
>  #define I915_SHRINK_PURGEABLE 0x1
>  #define I915_SHRINK_UNBOUND 0x2
>  #define I915_SHRINK_BOUND 0x4
> +#define I915_SHRINK_ACTIVE 0x8
>  unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
>  void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 2058d162aeb9..b2ccb7346899 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -126,6 +126,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>   obj->madv != I915_MADV_DONTNEED)
>   continue;
>  
> + if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
> + continue;
> +
>   drm_gem_object_reference(>base);
>  
>   /* For the unbound phase, this should be a no-op! */
> @@ -164,7 +167,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>  unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv)
>  {
>   return i915_gem_shrink(dev_priv, -1UL,
> -I915_SHRINK_BOUND | I915_SHRINK_UNBOUND);
> +I915_SHRINK_BOUND |
> +I915_SHRINK_UNBOUND |
> +I915_SHRINK_ACTIVE);
>  }
>  
>  static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
> @@ -217,7 +222,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct 
> shrink_control *sc)
>   count += obj->base.size >> PAGE_SHIFT;
>  
>   list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
> - if (obj->pages_pin_count == num_vma_bound(obj))
> + if (!obj->active && obj->pages_pin_count == num_vma_bound(obj))
>   count += obj->base.size >> PAGE_SHIFT;
>   }
>  
> -- 
> 2.6.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: During shrink_all we only need to idle the GPU

[Chris Wilson]

On Tue, Oct 06, 2015 at 03:00:49PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:18:27PM +0100, Chris Wilson wrote:
> > We can forgo an evict-everything here as the shrinker operation itself
> > will unbind any vma as required. If we explicitly idle the GPU through a
> > switch to the default context, we not only create a request in an
> > illegal context (e.g. whilst shrinking during execbuf with a request
> > already allocated), but switching to the default context will not free
> > up the memory backing the active contexts - unless in the unlikely
> > situation that context had already been closed (and just kept arrive by
> > being the current context). The saving is near zero and the danger real.
> > 
> > To compensate for the loss of the forced retire, add a couple of
> > retire-requests to i915_gem_shirnk() - this should help free up any
> > transitive cache from the requests.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index 88f66a2586ec..2058d162aeb9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -86,6 +86,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
> > unsigned long count = 0;
> >  
> > trace_i915_gem_shrink(dev_priv, target, flags);
> > +   i915_gem_retire_requests(dev_priv->dev);
> >  
> > /*
> >  * As we may completely rewrite the (un)bound list whilst unbinding
> > @@ -141,6 +142,8 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
> > list_splice(_in_list, phase->list);
> > }
> >  
> > +   i915_gem_retire_requests(dev_priv->dev);
> 
> I dont really get the justification for the 2nd retire_requests. Also
> isn't the first one only needed for the last patch to not stall in the
> normal shrinker on active objects?

No. The first one is just a convenience (putting it first just means we
may get more inactive objects during an inactive only shrink, through they
will be at the end and so more likely not to be included by the shrinker's
scan-count).

We need a i915_gem_retire_requests() over and above the usual retirement
because execlists is snafu. The second one is to handle a transient
cache of requests which you haven't seen yet, but execlists needs it
anyway in order to unpin itself (since it is not tied into retirement).
 
> Aside for blowing up on requests and nested stuff: We could make
> alloc_request/request_submit/cancel a lockdep locking pair. That would
> catch bogus nesting and locking inversion through the mm subsystem (since
> any malloc function is it's own lockdep critical section to avoid
> deadlocks on GFP_NOFS and friends).

Interesting. That sounds like a clean way to catch reentrancy, something
to think about.

> Also splitting out evict_everything into that one-line patch might be good
> for -fixes if we have bug reports where this blows up.

Corner-case performance issue on top of memory pressure. It's so old no
one will have noticed a regression, and it's already on a slow path that
unless you were analysing traces you probably wouldn't even notice the
degradation.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

[Daniel, Thomas]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, October 6, 2015 11:53 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson; Daniel, Thomas
> Subject: [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer
> 
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own object
> locations (for example along with full-ppgtt) and that the kernel will
> rarely have to make space for the user's requests.
> 
> v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary
> and fixed objects within the same batch
> 
> Signed-off-by: Chris Wilson 
> Cc: "Daniel, Thomas" 

This didn't apply cleanly to my tree pulled today (after patches 1 and 2 of 
this series).
Are you going to post a rebase?

Cheers,
Thomas.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Kill DRI1 cliprects

[Daniel Vetter]

On Tue, Oct 06, 2015 at 11:39:55AM +0100, Chris Wilson wrote:
> Passing cliprects into the kernel for it to re-execute the batch buffer
> with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> removed from the kernel, we can now simply reject any execbuf trying to
> use this "feature".
> 
> To keep Daniel happy with the prospect of being able to reuse these
> fields in the next decade, continue to ensure that current userspace is
> not passing garbage in through the dead fields.
> 
> v2: Fix the cliprects_ptr check
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

igt subtest seems to be missing to ensure we enforce this. Yay otherwise!
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 154 
> ++---
>  drivers/gpu/drm/i915/intel_lrc.c   |  15 ---
>  2 files changed, 31 insertions(+), 138 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 75a0c8b5305b..045a7631faa0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -947,7 +947,21 @@ i915_gem_check_execbuffer(struct 
> drm_i915_gem_execbuffer2 *exec)
>   if (exec->flags & __I915_EXEC_UNKNOWN_FLAGS)
>   return false;
>  
> - return ((exec->batch_start_offset | exec->batch_len) & 0x7) == 0;
> + /* Kernel clipping was a DRI1 misfeature */
> + if (exec->num_cliprects || exec->cliprects_ptr)
> + return false;
> +
> + if (exec->DR4 == 0x) {
> + DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> + exec->DR4 = 0;
> + }
> + if (exec->DR1 || exec->DR4)
> + return false;
> +
> + if ((exec->batch_start_offset | exec->batch_len) & 0x7)
> + return false;
> +
> + return true;
>  }
>  
>  static int
> @@ -,47 +1125,6 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
>   return 0;
>  }
>  
> -static int
> -i915_emit_box(struct drm_i915_gem_request *req,
> -   struct drm_clip_rect *box,
> -   int DR1, int DR4)
> -{
> - struct intel_engine_cs *ring = req->ring;
> - int ret;
> -
> - if (box->y2 <= box->y1 || box->x2 <= box->x1 ||
> - box->y2 <= 0 || box->x2 <= 0) {
> - DRM_ERROR("Bad box %d,%d..%d,%d\n",
> -   box->x1, box->y1, box->x2, box->y2);
> - return -EINVAL;
> - }
> -
> - if (INTEL_INFO(ring->dev)->gen >= 4) {
> - ret = intel_ring_begin(req, 4);
> - if (ret)
> - return ret;
> -
> - intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO_I965);
> - intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
> - intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
> << 16);
> - intel_ring_emit(ring, DR4);
> - } else {
> - ret = intel_ring_begin(req, 6);
> - if (ret)
> - return ret;
> -
> - intel_ring_emit(ring, GFX_OP_DRAWRECT_INFO);
> - intel_ring_emit(ring, DR1);
> - intel_ring_emit(ring, (box->x1 & 0x) | box->y1 << 16);
> - intel_ring_emit(ring, ((box->x2 - 1) & 0x) | (box->y2 - 1) 
> << 16);
> - intel_ring_emit(ring, DR4);
> - intel_ring_emit(ring, 0);
> - }
> - intel_ring_advance(ring);
> -
> - return 0;
> -}
> -
>  static struct drm_i915_gem_object*
>  i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
> struct drm_i915_gem_exec_object2 *shadow_exec_entry,
> @@ -1210,65 +1183,21 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>  struct drm_i915_gem_execbuffer2 *args,
>  struct list_head *vmas)
>  {
> - struct drm_clip_rect *cliprects = NULL;
>   struct drm_device *dev = params->dev;
>   struct intel_engine_cs *ring = params->ring;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   u64 exec_start, exec_len;
>   int instp_mode;
>   u32 instp_mask;
> - int i, ret = 0;
> -
> - if (args->num_cliprects != 0) {
> - if (ring != _priv->ring[RCS]) {
> - DRM_DEBUG("clip rectangles are only valid with the 
> render ring\n");
> - return -EINVAL;
> - }
> -
> - if (INTEL_INFO(dev)->gen >= 5) {
> - DRM_DEBUG("clip rectangles are only valid on 
> pre-gen5\n");
> - return -EINVAL;
> - }
> -
> - if (args->num_cliprects > UINT_MAX / sizeof(*cliprects)) {
> - DRM_DEBUG("execbuf with %u cliprects\n",
> -   args->num_cliprects);
> - return -EINVAL;
> - }
> -
> - cliprects = kcalloc(args->num_cliprects,
> 

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

[Dave Gordon]

On 06/10/15 09:38, Daniel Vetter wrote:

On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:

On 10/5/2015 5:36 PM, Dave Gordon wrote:

On 02/10/15 14:16, Michel Thierry wrote:

We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
range pt in gen6_for_each_pde").

But the static analyzer still complains that, just before we break due
to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an
iter value that is bigger than I915_PDES. Of course, this isn't really
a problem since no one uses pt outside the macro. Still, every single
new usage of the macro will create a new issue for us to mark as a
false positive.

Also, Paulo re-started the discussion a while ago [1], but didn't end up
implemented.

In order to "solve" this "problem", this patch takes the ideas from
Chris and Dave, but that check would change the desired behavior of the
code, because the object (for example pdp->page_directory[iter]) can be
null during init/alloc, and C would take this as false, breaking the for
loop immediately.

This has been already verified with "static analysis tools".

[1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html

v2: Make it a single statement, while preventing the common subexpression
elimination (Chris)

Cc: Paulo Zanoni 
Cc: Chris Wilson 
Cc: Dave Gordon 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gem_gtt.h | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 9fbb07d..a216397 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -394,7 +394,8 @@ struct i915_hw_ppgtt {
   */
  #define gen6_for_each_pde(pt, pd, start, length, temp, iter) \
  for (iter = gen6_pde_index(start); \
- pt = (pd)->page_table[iter], length > 0 && iter < I915_PDES; \
+ length > 0 && iter < I915_PDES ? \
+(pt = (pd)->page_table[iter]), 1 : 0; \
   iter++, \
   temp = ALIGN(start+1, 1 << GEN6_PDE_SHIFT) - start, \
   temp = min_t(unsigned, temp, length), \
@@ -459,7 +460,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)
   */
  #define gen8_for_each_pde(pt, pd, start, length, temp, iter)\
  for (iter = gen8_pde_index(start); \
- pt = (pd)->page_table[iter], length > 0 && iter <
I915_PDES;\
+ length > 0 && iter < I915_PDES ? \
+(pt = (pd)->page_table[iter]), 1 : 0; \
   iter++,\
   temp = ALIGN(start+1, 1 << GEN8_PDE_SHIFT) - start,\
   temp = min(temp, length),\
@@ -467,8 +469,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)

  #define gen8_for_each_pdpe(pd, pdp, start, length, temp, iter)\
  for (iter = gen8_pdpe_index(start); \
- pd = (pdp)->page_directory[iter], \
- length > 0 && (iter < I915_PDPES_PER_PDP(dev)); \
+ length > 0 && (iter < I915_PDPES_PER_PDP(dev)) ? \
+(pd = (pdp)->page_directory[iter]), 1 : 0; \
   iter++,\
   temp = ALIGN(start+1, 1 << GEN8_PDPE_SHIFT) - start,\
   temp = min(temp, length),\
@@ -476,8 +478,8 @@ static inline uint32_t gen6_pde_index(uint32_t addr)

  #define gen8_for_each_pml4e(pdp, pml4, start, length, temp, iter)\
  for (iter = gen8_pml4e_index(start);\
- pdp = (pml4)->pdps[iter], \
- length > 0 && iter < GEN8_PML4ES_PER_PML4; \
+ length > 0 && iter < GEN8_PML4ES_PER_PML4 ? \
+(pdp = (pml4)->pdps[iter]), 1 : 0; \


this won't compile -- see below


Hmm, it compiled (also got rid of of the "analysis tool error" and didn't
see any behavior change).




   iter++,\
   temp = ALIGN(start+1, 1ULL << GEN8_PML4E_SHIFT) - start,\
   temp = min(temp, length),\


The man page for C operators tells us:

Operator Associativity
() [] -> .   left to right
! ~ ++ -- + - (type) * & sizeof  right to left
* / %left to right
+ -  left to right
<< >>left to right
< <= > >=left to right
== !=left to right
&left to right
^left to right
|left to right
&&   left to right
||   left to right
?:   right to left
= += -= *= /= %= <<= >>= &= ^= |=right to left
,

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Daniel Vetter]

On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 04:11 PM, Imre Deak wrote:
> >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> >>On 10/05/2015 09:05 PM, Imre Deak wrote:
> >>>On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> Mostly reuse what is programmed by pre-os, but in case there is no
> pre-os initialization, init the cdclk with the default value.
> 
> Cc: Imre Deak 
> Signed-off-by: Shobhit Kumar 
> ---
>    drivers/gpu/drm/i915/intel_ddi.c | 6 ++
>    1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2d3cc82..675c60d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> 
>   cdclk_freq = 
>  dev_priv->display.get_display_clock_speed(dev);
>   dev_priv->skl_boot_cdclk = cdclk_freq;
> - if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> - DRM_ERROR("LCPLL1 is disabled\n");
> - else
> - intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> +
> + skl_init_cdclk(dev_priv);
> >>>
> >>>How does this prevent changing the clock if BIOS did enable some output?
> >>>We shouldn't change the clock in that case.
> >>
> >>In that case it will try to re-apply the same clock that BIOS enabled.
> >>Not sure if this is allowed, but I checked the cdclock change sequence
> >>and it is mostly followed in skl_init_cdclk.
> >>In my tests where BIOS does enable this, I faced no issues in
> >>initializing again in driver.
> >
> >The first step in that sequence:
> >"Disable all display engine functions using the full mode set disable
> >sequence on all pipes, ports, and planes."
> 
> Oh, yeah, I again made mistake of assuming that display is not enabled in
> the first place. You are right, though it works if I change the clock again.
> 
> >
> >So the problem is not that the PLL itself may be enabled here (as BIOS
> >left it), but that some output is also enabled.
> 
> Yes.
> 
> >
> >>I have noticed on some pre-os this value is programmed correctly except
> >>for the decimal part. That causes AUX transactions to fail on SKl. That
> >>is what triggered this patch actually. So other way is to completely
> >>validate the value in get_display_clock_speed instead of bit[28:26] and
> >>then if wrong then only do the cdclk init.
> >
> >I think we'd need to detect at this point if outputs are enabled and
> >only attempt to work around the above BIOS problem if this is not the
> >case. Alternatively you could also disable the active outputs as a first
> >step.
> 
> Ok, let me detect if any output is enabled by BIOS and accordingly
> initialize cdclk.

These kind of fixiups should be done after the hw state readout. We
already have sanitize_crtc/pll/encoder functions, probably best if we add
a sanitize_cdclk or similar for this at the very end of the hw state
sanitize sequence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Daniel Vetter]

On Tue, Oct 06, 2015 at 06:13:52PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 05:49 PM, Daniel Vetter wrote:
> >On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> >>On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> >>>On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 04:11 PM, Imre Deak wrote:
> >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> >>On 10/05/2015 09:05 PM, Imre Deak wrote:
> >>>On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> Mostly reuse what is programmed by pre-os, but in case there is no
> pre-os initialization, init the cdclk with the default value.
> 
> Cc: Imre Deak 
> Signed-off-by: Shobhit Kumar 
> ---
>    drivers/gpu/drm/i915/intel_ddi.c | 6 ++
>    1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2d3cc82..675c60d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> 
>   cdclk_freq = 
>  dev_priv->display.get_display_clock_speed(dev);
>   dev_priv->skl_boot_cdclk = cdclk_freq;
> - if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> - DRM_ERROR("LCPLL1 is disabled\n");
> - else
> - intel_display_power_get(dev_priv, 
> POWER_DOMAIN_PLLS);
> +
> + skl_init_cdclk(dev_priv);
> >>>
> >>>How does this prevent changing the clock if BIOS did enable some 
> >>>output?
> >>>We shouldn't change the clock in that case.
> >>
> >>In that case it will try to re-apply the same clock that BIOS enabled.
> >>Not sure if this is allowed, but I checked the cdclock change sequence
> >>and it is mostly followed in skl_init_cdclk.
> >>In my tests where BIOS does enable this, I faced no issues in
> >>initializing again in driver.
> >
> >The first step in that sequence:
> >"Disable all display engine functions using the full mode set disable
> >sequence on all pipes, ports, and planes."
> 
> Oh, yeah, I again made mistake of assuming that display is not enabled in
> the first place. You are right, though it works if I change the clock 
> again.
> 
> >
> >So the problem is not that the PLL itself may be enabled here (as BIOS
> >left it), but that some output is also enabled.
> 
> Yes.
> 
> >
> >>I have noticed on some pre-os this value is programmed correctly except
> >>for the decimal part. That causes AUX transactions to fail on SKl. That
> >>is what triggered this patch actually. So other way is to completely
> >>validate the value in get_display_clock_speed instead of bit[28:26] and
> >>then if wrong then only do the cdclk init.
> >
> >I think we'd need to detect at this point if outputs are enabled and
> >only attempt to work around the above BIOS problem if this is not the
> >case. Alternatively you could also disable the active outputs as a first
> >step.
> 
> Ok, let me detect if any output is enabled by BIOS and accordingly
> initialize cdclk.
> >>>
> >>>These kind of fixiups should be done after the hw state readout. We
> >>>already have sanitize_crtc/pll/encoder functions, probably best if we add
> >>>a sanitize_cdclk or similar for this at the very end of the hw state
> >>>sanitize sequence.
> >>
> >>Can't be done if we already need a somewhat sane cdclk for the
> >>eDP AUX probing and whatnot.
> >>
> >>For actually enabling the cdclk for pushing pixels, we wouldn't need
> >>to do anything except actually plug ia a calc_cdclk for SKL. No idea
> >>why we're not doing that currently. Some extra care may be needed
> >>due to the eDP DPLL0 usag IIRC.
> >
> >Hm right, cdlck is in the top-level power domain. Added fun is that with
> >dmc the firmware is supposed to handle it. Messy :(
> 
> Yes, exactly. How about just adding verify_cdclk and calling in
> get_display_clock_speed to check if cdclk is programmed correctly along with
> related DPLL0 VCO settings for now. If all looks good, then skip else
> initialize. Now in that case if we have to initialize where do we get the
> cdclock to initialize with at this point ? Any default in VBT ? Or go with
> minimum by default and it can be bumped up later if needed.

Just initialize to the slowest possible value, once we have dynamic cdclk
switching for skl. But that seems to be stuck behind resolving that big
confusion around dmc and the sequence for runtime pm. Without dynamic
cdclk we have to pick the maximum.
-Daniel
-- 
Daniel Vetter
Software Engineer, 

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc for i915_gem_shrink_all

[Jani Nikula]

On Tue, 06 Oct 2015, Daniel Vetter  wrote:
> I've botched this, so let's fix it.

Ahah, where's the reference to regressing commit, huh?! HUH?! ;)

Botched in

commit eb0b44adc08c0be01a027eb009e9cdadc31e65a2
Author: Daniel Vetter 
Date:   Wed Mar 18 14:47:59 2015 +0100

drm/i915: kerneldoc for i915_gem_shrinker.c


Reviewed-by: Jani Nikula 

>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index f6ecbda2c604..674341708033 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -143,7 +143,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * i915_gem_shrink - Shrink buffer object caches completely
> + * i915_gem_shrink_all - Shrink buffer object caches completely
>   * @dev_priv: i915 device
>   *
>   * This is a simple wraper around i915_gem_shrink() to aggressively shrink 
> all
> -- 
> 2.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[Chris Wilson]

On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > we occasionally and in the future often want to find a drm_mm_node by an
> > address. To do so efficiently we need to track the nodes in an interval
> > tree - lookups for a particular address will then be O(lg(N)), where N
> > is the number of nodes in the range manager as opposed to O(N).
> > Insertion however gains an extra O(lg(N)) step for all nodes
> > irrespective of whether the interval tree is in use. For future i915
> > patches, eliminating the linear walk is a significant improvement.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: dri-de...@lists.freedesktop.org
> 
> For the vma manager David Herrman put the interval tree outside of drm_mm.
> Whichever way we pick, but I think we should be consistent about this.

Given that the basis of this patch is that functionality exposed by
drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e.
there is a measurable perf degradation if we switch over from the mru
stack to using fixed addresses) it makes sense to improve that
functionality. The question is then why the drm_vma_manager didn't use
and improve the existing functionality...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Stop discarding GTT cache-domain on unbind vma

[Chris Wilson]

Since

commit 43566dedde54f9729113f5f9fde77d53e75e61e9
Author: Chris Wilson 
Date:   Fri Jan 2 16:29:29 2015 +0530

drm/i915: Broaden application of set-domain(GTT)

we allowed objects to be in the GTT domain, but unbound. Therefore
removing the GTT cache domain when removing the GGTT vma is no longer
semantically correct.

An unfortunate side-effect is we lose the wondrously named
i915_gem_object_finish_gtt(), not to be confused with
i915_gem_gtt_finish_object()!

Signed-off-by: Chris Wilson 
Cc: Akash Goel 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f498d4d874d..682af2ae3681 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3183,20 +3183,6 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
return 0;
 }
 
-static void i915_gem_object_finish_gtt(struct drm_i915_gem_object *obj)
-{
-   /* Force a pagefault for domain tracking on next user access */
-   i915_gem_release_mmap(obj);
-
-   if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
-   return;
-
-   obj->base.read_domains &= ~I915_GEM_DOMAIN_GTT;
-   obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
-
-   trace_i915_gem_object_change_domain(obj);
-}
-
 int i915_vma_unbind(struct i915_vma *vma)
 {
struct drm_i915_gem_object *obj = vma->obj;
@@ -3228,12 +3214,12 @@ int i915_vma_unbind(struct i915_vma *vma)
 */
 
if (vma->is_ggtt && vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
-   i915_gem_object_finish_gtt(obj);
-
-   /* release the fence reg _after_ flushing */
ret = i915_gem_object_put_fence(obj);
if (ret)
return ret;
+
+   /* Force a pagefault for domain tracking on next user access */
+   i915_gem_release_mmap(obj);
}
 
if (!vma->vm->closed) {
-- 
2.6.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Init cdclk in the driver rather than relying on pre-os

[Daniel Vetter]

On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> > > On 10/06/2015 04:11 PM, Imre Deak wrote:
> > > >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> > > >>On 10/05/2015 09:05 PM, Imre Deak wrote:
> > > >>>On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> > > Mostly reuse what is programmed by pre-os, but in case there is no
> > > pre-os initialization, init the cdclk with the default value.
> > > 
> > > Cc: Imre Deak 
> > > Signed-off-by: Shobhit Kumar 
> > > ---
> > >    drivers/gpu/drm/i915/intel_ddi.c | 6 ++
> > >    1 file changed, 2 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 2d3cc82..675c60d 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2947,10 +2947,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> > > 
> > >   cdclk_freq = 
> > >  dev_priv->display.get_display_clock_speed(dev);
> > >   dev_priv->skl_boot_cdclk = cdclk_freq;
> > > - if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> > > - DRM_ERROR("LCPLL1 is disabled\n");
> > > - else
> > > - intel_display_power_get(dev_priv, 
> > > POWER_DOMAIN_PLLS);
> > > +
> > > + skl_init_cdclk(dev_priv);
> > > >>>
> > > >>>How does this prevent changing the clock if BIOS did enable some 
> > > >>>output?
> > > >>>We shouldn't change the clock in that case.
> > > >>
> > > >>In that case it will try to re-apply the same clock that BIOS enabled.
> > > >>Not sure if this is allowed, but I checked the cdclock change sequence
> > > >>and it is mostly followed in skl_init_cdclk.
> > > >>In my tests where BIOS does enable this, I faced no issues in
> > > >>initializing again in driver.
> > > >
> > > >The first step in that sequence:
> > > >"Disable all display engine functions using the full mode set disable
> > > >sequence on all pipes, ports, and planes."
> > > 
> > > Oh, yeah, I again made mistake of assuming that display is not enabled in
> > > the first place. You are right, though it works if I change the clock 
> > > again.
> > > 
> > > >
> > > >So the problem is not that the PLL itself may be enabled here (as BIOS
> > > >left it), but that some output is also enabled.
> > > 
> > > Yes.
> > > 
> > > >
> > > >>I have noticed on some pre-os this value is programmed correctly except
> > > >>for the decimal part. That causes AUX transactions to fail on SKl. That
> > > >>is what triggered this patch actually. So other way is to completely
> > > >>validate the value in get_display_clock_speed instead of bit[28:26] and
> > > >>then if wrong then only do the cdclk init.
> > > >
> > > >I think we'd need to detect at this point if outputs are enabled and
> > > >only attempt to work around the above BIOS problem if this is not the
> > > >case. Alternatively you could also disable the active outputs as a first
> > > >step.
> > > 
> > > Ok, let me detect if any output is enabled by BIOS and accordingly
> > > initialize cdclk.
> > 
> > These kind of fixiups should be done after the hw state readout. We
> > already have sanitize_crtc/pll/encoder functions, probably best if we add
> > a sanitize_cdclk or similar for this at the very end of the hw state
> > sanitize sequence.
> 
> Can't be done if we already need a somewhat sane cdclk for the
> eDP AUX probing and whatnot.
> 
> For actually enabling the cdclk for pushing pixels, we wouldn't need
> to do anything except actually plug ia a calc_cdclk for SKL. No idea
> why we're not doing that currently. Some extra care may be needed
> due to the eDP DPLL0 usag IIRC.

Hm right, cdlck is in the top-level power domain. Added fun is that with
dmc the firmware is supposed to handle it. Messy :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing around GTT mappings

[Chris Wilson]

On Tue, Oct 06, 2015 at 02:12:31PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:36:05PM +0100, Chris Wilson wrote:
> > Once userptr becomes part of client API, it is almost a certainty that
> > eventually someone will try to create a new object from a mapping of
> > another client object, e.g.
> > 
> > new = vaImport(vaMap(old, ), size);
> > 
> > (using a hypothethical API, not meaning to pick on anyone!)
> > 
> > Since this is actually fairly safe to implement and to allow for a GTT
> > mapping (since it is within a single process space and the memory access
> > passes the standard permissions test) let us not limit the Client
> > possibilities.
> > 
> > v2: sfelling pixes
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Gwenole Beauchesne 
> > Cc: Michał Winiarski 
> > Cc: Tvrtko Ursulin 
> 
> This feels like a really big can of worms, since all the apis I've seen
> thus far have been rather explicit that you can only import malloc'ed
> memory.

Weirdly no one even brought it up as an issue for AMD_pinned_memory.
Nothing in the spec says you can't
glBufferData(GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD,
 ...,
 glMapBuffer(GL_PIXEL_UNPACK_BUFFER, ...));

Not that I would expect it to always work.

> Also tiling and stuff like this ...

Indeed, it is the only way to get tiling right... The only question is
whether every userptr mapping should be a unique bo (this also has the
effect of return a new handle for an existing userptr mapping to the
same exact address range). Note that the memory address is still
controlled by the earlier bo, so it will always remain linear, and with
the second handle the user still has to object all the normal userptr
restrictions.

As you probably guess Gwenole raise the question of whether this
behaviour would be possible to implement.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: shrinker_control->nr_to_scan is now unsigned long

[Daniel Vetter]

On Thu, Oct 01, 2015 at 12:18:25PM +0100, Chris Wilson wrote:
> As the shrinker_control now passes us unsigned long targets, update our
> shrinker functions to match.
> 
> Signed-off-by: Chris Wilson 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 +-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ec731e6db126..6c807c584d59 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3155,7 +3155,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
> drm_device *dev,
>  
>  /* i915_gem_shrinker.c */
>  unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
> -   long target,
> +   unsigned long target,
> unsigned flags);
>  #define I915_SHRINK_PURGEABLE 0x1
>  #define I915_SHRINK_UNBOUND 0x2
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index f6ecbda2c604..b627d07fad29 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -73,7 +73,7 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct 
> task_struct *task)
>   */
>  unsigned long
>  i915_gem_shrink(struct drm_i915_private *dev_priv,
> - long target, unsigned flags)
> + unsigned long target, unsigned flags)
>  {
>   const struct {
>   struct list_head *list;
> @@ -159,7 +159,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>  unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv)
>  {
>   i915_gem_evict_everything(dev_priv->dev);
> - return i915_gem_shrink(dev_priv, LONG_MAX,
> + return i915_gem_shrink(dev_priv, -1UL,
>  I915_SHRINK_BOUND | I915_SHRINK_UNBOUND);
>  }
>  
> -- 
> 2.6.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Stop discarding GTT cache-domain on unbind vma

[Daniel Vetter]

On Tue, Oct 06, 2015 at 01:46:25PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 02:40:26PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 01:02:22PM +0100, Chris Wilson wrote:
> > > Since
> > > 
> > > commit 43566dedde54f9729113f5f9fde77d53e75e61e9
> > > Author: Chris Wilson 
> > > Date:   Fri Jan 2 16:29:29 2015 +0530
> > > 
> > > drm/i915: Broaden application of set-domain(GTT)
> > > 
> > > we allowed objects to be in the GTT domain, but unbound. Therefore
> > > removing the GTT cache domain when removing the GGTT vma is no longer
> > > semantically correct.
> > > 
> > > An unfortunate side-effect is we lose the wondrously named
> > > i915_gem_object_finish_gtt(), not to be confused with
> > > i915_gem_gtt_finish_object()!
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Akash Goel 
> > > Cc: Joonas Lahtinen 
> > > Cc: Tvrtko Ursulin 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c | 20 +++-
> > >  1 file changed, 3 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 8f498d4d874d..682af2ae3681 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3183,20 +3183,6 @@ i915_gem_object_sync(struct drm_i915_gem_object 
> > > *obj,
> > >   return 0;
> > >  }
> > >  
> > > -static void i915_gem_object_finish_gtt(struct drm_i915_gem_object *obj)
> > > -{
> > > - /* Force a pagefault for domain tracking on next user access */
> > > - i915_gem_release_mmap(obj);
> > > -
> > > - if ((obj->base.read_domains & I915_GEM_DOMAIN_GTT) == 0)
> > > - return;
> > > -
> > > - obj->base.read_domains &= ~I915_GEM_DOMAIN_GTT;
> > > - obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
> > > -
> > > - trace_i915_gem_object_change_domain(obj);
> > > -}
> > > -
> > >  int i915_vma_unbind(struct i915_vma *vma)
> > >  {
> > >   struct drm_i915_gem_object *obj = vma->obj;
> > > @@ -3228,12 +3214,12 @@ int i915_vma_unbind(struct i915_vma *vma)
> > >*/
> > >  
> > >   if (vma->is_ggtt && vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
> > > - i915_gem_object_finish_gtt(obj);
> > > -
> > > - /* release the fence reg _after_ flushing */
> > >   ret = i915_gem_object_put_fence(obj);
> > >   if (ret)
> > >   return ret;
> > > +
> > > + /* Force a pagefault for domain tracking on next user access */
> > > + i915_gem_release_mmap(obj);
> > 
> > Can't put_fence before release_mmap ... I guess we should have a testcase
> > for this somewhere? Hard to provoke probably ...
> 
> Why not? i915_gem_object_put_fence() has to release the mmaps itself if
> it has a fence register assigned for the object.

Oh right, forgotten that put_fence is robust. Looking at this simply
brought up bad memories since I fixed this kind of bug 5 years ago once
;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] kms_rotation_crc: Excercise page flips with 90 degree rotation

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Do some page flipping on the rotated plane just to excercise
that code path.

Signed-off-by: Tvrtko Ursulin 
Cc: Sonika Jindal 
Cc: Arun R Murthy 
---
There are some, still unofficial, reports that page flipping with
90 degree rotation may be causing a vma->pin_count leak.

But more importantly it looks like it doesn't work at all at the
moment with frame buffers which do not cover the whole plane.
---
 tests/kms_rotation_crc.c | 56 
 1 file changed, 56 insertions(+)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index cc9847ecc113..fde910250353 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -31,6 +31,7 @@ typedef struct {
igt_display_t display;
struct igt_fb fb;
struct igt_fb fb_modeset;
+   struct igt_fb fb_flip;
igt_crc_t ref_crc;
igt_pipe_crc_t *pipe_crc;
igt_rotation_t rotation;
@@ -39,6 +40,7 @@ typedef struct {
unsigned int w, h;
uint32_t override_fmt;
uint64_t override_tiling;
+   unsigned int flip_stress;
 } data_t;
 
 static void
@@ -165,6 +167,16 @@ static void prepare_crtc(data_t *data, igt_output_t 
*output, enum pipe pipe,
  >fb);
igt_assert(fb_id);
 
+   if (data->flip_stress) {
+   fb_id = igt_create_fb(data->gfx_fd,
+ w, h,
+ pixel_format,
+ tiling,
+ >fb_flip);
+   igt_assert(fb_id);
+   paint_squares(data, mode, data->rotation, plane);
+   }
+
/* Step 1: create a reference CRC for a software-rotated fb */
paint_squares(data, mode, data->rotation, plane);
commit_crtc(data, output, plane);
@@ -187,6 +199,8 @@ static void cleanup_crtc(data_t *data, igt_output_t 
*output, igt_plane_t *plane)
 
igt_remove_fb(data->gfx_fd, >fb);
igt_remove_fb(data->gfx_fd, >fb_modeset);
+   if (data->fb_flip.fb_id)
+   igt_remove_fb(data->gfx_fd, >fb_flip);
 
/* XXX: see the note in prepare_crtc() */
if (!plane->is_primary) {
@@ -202,6 +216,23 @@ static void cleanup_crtc(data_t *data, igt_output_t 
*output, igt_plane_t *plane)
igt_display_commit(display);
 }
 
+static void wait_for_pageflip(int fd)
+{
+   drmEventContext evctx = { .version = DRM_EVENT_CONTEXT_VERSION };
+   struct timeval timeout = { .tv_sec = 0, .tv_usec = 32000 };
+   fd_set fds;
+   int ret;
+
+   /* Wait for pageflip completion, then consume event on fd */
+   FD_ZERO();
+   FD_SET(fd, );
+   do {
+   ret = select(fd + 1, , NULL, NULL, );
+   } while (ret < 0 && errno == EINTR);
+   igt_assert_eq(ret, 1);
+   igt_assert(drmHandleEvent(fd, ) == 0);
+}
+
 static void test_plane_rotation(data_t *data, enum igt_plane plane_type)
 {
igt_display_t *display = >display;
@@ -245,6 +276,23 @@ static void test_plane_rotation(data_t *data, enum 
igt_plane plane_type)
 _output);
}
 
+   while (data->flip_stress--) {
+   ret = drmModePageFlip(data->gfx_fd,
+ 
output->config.crtc->crtc_id,
+ data->fb_flip.fb_id,
+ DRM_MODE_PAGE_FLIP_EVENT,
+ NULL);
+   igt_assert(ret == 0);
+   wait_for_pageflip(data->gfx_fd);
+   ret = drmModePageFlip(data->gfx_fd,
+ 
output->config.crtc->crtc_id,
+ data->fb.fb_id,
+ DRM_MODE_PAGE_FLIP_EVENT,
+ NULL);
+   igt_assert(ret == 0);
+   wait_for_pageflip(data->gfx_fd);
+   }
+
/*
 * check the rotation state has been reset when the VT
 * mode is restored
@@ -345,6 +393,14 @@ igt_main
test_plane_rotation(, IGT_PLANE_PRIMARY);
}
 
+   igt_subtest_f("primary-rotation-90-flip-stress") {
+   igt_require(gen >= 9);
+   data.override_tiling = 0;
+   data.flip_stress = 120;
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation(, IGT_PLANE_PRIMARY);
+   }
+
igt_fixture {
igt_display_fini();
}
-- 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level

[Daniel Vetter]

On Tue, Oct 06, 2015 at 11:39:56AM +0100, Chris Wilson wrote:
> Since the remove of the pin-ioctl, we only care about not changing the
> cache level on buffers pinned to the hardware as indicated by
> obj->pin_display. So we can safely replace i915_gem_object_is_pinned()
> here with a plain obj->pin_display check. During rebinding, we will check
> sanity checks in case vma->pin_count is erroneously set.
> 
> At the same time, we can micro-optimise GTT mmap() behaviour since we
> only need to relinquish the mmaps before Sandybridge.

Actual condition is !LLC so would need to be updated (and split out imo).
 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 40 
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d4a3bdf0c5b6..2b8ed7a2faab 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3629,31 +3629,34 @@ int i915_gem_object_set_cache_level(struct 
> drm_i915_gem_object *obj,
>  {
>   struct drm_device *dev = obj->base.dev;
>   struct i915_vma *vma, *next;
> + bool bound = false;
>   int ret = 0;
>  
>   if (obj->cache_level == cache_level)
>   goto out;
>  
> - if (i915_gem_obj_is_pinned(obj)) {
> - DRM_DEBUG("can not change the cache level of pinned objects\n");
> - return -EBUSY;
> - }
> -
>   list_for_each_entry_safe(vma, next, >vma_list, vma_link) {
> + if (!drm_mm_node_allocated(>node))
> + continue;
> +
> + if (vma->pin_count) {
> + DRM_DEBUG("can not change the cache level of pinned 
> objects\n");
> + return -EBUSY;
> + }
> +
>   if (!i915_gem_valid_gtt_space(vma, cache_level)) {
>   ret = i915_vma_unbind(vma);
>   if (ret)
>   return ret;
> - }
> + } else
> + bound = true;
>   }
>  
> - if (i915_gem_obj_bound_any(obj)) {
> + if (bound) {
>   ret = i915_gem_object_wait_rendering(obj, false);
>   if (ret)
>   return ret;

Shouldn't the below be split out into a separate patch? And maybe for
paranoia keep calling finish_gtt but restrict it to !LLC && snooped like
you do below.
-Daniel

>  
> - i915_gem_object_finish_gtt(obj);
> -
>   /* Before SandyBridge, you could not use tiling or fence
>* registers with snooped memory, so relinquish any fences
>* currently pointing to our region in the aperture.
> @@ -3664,13 +3667,18 @@ int i915_gem_object_set_cache_level(struct 
> drm_i915_gem_object *obj,
>   return ret;
>   }
>  
> - list_for_each_entry(vma, >vma_list, vma_link)
> - if (drm_mm_node_allocated(>node)) {
> - ret = i915_vma_bind(vma, cache_level,
> - PIN_UPDATE);
> - if (ret)
> - return ret;
> - }
> + /* Access to snoopable pages through the GTT is incoherent. */
> + if (cache_level != I915_CACHE_NONE && !HAS_LLC(dev))
> + i915_gem_release_mmap(obj);
> +
> + list_for_each_entry(vma, >vma_list, vma_link) {
> + if (!drm_mm_node_allocated(>node))
> + continue;
> +
> + ret = i915_vma_bind(vma, cache_level, PIN_UPDATE);
> + if (ret)
> + return ret;
> + }
>   }
>  
>   list_for_each_entry(vma, >vma_list, vma_link)
> -- 
> 2.6.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

[Daniel Vetter]

On Tue, Oct 06, 2015 at 12:19:43PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > > we occasionally and in the future often want to find a drm_mm_node by an
> > > address. To do so efficiently we need to track the nodes in an interval
> > > tree - lookups for a particular address will then be O(lg(N)), where N
> > > is the number of nodes in the range manager as opposed to O(N).
> > > Insertion however gains an extra O(lg(N)) step for all nodes
> > > irrespective of whether the interval tree is in use. For future i915
> > > patches, eliminating the linear walk is a significant improvement.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: dri-de...@lists.freedesktop.org
> > 
> > For the vma manager David Herrman put the interval tree outside of drm_mm.
> > Whichever way we pick, but I think we should be consistent about this.
> 
> Given that the basis of this patch is that functionality exposed by
> drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e.
> there is a measurable perf degradation if we switch over from the mru
> stack to using fixed addresses) it makes sense to improve that
> functionality. The question is then why the drm_vma_manager didn't use
> and improve the existing functionality...

Yeah I'm trying to volunteer you to add a lookup-function and rework the
vma-manager ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing around GTT mappings

[Daniel Vetter]

On Thu, Oct 01, 2015 at 12:36:05PM +0100, Chris Wilson wrote:
> Once userptr becomes part of client API, it is almost a certainty that
> eventually someone will try to create a new object from a mapping of
> another client object, e.g.
> 
> new = vaImport(vaMap(old, ), size);
> 
> (using a hypothethical API, not meaning to pick on anyone!)
> 
> Since this is actually fairly safe to implement and to allow for a GTT
> mapping (since it is within a single process space and the memory access
> passes the standard permissions test) let us not limit the Client
> possibilities.
> 
> v2: sfelling pixes
> 
> Signed-off-by: Chris Wilson 
> Cc: Gwenole Beauchesne 
> Cc: Michał Winiarski 
> Cc: Tvrtko Ursulin 

This feels like a really big can of worms, since all the apis I've seen
thus far have been rather explicit that you can only import malloc'ed
memory. Also tiling and stuff like this ...
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c | 48 
> ++---
>  1 file changed, 45 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 1b3b451b6658..afd4c2c4cc04 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -795,6 +795,37 @@ static const struct drm_i915_gem_object_ops 
> i915_gem_userptr_ops = {
>   .release = i915_gem_userptr_release,
>  };
>  
> +static struct drm_i915_gem_object *
> +find_object_from_vma(struct drm_device *dev,
> +  struct drm_i915_gem_userptr *args)
> +{
> + struct drm_i915_gem_object *obj = NULL;
> + struct vm_area_struct *vma;
> +
> + down_read(>mm->mmap_sem);
> + vma = find_vma(current->mm, args->user_ptr);
> + if (vma == NULL) {
> + obj = ERR_PTR(-EFAULT);
> + goto out;
> + }
> +
> + if (vma->vm_ops != dev->driver->gem_vm_ops)
> + goto out;
> +
> + if (vma->vm_start != args->user_ptr ||
> + vma->vm_end != args->user_ptr + args->user_size) {
> + obj = ERR_PTR(-EINVAL);
> + goto out;
> + }
> +
> + obj = to_intel_bo(vma->vm_private_data);
> + drm_gem_object_reference(>base);
> +
> +out:
> + up_read(>mm->mmap_sem);
> + return obj;
> +}
> +
>  /**
>   * Creates a new mm object that wraps some normal memory from the process
>   * context - user memory.
> @@ -802,8 +833,11 @@ static const struct drm_i915_gem_object_ops 
> i915_gem_userptr_ops = {
>   * We impose several restrictions upon the memory being mapped
>   * into the GPU.
>   * 1. It must be page aligned (both start/end addresses, i.e ptr and size).
> - * 2. It must be normal system memory, not a pointer into another map of IO
> - *space (e.g. it must not be a GTT mmapping of another object).
> + * 2. It must either be:
> + *a) normal system memory, not a pointer into another map of IO
> + *   space (e.g. it must not be part of a GTT mmapping of another 
> object).
> + *b) a pointer to the complete GTT mmap of another object in your
> + *   address space.
>   * 3. We only allow a bo as large as we could in theory map into the GTT,
>   *that is we limit the size to the total size of the GTT.
>   * 4. The bo is marked as being snoopable. The backing pages are left
> @@ -853,6 +887,14 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *file
>   return -ENODEV;
>   }
>  
> + obj = find_object_from_vma(dev, args);
> + if (obj) {
> + if (!IS_ERR(obj))
> + goto out;
> +
> + return PTR_ERR(obj);
> + }
> +
>   obj = i915_gem_object_alloc(dev);
>   if (obj == NULL)
>   return -ENOMEM;
> @@ -874,7 +916,7 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *file
>   if (ret == 0)
>   ret = i915_gem_userptr_init__mmu_notifier(obj, args->flags);
>   if (ret == 0)
> - ret = drm_gem_handle_create(file, >base, );
> +out:  ret = drm_gem_handle_create(file, >base, );
>  
>   /* drop reference from allocate - handle holds it now */
>   drm_gem_object_unreference_unlocked(>base);
> -- 
> 2.6.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range

[Chris Wilson]

On Tue, Oct 06, 2015 at 02:04:19PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:34:47PM +0100, Chris Wilson wrote:
> > Whilst discussing possible ways to trigger an invalidate_range on a
> > userptr with an aliased GGTT mmapping (and so cause a struct_mutex
> > deadlock), the conclusion is that we can, and we must, prevent any
> > possible deadlock by avoiding taking the mutex at all during
> > invalidate_range. This has numerous advantages all of which stem from
> > avoid the sleeping function from inside the unknown context. In
> > particular, it simplifies the invalidate_range because we no longer
> > have to juggle the spinlock/mutex and can just hold the spinlock
> > for the entire walk. To compensate, we have to make get_pages a bit more
> > complicated in order to serialise with a pending cancel_userptr worker.
> > As we hold the struct_mutex, we have no choice but to return EAGAIN and
> > hope that the worker is then flushed before we retry after reacquiring
> > the struct_mutex.
> > 
> > The important caveat is that the invalidate_range itself is no longer
> > synchronous. There exists a small but definite period in time in which
> > the old PTE's page remain accessible via the GPU. Note however that the
> > physical pages themselves are not invalidated by the mmu_notifier, just
> > the CPU view of the address space. The impact should be limited to a
> > delay in pages being flushed, rather than a possibility of writing to
> > the wrong pages. The only race condition that this worsens is remapping
> > an userptr active on the GPU where fresh work may still reference the
> > old pages due to struct_mutex contention. Given that userspace is racing
> > with the GPU, it is fair to say that the results are undefined.
> > 
> > v2: Only queue (and importantly only take one refcnt) the worker once.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Michał Winiarski 
> > Cc: Tvrtko Ursulin 
> > Reviewed-by: Tvrtko Ursulin 
> 
> Pulled in all 3 patches. Btw some pretty kerneldoc explaining the
> high-level interactions would be neat for all the userptr stuff ... I'm
> totally lost in i915_gem_userptr.c ;-)

Probably because it already has too many verbose comments?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx