Re: [Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

2017-04-28 Thread Praveen Paneri
HI Paulo,



On Sat, Apr 29, 2017 at 12:51 AM, Paulo Zanoni  wrote:
> Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
>> This series adds Y-tiled buffer creation support into IGT libraries
>> and
>> goes on to use this capability to add support into FBC tests to use
>> Y-tiled buffers.
>
> The problem I reported before still happens to me. Please fix it before
> resending.
I tried reproducing it on SKL. For me the test was just running fine.

I ran it in shell mode on ubuntu running the latest kernel.

Could you plz give some hint to repro it at my end.
Thanks,
Praveen
>
>>
>> Akash Goel (1):
>>   lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method
>>
>> Paulo Zanoni (1):
>>   tests/kms_draw_crc: add support for Y tiling
>>
>> Praveen Paneri (5):
>>   lib/igt_fb: Let others use igt_get_fb_tile_size
>>   lib/igt_fb: Add helper function for tile_to_mod
>>   lib/igt_draw: Add Y-tiling support
>>   igt/kms_frontbuffer_tracking: Add Y-tiling support
>>   igt/kms_fbc_crc.c : Add Y-tile tests
>>
>>  lib/igt_draw.c   | 165 -
>> --
>>  lib/igt_fb.c |  41 +-
>>  lib/igt_fb.h |   4 +-
>>  tests/kms_draw_crc.c |  58 ++
>>  tests/kms_fbc_crc.c  |  71 +
>>  tests/kms_frontbuffer_tracking.c |  48 +++-
>>  6 files changed, 273 insertions(+), 114 deletions(-)
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: New vfunc prepare_request

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915: New vfunc prepare_request
URL   : https://patchwork.freedesktop.org/series/23727/
State : success

== Summary ==

Series 23727v1 drm/i915: New vfunc prepare_request
https://patchwork.freedesktop.org/api/1.0/series/23727/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:553s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:401s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:409s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:447s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:567s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:435s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:401s

1d490e4b6d5324cfbf8dc800cf4a99471252802c drm-tip: 2017y-04m-28d-14h-14m-47s UTC 
integration manifest
338839e drm/i915: New vfunc prepare_request

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4585/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: New vfunc prepare_request

2017-04-28 Thread Oscar Mateo
This will be more useful later to support platforms that need to emit
HW commands at the beginning of every request (more general than emitting
things at the beginning of every batchbuffer, which is already covered by
emit_bb_start).

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_lrc.c| 17 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9488578..a5c055a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -687,6 +687,15 @@ static bool insert_request(struct i915_priotree *pt, 
struct rb_root *root)
return first;
 }
 
+static int execlists_prepare_request(struct drm_i915_gem_request *request)
+{
+   u32 *cs = intel_ring_begin(request, 0);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   return 0;
+}
+
 static void execlists_submit_request(struct drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
@@ -879,7 +888,6 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
struct intel_context *ce = >ctx->engine[engine->id];
-   u32 *cs;
int ret;
 
GEM_BUG_ON(!ce->pin_count);
@@ -904,11 +912,9 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
goto err;
}
 
-   cs = intel_ring_begin(request, 0);
-   if (IS_ERR(cs)) {
-   ret = PTR_ERR(cs);
+   ret = engine->prepare_request(request);
+   if (ret)
goto err_unreserve;
-   }
 
if (!ce->initialised) {
ret = engine->init_context(request);
@@ -1650,6 +1656,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
 
 static void execlists_set_default_submission(struct intel_engine_cs *engine)
 {
+   engine->prepare_request = execlists_prepare_request;
engine->submit_request = execlists_submit_request;
engine->schedule = execlists_schedule;
engine->irq_tasklet.func = intel_lrc_irq_handler;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d901831..67de978 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -303,6 +303,7 @@ struct intel_engine_cs {
void(*emit_breadcrumb)(struct drm_i915_gem_request *req,
   u32 *cs);
int emit_breadcrumb_sz;
+   int (*prepare_request)(struct drm_i915_gem_request *req);
 
/* Pass the request to the hardware queue (e.g. directly into
 * the legacy ringbuffer or to the end of an execlist).
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH 12/67] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

2017-04-28 Thread Oscar Mateo



On 04/06/2017 07:15 PM, Rodrigo Vivi wrote:

Let's inherit workarounds from previous platforms that
according to wa_database and BSpec are still valid for
Cannonlake.

v2: Add missed workarounds.
v3: Rebase

Cc: Mika Kuoppala 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c|  4 ++--
  drivers/gpu/drm/i915/i915_reg.h|  6 +
  drivers/gpu/drm/i915/intel_engine_cs.c | 26 
  drivers/gpu/drm/i915/intel_lrc.c   |  1 +
  drivers/gpu/drm/i915/intel_pm.c| 44 +-
  5 files changed, 73 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8bab4ae..3c8457d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1881,12 +1881,12 @@ static void gtt_write_workarounds(struct 
drm_i915_private *dev_priv)
 * called on driver load and after a GPU reset, so you can place
 * workarounds here even if they get overwritten by GPU reset.
 */
-   /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk */
+   /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk,cnl */
if (IS_BROADWELL(dev_priv))
I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
else if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
-   else if (IS_GEN9_BC(dev_priv))
+   else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
else if (IS_GEN9_LP(dev_priv))
I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index efbbeb8..a09a0d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3424,6 +3424,12 @@ enum {
  #define   PWM1_GATING_DIS (1 << 13)
  
  /*

+ * GEN10 clock gating regs
+ */
+#define SLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x94d4)
+#define  SARBUNIT_CLKGATE_DIS  (1 << 5)
+
+/*
   * Display engine regs
   */
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index 854e8e0..da819a7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -946,6 +946,30 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
return 0;
  }
  
+static int cnl_init_workarounds(struct intel_engine_cs *engine)

+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   int ret;
+
+   /* WaInPlaceDecompressionHang:cnl */
+   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
+  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+
+   /* WaEnablePreemptionGranularityControlByUMD:cnl */
+   ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
+   if (ret)
+   return ret;
+
+   /* WaAllowUMDToModifyHDCChicken1:cnl (pre-prod) */
+   if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0)) {
+   ret = wa_ring_whitelist_reg(engine, GEN8_HDC_CHICKEN1);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
  static int kbl_init_workarounds(struct intel_engine_cs *engine)
  {
struct drm_i915_private *dev_priv = engine->i915;
@@ -1032,6 +1056,8 @@ int init_workarounds_ring(struct intel_engine_cs *engine)
err = kbl_init_workarounds(engine);
else if (IS_GEMINILAKE(dev_priv))
err =  glk_init_workarounds(engine);
+   else if (IS_CANNONLAKE(dev_priv))
+   err = cnl_init_workarounds(engine);
else
err = 0;
if (err)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..23e2bed 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1093,6 +1093,7 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
return -EINVAL;
  
  	switch (INTEL_GEN(engine->i915)) {

+   case 10:


Are you sure this is what you want? gen9_init_perctx_bb is just an empty 
batchbuffer, but gen9_init_indirectctx_bb introduces some WAs that do 
not apply to CNL (WaFlushCoherentL3CacheLinesAtContextSwitch, 
WaClearSlmSpaceAtContextSwitch, etc...)



case 9:
wa_bb_fn[0] = gen9_init_indirectctx_bb;
wa_bb_fn[1] = gen9_init_perctx_bb;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55e1e88..b6ecab9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -58,24 +58,24 @@
  
  static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)

  {
-   /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl */
+   /* See Bspec note for 

[Intel-gfx] ✓ Fi.CI.BAT: success for Adding driver-private objects to atomic state (rev3)

2017-04-28 Thread Patchwork
== Series Details ==

Series: Adding driver-private objects to atomic state (rev3)
URL   : https://patchwork.freedesktop.org/series/23308/
State : success

== Summary ==

Series 23308v3 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/3/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:546s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:401s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:411s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:406s

1d490e4b6d5324cfbf8dc800cf4a99471252802c drm-tip: 2017y-04m-28d-14h-14m-47s UTC 
integration manifest
3b1505e drm/dp: Track MST link bandwidth
3b20897 drm/dp: Add DP MST helpers to atomically find and release vcpi slots
ca3df31 drm/dp: Introduce MST topology state to track available link bandwidth
78f9371 drm: Add driver-private objects to atomic state

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4584/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v8 4/4] drm/dp: Track MST link bandwidth

2017-04-28 Thread Dhinakaran Pandiyan
From: "Pandiyan, Dhinakaran" 

Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots(). Similarly, link bw is released
during ->atomic_check() with the connector helper callback ->atomic_check()
when CRTCs are disabled.

v6: active_changed does not alter vcpi allocations (Maarten)
v5: Implement connector->atomic_check() in place of atomic_release()
v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
v3:
 Handled the case where ->atomic_release() is called more than once
 during an atomic_check() for the same state.
v2:
 Squashed atomic_release() implementation and caller (Daniel)
 Fixed logic for connector-crtc switching case (Daniel)
 Fixed logic for suspend-resume case.

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 48 -
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5af22a7..68c788e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -39,7 +39,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = _dig_port->dp;
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
-   struct drm_atomic_state *state;
+   struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
int lane_count, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
@@ -57,20 +57,24 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
 * seem to suggest we should do otherwise.
 */
lane_count = intel_dp_max_lane_count(intel_dp);
-
pipe_config->lane_count = lane_count;
 
pipe_config->pipe_bpp = bpp;
-   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
 
-   state = pipe_config->base.state;
+   pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
 
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
-   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
 
+   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
-   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
+
+   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
+ connector->port, mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+   return false;
+   }
 
intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
@@ -80,7 +84,38 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
pipe_config->dp_m_n.tu = slots;
 
return true;
+}
 
+static int intel_dp_mst_atomic_check(struct drm_connector *connector,
+   struct drm_connector_state *new_conn_state)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct drm_connector_state *old_conn_state;
+   struct drm_crtc *old_crtc;
+   struct drm_crtc_state *crtc_state;
+   int slots, ret = 0;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   old_crtc = old_conn_state->crtc;
+   if (!old_crtc)
+   return ret;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
+   slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
+   if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
+   struct drm_dp_mst_topology_mgr *mgr;
+   struct drm_encoder *old_encoder;
+
+   old_encoder = old_conn_state->best_encoder;
+   mgr = _to_mst(old_encoder)->primary->dp.mst_mgr;
+
+   ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
+   if (ret)
+   DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", 
slots, ret);
+   else
+   to_intel_crtc_state(crtc_state)->dp_m_n.tu = 0;
+   }
+   return ret;
 }
 
 static void intel_mst_disable_dp(struct intel_encoder *encoder,
@@ -378,6 +413,7 @@ static const struct drm_connector_helper_funcs 
intel_dp_mst_connector_helper_fun
.mode_valid = intel_dp_mst_mode_valid,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
.best_encoder = intel_mst_best_encoder,
+   .atomic_check = 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

2017-04-28 Thread Dongwon Kim
Hi Chris,

I tried this but I still see tests are failing. 
I wanted to debug it little further to find a specific
condition where clflush is missing but didn't have 
enough time. I will look into this early next week.

Thanks

On Thu, Apr 27, 2017 at 03:46:42PM +0100, Chris Wilson wrote:
> Currently, we only mark the CPU cache as dirty if we skip a clflush.
> This leads to some confusion where we have to ask if the object is in
> the write domain or missed a clflush. If we always mark the cache as
> dirty, this becomes a much simply question to answer.
> 
> The goal remains to do as few clflushes as required and to do them as
> late as possible, in the hope of deferring the work to a kthread and not
> block the caller (e.g. execbuf, flips).
> 
> v2: Always call clflush before GPU execution when the cache_dirty flag
> is set. This may cause some extra work on llc systems that migrate dirty
> buffers back and forth - but we do try to limit that by only setting
> cache_dirty at the end of the gpu sequence.
> 
> Reported-by: Dongwon Kim 
> Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning 
> the scanout")
> Signed-off-by: Chris Wilson 
> Cc: Dongwon Kim 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 78 
> +++-
>  drivers/gpu/drm/i915/i915_gem_clflush.c  | 15 +++--
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 21 +++
>  drivers/gpu/drm/i915/i915_gem_internal.c |  3 +-
>  drivers/gpu/drm/i915/i915_gem_userptr.c  |  5 +-
>  drivers/gpu/drm/i915/selftests/huge_gem_object.c |  3 +-
>  6 files changed, 70 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 33fb11cc5acc..488ca7733c1e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -49,7 +49,7 @@ static void i915_gem_flush_free_objects(struct 
> drm_i915_private *i915);
>  
>  static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
>  {
> - if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + if (obj->cache_dirty)
>   return false;
>  
>   if (!i915_gem_object_is_coherent(obj))
> @@ -233,6 +233,14 @@ i915_gem_object_get_pages_phys(struct 
> drm_i915_gem_object *obj)
>   return st;
>  }
>  
> +static void __start_cpu_write(struct drm_i915_gem_object *obj)
> +{
> + obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> + obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> + if (cpu_write_needs_clflush(obj))
> + obj->cache_dirty = true;
> +}
> +
>  static void
>  __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
>   struct sg_table *pages,
> @@ -248,8 +256,7 @@ __i915_gem_object_release_shmem(struct 
> drm_i915_gem_object *obj,
>   !i915_gem_object_is_coherent(obj))
>   drm_clflush_sg(pages);
>  
> - obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> - obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> + __start_cpu_write(obj);
>  }
>  
>  static void
> @@ -684,6 +691,12 @@ i915_gem_dumb_create(struct drm_file *file,
>  args->size, >handle);
>  }
>  
> +static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
> +{
> + return !(obj->cache_level == I915_CACHE_NONE ||
> +  obj->cache_level == I915_CACHE_WT);
> +}
> +
>  /**
>   * Creates a new mm object and returns a handle to it.
>   * @dev: drm device pointer
> @@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
> unsigned int flush_domains)
>   case I915_GEM_DOMAIN_CPU:
>   i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
>   break;
> +
> + case I915_GEM_DOMAIN_RENDER:
> + if (gpu_write_needs_clflush(obj))
> + obj->cache_dirty = true;
> + break;
>   }
>  
>   obj->base.write_domain = 0;
> @@ -854,7 +872,8 @@ int i915_gem_obj_prepare_shmem_read(struct 
> drm_i915_gem_object *obj,
>* optimizes for the case when the gpu will dirty the data
>* anyway again before the next pread happens.
>*/
> - if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
> + if (!obj->cache_dirty &&
> + !(obj->base.read_domains & I915_GEM_DOMAIN_CPU))
>   *needs_clflush = CLFLUSH_BEFORE;
>  
>  out:
> @@ -906,14 +925,15 @@ int i915_gem_obj_prepare_shmem_write(struct 
> drm_i915_gem_object *obj,
>* This optimizes for the case when the gpu will use the data
>* right away and we therefore have to clflush anyway.
>*/
> - if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
> + if (!obj->cache_dirty) {
>   *needs_clflush |= CLFLUSH_AFTER;
>  
> - /* Same trick applies to invalidate partially written cachelines read
> -  * before writing.
> -  

Re: [Intel-gfx] [PATCH v7 03/20] drm/i915: Add support for per engine reset recovery

2017-04-28 Thread Michel Thierry



On 4/27/2017 4:50 PM, Chris Wilson wrote:

-static void engine_retire_requests(struct intel_engine_cs *engine)
+void engine_retire_requests(struct intel_engine_cs *engine)

Fortunately stray chunk. I was about to scream.



This chunk has been there for quite a long time, at least since v4... 
thanks for spotting it (I'm the one that should be screaming).

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


Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

2017-04-28 Thread Rafael J. Wysocki
On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote:
> Some drivers - like i915 - may not support the system suspend direct
> complete optimization due to differences in their runtime and system
> suspend sequence. Add a flag that when set resumes the device before
> calling the driver's system suspend handlers which effectively disables
> the optimization.
> 
> Needed by the next patch fixing suspend/resume on i915.
> 
> Suggested by Rafael.
> 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Imre Deak 

Acked-by: Rafael J. Wysocki 

The reason why the opt-out flag was not added on day one was because we were
not sure whether or not it would be necessary at all.

Quite evidently, it is needed.

> ---
> 
> [ After discussing with Jani, I'm going to apply this and the next patch
>   for now to the intel-gfx specific CI branch to unblock our testing. ]
> 
>  drivers/pci/pci.c   | 3 ++-
>  include/linux/pci.h | 7 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..020f02d 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
>  
>   if (!pm_runtime_suspended(dev)
>   || pci_target_state(pci_dev) != pci_dev->current_state
> - || platform_pci_need_resume(pci_dev))
> + || platform_pci_need_resume(pci_dev)
> + || pci_dev->needs_resume)
>   return false;
>  
>   /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 5948cfd..2f012f8 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -316,6 +316,9 @@ struct pci_dev {
>   unsigned inthotplug_user_indicators:1; /* SlotCtl indicators
> controlled exclusively by
> user sysfs */
> + unsigned intneeds_resume:1; /* Resume before calling the driver's
> +system suspend hooks, disabling the
> +direct_complete optimization. */
>   unsigned intd3_delay;   /* D3->D0 transition time in ms */
>   unsigned intd3cold_delay;   /* D3cold->D0 transition time in ms */
>  
> @@ -1110,6 +1113,10 @@ bool pci_check_pme_status(struct pci_dev *dev);
>  void pci_pme_wakeup_bus(struct pci_bus *bus);
>  void pci_d3cold_enable(struct pci_dev *dev);
>  void pci_d3cold_disable(struct pci_dev *dev);
> +static inline void pci_resume_before_suspend(struct pci_dev *dev, bool 
> enable)
> +{
> + dev->needs_resume = enable;
> +}
>  
>  static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
> bool enable)
> 

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


[Intel-gfx] [PATCH] tools/null_state_gen: Add GEN10 golden context batch buffer creation

2017-04-28 Thread Oscar Mateo
This batchbuffer is over 4096 bytes, so we need to increase the size of the
array (and the KMD has to be modified to deal with more than one page).

Notice that there to workarounds embedded here, both applicable to all CNL
steppings.

v2: WaPSRandomCSNotDone is not A0 only (as per the latest BSpec), so update
the comment in the code and in the commit message.

Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Signed-off-by: Oscar Mateo 
---
 lib/gen10_render.h |  63 +++
 tools/null_state_gen/Makefile.am   |   3 +-
 tools/null_state_gen/intel_batchbuffer.h   |   2 +-
 tools/null_state_gen/intel_null_state_gen.c|   5 +-
 tools/null_state_gen/intel_renderstate.h   |   1 +
 tools/null_state_gen/intel_renderstate_gen10.c | 538 +
 6 files changed, 609 insertions(+), 3 deletions(-)
 create mode 100644 lib/gen10_render.h
 create mode 100644 tools/null_state_gen/intel_renderstate_gen10.c

diff --git a/lib/gen10_render.h b/lib/gen10_render.h
new file mode 100644
index 000..f4a7dff
--- /dev/null
+++ b/lib/gen10_render.h
@@ -0,0 +1,63 @@
+#ifndef GEN10_RENDER_H
+#define GEN10_RENDER_H
+
+#include "gen9_render.h"
+
+#define GEN7_MI_RS_CONTROL (0x6 << 23)
+# define GEN7_MI_RS_CONTROL_ENABLE (1 << 0)
+
+#define GEN10_3DSTATE_GATHER_POOL_ALLOCGEN6_3D(3, 1, 0x1a)
+# define GEN10_3DSTATE_GATHER_POOL_ENABLE  (1 << 11)
+
+#define GEN10_3DSTATE_GATHER_CONSTANT_VS   GEN6_3D(3, 0, 0x34)
+#define GEN10_3DSTATE_GATHER_CONSTANT_HS   GEN6_3D(3, 0, 0x36)
+#define GEN10_3DSTATE_GATHER_CONSTANT_DS   GEN6_3D(3, 0, 0x37)
+#define GEN10_3DSTATE_GATHER_CONSTANT_GS   GEN6_3D(3, 0, 0x35)
+#define GEN10_3DSTATE_GATHER_CONSTANT_PS   GEN6_3D(3, 0, 0x38)
+
+#define GEN10_3DSTATE_WM_DEPTH_STENCIL GEN6_3D(3, 0, 0x4e)
+#define GEN10_3DSTATE_WM_CHROMAKEY GEN6_3D(3, 0, 0x4c)
+
+#define GEN8_REG_L3_CACHE_CONFIG   0x7034
+
+/*
+ * Programming for L3 cache allocations can be made per bank. Based on the
+ * programmed value HW will apply same allocations on other available banks.
+ * Total L3 Cache size per bank = 256 KB.
+ * {SLM,URB, DC,  RO(I/S, C, T),   L3 Client Pool}
+ * {  0,96,  32,  128, 0  }
+ */
+#define GEN10_L3_CACHE_CONFIG_VALUE0x00420060
+
+#define URB_ALIGN(val, align)  ((val % align) ? (val - (val % align)) : val)
+
+#define GEN10_VS_MIN_NUM_OF_URB_ENTRIES64
+#define GEN10_VS_MAX_NUM_OF_URB_ENTRIES2752
+
+#define GEN10_KB_PER_URB_INDEX 8
+#define GEN10_L3_URB_SIZE_PER_BANK_IN_KB   96
+
+#define GEN10_URB_RESERVED_SIZE_KB 32
+#define GEN10_URB_RESERVED_END_SIZE_KB 8
+
+#define GEN10_VS_NUM_BITS_PER_URB_UNIT 512
+#define GEN10_VS_NUM_OF_URB_UNITS  1 // zero based
+#define GEN10_VS_URB_ENTRY_SIZE_IN_BITS
(GEN10_VS_NUM_BITS_PER_URB_UNIT * \
+   (GEN10_VS_NUM_OF_URB_UNITS + 1))
+
+#define GEN10_VS_URB_START_INDEX (GEN10_URB_RESERVED_SIZE_KB / 
GEN10_KB_PER_URB_INDEX)
+
+#define GEN10_URB_SIZE_PER_SLICE_KB(l3_bank_count, slice_count)
\
+   URB_ALIGN((uint32_t)(GEN10_L3_URB_SIZE_PER_BANK_IN_KB * l3_bank_count / 
slice_count), GEN10_KB_PER_URB_INDEX)
+
+#define GEN10_VS_URB_SIZE_PER_SLICE_KB(total_urb_size_per_slice)   \
+   (total_urb_size_per_slice - GEN10_URB_RESERVED_SIZE_KB - 
GEN10_URB_RESERVED_END_SIZE_KB)
+
+#define GEN10_VS_NUM_URB_ENTRIES_PER_SLICE(total_urb_size_per_slice)   \
+   ((GEN10_VS_URB_SIZE_PER_SLICE_KB(total_urb_size_per_slice) *\
+   1024 * 8) / GEN10_VS_URB_ENTRY_SIZE_IN_BITS)
+
+#define GEN10_VS_END_URB_INDEX(urb_size_per_slice) \
+   ((urb_size_per_slice - GEN10_URB_RESERVED_END_SIZE_KB) / 
GEN10_KB_PER_URB_INDEX)
+
+#endif
diff --git a/tools/null_state_gen/Makefile.am b/tools/null_state_gen/Makefile.am
index 24884a7..2f90990 100644
--- a/tools/null_state_gen/Makefile.am
+++ b/tools/null_state_gen/Makefile.am
@@ -12,9 +12,10 @@ intel_null_state_gen_SOURCES =   \
intel_renderstate_gen7.c \
intel_renderstate_gen8.c \
intel_renderstate_gen9.c \
+   intel_renderstate_gen10.c \
intel_null_state_gen.c
 
