date:20180423

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

2018-04-23 Thread Nautiyal, Ankit K




On 4/23/2018 3:43 PM, Ville Syrjälä wrote:

On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:


On 4/20/2018 7:42 PM, Ville Syrjälä wrote:

On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:

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;

Odd line split here. Makes this a bit hard to read.
I would split after the ||

Agreed. I wasn't sure how to let it have better readability and less
than 80 char length
at the same time. Will fix this.


+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);

Do we actually need to export these? I don't think so.

But I might be wrong. It's a bit hard to see with the way
you split this patch with the actual users in a different patch.

These helper functions are used in drm_mode_atomic.c, drm_mode_crtc.c,
and drm_mode_get_connector.c
The patches are split as to have modes-set handling separate and the
exposing of connector separate.
Do you suggest this patch to be merged with the patch for handling
aspect-ratio in modeset?

Usually if you add a function you should do it in the same patch where
you add the user(s) for said function. Otherwise it's impossibly to
judge whether the new function is any good.


That makes sense. I will merge this patch with the patch for handling 
aspect ratio in modeset path,

where its actually used.




+
+/**
+ * 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

--
Ville Syrjälä
Intel


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

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

2018-04-23 Thread Nautiyal, Ankit K




On 4/23/2018 3:52 PM, Jani Nikula wrote:

On Mon, 23 Apr 2018, "Nautiyal, Ankit K"  wrote:

On 4/20/2018 7:42 PM, Ville Syrjälä wrote:

On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 
+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;

Odd line split here. Makes this a bit hard to read.
I would split after the ||

Agreed. I wasn't sure how to let it have better readability and less
than 80 char length at the same time. Will fix this.

80 chars is not a strict requirement. Readability is. ;)

BR,
Jani.


Roger that! :)


___
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/3] drm/i915/dp: Check if the sink crc we read is 6 bytes.

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read 
is 6 bytes.
URL   : https://patchwork.freedesktop.org/series/42154/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8783 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8783 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8783, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42154/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8783:

  === IGT changes ===

 Possible regressions 

igt@kms_frontbuffer_tracking@basic:
  fi-cnl-y3:  PASS -> FAIL
  fi-cnl-psr: PASS -> FAIL
  fi-cfl-s3:  PASS -> FAIL
  {fi-kbl-7560u}: PASS -> FAIL
  fi-skl-6600u:   PASS -> FAIL
  fi-kbl-r:   PASS -> FAIL
  fi-cfl-u:   PASS -> FAIL


 Warnings 

igt@kms_force_connector_basic@force-load-detect:
  fi-ivb-3520m:   PASS -> SKIP +3

igt@kms_sink_crc_basic:
  fi-cfl-u:   PASS -> SKIP
  fi-cnl-psr: PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8783 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: PASS -> FAIL (fdo#102575)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  fi-skl-guc: PASS -> FAIL (fdo#103191)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-ilk-650: DMESG-WARN -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

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


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4082 -> Patchwork_8783

  CI_DRM_4082: 0600266ef9b8407e0dc281acb6b754eba8178c91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8783: c0e07f8b9d9412e9d41da72654ec408658913b94 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

c0e07f8b9d94 drm/i915/psr: Move sink-crc to intel_psr.c
676d279f8a86 drm/i915/dp: Fix sink-crc reads.
7fc2b33053e5 drm/i915/dp: Check if the sink crc we read is 6 bytes.

== Logs ==

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

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes.

2018-04-23 Thread Dhinakaran Pandiyan

We attempt to read 6 bytes, make sure we have.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..7dcc874b7d8f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3989,7 +3989,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, struct 
intel_crtc_state *crtc_s
goto stop;
}
 
-   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
+   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) != 6) {
ret = -EIO;
goto stop;
}
-- 
2.14.1

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

[Intel-gfx] [PATCH 3/3] drm/i915/psr: Move sink-crc to intel_psr.c

2018-04-23 Thread Dhinakaran Pandiyan

With sink-crc now being relevant only for PSR static frames, move the
code to intel_psr.c and rename the function.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/intel_dp.c | 35 ---
 drivers/gpu/drm/i915/intel_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_psr.c| 35 +++
 4 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 35fa1418cc07..9913258e20ed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2784,7 +2784,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
 
intel_dp = enc_to_intel_dp(state->best_encoder);
 
-   ret = intel_dp_sink_crc(intel_dp, crc);
+   ret = intel_psr_sink_crc(intel_dp, crc);
if (ret)
goto err;
 
@@ -4854,7 +4854,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_ppgtt_info", i915_ppgtt_info, 0},
{"i915_llc", i915_llc, 0},
{"i915_edp_psr_status", i915_edp_psr_status, 0},
-   {"i915_sink_crc_eDP1", i915_sink_crc, 0},
+   {"i915_edp_psr_sink_crc", i915_sink_crc, 0},
{"i915_energy_uJ", i915_energy_uJ, 0},
{"i915_runtime_pm_status", i915_runtime_pm_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7352ab631ea8..ff7522d3632e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3876,41 +3876,6 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
intel_dp->is_mst);
 }
 
-int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
-{
-   int count = 0, ret = 0, attempts;
-
-   for (attempts = 0; attempts < 3 && count == 0; attempts++) {
-   u8 buf;
-
-   /* Wait for approximately half a frame, we cannot wait for a
-* vblank interrupt as it triggers PSR exit.
-*/
-   if (attempts)
-   usleep_range(8000, 8500);
-
-   if (drm_dp_dpcd_readb(_dp->aux,
- DP_TEST_SINK_MISC, ) < 0) {
-   ret = -EIO;
-   goto out;
-   }
-   count = buf & DP_TEST_COUNT_MASK;
-   }
-
-   if (attempts == 3) {
-   ret = -ETIMEDOUT;
-   goto out;
-   }
-
-   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) != 6) {
-   ret = -EIO;
-   goto out;
-   }
-
-out:
-   return ret;
-}
-
 static bool
 intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cacee94749e2..0da7be3349cc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1644,7 +1644,6 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode);
 void intel_dp_encoder_reset(struct drm_encoder *encoder);
 void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
 void intel_dp_encoder_destroy(struct drm_encoder *encoder);
-int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config,
 struct drm_connector_state *conn_state);
@@ -1900,6 +1899,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
  struct intel_crtc_state *crtc_state);
 void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
 void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
+int intel_psr_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 
 /* intel_runtime_pm.c */
 int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0d548292dd09..4ebd05b6e86d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -197,6 +197,41 @@ static u8 intel_dp_get_sink_sync_latency(struct intel_dp 
*intel_dp)
return val;
 }
 
+int intel_psr_sink_crc(struct intel_dp *intel_dp, u8 *crc)
+{
+   int count = 0, ret = 0, attempts;
+
+   for (attempts = 0; attempts < 3 && count == 0; attempts++) {
+   u8 buf;
+
+   /* Wait for approximately half a frame, we cannot wait for a
+* vblank interrupt as it triggers PSR exit.
+*/
+   if (attempts)
+   usleep_range(8000, 8500);
+
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_TEST_SINK_MISC, ) < 0) {
+   ret = -EIO;

[Intel-gfx] [PATCH 2/3] drm/i915/dp: Fix sink-crc reads.

2018-04-23 Thread Dhinakaran Pandiyan

Sink crc is calculated by the sink for static frames irrespective of
what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
case for sink crc, we don't really need the sink_crc_{start, stop} code.

The second problem with the current implementation is vblank waits.
Enabling vblank interrupts triggers PSR exit, which means we aren't
really reading the correct CRC values for PSR tests. vblank waits are
replaced by delays.

With the changes made in this patch, sink CRC is available only for
static frames. I have tested this on a SKL laptop with PSR panel.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c |   2 +-
 drivers/gpu/drm/i915/intel_dp.c | 114 
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 3 files changed, 15 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..35fa1418cc07 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2784,7 +2784,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
 
intel_dp = enc_to_intel_dp(state->best_encoder);
 
-   ret = intel_dp_sink_crc(intel_dp, crtc_state, crc);
+   ret = intel_dp_sink_crc(intel_dp, crc);
if (ret)
goto err;
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7dcc874b7d8f..7352ab631ea8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3876,32 +3876,18 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
intel_dp->is_mst);
 }
 
