date:20180406

[Intel-gfx] [PATCH v20 12/18] drm/i915: Set scaler mode for NV12

2018-04-06 Thread Vidya Srinivas

From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

v4: Rebased (me)

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.

v9: Rebased (me)

v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.

v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.

v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

Tested-by: Clinton Taylor 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c | 14 --
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2afa96b..42f72a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6652,6 +6652,8 @@ enum {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e9fb6920..bb8c168 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -328,8 +328,18 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   scaler_state->scalers[*scaler_id].mode = 0;
+   if ((INTEL_GEN(dev_priv) >= 9) &&
+   plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {
+   if (INTEL_GEN(dev_priv) == 9 &&
+   !IS_GEMINILAKE(dev_priv) &&
+   !IS_SKYLAKE(dev_priv))
+   scaler_state->scalers[*scaler_id].mode =
+   SKL_PS_SCALER_MODE_NV12;
+   else
+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
-- 
2.7.4

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

[Intel-gfx] [PATCH v20 09/18] drm/i915/skl: split skl_compute_ddb function

2018-04-06 Thread Vidya Srinivas

From: Mahesh Kumar 

This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.

v2: Added reviewed by tag from Shashank Sharma

v3: Added reviewed by from Juha-Pekka Heikkila

v4: Rebased the series

v5: Fixed checkpatch error. Changed *changed = true
to (*changed) = true;

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 157 ++--
 1 file changed, 88 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3210868..ffed139 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5059,69 +5059,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
*cstate)
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
-   uint32_t realloc_pipes = pipes_modified(state);
-   int ret;
-
-   /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us.  Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
-   if (dev_priv->wm.distrust_bios_wm) {
-   ret = drm_modeset_lock(>mode_config.connection_mutex,
-  state->acquire_ctx);
-   if (ret)
-   return ret;
-
-   intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
-   }
-
-   /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit.  Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
-   if (intel_state->active_pipe_changes) {
-   realloc_pipes = ~0;
-   intel_state->wm_results.dirty_pipes = ~0;
-   }
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *cstate;
+   int ret, i;
 
-   /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, _priv->wm.skl_hw.ddb, sizeof(*ddb));
 
-   for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
-   struct intel_crtc_state *cstate;
-
-   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(cstate))
-   return PTR_ERR(cstate);
-
+   for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5183,23 +5130,23 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
 }
 
 static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
 {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *cstate;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
-   struct skl_pipe_wm *pipe_wm;
-   bool changed = false;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   struct intel_crtc *intel_crtc;
+   struct

[Intel-gfx] [PATCH v20 00/18] Add NV12 support

2018-04-06 Thread Vidya Srinivas

This patch series is adding NV12 support for Broxton display after rebasing on
latest drm-tip.
Initial series of the patches can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

Previous revision history:
The first version of patches were reviewed when floated by Chandra in 2015
but currently there was a design change with respect to
- the way fb offset is handled
- the way rotation is handled
Current NV12 patch series has been ported as per the
current changes on drm-tip

Review comments from Ville (12th June 2017) have been addressed Review
comments from Clinton A Taylor (7th July 2017) have been addressed

Review comments from Clinton A Taylor (10th July 2017)
have been addressed. Had missed out tested-by/reviewed-by in the 
patches.
Fixed that error in this series.
Review comments from Ville (11th July 2017) addressed.
Review comments from Paauwe, Bob (29th July 2017) addressed.

Update from rev 28 Aug 2017
Rebased the series.
Tested with IGT for rotation, sprite and tiling combinations.
IGT Links:
https://patchwork.kernel.org/patch/9995943/
https://patchwork.kernel.org/patch/9995945/
Review comments by Maarten are addressed in this series.
NV12 enabled for Gen10.
Review comments from Shashank Sharma are addressed.
IGT debug_fs test failure fixed.
Added reviewed-by tag from Shashank Sharma for few patches
Addressed comments from Juha-Pekka Heikkila in few patches
(NV12 not to be supported for SKL)
Adding an additional patch Display WA 827 for underrun during NV12
Adding more WA implementation to see if it helps underruns
Addressed review comments from Ville regarding the planar formats
Added minimum src height for yuv 420 planar formats
Added NV12 in skl_mod_supported
(review comments from Kristian Høgsberg 
Addressed review comments from Ville and Maarten
Re-ordered the series as per Maarten's suggestion

Update from previous series:
Removed the src/dest restrictions

Chandra Konduru (6):
  drm/i915: Set scaler mode for NV12
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Mahesh Kumar (9):
  drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
  drm/i915/skl+: refactor WM calculation for NV12
  drm/i915/skl+: add NV12 in skl_format_to_fourcc
  drm/i915/skl+: support verification of DDB HW state for NV12
  drm/i915/skl+: NV12 related changes for WM
  drm/i915/skl+: pass skl_wm_level struct to wm compute func
  drm/i915/skl+: make sure higher latency level has higher wm value
  drm/i915/skl+: nv12 workaround disable WM level 1-7
  drm/i915/skl: split skl_compute_ddb function

Vidya Srinivas (3):
  drm/i915: Display WA 827
  drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
  drm/i915: Do not do fb src adjustments for NV12

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_atomic.c  |  14 +-
 drivers/gpu/drm/i915/intel_display.c | 156 +++--
 drivers/gpu/drm/i915/intel_drv.h |  13 +-
 drivers/gpu/drm/i915/intel_pm.c  | 438 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  35 ++-
 7 files changed, 482 insertions(+), 189 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v20 04/18] drm/i915/skl+: support verification of DDB HW state for NV12

2018-04-06 Thread Vidya Srinivas

From: Mahesh Kumar 

For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.

v2: Addressed review comments by Maarten.

v3: Addressed review comments by Shashank Sharma.

v4: Adding reviewed by tag from Shashank Sharma

v5: Added reviewed by from Juha-Pekka Heikkila

v6: Rebased the series

Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 51 +---
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3038218..28de533 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2657,7 +2657,7 @@ static int i9xx_format_to_fourcc(int format)
}
 }
 
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
 {
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7310fe..ed79a61 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1612,6 +1612,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
 int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
 int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c051cd3..0f99652 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3825,6 +3825,44 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
 }
 
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+  const enum pipe pipe,
+  const enum plane_id plane_id,
+  struct skl_ddb_allocation *ddb /* out */)
+{
+   u32 val, val2 = 0;
+   int fourcc, pixel_format;
+
+   /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+   if (plane_id == PLANE_CURSOR) {
+   val = I915_READ(CUR_BUF_CFG(pipe));
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   return;
+   }
+
+   val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+   /* No DDB allocated for disabled planes */
+   if (!(val & PLANE_CTL_ENABLE))
+   return;
+
+   pixel_format = val & PLANE_CTL_FORMAT_MASK;
+   fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+   if (fourcc == DRM_FORMAT_NV12) {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val2);
+   skl_ddb_entry_init_from_hw(>uv_plane[pipe][plane_id], val);
+   } else {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   }
+}
+
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
@@ -3841,16 +3879,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_plane_id_on_crtc(crtc, plane_id) {
-   u32 val;
-
-   if (plane_id != PLANE_CURSOR)
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
-   else
-   val = I915_READ(CUR_BUF_CFG(pipe));
-
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id)
+   skl_ddb_get_hw_plane_state(dev_priv, pipe,
+  plane_id, ddb);
 
intel_display_power_put(dev_priv, power_domain);
}
-- 
2.7.4

___
Intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE 
(rev2)
URL   : https://patchwork.freedesktop.org/series/41263/
State : success

== Summary ==

Series 41263v2 drm/i915/execlists: Log fence context & seqno throughout 
GEM_TRACE
https://patchwork.freedesktop.org/api/1.0/series/41263/revisions/2/mbox/

Warning: Kernel 32bit buildtest failed
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8617/build_32bit.log

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:438s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:672s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:591s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
fi-glk-j4005 failed to collect. IGT log at Patchwork_8617/fi-glk-j4005/run0.log

983ee39a4fb441927f2bc64d5874e6c9e585362b drm-tip: 2018y-04m-06d-10h-12m-26s UTC 
integration manifest
ab856b2cd991 drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8617/issues.html
___
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: Enclose for_each_engine_masked macro arguments in parentheses (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Enclose for_each_engine_masked macro arguments in parentheses 
(rev2)
URL   : https://patchwork.freedesktop.org/series/41261/
State : success

== Summary ==

Series 41261v2 drm/i915: Enclose for_each_engine_masked macro arguments in 
parentheses
https://patchwork.freedesktop.org/api/1.0/series/41261/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:508s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:314s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:670s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:593s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:399s

983ee39a4fb441927f2bc64d5874e6c9e585362b drm-tip: 2018y-04m-06d-10h-12m-26s UTC 
integration manifest
b47119c818bc drm/i915: Enclose for_each_engine_masked macro arguments in 
parentheses

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8618/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 12:44:07)
> From: Tvrtko Ursulin 
> 
> Enclose for_each_engine_masked macro arguments in parentheses.
> 
> v2:
>  * Fixup whitespace to satisfy checkpatch.
>  * Likewise reformat to 80 chars.
> 
> Signed-off-by: Tvrtko Ursulin 

Just because the (mask__) does need fixing.

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

[Intel-gfx] [PATCH v20 18/18] drm/i915: Do not do fb src adjustments for NV12

2018-04-06 Thread Vidya Srinivas

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