-gens := 6 7 8 9
+gens := 6 7 8 9 10
 
 h = /tmp/intel_renderstate_gen$$gen.c
 states: intel_null_state_gen
diff --git a/tools/null_state_gen/intel_batchbuffer.h 
b/tools/null_state_gen/intel_batchbuffer.h
index 771d1c8..e40e01b 100644
--- a/tools/null_state_gen/intel_batchbuffer.h
+++ b/tools/null_state_gen/intel_batchbuffer.h
@@ -34,7 +34,7 @@
 #include 
 
 #define MAX_RELOCS 64
-#define MAX_ITEMS 1024
+#define MAX_ITEMS 2048
 #define MAX_STRLEN 256
 
 #define ALIGN(x, y) (((x) + (y)-1) & ~((y)-1))
diff --git a/tools/null_state_gen/intel_null_state_gen.c 

Re: [Intel-gfx] [alsa-devel] [PATCH v2 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card

2017-04-28 Thread Pierre-Louis Bossart
A quick bisect tells me this last patch looks problematic. I don't have 
time to look further into it today, hope this helps progress in finding 
the issue. This is on a CHT device with HDMI plugged in and DP left out 
unconnected for now.


$ git bisect good
9af5b5732365b8ea29000d1ad14800bb091a0724 is the first bad commit
commit 9af5b5732365b8ea29000d1ad14800bb091a0724
Author: Ville Syrjälä 
Date:   Tue Apr 25 20:42:40 2017 +0300

ALSA: x86: Register multiple PCM devices for the LPE audio card

Now that everything is in place let's register a PCM device for
each port of the display engine. This will make it possible to
actually output audio to multiple displays at the same time. And
it avoids modesets on unrelated displays from clobbering up the
ELD and whatnot for the display currently doing the playback.

v2: Add a PCM per port instead of per pipe

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 
Signed-off-by: Ville Syrjälä 

:04 04 17f94eecd597b97ccc003e2d27c03eadceb279f5 
271d4c3130f9cc1334e79bf60b7fdc7337192655 Mdrivers
:04 04 6806ba942f3c0844dcf6ffdfdd751c2007e5680f 
8b9e1d1f82a12febe705a771654fadc08c02c90f Minclude
:04 04 e1f46a21e1beaf9535b3e807f4cfeea5ad7dbe47 
afd86621214380c86769c30d6405d9335143cf6b Msound


$ git bisect log
git bisect start
# bad: [9af5b5732365b8ea29000d1ad14800bb091a0724] ALSA: x86: Register 
multiple PCM devices for the LPE audio card

git bisect bad 9af5b5732365b8ea29000d1ad14800bb091a0724
# good: [8b5a41bbd270c3a8db6d48bc1d6d6bafb59e6753] drm-tip: 
2017y-04m-27d-13h-10m-59s UTC integration manifest

git bisect good 8b5a41bbd270c3a8db6d48bc1d6d6bafb59e6753
# good: [63e34e5d2e8aaf85dfe48085e5dbbb7215da80ba] drm/i915: Replace 
tmds_clock_speed and link_rate with just ls_clock

git bisect good 63e34e5d2e8aaf85dfe48085e5dbbb7215da80ba
# good: [dc0ae8e9c2f395b24cba7a404f2ff49e7272bf4b] drm/i915: Clean up 
the LPE audio platform data

git bisect good dc0ae8e9c2f395b24cba7a404f2ff49e7272bf4b
# good: [7d80cfe6f7eafe6cddf36cd6e227d54a45c6f175] ALSA: x86: Split 
snd_intelhad into card and PCM specific structures

git bisect good 7d80cfe6f7eafe6cddf36cd6e227d54a45c6f175
# first bad commit: [9af5b5732365b8ea29000d1ad14800bb091a0724] ALSA: 
x86: Register multiple PCM devices for the LPE audio card




On 04/27/2017 11:02 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Now that everything is in place let's register a PCM device for
each port of the display engine. This will make it possible to
actually output audio to multiple displays at the same time. And
it avoids modesets on unrelated displays from clobbering up the
ELD and whatnot for the display currently doing the playback.

v2: Add a PCM per port instead of per pipe

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_lpe_audio.c |  19 ++---
  include/drm/intel_lpe_audio.h  |   6 +-
  sound/x86/intel_hdmi_audio.c   | 126 +++--
  sound/x86/intel_hdmi_audio.h   |   7 +-
  4 files changed, 92 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index bdbc235141b5..fa728ed21d1f 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -111,7 +111,11 @@ lpe_audio_platdev_create(struct drm_i915_private *dev_priv)
pinfo.size_data = sizeof(*pdata);
pinfo.dma_mask = DMA_BIT_MASK(32);
  
-	pdata->port.pipe = -1;

+   pdata->num_pipes = INTEL_INFO(dev_priv)->num_pipes;
+   pdata->num_ports = IS_CHERRYVIEW(dev_priv) ? 3 : 2; /* B,C,D or B,C */
+   pdata->port[0].pipe = -1;
+   pdata->port[1].pipe = -1;
+   pdata->port[2].pipe = -1;
spin_lock_init(>lpe_audio_slock);
  
  	platdev = platform_device_register_full();

@@ -319,7 +323,7 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
enum pipe pipe, enum port port,
const void *eld, int ls_clock, bool dp_output)
  {
-   unsigned long irq_flags;
+   unsigned long irqflags;
struct intel_hdmi_lpe_audio_pdata *pdata;
struct intel_hdmi_lpe_audio_port_pdata *ppdata;
u32 audio_enable;
@@ -328,14 +332,12 @@ void intel_lpe_audio_notify(struct drm_i915_private 
*dev_priv,
return;
  
  	pdata = dev_get_platdata(_priv->lpe_audio.platdev->dev);

-   ppdata = >port;
+   ppdata = >port[port];
  
-	spin_lock_irqsave(>lpe_audio_slock, irq_flags);

+   spin_lock_irqsave(>lpe_audio_slock, irqflags);
  
  	audio_enable = I915_READ(VLV_AUD_PORT_EN_DBG(port));
  
-	ppdata->port = port;

-
if (eld != NULL) 

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

2017-04-28 Thread Ville Syrjälä
On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:
> 
> 
> On 04/28/2017 03:41 AM, Takashi Iwai wrote:
> > On Thu, 27 Apr 2017 18:02:19 +0200,
> > ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä 
> >>
> >> Okay, here's the second attempt at getting multiple pipes playing back
> >> audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
> >> that now the PCM devices are associated with ports instead of pipes,
> >> so the audio from one device always gets output on the same display.
> >>
> >> I've also tacked on the alsa-lib conf update. No clue whether it's
> >> really correct or not (the config language isn't a close friend
> >> of mine).
> >>
> >> BTW I did notice that with LPE audio all the controls say iface=PCM,
> >> whereas on HDA a bunch of them say iface=MIXER. No idea if that's
> >> OK or not, just something I spotted when I was comparing the results
> >> with HDA.
> > We generally accept both iface types for IEC958 stuff, since
> > historically many drivers have already mixed them up.  So it's no
> > problem :)
> >
> >
> >> Entire series available here:
> >> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> >>
> >> Cc: Takashi Iwai 
> >> Cc: Pierre-Louis Bossart 
> > All look good, and feel free to take my reviewed-by tag
> >Reviewed-by: Takashi Iwai 
> >
> > As said previously, my only slight concern is the compatibility.
> > But, in the current situation with PulseAudio, only few people would
> > use this driver, so it shouldn't be so big impact, I suppose.
> >
> > BTW, which port is used in general on BYT/CHT?
> >
> > Oh, also, I suppose you want to carry these over i915 tree?
> > I don't mind either way, I can take them through sound tree if
> > preferred, too.
> I see frequent oops on startup with this lpe_audio_multipipe_2 branch 
> with my CHT device not booting or no HDMI audio device created.
> Not sure if these issues are due to the new patches or to the rest of 
> the drm code?
> 
> [5.529023] BUG: unable to handle kernel NULL pointer dereference 
> at   (null)
> [5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
> [5.529202] PGD 0
> 
> [5.529242] Oops:  [#1] SMP
> [5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform 
> snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq 
> snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac 
> snd soundcore i2c_designware_platform(+) i2c_designware_core 
> spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd 
> grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid 
> autofs4
> [5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted 
> 4.11.0-rc8-test+ #11
> [5.529671] Hardware name: ZOTAC XX/Cherry Trail FFD, BIOS 5.11 
> 09/28/2016
> [5.529736] task: 88007485b780 task.stack: c9bfc000
> [5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650 
> [snd_hdmi_lpe_audio]
> [5.529855] RSP: 0018:c9bffaf0 EFLAGS: 00010246
> [5.529904] RAX:  RBX: 880079209898 RCX: 
> 88007920f078
> [5.529967] RDX: 0014 RSI: c9bffb28 RDI: 
> 0002
> [5.530031] RBP: c9bffb70 R08: 0001 R09: 
> 
> [5.530094] R10: 88007441bf00 R11: c9bffb36 R12: 
> 88007920ef20
> [5.530159] R13: 88007920ef48 R14: 5688 R15: 
> 0047
> [5.530225] FS:  7f627c988640() GS:88007b30() 
> knlGS:
> [5.530299] CS:  0010 DS:  ES:  CR0: 80050033
> [5.530352] CR2:  CR3: 78cb8000 CR4: 
> 001006e0
> [5.530416] Call Trace:
> [5.530452]  platform_drv_probe+0x3b/0xa0
> [5.530494]  driver_probe_device+0x2bb/0x460
> [5.530538]  __driver_attach+0xdf/0xf0
> [5.530576]  ? driver_probe_device+0x460/0x460
> [5.530620]  bus_for_each_dev+0x60/0xa0
> [5.530658]  driver_attach+0x1e/0x20
> [5.530693]  bus_add_driver+0x170/0x270
> [5.530731]  driver_register+0x60/0xe0
> [5.530769]  ? 0xa01cb000
> [5.530803]  __platform_driver_register+0x36/0x40
> [5.530851]  hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio]
> [5.530915]  do_one_initcall+0x43/0x180
> [5.530956]  ? __vunmap+0x81/0xd0
> [5.530991]  ? kfree+0x14c/0x160
> [5.531024]  ? kmem_cache_alloc_trace+0x38/0x150
> [5.531070]  do_init_module+0x5f/0x1f8
> [5.531108]  load_module+0x271e/0x2bd0
> [5.531147]  ? kernel_read_file+0x1a3/0x1c0
> [5.531188]  SYSC_finit_module+0xbc/0xf0
> [5.531226]  ? SYSC_finit_module+0xbc/0xf0
> [5.531267]  SyS_finit_module+0xe/0x10
> [5.531305]  do_syscall_64+0x6e/0x180
> [5.531345]  entry_SYSCALL64_slow_path+0x25/0x25
> [5.531389] RIP: 0033:0x7f627b5fbbf9
> [

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev6)

2017-04-28 Thread Patchwork
== Series Details ==

Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file 
dynamically (rev6)
URL   : https://patchwork.freedesktop.org/series/23227/
State : success

== Summary ==

Series 23227v6 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23227/revisions/6/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:571s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:541s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:412s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:485s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:459s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:402s

1d490e4b6d5324cfbf8dc800cf4a99471252802c drm-tip: 2017y-04m-28d-14h-14m-47s UTC 
integration manifest
a004fb4 drm/i915: Redefine ptr_pack_bits() and friends
78596713 drm/i915: Make ptr_unpack_bits() more function-like
a1f6541 drm/i915: Lift timeline ordering to await_dma_fence
c37268d drm/i915: Mark up clflushes as belonging to an unordered timeline
3f480d8 drm/i915: Mark CPU cache as dirty on every transition for CPU writes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4583/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

2017-04-28 Thread Paulo Zanoni
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> This series adds Y-tiled buffer creation support into IGT libraries
> and
> goes on to use this capability to add support into FBC tests to use
> Y-tiled buffers.

The problem I reported before still happens to me. Please fix it before
resending.

> 
> Akash Goel (1):
>   lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method
> 
> Paulo Zanoni (1):
>   tests/kms_draw_crc: add support for Y tiling
> 
> Praveen Paneri (5):
>   lib/igt_fb: Let others use igt_get_fb_tile_size
>   lib/igt_fb: Add helper function for tile_to_mod
>   lib/igt_draw: Add Y-tiling support
>   igt/kms_frontbuffer_tracking: Add Y-tiling support
>   igt/kms_fbc_crc.c : Add Y-tile tests
> 
>  lib/igt_draw.c   | 165 -
> --
>  lib/igt_fb.c |  41 +-
>  lib/igt_fb.h |   4 +-
>  tests/kms_draw_crc.c |  58 ++
>  tests/kms_fbc_crc.c  |  71 +
>  tests/kms_frontbuffer_tracking.c |  48 +++-
>  6 files changed, 273 insertions(+), 114 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  93 +++-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  38 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 419 ++
 drivers/gpu/drm/i915/i915_syncmap.h|  39 ++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 272 +
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_random.c   |  11 +
 drivers/gpu/drm/i915/selftests/i915_random.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 609 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 ++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 15 files changed, 1558 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a7da9cdf6c39..0f8046e0a63c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3215,6 +3215,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__
 
+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 022f5588d906..637b8cddf988 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -773,6 +773,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;
 
+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 to_request(fence));
@@ -782,6 

Re: [Intel-gfx] [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

2017-04-28 Thread Logan Gunthorpe


On 28/04/17 11:51 AM, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 28/04/17 12:30 AM, Herbert Xu wrote:
>>> You are right.  Indeed the existing code looks buggy as they
>>> don't take sg->offset into account when doing the kmap.  Could
>>> you send me some patches that fix these problems first so that
>>> they can be easily backported?
>>
>> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
>> both do have the sg->offset accounted for. I'll send a patch for the
>> buggy one shortly.
> 
> I think they're all buggy when sg->offset is greater than PAGE_SIZE.

Yes, technically. But that's a _very_ common mistake. Pretty nearly
every case I looked at did not take that into account. I don't think
sg's that point to more than one continuous page are all that common.

Fixing all those cases without making a common function is a waste of
time IMO.

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


Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

2017-04-28 Thread Pierre-Louis Bossart



On 04/28/2017 03:41 AM, Takashi Iwai wrote:

On Thu, 27 Apr 2017 18:02:19 +0200,
ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Okay, here's the second attempt at getting multiple pipes playing back
audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
that now the PCM devices are associated with ports instead of pipes,
so the audio from one device always gets output on the same display.

I've also tacked on the alsa-lib conf update. No clue whether it's
really correct or not (the config language isn't a close friend
of mine).

BTW I did notice that with LPE audio all the controls say iface=PCM,
whereas on HDA a bunch of them say iface=MIXER. No idea if that's
OK or not, just something I spotted when I was comparing the results
with HDA.

We generally accept both iface types for IEC958 stuff, since
historically many drivers have already mixed them up.  So it's no
problem :)



Entire series available here:
git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 

All look good, and feel free to take my reviewed-by tag
   Reviewed-by: Takashi Iwai 

As said previously, my only slight concern is the compatibility.
But, in the current situation with PulseAudio, only few people would
use this driver, so it shouldn't be so big impact, I suppose.

BTW, which port is used in general on BYT/CHT?

Oh, also, I suppose you want to carry these over i915 tree?
I don't mind either way, I can take them through sound tree if
preferred, too.
I see frequent oops on startup with this lpe_audio_multipipe_2 branch 
with my CHT device not booting or no HDMI audio device created.
Not sure if these issues are due to the new patches or to the rest of 
the drm code?


[5.529023] BUG: unable to handle kernel NULL pointer dereference 
at   (null)

[5.529143] IP: hdmi_lpe_audio_probe+0x40f/0x650 [snd_hdmi_lpe_audio]
[5.529202] PGD 0

[5.529242] Oops:  [#1] SMP
[5.529274] Modules linked in: snd_soc_sst_atom_hifi2_platform 
snd_soc_sst_match snd_soc_core snd_compress lpc_ich snd_seq 
snd_seq_device shpchp snd_hdmi_lpe_audio(+) snd_pcm snd_timer dw_dmac 
snd soundcore i2c_designware_platform(+) i2c_designware_core 
spi_pxa2xx_platform acpi_pad mac_hid nfsd auth_rpcgss nfs_acl lockd 
grace sunrpc ip_tables x_tables hid_generic mmc_block i2c_hid usbhid hid 
autofs4
[5.529605] CPU: 2 PID: 512 Comm: systemd-udevd Not tainted 
4.11.0-rc8-test+ #11
[5.529671] Hardware name: ZOTAC XX/Cherry Trail FFD, BIOS 5.11 
09/28/2016

[5.529736] task: 88007485b780 task.stack: c9bfc000
[5.529793] RIP: 0010:hdmi_lpe_audio_probe+0x40f/0x650 
[snd_hdmi_lpe_audio]

[5.529855] RSP: 0018:c9bffaf0 EFLAGS: 00010246
[5.529904] RAX:  RBX: 880079209898 RCX: 
88007920f078
[5.529967] RDX: 0014 RSI: c9bffb28 RDI: 
0002
[5.530031] RBP: c9bffb70 R08: 0001 R09: 

[5.530094] R10: 88007441bf00 R11: c9bffb36 R12: 
88007920ef20
[5.530159] R13: 88007920ef48 R14: 5688 R15: 
0047
[5.530225] FS:  7f627c988640() GS:88007b30() 
knlGS:

[5.530299] CS:  0010 DS:  ES:  CR0: 80050033
[5.530352] CR2:  CR3: 78cb8000 CR4: 
001006e0

[5.530416] Call Trace:
[5.530452]  platform_drv_probe+0x3b/0xa0
[5.530494]  driver_probe_device+0x2bb/0x460
[5.530538]  __driver_attach+0xdf/0xf0
[5.530576]  ? driver_probe_device+0x460/0x460
[5.530620]  bus_for_each_dev+0x60/0xa0
[5.530658]  driver_attach+0x1e/0x20
[5.530693]  bus_add_driver+0x170/0x270
[5.530731]  driver_register+0x60/0xe0
[5.530769]  ? 0xa01cb000
[5.530803]  __platform_driver_register+0x36/0x40
[5.530851]  hdmi_lpe_audio_driver_init+0x17/0x1000 [snd_hdmi_lpe_audio]
[5.530915]  do_one_initcall+0x43/0x180
[5.530956]  ? __vunmap+0x81/0xd0
[5.530991]  ? kfree+0x14c/0x160
[5.531024]  ? kmem_cache_alloc_trace+0x38/0x150
[5.531070]  do_init_module+0x5f/0x1f8
[5.531108]  load_module+0x271e/0x2bd0
[5.531147]  ? kernel_read_file+0x1a3/0x1c0
[5.531188]  SYSC_finit_module+0xbc/0xf0
[5.531226]  ? SYSC_finit_module+0xbc/0xf0
[5.531267]  SyS_finit_module+0xe/0x10
[5.531305]  do_syscall_64+0x6e/0x180
[5.531345]  entry_SYSCALL64_slow_path+0x25/0x25
[5.531389] RIP: 0033:0x7f627b5fbbf9
[5.531424] RSP: 002b:7ffe053eee68 EFLAGS: 0246 ORIG_RAX: 
0139
[5.531493] RAX: ffda RBX: 55d6c745b690 RCX: 
7f627b5fbbf9
[5.531558] RDX:  RSI: 7f627c134995 RDI: 
0007
[5.531622] RBP: 7f627c134995 R08:  R09: 
7ffe053eef80
[5.531687] R10: 0007 R11: 

Re: [Intel-gfx] [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

2017-04-28 Thread Logan Gunthorpe


On 28/04/17 12:30 AM, Herbert Xu wrote:
> You are right.  Indeed the existing code looks buggy as they
> don't take sg->offset into account when doing the kmap.  Could
> you send me some patches that fix these problems first so that
> they can be easily backported?

Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
both do have the sg->offset accounted for. I'll send a patch for the
buggy one shortly.

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


Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote:
> The new batchbuffer for CNL surpasses the 4096 byte mark.
> 
> Cc: Mika Kuoppala 
> Cc: Ben Widawsky 
> Signed-off-by: Oscar Mateo 

Evil, 4k+ of nothing-ness that userspace then has to configure for itself
for correctness anyway.

Patch looks ok, but still question the sanity.
-Chris

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow null render state batchbuffers bigger than one page

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Allow null render state batchbuffers bigger than one page
URL   : https://patchwork.freedesktop.org/series/23713/
State : success

== Summary ==

Series 23713v1 drm/i915: Allow null render state batchbuffers bigger than one 
page
https://patchwork.freedesktop.org/api/1.0/series/23713/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-snb-2600) fdo#100125
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:513s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:534s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:412s

1d490e4b6d5324cfbf8dc800cf4a99471252802c drm-tip: 2017y-04m-28d-14h-14m-47s UTC 
integration manifest
fafea7b drm/i915: Allow null render state batchbuffers bigger than one page

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4582/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/2] tools/null_state_gen: Add GEN10 golden context batch buffer creation

2017-04-28 Thread Oscar Mateo
This batchbuffer is over 4096 bytes, so we need to increase the size of the
array (and the KMD has to be modified to deal with more than one page).

Notice that there to workarounds embedded here:
- WaRsGatherPoolEnable is to be applied to all CNL steppings, so it belongs
  here.
- WaPSRandomCSNotDone is A0 only, but since the golden context batch buffer
  is created offline in i-g-t (as opposed to dinamically in i915) we cannot
  really make it dependent on the stepping (there is a mechanism in i915 to
  *add* extra stuff to the golden context , via an additional auxiliary bb,
  but nothing to modify things *inside* the offline-created bb). So maybe
  apply the WA for now and remove it once production chips are the norm?

Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Signed-off-by: Oscar Mateo 
---
 lib/gen10_render.h |  63 +++
 tools/null_state_gen/Makefile.am   |   3 +-
 tools/null_state_gen/intel_batchbuffer.h   |   2 +-
 tools/null_state_gen/intel_null_state_gen.c|   5 +-
 tools/null_state_gen/intel_renderstate.h   |   1 +
 tools/null_state_gen/intel_renderstate_gen10.c | 538 +
 6 files changed, 609 insertions(+), 3 deletions(-)
 create mode 100644 lib/gen10_render.h
 create mode 100644 tools/null_state_gen/intel_renderstate_gen10.c

diff --git a/lib/gen10_render.h b/lib/gen10_render.h
new file mode 100644
index 000..f4a7dff
--- /dev/null
+++ b/lib/gen10_render.h
@@ -0,0 +1,63 @@
+#ifndef GEN10_RENDER_H
+#define GEN10_RENDER_H
+
+#include "gen9_render.h"
+
+#define GEN7_MI_RS_CONTROL (0x6 << 23)
+# define GEN7_MI_RS_CONTROL_ENABLE (1 << 0)
+
+#define GEN10_3DSTATE_GATHER_POOL_ALLOCGEN6_3D(3, 1, 0x1a)
+# define GEN10_3DSTATE_GATHER_POOL_ENABLE  (1 << 11)
+
+#define GEN10_3DSTATE_GATHER_CONSTANT_VS   GEN6_3D(3, 0, 0x34)
+#define GEN10_3DSTATE_GATHER_CONSTANT_HS   GEN6_3D(3, 0, 0x36)
+#define GEN10_3DSTATE_GATHER_CONSTANT_DS   GEN6_3D(3, 0, 0x37)
+#define GEN10_3DSTATE_GATHER_CONSTANT_GS   GEN6_3D(3, 0, 0x35)
+#define GEN10_3DSTATE_GATHER_CONSTANT_PS   GEN6_3D(3, 0, 0x38)
+
+#define GEN10_3DSTATE_WM_DEPTH_STENCIL GEN6_3D(3, 0, 0x4e)
+#define GEN10_3DSTATE_WM_CHROMAKEY GEN6_3D(3, 0, 0x4c)
+
+#define GEN8_REG_L3_CACHE_CONFIG   0x7034
+
+/*
+ * Programming for L3 cache allocations can be made per bank. Based on the
+ * programmed value HW will apply same allocations on other available banks.
+ * Total L3 Cache size per bank = 256 KB.
+ * {SLM,URB, DC,  RO(I/S, C, T),   L3 Client Pool}
+ * {  0,96,  32,  128, 0  }
+ */
+#define GEN10_L3_CACHE_CONFIG_VALUE0x00420060
+
+#define URB_ALIGN(val, align)  ((val % align) ? (val - (val % align)) : val)
+
+#define GEN10_VS_MIN_NUM_OF_URB_ENTRIES64
+#define GEN10_VS_MAX_NUM_OF_URB_ENTRIES2752
+
+#define GEN10_KB_PER_URB_INDEX 8
+#define GEN10_L3_URB_SIZE_PER_BANK_IN_KB   96
+
+#define GEN10_URB_RESERVED_SIZE_KB 32
+#define GEN10_URB_RESERVED_END_SIZE_KB 8
+
+#define GEN10_VS_NUM_BITS_PER_URB_UNIT 512
+#define GEN10_VS_NUM_OF_URB_UNITS  1 // zero based
+#define GEN10_VS_URB_ENTRY_SIZE_IN_BITS
(GEN10_VS_NUM_BITS_PER_URB_UNIT * \
+   (GEN10_VS_NUM_OF_URB_UNITS + 1))
+
+#define GEN10_VS_URB_START_INDEX (GEN10_URB_RESERVED_SIZE_KB / 
GEN10_KB_PER_URB_INDEX)
+
+#define GEN10_URB_SIZE_PER_SLICE_KB(l3_bank_count, slice_count)
\
+   URB_ALIGN((uint32_t)(GEN10_L3_URB_SIZE_PER_BANK_IN_KB * l3_bank_count / 
slice_count), GEN10_KB_PER_URB_INDEX)
+
+#define GEN10_VS_URB_SIZE_PER_SLICE_KB(total_urb_size_per_slice)   \
+   (total_urb_size_per_slice - GEN10_URB_RESERVED_SIZE_KB - 
GEN10_URB_RESERVED_END_SIZE_KB)
+
+#define GEN10_VS_NUM_URB_ENTRIES_PER_SLICE(total_urb_size_per_slice)   \
+   ((GEN10_VS_URB_SIZE_PER_SLICE_KB(total_urb_size_per_slice) *\
+   1024 * 8) / GEN10_VS_URB_ENTRY_SIZE_IN_BITS)
+
+#define GEN10_VS_END_URB_INDEX(urb_size_per_slice) \
+   ((urb_size_per_slice - GEN10_URB_RESERVED_END_SIZE_KB) / 
GEN10_KB_PER_URB_INDEX)
+
+#endif
diff --git a/tools/null_state_gen/Makefile.am b/tools/null_state_gen/Makefile.am
index 24884a7..2f90990 100644
--- a/tools/null_state_gen/Makefile.am
+++ b/tools/null_state_gen/Makefile.am
@@ -12,9 +12,10 @@ intel_null_state_gen_SOURCES =   \
intel_renderstate_gen7.c \
intel_renderstate_gen8.c \
intel_renderstate_gen9.c \
+   intel_renderstate_gen10.c \
intel_null_state_gen.c
 
-gens := 6 7 8 9
+gens := 6 7 8 9 10
 
 h = /tmp/intel_renderstate_gen$$gen.c
 states: intel_null_state_gen
diff --git a/tools/null_state_gen/intel_batchbuffer.h 
b/tools/null_state_gen/intel_batchbuffer.h
index 771d1c8..e40e01b 100644
--- 

[Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

2017-04-28 Thread Oscar Mateo
The new batchbuffer for CNL surpasses the 4096 byte mark.

Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_gem_render_state.c | 40 +++-
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 12d7036..07f9bd6 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -62,12 +62,12 @@ struct intel_render_state {
  * this is sufficient as the null state generator makes the final batch
  * with two passes to build command and state separately. At this point
  * the size of both are known and it compacts them by relocating the state
- * right after the commands taking care of alignment so we should sufficient
- * space below them for adding new commands.
+ * right after the commands taking care of alignment so we should have
+ * sufficient space below them for adding new commands.
  */
-#define OUT_BATCH(batch, i, val)   \
+#define OUT_BATCH(batch, size, i, val) \
do {\
-   if ((i) >= PAGE_SIZE / sizeof(u32)) \
+   if ((i) >= size / sizeof(u32))  \
goto err;   \
(batch)[(i)++] = (val); \
} while(0)
@@ -86,7 +86,11 @@ static int render_state_setup(struct intel_render_state *so,
if (ret)
return ret;
 
-   d = kmap_atomic(i915_gem_object_get_dirty_page(obj, 0));
+   d = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(d)) {
+   ret = PTR_ERR(d);
+   goto out;
+   }
 
while (i < rodata->batch_items) {
u32 s = rodata->batch[i];
@@ -118,7 +122,7 @@ static int render_state_setup(struct intel_render_state *so,
so->batch_size = rodata->batch_items * sizeof(u32);
 
while (i % CACHELINE_DWORDS)
-   OUT_BATCH(d, i, MI_NOOP);
+   OUT_BATCH(d, obj->base.size, i, MI_NOOP);
 
so->aux_offset = i * sizeof(u32);
 
@@ -141,15 +145,15 @@ static int render_state_setup(struct intel_render_state 
*so,
 */
u32 eu_pool_config = 0x00777000;
 
-   OUT_BATCH(d, i, GEN9_MEDIA_POOL_STATE);
-   OUT_BATCH(d, i, GEN9_MEDIA_POOL_ENABLE);
-   OUT_BATCH(d, i, eu_pool_config);
-   OUT_BATCH(d, i, 0);
-   OUT_BATCH(d, i, 0);
-   OUT_BATCH(d, i, 0);
+   OUT_BATCH(d, obj->base.size, i, GEN9_MEDIA_POOL_STATE);
+   OUT_BATCH(d, obj->base.size, i, GEN9_MEDIA_POOL_ENABLE);
+   OUT_BATCH(d, obj->base.size, i, eu_pool_config);
+   OUT_BATCH(d, obj->base.size, i, 0);
+   OUT_BATCH(d, obj->base.size, i, 0);
+   OUT_BATCH(d, obj->base.size, i, 0);
}
 
-   OUT_BATCH(d, i, MI_BATCH_BUFFER_END);
+   OUT_BATCH(d, obj->base.size, i, MI_BATCH_BUFFER_END);
so->aux_size = i * sizeof(u32) - so->aux_offset;
so->aux_offset += so->batch_offset;
/*
@@ -160,7 +164,7 @@ static int render_state_setup(struct intel_render_state *so,
 
if (needs_clflush)
drm_clflush_virt_range(d, i * sizeof(u32));
-   kunmap_atomic(d);
+   i915_gem_object_unpin_map(obj);
 
ret = i915_gem_object_set_to_gtt_domain(obj, false);
 out:
@@ -168,7 +172,7 @@ static int render_state_setup(struct intel_render_state *so,
return ret;
 
 err:
-   kunmap_atomic(d);
+   i915_gem_object_unpin_map(obj);
ret = -EINVAL;
goto out;
 }
@@ -189,14 +193,12 @@ int i915_gem_render_state_init(struct intel_engine_cs 
*engine)
if (!rodata)
return 0;
 
-   if (rodata->batch_items * 4 > PAGE_SIZE)
-   return -EINVAL;
-
so = kmalloc(sizeof(*so), GFP_KERNEL);
if (!so)
return -ENOMEM;
 
-   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   obj = i915_gem_object_create_internal(engine->i915,
+   PAGE_ALIGN(rodata->batch_items * 4));
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto err_free;
-- 
1.9.1

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


[Intel-gfx] [PATCH 1/2] tools/null_state_gen: Automatically generate the copyright header

2017-04-28 Thread Oscar Mateo
Last bit to make the generated files directly usable in i915.

Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 tools/null_state_gen/intel_null_state_gen.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/tools/null_state_gen/intel_null_state_gen.c 
b/tools/null_state_gen/intel_null_state_gen.c
index 7d5887e..06eb954 100644
--- a/tools/null_state_gen/intel_null_state_gen.c
+++ b/tools/null_state_gen/intel_null_state_gen.c
@@ -29,9 +29,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "intel_renderstate.h"
 #include "intel_batchbuffer.h"
+#include "lib/version.h"
+#include "config.h"
 
 static int debug = 0;
 
@@ -42,6 +45,42 @@ static void print_usage(char *s)
s);
 }
 
+static void print_copyright(void)
+{
+   time_t time_raw;
+   struct tm *time_local;
+   char year[6]; // avoid the year 1 effect!
+
+   time(_raw);
+   time_local = localtime(_raw);
+   strftime(year, sizeof(year), "%Y", time_local);
+
+   printf("/*\n");
+   printf(" * Copyright © %s Intel Corporation\n", year);
+   printf(" *\n");
+   printf(" * Permission is hereby granted, free of charge, to any person 
obtaining a\n");
+   printf(" * copy of this software and associated documentation files 
(the \"Software\"),\n");
+   printf(" * to deal in the Software without restriction, including 
without limitation\n");
+   printf(" * the rights to use, copy, modify, merge, publish, distribute, 
sublicense,\n");
+   printf(" * and/or sell copies of the Software, and to permit persons to 
whom the\n");
+   printf(" * Software is furnished to do so, subject to the following 
conditions:\n");
+   printf(" *\n");
+   printf(" * The above copyright notice and this permission notice 
(including the next\n");
+   printf(" * paragraph) shall be included in all copies or substantial 
portions of the\n");
+   printf(" * Software.\n");
+   printf(" *\n");
+   printf(" * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY 
KIND, EXPRESS OR\n");
+   printf(" * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,\n");
+   printf(" * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
EVENT SHALL\n");
+   printf(" * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, 
DAMAGES OR OTHER\n");
+   printf(" * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE, ARISING\n");
+   printf(" * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE 
OR OTHER\n");
+   printf(" * DEALINGS IN THE SOFTWARE.\n");
+   printf(" *\n");
+   printf(" * Generated by: intel-gpu-tools-%s-%s\n", PACKAGE_VERSION, 
IGT_GIT_SHA1);
+   printf(" */\n\n");
+}
+
 /* Creates the intel_renderstate_genX.c file for the particular
  * GEN product
  */
@@ -52,6 +91,8 @@ static int print_state(int gen, struct intel_batchbuffer 
*batch)
 
fprintf(stderr, "Generating for gen%d\n", gen);
 
+   print_copyright();
+
printf("#include \"intel_renderstate.h\"\n\n");
 
/* Relocation offsets.  These are byte offsets in the golden context
-- 
1.9.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

2017-04-28 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] PCI / PM: Add needs_resume flag to avoid 
suspend complete optimization
URL   : https://patchwork.freedesktop.org/series/23707/
State : success

== Summary ==

Series 23707v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23707/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:562s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:454s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:580s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:427s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:524s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:399s

1d490e4b6d5324cfbf8dc800cf4a99471252802c drm-tip: 2017y-04m-28d-14h-14m-47s UTC 
integration manifest
afe0d7e drm/i915: Prevent the system suspend complete optimization
926c9e5 PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4581/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v7 12/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

2017-04-28 Thread Michel Thierry



On 4/27/2017 4:58 PM, Chris Wilson wrote:

On Thu, Apr 27, 2017 at 04:12:52PM -0700, Michel Thierry wrote:

+#define WA_REG_WR_GUC_RESTORE(addr, val) do { \
+   const int r = guc_wa_add(dev_priv, (addr), (val)); \
+   if (r) \
+   return r; \
+   } while (0)


Try to avoid burying returns inside macros. Does this macro help code
readability? Would perhaps just a table of registers + values be easier?
-Chris



Sure, I can change it to something else.
I only replicated what the other WA_* macros (the ones we need in ctx 
switch) were doing.

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


Re: [Intel-gfx] [PATCH] drm/i915/guc: Enable send function only after successful init

2017-04-28 Thread Daniele Ceraolo Spurio



On 28/04/17 06:30, Michal Wajdeczko wrote:

It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 


Reviewed-by: Daniele Ceraolo Spurio 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev5)

2017-04-28 Thread Patchwork
== Series Details ==

Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file 
dynamically (rev5)
URL   : https://patchwork.freedesktop.org/series/23227/
State : success

== Summary ==

Series 23227v5 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23227/revisions/5/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:422s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:539s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:579s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:401s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
2826b18 drm/i915: Redefine ptr_pack_bits() and friends
d366ae4 drm/i915: Make ptr_unpack_bits() more function-like
758209b drm/i915: Lift timeline ordering to await_dma_fence
5cf482d drm/i915: Mark up clflushes as belonging to an unordered timeline
5eec284 drm/i915: Mark CPU cache as dirty on every transition for CPU writes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4580/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 6/7] igt/kms_frontbuffer_tracking: Add Y-tiling support

2017-04-28 Thread Praveen Paneri
Allow tests to create Y-tiled bufferes using a separate
argument to the test without increasing the number of
subtests.

v2: Changed tiling option to string (Paulo)

Signed-off-by: Praveen Paneri 
---
 tests/kms_frontbuffer_tracking.c | 48 
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 7cea4de..62ae33a 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -252,6 +252,7 @@ struct {
int only_pipes;
int shared_fb_x_offset;
int shared_fb_y_offset;
+   uint64_t tiling;
 } opt = {
.check_status = true,
.check_crc = true,
@@ -264,6 +265,7 @@ struct {
.only_pipes = PIPE_COUNT,
.shared_fb_x_offset = 500,
.shared_fb_y_offset = 500,
+   .tiling = LOCAL_I915_FORMAT_MOD_X_TILED,
 };
 
 struct modeset_params {
@@ -578,7 +580,7 @@ static void create_fb(enum pixel_format pformat, int width, 
int height,
if (plane == PLANE_CUR)
tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
else
-   tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
+   tiling_for_size = opt.tiling;
 
igt_calc_fb_size(drm.fd, width, height, bpp, tiling_for_size, ,
 );
@@ -710,7 +712,7 @@ static void create_shared_fb(enum pixel_format format)
 
big_h = prim_h + scnd_h + offs_h + opt.shared_fb_y_offset;
 
-   create_fb(format, big_w, big_h, LOCAL_I915_FORMAT_MOD_X_TILED,
+   create_fb(format, big_w, big_h, opt.tiling,
  PLANE_PRI, >big);
 }
 
@@ -744,16 +746,16 @@ static void create_fbs(enum pixel_format format)
 
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >prim_pri);
+ opt.tiling, PLANE_PRI, >prim_pri);
create_fb(format, prim_mode_params.cursor.w,
  prim_mode_params.cursor.h, LOCAL_DRM_FORMAT_MOD_NONE,
  PLANE_CUR, >prim_cur);
create_fb(format, prim_mode_params.sprite.w,
- prim_mode_params.sprite.h, LOCAL_I915_FORMAT_MOD_X_TILED,
+ prim_mode_params.sprite.h, opt.tiling,
  PLANE_SPR, >prim_spr);
 
create_fb(format, offscreen_fb.w, offscreen_fb.h,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >offscreen);
+ opt.tiling, PLANE_PRI, >offscreen);
 
create_shared_fb(format);
 
@@ -762,11 +764,11 @@ static void create_fbs(enum pixel_format format)
 
create_fb(format, scnd_mode_params.mode->hdisplay,
  scnd_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, >scnd_pri);
+ opt.tiling, PLANE_PRI, >scnd_pri);
create_fb(format, scnd_mode_params.cursor.w, scnd_mode_params.cursor.h,
  LOCAL_DRM_FORMAT_MOD_NONE, PLANE_CUR, >scnd_cur);
create_fb(format, scnd_mode_params.sprite.w, scnd_mode_params.sprite.h,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_SPR, >scnd_spr);
+ opt.tiling, PLANE_SPR, >scnd_spr);
 }
 
 static bool set_mode_for_params(struct modeset_params *params)
@@ -1252,7 +1254,7 @@ static void init_blue_crc(enum pixel_format format, bool 
mandatory_sink_crc)
 
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, );
+ opt.tiling, PLANE_PRI, );
 
fill_fb(, COLOR_PRIM_BG);
 
@@ -1287,7 +1289,7 @@ static void init_crcs(enum pixel_format format,
for (r = 0; r < pattern->n_rects; r++)
create_fb(format, prim_mode_params.mode->hdisplay,
  prim_mode_params.mode->vdisplay,
- LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, 
_fbs[r]);
+ opt.tiling, PLANE_PRI, _fbs[r]);
 
for (r = 0; r < pattern->n_rects; r++)
fill_fb(_fbs[r], COLOR_PRIM_BG);
@@ -2386,7 +2388,7 @@ static void flip_subtest(const struct test_mode *t)
prepare_subtest(t, pattern);
 
create_fb(t->format, params->fb.fb->width, params->fb.fb->height,
- LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
+ opt.tiling, t->plane, );
fill_fb(, bg_color);
orig_fb = params->fb.fb;
 
@@ -2432,7 +2434,7 @@ static void fliptrack_subtest(const struct test_mode *t, 
enum flip_type type)
prepare_subtest(t, pattern);
 
create_fb(t->format, params->fb.fb->width, params->fb.fb->height,
- LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
+ opt.tiling, t->plane, );
fill_fb(, COLOR_PRIM_BG);
orig_fb = params->fb.fb;
 
@@ -2643,7 +2645,7 @@ static void fullscreen_plane_subtest(const 

[Intel-gfx] [PATCH v2 7/7] igt/kms_fbc_crc.c : Add Y-tile tests

2017-04-28 Thread Praveen Paneri
Now that we have support for Y-tiled buffers, add another
iteration of tests for Y-tiled buffers.

Signed-off-by: Praveen Paneri 
---
 tests/kms_fbc_crc.c | 71 +
 1 file changed, 39 insertions(+), 32 deletions(-)

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 7964e05..cdf04c1 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -318,12 +318,10 @@ static void prepare_crtc(data_t *data)
igt_output_set_pipe(output, data->pipe);
 }
 
-static void create_fbs(data_t *data, bool tiled, struct igt_fb *fbs)
+static void create_fbs(data_t *data, uint64_t tiling, struct igt_fb *fbs)
 {
int rc;
drmModeModeInfo *mode = igt_output_get_mode(data->output);
-   uint64_t tiling = tiled ? LOCAL_I915_FORMAT_MOD_X_TILED :
- LOCAL_DRM_FORMAT_MOD_NONE;
 
rc = igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
 DRM_FORMAT_XRGB, tiling,
@@ -344,8 +342,8 @@ static void get_ref_crcs(data_t *data)
struct igt_fb fbs[4];
int i;
 
-   create_fbs(data, false, [0]);
-   create_fbs(data, false, [2]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [0]);
+   create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, [2]);
 
fill_mmap_gtt(data, fbs[2].gem_handle, 0xff);
fill_mmap_gtt(data, fbs[3].gem_handle, 0xff);
@@ -366,7 +364,7 @@ static void get_ref_crcs(data_t *data)
igt_remove_fb(data->drm_fd, [i]);
 }
 
-static bool prepare_test(data_t *data, enum test_mode test_mode)
+static bool prepare_test(data_t *data, enum test_mode test_mode, uint64_t 
tiling)
 {
igt_display_t *display = >display;
igt_output_t *output = data->output;
@@ -374,7 +372,7 @@ static bool prepare_test(data_t *data, enum test_mode 
test_mode)
 
data->primary = igt_output_get_plane_type(data->output, 
DRM_PLANE_TYPE_PRIMARY);
 
-   create_fbs(data, true, data->fb);
+   create_fbs(data, tiling, data->fb);
 
igt_pipe_crc_free(data->pipe_crc);
data->pipe_crc = NULL;
@@ -484,32 +482,41 @@ static void run_test(data_t *data, enum test_mode mode)
 
reset_display(data);
 
-   for_each_pipe_with_valid_output(display, data->pipe, data->output) {
-   prepare_crtc(data);
-
-   igt_info("Beginning %s on pipe %s, connector %s\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
-
-   if (!prepare_test(data, mode)) {
-   igt_info("%s on pipe %s, connector %s: SKIPPED\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- igt_output_name(data->output));
-   continue;
+   for (int tiling = I915_TILING_X;
+tiling <= I915_TILING_Y; tiling++) {
+   for_each_pipe_with_valid_output(display,
+   data->pipe, data->output) {
+   prepare_crtc(data);
+
+   igt_info("Beginning %s on pipe %s, connector "
+   "%s, %s-tiled\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output),
+   (tiling == I915_TILING_X) ? "x":"y" );
+
+   if (!prepare_test(data, mode,
+ igt_fb_tiling_to_mod(tiling))) {
+   igt_info("%s on pipe %s, connector %s: 
SKIPPED\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output));
+   continue;
+   }
+
+   valid_tests++;
+
+   test_crc(data, mode);
+
+   igt_info("%s on pipe %s, connector %s"
+   "%s-tiled: PASSED\n",
+   igt_subtest_name(),
+   kmstest_pipe_name(data->pipe),
+   igt_output_name(data->output),
+   (tiling == I915_TILING_X) ? "x":"y" );
+
+   finish_crtc(data, mode);
}
-
-   valid_tests++;
-
-   test_crc(data, mode);
-
-   igt_info("%s on pipe %s, connector %s: PASSED\n",
- igt_subtest_name(),
- kmstest_pipe_name(data->pipe),
- 

[Intel-gfx] [PATCH v2 3/7] lib/igt_draw: Add Y-tiling support

2017-04-28 Thread Praveen Paneri
This patch adds Y-tiling support for igt_draw_rect function.

v2:
Use helper function to get tile sizes (Ville)

Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 132 +
 1 file changed, 87 insertions(+), 45 deletions(-)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 29aec85..fcf8fba 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -136,32 +136,47 @@ static int swizzle_addr(int addr, int swizzle)
 
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
-  int bpp)
+static int linear_x_y_to_tiled_pos(int fd, int x, int y, uint32_t stride, int 
swizzle,
+  int bpp, int tiling)
 {
-   int x_tile_size, y_tile_size;
-   int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
-   int line_size, tile_size;
+   uint32_t tile_width, tile_height, tile_size;
+   int tile_x, tile_y; /* Co-ordinates of the tile holding the pixel */
+   int tile_x_off, tile_y_off; /* pixel position inside the tile */
int tile_n, tile_off;
-   int tiled_pos, tiles_per_line;
+   int line_size, tiles_per_line;
+   int tiled_pos;
int pixel_size = bpp / 8;
 
+   igt_get_fb_tile_size(fd, (uint64_t)igt_fb_tiling_to_mod(tiling), bpp,
+   _width, _height);
+
line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
+   tile_size = tile_width * tile_height;
+   tiles_per_line = line_size / tile_width;
 
-   y_tile_n = y / y_tile_size;
-   y_tile_off = y % y_tile_size;
+   tile_y = y / tile_height;
+   tile_y_off = y % tile_height;
 
-   x_tile_n = (x * pixel_size) / x_tile_size;
-   x_tile_off = (x * pixel_size) % x_tile_size;
+   tile_x = (x * pixel_size) / tile_width;
+   tile_x_off = (x * pixel_size) % tile_width;
 
-   tile_n = y_tile_n * tiles_per_line + x_tile_n;
-   tile_off = y_tile_off * x_tile_size + x_tile_off;
-   tiled_pos = tile_n * tile_size + tile_off;
+   tile_n = tile_y * tiles_per_line + tile_x;
+
+   if (tiling == I915_TILING_X ) {
+   tile_off = tile_y_off * tile_width + tile_x_off;
+   } else { /* (tiling == I915_TILING_Y ) */
+   int x_oword_n, x_oword_off;
+   int oword_size = 16;
+
+   /* computation inside the tile */
+   x_oword_n = tile_x_off / oword_size;
+   x_oword_off = tile_x_off % oword_size;
+   tile_off = x_oword_n * tile_height * oword_size
+  + tile_y_off * oword_size
+  + x_oword_off;
+   }
 
+   tiled_pos = tile_n * tile_size + tile_off;
tiled_pos = swizzle_addr(tiled_pos, swizzle);
 
return tiled_pos / pixel_size;
@@ -169,34 +184,49 @@ static int linear_x_y_to_tiled_pos(int x, int y, uint32_t 
stride, int swizzle,
 
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
-static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
-   int swizzle, int bpp, int *x, int *y)
+static void tiled_pos_to_x_y_linear(int fd, int tiled_pos, uint32_t stride,
+   int swizzle, int bpp, int *x, int *y,
+   int tiling)
 {
-   int tile_n, tile_off, tiles_per_line, line_size;
-   int x_tile_off, y_tile_off;
-   int x_tile_n, y_tile_n;
-   int x_tile_size, y_tile_size, tile_size;
+   uint32_t tile_width, tile_height, tile_size;
+   int tile_x, tile_y; /* Co-ordinates of the tile holding the pixel */
+   int tile_x_off, tile_y_off; /* pixel position inside the tile */
+   int tile_n, tile_off;
+   int line_size, tiles_per_line;
int pixel_size = bpp / 8;
 
+   igt_get_fb_tile_size(fd, (uint64_t)igt_fb_tiling_to_mod(tiling), bpp,
+ _width, _height);
tiled_pos = swizzle_addr(tiled_pos, swizzle);
 
line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
+   tile_size = tile_width * tile_height;
+   tiles_per_line = line_size / tile_width;
 
tile_n = tiled_pos / tile_size;
tile_off = tiled_pos % tile_size;
 
-   y_tile_off = tile_off / x_tile_size;
-   x_tile_off = tile_off % x_tile_size;
+   tile_x = tile_n % tiles_per_line;
+   tile_y = tile_n / tiles_per_line;
 
-   x_tile_n = tile_n % tiles_per_line;
-   y_tile_n = tile_n / tiles_per_line;
+   if (tiling == I915_TILING_X ) {
 
-   *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;

[Intel-gfx] [PATCH v2 4/7] lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

2017-04-28 Thread Praveen Paneri
From: Akash Goel 

v2: Moved identical code into a single function (Paulo)

Signed-off-by: Akash Goel 
Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index fcf8fba..27a69cd 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -31,6 +31,7 @@
 #include "igt_core.h"
 #include "igt_fb.h"
 #include "ioctl_wrappers.h"
+#include "i830_reg.h"
 
 /**
  * SECTION:igt_draw
@@ -242,6 +243,34 @@ static void set_pixel(void *_ptr, int index, uint32_t 
color, int bpp)
}
 }
 
+static void switch_blt_tiling(struct intel_batchbuffer *batch, uint32_t 
tiling, bool on)
+{
+   uint32_t bcs_swctrl;
+
+   /* Default is X-tile */
+   if (tiling != I915_TILING_Y)
+   return;
+
+   bcs_swctrl = (0x3 << 16) | (on ? 0x3 : 0x0);
+
+   /* To change the tile register, insert an MI_FLUSH_DW followed by an
+* MI_LOAD_REGISTER_IMM
+*/
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_FLUSH_DW | 2);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   OUT_BATCH(0x0);
+   ADVANCE_BATCH();
+
+   BEGIN_BATCH(4, 0);
+   OUT_BATCH(MI_LOAD_REGISTER_IMM);
+   OUT_BATCH(0x22200); /* BCS_SWCTRL */
+   OUT_BATCH(bcs_swctrl);
+   OUT_BATCH(MI_NOOP);
+   ADVANCE_BATCH();
+}
+
 static void draw_rect_ptr_linear(void *ptr, uint32_t stride,
 struct rect *rect, uint32_t color, int bpp)
 {
@@ -487,6 +516,8 @@ static void draw_rect_blt(int fd, struct cmd_data *cmd_data,
blt_cmd_tiling = (tiling) ? XY_COLOR_BLT_TILED : 0;
pitch = (tiling) ? buf->stride / 4 : buf->stride;
 
+   switch_blt_tiling(batch, tiling, true);
+
BEGIN_BATCH(6, 1);
OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | XY_COLOR_BLT_WRITE_ALPHA |
  XY_COLOR_BLT_WRITE_RGB | blt_cmd_tiling | blt_cmd_len);
@@ -497,6 +528,8 @@ static void draw_rect_blt(int fd, struct cmd_data *cmd_data,
OUT_BATCH(color);
ADVANCE_BATCH();
 
+   switch_blt_tiling(batch, tiling, false);
+
intel_batchbuffer_flush(batch);
intel_batchbuffer_free(batch);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 5/7] tests/kms_draw_crc: add support for Y tiling

2017-04-28 Thread Praveen Paneri
From: Paulo Zanoni 

This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.

Signed-off-by: Paulo Zanoni 
Signed-off-by: Praveen Paneri 
---
 tests/kms_draw_crc.c | 58 ++--
 1 file changed, 43 insertions(+), 15 deletions(-)

diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index c57d3a3..1d91b48 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
 };
 
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   LOCAL_I915_FORMAT_MOD_X_TILED,
+   LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
 struct base_crc {
bool set;
igt_crc_t crc;
@@ -151,6 +158,11 @@ static void draw_method_subtest(enum igt_draw_method 
method,
 {
igt_crc_t crc;
 
+   if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+   igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
+
+   kmstest_unset_all_crtcs(drm_fd, drm_res);
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
 * comparison. Cache the value so we don't recompute it for every single
 * subtest. */
@@ -208,6 +220,12 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, );
igt_assert_crc_equal(, _crc);
 
+   if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+   get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED, );
+   igt_assert_crc_equal(, _crc);
+   }
+
+   kmstest_unset_all_crtcs(drm_fd, drm_res);
igt_remove_fb(drm_fd, );
 }
 
@@ -265,28 +283,38 @@ static const char *format_str(int format_index)
}
 }
 
+static const char *tiling_str(int tiling_index)
+{
+   switch (tilings[tiling_index]) {
+   case LOCAL_DRM_FORMAT_MOD_NONE:
+   return "untiled";
+   case LOCAL_I915_FORMAT_MOD_X_TILED:
+   return "xtiled";
+   case LOCAL_I915_FORMAT_MOD_Y_TILED:
+   return "ytiled";
+   default:
+   igt_assert(false);
+   }
+}
+
 igt_main
 {
enum igt_draw_method method;
-   int format_index;
+   int format_idx, tiling_idx;
 
igt_fixture
setup_environment();
 
-   for (format_index = 0; format_index < N_FORMATS; format_index++) {
-   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
-   igt_subtest_f("draw-method-%s-%s-untiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_DRM_FORMAT_MOD_NONE);
-   igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_I915_FORMAT_MOD_X_TILED);
-   }
-   }
+   for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
+   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+   for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
+   igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+   draw_method_subtest(method, format_idx,
+   tilings[tiling_idx]);
+   } } }
 
igt_subtest("fill-fb")
fill_fb_subtest();
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 2/7] lib/igt_fb: Add helper function for tile_to_mod