-static int intel_dp_sink_crc_stop(struct intel_dp *intel_dp,
- struct intel_crtc_state *crtc_state, bool 
disable_wa)
+int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
 {
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
-   u8 buf;
-   int ret = 0;
-   int count = 0;
-   int attempts = 10;
+   int count = 0, ret = 0, attempts;
 
-   if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK, ) < 0) {
-   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
-   ret = -EIO;
-   goto out;
-   }
+   for (attempts = 0; attempts < 3 && count == 0; attempts++) {
+   u8 buf;
 
-   if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_SINK,
-  buf & ~DP_TEST_SINK_START) < 0) {
-   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
-   ret = -EIO;
-   goto out;
-   }
-
-   do {
-   intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+   /* Wait for approximately half a frame, we cannot wait for a
+* vblank interrupt as it triggers PSR exit.
+*/
+   if (attempts)
+   usleep_range(8000, 8500);
 
if (drm_dp_dpcd_readb(_dp->aux,
  DP_TEST_SINK_MISC, ) < 0) {
@@ -3909,93 +3895,19 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
*intel_dp,
goto out;
}
count = buf & DP_TEST_COUNT_MASK;
-   } while (--attempts && count);
-
-   if (attempts == 0) {
-   DRM_DEBUG_KMS("TIMEOUT: Sink CRC counter is not zeroed after 
calculation is stopped\n");
-   ret = -ETIMEDOUT;
}
 
- out:
-   if (disable_wa)
-   hsw_enable_ips(crtc_state);
-   return ret;
-}
-
-static int intel_dp_sink_crc_start(struct intel_dp *intel_dp,
-  struct intel_crtc_state *crtc_state)
-{
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
-   u8 buf;
-   int ret;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, ) < 0)
-   return -EIO;
-
-   if (!(buf & DP_TEST_CRC_SUPPORTED))
-   return -ENOTTY;
-
-   if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK, ) < 0)
-   return -EIO;
-
-   if (buf & DP_TEST_SINK_START) {
-   ret = intel_dp_sink_crc_stop(intel_dp, crtc_state, false);
-   if (ret)
-   return ret;
-   }
-
-   hsw_disable_ips(crtc_state);
-
-   if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_SINK,
-  buf | DP_TEST_SINK_START) < 0) {
-   hsw_enable_ips(crtc_state);
-   return -EIO;
-   }
-
-   intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
-   return

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Build request info on stack before printk (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915: Build request info on stack before printk (rev2)
URL   : https://patchwork.freedesktop.org/series/42150/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4082_full -> Patchwork_8781_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8781_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8781_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42150/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8781_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +4

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-kbl:  PASS -> SKIP +20

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  PASS -> SKIP +42

igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack:
  shard-glk:  SKIP -> PASS +45


== Known issues ==

  Here are the changes found in Patchwork_8781_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#106087)

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103558)

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  PASS -> FAIL (fdo#102370)

igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip:
  shard-kbl:  PASS -> DMESG-WARN (fdo#105602, fdo#103313, 
fdo#103558)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)

igt@pm_rpm@pm-caching:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103313, fdo#103558)


 Possible fixes 

igt@gem_exec_parallel@default-contexts:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions:
  shard-apl:  FAIL (fdo#103207) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  FAIL (fdo#103060) -> PASS +1


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
  fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4082 -> Patchwork_8781

  CI_DRM_4082: 0600266ef9b8407e0dc281acb6b754eba8178c91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8781: 82f3d491ddbe50ab7d41593587b28fbffb0c1c3b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8781/shards.html
___
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: Don't dump umpteen thousand requests

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915: Don't dump umpteen thousand requests
URL   : https://patchwork.freedesktop.org/series/42151/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8782 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8782 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8782, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42151/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8782:

  === IGT changes ===

 Possible regressions 

igt@gem_ringfill@basic-default-hang:
  fi-cfl-u:   PASS -> INCOMPLETE
  fi-cfl-s3:  PASS -> INCOMPLETE
  fi-skl-6700k2:  PASS -> INCOMPLETE
  fi-ivb-3770:PASS -> INCOMPLETE
  fi-skl-6770hq:  PASS -> INCOMPLETE
  fi-ivb-3520m:   PASS -> INCOMPLETE
  fi-ilk-650: PASS -> INCOMPLETE
  {fi-kbl-7560u}: PASS -> INCOMPLETE
  fi-hsw-4770:PASS -> INCOMPLETE
  fi-bsw-n3050:   PASS -> INCOMPLETE
  fi-skl-6600u:   PASS -> INCOMPLETE
  fi-cfl-8700k:   PASS -> INCOMPLETE
  fi-kbl-r:   PASS -> INCOMPLETE
  fi-kbl-7567u:   PASS -> INCOMPLETE
  fi-bdw-5557u:   PASS -> INCOMPLETE
  fi-kbl-7500u:   PASS -> INCOMPLETE
  fi-snb-2600:PASS -> INCOMPLETE
  fi-skl-6260u:   PASS -> INCOMPLETE


 Warnings 

igt@gem_ringfill@basic-default-hang:
  fi-blb-e6850:   DMESG-WARN (fdo#101600) -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8782 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@gem_ringfill@basic-default-hang:
  fi-skl-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
  fi-byt-n2820:   PASS -> INCOMPLETE (fdo#102657)
  fi-cnl-psr: PASS -> INCOMPLETE (fdo#105086)
  fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)
  fi-elk-e7500:   PASS -> INCOMPLETE (fdo#103989)
  fi-byt-j1900:   PASS -> INCOMPLETE (fdo#102657)
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
  fi-glk-j4005:   PASS -> INCOMPLETE (fdo#103359, k.org#198133)
  fi-bdw-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
  fi-bxt-j4205:   PASS -> INCOMPLETE (fdo#103927)


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4082 -> Patchwork_8782

  CI_DRM_4082: 0600266ef9b8407e0dc281acb6b754eba8178c91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8782: fb469863454286bdd6ba86a2b08a373b5340f572 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

fb4698634542 drm/i915: Don't dump umpteen thousand requests

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8782/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: Build request info on stack before printk (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915: Build request info on stack before printk (rev2)
URL   : https://patchwork.freedesktop.org/series/42150/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8781 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42150/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8781 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: PASS -> FAIL (fdo#102575)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  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


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4082 -> Patchwork_8781

  CI_DRM_4082: 0600266ef9b8407e0dc281acb6b754eba8178c91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8781: 82f3d491ddbe50ab7d41593587b28fbffb0c1c3b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

82f3d491ddbe drm/i915: Build request info on stack before printk

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8781/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: Build request info on stack before printk

2018-04-23 Thread Chris Wilson

Quoting Chris Wilson (2018-04-24 02:08:39)
> printk unhelpfully inserts a '\n' between consecutive calls, and since
> our drm_printf wrapper may be emitting info a seq_file instead,
> KERN_CONT is not an option. To work with any drm_printf destination, we
> need to build up the output into a temporary buf on the stack and then
> feed the complete line in a single call to printk.
> 
> Fixes: b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a 
> struct")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---

I put back the i915 parameter as it makes later patches easier. The
conflict in rebasing was a reminder why it was there in the first place.
-Chris

>  drivers/gpu/drm/i915/intel_engine_cs.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index be608f7111f5..66cddd059666 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1113,14 +1113,17 @@ unsigned int 
> intel_engines_has_context_isolation(struct drm_i915_private *i915)
> return which;
>  }
>  
> -static void print_sched_attr(struct drm_printer *m,
> -const struct drm_i915_private *i915,
> -const struct i915_sched_attr *attr)
> +static int print_sched_attr(struct drm_i915_private *i915,
> +   const struct i915_sched_attr *attr,
> +   char *buf, int x, int len)
>  {
> if (attr->priority == I915_PRIORITY_INVALID)
> -   return;
> +   return x;
> +
> +   x += snprintf(buf + x, len - x,
> + " prio=%d", attr->priority);
>  
> -   drm_printf(m, "prio=%d", attr->priority);
> +   return x;
>  }
>  
>  static void print_request(struct drm_printer *m,
> @@ -1128,14 +1131,17 @@ static void print_request(struct drm_printer *m,
>   const char *prefix)
>  {
> const char *name = rq->fence.ops->get_timeline_name(>fence);
> +   char buf[80];
> +   int x = 0;
> +
> +   x = print_sched_attr(rq->i915, >sched.attr, buf, x, sizeof(buf));
>  
> -   drm_printf(m, "%s%x%s [%llx:%x] ",
> +   drm_printf(m, "%s%x%s [%llx:%x]%s @ %dms: %s\n",
>prefix,
>rq->global_seqno,
>i915_request_completed(rq) ? "!" : "",
> -  rq->fence.context, rq->fence.seqno);
> -   print_sched_attr(m, rq->i915, >sched.attr);
> -   drm_printf(m, " @ %dms: %s\n",
> +  rq->fence.context, rq->fence.seqno,
> +  buf,
>jiffies_to_msecs(jiffies - rq->emitted_jiffies),
>name);
>  }
> -- 
> 2.17.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Don't dump umpteen thousand requests

2018-04-23 Thread Chris Wilson

If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most often comparing the first/last
in the queue is enough to identify problems in the scheduling.

We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common
debug scenarios, but for the moment if we can avoiding spending more
than a few seconds dumping the GPU state that will avoid a nasty
livelock (where hangcheck spends so long dumping the state, it fires
again and starts to dump the state again in parallel, ad infinitum).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 41 +++---
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 66cddd059666..db28f9e3c306 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1307,11 +1307,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
   struct drm_printer *m,
   const char *header, ...)
 {
+   const int MAX_REQUESTS_TO_SHOW = 8;
struct intel_breadcrumbs * const b = >breadcrumbs;
const struct intel_engine_execlists * const execlists = 
>execlists;
struct i915_gpu_error * const error = >i915->gpu_error;
-   struct i915_request *rq;
+   struct i915_request *rq, *last;
struct rb_node *rb;
+   int count;
 
if (header) {
va_list ap;
@@ -1378,16 +1380,47 @@ void intel_engine_dump(struct intel_engine_cs *engine,
}
 
spin_lock_irq(>timeline->lock);
-   list_for_each_entry(rq, >timeline->requests, link)
+
+   last = NULL;
+   count = 0;
+   list_for_each_entry(rq, >timeline->requests, link) {
+   if (count++ < MAX_REQUESTS_TO_SHOW - 1)
+   print_request(m, rq, "\t\tE ");
+   else
+   last = rq;
+   }
+   if (last) {
+   if (count > MAX_REQUESTS_TO_SHOW) {
+   drm_printf(m,
+  "\t\t...skipping %d executing requests...\n",
+  count - MAX_REQUESTS_TO_SHOW);
+   }
print_request(m, rq, "\t\tE ");
+   }
+
+   last = NULL;
+   count = 0;
drm_printf(m, "\t\tQueue priority: %d\n", execlists->queue_priority);
for (rb = execlists->first; rb; rb = rb_next(rb)) {
struct i915_priolist *p =
rb_entry(rb, typeof(*p), node);
 
-   list_for_each_entry(rq, >requests, sched.link)
-   print_request(m, rq, "\t\tQ ");
+   list_for_each_entry(rq, >requests, sched.link) {
+   if (count++ < MAX_REQUESTS_TO_SHOW - 1)
+   print_request(m, rq, "\t\tQ ");
+   else
+   last = rq;
+   }
}
+   if (last) {
+   if (count > MAX_REQUESTS_TO_SHOW) {
+   drm_printf(m,
+  "\t\t...skipping %d queued requests...\n",
+  count - MAX_REQUESTS_TO_SHOW);
+   }
+   print_request(m, last, "\t\tQ ");
+   }
+
spin_unlock_irq(>timeline->lock);
 
spin_lock_irq(>rb_lock);
-- 
2.17.0

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

[Intel-gfx] [PATCH] drm/i915: Build request info on stack before printk

2018-04-23 Thread Chris Wilson

printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete line in a single call to printk.

Fixes: b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a 
struct")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index be608f7111f5..66cddd059666 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1113,14 +1113,17 @@ unsigned int intel_engines_has_context_isolation(struct 
drm_i915_private *i915)
return which;
 }
 
-static void print_sched_attr(struct drm_printer *m,
-const struct drm_i915_private *i915,
-const struct i915_sched_attr *attr)
+static int print_sched_attr(struct drm_i915_private *i915,
+   const struct i915_sched_attr *attr,
+   char *buf, int x, int len)
 {
if (attr->priority == I915_PRIORITY_INVALID)
-   return;
+   return x;
+
+   x += snprintf(buf + x, len - x,
+ " prio=%d", attr->priority);
 
-   drm_printf(m, "prio=%d", attr->priority);
+   return x;
 }
 
 static void print_request(struct drm_printer *m,
@@ -1128,14 +1131,17 @@ static void print_request(struct drm_printer *m,
  const char *prefix)
 {
const char *name = rq->fence.ops->get_timeline_name(>fence);
+   char buf[80];
+   int x = 0;
+
+   x = print_sched_attr(rq->i915, >sched.attr, buf, x, sizeof(buf));
 
-   drm_printf(m, "%s%x%s [%llx:%x] ",
+   drm_printf(m, "%s%x%s [%llx:%x]%s @ %dms: %s\n",
   prefix,
   rq->global_seqno,
   i915_request_completed(rq) ? "!" : "",
-  rq->fence.context, rq->fence.seqno);
-   print_sched_attr(m, rq->i915, >sched.attr);
-   drm_printf(m, " @ %dms: %s\n",
+  rq->fence.context, rq->fence.seqno,
+  buf,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   name);
 }
-- 
2.17.0

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

[Intel-gfx] [PATCH] drm/i915: Build request info on stack before printk

2018-04-23 Thread Chris Wilson

printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete line in a single call to printk.

Fixes: b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a 
struct")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index be608f7111f5..6a5e0a05b1ee 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1113,14 +1113,16 @@ unsigned int intel_engines_has_context_isolation(struct 
drm_i915_private *i915)
return which;
 }
 
-static void print_sched_attr(struct drm_printer *m,
-const struct drm_i915_private *i915,
-const struct i915_sched_attr *attr)
+static int print_sched_attr(const struct i915_sched_attr *attr,
+   char *buf, int offset, int len)
 {
if (attr->priority == I915_PRIORITY_INVALID)
-   return;
+   return offset;
+
+   offset += snprintf(buf + offset, len - offset,
+  " prio=%d", attr->priority);
 
-   drm_printf(m, "prio=%d", attr->priority);
+   return offset;
 }
 
 static void print_request(struct drm_printer *m,
@@ -1128,14 +1130,17 @@ static void print_request(struct drm_printer *m,
  const char *prefix)
 {
const char *name = rq->fence.ops->get_timeline_name(>fence);
+   char buf[80];
+   int x = 0;
+
+   x = print_sched_attr(>sched.attr, buf, x, sizeof(buf));
 
-   drm_printf(m, "%s%x%s [%llx:%x] ",
+   drm_printf(m, "%s%x%s [%llx:%x]%s @ %dms: %s\n",
   prefix,
   rq->global_seqno,
   i915_request_completed(rq) ? "!" : "",
-  rq->fence.context, rq->fence.seqno);
-   print_sched_attr(m, rq->i915, >sched.attr);
-   drm_printf(m, " @ %dms: %s\n",
+  rq->fence.context, rq->fence.seqno,
+  buf,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   name);
 }
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written

2018-04-23 Thread Souza, Jose

On Fri, 2018-04-20 at 15:57 -0700, Rodrigo Vivi wrote:
> On Fri, Apr 20, 2018 at 03:27:56PM -0700, José Roberto de Souza
> wrote:
> > Any write in any display register was causing HW to exit PSR,
> > masking it to allow more power savings. Writes to pipe related
> > registers will still cause HW to exit PSR.
> > This is already masked for PSR2.
> 
> This seems a good idea indeed with the test case on perspective.

what test cases are thinking? the current ones already do pages flips
that will only touch the pipe related registers.

> 
> But it needs more tests to make sure it doesn't break
> "Display WA #0884: all"

I just tested the WA #0884 and it still causes PSR to exit. I have
added a new debugfs that when read it writes to
'I915_WRITE(CURSURFLIVE(pipe), 0);' causing a PSR exit.

> 
> Or we might need to revert that patch before moving with this idea.
> 
> > 
> > Bspec: 7721 and 8042
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > New patch in this series.
> > 
> >  drivers/gpu/drm/i915/intel_psr.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 0938df48107a..c907282dc82d 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -712,7 +712,8 @@ static void hsw_psr_enable_source(struct
> > intel_dp *intel_dp,
> > I915_WRITE(EDP_PSR_DEBUG,
> >EDP_PSR_DEBUG_MASK_MEMUP |
> >EDP_PSR_DEBUG_MASK_HPD |
> > -  EDP_PSR_DEBUG_MASK_LPSP);
> > +  EDP_PSR_DEBUG_MASK_LPSP |
> > +  EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
> > }
> >  }
> >  
> > -- 
> > 2.17.0
> > 
___
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 [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos (rev2)
URL   : https://patchwork.freedesktop.org/series/42139/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4082 -> Patchwork_8780 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8780 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8780, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42139/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8780:

  === IGT changes ===

 Possible regressions 

igt@gem_ctx_switch@basic-default:
  fi-bsw-n3050:   PASS -> INCOMPLETE

igt@gem_exec_suspend@basic-s4-devices:
  fi-skl-guc: PASS -> FAIL


== Known issues ==

  Here are the changes found in Patchwork_8780 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   SKIP -> FAIL (fdo#102672, fdo#103841)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-cfl-s3:  PASS -> FAIL (fdo#100368)

igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
  fi-cfl-s3:  PASS -> FAIL (fdo#103481)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)
  fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)


 Possible fixes 

igt@drv_module_reload@basic-no-display:
  fi-ilk-650: DMESG-WARN -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (36 -> 32) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-cnl-y3 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4082 -> Patchwork_8780

  CI_DRM_4082: 0600266ef9b8407e0dc281acb6b754eba8178c91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8780: 088bede798a4806e09b457a6db4143b2510daa2e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

088bede798a4 drm/i915: Lazily unbind vma on close
8b221e8610f7 drm/i915: Split i915_gem_timeline into individual timelines
73d820ce21e1 drm/i915: Move timeline from GTT to ring
f329f05ed93a drm/i915: Only track live rings for retiring
bbfb45c829a5 drm/i915: Retire requests along rings
84a91bc19416 drm/i915: Stop tracking timeline->inflight_seqnos

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos (rev2)
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/drm/i915/i915_request.c:268:13: error: undefined identifier 
'__builtin_add_overflow_p'
-O:drivers/gpu/drm/i915/i915_request.c:268:13: warning: call with no type!
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Retire requests along rings
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Only track live rings for retiring
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Move timeline from GTT to ring
+  ^~
+  ^~
+  ^
+  ^
+  ^
+  ^
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/kbl: Add KBL GT2 sku (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915/kbl: Add KBL GT2 sku (rev2)
URL   : https://patchwork.freedesktop.org/series/42144/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4081_full -> Patchwork_8779_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8779_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8779_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42144/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8779_full:

  === IGT changes ===

 Possible regressions 

igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
  shard-apl:  PASS -> DMESG-WARN


 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS +2

igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-cpu:
  shard-hsw:  SKIP -> PASS

igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
  shard-glk:  SKIP -> PASS +37

igt@kms_vblank@pipe-b-wait-forked-busy-hang:
  shard-glk:  PASS -> SKIP +48


== Known issues ==

  Here are the changes found in Patchwork_8779_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@mock_breadcrumbs:
  shard-snb:  NOTRUN -> DMESG-FAIL (fdo#106085)

igt@drv_selftest@mock_scatterlist:
  shard-snb:  NOTRUN -> DMESG-WARN (fdo#103667)

igt@gem_eio@in-flight-suspend:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
  shard-hsw:  PASS -> FAIL (fdo#104873)

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-kbl:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602) +10


 Possible fixes 

igt@drv_module_reload@basic-no-display:
  shard-snb:  DMESG-FAIL -> PASS

igt@drv_selftest@mock_sanitycheck:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-hsw:  FAIL (fdo#105707) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS +1

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  FAIL (fdo#102370) -> PASS

igt@kms_rotation_crc@primary-rotation-90:
  shard-kbl:  FAIL (fdo#103925) -> PASS

igt@perf_pmu@interrupts-sync:
  shard-glk:  FAIL (fdo#104485) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104485 https://bugs.freedesktop.org/show_bug.cgi?id=104485
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106085 https://bugs.freedesktop.org/show_bug.cgi?id=106085


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4081 -> Patchwork_8779

  CI_DRM_4081: fb7048acaac8ece5ebc53f9b748b76cdcef60fa3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8779: 3f9866f91add309c6b5d9dca6c34b8656d9b0b0c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos (rev2)
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
84a91bc19416 drm/i915: Stop tracking timeline->inflight_seqnos
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 9b6586ae9f6b ("drm/i915: Keep a 
global seqno per-engine")'
#17: 
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")

total: 1 errors, 0 warnings, 0 checks, 128 lines checked
bbfb45c829a5 drm/i915: Retire requests along rings
f329f05ed93a drm/i915: Only track live rings for retiring
73d820ce21e1 drm/i915: Move timeline from GTT to ring
8b221e8610f7 drm/i915: Split i915_gem_timeline into individual timelines
-:464: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#464: 
deleted file mode 100644

-:960: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#960: FILE: drivers/gpu/drm/i915/i915_timeline.c:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 1619 lines checked
088bede798a4 drm/i915: Lazily unbind vma on close

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

[Intel-gfx] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Chris Wilson

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

v2: Move the requirements checks from the fixture to subtest so that
the test list is stable (Antonio)
v3: Protect SNB from the evil MI_STORE_DWORD.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Antonio Argenziano 
---
 tests/gem_exec_schedule.c | 96 ---
 1 file changed, 90 insertions(+), 6 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 5d0f215b2..1f43147f7 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -49,9 +49,9 @@
 
 IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
 
-static void store_dword(int fd, uint32_t ctx, unsigned ring,
-   uint32_t target, uint32_t offset, uint32_t value,
-   uint32_t cork, unsigned write_domain)
+static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
+ uint32_t target, uint32_t offset, uint32_t value,
+ uint32_t cork, unsigned write_domain)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[3];
@@ -100,7 +100,17 @@ static void store_dword(int fd, uint32_t ctx, unsigned 
ring,
batch[++i] = MI_BATCH_BUFFER_END;
gem_write(fd, obj[2].handle, 0, batch, sizeof(batch));
gem_execbuf(fd, );
-   gem_close(fd, obj[2].handle);
+
+   return obj[2].handle;
+}
+
+static void store_dword(int fd, uint32_t ctx, unsigned ring,
+   uint32_t target, uint32_t offset, uint32_t value,
+   uint32_t cork, unsigned write_domain)
+{
+   gem_close(fd, __store_dword(fd, ctx, ring,
+   target, offset, value,
+   cork, write_domain));
 }
 
 static uint32_t create_highest_priority(int fd)
@@ -161,6 +171,74 @@ static void fifo(int fd, unsigned ring)
munmap(ptr, 4096);
 }
 
+static void independent(int fd, unsigned int engine)
+{
+   IGT_CORK_HANDLE(cork);
+   uint32_t scratch, plug, batch;
+   igt_spin_t *spin = NULL;
+   unsigned int other;
+   uint32_t *ptr;
+
+   igt_require(engine != 0);
+
+   scratch = gem_create(fd, 4096);
+   ptr = gem_mmap__gtt(fd, scratch, 4096, PROT_READ);
+   igt_assert_eq(ptr[0], 0);
+
+   plug = igt_cork_plug(, fd);
+
+   /* Check that we can submit to engine while all others are blocked */
+   for_each_physical_engine(fd, other) {
+   if (other == engine)
+   continue;
+
+   if (!gem_can_store_dword(fd, other))
+   continue;
+
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, 0, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+
+   store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+   }
+   igt_require(spin);
+
+   /* Same priority, but different timeline (as different engine) */
+   batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
+
+   unplug_show_queue(fd, , engine);
+   gem_close(fd, plug);
+
+   gem_sync(fd, batch);
+   igt_assert(!gem_bo_busy(fd, batch));
+   igt_assert(gem_bo_busy(fd, spin->handle));
+   gem_close(fd, batch);
+
+   /* Only the local engine should be free to complete. */
+   igt_assert(gem_bo_busy(fd, scratch));
+   igt_assert_eq(ptr[0], engine);
+
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   /* And we expect the others to have overwritten us, order unspecified */
+   igt_assert(!gem_bo_busy(fd, scratch));
+   igt_assert_neq(ptr[0], engine);
+
+   munmap(ptr, 4096);
+   gem_close(fd, scratch);
+}
+
 static void smoketest(int fd, unsigned ring, unsigned timeout)
 {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -1072,9 +1150,15 @@ igt_main
 
igt_subtest_f("fifo-%s", e->name) {
igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));
-   igt_require(gem_can_store_dword(fd, e->exec_id) 
| e->flags);
+   igt_require(gem_can_store_dword(fd, e->exec_id

[Intel-gfx] [PATCH] drm/i915: Split i915_gem_timeline into individual timelines

2018-04-23 Thread Chris Wilson

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.

v2: Tweak wait_for_idle to stop the compiling thinking that ret may be
uninitialised.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 129 +---
 drivers/gpu/drm/i915/i915_gem_context.c   |  49 ++---
 drivers/gpu/drm/i915/i915_gem_context.h   |   2 -
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 198 --
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_perf.c  |  10 +-
 drivers/gpu/drm/i915/i915_request.c   |  66 +++---
 drivers/gpu/drm/i915/i915_request.h   |   3 +-
 drivers/gpu/drm/i915/i915_timeline.c  | 105 ++
 .../{i915_gem_timeline.h => i915_timeline.h}  |  67 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  27 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c   |   4 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  48 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  23 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  11 +-
 .../{i915_gem_timeline.c => i915_timeline.c}  |  94 +++--
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  32 ++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  10 +-
 .../gpu/drm/i915/selftests/mock_timeline.c|  45 ++--
 .../gpu/drm/i915/selftests/mock_timeline.h|  28 +--
 23 files changed, 396 insertions(+), 568 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
 rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
 rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => i915_timeline.c} 
(70%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
- i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
  i915_query.o \
  i915_request.o \
+ i915_timeline.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9bd8328f501..dab15b6abc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
 #include "i915_gem_fence_reg.h"
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
 #include "i915_gpu_error.h"
 #include "i915_request.h"
 #include "i915_scheduler.h"
+#include "i915_timeline.h"
 #include "i915_vma.h"
 
 #include "intel_gvt.h"
@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline execution_timeline;
-   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
 
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d60f3bd4bc66..44cf67f713c7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
 
intel_engines_park(i915);
-   i915_gem_timelines_park(i915);
+   i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
 
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 */
-   spin_lock_irqsave(>timeline->lock, flags);
-   list_for_each_entry(request, >timeline->requests, link) {
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

2018-04-23 Thread Rodrigo Vivi

On Mon, Apr 23, 2018 at 03:28:03PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> Adding a missing GT2 sku discovered off hardware.
> 
> Signed-off-by: Matt Atwood 
> Reviewed-by: Clint Taylor 

pushed to dinq, thanks for patch and review.

> ---
>  include/drm/i915_pciids.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 70f0c25..bab70ff 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -349,6 +349,7 @@
>  #define INTEL_KBL_GT2_IDS(info)  \
>   INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
>   INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
> + INTEL_VGA_DEVICE(0x591C, info), /* ULX GT2 */ \
>   INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
>   INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
>   INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/kbl: Add KBL GT2 sku (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915/kbl: Add KBL GT2 sku (rev2)
URL   : https://patchwork.freedesktop.org/series/42144/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8779 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42144/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8779 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


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


== Participating hosts (35 -> 33) ==

  Additional (1): fi-glk-j4005 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4081 -> Patchwork_8779

  CI_DRM_4081: fb7048acaac8ece5ebc53f9b748b76cdcef60fa3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8779: 3f9866f91add309c6b5d9dca6c34b8656d9b0b0c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

3f9866f91add drm/i915/kbl: Add KBL GT2 sku

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8779/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/kbl: Add KBL GT2 sku

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915/kbl: Add KBL GT2 sku
URL   : https://patchwork.freedesktop.org/series/42144/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8778 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42144/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8778 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


  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#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (35 -> 33) ==

  Additional (1): fi-glk-j4005 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4081 -> Patchwork_8778

  CI_DRM_4081: fb7048acaac8ece5ebc53f9b748b76cdcef60fa3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8778: 9614a8734006963f14240b48edeeced3005f85bc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

9614a8734006 drm/i915/kbl: Add KBL GT2 sku

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

2018-04-23 Thread matthew . s . atwood

From: Matt Atwood 

Adding a missing GT2 sku discovered off hardware.

Signed-off-by: Matt Atwood 
Reviewed-by: Clint Taylor 
---
 include/drm/i915_pciids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..bab70ff 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -349,6 +349,7 @@
 #define INTEL_KBL_GT2_IDS(info)\
INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
+   INTEL_VGA_DEVICE(0x591C, info), /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

2018-04-23 Thread Clint Taylor




On 04/23/2018 03:01 PM, matthew.s.atw...@intel.com wrote:

From: Matt Atwood 

Adding a missing GT2 sku discovered off hardware.

Signed-off-by: Matt Atwood 
---
  include/drm/i915_pciids.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..a58a548 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -349,6 +349,7 @@
  #define INTEL_KBL_GT2_IDS(info)   \
INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
+   INTEL_VGA_DEVICE(0x591C, info), /* Mobile GT2 */ \


KBL-R Y 2+2 should actually be labeled as ULX GT2 instead of Mobile GT2. 
Of course this information is conveniently missing from the spec.


With that change:
Reviewed-by: Clint Taylor 

-Clint



INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \


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

[Intel-gfx] [PATCH] drm/i915/kbl: Add KBL GT2 sku

2018-04-23 Thread matthew . s . atwood

From: Matt Atwood 

Adding a missing GT2 sku discovered off hardware.

Signed-off-by: Matt Atwood 
---
 include/drm/i915_pciids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..a58a548 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -349,6 +349,7 @@
 #define INTEL_KBL_GT2_IDS(info)\
INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
+   INTEL_VGA_DEVICE(0x591C, info), /* Mobile GT2 */ \
INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
-- 
2.7.4

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

[Intel-gfx] UHD 620: How to debug a screen resolution that does not work reliably

2018-04-23 Thread Ricardo Ribalda Delgado

Hi

I have a secondary monitor connected via USB-C adapter to  HDMI. It
can manage resolutions up to 2560x1440.

Most of the time, when the system is booted the resolution is detected
ok, but If I suspend the machine, or replug the screen, or alternate
to the text console, the resolution is "downgraded" to Full HD.

I have added the paramter drm.debug=0x06  to my kernel option and I
have managed to catch this error when the resolution is not detected
properly:

[4.941022] [drm:drm_mode_debug_printmodeline [drm]] Modeline
77:"2560x1440" 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x48
0x5
[4.941046] [drm:drm_mode_prune_invalid [drm]] Not using 2560x1440
mode: CLOCK_HIGH


On the other hand, when it works fine:

[   95.361838] [drm:drm_mode_debug_printmodeline [drm]] Modeline
85:"2560x1440" 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x48
0x5
[   95.928536] [drm:intel_dump_pipe_config [i915]] crtc timings:
241500 2560 2608 2640 2720 1440 1443 1448 1481, type: 0x48 flags: 0x5
[   95.928546] [drm:intel_dump_pipe_config [i915]] port clock: 54,
pipe src size: 2560x1440, pixel rate 241500


The adapter is brand new (Xiaomi) and the cable should be of good
quality (ethernet capable).


Any ideas about how to debug this? The EDID seems fine, it seems
related to hock clock_high is calculated.


My kernel version is Linux piling 4.15.0-2-amd64 #1 SMP Debian
4.15.11-1 (2018-03-20) x86_64 GNU/Linux

When it works:
[  853.586182] [drm:drm_detect_monitor_audio [drm]] Monitor has basic
audio support
[  853.586850] [drm:intel_power_well_disable [i915]] disabling power well 2
[  853.586862] [drm:drm_add_display_info [drm]] non_desktop set to 0
[  853.586868] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max
TMDS clock 30 kHz
[  853.586874] [drm:drm_add_display_info [drm]] non_desktop set to 0
[  853.586879] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max
TMDS clock 30 kHz
[  853.586956] [drm:drm_edid_to_eld [drm]] ELD monitor Q2775
[  853.586961] [drm:drm_edid_to_eld [drm]] HDMI: latency present 0 0,
video latency 0 0, audio latency 0 0
[  853.586974] [drm:intel_connector_update_modes [i915]] ELD size 28,
SAD count 1
[  853.587047] [drm:drm_helper_probe_single_connector_modes
[drm_kms_helper]] [CONNECTOR:69:DP-1] probed modes :
[  853.587054] [drm:drm_mode_debug_printmodeline [drm]] Modeline
84:"2560x1440" 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x48
0x5
[  853.587059] [drm:drm_mode_debug_printmodeline [drm]] Modeline
87:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40
0x5
[  853.587064] [drm:drm_mode_debug_printmodeline [drm]] Modeline
123:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40
0x5
[  853.587069] [drm:drm_mode_debug_printmodeline [drm]] Modeline
114:"1920x1080i" 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40
0x15
[  853.587073] [drm:drm_mode_debug_printmodeline [drm]] Modeline
128:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40
0x15
[  853.587078] [drm:drm_mode_debug_printmodeline [drm]] Modeline
113:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40
0x5
[  853.587082] [drm:drm_mode_debug_printmodeline [drm]] Modeline
115:"1920x1080i" 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40
0x15
[  853.587087] [drm:drm_mode_debug_printmodeline [drm]] Modeline
91:"1280x1440" 60 156000 1280 1376 1512 1744 1440 1443 1453 1493 0x40
0x6
[  853.587091] [drm:drm_mode_debug_printmodeline [drm]] Modeline
92:"1680x1050" 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40
0x9
[  853.587095] [drm:drm_mode_debug_printmodeline [drm]] Modeline
103:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40
0x5
[  853.587099] [drm:drm_mode_debug_printmodeline [drm]] Modeline
94:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40
0x5
[  853.587104] [drm:drm_mode_debug_printmodeline [drm]] Modeline
93:"1440x900" 60 88750 1440 1488 1520 1600 900 903 909 926 0x40 0x9
[  853.587108] [drm:drm_mode_debug_printmodeline [drm]] Modeline
95:"1280x960" 60 108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[  853.587112] [drm:drm_mode_debug_printmodeline [drm]] Modeline
88:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[  853.587116] [drm:drm_mode_debug_printmodeline [drm]] Modeline
124:"1280x720" 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[  853.587121] [drm:drm_mode_debug_printmodeline [drm]] Modeline
117:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[  853.587125] [drm:drm_mode_debug_printmodeline [drm]] Modeline
104:"1024x768" 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[  853.587129] [drm:drm_mode_debug_printmodeline [drm]] Modeline
105:"1024x768" 70 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[  853.587133] [drm:drm_mode_debug_printmodeline [drm]] Modeline
106:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[  853.587137] [drm:drm_mode_debug_printmodeline [drm]] Modeline
107:"832x624" 75 57284 832 864

Re: [Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

2018-04-23 Thread Zhang, Yunwei

Sorry, I added a debug patch when submitting to trybot and forgot to 
remove that from my local branch. I will resubmit to a new series.


Yunwei


On 4/23/2018 12:55 PM, Rodrigo Vivi wrote:

On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
  - use fls instead of find_last_bit (Chris)
  - use is_power_of_2() instead of counting bit set (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Move local variable into scope where they are used (Ursulin)
  - use a new local variable to reduce long line of code (Ursulin)
v6:
  - Some coding style and use more local variables for clearer
logic (Ursulin)
v7:
  - Rebased.
v8:
  - Reviewed by Oscar.
v9:
  - Fixed label location. (Oscar)
v10:
  - Improved comments and replaced magical number. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 

I confess that I got lost on this thread, so please
accept my apologies in advance if I'm missing something here.

But I don't know anymore:

- if this series has 2 or 3 patches.
- which of the patches rv-b by Oscar are still valid
- if they are passing cleaning on CI.

So, my suggestion is to start a new series from scratch.
(resend all without any in-reply-to)

But please double check with Oscar if his rv-b should stay
on the new series.

Thanks,
Rodrigo.



---
  drivers/gpu/drm/i915/i915_reg.h  |  4 
  drivers/gpu/drm/i915/intel_device_info.c | 34 
  2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
  #define   GEN10_F2_SS_DIS_SHIFT   18
  #define   GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT)
  
+#define	GEN10_MIRROR_FUSE3		_MMIO(0x9118)

+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
  #define GEN8_EU_DISABLE0  _MMIO(0x9134)
  #define   GEN8_EU_DIS0_S0_MASK0xff
  #define   GEN8_EU_DIS0_S1_SHIFT   24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d917c9b..44ca90a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -729,6 +729,40 @@ static void sanitize_mcr(struct intel_device_info *info)
u32 slice = fls(info->sseu.slice_mask);
u32 subslice = fls(info->sseu.subslice_mask[slice]);
  
+	/*

+* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+* L3Banks could be fused off in single slice scenario. If that is
+* the case, we might need to program MCR select to a valid L3Bank
+* by default, to make sure we correctly read certain registers
+* later on (in the range 0xB100 - 0xB3FF).
+* This might be incompatible with
+* WaProgramMgsrForCorrectSliceSpecificMmioReads.
+* Fortunately, this should not happen in production hardware, so
+* we only assert that this is the case (instead of implementing
+* something more complex that requires checking the range of every
+* MMIO read).
+*/
+   if (INTEL_GEN(dev_priv) >= 10 &&
+   is_power_of_2(info->sseu.slice_mask)) {
+   /*
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = info->sseu.subslice_mask[slice];
+
+   u8 enabled_mask = (ss_mask | ss_mask >>
+  GEN10_L3BANK_PAIR_COUNT) &
+  GEN10_L3BANK_MASK;
+   u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
+
+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+   }
+
if (INTEL_GEN(dev_priv) >= 11) {

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8777 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8777 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8777, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42139/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8777:

  === IGT changes ===

 Possible regressions 

igt@gem_exec_suspend@basic-s3:
  fi-skl-guc: PASS -> FAIL


== Known issues ==

  Here are the changes found in Patchwork_8777 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


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


== Participating hosts (35 -> 33) ==

  Additional (1): fi-glk-j4005 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4081 -> Patchwork_8777

  CI_DRM_4081: fb7048acaac8ece5ebc53f9b748b76cdcef60fa3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8777: 123351d9c80ef8286f1d8d12e5a1d06e707c87d3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

123351d9c80e drm/i915: Lazily unbind vma on close
23a6561be624 drm/i915: Split i915_gem_timeline into individual timelines
38d2d82de298 drm/i915: Move timeline from GTT to ring
1cca0fbbe09b drm/i915: Only track live rings for retiring
f1d8ea9d3683 drm/i915: Retire requests along rings
397f93096828 drm/i915: Stop tracking timeline->inflight_seqnos


== Kernel 32bit build ==

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

== Logs ==

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

[Intel-gfx] [PATCH igt v2] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Chris Wilson

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

v2: Move the requirements checks from the fixture to subtest so that
the test list is stable (Antonio)

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Antonio Argenziano 
---
 tests/gem_exec_schedule.c | 89 +--
 1 file changed, 85 insertions(+), 4 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 5d0f215b2..8e82f113f 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -49,9 +49,9 @@
 
 IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
 
-static void store_dword(int fd, uint32_t ctx, unsigned ring,
-   uint32_t target, uint32_t offset, uint32_t value,
-   uint32_t cork, unsigned write_domain)
+static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
+ uint32_t target, uint32_t offset, uint32_t value,
+ uint32_t cork, unsigned write_domain)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[3];
@@ -100,7 +100,17 @@ static void store_dword(int fd, uint32_t ctx, unsigned 
ring,
batch[++i] = MI_BATCH_BUFFER_END;
gem_write(fd, obj[2].handle, 0, batch, sizeof(batch));
gem_execbuf(fd, );
-   gem_close(fd, obj[2].handle);
+
+   return obj[2].handle;
+}
+
+static void store_dword(int fd, uint32_t ctx, unsigned ring,
+   uint32_t target, uint32_t offset, uint32_t value,
+   uint32_t cork, unsigned write_domain)
+{
+   gem_close(fd, __store_dword(fd, ctx, ring,
+   target, offset, value,
+   cork, write_domain));
 }
 
 static uint32_t create_highest_priority(int fd)
@@ -161,6 +171,71 @@ static void fifo(int fd, unsigned ring)
munmap(ptr, 4096);
 }
 
+static void independent(int fd, unsigned int engine)
+{
+   IGT_CORK_HANDLE(cork);
+   uint32_t scratch, plug, batch;
+   igt_spin_t *spin = NULL;
+   unsigned int other;
+   uint32_t *ptr;
+
+   igt_require(engine != 0);
+
+   scratch = gem_create(fd, 4096);
+   ptr = gem_mmap__gtt(fd, scratch, 4096, PROT_READ);
+   igt_assert_eq(ptr[0], 0);
+
+   plug = igt_cork_plug(, fd);
+
+   /* Check that we can submit to engine while all others are blocked */
+   for_each_physical_engine(fd, other) {
+   if (other == engine)
+   continue;
+
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, 0, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+
+   store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+   }
+   igt_require(spin);
+
+   /* Same priority, but different timeline (as different engine) */
+   batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
+
+   unplug_show_queue(fd, , engine);
+   gem_close(fd, plug);
+
+   gem_sync(fd, batch);
+   igt_assert(!gem_bo_busy(fd, batch));
+   igt_assert(gem_bo_busy(fd, spin->handle));
+   gem_close(fd, batch);
+
+   /* Only the local engine should be free to complete. */
+   igt_assert(gem_bo_busy(fd, scratch));
+   igt_assert_eq(ptr[0], engine);
+
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   /* And we expect the others to have overwritten us, order unspecified */
+   igt_assert(!gem_bo_busy(fd, scratch));
+   igt_assert_neq(ptr[0], engine);
+
+   gem_close(fd, scratch);
+   munmap(ptr, 4096);
+}
+
 static void smoketest(int fd, unsigned ring, unsigned timeout)
 {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -1075,6 +1150,12 @@ igt_main
igt_require(gem_can_store_dword(fd, e->exec_id) 
| e->flags);
fifo(fd, e->exec_id | e->flags);
}
+
+   igt_subtest_f("independent-%s", e->name) {
+   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));
+   igt_require(gem_can_store_dword(fd, e->exec_id) 
| e->flags);
+

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/drm/i915/i915_request.c:268:13: error: undefined identifier 
'__builtin_add_overflow_p'
-O:drivers/gpu/drm/i915/i915_request.c:268:13: warning: call with no type!
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Retire requests along rings
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Only track live rings for retiring
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Move timeline from GTT to ring
+  ^~
+  ^~
+  ^
+  ^
+  ^
+  ^
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
397f93096828 drm/i915: Stop tracking timeline->inflight_seqnos
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 9b6586ae9f6b ("drm/i915: Keep a 
global seqno per-engine")'
#17: 
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")

total: 1 errors, 0 warnings, 0 checks, 128 lines checked
f1d8ea9d3683 drm/i915: Retire requests along rings
1cca0fbbe09b drm/i915: Only track live rings for retiring
38d2d82de298 drm/i915: Move timeline from GTT to ring
23a6561be624 drm/i915: Split i915_gem_timeline into individual timelines
-:446: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#446: 
deleted file mode 100644

-:942: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#942: FILE: drivers/gpu/drm/i915/i915_timeline.c:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 1603 lines checked
123351d9c80e drm/i915: Lazily unbind vma on close

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

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

2018-04-23 Thread Rodrigo Vivi

On Mon, Apr 23, 2018 at 01:24:39PM -0700, Dhinakaran Pandiyan wrote:
> 
> 
> 
> On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> > On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> > > 
> > > 
> > > 
> > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > > > On Fri, 20 Apr 2018, Mika Kahola  wrote:
> > > > > > 
> > > > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > > > > > 
> > > > > > > On Wed, 18 Apr 2018, Mika Kahola  wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > When reading out CRC's we  wait for a vblank on
> > > > > > > > intel_dp_sink_crc_start()
> > > > > > > > function. When we start reading out CRC's in
> > > > > > > > intel_dp_sink_crc()
> > > > > > > > loop we
> > > > > > > > first wait for a vblank yielding that all in all we end up
> > > > > > > > waiting
> > > > > > > > two
> > > > > > > > vblanks on the first iteration round. Therefore, let's move the
> > > > > > > > intel_wait_for_vblank() as the last routine that we do in an
> > > > > > > > iteration loop
> > > > > > > > in intel_dp_sink_crc().
> > > > > > > > 
> > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166
> > > > > > > Umm, do the CI failures in the bug really use sink crc, or are
> > > > > > > they
> > > > > > > rather about pipe crc?
> > > > > > > 
> > > > > > The bug is more on pipe crc. This just caught my attention while I
> > > > > > was
> > > > > > looking into these bugs. 
> > > > > I think the practice we've adopted is,
> > > > > 
> > > > > Bugzilla: 
> > > > > 
> > > > > References: 
> > > > Got it :) I try to remember this notation.
> > > > 
> > > > > 
> > > > > > 
> > > > > > Was there a reason why we need to wait two vblanks here before
> > > > > > running
> > > > > > the loop?
> > > > > I can't remember by heart. I'm not sure if it would make more sense
> > > > > to
> > > > > remove the vblank wait from intel_dp_sink_crc_start() instead. Even
> > > > > with
> > > > > your patch, there'll still be an extra vblank wait, you just move it
> > > > > to
> > > > > a different place.
> > > > We could remove vblank wait form intel_dp_sink_crc_start(). Maybe that
> > > > would be more logical place for the removal. As CI runs pointed out
> > > > this patch didn't fix the actual bug so should I drop this change or
> > > > should we still try optimize the code a bit?
> > > > 
> > > 
> > > I looked at this code in more detail, there is a big problem here.
> > > 
> > > The implementation generously uses vblank waits that end up triggering
> > > PSR exits. This in turn means we never read crc's when PSR is active. I
> > > am not surprised anymore the tests were not reliable. We should nuke
> > > this whole thing or use delays in place of vblank waits. This patch is
> > > not what we need.
> > 
> > hmmm... good point...
> > 
> > so we should for now remove all vblank waits there and wait for the 
> > TEST_COUNT
> > to increase with some "random" sleep timeout...
> > 
> 
> There is some IPS related code that needs vblanks, git blame didn't tell
> if it exactly needs to wait until a vblank interrupt occurs.

oh! indeed. luckly IPS is only HSW and BDW. SKL+ is free from that.

But from what I rememeber a time based wait there should be ok.
Not necessarily an interrupt. But safe if we change the behaviour only
when disabling IPS from the sink crc check.

> 
> Second, we'll need a dual implementation, 
> 1. with crc start and stop programming before entering PSR and after
> exit. Read $debugfs/sink_crc_edp
> 2. directly read the CRC for static frames when PSR is active.
> $debugfs/sink_crc_edp_psr

I'm not sure if I followed, but if the idea is to decouple start/stop from the
read itself I agree... The problem is just on how to handle the counters
since we could end up in situations where what we are reading is not exactly
what we want.

But anyways I believe we should put the minimal effort there if the idea is
to move away from that and also the wish of enabling the CRC feature...

> 
> 
> 
> > > 
> > > There is also the assumption of starting and stopping crc calculation.
> > > Careful reading of the spec shows they are not required for crc
> > > calculation for PSR idle frames. We need to put more thought into fixing
> > > this.
> > > 
> > > 
> > > -DK
> > > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

2018-04-23 Thread Dhinakaran Pandiyan




On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> > 
> > 
> > 
> > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > > On Fri, 20 Apr 2018, Mika Kahola  wrote:
> > > > > 
> > > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > > > > 
> > > > > > On Wed, 18 Apr 2018, Mika Kahola  wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > When reading out CRC's we  wait for a vblank on
> > > > > > > intel_dp_sink_crc_start()
> > > > > > > function. When we start reading out CRC's in
> > > > > > > intel_dp_sink_crc()
> > > > > > > loop we
> > > > > > > first wait for a vblank yielding that all in all we end up
> > > > > > > waiting
> > > > > > > two
> > > > > > > vblanks on the first iteration round. Therefore, let's move the
> > > > > > > intel_wait_for_vblank() as the last routine that we do in an
> > > > > > > iteration loop
> > > > > > > in intel_dp_sink_crc().
> > > > > > > 
> > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166
> > > > > > Umm, do the CI failures in the bug really use sink crc, or are
> > > > > > they
> > > > > > rather about pipe crc?
> > > > > > 
> > > > > The bug is more on pipe crc. This just caught my attention while I
> > > > > was
> > > > > looking into these bugs. 
> > > > I think the practice we've adopted is,
> > > > 
> > > > Bugzilla: 
> > > > 
> > > > References: 
> > > Got it :) I try to remember this notation.
> > > 
> > > > 
> > > > > 
> > > > > Was there a reason why we need to wait two vblanks here before
> > > > > running
> > > > > the loop?
> > > > I can't remember by heart. I'm not sure if it would make more sense
> > > > to
> > > > remove the vblank wait from intel_dp_sink_crc_start() instead. Even
> > > > with
> > > > your patch, there'll still be an extra vblank wait, you just move it
> > > > to
> > > > a different place.
> > > We could remove vblank wait form intel_dp_sink_crc_start(). Maybe that
> > > would be more logical place for the removal. As CI runs pointed out
> > > this patch didn't fix the actual bug so should I drop this change or
> > > should we still try optimize the code a bit?
> > > 
> > 
> > I looked at this code in more detail, there is a big problem here.
> > 
> > The implementation generously uses vblank waits that end up triggering
> > PSR exits. This in turn means we never read crc's when PSR is active. I
> > am not surprised anymore the tests were not reliable. We should nuke
> > this whole thing or use delays in place of vblank waits. This patch is
> > not what we need.
> 
> hmmm... good point...
> 
> so we should for now remove all vblank waits there and wait for the TEST_COUNT
> to increase with some "random" sleep timeout...
> 

There is some IPS related code that needs vblanks, git blame didn't tell
if it exactly needs to wait until a vblank interrupt occurs.

Second, we'll need a dual implementation, 
1. with crc start and stop programming before entering PSR and after
exit. Read $debugfs/sink_crc_edp
2. directly read the CRC for static frames when PSR is active.
$debugfs/sink_crc_edp_psr



> > 
> > There is also the assumption of starting and stopping crc calculation.
> > Careful reading of the spec shows they are not required for crc
> > calculation for PSR idle frames. We need to put more thought into fixing
> > this.
> > 
> > 
> > -DK
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

2018-04-23 Thread Rodrigo Vivi

On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:
> L3Bank could be fused off in hardware for debug purpose, and it
> is possible that subslice is enabled while its corresponding L3Bank pairs
> are disabled. In such case, if MCR packet control register(0xFDC) is
> programed to point to a disabled bank pair, a MMIO read into L3Bank range
> will return 0 instead of correct values.
> 
> However, this is not going to be the case in any production silicon.
> Therefore, we only check at initialization and issue a warning should
> this really happen.
> 
> References: HSDES#1405586840
> 
> v2:
>  - use fls instead of find_last_bit (Chris)
>  - use is_power_of_2() instead of counting bit set (Chris)
> v3:
>  - rebase on latest tip
> v5:
>  - Added references (Mika)
>  - Move local variable into scope where they are used (Ursulin)
>  - use a new local variable to reduce long line of code (Ursulin)
> v6:
>  - Some coding style and use more local variables for clearer
>logic (Ursulin)
> v7:
>  - Rebased.
> v8:
>  - Reviewed by Oscar.
> v9:
>  - Fixed label location. (Oscar)
> v10:
>  - Improved comments and replaced magical number. (Oscar)
> 
> Cc: Oscar Mateo 
> Cc: Michel Thierry 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Yunwei Zhang 
> Reviewed-by: Oscar Mateo 

I confess that I got lost on this thread, so please
accept my apologies in advance if I'm missing something here.

But I don't know anymore:

- if this series has 2 or 3 patches.
- which of the patches rv-b by Oscar are still valid
- if they are passing cleaning on CI.

So, my suggestion is to start a new series from scratch.
(resend all without any in-reply-to)

But please double check with Oscar if his rv-b should stay
on the new series.

Thanks,
Rodrigo.


> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  4 
>  drivers/gpu/drm/i915/intel_device_info.c | 34 
> 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fb10602..6c9c01b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2709,6 +2709,10 @@ enum i915_power_well_id {
>  #define   GEN10_F2_SS_DIS_SHIFT  18
>  #define   GEN10_F2_SS_DIS_MASK   (0xf << GEN10_F2_SS_DIS_SHIFT)
>  
> +#define  GEN10_MIRROR_FUSE3  _MMIO(0x9118)
> +#define GEN10_L3BANK_PAIR_COUNT 4
> +#define GEN10_L3BANK_MASK   0x0F
> +
>  #define GEN8_EU_DISABLE0 _MMIO(0x9134)
>  #define   GEN8_EU_DIS0_S0_MASK   0xff
>  #define   GEN8_EU_DIS0_S1_SHIFT  24
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index d917c9b..44ca90a 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -729,6 +729,40 @@ static void sanitize_mcr(struct intel_device_info *info)
>   u32 slice = fls(info->sseu.slice_mask);
>   u32 subslice = fls(info->sseu.subslice_mask[slice]);
>  
> + /*
> +  * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
> +  * L3Banks could be fused off in single slice scenario. If that is
> +  * the case, we might need to program MCR select to a valid L3Bank
> +  * by default, to make sure we correctly read certain registers
> +  * later on (in the range 0xB100 - 0xB3FF).
> +  * This might be incompatible with
> +  * WaProgramMgsrForCorrectSliceSpecificMmioReads.
> +  * Fortunately, this should not happen in production hardware, so
> +  * we only assert that this is the case (instead of implementing
> +  * something more complex that requires checking the range of every
> +  * MMIO read).
> +  */
> + if (INTEL_GEN(dev_priv) >= 10 &&
> + is_power_of_2(info->sseu.slice_mask)) {
> + /*
> +  * read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
> +  * enabled subslice, no need to redirect MCR packet
> +  */
> + u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
> + u8 ss_mask = info->sseu.subslice_mask[slice];
> +
> + u8 enabled_mask = (ss_mask | ss_mask >>
> +GEN10_L3BANK_PAIR_COUNT) &
> +GEN10_L3BANK_MASK;
> + u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
> +
> + /*
> +  * Production silicon should have matched L3Bank and
> +  * subslice enabled
> +  */
> + WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
> + }
> +
>   if (INTEL_GEN(dev_priv) >= 11) {
>   mcr_slice_subslice_mask =

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

2018-04-23 Thread Rodrigo Vivi

On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> 
> 
> 
> On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > On Fri, 20 Apr 2018, Mika Kahola  wrote:
> > > > 
> > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > > > 
> > > > > On Wed, 18 Apr 2018, Mika Kahola  wrote:
> > > > > > 
> > > > > > 
> > > > > > When reading out CRC's we  wait for a vblank on
> > > > > > intel_dp_sink_crc_start()
> > > > > > function. When we start reading out CRC's in
> > > > > > intel_dp_sink_crc()
> > > > > > loop we
> > > > > > first wait for a vblank yielding that all in all we end up
> > > > > > waiting
> > > > > > two
> > > > > > vblanks on the first iteration round. Therefore, let's move the
> > > > > > intel_wait_for_vblank() as the last routine that we do in an
> > > > > > iteration loop
> > > > > > in intel_dp_sink_crc().
> > > > > > 
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166
> > > > > Umm, do the CI failures in the bug really use sink crc, or are
> > > > > they
> > > > > rather about pipe crc?
> > > > > 
> > > > The bug is more on pipe crc. This just caught my attention while I
> > > > was
> > > > looking into these bugs. 
> > > I think the practice we've adopted is,
> > > 
> > > Bugzilla: 
> > > 
> > > References: 
> > Got it :) I try to remember this notation.
> > 
> > > 
> > > > 
> > > > Was there a reason why we need to wait two vblanks here before
> > > > running
> > > > the loop?
> > > I can't remember by heart. I'm not sure if it would make more sense
> > > to
> > > remove the vblank wait from intel_dp_sink_crc_start() instead. Even
> > > with
> > > your patch, there'll still be an extra vblank wait, you just move it
> > > to
> > > a different place.
> > We could remove vblank wait form intel_dp_sink_crc_start(). Maybe that
> > would be more logical place for the removal. As CI runs pointed out
> > this patch didn't fix the actual bug so should I drop this change or
> > should we still try optimize the code a bit?
> > 
> 
> I looked at this code in more detail, there is a big problem here.
> 
> The implementation generously uses vblank waits that end up triggering
> PSR exits. This in turn means we never read crc's when PSR is active. I
> am not surprised anymore the tests were not reliable. We should nuke
> this whole thing or use delays in place of vblank waits. This patch is
> not what we need.

hmmm... good point...

so we should for now remove all vblank waits there and wait for the TEST_COUNT
to increase with some "random" sleep timeout...

> 
> There is also the assumption of starting and stopping crc calculation.
> Careful reading of the spec shows they are not required for crc
> calculation for PSR idle frames. We need to put more thought into fixing
> this.
> 
> 
> -DK
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read

2018-04-23 Thread Dhinakaran Pandiyan




On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > On Fri, 20 Apr 2018, Mika Kahola  wrote:
> > > 
> > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > > 
> > > > On Wed, 18 Apr 2018, Mika Kahola  wrote:
> > > > > 
> > > > > 
> > > > > When reading out CRC's we  wait for a vblank on
> > > > > intel_dp_sink_crc_start()
> > > > > function. When we start reading out CRC's in
> > > > > intel_dp_sink_crc()
> > > > > loop we
> > > > > first wait for a vblank yielding that all in all we end up
> > > > > waiting
> > > > > two
> > > > > vblanks on the first iteration round. Therefore, let's move the
> > > > > intel_wait_for_vblank() as the last routine that we do in an
> > > > > iteration loop
> > > > > in intel_dp_sink_crc().
> > > > > 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166
> > > > Umm, do the CI failures in the bug really use sink crc, or are
> > > > they
> > > > rather about pipe crc?
> > > > 
> > > The bug is more on pipe crc. This just caught my attention while I
> > > was
> > > looking into these bugs. 
> > I think the practice we've adopted is,
> > 
> > Bugzilla: 
> > 
> > References: 
> Got it :) I try to remember this notation.
> 
> > 
> > > 
> > > Was there a reason why we need to wait two vblanks here before
> > > running
> > > the loop?
> > I can't remember by heart. I'm not sure if it would make more sense
> > to
> > remove the vblank wait from intel_dp_sink_crc_start() instead. Even
> > with
> > your patch, there'll still be an extra vblank wait, you just move it
> > to
> > a different place.
> We could remove vblank wait form intel_dp_sink_crc_start(). Maybe that
> would be more logical place for the removal. As CI runs pointed out
> this patch didn't fix the actual bug so should I drop this change or
> should we still try optimize the code a bit?
> 

I looked at this code in more detail, there is a big problem here.

The implementation generously uses vblank waits that end up triggering
PSR exits. This in turn means we never read crc's when PSR is active. I
am not surprised anymore the tests were not reliable. We should nuke
this whole thing or use delays in place of vblank waits. This patch is
not what we need.

There is also the assumption of starting and stopping crc calculation.
Careful reading of the spec shows they are not required for crc
calculation for PSR idle frames. We need to put more thought into fixing
this.


-DK

___
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 [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4079 -> Patchwork_8776 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8776 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8776, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42139/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8776:

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-reload:
  fi-glk-j4005:   PASS -> DMESG-WARN

igt@gem_ctx_switch@basic-default:
  fi-bsw-n3050:   PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8776 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_ctx_switch@basic-default:
  fi-bdw-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128)

igt@kms_flip@basic-flip-vs-dpms:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106097) +1


 Possible fixes 

igt@drv_module_reload@basic-no-display:
  fi-bwr-2160:INCOMPLETE (fdo#105268) -> PASS


  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105268 https://bugs.freedesktop.org/show_bug.cgi?id=105268
  fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4079 -> Patchwork_8776

  CI_DRM_4079: 5b0d2878a1667b63a937eb67c1673f29ff280e8b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8776: 9c373ac32b705c7a767220bc2cea59d869ca3b5e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

9c373ac32b70 drm/i915: Lazily unbind vma on close
7d0dd099190b drm/i915: Split i915_gem_timeline into individual timelines
9e0240db6895 drm/i915: Move timeline from GTT to ring
b6e3c9bab43f drm/i915: Only track live rings for retiring
e982294a22bd drm/i915: Retire requests along rings
b1a184759165 drm/i915: Stop tracking timeline->inflight_seqnos


== Kernel 32bit build ==

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

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/drm/i915/i915_request.c:268:13: error: undefined identifier 
'__builtin_add_overflow_p'
-O:drivers/gpu/drm/i915/i915_request.c:268:13: warning: call with no type!
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Retire requests along rings
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Only track live rings for retiring
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Move timeline from GTT to ring
+  ^~
+  ^~
+  ^
+  ^
+  ^
+  ^
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31: warning: constant 0xea00 
is so big it is unsigned long
-./arch/x86/include/asm/pgalloc.h:115:31:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Use ktime on wait_for

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL   : https://patchwork.freedesktop.org/series/42115/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8774_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8774_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8774_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42115/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8774_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  SKIP -> PASS

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +1

igt@kms_atomic_transition@plane-all-transition-nonblocking:
  shard-snb:  PASS -> SKIP +2

igt@kms_vblank@pipe-b-wait-forked-busy-hang:
  shard-glk:  SKIP -> PASS +79

igt@kms_vblank@pipe-c-wait-forked-busy:
  shard-glk:  PASS -> SKIP +103


== Known issues ==

  Here are the changes found in Patchwork_8774_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105312)

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-wc:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_vblank@pipe-c-accuracy-idle:
  shard-hsw:  PASS -> FAIL (fdo#102583)


 Possible fixes 

igt@gem_eio@suspend:
  shard-kbl:  DMESG-WARN -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-apl:  FAIL (fdo#103207) -> PASS

igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106134) -> SKIP

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#105312) -> PASS

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#103933) -> PASS

igt@kms_setmode@basic:
  shard-glk:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103933 https://bugs.freedesktop.org/show_bug.cgi?id=103933
  fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312
  fdo#106134 https://bugs.freedesktop.org/show_bug.cgi?id=106134
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8774

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8774: d8fac5f69e93f2197dc4bd591b196a524873a795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8774/shards.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 series starting with [v2,1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42139/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b1a184759165 drm/i915: Stop tracking timeline->inflight_seqnos
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 9b6586ae9f6b ("drm/i915: Keep a 
global seqno per-engine")'
#17: 
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")

total: 1 errors, 0 warnings, 0 checks, 128 lines checked
e982294a22bd drm/i915: Retire requests along rings
b6e3c9bab43f drm/i915: Only track live rings for retiring
9e0240db6895 drm/i915: Move timeline from GTT to ring
7d0dd099190b drm/i915: Split i915_gem_timeline into individual timelines
-:446: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#446: 
deleted file mode 100644

-:942: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#942: FILE: drivers/gpu/drm/i915/i915_timeline.c:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 1603 lines checked
9c373ac32b70 drm/i915: Lazily unbind vma on close

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL   : https://patchwork.freedesktop.org/series/42113/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8773_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8773_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8773_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42113/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8773_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  SKIP -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  PASS -> SKIP +67

igt@kms_vblank@pipe-b-wait-forked-busy-hang:
  shard-glk:  SKIP -> PASS +46


== Known issues ==

  Here are the changes found in Patchwork_8773_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-plain-flip-ts-check:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_hdmi_inject@inject-audio:
  shard-glk:  PASS -> FAIL (fdo#102370)

igt@kms_plane@plane-position-hole-pipe-a-planes:
  shard-apl:  PASS -> FAIL (fdo#103166)


 Possible fixes 

igt@gem_eio@suspend:
  shard-kbl:  DMESG-WARN -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-apl:  FAIL (fdo#103207) -> PASS

igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#105312) -> PASS

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102370 https://bugs.freedesktop.org/show_bug.cgi?id=102370
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8773

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8773: dedb75c52059a931ae14dca63f4b70880f678cf4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/hisilicon/hibmc: Using module_pci_driver.

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL   : https://patchwork.freedesktop.org/series/42103/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8771_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8771_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8771_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42103/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8771_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  SKIP -> PASS

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +1

igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
  shard-glk:  PASS -> SKIP +92

igt@kms_vblank@pipe-b-wait-forked-busy-hang:
  shard-glk:  SKIP -> PASS +79


== Known issues ==

  Here are the changes found in Patchwork_8771_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#100368)

igt@kms_flip@plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@gem_eio@suspend:
  shard-kbl:  DMESG-WARN -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-apl:  FAIL (fdo#103207) -> PASS

igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@blocking-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106134) -> PASS

igt@kms_flip@modeset-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#103933) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


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


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8771

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8771: 10d8b3ee29f819bfcc2a469935d4f006e16a3518 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] [PATCH v2 4/6] drm/i915: Move timeline from GTT to ring

2018-04-23 Thread Chris Wilson

In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.

The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.

v2: Reinforce that one isn't allowed to mix the engine execution
timeline with the client timeline from userspace (on the ring).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   | 13 +
 drivers/gpu/drm/i915/i915_gem.c   |  9 ++--
 drivers/gpu/drm/i915/i915_gem_context.c   | 15 +-
 drivers/gpu/drm/i915/i915_gem_context.h   |  2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 --
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 -
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 54 +--
 drivers/gpu/drm/i915/i915_gem_timeline.h  |  4 ++
 drivers/gpu/drm/i915/i915_request.c   | 15 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  3 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 10 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  5 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 -
 16 files changed, 102 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54351cace362..b9bd8328f501 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,7 +2058,8 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline global_timeline;
+   struct i915_gem_timeline execution_timeline;
+   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
 
struct list_head active_rings;
@@ -3234,16 +3235,6 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
-static inline struct intel_timeline *
-i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
-{
-   struct i915_address_space *vm;
-
-   vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
-   return >timeline.engine[engine->id];
-}
-
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 56c79df5ebce..d60f3bd4bc66 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request 
*request)
 {
struct intel_engine_cs *engine = request->engine;
struct i915_gem_context *hung_ctx = request->ctx;
-   struct intel_timeline *timeline;
+   struct intel_timeline *timeline = request->timeline;
unsigned long flags;
 
-   timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
+   GEM_BUG_ON(timeline == engine->timeline);
 
spin_lock_irqsave(>timeline->lock, flags);
spin_lock(>lock);
@@ -3782,7 +3782,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915, 
unsigned int flags)
 
ret = wait_for_engines(i915);
} else {
-   ret = wait_for_timeline(>gt.global_timeline, flags);
+   ret = wait_for_timeline(>gt.execution_timeline, flags);
}
 
return ret;
@@ -5652,7 +5652,8 @@ void i915_gem_cleanup_early(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->mm.object_count);
 
mutex_lock(_priv->drm.struct_mutex);
-   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   i915_gem_timeline_fini(_priv->gt.legacy_timeline);
+   i915_gem_timeline_fini(_priv->gt.execution_timeline);
WARN_ON(!list_empty(_priv->gt.timelines));
mutex_unlock(_priv->drm.struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c

[Intel-gfx] [PATCH v2 2/6] drm/i915: Retire requests along rings

2018-04-23 Thread Chris Wilson

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem.c   |   1 +
 drivers/gpu/drm/i915/i915_request.c   | 135 ++
 drivers/gpu/drm/i915/i915_utils.h |   6 +
 drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
 8 files changed, 116 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct list_head timelines;
struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index f3d04f0ab21c..0a117bf9e455 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -298,6 +298,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
 
 static void advance_ring(struct i915_request *request)
 {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
 
/*
@@ -309,7 +310,8 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(!list_is_first(>ring_link, >request_list));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -322,9 +324,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
-   list_del(>ring_link);
+   list_del_init(>ring_link);
 
-   request->ring->head = tail;
+   ring->head = tail;
 }
 
 static void free_capture_list(struct i915_request *request)
@@ -340,16 +342,68 @@ static void free_capture_list(struct i915_request 
*request)
}
 }
 
-static void i915_request_retire(struct i915_request *request)
+static void __request_retire__engine(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
+
+   local_irq_disable();
+
+   spin_lock(>timeline->lock);
+   GEM_BUG_ON(!list_is_first(>link, >timeline->requests));
+   list_del_init(>link);
+   spin_unlock(>timeline->lock);
+
+   spin_lock(>lock);
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+

[Intel-gfx] [PATCH v2 1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Chris Wilson

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to preserve the semantics that no engine wraps in the
middle of a submit. (Although this semantic is now only required for gen7
semaphore support, which only supports greater-then comparisons!)

v2: Keep a global counter of all requests ever submitted and force the
reset when it wraps.

References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_timeline.h |  6 -
 drivers/gpu/drm/i915/i915_request.c  | 33 
 drivers/gpu/drm/i915/intel_engine_cs.c   |  5 ++--
 5 files changed, 22 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..547e97102b85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1340,10 +1340,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
struct rb_node *rb;
 
seq_printf(m, "%s:\n", engine->name);
-   seq_printf(m, "\tseqno = %x [current %x, last %x], inflight 
%d\n",
+   seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
   engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
-  engine->timeline->inflight_seqnos);
+  intel_engine_last_submit(engine));
seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled? 
%s\n",
   yesno(intel_engine_has_waiter(engine)),
   yesno(test_bit(engine->id,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..8fd9fb6efba5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
struct i915_gem_timeline global_timeline;
u32 active_requests;
+   u32 request_serial;
 
/**
 * Is the GPU currently considered idle, or busy executing
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h 
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index 33e01bf6aa36..6e82119e2cd8 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -37,12 +37,6 @@ struct intel_timeline {
u64 fence_context;
u32 seqno;
 
-   /**
-* Count of outstanding requests, from the time they are constructed
-* to the moment they are retired. Loosely coupled to hardware.
-*/
-   u32 inflight_seqnos;
-
spinlock_t lock;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index b692a9f7c357..f3d04f0ab21c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -241,6 +241,7 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
   sizeof(timeline->engine[id].global_sync));
}
 
+   i915->gt.request_serial = seqno;
return 0;
 }
 
@@ -257,18 +258,22 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32 
seqno)
return reset_all_global_seqno(i915, seqno - 1);
 }
 
-static int reserve_engine(struct intel_engine_cs *engine)
+static int reserve_gt(struct drm_i915_private *i915)
 {
-   struct drm_i915_private *i915 = engine->i915;
-   u32 active = ++engine->timeline->inflight_seqnos;
-   u32 seqno = engine->timeline->seqno;
int ret;
 
-   /* Reservation is fine until we need to wrap around */
-   if (unlikely(add_overflows(seqno, active))) {
+   /*
+* Reservation is fine until we may need to wrap around
+*
+* By incrementing the serial for every request, we know that no
+* individual engine may exceed that serial (as each is reset to 0
+* on any wrap). This protects even the most pessimistic of migrations
+* of every request from all engines onto just one.
+*/
+   if (unlikely(++i915->gt.request_serial == 0)) {
ret = reset_all_global_seqno(i915, 0);
if (ret) {
-   engine->timeline->inflight_seqnos--;
+   i915->gt.request_serial--;
return ret;
}
}
@@ -279,15 +284,10 @@ static int reserve_engine(struct intel_engine_cs *engine)
return 0;
 }
 
-static

[Intel-gfx] [PATCH v2 5/6] drm/i915: Split i915_gem_timeline into individual timelines

2018-04-23 Thread Chris Wilson

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 118 +--
 drivers/gpu/drm/i915/i915_gem_context.c   |  49 ++---
 drivers/gpu/drm/i915/i915_gem_context.h   |   2 -
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 198 --
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_perf.c  |  10 +-
 drivers/gpu/drm/i915/i915_request.c   |  66 +++---
 drivers/gpu/drm/i915/i915_request.h   |   3 +-
 drivers/gpu/drm/i915/i915_timeline.c  | 105 ++
 .../{i915_gem_timeline.h => i915_timeline.h}  |  67 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  27 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c   |   4 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  48 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  23 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  11 +-
 .../{i915_gem_timeline.c => i915_timeline.c}  |  94 +++--
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  32 ++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  10 +-
 .../gpu/drm/i915/selftests/mock_timeline.c|  45 ++--
 .../gpu/drm/i915/selftests/mock_timeline.h|  28 +--
 23 files changed, 389 insertions(+), 564 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
 rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
 rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => i915_timeline.c} 
(70%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
- i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
  i915_query.o \
  i915_request.o \
+ i915_timeline.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9bd8328f501..dab15b6abc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
 #include "i915_gem_fence_reg.h"
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
 #include "i915_gpu_error.h"
 #include "i915_request.h"
 #include "i915_scheduler.h"
+#include "i915_timeline.h"
 #include "i915_vma.h"
 
 #include "intel_gvt.h"
@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline execution_timeline;
-   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
 
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d60f3bd4bc66..d36778518cdf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
 
intel_engines_park(i915);
-   i915_gem_timelines_park(i915);
+   i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
 
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 */
-   spin_lock_irqsave(>timeline->lock, flags);
-   list_for_each_entry(request, >timeline->requests, link) {
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
 
@@ -2989,7 +2989,7 @@ i915_gem_find_active_request(struct

[Intel-gfx] [PATCH v2 6/6] drm/i915: Lazily unbind vma on close

2018-04-23 Thread Chris Wilson

When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.

However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.

If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.

In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.

v2: s/__i915_vma_final_close/i915_vma_destroy/ etc.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 14 +++--
 drivers/gpu/drm/i915/i915_vma.c   | 61 +--
 drivers/gpu/drm/i915/i915_vma.h   |  6 ++
 drivers/gpu/drm/i915/selftests/huge_pages.c   |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 8 files changed, 67 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dab15b6abc3c..d4da9f941d04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
 
struct list_head active_rings;
+   struct list_head closed_vma;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d36778518cdf..0dc1658393df 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -165,6 +165,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
+   i915_vma_parked(i915);
 
i915->gt.awake = false;
 
@@ -4792,7 +4793,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
 >vma_list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
-   i915_vma_close(vma);
+   i915_vma_destroy(vma);
}
GEM_BUG_ON(!list_empty(>vma_list));
GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
@@ -5595,6 +5596,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
 
INIT_LIST_HEAD(_priv->gt.timelines);
INIT_LIST_HEAD(_priv->gt.active_rings);
+   INIT_LIST_HEAD(_priv->gt.closed_vma);
 
i915_gem_init__mm(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c74f5df3fb5a..f627a8c47c58 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -762,7 +762,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
 
/* transfer ref to ctx */
-   vma->open_count++;
+   if (!vma->open_count++)
+   i915_vma_reopen(vma);
list_add(>obj_link, >lut_list);
list_add(>ctx_link, >ctx->handles_list);
lut->ctx = eb->ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e9d828324f67..272d6bb407cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2218,6 +2218,12 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
 }
 
 void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   GEM_BUG_ON(vm->closed);
+   vm->closed = true;
+}
+
+static void ppgtt_destroy_vma(struct i915_address_space *vm)
 {
struct list_head *phases[] = {
>active_list,
@@ -2226,15 +2232,12 @@ void i915_ppgtt_close(struct i915_address_space *vm)
NULL,
}, **phase;
 
-   GEM_BUG_ON(vm->closed);
vm->closed = true;
-
for (phase = phases; *phase; phase++) {
struct i915_vma *vma, *vn;
 
list_for_each_entry_safe(vma, vn, *phase, vm_link)
-   if (!i915_vma_is_closed(vma))
-

[Intel-gfx] [PATCH v2 3/6] drm/i915: Only track live rings for retiring

2018-04-23 Thread Chris Wilson

We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.

v2: s/live/active/ for consistency with gt.active_requests

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c  |  6 --
 drivers/gpu/drm/i915/i915_request.c  | 10 --
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  4 
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c |  4 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  5 +++--
 7 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1837c01d44d0..54351cace362 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,8 @@ struct drm_i915_private {
 
struct i915_gem_timeline global_timeline;
struct list_head timelines;
-   struct list_head rings;
+
+   struct list_head active_rings;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 906e2395c245..56c79df5ebce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
 {
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
+   GEM_BUG_ON(!list_empty(>gt.active_rings));
 
if (!i915->gt.awake)
return I915_EPOCH_INVALID;
@@ -5599,9 +5600,10 @@ int i915_gem_init_early(struct drm_i915_private 
*dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
 
-   mutex_lock(_priv->drm.struct_mutex);
-   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
+   INIT_LIST_HEAD(_priv->gt.active_rings);
+
+   mutex_lock(_priv->drm.struct_mutex);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0a117bf9e455..f13b7a1a0aa9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -321,6 +321,7 @@ static void advance_ring(struct i915_request *request)
 * noops - they are safe to be replayed on a reset.
 */
tail = READ_ONCE(request->tail);
+   list_del(>active_link);
} else {
tail = request->postfix;
}
@@ -1081,6 +1082,8 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
i915_gem_active_set(>last_request, request);
 
list_add_tail(>ring_link, >request_list);
+   if (list_is_first(>ring_link, >request_list))
+   list_add(>active_link, >i915->gt.active_rings);
request->emitted_jiffies = jiffies;
 
/*
@@ -1403,14 +1406,17 @@ static void ring_retire_requests(struct intel_ring 
*ring)
 
 void i915_retire_requests(struct drm_i915_private *i915)
 {
-   struct intel_ring *ring, *next;
+   struct intel_ring *ring, *tmp;
 
lockdep_assert_held(>drm.struct_mutex);
 
if (!i915->gt.active_requests)
return;
 
-   list_for_each_entry_safe(ring, next, >gt.rings, link)
+   /* An outstanding request must be on a still active ring somewhere */
+   GEM_BUG_ON(list_empty(>gt.active_rings));
+
+   list_for_each_entry_safe(ring, tmp, >gt.active_rings, active_link)
ring_retire_requests(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 75dca28782ee..3d02b2c779e7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1149,8 +1149,6 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
}
ring->vma = vma;
 
-   list_add(>link, >i915->gt.rings);
-
return ring;
 }
 
@@ -1162,8 +1160,6 @@ intel_ring_free(struct intel_ring *ring)
i915_vma_close(ring->vma);
__i915_gem_object_release_unless_active(obj);
 
-   list_del(>link);
-
kfree(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d816f8dea245..e8d17bcd9bee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -129,7 +129,7 @@ struct intel_ring {
void *vaddr;

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-23 17:52:54)
> 
> On 23/04/2018 14:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affect execution
> > on the local engine.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   tests/gem_exec_schedule.c | 90 +++
> >   1 file changed, 82 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> > index 5d0f215b2..471275169 100644
> > --- a/tests/gem_exec_schedule.c
> > +++ b/tests/gem_exec_schedule.c
> > @@ -49,9 +49,9 @@
> >   
> >   IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
> >   
> > -static void store_dword(int fd, uint32_t ctx, unsigned ring,
> > - uint32_t target, uint32_t offset, uint32_t value,
> > - uint32_t cork, unsigned write_domain)
> > +static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
> > +   uint32_t target, uint32_t offset, uint32_t 
> > value,
> > +   uint32_t cork, unsigned write_domain)
> >   {
> >   const int gen = intel_gen(intel_get_drm_devid(fd));
> >   struct drm_i915_gem_exec_object2 obj[3];
> > @@ -100,7 +100,17 @@ static void store_dword(int fd, uint32_t ctx, unsigned 
> > ring,
> >   batch[++i] = MI_BATCH_BUFFER_END;
> >   gem_write(fd, obj[2].handle, 0, batch, sizeof(batch));
> >   gem_execbuf(fd, );
> > - gem_close(fd, obj[2].handle);
> > +
> > + return obj[2].handle;
> > +}
> > +
> > +static void store_dword(int fd, uint32_t ctx, unsigned ring,
> > + uint32_t target, uint32_t offset, uint32_t value,
> > + uint32_t cork, unsigned write_domain)
> > +{
> > + gem_close(fd, __store_dword(fd, ctx, ring,
> > + target, offset, value,
> > + cork, write_domain));
> >   }
> >   
> >   static uint32_t create_highest_priority(int fd)
> > @@ -161,6 +171,64 @@ static void fifo(int fd, unsigned ring)
> >   munmap(ptr, 4096);
> >   }
> >   
> > +static void independent(int fd, unsigned int engine)
> > +{
> > + IGT_CORK_HANDLE(cork);
> > + uint32_t scratch, plug, batch;
> > + igt_spin_t *spin = NULL;
> > + unsigned int other;
> > + uint32_t *ptr;
> > +
> > + igt_require(engine != 0);
> > +
> > + scratch = gem_create(fd, 4096);
> > + plug = igt_cork_plug(, fd);
> > +
> > + /* Check that we can submit to engine while all others are blocked */
> > + for_each_physical_engine(fd, other) {
> > + if (other == engine)
> > + continue;
> > +
> > + if (spin == NULL) {
> > + spin = __igt_spin_batch_new(fd, 0, other, 0);
> > + } else {
> > + struct drm_i915_gem_exec_object2 obj = {
> > + .handle = spin->handle,
> > + };
> > + struct drm_i915_gem_execbuffer2 eb = {
> > + .buffer_count = 1,
> > + .buffers_ptr = to_user_pointer(),
> > + .flags = other,
> > + };
> > + gem_execbuf(fd, );
> > + }
> > +
> > + store_dword(fd, 0, other, scratch, 0, other, plug, 0);
> > + }
> > + igt_require(spin);
> > +
> > + /* Same priority, but different timeline (as different engine) */
> > + batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
> > +
> > + unplug_show_queue(fd, , engine);
> > + gem_close(fd, plug);
> > +
> > + gem_sync(fd, batch);
> > + gem_close(fd, batch);
> 
> Strictly speaking I think you need to use the poll-able spinner and wait 
> on it here, before the busy assert. It's unlikely, but spinners on 
> 'other' engines are getting submitted async to the store dword batch on 
> 'engine'.

We've waited for its completion, so we know batch is idle and the others
are still busy. We then check its seqno is written to the scratch; so
using pollable here is redundant. And then we check that the others are
run after.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 14:43, Chris Wilson wrote:

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tests/gem_exec_schedule.c | 90 +++
  1 file changed, 82 insertions(+), 8 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 5d0f215b2..471275169 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -49,9 +49,9 @@
  
  IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
  
-static void store_dword(int fd, uint32_t ctx, unsigned ring,

-   uint32_t target, uint32_t offset, uint32_t value,
-   uint32_t cork, unsigned write_domain)
+static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
+ uint32_t target, uint32_t offset, uint32_t value,
+ uint32_t cork, unsigned write_domain)
  {
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[3];
@@ -100,7 +100,17 @@ static void store_dword(int fd, uint32_t ctx, unsigned 
ring,
batch[++i] = MI_BATCH_BUFFER_END;
gem_write(fd, obj[2].handle, 0, batch, sizeof(batch));
gem_execbuf(fd, );
-   gem_close(fd, obj[2].handle);
+
+   return obj[2].handle;
+}
+
+static void store_dword(int fd, uint32_t ctx, unsigned ring,
+   uint32_t target, uint32_t offset, uint32_t value,
+   uint32_t cork, unsigned write_domain)
+{
+   gem_close(fd, __store_dword(fd, ctx, ring,
+   target, offset, value,
+   cork, write_domain));
  }
  
  static uint32_t create_highest_priority(int fd)

@@ -161,6 +171,64 @@ static void fifo(int fd, unsigned ring)
munmap(ptr, 4096);
  }
  
+static void independent(int fd, unsigned int engine)

+{
+   IGT_CORK_HANDLE(cork);
+   uint32_t scratch, plug, batch;
+   igt_spin_t *spin = NULL;
+   unsigned int other;
+   uint32_t *ptr;
+
+   igt_require(engine != 0);
+
+   scratch = gem_create(fd, 4096);
+   plug = igt_cork_plug(, fd);
+
+   /* Check that we can submit to engine while all others are blocked */
+   for_each_physical_engine(fd, other) {
+   if (other == engine)
+   continue;
+
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, 0, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+
+   store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+   }
+   igt_require(spin);
+
+   /* Same priority, but different timeline (as different engine) */
+   batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
+
+   unplug_show_queue(fd, , engine);
+   gem_close(fd, plug);
+
+   gem_sync(fd, batch);
+   gem_close(fd, batch);


Strictly speaking I think you need to use the poll-able spinner and wait 
on it here, before the busy assert. It's unlikely, but spinners on 
'other' engines are getting submitted async to the store dword batch on 
'engine'.



+   igt_assert(gem_bo_busy(fd, spin->handle));
+
+   ptr = gem_mmap__gtt(fd, scratch, 4096, PROT_READ);
+   gem_close(fd, scratch);
+   igt_assert_eq(ptr[0], engine);
+
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   /* And we expect the others to have overwritten us, order unspecified */
+   igt_assert_neq(ptr[0], engine);
+   munmap(ptr, 4096);
+}
+
  static void smoketest(int fd, unsigned ring, unsigned timeout)
  {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -1070,10 +1138,16 @@ igt_main
if (e->exec_id == 0)
continue;
  
-			igt_subtest_f("fifo-%s", e->name) {

-   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));
-   igt_require(gem_can_store_dword(fd, e->exec_id) | 
e->flags);
-   fifo(fd, e->exec_id | e->flags);
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id

[Intel-gfx] [PATCH v11 2/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

2018-04-23 Thread Yunwei Zhang

L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
 - use fls instead of find_last_bit (Chris)
 - use is_power_of_2() instead of counting bit set (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Move local variable into scope where they are used (Ursulin)
 - use a new local variable to reduce long line of code (Ursulin)
v6:
 - Some coding style and use more local variables for clearer
   logic (Ursulin)
v7:
 - Rebased.
v8:
 - Reviewed by Oscar.
v9:
 - Fixed label location. (Oscar)
v10:
 - Improved comments and replaced magical number. (Oscar)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_device_info.c | 34 
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..6c9c01b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2709,6 +2709,10 @@ enum i915_power_well_id {
 #define   GEN10_F2_SS_DIS_SHIFT18
 #define   GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
 
+#defineGEN10_MIRROR_FUSE3  _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
 #define GEN8_EU_DISABLE0   _MMIO(0x9134)
 #define   GEN8_EU_DIS0_S0_MASK 0xff
 #define   GEN8_EU_DIS0_S1_SHIFT24
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d917c9b..44ca90a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -729,6 +729,40 @@ static void sanitize_mcr(struct intel_device_info *info)
u32 slice = fls(info->sseu.slice_mask);
u32 subslice = fls(info->sseu.subslice_mask[slice]);
 
+   /*
+* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
+* L3Banks could be fused off in single slice scenario. If that is
+* the case, we might need to program MCR select to a valid L3Bank
+* by default, to make sure we correctly read certain registers
+* later on (in the range 0xB100 - 0xB3FF).
+* This might be incompatible with
+* WaProgramMgsrForCorrectSliceSpecificMmioReads.
+* Fortunately, this should not happen in production hardware, so
+* we only assert that this is the case (instead of implementing
+* something more complex that requires checking the range of every
+* MMIO read).
+*/
+   if (INTEL_GEN(dev_priv) >= 10 &&
+   is_power_of_2(info->sseu.slice_mask)) {
+   /*
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = info->sseu.subslice_mask[slice];
+
+   u8 enabled_mask = (ss_mask | ss_mask >>
+  GEN10_L3BANK_PAIR_COUNT) &
+  GEN10_L3BANK_MASK;
+   u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
+
+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
+   }
+
if (INTEL_GEN(dev_priv) >= 11) {
mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
  GEN11_MCR_SUBSLICE_MASK;
-- 
2.7.4

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

[Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

2018-04-23 Thread Dave Jones

This warning just started appearing during boot on a machine I upgraded
to 4.17-rc2.  The warning seems to have been there since 2015, but it
has never triggered before today.

Dave

[1.158500] fb: switching to inteldrmfb from EFI VGA
[1.159073] Console: switching to colour dummy device 80x25
[1.159523] checking generic (a 1) vs hw (e000 1000)
[1.159539] fb: switching to inteldrmfb from VGA16 VGA
[1.159752] [drm] Replacing VGA console driver
[1.164454] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.164472] [drm] Driver supports precise vblank timestamp query.
[1.167285] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[1.170212] [ cut here ]
[1.170230] Could not determine valid watermarks for inherited state
[1.170267] WARNING: CPU: 1 PID: 1 at 
drivers/gpu/drm/i915/intel_display.c:14584 sanitize_watermarks+0x17b/0x1c0
[1.170291] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc2+ #1
[1.170308] Hardware name: Shuttle Inc. SH87R/FH87, BIOS 2.03 06/19/2014
[1.170325] RIP: 0010:sanitize_watermarks+0x17b/0x1c0
[1.170338] RSP: :a944c0023bf0 EFLAGS: 00010246
[1.170352] RAX:  RBX: 9193508c RCX: 
[1.170369] RDX: 0001 RSI: 990b7399 RDI: 990b7399
[1.170385] RBP: 9193508c R08: 0001 R09: 0001
[1.170401] R10:  R11:  R12: ffea
[1.170418] R13: 9193508faa88 R14: 919350823528 R15: 9193508c0a08
[1.170434] FS:  () GS:91935640() 
knlGS:
[1.170453] CS:  0010 DS:  ES:  CR0: 80050033
[1.170466] CR2:  CR3: 00011d224001 CR4: 000606e0
[1.170483] Call Trace:
[1.170493]  intel_modeset_init+0x769/0x18f0
[1.170506]  i915_driver_load+0x9b9/0xf30
[1.170519]  ? _raw_spin_unlock_irqrestore+0x3f/0x70
[1.170534]  pci_device_probe+0xa3/0x120
[1.170546]  driver_probe_device+0x28a/0x320
[1.170557]  __driver_attach+0x9e/0xb0
[1.170568]  ? driver_probe_device+0x320/0x320
[1.170581]  bus_for_each_dev+0x68/0xc0
[1.170592]  bus_add_driver+0x11d/0x210
[1.170604]  ? mipi_dsi_bus_init+0x11/0x11
[1.170615]  driver_register+0x5b/0xd0
[1.170627]  do_one_initcall+0x10b/0x33f
[1.170638]  ? do_early_param+0x8b/0x8b
[1.170651]  ? rcu_read_lock_sched_held+0x66/0x70
[1.170663]  ? do_early_param+0x8b/0x8b
[1.170674]  kernel_init_freeable+0x1c3/0x249
[1.170687]  ? rest_init+0xc0/0xc0
[1.170697]  kernel_init+0xa/0x100
[1.170707]  ret_from_fork+0x24/0x30
[1.170717] Code: 00 00 00 65 48 33 04 25 28 00 00 00 75 4f 48 8d a4 24 88 
00 00 00 5b 5d 41 5c 41 5d 41 5e c3 48 c7 c7 e0 5d 04 9a e8 25 33 b1 ff <0f> 0b 
eb a4 48 c7 c6 d5 73 04 9a 48 c7 c7 0f c6 fe 99 e8 0e 33 
[1.170847] irq event stamp: 1449710
[1.170858] hardirqs last  enabled at (1449709): [] 
console_unlock+0x51b/0x6b0
[1.170879] hardirqs last disabled at (1449710): [] 
error_entry+0x86/0x100
[1.170900] softirqs last  enabled at (1449580): [] 
__do_softirq+0x3dd/0x521
[1.170922] softirqs last disabled at (1449563): [] 
irq_exit+0xb7/0xc0


00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor Integrated Graphics Controller (rev 06)

(That's 8086:0402 fwiw)

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

Re: [Intel-gfx] [PULL] gvt-next for 4.18

2018-04-23 Thread Zhi Wang


Thanks! :)

On 04/23/18 18:25, Jani Nikula wrote:

On Mon, 23 Apr 2018, Zhi Wang  wrote:

Hi Jani:

I picked out the patch which causes conflicts and may put it back in the
next back merge from drm-intel-next to gvt-next. So there shouldn't be
any conflict in this pull. Thanks for your efforts.


Thanks, pulled to drm-intel-next-queued.

Just as a reminder, if you have more stuff for v4.18 the deadline is in
about three weeks.

BR,
Jani.




Thanks,
Zhi.

On 04/23/18 16:11, Zhi Wang wrote:

The following changes since commit
fadec6eefe232696c5c471b40df33e6db616e854:

drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)

are available in the git repository at:

https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-23

for you to fetch changes up to 3eda0d22ead04f81ea59c9584bcbf5b496745e92:

drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification (2018-04-23 13:09:36 +0800)


- Minor condition check improvment (Gustavo A. R. Silva)
- Non-priviliged batch buffer scan (Yan Zhao)
- Scheduling optimizations (Zhipeng Gong)


Gustavo A. R. Silva (2):
drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
drm/i915/gvt: Mark expected switch fall-through in
handle_g2v_notification

Zhao Yan (1):
drm/i915/gvt: scan non-privileged batch buffer for debug purpose

Zhipeng Gong (2):
drm/i915/gvt: Use real time to do timer check
drm/i915/gvt: Update time slice more frequently

   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 ---
   drivers/gpu/drm/i915/gvt/debugfs.c  | 67
+
   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
   drivers/gpu/drm/i915/gvt/scheduler.c| 66
+---
   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
   8 files changed, 193 insertions(+), 53 deletions(-)




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

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Antonio Argenziano




On 23/04/18 08:51, Chris Wilson wrote:

Quoting Antonio Argenziano (2018-04-23 16:37:17)



On 23/04/18 06:43, Chris Wilson wrote:

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 



+static void independent(int fd, unsigned int engine)
+{
+ IGT_CORK_HANDLE(cork);
+ uint32_t scratch, plug, batch;
+ igt_spin_t *spin = NULL;
+ unsigned int other;
+ uint32_t *ptr;
+
+ igt_require(engine != 0);
+
+ scratch = gem_create(fd, 4096);
+ plug = igt_cork_plug(, fd);
+
+ /* Check that we can submit to engine while all others are blocked */
+ for_each_physical_engine(fd, other) {
+ if (other == engine)
+ continue;
+
+ if (spin == NULL) {
+ spin = __igt_spin_batch_new(fd, 0, other, 0);
+ } else {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = spin->handle,
+ };
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffer_count = 1,
+ .buffers_ptr = to_user_pointer(),
+ .flags = other,
+ };
+ gem_execbuf(fd, );
+ }
+
+ store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+ }
+ igt_require(spin);
+
+ /* Same priority, but different timeline (as different engine) */
+ batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);


It would be interesting to check that priority scheduling/preemption is
still happening on the free engine.


It's being run on machines without scheduling as well. Reordering tests
are later; not sure if I care about reordering while blocking, that's an
entirely different set of tests being worked on for queues.


Cool, a different set of tests is what I had in mind as well :).

Oh BTW, with the igt_require in the subtests this is:

Reviewed-by: Antonio Argenziano 

Thanks,
Antonio


-Chris


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

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Chris Wilson

Quoting Antonio Argenziano (2018-04-23 16:37:17)
> 
> 
> On 23/04/18 06:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affect execution
> > on the local engine.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> 
> > +static void independent(int fd, unsigned int engine)
> > +{
> > + IGT_CORK_HANDLE(cork);
> > + uint32_t scratch, plug, batch;
> > + igt_spin_t *spin = NULL;
> > + unsigned int other;
> > + uint32_t *ptr;
> > +
> > + igt_require(engine != 0);
> > +
> > + scratch = gem_create(fd, 4096);
> > + plug = igt_cork_plug(, fd);
> > +
> > + /* Check that we can submit to engine while all others are blocked */
> > + for_each_physical_engine(fd, other) {
> > + if (other == engine)
> > + continue;
> > +
> > + if (spin == NULL) {
> > + spin = __igt_spin_batch_new(fd, 0, other, 0);
> > + } else {
> > + struct drm_i915_gem_exec_object2 obj = {
> > + .handle = spin->handle,
> > + };
> > + struct drm_i915_gem_execbuffer2 eb = {
> > + .buffer_count = 1,
> > + .buffers_ptr = to_user_pointer(),
> > + .flags = other,
> > + };
> > + gem_execbuf(fd, );
> > + }
> > +
> > + store_dword(fd, 0, other, scratch, 0, other, plug, 0);
> > + }
> > + igt_require(spin);
> > +
> > + /* Same priority, but different timeline (as different engine) */
> > + batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
> 
> It would be interesting to check that priority scheduling/preemption is 
> still happening on the free engine.

It's being run on machines without scheduling as well. Reordering tests
are later; not sure if I care about reordering while blocking, that's an
entirely different set of tests being worked on for queues.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Antonio Argenziano




On 23/04/18 06:43, Chris Wilson wrote:

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 



+static void independent(int fd, unsigned int engine)
+{
+   IGT_CORK_HANDLE(cork);
+   uint32_t scratch, plug, batch;
+   igt_spin_t *spin = NULL;
+   unsigned int other;
+   uint32_t *ptr;
+
+   igt_require(engine != 0);
+
+   scratch = gem_create(fd, 4096);
+   plug = igt_cork_plug(, fd);
+
+   /* Check that we can submit to engine while all others are blocked */
+   for_each_physical_engine(fd, other) {
+   if (other == engine)
+   continue;
+
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, 0, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+
+   store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+   }
+   igt_require(spin);
+
+   /* Same priority, but different timeline (as different engine) */
+   batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);


It would be interesting to check that priority scheduling/preemption is 
still happening on the free engine.



+
+   unplug_show_queue(fd, , engine);
+   gem_close(fd, plug);
+
+   gem_sync(fd, batch);
+   gem_close(fd, batch);
+   igt_assert(gem_bo_busy(fd, spin->handle));
+
+   ptr = gem_mmap__gtt(fd, scratch, 4096, PROT_READ);
+   gem_close(fd, scratch);
+   igt_assert_eq(ptr[0], engine);
+
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   /* And we expect the others to have overwritten us, order unspecified */
+   igt_assert_neq(ptr[0], engine);
+   munmap(ptr, 4096);
+}
+
  static void smoketest(int fd, unsigned ring, unsigned timeout)
  {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -1070,10 +1138,16 @@ igt_main
if (e->exec_id == 0)
continue;
  
-			igt_subtest_f("fifo-%s", e->name) {

-   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));
-   igt_require(gem_can_store_dword(fd, e->exec_id) | 
e->flags);
-   fifo(fd, e->exec_id | e->flags);
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));


I thought that we added this to the subtests to have a constant list of 
tests for all platforms.


Thanks,
Antonio


+   igt_require(gem_can_store_dword(fd, 
e->exec_id) | e->flags);
+   }
+
+   igt_subtest_f("fifo-%s", e->name)
+   fifo(fd, e->exec_id | e->flags);
+   igt_subtest_f("independent-%s", e->name)
+   independent(fd, e->exec_id | e->flags);
}
}
}


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

Re: [Intel-gfx] [CI 1/2] drm/i915: Use ktime on wait_for

2018-04-23 Thread Lucas De Marchi

On Mon, Apr 23, 2018 at 4:37 AM, Mika Kuoppala
 wrote:
> We use jiffies to determine when wait expires. However
> Imre did find out that jiffies can and will do a >1
> increments on certain situations [1]. When this happens
> in a wait_for loop, we return timeout errorneously
> much earlier than what the real wallclock would say.
>
> We can't afford our waits to timeout prematurely.

Isn't this also the reason why we have *_to_jiffies_timeout() family
of functions? Should those
be converted as well?

Lucas De Marchi

> Discard jiffies and change to ktime to detect timeouts.
>
> v2: added bugzilla entry (Imre), added stable (Chris)
>
> Reported-by: Imre Deak 
> References: https://lkml.org/lkml/2018/4/18/798 [1]
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
> Cc: Imre Deak 
> Cc: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: 
> Signed-off-by: Mika Kuoppala 
> Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 44ed248f1fe9..33ff2638c92b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -49,12 +49,12 @@
>   * check the condition before the timeout.
>   */
>  #define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
> -   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
> +   const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \
> long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
> int ret__;  \
> might_sleep();  \
> for (;;) {  \
> -   bool expired__ = time_after(jiffies, timeout__);\
> +   const bool expired__ = ktime_after(ktime_get_raw(), end__); \
> OP; \
> if (COND) { \
> ret__ = 0;  \
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Ville Syrjälä

On Mon, Apr 23, 2018 at 04:39:54PM +0200, Maarten Lankhorst wrote:
> Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> > On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> >> The rounding can cause a perfectly normal 16x16 src to full-screen
> >> dst to be rounded down, even without clipping involved. Because of
> >> this we should just remove the adjustment, as no other driver or plane
> >> does it.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/intel_sprite.c | 5 -
> >>  1 file changed, 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> index a1d048af0261..203ca8b362a5 100644
> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> @@ -996,11 +996,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
> >>return vscale;
> >>}
> >>  
> >> -  /* Make the source viewport size an exact multiple of the 
> >> scaling factors. */
> >> -  drm_rect_adjust_size(src,
> >> -   drm_rect_width(dst) * hscale - 
> >> drm_rect_width(src),
> >> -   drm_rect_height(dst) * vscale - 
> >> drm_rect_height(src));
> >> -
> > This makes the scaling factor checks a slightly incorrect. Ie. we might
> > exceed the max h/vscale a bit without realizing it. It's a shame the
> > hardware doesn't let us actually program the scaling factors/increments
> > and starting phases anymore :( Also we don't actually know how the
> > hardware calculates that stuff (assuming it has such things internally),
> > so I'm not actually sure how we should be checking the max limit so
> > that we actually check what the hardware will use.
> >
> > Without a more detailed study of the hardware behaviour I'm thinking
> > we should perhaps just check the final src vs. dst coordinates like so:
> > if (src > dst*max)
> > fail;
> > as that would avoid the precision issues with the .16 scaling factors.
> >
> > Another option could be to round h/vscale up. That should guarantee
> > that we never exceed the max.
> Could we take a pessimistic view for both sides? Round up if scaling > 1, 
> round down when scaling < 1?
> That way we should never be afraid of any limits..

That does sound like a decent idea to me. At least I can't immediately
think why it wouldn't work out.

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

Re: [Intel-gfx] [PATCH 06/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset

2018-04-23 Thread Chris Wilson

Quoting Mika Kuoppala (2018-04-23 14:03:02)
> Chris Wilson  writes:
> > @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct 
> > timer_list *t)
> >   if (!b->irq_armed)
> >   return;
> >  
> > + /* If the user has disabled the fake-irq, restore the hangchecking */
> > + if (!test_bit(engine->id, >i915->gpu_error.missed_irq_rings)) 
> > {
> > + mod_timer(>hangcheck, wait_timeout());
> > + return;
> > + }
> > +
> 
> Looking at the cancel_fake_irq() now, which we still need to keep as
> sync, I think there is race introduce now as this can queue itself.
> 
> I think we want to also change the cancel_fake_irq() to do
> the bit clearing first, not last after the del_timer_syncs().

I see what you mean, but I think we want

del_timer_sync(>fake_irq); // may queue b->hangcheck
del_timer_sync(>hangcheck);
clear_bit(engine->id. missed_irq_rings);

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Maarten Lankhorst

Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
>> The rounding can cause a perfectly normal 16x16 src to full-screen
>> dst to be rounded down, even without clipping involved. Because of
>> this we should just remove the adjustment, as no other driver or plane
>> does it.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_sprite.c | 5 -
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index a1d048af0261..203ca8b362a5 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -996,11 +996,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
>>  return vscale;
>>  }
>>  
>> -/* Make the source viewport size an exact multiple of the 
>> scaling factors. */
>> -drm_rect_adjust_size(src,
>> - drm_rect_width(dst) * hscale - 
>> drm_rect_width(src),
>> - drm_rect_height(dst) * vscale - 
>> drm_rect_height(src));
>> -
> This makes the scaling factor checks a slightly incorrect. Ie. we might
> exceed the max h/vscale a bit without realizing it. It's a shame the
> hardware doesn't let us actually program the scaling factors/increments
> and starting phases anymore :( Also we don't actually know how the
> hardware calculates that stuff (assuming it has such things internally),
> so I'm not actually sure how we should be checking the max limit so
> that we actually check what the hardware will use.
>
> Without a more detailed study of the hardware behaviour I'm thinking
> we should perhaps just check the final src vs. dst coordinates like so:
> if (src > dst*max)
>   fail;
> as that would avoid the precision issues with the .16 scaling factors.
>
> Another option could be to round h/vscale up. That should guarantee
> that we never exceed the max.
Could we take a pessimistic view for both sides? Round up if scaling > 1, round 
down when scaling < 1?
That way we should never be afraid of any limits..

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Ville Syrjälä

On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> The rounding can cause a perfectly normal 16x16 src to full-screen
> dst to be rounded down, even without clipping involved. Because of
> this we should just remove the adjustment, as no other driver or plane
> does it.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index a1d048af0261..203ca8b362a5 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -996,11 +996,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
>   return vscale;
>   }
>  
> - /* Make the source viewport size an exact multiple of the 
> scaling factors. */
> - drm_rect_adjust_size(src,
> -  drm_rect_width(dst) * hscale - 
> drm_rect_width(src),
> -  drm_rect_height(dst) * vscale - 
> drm_rect_height(src));
> -

This makes the scaling factor checks a slightly incorrect. Ie. we might
exceed the max h/vscale a bit without realizing it. It's a shame the
hardware doesn't let us actually program the scaling factors/increments
and starting phases anymore :( Also we don't actually know how the
hardware calculates that stuff (assuming it has such things internally),
so I'm not actually sure how we should be checking the max limit so
that we actually check what the hardware will use.

Without a more detailed study of the hardware behaviour I'm thinking
we should perhaps just check the final src vs. dst coordinates like so:
if (src > dst*max)
fail;
as that would avoid the precision issues with the .16 scaling factors.

Another option could be to round h/vscale up. That should guarantee
that we never exceed the max.

>   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
>   state->base.rotation);
>  
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
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: Don't pass the index to drm_property_add_enum() (rev2)

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm: Don't pass the index to drm_property_add_enum() (rev2)
URL   : https://patchwork.freedesktop.org/series/40122/
State : failure

== Summary ==

Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
error: drivers/gpu/drm/drm_connector.c: patch does not apply
error: patch failed: drivers/gpu/drm/drm_property.c:169
error: drivers/gpu/drm/drm_property.c: patch does not apply
error: patch failed: drivers/gpu/drm/gma500/cdv_device.c:485
error: drivers/gpu/drm/gma500/cdv_device.c: patch does not apply
error: patch failed: drivers/gpu/drm/gma500/psb_intel_sdvo.c:2281
error: drivers/gpu/drm/gma500/psb_intel_sdvo.c: patch does not apply
error: patch failed: drivers/gpu/drm/i915/intel_sdvo.c:2779
error: drivers/gpu/drm/i915/intel_sdvo.c: patch does not apply
error: patch failed: drivers/gpu/drm/nouveau/nouveau_display.c:338
error: drivers/gpu/drm/nouveau/nouveau_display.c: patch does not apply
error: patch failed: include/drm/drm_property.h:260
error: include/drm/drm_property.h: 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   include/drm/drm_property.h
Patch failed at 0001 drm: Don't pass the index to drm_property_add_enum()
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] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Use ktime on wait_for

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL   : https://patchwork.freedesktop.org/series/42115/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8774 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42115/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8774 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-cnl-y3:  PASS -> DMESG-WARN (fdo#104951)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8774

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8774: d8fac5f69e93f2197dc4bd591b196a524873a795 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

d8fac5f69e93 drm/i915: Add compiler barrier to wait_for
4dbef50fbcf3 drm/i915: Use ktime on wait_for

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8774/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: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL   : https://patchwork.freedesktop.org/series/42113/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8773 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42113/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8773 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8773

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8773: dedb75c52059a931ae14dca63f4b70880f678cf4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

dedb75c52059 drm/i915: Remove src adjustment in intel_check_sprite_plane.

== Logs ==

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

Re: [Intel-gfx] [v2] drm/i915/fbdev: Enable late fbdev initial configuration

2018-04-23 Thread Jani Nikula

On Fri, 20 Apr 2018, Paul Menzel  wrote:
> Dear Jose,
>
>
> On 04/19/18 01:41, Souza, Jose wrote:
>> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
>
> Nit: Space before (.
>
>> there still no sink connected it will cause
>> drm_fb_helper_initial_config() to return 0 as no error happened(but
>> internally the return is -EAGAIN).
>
> Nit: Space before (.
>
>> Because no framebuffer was allocated, when a sink is connected
>> intel_fbdev_output_poll_changed() will not execute
>> drm_fb_helper_hotplug_event() that would trigger another try to do the
>> initial fbdev configuration.
>> 
>> So here allowing drm_fb_helper_hotplug_event() to be executed when there
>> is not frambebuffer allocated and fbdev was not setup yet.
>
> s/not/no/
> s/setup/set up/
>
>> This issue also happens when a MST DP sink is connected since boot, as
>> the MST topology is discovered in parallel if intel_fbdev_initial_config()
>> is executed before the first sink MST is discovered it will cause this
>> same issue.
>> 
>> This is a follow up patch of
>
> follow-up
>
>> https://patchwork.freedesktop.org/patch/196089/
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Chris Wilson 
>> Signed-off-by: José Roberto de Souza 
>> ---
>> 
>> Changes from v1:
>> - not creating a dump framebuffer anymore, instead just allowing
>> drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.
>
> s/setup/set up/
>
>>   drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
>> b/drivers/gpu/drm/i915/intel_fbdev.c
>> index 7d41d139341b..e9e02b58b7be 100644
>> --- a/drivers/gpu/drm/i915/intel_fbdev.c
>> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
>> @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct drm_device 
>> *dev)
>>  return;
>>   
>>  intel_fbdev_sync(ifbdev);
>> -if (ifbdev->vma)
>> +if (ifbdev->vma || ifbdev->helper.deferred_setup)
>>  drm_fb_helper_hotplug_event(>helper);
>>   }
>>   
>
> Tested-by: Paul Menzel 

Also from the bug,

Tested-by: frederik  # 4.15.17
Tested-by: Ian Pilcher 

>
>
> Kind regards,
>
> Paul
>
> ___
> 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] drm: Don't pass the index to drm_property_add_enum()

2018-04-23 Thread Lisovskiy, Stanislav

Acked-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>


From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs; 
nouv...@lists.freedesktop.org
Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()

From: Ville Syrjälä 

drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.

Cc: Patrik Jakobsson 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c   |  6 +++---
 drivers/gpu/drm/drm_property.c| 27 +--
 drivers/gpu/drm/gma500/cdv_device.c   |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +---
 include/drm/drm_property.h|  2 +-
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..dfc8ca1e9413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
goto nomem;

for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property, i,
+   drm_property_add_enum(dev->mode_config.tv_mode_property,
  i, modes[i]);

dev->mode_config.tv_brightness_property =
@@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
-   int i, j = 0;
+   int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;

@@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
if (!(BIT(i) & scaling_mode_mask))
continue;

-   ret = drm_property_add_enum(scaling_mode_property, j++,
+   ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 8f4672daac7f..1f8031e30f53 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev,
return NULL;

for (i = 0; i < num_values; i++) {
-   ret = drm_property_add_enum(property, i,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret, index = 0;
+   int i, ret;
int num_values = hweight64(supported_bits);

flags |= DRM_MODE_PROP_BITMASK;
@@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
if (!(supported_bits & (1ULL << props[i].type)))
continue;

-   if (WARN_ON(index >= num_values)) {
-   drm_property_destroy(dev, property);
-   return NULL;
-   }
-
-   ret = drm_property_add_enum(property, index++,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -376,7 +371,6 @@ EXPORT_SYMBOL(drm_property_create_bool);
 /**
  * drm_property_add_enum - add a possible value to an enumeration property
  * @property: enumeration property to change
- * @index: index of the new enumeration
  *

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Chris Wilson

Quoting Patchwork (2018-04-23 14:40:51)
> igt@core_auth@basic-auth:
>   fi-glk-j4005:   PASS -> INCOMPLETE (k.org#198133, fdo#103359)
>   fi-bdw-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
>   fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
>   fi-cnl-psr: PASS -> INCOMPLETE (fdo#105086)
>   fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)
>   fi-bxt-j4205:   PASS -> INCOMPLETE (fdo#103927)
>   fi-skl-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)

Oh sausage. engine->last_retired_context needs to be in engine order,
but ring->head needs to be in ring order.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector

2018-04-23 Thread Lisovskiy, Stanislav

Ping

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis 
[stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 10:34 AM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI 
connector

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 +++
 drivers/gpu/drm/drm_connector.c  | 74 
 drivers/gpu/drm/drm_edid.c   |  2 +
 include/drm/drm_connector.h  | 18 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 8 files changed, 130 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..e233c2626bd0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -517,6 +517,12 @@ Standard Connector Properties
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: standard connector properties

+HDMI Specific Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: HDMI connector properties
+
 Plane Composition Properties
 

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..3567c986bd7d 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@

[Intel-gfx] [PATCH igt] test/gem_exec_schedule: Check each engine is an independent timeline

2018-04-23 Thread Chris Wilson

In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/gem_exec_schedule.c | 90 +++
 1 file changed, 82 insertions(+), 8 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 5d0f215b2..471275169 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -49,9 +49,9 @@
 
 IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
 
-static void store_dword(int fd, uint32_t ctx, unsigned ring,
-   uint32_t target, uint32_t offset, uint32_t value,
-   uint32_t cork, unsigned write_domain)
+static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
+ uint32_t target, uint32_t offset, uint32_t value,
+ uint32_t cork, unsigned write_domain)
 {
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[3];
@@ -100,7 +100,17 @@ static void store_dword(int fd, uint32_t ctx, unsigned 
ring,
batch[++i] = MI_BATCH_BUFFER_END;
gem_write(fd, obj[2].handle, 0, batch, sizeof(batch));
gem_execbuf(fd, );
-   gem_close(fd, obj[2].handle);
+
+   return obj[2].handle;
+}
+
+static void store_dword(int fd, uint32_t ctx, unsigned ring,
+   uint32_t target, uint32_t offset, uint32_t value,
+   uint32_t cork, unsigned write_domain)
+{
+   gem_close(fd, __store_dword(fd, ctx, ring,
+   target, offset, value,
+   cork, write_domain));
 }
 
 static uint32_t create_highest_priority(int fd)
@@ -161,6 +171,64 @@ static void fifo(int fd, unsigned ring)
munmap(ptr, 4096);
 }
 
+static void independent(int fd, unsigned int engine)
+{
+   IGT_CORK_HANDLE(cork);
+   uint32_t scratch, plug, batch;
+   igt_spin_t *spin = NULL;
+   unsigned int other;
+   uint32_t *ptr;
+
+   igt_require(engine != 0);
+
+   scratch = gem_create(fd, 4096);
+   plug = igt_cork_plug(, fd);
+
+   /* Check that we can submit to engine while all others are blocked */
+   for_each_physical_engine(fd, other) {
+   if (other == engine)
+   continue;
+
+   if (spin == NULL) {
+   spin = __igt_spin_batch_new(fd, 0, other, 0);
+   } else {
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = spin->handle,
+   };
+   struct drm_i915_gem_execbuffer2 eb = {
+   .buffer_count = 1,
+   .buffers_ptr = to_user_pointer(),
+   .flags = other,
+   };
+   gem_execbuf(fd, );
+   }
+
+   store_dword(fd, 0, other, scratch, 0, other, plug, 0);
+   }
+   igt_require(spin);
+
+   /* Same priority, but different timeline (as different engine) */
+   batch = __store_dword(fd, 0, engine, scratch, 0, engine, plug, 0);
+
+   unplug_show_queue(fd, , engine);
+   gem_close(fd, plug);
+
+   gem_sync(fd, batch);
+   gem_close(fd, batch);
+   igt_assert(gem_bo_busy(fd, spin->handle));
+
+   ptr = gem_mmap__gtt(fd, scratch, 4096, PROT_READ);
+   gem_close(fd, scratch);
+   igt_assert_eq(ptr[0], engine);
+
+   igt_spin_batch_free(fd, spin);
+   gem_quiescent_gpu(fd);
+
+   /* And we expect the others to have overwritten us, order unspecified */
+   igt_assert_neq(ptr[0], engine);
+   munmap(ptr, 4096);
+}
+
 static void smoketest(int fd, unsigned ring, unsigned timeout)
 {
const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
@@ -1070,10 +1138,16 @@ igt_main
if (e->exec_id == 0)
continue;
 
-   igt_subtest_f("fifo-%s", e->name) {
-   igt_require(gem_ring_has_physical_engine(fd, 
e->exec_id | e->flags));
-   igt_require(gem_can_store_dword(fd, e->exec_id) 
| e->flags);
-   fifo(fd, e->exec_id | e->flags);
+   igt_subtest_group {
+   igt_fixture {
+   
igt_require(gem_ring_has_physical_engine(fd, e->exec_id | e->flags));
+   igt_require(gem_can_store_dword(fd, 
e->exec_id) | e->flags);
+   }
+
+   igt_subtest_f("fifo-%s", e->name)
+   fifo(fd,

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42111/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8772 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8772 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8772, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42111/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8772:

  === IGT changes ===

 Possible regressions 

igt@core_auth@basic-auth:
  fi-kbl-r:   PASS -> INCOMPLETE
  fi-bdw-5557u:   PASS -> INCOMPLETE
  fi-skl-guc: PASS -> INCOMPLETE
  fi-kbl-7567u:   PASS -> INCOMPLETE
  fi-kbl-7500u:   PASS -> INCOMPLETE
  fi-skl-6600u:   PASS -> INCOMPLETE
  {fi-kbl-7560u}: PASS -> INCOMPLETE
  fi-cfl-8700k:   PASS -> INCOMPLETE
  fi-skl-6700k2:  PASS -> INCOMPLETE
  fi-cfl-s3:  PASS -> INCOMPLETE
  fi-skl-6770hq:  PASS -> INCOMPLETE
  fi-bsw-n3050:   PASS -> INCOMPLETE
  fi-skl-6260u:   PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8772 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@core_auth@basic-auth:
  fi-glk-j4005:   PASS -> INCOMPLETE (k.org#198133, fdo#103359)
  fi-bdw-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
  fi-cnl-psr: PASS -> INCOMPLETE (fdo#105086)
  fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)
  fi-bxt-j4205:   PASS -> INCOMPLETE (fdo#103927)
  fi-skl-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086
  fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (36 -> 32) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq fi-cfl-u 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8772

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8772: 2b96d52d778b75c784da54bc5a6cda1dc937c0d5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

2b96d52d778b drm/i915: Lazily unbind vma on close
13fe29e79460 drm/i915: Split i915_gem_timeline into individual timelines
c0197b0d3111 drm/i915: Move timeline from GTT to ring
7a4324010faa drm/i915: Only track live rings for retiring
8456001c1d6e drm/i915: Retire requests along rings
cdd8eb08a9de drm/i915: Stop tracking timeline->inflight_seqnos


== Kernel 32bit build ==

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

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42111/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/drm/i915/i915_request.c:268:13: error: undefined identifier 
'__builtin_add_overflow_p'
-O:drivers/gpu/drm/i915/i915_request.c:268:13: warning: call with no type!
+drivers/gpu/drm/i915/i915_request.c:266:13: error: undefined identifier 
'__builtin_add_overflow_p'
+drivers/gpu/drm/i915/i915_request.c:266:13: warning: call with no type!

Commit: drm/i915: Retire requests along rings
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Only track live rings for retiring
Okay!

Commit: drm/i915: Move timeline from GTT to ring
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3651:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Split i915_gem_timeline into individual timelines
-O:drivers/gpu/drm/i915/i915_request.c:266:13: error: undefined identifier 
'__builtin_add_overflow_p'
-O:drivers/gpu/drm/i915/i915_request.c:266:13: warning: call with no type!
+drivers/gpu/drm/i915/i915_request.c:263:13: error: undefined identifier 
'__builtin_add_overflow_p'
+drivers/gpu/drm/i915/i915_request.c:263:13: warning: call with no type!
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3651:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3649:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Lazily unbind vma on close
-drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 
0xea00 is so big it is unsigned long
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3649:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 
0xea00 is so big it is unsigned long
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3650:16: warning: expression 
using sizeof(void)

___
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/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Patchwork

== Series Details ==

Series: series starting with [1/6] drm/i915: Stop tracking 
timeline->inflight_seqnos
URL   : https://patchwork.freedesktop.org/series/42111/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cdd8eb08a9de drm/i915: Stop tracking timeline->inflight_seqnos
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 9b6586ae9f6b ("drm/i915: Keep a 
global seqno per-engine")'
#14: 
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")

total: 1 errors, 0 warnings, 0 checks, 67 lines checked
8456001c1d6e drm/i915: Retire requests along rings
7a4324010faa drm/i915: Only track live rings for retiring
c0197b0d3111 drm/i915: Move timeline from GTT to ring
13fe29e79460 drm/i915: Split i915_gem_timeline into individual timelines
-:447: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#447: 
deleted file mode 100644

-:948: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#948: FILE: drivers/gpu/drm/i915/i915_timeline.c:1:
+/*

total: 0 errors, 2 warnings, 0 checks, 1612 lines checked
2b96d52d778b drm/i915: Lazily unbind vma on close

___
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/hisilicon/hibmc: Using module_pci_driver.

2018-04-23 Thread Patchwork

== Series Details ==

Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL   : https://patchwork.freedesktop.org/series/42103/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8771 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42103/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8771 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


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


== Participating hosts (36 -> 33) ==

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4078 -> Patchwork_8771

  CI_DRM_4078: 9391010824b34ec58217f816ba5e314e7312191d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_: dcc44347494231feabc588c2a76998cbc9afdf8c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8771: 10d8b3ee29f819bfcc2a469935d4f006e16a3518 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

10d8b3ee29f8 drm/hisilicon/hibmc: Using module_pci_driver.

== Logs ==

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Lazily unbind vma on close

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:14, Chris Wilson wrote:

When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.

However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.

If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.

In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/i915_gem.c   |  4 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c|  5 +++
  drivers/gpu/drm/i915/i915_gem_gtt.c   | 14 ---
  drivers/gpu/drm/i915/i915_vma.c   | 39 ---
  drivers/gpu/drm/i915/i915_vma.h   |  5 +++
  drivers/gpu/drm/i915/selftests/huge_pages.c   |  2 +-
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
  8 files changed, 51 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89cb74c30a00..b2f78da9bc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,6 +2060,7 @@ struct drm_i915_private {
  
  		struct list_head timelines;

struct list_head live_rings;
+   struct list_head closed_vma;
u32 active_requests;
  
  		/**

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f07556693cfe..4fb7d45b5b5d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -165,6 +165,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
i915_timelines_park(i915);
  
  	i915_pmu_gt_parked(i915);

+   i915_vma_parked(i915);
  
  	i915->gt.awake = false;
  
@@ -4792,7 +4793,7 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,

 >vma_list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
-   i915_vma_close(vma);
+   __i915_vma_final_close(vma);
}
GEM_BUG_ON(!list_empty(>vma_list));
GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
@@ -5595,6 +5596,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
  
  	INIT_LIST_HEAD(_priv->gt.live_rings);

INIT_LIST_HEAD(_priv->gt.timelines);
+   INIT_LIST_HEAD(_priv->gt.closed_vma);
  
  	i915_gem_init__mm(dev_priv);
  
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c

index c74f5df3fb5a..e5b8371e30de 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -768,6 +768,11 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
lut->ctx = eb->ctx;
lut->handle = handle;
  
+		if (vma->flags & I915_VMA_CLOSED) {

+   vma->flags &= ~I915_VMA_CLOSED;
+   list_del(>closed_link);
+   }


Feels like i915_vma.c should contain code do deal with this level of 
operation. Not sure - i915_vma_pin perhaps, or somewhere else, or 
somewhere new yet. i915_vma_reopen maybe?



+
  add_vma:
err = eb_add_vma(eb, i, vma);
if (unlikely(err))
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e9d828324f67..c1587d83fd19 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2218,6 +2218,12 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
  }
  
  void i915_ppgtt_close(struct i915_address_space *vm)

+{
+   GEM_BUG_ON(vm->closed);
+   vm->closed = true;
+}
+
+static void ppgtt_close_vma(struct i915_address_space *vm)
  {
struct list_head *phases[] = {
>active_list,
@@ -2226,15 +2232,12 @@ void i915_ppgtt_close(struct i915_address_space *vm)
NULL,
}, **phase;
  
-	GEM_BUG_ON(vm->closed);

vm->closed = true;
-
for (phase = phases; *phase; phase++) {
struct

Re: [Intel-gfx] [PATCH 06/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset

2018-04-23 Thread Mika Kuoppala

Chris Wilson  writes:

> Instead of synchronously cancelling the timer and re-enabling it inside
> the reset callbacks, keep the timer enabled and let it die on its next
> wakeup if no longer required. This allows
> intel_engine_reset_breadcrumbs() to be used from an atomic
> (timer/softirq) context such as required for resetting an engine.
>
> It also allows us to react better to the user poking around debugfs for
> testing missed irqs.
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 27 +---
>  1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 671a6d61e29d..0a2128c6b418 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -130,11 +130,12 @@ static void intel_breadcrumbs_hangcheck(struct 
> timer_list *t)
>  
>  static void intel_breadcrumbs_fake_irq(struct timer_list *t)
>  {
> - struct intel_engine_cs *engine = from_timer(engine, t,
> - breadcrumbs.fake_irq);
> + struct intel_engine_cs *engine =
> + from_timer(engine, t, breadcrumbs.fake_irq);
>   struct intel_breadcrumbs *b = >breadcrumbs;
>  
> - /* The timer persists in case we cannot enable interrupts,
> + /*
> +  * The timer persists in case we cannot enable interrupts,
>* or if we have previously seen seqno/interrupt incoherency
>* ("missed interrupt" syndrome, better known as a "missed breadcrumb").
>* Here the worker will wake up every jiffie in order to kick the
> @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct timer_list 
> *t)
>   if (!b->irq_armed)
>   return;
>  
> + /* If the user has disabled the fake-irq, restore the hangchecking */
> + if (!test_bit(engine->id, >i915->gpu_error.missed_irq_rings)) {
> + mod_timer(>hangcheck, wait_timeout());
> + return;
> + }
> +

Looking at the cancel_fake_irq() now, which we still need to keep as
sync, I think there is race introduce now as this can queue itself.

I think we want to also change the cancel_fake_irq() to do
the bit clearing first, not last after the del_timer_syncs().

-Mika

>   mod_timer(>fake_irq, jiffies + 1);
>  }
>  
> @@ -840,15 +847,22 @@ void intel_engine_reset_breadcrumbs(struct 
> intel_engine_cs *engine)
>  {
>   struct intel_breadcrumbs *b = >breadcrumbs;
>  
> - cancel_fake_irq(engine);
>   spin_lock_irq(>irq_lock);
>  
> + /*
> +  * Leave the fake_irq timer enabled (if it is running), but clear the
> +  * bit so that it turns itself off on its next wake up and goes back
> +  * to the long hangcheck interval if still required.
> +  */
> + clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
> +
>   if (b->irq_enabled)
>   irq_enable(engine);
>   else
>   irq_disable(engine);
>  
> - /* We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
> + /*
> +  * We set the IRQ_BREADCRUMB bit when we enable the irq presuming the
>* GPU is active and may have already executed the MI_USER_INTERRUPT
>* before the CPU is ready to receive. However, the engine is currently
>* idle (we haven't started it yet), there is no possibility for a
> @@ -857,9 +871,6 @@ void intel_engine_reset_breadcrumbs(struct 
> intel_engine_cs *engine)
>*/
>   clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
>  
> - if (b->irq_armed)
> - enable_fake_irq(b);
> -
>   spin_unlock_irq(>irq_lock);
>  }
>  
> -- 
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

2018-04-23 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-23 13:33:04)
> 
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We need to move to a more flexible timeline that doesn't assume one
> > fence context per engine, and so allow for a single timeline to be used
> > across a combination of engines. This means that preallocating a fence
> > context per engine is now a hindrance, and so we want to introduce the
> > singular timeline. From the code perspective, this has the notable
> > advantage of clearing up a lot of mirky semantics and some clumsy
> > pointer chasing.
> > 
> > By splitting the timeline up into a single entity rather than an array
> > of per-engine timelines, we can realise the goal of the previous patch
> > of tracking the timeline alongside the ring.
> 
> Isn't single fence context and a single seqno space breaking the ABI? 
> Submissions from a context are now serialized across all engines. I am 
> thinking about await and dependency created in __i915_add_request to 
> timeline->last_request.

It's still one per engine, the ABI shouldn't have changed unless I've
screwed up. I now I wrote some tests to assert the independence... But
probably only have those for the new ABI we were discussing.

I guess I should make sure gem_exec_schedule is covering it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move timeline from GTT to ring

2018-04-23 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-23 11:44:19)
> 
> On 23/04/2018 11:13, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 0097a77fae8d..1635975dbc16 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request 
> > *request)
> >   {
> >   struct intel_engine_cs *engine = request->engine;
> >   struct i915_gem_context *hung_ctx = request->ctx;
> > - struct intel_timeline *timeline;
> > + struct intel_timeline *timeline = request->timeline;
> >   unsigned long flags;
> >   
> > - timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
> > + GEM_BUG_ON(timeline == engine->timeline);
> 
> Isn't this the guilty request, so would be on the engine timeline?

request->timeline is always the client timeline, so we can move it back
to the client on being preempted.

> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 534b8d684cef..35869afdb199 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -639,6 +639,7 @@ i915_request_alloc(struct intel_engine_cs *engine, 
> > struct i915_gem_context *ctx)
> >   if (IS_ERR(ring))
> >   return ERR_CAST(ring);
> >   GEM_BUG_ON(!ring);
> > + GEM_BUG_ON(ring->timeline == engine->timeline);
> 
> It's debugging only but feels out of place. Put it in 
> intel_engine_create_ring?

Not quite, I can move it down, the point is that rq->timeline !=
engine->timeline. Maybe a bit of s/rq->timeline/rq->user_timeline/?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:13, Chris Wilson wrote:

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.


Isn't single fence context and a single seqno space breaking the ABI? 
Submissions from a context are now serialized across all engines. I am 
thinking about await and dependency created in __i915_add_request to 
timeline->last_request.




Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/Makefile |   2 +-
  drivers/gpu/drm/i915/i915_drv.h   |   4 +-
  drivers/gpu/drm/i915/i915_gem.c   | 117 +--
  drivers/gpu/drm/i915/i915_gem_context.c   |  49 ++---
  drivers/gpu/drm/i915/i915_gem_context.h   |   2 -
  drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
  drivers/gpu/drm/i915/i915_gem_timeline.c  | 198 --
  drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
  drivers/gpu/drm/i915/i915_perf.c  |  10 +-
  drivers/gpu/drm/i915/i915_request.c   |  65 +++---
  drivers/gpu/drm/i915/i915_request.h   |   3 +-
  drivers/gpu/drm/i915/i915_timeline.c  | 105 ++
  .../{i915_gem_timeline.h => i915_timeline.h}  |  67 +++---
  drivers/gpu/drm/i915/intel_engine_cs.c|  27 ++-
  drivers/gpu/drm/i915/intel_guc_submission.c   |   4 +-
  drivers/gpu/drm/i915/intel_lrc.c  |  48 +++--
  drivers/gpu/drm/i915/intel_ringbuffer.c   |  23 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  11 +-
  .../{i915_gem_timeline.c => i915_timeline.c}  |  94 +++--
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  32 ++-
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  11 +-
  .../gpu/drm/i915/selftests/mock_timeline.c|  45 ++--
  .../gpu/drm/i915/selftests/mock_timeline.h|  28 +--
  23 files changed, 389 insertions(+), 563 deletions(-)
  delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
  create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
  rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
  rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => 
i915_timeline.c} (70%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
- i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
  i915_query.o \
  i915_request.o \
+ i915_timeline.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 66123cf0eda3..89cb74c30a00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
  #include "i915_gem_fence_reg.h"
  #include "i915_gem_object.h"
  #include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
  #include "i915_gpu_error.h"
  #include "i915_request.h"
  #include "i915_scheduler.h"
+#include "i915_timeline.h"
  #include "i915_vma.h"
  
  #include "intel_gvt.h"

@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
  
-		struct i915_gem_timeline execution_timeline;

-   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head live_rings;
u32 active_requests;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1635975dbc16..f07556693cfe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
  
  	intel_engines_park(i915);

-   i915_gem_timelines_park(i915);
+   i915_timelines_park(i915);
  
  	i915_pmu_gt_parked(i915);
  
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs *engine)

 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 */
-   spin_lock_irqsave(>timeline->lock, flags);
-

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v6] intel-gpu-top: Rewrite the tool to be safe to use

2018-04-23 Thread Rinat Ibragimov

Ping?


>Понедельник,  9 апреля 2018, 15:26 +03:00 от Tvrtko Ursulin 
>:
>
>
>[Adding some people to Cc for more ack/nack type feedback.]
>
>Executive question is ack or nack on replacing intel_gpu_top with a new 
>implementation which uses only perf PMU for counter gathering.
>
>A short history on how this came to be:
>
>There was a recent external patch contribution from Rinat Ibragimov to 
>support more platforms from the existing intel_gpu_top. But as the tool 
>is not safe to use Chris Wilson suggested to maybe just replace it.
>
>As it happens I had a good start to do this quickly and cheaply, in the 
>form of one prototype I did recently, which only needed ripping some 
>bits out, and polishing the rest.
>
>Eero and Rinat kindly did a lot of platform coverage testing and the 
>rewrite seems ready for next steps.
>
>I need to stress that as the commit notes, the new tool has a slightly 
>different scope as that it doesn't expose GPU functional level data, but 
>only overall stats like power, frequencies, RC6, interrupts, IMC memory 
>bandwidth and per command streamer busyness, mi_semaphore and mi_event 
>waits. My thinking was that for more functional level profiling gpu-top 
>(OA) should be used.
>
>Also the "run a command" and CSV output features are not not supported 
>since both can be done directly via perf stat.
>
>Regards,
>
>Tvrtko
>
>On 04/04/2018 16:26, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin < tvrtko.ursu...@intel.com >
>> 
>> intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
>> register access. This patch rewrites it to use only PMU.
>> 
>> Only overall command streamer busyness and GPU global data such as power
>> and frequencies are included in this new version.
>> 
>> For access to more GPU functional unit level data, an OA metric based tool
>> like gpu-top should be used instead.
>> 
>> v2:
>>   * Sort engines by class and instance.
>>   * Do not wait for one sampling period to display something on screen.
>>   * Move code out of the asserts. (Rinat Ibragimov)
>>   * Continuously adapt to terminal size. (Rinat Ibragimov)
>> 
>> v3:
>>   * Change layout and precision of some field. (Chris Wilson)
>>   Eero Tamminen:
>>   * Use more user friendly engine names.
>>   * Don't error out if a counter is missing.
>>   * Add IMC read/write bandwidth.
>>   * Report minimum required kernel version.
>> 
>> v4:
>>   * Really support 4.16 by skipping of missing engines.
>>   * Simpler and less hacky float printing.
>>   * Preserve copyright header. (Antonio Argenziano)
>>   * Simplify engines_ptr macro. (Rinat Ibragimov)
>> 
>> v5:
>>   * Get RAPL unit from sysfs.
>>   * Consolidate sysfs paths with a macro.
>>   * Tidy error handling by carrying over and reporting errno.
>>   * Check against console height on all prints.
>>   * More readable minimum kernel version message. (Eero Tamminen)
>>   * Column banner for per engine stats. (Eero Tamminen)
>> 
>> v6:
>>   * Man page update. (Eero Tamminen)
>> 
>> Signed-off-by: Tvrtko Ursulin < tvrtko.ursu...@intel.com >
>> Cc: Chris Wilson < ch...@chris-wilson.co.uk >
>> Cc: Lionel Landwerlin < lionel.g.landwer...@intel.com >
>> Cc: Petri Latvala < petri.latv...@intel.com >
>> Cc: Eero Tamminen < eero.t.tammi...@intel.com >
>> Cc: Rinat Ibragimov < ibragimovri...@mail.ru >
>> Reviewed-by: Lionel Landwerlin < lionel.g.landwer...@intel.com > # v1
>> Reviewed-by: Chris Wilson < ch...@chris-wilson.co.uk > # v0.5
>> ---
>>   lib/igt_perf.c|6 +
>>   lib/igt_perf.h|1 +
>>   man/intel_gpu_top.rst |   41 +-
>>   tools/Makefile.am |2 +
>>   tools/intel_gpu_top.c | 1250 
>> +++--
>>   tools/meson.build |6 +-
>>   6 files changed, 719 insertions(+), 587 deletions(-)
>> 
>> diff --git a/lib/igt_perf.c b/lib/igt_perf.c
>> index 99d82ea51c9b..e3dec2cc29c7 100644
>> --- a/lib/igt_perf.c
>> +++ b/lib/igt_perf.c
>> @@ -69,3 +69,9 @@ int igt_perf_open(uint64_t type, uint64_t config)
>>   return _perf_open(type, config, -1,
>> PERF_FORMAT_TOTAL_TIME_ENABLED);
>>   }
>> +
>> +int igt_perf_open_group(uint64_t type, uint64_t config, int group)
>> +{
>> +return _perf_open(type, config, group,
>> +  PERF_FORMAT_TOTAL_TIME_ENABLED | PERF_FORMAT_GROUP);
>> +}
>> diff --git a/lib/igt_perf.h b/lib/igt_perf.h
>> index 614ea5d23fa6..e00718f4769a 100644
>> --- a/lib/igt_perf.h
>> +++ b/lib/igt_perf.h
>> @@ -55,5 +55,6 @@ uint64_t i915_type_id(void);
>>   int perf_i915_open(uint64_t config);
>>   int perf_i915_open_group(uint64_t config, int group);
>>   int igt_perf_open(uint64_t type, uint64_t config);
>> +int igt_perf_open_group(uint64_t type, uint64_t config, int group);
>> 
>>   #endif /* I915_PERF_H */
>> diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
>> index a5f7175bb1a0..19c712307d28 100644
>> --- a/man/intel_gpu_top.rst
>> +++ b/man/intel_gpu_top.rst
>> @@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
>>

[Intel-gfx] [CI 1/2] drm/i915: Use ktime on wait_for

2018-04-23 Thread Mika Kuoppala

We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.

We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.

v2: added bugzilla entry (Imre), added stable (Chris)

Reported-by: Imre Deak 
References: https://lkml.org/lkml/2018/4/18/798 [1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Cc: Imre Deak 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Cc: 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 44ed248f1fe9..33ff2638c92b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -49,12 +49,12 @@
  * check the condition before the timeout.
  */
 #define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
-   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
+   const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \
long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
int ret__;  \
might_sleep();  \
for (;;) {  \
-   bool expired__ = time_after(jiffies, timeout__);\
+   const bool expired__ = ktime_after(ktime_get_raw(), end__); \
OP; \
if (COND) { \
ret__ = 0;  \
-- 
2.14.1

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

[Intel-gfx] [CI 2/2] drm/i915: Add compiler barrier to wait_for

2018-04-23 Thread Mika Kuoppala

We need to be careful to not let compiler evaluate
the expiration and the operation on it's terms.

Document and enforce that COND will be evaluated
before checking timeout expiration.

Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_drv.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 33ff2638c92b..58868b93d2a0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -56,6 +56,8 @@
for (;;) {  \
const bool expired__ = ktime_after(ktime_get_raw(), end__); \
OP; \
+   /* Guarantee COND check prior to timeout */ \
+   barrier();  \
if (COND) { \
ret__ = 0;  \
break;  \
@@ -96,6 +98,8 @@
u64 now = local_clock(); \
if (!(ATOMIC)) \
preempt_enable(); \
+   /* Guarantee COND check prior to timeout */ \
+   barrier(); \
if (COND) { \
ret = 0; \
break; \
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:36, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-04-23 11:25:54)


On 23/04/2018 11:13, Chris Wilson wrote:

We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   drivers/gpu/drm/i915/i915_drv.h  | 2 +-
   drivers/gpu/drm/i915/i915_gem.c  | 3 ++-
   drivers/gpu/drm/i915/i915_request.c  | 6 +-
   drivers/gpu/drm/i915/i915_utils.h| 6 ++
   drivers/gpu/drm/i915/intel_ringbuffer.c  | 4 
   drivers/gpu/drm/i915/intel_ringbuffer.h  | 2 +-
   drivers/gpu/drm/i915/selftests/mock_engine.c | 4 
   drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
   8 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73936be90aed..a7787c2cb53c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,7 @@ struct drm_i915_private {
   
   struct i915_gem_timeline global_timeline;

   struct list_head timelines;
- struct list_head rings;
+ struct list_head live_rings;
   u32 active_requests;
   
   /**

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 906e2395c245..0097a77fae8d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
   {
   lockdep_assert_held(>drm.struct_mutex);
   GEM_BUG_ON(i915->gt.active_requests);
+ GEM_BUG_ON(!list_empty(>gt.live_rings));
   
   if (!i915->gt.awake)

   return I915_EPOCH_INVALID;
@@ -5600,7 +5601,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
   goto err_dependencies;
   
   mutex_lock(_priv->drm.struct_mutex);

- INIT_LIST_HEAD(_priv->gt.rings);
+ INIT_LIST_HEAD(_priv->gt.live_rings);
   INIT_LIST_HEAD(_priv->gt.timelines);
   err = i915_gem_timeline_init__global(dev_priv);
   mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0bf949ec9f1a..534b8d684cef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -316,6 +316,7 @@ static void advance_ring(struct i915_request *request)
* noops - they are safe to be replayed on a reset.
*/
   tail = READ_ONCE(request->tail);
+ list_del(>live);
   } else {
   tail = request->postfix;
   }
@@ -1046,6 +1047,8 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
   i915_gem_active_set(>last_request, request);
   
   list_add_tail(>ring_link, >request_list);

+ if (list_is_first(>ring_link, >request_list))
+ list_add(>live, >i915->gt.live_rings);


If you re-order the two list adds you could use list_empty and wouldn't
have to add list_is_first.


list_is_first tallies nicely with the list_is_last used before the
corresponding list_del.


Yes but to me that's minor, basically immaterial as argument whether or 
not to add our own list helper.





   request->emitted_jiffies = jiffies;
   
   /*

@@ -1375,7 +1378,8 @@ void i915_retire_requests(struct drm_i915_private *i915)
   if (!i915->gt.active_requests)
   return;
   
- list_for_each_entry_safe(ring, next, >gt.rings, link)

+ GEM_BUG_ON(list_empty(>gt.live_rings));


Maybe blank line here since the assert is not logically associated with
the list but with the !i915.active_requests?


I was thinking list when I wrote it. It's small enough we can argue both
and both be right.


Hm obviosuly it is not an error to call i915_retire_requests with 
nothing active (early return). So I even briefly wanted to suggest to 
make it 100% explicit and have the assert at the top of the function as:


GEM_BUG_ON(!!i915->gt.active_requests ^ !!list_empty(..));

Unless I messed it up, the idea is to check those two are always in the 
same state.







+ list_for_each_entry_safe(ring, next, >gt.live_rings, live)
   ring_retire_requests(ring);
   }
   
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h

index 0695717522ea..00165ad55fb3 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -120,6 +120,12 @@ static inline u64 ptr_to_u64(const void *ptr)
   
   #include 
   
+static inline int list_is_first(const struct list_head

[Intel-gfx] [PATCH] drm/i915: Remove src adjustment in intel_check_sprite_plane.

2018-04-23 Thread Maarten Lankhorst

The rounding can cause a perfectly normal 16x16 src to full-screen
dst to be rounded down, even without clipping involved. Because of
this we should just remove the adjustment, as no other driver or plane
does it.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index a1d048af0261..203ca8b362a5 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -996,11 +996,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
return vscale;
}
 
-   /* Make the source viewport size an exact multiple of the 
scaling factors. */
-   drm_rect_adjust_size(src,
-drm_rect_width(dst) * hscale - 
drm_rect_width(src),
-drm_rect_height(dst) * vscale - 
drm_rect_height(src));
-
drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
state->base.rotation);
 
-- 
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/6] drm/i915: Move timeline from GTT to ring

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:13, Chris Wilson wrote:

In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.

The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   | 13 +
  drivers/gpu/drm/i915/i915_gem.c   |  9 ++--
  drivers/gpu/drm/i915/i915_gem_context.c   | 15 +-
  drivers/gpu/drm/i915/i915_gem_context.h   |  2 +
  drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 --
  drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 -
  drivers/gpu/drm/i915/i915_gem_timeline.c  | 54 +--
  drivers/gpu/drm/i915/i915_gem_timeline.h  |  4 ++
  drivers/gpu/drm/i915/i915_request.c   | 15 +++---
  drivers/gpu/drm/i915/intel_engine_cs.c|  3 +-
  drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c   |  9 +++-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  5 +-
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 +-
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  4 +-
  drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 -
  16 files changed, 101 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7787c2cb53c..66123cf0eda3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,7 +2058,8 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
  
-		struct i915_gem_timeline global_timeline;

+   struct i915_gem_timeline execution_timeline;
+   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head live_rings;
u32 active_requests;
@@ -3232,16 +3233,6 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
  }
  
-static inline struct intel_timeline *

-i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
-{
-   struct i915_address_space *vm;
-
-   vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
-   return >timeline.engine[engine->id];
-}
-
  int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
  int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0097a77fae8d..1635975dbc16 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request 
*request)
  {
struct intel_engine_cs *engine = request->engine;
struct i915_gem_context *hung_ctx = request->ctx;
-   struct intel_timeline *timeline;
+   struct intel_timeline *timeline = request->timeline;
unsigned long flags;
  
-	timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);

+   GEM_BUG_ON(timeline == engine->timeline);


Isn't this the guilty request, so would be on the engine timeline?

  
  	spin_lock_irqsave(>timeline->lock, flags);

spin_lock(>lock);
@@ -3782,7 +3782,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915, 
unsigned int flags)
  
  		ret = wait_for_engines(i915);

} else {
-   ret = wait_for_timeline(>gt.global_timeline, flags);
+   ret = wait_for_timeline(>gt.execution_timeline, flags);
}
  
  	return ret;

@@ -5651,7 +5651,8 @@ void i915_gem_cleanup_early(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->mm.object_count);
  
  	mutex_lock(_priv->drm.struct_mutex);

-   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   i915_gem_timeline_fini(_priv->gt.legacy_timeline);
+   i915_gem_timeline_fini(_priv->gt.execution_timeline);
WARN_ON(!list_empty(_priv->gt.timelines));
mutex_unlock(_priv->drm.struct_mutex);
  
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

2018-04-23 Thread Chris Wilson

Quoting Tvrtko Ursulin (2018-04-23 11:25:54)
> 
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We don't need to track every ring for its lifetime as they are managed
> > by the contexts/engines. What we do want to track are the live rings so
> > that we can sporadically clean up requests if userspace falls behind. We
> > can simply restrict the gt->rings list to being only gt->live_rings.
> > 
> > Suggested-by: Tvrtko Ursulin 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h  | 2 +-
> >   drivers/gpu/drm/i915/i915_gem.c  | 3 ++-
> >   drivers/gpu/drm/i915/i915_request.c  | 6 +-
> >   drivers/gpu/drm/i915/i915_utils.h| 6 ++
> >   drivers/gpu/drm/i915/intel_ringbuffer.c  | 4 
> >   drivers/gpu/drm/i915/intel_ringbuffer.h  | 2 +-
> >   drivers/gpu/drm/i915/selftests/mock_engine.c | 4 
> >   drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> >   8 files changed, 16 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 73936be90aed..a7787c2cb53c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2060,7 +2060,7 @@ struct drm_i915_private {
> >   
> >   struct i915_gem_timeline global_timeline;
> >   struct list_head timelines;
> > - struct list_head rings;
> > + struct list_head live_rings;
> >   u32 active_requests;
> >   
> >   /**
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 906e2395c245..0097a77fae8d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private 
> > *i915)
> >   {
> >   lockdep_assert_held(>drm.struct_mutex);
> >   GEM_BUG_ON(i915->gt.active_requests);
> > + GEM_BUG_ON(!list_empty(>gt.live_rings));
> >   
> >   if (!i915->gt.awake)
> >   return I915_EPOCH_INVALID;
> > @@ -5600,7 +5601,7 @@ int i915_gem_init_early(struct drm_i915_private 
> > *dev_priv)
> >   goto err_dependencies;
> >   
> >   mutex_lock(_priv->drm.struct_mutex);
> > - INIT_LIST_HEAD(_priv->gt.rings);
> > + INIT_LIST_HEAD(_priv->gt.live_rings);
> >   INIT_LIST_HEAD(_priv->gt.timelines);
> >   err = i915_gem_timeline_init__global(dev_priv);
> >   mutex_unlock(_priv->drm.struct_mutex);
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 0bf949ec9f1a..534b8d684cef 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -316,6 +316,7 @@ static void advance_ring(struct i915_request *request)
> >* noops - they are safe to be replayed on a reset.
> >*/
> >   tail = READ_ONCE(request->tail);
> > + list_del(>live);
> >   } else {
> >   tail = request->postfix;
> >   }
> > @@ -1046,6 +1047,8 @@ void __i915_request_add(struct i915_request *request, 
> > bool flush_caches)
> >   i915_gem_active_set(>last_request, request);
> >   
> >   list_add_tail(>ring_link, >request_list);
> > + if (list_is_first(>ring_link, >request_list))
> > + list_add(>live, >i915->gt.live_rings);
> 
> If you re-order the two list adds you could use list_empty and wouldn't 
> have to add list_is_first.

list_is_first tallies nicely with the list_is_last used before the
corresponding list_del.

> 
> >   request->emitted_jiffies = jiffies;
> >   
> >   /*
> > @@ -1375,7 +1378,8 @@ void i915_retire_requests(struct drm_i915_private 
> > *i915)
> >   if (!i915->gt.active_requests)
> >   return;
> >   
> > - list_for_each_entry_safe(ring, next, >gt.rings, link)
> > + GEM_BUG_ON(list_empty(>gt.live_rings));
> 
> Maybe blank line here since the assert is not logically associated with 
> the list but with the !i915.active_requests?

I was thinking list when I wrote it. It's small enough we can argue both
and both be right.

> 
> > + list_for_each_entry_safe(ring, next, >gt.live_rings, live)
> >   ring_retire_requests(ring);
> >   }
> >   
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h 
> > b/drivers/gpu/drm/i915/i915_utils.h
> > index 0695717522ea..00165ad55fb3 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > @@ -120,6 +120,12 @@ static inline u64 ptr_to_u64(const void *ptr)
> >   
> >   #include 
> >   
> > +static inline int list_is_first(const struct list_head *list,
> > + const struct list_head *head)
> 
> Return bool if you decide you prefer to keep list_is_first?

Copy'n'paste from

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:13, Chris Wilson wrote:

We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h  | 2 +-
  drivers/gpu/drm/i915/i915_gem.c  | 3 ++-
  drivers/gpu/drm/i915/i915_request.c  | 6 +-
  drivers/gpu/drm/i915/i915_utils.h| 6 ++
  drivers/gpu/drm/i915/intel_ringbuffer.c  | 4 
  drivers/gpu/drm/i915/intel_ringbuffer.h  | 2 +-
  drivers/gpu/drm/i915/selftests/mock_engine.c | 4 
  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
  8 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73936be90aed..a7787c2cb53c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,7 @@ struct drm_i915_private {
  
  		struct i915_gem_timeline global_timeline;

struct list_head timelines;
-   struct list_head rings;
+   struct list_head live_rings;
u32 active_requests;
  
  		/**

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 906e2395c245..0097a77fae8d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
  {
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
+   GEM_BUG_ON(!list_empty(>gt.live_rings));
  
  	if (!i915->gt.awake)

return I915_EPOCH_INVALID;
@@ -5600,7 +5601,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
  
  	mutex_lock(_priv->drm.struct_mutex);

-   INIT_LIST_HEAD(_priv->gt.rings);
+   INIT_LIST_HEAD(_priv->gt.live_rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0bf949ec9f1a..534b8d684cef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -316,6 +316,7 @@ static void advance_ring(struct i915_request *request)
 * noops - they are safe to be replayed on a reset.
 */
tail = READ_ONCE(request->tail);
+   list_del(>live);
} else {
tail = request->postfix;
}
@@ -1046,6 +1047,8 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
i915_gem_active_set(>last_request, request);
  
  	list_add_tail(>ring_link, >request_list);

+   if (list_is_first(>ring_link, >request_list))
+   list_add(>live, >i915->gt.live_rings);


If you re-order the two list adds you could use list_empty and wouldn't 
have to add list_is_first.



request->emitted_jiffies = jiffies;
  
  	/*

@@ -1375,7 +1378,8 @@ void i915_retire_requests(struct drm_i915_private *i915)
if (!i915->gt.active_requests)
return;
  
-	list_for_each_entry_safe(ring, next, >gt.rings, link)

+   GEM_BUG_ON(list_empty(>gt.live_rings));


Maybe blank line here since the assert is not logically associated with 
the list but with the !i915.active_requests?



+   list_for_each_entry_safe(ring, next, >gt.live_rings, live)
ring_retire_requests(ring);
  }
  
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h

index 0695717522ea..00165ad55fb3 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -120,6 +120,12 @@ static inline u64 ptr_to_u64(const void *ptr)
  
  #include 
  
+static inline int list_is_first(const struct list_head *list,

+   const struct list_head *head)


Return bool if you decide you prefer to keep list_is_first?


+{
+   return head->next == list;
+}
+
  static inline void __list_del_many(struct list_head *head,
   struct list_head *first)
  {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 792a2ca95872..3453e7426f6b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1150,8 +1150,6 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
}
ring->vma = vma;
  
-	list_add(>link, >i915->gt.rings);

-
return ring;
  }
  
@@ -1163,8 +1161,6 @@ intel_ring_free(struct

Re: [Intel-gfx] [PULL] gvt-next for 4.18

2018-04-23 Thread Jani Nikula

On Mon, 23 Apr 2018, Zhi Wang  wrote:
> Hi Jani:
>
> I picked out the patch which causes conflicts and may put it back in the 
> next back merge from drm-intel-next to gvt-next. So there shouldn't be 
> any conflict in this pull. Thanks for your efforts.

Thanks, pulled to drm-intel-next-queued.

Just as a reminder, if you have more stuff for v4.18 the deadline is in
about three weeks.

BR,
Jani.


>
> Thanks,
> Zhi.
>
> On 04/23/18 16:11, Zhi Wang wrote:
>> The following changes since commit 
>> fadec6eefe232696c5c471b40df33e6db616e854:
>> 
>>drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)
>> 
>> are available in the git repository at:
>> 
>>https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-23
>> 
>> for you to fetch changes up to 3eda0d22ead04f81ea59c9584bcbf5b496745e92:
>> 
>>drm/i915/gvt: Mark expected switch fall-through in 
>> handle_g2v_notification (2018-04-23 13:09:36 +0800)
>> 
>> 
>> - Minor condition check improvment (Gustavo A. R. Silva)
>> - Non-priviliged batch buffer scan (Yan Zhao)
>> - Scheduling optimizations (Zhipeng Gong)
>> 
>> 
>> Gustavo A. R. Silva (2):
>>drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
>>drm/i915/gvt: Mark expected switch fall-through in 
>> handle_g2v_notification
>> 
>> Zhao Yan (1):
>>drm/i915/gvt: scan non-privileged batch buffer for debug purpose
>> 
>> Zhipeng Gong (2):
>>drm/i915/gvt: Use real time to do timer check
>>drm/i915/gvt: Update time slice more frequently
>> 
>>   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 ---
>>   drivers/gpu/drm/i915/gvt/debugfs.c  | 67 
>> +
>>   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
>>   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
>>   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
>>   drivers/gpu/drm/i915/gvt/scheduler.c| 66 
>> +---
>>   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
>>   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
>>   8 files changed, 193 insertions(+), 53 deletions(-)
>> 

-- 
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 2/6] drm/i915: Retire requests along rings

2018-04-23 Thread Tvrtko Ursulin



On 23/04/2018 11:13, Chris Wilson wrote:

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |  3 +-
  drivers/gpu/drm/i915/i915_gem.c   |  1 +
  drivers/gpu/drm/i915/i915_request.c   | 43 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c   |  5 +++
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  1 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  | 27 +---
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  2 +
  7 files changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..73936be90aed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
  
-		struct list_head timelines;

struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
  
  		/**

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
  
  	mutex_lock(_priv->drm.struct_mutex);

+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1437538d5bfa..0bf949ec9f1a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -292,6 +292,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
  
  static void advance_ring(struct i915_request *request)

  {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
  
  	/*

@@ -303,7 +304,9 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(request != list_first_entry(>request_list,
+  typeof(*request), ring_link));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -318,7 +321,7 @@ static void advance_ring(struct i915_request *request)
}
list_del(>ring_link);
  
-	request->ring->head = tail;

+   ring->head = tail;
  }
  
  static void free_capture_list(struct i915_request *request)

@@ -424,18 +427,18 @@ static void i915_request_retire(struct i915_request 
*request)
  
  void i915_request_retire_upto(struct i915_request *rq)

  {
-   struct intel_engine_cs *engine = rq->engine;
+   struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
  
  	lockdep_assert_held(>i915->drm.struct_mutex);

GEM_BUG_ON(!i915_request_completed(rq));
  
-	if (list_empty(>link))

+   if (list_empty(>ring_link))
return;
  
  	do {

-   tmp = list_first_entry(>timeline->requests,
-  typeof(*tmp), link);
+   tmp = list_first_entry(>request_list,
+  typeof(*tmp), ring_link);
  
  		i915_request_retire(tmp);

} while (tmp != rq);
@@ -644,9 +647,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
if (ret)
goto err_unreserve;
  
-	/* Move the oldest request to the slab-cache (if not in use!) */

-   rq = list_first_entry_or_null(>timeline->requests,
-

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

2018-04-23 Thread Jani Nikula

On Mon, 23 Apr 2018, "Nautiyal, Ankit K"  wrote:
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
>> On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
>>> From: Ankit Nautiyal 
>>> +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;
>> Odd line split here. Makes this a bit hard to read.
>> I would split after the ||
>
> Agreed. I wasn't sure how to let it have better readability and less
> than 80 char length at the same time. Will fix this.

80 chars is not a strict requirement. Readability is. ;)

BR,
Jani.

-- 
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 v11 09/11] drm: Expose modes with aspect ratio, only if requested

2018-04-23 Thread Ville Syrjälä

On Mon, Apr 23, 2018 at 11:19:08AM +0530, Nautiyal, Ankit K wrote:
> 
> 
> On 4/20/2018 7:52 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote:
> >> 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, regardless 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. However if such a mode is unique in the list, it is
> >> kept in the list, with aspect-ratio flags reset.
> >>
> >> 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
> >> V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
> >>   logic to correctly identify and prune modes with aspect-ratio,
> >>   if aspect-ratio cap is not set.
> >> ---
> >>   drivers/gpu/drm/drm_connector.c | 56 
> >> +++--
> >>   1 file changed, 48 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c 
> >> b/drivers/gpu/drm/drm_connector.c
> >> index b3cde89..865ee354 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1531,15 +1531,35 @@ 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 *modelist,
> >> +   const struct drm_file *file_priv)
> >>   {
> >>/*
> >> * If user-space hasn't configured the driver to expose the stereo 3D
> >> * modes, don't expose them.
> >> */
> >> +  struct drm_display_mode *mode_itr;
> >> +
> >>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. However if such a mode
> >> +   * is unique, let it be exposed, but reset the aspect-ratio flags
> >> +   * while preparing the list of user-modes.
> >> +   */
> >> +  if (!file_priv->aspect_ratio_allowed &&
> >> +  mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
> >> +  list_for_each_entry(mode_itr, >head, head)
> >> +  if (drm_mode_match(mode_itr, mode,
> >> + DRM_MODE_MATCH_TIMINGS |
> >> + DRM_MODE_MATCH_CLOCK |
> >> + DRM_MODE_MATCH_FLAGS |
> >> + DRM_MODE_MATCH_3D_FLAGS))
> >> +  return false;
> >> +  }
> >>   
> >>return true;
> >>   }
> >> @@ -1550,7 +1570,7 @@ int drm_mode_getconnector(struct drm_device *dev, 
> >> void *data,
> >>struct drm_mode_get_connector *out_resp = data;
> >>struct drm_connector *connector;
> >>struct drm_encoder *encoder;
> >> -  struct drm_display_mode *mode;
> >> +  struct drm_display_mode *mode, *tmp, modelist;
> >>int mode_count = 0;
> >>int encoders_count = 0;
> >>int ret = 0;
> >> @@ -1605,23 +1625,37 @@ int drm_mode_getconnector(struct drm_device *dev, 
> >> void *data,
> >>out_resp->subpixel = connector->display_info.subpixel_order;
> >>out_resp->connection = connector->status;
> >>   
> >> +  INIT_LIST_HEAD();
> > Why are we using a struct drm_display_mode to get a simple list_head?
> 
> Yes you are right, we can use the simple list_head here. I was trying to 
> use modelist as first mode, and goofed up.
> Its a mistake, I will correct it in next patchset.
> 
> >
> >> +
> >>/* delayed so

[Intel-gfx] [PATCH 4/6] drm/i915: Move timeline from GTT to ring

2018-04-23 Thread Chris Wilson

In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.

The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   | 13 +
 drivers/gpu/drm/i915/i915_gem.c   |  9 ++--
 drivers/gpu/drm/i915/i915_gem_context.c   | 15 +-
 drivers/gpu/drm/i915/i915_gem_context.h   |  2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 --
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 -
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 54 +--
 drivers/gpu/drm/i915/i915_gem_timeline.h  |  4 ++
 drivers/gpu/drm/i915/i915_request.c   | 15 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  3 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  9 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  5 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 -
 16 files changed, 101 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7787c2cb53c..66123cf0eda3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,7 +2058,8 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline global_timeline;
+   struct i915_gem_timeline execution_timeline;
+   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head live_rings;
u32 active_requests;
@@ -3232,16 +3233,6 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
-static inline struct intel_timeline *
-i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
-{
-   struct i915_address_space *vm;
-
-   vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
-   return >timeline.engine[engine->id];
-}
-
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0097a77fae8d..1635975dbc16 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request 
*request)
 {
struct intel_engine_cs *engine = request->engine;
struct i915_gem_context *hung_ctx = request->ctx;
-   struct intel_timeline *timeline;
+   struct intel_timeline *timeline = request->timeline;
unsigned long flags;
 
-   timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
+   GEM_BUG_ON(timeline == engine->timeline);
 
spin_lock_irqsave(>timeline->lock, flags);
spin_lock(>lock);
@@ -3782,7 +3782,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915, 
unsigned int flags)
 
ret = wait_for_engines(i915);
} else {
-   ret = wait_for_timeline(>gt.global_timeline, flags);
+   ret = wait_for_timeline(>gt.execution_timeline, flags);
}
 
return ret;
@@ -5651,7 +5651,8 @@ void i915_gem_cleanup_early(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->mm.object_count);
 
mutex_lock(_priv->drm.struct_mutex);
-   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   i915_gem_timeline_fini(_priv->gt.legacy_timeline);
+   i915_gem_timeline_fini(_priv->gt.execution_timeline);
WARN_ON(!list_empty(_priv->gt.timelines));
mutex_unlock(_priv->drm.struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74435affe23f..58b185abe652 100644
---

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Retire requests along rings

2018-04-23 Thread Tvrtko Ursulin




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

Quoting Tvrtko Ursulin (2018-04-23 09:47:57)


On 20/04/2018 14:20, Chris Wilson wrote:

   void i915_retire_requests(struct drm_i915_private *i915)
   {
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
+ struct intel_ring *ring, *next;
   
   lockdep_assert_held(>drm.struct_mutex);
   
   if (!i915->gt.active_requests)

   return;
   
- for_each_engine(engine, i915, id)

- engine_retire_requests(engine);
+ list_for_each_entry_safe(ring, next, >gt.rings, link)
+ ring_retire_requests(ring);


[Continuing from previous discussion on try-bot.]

I had a thought that this could be managed more efficiently in a very
simple manner.

We rename timeline->inflight_seqnos to something like live_requests and
manage this per ctx timeline, from request_add to request_retire. At the
same time we only have ring->ring_link be linked to
i915->gt.(live_)rings while the ctx timeline live_requests count is
greater than zero. In other words list_add on 0->1, list_del on 1->0.

This way the retire path does not have to walk all known rings, but only
all rings with live (unretired) reqeusts.

What do you think?


I wouldn't resurrect inflight_seqnos for this, we can simply use
list_empty(ring->request_list). Slight icky feeling every time we do
anything under struct_mutex, but by this point I itch all over.


Right, that's even simpler.


Seems like a small enough patch to try after. I think I class it as an
optimisation, so would like to get the bigger change in engine to ring
soaking first.


Ok, as you wish.

Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH 3/6] drm/i915: Only track live rings for retiring

2018-04-23 Thread Chris Wilson

We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_gem.c  | 3 ++-
 drivers/gpu/drm/i915/i915_request.c  | 6 +-
 drivers/gpu/drm/i915/i915_utils.h| 6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 4 
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 2 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c | 4 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 8 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 73936be90aed..a7787c2cb53c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,7 @@ struct drm_i915_private {
 
struct i915_gem_timeline global_timeline;
struct list_head timelines;
-   struct list_head rings;
+   struct list_head live_rings;
u32 active_requests;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 906e2395c245..0097a77fae8d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
 {
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
+   GEM_BUG_ON(!list_empty(>gt.live_rings));
 
if (!i915->gt.awake)
return I915_EPOCH_INVALID;
@@ -5600,7 +5601,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
-   INIT_LIST_HEAD(_priv->gt.rings);
+   INIT_LIST_HEAD(_priv->gt.live_rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 0bf949ec9f1a..534b8d684cef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -316,6 +316,7 @@ static void advance_ring(struct i915_request *request)
 * noops - they are safe to be replayed on a reset.
 */
tail = READ_ONCE(request->tail);
+   list_del(>live);
} else {
tail = request->postfix;
}
@@ -1046,6 +1047,8 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
i915_gem_active_set(>last_request, request);
 
list_add_tail(>ring_link, >request_list);
+   if (list_is_first(>ring_link, >request_list))
+   list_add(>live, >i915->gt.live_rings);
request->emitted_jiffies = jiffies;
 
/*
@@ -1375,7 +1378,8 @@ void i915_retire_requests(struct drm_i915_private *i915)
if (!i915->gt.active_requests)
return;
 
-   list_for_each_entry_safe(ring, next, >gt.rings, link)
+   GEM_BUG_ON(list_empty(>gt.live_rings));
+   list_for_each_entry_safe(ring, next, >gt.live_rings, live)
ring_retire_requests(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 0695717522ea..00165ad55fb3 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -120,6 +120,12 @@ static inline u64 ptr_to_u64(const void *ptr)
 
 #include 
 
+static inline int list_is_first(const struct list_head *list,
+   const struct list_head *head)
+{
+   return head->next == list;
+}
+
 static inline void __list_del_many(struct list_head *head,
   struct list_head *first)
 {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 792a2ca95872..3453e7426f6b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1150,8 +1150,6 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
}
ring->vma = vma;
 
-   list_add(>link, >i915->gt.rings);
-
return ring;
 }
 
@@ -1163,8 +1161,6 @@ intel_ring_free(struct intel_ring *ring)
i915_vma_close(ring->vma);
__i915_gem_object_release_unless_active(obj);
 
-   list_del(>link);
-
kfree(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d816f8dea245..fd5a6363ab1d 100644
---

[Intel-gfx] [PATCH 5/6] drm/i915: Split i915_gem_timeline into individual timelines

2018-04-23 Thread Chris Wilson

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 117 +--
 drivers/gpu/drm/i915/i915_gem_context.c   |  49 ++---
 drivers/gpu/drm/i915/i915_gem_context.h   |   2 -
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 198 --
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_perf.c  |  10 +-
 drivers/gpu/drm/i915/i915_request.c   |  65 +++---
 drivers/gpu/drm/i915/i915_request.h   |   3 +-
 drivers/gpu/drm/i915/i915_timeline.c  | 105 ++
 .../{i915_gem_timeline.h => i915_timeline.h}  |  67 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  27 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c   |   4 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  48 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  23 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  11 +-
 .../{i915_gem_timeline.c => i915_timeline.c}  |  94 +++--
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  32 ++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  11 +-
 .../gpu/drm/i915/selftests/mock_timeline.c|  45 ++--
 .../gpu/drm/i915/selftests/mock_timeline.h|  28 +--
 23 files changed, 389 insertions(+), 563 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
 rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
 rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => i915_timeline.c} 
(70%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
- i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
  i915_query.o \
  i915_request.o \
+ i915_timeline.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 66123cf0eda3..89cb74c30a00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
 #include "i915_gem_fence_reg.h"
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
 #include "i915_gpu_error.h"
 #include "i915_request.h"
 #include "i915_scheduler.h"
+#include "i915_timeline.h"
 #include "i915_vma.h"
 
 #include "intel_gvt.h"
@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline execution_timeline;
-   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head live_rings;
u32 active_requests;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1635975dbc16..f07556693cfe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
 
intel_engines_park(i915);
-   i915_gem_timelines_park(i915);
+   i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
 
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 */
-   spin_lock_irqsave(>timeline->lock, flags);
-   list_for_each_entry(request, >timeline->requests, link) {
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
 
@@ -2989,7 +2989,7 @@

[Intel-gfx] [PATCH 6/6] drm/i915: Lazily unbind vma on close

2018-04-23 Thread Chris Wilson

When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.

However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.

If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.

In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  5 +++
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 14 ---
 drivers/gpu/drm/i915/i915_vma.c   | 39 ---
 drivers/gpu/drm/i915/i915_vma.h   |  5 +++
 drivers/gpu/drm/i915/selftests/huge_pages.c   |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 8 files changed, 51 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89cb74c30a00..b2f78da9bc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,6 +2060,7 @@ struct drm_i915_private {
 
struct list_head timelines;
struct list_head live_rings;
+   struct list_head closed_vma;
u32 active_requests;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f07556693cfe..4fb7d45b5b5d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -165,6 +165,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
+   i915_vma_parked(i915);
 
i915->gt.awake = false;
 
@@ -4792,7 +4793,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
 >vma_list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
-   i915_vma_close(vma);
+   __i915_vma_final_close(vma);
}
GEM_BUG_ON(!list_empty(>vma_list));
GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
@@ -5595,6 +5596,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
 
INIT_LIST_HEAD(_priv->gt.live_rings);
INIT_LIST_HEAD(_priv->gt.timelines);
+   INIT_LIST_HEAD(_priv->gt.closed_vma);
 
i915_gem_init__mm(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c74f5df3fb5a..e5b8371e30de 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -768,6 +768,11 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
lut->ctx = eb->ctx;
lut->handle = handle;
 
+   if (vma->flags & I915_VMA_CLOSED) {
+   vma->flags &= ~I915_VMA_CLOSED;
+   list_del(>closed_link);
+   }
+
 add_vma:
err = eb_add_vma(eb, i, vma);
if (unlikely(err))
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e9d828324f67..c1587d83fd19 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2218,6 +2218,12 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
 }
 
 void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   GEM_BUG_ON(vm->closed);
+   vm->closed = true;
+}
+
+static void ppgtt_close_vma(struct i915_address_space *vm)
 {
struct list_head *phases[] = {
>active_list,
@@ -2226,15 +2232,12 @@ void i915_ppgtt_close(struct i915_address_space *vm)
NULL,
}, **phase;
 
-   GEM_BUG_ON(vm->closed);
vm->closed = true;
-
for (phase = phases; *phase; phase++) {
struct i915_vma *vma, *vn;
 
list_for_each_entry_safe(vma, vn, *phase, vm_link)
-   if (!i915_vma_is_closed(vma))
-   i915_vma_close(vma);

[Intel-gfx] [PATCH 1/6] drm/i915: Stop tracking timeline->inflight_seqnos

2018-04-23 Thread Chris Wilson

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to preserve the semantics that no engine wraps in the
middle of a submit. (Although this semantic is now only required for gen7
semaphore support, which only supports greater-then comparisons!)

References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++---
 drivers/gpu/drm/i915/i915_gem_timeline.h |  6 --
 drivers/gpu/drm/i915/i915_request.c  | 12 +++-
 drivers/gpu/drm/i915/intel_engine_cs.c   |  5 ++---
 4 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..547e97102b85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1340,10 +1340,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
struct rb_node *rb;
 
seq_printf(m, "%s:\n", engine->name);
-   seq_printf(m, "\tseqno = %x [current %x, last %x], inflight 
%d\n",
+   seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
   engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
-  engine->timeline->inflight_seqnos);
+  intel_engine_last_submit(engine));
seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled? 
%s\n",
   yesno(intel_engine_has_waiter(engine)),
   yesno(test_bit(engine->id,
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h 
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index 33e01bf6aa36..6e82119e2cd8 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -37,12 +37,6 @@ struct intel_timeline {
u64 fence_context;
u32 seqno;
 
-   /**
-* Count of outstanding requests, from the time they are constructed
-* to the moment they are retired. Loosely coupled to hardware.
-*/
-   u32 inflight_seqnos;
-
spinlock_t lock;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index b692a9f7c357..1437538d5bfa 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -260,17 +260,14 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32 
seqno)
 static int reserve_engine(struct intel_engine_cs *engine)
 {
struct drm_i915_private *i915 = engine->i915;
-   u32 active = ++engine->timeline->inflight_seqnos;
-   u32 seqno = engine->timeline->seqno;
int ret;
 
/* Reservation is fine until we need to wrap around */
-   if (unlikely(add_overflows(seqno, active))) {
+   if (unlikely(add_overflows(engine->timeline->seqno,
+  i915->gt.active_requests + 1))) {
ret = reset_all_global_seqno(i915, 0);
-   if (ret) {
-   engine->timeline->inflight_seqnos--;
+   if (ret)
return ret;
-   }
}
 
if (!i915->gt.active_requests++)
@@ -285,9 +282,6 @@ static void unreserve_engine(struct intel_engine_cs *engine)
 
if (!--i915->gt.active_requests)
i915_gem_park(i915);
-
-   GEM_BUG_ON(!engine->timeline->inflight_seqnos);
-   engine->timeline->inflight_seqnos--;
 }
 
 void i915_gem_retire_noop(struct i915_gem_active *active,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index be608f7111f5..a55a849b81b6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1318,12 +1318,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms]\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
   engine->hangcheck.seqno,
-  jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
-  engine->timeline->inflight_seqnos);
+  jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp));
drm_printf(m, "\tReset count: %d (global %d)\n",

[Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

2018-04-23 Thread Chris Wilson

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 +-
 drivers/gpu/drm/i915/i915_gem.c   |  1 +
 drivers/gpu/drm/i915/i915_request.c   | 43 ---
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  5 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  1 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  | 27 +---
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  2 +
 7 files changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..73936be90aed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct list_head timelines;
struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1437538d5bfa..0bf949ec9f1a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -292,6 +292,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
 
 static void advance_ring(struct i915_request *request)
 {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
 
/*
@@ -303,7 +304,9 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(request != list_first_entry(>request_list,
+  typeof(*request), ring_link));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -318,7 +321,7 @@ static void advance_ring(struct i915_request *request)
}
list_del(>ring_link);
 
-   request->ring->head = tail;
+   ring->head = tail;
 }
 
 static void free_capture_list(struct i915_request *request)
@@ -424,18 +427,18 @@ static void i915_request_retire(struct i915_request 
*request)
 
 void i915_request_retire_upto(struct i915_request *rq)
 {
-   struct intel_engine_cs *engine = rq->engine;
+   struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
 
-   if (list_empty(>link))
+   if (list_empty(>ring_link))
return;
 
do {
-   tmp = list_first_entry(>timeline->requests,
-  typeof(*tmp), link);
+   tmp = list_first_entry(>request_list,
+  typeof(*tmp), ring_link);
 
i915_request_retire(tmp);
} while (tmp != rq);
@@ -644,9 +647,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
if (ret)
goto err_unreserve;
 
-   /* Move the oldest request to the slab-cache (if not in use!) */
-   rq = list_first_entry_or_null(>timeline->requests,
-

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

2018-04-23 Thread Ville Syrjälä

On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:
> 
> 
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
> >> 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;
> > Odd line split here. Makes this a bit hard to read.
> > I would split after the ||
> 
> Agreed. I wasn't sure how to let it have better readability and less 
> than 80 char length
> at the same time. Will fix this.
> 
> >
> >> +}
> >> +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
> > Do we actually need to export these? I don't think so.
> >
> > But I might be wrong. It's a bit hard to see with the way
> > you split this patch with the actual users in a different patch.
> 
> These helper functions are used in drm_mode_atomic.c, drm_mode_crtc.c, 
> and drm_mode_get_connector.c
> The patches are split as to have modes-set handling separate and the 
> exposing of connector separate.
> Do you suggest this patch to be merged with the patch for handling 
> aspect-ratio in modeset?

Usually if you add a function you should do it in the same patch where
you add the user(s) for said function. Otherwise it's impossibly to
judge whether the new function is any good.

> 
> >> +
> >> +/**
> >> + * 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
> 

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list

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

2018-04-23 Thread Ville Syrjälä

On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> 
> 
> On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> >> 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.
> >> +   */
> > Bogus indentation.
> 
> Thanks to point that out, will fix this.
> 
> > Also where's the aspect_ratio_allowed handling for the atomic cap?
> > Or did we decide against it after all?
> 
> As discussed, aspect ratio is handled in the atomic modeset path, where 
> in the modeset requests with aspect-ratios
> are rejected, if the aspect-ratio cap not set.

That is not what we discussed on irc. What Daniel was suggesting is
always enabling the aspect ratio cap for atomic clients, just as we
already enable the univerals planes cap for atomic clients.

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

1 2 >

1 - 100 of 121 matches

Mail list logo