Credits-to: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d5dad44..68a4344 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -261,6 +261,8 @@ skl_update_plane(struct intel_plane *plane,
crtc_w--;
crtc_h--;
 
+   DRM_ERROR("%x, %d %d %d %d\n", fb->format->format, src_w, src_h, 
crtc_w, crtc_h);
+
spin_lock_irqsave(_priv->uncore.lock, irqflags);
 
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
@@ -1015,6 +1017,9 @@ intel_check_sprite_plane(struct intel_plane *plane,
crtc_w = drm_rect_width(dst);
crtc_h = drm_rect_height(dst);
 
+   if (fb->format->format == DRM_FORMAT_NV12)
+   goto check_plane_surface;
+
if (state->base.visible) {
/* check again in case clipping clamped the results */
hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
@@ -1112,6 +1117,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
 
+check_plane_surface:
if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(crtc_state, state);
if (ret)
-- 
2.7.4

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Only call finish_reset after a prepare_reset (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: Only call finish_reset after a 
prepare_reset (rev2)
URL   : https://patchwork.freedesktop.org/series/41204/
State : failure

== Summary ==

Applying: drm/i915: Only call finish_reset after a prepare_reset
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915: Always assume the GPU reset occurs
Applying: drm/i915: Split out parking from the idle worker for reuse
Applying: drm/i915: Park before resetting the submission backend
error: patch failed: drivers/gpu/drm/i915/i915_gem.c:3132
error: drivers/gpu/drm/i915/i915_gem.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_gem.c
Patch failed at 0004 drm/i915: Park before resetting the submission backend
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH v3] drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Include fence context and seqno in low level tracing so it is easier to
follow flows of individual requests when things go bad.

Also added tracing on the reset side of things.

v2:
 Chris Wilson:
 * Standardize global_seqno and seqno as global.
 * Include current hws seqno in execlists_cancel_port_requests.

v3:
 * Fix port printk format for all builds.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson  # v2
---
 drivers/gpu/drm/i915/i915_request.c |  6 +++---
 drivers/gpu/drm/i915/intel_lrc.c| 22 +-
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 152321655fe6..66976683 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -389,7 +389,7 @@ static void i915_request_retire(struct i915_request 
*request)
struct intel_engine_cs *engine = request->engine;
struct i915_gem_active *active, *next;
 
-   GEM_TRACE("%s fence %llx:%d, global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d, global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
@@ -512,7 +512,7 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
 
-   GEM_TRACE("%s fence %llx:%d -> global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d -> global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  engine->timeline->seqno + 1,
@@ -567,7 +567,7 @@ void __i915_request_unsubmit(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
 
-   GEM_TRACE("%s fence %llx:%d <- global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d <- global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f6631ff11caf..16ea95ff7c51 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -468,10 +468,11 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
 
-   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (current 
%d), prio=%d\n",
+   GEM_TRACE("%s in[%d]:  ctx=%d.%d, global=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name, n,
  port[n].context_id, count,
  rq->global_seqno,
+ rq->fence.context, rq->fence.seqno,
  intel_engine_get_seqno(engine),
  rq_prio(rq));
} else {
@@ -742,6 +743,13 @@ execlists_cancel_port_requests(struct 
intel_engine_execlists * const execlists)
while (num_ports-- && port_isset(port)) {
struct i915_request *rq = port_request(port);
 
+   GEM_TRACE("%s:port%u global=%d (fence %llx:%d), (current %d)\n",
+ rq->engine->name,
+ (unsigned int)(port - execlists->port),
+ rq->global_seqno,
+ rq->fence.context, rq->fence.seqno,
+ intel_engine_get_seqno(rq->engine));
+
GEM_BUG_ON(!execlists->active);
intel_engine_context_out(rq->engine);
 
@@ -817,7 +825,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
 
-   GEM_TRACE("%s\n", engine->name);
+   GEM_TRACE("%s current %d\n",
+ engine->name, intel_engine_get_seqno(engine));
 
/*
 * Before we call engine->cancel_requests(), we should have exclusive
@@ -1014,10 +1023,12 @@ static void execlists_submission_tasklet(unsigned long 
data)
EXECLISTS_ACTIVE_USER));
 
rq = port_unpack(port, );
-   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (current %d), 
prio=%d\n",
+   GEM_TRACE("%s out[0]: ctx=%d.%d, global=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name,
  port->context_id, count,
  rq ? rq->global_seqno : 0,
+ rq ? rq->fence.context : 0,
+ rq ? rq->fence.seqno

[Intel-gfx] [PATCH v20 18/18] drm/i915: Do not do fb src adjustments for NV12

2018-04-06 Thread Vidya Srinivas

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

Credits-to: Maarten Lankhorst 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d5dad44..89845d5 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1015,6 +1015,9 @@ intel_check_sprite_plane(struct intel_plane *plane,
crtc_w = drm_rect_width(dst);
crtc_h = drm_rect_height(dst);
 
+   if (fb->format->format == DRM_FORMAT_NV12)
+   goto check_plane_surface;
+
if (state->base.visible) {
/* check again in case clipping clamped the results */
hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
@@ -1112,6 +1115,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
dst->y1 = crtc_y;
dst->y2 = crtc_y + crtc_h;
 
+check_plane_surface:
if (INTEL_GEN(dev_priv) >= 9) {
ret = skl_check_plane_surface(crtc_state, state);
if (ret)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm/i915: set minimum CD clock to twice the BCLK.

2018-04-06 Thread kbuild test robot

Hi Abhay,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.16 next-20180405]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Abhay-Kumar/drm-i915-set-minimum-CD-clock-to-twice-the-BCLK/20180406-143913
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x001-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_audio.c: In function 
'i915_audio_component_codec_wake_override':
>> drivers/gpu//drm/i915/intel_audio.c:742:21: error: unused variable 
>> 'min_cdclk' [-Werror=unused-variable]
 int current_cdclk, min_cdclk;
^
   cc1: all warnings being treated as errors

vim +/min_cdclk +742 drivers/gpu//drm/i915/intel_audio.c

   736  
   737  static void i915_audio_component_codec_wake_override(struct device 
*kdev,
   738   bool enable)
   739  {
   740  struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
   741  u32 tmp;
 > 742  int current_cdclk, min_cdclk;
   743  
   744  if (!IS_GEN9_BC(dev_priv))
   745  return;
   746  
   747  current_cdclk = i915_audio_component_get_cdclk_freq(kdev);
   748  
   749  /*
   750   * Before probing for HDA Codec we need to make sure
   751   * "The CD clock frequency must be at least twice
   752   * the frequency of the Azalia BCLK."
   753   */
   754  if (INTEL_GEN(dev_priv) >= 9 && current_cdclk <= 192000) {
   755  intel_cdclk_bump(dev_priv);
   756  }
   757  
   758  i915_audio_component_get_power(kdev);
   759  
   760  /*
   761   * Enable/disable generating the codec wake signal, overriding 
the
   762   * internal logic to generate the codec wake to controller.
   763   */
   764  tmp = I915_READ(HSW_AUD_CHICKENBIT);
   765  tmp &= ~SKL_AUD_CODEC_WAKE_SIGNAL;
   766  I915_WRITE(HSW_AUD_CHICKENBIT, tmp);
   767  usleep_range(1000, 1500);
   768  
   769  if (enable) {
   770  tmp = I915_READ(HSW_AUD_CHICKENBIT);
   771  tmp |= SKL_AUD_CODEC_WAKE_SIGNAL;
   772  I915_WRITE(HSW_AUD_CHICKENBIT, tmp);
   773  usleep_range(1000, 1500);
   774  }
   775  
   776  i915_audio_component_put_power(kdev);
   777  }
   778  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/gem_eio: Require context support before creation

2018-04-06 Thread Chris Wilson

gem_context_create() nowadays assumes you have already checked for
context support and asserts for any error. So check first.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105924
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/gem_eio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 9599e73d..1a4659a9 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -703,11 +703,17 @@ igt_main
igt_subtest("in-flight-suspend")
test_inflight_suspend(fd);
 
-   igt_subtest("reset-stress")
-   test_reset_stress(fd, 0);
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(gem_has_contexts(fd));
+   }
 
-   igt_subtest("unwedge-stress")
-   test_reset_stress(fd, TEST_WEDGE);
+   igt_subtest("reset-stress")
+   test_reset_stress(fd, 0);
+
+   igt_subtest("unwedge-stress")
+   test_reset_stress(fd, TEST_WEDGE);
+   }
 
igt_subtest_group {
const struct {
-- 
2.16.3

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

Re: [Intel-gfx] [PATCH igt] igt/gem_eio: Require context support before creation

2018-04-06 Thread Tvrtko Ursulin



On 06/04/2018 10:11, Chris Wilson wrote:

gem_context_create() nowadays assumes you have already checked for
context support and asserts for any error. So check first.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105924
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/gem_eio.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 9599e73d..1a4659a9 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -703,11 +703,17 @@ igt_main
igt_subtest("in-flight-suspend")
test_inflight_suspend(fd);
  
-	igt_subtest("reset-stress")

-   test_reset_stress(fd, 0);
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(gem_has_contexts(fd));
+   }
  
-	igt_subtest("unwedge-stress")

-   test_reset_stress(fd, TEST_WEDGE);
+   igt_subtest("reset-stress")
+   test_reset_stress(fd, 0);
+
+   igt_subtest("unwedge-stress")
+   test_reset_stress(fd, TEST_WEDGE);
+   }
  
  	igt_subtest_group {

const struct {



I am so good at context isolation that I can fix one thing in one stream 
of work, then switch to another stream and repeat the same mistake again. :(


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] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Chris Wilson

Quoting Patchwork (2018-04-06 10:29:45)
> == Series Details ==
> 
> Series: drm/i915: Enclose for_each_engine_masked macro arguments in 
> parentheses
> URL   : https://patchwork.freedesktop.org/series/41261/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> e31cc0477730 drm/i915: Enclose for_each_engine_masked macro arguments in 
> parentheses
> -:22: ERROR:SPACING: space prohibited before that close parenthesis ')'
> #22: FILE: drivers/gpu/drm/i915/i915_drv.h:2153:
> +(tmp__) ? ((engine__) = 
> (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )

It has no mercy!
-Chris
___
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: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Enclose for_each_engine_masked macro arguments in parentheses
URL   : https://patchwork.freedesktop.org/series/41261/
State : failure

== Summary ==

Series 41261v1 drm/i915: Enclose for_each_engine_masked macro arguments in 
parentheses
https://patchwork.freedesktop.org/api/1.0/series/41261/revisions/1/mbox/

 Possible new issues:

Test gem_exec_flush:
Subgroup basic-uc-pro-default:
pass   -> INCOMPLETE (fi-cnl-y3)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:518s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7  
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:433s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:435s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:649s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:433s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:401s

f818c2b87fa1733a6801757f588ca544e105b082 drm-tip: 2018y-04m-06d-07h-06m-57s UTC 
integration manifest
e31cc0477730 drm/i915: Enclose for_each_engine_masked macro arguments in 
parentheses

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8613/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Avoid repeatedly harming the same innocent context

2018-04-06 Thread Tvrtko Ursulin



On 06/04/2018 10:40, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-04-06 10:11:57)


On 30/03/2018 14:18, Chris Wilson wrote:

   if (!wait_for_hang(, prev)) {


This was confusing me a period since I was assuming the seqno check is
against the breadcrumb, but it is actually about the same number written
to a different place. So it actually means
wait_for_request_to_start_executing.


Bonus points for a better name than struct hang.

struct spinner;

spinner_wait_until_active() ?


Maybe just rename the helper to wait_until_running if you feel like it. 
To keep things simple and scope in check.


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 10:54:57)
> From: Tvrtko Ursulin 
> 
> Include fence context and seqno in low level tracing so it is easier to
> follow flows of individual requests when things go bad.
> 
> Also added tracing on the reset side of things.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f6631ff11caf..a5cd698a2e3c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -468,10 +468,11 @@ static void execlists_submit_ports(struct 
> intel_engine_cs *engine)
> desc = execlists_update_context(rq);
> GEM_DEBUG_EXEC(port[n].context_id = 
> upper_32_bits(desc));
>  
> -   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (current 
> %d), prio=%d\n",
> +   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (fence 
> %llx:%d) (current %d), prio=%d\n",

We mix seqno=%d and global_seqno=%d. Please fix my inconsistency. :)

Using seqno is fine as we've standardised on calling the other (fence
x:y).

>   engine->name, n,
>   port[n].context_id, count,
>   rq->global_seqno,
> + rq->fence.context, rq->fence.seqno,
>   intel_engine_get_seqno(engine),
>   rq_prio(rq));
> } else {
> @@ -742,6 +743,10 @@ execlists_cancel_port_requests(struct 
> intel_engine_execlists * const execlists)
> while (num_ports-- && port_isset(port)) {
> struct i915_request *rq = port_request(port);
>  
> +   GEM_TRACE("%s:port%lu fence %llx:%d (current %d)\n",
> + rq->engine->name, port - execlists->port,
> + rq->fence.context, rq->fence.seqno, 
> rq->global_seqno);

Please always keep current == intel_engine_get_seqno(). So _also_ add
seqno=%d.

Hmm, do want to use x=y, or "x: y", or "x y". Again, we might as well
stick to our internal rules for notation. Actually I'd love to adopt a
yaml approach { x: value; y: value }. (But until we have yaml output
throughout, the inconsistency might be annoying ;) Basically I'm
thinking from a scripting aspect, the very least being grep or ^F.

Overall, a very big "yes please" to the improvements.
-Chris
___
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 Documentation patch for batchbuffer submission (rev5)

2018-04-06 Thread Joonas Lahtinen

Merged these (documentation only changes). Thanks for the patches!

Regards, Joonas

Quoting Patchwork (2018-04-06 11:29:26)
> == Series Details ==
> 
> Series: Documentation patch for batchbuffer submission (rev5)
> URL   : https://patchwork.freedesktop.org/series/38433/
> State : failure
> 
> == Summary ==
> 
> Series 38433v5 Documentation patch for batchbuffer submission
> https://patchwork.freedesktop.org/api/1.0/series/38433/revisions/5/mbox/
> 
>  Possible new issues:
> 
> Test gem_sync:
> Subgroup basic-store-all:
> pass   -> DMESG-FAIL (fi-snb-2520m)
> 
>  Known issues:
> 
> Test gem_mmap_gtt:
> Subgroup basic-small-bo-tiledx:
> pass   -> FAIL   (fi-gdg-551) fdo#102575
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> pass   -> FAIL   (fi-cfl-s3) fdo#103481
> Subgroup suspend-read-crc-pipe-c:
> pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951
> Test prime_vgem:
> Subgroup basic-fence-flip:
> fail   -> PASS   (fi-ilk-650) fdo#104008
> 
> fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
> fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
> fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
> fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
> 
> fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
> time:430s
> fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
> time:444s
> fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
> time:379s
> fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
> time:537s
> fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
> time:297s
> fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
> time:514s
> fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
> time:525s
> fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
> time:523s
> fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
> time:512s
> fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
> time:412s
> fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
> time:562s
> fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
> time:514s
> fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
> time:580s
> fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
> time:425s
> fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
> time:319s
> fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
> time:545s
> fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
> time:489s
> fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
> time:407s
> fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
> time:424s
> fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
> time:470s
> fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
> time:438s
> fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
> time:477s
> fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
> time:468s
> fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
> time:508s
> fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
> time:673s
> fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
> time:444s
> fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
> time:542s
> fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
> time:513s
> fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
> time:500s
> fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
> time:432s
> fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
> time:447s
> fi-snb-2520m total:285  pass:244  dwarn:0   dfail:1   fail:0   skip:40  
> time:553s
> fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
> time:406s
> Blacklisted hosts:
> fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
> time:520s
> 
> f818c2b87fa1733a6801757f588ca544e105b082 drm-tip: 2018y-04m-06d-07h-06m-57s 
> UTC integration manifest
> f6316ec9ba3c i915: add a text about what happens at bottom of stack in 
> processing a batchbuffer
> 687d7a2c75ff i915.rst: add link to documentation in i915_gem_execbuffer.c
> a2effe863103 i915.rst: Narration overview on GEM + minor reorder to improve 
> narration
> 
> == Logs ==
> 
> For more details see: 
>

Re: [Intel-gfx] [PATCH] drm/i915: throw __must_check at GEM_WARN_ON

2018-04-06 Thread Joonas Lahtinen

Quoting Matthew Auld (2018-04-04 14:19:04)
> GEM_WARN_ON is intended to be used as:
> 
> if (GEM_WARN_ON(expr))
> ...
> 
> However this isn't clear since we just wrap WARN_ON, therefore throw a
> warning if the result is ignored. For !DRM_I915_DEBUG_GEM builds this
> should already be the case.
> 
> Suggested-by: Jani Nikula 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Jani Nikula 
> Cc: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

I think this would be a worthwhile improvement.

Regards, Joonas

> ---
>  drivers/gpu/drm/i915/i915_gem.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 8922344fc21b..760671119130 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -36,7 +36,14 @@
> BUG(); \
> } \
> } while(0)
> -#define GEM_WARN_ON(expr) WARN_ON(expr)
> +
> +static __always_inline bool __must_check __gem_warn_on(bool v)
> +{
> +   return WARN_ON(v);
> +}
> +
> +/* To be used as: if (GEM_WARN_ON(expr)) */
> +#define GEM_WARN_ON(expr) __gem_warn_on(expr)
>  
>  #define GEM_DEBUG_DECL(var) var
>  #define GEM_DEBUG_EXEC(expr) expr
> -- 
> 2.14.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: throw __must_check at GEM_WARN_ON

2018-04-06 Thread Chris Wilson

Quoting Joonas Lahtinen (2018-04-06 12:29:01)
> Quoting Matthew Auld (2018-04-04 14:19:04)
> > GEM_WARN_ON is intended to be used as:
> > 
> > if (GEM_WARN_ON(expr))
> > ...
> > 
> > However this isn't clear since we just wrap WARN_ON, therefore throw a
> > warning if the result is ignored. For !DRM_I915_DEBUG_GEM builds this
> > should already be the case.
> > 
> > Suggested-by: Jani Nikula 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc: Jani Nikula 
> > Cc: Chris Wilson 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> I think this would be a worthwhile improvement.

At the very least may I beg for the GEM_TRACE output and #expr?
#expr kind of defeats the use of an inline... Or at least requires more
macro magic.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Enclose for_each_engine_masked macro arguments in parentheses.

v2:
 * Fixup whitespace to satisfy checkpatch.
 * Likewise reformat to 80 chars.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..d25713bab416 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2149,8 +2149,10 @@ static inline struct drm_i915_private 
*huc_to_i915(struct intel_huc *huc)
 
 /* Iterator over subset of engines selected by mask */
 #define for_each_engine_masked(engine__, dev_priv__, mask__, tmp__) \
-   for (tmp__ = mask__ & INTEL_INFO(dev_priv__)->ring_mask;\
-tmp__ ? (engine__ = (dev_priv__)->engine[__mask_next_bit(tmp__)]), 
1 : 0; )
+   for ((tmp__) = (mask__) & INTEL_INFO(dev_priv__)->ring_mask; \
+(tmp__) ? \
+((engine__) = (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : \
+0;)
 
 enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
-- 
2.14.1

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

[Intel-gfx] [PATCH] drm/i915/selftests: Rename wait_for_hang() to wait_until_running()

2018-04-06 Thread Chris Wilson

Tvrtko mentioned that wait_for_hang() was confusing as it does not
actually wait for the aforementioned hang, just until the request is
running and we are *ready* to inject a hang. A quick
s/wait_for_hang/wait_until_running/ removes that confusion without
having to rethink the naming scheme, immediately at least.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index d03abe7f8a53..8650853c8cb3 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -322,7 +322,7 @@ static void hang_fini(struct hang *h)
flush_test(h->i915, I915_WAIT_LOCKED);
 }
 
-static bool wait_for_hang(struct hang *h, struct i915_request *rq)
+static bool wait_until_running(struct hang *h, struct i915_request *rq)
 {
return !(wait_for_us(i915_seqno_passed(hws_seqno(h, rq),
   rq->fence.seqno),
@@ -504,7 +504,7 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
__i915_request_add(rq, true);
mutex_unlock(>drm.struct_mutex);
 
-   if (!wait_for_hang(, rq)) {
+   if (!wait_until_running(, rq)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
 
pr_err("%s: Failed to start request %x, 
at %x\n",
@@ -747,7 +747,7 @@ static int __igt_reset_engines(struct drm_i915_private 
*i915,
__i915_request_add(rq, true);
mutex_unlock(>drm.struct_mutex);
 
-   if (!wait_for_hang(, rq)) {
+   if (!wait_until_running(, rq)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
 
pr_err("%s: Failed to start request %x, 
at %x\n",
@@ -935,7 +935,7 @@ static int igt_wait_reset(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
 
-   if (!wait_for_hang(, rq)) {
+   if (!wait_until_running(, rq)) {
struct drm_printer p = drm_info_printer(i915->drm.dev);
 
pr_err("%s: Failed to start request %x, at %x\n",
@@ -1066,7 +1066,7 @@ static int igt_reset_queue(void *arg)
goto fini;
}
 
-   if (!wait_for_hang(, prev)) {
+   if (!wait_until_running(, prev)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
 
pr_err("%s(%s): Failed to start request %x, at 
%x\n",
@@ -1177,7 +1177,7 @@ static int igt_handle_error(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
 
-   if (!wait_for_hang(, rq)) {
+   if (!wait_until_running(, rq)) {
struct drm_printer p = drm_info_printer(i915->drm.dev);
 
pr_err("%s: Failed to start request %x, at %x\n",
-- 
2.16.3

___
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/5] drm/i915/icl: Add reset control register changes (rev3)

2018-04-06 Thread Patchwork

== Series Details ==

Series: series starting with [1/5] drm/i915/icl: Add reset control register 
changes (rev3)
URL   : https://patchwork.freedesktop.org/series/41214/
State : success

== Summary ==

Series 41214v3 series starting with [1/5] drm/i915/icl: Add reset control 
register changes
https://patchwork.freedesktop.org/api/1.0/series/41214/revisions/3/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:519s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:521s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:313s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:677s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:597s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:398s

983ee39a4fb441927f2bc64d5874e6c9e585362b drm-tip: 2018y-04m-06d-10h-12m-26s UTC 
integration manifest
0472e52dace0 drm/i915/icl: Enable RC6 and RPS in Gen11
be4a43139251 drm/i915/icl: Deal with GT INT DW correctly
9c914d23015b drm/i915/icl: Handle RPS interrupts correctly for Gen11
610cea61c2b7 drm/i915/icl: Use hw engine class, instance to find irq handler
27c0b6b10865 drm/i915/icl: Add reset control register changes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8614/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Rename wait_for_hang() to wait_until_running()

2018-04-06 Thread Tvrtko Ursulin



On 06/04/2018 11:09, Chris Wilson wrote:

Tvrtko mentioned that wait_for_hang() was confusing as it does not
actually wait for the aforementioned hang, just until the request is
running and we are *ready* to inject a hang. A quick
s/wait_for_hang/wait_until_running/ removes that confusion without
having to rethink the naming scheme, immediately at least.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index d03abe7f8a53..8650853c8cb3 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -322,7 +322,7 @@ static void hang_fini(struct hang *h)
flush_test(h->i915, I915_WAIT_LOCKED);
  }
  
-static bool wait_for_hang(struct hang *h, struct i915_request *rq)

+static bool wait_until_running(struct hang *h, struct i915_request *rq)
  {
return !(wait_for_us(i915_seqno_passed(hws_seqno(h, rq),
   rq->fence.seqno),
@@ -504,7 +504,7 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
__i915_request_add(rq, true);
mutex_unlock(>drm.struct_mutex);
  
-if (!wait_for_hang(, rq)) {

+   if (!wait_until_running(, rq)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
  
  	pr_err("%s: Failed to start request %x, at %x\n",

@@ -747,7 +747,7 @@ static int __igt_reset_engines(struct drm_i915_private 
*i915,
__i915_request_add(rq, true);
mutex_unlock(>drm.struct_mutex);
  
-if (!wait_for_hang(, rq)) {

+   if (!wait_until_running(, rq)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
  
  	pr_err("%s: Failed to start request %x, at %x\n",

@@ -935,7 +935,7 @@ static int igt_wait_reset(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
  
-	if (!wait_for_hang(, rq)) {

+   if (!wait_until_running(, rq)) {
struct drm_printer p = drm_info_printer(i915->drm.dev);
  
  		pr_err("%s: Failed to start request %x, at %x\n",

@@ -1066,7 +1066,7 @@ static int igt_reset_queue(void *arg)
goto fini;
}
  
-			if (!wait_for_hang(, prev)) {

+   if (!wait_until_running(, prev)) {
struct drm_printer p = 
drm_info_printer(i915->drm.dev);
  
  pr_err("%s(%s): Failed to start request %x, at %x\n",

@@ -1177,7 +1177,7 @@ static int igt_handle_error(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
  
-	if (!wait_for_hang(, rq)) {

+   if (!wait_until_running(, rq)) {
struct drm_printer p = drm_info_printer(i915->drm.dev);
  
  		pr_err("%s: Failed to start request %x, at %x\n",




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 v2] drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 12:36:51)
> From: Tvrtko Ursulin 
> 
> Include fence context and seqno in low level tracing so it is easier to
> follow flows of individual requests when things go bad.
> 
> Also added tracing on the reset side of things.
> 
> v2:
>  Chris Wilson:
>  * Standardize global_seqno and seqno as global.
>  * Include current hws seqno in execlists_cancel_port_requests.
> 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for Documentation patch for batchbuffer submission (rev5)

2018-04-06 Thread Patchwork

== Series Details ==

Series: Documentation patch for batchbuffer submission (rev5)
URL   : https://patchwork.freedesktop.org/series/38433/
State : failure

== Summary ==

Series 38433v5 Documentation patch for batchbuffer submission
https://patchwork.freedesktop.org/api/1.0/series/38433/revisions/5/mbox/

 Possible new issues:

Test gem_sync:
Subgroup basic-store-all:
pass   -> DMESG-FAIL (fi-snb-2520m)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> FAIL   (fi-cfl-s3) fdo#103481
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:525s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:562s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:319s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:438s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:673s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:513s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:285  pass:244  dwarn:0   dfail:1   fail:0   skip:40  
time:553s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:406s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:520s

f818c2b87fa1733a6801757f588ca544e105b082 drm-tip: 2018y-04m-06d-07h-06m-57s UTC 
integration manifest
f6316ec9ba3c i915: add a text about what happens at bottom of stack in 
processing a batchbuffer
687d7a2c75ff i915.rst: add link to documentation in i915_gem_execbuffer.c
a2effe863103 i915.rst: Narration overview on GEM + minor reorder to improve 
narration

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8611/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Enclose for_each_engine_masked macro arguments in parentheses
URL   : https://patchwork.freedesktop.org/series/41261/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e31cc0477730 drm/i915: Enclose for_each_engine_masked macro arguments in 
parentheses
-:22: ERROR:SPACING: space prohibited before that close parenthesis ')'
#22: FILE: drivers/gpu/drm/i915/i915_drv.h:2153:
+(tmp__) ? ((engine__) = 
(dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )

total: 1 errors, 0 warnings, 0 checks, 10 lines checked

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

Re: [Intel-gfx] [PATCH] drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 10:24:17)
> From: Tvrtko Ursulin 
> 
> Enclose for_each_engine_masked macro arguments in parentheses.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5373b171bb96..79dc715db26b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2149,8 +2149,8 @@ static inline struct drm_i915_private 
> *huc_to_i915(struct intel_huc *huc)
>  
>  /* Iterator over subset of engines selected by mask */
>  #define for_each_engine_masked(engine__, dev_priv__, mask__, tmp__) \
> -   for (tmp__ = mask__ & INTEL_INFO(dev_priv__)->ring_mask;\
> -tmp__ ? (engine__ = 
> (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )
> +   for ((tmp__) = (mask__) & INTEL_INFO(dev_priv__)->ring_mask; \
> +(tmp__) ? ((engine__) = 
> (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )

engine__ is a rhs, it can't have side-effects. Nor tmp__. Doesn't
enclosing in () just make the error even more opaque?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Chris Wilson

Quoting Chris Wilson (2018-04-06 10:29:36)
> Quoting Tvrtko Ursulin (2018-04-06 10:24:17)
> > From: Tvrtko Ursulin 
> > 
> > Enclose for_each_engine_masked macro arguments in parentheses.
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5373b171bb96..79dc715db26b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2149,8 +2149,8 @@ static inline struct drm_i915_private 
> > *huc_to_i915(struct intel_huc *huc)
> >  
> >  /* Iterator over subset of engines selected by mask */
> >  #define for_each_engine_masked(engine__, dev_priv__, mask__, tmp__) \
> > -   for (tmp__ = mask__ & INTEL_INFO(dev_priv__)->ring_mask;\
> > -tmp__ ? (engine__ = 
> > (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )
> > +   for ((tmp__) = (mask__) & INTEL_INFO(dev_priv__)->ring_mask; \
> > +(tmp__) ? ((engine__) = 
> > (dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )
> 
> engine__ is a rhs, it can't have side-effects. Nor tmp__. Doesn't
> enclosing in () just make the error even more opaque?

Lhs. Lhs! I'll be back after coffee.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Include fence context and seqno in low level tracing so it is easier to
follow flows of individual requests when things go bad.

Also added tracing on the reset side of things.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f6631ff11caf..a5cd698a2e3c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -468,10 +468,11 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
 
-   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (current 
%d), prio=%d\n",
+   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name, n,
  port[n].context_id, count,
  rq->global_seqno,
+ rq->fence.context, rq->fence.seqno,
  intel_engine_get_seqno(engine),
  rq_prio(rq));
} else {
@@ -742,6 +743,10 @@ execlists_cancel_port_requests(struct 
intel_engine_execlists * const execlists)
while (num_ports-- && port_isset(port)) {
struct i915_request *rq = port_request(port);
 
+   GEM_TRACE("%s:port%lu fence %llx:%d (current %d)\n",
+ rq->engine->name, port - execlists->port,
+ rq->fence.context, rq->fence.seqno, rq->global_seqno);
+
GEM_BUG_ON(!execlists->active);
intel_engine_context_out(rq->engine);
 
@@ -817,7 +822,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
 
-   GEM_TRACE("%s\n", engine->name);
+   GEM_TRACE("%s current %d\n",
+ engine->name, intel_engine_get_seqno(engine));
 
/*
 * Before we call engine->cancel_requests(), we should have exclusive
@@ -1014,10 +1020,12 @@ static void execlists_submission_tasklet(unsigned long 
data)
EXECLISTS_ACTIVE_USER));
 
rq = port_unpack(port, );
-   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (current %d), 
prio=%d\n",
+   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name,
  port->context_id, count,
  rq ? rq->global_seqno : 0,
+ rq ? rq->fence.context : 0,
+ rq ? rq->fence.seqno : 0,
  intel_engine_get_seqno(engine),
  rq ? rq_prio(rq) : 0);
 
@@ -1745,8 +1753,9 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
struct intel_context *ce;
unsigned long flags;
 
-   GEM_TRACE("%s seqno=%x\n",
- engine->name, request ? request->global_seqno : 0);
+   GEM_TRACE("%s seqno=%x current=%d\n",
+ engine->name, request ? request->global_seqno : 0,
+ intel_engine_get_seqno(engine));
 
/* See execlists_cancel_requests() for the irq/spinlock split. */
local_irq_save(flags);
-- 
2.14.1

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

Re: [Intel-gfx] [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

2018-04-06 Thread Chris Wilson

Quoting Jordan Crouse (2018-04-05 23:06:53)
> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
> > The i915 DRM driver very cleverly used ascii85 encoding for their
> > GPU state file. Move the encode functions to a general header file to
> > support other drivers that might be interested in the same
> > functionality.
> 
> In a previous version of this patch, Chris asked what tree I wanted this 
> applied
> to, and the answer is: I'm not sure?  I'm hoping that Rob will be cool with
> picking the rest up for msm-next for 4.18 but I'm okay with putting this
> particular patch wherever it is easiest for the maintainers.

We are a bit late to sneak it into the 4.17 drm base via i915. I don't
anticipate any problems (for i915) with this patch going in through
msm-next, so happy to have it land there and percolate back to i915 3
months later.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/icl: Add reset control register changes (rev3)

2018-04-06 Thread Patchwork

== Series Details ==

Series: series starting with [1/5] drm/i915/icl: Add reset control register 
changes (rev3)
URL   : https://patchwork.freedesktop.org/series/41214/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
27c0b6b10865 drm/i915/icl: Add reset control register changes
-:68: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#68: FILE: drivers/gpu/drm/i915/intel_uncore.c:1926:
+  unsigned engine_mask)

total: 0 errors, 1 warnings, 0 checks, 93 lines checked
610cea61c2b7 drm/i915/icl: Use hw engine class, instance to find irq handler
9c914d23015b drm/i915/icl: Handle RPS interrupts correctly for Gen11
be4a43139251 drm/i915/icl: Deal with GT INT DW correctly
-:84: WARNING:TYPO_SPELLING: 'succesfully' may be misspelled - perhaps 
'successfully'?
#84: FILE: drivers/gpu/drm/i915/i915_irq.c:269:
+* to) recover from this succesfully, we need to clear

total: 0 errors, 1 warnings, 0 checks, 157 lines checked
0472e52dace0 drm/i915/icl: Enable RC6 and RPS in Gen11

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

[Intel-gfx] [PATCH v2] drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Include fence context and seqno in low level tracing so it is easier to
follow flows of individual requests when things go bad.

Also added tracing on the reset side of things.

v2:
 Chris Wilson:
 * Standardize global_seqno and seqno as global.
 * Include current hws seqno in execlists_cancel_port_requests.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_request.c |  6 +++---
 drivers/gpu/drm/i915/intel_lrc.c| 21 -
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 152321655fe6..66976683 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -389,7 +389,7 @@ static void i915_request_retire(struct i915_request 
*request)
struct intel_engine_cs *engine = request->engine;
struct i915_gem_active *active, *next;
 
-   GEM_TRACE("%s fence %llx:%d, global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d, global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
@@ -512,7 +512,7 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
 
-   GEM_TRACE("%s fence %llx:%d -> global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d -> global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  engine->timeline->seqno + 1,
@@ -567,7 +567,7 @@ void __i915_request_unsubmit(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
 
-   GEM_TRACE("%s fence %llx:%d <- global_seqno %d, current %d\n",
+   GEM_TRACE("%s fence %llx:%d <- global=%d, current %d\n",
  engine->name,
  request->fence.context, request->fence.seqno,
  request->global_seqno,
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f6631ff11caf..6ef53ab43514 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -468,10 +468,11 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
 
-   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (current 
%d), prio=%d\n",
+   GEM_TRACE("%s in[%d]:  ctx=%d.%d, global=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name, n,
  port[n].context_id, count,
  rq->global_seqno,
+ rq->fence.context, rq->fence.seqno,
  intel_engine_get_seqno(engine),
  rq_prio(rq));
} else {
@@ -742,6 +743,12 @@ execlists_cancel_port_requests(struct 
intel_engine_execlists * const execlists)
while (num_ports-- && port_isset(port)) {
struct i915_request *rq = port_request(port);
 
+   GEM_TRACE("%s:port%lu global=%d (fence %llx:%d), (current 
%d)\n",
+ rq->engine->name, port - execlists->port,
+ rq->global_seqno,
+ rq->fence.context, rq->fence.seqno,
+ intel_engine_get_seqno(rq->engine));
+
GEM_BUG_ON(!execlists->active);
intel_engine_context_out(rq->engine);
 
@@ -817,7 +824,8 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
 
-   GEM_TRACE("%s\n", engine->name);
+   GEM_TRACE("%s current %d\n",
+ engine->name, intel_engine_get_seqno(engine));
 
/*
 * Before we call engine->cancel_requests(), we should have exclusive
@@ -1014,10 +1022,12 @@ static void execlists_submission_tasklet(unsigned long 
data)
EXECLISTS_ACTIVE_USER));
 
rq = port_unpack(port, );
-   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (current %d), 
prio=%d\n",
+   GEM_TRACE("%s out[0]: ctx=%d.%d, global=%d (fence 
%llx:%d) (current %d), prio=%d\n",
  engine->name,
  port->context_id, count,
  rq ? rq->global_seqno : 0,
+ rq ? rq->fence.context : 0,
+ rq ? rq->fence.seqno : 0,
  intel_engine_get_seqno(engine),
  rq ? rq_prio(rq) : 0);
 
@@ -1745,8

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE
URL   : https://patchwork.freedesktop.org/series/41263/
State : warning

== Summary ==

Series 41263v1 drm/i915/execlists: Log fence context & seqno throughout 
GEM_TRACE
https://patchwork.freedesktop.org/api/1.0/series/41263/revisions/1/mbox/

Warning: Kernel 32bit buildtest failed
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8615/build_32bit.log

 Possible new issues:

Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:550s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:518s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:519s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:513s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:313s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:633s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:451s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:556s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:404s

983ee39a4fb441927f2bc64d5874e6c9e585362b drm-tip: 2018y-04m-06d-10h-12m-26s UTC 
integration manifest
de07da870247 drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8615/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix memory leak in intel_hdcp auth

2018-04-06 Thread Jani Nikula

On Thu, 05 Apr 2018, "Srivatsa, Anusha"  wrote:
> Earlier, I responded to the wrong version of the patch :(
> Apologies.
>
>>-Original Message-
>>From: Sripada, Radhakrishna
>>Sent: Wednesday, April 4, 2018 4:00 PM
>>To: intel-gfx@lists.freedesktop.org
>>Cc: Sripada, Radhakrishna ; Jani Nikula
>>; Srivatsa, Anusha 
>>Subject: [PATCH v2] drm/i915: Fix memory leak in intel_hdcp auth
>>
>>Static code analysis tool reported memory leak in intel_hdcp_auth_downstream.
>>Fixing the memory leak.
>>
>>v2: Rebase, move free to a cleanup label(Jani)
>>
>>Cc: Jani Nikula 
>>Cc: Anusha Srivatsa 
>>Signed-off-by: Radhakrishna Sripada 
> Reviewed-by: Anusha Srivatsa 

Thanks for the patch and the review, pushed to dinq.

BR,
Jani.

>
>>---
>> drivers/gpu/drm/i915/intel_hdcp.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>>b/drivers/gpu/drm/i915/intel_hdcp.c
>>index 98a9c81e2dc1..2db5da550a1c 100644
>>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>>@@ -435,7 +435,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
>>*intel_dig_port,
>>
>>  ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
>>  if (ret)
>>- return ret;
>>+ goto err;
>>
>>  /*
>>   * When V prime mismatches, DP Spec mandates re-read of @@ -451,12
>>+451,15 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
>>*intel_dig_port,
>>
>>  if (i == tries) {
>>  DRM_ERROR("V Prime validation failed.(%d)\n", ret);
>>- return ret;
>>+ goto err;
>>  }
>>
>>  DRM_DEBUG_KMS("HDCP is enabled (%d downstream devices)\n",
>>num_downstream);
>>- return 0;
>>+ ret = 0;
>>+err:
>>+ kfree(ksv_fifo);
>>+ return ret;
>> }
>>
>> /* Implements Part 1 of the HDCP authorization procedure */
>>--
>>2.9.3
>

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

[Intel-gfx] [PATCH v5 2/3] i915.rst: add link to documentation in i915_gem_execbuffer.c

2018-04-06 Thread kevin . rogovin

From: Kevin Rogovin 

Add the documentation of "DOC: User command execution" of
i915_gem_execbuffer.c into a new section in i915.rst.

Signed-off-by: Kevin Rogovin 
Reviewed-by: Joonas Lahtinen 

---
 Documentation/gpu/i915.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index cd2d796d23dd..34d22f275708 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -364,6 +364,12 @@ Batchbuffer Pools
 .. kernel-doc:: drivers/gpu/drm/i915/i915_gem_batch_pool.c
:internal:
 
+User Batchbuffer Execution
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_execbuffer.c
+   :doc: User command execution
+
 Logical Rings, Logical Ring Contexts and Execlists
 --
 
-- 
2.16.2

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

[Intel-gfx] [PATCH v5 1/3] i915.rst: Narration overview on GEM + minor reorder to improve narration

2018-04-06 Thread kevin . rogovin

From: Kevin Rogovin 

Add a narration to i915.rst about Intel GEN GPU's: engines,
driver context and relocation.

v5:
  More type fixes.
  Flow bullet list so lines are not too long.

Signed-off-by: Kevin Rogovin 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Mika Kuoppala 
---
 Documentation/gpu/i915.rst | 120 -
 1 file changed, 97 insertions(+), 23 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 7ecad7134677..cd2d796d23dd 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -249,6 +249,103 @@ Memory Management and Command Submission
 This sections covers all things related to the GEM implementation in the
 i915 driver.
 
+Intel GPU Basics
+
+
+An Intel GPU has multiple engines. There are several engine types.
+
+- RCS engine is for rendering 3D and performing compute, this is named
+  `I915_EXEC_RENDER` in user space.
+- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user
+  space.
+- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD`
+  in user space
+- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user
+  space.
+- The enumeration `I915_EXEC_DEFAULT` does not refer to specific engine;
+  instead it is to be used by user space to specify a default rendering
+  engine (for 3D) that may or may not be the same as RCS.
+
+The Intel GPU family is a family of integrated GPU's using Unified
+Memory Access. For having the GPU "do work", user space will feed the
+GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`
+or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will
+instruct the GPU to perform work (for example rendering) and that work
+needs memory from which to read and memory to which to write. All memory
+is encapsulated within GEM buffer objects (usually created with the ioctl
+`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU
+to create will also list all GEM buffer objects that the batchbuffer reads
+and/or writes. For implementation details of memory management see
+`GEM BO Management Implementation Details`_.
+
+The i915 driver allows user space to create a context via the ioctl
+`DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit
+integer. Such a context should be viewed by user-space as -loosely-
+analogous to the idea of a CPU process of an operating system. The i915
+driver guarantees that commands issued to a fixed context are to be
+executed so that writes of a previously issued command are seen by
+reads of following commands. Actions issued between different contexts
+(even if from the same file descriptor) are NOT given that guarantee
+and the only way to synchronize across contexts (even from the same
+file descriptor) is through the use of fences. At least as far back as
+Gen4, also have that a context carries with it a GPU HW context;
+the HW context is essentially (most of atleast) the state of a GPU.
+In addition to the ordering guarantees, the kernel will restore GPU
+state via HW context when commands are issued to a context, this saves
+user space the need to restore (most of atleast) the GPU state at the
+start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer
+work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
+to identify what context to use with the command.
+
+The GPU has its own memory management and address space. The kernel
+driver maintains the memory translation table for the GPU. For older
+GPUs (i.e. those before Gen8), there is a single global such translation
+table, a global Graphics Translation Table (GTT). For newer generation
+GPUs each context has its own translation table, called Per-Process
+Graphics Translation Table (PPGTT). Of important note, is that although
+PPGTT is named per-process it is actually per context. When user space
+submits a batchbuffer, the kernel walks the list of GEM buffer objects
+used by the batchbuffer and guarantees that not only is the memory of
+each such GEM buffer object resident but it is also present in the
+(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT,
+then it is given an address. Two consequences of this are: the kernel
+needs to edit the batchbuffer submitted to write the correct value of
+the GPU address when a GEM BO is assigned a GPU address and the kernel
+might evict a different GEM BO from the (PP)GTT to make address room
+for another GEM BO. Consequently, the ioctls submitting a batchbuffer
+for execution also include a list of all locations within buffers that
+refer to GPU-addresses so that the kernel can edit the buffer correctly.
+This process is dubbed relocation.
+
+GEM BO Management Implementation Details
+
+
+.. kernel-doc::

[Intel-gfx] [PATCH v5 3/3] i915: add a text about what happens at bottom of stack in processing a batchbuffer

2018-04-06 Thread kevin . rogovin

From: Kevin Rogovin 

Now that "DOC: User command execution" of i915_gem_execbuffer.c is included
in the i915.rst, it is benecifial (for new developers) to read what happens
at the bottom of the driver stack (in terms of bytes written to be read
by the GPU) when processing a user-space batchbuffer.

v5:
  Typo correction of lacking double tick.

Signed-off-by: Kevin Rogovin 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8c170db8495d..407a4a8ec61e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -81,6 +81,35 @@ enum {
  * but this remains just a hint as the kernel may choose a new location for
  * any object in the future.
  *
+ * At the level of talking to the hardware, submitting a batchbuffer for the
+ * GPU to execute is to add content to a buffer from which the HW
+ * command streamer is reading.
+ *
+ * 1. Add a command to load the HW context. For Logical Ring Contexts, i.e.
+ *Execlists, this command is not placed on the same buffer as the
+ *remaining items.
+ *
+ * 2. Add a command to invalidate caches to the buffer.
+ *
+ * 3. Add a batchbuffer start command to the buffer; the start command is
+ *essentially a token together with the GPU address of the batchbuffer
+ *to be executed.
+ *
+ * 4. Add a pipeline flush to the buffer.
+ *
+ * 5. Add a memory write command to the buffer to record when the GPU
+ *is done executing the batchbuffer. The memory write writes the
+ *global sequence number of the request, ``i915_request::global_seqno``;
+ *the i915 driver uses the current value in the register to determine
+ *if the GPU has completed the batchbuffer.
+ *
+ * 6. Add a user interrupt command to the buffer. This command instructs
+ *the GPU to issue an interrupt when the command, pipeline flush and
+ *memory write are completed.
+ *
+ * 7. Inform the hardware of the additional commands added to the buffer
+ *(by updating the tail pointer).
+ *
  * Processing an execbuf ioctl is conceptually split up into a few phases.
  *
  * 1. Validation - Ensure all the pointers, handles and flags are valid.
-- 
2.16.2

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

[Intel-gfx] [PATCH v5 0/3] Documentation patch for batchbuffer submission

2018-04-06 Thread kevin . rogovin

From: Kevin Rogovin 

v5:
   In interest of getting reviewed patches in sonner, last two patches
   dropped for a later series.

   Permute patch order of 2 and 3 (this is what the v4 series should
   have had).

v4:
   Drop some details from narration to provide better focus.
   (suggested/requested by Chris Wilson)

   Spelling and grammar fixes.
   (errors caught by Tvrtko Ursuli)

   Move "at the bottom" details to part of documentation in
   i915_gem_execbuffer.c.
   (suggested by Chris Wilson)

   Place additional documentation of intel_engine_cs function
   pointers to inlined in struct.

   Fix documentation error about lazy creation of intel_ringbuffer
   and backing store in intel_lrc.c.
   (Caught by Chris Wilson)

v3:
   More documentation: emphasize that handling of batchbuffer
   requests creates a request struct that is added to the
   dependency tree and that the inform to the hardware that
   there is new data on a ringbuffer is deferred until dependencies
   are satsified.

   Break patch into more digestable chunks.  

v2:
   More documentation: intel_ringbuffer, sequence number.
   Expose to i915.rst existing documentation

   Call out GEM_EXECBUFFER as deprecated.
   Place code detailed documentation in source files.
   Call out INTEL_EXEC_RENDER.
   Reorder text to make it more readable.
   Refer to Command Buffer Parser instead of Batchbuffer Parser.
   (suggested by Joonas Lahtinen)

Kevin Rogovin (3):
  i915.rst: Narration overview on GEM + minor reorder to improve
narration
  i915.rst: add link to documentation in i915_gem_execbuffer.c
  i915: add a text about what happens at bottom of stack in processing a
batchbuffer

 Documentation/gpu/i915.rst | 126 +++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  29 +++
 2 files changed, 132 insertions(+), 23 deletions(-)

-- 
2.16.2

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Avoid repeatedly harming the same innocent context

2018-04-06 Thread Tvrtko Ursulin



On 30/03/2018 14:18, Chris Wilson wrote:

We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrumb.  This is really only a problem for the selftest as
normally there is a large interlude between resets (hangcheck), or we
focus on resetting just one engine and so avoid repeatedly resetting
innocents.

Something to try would be a preempt-to-idle to quiesce the engine before
reset, so that innocent contexts would be spared the reset.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michał Winiarski 
CC: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_drv.c  |  3 ++
  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 48 ++--
  2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d354627882e3..684060ed8db6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1886,6 +1886,8 @@ void i915_reset(struct drm_i915_private *i915)
int ret;
int i;
  
+	GEM_TRACE("flags=%lx\n", error->flags);

+
might_sleep();
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
@@ -2016,6 +2018,7 @@ int i915_reset_engine(struct intel_engine_cs *engine, 
const char *msg)
struct i915_request *active_request;
int ret;
  
+	GEM_TRACE("%s flags=%lx\n", engine->name, error->flags);

GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, >flags));
  
  	active_request = i915_gem_reset_prepare_engine(engine);

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 9e4e0ad62724..122a32e0a69d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -979,6 +979,23 @@ static int igt_wait_reset(void *arg)
return err;
  }
  
+static int wait_for_others(struct drm_i915_private *i915,

+   struct intel_engine_cs *exclude)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, i915, id) { > +  if (engine == 
exclude)> +continue;


Bike-shedder in me says:

for_each_engine_masked(engine, i915, ~BIT(exclude->id), id)

:)

Although for_each_engine_masked failed to enclose its arguments in 
parentheses so never mind.



+
+   if (wait_for(intel_engine_is_idle(engine), 10))
+   return -EIO;
+   }
+
+   return 0;
+}
+
  static int igt_reset_queue(void *arg)
  {
struct drm_i915_private *i915 = arg;
@@ -1027,13 +1044,36 @@ static int igt_reset_queue(void *arg)
i915_request_get(rq);
__i915_request_add(rq, true);
  
+			/*

+* XXX We don't handle resetting the kernel context
+* very well. If we trigger a device reset twice in
+* quick succession while the kernel context is
+* executing, we may end up skipping the breadcrumb.
+* This is really only a problem for the selftest as
+* normally there is a large interlude between resets
+* (hangcheck), or we focus on resetting just one
+* engine and so avoid repeatedly resetting innocents.
+*/
+   err = wait_for_others(i915, engine);
+   if (err) {
+   pr_err("%s(%s): Failed to idle other inactive 
engines after device reset\n",
+  __func__, engine->name);
+   i915_request_put(rq);
+   i915_request_put(prev);
+
+   GEM_TRACE_DUMP();
+   i915_gem_set_wedged(i915);
+   goto fini;
+   }
+
if (!wait_for_hang(, prev)) {


This was confusing me a period since I was assuming the seqno check is 
against the breadcrumb, but it is actually about the same number written 
to a different place. So it actually means 
wait_for_request_to_start_executing.



struct drm_printer p = 
drm_info_printer(i915->drm.dev);
  
-pr_err("%s: Failed to start request %x, at %x\n",

-  __func__, prev->fence.seqno, 
hws_seqno(, prev));
-   intel_engine_dump(prev->engine, ,
-

Re: [Intel-gfx] [PATCH igt 1/2] lib: Acquire master for pollable spinbatch on gen4/5

2018-04-06 Thread Tvrtko Ursulin



On 05/04/2018 19:47, Chris Wilson wrote:

gen4/5 require a DRM_MASTER to use MI_STORE_DW, make it so.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  lib/igt_dummyload.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 98ab7ac2..ba917ba5 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -31,6 +31,7 @@
  
  #include "igt_core.h"

  #include "drmtest.h"
+#include "igt_device.h"
  #include "igt_dummyload.h"
  #include "igt_gt.h"
  #include "intel_chipset.h"
@@ -144,8 +145,10 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t 
ctx, unsigned engine,
  
  		igt_assert(!dep);
  
-		if (gen == 4 || gen == 5)

+   if (gen == 4 || gen == 5) {
execbuf->flags |= I915_EXEC_SECURE;
+   igt_require(__igt_device_set_master(fd) == 0);
+   }
  
  		spin->poll_handle = gem_create(fd, 4096);
  



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 igt 2/2] igt/gem_eio: Drop DRM_MASTER so we can reacquire it in the subtests

2018-04-06 Thread Tvrtko Ursulin



On 05/04/2018 19:47, Chris Wilson wrote:

As we reopen the fd for each subtest, and we need a DRM_MASTER, we need
to drop master on the original before we are allowed to claim DRM_MASTER
on the second.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/gem_eio.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 9599e73d..66d8c18a 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -41,6 +41,7 @@
  #include 
  
  #include "igt.h"

+#include "igt_device.h"
  #include "igt_sysfs.h"
  #include "sw_sync.h"
  
@@ -674,6 +675,7 @@ igt_main
  
  	igt_fixture {

fd = drm_open_driver(DRIVER_INTEL);
+   igt_device_drop_master(fd);



Is it master by default? I can't spot a place which would set master 
either in igt/lib/ or in drm.


But in any case, should we have gem_reopen_driver attempt to drop master 
before re-opening? And if it was successful, drop it again after 
re-opening to end up in the same state?


Regards,

Tvrtko

  
  		igt_require(i915_reset_control(true));

igt_force_gpu_reset(fd);



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

Re: [Intel-gfx] [PATCH] drm/i915: Fix audio issue on BXT

2018-04-06 Thread Jani Nikula

On Thu, 05 Apr 2018, "Pandiyan, Dhinakaran"  
wrote:
> On Thu, 2018-04-05 at 22:12 +0530, Gaurav K Singh wrote:
>> On Apollolake, with stress test warm reboot, audio card
>> was not getting enumerated after reboot. This was a
>> spurious issue happening on Apollolake. HW codec and
>> HD audio controller link was going out of sync for which
>> there was a fix in i915 driver but was not getting invoked
>> for BXT. Extending this fix to BXT as well.
>> 
>> Tested on apollolake chromebook by stress test warm reboot
>> with 2500 iterations.
>> 
>> Bspec: 21829
>> 
>
> R-B stands.
>
> Btw, it would be easier to spot this patch and pick this up for merging
> if you did not send this as a reply. I guess that's okay this time?
> Also, a minor nitpick, "drm/i915/audio" would have been a more
> appropriate prefix for the patch subject.

Thanks for the patch and review, pushed to dinq, with the patch title
amended.

Immediately after pushing I realized that this should have been Cc:
stable. Joonas, after v4.17-rc1 is out and you've rebased
drm-intel-fixes on it, please cherry-pick this one with Cc: stable
added.

Thanks,
Jani.


>
>
>
>> Signed-off-by: Gaurav K Singh 
>> Reviewed-by: Dhinakaran Pandiyan 
>> ---
>>  drivers/gpu/drm/i915/intel_audio.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index 709d6ca68074..656f6c931341 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -729,7 +729,7 @@ static void 
>> i915_audio_component_codec_wake_override(struct device *kdev,
>>  struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
>>  u32 tmp;
>>  
>> -if (!IS_GEN9_BC(dev_priv))
>> +if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
>>  return;
>>  
>>  i915_audio_component_get_power(kdev);

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm: i915: Fix audio issue on BXT (rev3)

2018-04-06 Thread Jani Nikula

On Thu, 05 Apr 2018, Patchwork  wrote:
> == Series Details ==
>
> Series: drm: i915: Fix audio issue on BXT (rev3)
> URL   : https://patchwork.freedesktop.org/series/35955/
> State : warning
>
> == Summary ==
>
>  Possible new issues:
>
> Test kms_flip:
> Subgroup flip-vs-modeset-interruptible:
> pass   -> DMESG-WARN (shard-hsw)

This is unrelated.

Jani.

>
>  Known issues:
>
> Test kms_flip:
> Subgroup 2x-dpms-vs-vblank-race:
> pass   -> FAIL   (shard-hsw) fdo#103060 +1
> Subgroup 2x-flip-vs-expired-vblank-interruptible:
> fail   -> PASS   (shard-hsw) fdo#102887 +1
> Subgroup flip-vs-blocking-wf-vblank:
> fail   -> PASS   (shard-hsw) fdo#100368 +2
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-pwrite:
> dmesg-fail -> PASS   (shard-apl) fdo#105685
> Test kms_plane_multiple:
> Subgroup atomic-pipe-a-tiling-x:
> pass   -> FAIL   (shard-snb) fdo#103166
> Test kms_rotation_crc:
> Subgroup sprite-rotation-180:
> pass   -> FAIL   (shard-snb) fdo#103925
>
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#105685 https://bugs.freedesktop.org/show_bug.cgi?id=105685
> fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
> fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
>
> shard-apltotal:3499 pass:1835 dwarn:1   dfail:0   fail:7   skip:1655 
> time:12904s
> shard-hswtotal:3499 pass:1782 dwarn:2   dfail:0   fail:4   skip:1710 
> time:11565s
> shard-snbtotal:3499 pass:1376 dwarn:1   dfail:0   fail:4   skip:2118 
> time:7029s
> Blacklisted hosts:
> shard-kbltotal:3499 pass:1931 dwarn:8   dfail:0   fail:26  skip:1534 
> time:9235s
>
> == Logs ==
>
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8587/shards.html
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH igt 2/2] igt/gem_eio: Drop DRM_MASTER so we can reacquire it in the subtests

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 09:35:41)
> 
> On 05/04/2018 19:47, Chris Wilson wrote:
> > As we reopen the fd for each subtest, and we need a DRM_MASTER, we need
> > to drop master on the original before we are allowed to claim DRM_MASTER
> > on the second.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   tests/gem_eio.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> > index 9599e73d..66d8c18a 100644
> > --- a/tests/gem_eio.c
> > +++ b/tests/gem_eio.c
> > @@ -41,6 +41,7 @@
> >   #include 
> >   
> >   #include "igt.h"
> > +#include "igt_device.h"
> >   #include "igt_sysfs.h"
> >   #include "sw_sync.h"
> >   
> > @@ -674,6 +675,7 @@ igt_main
> >   
> >   igt_fixture {
> >   fd = drm_open_driver(DRIVER_INTEL);
> > + igt_device_drop_master(fd);
> 
> 
> Is it master by default? I can't spot a place which would set master 
> either in igt/lib/ or in drm.

First person to open /dev/dri/cardN gets DRM_MASTER.
 
> But in any case, should we have gem_reopen_driver attempt to drop master 
> before re-opening? And if it was successful, drop it again after 
> re-opening to end up in the same state?

Not sure. I can argue the alternative as well, what if we were testing
authentication and wanted to keep DRM_MASTER and spawn a !MASTER fd.
My first thought was the same, gem_reopen_fd() should try to ensure the
new fd has the same caps as the original, but API they be tricky to rule
out surprises. For me it's easier to say, gem_reopen_fd() follows the
DRM convention in that the second fd will not be DRM_MASTER unless you
play the DRM games. Then you can choose what games to play?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

2018-04-06 Thread kbuild test robot

Hi Ville,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180405]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-arc-Stop-consulting-plane-fb/20180406-155056
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x010-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/debug_locks.h:7,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from include/linux/mutex.h:16,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/cdev.h:5,
from include/drm/drmP.h:36,
from drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:31,
from drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:28:
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c: In function 'vmw_kms_helper_dirty':
>> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has no 
>> member named 'dep_map'
#define lockdep_is_held(lock)  lock_is_held(&(lock)->dep_map)
   ^
   include/asm-generic/bug.h:112:25: note: in definition of macro 'WARN_ON'
 int __ret_warn_on = !!(condition);\
^
>> include/linux/lockdep.h:373:27: note: in expansion of macro 'lockdep_is_held'
  WARN_ON(debug_locks && !lockdep_is_held(l)); \
  ^~~
>> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:2337:4: note: in expansion of macro 
>> 'lockdep_assert_held'
   lockdep_assert_held(>mutex);
   ^~~
--
   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/debug_locks.h:7,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from include/linux/mutex.h:16,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/cdev.h:5,
from include/drm/drmP.h:36,
from drivers/gpu//drm/vmwgfx/vmwgfx_kms.h:31,
from drivers/gpu//drm/vmwgfx/vmwgfx_kms.c:28:
   drivers/gpu//drm/vmwgfx/vmwgfx_kms.c: In function 'vmw_kms_helper_dirty':
>> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has no 
>> member named 'dep_map'
#define lockdep_is_held(lock)  lock_is_held(&(lock)->dep_map)
   ^
   include/asm-generic/bug.h:112:25: note: in definition of macro 'WARN_ON'
 int __ret_warn_on = !!(condition);\
^
>> include/linux/lockdep.h:373:27: note: in expansion of macro 'lockdep_is_held'
  WARN_ON(debug_locks && !lockdep_is_held(l)); \
  ^~~
   drivers/gpu//drm/vmwgfx/vmwgfx_kms.c:2337:4: note: in expansion of macro 
'lockdep_assert_held'
   lockdep_assert_held(>mutex);
   ^~~

vim +/lockdep_assert_held +2337 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

  2289  
  2290  /**
  2291   * vmw_kms_helper_dirty - Helper to build commands and perform actions 
based
  2292   * on a set of cliprects and a set of display units.
  2293   *
  2294   * @dev_priv: Pointer to a device private structure.
  2295   * @framebuffer: Pointer to the framebuffer on which to perform the 
actions.
  2296   * @clips: A set of struct drm_clip_rect. Either this os @vclips must 
be NULL.
  2297   * Cliprects are given in framebuffer coordinates.
  2298   * @vclips: A set of struct drm_vmw_rect cliprects. Either this or 
@clips must
  2299   * be NULL. Cliprects are given in source coordinates.
  2300   * @dest_x: X coordinate offset for the crtc / destination clip rects.
  2301   * @dest_y: Y coordinate offset for the crtc / destination clip rects.
  2302   * @num_clips: Number of cliprects in the @clips or @vclips array.
  2303   * @increment: Integer with which to increment the clip counter when 
looping.
  2304   * Used to skip a predetermined number of clip rects.
  2305   * @dirty: Closure structure. See the description of struct 
vmw_kms_dirty.
  2306   */
  2307  int

[Intel-gfx] ✗ Fi.CI.BAT: failure for Documentation patch for batchbuffer submission (rev5)

2018-04-06 Thread Patchwork

== Series Details ==

Series: Documentation patch for batchbuffer submission (rev5)
URL   : https://patchwork.freedesktop.org/series/38433/
State : failure

== Summary ==

Series 38433v5 Documentation patch for batchbuffer submission
https://patchwork.freedesktop.org/api/1.0/series/38433/revisions/5/mbox/

 Possible new issues:

Test kms_chamelium:
Subgroup common-hpd-after-suspend:
pass   -> INCOMPLETE (fi-skl-6700k2)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-cfl-s3) fdo#100368
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:518s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:541s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:666s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:207  pass:190  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:580s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:402s

f818c2b87fa1733a6801757f588ca544e105b082 drm-tip: 2018y-04m-06d-07h-06m-57s UTC 
integration manifest
4679d125c11f i915: add a text about what happens at bottom of stack in 
processing a batchbuffer
0ddf7fb3e72e i915.rst: add link to documentation in i915_gem_execbuffer.c
13e06f10c553 i915.rst: Narration overview on GEM + minor reorder to improve 
narration

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8612/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 2/2] igt/gem_eio: Drop DRM_MASTER so we can reacquire it in the subtests

2018-04-06 Thread Tvrtko Ursulin



On 06/04/2018 09:51, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-04-06 09:35:41)


On 05/04/2018 19:47, Chris Wilson wrote:

As we reopen the fd for each subtest, and we need a DRM_MASTER, we need
to drop master on the original before we are allowed to claim DRM_MASTER
on the second.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   tests/gem_eio.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 9599e73d..66d8c18a 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -41,6 +41,7 @@
   #include 
   
   #include "igt.h"

+#include "igt_device.h"
   #include "igt_sysfs.h"
   #include "sw_sync.h"
   
@@ -674,6 +675,7 @@ igt_main
   
   igt_fixture {

   fd = drm_open_driver(DRIVER_INTEL);
+ igt_device_drop_master(fd);



Is it master by default? I can't spot a place which would set master
either in igt/lib/ or in drm.


First person to open /dev/dri/cardN gets DRM_MASTER.


Weird. And I missed to spot that magic while browsing around.


But in any case, should we have gem_reopen_driver attempt to drop master
before re-opening? And if it was successful, drop it again after
re-opening to end up in the same state?


Not sure. I can argue the alternative as well, what if we were testing
authentication and wanted to keep DRM_MASTER and spawn a !MASTER fd.
My first thought was the same, gem_reopen_fd() should try to ensure the
new fd has the same caps as the original, but API they be tricky to rule
out surprises. For me it's easier to say, gem_reopen_fd() follows the
DRM convention in that the second fd will not be DRM_MASTER unless you
play the DRM games. Then you can choose what games to play?


Okay, pragmatic response says:

Reviewed-by: Tvrtko Ursulin 

Apologies for causing breakage.

Regards,

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

[Intel-gfx] [PATCH] drm/i915: Enclose for_each_engine_masked macro arguments in parentheses

2018-04-06 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Enclose for_each_engine_masked macro arguments in parentheses.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..79dc715db26b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2149,8 +2149,8 @@ static inline struct drm_i915_private *huc_to_i915(struct 
intel_huc *huc)
 
 /* Iterator over subset of engines selected by mask */
 #define for_each_engine_masked(engine__, dev_priv__, mask__, tmp__) \
-   for (tmp__ = mask__ & INTEL_INFO(dev_priv__)->ring_mask;\
-tmp__ ? (engine__ = (dev_priv__)->engine[__mask_next_bit(tmp__)]), 
1 : 0; )
+   for ((tmp__) = (mask__) & INTEL_INFO(dev_priv__)->ring_mask; \
+(tmp__) ? ((engine__) = 
(dev_priv__)->engine[__mask_next_bit(tmp__)]), 1 : 0; )
 
 enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Avoid repeatedly harming the same innocent context

2018-04-06 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-06 10:11:57)
> 
> On 30/03/2018 14:18, Chris Wilson wrote:
> >   if (!wait_for_hang(, prev)) {
> 
> This was confusing me a period since I was assuming the seqno check is 
> against the breadcrumb, but it is actually about the same number written 
> to a different place. So it actually means 
> wait_for_request_to_start_executing.

Bonus points for a better name than struct hang.

struct spinner;

spinner_wait_until_active() ?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/arc: Stop consulting plane->fb

2018-04-06 Thread Alexey Brodkin

Hi Ville,

On Thu, 2018-04-05 at 22:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We want to stop using plane->fb with atomic driver, so stop looking at
> it.
> 
> I have no idea what this code is trying to achieve. There is no
> corresponding check in the enable path. Also since
> arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
> to assuming that I can just remove the check entirely. There seems
> to be a general shortage of .atomic_check() in this driver...
> 
> Cc: Alexey Brodkin 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

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

[Intel-gfx] [PATCH 4/5] drm/i915/icl: Deal with GT INT DW correctly

2018-04-06 Thread Mika Kuoppala

From: Oscar Mateo 

BSpec says:

"Second level interrupt events are stored in the GT INT DW. GT INT DW is
a double buffered structure. A snapshot of events is taken when SW reads
GT INT DW. From the time of read to the time of SW completely clearing
GT INT DW (to indicate end of service), all incoming interrupts are logged
in a secondary storage structure. this guarantees that the record of
interrupts SW is servicing will not change while under service".

We read GT INT DW in several places now:

- The IRQ handler (banks 0 and 1) where, hopefully, it is completely
  cleared (operation now covered with the irq lock).
- The 'reset' interrupts functions for RPS and GuC logs, where we clear
  the bit we are interested in and leave the others for the normal
  interrupt handler.
- The 'enable' interrupts functions for RPS and GuC logs, as a measure
  of precaution. Here we could relax a bit and don't check GT INT DW
  at all or, if we do, at least we should clear the offending bit
  (which is what this patch does).

Note that, if every bit is cleared on reading GT INT DW, the register
won't be locked. Also note that, according to the BSpec, GT INT DW
cannot be cleared without first servicing the Selector & Shared IIR
registers.

v2:
  - Remove some code duplication (Tvrtko)
  - Make sure GT_INTR_DW are protected by the irq spinlock, since it's a
global resource (Tvrtko)

v3: Optimize the spinlock (Tvrtko)

v4: Rebase.
v5:
  - take spinlock on outer scope to please sparse (Mika)
  - use raw_reg accessors (Mika)
v6: omit the continue in looping banks (Michel)

Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Signed-off-by: Oscar Mateo 
Reviewed-by: Tvrtko Ursulin  (v4)
Signed-off-by: Mika Kuoppala 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c | 110 ++--
 1 file changed, 73 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 36a635475a74..c2f878ace0ea 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -243,6 +243,41 @@ void i915_hotplug_interrupt_update(struct drm_i915_private 
*dev_priv,
spin_unlock_irq(_priv->irq_lock);
 }
 
+static u32
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit);
+
+static bool gen11_reset_one_iir(struct drm_i915_private * const i915,
+   const unsigned int bank,
+   const unsigned int bit)
+{
+   void __iomem * const regs = i915->regs;
+   u32 dw;
+
+   lockdep_assert_held(>irq_lock);
+
+   dw = raw_reg_read(regs, GEN11_GT_INTR_DW(bank));
+   if (dw & BIT(bit)) {
+   /*
+* According to the BSpec, DW_IIR bits cannot be cleared without
+* first servicing the Selector & Shared IIR registers.
+*/
+   gen11_gt_engine_identity(i915, bank, bit);
+
+   /*
+* We locked GT INT DW by reading it. If we want to (try
+* to) recover from this succesfully, we need to clear
+* our bit, otherwise we are locking the register for
+* everybody.
+*/
+   raw_reg_write(regs, GEN11_GT_INTR_DW(bank), BIT(bit));
+
+   return true;
+   }
+
+   return false;
+}
+
 /**
  * ilk_update_display_irq - update DEIMR
  * @dev_priv: driver private
@@ -412,26 +447,12 @@ static void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, u32 disable_m
/* though a barrier is missing here, but don't really need a one */
 }
 
-static u32
-gen11_gt_engine_identity(struct drm_i915_private * const i915,
-const unsigned int bank, const unsigned int bit);
-
 void gen11_reset_rps_interrupts(struct drm_i915_private *dev_priv)
 {
-   u32 dw;
-
spin_lock_irq(_priv->irq_lock);
 
-   /*
-* According to the BSpec, DW_IIR bits cannot be cleared without
-* first servicing the Selector & Shared IIR registers.
-*/
-   dw = I915_READ_FW(GEN11_GT_INTR_DW0);
-   while (dw & BIT(GEN11_GTPM)) {
-   gen11_gt_engine_identity(dev_priv, 0, GEN11_GTPM);
-   I915_WRITE_FW(GEN11_GT_INTR_DW0, BIT(GEN11_GTPM));
-   dw = I915_READ_FW(GEN11_GT_INTR_DW0);
-   }
+   while (gen11_reset_one_iir(dev_priv, 0, GEN11_GTPM))
+   ;
 
dev_priv->gt_pm.rps.pm_iir = 0;
 
@@ -455,10 +476,12 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
 
spin_lock_irq(_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
+
if (INTEL_GEN(dev_priv) >= 11)
-

[Intel-gfx] [PATCH 2/5] drm/i915/icl: Use hw engine class, instance to find irq handler

2018-04-06 Thread Mika Kuoppala

Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.

v3: rebase on top of rps intr
use correct class / instance limits (Michel)
v4: split engine/other handling
v5: empty iir is not err (Daniele, Michel)

Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Michel Thierry 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Daniele Ceraolo Spurio 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c | 99 ++---
 drivers/gpu/drm/i915/i915_reg.h |  4 +-
 2 files changed, 56 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 27aee25429b7..45f72a0ece04 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2732,47 +2732,9 @@ static void __fini_wedge(struct wedge_me *w)
 (W)->i915; \
 __fini_wedge((W)))
 
-static void
-gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
-   const unsigned int bank,
-   const unsigned int engine_n,
-   const u16 iir)
-{
-   struct intel_engine_cs ** const engine = i915->engine;
-
-   switch (bank) {
-   case 0:
-   switch (engine_n) {
-
-   case GEN11_RCS0:
-   return gen8_cs_irq_handler(engine[RCS], iir);
-
-   case GEN11_BCS:
-   return gen8_cs_irq_handler(engine[BCS], iir);
-   }
-   case 1:
-   switch (engine_n) {
-
-   case GEN11_VCS(0):
-   return gen8_cs_irq_handler(engine[_VCS(0)], iir);
-   case GEN11_VCS(1):
-   return gen8_cs_irq_handler(engine[_VCS(1)], iir);
-   case GEN11_VCS(2):
-   return gen8_cs_irq_handler(engine[_VCS(2)], iir);
-   case GEN11_VCS(3):
-   return gen8_cs_irq_handler(engine[_VCS(3)], iir);
-
-   case GEN11_VECS(0):
-   return gen8_cs_irq_handler(engine[_VECS(0)], iir);
-   case GEN11_VECS(1):
-   return gen8_cs_irq_handler(engine[_VECS(1)], iir);
-   }
-   }
-}
-
 static u32
-gen11_gt_engine_intr(struct drm_i915_private * const i915,
-const unsigned int bank, const unsigned int bit)
+gen11_gt_engine_identity(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit)
 {
void __iomem * const regs = i915->regs;
u32 timeout_ts;
@@ -2799,7 +2761,54 @@ gen11_gt_engine_intr(struct drm_i915_private * const 
i915,
raw_reg_write(regs, GEN11_INTR_IDENTITY_REG(bank),
  GEN11_INTR_DATA_VALID);
 
-   return ident & GEN11_INTR_ENGINE_MASK;
+   return ident;
+}
+
+static void
+gen11_other_irq_handler(struct drm_i915_private * const i915,
+   const u8 instance, const u16 iir)
+{
+   WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
+ instance, iir);
+}
+
+static void
+gen11_engine_irq_handler(struct drm_i915_private * const i915,
+const u8 class, const u8 instance, const u16 iir)
+{
+   struct intel_engine_cs *engine;
+
+   if (instance <= MAX_ENGINE_INSTANCE)
+   engine = i915->engine_class[class][instance];
+   else
+   engine = NULL;
+
+   if (likely(engine))
+   return gen8_cs_irq_handler(engine, iir);
+
+   WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
+ class, instance);
+}
+
+static void
+gen11_gt_identity_handler(struct drm_i915_private * const i915,
+ const u32 identity)
+{
+   const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
+   const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
+   const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
+
+   if (unlikely(!intr))
+   return;
+
+   if (class <= COPY_ENGINE_CLASS)
+   return gen11_engine_irq_handler(i915, class, instance, intr);
+
+   if (class == OTHER_CLASS)
+   return gen11_other_irq_handler(i915, instance, intr);
+
+   WARN_ONCE(1, "unknown interrupt class=0x%x, instance=0x%x, intr=0x%x\n",
+ class, instance, intr);
 }
 
 static void
@@ -2824,12 +2833,10 @@ gen11_gt_irq_handler(struct drm_i915_private * const 
i915,
}
 
for_each_set_bit(bit, _dw, 32) {

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enclose for_each_engine_masked macro arguments in parentheses (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Enclose for_each_engine_masked macro arguments in parentheses 
(rev2)
URL   : https://patchwork.freedesktop.org/series/41261/
State : failure

== Summary ==

 Possible new issues:

Test kms_atomic:
Subgroup plane_invalid_params_fence:
fail   -> PASS   (shard-snb)
Test kms_atomic_interruptible:
Subgroup legacy-pageflip:
pass   -> FAIL   (shard-snb)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
fail   -> PASS   (shard-snb)
Test kms_busy:
Subgroup basic-flip-b:
pass   -> SKIP   (shard-snb)
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
pass   -> FAIL   (shard-snb)
Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
fail   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
fail   -> PASS   (shard-snb)
Subgroup flip-vs-cursor-busy-crc-legacy:
fail   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-wc-untiled:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-wc:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-indfb-scaledprimary:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-rgb101010-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-slowdraw:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-offscren-pri-indfb-draw-pwrite:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-cur-indfb-draw-mmap-wc:
skip   -> FAIL   (shard-snb)
Subgroup psr-1p-primscrn-indfb-msflip-blt:
skip   -> FAIL   (shard-snb)
Subgroup psr-1p-primscrn-pri-shrfb-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-spr-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-cur-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-spr-indfb-move:
fail   -> SKIP   (shard-snb)
Test kms_plane:
Subgroup pixel-format-pipe-b-planes:
fail   -> PASS   (shard-snb)
Test kms_properties:
Subgroup connector-properties-atomic:
pass   -> FAIL   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
pass   -> FAIL   (shard-snb)
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-snb)
Test testdisplay:
warn   -> PASS   (shard-snb)

 Known issues:

Test gem_fenced_exec_thrash:
Subgroup 2-spare-fences:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_flip:
Subgroup 2x-plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-pri-shrfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb) fdo#103167 +3
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2680 pass:1836 dwarn:1   dfail:0   fail:7   skip:836 
time:12596s
shard-hswtotal:2680 pass:1784 dwarn:1   dfail:0   fail:3   skip:891 
time:11304s
shard-snbtotal:2680 pass:1370 dwarn:1   dfail:0   fail:12  skip:1297 
time:6854s
Blacklisted hosts:
shard-kbltotal:2680 pass:1956 dwarn:5   dfail:1   fail:7   skip:711 
time:9218s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8618/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Michal Wajdeczko

On Fri, 06 Apr 2018 16:33:39 +0200, Chris Wilson  
 wrote:



We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.

v2: Just skip if already parked; makes it more forgiving to use by
future callers.

Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
Even with the follow up patch on hold, I think this will be useful when
we figure out the right order of operations in reset and stands by itself
as an improvement.

Any objections to pushing this by itself?
-Chris


I would only suggest to make this new function more symmetrical to
"mark_busy" from i915_request.c both in naming and location ;)

/michal


---
 drivers/gpu/drm/i915/i915_gem.c | 69 -
 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c  
b/drivers/gpu/drm/i915/i915_gem.c

index 9650a7b10c5f..134529598a84 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -136,6 +136,46 @@ int i915_mutex_lock_interruptible(struct drm_device  
*dev)

return 0;
 }
+static u32 i915_gem_park(struct drm_i915_private *i915)
+{
+   lockdep_assert_held(>drm.struct_mutex);
+   GEM_BUG_ON(i915->gt.active_requests);
+
+   if (!i915->gt.awake)
+   return I915_EPOCH_INVALID;
+
+   GEM_BUG_ON(i915->gt.epoch == I915_EPOCH_INVALID);
+
+   /*
+* Be paranoid and flush a concurrent interrupt to make sure
+* we don't reactivate any irq tasklets after parking.
+*
+	 * FIXME: Note that even though we have waited for execlists to be  
idle,

+* there may still be an in-flight interrupt even though the CSB
+* is now empty. synchronize_irq() makes sure that a residual interrupt
+* is completed before we continue, but it doesn't prevent the HW from
+* raising a spurious interrupt later. To complete the shield we should
+* coordinate disabling the CS irq with flushing the interrupts.
+*/
+   synchronize_irq(i915->drm.irq);
+
+   intel_engines_park(i915);
+   i915_gem_timelines_park(i915);
+
+   i915_pmu_gt_parked(i915);
+
+   i915->gt.awake = false;
+
+   if (INTEL_GEN(i915) >= 6)
+   gen6_rps_idle(i915);
+
+   intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ);
+
+   intel_runtime_pm_put(i915);
+
+   return i915->gt.epoch;
+}
+
 int
 i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
@@ -3496,36 +3536,9 @@ i915_gem_idle_work_handler(struct work_struct  
*work)

if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
-   /*
-* Be paranoid and flush a concurrent interrupt to make sure
-* we don't reactivate any irq tasklets after parking.
-*
-	 * FIXME: Note that even though we have waited for execlists to be  
idle,

-* there may still be an in-flight interrupt even though the CSB
-* is now empty. synchronize_irq() makes sure that a residual interrupt
-* is completed before we continue, but it doesn't prevent the HW from
-* raising a spurious interrupt later. To complete the shield we should
-* coordinate disabling the CS irq with flushing the interrupts.
-*/
-   synchronize_irq(dev_priv->drm.irq);
-
-   intel_engines_park(dev_priv);
-   i915_gem_timelines_park(dev_priv);
+   epoch = i915_gem_park(dev_priv);
-   i915_pmu_gt_parked(dev_priv);
-
-   GEM_BUG_ON(!dev_priv->gt.awake);
-   dev_priv->gt.awake = false;
-   epoch = dev_priv->gt.epoch;
-   GEM_BUG_ON(epoch == I915_EPOCH_INVALID);
rearm_hangcheck = false;
-
-   if (INTEL_GEN(dev_priv) >= 6)
-   gen6_rps_idle(dev_priv);
-
-   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
-
-   intel_runtime_pm_put(dev_priv);
 out_unlock:
mutex_unlock(_priv->drm.struct_mutex);

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

Re: [Intel-gfx] [PATCH] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Chris Wilson

Quoting Michal Wajdeczko (2018-04-06 16:18:53)
> On Fri, 06 Apr 2018 16:33:39 +0200, Chris Wilson  
>  wrote:
> 
> > We will want to park GEM before disengaging the drive^W^W^W unwedging.
> > Since we already do the work for idling, expose the guts as a new
> > function that we can then reuse.
> >
> > v2: Just skip if already parked; makes it more forgiving to use by
> > future callers.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Michal Wajdeczko 
> > Cc: Sagar Arun Kamble 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > Reviewed-by: Mika Kuoppala 
> > ---
> > Even with the follow up patch on hold, I think this will be useful when
> > we figure out the right order of operations in reset and stands by itself
> > as an improvement.
> >
> > Any objections to pushing this by itself?
> > -Chris
> 
> I would only suggest to make this new function more symmetrical to
> "mark_busy" from i915_request.c both in naming and location ;)

Fine, we'll pull back unpark and export that as well!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Rename wait_for_hang() to wait_until_running()

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915/selftests: Rename wait_for_hang() to wait_until_running()
URL   : https://patchwork.freedesktop.org/series/41264/
State : failure

== Summary ==

 Possible new issues:

Test gem_pipe_control_store_loop:
Subgroup reused-buffer:
pass   -> INCOMPLETE (shard-apl)
Test kms_atomic:
Subgroup plane_invalid_params_fence:
fail   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
fail   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
fail   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
fail   -> PASS   (shard-snb)
Subgroup flip-vs-cursor-busy-crc-legacy:
fail   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-rgb101010-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-slowdraw:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-offscren-pri-indfb-draw-pwrite:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-pri-shrfb-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-spr-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-cur-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-spr-indfb-move:
fail   -> SKIP   (shard-snb)
Test kms_plane:
Subgroup pixel-format-pipe-b-planes:
fail   -> PASS   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-snb)
Test testdisplay:
warn   -> PASS   (shard-snb)

 Known issues:

Test gem_fenced_exec_thrash:
Subgroup 2-spare-fences:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +2
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
fail   -> PASS   (shard-snb) fdo#103167 +1

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:2680 pass:1834 dwarn:1   dfail:0   fail:7   skip:836 
time:12129s
shard-hswtotal:2680 pass:1781 dwarn:1   dfail:1   fail:5   skip:891 
time:11331s
shard-snbtotal:2680 pass:1378 dwarn:1   dfail:0   fail:2   skip:1299 
time:6879s
Blacklisted hosts:
shard-kbltotal:2680 pass:1917 dwarn:29  dfail:0   fail:16  skip:717 
time:9083s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8616/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_eio: Require context support before creation

2018-04-06 Thread Patchwork

== Series Details ==

Series: igt/gem_eio: Require context support before creation
URL   : https://patchwork.freedesktop.org/series/41260/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-cur-indfb-move:
pass   -> SKIP   (shard-hsw)

 Known issues:

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-legacy:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +3
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-x:
pass   -> FAIL   (shard-snb) fdo#103166
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2680 pass:1835 dwarn:1   dfail:0   fail:7   skip:836 
time:12739s
shard-hswtotal:2680 pass:1782 dwarn:1   dfail:0   fail:4   skip:892 
time:11395s
shard-snbtotal:2680 pass:1377 dwarn:1   dfail:0   fail:3   skip:1299 
time:6956s
Blacklisted hosts:
shard-kbltotal:2680 pass:1963 dwarn:1   dfail:0   fail:6   skip:710 
time:9296s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1231/shards.html
___
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: Split out parking from the idle worker for reuse

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Split out parking from the idle worker for reuse
URL   : https://patchwork.freedesktop.org/series/41278/
State : success

== Summary ==

Series 41278v1 drm/i915: Split out parking from the idle worker for reuse
https://patchwork.freedesktop.org/api/1.0/series/41278/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bdw-5557u) fdo#104944

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:515s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:313s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:665s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:585s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:406s

8ff6fb0c22f11dbcd3524bff374baa53a591438b drm-tip: 2018y-04m-06d-12h-37m-26s UTC 
integration manifest
1ff0af502baf drm/i915: Split out parking from the idle worker for reuse

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8622/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Rename wait_for_hang() to wait_until_running()

2018-04-06 Thread Chris Wilson

Quoting Patchwork (2018-04-06 16:04:14)
> == Series Details ==
> 
> Series: drm/i915/selftests: Rename wait_for_hang() to wait_until_running()
> URL   : https://patchwork.freedesktop.org/series/41264/
> State : failure
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test gem_pipe_control_store_loop:
> Subgroup reused-buffer:
> pass   -> INCOMPLETE (shard-apl)

<0>[  499.756242] thermal thermal_zone0: critical temperature reached (100 C), 
shutting down

Tomi, quick get the duster!

> Test kms_atomic:
> Subgroup plane_invalid_params_fence:
> fail   -> PASS   (shard-snb)
> Test kms_atomic_transition:
> Subgroup plane-all-transition-fencing:
> fail   -> PASS   (shard-snb)
> Test kms_busy:
> Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
> fail   -> PASS   (shard-snb)
> Test kms_chv_cursor_fail:
> Subgroup pipe-c-128x128-right-edge:
> dmesg-warn -> PASS   (shard-hsw)
> Test kms_cursor_legacy:
> Subgroup flip-vs-cursor-busy-crc-atomic:
> fail   -> PASS   (shard-snb)
> Subgroup flip-vs-cursor-busy-crc-legacy:
> fail   -> PASS   (shard-snb)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
> fail   -> SKIP   (shard-snb)
> Subgroup fbcpsr-rgb101010-draw-render:
> fail   -> SKIP   (shard-snb)
> Subgroup fbcpsr-slowdraw:
> fail   -> SKIP   (shard-snb)
> Subgroup psr-1p-offscren-pri-indfb-draw-pwrite:
> fail   -> SKIP   (shard-snb)
> Subgroup psr-1p-primscrn-pri-shrfb-draw-render:
> fail   -> SKIP   (shard-snb)
> Subgroup psr-1p-primscrn-spr-indfb-draw-mmap-wc:
> fail   -> SKIP   (shard-snb)
> Subgroup psr-2p-primscrn-cur-indfb-draw-mmap-wc:
> fail   -> SKIP   (shard-snb)
> Subgroup psr-2p-primscrn-spr-indfb-move:
> fail   -> SKIP   (shard-snb)
> Test kms_plane:
> Subgroup pixel-format-pipe-b-planes:
> fail   -> PASS   (shard-snb)
> Test kms_vblank:
> Subgroup pipe-a-ts-continuation-suspend:
> fail   -> PASS   (shard-snb)
> Test testdisplay:
> warn   -> PASS   (shard-snb)

Wow, that was noisy and all unconnected to the patch.

Thanks for the suggestion and review, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Chris Wilson

Quoting Chris Wilson (2018-04-06 16:21:04)
> Quoting Michal Wajdeczko (2018-04-06 16:18:53)
> > On Fri, 06 Apr 2018 16:33:39 +0200, Chris Wilson  
> >  wrote:
> > 
> > > We will want to park GEM before disengaging the drive^W^W^W unwedging.
> > > Since we already do the work for idling, expose the guts as a new
> > > function that we can then reuse.
> > >
> > > v2: Just skip if already parked; makes it more forgiving to use by
> > > future callers.
> > >
> > > Signed-off-by: Chris Wilson 
> > > Cc: Michal Wajdeczko 
> > > Cc: Sagar Arun Kamble 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Mika Kuoppala 
> > > Reviewed-by: Mika Kuoppala 
> > > ---
> > > Even with the follow up patch on hold, I think this will be useful when
> > > we figure out the right order of operations in reset and stands by itself
> > > as an improvement.
> > >
> > > Any objections to pushing this by itself?
> > > -Chris
> > 
> > I would only suggest to make this new function more symmetrical to
> > "mark_busy" from i915_request.c both in naming and location ;)
> 
> Fine, we'll pull back unpark and export that as well!

The tricky part is trying to get the split correct; i915_request really
shouldn't be doing the GEM unpark itself, but that is, or at least was,
the convenient point to place it. The rationale for placing it there was
for autoenabling rps, but that can be rearranged now so maybe it will be
doable to push the mark_busy/unpark into the execbuf ioctl, i.e. back to
the GEM level.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: set minimum CD clock to twice the BCLK.

2018-04-06 Thread Jani Nikula

On Thu, 05 Apr 2018, Abhay Kumar  wrote:
> In glk when device boots with 1366x768 panel, HDA codec doesn't comeup.
> This result in no audio forever as cdclk is < 96Mhz.
> This chagne will ensure CD clock to be twice of  BCLK.

In short, we can't poke around CDCLK like this. It needs a full modeset,
and it's non-trivial from the path you're calling this from.

I'm considering pushing the original patch [1], because we haven't come
up with working alternatives. Please confirm that the patch reliably
fixes the issue.

(Though I think if you boot with *all* outputs disabled, we'll choose
the lowest CDCLK possible regardless of the patch, reproducing the same
issue.)

What's the CDCLK frequency set by the BIOS/GOP at boot? There are no
logs with drm.debug=14 attached to the referenced bug.

I see that bspec says, "158.4 MHz CD (Display Audio enumeration and
playback OK)" but that's *not* twice the BCLK. I'm inclined to lean
towards 192 MHz min leading to max CDCLK on GLK.

BR,
Jani.


[1] https://patchwork.freedesktop.org/patch/184778/



>
> v2:
> - Address comment (Jani)
> - New design approach
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
> Signed-off-by: Abhay Kumar 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 33 ++---
>  drivers/gpu/drm/i915/intel_cdclk.c | 21 +
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  3 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 709d6ca68074..f7dd3d532e93 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -723,15 +723,37 @@ static void i915_audio_component_put_power(struct 
> device *kdev)
>   intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
>  }
>  
> +/* Get CDCLK in kHz  */
> +static int i915_audio_component_get_cdclk_freq(struct device *kdev)
> +{
> + struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> +
> + if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
> + return -ENODEV;
> +
> + return dev_priv->cdclk.hw.cdclk;
> +}
> +
>  static void i915_audio_component_codec_wake_override(struct device *kdev,
>bool enable)
>  {
>   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
>   u32 tmp;
> + int current_cdclk;
>  
>   if (!IS_GEN9_BC(dev_priv))
>   return;
>  
> + current_cdclk = i915_audio_component_get_cdclk_freq(kdev);
> +
> + /*
> +  * Before probing for HDA Codec we need to make sure
> +  * "The CD clock frequency must be at least twice
> +  * the frequency of the Azalia BCLK."
> +  */
> + if (INTEL_GEN(dev_priv) >= 9 && current_cdclk <= 192000)
> + intel_cdclk_bump(dev_priv);
> +
>   i915_audio_component_get_power(kdev);
>  
>   /*
> @@ -753,17 +775,6 @@ static void 
> i915_audio_component_codec_wake_override(struct device *kdev,
>   i915_audio_component_put_power(kdev);
>  }
>  
> -/* Get CDCLK in kHz  */
> -static int i915_audio_component_get_cdclk_freq(struct device *kdev)
> -{
> - struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> -
> - if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
> - return -ENODEV;
> -
> - return dev_priv->cdclk.hw.cdclk;
> -}
> -
>  /*
>   * get the intel_encoder according to the parameter port and pipe
>   * intel_encoder is saved by the index of pipe
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index dc7db8a2caf8..9426e1b7badc 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1516,6 +1516,27 @@ void bxt_init_cdclk(struct drm_i915_private *dev_priv)
>  }
>  
>  /**
> + * intel_cdclk_bump - Increase cdclk to 2* BCLK
> + * @dev_priv: i915 device
> + *
> + * Increase CDCLK for GKL and CNL. This is done only
> + * during HDA codec probe.
> + */
> +void intel_cdclk_bump(struct drm_i915_private *dev_priv)
> +{
> + struct intel_cdclk_state cdclk_state;
> +
> + cdclk_state = dev_priv->cdclk.hw;
> +
> + if (IS_GEMINILAKE(dev_priv)) {
> + cdclk_state.cdclk = glk_calc_cdclk((2*96000));
> + cdclk_state.vco = glk_de_pll_vco(dev_priv, cdclk_state.cdclk);
> + cdclk_state.voltage_level = 
> bxt_calc_voltage_level(cdclk_state.cdclk);
> + bxt_set_cdclk(dev_priv, _state);
> + }
> +}
> +
> +/**
>   * bxt_uninit_cdclk - Uninitialize CDCLK on BXT
>   * @dev_priv: i915 device
>   *
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d1452fd2a58d..5192753df3dc 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1417,6 +1417,7 @@ void skl_uninit_cdclk(struct drm_i915_private 
> *dev_priv);
>  void cnl_init_cdclk(struct drm_i915_private *dev_priv);
>  void

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/icl: Add reset control register changes (rev3)

2018-04-06 Thread Patchwork

== Series Details ==

Series: series starting with [1/5] drm/i915/icl: Add reset control register 
changes (rev3)
URL   : https://patchwork.freedesktop.org/series/41214/
State : success

== Summary ==

 Possible new issues:

Test kms_atomic:
Subgroup plane_invalid_params_fence:
fail   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
fail   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
fail   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
fail   -> PASS   (shard-snb)
Subgroup flip-vs-cursor-busy-crc-legacy:
fail   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-rgb101010-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-slowdraw:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-offscren-pri-indfb-draw-pwrite:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-pri-shrfb-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-spr-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-cur-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-spr-indfb-move:
fail   -> SKIP   (shard-snb)
Test kms_plane:
Subgroup pixel-format-pipe-b-planes:
fail   -> PASS   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-snb)
Test testdisplay:
warn   -> PASS   (shard-snb)

 Known issues:

Test gem_fenced_exec_thrash:
Subgroup 2-spare-fences:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-pri-shrfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb) fdo#103167 +1

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:2680 pass:1835 dwarn:1   dfail:0   fail:7   skip:836 
time:12570s
shard-hswtotal:2680 pass:1784 dwarn:1   dfail:0   fail:3   skip:891 
time:11286s
shard-snbtotal:2680 pass:1378 dwarn:1   dfail:0   fail:2   skip:1299 
time:6868s
Blacklisted hosts:
shard-kbltotal:2680 pass:1949 dwarn:12  dfail:1   fail:7   skip:711 
time:9224s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8614/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_eio: Require context support before creation

2018-04-06 Thread Patchwork

== Series Details ==

Series: igt/gem_eio: Require context support before creation
URL   : https://patchwork.freedesktop.org/series/41260/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
8a7353abf41eb3dbbde240ac5f7ac26f92ed693a tests/kms_psr_sink_crc: Save runtime 
by not waiting in crc function

with latest DRM-Tip kernel build CI_DRM_4030
8ff6fb0c22f1 drm-tip: 2018y-04m-06d-12h-37m-26s UTC integration manifest

No testlist changes.

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bdw-5557u) fdo#104944
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:546s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:665s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:575s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:413s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1231/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Chris Wilson

We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.

v2: Just skip if already parked; makes it more forgiving to use by
future callers.

Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
Even with the follow up patch on hold, I think this will be useful when
we figure out the right order of operations in reset and stands by itself
as an improvement.

Any objections to pushing this by itself?
-Chris
---
 drivers/gpu/drm/i915/i915_gem.c | 69 -
 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b10c5f..134529598a84 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -136,6 +136,46 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
 }
 
+static u32 i915_gem_park(struct drm_i915_private *i915)
+{
+   lockdep_assert_held(>drm.struct_mutex);
+   GEM_BUG_ON(i915->gt.active_requests);
+
+   if (!i915->gt.awake)
+   return I915_EPOCH_INVALID;
+
+   GEM_BUG_ON(i915->gt.epoch == I915_EPOCH_INVALID);
+
+   /*
+* Be paranoid and flush a concurrent interrupt to make sure
+* we don't reactivate any irq tasklets after parking.
+*
+* FIXME: Note that even though we have waited for execlists to be idle,
+* there may still be an in-flight interrupt even though the CSB
+* is now empty. synchronize_irq() makes sure that a residual interrupt
+* is completed before we continue, but it doesn't prevent the HW from
+* raising a spurious interrupt later. To complete the shield we should
+* coordinate disabling the CS irq with flushing the interrupts.
+*/
+   synchronize_irq(i915->drm.irq);
+
+   intel_engines_park(i915);
+   i915_gem_timelines_park(i915);
+
+   i915_pmu_gt_parked(i915);
+
+   i915->gt.awake = false;
+
+   if (INTEL_GEN(i915) >= 6)
+   gen6_rps_idle(i915);
+
+   intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ);
+
+   intel_runtime_pm_put(i915);
+
+   return i915->gt.epoch;
+}
+
 int
 i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
@@ -3496,36 +3536,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   /*
-* Be paranoid and flush a concurrent interrupt to make sure
-* we don't reactivate any irq tasklets after parking.
-*
-* FIXME: Note that even though we have waited for execlists to be idle,
-* there may still be an in-flight interrupt even though the CSB
-* is now empty. synchronize_irq() makes sure that a residual interrupt
-* is completed before we continue, but it doesn't prevent the HW from
-* raising a spurious interrupt later. To complete the shield we should
-* coordinate disabling the CS irq with flushing the interrupts.
-*/
-   synchronize_irq(dev_priv->drm.irq);
-
-   intel_engines_park(dev_priv);
-   i915_gem_timelines_park(dev_priv);
+   epoch = i915_gem_park(dev_priv);
 
-   i915_pmu_gt_parked(dev_priv);
-
-   GEM_BUG_ON(!dev_priv->gt.awake);
-   dev_priv->gt.awake = false;
-   epoch = dev_priv->gt.epoch;
-   GEM_BUG_ON(epoch == I915_EPOCH_INVALID);
rearm_hangcheck = false;
-
-   if (INTEL_GEN(dev_priv) >= 6)
-   gen6_rps_idle(dev_priv);
-
-   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
-
-   intel_runtime_pm_put(dev_priv);
 out_unlock:
mutex_unlock(_priv->drm.struct_mutex);
 
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Park before resetting the submission backend

2018-04-06 Thread Michal Wajdeczko

On Fri, 06 Apr 2018 14:25:48 +0200, Chris Wilson  
 wrote:



Quoting Sagar Arun Kamble (2018-04-05 12:54:38)



On 4/5/2018 4:32 PM, Chris Wilson wrote:
> As different backends may have different park/unpark callbacks, we
> should only ever switch backends (reset_default_submission on wedge
> recovery, or on enabling the guc) while parked.
>
> Signed-off-by: Chris Wilson 
> Cc: Michal Wajdeczko 
> Cc: Sagar Arun Kamble 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>   drivers/gpu/drm/i915/i915_gem.c | 11 +++
>   drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
>   drivers/gpu/drm/i915/intel_guc_submission.c |  1 +
>   3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c  
b/drivers/gpu/drm/i915/i915_gem.c

> index e148db310ea6..e2880de2fc7e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3380,6 +3380,17 @@ bool i915_gem_unset_wedged(struct  
drm_i915_private *i915)

>   i915_retire_requests(i915);
>   GEM_BUG_ON(i915->gt.active_requests);
>
> + /*
> +  * Park before disengaging the old submit mechanism as different
> +  * backends may have different park/unpack callbacks.
> +  *
> +  * We are idle; the idle-worker will be queued, but we need to  
run

> +  * it now. As we already hold the struct mutex, we can get park
> +  * the GPU right away, letting the lazy worker see that we are
> +  * already active again by the time it acquires the mutex.
> +  */
> + i915_gem_park(i915);
I think we should be calling this before gem_unset_wedged in i915_reset.
With GuC, hitting the GEM_BUG_ON(awake) in guc_submission_enable.


Right, we really do need to restore guc submission before restarting. So
how can we fit in something like

diff --git a/drivers/gpu/drm/i915/i915_gem.c  
b/drivers/gpu/drm/i915/i915_gem.c

index 9650a7b10c5f..95fa30d9aec6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3132,6 +3132,9 @@ void i915_gem_reset(struct drm_i915_private  
*dev_priv)

   i915_retire_requests(dev_priv);
+   if (USES_GUC_SUBMISSION(dev_priv))
+   (void)intel_guc_submission_enable(guc);
+
for_each_engine(engine, dev_priv, id) {
struct i915_gem_context *ctx;
?


In series [1] I was trying to fix symmetry in calls to uc_init_hw/fini_hw
where we are enabling/disabling GuC submission. In particular, patch [2]
fixes reset path.

So maybe we should try to merge* both series ?

Michal

*) without my patch 6/12 [3]

[1] https://patchwork.freedesktop.org/series/41159/
[2] https://patchwork.freedesktop.org/patch/214967/
[3] https://patchwork.freedesktop.org/patch/214976/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for Add NV12 support (rev10)

2018-04-06 Thread Patchwork

== Series Details ==

Series: Add NV12 support (rev10)
URL   : https://patchwork.freedesktop.org/series/39670/
State : warning

== Summary ==

Series 39670v10 Add NV12 support
https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/10/mbox/

 Possible new issues:

Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)

 Known issues:

Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#105589
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-bdw-5557u) fdo#104944
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

fdo#105589 https://bugs.freedesktop.org/show_bug.cgi?id=105589
fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:520s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:423s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:224  dwarn:0   dfail:0   fail:1   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:259  dwarn:1   dfail:1   fail:0   skip:24  
time:478s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:631s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:402s

8ff6fb0c22f11dbcd3524bff374baa53a591438b drm-tip: 2018y-04m-06d-12h-37m-26s UTC 
integration manifest
e8d961baffd6 drm/i915: Do not do fb src adjustments for NV12
9f9b3ebee7d5 drm/i915: Add NV12 support to intel_framebuffer_init
b066ce1c2a3f drm/i915: Add NV12 as supported format for sprite plane
7c2115b191f5 drm/i915: Add NV12 as supported format for primary plane
7744cf596189 drm/i915: Upscale scaler max scale for NV12
bbc449ba874f drm/i915: Update format_is_yuv() to include NV12
489e0c91d2a1 drm/i915: Set scaler mode for NV12
b6b47ee40e6e drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
3a005219c94c drm/i915: Display WA 827
e448c0cfedef drm/i915/skl: split skl_compute_ddb function
af307a9a1777 drm/i915/skl+: nv12 workaround disable WM level 1-7
ea1a8eae0500 drm/i915/skl+: make sure higher latency level has higher

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Park before resetting the submission backend

2018-04-06 Thread Chris Wilson

Quoting Michal Wajdeczko (2018-04-06 14:39:28)
> On Fri, 06 Apr 2018 14:25:48 +0200, Chris Wilson  
>  wrote:
> 
> > Quoting Sagar Arun Kamble (2018-04-05 12:54:38)
> >>
> >>
> >> On 4/5/2018 4:32 PM, Chris Wilson wrote:
> >> > As different backends may have different park/unpark callbacks, we
> >> > should only ever switch backends (reset_default_submission on wedge
> >> > recovery, or on enabling the guc) while parked.
> >> >
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Michal Wajdeczko 
> >> > Cc: Sagar Arun Kamble 
> >> > Cc: Tvrtko Ursulin 
> >> > Cc: Mika Kuoppala 
> >> > ---
> >> >   drivers/gpu/drm/i915/i915_gem.c | 11 +++
> >> >   drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
> >> >   drivers/gpu/drm/i915/intel_guc_submission.c |  1 +
> >> >   3 files changed, 15 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_gem.c  
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> > index e148db310ea6..e2880de2fc7e 100644
> >> > --- a/drivers/gpu/drm/i915/i915_gem.c
> >> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> > @@ -3380,6 +3380,17 @@ bool i915_gem_unset_wedged(struct  
> >> drm_i915_private *i915)
> >> >   i915_retire_requests(i915);
> >> >   GEM_BUG_ON(i915->gt.active_requests);
> >> >
> >> > + /*
> >> > +  * Park before disengaging the old submit mechanism as different
> >> > +  * backends may have different park/unpack callbacks.
> >> > +  *
> >> > +  * We are idle; the idle-worker will be queued, but we need to  
> >> run
> >> > +  * it now. As we already hold the struct mutex, we can get park
> >> > +  * the GPU right away, letting the lazy worker see that we are
> >> > +  * already active again by the time it acquires the mutex.
> >> > +  */
> >> > + i915_gem_park(i915);
> >> I think we should be calling this before gem_unset_wedged in i915_reset.
> >> With GuC, hitting the GEM_BUG_ON(awake) in guc_submission_enable.
> >
> > Right, we really do need to restore guc submission before restarting. So
> > how can we fit in something like
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c  
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 9650a7b10c5f..95fa30d9aec6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3132,6 +3132,9 @@ void i915_gem_reset(struct drm_i915_private  
> > *dev_priv)
> >i915_retire_requests(dev_priv);
> > +   if (USES_GUC_SUBMISSION(dev_priv))
> > +   (void)intel_guc_submission_enable(guc);
> > +
> > for_each_engine(engine, dev_priv, id) {
> > struct i915_gem_context *ctx;
> > ?
> 
> In series [1] I was trying to fix symmetry in calls to uc_init_hw/fini_hw
> where we are enabling/disabling GuC submission. In particular, patch [2]
> fixes reset path.

Tbh, I first misread that as i915_gem_fini(). Hmm, but we still should
be re-enabling guc prior to submitting our first requests here in
i915_gem_reset() prior to calling i915_gem_init_hw(). We want to start
from the repopulated request lists, so sticking the current init_hw() is
overkill.

I guess I have this sketch in mind:

i915_reset:

i915_gem_reset_prepare();
i915_gem_disable_hw(); // placeholder!

i915_gem_fini_hw(); // revert to default state

intel_gpu_reset();

i915_gem_init_hw(); // just the HW setup

i915_gem_reset();

i915_gem_enable_hw(); // tell the HW to run
i915_gem_reset_finish();

That i915_gem_reset() sticks out like a sore thumb. I think that's what
we need to break up and rearrange. Hmm, there's some of that in the RPS
series. Looks like we're too early to try and do this neatly.

> So maybe we should try to merge* both series ?

Hmm, looking over that series doesn't patch 5 hit the GEM_BUG_ON removed
in patch 6? Otherwise, merging the first 5 with Sagar's blessing would
be on the cards as they look sane otherwise. Maybe start with the first
4 then?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE 
(rev2)
URL   : https://patchwork.freedesktop.org/series/41263/
State : failure

== Summary ==

 Possible new issues:

Test kms_atomic:
Subgroup plane_invalid_params_fence:
fail   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
fail   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-modeset-hang-oldfb-render-b:
fail   -> PASS   (shard-snb)
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-right-edge:
pass   -> FAIL   (shard-snb)
Subgroup pipe-c-128x128-right-edge:
dmesg-warn -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
fail   -> PASS   (shard-snb)
Subgroup flip-vs-cursor-busy-crc-legacy:
fail   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-gtt-xtiled:
pass   -> SKIP   (shard-snb)
Subgroup draw-method-xrgb-mmap-wc-xtiled:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
fail   -> SKIP   (shard-snb)
Subgroup fbc-2p-scndscrn-spr-indfb-move:
pass   -> DMESG-FAIL (shard-hsw)
Subgroup fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-2p-primscrn-shrfb-msflip-blt:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-rgb101010-draw-mmap-gtt:
skip   -> FAIL   (shard-snb)
Subgroup fbcpsr-rgb101010-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup fbcpsr-slowdraw:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-offscren-pri-indfb-draw-pwrite:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-pri-shrfb-draw-render:
fail   -> SKIP   (shard-snb)
Subgroup psr-1p-primscrn-spr-indfb-draw-blt:
skip   -> FAIL   (shard-snb)
Subgroup psr-1p-primscrn-spr-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-cur-indfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-primscrn-spr-indfb-move:
fail   -> SKIP   (shard-snb)
Subgroup psr-2p-scndscrn-indfb-msflip-blt:
skip   -> FAIL   (shard-snb)
Subgroup psr-rgb101010-draw-mmap-cpu:
skip   -> FAIL   (shard-snb)
Subgroup psr-suspend:
skip   -> FAIL   (shard-snb)
Test kms_plane:
Subgroup pixel-format-pipe-b-planes:
fail   -> PASS   (shard-snb)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> WARN   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-snb)
Test testdisplay:
warn   -> PASS   (shard-snb)

 Known issues:

Test gem_fenced_exec_thrash:
Subgroup 2-spare-fences:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_flip:
Subgroup 2x-plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-pri-shrfb-draw-mmap-wc:
fail   -> SKIP   (shard-snb) fdo#103167 +2
Test kms_setmode:
Subgroup basic:
fail   -> WARN   (shard-snb) fdo#99912

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-apltotal:2680 pass:1835 dwarn:1   dfail:0   fail:7   skip:836 
time:12604s
shard-hswtotal:2680 pass:1783 dwarn:1   dfail:1   fail:3   skip:891 
time:11343s
shard-snbtotal:2680 pass:1374 dwarn:1   dfail:0   fail:11  skip:1292 
time:6859s
Blacklisted hosts:
shard-kbltotal:2680 pass:1963 dwarn:1   dfail:0   fail:7   skip:709 
time:9173s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8617/shards.html
___
Intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Michal Wajdeczko

On Fri, 06 Apr 2018 17:51:44 +0200, Chris Wilson  
 wrote:



We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.

v2: Just skip if already parked; makes it more forgiving to use by
future callers.
v3: Extract mark_busy, rename it to i915_gem_unpark and place it next to
i915_gem_park so that we can evaluate it for symmetry more easily.
Calling GEM from inside i915_request looks to be a bit of a layering
violation, for the moment I am imaging them as being notify_cb.

Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala  #v1
---


Reviewed-by: Michal Wajdeczko 

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Set queue priority from secondary port

2018-04-06 Thread Chris Wilson

Quoting Chris Wilson (2018-03-29 10:39:00)
> We can refine our current execlists->queue_priority if we inspect
> ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
> the unsubmitted queue and say that if a subsequent request is more than
> important than the current queue, we will rerun the submission tasklet
> to evaluate the need for preemption. However, we only want to preempt if
> we need to jump ahead of a currently executing request in ELSP. The
> second reason for running the submission tasklet is amalgamate requests
> into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
> (Though repeatedly amalgamating requests into the active context and
> triggering many lite-restore is off question gain, the goal really is to
> put a context into ELSP[1] to cover the interrupt.) So if instead of
> looking at the head of the queue, we look at the context in ELSP[1] we
> can answer both of the questions more accurately -- we don't need to
> rerun the submission tasklet unless our new request is important enough
> to feed into, at least, ELSP[1].
> 
> References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between 
> submission ports")
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Michel Thierry 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 

Has anyone had a chance to think about this yet?
-Chris

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 654634254b64..e6d3ee4ca0b2 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -698,7 +698,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
> kmem_cache_free(engine->i915->priorities, p);
> }
>  done:
> -   execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
> +   execlists->queue_priority =
> +   port != execlists->port ? rq_prio(last) : INT_MIN;
> execlists->first = rb;
> if (submit)
> port_assign(port, last);
> -- 
> 2.16.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v10 01/11] drm/modes: Introduce drm_mode_match()

2018-04-06 Thread Nautiyal, Ankit K

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..c395a24 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,17 +939,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -957,15 +1008,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode

[Intel-gfx] [PATCH v10 00/11] Aspect ratio support in DRM layer

2018-04-06 Thread Nautiyal, Ankit K

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 5 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes':
https://patchwork.freedesktop.org/series/33730/ which fixes the mode
matching mechanism via flags, and also ensures that no bogus aspect-ratios
are sent in the AVI infoframes.

This patch series, adds a DRM client option for aspect ratio, and loads
aspect ratio flags, only when the client sets this cap. 

To test this patch, the testdiplay IGT test is modified to have an option
to do a modeset with only aspect ratio modes.
Also, there is a userspace implementation in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)

This, helps us in passing HDMI compliance test cases like 7-27, where the
test equipment applies a CEA mode, and expects the exact VIC in the AVI
infoframes.

Ankit Nautiyal (4):
  drm: Add DRM client cap for aspect-ratio
  drm: Add helper functions to handle aspect-ratio flag bits
  drm: Handle aspect ratio info in legacy and atomic modeset paths
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (5):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling
  drm/edid: Don't send bogus aspect ratios in AVI infoframes
  video/hdmi: Reject illegal picture aspect ratios

 drivers/gpu/drm/drm_atomic.c|  34 --
 drivers/gpu/drm/drm_atomic_helper.c |   6 +-
 drivers/gpu/drm/drm_connector.c |  40 ++-
 drivers/gpu/drm/drm_crtc.c  |   8 ++
 drivers/gpu/drm/drm_crtc_internal.h |   3 +-
 drivers/gpu/drm/drm_edid.c  |  41 +--
 drivers/gpu/drm/drm_fb_helper.c |  12 +-
 drivers/gpu/drm/drm_ioctl.c |   9 ++
 drivers/gpu/drm/drm_mode_object.c   |   9 +-
 drivers/gpu/drm/drm_modes.c | 226 +++-
 drivers/video/hdmi.c|   3 +
 include/drm/drm_atomic.h|   5 +-
 include/drm/drm_file.h  |   8 ++
 include/drm/drm_modes.h |  13 +++
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 +
 16 files changed, 365 insertions(+), 65 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v10 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

2018-04-06 Thread Nautiyal, Ankit K

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 134069f..c35d3bc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3047,7 +3047,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 07/11] drm: Add helper functions to handle aspect-ratio flag bits

2018-04-06 Thread Nautiyal, Ankit K

From: Ankit Nautiyal 

This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_modes.c | 47 +
 include/drm/drm_modes.h |  4 
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c395a24..d6133e8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
 }
 EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
+ * is expected from the user-mode.
+ *
+ * If the user has set aspect-ratio cap, then the flag of the user-mode is
+ * allowed to contain aspect-ratio value.
+ * If the user does not set aspect-ratio cap, then the only value allowed in 
the
+ * flags bits is aspect-ratio NONE.
+ *
+ * @file_priv: file private structure to get the user capabilities
+ * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio
+ * information.
+ *
+ * Returns:
+ * true if the aspect-ratio info is allowed in the user-mode flags.
+ * false, otherwise.
+ */
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode)
+{
+   return file_priv->aspect_ratio_allowed || (umode->flags &
+   DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;
+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
+
+/**
+ * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the
+ * user-mode flags.
+ *
+ * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
+ * bits in the user-mode flags, if aspect-ratio info is not allowed.
+ *
+ * @file_priv: file private structure to get the user capabilities.
+ * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to
+ * be filtered.
+ *
+ */
+void
+drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode)
+{
+   if (!drm_mode_aspect_ratio_allowed(file_priv, umode))
+   umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+}
+EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags);
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2f78b7e..e0b060d 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info 
*display,
  const struct drm_display_mode *mode);
 bool drm_mode_is_420(const struct drm_display_info *display,
 const struct drm_display_mode *mode);
+bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode);
+void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+   struct drm_mode_modeinfo *umode);
 
 struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
  int hdisplay, int vdisplay, int vrefresh,
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 03/11] drm/edid: Fix cea mode aspect ratio handling

2018-04-06 Thread Nautiyal, Ankit K

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c35d3bc..29c88eb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2930,11 +2930,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2948,7 +2952,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2965,11 +2969,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2983,7 +2991,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3030,6 +3038,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3047,7 +3056,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3064,6 +3073,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3079,7 +3089,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if

[Intel-gfx] [PATCH v10 06/11] drm: Add DRM client cap for aspect-ratio

2018-04-06 Thread Nautiyal, Ankit K

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.

To avoid this, a new drm client cap is required to enable a
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: added comment explaining that no userspace breaks on aspect-ratio
 mode bits.

Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_ioctl.c | 9 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af78291..39c8eab 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   /*
+* No Atomic userspace blows up on aspect ratio mode bits. Checked in
+* wayland/weston, xserver, and hardware-composer modeset paths.
+*/
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5176c37..02b7dde 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..9c660e1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes

2018-04-06 Thread Nautiyal, Ankit K

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 29c88eb..d5757aa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4840,6 +4840,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
 {
+   enum hdmi_picture_aspect picture_aspect;
int err;
 
if (!frame || !mode)
@@ -4882,13 +4883,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
 
+   /*
+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths

2018-04-06 Thread Nautiyal, Ankit K

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

Note: In case, a user-space asks for a video-mode blob, from the
getblob ioctl, the aspect-ratio bits in the video-mode blob are passed
to the user as it is, without any filtering. However, no such case is
present in most of the atomic user-spaces. Currently atomic path of
Xserver, Wayland/weston, Hardware-Composer are checked, and none of
them are using getblob ioctl to get the video-mode blob.

This patch:
1. passes the file_priv structure from the drm_mode_atomic_ioctl till
   the drm_mode_crtc_set_mode_prop, to get the user capability.
2. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
3. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
v10: Modified the commit-message
---
 drivers/gpu/drm/drm_atomic.c| 34 +-
 drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
 drivers/gpu/drm/drm_crtc.c  |  8 
 drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
 drivers/gpu/drm/drm_mode_object.c   |  9 ++---
 include/drm/drm_atomic.h|  5 +++--
 6 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42..5863072 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
  * @blob: pointer to blob property to use for mode
+ * @file_priv: file priv structure, to get the userspace capabilities
  *
  * Set a mode (originating from a blob property) on the desired CRTC state.
  * This function will take a reference on the blob property for the CRTC state,
@@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * Zero on success, error code on failure. Cannot return -EDEADLK.
  */
 int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
-  struct drm_property_blob *blob)
+ struct drm_property_blob *blob,
+ struct drm_file *file_priv)
 {
if (blob == state->mode_blob)
return 0;
@@ -389,9 +391,21 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
 
if (blob) {
-   if (blob->length != sizeof(struct drm_mode_modeinfo) ||
-   drm_mode_convert_umode(state->crtc->dev, >mode,
-  blob->data))
+   struct drm_mode_modeinfo *u_mode;
+
+   if (blob->length != sizeof(struct drm_mode_modeinfo))
+   return -EINVAL;
+
+   u_mode = (struct drm_mode_modeinfo *) blob->data;
+   if (!drm_mode_aspect_ratio_allowed(file_priv,
+  u_mode)) {
+   DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }
+
+   if (drm_mode_convert_umode(state->crtc->dev, >mode,
+  (const struct drm_mode_modeinfo *)
+  u_mode))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
@@ -471,6 +485,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  * @state: the state object to update with the new property value
  * @property: the property to set
  * @val: the new property value
+ * @file_priv: the file private structure, to get the user capabilities
  *
  * This function handles generic/core properties and calls out to driver's
  * _crtc_funcs.atomic_set_property for driver properties. To ensure
@@ -482,7 +497,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  */
 int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
-   uint64_t val)
+   uint64_t val, struct drm_file

[Intel-gfx] [PATCH v10 05/11] video/hdmi: Reject illegal picture aspect ratios

2018-04-06 Thread Nautiyal, Ankit K

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jose Abreu 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab..38716eb5 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 09/11] drm: Expose modes with aspect ratio, only if requested

2018-04-06 Thread Nautiyal, Ankit K

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.

This patch prunes the modes with aspect-ratio information, from a
connector's modelist, if the user-space has not set the aspect ratio
DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
 instead only flags bits of user mode are reset (if aspect-ratio
 is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
 drivers/gpu/drm/drm_connector.c | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde89..5420325 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1531,8 +1531,10 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct drm_display_mode *last_mode,
+const struct drm_file *file_priv)
 {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
@@ -1540,6 +1542,26 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes with
+* aspect-ratio, don't expose them. But in case of a unique mode, let
+* the mode be passed, so that it can be enumerated with aspect-ratio
+* bits erased.
+*
+* It is assumed here, that the list of modes for a given connector, is
+* sorted, such that modes that have different aspect-ratios, but are
+* otherwise identical, are back to back.
+* This way, saving the last valid mode, and matching it with the
+* current mode will help in determining, if the current mode is unique.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE &&
+   last_mode && drm_mode_match(mode, last_mode,
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
+   return false;
 
return true;
 }
@@ -1551,6 +1573,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode *last_valid_mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1606,9 +1629,13 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
 
/* delayed so we get modes regardless of pre-fill_modes state */
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(mode, last_valid_mode,
+file_priv)) {
mode_count++;
+   last_valid_mode = mode;
+   }
 
/*
 * This ioctl is called twice, once to determine how much space is
@@ -1617,11 +1644,15 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head) {
-   if

[Intel-gfx] [PATCH v10 11/11] drm: Add and handle new aspect ratios in DRM layer

2018-04-06 Thread Nautiyal, Ankit K

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 454f2ff..21cc84b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1656,6 +1656,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case HDMI_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1721,6 +1727,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50bcf42..4b3a1bb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -93,6 +93,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -102,6 +104,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
 DRM_MODE_FLAG_NHSYNC | \
-- 
2.7.4

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

[Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

2018-04-06 Thread Nautiyal, Ankit K

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
 drivers/gpu/drm/drm_fb_helper.c | 12 ++--
 drivers/gpu/drm/drm_modes.c | 35 ++-
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b10..2ee1eaa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
fb_helper_conn = fb_helper->connector_info[i];
list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
modes[i] = mode;
}
if (!modes[i])
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d6133e8..454f2ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1647,6 +1648,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1693,6 +1708,24 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Split out parking from the idle worker for reuse (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Split out parking from the idle worker for reuse (rev2)
URL   : https://patchwork.freedesktop.org/series/41278/
State : success

== Summary ==

Series 41278v2 drm/i915: Split out parking from the idle worker for reuse
https://patchwork.freedesktop.org/api/1.0/series/41278/revisions/2/mbox/

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
incomplete -> PASS   (fi-elk-e7500)

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:516s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:518s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:506s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:589s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:420s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:435s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:472s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:642s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:504s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:578s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s

3cbdbfb1ecc8769c8db88e95b1d6ea55c5e87dbf drm-tip: 2018y-04m-06d-15h-15m-21s UTC 
integration manifest
1a10dad9eb99 drm/i915: Split out parking from the idle worker for reuse

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8624/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Check hdcp key loadability

2018-04-06 Thread Ville Syrjälä

On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> 
> 
> On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:
> > On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> >> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> >> is enabled. Using the I915 power well infrastruture, above requirement
> >> is verified.
> >>
> >> This patch enables the hdcp initialization for HSW, BDW, and BXT.
> >>
> >> v2:
> >>Choose the PW# based on the platform.
> >>
> >> Signed-off-by: Ramalingam C 
> >> Reviewed-by: Sean Paul 
> >> ---
> >>   drivers/gpu/drm/i915/intel_hdcp.c | 41 
> >> +--
> >>   1 file changed, 39 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> >> b/drivers/gpu/drm/i915/intel_hdcp.c
> >> index f77d956b2b18..d8af09b46a44 100644
> >> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> >> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> >> @@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
> >> intel_digital_port *intel_dig_port,
> >>return 0;
> >>   }
> >>   
> >> +static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
> >> +{
> >> +  struct i915_power_domains *power_domains = _priv->power_domains;
> >> +  struct i915_power_well *power_well;
> >> +  enum i915_power_well_id id;
> >> +  bool enabled = false;
> >> +
> >> +  /*
> >> +   * On HSW and BDW, Display HW loads the Key as soon as Display resumes.
> >> +   * On all BXT+, SW can load the keys only when the PW#1 is turned on.
> >> +   */
> >> +  if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> >> +  id = HSW_DISP_PW_GLOBAL;
> >> +  else
> >> +  id = SKL_DISP_PW_1;
> >> +
> >> +  mutex_lock(_domains->lock);
> >> +
> >> +  /* PG1 (power well #1) needs to be enabled */
> >> +  for_each_power_well(dev_priv, power_well) {
> >> +  if (power_well->id == id) {
> >> +  enabled = power_well->ops->is_enabled(dev_priv,
> >> +power_well);
> >> +  break;
> >> +  }
> >> +  }
> >> +  mutex_unlock(_domains->lock);
> >> +
> >> +  /*
> >> +   * Another req for hdcp key loadability is enabled state of pll for
> >> +   * cdclk. Without active crtc we wont land here. So we are assuming that
> >> +   * cdclk is already on.
> >> +   */
> >> +
> >> +  return enabled;
> >> +}
> >> +
> >>   static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
> >>   {
> >>I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
> >> @@ -615,8 +652,8 @@ static int _intel_hdcp_enable(struct intel_connector 
> >> *connector)
> >>DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> >>  connector->base.name, connector->base.base.id);
> >>   
> >> -  if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
> >> -  DRM_ERROR("PG1 is disabled, cannot load keys\n");
> >> +  if (!hdcp_key_loadable(dev_priv)) {
> >> +  DRM_ERROR("HDCP key Load is not possible\n");
> >>return -ENXIO;
> >>}
> > If you need the power well then why aren't you grabbing the correct
> > power domain reference somewhere?
> 
> Ville,
> 
> As HDCP is supposed to be enabled after the basic display is up, power well 
> #1 is supposed to be enabled.
> If not that is mostly an error w.r.t HDCP.
> 
> So at this point we just want to verify whether required PW is up and HDCP 
> key can be loaded from the HW. Else fail the HDCP request.

So this is in practice dead code to deal with a hypothetical bug
elsewhere in the driver?

-- 
Ville Syrjälä
Intel OTC
___
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 skip the first 4k of stolen memory for pre-allocated buffers

2018-04-06 Thread Ville Syrjälä

On Thu, Apr 05, 2018 at 01:37:31PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 04-04-18 22:49, Ville Syrjälä wrote:
> > On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 04-04-18 17:50, Ville Syrjälä wrote:
> >>> On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:
>  Hi,
> 
>  On 30-03-18 15:25, Hans de Goede wrote:
> > Hi,
> >
> > On 30-03-18 14:44, Chris Wilson wrote:
> >> Quoting Hans de Goede (2018-03-30 13:37:40)
> >>> Hi,
> >>>
> >>> On 30-03-18 14:30, Chris Wilson wrote:
>  Quoting Hans de Goede (2018-03-30 13:27:15)
> > Before this commit the WaSkipStolenMemoryFirstPage workaround code 
> > was
> > skipping the first 4k by passing 4096 as start of the address range 
> > passed
> > to drm_mm_init(). This means that calling drm_mm_reserve_node() to 
> > try and
> > reserve the firmware framebuffer so that we can inherit it would 
> > always
> > fail, as the firmware framebuffer starts at address 0.
> >
> > Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory 
> > on
> > everything >= gen8") says in its commit message: "This is confirmed 
> > to fix
> > Skylake screen flickering issues (probably caused by the fact that 
> > we
> > initialized a ring in the first page of stolen, but I didn't 100% 
> > confirm
> > this theory)."
> >
> > Which suggests that it is safe to use the first page for a linear
> > framebuffer as the firmware is doing.
> >
> > This commit always passes 0 as start to drm_mm_init() and works 
> > around
> > WaSkipStolenMemoryFirstPage in 
> > i915_gem_stolen_insert_node_in_range()
> > by insuring the start address passed by to 
> > drm_mm_insert_node_in_range()
> > is always 4k or more. All entry points to i915_gem_stolen.c go 
> > through
> > i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> > objects such as ring-buffers will not be allocated in the first 4k.
> >
> > The one exception is 
> > i915_gem_object_create_stolen_for_preallocated()
> > which directly calls drm_mm_reserve_node() which now will be able to
> > use the first 4k.
> >
> > This fixes the i915 driver no longer being able to inherit the 
> > firmware
> > framebuffer on gen8+, which fixes the video output changing from the
> > vendor logo to a black screen as soon as the i915 driver is loaded
> > (on systems without fbcon).
> 
>  We've been told by the HW guys not to use the first page. (That's my
>  understanding from every time this gets questioned.)
> >>>
> >>> Yet the GOP is happily using the first page. I think we may need to 
> >>> make
> >>> a difference here between the GPU not using the first page and the
> >>> display engine/pipeline not using the first page. Note that my patch
> >>> only influences the inheriting of the initial framebuffer as allocated
> >>> by the GOP. It does not influence any other allocations from the
> >>> reserved range, those will still all avoid the first page.
> >>>
> >>> Without this patch fastboot / flickerfree support is essentially 
> >>> broken
> >>> on any gen8+ hardware given that one of the goals of atomic is to be
> >>> able to do flickerfree transitions I think that this warrants a closer
> >>> look then just simply saying never use the first page.
> >>
> >> The concern is what else (i.e. nothing that we allocated ourselves) 
> >> that
> >> may be in the first page...
> >
> > Given that the GOP has put its framebuffer there at least at boot there
> > is nothing there, otherwise it would show up on the display.
> >
> > We have a whole bunch of code to inherit the BIOS fb in intel_display.c
> > and AFAIK that code is there because this inheriting the BIOS fb is
> > deemed an important feature. So I'm not happy at all with the handwavy
> > best to not touch it answer I'm getting to this patch.
> >
> > Unless there are some clear answer from the hardware folks which 
> > specifically
> > say we cannot put a framebuffer there (and then why is the GOP doing 
> > it?)
> > then I believe that the best way forward here is to get various people 
> > to
> > test with this patch and the best way to do that is probably to put it
> > in next. Note I deliberately did not add a Cc stable.
> 
>  To elaborate on this, the excluding of the first 4k of the stolen memory
>  region causes intel_alloc_initial_plane_obj() from intel_display.c to 
>  fail,
>  which in turn causes intel_find_initial_plane_obj() to call
>

[Intel-gfx] [PATCH v3] drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Chris Wilson

We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.

v2: Just skip if already parked; makes it more forgiving to use by
future callers.
v3: Extract mark_busy, rename it to i915_gem_unpark and place it next to
i915_gem_park so that we can evaluate it for symmetry more easily.
Calling GEM from inside i915_request looks to be a bit of a layering
violation, for the moment I am imaging them as being notify_cb.

Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala  #v1
---
 drivers/gpu/drm/i915/i915_gem.c | 123 +---
 drivers/gpu/drm/i915/i915_gem.h |   5 ++
 drivers/gpu/drm/i915/i915_request.c |  52 +---
 3 files changed, 103 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b10c5f..a69dc19a0bdb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -136,6 +136,100 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
return 0;
 }
 
+static u32 __i915_gem_park(struct drm_i915_private *i915)
+{
+   lockdep_assert_held(>drm.struct_mutex);
+   GEM_BUG_ON(i915->gt.active_requests);
+
+   if (!i915->gt.awake)
+   return I915_EPOCH_INVALID;
+
+   GEM_BUG_ON(i915->gt.epoch == I915_EPOCH_INVALID);
+
+   /*
+* Be paranoid and flush a concurrent interrupt to make sure
+* we don't reactivate any irq tasklets after parking.
+*
+* FIXME: Note that even though we have waited for execlists to be idle,
+* there may still be an in-flight interrupt even though the CSB
+* is now empty. synchronize_irq() makes sure that a residual interrupt
+* is completed before we continue, but it doesn't prevent the HW from
+* raising a spurious interrupt later. To complete the shield we should
+* coordinate disabling the CS irq with flushing the interrupts.
+*/
+   synchronize_irq(i915->drm.irq);
+
+   intel_engines_park(i915);
+   i915_gem_timelines_park(i915);
+
+   i915_pmu_gt_parked(i915);
+
+   i915->gt.awake = false;
+
+   if (INTEL_GEN(i915) >= 6)
+   gen6_rps_idle(i915);
+
+   intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ);
+
+   intel_runtime_pm_put(i915);
+
+   return i915->gt.epoch;
+}
+
+void i915_gem_park(struct drm_i915_private *i915)
+{
+   lockdep_assert_held(>drm.struct_mutex);
+   GEM_BUG_ON(i915->gt.active_requests);
+
+   if (!i915->gt.awake)
+   return;
+
+   /* Defer the actual call to __i915_gem_park() to prevent ping-pongs */
+   mod_delayed_work(i915->wq, >gt.idle_work, msecs_to_jiffies(100));
+}
+
+void i915_gem_unpark(struct drm_i915_private *i915)
+{
+   lockdep_assert_held(>drm.struct_mutex);
+   GEM_BUG_ON(!i915->gt.active_requests);
+
+   if (i915->gt.awake)
+   return;
+
+   intel_runtime_pm_get_noresume(i915);
+
+   /*
+* It seems that the DMC likes to transition between the DC states a lot
+* when there are no connected displays (no active power domains) during
+* command submission.
+*
+* This activity has negative impact on the performance of the chip with
+* huge latencies observed in the interrupt handler and elsewhere.
+*
+* Work around it by grabbing a GT IRQ power domain whilst there is any
+* GT activity, preventing any DC state transitions.
+*/
+   intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
+
+   i915->gt.awake = true;
+   if (unlikely(++i915->gt.epoch == 0)) /* keep 0 as invalid */
+   i915->gt.epoch = 1;
+
+   intel_enable_gt_powersave(i915);
+   i915_update_gfx_val(i915);
+   if (INTEL_GEN(i915) >= 6)
+   gen6_rps_busy(i915);
+   i915_pmu_gt_unparked(i915);
+
+   intel_engines_unpark(i915);
+
+   i915_queue_hangcheck(i915);
+
+   queue_delayed_work(i915->wq,
+  >gt.retire_work,
+  round_jiffies_up_relative(HZ));
+}
+
 int
 i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
@@ -3496,36 +3590,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   /*
-* Be paranoid and flush a concurrent interrupt to make sure
-* we don't reactivate any irq tasklets after parking.
-*
-* FIXME: Note that even though we have waited for execlists to be idle,
-* there may still

Re: [Intel-gfx] [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases

2018-04-06 Thread Ville Syrjälä

On Thu, Mar 29, 2018 at 06:19:40AM +, Sripada, Radhakrishna wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Wednesday, March 28, 2018 3:36 AM
> > To: Maarten Lankhorst 
> > Cc: Sripada, Radhakrishna ; igt-
> > d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Srivatsa, 
> > Anusha
> > ; Vetter, Daniel ; Vivi,
> > Rodrigo ; Kahola, Mika ;
> > Navare, Manasi D 
> > Subject: Re: [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks
> > to one place for non exhaust fence cases
> > 
> > On Wed, Mar 28, 2018 at 10:29:15AM +0200, Maarten Lankhorst wrote:
> > > Op 22-03-18 om 23:10 schreef Radhakrishna Sripada:
> > > > From: Anusha Srivatsa 
> > > >
> > > > Cleanup the testcases by moving the platform checks to a single 
> > > > function.
> > > >
> > > > The earlier version of the path is posted here [1]
> > > >
> > > > v2: Make use of the property enums to get the supported rotations
> > > > v3: Move hardcodings to a single function(Ville)
> > > >
> > > > [1]: https://patchwork.freedesktop.org/patch/209647/
> > > >
> > > > Cc: Radhakrishna Sripada 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Daniel Vetter 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Mika Kahola 
> > > > Cc: Manasi Navare 
> > > > Signed-off-by: Anusha Srivatsa 
> > > > Signed-off-by: Radhakrishna Sripada 
> > > > ---
> > > >  tests/kms_rotation_crc.c | 31 ---
> > > >  1 file changed, 16 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> > > > index 0cd5c6e52b57..60fb9012e14e 100644
> > > > --- a/tests/kms_rotation_crc.c
> > > > +++ b/tests/kms_rotation_crc.c
> > > > @@ -43,6 +43,7 @@ typedef struct {
> > > > uint32_t override_fmt;
> > > > uint64_t override_tiling;
> > > > int devid;
> > > > +   int gen;
> > > >  } data_t;
> > > >
> > > >  typedef struct {
> > > > @@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
> > > > igt_assert(drmHandleEvent(fd, ) == 0);  }
> > > >
> > > > +static void igt_check_rotation(data_t *data) {
> > > > +   if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> > > > +   igt_require(data->gen >= 9);
> > > > +   else if (data->rotation & IGT_REFLECT_X)
> > > > +   igt_require(data->gen >= 10 ||
> > > > +   (IS_CHERRYVIEW(data->devid) && 
> > > > (data->rotation
> > & IGT_ROTATION_0)));
> > > > +   else if (data->rotation & IGT_ROTATION_180)
> > > > +   igt_require(data->gen >= 4);
> > > > +}
> > > This still won't work as intended on CHV as it only has reflection on 
> > > PIPE_B,
> > for X tiled fb's.
> > 
> > s/X tiled//
> So should we hack the reflect subtest to partially run for a single pipe and 
> skip for the other pipes on Chv? If so is there a non-murky way to do it?

At least skipping for pipe A/C should happen automagically if we ask the
plane what it supports. The pipe B case still needs to be special cased
though.

> 
> Thanks,
> Radhakrishna
> 
> > 
> > >
> > >
> > > >  static void test_single_case(data_t *data, enum pipe pipe,
> > > >  igt_output_t *output, igt_plane_t *plane,
> > > >  enum rectangle_type rect,
> > > > @@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data,
> > > > int plane_type, bool test_bad_form
> > > >
> > > > igt_display_require_output(display);
> > > >
> > > > +   igt_check_rotation(data);
> > > > +
> > > > for_each_pipe_with_valid_output(display, pipe, output) {
> > > > igt_plane_t *plane;
> > > > int i, j;
> > > >
> > > > -   if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> > > > -   continue;
> > > > -
> > > > igt_output_set_pipe(output, pipe);
> > > >
> > > > plane = igt_output_get_plane_type(output, plane_type); 
> > > > @@
> > -538,14
> > > > +549,13 @@ igt_main
> > > > };
> > > >
> > > > data_t data = {};
> > > > -   int gen = 0;
> > > >
> > > > igt_skip_on_simulation();
> > > >
> > > > igt_fixture {
> > > > data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> > > > data.devid = intel_get_drm_devid(data.gfx_fd);
> > > > -   gen = intel_gen(data.devid);
> > > > +   data.gen = intel_gen(data.devid);
> > > >
> > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split out parking from the idle worker for reuse (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Split out parking from the idle worker for reuse (rev2)
URL   : https://patchwork.freedesktop.org/series/41278/
State : failure

== Summary ==

Series 41278v2 drm/i915: Split out parking from the idle worker for reuse
https://patchwork.freedesktop.org/api/1.0/series/41278/revisions/2/mbox/

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
incomplete -> PASS   (fi-elk-e7500)
Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-kbl-7567u)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
pass   -> INCOMPLETE (fi-skl-6700k2) fdo#104108

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:519s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:519s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:264  dwarn:0   dfail:0   fail:1   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:636s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:243  pass:222  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:398s

3cbdbfb1ecc8769c8db88e95b1d6ea55c5e87dbf drm-tip: 2018y-04m-06d-15h-15m-21s UTC 
integration manifest
2109c0a440d9 drm/i915: Split out parking from the idle worker for reuse

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8623/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Aspect ratio support in DRM layer (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: Aspect ratio support in DRM layer (rev2)
URL   : https://patchwork.freedesktop.org/series/39960/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e9fb8279cbaa drm/modes: Introduce drm_mode_match()
-:39: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#39: FILE: drivers/gpu/drm/drm_modes.c:958:
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)

total: 0 errors, 0 warnings, 1 checks, 190 lines checked
c8c80aa31122 drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
7814e2b10e68 drm/edid: Fix cea mode aspect ratio handling
43c4528f5758 drm/edid: Don't send bogus aspect ratios in AVI infoframes
bb7278472467 video/hdmi: Reject illegal picture aspect ratios
73fd1b48e332 drm: Add DRM client cap for aspect-ratio
7044f8820325 drm: Add helper functions to handle aspect-ratio flag bits
03deca3a8769 drm: Handle aspect ratio info in legacy and atomic modeset paths
-:77: CHECK:SPACING: No space is necessary after a cast
#77: FILE: drivers/gpu/drm/drm_atomic.c:399:
+   u_mode = (struct drm_mode_modeinfo *) blob->data;

total: 0 errors, 0 warnings, 1 checks, 185 lines checked
3fcc37ccf3df drm: Expose modes with aspect ratio, only if requested
dc1b0391df73 drm: Add aspect ratio parsing in DRM layer
-:86: CHECK:SPACING: space preferred before that '|' (ctx:VxE)
#86: FILE: drivers/gpu/drm/drm_modes.c:1052:
+ DRM_MODE_MATCH_3D_FLAGS|
 ^

total: 0 errors, 0 warnings, 1 checks, 77 lines checked
41ab2195ed81 drm: Add and handle new aspect ratios in DRM layer
-:89: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#89: FILE: include/uapi/drm/drm_mode.h:108:
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
  ^

-:91: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#91: FILE: include/uapi/drm/drm_mode.h:110:
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
^

total: 0 errors, 0 warnings, 2 checks, 42 lines checked

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

Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

2018-04-06 Thread Nautiyal, Ankit K

This patch is causing failure of IGT test kms_3d. The kms_3d test 
expects the no. of 3d modes to be 13.


(The test has hard-coded value for expected no. of 3d modes as 13)

But due to the addition of "matching aspect_ratio" in drm_mode_equal in 
this patch, the total no. of


modes in the connector modelist is increased by 2, resulting in failure 
of assertion 'mode_count==13'.


Perhaps this need to be handled in the test.

-Regards,

Ankit


On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
 provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
 drm_fb_helper, while trying to find a common mode among connectors
 for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
  drivers/gpu/drm/drm_fb_helper.c | 12 ++--
  drivers/gpu/drm/drm_modes.c | 35 ++-
  2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b10..2ee1eaa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
  
  		fb_helper_conn = fb_helper->connector_info[i];

list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
modes[i] = mode;
}
if (!modes[i])
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d6133e8..454f2ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
  }
  EXPORT_SYMBOL(drm_mode_equal);
  
@@ -1647,6 +1648,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,

out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+

[Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

2018-04-06 Thread vathsala nagaraju

From: Vathsala Nagaraju 

For psr block #9, the vbt description has moved to options [0-3] for
TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
structure. Since spec does not  mention from which VBT version this
change was added to vbt.bsf file, we cannot depend on bdb->version check
to change for all the platforms.

There is RCR inplace for GOP team to  provide the version number
to make generic change. Since Kabylake with bdb version 209 is having this
change, limiting this change to kbl and version 209+ to unblock google.

bspec 20131

Cc: Rodrigo Vivi 
CC: Puthikorn Voravootivat 

Signed-off-by: Maulik V Vaghela 
Signed-off-by: Vathsala Nagaraju 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c |  2 +-
 drivers/gpu/drm/i915/intel_psr.c  | 84 ++-
 3 files changed, 59 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b17..a47be19b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1075,6 +1075,7 @@ struct intel_vbt_data {
enum psr_lines_to_wait lines_to_wait;
int tp1_wakeup_time;
int tp2_tp3_wakeup_time;
+   int bdb_version;
} psr;
 
struct {
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c5c7530..cfefd32 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -658,7 +658,7 @@ static int intel_bios_ssc_frequency(struct drm_i915_private 
*dev_priv,
DRM_DEBUG_KMS("No PSR BDB found.\n");
return;
}
-
+   dev_priv->vbt.psr.bdb_version = bdb->version;
psr_table = >psr_table[panel_type];
 
dev_priv->vbt.psr.full_link = psr_table->full_link;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2d53f73..e470d5e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -353,24 +353,45 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
if (dev_priv->psr.link_standby)
val |= EDP_PSR_LINK_STANDBY;
 
-   if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
-   val |= EDP_PSR_TP1_TIME_2500us;
-   else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
-   val |= EDP_PSR_TP1_TIME_500us;
-   else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
-   val |= EDP_PSR_TP1_TIME_100us;
-   else
-   val |= EDP_PSR_TP1_TIME_0us;
-
-   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
-   val |= EDP_PSR_TP2_TP3_TIME_2500us;
-   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
-   val |= EDP_PSR_TP2_TP3_TIME_500us;
-   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
-   val |= EDP_PSR_TP2_TP3_TIME_100us;
-   else
-   val |= EDP_PSR_TP2_TP3_TIME_0us;
+   if (dev_priv->vbt.psr.bdb_version >= 209 && IS_KABYLAKE(dev_priv)) {
+   if (dev_priv->vbt.psr.tp1_wakeup_time == 0)
+   val |= EDP_PSR_TP1_TIME_500us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time == 1)
+   val |= EDP_PSR_TP1_TIME_100us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time == 2)
+   val |= EDP_PSR_TP1_TIME_2500us;
+   else
+   val |= EDP_PSR_TP1_TIME_0us;
+   } else {
+   if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
+   val |= EDP_PSR_TP1_TIME_2500us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
+   val |= EDP_PSR_TP1_TIME_500us;
+   else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
+   val |= EDP_PSR_TP1_TIME_100us;
+   else
+   val |= EDP_PSR_TP1_TIME_0us;
+   }
 
+   if (dev_priv->vbt.psr.bdb_version >= 209 && IS_KABYLAKE(dev_priv)) {
+   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 0)
+   val |=  EDP_PSR_TP2_TP3_TIME_500us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 1)
+   val |= EDP_PSR_TP2_TP3_TIME_100us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 2)
+   val |= EDP_PSR_TP2_TP3_TIME_2500us;
+   else
+   val |= EDP_PSR_TP2_TP3_TIME_0us;
+   } else {
+   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
+   val |= EDP_PSR_TP2_TP3_TIME_2500us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
+   val |= EDP_PSR_TP2_TP3_TIME_500us;
+   else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
+   val |=

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Split out parking from the idle worker for reuse

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915: Split out parking from the idle worker for reuse
URL   : https://patchwork.freedesktop.org/series/41278/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-absolute-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +2

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

shard-apltotal:2680 pass:1836 dwarn:1   dfail:0   fail:7   skip:836 
time:12678s
shard-hswtotal:2680 pass:1783 dwarn:1   dfail:0   fail:4   skip:891 
time:11348s
shard-snbtotal:2680 pass:1378 dwarn:1   dfail:0   fail:2   skip:1299 
time:6890s
Blacklisted hosts:
shard-kbltotal:2680 pass:1936 dwarn:27  dfail:0   fail:7   skip:710 
time:8994s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8622/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

2018-04-06 Thread Rodrigo Vivi

On Fri, Apr 06, 2018 at 10:58:51PM +0530, vathsala nagaraju wrote:
> From: Vathsala Nagaraju 
> 
> For psr block #9, the vbt description has moved to options [0-3] for
> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
> structure. Since spec does not  mention from which VBT version this
> change was added to vbt.bsf file, we cannot depend on bdb->version check
> to change for all the platforms.
> 
> There is RCR inplace for GOP team to  provide the version number
> to make generic change. Since Kabylake with bdb version 209 is having this
> change, limiting this change to kbl and version 209+ to unblock google.
> 
> bspec 20131
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> 
> Signed-off-by: Maulik V Vaghela 
> Signed-off-by: Vathsala Nagaraju 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c |  2 +-
>  drivers/gpu/drm/i915/intel_psr.c  | 84 
> ++-
>  3 files changed, 59 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5373b17..a47be19b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1075,6 +1075,7 @@ struct intel_vbt_data {
>   enum psr_lines_to_wait lines_to_wait;
>   int tp1_wakeup_time;
>   int tp2_tp3_wakeup_time;
> + int bdb_version;

please keep the vbt stuff inside intel_bios.c

so there at intel_bios.c you parse the vbt and based on the vbt version
you export in a standard way to intel_psr.c

>   } psr;
>  
>   struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index c5c7530..cfefd32 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -658,7 +658,7 @@ static int intel_bios_ssc_frequency(struct 
> drm_i915_private *dev_priv,
>   DRM_DEBUG_KMS("No PSR BDB found.\n");
>   return;
>   }
> -
> + dev_priv->vbt.psr.bdb_version = bdb->version;
>   psr_table = >psr_table[panel_type];
>  
>   dev_priv->vbt.psr.full_link = psr_table->full_link;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2d53f73..e470d5e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -353,24 +353,45 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
>   if (dev_priv->psr.link_standby)
>   val |= EDP_PSR_LINK_STANDBY;
>  
> - if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
> - val |= EDP_PSR_TP1_TIME_2500us;
> - else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
> - val |= EDP_PSR_TP1_TIME_500us;
> - else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
> - val |= EDP_PSR_TP1_TIME_100us;
> - else
> - val |= EDP_PSR_TP1_TIME_0us;
> -
> - if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> - val |= EDP_PSR_TP2_TP3_TIME_2500us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
> - val |= EDP_PSR_TP2_TP3_TIME_500us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
> - val |= EDP_PSR_TP2_TP3_TIME_100us;
> - else
> - val |= EDP_PSR_TP2_TP3_TIME_0us;
> + if (dev_priv->vbt.psr.bdb_version >= 209 && IS_KABYLAKE(dev_priv)) {
> + if (dev_priv->vbt.psr.tp1_wakeup_time == 0)
> + val |= EDP_PSR_TP1_TIME_500us;
> + else if (dev_priv->vbt.psr.tp1_wakeup_time == 1)
> + val |= EDP_PSR_TP1_TIME_100us;
> + else if (dev_priv->vbt.psr.tp1_wakeup_time == 2)
> + val |= EDP_PSR_TP1_TIME_2500us;
> + else
> + val |= EDP_PSR_TP1_TIME_0us;
> + } else {
> + if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
> + val |= EDP_PSR_TP1_TIME_2500us;
> + else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
> + val |= EDP_PSR_TP1_TIME_500us;
> + else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
> + val |= EDP_PSR_TP1_TIME_100us;
> + else
> + val |= EDP_PSR_TP1_TIME_0us;
> + }
>  
> + if (dev_priv->vbt.psr.bdb_version >= 209 && IS_KABYLAKE(dev_priv)) {
> + if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 0)
> + val |=  EDP_PSR_TP2_TP3_TIME_500us;
> + else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 1)
> + val |= EDP_PSR_TP2_TP3_TIME_100us;
> + else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time == 2)
> + val |= EDP_PSR_TP2_TP3_TIME_2500us;
> + else
> + val |= EDP_PSR_TP2_TP3_TIME_0us;
> + } else {
> + if

[Intel-gfx] ✓ Fi.CI.BAT: success for Aspect ratio support in DRM layer (rev2)

2018-04-06 Thread Patchwork

== Series Details ==

Series: Aspect ratio support in DRM layer (rev2)
URL   : https://patchwork.freedesktop.org/series/39960/
State : success

== Summary ==

Series 39960v2 Aspect ratio support in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/39960/revisions/2/mbox/

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
incomplete -> PASS   (fi-elk-e7500)

 Known issues:

Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#105589
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

fdo#105589 https://bugs.freedesktop.org/show_bug.cgi?id=105589
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:429s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:518s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:527s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:508s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:511s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:313s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:259  dwarn:1   dfail:1   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:657s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:504s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:433s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:407s

3cbdbfb1ecc8769c8db88e95b1d6ea55c5e87dbf drm-tip: 2018y-04m-06d-15h-15m-21s UTC 
integration manifest
41ab2195ed81 drm: Add and handle new aspect ratios in DRM layer
dc1b0391df73 drm: Add aspect ratio parsing in DRM layer
3fcc37ccf3df drm: Expose modes with aspect ratio, only if requested
03deca3a8769 drm: Handle aspect ratio info in legacy and atomic modeset paths
7044f8820325 drm: Add helper functions to handle aspect-ratio flag bits
73fd1b48e332 drm: Add DRM client cap for aspect-ratio
bb7278472467 video/hdmi: Reject illegal picture aspect ratios
43c4528f5758 drm/edid: Don't send bogus aspect ratios in AVI infoframes
7814e2b10e68 drm/edid: Fix cea mode aspect ratio handling
c8c80aa31122 drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
e9fb8279cbaa drm/modes: Introduce drm_mode_match()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8625/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

2018-04-06 Thread Ville Syrjälä

On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
> This patch is causing failure of IGT test kms_3d. The kms_3d test 
> expects the no. of 3d modes to be 13.
> 
> (The test has hard-coded value for expected no. of 3d modes as 13)
> 
> But due to the addition of "matching aspect_ratio" in drm_mode_equal in 
> this patch, the total no. of
> 
> modes in the connector modelist is increased by 2, resulting in failure 
> of assertion 'mode_count==13'.

If kms_3d isn't setting the aspect ratio cap how is it affected by these
changes?

> 
> Perhaps this need to be handled in the test.
> 
> -Regards,
> 
> Ankit
> 
> 
> On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:
> > From: "Sharma, Shashank" 
> >
> > Current DRM layer functions don't parse aspect ratio information
> > while converting a user mode->kernel mode or vice versa. This
> > causes modeset to pick mode with wrong aspect ratio, eventually
> > causing failures in HDMI compliance test cases, due to wrong VIC.
> >
> > This patch adds aspect ratio information in DRM's mode conversion
> > and mode comparision functions, to make sure kernel picks mode
> > with right aspect ratio (as per the VIC).
> >
> > Background:
> > This patch was once reviewed and merged, and later reverted due to
> > lack of DRM cap protection. This is a re-spin of this patch, this
> > time with DRM cap protection, to avoid aspect ratio information, when
> > the client doesn't request for it.
> >
> > Review link: https://pw-emeril.freedesktop.org/patch/104068/
> > Background discussion: https://patchwork.kernel.org/patch/9379057/
> >
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Lin, Jia 
> > Signed-off-by: Akashdeep Sharma 
> > Reviewed-by: Jim Bride  (V2)
> > Reviewed-by: Jose Abreu  (V4)
> >
> > Cc: Ville Syrjala 
> > Cc: Jim Bride 
> > Cc: Jose Abreu 
> > Cc: Ankit Nautiyal 
> >
> > V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> >  provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> > V4: rebase
> > V5: rebase
> > V6: As recommended by Ville, avoided matching of aspect-ratio in
> >  drm_fb_helper, while trying to find a common mode among connectors
> >  for the target clone mode.
> > V7: rebase
> > V8: rebase
> > V9: rebase
> > V10: rebase
> > ---
> >   drivers/gpu/drm/drm_fb_helper.c | 12 ++--
> >   drivers/gpu/drm/drm_modes.c | 35 ++-
> >   2 files changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 0646b10..2ee1eaa 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
> > *fb_helper,
> > for (j = 0; j < i; j++) {
> > if (!enabled[j])
> > continue;
> > -   if (!drm_mode_equal(modes[j], modes[i]))
> > +   if (!drm_mode_match(modes[j], modes[i],
> > +   DRM_MODE_MATCH_TIMINGS |
> > +   DRM_MODE_MATCH_CLOCK |
> > +   DRM_MODE_MATCH_FLAGS |
> > +   DRM_MODE_MATCH_3D_FLAGS))
> > can_clone = false;
> > }
> > }
> > @@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
> > *fb_helper,
> >   
> > fb_helper_conn = fb_helper->connector_info[i];
> > list_for_each_entry(mode, _helper_conn->connector->modes, 
> > head) {
> > -   if (drm_mode_equal(mode, dmt_mode))
> > +   if (drm_mode_match(mode, dmt_mode,
> > +  DRM_MODE_MATCH_TIMINGS |
> > +  DRM_MODE_MATCH_CLOCK |
> > +  DRM_MODE_MATCH_FLAGS |
> > +  DRM_MODE_MATCH_3D_FLAGS))
> > modes[i] = mode;
> > }
> > if (!modes[i])
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index d6133e8..454f2ff 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode 
> > *mode1,
> >   DRM_MODE_MATCH_TIMINGS |
> >   DRM_MODE_MATCH_CLOCK |
> >   DRM_MODE_MATCH_FLAGS |
> > - DRM_MODE_MATCH_3D_FLAGS);
> > + DRM_MODE_MATCH_3D_FLAGS|
> > +

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: vbt change for psr

2018-04-06 Thread Patchwork

== Series Details ==

Series: drm/i915/psr: vbt change for psr
URL   : https://patchwork.freedesktop.org/series/41289/
State : success

== Summary ==

Series 41289v1 drm/i915/psr: vbt change for psr
https://patchwork.freedesktop.org/api/1.0/series/41289/revisions/1/mbox/

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
incomplete -> PASS   (fi-elk-e7500)

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:428s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
time:594s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:659s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:569s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:405s

3cbdbfb1ecc8769c8db88e95b1d6ea55c5e87dbf drm-tip: 2018y-04m-06d-15h-15m-21s UTC 
integration manifest
1630bdc52cc9 drm/i915/psr: vbt change for psr

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8626/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

< 1 2

101 - 198 of 198 matches

Mail list logo