2017-04-28 Thread Praveen Paneri
igt_get_fb_tile_size function takes modifer as an argument
This helper function will let users to convert tiling to
modifier and use igt_get_fb_tile_size()

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 26 ++
 lib/igt_fb.h |  1 +
 2 files changed, 27 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 9ba1e3b..27baf79 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -216,6 +216,32 @@ uint64_t igt_fb_mod_to_tiling(uint64_t modifier)
}
 }
 
+/**
+ * igt_fb_tiling_to_mod:
+ * @tiling: DRM framebuffer tiling
+ *
+ * This function converts a DRM framebuffer tiling to its corresponding
+ * modifier constant.
+ *
+ * Returns:
+ * A tiling constant
+ */
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling)
+{
+   switch (tiling) {
+   case I915_TILING_NONE:
+   return LOCAL_DRM_FORMAT_MOD_NONE;
+   case I915_TILING_X:
+   return LOCAL_I915_FORMAT_MOD_X_TILED;
+   case I915_TILING_Y:
+   return LOCAL_I915_FORMAT_MOD_Y_TILED;
+   case I915_TILING_Yf:
+   return LOCAL_I915_FORMAT_MOD_Yf_TILED;
+   default:
+   igt_assert(0);
+   }
+}
+
 /* helpers to create nice-looking framebuffers */
 static int create_bo_for_fb(int fd, int width, int height, uint32_t format,
uint64_t tiling, unsigned size, unsigned stride,
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 414cb3d..a01671b 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -131,6 +131,7 @@ int igt_create_bo_with_dimensions(int fd, int width, int 
height, uint32_t format
  bool *is_dumb);
 
 uint64_t igt_fb_mod_to_tiling(uint64_t modifier);
+uint64_t igt_fb_tiling_to_mod(uint64_t tiling);
 
 /* cairo-based painting */
 cairo_t *igt_get_cairo_ctx(int fd, struct igt_fb *fb);
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

2017-04-28 Thread Praveen Paneri
This series adds Y-tiled buffer creation support into IGT libraries and
goes on to use this capability to add support into FBC tests to use
Y-tiled buffers.

Akash Goel (1):
  lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

Paulo Zanoni (1):
  tests/kms_draw_crc: add support for Y tiling

Praveen Paneri (5):
  lib/igt_fb: Let others use igt_get_fb_tile_size
  lib/igt_fb: Add helper function for tile_to_mod
  lib/igt_draw: Add Y-tiling support
  igt/kms_frontbuffer_tracking: Add Y-tiling support
  igt/kms_fbc_crc.c : Add Y-tile tests

 lib/igt_draw.c   | 165 ---
 lib/igt_fb.c |  41 +-
 lib/igt_fb.h |   4 +-
 tests/kms_draw_crc.c |  58 ++
 tests/kms_fbc_crc.c  |  71 +
 tests/kms_frontbuffer_tracking.c |  48 +++-
 6 files changed, 273 insertions(+), 114 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 1/7] lib/igt_fb: Let others use igt_get_fb_tile_size

2017-04-28 Thread Praveen Paneri
This function can be used by igt_draw to get accurate
tile dimensions for all tile formats.

v2: Added comments to function igt_get_fb_tile_size (Daniel)

Signed-off-by: Praveen Paneri 
---
 lib/igt_fb.c | 16 +---
 lib/igt_fb.h |  3 ++-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d2b7e9e..9ba1e3b 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -73,9 +73,19 @@ static struct format_desc_struct {
 
 #define for_each_format(f) \
for (f = format_desc; f - format_desc < ARRAY_SIZE(format_desc); f++)
-
-static void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
-unsigned *width_ret, unsigned *height_ret)
+/**
+ * igt_get_fb_tile_size:
+ * @fd: The DRM file descriptor
+ * @tiling: Tiling layout of the framebuffer (as framebuffer modifier)
+ * @fb_bpp: Bytes per pixel of the framebuffer
+ * @width_ret: Width of the tile in pixels
+ * @height_ret: Height of the tile in pixels
+ *
+ * This function returns width and height of a tile based on the given tiling
+ * format.
+ */
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret)
 {
switch (tiling) {
case LOCAL_DRM_FORMAT_MOD_NONE:
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4a680ce..414cb3d 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -94,7 +94,8 @@ enum igt_text_align {
align_vcenter   = 0x04,
align_hcenter   = 0x08,
 };
-
+void igt_get_fb_tile_size(int fd, uint64_t tiling, int fb_bpp,
+ unsigned *width_ret, unsigned *height_ret);
 void igt_calc_fb_size(int fd, int width, int height, int bpp, uint64_t tiling,
  unsigned *size_ret, unsigned *stride_ret);
 unsigned int
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Ander Conselvan De Oliveira
On Fri, 2017-04-28 at 12:44 +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> > Sent: Friday, April 28, 2017 2:28 PM
> > To: Chauhan, Madhav ; intel-
> > g...@lists.freedesktop.org
> > Cc: Deepak M ; Nikula, Jani ;
> > Vetter, Daniel ; Jani Nikula
> > ; drm-intel-fi...@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > messages
> > 
> > On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote:
> > > > -Original Message-
> > > > From: Conselvan De Oliveira, Ander
> > > > Sent: Friday, April 28, 2017 1:32 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Conselvan De Oliveira, Ander
> > > > ;
> > > > Deepak M ; Chauhan, Madhav
> > > > ; Nikula, Jani ;
> > > > Vetter, Daniel ; Jani Nikula
> > > > ; drm-intel-fi...@lists.freedesktop.org
> > > > Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > > > messages
> > > > 
> > > > The sequence in glk_dsi_device_ready() enters ULPS then waits until
> > > > it is
> > > > *not* active to then disable it. The correct sequence according to
> > > > the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE
> > > > bit is zero, i.e., ULPS is active, and then disable ULPS.
> > > > 
> > > > Fixing the codition gets rid of the following spurious error messages:
> > > 
> > > Please correct the typo error to "condition", otherwise looks good.
> > > Thanks for catching this.
> > 
> > If you upgrade the above statement to a Reviewed-by, I can fix the typo 
> > while
> > merging?
> > 
> > Ander
> > 
> > > 
> > > > 
> > > > [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> > > > 
> > > > Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable
> > > > sequence")
> > > > Cc: Deepak M 
> > > > Cc: Madhav Chauhan 
> > > > Cc: Jani Nikula 
> > > > Cc: Daniel Vetter 
> > > > Cc: Jani Nikula 
> > > > Cc: intel-gfx@lists.freedesktop.org
> > > > Cc: 
> > > > Signed-off-by: Ander Conselvan de Oliveira
> > > > 
> 
> Reviewed-by: Madhav Chauhan 

Pushed with the typo fixed. Thanks for reviewing.

Ander

> 
> 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> > > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > > index 3ffe8b1..fc0ef49 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > > @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> > > > intel_encoder *encoder)
> > > > val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > > > I915_WRITE(MIPI_DEVICE_READY(port), val);
> > > > 
> > > > -   /* Wait for ULPS Not active */
> > > > +   /* Wait for ULPS active */
> > > > if (intel_wait_for_register(dev_priv,
> > > > -   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > > > -   GLK_ULPS_NOT_ACTIVE, 20))
> > > > -   DRM_ERROR("ULPS is still active\n");
> > > > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> > > > 20))
> > > > +   DRM_ERROR("ULPS not active\n");
> > > > 
> > > > /* Exit ULPS */
> > > > val = I915_READ(MIPI_DEVICE_READY(port));
> > > > --
> > > > 2.9.3
> > > 
> > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3 2/2] drm/i915: Prevent the system suspend complete optimization

2017-04-28 Thread Imre Deak
Since

commit bac2a909a096c9110525c18cbb8ce73c660d5f71
Author: Rafael J. Wysocki 
Date:   Wed Jan 21 02:17:42 2015 +0100

PCI / PM: Avoid resuming PCI devices during system suspend

PCI devices will default to allowing the system suspend complete
optimization where devices are not woken up during system suspend if
they were already runtime suspended. This however breaks the i915/HDA
drivers for two reasons:

- The i915 driver has system suspend specific steps that it needs to
  run, that bring the device to a different state than its runtime
  suspended state.

- The HDA driver's suspend handler requires power that it will request
  from the i915 driver's power domain handler. This in turn requires the
  i915 driver to runtime resume itself, but this won't be possible if the
  suspend complete optimization is in effect: in this case the i915
  runtime PM is disabled and trying to get an RPM reference returns
  -EACCESS.

Solve this by requiring the PCI/PM core to resume the device during
system suspend which in effect disables the suspend complete optimization.

Regardless of the above commit the optimization stayed disabled for DRM
devices until

commit d14d2a8453d650bea32a1c5271af1458cd283a0f
Author: Lukas Wunner 
Date:   Wed Jun 8 12:49:29 2016 +0200

drm: Remove dev_pm_ops from drm_class

so this patch is in practice a fix for this commit. Another reason for
the bug staying hidden for so long is that the optimization for a device
is disabled if it's disabled for any of its children devices. i915 may
have a backlight device as its child which doesn't support runtime PM
and so doesn't allow the optimization either.  So if this backlight
device got registered the bug stayed hidden.

Credits to Marta, Tomi and David who enabled pstore logging,
that caught one instance of this issue across a suspend/
resume-to-ram and Ville who rememberd that the optimization was enabled
for some devices at one point.

The first WARN triggered by the problem:

[ 6250.746445] WARNING: CPU: 2 PID: 17384 at 
drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0 
[i915]
[ 6250.746448] pm_runtime_get_sync() failed: -13
[ 6250.746451] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul
snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e 
snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich mei 
prime_
numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded: 
i915]
[ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U  W   
4.11.0-rc5-CI-CI_DRM_334+ #1
[ 6250.746515] Hardware name:  /NUC5i5RYB, BIOS 
RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
[ 6250.746521] Workqueue: events_unbound async_run_entry_fn
[ 6250.746525] Call Trace:
[ 6250.746530]  dump_stack+0x67/0x92
[ 6250.746536]  __warn+0xc6/0xe0
[ 6250.746542]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746546]  warn_slowpath_fmt+0x46/0x50
[ 6250.746553]  ? __pm_runtime_resume+0x56/0x80
[ 6250.746584]  intel_runtime_pm_get+0x6b/0xd0 [i915]
[ 6250.746610]  intel_display_power_get+0x1b/0x40 [i915]
[ 6250.746646]  i915_audio_component_get_power+0x15/0x20 [i915]
[ 6250.746654]  snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
[ 6250.746661]  azx_runtime_resume+0x218/0x280 [snd_hda_intel]
[ 6250.746667]  pci_pm_runtime_resume+0x76/0xa0
[ 6250.746672]  __rpm_callback+0xb4/0x1f0
[ 6250.746677]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746682]  rpm_callback+0x1f/0x80
[ 6250.746686]  ? pci_restore_standard_config+0x40/0x40
[ 6250.746690]  rpm_resume+0x4ba/0x740
[ 6250.746698]  __pm_runtime_resume+0x49/0x80
[ 6250.746703]  pci_pm_suspend+0x57/0x140
[ 6250.746709]  dpm_run_callback+0x6f/0x330
[ 6250.746713]  ? pci_pm_freeze+0xe0/0xe0
[ 6250.746718]  __device_suspend+0xf9/0x370
[ 6250.746724]  ? dpm_watchdog_set+0x60/0x60
[ 6250.746730]  async_suspend+0x1a/0x90
[ 6250.746735]  async_run_entry_fn+0x34/0x160
[ 6250.746741]  process_one_work+0x1f2/0x6d0
[ 6250.746749]  worker_thread+0x49/0x4a0
[ 6250.746755]  kthread+0x107/0x140
[ 6250.746759]  ? process_one_work+0x6d0/0x6d0
[ 6250.746763]  ? kthread_create_on_node+0x40/0x40
[ 6250.746768]  ret_from_fork+0x2e/0x40
[ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---

v2:
- Use the new pci_dev->needs_resume flag, to avoid any overhead during
  the ->pm_prepare hook. (Rafael)

v3:
- Update commit message to reference the actual regressing commit.
  (Lukas)

Fixes: d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class")
References: https://bugs.freedesktop.org/show_bug.cgi?id=100378
References: https://bugs.freedesktop.org/show_bug.cgi?id=100770
Cc: Rafael J. Wysocki 
Cc: Marta Lofstedt 
Cc: David Weinehall 
Cc: Tomi Sarvela 
Cc: Ville Syrjälä 

[Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

2017-04-28 Thread Imre Deak
Some drivers - like i915 - may not support the system suspend direct
complete optimization due to differences in their runtime and system
suspend sequence. Add a flag that when set resumes the device before
calling the driver's system suspend handlers which effectively disables
the optimization.

Needed by the next patch fixing suspend/resume on i915.

Suggested by Rafael.

Cc: Rafael J. Wysocki 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Imre Deak 
---

[ After discussing with Jani, I'm going to apply this and the next patch
  for now to the intel-gfx specific CI branch to unblock our testing. ]

 drivers/pci/pci.c   | 3 ++-
 include/linux/pci.h | 7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7904d02..020f02d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
 
if (!pm_runtime_suspended(dev)
|| pci_target_state(pci_dev) != pci_dev->current_state
-   || platform_pci_need_resume(pci_dev))
+   || platform_pci_need_resume(pci_dev)
+   || pci_dev->needs_resume)
return false;
 
/*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5948cfd..2f012f8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -316,6 +316,9 @@ struct pci_dev {
unsigned inthotplug_user_indicators:1; /* SlotCtl indicators
  controlled exclusively by
  user sysfs */
+   unsigned intneeds_resume:1; /* Resume before calling the driver's
+  system suspend hooks, disabling the
+  direct_complete optimization. */
unsigned intd3_delay;   /* D3->D0 transition time in ms */
unsigned intd3cold_delay;   /* D3cold->D0 transition time in ms */
 
@@ -1110,6 +1113,10 @@ bool pci_check_pme_status(struct pci_dev *dev);
 void pci_pme_wakeup_bus(struct pci_bus *bus);
 void pci_d3cold_enable(struct pci_dev *dev);
 void pci_d3cold_disable(struct pci_dev *dev);
+static inline void pci_resume_before_suspend(struct pci_dev *dev, bool enable)
+{
+   dev->needs_resume = enable;
+}
 
 static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
  bool enable)
-- 
2.5.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Enable send function only after successful init

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Enable send function only after successful init
URL   : https://patchwork.freedesktop.org/series/23702/
State : success

== Summary ==

Series 23702v1 drm/i915/guc: Enable send function only after successful init
https://patchwork.freedesktop.org/api/1.0/series/23702/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:567s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:556s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:456s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
90051ca drm/i915/guc: Enable send function only after successful init

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4579/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v13] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
Now just needs some ascii art!
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  93 +++-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  38 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 381 +++
 drivers/gpu/drm/i915/i915_syncmap.h|  39 ++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 283 +++
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   2 +
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 539 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 ++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 13 files changed, 1448 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 327645ae7d96..edd4baae892a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3214,6 +3214,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__
 
+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5fa4e52ded06..807fc1b65dd1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -772,6 +772,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;
 
+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 to_request(fence));
@@ -781,6 +786,10 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable send function only after successful init

2017-04-28 Thread Saarinen, Jani
Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: Friday, April 28, 2017 4:50 PM
> To: Wajdeczko, Michal 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable send 
> function
> only after successful init
> 
> == Series Details ==
> 
> Series: drm/i915/guc: Enable send function only after successful init
> URL   : https://patchwork.freedesktop.org/series/23702/
> State : failure
> 
> == Summary ==
> 
> Series 23702v1 drm/i915/guc: Enable send function only after successful init
> https://patchwork.freedesktop.org/api/1.0/series/23702/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gvt_basic:
> Subgroup invalid-placeholder-test:
> skip   -> INCOMPLETE (fi-hsw-4770r)
I guess just need to re-open:
https://bugs.freedesktop.org/show_bug.cgi?id=100256
blah...done, marked for the future.

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable send function only after successful init

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Enable send function only after successful init
URL   : https://patchwork.freedesktop.org/series/23702/
State : failure

== Summary ==

Series 23702v1 drm/i915/guc: Enable send function only after successful init
https://patchwork.freedesktop.org/api/1.0/series/23702/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gvt_basic:
Subgroup invalid-placeholder-test:
skip   -> INCOMPLETE (fi-hsw-4770r)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:569s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:506s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:535s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:15 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:422s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:404s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
f79780b drm/i915/guc: Enable send function only after successful init

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4578/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/guc: Enable send function only after successful init

2017-04-28 Thread Michal Wajdeczko
It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 27 ++-
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 900e376..5957a95 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -99,7 +99,7 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
struct intel_guc *guc = _priv->guc;
 
mutex_init(>send_mutex);
-   guc->send = intel_guc_send_mmio;
+   guc->send = intel_guc_send_nop;
 }
 
 static void fetch_uc_fw(struct drm_i915_private *dev_priv,
@@ -252,13 +252,27 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }
 
+static int guc_enable_communication(struct intel_guc *guc)
+{
+   /* XXX: placeholder for alternate setup */
+   guc->send = intel_guc_send_mmio;
+   return 0;
+}
+
+static void guc_disable_communication(struct intel_guc *guc)
+{
+   guc->send = intel_guc_send_nop;
+}
+
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
+   struct intel_guc *guc = _priv->guc;
int ret, attempts;
 
if (!i915.enable_guc_loading)
return 0;
 
+   guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
 
/* We need to notify the guc whenever we change the GGTT */
@@ -308,6 +322,10 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
 
+   ret = guc_enable_communication(guc);
+   if (ret)
+   goto err_submission;
+
intel_guc_auth_huc(dev_priv);
if (i915.enable_guc_submission) {
if (i915.guc_log_level >= 0)
@@ -330,6 +348,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * marks the GPU as wedged until reset).
 */
 err_interrupts:
+   guc_disable_communication(guc);
gen9_disable_guc_interrupts(dev_priv);
 err_submission:
if (i915.enable_guc_submission)
@@ -364,6 +383,12 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
i915_ggtt_disable_guc(dev_priv);
 }
 
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
+{
+   WARN(1, "Unexpected send: action=%#x\n", *action);
+   return -ENOSYS;
+}
+
 /*
  * This function implements the MMIO based host to GuC interface.
  */
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 2f0229d..1e0eecd 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -227,6 +227,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
 int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
 static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 
len)
 {
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Chauhan, Madhav
> -Original Message-
> From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> Sent: Friday, April 28, 2017 2:28 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Deepak M ; Nikula, Jani ;
> Vetter, Daniel ; Jani Nikula
> ; drm-intel-fi...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> messages
> 
> On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote:
> > > -Original Message-
> > > From: Conselvan De Oliveira, Ander
> > > Sent: Friday, April 28, 2017 1:32 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Conselvan De Oliveira, Ander
> > > ;
> > > Deepak M ; Chauhan, Madhav
> > > ; Nikula, Jani ;
> > > Vetter, Daniel ; Jani Nikula
> > > ; drm-intel-fi...@lists.freedesktop.org
> > > Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > > messages
> > >
> > > The sequence in glk_dsi_device_ready() enters ULPS then waits until
> > > it is
> > > *not* active to then disable it. The correct sequence according to
> > > the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE
> > > bit is zero, i.e., ULPS is active, and then disable ULPS.
> > >
> > > Fixing the codition gets rid of the following spurious error messages:
> >
> > Please correct the typo error to "condition", otherwise looks good.
> > Thanks for catching this.
> 
> If you upgrade the above statement to a Reviewed-by, I can fix the typo while
> merging?
> 
> Ander
> 
> >
> > >
> > > [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> > >
> > > Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable
> > > sequence")
> > > Cc: Deepak M 
> > > Cc: Madhav Chauhan 
> > > Cc: Jani Nikula 
> > > Cc: Daniel Vetter 
> > > Cc: Jani Nikula 
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: 
> > > Signed-off-by: Ander Conselvan de Oliveira
> > > 

Reviewed-by: Madhav Chauhan 


> > > ---
> > >  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > index 3ffe8b1..fc0ef49 100644
> > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> > > intel_encoder *encoder)
> > >   val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > >   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > >
> > > - /* Wait for ULPS Not active */
> > > + /* Wait for ULPS active */
> > >   if (intel_wait_for_register(dev_priv,
> > > - MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > > - GLK_ULPS_NOT_ACTIVE, 20))
> > > - DRM_ERROR("ULPS is still active\n");
> > > + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> > > 20))
> > > + DRM_ERROR("ULPS not active\n");
> > >
> > >   /* Exit ULPS */
> > >   val = I915_READ(MIPI_DEVICE_READY(port));
> > > --
> > > 2.9.3
> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 01:02:25PM +0100, Tvrtko Ursulin wrote:
> 
> On 27/04/2017 15:37, Chris Wilson wrote:
> >On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote:
> >>>static void record_context(struct drm_i915_error_context *e,
> >>>diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >>>b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>index 1642fff9cf13..370373c97b81 100644
> >>>--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>@@ -658,7 +658,7 @@ static void nested_enable_signaling(struct 
> >>>drm_i915_gem_request *rq)
> >>>static bool i915_guc_dequeue(struct intel_engine_cs *engine)
> >>>{
> >>>   struct execlist_port *port = engine->execlist_port;
> >>>-  struct drm_i915_gem_request *last = port[0].request;
> >>>+  struct drm_i915_gem_request *last = port[0].request_count;
> >>
> >>It's confusing that in this new scheme sometimes we have direct
> >>access to the request and sometimes we have to go through the
> >>port_request macro.
> >>
> >>So maybe we should always use the port_request macro. Hm, could we
> >>invent a new type to help enforce that? Like:
> >>
> >>struct drm_i915_gem_port_request_slot {
> >>struct drm_i915_gem_request *req_count;
> >>};
> >>
> >>And then execlist port would contain these and helpers would need to
> >>be functions?
> >>
> >>I've also noticed some GVT/GuC patches which sounded like they are
> >>adding the same single submission constraints so maybe now is the
> >>time to unify the dequeue? (Haven't looked at those patches deeper
> >>than the subject line so might be wrong.)
> >>
> >>Not sure 100% of all the above, would need to sketch it. What are
> >>your thoughts?
> >
> >I forsee a use for the count in guc as well, so conversion is ok with
> >me.
> 
> Conversion to a wrapper structure as I proposed or keeping it as you
> have it?
> 
> >>>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> >>>b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >>>index d25b88467e5e..39b733e5cfd3 100644
> >>>--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >>>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >>>@@ -377,8 +377,12 @@ struct intel_engine_cs {
> >>>   /* Execlists */
> >>>   struct tasklet_struct irq_tasklet;
> >>>   struct execlist_port {
> >>>-  struct drm_i915_gem_request *request;
> >>>-  unsigned int count;
> >>>+  struct drm_i915_gem_request *request_count;
> >>
> >>Would req(uest)_slot maybe be better?
> >
> >It's definitely a count (of how many times this request has been
> >submitted), and I like long verbose names when I don't want them to be
> >used directly. So expect guc to be tidied.
> 
> It is a pointer and a count. My point was that request_count sounds
> too much like a count of how many times has something been done or
> happened to the request.
> 
> Request_slot was my attempt to make it obvious in the name itself
> there is more to it. And the wrapper struct was another step
> further, plus the idea was it would make sure you always need to
> access this field via the accessor. Since I think going sometimes
> directly and sometimes via wrapper is too fragile.

I read slot as port[slot], whereas I am using as a count of how many
times I have done something with this request/context.

> Anyway, my big issue is I am not sure if we are in agreement or not.
> Do you agree going with the wrapper structure makes sense or not?

I'm using port_request() in guc, see the version in #prescheduler.

What I haven't come up with is a good plan for assignment, which
is still using port->request_count = port_pack() but now that is limited
to just the port_assign() functions.
-Chris

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


Re: [Intel-gfx] [PATCH 16/27] drm/i915: Reinstate reservation_object zapping for batch_pool objects

2017-04-28 Thread Tvrtko Ursulin


On 19/04/2017 10:41, Chris Wilson wrote:

I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across many timelines.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 41aa598c4f3b..414e46e2f072 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -114,12 +114,26 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
list_for_each_entry(obj, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (i915_gem_object_is_active(obj)) {
-   if (!reservation_object_test_signaled_rcu(obj->resv,
- true))
+   struct reservation_object *resv = obj->resv;
+
+   if (!reservation_object_test_signaled_rcu(resv, true))
break;

i915_gem_retire_requests(pool->engine->i915);
GEM_BUG_ON(i915_gem_object_is_active(obj));
+
+   /* The object is now idle, clear the array of shared
+* fences before we add a new request. Although, we
+* remain on the same engine, we may be on a different
+* timeline and so may continually grow the array,
+* trapping a reference to all the old fences, rather
+* than replace the existing fence.
+*/
+   if (rcu_access_pointer(resv->fence)) {
+   reservation_object_lock(resv, NULL);
+   reservation_object_add_excl_fence(resv, NULL);
+   reservation_object_unlock(resv);
+   }
}

GEM_BUG_ON(!reservation_object_test_signaled_rcu(obj->resv,



Not too familiar with the reservation object stuff but having read some 
kerneldoc it looks correct to me.


Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

2017-04-28 Thread Tvrtko Ursulin


On 27/04/2017 15:37, Chris Wilson wrote:

On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote:

static void record_context(struct drm_i915_error_context *e,
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1642fff9cf13..370373c97b81 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -658,7 +658,7 @@ static void nested_enable_signaling(struct 
drm_i915_gem_request *rq)
static bool i915_guc_dequeue(struct intel_engine_cs *engine)
{
struct execlist_port *port = engine->execlist_port;
-   struct drm_i915_gem_request *last = port[0].request;
+   struct drm_i915_gem_request *last = port[0].request_count;


It's confusing that in this new scheme sometimes we have direct
access to the request and sometimes we have to go through the
port_request macro.

So maybe we should always use the port_request macro. Hm, could we
invent a new type to help enforce that? Like:

struct drm_i915_gem_port_request_slot {
struct drm_i915_gem_request *req_count;
};

And then execlist port would contain these and helpers would need to
be functions?

I've also noticed some GVT/GuC patches which sounded like they are
adding the same single submission constraints so maybe now is the
time to unify the dequeue? (Haven't looked at those patches deeper
than the subject line so might be wrong.)

Not sure 100% of all the above, would need to sketch it. What are
your thoughts?


I forsee a use for the count in guc as well, so conversion is ok with
me.


Conversion to a wrapper structure as I proposed or keeping it as you 
have it?



diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d25b88467e5e..39b733e5cfd3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -377,8 +377,12 @@ struct intel_engine_cs {
/* Execlists */
struct tasklet_struct irq_tasklet;
struct execlist_port {
-   struct drm_i915_gem_request *request;
-   unsigned int count;
+   struct drm_i915_gem_request *request_count;


Would req(uest)_slot maybe be better?


It's definitely a count (of how many times this request has been
submitted), and I like long verbose names when I don't want them to be
used directly. So expect guc to be tidied.


It is a pointer and a count. My point was that request_count sounds too 
much like a count of how many times has something been done or happened 
to the request.


Request_slot was my attempt to make it obvious in the name itself there 
is more to it. And the wrapper struct was another step further, plus the 
idea was it would make sure you always need to access this field via the 
accessor. Since I think going sometimes directly and sometimes via 
wrapper is too fragile.


Anyway, my big issue is I am not sure if we are in agreement or not. Do 
you agree going with the wrapper structure makes sense or not?


Regards,

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


Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Read link status after exit link training

2017-04-28 Thread Tvrtko Ursulin


On 28/04/2017 10:58, Lee, Shawn C wrote:

From: "Lee, Shawn C" 

Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source
read these registers at the same time. Panel will report EQ & symbol
lock not done. It will cause panel display flicking.
So driver have to make sure PSR already exit before read link status.

Change log:
v2:
- Use intel_wait_for_register() to replace I915_READ().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99639
TEST=Reboot DUT and no flicking on local display at login screen

Cc: Cooper Chiou 
Cc: Gary C Wang 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jim Bride 
Cc: Ryan Lin 

Signed-off-by: Shawn Lee 
---
 drivers/gpu/drm/i915/intel_dp.c |   33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f74d396..099b6c0605a7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4252,19 +4252,34 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
 }

 static void
+intel_edp_wait_PSR_exit(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;


... dev_priv = to_i915(dev);


+   u16 count = 100;
+
+   while (count--)
+   if (!intel_wait_for_register(dev_priv,
+   EDP_PSR_STATUS_CTL,
+   (EDP_PSR_STATUS_SENDING_TP1 |
+EDP_PSR_STATUS_SENDING_TP2_TP3 |
+EDP_PSR_STATUS_SENDING_IDLE |
+EDP_PSR_STATUS_AUX_SENDING),
+0,
+1))
+   return;
+}


You don't need your own retry loop - intel_wait_for_register will do 
that for you. But it will only check every millisecond, if the inital 
busy wait for 2us wasn't successful.


I've  noticed that your initial patch had a 10ms timeout with a 100us 
period. If you had a good reason for that, then with this conversion you 
only have a 1ms timeout with a 1ms period, so if you need a shorter 
period, this solution is not ideal for you.


I've complicated the explanation a bit - but a bottom line is, v1 and v2 
are a lot different. Depending on the typical response time one of the 
two will have a much worse latency.



+
+static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;


to_i915 also.


u8 link_status[DP_LINK_STATUS_SIZE];

WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));

-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
-   return;
-   }
-
if (!intel_encoder->base.crtc)
return;

@@ -4278,6 +4293,14 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!intel_dp_link_params_valid(intel_dp))
return;

+   if (is_edp(intel_dp) && dev_priv->psr.enabled)
+   intel_edp_wait_PSR_exit(intel_dp);
+
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   DRM_ERROR("Failed to get link status\n");
+   return;
+   }
+
/* Retrain if Channel EQ or CR not ok */
if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",



Regards,

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: dma-buf support for GVT-g

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: dma-buf support for GVT-g
URL   : https://patchwork.freedesktop.org/series/23686/
State : success

== Summary ==

Series 23686v1 drm/i915/gvt: dma-buf support for GVT-g
https://patchwork.freedesktop.org/api/1.0/series/23686/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-snb-2600) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:577s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:537s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:447s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:567s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:406s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
df8b8b9 drm/i915/gvt: support QEMU getting the dmabuf
9b5ff91 drm/i915/gvt: dmabuf support for GVT-g
1a54a75 drm/i915: export i915 dmabuf_ops
3c2166c drm/i915/gvt: framebuffer decoder support for GVT-g
9daf315 drm/i915/gvt: OpRegion support for GVT-g
c62fb8f drm/i915/gvt: extend the GVT-g architecture to support vfio device 
region

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4577/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Read link status after exit PSR (rev2)

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915/edp: Read link status after exit PSR (rev2)
URL   : https://patchwork.freedesktop.org/series/23631/
State : success

== Summary ==

Series 23631v2 drm/i915/edp: Read link status after exit PSR
https://patchwork.freedesktop.org/api/1.0/series/23631/revisions/2/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:555s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:401s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:463s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:661s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:414s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
4d009e1 drm/i915/edp: Read link status after exit link training

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4576/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

2017-04-28 Thread Ville Syrjälä
On Fri, Apr 28, 2017 at 03:08:53AM +, Lee, Shawn C wrote:
> 
> 
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
> Sent: Thursday, April 27, 2017 10:39 PM
> To: Lee, Shawn C 
> Cc: intel-gfx@lists.freedesktop.org; Chiou, Cooper ; 
> Bride, Jim ; Nikula, Jani ; Vivi, 
> Rodrigo ; Lin, Ryan 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR
> 
> On Thu, Apr 27, 2017 at 10:35:22PM +0800, Lee, Shawn C wrote:
> > From: "Lee, Shawn C" 
> > 
> > Display driver read DPCD register 0x202, 0x203 and 0x204 to identify 
> > eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source 
> > read these registers at the same time. Panel will report EQ & symbol 
> > lock not done. It will cause panel display flicking.
> > So driver have to make sure PSR already exit before read link status.
> 
> And what exactly guarantees that it will exit PSR eventually?
> 
> When read DPCD link status register, eDP can't at link train stage (after PSR 
> exit). 

There seem to be some important word(s) missing from that sentence.
As is I don't really know what you're trying to say here.

> TCON report EQ not done then will cause link re-training and display flicker. 
> So we read SRD_STATUS to make sure source did not send TP1, TP2, TP3 or idle
> pattern to sink side for link training.

That doesn't answer my question.

> 
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99639
> > TEST=Reboot DUT and no flicking on local display at login screen
> > 
> > Cc: Cooper Chiou 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Cc: Jim Bride 
> > Cc: Ryan Lin 
> > 
> > Signed-off-by: Shawn Lee 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |   34 +-
> >  1 file changed, 29 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c index 08834f74d396..cc431337b2dc 
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4252,19 +4252,35 @@ static void 
> > intel_dp_handle_test_request(struct intel_dp *intel_dp)  }
> >  
> >  static void
> > +intel_edp_wait_PSR_exit(struct intel_dp *intel_dp) {
> > +   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   u32 srd_status, count = 100;
> > +
> > +   while (count--) {
> > +   srd_status = I915_READ(EDP_PSR_STATUS_CTL);
> > +
> > +   if ((srd_status & EDP_PSR_STATUS_SENDING_TP1) ||
> > +   (srd_status & EDP_PSR_STATUS_SENDING_TP2_TP3) ||
> > +   (srd_status & EDP_PSR_STATUS_SENDING_IDLE) ||
> > +   (srd_status & EDP_PSR_STATUS_AUX_SENDING)) {
> > +   usleep_range(100, 150);
> > +   } else
> > +   return;
> > +   }
> > +}
> > +
> > +static void
> >  intel_dp_check_link_status(struct intel_dp *intel_dp)  {
> > struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
> > struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > u8 link_status[DP_LINK_STATUS_SIZE];
> >  
> > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> >  
> > -   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > -   DRM_ERROR("Failed to get link status\n");
> > -   return;
> > -   }
> > -
> > if (!intel_encoder->base.crtc)
> > return;
> >  
> > @@ -4278,6 +4294,14 @@ static void intel_dp_handle_test_request(struct 
> > intel_dp *intel_dp)
> > if (!intel_dp_link_params_valid(intel_dp))
> > return;
> >  
> > +   if (is_edp(intel_dp) && dev_priv->psr.enabled)
> > +   intel_edp_wait_PSR_exit(intel_dp);
> > +
> > +   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > +   DRM_ERROR("Failed to get link status\n");
> > +   return;
> > +   }
> > +
> > /* Retrain if Channel EQ or CR not ok */
> > if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> > DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> > --
> > 1.7.9.5
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel OTC

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages
URL   : https://patchwork.freedesktop.org/series/23680/
State : success

== Summary ==

Series 23680v1 drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages
https://patchwork.freedesktop.org/api/1.0/series/23680/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-byt-j1900) fdo#100652

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100652 https://bugs.freedesktop.org/show_bug.cgi?id=100652

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:542s
fi-byt-j1900 total:278  pass:253  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:569s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:456s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:400s

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
b7f9ab5 drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4575/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

2017-04-28 Thread Patchwork
== Series Details ==

Series: drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
URL   : https://patchwork.freedesktop.org/series/23679/
State : success

== Summary ==

Series 23679v1 drm/i915: Do not leak dev_priv->l3_parity.remap_info[]
https://patchwork.freedesktop.org/api/1.0/series/23679/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:428s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:517s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:558s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:401s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:574s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:407s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_4574/fi-bdw-gvtdvm/igt.log

86cc4197d2fa4c45b75bf54026765d27d86b84c8 drm-tip: 2017y-04m-28d-09h-14m-47s UTC 
integration manifest
38aca2b drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4574/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 10:55:09AM +0100, Tvrtko Ursulin wrote:
> 
> On 28/04/2017 08:41, Chris Wilson wrote:
> 
> [snip]
> 
> >+static int igt_sync(void *arg)
> >+{
> >+const struct {
> >+const char *name;
> >+u32 seqno;
> >+bool expected;
> >+bool set;
> >+} pass[] = {
> >+{ "unset", 0, false, false },
> >+{ "new", 0, false, true },
> >+{ "0a", 0, true, true },
> >+{ "1a", 1, false, true },
> >+{ "1b", 1, true, true },
> >+{ "0b", 0, true, false },
> >+{ "2a", 2, false, true },
> >+{ "4", 4, false, true },
> >+{ "INT_MAX", INT_MAX, false, true },
> >+{ "INT_MAX-1", INT_MAX-1, true, false },
> >+{ "INT_MAX+1", (u32)INT_MAX+1, false, true },
> >+{ "INT_MAX", INT_MAX, true, false },
> >+{ "UINT_MAX", UINT_MAX, false, true },
> >+{ "wrap", 0, false, true },
> >+{ "unwrap", UINT_MAX, true, false },
> >+{},
> >+}, *p;
> >+struct intel_timeline *tl;
> >+int order, offset;
> >+int ret;
> >+
> >+tl = mock_timeline(0);
> >+if (!tl)
> >+return -ENOMEM;
> >+
> >+for (p = pass; p->name; p++) {
> >+for (order = 1; order < 64; order++) {
> >+for (offset = -1; offset <= (order > 1); offset++) {
> >+u64 ctx = BIT_ULL(order) + offset;
> >+
> >+if (__intel_timeline_sync_is_later
> >+(tl, ctx, p->seqno) != p->expected) {
> >+pr_err("1: %s(ctx=%llu, seqno=%u) 
> >expected passed %s but failed\n",
> >+   p->name, ctx, p->seqno, 
> >yesno(p->expected));
> >+ret = -EINVAL;
> >+goto out;
> >+}
> >+
> >+if (p->set) {
> >+ret = __intel_timeline_sync_set(tl, 
> >ctx, p->seqno);
> >+if (ret)
> >+goto out;
> >+}
> >+}
> >+}
> >+}
> 
> I think verification that the tree height matches the expectation,
> and also total number of nodes, is required.

That sounds a good excuse to start selftests/i915_syncmap

My primary goal here is to exercise the simpler intel_timeline_sync
interface, i.e. this portion should be agnostic to the implementation.
-Chris

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


Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 05:35:29PM +0800, Xiaoguang Chen wrote:
> dmabuf for GVT-g can be exported to users who can use the dmabuf to show
> the desktop of vm which use intel vgpu.
> 
> Currently we provide query and create new dmabuf operations.
> 
> Users of dmabuf can cache some created dmabufs and related information such
> as the framebuffer's address, size, tiling mode, width, height etc. When
> refresh the screen first query the currnet vgpu's frambuffer and compare
> with the cached ones(address, size, tiling, width, height etc) if found one
> then reuse the found dmabuf to gain performance improvment.
> 
> If there is no dmabuf created yet or not found in the cached dmabufs then
> need to create a new dmabuf. To create a dmabuf first a gem object will
> be created and the backing storage of this gem object is the vgpu's
> framebuffer(primary/cursor). Then associate this gem object to a dmabuf
> and export this dmabuf. A file descriptor will be generated for this dmabuf
> and this file descriptor can be sent to user space to do display.
> 
> Signed-off-by: Xiaoguang Chen 
> ---
>  drivers/gpu/drm/i915/gvt/Makefile |   2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.c | 268 
> ++
>  drivers/gpu/drm/i915/gvt/dmabuf.h |  50 +++
>  drivers/gpu/drm/i915/gvt/gvt.h|   1 +
>  4 files changed, 320 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
> 
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> index 192ca26..e480f7d 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -2,7 +2,7 @@ GVT_DIR := gvt
>  GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o 
> firmware.o \
>   interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
> - fb_decoder.o
> + fb_decoder.o dmabuf.o
>  
>  ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) -Wall
>  i915-y   += $(addprefix $(GVT_DIR)/, 
> $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> new file mode 100644
> index 000..d776dfa
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -0,0 +1,268 @@
> +/*
> + * Copyright 2017 Intel Corporation. All rights reserved.
> + *
> + * 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:
> + *Zhiyuan Lv 
> + *
> + * Contributors:
> + *Xiaoguang Chen 
> + */
> +
> +#include 
> +#include 
> +
> +#include "i915_drv.h"
> +#include "gvt.h"
> +
> +static struct sg_table *intel_vgpu_gem_get_pages(
> + struct drm_i915_gem_object *obj)
> +{
> + WARN_ON(1);
> + return NULL;
> +}
> +
> +static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
> + struct sg_table *pages)
> +{
> + /* like stolen memory, this should only be called during free
> +  * after clearing pin count.
> +  */

Time to re-read how stolen works (see get_pages and pinning on
creation).

> + sg_free_table(pages);
> + kfree(pages);
> +}
> +
> +static const struct drm_i915_gem_object_ops intel_vgpu_gem_ops = {
> + .get_pages = intel_vgpu_gem_get_pages,
> + .put_pages = intel_vgpu_gem_put_pages,
> +};
> +
> +#define GEN8_DECODE_PTE(pte) \
> + ((dma_addr_t)(u64)pte) >> 12) & 0x7ffULL) << 12))
> +
> +#define GEN7_DECODE_PTE(pte) \
> + ((dma_addr_t)(u64)pte) & 0x7f0) << 28) | (u64)(pte & 0xf000)))
> +
> +static struct sg_table *
> +intel_vgpu_create_sg_pages(struct drm_device *dev, u32 start, u32 num_pages)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Tvrtko Ursulin


On 28/04/2017 08:41, Chris Wilson wrote:

[snip]


+static int igt_sync(void *arg)
+{
+   const struct {
+   const char *name;
+   u32 seqno;
+   bool expected;
+   bool set;
+   } pass[] = {
+   { "unset", 0, false, false },
+   { "new", 0, false, true },
+   { "0a", 0, true, true },
+   { "1a", 1, false, true },
+   { "1b", 1, true, true },
+   { "0b", 0, true, false },
+   { "2a", 2, false, true },
+   { "4", 4, false, true },
+   { "INT_MAX", INT_MAX, false, true },
+   { "INT_MAX-1", INT_MAX-1, true, false },
+   { "INT_MAX+1", (u32)INT_MAX+1, false, true },
+   { "INT_MAX", INT_MAX, true, false },
+   { "UINT_MAX", UINT_MAX, false, true },
+   { "wrap", 0, false, true },
+   { "unwrap", UINT_MAX, true, false },
+   {},
+   }, *p;
+   struct intel_timeline *tl;
+   int order, offset;
+   int ret;
+
+   tl = mock_timeline(0);
+   if (!tl)
+   return -ENOMEM;
+
+   for (p = pass; p->name; p++) {
+   for (order = 1; order < 64; order++) {
+   for (offset = -1; offset <= (order > 1); offset++) {
+   u64 ctx = BIT_ULL(order) + offset;
+
+   if (__intel_timeline_sync_is_later
+   (tl, ctx, p->seqno) != p->expected) {
+   pr_err("1: %s(ctx=%llu, seqno=%u) expected 
passed %s but failed\n",
+  p->name, ctx, p->seqno, 
yesno(p->expected));
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (p->set) {
+   ret = __intel_timeline_sync_set(tl, ctx, 
p->seqno);
+   if (ret)
+   goto out;
+   }
+   }
+   }
+   }


I think verification that the tree height matches the expectation, and 
also total number of nodes, is required.


If too complicated in the current structure you could add a simpler 
iteration over another table of steps, which would include the ctx id 
and seqno in it, and expected height/total nodes after each step.


Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 10:32:58AM +0100, Tvrtko Ursulin wrote:
> 
> On 28/04/2017 08:41, Chris Wilson wrote:
> >Track the latest fence waited upon on each context, and only add a new
> >asynchronous wait if the new fence is more recent than the recorded
> >fence for that context. This requires us to filter out unordered
> >timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
> >absence of a universal identifier, we have to use our own
> >i915->mm.unordered_timeline token.
> >
> >v2: Throw around the debug crutches
> >v3: Inline the likely case of the pre-allocation cache being full.
> >v4: Drop the pre-allocation support, we can lose the most recent fence
> >in case of allocation failure -- it just means we may emit more awaits
> >than strictly necessary but will not break.
> >v5: Trim allocation size for leaf nodes, they only need an array of u32
> >not pointers.
> >v6: Create mock_timeline to tidy selftest writing
> >v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
> >v8: Prune the stale sync points when we idle.
> >v9: Include a small benchmark in the kselftests
> >v10: Separate the idr implementation into its own compartment.
> 
> FYI I am reading v11 and commenting here. Hopefully it works out. :)
> 
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Joonas Lahtinen 
> >---
> > drivers/gpu/drm/i915/Makefile  |   1 +
> > drivers/gpu/drm/i915/i915_gem.c|   1 +
> > drivers/gpu/drm/i915/i915_gem.h|   2 +
> > drivers/gpu/drm/i915/i915_gem_request.c|   9 +
> > drivers/gpu/drm/i915/i915_gem_timeline.c   |  92 +-
> > drivers/gpu/drm/i915/i915_gem_timeline.h   |  36 ++
> > drivers/gpu/drm/i915/i915_syncmap.c| 362 
> > +
> > drivers/gpu/drm/i915/i915_syncmap.h|  39 +++
> > drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 257 +++
> > .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
> > drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 +++
> > drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
> > 12 files changed, 860 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
> > create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
> > create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> > create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
> > create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h
> >
> >diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> >index 2cf04504e494..7b05fb802f4c 100644
> >--- a/drivers/gpu/drm/i915/Makefile
> >+++ b/drivers/gpu/drm/i915/Makefile
> >@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
> >   i915_params.o \
> >   i915_pci.o \
> >   i915_suspend.o \
> >+  i915_syncmap.o \
> >   i915_sw_fence.o \
> >   i915_sysfs.o \
> >   intel_csr.o \
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index c1fa3c103f38..f886ef492036 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3214,6 +3214,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > intel_engine_disarm_breadcrumbs(engine);
> > i915_gem_batch_pool_fini(>batch_pool);
> > }
> >+i915_gem_timelines_mark_idle(dev_priv);
> >
> > GEM_BUG_ON(!dev_priv->gt.awake);
> > dev_priv->gt.awake = false;
> >diff --git a/drivers/gpu/drm/i915/i915_gem.h 
> >b/drivers/gpu/drm/i915/i915_gem.h
> >index 5a49487368ca..ee54597465b6 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.h
> >+++ b/drivers/gpu/drm/i915/i915_gem.h
> >@@ -25,6 +25,8 @@
> > #ifndef __I915_GEM_H__
> > #define __I915_GEM_H__
> >
> >+#include 
> >+
> > #ifdef CONFIG_DRM_I915_DEBUG_GEM
> > #define GEM_BUG_ON(expr) BUG_ON(expr)
> > #define GEM_WARN_ON(expr) WARN_ON(expr)
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 5fa4e52ded06..807fc1b65dd1 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -772,6 +772,11 @@ i915_gem_request_await_dma_fence(struct 
> >drm_i915_gem_request *req,
> > if (fence->context == req->fence.context)
> > continue;
> >
> >+/* Squash repeated waits to the same timelines */
> >+if (fence->context != req->i915->mm.unordered_timeline &&
> >+intel_timeline_sync_is_later(req->timeline, fence))
> >+continue;
> >+
> > if (dma_fence_is_i915(fence))
> > ret = i915_gem_request_await_request(req,
> >  to_request(fence));
> >@@ -781,6 +786,10 @@ i915_gem_request_await_dma_fence(struct 
> 

[Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

2017-04-28 Thread Xiaoguang Chen
GVT-g will create an anonymous fd and a vfio device region to deliver
the fd to QEMU.
QEMU can do ioctl using this fd to query/generate dmabuf on an intel vgpu.

Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/gvt/gvt.c   |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h   |   2 +
 drivers/gpu/drm/i915/gvt/kvmgt.c | 109 +++
 include/uapi/linux/vfio.h|   1 +
 4 files changed, 114 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 7dea5e5..c266d31 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,6 +54,8 @@
.vgpu_reset = intel_gvt_reset_vgpu,
.vgpu_activate = intel_gvt_activate_vgpu,
.vgpu_deactivate = intel_gvt_deactivate_vgpu,
+   .vgpu_query_dmabuf = intel_vgpu_query_dmabuf,
+   .vgpu_generate_dmabuf = intel_vgpu_generate_dmabuf,
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 763a8c5..2733a69 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -467,6 +467,8 @@ struct intel_gvt_ops {
void (*vgpu_reset)(struct intel_vgpu *);
void (*vgpu_activate)(struct intel_vgpu *);
void (*vgpu_deactivate)(struct intel_vgpu *);
+   int (*vgpu_query_dmabuf)(struct intel_vgpu *, void *);
+   int (*vgpu_generate_dmabuf)(struct intel_vgpu *, void *);
 };
 
 
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 389f072..beb5356 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "gvt.h"
@@ -524,6 +525,106 @@ static int intel_vgpu_reg_init_opregion(struct intel_vgpu 
*vgpu)
return ret;
 }
 
+static int intel_vgpu_gvtg_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   WARN_ON(1);
+
+   return 0;
+}
+
+static int intel_vgpu_gvtg_release(struct inode *inode, struct file *filp)
+{
+   return 0;
+}
+
+static long intel_vgpu_gvtg_ioctl(struct file *filp,
+   unsigned int ioctl, unsigned long arg)
+{
+   struct intel_vgpu *vgpu = filp->private_data;
+   int minsz;
+   struct intel_vgpu_dmabuf dmabuf;
+   int ret;
+
+   minsz = offsetofend(struct intel_vgpu_dmabuf, y_pos);
+   if (copy_from_user(, (void __user *)arg, minsz))
+   return -EFAULT;
+   if (ioctl == INTEL_VGPU_QUERY_DMABUF)
+   ret = intel_gvt_ops->vgpu_query_dmabuf(vgpu, );
+   else if (ioctl == INTEL_VGPU_GENERATE_DMABUF)
+   ret = intel_gvt_ops->vgpu_generate_dmabuf(vgpu, );
+   else {
+   gvt_vgpu_err("unsupported dmabuf operation\n");
+   return -EINVAL;
+   }
+
+   if (ret != 0) {
+   gvt_vgpu_err("gvt-g get dmabuf failed:%d\n", ret);
+   return -EINVAL;
+   }
+
+   return copy_to_user((void __user *)arg, , minsz) ? -EFAULT : 0;
+}
+
+static const struct file_operations intel_vgpu_gvtg_ops = {
+   .release= intel_vgpu_gvtg_release,
+   .unlocked_ioctl = intel_vgpu_gvtg_ioctl,
+   .mmap   = intel_vgpu_gvtg_mmap,
+   .llseek = noop_llseek,
+};
+
+static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char *buf,
+   size_t count, loff_t *ppos, bool iswrite)
+{
+   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+   VFIO_PCI_NUM_REGIONS;
+   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+   int fd;
+
+   if (pos >= vgpu->vdev.region[i].size || iswrite) {
+   gvt_vgpu_err("invalid op or offset for Intel vgpu fd region\n");
+   return -EINVAL;
+   }
+
+   fd = anon_inode_getfd("gvtg", _vgpu_gvtg_ops, vgpu,
+   O_RDWR | O_CLOEXEC);
+   if (fd < 0) {
+   gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
+   return -EINVAL;
+   }
+
+   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+   memcpy(buf, , count);
+
+   return count;
+}
+
+static void intel_vgpu_reg_release_gvtg(struct intel_vgpu *vgpu,
+   struct vfio_region *region)
+{
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_gvtg = {
+   .rw = intel_vgpu_reg_rw_gvtg,
+   .release = intel_vgpu_reg_release_gvtg,
+};
+
+static int intel_vgpu_reg_init_gvtg(struct intel_vgpu *vgpu)
+{
+   int ret;
+
+   ret = intel_vgpu_register_reg(vgpu,
+   PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+   VFIO_REGION_SUBTYPE_INTEL_IGD_GVTG,
+   _vgpu_regops_gvtg, sizeof(int),
+   VFIO_REGION_INFO_FLAG_READ, NULL);
+   if (ret) {
+   gvt_vgpu_err("failed to register gvtg region:%d\n", ret);
+   return ret;
+   }
+
+   return ret;
+}
+
 static int intel_vgpu_create(struct 

[Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

2017-04-28 Thread Xiaoguang Chen
dmabuf for GVT-g can be exported to users who can use the dmabuf to show
the desktop of vm which use intel vgpu.

Currently we provide query and create new dmabuf operations.

Users of dmabuf can cache some created dmabufs and related information such
as the framebuffer's address, size, tiling mode, width, height etc. When
refresh the screen first query the currnet vgpu's frambuffer and compare
with the cached ones(address, size, tiling, width, height etc) if found one
then reuse the found dmabuf to gain performance improvment.

If there is no dmabuf created yet or not found in the cached dmabufs then
need to create a new dmabuf. To create a dmabuf first a gem object will
be created and the backing storage of this gem object is the vgpu's
framebuffer(primary/cursor). Then associate this gem object to a dmabuf
and export this dmabuf. A file descriptor will be generated for this dmabuf
and this file descriptor can be sent to user space to do display.

Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/gvt/Makefile |   2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c | 268 ++
 drivers/gpu/drm/i915/gvt/dmabuf.h |  50 +++
 drivers/gpu/drm/i915/gvt/gvt.h|   1 +
 4 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index 192ca26..e480f7d 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -2,7 +2,7 @@ GVT_DIR := gvt
 GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
-   fb_decoder.o
+   fb_decoder.o dmabuf.o
 
 ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR) -Wall
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
b/drivers/gpu/drm/i915/gvt/dmabuf.c
new file mode 100644
index 000..d776dfa
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -0,0 +1,268 @@
+/*
+ * Copyright 2017 Intel Corporation. All rights reserved.
+ *
+ * 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:
+ *Zhiyuan Lv 
+ *
+ * Contributors:
+ *Xiaoguang Chen 
+ */
+
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "gvt.h"
+
+static struct sg_table *intel_vgpu_gem_get_pages(
+   struct drm_i915_gem_object *obj)
+{
+   WARN_ON(1);
+   return NULL;
+}
+
+static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
+   struct sg_table *pages)
+{
+   /* like stolen memory, this should only be called during free
+* after clearing pin count.
+*/
+   sg_free_table(pages);
+   kfree(pages);
+}
+
+static const struct drm_i915_gem_object_ops intel_vgpu_gem_ops = {
+   .get_pages = intel_vgpu_gem_get_pages,
+   .put_pages = intel_vgpu_gem_put_pages,
+};
+
+#define GEN8_DECODE_PTE(pte) \
+   ((dma_addr_t)(u64)pte) >> 12) & 0x7ffULL) << 12))
+
+#define GEN7_DECODE_PTE(pte) \
+   ((dma_addr_t)(u64)pte) & 0x7f0) << 28) | (u64)(pte & 0xf000)))
+
+static struct sg_table *
+intel_vgpu_create_sg_pages(struct drm_device *dev, u32 start, u32 num_pages)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct sg_table *st;
+   struct scatterlist *sg;
+   int i;
+   gen8_pte_t __iomem *gtt_entries;
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (st == NULL)
+   return NULL;
+
+   if (sg_alloc_table(st, num_pages, GFP_KERNEL)) {
+   kfree(st);
+   return NULL;
+   }
+
+ 

[Intel-gfx] [RFC PATCH 1/6] drm/i915/gvt: extend the GVT-g architecture to support vfio device region

2017-04-28 Thread Xiaoguang Chen
Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ae0b40..3c6a02b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,11 +53,21 @@
 #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
 #define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
 
+struct vfio_region;
+struct intel_vgpu_regops {
+   size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
+   size_t count, loff_t *ppos, bool iswrite);
+   void (*release)(struct intel_vgpu *vgpu,
+   struct vfio_region *region);
+};
+
 struct vfio_region {
u32 type;
u32 subtype;
size_t  size;
u32 flags;
+   const struct intel_vgpu_regops  *ops;
+   void*data;
 };
 
 struct kvmgt_pgfn {
@@ -642,7 +652,7 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, char 
*buf,
int ret = -EINVAL;
 
 
-   if (index >= VFIO_PCI_NUM_REGIONS) {
+   if (index >= VFIO_PCI_NUM_REGIONS + vgpu->vdev.num_regions) {
gvt_vgpu_err("invalid index: %u\n", index);
return -EINVAL;
}
@@ -676,8 +686,11 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, 
char *buf,
case VFIO_PCI_BAR5_REGION_INDEX:
case VFIO_PCI_VGA_REGION_INDEX:
case VFIO_PCI_ROM_REGION_INDEX:
+   break;
default:
-   gvt_vgpu_err("unsupported region: %u\n", index);
+   index -= VFIO_PCI_NUM_REGIONS;
+   return vgpu->vdev.region[index].ops->rw(vgpu, buf, count,
+   ppos, is_write);
}
 
return ret == 0 ? count : ret;
@@ -940,7 +953,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
 
info.flags = VFIO_DEVICE_FLAGS_PCI;
info.flags |= VFIO_DEVICE_FLAGS_RESET;
-   info.num_regions = VFIO_PCI_NUM_REGIONS;
+   info.num_regions = VFIO_PCI_NUM_REGIONS +
+   vgpu->vdev.num_regions;
info.num_irqs = VFIO_PCI_NUM_IRQS;
 
return copy_to_user((void __user *)arg, , minsz) ?
@@ -1061,6 +1075,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
}
 
if (caps.size) {
+   info.flags |= VFIO_REGION_INFO_FLAG_CAPS;
if (info.argsz < sizeof(info) + caps.size) {
info.argsz = sizeof(info) + caps.size;
info.cap_offset = 0;
-- 
1.9.1

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


[Intel-gfx] [RFC PATCH 2/6] drm/i915/gvt: OpRegion support for GVT-g

2017-04-28 Thread Xiaoguang Chen
OpRegion is needed to support display related operation for
intel vgpu.

A vfio device region is added to intel vgpu to deliver the
host OpRegion information to user space so user space can
construct the OpRegion for vgpu.

Signed-off-by: Bing Niu 
Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c| 97 +
 drivers/gpu/drm/i915/gvt/opregion.c | 12 -
 2 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3c6a02b..389f072 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,6 +53,8 @@
 #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
 #define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
 
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
 struct vfio_region;
 struct intel_vgpu_regops {
size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
@@ -436,6 +438,92 @@ static void kvmgt_protect_table_del(struct 
kvmgt_guest_info *info,
}
 }
 
+static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
+   size_t count, loff_t *ppos, bool iswrite)
+{
+   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+   VFIO_PCI_NUM_REGIONS;
+   void *base = vgpu->vdev.region[i].data;
+   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+
+   if (pos >= vgpu->vdev.region[i].size || iswrite) {
+   gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
+   return -EINVAL;
+   }
+   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+   memcpy(buf, base + pos, count);
+
+   return count;
+}
+
+static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
+   struct vfio_region *region)
+{
+   memunmap(region->data);
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
+   .rw = intel_vgpu_reg_rw_opregion,
+   .release = intel_vgpu_reg_release_opregion,
+};
+
+static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
+   unsigned int type, unsigned int subtype,
+   const struct intel_vgpu_regops *ops,
+   size_t size, u32 flags, void *data)
+{
+   struct vfio_region *region;
+
+   region = krealloc(vgpu->vdev.region,
+   (vgpu->vdev.num_regions + 1) * sizeof(*region),
+   GFP_KERNEL);
+   if (!region)
+   return -ENOMEM;
+
+   vgpu->vdev.region = region;
+   vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
+   vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
+   vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
+   vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
+   vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
+   vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
+   vgpu->vdev.num_regions++;
+
+   return 0;
+}
+
+static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu)
+{
+   unsigned int addr;
+   void *base;
+   int ret;
+
+   addr = vgpu->gvt->opregion.opregion_pa;
+   if (!addr || !(~addr))
+   return -ENODEV;
+
+   base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
+   if (!base)
+   return -ENOMEM;
+
+   if (memcmp(base, OPREGION_SIGNATURE, 16)) {
+   memunmap(base);
+   return -EINVAL;
+   }
+
+   ret = intel_vgpu_register_reg(vgpu,
+   PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+   VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
+   _vgpu_regops_opregion, OPREGION_SIZE,
+   VFIO_REGION_INFO_FLAG_READ, base);
+   if (ret) {
+   memunmap(base);
+   return ret;
+   }
+
+   return ret;
+}
+
 static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
 {
struct intel_vgpu *vgpu = NULL;
@@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj, struct 
mdev_device *mdev)
vgpu->vdev.mdev = mdev;
mdev_set_drvdata(mdev, vgpu);
 
+   ret = intel_vgpu_reg_init_opregion(vgpu);
+   if (ret) {
+   gvt_vgpu_err("create OpRegion failed\n");
+   goto out;
+   }
+
+   gvt_dbg_core("create OpRegion succeeded for mdev:%s\n",
+   dev_name(mdev_dev(mdev)));
+
gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
 dev_name(mdev_dev(mdev)));
ret = 0;
diff --git a/drivers/gpu/drm/i915/gvt/opregion.c 
b/drivers/gpu/drm/i915/gvt/opregion.c
index 3117991..99591bc 100644
--- a/drivers/gpu/drm/i915/gvt/opregion.c
+++ b/drivers/gpu/drm/i915/gvt/opregion.c
@@ -283,14 +283,22 @@ int intel_vgpu_emulate_opregion_request(struct intel_vgpu 
*vgpu, u32 swsci)
 

[Intel-gfx] [RFC PATCH 4/6] drm/i915: export i915 dmabuf_ops

2017-04-28 Thread Xiaoguang Chen
GVT-g will use i915's dmabuf_ops to implement its own dmabuf so
exporting it.

Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/i915_drv.h| 2 ++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb6fc1e..470d461 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3476,6 +3476,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gem_obj, int flags);
 
+extern const struct dma_buf_ops i915_dmabuf_ops;
+
 static inline struct i915_hw_ppgtt *
 i915_vm_to_ppgtt(struct i915_address_space *vm)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 11898cd..4dafc99 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -196,7 +196,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, 
enum dma_data_direct
return err;
 }
 
-static const struct dma_buf_ops i915_dmabuf_ops =  {
+const struct dma_buf_ops i915_dmabuf_ops =  {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-- 
1.9.1

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


[Intel-gfx] [RFC PATCH 0/6] drm/i915/gvt: dma-buf support for GVT-g

2017-04-28 Thread Xiaoguang Chen
This patch set adds the dma-buf support for intel GVT-g.
dma-buf is a uniform mechanism to share DMA buffers across different
devices and sub-systems.
dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer
to other users or sub-systems so they can use the dma-buf to show the
desktop of a vm which uses intel vgpu.

The main idea is we create a gem object and set vgpu's framebuffer as
the backing storage of this gem object. And associate this gem obj
to a dma-buf object then export this dma-buf at the meantime
generate a file descriptor for this dma-buf. Finally deliver this file
descriptor to end users.
In the implementation we create an anonymous fd and send this fd to users
using an vfio device region. Once users get this anonymous fd they can do
ioctl using this anonymous fd to get the file descriptor we generated for
dma-buf.

We have an example program on how to use the dma-buf. You can download
the program to have a try :)
git repo: https://github.com/01org/igvtg-qemu branch:kvmgt_dmabuf_example

Xiaoguang Chen (6):
  drm/i915/gvt: extend the GVT-g architecture to support vfio device
region
  drm/i915/gvt: OpRegion support for GVT-g
  drm/i915/gvt: framebuffer decoder support for GVT-g
  drm/i915: export i915 dmabuf_ops
  drm/i915/gvt: dmabuf support for GVT-g
  drm/i915/gvt: support QEMU getting the dmabuf

 drivers/gpu/drm/i915/gvt/Makefile  |   3 +-
 drivers/gpu/drm/i915/gvt/display.c |   2 +-
 drivers/gpu/drm/i915/gvt/display.h |   2 +
 drivers/gpu/drm/i915/gvt/dmabuf.c  | 268 ++
 drivers/gpu/drm/i915/gvt/dmabuf.h  |  50 
 drivers/gpu/drm/i915/gvt/fb_decoder.c  | 487 +
 drivers/gpu/drm/i915/gvt/fb_decoder.h  | 170 
 drivers/gpu/drm/i915/gvt/gvt.c |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h |   4 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 227 ++-
 drivers/gpu/drm/i915/gvt/opregion.c|  12 +-
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 include/uapi/linux/vfio.h  |   1 +
 14 files changed, 1224 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h

-- 
1.9.1

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


[Intel-gfx] [RFC PATCH 3/6] drm/i915/gvt: framebuffer decoder support for GVT-g

2017-04-28 Thread Xiaoguang Chen
decode frambuffer attributes of primary, cursor and sprite plane

Signed-off-by: Xiaoguang Chen 
---
 drivers/gpu/drm/i915/gvt/Makefile |   3 +-
 drivers/gpu/drm/i915/gvt/display.c|   2 +-
 drivers/gpu/drm/i915/gvt/display.h|   2 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 487 ++
 drivers/gpu/drm/i915/gvt/fb_decoder.h | 170 
 drivers/gpu/drm/i915/gvt/gvt.h|   1 +
 6 files changed, 663 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index b123c20..192ca26 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
 GVT_DIR := gvt
 GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
-   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+   fb_decoder.o
 
 ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR) -Wall
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 4cf2b29..9f8d126 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
 }
 
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
 {
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
 
diff --git a/drivers/gpu/drm/i915/gvt/display.h 
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ static inline char *vgpu_edid_str(enum intel_vgpu_edid id)
 void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
 void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
 
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
 #endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..954f047
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,487 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * 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:
+ *Kevin Tian 
+ *
+ * Contributors:
+ *Bing Niu 
+ *Xu Han 
+ *Ping Gao 
+ *Xiaoguang Chen 
+ *Yang Liu 
+ *
+ */
+
+#include 
+#include "i915_drv.h"
+#include "gvt.h"
+
+/* The below definitions are required by guest. */
+// [63:0] x:R:G:B 16:16:16:16 little endian
+#define DRM_FORMAT_XRGB161616_GVT  fourcc_code('X', 'R', '4', '8')
+// [63:0] x:B:G:R 16:16:16:16 little endian
+#define DRM_FORMAT_XBGR161616_GVT  fourcc_code('X', 'B', '4', '8')
+
+#define FORMAT_NUM 16
+struct pixel_format {
+   int drm_format; /* Pixel format in DRM definition */
+   int bpp;/* Bits per pixel, 0 indicates invalid */
+   char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format primary_pixel_formats[FORMAT_NUM] = {
+   [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+   [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+   [0x6] = {DRM_FORMAT_XRGB, 32,
+   "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+   [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+   "32-bit RGBX (2:10:10:10 

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Tvrtko Ursulin


On 28/04/2017 08:41, Chris Wilson wrote:

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment.


FYI I am reading v11 and commenting here. Hopefully it works out. :)



Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  92 +-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  36 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 362 +
 drivers/gpu/drm/i915/i915_syncmap.h|  39 +++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 257 +++
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 +++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 12 files changed, 860 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1fa3c103f38..f886ef492036 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3214,6 +3214,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);

GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__

+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5fa4e52ded06..807fc1b65dd1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -772,6 +772,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;

+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 to_request(fence));
@@ -781,6 +786,10 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
GFP_KERNEL);
if (ret < 0)
return ret;
+
+   /* Record the latest fence used against each timeline */
+   if (fence->context != req->i915->mm.unordered_timeline)
+   

[Intel-gfx] [PATCH v2] drm/i915/edp: Read link status after exit link training

2017-04-28 Thread Lee, Shawn C
From: "Lee, Shawn C" 

Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source
read these registers at the same time. Panel will report EQ & symbol
lock not done. It will cause panel display flicking.
So driver have to make sure PSR already exit before read link status.

Change log:
v2:
- Use intel_wait_for_register() to replace I915_READ().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99639
TEST=Reboot DUT and no flicking on local display at login screen

Cc: Cooper Chiou 
Cc: Gary C Wang 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jim Bride 
Cc: Ryan Lin 

Signed-off-by: Shawn Lee 
---
 drivers/gpu/drm/i915/intel_dp.c |   33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f74d396..099b6c0605a7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4252,19 +4252,34 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
 }
 
 static void
+intel_edp_wait_PSR_exit(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u16 count = 100;
+
+   while (count--)
+   if (!intel_wait_for_register(dev_priv,
+   EDP_PSR_STATUS_CTL,
+   (EDP_PSR_STATUS_SENDING_TP1 |
+EDP_PSR_STATUS_SENDING_TP2_TP3 |
+EDP_PSR_STATUS_SENDING_IDLE |
+EDP_PSR_STATUS_AUX_SENDING),
+0,
+1))
+   return;
+}
+
+static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
-   return;
-   }
-
if (!intel_encoder->base.crtc)
return;
 
@@ -4278,6 +4293,14 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!intel_dp_link_params_valid(intel_dp))
return;
 
+   if (is_edp(intel_dp) && dev_priv->psr.enabled)
+   intel_edp_wait_PSR_exit(intel_dp);
+
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   DRM_ERROR("Failed to get link status\n");
+   return;
+   }
+
/* Retrain if Channel EQ or CR not ok */
if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
-- 
1.7.9.5

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


Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Sanitize engine context sizes

2017-04-28 Thread Joonas Lahtinen
On pe, 2017-04-28 at 09:02 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/4] drm/i915: Sanitize engine context sizes
> URL   : https://patchwork.freedesktop.org/series/23678/
> State : success

Pushed the series, thanks for the review.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Sanitize engine context sizes

2017-04-28 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Sanitize engine context sizes
URL   : https://patchwork.freedesktop.org/series/23678/
State : success

== Summary ==

Series 23678v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23678/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6260u) fdo#100461

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:566s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:539s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:476s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:564s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:487s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:428s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:401s

ef1bc2e0d9b4a6342b300ccd25332f7cc4fc360b drm-tip: 2017y-04m-28d-07h-58m-50s UTC 
integration manifest
960ec0a drm/i915: Capture CCID on ILK
738bc88 drm/i915: Reset ILK during GEM sanitization
d258bf5 drm/i915: Eliminate HAS_HW_CONTEXTS
ca23d96 drm/i915: Sanitize engine context sizes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4573/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Ander Conselvan De Oliveira
On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, April 28, 2017 1:32 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Conselvan De Oliveira, Ander ;
> > Deepak M ; Chauhan, Madhav
> > ; Nikula, Jani ; Vetter,
> > Daniel ; Jani Nikula ;
> > drm-intel-fi...@lists.freedesktop.org
> > Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> > messages
> > 
> > The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
> > *not* active to then disable it. The correct sequence according to the spec 
> > is
> > to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., 
> > ULPS
> > is active, and then disable ULPS.
> > 
> > Fixing the codition gets rid of the following spurious error messages:
> 
> Please correct the typo error to "condition", otherwise looks good.
> Thanks for catching this.

If you upgrade the above statement to a Reviewed-by, I can fix the typo while
merging?

Ander

> 
> > 
> > [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> > 
> > Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
> > Cc: Deepak M 
> > Cc: Madhav Chauhan 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: 
> > Signed-off-by: Ander Conselvan de Oliveira
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 3ffe8b1..fc0ef49 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> > intel_encoder *encoder)
> > val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > I915_WRITE(MIPI_DEVICE_READY(port), val);
> > 
> > -   /* Wait for ULPS Not active */
> > +   /* Wait for ULPS active */
> > if (intel_wait_for_register(dev_priv,
> > -   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > -   GLK_ULPS_NOT_ACTIVE, 20))
> > -   DRM_ERROR("ULPS is still active\n");
> > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> > 20))
> > +   DRM_ERROR("ULPS not active\n");
> > 
> > /* Exit ULPS */
> > val = I915_READ(MIPI_DEVICE_READY(port));
> > --
> > 2.9.3
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Chauhan, Madhav
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, April 28, 2017 1:32 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Deepak M ; Chauhan, Madhav
> ; Nikula, Jani ; Vetter,
> Daniel ; Jani Nikula ;
> drm-intel-fi...@lists.freedesktop.org
> Subject: [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active"
> messages
> 
> The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
> *not* active to then disable it. The correct sequence according to the spec is
> to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS
> is active, and then disable ULPS.
> 
> Fixing the codition gets rid of the following spurious error messages:

Please correct the typo error to "condition", otherwise looks good.
Thanks for catching this.

> 
> [drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active
> 
> Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
> Cc: Deepak M 
> Cc: Madhav Chauhan 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: 
> Signed-off-by: Ander Conselvan de Oliveira
> 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 3ffe8b1..fc0ef49 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct
> intel_encoder *encoder)
>   val |= (ULPS_STATE_ENTER | DEVICE_READY);
>   I915_WRITE(MIPI_DEVICE_READY(port), val);
> 
> - /* Wait for ULPS Not active */
> + /* Wait for ULPS active */
>   if (intel_wait_for_register(dev_priv,
> - MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> - GLK_ULPS_NOT_ACTIVE, 20))
> - DRM_ERROR("ULPS is still active\n");
> + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0,
> 20))
> + DRM_ERROR("ULPS not active\n");
> 
>   /* Exit ULPS */
>   val = I915_READ(MIPI_DEVICE_READY(port));
> --
> 2.9.3

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


Re: [Intel-gfx] [PATCH] drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 10:58:39AM +0300, Joonas Lahtinen wrote:
> Add intel_irq_fini() for placing the deinitialization code,
> starting with freeing dev_priv->l3_parity.remap_info[].
> 
> Signed-off-by: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 

Couldn't spot anything broken, so
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

2017-04-28 Thread Takashi Iwai
On Thu, 27 Apr 2017 18:02:19 +0200,
ville.syrj...@linux.intel.com wrote:
> 
> From: Ville Syrjälä 
> 
> Okay, here's the second attempt at getting multiple pipes playing back
> audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
> that now the PCM devices are associated with ports instead of pipes,
> so the audio from one device always gets output on the same display.
> 
> I've also tacked on the alsa-lib conf update. No clue whether it's
> really correct or not (the config language isn't a close friend
> of mine).
> 
> BTW I did notice that with LPE audio all the controls say iface=PCM,
> whereas on HDA a bunch of them say iface=MIXER. No idea if that's
> OK or not, just something I spotted when I was comparing the results
> with HDA.

We generally accept both iface types for IEC958 stuff, since
historically many drivers have already mixed them up.  So it's no
problem :)


> Entire series available here:
> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
> 
> Cc: Takashi Iwai 
> Cc: Pierre-Louis Bossart 

All look good, and feel free to take my reviewed-by tag
  Reviewed-by: Takashi Iwai 

As said previously, my only slight concern is the compatibility.
But, in the current situation with PulseAudio, only few people would
use this driver, so it shouldn't be so big impact, I suppose.

BTW, which port is used in general on BYT/CHT?

Oh, also, I suppose you want to carry these over i915 tree?
I don't mind either way, I can take them through sound tree if
preferred, too.


thanks,

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Report the ring->space from intel_ring_update_space()

2017-04-28 Thread Joonas Lahtinen
On ke, 2017-04-26 at 09:37 +0100, Chris Wilson wrote:
> Some callers immediately want to know the current ring->space after
> calling intel_ring_update_space(), which we can freely provide via the
> return parameter.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Fix sleep under spinlock during reset

2017-04-28 Thread Saarinen, Jani
Hi, 
> -Original Message-
> On 12/04/2017 18:16, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [1/2] drm/i915/guc: Fix sleep under spinlock 
> > during
> reset
> > URL   : https://patchwork.freedesktop.org/series/22937/ 
> > State : failure
> >
> > == Summary ==
> >
> > Series 22937v1 Series without cover letter
> > https://patchwork.freedesktop.org/api/1.0/series/22937/revisions/1/mbo
> > x/
> >
> > Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-uc:
> > fail   -> PASS   (fi-snb-2600) fdo#17
> > Test kms_pipe_crc_basic:
> > Subgroup read-crc-pipe-a-frame-sequence:
> > pass   -> FAIL   (fi-skl-6770hq)
> 
> Re-opening:
Thanks 
Re-opened for real now and marked for CI
 
> https://bugs.freedesktop.org/show_bug.cgi?id=99788
> 
> kms_pipe_crc_basic/read-crc-pipe-b-frame-sequence:
> 
> (kms_pipe_crc_basic:8766) CRITICAL: Failed assertion: crcs[j].frame + 1 
> ==crcs[j + 1].frame
> (kms_pipe_crc_basic:8766) CRITICAL: error: 20240 != 20241


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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


Re: [Intel-gfx] [PATCH 02/11] ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown

2017-04-28 Thread Takashi Iwai
On Thu, 27 Apr 2017 18:02:21 +0200,
ville.syrj...@linux.intel.com wrote:
> 
> From: Ville Syrjälä 
> 
> Clear the notify function pointer in the platform data before we tear
> down the driver. Otherwise i915 would end up calling a stale function
> pointer and possibly explode.
> 
> Cc: Takashi Iwai 
> Cc: Pierre-Louis Bossart 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Takashi Iwai 

This deserves also Cc to stable, IMO.


thanks,

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


Re: [Intel-gfx] [PATCH 01/11] drm/i915: Fix runtime PM for LPE audio

2017-04-28 Thread Takashi Iwai
On Thu, 27 Apr 2017 18:02:20 +0200,
ville.syrj...@linux.intel.com wrote:
> 
> From: Ville Syrjälä 
> 
> Not calling pm_runtime_enable() means that runtime PM can't be
> enabled at all via sysfs. So we definitely need to call it
> from somewhere.
> 
> Calling it from the driver seems like a bad idea because it
> would have to be paired with a pm_runtime_disable() at driver
> unload time, otherwise the core gets upset. Also if there's
> no LPE audio driver loaded then we couldn't runtime suspend
> i915 either.
> 
> So it looks like a better plan is to call it from i915 when
> we register the platform device. That seems to match how
> pci generally does things. I cargo culted the
> pm_runtime_forbid() and pm_runtime_set_active() calls from
> pci as well.
> 
> The exposed runtime PM API is massive an thorougly misleading, so
> I don't actually know if this is how you're supposed to use the API
> or not. But it seems to work. I can now runtime suspend i915 again
> with or without the LPE audio driver loaded, and reloading the
> LPE audio driver also seems to work.
> 
> Note that powertop won't auto-tune runtime PM for platform devices,
> which is a little annoying. So I'm not sure that leaving runtime
> PM in "on" mode by default is the best choice here. But I've left
> it like that for now at least.

The reason I didn't proactively turn on the runtime PM was that it
often caused a few seconds of pause to the A/V receivers before
actually starting playing.

There is a planned feature to keep sending the silent stream even
after stopping the stream, but it's not implemented yet.

> Also remove the comment about there not being much benefit from
> LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
> PM, which will also block s0ix, and that could have a measurable
> impact on power consumption.
> 
> Cc: Takashi Iwai 
> Cc: Pierre-Louis Bossart 
> Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Takashi Iwai 

IMO, this should be tagged with Cc to stable.


thanks,

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


[Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

2017-04-28 Thread Ander Conselvan de Oliveira
The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
*not* active to then disable it. The correct sequence according to the
spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is
zero, i.e., ULPS is active, and then disable ULPS.

Fixing the codition gets rid of the following spurious error messages:

[drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active

Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
Cc: Deepak M 
Cc: Madhav Chauhan 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_dsi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3ffe8b1..fc0ef49 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -410,11 +410,10 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
val |= (ULPS_STATE_ENTER | DEVICE_READY);
I915_WRITE(MIPI_DEVICE_READY(port), val);
 
-   /* Wait for ULPS Not active */
+   /* Wait for ULPS active */
if (intel_wait_for_register(dev_priv,
-   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
-   GLK_ULPS_NOT_ACTIVE, 20))
-   DRM_ERROR("ULPS is still active\n");
+   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0, 20))
+   DRM_ERROR("ULPS not active\n");
 
/* Exit ULPS */
val = I915_READ(MIPI_DEVICE_READY(port));
-- 
2.9.3

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Fix sleep under spinlock during reset

2017-04-28 Thread Tvrtko Ursulin


On 12/04/2017 18:16, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Fix sleep under spinlock 
during reset
URL   : https://patchwork.freedesktop.org/series/22937/
State : failure

== Summary ==

Series 22937v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22937/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> FAIL   (fi-skl-6770hq)


Re-opening:

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

kms_pipe_crc_basic/read-crc-pipe-b-frame-sequence:

(kms_pipe_crc_basic:8766) CRITICAL: Failed assertion: crcs[j].frame + 1 
== crcs[j + 1].frame

(kms_pipe_crc_basic:8766) CRITICAL: error: 20240 != 20241



fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:423s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:536s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:442s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:554s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:437s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:449s
fi-skl-6770hqtotal:278  pass:267  dwarn:0   dfail:0   fail:1   skip:10  
time:483s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:412s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:413s

57188aaf3b96d08e4095755fda0e577b1e0d8c60 drm-tip: 2017y-04m-12d-16h-12m-10s UTC 
integration manifest
54e2b93 guc run
e066fdc drm/i915/guc: Fix sleep under spinlock during reset


Pushed, thanks for the review!

Regards,

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


Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
On Fri, Apr 28, 2017 at 08:41:36AM +0100, Chris Wilson wrote:
> Track the latest fence waited upon on each context, and only add a new
> asynchronous wait if the new fence is more recent than the recorded
> fence for that context. This requires us to filter out unordered
> timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
> absence of a universal identifier, we have to use our own
> i915->mm.unordered_timeline token.
> 
> v2: Throw around the debug crutches
> v3: Inline the likely case of the pre-allocation cache being full.
> v4: Drop the pre-allocation support, we can lose the most recent fence
> in case of allocation failure -- it just means we may emit more awaits
> than strictly necessary but will not break.
> v5: Trim allocation size for leaf nodes, they only need an array of u32
> not pointers.
> v6: Create mock_timeline to tidy selftest writing
> v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
> v8: Prune the stale sync points when we idle.
> v9: Include a small benchmark in the kselftests
> v10: Separate the idr implementation into its own compartment.

Before you complain, I haven't yet attempted to refactor the kselftests
to avoid deep indentation.
-Chris

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


[Intel-gfx] [PATCH] drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

2017-04-28 Thread Joonas Lahtinen
Add intel_irq_fini() for placing the deinitialization code,
starting with freeing dev_priv->l3_parity.remap_info[].

Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.c   |  6 --
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_irq.c   | 20 +++-
 drivers/gpu/drm/i915/i915_sysfs.c | 23 ---
 4 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c7d68e7..8228b4c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -856,7 +856,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_init_audio_hooks(dev_priv);
ret = i915_gem_load_init(dev_priv);
if (ret < 0)
-   goto err_workqueues;
+   goto err_irq;
 
intel_display_crc_init(dev_priv);
 
@@ -868,7 +868,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
return 0;
 
-err_workqueues:
+err_irq:
+   intel_irq_fini(dev_priv);
i915_workqueues_cleanup(dev_priv);
 err_engines:
i915_engines_cleanup(dev_priv);
@@ -883,6 +884,7 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
 {
i915_perf_fini(dev_priv);
i915_gem_load_cleanup(dev_priv);
+   intel_irq_fini(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1f7c48..618ea2d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3060,6 +3060,7 @@ void i915_handle_error(struct drm_i915_private *dev_priv,
   const char *fmt, ...);
 
 extern void intel_irq_init(struct drm_i915_private *dev_priv);
+extern void intel_irq_fini(struct drm_i915_private *dev_priv);
 int intel_irq_install(struct drm_i915_private *dev_priv);
 void intel_irq_uninstall(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fd97fe0..0e4dcbeb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1236,7 +1236,7 @@ static void gen6_pm_rps_work(struct work_struct *work)
 static void ivybridge_parity_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
-   container_of(work, struct drm_i915_private, 
l3_parity.error_work);
+   container_of(work, typeof(*dev_priv), l3_parity.error_work);
u32 error_status, row, bank, subbank;
char *parity_event[6];
uint32_t misccpctl;
@@ -4233,11 +4233,15 @@ static void i965_irq_uninstall(struct drm_device * dev)
 void intel_irq_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = _priv->drm;
+   int i;
 
intel_hpd_init_work(dev_priv);
 
INIT_WORK(_priv->rps.work, gen6_pm_rps_work);
+
INIT_WORK(_priv->l3_parity.error_work, ivybridge_parity_work);
+   for (i = 0; i < MAX_L3_SLICES; ++i)
+   dev_priv->l3_parity.remap_info[i] = NULL;
 
if (HAS_GUC_SCHED(dev_priv))
dev_priv->pm_guc_events = GEN9_GUC_TO_HOST_INT_EVENT;
@@ -4363,6 +4367,20 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
 }
 
 /**
+ * intel_irq_fini - deinitializes IRQ support
+ * @i915: i915 device instance
+ *
+ * This function deinitializes all the IRQ support.
+ */
+void intel_irq_fini(struct drm_i915_private *i915)
+{
+   int i;
+
+   for (i = 0; i < MAX_L3_SLICES; ++i)
+   kfree(i915->l3_parity.remap_info[i]);
+}
+
+/**
  * intel_irq_install - enables the hardware interrupt
  * @dev_priv: i915 device instance
  *
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index f3fdfda..f9e009c 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -181,8 +181,8 @@ i915_l3_write(struct file *filp, struct kobject *kobj,
struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
struct drm_device *dev = _priv->drm;
struct i915_gem_context *ctx;
-   u32 *temp = NULL; /* Just here to make handling failures easy */
int slice = (int)(uintptr_t)attr->private;
+   u32 **remap_info;
int ret;
 
if (!HAS_HW_CONTEXTS(dev_priv))
@@ -196,11 +196,12 @@ i915_l3_write(struct file *filp, struct kobject *kobj,
if (ret)
return ret;
 
-   if (!dev_priv->l3_parity.remap_info[slice]) {
-   temp = kzalloc(GEN7_L3LOG_SIZE, GFP_KERNEL);
-   if (!temp) {
-   mutex_unlock(>struct_mutex);
-   return -ENOMEM;
+   remap_info = _priv->l3_parity.remap_info[slice];
+   if 

[Intel-gfx] [PATCH 3/4] drm/i915: Reset ILK during GEM sanitization

2017-04-28 Thread Joonas Lahtinen
ILK should survive a reset without display corruption.

Suggested-by: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ea34a32..f5f6057 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4485,10 +4485,9 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 * try to take over. The only way to remove the earlier state
 * is by resetting. However, resetting on earlier gen is tricky as
 * it may impact the display and we are uncertain about the stability
-* of the reset, so we only reset recent machines with logical
-* context support (that must be reset to remove any stray contexts).
+* of the reset, so this could be applied to even earlier gen.
 */
-   if (INTEL_GEN(i915) >= 6) {
+   if (INTEL_GEN(i915) >= 5) {
int reset = intel_gpu_reset(i915, ALL_ENGINES);
WARN_ON(reset && reset != -ENODEV);
}
-- 
2.7.4

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


[Intel-gfx] [PATCH 4/4] drm/i915: Capture CCID on ILK

2017-04-28 Thread Joonas Lahtinen
CCID register existed already on ILK according to the PRM (Chris
verified the address to match too).

Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index fbdd06c..ec526d9 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1598,7 +1598,7 @@ static void i915_capture_reg_state(struct 
drm_i915_private *dev_priv,
error->done_reg = I915_READ(DONE_REG);
}
 
-   if (INTEL_GEN(dev_priv) >= 6)
+   if (INTEL_GEN(dev_priv) >= 5)
error->ccid = I915_READ(CCID);
 
/* 3: Feature specific registers */
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/4] drm/i915: Eliminate HAS_HW_CONTEXTS

2017-04-28 Thread Joonas Lahtinen
HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
replace it with Gen specific (to be updated in next patches).

HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.

This leads to us being able to get rid of the property completely.

v2:
- Keep the checks at Gen6 for no functional change (Ville)

Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   | 2 --
 drivers/gpu/drm/i915/i915_gem.c   | 2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 6 +++---
 drivers/gpu/drm/i915/i915_pci.c   | 5 -
 drivers/gpu/drm/i915/i915_sysfs.c | 3 ---
 5 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e68edf1..cfa5689 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -822,7 +822,6 @@ struct intel_csr {
func(has_gmch_display); \
func(has_guc); \
func(has_hotplug); \
-   func(has_hw_contexts); \
func(has_l3_dpf); \
func(has_llc); \
func(has_logical_ring_contexts); \
@@ -2866,7 +2865,6 @@ intel_info(const struct drm_i915_private *dev_priv)
 
 #define HWS_NEEDS_PHYSICAL(dev_priv)   ((dev_priv)->info.hws_needs_physical)
 
-#define HAS_HW_CONTEXTS(dev_priv)  ((dev_priv)->info.has_hw_contexts)
 #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
((dev_priv)->info.has_logical_ring_contexts)
 #define USES_PPGTT(dev_priv)   (i915.enable_ppgtt)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33fb11c..ea34a32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4488,7 +4488,7 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 * of the reset, so we only reset recent machines with logical
 * context support (that must be reset to remove any stray contexts).
 */
-   if (HAS_HW_CONTEXTS(i915)) {
+   if (INTEL_GEN(i915) >= 6) {
int reset = intel_gpu_reset(i915, ALL_ENGINES);
WARN_ON(reset && reset != -ENODEV);
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4b247b0..fbdd06c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1598,6 +1598,9 @@ static void i915_capture_reg_state(struct 
drm_i915_private *dev_priv,
error->done_reg = I915_READ(DONE_REG);
}
 
+   if (INTEL_GEN(dev_priv) >= 6)
+   error->ccid = I915_READ(CCID);
+
/* 3: Feature specific registers */
if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {
error->gam_ecochk = I915_READ(GAM_ECOCHK);
@@ -1605,9 +1608,6 @@ static void i915_capture_reg_state(struct 
drm_i915_private *dev_priv,
}
 
/* 4: Everything else */
-   if (HAS_HW_CONTEXTS(dev_priv))
-   error->ccid = I915_READ(CCID);
-
if (INTEL_GEN(dev_priv) >= 8) {
error->ier = I915_READ(GEN8_DE_MISC_IER);
for (i = 0; i < 4; i++)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f87b0c4..f80db2c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -220,7 +220,6 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_rc6 = 1, \
.has_rc6p = 1, \
.has_gmbus_irq = 1, \
-   .has_hw_contexts = 1, \
.has_aliasing_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -245,7 +244,6 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_rc6 = 1, \
.has_rc6p = 1, \
.has_gmbus_irq = 1, \
-   .has_hw_contexts = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -280,7 +278,6 @@ static const struct intel_device_info intel_valleyview_info 
= {
.has_runtime_pm = 1,
.has_rc6 = 1,
.has_gmbus_irq = 1,
-   .has_hw_contexts = 1,
.has_gmch_display = 1,
.has_hotplug = 1,
.has_aliasing_ppgtt = 1,
@@ -340,7 +337,6 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_resource_streamer = 1,
.has_rc6 = 1,
.has_gmbus_irq = 1,
-   .has_hw_contexts = 1,
.has_logical_ring_contexts = 1,
.has_gmch_display = 1,
.has_aliasing_ppgtt = 1,
@@ -387,7 +383,6 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.has_rc6 = 1, \
.has_dp_mst = 1, \
.has_gmbus_irq = 1, \
-   .has_hw_contexts = 1, \

[Intel-gfx] [PATCH 1/4] drm/i915: Sanitize engine context sizes

2017-04-28 Thread Joonas Lahtinen
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context allocation

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
Acked-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  6 +-
 drivers/gpu/drm/i915/i915_drv.c| 15 +++--
 drivers/gpu/drm/i915/i915_drv.h|  3 +-
 drivers/gpu/drm/i915/i915_gem_context.c| 56 ++-
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
 drivers/gpu/drm/i915/i915_reg.h| 10 
 drivers/gpu/drm/i915/intel_engine_cs.c | 90 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +-
 drivers/gpu/drm/i915/intel_lrc.h   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.c|  4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 ++-
 11 files changed, 112 insertions(+), 138 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index bada32b..1256fe2 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -330,8 +329,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c7d68e7..2d3c4264 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -835,10 +835,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
 
-   ret = intel_engines_init_early(dev_priv);
-   if (ret)
-   return ret;
-
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
goto err_engines;
@@ -948,14 +944,21 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
 
ret = i915_mmio_setup(dev_priv);
if (ret < 0)
-   goto put_bridge;
+   goto err_bridge;
 
intel_uncore_init(dev_priv);
+
+   ret = intel_engines_init_mmio(dev_priv);
+   if (ret)
+   goto err_uncore;
+
i915_gem_init_mmio(dev_priv);
 
return 0;
 
-put_bridge:
+err_uncore:
+   intel_uncore_fini(dev_priv);
+err_bridge:
pci_dev_put(dev_priv->bridge_dev);
 
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1f7c48..e68edf1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2359,7 +2359,6 @@ struct drm_i915_private {
 */
struct mutex av_mutex;
 
-   uint32_t hw_context_size;
struct list_head context_list;
 
u32 fdi_rx_config;
@@ -3023,7 +3022,7 @@ extern unsigned long i915_gfx_val(struct drm_i915_private 
*dev_priv);
 extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
 int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
 
-int intel_engines_init_early(struct drm_i915_private *dev_priv);
+int intel_engines_init_mmio(struct drm_i915_private *dev_priv);
 int intel_engines_init(struct drm_i915_private *dev_priv);
 
 /* intel_hotplug.c */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index d46a69d..31a73c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,33 +92,6 @@
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
-static int get_context_size(struct drm_i915_private 

[Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

2017-04-28 Thread Chris Wilson
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_gem.c|   1 +
 drivers/gpu/drm/i915/i915_gem.h|   2 +
 drivers/gpu/drm/i915/i915_gem_request.c|   9 +
 drivers/gpu/drm/i915/i915_gem_timeline.c   |  92 +-
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  36 ++
 drivers/gpu/drm/i915/i915_syncmap.c| 362 +
 drivers/gpu/drm/i915/i915_syncmap.h|  39 +++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 257 +++
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
 drivers/gpu/drm/i915/selftests/mock_timeline.c |  45 +++
 drivers/gpu/drm/i915/selftests/mock_timeline.h |  33 ++
 12 files changed, 860 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.c
 create mode 100644 drivers/gpu/drm/i915/i915_syncmap.h
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.c
 create mode 100644 drivers/gpu/drm/i915/selftests/mock_timeline.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..7b05fb802f4c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
  i915_params.o \
  i915_pci.o \
   i915_suspend.o \
+ i915_syncmap.o \
  i915_sw_fence.o \
  i915_sysfs.o \
  intel_csr.o \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1fa3c103f38..f886ef492036 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3214,6 +3214,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
}
+   i915_gem_timelines_mark_idle(dev_priv);
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487368ca..ee54597465b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -25,6 +25,8 @@
 #ifndef __I915_GEM_H__
 #define __I915_GEM_H__
 
+#include 
+
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #define GEM_WARN_ON(expr) WARN_ON(expr)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5fa4e52ded06..807fc1b65dd1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -772,6 +772,11 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
continue;
 
+   /* Squash repeated waits to the same timelines */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_is_later(req->timeline, fence))
+   continue;
+
if (dma_fence_is_i915(fence))
ret = i915_gem_request_await_request(req,
 to_request(fence));
@@ -781,6 +786,10 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
GFP_KERNEL);
if (ret < 0)
return ret;
+
+   /* Record the latest fence used against each timeline */
+   if (fence->context != req->i915->mm.unordered_timeline)
+   intel_timeline_sync_set(req->timeline, fence);
} while (--nchild);
 
return 0;
diff --git 

Re: [Intel-gfx] [PATCH v7 13/20] drm/i915/guc: Rename the function that resets the GuC

2017-04-28 Thread Tvrtko Ursulin


On 28/04/2017 00:12, Michel Thierry wrote:

intel_guc_reset sounds more like the microcontroller is the one performing
a reset, while in this case is the opposite. intel_reset_guc not only
makes it clearer, it follows the other intel_reset functions available.

Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c | 4 ++--
 drivers/gpu/drm/i915/intel_uncore.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9ff7f726d47..e9e04c92a376 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3031,7 +3031,7 @@ extern int i915_reset_engine(struct intel_engine_cs 
*engine);
 extern bool intel_has_reset_engine(struct drm_i915_private *dev_priv);
 extern int intel_reset_engine_start(struct intel_engine_cs *engine);
 extern void intel_reset_engine_cancel(struct intel_engine_cs *engine);
-extern int intel_guc_reset(struct drm_i915_private *dev_priv);
+extern int intel_reset_guc(struct drm_i915_private *dev_priv);
 extern void intel_engine_init_hangcheck(struct intel_engine_cs *engine);
 extern void intel_hangcheck_init(struct drm_i915_private *dev_priv);
 extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 900e3767a899..bad282b6c886 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -46,9 +46,9 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
int ret;
u32 guc_status;

-   ret = intel_guc_reset(dev_priv);
+   ret = intel_reset_guc(dev_priv);
if (ret) {
-   DRM_ERROR("GuC reset failed, ret = %d\n", ret);
+   DRM_ERROR("Reset GuC failed, ret = %d\n", ret);


As a non-native speaker I might be wrong, but was thinking something 
like "Failed to reset GuC", "Resetting GuC failed", "Reset of GuC 
failed" would be clearer? I leave it for someone more competent to decide.



return ret;
}

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 120fb440bb8b..00251d83e7bd 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1792,7 +1792,7 @@ bool intel_has_reset_engine(struct drm_i915_private 
*dev_priv)
i915.reset == 2);
 }

-int intel_guc_reset(struct drm_i915_private *dev_priv)
+int intel_reset_guc(struct drm_i915_private *dev_priv)
 {
int ret;




Potential message bikeshed aside:

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Fix sleep under spinlock during reset

2017-04-28 Thread Joonas Lahtinen
On ke, 2017-04-12 at 16:48 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Looks like intel_guc_reset had the ability to sleep under the
> uncore spinlock since forever but it wasn't detected until the
> recent changes annotated the wait for register with might_sleep.
> 
> I have fixed it by removing holding of the uncore spinlock over
> the call to gen6_hw_domain_reset, since I do not see that is
> really needed. But there is always a possibility I am missing
> some nasty detail so please double check.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Arkadiusz Hiler 
> Cc: Joonas Lahtinen 
> Cc: Oscar Mateo 

Reviewed-by: Joonas Lahtinen 

Name and location of intel_guc_reset is bad, yes.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx