Re: [Intel-gfx] [PATCH 4/4] drm/i915/tgl: Report valid VDBoxes with SFC capability

2019-07-30 Thread Tvrtko Ursulin


On 31/07/2019 01:49, Daniele Ceraolo Spurio wrote:

From: Michel Thierry 

In Gen11, only even numbered "logical" VDBoxes are hooked up to a SFC
(Scaler & Format Converter) unit. This is not the case in Tigerlake,
where each VDBox can access a SFC.

We will use this information to decide when the SFC units need to be reset
and also pass it to the GuC.

Bspec: 48077
Signed-off-by: Michel Thierry 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Lucas De Marchi 
Cc: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index f99c9fd497b2..2a39b52c3582 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -1022,8 +1022,9 @@ void intel_device_info_init_mmio(struct drm_i915_private 
*dev_priv)
/*
 * In Gen11, only even numbered logical VDBOXes are
 * hooked up to an SFC (Scaler & Format Converter) unit.
+* In TGL each VDBOX has access to an SFC.
 */
-   if (logical_vdbox++ % 2 == 0)
+   if (IS_TIGERLAKE(dev_priv) || logical_vdbox++ % 2 == 0)
RUNTIME_INFO(dev_priv)->vdbox_sfc_access |= BIT(i);
}
DRM_DEBUG_DRIVER("vdbox enable: %04x, instances: %04lx\n",



Reviewed-by: Tvrtko Ursulin 

Only uncertainty is if we want to code the condition as Icelake 
exception instead for more future proofing. Like if "!IS_ICELAKE ||" 
instead of "IS_TIGERLAKE ||"?


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Pass intel_context to igt_spinner

2019-07-30 Thread Tvrtko Ursulin


On 30/07/2019 16:48, Chris Wilson wrote:

Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.

Signed-off-by: Chris Wilson 
---
  .../drm/i915/gem/selftests/i915_gem_context.c |  43 +++
  drivers/gpu/drm/i915/gt/selftest_lrc.c| 115 ++
  .../gpu/drm/i915/gt/selftest_workarounds.c|  23 +++-
  drivers/gpu/drm/i915/selftests/igt_spinner.c  |  32 +++--
  drivers/gpu/drm/i915/selftests/igt_spinner.h  |   6 +-
  5 files changed, 119 insertions(+), 100 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 7f9f6701b32c..c24430352a38 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -821,8 +821,7 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
  #define TEST_RESETBIT(2)
  
  static int

-__sseu_prepare(struct drm_i915_private *i915,
-  const char *name,
+__sseu_prepare(const char *name,
   unsigned int flags,
   struct intel_context *ce,
   struct igt_spinner **spin)
@@ -838,14 +837,11 @@ __sseu_prepare(struct drm_i915_private *i915,
if (!*spin)
return -ENOMEM;
  
-	ret = igt_spinner_init(*spin, i915);

+   ret = igt_spinner_init(*spin, ce->engine->gt);
if (ret)
goto err_free;
  
-	rq = igt_spinner_create_request(*spin,

-   ce->gem_context,
-   ce->engine,
-   MI_NOOP);
+   rq = igt_spinner_create_request(*spin, ce, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
goto err_fini;
@@ -871,8 +867,7 @@ __sseu_prepare(struct drm_i915_private *i915,
  }
  
  static int

-__read_slice_count(struct drm_i915_private *i915,
-  struct intel_context *ce,
+__read_slice_count(struct intel_context *ce,
   struct drm_i915_gem_object *obj,
   struct igt_spinner *spin,
   u32 *rpcs)
@@ -901,7 +896,7 @@ __read_slice_count(struct drm_i915_private *i915,
return ret;
}
  
-	if (INTEL_GEN(i915) >= 11) {

+   if (INTEL_GEN(ce->engine->i915) >= 11) {
s_mask = GEN11_RPCS_S_CNT_MASK;
s_shift = GEN11_RPCS_S_CNT_SHIFT;
} else {
@@ -944,8 +939,7 @@ __check_rpcs(const char *name, u32 rpcs, int slices, 
unsigned int expected,
  }
  
  static int

-__sseu_finish(struct drm_i915_private *i915,
- const char *name,
+__sseu_finish(const char *name,
  unsigned int flags,
  struct intel_context *ce,
  struct drm_i915_gem_object *obj,
@@ -962,14 +956,13 @@ __sseu_finish(struct drm_i915_private *i915,
goto out;
}
  
-	ret = __read_slice_count(i915, ce, obj,

+   ret = __read_slice_count(ce, obj,
 flags & TEST_RESET ? NULL : spin, );
ret = __check_rpcs(name, rpcs, ret, expected, "Context", "!");
if (ret)
goto out;
  
-	ret = __read_slice_count(i915, ce->engine->kernel_context, obj,

-NULL, );
+   ret = __read_slice_count(ce->engine->kernel_context, obj, NULL, );
ret = __check_rpcs(name, rpcs, ret, slices, "Kernel context", "!");
  
  out:

@@ -977,11 +970,12 @@ __sseu_finish(struct drm_i915_private *i915,
igt_spinner_end(spin);
  
  	if ((flags & TEST_IDLE) && ret == 0) {

-   ret = i915_gem_wait_for_idle(i915, 0, MAX_SCHEDULE_TIMEOUT);
+   ret = i915_gem_wait_for_idle(ce->engine->i915,
+0, MAX_SCHEDULE_TIMEOUT);
if (ret)
return ret;
  
-		ret = __read_slice_count(i915, ce, obj, NULL, );

+   ret = __read_slice_count(ce, obj, NULL, );
ret = __check_rpcs(name, rpcs, ret, expected,
   "Context", " after idle!");
}
@@ -990,8 +984,7 @@ __sseu_finish(struct drm_i915_private *i915,
  }
  
  static int

-__sseu_test(struct drm_i915_private *i915,
-   const char *name,
+__sseu_test(const char *name,
unsigned int flags,
struct intel_context *ce,
struct drm_i915_gem_object *obj,
@@ -1000,7 +993,7 @@ __sseu_test(struct drm_i915_private *i915,
struct igt_spinner *spin = NULL;
int ret;
  
-	ret = __sseu_prepare(i915, name, flags, ce, );

+   ret = __sseu_prepare(name, flags, ce, );
if (ret)
return ret;
  
@@ -1008,7 +1001,7 @@ __sseu_test(struct drm_i915_private *i915,

if (ret)
goto out_spin;
  
-	ret = __sseu_finish(i915, name, 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid ce->gem_context->i915

2019-07-30 Thread Tvrtko Ursulin


On 30/07/2019 17:34, Chris Wilson wrote:

My plan for the future is to have kernel contexts no have a GEM context
backpointer (as they will not belong to any GEM context). In a few
places, we use ce->gem_context to simply obtain the i915 backpointer,
which we can use ce->engine->i915 instead.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 2 +-
  drivers/gpu/drm/i915/gem/i915_gem_context.c| 4 ++--
  drivers/gpu/drm/i915/i915_perf.c   | 2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 2312a0c6af89..997e122545bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -152,7 +152,7 @@ static void clear_pages_dma_fence_cb(struct dma_fence 
*fence,
  static void clear_pages_worker(struct work_struct *work)
  {
struct clear_pages_work *w = container_of(work, typeof(*w), work);
-   struct drm_i915_private *i915 = w->ce->gem_context->i915;
+   struct drm_i915_private *i915 = w->ce->engine->i915;
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b28c7ca681a8..eb2d28a37b58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1194,7 +1194,7 @@ __intel_context_reconfigure_sseu(struct intel_context *ce,
  {
int ret;
  
-	GEM_BUG_ON(INTEL_GEN(ce->gem_context->i915) < 8);

+   GEM_BUG_ON(INTEL_GEN(ce->engine->i915) < 8);
  
  	ret = intel_context_lock_pinned(ce);

if (ret)
@@ -1216,7 +1216,7 @@ __intel_context_reconfigure_sseu(struct intel_context *ce,
  static int
  intel_context_reconfigure_sseu(struct intel_context *ce, struct intel_sseu 
sseu)
  {
-   struct drm_i915_private *i915 = ce->gem_context->i915;
+   struct drm_i915_private *i915 = ce->engine->i915;
int ret;
  
  	ret = mutex_lock_interruptible(>drm.struct_mutex);

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 988a4092164e..f2cc69ccb635 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1667,7 +1667,7 @@ gen8_update_reg_state_unlocked(struct intel_context *ce,
   u32 *reg_state,
   const struct i915_oa_config *oa_config)
  {
-   struct drm_i915_private *i915 = ce->gem_context->i915;
+   struct drm_i915_private *i915 = ce->engine->i915;
u32 ctx_oactxctrl = i915->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = i915->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */



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] ✓ Fi.CI.IGT: success for drm/i915: Avoid ce->gem_context->i915

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915: Avoid ce->gem_context->i915
URL   : https://patchwork.freedesktop.org/series/64442/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6582_full -> Patchwork_13805_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-iclb8/igt@gem_exec_balan...@smoke.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103540])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-hsw6/igt@kms_f...@flip-vs-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-hsw2/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / 
[fdo#106978])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl6/igt@kms_frontbuffer_track...@fbcpsr-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-skl4/igt@kms_frontbuffer_track...@fbcpsr-suspend.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt:
- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-skl5/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_basic:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb2/igt@kms_psr@psr2_basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-iclb4/igt@kms_psr@psr2_basic.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][17] -> [FAIL][18] ([fdo#99912])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl1/igt@kms_setm...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-apl3/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@gem_exec_flush@basic-wb-set-default:
- shard-iclb: [INCOMPLETE][19] ([fdo#107713]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb7/igt@gem_exec_fl...@basic-wb-set-default.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-iclb2/igt@gem_exec_fl...@basic-wb-set-default.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [FAIL][23] ([fdo#103167]) -> [PASS][24] +3 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [24]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Remove DDI IO power domain from PG3 power domains

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/icl: Remove DDI IO power domain from PG3 power domains
URL   : https://patchwork.freedesktop.org/series/64465/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13816


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_basic@create-fd-close:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_ba...@create-fd-close.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-u3/igt@gem_ba...@create-fd-close.html

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2:  [PASS][5] -> [FAIL][6] ([fdo#110387])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [PASS][7] -> [DMESG-WARN][8] ([fdo#102614])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2:  [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [INCOMPLETE][11] ([fdo#107713] / [fdo#109100]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][15] ([fdo#74]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  * igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][17] ([fdo#111045] / [fdo#111046 ]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][19] ([fdo#111045]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13816/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

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

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046 
  [fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 46)
--

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Pass intel_context to igt_spinner

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Pass intel_context to igt_spinner
URL   : https://patchwork.freedesktop.org/series/64440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6582_full -> Patchwork_13804_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +6 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-iclb6/igt@gem_exec_balan...@smoke.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108686])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html

  * igt@i915_pm_rpm@fences-dpms:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#108840])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb4/igt@i915_pm_...@fences-dpms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-iclb2/igt@i915_pm_...@fences-dpms.html

  * igt@kms_big_fb@linear-16bpp-rotate-0:
- shard-snb:  [PASS][9] -> [SKIP][10] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-snb7/igt@kms_big...@linear-16bpp-rotate-0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-snb7/igt@kms_big...@linear-16bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([fdo#103232])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-apl:  [PASS][13] -> [FAIL][14] ([fdo#105363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl1/igt@kms_f...@flip-vs-expired-vblank.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-apl3/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][15] -> [INCOMPLETE][16] ([fdo#103540])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-hsw6/igt@kms_f...@flip-vs-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-hsw7/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt:
- shard-skl:  [PASS][19] -> [FAIL][20] ([fdo#103167]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-blt.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][23] -> [FAIL][24] ([fdo#108145])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * 

[Intel-gfx] [PATCH] drm/i915/icl: Remove DDI IO power domain from PG3 power domains

2019-07-30 Thread Anshuman Gupta
DDI IO power domain are in IO/PHY/AFE power domains.
Which does not require PG3 power well to be enable.
MIPI DSI dual link gets "DDI B" IO power domain reference
count which enables PG3 since "DDI B" IO power domain is
part of PG3 power domain, that makes power leakage in
MIPI DSI dual link use case.

Cc: Deak Imre 
Cc: Syrjala Ville 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index dd2a50b8ba0a..ca33e8d41218 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2482,11 +2482,8 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\
-   BIT_ULL(POWER_DOMAIN_PORT_DDI_B_IO) |   \
BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
-   BIT_ULL(POWER_DOMAIN_PORT_DDI_C_IO) |   \
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
-   BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO) |   \
BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DDI_E_IO) |   \
BIT_ULL(POWER_DOMAIN_PORT_DDI_F_LANES) |\
-- 
2.21.0

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Pass intel_context to mock_request

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Pass intel_context to mock_request
URL   : https://patchwork.freedesktop.org/series/64439/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6582_full -> Patchwork_13803_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_execlists:
- shard-skl:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl5/igt@i915_selftest@live_execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-skl1/igt@i915_selftest@live_execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-iclb6/igt@gem_exec_balan...@smoke.html

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-skl8/igt@i915_pm_backlight@fade_with_suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-skl6/igt@i915_pm_backlight@fade_with_suspend.html

  * igt@i915_pm_rpm@debugfs-forcewake-user:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / 
[fdo#108840])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb1/igt@i915_pm_...@debugfs-forcewake-user.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-iclb7/igt@i915_pm_...@debugfs-forcewake-user.html

  * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque:
- shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#103232])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-glk6/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-glk8/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html
- shard-kbl:  [PASS][13] -> [FAIL][14] ([fdo#103232])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html

  * igt@kms_flip@2x-plain-flip-ts-check:
- shard-glk:  [PASS][15] -> [FAIL][16] ([fdo#100368])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-glk2/igt@kms_f...@2x-plain-flip-ts-check.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-glk6/igt@kms_f...@2x-plain-flip-ts-check.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][17] -> [INCOMPLETE][18] ([fdo#103540])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-hsw6/igt@kms_f...@flip-vs-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-hsw2/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@basic:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-iclb8/igt@kms_frontbuffer_track...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-iclb2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-snb:  [PASS][21] -> [SKIP][22] ([fdo#109271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/shard-snb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 
similar issue
   

[Intel-gfx] ✓ Fi.CI.BAT: success for Initial TGL submission changes

2019-07-30 Thread Patchwork
== Series Details ==

Series: Initial TGL submission changes
URL   : https://patchwork.freedesktop.org/series/64461/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13815


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][1] -> [SKIP][2] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][5] -> [WARN][6] ([fdo#109380])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][9] ([fdo#74]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  * igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][11] ([fdo#111045] / [fdo#111046 ]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][13] ([fdo#111045]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Warnings 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][15] ([fdo#102505] / [fdo#110390]) -> 
[FAIL][16] ([fdo#109483])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13815/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

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

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046 
  [fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 43)
--

  Missing(11): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-skl-guc 
fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-icl-u3 fi-icl-y fi-byt-clapper 
fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6586 -> Patchwork_13815

  CI-20190529: 20190529
  CI_DRM_6586: 066993443a56467f54fdcf560e89378f8e93a15b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13815: b6503210b82338253ab4a38156901a0a6acbae01 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b6503210b823 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Move aliasing_ppgtt underneath its i915_ggtt

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Move aliasing_ppgtt underneath 
its i915_ggtt
URL   : https://patchwork.freedesktop.org/series/64438/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13802_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] ([fdo#103665])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl3/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-kbl2/igt@gem_...@in-flight-suspend.html

  * igt@gem_pwrite@huge-cpu-forwards:
- shard-hsw:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103540])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-hsw1/igt@gem_pwr...@huge-cpu-forwards.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-hsw8/igt@gem_pwr...@huge-cpu-forwards.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@kms_frontbuffer_track...@fbc-badstride.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-iclb4/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-render:
- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl4/igt@kms_frontbuffer_track...@psr-rgb101010-draw-render.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-skl3/igt@kms_frontbuffer_track...@psr-rgb101010-draw-render.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#108145] / [fdo#110403])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +3 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-iclb4/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][13] -> [FAIL][14] ([fdo#99912])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@kms_setm...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-apl2/igt@kms_setm...@basic.html

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([fdo#108566])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl5/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-apl8/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html

  
 Possible fixes 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-apl:  [DMESG-WARN][17] ([fdo#108566]) -> [PASS][18] +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][19] ([fdo#104108]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl7/igt@gem_soft...@noreloc-s3.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-skl8/igt@gem_soft...@noreloc-s3.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  [DMESG-WARN][21] ([fdo#108686]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +4 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb:  [SKIP][25] ([fdo#109271]) -> [PASS][26]
   [25]: 

Re: [Intel-gfx] [RFC PATCH 0/3] Propose new struct drm_mem_region

2019-07-30 Thread Brian Welty

On 7/30/2019 2:34 AM, Daniel Vetter wrote:
> On Tue, Jul 30, 2019 at 08:45:57AM +, Koenig, Christian wrote:
>> Yeah, that looks like a good start. Just a couple of random design 
>> comments/requirements.
>>
>> First of all please restructure the changes so that you more or less 
>> have the following:
>> 1. Adding of the new structures and functionality without any change to 
>> existing code.
>> 2. Replacing the existing functionality in TTM and all of its drivers.
>> 3. Replacing the existing functionality in i915.
>>
>> This should make it much easier to review the new functionality when it 
>> is not mixed with existing TTM stuff.

Sure, understood.  But I hope it's fair that I wouldn't be updating all
drivers in an RFC series until there is a bit of clarity/agreement on any
path forward.  But I can include amdgpu patch next time.

>>
>>
>> Second please completely drop the concept of gpu_offset or start of the 
>> memory region like here:
>>> drm_printf(p, "gpu_offset: 0x%08llX\n", man->region.start);
>> At least on AMD hardware we have the following address spaces which are 
>> sometimes even partially overlapping: VM, MC, SYSTEM, FB, AGP, XGMI, bus 
>> addresses and physical addresses.
>>
>> Pushing a concept of a general GPU address space into the memory 
>> management was a rather bad design mistake in TTM and we should not 
>> repeat that here.
>>
>> A region should only consists of a size in bytes and (internal to the 
>> region manager) allocations in that region.

Got it. I was trying to include fields that seemed relevant to a base
structure and could then optionally be leveraged at the choice of device
driver.  But I see your point.

>>
>>
>> Third please don't use any CPU or architecture specific types in any 
>> data structures:
>>> +struct drm_mem_region {
>>> +   resource_size_t start; /* within GPU physical address space */
>>> +   resource_size_t io_start; /* BAR address (CPU accessible) */
>>> +   resource_size_t size;
>>
>> I knew that resource_size is mostly 64bit on modern architectures, but 
>> dGPUs are completely separate to the architecture and we always need 
>> 64bits here at least for AMD hardware.
>>
>> So this should either be always uint64_t, or something like 
>> gpu_resource_size which depends on what the compiled in drivers require 
>> if we really need that.
>>
>> And by the way: Please always use bytes for things like sizes and not 
>> number of pages, cause page size is again CPU/architecture specific and 
>> GPU drivers don't necessary care about that.

Makes sense,  will fix.

Hmm,  I did hope that at least the DRM cgroup controller could leverage
struct page_counter.  It encapsulates nicely much of the fields for 
managing a memory limit.  But well, this is off topic

>>
>>
>> And here also a few direct comments on the code:
>>> +   union {
>>> +   struct drm_mm *mm;
>>> +   /* FIXME (for i915): struct drm_buddy_mm *buddy_mm; */
>>> +   void *priv;
>>> +   };
>> Maybe just always use void *mm here.
> 
> I'd say lets drop this outright, and handle private data by embedding this
> structure in the right place. That's how we handle everything in drm now
> as much as possible, and it's so much cleaner. I think ttm still loves
> priv pointers a bit too much in some places.

Okay, I'll drop it until I might be able to prove this might be useful later.

>
>>> +   spinlock_t move_lock;
>>> +   struct dma_fence *move;
>>
>> That is TTM specific and I'm not sure if we want it in the common memory 
>> management handling.
>>
>> If we want that here we should probably replace the lock with some rcu 
>> and atomic fence pointer exchange first.
> 
> Yeah  not sure we want any of these details in this shared structure
> either.
> 

Thanks for the feedback. I can remove it too.
I was unsure if might be a case for having it in future.

Well, struct drm_mem_region will be quite small then if it only has a
size and type field.
Hardly seems worth introducing a new structure if these are the only fields.
I know we thought it might benefit cgroups controller,  but I still hope to
find earlier purpose it could serve.

-Brian


[snip]

>>
>> Am 30.07.19 um 02:32 schrieb Brian Welty:
>>> [ By request, resending to include amd-gfx + intel-gfx.  Since resending,
>>>I fixed the nit with ordering of header includes that Sam noted. ]
>>>
>>> This RFC series is first implementation of some ideas expressed
>>> earlier on dri-devel [1].
>>>
>>> Some of the goals (open for much debate) are:
>>>- Create common base structure (subclass) for memory regions (patch #1)
>>>- Create common memory region types (patch #2)
>>>- Create common set of memory_region function callbacks (based on
>>>  ttm_mem_type_manager_funcs and intel_memory_regions_ops)
>>>- Create common helpers that operate on drm_mem_region to be leveraged
>>>  by both TTM drivers and i915, reducing code duplication
>>>- Above might start with refactoring 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Initial TGL submission changes

2019-07-30 Thread Patchwork
== Series Details ==

Series: Initial TGL submission changes
URL   : https://patchwork.freedesktop.org/series/64461/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
74d80bbbdcd2 drm/i915/tgl: add Gen12 default indirect ctx offset
d43424d8627c drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID
0cef7902632f drm/i915/tgl: Gen12 csb support
-:48: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct 
intel_engine_execlists *' should also have an identifier name
#48: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:264:
+   enum intel_csb_step

total: 0 errors, 1 warnings, 0 checks, 123 lines checked
b6503210b823 drm/i915/tgl: Report valid VDBoxes with SFC capability

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

Re: [Intel-gfx] [RFC PATCH 0/3] Propose new struct drm_mem_region

2019-07-30 Thread Brian Welty

On 7/30/2019 3:45 AM, Daniel Vetter wrote:
> On Tue, Jul 30, 2019 at 12:24 PM Koenig, Christian
>  wrote:
>>
>> Am 30.07.19 um 11:38 schrieb Daniel Vetter:
>>> On Tue, Jul 30, 2019 at 08:45:57AM +, Koenig, Christian wrote:

Snipped the feedback on struct drm_mem_region.
Will be easier to have separate thread.


> +/*
> + * Memory types for drm_mem_region
> + */
 #define DRM_MEM_SWAP?
>>> btw what did you have in mind for this? Since we use shmem we kinda don't
>>> know whether the BO is actually swapped out or not, at least on the i915
>>> side. So this would be more NOT_CURRENTLY_PINNED_AND_POSSIBLY_SWAPPED_OUT.
>>
>> Yeah, the problem is not everybody can use shmem. For some use cases you
>> have to use memory allocated through dma_alloc_coherent().
>>
>> So to be able to swap this out you need a separate domain to copy it
>> from whatever is backing it currently to shmem.
>>
>> So we essentially have:
>> DRM_MEM_SYS_SWAPABLE
>> DRM_MEM_SYS_NOT_GPU_MAPPED
>> DRM_MEM_SYS_GPU_MAPPED
>>
>> Or something like that.
> 
> Yeah i915-gem is similar. We oportunistically keep the pages pinned
> sometimes even if not currently mapped into the (what ttm calls) TT.
> So I think these three for system memory make sense for us too. I
> think that's similar (at least in spirit) to the dma_alloc cache you
> have going on. Mabye instead of the somewhat cumbersome NOT_GPU_MAPPED
> we could have something like PINNED or so. Although it's not
> permanently pinned, so maybe that's confusing too.
> 

Okay, I see now I was far off the mark with what I thought TTM_PL_SYSTEM
was.  The discussion helped clear up several bits of confusion on my part.
From proposed names, I find MAPPED and PINNED slightly confusing.
In terms of backing store description, maybe these are a little better:
  DRM_MEM_SYS_UNTRANSLATED  (TTM_PL_SYSTEM)
  DRM_MEM_SYS_TRANSLATED(TTM_PL_TT or i915's SYSTEM)

Are these allowed to be both overlapping? Or non-overlapping (partitioned)?
Per Christian's point about removing .start, seems it doesn't need to
matter.

Whatever we define for these sub-types, does it make sense for SYSTEM and
VRAM to each have them defined?

I'm unclear how DRM_MEM_SWAP (or DRM_MEM_SYS_SWAPABLE) would get
configured by driver...  this is a fixed size partition of host memory?
Or it is a kind of dummy memory region just for swap implementation?


 TTM was clearly missing that resulting in a whole bunch of extra
 handling and rather complicated handling.

> +#define DRM_MEM_SYSTEM 0
> +#define DRM_MEM_STOLEN 1
 I think we need a better naming for that.

 STOLEN sounds way to much like stolen VRAM for integrated GPUs, but at
 least for TTM this is the system memory currently GPU accessible.
>>> Yup this is wrong, for i915 we use this as stolen, for ttm it's the gpu
>>> translation table window into system memory. Not the same thing at all.
>>
>> Thought so. The closest I have in mind is GTT, but everything else works
>> as well.
> 
> Would your GPU_MAPPED above work for TT? I think we'll also need
> STOLEN, I'm even hearing noises that there's going to be stolen for
> discrete vram for us ... Also if we expand I guess we need to teach
> ttm to cope with more, or maybe treat the DRM one as some kind of
> sub-flavour.
Daniel, maybe what i915 calls stolen could just be DRM_MEM_RESERVED or
DRM_MEM_PRIV.  Or maybe can argue it falls into UNTRANSLATED type that
I suggested above, I'm not sure.

-Brian


> -Daniel
> 
>>
>> Christian.
>>
>>> -Daniel
>>>

 Thanks for looking into that,
 Christian.

 Am 30.07.19 um 02:32 schrieb Brian Welty:
> [ By request, resending to include amd-gfx + intel-gfx.  Since resending,
> I fixed the nit with ordering of header includes that Sam noted. ]
>
> This RFC series is first implementation of some ideas expressed
> earlier on dri-devel [1].
>
> Some of the goals (open for much debate) are:
> - Create common base structure (subclass) for memory regions (patch 
> #1)
> - Create common memory region types (patch #2)
> - Create common set of memory_region function callbacks (based on
>   ttm_mem_type_manager_funcs and intel_memory_regions_ops)
> - Create common helpers that operate on drm_mem_region to be leveraged
>   by both TTM drivers and i915, reducing code duplication
> - Above might start with refactoring ttm_bo_manager.c as these are
>   helpers for using drm_mm's range allocator and could be made to
>   operate on DRM structures instead of TTM ones.
> - Larger goal might be to make LRU management of GEM objects common, 
> and
>   migrate those fields into drm_mem_region and drm_gem_object 
> strucures.
>
> Patches 1-2 implement the proposed struct drm_mem_region and adds
> associated common set of definitions for memory region type.
>
> Patch #3 is update to 

[Intel-gfx] [PATCH 1/4] drm/i915/tgl: add Gen12 default indirect ctx offset

2019-07-30 Thread Daniele Ceraolo Spurio
Gen12 uses a new indirect ctx offset.

Cc: Lucas De Marchi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 4 
 drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d9061d9348cb..c379184ac987 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2891,6 +2891,10 @@ static u32 intel_lr_indirect_ctx_offset(struct 
intel_engine_cs *engine)
default:
MISSING_CASE(INTEL_GEN(engine->i915));
/* fall through */
+   case 12:
+   indirect_ctx_offset =
+   GEN12_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
+   break;
case 11:
indirect_ctx_offset =
GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
index 6bf34738b4e5..b8f20ad71169 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
@@ -64,5 +64,6 @@
 #define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 #define GEN10_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x19
 #define GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x1A
+#define GEN12_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0xD
 
 #endif /* _INTEL_LRC_REG_H_ */
-- 
2.22.0

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

[Intel-gfx] [PATCH 2/4] drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID

2019-07-30 Thread Daniele Ceraolo Spurio
Like Gen11, Gen12 has 11 available bits for the ctx id field. However,
the last value (0x7FF) is reserved to indicate engine idle, so we
need to reduce the maximum number of contexts by 1 compared to Gen11.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Lucas De Marchi 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +++-
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b28c7ca681a8..67d76ef6a7ae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -172,7 +172,9 @@ static inline int new_hw_id(struct drm_i915_private *i915, 
gfp_t gfp)
 
lockdep_assert_held(>contexts.mutex);
 
-   if (INTEL_GEN(i915) >= 11)
+   if (INTEL_GEN(i915) >= 12)
+   max = GEN12_MAX_CONTEXT_HW_ID;
+   else if (INTEL_GEN(i915) >= 11)
max = GEN11_MAX_CONTEXT_HW_ID;
else if (USES_GUC_SUBMISSION(i915))
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3eeb21ff04c2..20161f4ebd19 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1580,6 +1580,8 @@ struct drm_i915_private {
 #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
 #define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
 #define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+/* in Gen12 ID 0x7FF is reserved to indicate idle */
+#define GEN12_MAX_CONTEXT_HW_ID(GEN11_MAX_CONTEXT_HW_ID - 1)
struct list_head hw_id_list;
} contexts;
 
-- 
2.22.0

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

[Intel-gfx] [PATCH 3/4] drm/i915/tgl: Gen12 csb support

2019-07-30 Thread Daniele Ceraolo Spurio
The CSB format has been reworked for Gen12 to include information on
both the context we're switching away from and the context we're
switching to. After the change, some of the events don't have their
own bit anymore and need to be inferred from other values in the csb.
One of the context IDs (0x7FF) has also been reserved to indicate
the invalid ctx, i.e. engine idle.

Note that the full context ID includes the SW counter as well, but since
we currently only care if the context is valid or not we can ignore that
part.

Bspec: 4, 46144
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 73 +---
 2 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index da61dd329210..98adc764d4f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -139,6 +139,13 @@ struct st_preempt_hang {
bool inject_hang;
 };
 
+enum intel_csb_step {
+   CSB_NOP,
+   CSB_PROMOTE,
+   CSB_PREEMPT,
+   CSB_COMPLETE,
+};
+
 /**
  * struct intel_engine_execlists - execlist submission queue and port state
  *
@@ -251,6 +258,12 @@ struct intel_engine_execlists {
 */
u8 csb_head;
 
+   /**
+* @csb_parse: platform-specific function to parse the status buffer
+*/
+   enum intel_csb_step
+   (*csb_parse)(const struct intel_engine_execlists *, const u32 *csb);
+
I915_SELFTEST_DECLARE(struct st_preempt_hang preempt_hang;)
 };
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c379184ac987..00afdcd71bd4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -163,6 +163,13 @@
 
 #define CTX_DESC_FORCE_RESTORE BIT_ULL(2)
 
+#define GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE (0x1) /* lower csb dword */
+#define GEN12_CTX_SWITCH_DETAIL(csb_dw)((csb_dw) & 0xF) /* upper csb 
dword */
+#define GEN12_CSB_SW_CTX_ID_MASK   GENMASK_ULL(25, 15)
+#define GEN12_IDLE_CTX_ID  0x7FF
+#define GEN12_CSB_CTX_VALID(csb_dw)\
+   (FIELD_GET(GEN12_CSB_SW_CTX_ID_MASK, csb_dw) != GEN12_IDLE_CTX_ID)
+
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 #define WA_TAIL_DWORDS 2
@@ -1315,14 +1322,59 @@ reset_in_progress(const struct intel_engine_execlists 
*execlists)
return unlikely(!__tasklet_is_enabled(>tasklet));
 }
 
-enum csb_step {
-   CSB_NOP,
-   CSB_PROMOTE,
-   CSB_PREEMPT,
-   CSB_COMPLETE,
-};
+/*
+ * Starting with Gen12, the status has a new format:
+ *
+ * bit  0: switched to new queue
+ * bit  1: reserved
+ * bit  2: semaphore wait mode (poll or signal), Only valid when
+ * switch detail is set to "wait on semaphore"
+ * bits 3-5:   engine class
+ * bits 6-11:  engine instance
+ * bits 12-14: reserved
+ * bits 15-25: sw context id of the lrc we're switching to
+ * bits 26-31: sw counter of the lrc we're switching to
+ * bits 32-35: context switch detail
+ *  - 0: ctx complete
+ *  - 1: wait on sync flip
+ *  - 2: wait on vblank
+ *  - 3: wait on scanline
+ *  - 4: wait on semaphore
+ *  - 5: context preempted (not on SEMAPHORE_WAIT or
+ *   WAIT_FOR_EVENT)
+ * bit  36:reserved
+ * bits 37-43: wait detail (for switch detail 1 to 4)
+ * bits 44-46: reserved
+ * bits 47-57: sw context id of the lrc we're switching away from
+ * bits 58-63: sw counter of the lrc we're switching away from
+ */
+static enum intel_csb_step
+gen12_csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
+{
+   u32 lower_dw = csb[0];
+   u32 upper_dw = csb[1];
+   bool ctx_to_valid = GEN12_CSB_CTX_VALID(lower_dw);
+   bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_dw);
+   bool new_queue = lower_dw & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
+
+   if (!ctx_away_valid && ctx_to_valid)
+   return CSB_PROMOTE;
+
+   if (new_queue && ctx_away_valid)
+   return CSB_PREEMPT;
 
-static inline enum csb_step
+   /* we do not expect a ctx switch on unsuccessful wait */
+   GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_dw));
+
+   if (*execlists->active) {
+   GEM_BUG_ON(!ctx_away_valid);
+   return CSB_COMPLETE;
+   }
+
+   return CSB_NOP;
+}
+
+static enum intel_csb_step
 csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
 {
unsigned int status = *csb;
@@ -1401,7 +1453,7 @@ static void process_csb(struct intel_engine_cs *engine)

[Intel-gfx] [PATCH 4/4] drm/i915/tgl: Report valid VDBoxes with SFC capability

2019-07-30 Thread Daniele Ceraolo Spurio
From: Michel Thierry 

In Gen11, only even numbered "logical" VDBoxes are hooked up to a SFC
(Scaler & Format Converter) unit. This is not the case in Tigerlake,
where each VDBox can access a SFC.

We will use this information to decide when the SFC units need to be reset
and also pass it to the GuC.

Bspec: 48077
Signed-off-by: Michel Thierry 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Lucas De Marchi 
Cc: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index f99c9fd497b2..2a39b52c3582 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -1022,8 +1022,9 @@ void intel_device_info_init_mmio(struct drm_i915_private 
*dev_priv)
/*
 * In Gen11, only even numbered logical VDBOXes are
 * hooked up to an SFC (Scaler & Format Converter) unit.
+* In TGL each VDBOX has access to an SFC.
 */
-   if (logical_vdbox++ % 2 == 0)
+   if (IS_TIGERLAKE(dev_priv) || logical_vdbox++ % 2 == 0)
RUNTIME_INFO(dev_priv)->vdbox_sfc_access |= BIT(i);
}
DRM_DEBUG_DRIVER("vdbox enable: %04x, instances: %04lx\n",
-- 
2.22.0

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

[Intel-gfx] [PATCH 0/4] Initial TGL submission changes

2019-07-30 Thread Daniele Ceraolo Spurio
New lrc-related defines, new csb parser and TGL sfc pairing.

There are required changes for the context image as well, I'll send them
separately as I haven't done the math for the lrc size yet.

Cc: Lucas De Marchi 

Daniele Ceraolo Spurio (3):
  drm/i915/tgl: add Gen12 default indirect ctx offset
  drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID
  drm/i915/tgl: Gen12 csb support

Michel Thierry (1):
  drm/i915/tgl: Report valid VDBoxes with SFC capability

 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 77 ++--
 drivers/gpu/drm/i915/gt/intel_lrc_reg.h  |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_device_info.c |  3 +-
 6 files changed, 90 insertions(+), 10 deletions(-)

-- 
2.22.0

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

[Intel-gfx] ✓ Fi.CI.IGT: success for DC3CO Support for TGL.

2019-07-30 Thread Patchwork
== Series Details ==

Series: DC3CO Support for TGL.
URL   : https://patchwork.freedesktop.org/series/64436/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13801_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-iclb7/igt@gem_exec_balan...@smoke.html

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([fdo#104108]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl5/igt@i915_pm_backlight@fade_with_suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-skl3/igt@i915_pm_backlight@fade_with_suspend.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#103927])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl5/igt@i915_susp...@sysfs-reader.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-apl6/igt@i915_susp...@sysfs-reader.html

  * igt@kms_busy@extended-modeset-hang-oldfb-render-c:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb1/igt@kms_b...@extended-modeset-hang-oldfb-render-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-iclb7/igt@kms_b...@extended-modeset-hang-oldfb-render-c.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#110741])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x21-random:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-hsw1/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-hsw8/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#105363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-glk8/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#105363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl4/igt@kms_frontbuffer_track...@fbc-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-apl6/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13801/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [24]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/5] drm/i915/uc: Don't enable communication twice on resume

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/5] drm/i915/uc: Don't enable communication 
twice on resume
URL   : https://patchwork.freedesktop.org/series/64459/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13814


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-whl-u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-whl-u/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-whl-u/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-ilk-650: [PASS][3] -> [DMESG-WARN][4] ([fdo#106387])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-ilk-650/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-ilk-650/igt@i915_module_l...@reload.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [INCOMPLETE][11] ([fdo#107713] / [fdo#109100]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][15] ([fdo#107718]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][17] ([fdo#74]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  * igt@kms_chamelium@dp-edid-read:
- {fi-icl-u4}:[FAIL][19] ([fdo#111045] / [fdo#111046 ]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13814/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v7,1/4] drm/i915/bdw+: Move misc display IRQ handling to it own function

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [v7,1/4] drm/i915/bdw+: Move misc display IRQ 
handling to it own function
URL   : https://patchwork.freedesktop.org/series/64457/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13813


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#109100])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_flink_basic@basic:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_flink_ba...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-icl-u3/igt@gem_flink_ba...@basic.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][9] -> [WARN][10] ([fdo#109380])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [INCOMPLETE][13] ([fdo#107713] / [fdo#109100]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][17] ([fdo#107718]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][19] ([fdo#74]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][21] ([fdo#109485]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13813/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/oa: add content to Makefile

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/oa: add content to Makefile
URL   : https://patchwork.freedesktop.org/series/64427/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13799_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@reset-stress:
- shard-skl:  [PASS][1] -> [FAIL][2] ([fdo#109661])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl1/igt@gem_...@reset-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-skl9/igt@gem_...@reset-stress.html

  * igt@i915_suspend@debugfs-reader:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl1/igt@i915_susp...@debugfs-reader.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-kbl1/igt@i915_susp...@debugfs-reader.html

  * igt@kms_busy@extended-modeset-hang-oldfb-render-c:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb1/igt@kms_b...@extended-modeset-hang-oldfb-render-c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-iclb7/igt@kms_b...@extended-modeset-hang-oldfb-render-c.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][7] -> [FAIL][8] ([fdo#104873])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#105363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-hsw1/igt@kms_f...@flip-vs-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-hsw4/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][13] -> [INCOMPLETE][14] ([fdo#103665])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-skl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#110403])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-iclb6/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@kms_setm...@basic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13799/shard-apl2/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@gem_softpin@noreloc-s3:
- shard-skl:   

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v7,1/4] drm/i915/bdw+: Move misc display IRQ handling to it own function

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [v7,1/4] drm/i915/bdw+: Move misc display IRQ 
handling to it own function
URL   : https://patchwork.freedesktop.org/series/64457/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5a3f9ccb3fc9 drm/i915/bdw+: Move misc display IRQ handling to it own function
a8018e3ff959 drm/i915: Add _TRANS2()
-:31: WARNING:LONG_LINE: line over 100 characters
#31: FILE: drivers/gpu/drm/i915/i915_reg.h:255:
+
INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_A] + (reg) + \

total: 0 errors, 1 warnings, 0 checks, 13 lines checked
0fc9611632eb drm/i915/psr: Make PSR registers relative to transcoders
-:427: WARNING:LONG_LINE_COMMENT: line over 100 characters
#427: FILE: drivers/gpu/drm/i915/i915_reg.h:4308:
+#define EDP_PSR_AUX_DATA(tran, i)  _MMIO(_PSR_ADJ(tran, 
_SRD_AUX_DATA_A) + (i) + 4) /* 5 registers */

total: 0 errors, 1 warnings, 0 checks, 393 lines checked
2bb2793c50ec drm/i915: Add transcoder restriction to PSR2

___
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/ehl: Don't forget to handle port C's hotplug interrupts (rev2)

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Don't forget to handle port C's hotplug interrupts (rev2)
URL   : https://patchwork.freedesktop.org/series/64452/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13812


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][1] -> [SKIP][2] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][5] -> [WARN][6] ([fdo#109380])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][13] ([fdo#74]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13812/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 45)
--

  Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6586 -> Patchwork_13812

  CI-20190529: 20190529
  CI_DRM_6586: 066993443a56467f54fdcf560e89378f8e93a15b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13812: 6d2cec83dd6fb55ad998fc47aada4a1c723114da @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6d2cec83dd6f drm/i915/ehl: Don't forget to handle port C's hotplug interrupts

== Logs ==

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

[Intel-gfx] [PATCH v2 5/5] drm/i915/gt: Introduce intel_gt_runtime_suspend/resume

2019-07-30 Thread Daniele Ceraolo Spurio
To be called from the top level runtime functions, to hide the
gt-specific bits (mainly related to intel_uc).

v2: rebased

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 
 drivers/gpu/drm/i915/gt/intel_gt_pm.h |  2 ++
 drivers/gpu/drm/i915/i915_drv.c   |  9 +++--
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 65c0d0c9d543..6c8970271a7f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -164,3 +164,15 @@ int intel_gt_resume(struct intel_gt *gt)
 
return err;
 }
+
+void intel_gt_runtime_suspend(struct intel_gt *gt)
+{
+   intel_uc_runtime_suspend(>uc);
+}
+
+int intel_gt_runtime_resume(struct intel_gt *gt)
+{
+   intel_gt_init_swizzling(gt);
+
+   return intel_uc_runtime_resume(>uc);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index ba960e1fc209..527894fe1345 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -23,5 +23,7 @@ void intel_gt_pm_init_early(struct intel_gt *gt);
 
 void intel_gt_sanitize(struct intel_gt *gt, bool force);
 int intel_gt_resume(struct intel_gt *gt);
+void intel_gt_runtime_suspend(struct intel_gt *gt);
+int intel_gt_runtime_resume(struct intel_gt *gt);
 
 #endif /* INTEL_GT_PM_H */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 86e024d063f3..2c68ebd7284b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2925,7 +2925,7 @@ static int intel_runtime_suspend(struct device *kdev)
 */
i915_gem_runtime_suspend(dev_priv);
 
-   intel_uc_runtime_suspend(_priv->gt.uc);
+   intel_gt_runtime_suspend(_priv->gt);
 
intel_runtime_pm_disable_interrupts(dev_priv);
 
@@ -2950,9 +2950,8 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_uc_runtime_resume(_priv->gt.uc);
+   intel_gt_runtime_resume(_priv->gt);
 
-   intel_gt_init_swizzling(_priv->gt);
i915_gem_restore_fences(dev_priv);
 
enable_rpm_wakeref_asserts(rpm);
@@ -3047,13 +3046,11 @@ static int intel_runtime_resume(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_uc_runtime_resume(_priv->gt.uc);
-
/*
 * No point of rolling back things in case of an error, as the best
 * we can do is to hope that things will still work (and disable RPM).
 */
-   intel_gt_init_swizzling(_priv->gt);
+   intel_gt_runtime_resume(_priv->gt);
i915_gem_restore_fences(dev_priv);
 
/*
-- 
2.22.0

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

[Intel-gfx] [PATCH v2 4/5] drm/i915/uc: Move uC early functions inside the GT ones

2019-07-30 Thread Daniele Ceraolo Spurio
uC is a subcomponent of GT, so initialize/clean it as part of it. The
wopcm_init_early doesn't have to be happen before the uC one, but since
in other parts of the code we consider WOPCM first do the same for
consistency.

v2: s/cleanup_early/late_release to match the caller

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Michal Wajdeczko  #v1
---
 drivers/gpu/drm/i915/gt/intel_gt.c|  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  2 +-
 drivers/gpu/drm/i915/i915_drv.c   | 10 --
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 5e76a426994a..362cac779afb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -22,6 +22,7 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
intel_gt_init_hangcheck(gt);
intel_gt_init_reset(gt);
intel_gt_pm_init_early(gt);
+   intel_uc_init_early(>uc);
 }
 
 void intel_gt_init_hw(struct drm_i915_private *i915)
@@ -246,5 +247,6 @@ void intel_gt_fini_scratch(struct intel_gt *gt)
 
 void intel_gt_late_release(struct intel_gt *gt)
 {
+   intel_uc_late_release(>uc);
intel_gt_fini_reset(gt);
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7794a6a1f932..ecd245cb6311 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -137,7 +137,7 @@ void intel_uc_init_early(struct intel_uc *uc)
sanitize_options_early(uc);
 }
 
-void intel_uc_cleanup_early(struct intel_uc *uc)
+void intel_uc_late_release(struct intel_uc *uc)
 {
guc_free_load_err_log(>guc);
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 25da51e95417..3ba2ac74c1a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -34,7 +34,7 @@ struct intel_uc {
 };
 
 void intel_uc_init_early(struct intel_uc *uc);
-void intel_uc_cleanup_early(struct intel_uc *uc);
+void intel_uc_late_release(struct intel_uc *uc);
 void intel_uc_init_mmio(struct intel_uc *uc);
 void intel_uc_fetch_firmwares(struct intel_uc *uc);
 void intel_uc_cleanup_firmwares(struct intel_uc *uc);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4b1bba018df7..86e024d063f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -921,6 +921,8 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
if (ret < 0)
return ret;
 
+   intel_wopcm_init_early(_priv->wopcm);
+
intel_gt_init_early(_priv->gt, dev_priv);
 
ret = i915_gem_init_early(dev_priv);
@@ -930,13 +932,11 @@ static int i915_driver_early_probe(struct 
drm_i915_private *dev_priv)
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
 
-   intel_wopcm_init_early(_priv->wopcm);
-   intel_uc_init_early(_priv->gt.uc);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
ret = intel_power_domains_init(dev_priv);
if (ret < 0)
-   goto err_uc;
+   goto err_gem;
intel_irq_init(dev_priv);
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
@@ -947,8 +947,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
 
return 0;
 
-err_uc:
-   intel_uc_cleanup_early(_priv->gt.uc);
+err_gem:
i915_gem_cleanup_early(dev_priv);
 err_workqueues:
intel_gt_late_release(_priv->gt);
@@ -965,7 +964,6 @@ static void i915_driver_late_release(struct 
drm_i915_private *dev_priv)
 {
intel_irq_fini(dev_priv);
intel_power_domains_cleanup(dev_priv);
-   intel_uc_cleanup_early(_priv->gt.uc);
i915_gem_cleanup_early(dev_priv);
intel_gt_late_release(_priv->gt);
i915_workqueues_cleanup(dev_priv);
-- 
2.22.0

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

[Intel-gfx] [PATCH v2 3/5] drm/i915/gt: Move gt_cleanup_early out of gem_cleanup_early

2019-07-30 Thread Daniele Ceraolo Spurio
We don't call the init_early function from within the gem code, so we
shouldn't do it for the cleanup either.

v2: while at it, s/gt_cleanup_early/gt_late_release (Chris)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  #v1
---
 drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_gt.h | 2 +-
 drivers/gpu/drm/i915/i915_drv.c| 2 ++
 drivers/gpu/drm/i915/i915_gem.c| 2 --
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f7e69db4019d..5e76a426994a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -244,7 +244,7 @@ void intel_gt_fini_scratch(struct intel_gt *gt)
i915_vma_unpin_and_release(>scratch, 0);
 }
 
-void intel_gt_cleanup_early(struct intel_gt *gt)
+void intel_gt_late_release(struct intel_gt *gt)
 {
intel_gt_fini_reset(gt);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 640bb0531f5b..123247ad32b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -30,7 +30,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
 void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
 void intel_gt_init_hw(struct drm_i915_private *i915);
 
-void intel_gt_cleanup_early(struct intel_gt *gt);
+void intel_gt_late_release(struct intel_gt *gt);
 
 void intel_gt_check_and_clear_faults(struct intel_gt *gt);
 void intel_gt_clear_error_registers(struct intel_gt *gt,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 761726818a22..4b1bba018df7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -951,6 +951,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
intel_uc_cleanup_early(_priv->gt.uc);
i915_gem_cleanup_early(dev_priv);
 err_workqueues:
+   intel_gt_late_release(_priv->gt);
i915_workqueues_cleanup(dev_priv);
return ret;
 }
@@ -966,6 +967,7 @@ static void i915_driver_late_release(struct 
drm_i915_private *dev_priv)
intel_power_domains_cleanup(dev_priv);
intel_uc_cleanup_early(_priv->gt.uc);
i915_gem_cleanup_early(dev_priv);
+   intel_gt_late_release(_priv->gt);
i915_workqueues_cleanup(dev_priv);
 
pm_qos_remove_request(_priv->sb_qos);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f681152d27fa..8438ce037e4b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1689,8 +1689,6 @@ void i915_gem_cleanup_early(struct drm_i915_private 
*dev_priv)
GEM_BUG_ON(atomic_read(_priv->mm.free_count));
WARN_ON(dev_priv->mm.shrink_count);
 
-   intel_gt_cleanup_early(_priv->gt);
-
i915_gemfs_fini(dev_priv);
 }
 
-- 
2.22.0

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

[Intel-gfx] [PATCH v2 1/5] drm/i915/uc: Don't enable communication twice on resume

2019-07-30 Thread Daniele Ceraolo Spurio
When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.

v2: split uc_resume and uc_runtime_resume to match the suspend
functions and to better differentiate the expected state in the 2
scenarios (Chris)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 35 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  1 +
 drivers/gpu/drm/i915/i915_drv.c   |  4 +--
 3 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6eb8bb3fa252..657fdcb70d00 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -233,11 +233,20 @@ static void guc_disable_interrupts(struct intel_guc *guc)
guc->interrupts.disable(guc);
 }
 
+#ifdef CONFIG_DRM_I915_DEBUG_GEM
+static bool guc_communication_enabled(struct intel_guc *guc)
+{
+   return guc->send != intel_guc_send_nop;
+}
+#endif
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
int ret;
 
+   GEM_BUG_ON(guc_communication_enabled(guc));
+
ret = intel_guc_ct_enable(>ct);
if (ret)
return ret;
@@ -550,7 +559,7 @@ void intel_uc_suspend(struct intel_uc *uc)
intel_uc_runtime_suspend(uc);
 }
 
-int intel_uc_resume(struct intel_uc *uc)
+static int __uc_resume(struct intel_uc *uc, bool enable_communication)
 {
struct intel_guc *guc = >guc;
int err;
@@ -558,7 +567,11 @@ int intel_uc_resume(struct intel_uc *uc)
if (!intel_guc_is_running(guc))
return 0;
 
-   guc_enable_communication(guc);
+   /* Make sure we enable communication if and only if it's disabled */
+   GEM_BUG_ON(enable_communication == guc_communication_enabled(guc));
+
+   if (enable_communication)
+   guc_enable_communication(guc);
 
err = intel_guc_resume(guc);
if (err) {
@@ -568,3 +581,21 @@ int intel_uc_resume(struct intel_uc *uc)
 
return 0;
 }
+
+int intel_uc_resume(struct intel_uc *uc)
+{
+   /*
+* When coming out of S3/S4 we sanitize and re-init the HW, so
+* communication is already re-enabled at this point.
+*/
+   return __uc_resume(uc, false);
+}
+
+int intel_uc_runtime_resume(struct intel_uc *uc)
+{
+   /*
+* During runtime resume we don't sanitize, so we need to re-init
+* communication as well.
+*/
+   return __uc_resume(uc, true);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index fe3362fd7706..25da51e95417 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -47,6 +47,7 @@ void intel_uc_reset_prepare(struct intel_uc *uc);
 void intel_uc_suspend(struct intel_uc *uc);
 void intel_uc_runtime_suspend(struct intel_uc *uc);
 int intel_uc_resume(struct intel_uc *uc);
+int intel_uc_runtime_resume(struct intel_uc *uc);
 
 static inline bool intel_uc_is_using_guc(struct intel_uc *uc)
 {
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f2d3d754af37..761726818a22 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2950,7 +2950,7 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_uc_resume(_priv->gt.uc);
+   intel_uc_runtime_resume(_priv->gt.uc);
 
intel_gt_init_swizzling(_priv->gt);
i915_gem_restore_fences(dev_priv);
@@ -3047,7 +3047,7 @@ static int intel_runtime_resume(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
-   intel_uc_resume(_priv->gt.uc);
+   intel_uc_runtime_resume(_priv->gt.uc);
 
/*
 * No point of rolling back things in case of an error, as the best
-- 
2.22.0

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

[Intel-gfx] [PATCH v2 2/5] drm/i915/uc: Move uC WOPCM setup in uc_init_hw

2019-07-30 Thread Daniele Ceraolo Spurio
The register we write are not WOPCM regs but uC ones related to how
GuC and HuC are going to use the WOPCM, so it makes logical sense
for them to be programmed as part of uc_init_hw. The WOPCM map on the
other side is not uC-specific (although that is our main use-case), so
keep that separate.

v2: move write_and_verify to uncore, fix log, re-use err_out tag,
add intel_wopcm_guc_base, fix log

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 47 ++
 drivers/gpu/drm/i915/i915_drv.h   |  3 +-
 drivers/gpu/drm/i915/i915_gem.c   |  8 +---
 drivers/gpu/drm/i915/intel_uncore.h   | 12 +
 drivers/gpu/drm/i915/intel_wopcm.c| 68 ---
 drivers/gpu/drm/i915/intel_wopcm.h| 18 +--
 6 files changed, 76 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 657fdcb70d00..7794a6a1f932 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -399,6 +399,49 @@ void intel_uc_sanitize(struct intel_uc *uc)
__uc_sanitize(uc);
 }
 
+/* Initialize and verify the uC regs related to uC positioning in WOPCM */
+static int uc_init_wopcm(struct intel_uc *uc)
+{
+   struct intel_gt *gt = uc_to_gt(uc);
+   struct intel_uncore *uncore = gt->uncore;
+   u32 base = intel_wopcm_guc_base(>i915->wopcm);
+   u32 size = intel_wopcm_guc_size(>i915->wopcm);
+   u32 huc_agent = intel_uc_is_using_huc(uc) ? HUC_LOADING_AGENT_GUC : 0;
+   u32 mask;
+   int err;
+
+   GEM_BUG_ON(!intel_uc_is_using_guc(uc));
+   GEM_BUG_ON(!(base & GUC_WOPCM_OFFSET_MASK));
+   GEM_BUG_ON(base & ~GUC_WOPCM_OFFSET_MASK);
+   GEM_BUG_ON(!(size & GUC_WOPCM_SIZE_MASK));
+   GEM_BUG_ON(size & ~GUC_WOPCM_SIZE_MASK);
+
+   mask = GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED;
+   err = intel_uncore_write_and_verify(uncore, GUC_WOPCM_SIZE, size, mask,
+   size | GUC_WOPCM_SIZE_LOCKED);
+   if (err)
+   goto err_out;
+
+   mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
+   err = intel_uncore_write_and_verify(uncore, DMA_GUC_WOPCM_OFFSET,
+   base | huc_agent, mask,
+   base | huc_agent |
+   GUC_WOPCM_OFFSET_VALID);
+   if (err)
+   goto err_out;
+
+   return 0;
+
+err_out:
+   DRM_ERROR("Failed to init uC WOPCM registers:\n");
+   DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
+ intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+   DRM_ERROR("GUC_WOPCM_SIZE=%#x\n",
+ intel_uncore_read(uncore, GUC_WOPCM_SIZE));
+
+   return err;
+}
+
 int intel_uc_init_hw(struct intel_uc *uc)
 {
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
@@ -411,6 +454,10 @@ int intel_uc_init_hw(struct intel_uc *uc)
 
GEM_BUG_ON(!intel_uc_fw_supported(>fw));
 
+   ret = uc_init_wopcm(uc);
+   if (ret)
+   goto err_out;
+
guc_reset_interrupts(guc);
 
/* WaEnableuKernelHeaderValidFix:skl */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3eeb21ff04c2..bdede6325d87 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2274,10 +2274,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
 
-/* Having GuC/HuC is not the same as using GuC/HuC */
+/* Having GuC is not the same as using GuC */
 #define USES_GUC(dev_priv) 
intel_uc_is_using_guc(&(dev_priv)->gt.uc)
 #define USES_GUC_SUBMISSION(dev_priv)  
intel_uc_is_using_guc_submission(&(dev_priv)->gt.uc)
-#define USES_HUC(dev_priv) 
intel_uc_is_using_huc(&(dev_priv)->gt.uc)
 
 #define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 65863e955f40..f681152d27fa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1240,14 +1240,8 @@ int i915_gem_init_hw(struct drm_i915_private *i915)
goto out;
}
 
-   ret = intel_wopcm_init_hw(>wopcm, gt);
-   if (ret) {
-   DRM_ERROR("Enabling WOPCM failed (%d)\n", ret);
-   goto out;
-   }
-
/* We can't enable contexts until all firmware is loaded */
-   ret = intel_uc_init_hw(>gt.uc);
+   ret = intel_uc_init_hw(>uc);
if (ret) {
DRM_ERROR("Enabling uc failed (%d)\n", ret);
goto out;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 2f6ffa309669..e603d210a34d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Report resv_obj allocation failure

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915: Report resv_obj allocation failure
URL   : https://patchwork.freedesktop.org/series/64450/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13811


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-u3:  [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#109100])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [PASS][3] -> [FAIL][4] ([fdo#108511])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][7] -> [WARN][8] ([fdo#109380])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7567u:   [PASS][9] -> [FAIL][10] ([fdo#109485])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][11] -> [FAIL][12] ([fdo#103167])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][13] -> [SKIP][14] ([fdo#109271]) +23 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [INCOMPLETE][15] ([fdo#107713] / [fdo#109100]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][17] ([fdo#107718]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][19] ([fdo#74]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13811/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 46)
--

  Missing(8): 

[Intel-gfx] [PATCH v7 1/4] drm/i915/bdw+: Move misc display IRQ handling to it own function

2019-07-30 Thread José Roberto de Souza
Just moving it to reduce the tabs and avoid break code lines.
No behavior changes intended here.

v2:
- Reading misc display IRQ outside of gen8_de_misc_irq_handler() as
other irq handlers (Dhinakaran)

Cc: Dhinakaran Pandiyan 
Reviewed-by: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_irq.c | 45 ++---
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fbe13bacd5b7..f54744644280 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2982,6 +2982,28 @@ static u32 gen8_de_pipe_fault_mask(struct 
drm_i915_private *dev_priv)
return GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
 }
 
+static void
+gen8_de_misc_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
+{
+   bool found = false;
+
+   if (iir & GEN8_DE_MISC_GSE) {
+   intel_opregion_asle_intr(dev_priv);
+   found = true;
+   }
+
+   if (iir & GEN8_DE_EDP_PSR) {
+   u32 psr_iir = I915_READ(EDP_PSR_IIR);
+
+   intel_psr_irq_handler(dev_priv, psr_iir);
+   I915_WRITE(EDP_PSR_IIR, psr_iir);
+   found = true;
+   }
+
+   if (!found)
+   DRM_ERROR("Unexpected DE Misc interrupt\n");
+}
+
 static irqreturn_t
 gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
 {
@@ -2992,29 +3014,12 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
if (master_ctl & GEN8_DE_MISC_IRQ) {
iir = I915_READ(GEN8_DE_MISC_IIR);
if (iir) {
-   bool found = false;
-
I915_WRITE(GEN8_DE_MISC_IIR, iir);
ret = IRQ_HANDLED;
-
-   if (iir & GEN8_DE_MISC_GSE) {
-   intel_opregion_asle_intr(dev_priv);
-   found = true;
-   }
-
-   if (iir & GEN8_DE_EDP_PSR) {
-   u32 psr_iir = I915_READ(EDP_PSR_IIR);
-
-   intel_psr_irq_handler(dev_priv, psr_iir);
-   I915_WRITE(EDP_PSR_IIR, psr_iir);
-   found = true;
-   }
-
-   if (!found)
-   DRM_ERROR("Unexpected DE Misc interrupt\n");
-   }
-   else
+   gen8_de_misc_irq_handler(dev_priv, iir);
+   } else {
DRM_ERROR("The master control interrupt lied (DE 
MISC)!\n");
+   }
}
 
if (INTEL_GEN(dev_priv) >= 11 && (master_ctl & GEN11_DE_HPD_IRQ)) {
-- 
2.22.0

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

[Intel-gfx] [PATCH v7 2/4] drm/i915: Add _TRANS2()

2019-07-30 Thread José Roberto de Souza
A new macro that is going to be added in a further patch will need to
adjust the offset returned by _MMIO_TRANS2(), so here adding
_TRANS2() and moving most of the implementation of _MMIO_TRANS2() to
it and while at it taking the opportunity to rename pipe to trans.

Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 
Reviewed-by: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 21306dd3790a..f4e1acc936b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -251,9 +251,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _MMIO_PIPE2(pipe, reg) 
_MMIO(INTEL_INFO(dev_priv)->pipe_offsets[pipe] - \
  
INTEL_INFO(dev_priv)->pipe_offsets[PIPE_A] + (reg) + \
  DISPLAY_MMIO_BASE(dev_priv))
-#define _MMIO_TRANS2(pipe, reg)
_MMIO(INTEL_INFO(dev_priv)->trans_offsets[(pipe)] - \
- 
INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_A] + (reg) + \
- DISPLAY_MMIO_BASE(dev_priv))
+#define _TRANS2(tran, reg) 
(INTEL_INFO(dev_priv)->trans_offsets[(tran)] - \
+
INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_A] + (reg) + \
+DISPLAY_MMIO_BASE(dev_priv))
+#define _MMIO_TRANS2(tran, reg)_MMIO(_TRANS2(tran, reg))
 #define _CURSOR2(pipe, reg)
_MMIO(INTEL_INFO(dev_priv)->cursor_offsets[(pipe)] - \
  
INTEL_INFO(dev_priv)->cursor_offsets[PIPE_A] + (reg) + \
  DISPLAY_MMIO_BASE(dev_priv))
-- 
2.22.0

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

[Intel-gfx] [PATCH v7 3/4] drm/i915/psr: Make PSR registers relative to transcoders

2019-07-30 Thread José Roberto de Souza
PSR registers are a mess, some have the full address while others just
have the additional offset from psr_mmio_base.

For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
0x800 and using it makes more difficult for people with an PSR
register address or PSR register name from from BSpec as i915 also
don't match the BSpec names.
For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are
only available in DDIA.

Other reason to make relative to transcoder is that since BDW every
transcoder have PSR registers, so in theory it should be possible to
have PSR enabled in a non-eDP transcoder.

So for BDW+ we can use _TRANS2() to get the register offset of any
PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
that will calculate the register offset for the single PSR instance,
noting that we are already guarded about trying to enable PSR in other
port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in
intel_psr_compute_config(), this check should only be valid for HSW
and will be changed in future.
PSR2 registers and PSR_EVENT was added after Haswell so that is why
_PSR_ADJ() is not used in some macros.

The only registers that can not be relative to transcoder are
PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
hardcoded.

Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
is the only PSR register that GVT have.

v5:
- Macros changed to be more explicit about HSW (Dhinakaran)
- Squashed with the patch that added the tran parameter to the
macros (Dhinakaran)

v6:
- Checking for interruption errors after module reload in the
transcoder that will be used (Dhinakaran)
- Using lowercase to the registers offsets

v7:
- Removing IS_HASWELL() from registers macros(Jani)

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Zhi Wang 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 104 +--
 drivers/gpu/drm/i915/gvt/handlers.c  |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |  18 ++--
 drivers/gpu/drm/i915/i915_drv.h  |   5 +-
 drivers/gpu/drm/i915/i915_reg.h  |  57 +
 5 files changed, 113 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 69d908e6a050..f06b4a0b9e26 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -390,7 +390,7 @@ static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
 
BUILD_BUG_ON(sizeof(aux_msg) > 20);
for (i = 0; i < sizeof(aux_msg); i += 4)
-   I915_WRITE(EDP_PSR_AUX_DATA(i >> 2),
+   I915_WRITE(EDP_PSR_AUX_DATA(dev_priv->psr.transcoder, i >> 2),
   intel_dp_pack_aux(_msg[i], sizeof(aux_msg) - i));
 
aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 0);
@@ -401,7 +401,7 @@ static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
 
/* Select only valid bits for SRD_AUX_CTL */
aux_ctl &= psr_aux_mask;
-   I915_WRITE(EDP_PSR_AUX_CTL, aux_ctl);
+   I915_WRITE(EDP_PSR_AUX_CTL(dev_priv->psr.transcoder), aux_ctl);
 }
 
 static void intel_psr_enable_sink(struct intel_dp *intel_dp)
@@ -491,8 +491,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 8)
val |= EDP_PSR_CRC_ENABLE;
 
-   val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
-   I915_WRITE(EDP_PSR_CTL, val);
+   val |= (I915_READ(EDP_PSR_CTL(dev_priv->psr.transcoder)) &
+   EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK);
+   I915_WRITE(EDP_PSR_CTL(dev_priv->psr.transcoder), val);
 }
 
 static void hsw_activate_psr2(struct intel_dp *intel_dp)
@@ -528,9 +529,9 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec is
 * recommending keep this bit unset while PSR2 is enabled.
 */
-   I915_WRITE(EDP_PSR_CTL, 0);
+   I915_WRITE(EDP_PSR_CTL(dev_priv->psr.transcoder), 0);
 
-   I915_WRITE(EDP_PSR2_CTL, val);
+   I915_WRITE(EDP_PSR2_CTL(dev_priv->psr.transcoder), val);
 }
 
 static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
@@ -606,10 +607,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
 
/*
 * HSW spec explicitly says PSR is tied to port A.
-* BDW+ platforms with DDI implementation of PSR have different
-* PSR registers per transcoder and we only implement transcoder EDP
-* ones. Since by Display design transcoder EDP is tied to port A
-* we can safely escape based on the port A.
+* BDW+ platforms have a instance of PSR registers per transcoder but
+* for now it only supports one instance of PSR, so lets keep it
+* hardcoded to PORT_A
 */
if (dig_port->base.port != PORT_A) {

[Intel-gfx] [PATCH v7 4/4] drm/i915: Add transcoder restriction to PSR2

2019-07-30 Thread José Roberto de Souza
According to PSR2_CTL definition on BSpec there is only one instance
of PSR2_CTL also ICL display overview state that PSR2 is only
supported in EDP transcoder, so now that is possible to have PSR in
any transcoder lets add this hardware restriction.

BSpec: 7713
BSpec: 20584
Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index f06b4a0b9e26..526990767c52 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -545,6 +545,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (!dev_priv->psr.sink_psr2_support)
return false;
 
+   if (crtc_state->cpu_transcoder != TRANSCODER_EDP) {
+   DRM_DEBUG_KMS("PSR2 is only supported in EDP transcoder\n");
+   return false;
+   }
+
/*
 * DSC and PSR2 cannot be enabled simultaneously. If a requested
 * resolution requires DSC to be enabled, priority is given to DSC
-- 
2.22.0

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/execlists: Always clear pending requests on reset

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/execlists: Always clear 
pending requests on reset
URL   : https://patchwork.freedesktop.org/series/64426/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13798_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_6581_full and 
Patchwork_13798_full:

### New IGT tests (2) ###

  * igt@i915_selftest@live_gem_contexts:
- Statuses : 7 pass(s)
- Exec time: [5.07, 35.74] s

  * igt@i915_selftest@live_gt_contexts:
- Statuses : 7 pass(s)
- Exec time: [0.46, 2.36] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@gem-mmap-cpu:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#108840])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb1/igt@i915_pm_...@gem-mmap-cpu.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-iclb2/igt@i915_pm_...@gem-mmap-cpu.html

  * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque:
- shard-glk:  [PASS][3] -> [FAIL][4] ([fdo#103232])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-glk1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-glk9/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb3/igt@kms_fbcon_...@fbc-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-iclb3/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  [PASS][7] -> [FAIL][8] ([fdo#105363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-glk7/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#105363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-hsw1/igt@kms_f...@flip-vs-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-hsw8/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][13] -> [INCOMPLETE][14] ([fdo#109507])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-skl7/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13798/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [22]: 

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Remove lrc default desc from GEM context

2019-07-30 Thread Kumar Valsan, Prathap
On Tue, Jul 30, 2019 at 02:30:26PM +0100, Chris Wilson wrote:
> We only compute the lrc_descriptor() on pinning the context, i.e.
> infrequently, so we do not benefit from storing the template as the
> addressing mode is also fixed for the lifetime of the intel_context.
> 
> Signed-off-by: Chris Wilson 
Reviewed-by: Prathap Kumar Valsan 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 28 ++-
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  2 --
>  drivers/gpu/drm/i915/gt/intel_lrc.c   | 12 +---
>  drivers/gpu/drm/i915/gvt/scheduler.c  |  3 --
>  4 files changed, 10 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index b28c7ca681a8..1b3dc7258ef2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -397,30 +397,6 @@ static void context_close(struct i915_gem_context *ctx)
>   i915_gem_context_put(ctx);
>  }
>  
> -static u32 default_desc_template(const struct drm_i915_private *i915,
> -  const struct i915_address_space *vm)
> -{
> - u32 address_mode;
> - u32 desc;
> -
> - desc = GEN8_CTX_VALID | GEN8_CTX_PRIVILEGE;
> -
> - address_mode = INTEL_LEGACY_32B_CONTEXT;
> - if (vm && i915_vm_is_4lvl(vm))
> - address_mode = INTEL_LEGACY_64B_CONTEXT;
> - desc |= address_mode << GEN8_CTX_ADDRESSING_MODE_SHIFT;
> -
> - if (IS_GEN(i915, 8))
> - desc |= GEN8_CTX_L3LLC_COHERENT;
> -
> - /* TODO: WaDisableLiteRestore when we start using semaphore
> -  * signalling between Command Streamers
> -  * ring->ctx_desc_template |= GEN8_CTX_FORCE_RESTORE;
> -  */
> -
> - return desc;
> -}
> -
>  static struct i915_gem_context *
>  __create_context(struct drm_i915_private *i915)
>  {
> @@ -459,7 +435,6 @@ __create_context(struct drm_i915_private *i915)
>   i915_gem_context_set_recoverable(ctx);
>  
>   ctx->ring_size = 4 * PAGE_SIZE;
> - ctx->desc_template = default_desc_template(i915, NULL);
>  
>   for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
>   ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
> @@ -478,8 +453,9 @@ __set_ppgtt(struct i915_gem_context *ctx, struct 
> i915_address_space *vm)
>   struct i915_gem_engines_iter it;
>   struct intel_context *ce;
>  
> + GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
> +
>   ctx->vm = i915_vm_get(vm);
> - ctx->desc_template = default_desc_template(ctx->i915, vm);
>  
>   for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
>   i915_vm_put(ce->vm);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 0ee61482ef94..a02d98494078 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -171,8 +171,6 @@ struct i915_gem_context {
>  
>   /** ring_size: size for allocating the per-engine ring buffer */
>   u32 ring_size;
> - /** desc_template: invariant fields for the HW context descriptor */
> - u32 desc_template;
>  
>   /** guilty_count: How many times this context has caused a GPU hang. */
>   atomic_t guilty_count;
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 5181d29d272e..232f40fcb490 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -417,13 +417,17 @@ lrc_descriptor(struct intel_context *ce, struct 
> intel_engine_cs *engine)
>   BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (BIT(GEN8_CTX_ID_WIDTH)));
>   BUILD_BUG_ON(GEN11_MAX_CONTEXT_HW_ID > (BIT(GEN11_SW_CTX_ID_WIDTH)));
>  
> - desc = ctx->desc_template;  /* bits  0-11 */
> - GEM_BUG_ON(desc & GENMASK_ULL(63, 12));
> + desc = INTEL_LEGACY_32B_CONTEXT;
> + if (i915_vm_is_4lvl(ce->vm))
> + desc = INTEL_LEGACY_64B_CONTEXT;
> + desc <<= GEN8_CTX_ADDRESSING_MODE_SHIFT;
> +
> + desc |= GEN8_CTX_VALID | GEN8_CTX_PRIVILEGE;
> + if (IS_GEN(engine->i915, 8))
> + desc |= GEN8_CTX_L3LLC_COHERENT;
>  
>   desc |= i915_ggtt_offset(ce->state) + LRC_HEADER_PAGES * PAGE_SIZE;
>   /* bits 12-31 */
> - GEM_BUG_ON(desc & GENMASK_ULL(63, 32));
> -
>   /*
>* The following 32bits are copied into the OA reports (dword 2).
>* Consider updating oa_get_render_ctx_id in i915_perf.c when changing
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index f40524b0e300..32ae6b5b7e16 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -291,9 +291,6 @@ shadow_context_descriptor_update(struct intel_context *ce,
>* 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove dangling forward declaration

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915: remove dangling forward declaration
URL   : https://patchwork.freedesktop.org/series/64447/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13810


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-cml-u2:  [PASS][1] -> [INCOMPLETE][2] ([fdo#110566])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_ctx_exec@basic:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_ctx_e...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-icl-u3/igt@gem_ctx_e...@basic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][5] -> [FAIL][6] ([fdo#103167])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][11] ([fdo#74]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13810/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 45)
--

  Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6586 -> Patchwork_13810

  CI-20190529: 20190529
  CI_DRM_6586: 066993443a56467f54fdcf560e89378f8e93a15b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13810: 0eea87f28dcac90050d608c751a65d7523a8574c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0eea87f28dca drm/i915: remove dangling forward declaration

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Don't sanitize enable_guc

2019-07-30 Thread Patchwork
== Series Details ==

Series: Don't sanitize enable_guc
URL   : https://patchwork.freedesktop.org/series/64446/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6586 -> Patchwork_13809


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][1] -> [SKIP][2] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][3] -> [FAIL][4] ([fdo#103167])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3:  [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[INCOMPLETE][11] ([fdo#74]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html

  * igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u:   [SKIP][13] ([fdo#109271]) -> [PASS][14] +23 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6586/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13809/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#74]: https://bugs.freedesktop.org/show_bug.cgi?id=74


Participating hosts (54 -> 46)
--

  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6586 -> Patchwork_13809

  CI-20190529: 20190529
  CI_DRM_6586: 066993443a56467f54fdcf560e89378f8e93a15b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13809: 8b60c2d8e654529e5514066e6dd905b73a2b2bad @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8b60c2d8e654 drm/i915/uc: Stop sanitizing enable_guc modparam
b73f7436e919 drm/i915/guc: Use dedicated flag to track submission mode
26060db5e380 drm/i915/uc: Consider enable_guc modparam during fw selection

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915/ehl: Don't forget to handle port C's hotplug interrupts

2019-07-30 Thread Matt Roper
We're mostly re-using ICL's interrupt handling on EHL, but we still need
to remember to account for the extra combo port that EHL has.  Use TGP's
mask (which includes combo port C) rather than ICP's mask when
appropriate.  Let's also skip reading TC-specific registers on this
platform since EHL doesn't have any TC ports.

v2: Base setup of SHOTPLUG_CTL_TC on whether the tc pin mask is non-zero
rather than performing another PCH type check.  (Jose)

Cc: José Roberto de Souza 
Cc: Vivek Kasireddy 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_irq.c | 41 -
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fbe13bacd5b7..33ac5d7e1e9e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1746,6 +1746,8 @@ static bool icp_ddi_port_hotplug_long_detect(enum hpd_pin 
pin, u32 val)
return val & ICP_DDIA_HPD_LONG_DETECT;
case HPD_PORT_B:
return val & ICP_DDIB_HPD_LONG_DETECT;
+   case HPD_PORT_C:
+   return val & TGP_DDIC_HPD_LONG_DETECT;
default:
return false;
}
@@ -2605,10 +2607,18 @@ static void cpt_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
 static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir,
const u32 *pins)
 {
-   u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
-   u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+   u32 ddi_hotplug_trigger;
+   u32 tc_hotplug_trigger;
u32 pin_mask = 0, long_mask = 0;
 
+   if (HAS_PCH_MCC(dev_priv)) {
+   ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+   tc_hotplug_trigger = 0;
+   } else {
+   ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
+   tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+   }
+
if (ddi_hotplug_trigger) {
u32 dig_hotplug_reg;
 
@@ -3920,9 +3930,11 @@ static void icp_hpd_detection_setup(struct 
drm_i915_private *dev_priv,
hotplug |= ddi_hotplug_enable_mask;
I915_WRITE(SHOTPLUG_CTL_DDI, hotplug);
 
-   hotplug = I915_READ(SHOTPLUG_CTL_TC);
-   hotplug |= tc_hotplug_enable_mask;
-   I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
+   if (tc_hotplug_enable_mask) {
+   hotplug = I915_READ(SHOTPLUG_CTL_TC);
+   hotplug |= tc_hotplug_enable_mask;
+   I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
+   }
 }
 
 static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
@@ -3938,6 +3950,18 @@ static void icp_hpd_irq_setup(struct drm_i915_private 
*dev_priv)
ICP_TC_HPD_ENABLE_MASK);
 }
 
+static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
+{
+   u32 hotplug_irqs, enabled_irqs;
+
+   hotplug_irqs = SDE_DDI_MASK_TGP;
+   enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_mcc);
+
+   ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
+
+   icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK, 0);
+}
+
 static void tgp_hpd_irq_setup(struct drm_i915_private *dev_priv)
 {
u32 hotplug_irqs, enabled_irqs;
@@ -4442,6 +4466,8 @@ static void icp_irq_postinstall(struct drm_i915_private 
*dev_priv)
if (HAS_PCH_TGP(dev_priv))
icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK,
TGP_TC_HPD_ENABLE_MASK);
+   else if (HAS_PCH_MCC(dev_priv))
+   icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK, 0);
else
icp_hpd_detection_setup(dev_priv, ICP_DDI_HPD_ENABLE_MASK,
ICP_TC_HPD_ENABLE_MASK);
@@ -4974,7 +5000,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (I915_HAS_HOTPLUG(dev_priv))
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else {
-   if (INTEL_GEN(dev_priv) >= 11)
+   if (HAS_PCH_MCC(dev_priv))
+   /* EHL doesn't need most of gen11_hpd_irq_setup */
+   dev_priv->display.hpd_irq_setup = mcc_hpd_irq_setup;
+   else if (INTEL_GEN(dev_priv) >= 11)
dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
else if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Don't forget to handle port C's hotplug interrupts

2019-07-30 Thread Souza, Jose
On Tue, 2019-07-30 at 14:35 -0700, Matt Roper wrote:
> We're mostly re-using ICL's interrupt handling on EHL, but we still
> need
> to remember to account for the extra combo port that EHL has.  Use
> TGP's
> mask (which includes combo port C) rather than ICP's mask when
> appropriate.  Let's also skip reading TC-specific registers on this
> platform since EHL doesn't have any TC ports.
> 
> Cc: José Roberto de Souza 
> Cc: Vivek Kasireddy 
> Cc: Lucas De Marchi 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 41 ---
> --
>  1 file changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index fbe13bacd5b7..621ca0edcd42 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1746,6 +1746,8 @@ static bool
> icp_ddi_port_hotplug_long_detect(enum hpd_pin pin, u32 val)
>   return val & ICP_DDIA_HPD_LONG_DETECT;
>   case HPD_PORT_B:
>   return val & ICP_DDIB_HPD_LONG_DETECT;
> + case HPD_PORT_C:
> + return val & TGP_DDIC_HPD_LONG_DETECT;
>   default:
>   return false;
>   }
> @@ -2605,10 +2607,18 @@ static void cpt_irq_handler(struct
> drm_i915_private *dev_priv, u32 pch_iir)
>  static void icp_irq_handler(struct drm_i915_private *dev_priv, u32
> pch_iir,
>   const u32 *pins)
>  {
> - u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> - u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> + u32 ddi_hotplug_trigger;
> + u32 tc_hotplug_trigger;
>   u32 pin_mask = 0, long_mask = 0;
>  
> + if (HAS_PCH_MCC(dev_priv)) {
> + ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
> + tc_hotplug_trigger = 0;
> + } else {
> + ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> + tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> + }
> +
>   if (ddi_hotplug_trigger) {
>   u32 dig_hotplug_reg;
>  
> @@ -3920,9 +3930,11 @@ static void icp_hpd_detection_setup(struct
> drm_i915_private *dev_priv,
>   hotplug |= ddi_hotplug_enable_mask;
>   I915_WRITE(SHOTPLUG_CTL_DDI, hotplug);
>  
> - hotplug = I915_READ(SHOTPLUG_CTL_TC);
> - hotplug |= tc_hotplug_enable_mask;
> - I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
> + if (!HAS_PCH_MCC(dev_priv)) {

Maybe if (tc_hotplug_enable_mask)?

Other than that:
Reviewed-by: José Roberto de Souza 

> + hotplug = I915_READ(SHOTPLUG_CTL_TC);
> + hotplug |= tc_hotplug_enable_mask;
> + I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
> + }
>  }
>  
>  static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
> @@ -3938,6 +3950,18 @@ static void icp_hpd_irq_setup(struct
> drm_i915_private *dev_priv)
>   ICP_TC_HPD_ENABLE_MASK);
>  }
>  
> +static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
> +{
> + u32 hotplug_irqs, enabled_irqs;
> +
> + hotplug_irqs = SDE_DDI_MASK_TGP;
> + enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_mcc);
> +
> + ibx_display_interrupt_update(dev_priv, hotplug_irqs,
> enabled_irqs);
> +
> + icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK, 0);
> +}
> +
>  static void tgp_hpd_irq_setup(struct drm_i915_private *dev_priv)
>  {
>   u32 hotplug_irqs, enabled_irqs;
> @@ -4442,6 +4466,8 @@ static void icp_irq_postinstall(struct
> drm_i915_private *dev_priv)
>   if (HAS_PCH_TGP(dev_priv))
>   icp_hpd_detection_setup(dev_priv,
> TGP_DDI_HPD_ENABLE_MASK,
>   TGP_TC_HPD_ENABLE_MASK);
> + else if (HAS_PCH_MCC(dev_priv))
> + icp_hpd_detection_setup(dev_priv,
> TGP_DDI_HPD_ENABLE_MASK, 0);
>   else
>   icp_hpd_detection_setup(dev_priv,
> ICP_DDI_HPD_ENABLE_MASK,
>   ICP_TC_HPD_ENABLE_MASK);
> @@ -4974,7 +5000,10 @@ void intel_irq_init(struct drm_i915_private
> *dev_priv)
>   if (I915_HAS_HOTPLUG(dev_priv))
>   dev_priv->display.hpd_irq_setup =
> i915_hpd_irq_setup;
>   } else {
> - if (INTEL_GEN(dev_priv) >= 11)
> + if (HAS_PCH_MCC(dev_priv))
> + /* EHL doesn't need most of gen11_hpd_irq_setup
> */
> + dev_priv->display.hpd_irq_setup =
> mcc_hpd_irq_setup;
> + else if (INTEL_GEN(dev_priv) >= 11)
>   dev_priv->display.hpd_irq_setup =
> gen11_hpd_irq_setup;
>   else if (IS_GEN9_LP(dev_priv))
>   dev_priv->display.hpd_irq_setup =
> bxt_hpd_irq_setup;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/oa: add content to Makefile

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/oa: add content to Makefile
URL   : https://patchwork.freedesktop.org/series/64424/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13797_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] ([fdo#103665])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl3/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-kbl6/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-iclb8/igt@gem_exec_balan...@smoke.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +5 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl5/igt@i915_susp...@sysfs-reader.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-apl8/igt@i915_susp...@sysfs-reader.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw:  [PASS][7] -> [INCOMPLETE][8] ([fdo#103540])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-hsw7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-hsw7/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@no_drrs:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#108341])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb2/igt@kms_psr@no_drrs.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-iclb8/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][19] -> [FAIL][20] ([fdo#99912])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@kms_setm...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-apl3/igt@kms_setm...@basic.html

  * igt@perf@polling:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#110728])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl6/igt@p...@polling.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-skl6/igt@p...@polling.html

  
 Possible fixes 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-apl:  [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +4 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13797/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][25] ([fdo#104108]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl7/igt@gem_soft...@noreloc-s3.html
   [26]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Don't sanitize enable_guc

2019-07-30 Thread Patchwork
== Series Details ==

Series: Don't sanitize enable_guc
URL   : https://patchwork.freedesktop.org/series/64446/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
26060db5e380 drm/i915/uc: Consider enable_guc modparam during fw selection
-:81: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'i915_modparams.enable_guc < 0'
#81: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:137:
+   if ((i915_modparams.enable_guc < 0) && (p < INTEL_ICELAKE))

-:81: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'p < 
INTEL_ICELAKE'
#81: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:137:
+   if ((i915_modparams.enable_guc < 0) && (p < INTEL_ICELAKE))

-:85: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#85: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:141:
+static const char* __override_guc_firmware_path(void)

-:88: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'i915_modparams.enable_guc < 0'
#88: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:144:
+   if ((i915_modparams.enable_guc < 0) ||
+   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))

-:94: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#94: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:150:
+static const char* __override_huc_firmware_path(void)

-:96: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'i915_modparams.enable_guc < 0'
#96: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:152:
+   if ((i915_modparams.enable_guc < 0) ||
+   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))

total: 2 errors, 0 warnings, 4 checks, 79 lines checked
b73f7436e919 drm/i915/guc: Use dedicated flag to track submission mode
8b60c2d8e654 drm/i915/uc: Stop sanitizing enable_guc modparam

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

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Sasha Levin

On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:

Hi Sasha,


Hello!


On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin  wrote:


Hi,

[This is an automated email]


Where did you get this patch from? Since stable needs patches merged


This bot grabs them from various mailing lists.


on Linus tree,
shouldn't your scripts run to try backporting only patches from there?


There's a note a few lines down that says:

   "NOTE: The patch will not be queued to stable trees until it is upstream."

Otherwise, no, there's no rule that says we can't look at patches before
they are upstream. We can't queue them up, but we sure can poke them.

The reasoning behind this is that it's easier to get replies (and
backports) from folks who are actively working on the patch now, rather
than a few weeks later when Greg sends his "FAILED:" mails and gets
ignored because said folks have moved on.

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

[Intel-gfx] [PATCH] drm/i915/ehl: Don't forget to handle port C's hotplug interrupts

2019-07-30 Thread Matt Roper
We're mostly re-using ICL's interrupt handling on EHL, but we still need
to remember to account for the extra combo port that EHL has.  Use TGP's
mask (which includes combo port C) rather than ICP's mask when
appropriate.  Let's also skip reading TC-specific registers on this
platform since EHL doesn't have any TC ports.

Cc: José Roberto de Souza 
Cc: Vivek Kasireddy 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_irq.c | 41 -
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fbe13bacd5b7..621ca0edcd42 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1746,6 +1746,8 @@ static bool icp_ddi_port_hotplug_long_detect(enum hpd_pin 
pin, u32 val)
return val & ICP_DDIA_HPD_LONG_DETECT;
case HPD_PORT_B:
return val & ICP_DDIB_HPD_LONG_DETECT;
+   case HPD_PORT_C:
+   return val & TGP_DDIC_HPD_LONG_DETECT;
default:
return false;
}
@@ -2605,10 +2607,18 @@ static void cpt_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
 static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir,
const u32 *pins)
 {
-   u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
-   u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+   u32 ddi_hotplug_trigger;
+   u32 tc_hotplug_trigger;
u32 pin_mask = 0, long_mask = 0;
 
+   if (HAS_PCH_MCC(dev_priv)) {
+   ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+   tc_hotplug_trigger = 0;
+   } else {
+   ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
+   tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+   }
+
if (ddi_hotplug_trigger) {
u32 dig_hotplug_reg;
 
@@ -3920,9 +3930,11 @@ static void icp_hpd_detection_setup(struct 
drm_i915_private *dev_priv,
hotplug |= ddi_hotplug_enable_mask;
I915_WRITE(SHOTPLUG_CTL_DDI, hotplug);
 
-   hotplug = I915_READ(SHOTPLUG_CTL_TC);
-   hotplug |= tc_hotplug_enable_mask;
-   I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
+   if (!HAS_PCH_MCC(dev_priv)) {
+   hotplug = I915_READ(SHOTPLUG_CTL_TC);
+   hotplug |= tc_hotplug_enable_mask;
+   I915_WRITE(SHOTPLUG_CTL_TC, hotplug);
+   }
 }
 
 static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
@@ -3938,6 +3950,18 @@ static void icp_hpd_irq_setup(struct drm_i915_private 
*dev_priv)
ICP_TC_HPD_ENABLE_MASK);
 }
 
+static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
+{
+   u32 hotplug_irqs, enabled_irqs;
+
+   hotplug_irqs = SDE_DDI_MASK_TGP;
+   enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_mcc);
+
+   ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
+
+   icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK, 0);
+}
+
 static void tgp_hpd_irq_setup(struct drm_i915_private *dev_priv)
 {
u32 hotplug_irqs, enabled_irqs;
@@ -4442,6 +4466,8 @@ static void icp_irq_postinstall(struct drm_i915_private 
*dev_priv)
if (HAS_PCH_TGP(dev_priv))
icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK,
TGP_TC_HPD_ENABLE_MASK);
+   else if (HAS_PCH_MCC(dev_priv))
+   icp_hpd_detection_setup(dev_priv, TGP_DDI_HPD_ENABLE_MASK, 0);
else
icp_hpd_detection_setup(dev_priv, ICP_DDI_HPD_ENABLE_MASK,
ICP_TC_HPD_ENABLE_MASK);
@@ -4974,7 +5000,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (I915_HAS_HOTPLUG(dev_priv))
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else {
-   if (INTEL_GEN(dev_priv) >= 11)
+   if (HAS_PCH_MCC(dev_priv))
+   /* EHL doesn't need most of gen11_hpd_irq_setup */
+   dev_priv->display.hpd_irq_setup = mcc_hpd_irq_setup;
+   else if (INTEL_GEN(dev_priv) >= 11)
dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
else if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-- 
2.20.1

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

[Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_schedule: Avoid using borked engines

2019-07-30 Thread Chris Wilson
Check for viability of store-dword before use.

Signed-off-by: Chris Wilson 
---
 tests/i915/gem_exec_schedule.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 4ccacba41..6e8466299 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -282,9 +282,11 @@ static void smoketest(int fd, unsigned ring, unsigned 
timeout)
nengine = 0;
if (ring == ALL_ENGINES) {
for_each_physical_engine(fd, engine)
-   engines[nengine++] = engine;
+   if (gem_can_store_dword(fd, engine))
+   engines[nengine++] = engine;
} else {
-   engines[nengine++] = ring;
+   if (gem_can_store_dword(fd, ring))
+   engines[nengine++] = ring;
}
igt_require(nengine);
 
-- 
2.22.0

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

[Intel-gfx] [PATCH i-g-t 2/2] i915/gem_ctx_engine: Drip feed requests into 'independent'

2019-07-30 Thread Chris Wilson
The intent of the test is to exercise that each channel in the engine[]
is an independent context/ring/timeline. It setups 64 channels pointing
to rcs0 and then submits one request to each in turn waiting on a
timeline that will force them to run out of submission order. They can
only run in fence order and not submission order if the timelines of
each channel are truly independent.

However, we released the fences en masse, and once the requests are
ready they are independent any may be executed in any order by the HW,
especially true with timeslicing that may reorder the requests on a
whim. So instead of releasing all requests at once, increment the
timeline step by step and check we get our results advancing. If the
requests can not be run in fence order and fall back to submission
order, we will time out waiting for our incremental results and trigger
a few GPU hangs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110987
Signed-off-by: Chris Wilson 
---
 tests/i915/gem_ctx_engines.c | 39 +++-
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 8c66fb261..2e80d0f3e 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -405,6 +405,14 @@ static void execute_allforone(int i915)
gem_context_destroy(i915, param.ctx_id);
 }
 
+static uint32_t read_result(int timeline, uint32_t *map, int idx)
+{
+   sw_sync_timeline_inc(timeline, 1);
+   while (!READ_ONCE(map[idx]))
+   ;
+   return map[idx];
+}
+
 static void independent(int i915)
 {
 #define RCS_TIMESTAMP (0x2000 + 0x358)
@@ -438,6 +446,12 @@ static void independent(int i915)
memset(, 0, sizeof(engines)); /* All rcs0 */
gem_context_set_param(i915, );
 
+   gem_set_caching(i915, results.handle, I915_CACHING_CACHED);
+   map = gem_mmap__cpu(i915, results.handle, 0, 4096, PROT_READ);
+   gem_set_domain(i915, results.handle,
+  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+   memset(map, 0, 4096);
+
for (int i = 0; i < I915_EXEC_RING_MASK + 1; i++) {
struct drm_i915_gem_exec_object2 obj[2] = {
results, /* write hazard lies! */
@@ -472,21 +486,21 @@ static void independent(int i915)
gem_close(i915, obj[1].handle);
close(execbuf.rsvd2);
}
-   close(timeline);
-   gem_sync(i915, results.handle);
-
-   map = gem_mmap__cpu(i915, results.handle, 0, 4096, PROT_READ);
-   gem_set_domain(i915, results.handle, I915_GEM_DOMAIN_CPU, 0);
-   gem_close(i915, results.handle);
 
-   last = map[0];
+   last = read_result(timeline, map, 0);
for (int i = 1; i < I915_EXEC_RING_MASK + 1; i++) {
-   igt_assert_f((map[i] - last) > 0,
-"Engine instance [%d] executed too late\n", i);
-   last = map[i];
+   uint32_t t = read_result(timeline, map, i);
+   igt_assert_f(t - last > 0,
+"Engine instance [%d] executed too late, previous 
timestamp %08x, now %08x\n",
+i, last, t);
+   last = t;
}
munmap(map, 4096);
 
+   close(timeline);
+   gem_sync(i915, results.handle);
+   gem_close(i915, results.handle);
+
gem_context_destroy(i915, param.ctx_id);
 }
 
@@ -500,6 +514,8 @@ igt_main
 
gem_require_contexts(i915);
igt_require(has_context_engines(i915));
+
+   igt_fork_hang_detector(i915);
}
 
igt_subtest("invalid-engines")
@@ -519,4 +535,7 @@ igt_main
 
igt_subtest("independent")
independent(i915);
+
+   igt_fixture
+   igt_stop_hang_detector();
 }
-- 
2.22.0

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915/uc: move uC WOPCM setup in uc_init_hw

2019-07-30 Thread Daniele Ceraolo Spurio



On 7/30/19 7:39 AM, Michal Wajdeczko wrote:
On Tue, 30 Jul 2019 01:47:22 +0200, Daniele Ceraolo Spurio 
 wrote:



The register we write are not WOPCM regs but uC ones related to how
GuC and HuC are going to use the WOPCM, so it makes logical sense
for them to be programmed as part of uc_init_hw. The wopcm map on the


s/wopcm/WOPCM


other side is not uC-specific (although that is our main use-case), so
keep that separate.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 62 
 drivers/gpu/drm/i915/i915_gem.c   |  8 +---
 drivers/gpu/drm/i915/intel_wopcm.c    | 68 ---
 drivers/gpu/drm/i915/intel_wopcm.h    |  3 --
 4 files changed, 63 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c

index fafa9be1e12a..2f71f3704c46 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -390,6 +390,63 @@ void intel_uc_sanitize(struct intel_uc *uc)
 __uc_sanitize(uc);
 }
+static int
+write_and_verify(struct intel_gt *gt,
+ i915_reg_t reg, u32 val, u32 mask, u32 locked_bit)


as this function is more 'uncore' than 'gt' I would define it as:

static inline bool
intel_uncore_write_and_verify(struct intel_uncore *uncore,
   i915_reg_t reg, u32 value,
   u32 expected_value, u32 mask)
in intel_uncore.h



ok


+{
+    struct intel_uncore *uncore = gt->uncore;
+    u32 reg_val;
+
+    GEM_BUG_ON(val & ~mask);
+
+    intel_uncore_write(uncore, reg, val);
+
+    reg_val = intel_uncore_read(uncore, reg);
+
+    return (reg_val & mask) != (val | locked_bit) ? -EIO : 0;
+}
+
+/* Initialize and verify the uC regs related to uC positioning in 
WOPCM */

+int uc_wopcm_init_hw(struct intel_uc *uc)


static int uc_init_wopcm()


+{
+    struct intel_gt *gt = uc_to_gt(uc);
+    struct intel_wopcm *wopcm = >i915->wopcm;
+    struct intel_uncore *uncore = gt->uncore;
+    u32 huc_agent;
+    u32 mask;
+    int err;
+
+    GEM_BUG_ON(!HAS_GT_UC(gt->i915));
+    GEM_BUG_ON(!intel_uc_is_using_guc(uc));
+    GEM_BUG_ON(!wopcm->guc.size);


on one hand there is intel_wopcm_guc_size() that can be used here,
but on other hand there is no intel_wopcm_guc_base ;(


+    GEM_BUG_ON(!wopcm->guc.base);
+
+    err = write_and_verify(gt, GUC_WOPCM_SIZE, wopcm->guc.size,
+   GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
+   GUC_WOPCM_SIZE_LOCKED);


hmm, as these are write-once registers, maybe we should write only once
(not here) and only verify every time in uc_init_hw ?



AFAIK they don't survive deep sleep states even if they're write once, 
so we do need to write them again in some occasions. We could read them 
first and only write them if they're not locked, but IMO it's simpler to 
just unconditionally emit the write every time.



+    if (err)
+    goto err_out;
+
+    huc_agent = intel_uc_is_using_huc(uc) ? HUC_LOADING_AGENT_GUC : 0;
+    mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
+    err = write_and_verify(gt, DMA_GUC_WOPCM_OFFSET,
+   wopcm->guc.base | huc_agent, mask,
+   GUC_WOPCM_OFFSET_VALID);
+    if (err)
+    goto err_out;
+
+    return 0;
+
+err_out:
+    DRM_ERROR("Failed to init WOPCM registers:\n");


In commit msg you said that these are not WOPCM registers ;)



ops :)


+    DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
+  intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+    DRM_ERROR("GUC_WOPCM_SIZE=%#x\n",
+  intel_uncore_read(uncore, GUC_WOPCM_SIZE));


btw, we can avoid extra read by reporting already failed write
in intel_uncore_write_and_verify()



intel_uncore_write_and_verify(0 is better kept generic using a bool 
return IMO. We only do the extra reads in an error path anyway, so it 
shouldn't be an issue.



+
+    return err;
+}
+
 int intel_uc_init_hw(struct intel_uc *uc)
 {
 struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
@@ -402,6 +459,10 @@ int intel_uc_init_hw(struct intel_uc *uc)
GEM_BUG_ON(!intel_uc_fw_supported(>fw));
+    ret = uc_wopcm_init_hw(uc);
+    if (ret)
+    goto out;


it should be harmless to reuse existing err_out label



ack.

Thanks,
Daniele


+
 guc_reset_interrupts(guc);
/* WaEnableuKernelHeaderValidFix:skl */
@@ -486,6 +547,7 @@ int intel_uc_init_hw(struct intel_uc *uc)
 if (GEM_WARN_ON(ret == -EIO))
 ret = -EINVAL;
+out:
 dev_err(i915->drm.dev, "GuC initialization failed %d\n", ret);
 return ret;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 01dd0d1d9bf6..ae4e7cc3e3f9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1239,14 +1239,8 @@ int i915_gem_init_hw(struct drm_i915_private 
*i915)

 goto out;
 }
-    ret = intel_wopcm_init_hw(>wopcm, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make i915_selftest.h self-contained

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915: make i915_selftest.h self-contained
URL   : https://patchwork.freedesktop.org/series/64445/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6585 -> Patchwork_13808


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-u3/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-icl-u3/igt@debugfs_test@read_all_entries.html

  * igt@i915_selftest@live_hangcheck:
- fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / 
[fdo#108569])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][7] -> [WARN][8] ([fdo#109483] / [fdo#56])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][9] -> [FAIL][10] ([fdo#109485])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-dsi: [PASS][11] -> [FAIL][12] ([fdo#103167])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html
- fi-hsw-peppy:   [PASS][13] -> [DMESG-WARN][14] ([fdo#102614])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-u3/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-icl-u3/igt@i915_module_l...@reload.html

  * igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u:   [SKIP][17] ([fdo#109271]) -> [PASS][18] +23 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13808/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html

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

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#56]: https://bugs.freedesktop.org/show_bug.cgi?id=56


Participating hosts (54 -> 46)
--

  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6585 -> Patchwork_13808

  CI-20190529: 20190529
  CI_DRM_6585: e3758948ece56bbac86e96a326fa6b01ec05d202 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 

[Intel-gfx] [PATCH] drm/i915: Report resv_obj allocation failure

2019-07-30 Thread Chris Wilson
Since commit 64d6c500a384 ("drm/i915: Generalise GPU activity
tracking"), we have been prepared for i915_vma_move_to_active() to fail.
We can take advantage of this to report the failure for allocating the
shared-fence slot in the reservation_object.

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

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index eb16a1a93bbc..7734d6218ce7 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -886,23 +886,6 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(>obj->userfault_link);
 }
 
-static void export_fence(struct i915_vma *vma,
-struct i915_request *rq,
-unsigned int flags)
-{
-   struct reservation_object *resv = vma->resv;
-
-   /*
-* Ignore errors from failing to allocate the new fence, we can't
-* handle an error right now. Worst case should be missed
-* synchronisation leading to rendering corruption.
-*/
-   if (flags & EXEC_OBJECT_WRITE)
-   reservation_object_add_excl_fence(resv, >fence);
-   else if (reservation_object_reserve_shared(resv, 1) == 0)
-   reservation_object_add_shared_fence(resv, >fence);
-}
-
 int i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq,
unsigned int flags)
@@ -926,14 +909,20 @@ int i915_vma_move_to_active(struct i915_vma *vma,
if (unlikely(err))
return err;
 
-   obj->write_domain = 0;
if (flags & EXEC_OBJECT_WRITE) {
-   obj->write_domain = I915_GEM_DOMAIN_RENDER;
-
if (intel_fb_obj_invalidate(obj, ORIGIN_CS))
__i915_active_request_set(>frontbuffer_write, rq);
 
+   reservation_object_add_excl_fence(vma->resv, >fence);
+   obj->write_domain = I915_GEM_DOMAIN_RENDER;
obj->read_domains = 0;
+   } else {
+   err = reservation_object_reserve_shared(vma->resv, 1);
+   if (unlikely(err))
+   return err;
+
+   reservation_object_add_shared_fence(vma->resv, >fence);
+   obj->write_domain = 0;
}
obj->read_domains |= I915_GEM_GPU_DOMAINS;
obj->mm.dirty = true;
@@ -941,8 +930,6 @@ int i915_vma_move_to_active(struct i915_vma *vma,
if (flags & EXEC_OBJECT_NEEDS_FENCE)
__i915_active_request_set(>last_fence, rq);
 
-   export_fence(vma, rq, flags);
-
GEM_BUG_ON(!i915_vma_is_active(vma));
return 0;
 }
-- 
2.22.0

___
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/execlists: Always clear pending requests on reset

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Always clear pending requests on reset
URL   : https://patchwork.freedesktop.org/series/64423/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581_full -> Patchwork_13796_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-suspend:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([fdo#104108]) +2 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl8/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-skl3/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-iclb7/igt@gem_exec_balan...@smoke.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / 
[fdo#107807])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-skl9/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_draw_crc@draw-method-rgb565-blt-xtiled:
- shard-snb:  [PASS][9] -> [SKIP][10] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-snb7/igt@kms_draw_...@draw-method-rgb565-blt-xtiled.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-snb2/igt@kms_draw_...@draw-method-rgb565-blt-xtiled.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl:  [PASS][11] -> [FAIL][12] ([fdo#100368])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-skl3/igt@kms_f...@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +4 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +6 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-iclb7/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][21] -> [FAIL][22] ([fdo#99912])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-apl1/igt@kms_setm...@basic.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-apl4/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][23] ([fdo#104108]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/shard-skl7/igt@gem_soft...@noreloc-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13796/shard-skl1/igt@gem_soft...@noreloc-s3.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  

[Intel-gfx] ✓ Fi.CI.BAT: success for Tiger Lake: MOCS table handling (rev3)

2019-07-30 Thread Patchwork
== Series Details ==

Series: Tiger Lake: MOCS table handling (rev3)
URL   : https://patchwork.freedesktop.org/series/64275/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6585 -> Patchwork_13807


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-cml-u:   [PASS][1] -> [INCOMPLETE][2] ([fdo#110566])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-cml-u/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u:   [PASS][3] -> [FAIL][4] ([fdo#107707])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#109485])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@prime_vgem@basic-read:
- fi-icl-u3:  [PASS][9] -> [DMESG-WARN][10] ([fdo#107724])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-u3/igt@prime_v...@basic-read.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-icl-u3/igt@prime_v...@basic-read.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6585/fi-icl-u3/igt@i915_module_l...@reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13807/fi-icl-u3/igt@i915_module_l...@reload.html

  
  [fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566


Participating hosts (54 -> 46)
--

  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6585 -> Patchwork_13807

  CI-20190529: 20190529
  CI_DRM_6585: e3758948ece56bbac86e96a326fa6b01ec05d202 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5116: d2e6dd2f789596da5bd06efc2e9448e3160583b6 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13807: b9df6b40ff67a8d1219bb3eea1ce8a68c11a4533 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b9df6b40ff67 drm/i915: Move MOCS setup to intel_mocs.c
83bded8c3976 drm/i915/tgl: Tigerlake only has global MOCS registers
e5f291ffbec7 drm/i915/tgl: Define MOCS entries for Tigerlake
93da890f569c drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG
e048237ee7c4 drm/i915/tgl: Move fault registers to their new offset

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Rodrigo Vivi
Hi Sasha,

On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin  wrote:
>
> Hi,
>
> [This is an automated email]

Where did you get this patch from? Since stable needs patches merged
on Linus tree,
shouldn't your scripts run to try backporting only patches from there?

Thanks,
Rodrigo.

>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 88a0d9606aff drm/i915/vbt: Parse and use the new field with 
> PSR2 TP2/3 wakeup time.
>
> The bot has tested the following trees: v5.2.1.
> v5.2.1: Failed to apply! Possible dependencies:
> 231dcffc234f ("drm/i915/bios: add BDB block comments before definitions")
> 843444ed1301 ("drm/i915/bios: sort BDB block definitions using block ID")
> f87f6599c843 ("drm/i915/bios: reserve struct bdb_ prefix for BDB blocks")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915/uc: move uC WOPCM setup in uc_init_hw

2019-07-30 Thread kbuild test robot
Hi Daniele,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc2 next-20190730]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniele-Ceraolo-Spurio/Call-uC-functions-from-GT-ones/20190730-131043
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/gt/uc/intel_uc.c:410:5: sparse: sparse: symbol 
>> 'uc_wopcm_init_hw' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH] drm/i915/uc: uc_wopcm_init_hw() can be static

2019-07-30 Thread kbuild test robot

Fixes: 6b6fa175ec57 ("drm/i915/uc: move uC WOPCM setup in uc_init_hw")
Signed-off-by: kbuild test robot 
---
 intel_uc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 2f71f3704c4671..383f048e490092 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -407,7 +407,7 @@ write_and_verify(struct intel_gt *gt,
 }
 
 /* Initialize and verify the uC regs related to uC positioning in WOPCM */
-int uc_wopcm_init_hw(struct intel_uc *uc)
+static int uc_wopcm_init_hw(struct intel_uc *uc)
 {
struct intel_gt *gt = uc_to_gt(uc);
struct intel_wopcm *wopcm = >i915->wopcm;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Use dedicated flag to track submission mode

2019-07-30 Thread Chris Wilson
Quoting Michal Wajdeczko (2019-07-30 19:19:02)
> Instead of relying on enable_guc modparam to represent actual
> GuC submission mode, use dedicated flag and look at modparam
> only to check if submission was explicitly disabled by the user.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  1 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc.h   |  7 +++
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16 
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.h|  1 +
>  drivers/gpu/drm/i915/gt/uc/intel_uc.h|  3 +--
>  5 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 13fbbffd05c7..a75ef0096f15 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -82,6 +82,7 @@ void intel_guc_init_early(struct intel_guc *guc)
> intel_guc_fw_init_early(guc);
> intel_guc_ct_init_early(>ct);
> intel_guc_log_init_early(>log);
> +   intel_guc_submission_init_early(guc);
>  
> mutex_init(>send_mutex);
> spin_lock_init(>irq_lock);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 5901506672cd..680625a0c722 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -64,6 +64,8 @@ struct intel_guc {
> struct i915_vma *ads_vma;
> struct __guc_ads_blob *ads_blob;
>  
> +   bool using_submission;

First boolean, but not necessarily the last?

> +
> struct i915_vma *stage_desc_pool;
> void *stage_desc_pool_vaddr;
> struct ida stage_ids;
> @@ -190,6 +192,11 @@ static inline int intel_guc_sanitize(struct intel_guc 
> *guc)
> return 0;
>  }
>  
> +static inline bool intel_guc_is_submission_supported(struct intel_guc *guc)
> +{
> +   return guc->using_submission;

I still suffer a logical disconnect between using and is.

> +}
> +
>  static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
>  {
> spin_lock_irq(>irq_lock);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index b4238fe16a03..b0cdbd9b2365 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1163,6 +1163,22 @@ void intel_guc_submission_disable(struct intel_guc 
> *guc)
> guc_clients_disable(guc);
>  }
>  
> +static bool __force_no_guc_submission(void)
> +{
> +   /* XXX: GuC submission is unavailable for now */
> +   return true;
> +
> +   return (i915_modparams.enable_guc == 0) ||
> +  ((i915_modparams.enable_guc > 0) &&
> +   !(i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION));

enable_guc <= 0 || !(enable_guc & ENABLE_SUBMISSION)

?

Then in future if you want <-1 for auto enable, s/<=/==/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Consider enable_guc modparam during fw selection

2019-07-30 Thread Chris Wilson
Quoting Michal Wajdeczko (2019-07-30 19:19:01)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> index fe3362fd7706..c8e5ad9807db 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> @@ -50,8 +50,7 @@ int intel_uc_resume(struct intel_uc *uc);
>  
>  static inline bool intel_uc_is_using_guc(struct intel_uc *uc)
>  {
> -   GEM_BUG_ON(i915_modparams.enable_guc < 0);
> -   return i915_modparams.enable_guc > 0;
> +   return intel_guc_is_supported(>guc);

is_using_guc sounds like it should be looking at guc_is_running

I think the callers read better for me if I
s/intel_uc_is_using_guc/intel_uc_uses_guc/
or even better if intel_uc_supports_guc().

With that in mind,

Reviewed-by: Chris Wilson 

> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index ac91e3efd02b..3f051451caba 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -132,6 +132,27 @@ __uc_fw_auto_select(struct intel_uc_fw *uc_fw, enum 
> intel_platform p, u8 rev)
> uc_fw->path = NULL;
> }
> }
> +
> +   /* We don't want to enable GuC/HuC on pre-Gen11 by default */
> +   if ((i915_modparams.enable_guc < 0) && (p < INTEL_ICELAKE))
> +   uc_fw->path = NULL;

(Bonus) (brackets)
> +}
> +
> +static const char* __override_guc_firmware_path(void)
> +{
> +   /* XXX: don't check for GuC submission as it is unavailable for now */
> +   if ((i915_modparams.enable_guc < 0) ||
> +   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
> +   return i915_modparams.guc_firmware_path;
> +   return "";
> +}
> +
> +static const char* __override_huc_firmware_path(void)
> +{
> +   if ((i915_modparams.enable_guc < 0) ||
> +   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
> +   return i915_modparams.huc_firmware_path;

Looks habitual.

We can even lose the <0. No negative value other than -1 is documented.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/i915/gem_exec_async: Update with engine discovery

2019-07-30 Thread Patchwork
== Series Details ==

Series: tests/i915/gem_exec_async: Update with engine discovery
URL   : https://patchwork.freedesktop.org/series/64425/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6580_full -> IGTPW_3308_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_exec_async@legacy-concurrent-writes-default} (NEW):
- shard-iclb: NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-iclb6/igt@gem_exec_as...@legacy-concurrent-writes-default.html

  
New tests
-

  New tests have been introduced between CI_DRM_6580_full and IGTPW_3308_full:

### New IGT tests (12) ###

  * igt@gem_exec_async@concurrent-writes-bcs0:
- Statuses : 6 pass(s)
- Exec time: [0.00] s

  * igt@gem_exec_async@concurrent-writes-rcs0:
- Statuses : 6 pass(s)
- Exec time: [0.00] s

  * igt@gem_exec_async@concurrent-writes-vcs0:
- Statuses : 5 pass(s) 1 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@gem_exec_async@concurrent-writes-vcs1:
- Statuses : 1 pass(s)
- Exec time: [0.00] s

  * igt@gem_exec_async@concurrent-writes-vcs2:
- Statuses :
- Exec time: [None] s

  * igt@gem_exec_async@concurrent-writes-vecs0:
- Statuses : 4 pass(s)
- Exec time: [0.00] s

  * igt@gem_exec_async@legacy-concurrent-writes-bcs0:
- Statuses : 6 pass(s)
- Exec time: [0.00] s

  * igt@gem_exec_async@legacy-concurrent-writes-default:
- Statuses : 6 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@legacy-concurrent-writes-rcs0:
- Statuses : 6 pass(s)
- Exec time: [0.00, 0.01] s

  * igt@gem_exec_async@legacy-concurrent-writes-vcs0:
- Statuses : 1 pass(s) 5 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@gem_exec_async@legacy-concurrent-writes-vcs1:
- Statuses : 1 pass(s) 5 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@gem_exec_async@legacy-concurrent-writes-vecs0:
- Statuses : 5 pass(s) 1 skip(s)
- Exec time: [0.0, 0.01] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][2] -> [DMESG-WARN][3] ([fdo#108566]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-kbl4/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][4] -> [FAIL][5] ([fdo#109661])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-snb7/igt@gem_...@reset-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-snb4/igt@gem_...@reset-stress.html

  * igt@i915_pm_rpm@i2c:
- shard-hsw:  [PASS][6] -> [FAIL][7] ([fdo#104097])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-hsw7/igt@i915_pm_...@i2c.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-hsw1/igt@i915_pm_...@i2c.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-apl:  [PASS][8] -> [DMESG-WARN][9] ([fdo#108566]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-apl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw:  [PASS][10] -> [INCOMPLETE][11] ([fdo#103540])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite:
- shard-glk:  [PASS][12] -> [FAIL][13] ([fdo#103167])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-glk8/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3308/shard-glk6/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][14] -> [FAIL][15] ([fdo#103167]) +4 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6580/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html
   [15]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Ungate DDIC and DDID

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Ungate DDIC and DDID
URL   : https://patchwork.freedesktop.org/series/64443/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6583 -> Patchwork_13806


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#109100])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_pm_rpm@module-reload:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-icl-u3/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-icl-u3/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [PASS][5] -> [DMESG-FAIL][6] ([fdo#08])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][7] -> [WARN][8] ([fdo#109380])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][9] -> [FAIL][10] ([fdo#109485])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][11] -> [FAIL][12] ([fdo#103167])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][13] -> [SKIP][14] ([fdo#109271]) +23 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@prime_self_import@basic-with_fd_dup:
- fi-icl-u3:  [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6583/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13806/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08


Participating hosts (54 -> 45)
--

  Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-cfl-8109u fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6583 -> Patchwork_13806

  CI-20190529: 20190529
  CI_DRM_6583: 892c242344c9adfca582ace4ea0063466a35d794 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5115: 21be7a02ac8a8ff46b561c36a69e4dd5a0c2938b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13806: 70d3172454e66c95d1e9b9a40cbf18b4ab9a762b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

70d3172454e6 drm/i915/ehl: Ungate DDIC and DDID

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: remove dangling forward declaration

2019-07-30 Thread Chris Wilson
Quoting Lucas De Marchi (2019-07-30 19:26:14)
> Commit 20a7f2fc4d7a ("drm/i915: Convert intel_mocs_init_l3cc_table to
> intel_gt") removed the only user.
> 
> Signed-off-by: Lucas De Marchi 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: remove dangling forward declaration

2019-07-30 Thread Lucas De Marchi
Commit 20a7f2fc4d7a ("drm/i915: Convert intel_mocs_init_l3cc_table to
intel_gt") removed the only user.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_mocs.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h 
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index a334db2d6d6b..8e20ca8bb34c 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -49,7 +49,6 @@
  * context handling keep the MOCS in step.
  */
 
-struct drm_i915_private;
 struct i915_request;
 struct intel_engine_cs;
 struct intel_gt;
-- 
2.21.0

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

Re: [Intel-gfx] [PATCH] drm/i915: make i915_selftest.h self-contained

2019-07-30 Thread Chris Wilson
Quoting Lucas De Marchi (2019-07-30 19:17:59)
> Fix build breakage:
> 
> In file included from :
> ./drivers/gpu/drm/i915/i915_selftest.h:125:1: error: unknown type name ‘bool’
>   125 | bool __igt_timeout(unsigned long timeout, const char *fmt, ...);
>   | ^~~~
> 
> Signed-off-by: Lucas De Marchi 

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

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Pandiyan, Dhinakaran


> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, July 30, 2019 10:09 AM
> To: Vivi, Rodrigo 
> Cc: Nikula, Jani ; Joonas Lahtinen
> ; Souza, Jose ;
> sas...@kernel.org; intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org;
> Pandiyan, Dhinakaran 
> Subject: Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for
> the PSR section
> 
> On Tue, Jul 30, 2019 at 09:56:59AM -0700, Rodrigo Vivi wrote:
> >
> > On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > > > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan
> wrote:
> > > > > > > > > > A single 32-bit PSR2 training pattern field follows the 
> > > > > > > > > > sixteen
> > > > > > > > > > element
> > > > > > > > > > array of PSR table entries in the VBT spec. But, we 
> > > > > > > > > > incorrectly
> > > > > > > > > > define
> > > > > > > > > > this PSR2 field for each of the PSR table entries. As a 
> > > > > > > > > > result,
> the
> > > > > > > > > > PSR1
> > > > > > > > > > training pattern duration for any panel_type != 0 will be
> parsed
> > > > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for 
> > > > > > > > > > VBTs
> > > > > > > > > > with bdb
> > > > > > > > > > version >= 226 will also be wrong.
> > > > > > > > > >
> > > > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > > > Cc: José Roberto de Souza 
> > > > > > > > > > Cc: sta...@vger.kernel.org
> > > > > > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new 
> > > > > > > > > > field
> > > > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > > > Bugzilla: 
> > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > > > Signed-off-by: Dhinakaran Pandiyan
> 
> > > > > > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > > > > > Acked-by: Rodrigo Vivi 
> > > > > > > > > > Tested-by: François Guerraz 
> > > > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > > > Link:
> > > > > > > > > >
> https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-
> dhinakaran.pandi...@intel.com
> > > > > > > > > > (cherry picked from commit
> > > > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > > >
> > > > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > > >
> > > > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > > >
> > > > > > > This line is automatically added by "dim" tool when
> > > > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > > >
> > > > > > What do you need her from us to accept this patch?
> > > > >
> > > > > Um, you have read the stable kernel rules, right?
> > > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-
> rules.html
> > > > >
> > > > > That's what I need for it to go into a stable kernel release.
> > > >
> > > > Yes, I have read it. Maybe what I don't understand is just the fact 
> > > > that we
> will
> > > > let customers facing issues for 6 weeks or more while the original patch
> > > > doesn't land on Linus tree. :(
> > >
> > > Then get the patch into Linus's tree!
> > > Nothing I can do until that happens, you know this...
> >
> > -ENOTENOUGHCOFFEE sorry.
> > For some reason I thought this thread had started as the reject of your
> scripts.
> 
> That is correct.  But more coffee is always good.
> 
> > This patch is already queued on our drm-intel-fixes and will probably land 
> > on
> > Linus tree next week. Than your scripts will just get it.
> >
> > So, back to your original concern:
> >
> > The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out 
> > won't
> > exist until 5.3 merge window though.
> 
> That's fine.
> 
> > My question now is regarding our fixes flow adding these future references.
> > Do you have any concern with that?
> 
> I hate and despise and complain endlessly about how you all are doing
> this, but I have learned to just suck it up and accept it.  It is a
> major pain in the rear, and I will say that it causes me to delay all
> merges of stable drm patches that get merged in Linus's tree in -rc1
> until -rc2 or -rc3 is out usually as I have to go through and
> hand-determine if a reject happens because it really is a reject, or
> because this patch is already in the tree.
> 
> So, if this hits Linus's tree "like normal", 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/uc: Stop sanitizing enable_guc modparam

2019-07-30 Thread Chris Wilson
Quoting Michal Wajdeczko (2019-07-30 19:19:03)
> As we already track GuC/HuC uses by other means than modparam
> there is no point in sanitizing it. Just scan modparam for
> major discrepancies between what was requested vs actual.

Note that igt is using this modparam to discover if guc submission is
active. :|

Fortunately, it appears that no one is using that facility so quickly
remove it!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915/uc: Stop sanitizing enable_guc modparam

2019-07-30 Thread Michal Wajdeczko
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 70 +++
 1 file changed, 17 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6eb8bb3fa252..34201d156271 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -55,78 +55,42 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
return ret;
 }
 
-static int __get_platform_enable_guc(struct intel_uc *uc)
+static void __confirm_options(struct intel_uc *uc)
 {
-   struct intel_uc_fw *guc_fw = >guc.fw;
-   struct intel_uc_fw *huc_fw = >huc.fw;
-   int enable_guc = 0;
-
-   if (!HAS_GT_UC(uc_to_gt(uc)->i915))
-   return 0;
-
-   /* We don't want to enable GuC/HuC on pre-Gen11 by default */
-   if (INTEL_GEN(uc_to_gt(uc)->i915) < 11)
-   return 0;
-
-   if (intel_uc_fw_supported(guc_fw) && intel_uc_fw_supported(huc_fw))
-   enable_guc |= ENABLE_GUC_LOAD_HUC;
-
-   return enable_guc;
-}
-
-/**
- * sanitize_options_early - sanitize uC related modparam options
- * @uc: the intel_uc structure
- *
- * In case of "enable_guc" option this function will attempt to modify
- * it only if it was initially set to "auto(-1)". Default value for this
- * modparam varies between platforms and it is hardcoded in driver code.
- * Any other modparam value is only monitored against availability of the
- * related hardware or firmware definitions.
- */
-static void sanitize_options_early(struct intel_uc *uc)
-{
-   struct intel_uc_fw *guc_fw = >guc.fw;
-   struct intel_uc_fw *huc_fw = >huc.fw;
-
-   /* A negative value means "use platform default" */
-   if (i915_modparams.enable_guc < 0)
-   i915_modparams.enable_guc = __get_platform_enable_guc(uc);
-
DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
 i915_modparams.enable_guc,
 yesno(intel_uc_is_using_guc_submission(uc)),
 yesno(intel_uc_is_using_huc(uc)));
 
-   /* Verify GuC firmware availability */
-   if (intel_uc_is_using_guc(uc) && !intel_uc_fw_supported(guc_fw)) {
+   if (i915_modparams.enable_guc < 0)
+   return;
+
+   if (i915_modparams.enable_guc == 0) {
+   GEM_BUG_ON(intel_uc_is_using_guc(uc));
+   GEM_BUG_ON(intel_uc_is_using_guc_submission(uc));
+   GEM_BUG_ON(intel_uc_is_using_huc(uc));
+   return;
+   }
+
+   if (!intel_uc_is_using_guc(uc)) {
DRM_WARN("Incompatible option detected: enable_guc=%d, "
 "but GuC is not supported!\n",
 i915_modparams.enable_guc);
-   DRM_INFO("Disabling GuC/HuC loading!\n");
-   i915_modparams.enable_guc = 0;
}
 
-   /* Verify HuC firmware availability */
-   if (intel_uc_is_using_huc(uc) && !intel_uc_fw_supported(huc_fw)) {
+   if (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC &&
+   !intel_uc_is_using_huc(uc)) {
DRM_WARN("Incompatible option detected: enable_guc=%d, "
 "but HuC is not supported!\n",
 i915_modparams.enable_guc);
-   DRM_INFO("Disabling HuC loading!\n");
-   i915_modparams.enable_guc &= ~ENABLE_GUC_LOAD_HUC;
}
 
-   /* XXX: GuC submission is unavailable for now */
-   if (intel_uc_is_using_guc_submission(uc)) {
+   if (i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION &&
+   !intel_uc_is_using_guc_submission(uc)) {
DRM_INFO("Incompatible option detected: enable_guc=%d, "
 "but GuC submission is not supported!\n",
 i915_modparams.enable_guc);
-   DRM_INFO("Switching to non-GuC submission mode!\n");
-   i915_modparams.enable_guc &= ~ENABLE_GUC_SUBMISSION;
}
-
-   /* Make sure that sanitization was done */
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
 }
 
 void intel_uc_init_early(struct intel_uc *uc)
@@ -134,7 +98,7 @@ void intel_uc_init_early(struct intel_uc *uc)
intel_guc_init_early(>guc);
intel_huc_init_early(>huc);
 
-   sanitize_options_early(uc);
+   __confirm_options(uc);
 }
 
 void intel_uc_cleanup_early(struct intel_uc *uc)
-- 
2.19.2

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

[Intel-gfx] [PATCH 0/3] Don't sanitize enable_guc

2019-07-30 Thread Michal Wajdeczko
We want to stop relying on modparam for runtime uC status

Michal Wajdeczko (3):
  drm/i915/uc: Consider enable_guc modparam during fw selection
  drm/i915/guc: Use dedicated flag to track submission mode
  drm/i915/uc: Stop sanitizing enable_guc modparam

 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  5 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 70 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  9 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 25 ++-
 8 files changed, 78 insertions(+), 61 deletions(-)

-- 
2.19.2

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

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Use dedicated flag to track submission mode

2019-07-30 Thread Michal Wajdeczko
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h   |  7 +++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16 
 .../gpu/drm/i915/gt/uc/intel_guc_submission.h|  1 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|  3 +--
 5 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 13fbbffd05c7..a75ef0096f15 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -82,6 +82,7 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_fw_init_early(guc);
intel_guc_ct_init_early(>ct);
intel_guc_log_init_early(>log);
+   intel_guc_submission_init_early(guc);
 
mutex_init(>send_mutex);
spin_lock_init(>irq_lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5901506672cd..680625a0c722 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -64,6 +64,8 @@ struct intel_guc {
struct i915_vma *ads_vma;
struct __guc_ads_blob *ads_blob;
 
+   bool using_submission;
+
struct i915_vma *stage_desc_pool;
void *stage_desc_pool_vaddr;
struct ida stage_ids;
@@ -190,6 +192,11 @@ static inline int intel_guc_sanitize(struct intel_guc *guc)
return 0;
 }
 
+static inline bool intel_guc_is_submission_supported(struct intel_guc *guc)
+{
+   return guc->using_submission;
+}
+
 static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
 {
spin_lock_irq(>irq_lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b4238fe16a03..b0cdbd9b2365 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1163,6 +1163,22 @@ void intel_guc_submission_disable(struct intel_guc *guc)
guc_clients_disable(guc);
 }
 
+static bool __force_no_guc_submission(void)
+{
+   /* XXX: GuC submission is unavailable for now */
+   return true;
+
+   return (i915_modparams.enable_guc == 0) ||
+  ((i915_modparams.enable_guc > 0) &&
+   !(i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION));
+}
+
+void intel_guc_submission_init_early(struct intel_guc *guc)
+{
+   guc->using_submission = intel_guc_is_supported(guc) &&
+   !__force_no_guc_submission();
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftest_guc.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index 87a38cb6faf3..c4ad2702ec8d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -77,6 +77,7 @@ struct intel_guc_client {
I915_SELFTEST_DECLARE(bool use_nop_wqi);
 };
 
+void intel_guc_submission_init_early(struct intel_guc *guc);
 int intel_guc_submission_init(struct intel_guc *guc);
 int intel_guc_submission_enable(struct intel_guc *guc);
 void intel_guc_submission_disable(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index c8e5ad9807db..96bd9a461c93 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -55,8 +55,7 @@ static inline bool intel_uc_is_using_guc(struct intel_uc *uc)
 
 static inline bool intel_uc_is_using_guc_submission(struct intel_uc *uc)
 {
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
-   return i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION;
+   return intel_guc_is_submission_supported(>guc);
 }
 
 static inline bool intel_uc_is_using_huc(struct intel_uc *uc)
-- 
2.19.2

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

[Intel-gfx] [PATCH 1/3] drm/i915/uc: Consider enable_guc modparam during fw selection

2019-07-30 Thread Michal Wajdeczko
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h   |  5 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.h   |  5 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|  6 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 25 ++--
 4 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 714e9892aaff..5901506672cd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -172,6 +172,11 @@ int intel_guc_suspend(struct intel_guc *guc);
 int intel_guc_resume(struct intel_guc *guc);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
 
+static inline bool intel_guc_is_supported(struct intel_guc *guc)
+{
+   return intel_uc_fw_supported(>fw);
+}
+
 static inline bool intel_guc_is_running(struct intel_guc *guc)
 {
return intel_uc_fw_is_running(>fw);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 4465209ce233..a6ae59b8cb77 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -55,6 +55,11 @@ static inline int intel_huc_sanitize(struct intel_huc *huc)
return 0;
 }
 
+static inline bool intel_huc_is_supported(struct intel_huc *huc)
+{
+   return intel_uc_fw_supported(>fw);
+}
+
 static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
 {
return intel_uc_fw_is_running(>fw);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index fe3362fd7706..c8e5ad9807db 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -50,8 +50,7 @@ int intel_uc_resume(struct intel_uc *uc);
 
 static inline bool intel_uc_is_using_guc(struct intel_uc *uc)
 {
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
-   return i915_modparams.enable_guc > 0;
+   return intel_guc_is_supported(>guc);
 }
 
 static inline bool intel_uc_is_using_guc_submission(struct intel_uc *uc)
@@ -62,8 +61,7 @@ static inline bool intel_uc_is_using_guc_submission(struct 
intel_uc *uc)
 
 static inline bool intel_uc_is_using_huc(struct intel_uc *uc)
 {
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
-   return i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC;
+   return intel_huc_is_supported(>huc);
 }
 
 #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index ac91e3efd02b..3f051451caba 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -132,6 +132,27 @@ __uc_fw_auto_select(struct intel_uc_fw *uc_fw, enum 
intel_platform p, u8 rev)
uc_fw->path = NULL;
}
}
+
+   /* We don't want to enable GuC/HuC on pre-Gen11 by default */
+   if ((i915_modparams.enable_guc < 0) && (p < INTEL_ICELAKE))
+   uc_fw->path = NULL;
+}
+
+static const char* __override_guc_firmware_path(void)
+{
+   /* XXX: don't check for GuC submission as it is unavailable for now */
+   if ((i915_modparams.enable_guc < 0) ||
+   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
+   return i915_modparams.guc_firmware_path;
+   return "";
+}
+
+static const char* __override_huc_firmware_path(void)
+{
+   if ((i915_modparams.enable_guc < 0) ||
+   (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
+   return i915_modparams.huc_firmware_path;
+   return "";
 }
 
 static bool
@@ -139,10 +160,10 @@ __uc_fw_override(struct intel_uc_fw *uc_fw)
 {
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
-   uc_fw->path = i915_modparams.guc_firmware_path;
+   uc_fw->path = __override_guc_firmware_path();
break;
case INTEL_UC_FW_TYPE_HUC:
-   uc_fw->path = i915_modparams.huc_firmware_path;
+   uc_fw->path = __override_huc_firmware_path();
break;
}
 
-- 
2.19.2

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

[Intel-gfx] [PATCH] drm/i915: make i915_selftest.h self-contained

2019-07-30 Thread Lucas De Marchi
Fix build breakage:

In file included from :
./drivers/gpu/drm/i915/i915_selftest.h:125:1: error: unknown type name ‘bool’
  125 | bool __igt_timeout(unsigned long timeout, const char *fmt, ...);
  | ^~~~

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_selftest.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_selftest.h 
b/drivers/gpu/drm/i915/i915_selftest.h
index acdf6eb9e262..4d88205de51b 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -24,6 +24,8 @@
 #ifndef __I915_SELFTEST_H__
 #define __I915_SELFTEST_H__
 
+#include 
+
 struct pci_dev;
 struct drm_i915_private;
 
-- 
2.21.0

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

Re: [Intel-gfx] [PATCH] drm/i915/ehl: Ungate DDIC and DDID

2019-07-30 Thread Matt Roper
On Tue, Jul 30, 2019 at 10:51:21AM -0700, José Roberto de Souza wrote:
> Specification states that DDI_CLK_SEL needs to be mapped to MG clock
> even if MG do not exist on EHL, this will ungate those DDIs.
> 
> BSpec: 20845
> Cc: Matt Roper 
> Cc: Vivek Kasireddy 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Matt Roper 
Tested-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index c6f38c7b397d..fb58845020dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2921,6 +2921,12 @@ static void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>   if (!intel_phy_is_combo(dev_priv, phy))
>   I915_WRITE(DDI_CLK_SEL(port),
>  icl_pll_to_ddi_clk_sel(encoder, crtc_state));
> + else if (IS_ELKHARTLAKE(dev_priv) && port >= PORT_C)
> + /*
> +  * MG does not exist but the programming is required
> +  * to ungate DDIC and DDID
> +  */
> + I915_WRITE(DDI_CLK_SEL(port), DDI_CLK_SEL_MG);
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
>   val = I915_READ(DPCLKA_CFGCR0);
> @@ -2961,7 +2967,8 @@ static void intel_ddi_clk_disable(struct intel_encoder 
> *encoder)
>   enum phy phy = intel_port_to_phy(dev_priv, port);
>  
>   if (INTEL_GEN(dev_priv) >= 11) {
> - if (!intel_phy_is_combo(dev_priv, phy))
> + if (!intel_phy_is_combo(dev_priv, phy) ||
> + (IS_ELKHARTLAKE(dev_priv) && port >= PORT_C))
>   I915_WRITE(DDI_CLK_SEL(port), DDI_CLK_SEL_NONE);
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   I915_WRITE(DPCLKA_CFGCR0, I915_READ(DPCLKA_CFGCR0) |
> -- 
> 2.22.0
> 

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

[Intel-gfx] [PATCH v3 3/5] drm/i915/tgl: Define MOCS entries for Tigerlake

2019-07-30 Thread Lucas De Marchi
From: Tomasz Lis 

The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.

Two of the 3 legacy entries used for gen9 are no longer expected to work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.

v2: Add the missing entries in 49-51 range and replace "HW reserved"
terminology to what it actually is: L1 is implicitly enabled
(from Daniele)
v3: Use a different table for Tiger Lake since entries 0 and 1 are not
the same (from Daniele)

Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Signed-off-by: Tomasz Lis 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 68 +++-
 1 file changed, 57 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index e082b25d2db1..d93301310dc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -62,6 +62,10 @@ struct drm_i915_mocs_table {
 #define GEN11_NUM_MOCS_ENTRIES 64  /* 63-64 are reserved, but configured. */
 
 /* (e)LLC caching options */
+/*
+ * Note: LE_0_PAGETABLE works only up to Gen11; for newer gens it means
+ * the same as LE_UC
+ */
 #define LE_0_PAGETABLE _LE_CACHEABILITY(0)
 #define LE_1_UC_LE_CACHEABILITY(1)
 #define LE_2_WT_LE_CACHEABILITY(2)
@@ -100,8 +104,9 @@ struct drm_i915_mocs_table {
  * of bspec.
  *
  * Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon.  For the time
- * being they will be initialized to PTE.
+ * userspace is concerned and shouldn't be relied upon.  For Gen < 12
+ * they will be initialized to PTE. Gen >= 12 onwards don't have a setting for
+ * PTE and will be initialized to an invalid value.
  *
  * The last two entries are reserved by the hardware. For ICL+ they
  * should be initialized according to bspec and never used, for older
@@ -137,14 +142,7 @@ static const struct drm_i915_mocs_entry 
broxton_mocs_table[] = {
 };
 
 #define GEN11_MOCS_ENTRIES \
-   /* Base - Uncached (Deprecated) */ \
-   MOCS_ENTRY(I915_MOCS_UNCACHED, \
-  LE_1_UC | LE_TC_1_LLC, \
-  L3_1_UC), \
-   /* Base - L3 + LeCC:PAT (Deprecated) */ \
-   MOCS_ENTRY(I915_MOCS_PTE, \
-  LE_0_PAGETABLE | LE_TC_1_LLC, \
-  L3_3_WB), \
+   /* Entries 0 and 1 are defined per-platform */ \
/* Base - L3 + LLC */ \
MOCS_ENTRY(2, \
   LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
@@ -242,7 +240,50 @@ static const struct drm_i915_mocs_entry 
broxton_mocs_table[] = {
   LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), \
   L3_1_UC)
 
+static const struct drm_i915_mocs_entry tigerlake_mocs_table[] = {
+   /* Base - Error (Reserved for Non-Use) */
+   MOCS_ENTRY(0, 0x0, 0x0),
+   /* Base - Reserved */
+   MOCS_ENTRY(1, 0x0, 0x0),
+
+   GEN11_MOCS_ENTRIES,
+
+   /* Implicitly enable L1 - HDC:L1 + L3 + LLC */
+   MOCS_ENTRY(48,
+  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+  L3_3_WB),
+   /* Implicitly enable L1 - HDC:L1 + L3 */
+   MOCS_ENTRY(49,
+  LE_1_UC | LE_TC_1_LLC,
+  L3_3_WB),
+   /* Implicitly enable L1 - HDC:L1 + LLC */
+   MOCS_ENTRY(50,
+  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+  L3_1_UC),
+   /* Implicitly enable L1 - HDC:L1 */
+   MOCS_ENTRY(51,
+  LE_1_UC | LE_TC_1_LLC,
+  L3_1_UC),
+   /* HW Special Case (CCS) */
+   MOCS_ENTRY(60,
+  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+  L3_1_UC),
+   /* HW Special Case (Displayable) */
+   MOCS_ENTRY(61,
+  LE_1_UC | LE_TC_1_LLC | LE_SCF(1),
+  L3_3_WB),
+};
+
 static const struct drm_i915_mocs_entry icelake_mocs_table[] = {
+   /* Base - Uncached (Deprecated) */
+   MOCS_ENTRY(I915_MOCS_UNCACHED,
+  LE_1_UC | LE_TC_1_LLC,
+  L3_1_UC),
+   /* Base - L3 + LeCC:PAT (Deprecated) */
+   MOCS_ENTRY(I915_MOCS_PTE,
+  LE_0_PAGETABLE | LE_TC_1_LLC,
+  L3_3_WB),
+
GEN11_MOCS_ENTRIES
 };
 
@@ -264,7 +305,12 @@ static bool get_mocs_settings(struct intel_gt *gt,
struct drm_i915_private *i915 = gt->i915;
bool result = false;
 
-   if (INTEL_GEN(i915) >= 11) {
+   if (INTEL_GEN(i915) >= 12) {
+   table->size  = ARRAY_SIZE(tigerlake_mocs_table);
+   table->table = tigerlake_mocs_table;
+   table->n_entries = GEN11_NUM_MOCS_ENTRIES;
+   

[Intel-gfx] [PATCH v3 2/5] drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG

2019-07-30 Thread Lucas De Marchi
These registers have been removed on gen12.

v2: merge common branch for IS_GEN_RANGE(i915, 6, 11)

Signed-off-by: Lucas De Marchi 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 673c5dc93d28..9eee99bdc514 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -745,16 +745,15 @@ static void __err_print_to_sgl(struct 
drm_i915_error_state_buf *m,
for (i = 0; i < error->nfence; i++)
err_printf(m, "  fence[%d] = %08llx\n", i, error->fence[i]);
 
-   if (INTEL_GEN(m->i915) >= 6) {
+   if (IS_GEN_RANGE(m->i915, 6, 11)) {
err_printf(m, "ERROR: 0x%08x\n", error->error);
-
-   if (INTEL_GEN(m->i915) >= 8)
-   err_printf(m, "FAULT_TLB_DATA: 0x%08x 0x%08x\n",
-  error->fault_data1, error->fault_data0);
-
err_printf(m, "DONE_REG: 0x%08x\n", error->done_reg);
}
 
+   if (INTEL_GEN(m->i915) >= 8)
+   err_printf(m, "FAULT_TLB_DATA: 0x%08x 0x%08x\n",
+  error->fault_data1, error->fault_data0);
+
if (IS_GEN(m->i915, 7))
err_printf(m, "ERR_INT: 0x%08x\n", error->err_int);
 
@@ -1569,8 +1568,10 @@ static void capture_reg_state(struct i915_gpu_state 
*error)
 
if (INTEL_GEN(i915) >= 6) {
error->derrmr = intel_uncore_read(uncore, DERRMR);
-   error->error = intel_uncore_read(uncore, ERROR_GEN6);
-   error->done_reg = intel_uncore_read(uncore, DONE_REG);
+   if (INTEL_GEN(i915) < 12) {
+   error->error = intel_uncore_read(uncore, ERROR_GEN6);
+   error->done_reg = intel_uncore_read(uncore, DONE_REG);
+   }
}
 
if (INTEL_GEN(i915) >= 5)
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 0/5] Tiger Lake: MOCS table handling

2019-07-30 Thread Lucas De Marchi
v3 of https://patchwork.freedesktop.org/series/64275/

Changes:
  - Fix checkpatch warning on commit message
  - Minor change on "drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG"
  - Rebase again to be able to apply

Lucas De Marchi (2):
  drm/i915/tgl: Move fault registers to their new offset
  drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG

Michel Thierry (1):
  drm/i915/tgl: Tigerlake only has global MOCS registers

Tomasz Lis (1):
  drm/i915/tgl: Define MOCS entries for Tigerlake

Tvrtko Ursulin (1):
  drm/i915: Move MOCS setup to intel_mocs.c

 drivers/gpu/drm/i915/gt/intel_gt.c   |  24 -
 drivers/gpu/drm/i915/gt/intel_mocs.c | 121 ---
 drivers/gpu/drm/i915/gt/intel_mocs.h |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem.c  |   2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|  29 --
 drivers/gpu/drm/i915/i915_pci.c  |   3 +-
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 9 files changed, 159 insertions(+), 30 deletions(-)

-- 
2.21.0

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

[Intel-gfx] [PATCH v3 5/5] drm/i915: Move MOCS setup to intel_mocs.c

2019-07-30 Thread Lucas De Marchi
From: Tvrtko Ursulin 

Hide the details of MOCS setup from i915_gem by moving both current calls
into one in intel_mocs_init.

Cc: Stuart Summers 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Stuart Summers 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-21-lucas.demar...@intel.com
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 15 +++
 drivers/gpu/drm/i915/gt/intel_mocs.h |  3 +--
 drivers/gpu/drm/i915/i915_gem.c  |  3 +--
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 764e47131c06..77ddb307346a 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -426,14 +426,13 @@ void intel_mocs_init_engine(struct intel_engine_cs 
*engine)
  *
  * This function initializes the MOCS global registers.
  */
-void intel_mocs_init_global(struct intel_gt *gt)
+static void intel_mocs_init_global(struct intel_gt *gt)
 {
struct intel_uncore *uncore = gt->uncore;
struct drm_i915_mocs_table table;
unsigned int index;
 
-   if (!HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
-   return;
+   GEM_BUG_ON(!HAS_GLOBAL_MOCS_REGISTERS(gt->i915));
 
if (!get_mocs_settings(gt, ))
return;
@@ -599,7 +598,7 @@ static int emit_mocs_l3cc_table(struct i915_request *rq,
  *
  * Return: Nothing.
  */
-void intel_mocs_init_l3cc_table(struct intel_gt *gt)
+static void intel_mocs_init_l3cc_table(struct intel_gt *gt)
 {
struct intel_uncore *uncore = gt->uncore;
struct drm_i915_mocs_table table;
@@ -678,3 +677,11 @@ int intel_mocs_emit(struct i915_request *rq)
 
return 0;
 }
+
+void intel_mocs_init(struct intel_gt *gt)
+{
+   intel_mocs_init_l3cc_table(gt);
+
+   if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+   intel_mocs_init_global(gt);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h 
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index 727e67bda8f6..2391a53ed08a 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -54,8 +54,7 @@ struct i915_request;
 struct intel_engine_cs;
 struct intel_gt;
 
-void intel_mocs_init_l3cc_table(struct intel_gt *gt);
-void intel_mocs_init_global(struct intel_gt *gt);
+void intel_mocs_init(struct intel_gt *gt);
 void intel_mocs_init_engine(struct intel_engine_cs *engine);
 
 int intel_mocs_emit(struct i915_request *rq);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 95489488b0cb..ad33a7addd57 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1253,8 +1253,7 @@ int i915_gem_init_hw(struct drm_i915_private *i915)
goto out;
}
 
-   intel_mocs_init_global(gt);
-   intel_mocs_init_l3cc_table(gt);
+   intel_mocs_init(gt);
 
intel_engines_set_scheduler_caps(i915);
 
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 4/5] drm/i915/tgl: Tigerlake only has global MOCS registers

2019-07-30 Thread Lucas De Marchi
From: Michel Thierry 

Until Icelake, each engine had its own set of 64 MOCS registers. In
order to simplify, Tigerlake moves to only 64 Global MOCS registers,
which are no longer part of the engine context. Since these registers
are now global, they also only need to be initialized once.

From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU
management (5:4) fields and cannot be programmed to 'use the value from
Private PAT', because these fields are no longer part of the PPAT. Also
cacheability control (1:0) field has changed, 00 no longer means 'use
controls from page table', but uncacheable (UC).

v2 (Lucas):
- Move the changes to the fault registers to a separate commit - the
  old ones overlap with the range used by the new global MOCS
  (requested by Daniele)
v3 (Lucas):
- Clarify comment about setting the unused entries to the same value
  of index 0, that is the invalid entry (requested by Daniele)
- Move changes to DONE_REG and ERROR_GEN6 to a separate commit
  (requested by Daniele)

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Tomasz Lis 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 44 +++-
 drivers/gpu/drm/i915/gt/intel_mocs.h |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_gem.c  |  1 +
 drivers/gpu/drm/i915/i915_pci.c  |  3 +-
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 7 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index d93301310dc7..764e47131c06 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -392,6 +392,10 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
unsigned int index;
u32 unused_value;
 
+   /* Platforms with global MOCS do not need per-engine initialization. */
+   if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+   return;
+
/* Called under a blanket forcewake */
assert_forcewakes_active(uncore, FORCEWAKE_ALL);
 
@@ -416,6 +420,43 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
  unused_value);
 }
 
+/**
+ * intel_mocs_init_global() - program the global mocs registers
+ * gt:  pointer to struct intel_gt
+ *
+ * This function initializes the MOCS global registers.
+ */
+void intel_mocs_init_global(struct intel_gt *gt)
+{
+   struct intel_uncore *uncore = gt->uncore;
+   struct drm_i915_mocs_table table;
+   unsigned int index;
+
+   if (!HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+   return;
+
+   if (!get_mocs_settings(gt, ))
+   return;
+
+   if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
+   return;
+
+   for (index = 0; index < table.size; index++)
+   intel_uncore_write(uncore,
+  GEN12_GLOBAL_MOCS(index),
+  table.table[index].control_value);
+
+   /*
+* Ok, now set the unused entries to the invalid entry (index 0). These
+* entries are officially undefined and no contract for the contents and
+* settings is given for these entries.
+*/
+   for (; index < table.n_entries; index++)
+   intel_uncore_write(uncore,
+  GEN12_GLOBAL_MOCS(index),
+  table.table[0].control_value);
+}
+
 /**
  * emit_mocs_control_table() - emit the mocs control table
  * @rq:Request to set up the MOCS table for.
@@ -619,7 +660,8 @@ int intel_mocs_emit(struct i915_request *rq)
struct drm_i915_mocs_table t;
int ret;
 
-   if (rq->engine->class != RENDER_CLASS)
+   if (HAS_GLOBAL_MOCS_REGISTERS(rq->i915) ||
+   rq->engine->class != RENDER_CLASS)
return 0;
 
if (get_mocs_settings(rq->engine->gt, )) {
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h 
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index a334db2d6d6b..727e67bda8f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -55,6 +55,7 @@ struct intel_engine_cs;
 struct intel_gt;
 
 void intel_mocs_init_l3cc_table(struct intel_gt *gt);
+void intel_mocs_init_global(struct intel_gt *gt);
 void intel_mocs_init_engine(struct intel_engine_cs *engine);
 
 int intel_mocs_emit(struct i915_request *rq);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4f524e791b1..706ea84b7f3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2277,6 +2277,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
 
+#define HAS_GLOBAL_MOCS_REGISTERS(dev_priv)   

[Intel-gfx] [PATCH v3 1/5] drm/i915/tgl: Move fault registers to their new offset

2019-07-30 Thread Lucas De Marchi
The fault registers moved to another offset. The old location is now
taken by the global MOCS registers, to be added in a follow up change.

Based on previous patches by Michel Thierry .

Signed-off-by: Lucas De Marchi 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt.c| 24 
 drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  3 +++
 3 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f7e69db4019d..caa07eb20a64 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -79,7 +79,10 @@ intel_gt_clear_error_registers(struct intel_gt *gt,
   I915_MASTER_ERROR_INTERRUPT);
}
 
-   if (INTEL_GEN(i915) >= 8) {
+   if (INTEL_GEN(i915) >= 12) {
+   rmw_clear(uncore, GEN12_RING_FAULT_REG, RING_FAULT_VALID);
+   intel_uncore_posting_read(uncore, GEN12_RING_FAULT_REG);
+   } else if (INTEL_GEN(i915) >= 8) {
rmw_clear(uncore, GEN8_RING_FAULT_REG, RING_FAULT_VALID);
intel_uncore_posting_read(uncore, GEN8_RING_FAULT_REG);
} else if (INTEL_GEN(i915) >= 6) {
@@ -117,14 +120,27 @@ static void gen6_check_faults(struct intel_gt *gt)
 static void gen8_check_faults(struct intel_gt *gt)
 {
struct intel_uncore *uncore = gt->uncore;
-   u32 fault = intel_uncore_read(uncore, GEN8_RING_FAULT_REG);
+   i915_reg_t fault_reg, fault_data0_reg, fault_data1_reg;
+   u32 fault;
+
+   if (INTEL_GEN(gt->i915) >= 12) {
+   fault_reg = GEN12_RING_FAULT_REG;
+   fault_data0_reg = GEN12_FAULT_TLB_DATA0;
+   fault_data1_reg = GEN12_FAULT_TLB_DATA1;
+   } else {
+   fault_reg = GEN8_RING_FAULT_REG;
+   fault_data0_reg = GEN8_FAULT_TLB_DATA0;
+   fault_data1_reg = GEN8_FAULT_TLB_DATA1;
+   }
 
+   fault = intel_uncore_read(uncore, fault_reg);
if (fault & RING_FAULT_VALID) {
u32 fault_data0, fault_data1;
u64 fault_addr;
 
-   fault_data0 = intel_uncore_read(uncore, GEN8_FAULT_TLB_DATA0);
-   fault_data1 = intel_uncore_read(uncore, GEN8_FAULT_TLB_DATA1);
+   fault_data0 = intel_uncore_read(uncore, fault_data0_reg);
+   fault_data1 = intel_uncore_read(uncore, fault_data1_reg);
+
fault_addr = ((u64)(fault_data1 & FAULT_VA_HIGH_BITS) << 44) |
 ((u64)fault_data0 << 12);
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0c0f255000c2..673c5dc93d28 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1106,7 +1106,10 @@ static void error_record_engine_registers(struct 
i915_gpu_state *error,
 
if (INTEL_GEN(dev_priv) >= 6) {
ee->rc_psmi = ENGINE_READ(engine, RING_PSMI_CTL);
-   if (INTEL_GEN(dev_priv) >= 8)
+
+   if (INTEL_GEN(dev_priv) >= 12)
+   ee->fault_reg = I915_READ(GEN12_RING_FAULT_REG);
+   else if (INTEL_GEN(dev_priv) >= 8)
ee->fault_reg = I915_READ(GEN8_RING_FAULT_REG);
else
ee->fault_reg = GEN6_RING_FAULT_REG_READ(engine);
@@ -1542,7 +1545,12 @@ static void capture_reg_state(struct i915_gpu_state 
*error)
if (IS_GEN(i915, 7))
error->err_int = intel_uncore_read(uncore, GEN7_ERR_INT);
 
-   if (INTEL_GEN(i915) >= 8) {
+   if (INTEL_GEN(i915) >= 12) {
+   error->fault_data0 = intel_uncore_read(uncore,
+  GEN12_FAULT_TLB_DATA0);
+   error->fault_data1 = intel_uncore_read(uncore,
+  GEN12_FAULT_TLB_DATA1);
+   } else if (INTEL_GEN(i915) >= 8) {
error->fault_data0 = intel_uncore_read(uncore,
   GEN8_FAULT_TLB_DATA0);
error->fault_data1 = intel_uncore_read(uncore,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d2b76121d863..0f0edb9912d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2490,6 +2490,7 @@ enum i915_power_well_id {
 #define RENDER_HWS_PGA_GEN7_MMIO(0x04080)
 #define RING_FAULT_REG(engine) _MMIO(0x4094 + 0x100 * (engine)->hw_id)
 #define GEN8_RING_FAULT_REG_MMIO(0x4094)
+#define GEN12_RING_FAULT_REG   _MMIO(0xcec4)
 #define   GEN8_RING_FAULT_ENGINE_ID(x) (((x) >> 12) & 0x7)
 #define   RING_FAULT_GTTSEL_MASK (1 << 11)
 #define   RING_FAULT_SRCID(x)  (((x) >> 3) & 0xff)
@@ -2633,6 +2634,8 @@ enum i915_power_well_id {
 
 #define GEN8_FAULT_TLB_DATA0   _MMIO(0x4b10)
 #define GEN8_FAULT_TLB_DATA1   

[Intel-gfx] [PATCH] drm/i915/ehl: Ungate DDIC and DDID

2019-07-30 Thread José Roberto de Souza
Specification states that DDI_CLK_SEL needs to be mapped to MG clock
even if MG do not exist on EHL, this will ungate those DDIs.

BSpec: 20845
Cc: Matt Roper 
Cc: Vivek Kasireddy 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c6f38c7b397d..fb58845020dc 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2921,6 +2921,12 @@ static void intel_ddi_clk_select(struct intel_encoder 
*encoder,
if (!intel_phy_is_combo(dev_priv, phy))
I915_WRITE(DDI_CLK_SEL(port),
   icl_pll_to_ddi_clk_sel(encoder, crtc_state));
+   else if (IS_ELKHARTLAKE(dev_priv) && port >= PORT_C)
+   /*
+* MG does not exist but the programming is required
+* to ungate DDIC and DDID
+*/
+   I915_WRITE(DDI_CLK_SEL(port), DDI_CLK_SEL_MG);
} else if (IS_CANNONLAKE(dev_priv)) {
/* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
val = I915_READ(DPCLKA_CFGCR0);
@@ -2961,7 +2967,8 @@ static void intel_ddi_clk_disable(struct intel_encoder 
*encoder)
enum phy phy = intel_port_to_phy(dev_priv, port);
 
if (INTEL_GEN(dev_priv) >= 11) {
-   if (!intel_phy_is_combo(dev_priv, phy))
+   if (!intel_phy_is_combo(dev_priv, phy) ||
+   (IS_ELKHARTLAKE(dev_priv) && port >= PORT_C))
I915_WRITE(DDI_CLK_SEL(port), DDI_CLK_SEL_NONE);
} else if (IS_CANNONLAKE(dev_priv)) {
I915_WRITE(DPCLKA_CFGCR0, I915_READ(DPCLKA_CFGCR0) |
-- 
2.22.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid ce->gem_context->i915

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915: Avoid ce->gem_context->i915
URL   : https://patchwork.freedesktop.org/series/64442/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6582 -> Patchwork_13805


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mmap_gtt@basic-copy:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-icl-u3/igt@gem_mmap_...@basic-copy.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6600u:   [PASS][3] -> [FAIL][4] ([fdo#107707])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-skl-6600u/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-skl-6600u/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][5] -> [WARN][6] ([fdo#109380])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@i915_selftest@live_blt:
- fi-icl-dsi: [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-dsi/igt@i915_selftest@live_blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-icl-dsi/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_reset:
- fi-icl-u3:  [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@i915_selftest@live_reset.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-icl-u3/igt@i915_selftest@live_reset.html

  * igt@prime_vgem@basic-fence-flip:
- fi-icl-u3:  [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13805/fi-icl-u3/igt@prime_v...@basic-fence-flip.html

  
  [fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380


Participating hosts (53 -> 46)
--

  Additional (1): fi-icl-u2 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6582 -> Patchwork_13805

  CI-20190529: 20190529
  CI_DRM_6582: baef11a342abaa746712654a99bd33a11f8f61a3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5115: 21be7a02ac8a8ff46b561c36a69e4dd5a0c2938b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13805: 7b348815d14868b7757fcfd82f02e607817ab8d3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7b348815d148 drm/i915: Avoid ce->gem_context->i915

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 19/23] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Sam Ravnborg
Hi Neil.

> > Signed-off-by: Andrzej Pietrasiewicz 
> > ---
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +++
> >  1 file changed, 20 insertions(+), 20 deletions(-)
> > 
...
> 
> Reviewed-by: Neil Armstrong 

There is now a much simpler v6 of this patch.
Care to take a look and ack/r-b?

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

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Greg KH
On Tue, Jul 30, 2019 at 09:56:59AM -0700, Rodrigo Vivi wrote:
> 
> On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> > On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan 
> > > > > > > > wrote:
> > > > > > > > > A single 32-bit PSR2 training pattern field follows the 
> > > > > > > > > sixteen
> > > > > > > > > element
> > > > > > > > > array of PSR table entries in the VBT spec. But, we 
> > > > > > > > > incorrectly
> > > > > > > > > define
> > > > > > > > > this PSR2 field for each of the PSR table entries. As a 
> > > > > > > > > result, the
> > > > > > > > > PSR1
> > > > > > > > > training pattern duration for any panel_type != 0 will be 
> > > > > > > > > parsed
> > > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for 
> > > > > > > > > VBTs
> > > > > > > > > with bdb
> > > > > > > > > version >= 226 will also be wrong.
> > > > > > > > > 
> > > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > > Cc: José Roberto de Souza 
> > > > > > > > > Cc: sta...@vger.kernel.org
> > > > > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new 
> > > > > > > > > field
> > > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > > 
> > > > > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > > > > Acked-by: Rodrigo Vivi 
> > > > > > > > > Tested-by: François Guerraz 
> > > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > > Link: 
> > > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > > > > > > (cherry picked from commit
> > > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > > 
> > > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > > 
> > > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > > 
> > > > > > This line is automatically added by "dim" tool when
> > > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > > 
> > > > > What do you need her from us to accept this patch?
> > > > 
> > > > Um, you have read the stable kernel rules, right?
> > > > 
> > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > >
> > > > That's what I need for it to go into a stable kernel release.
> > > 
> > > Yes, I have read it. Maybe what I don't understand is just the fact that 
> > > we will
> > > let customers facing issues for 6 weeks or more while the original patch
> > > doesn't land on Linus tree. :(
> > 
> > Then get the patch into Linus's tree!
> > Nothing I can do until that happens, you know this...
> 
> -ENOTENOUGHCOFFEE sorry.
> For some reason I thought this thread had started as the reject of your 
> scripts.

That is correct.  But more coffee is always good.

> This patch is already queued on our drm-intel-fixes and will probably land on
> Linus tree next week. Than your scripts will just get it.
> 
> So, back to your original concern:
> 
> The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
> exist until 5.3 merge window though.

That's fine.

> My question now is regarding our fixes flow adding these future references.
> Do you have any concern with that?

I hate and despise and complain endlessly about how you all are doing
this, but I have learned to just suck it up and accept it.  It is a
major pain in the rear, and I will say that it causes me to delay all
merges of stable drm patches that get merged in Linus's tree in -rc1
until -rc2 or -rc3 is out usually as I have to go through and
hand-determine if a reject happens because it really is a reject, or
because this patch is already in the tree.

So, if this hits Linus's tree "like normal", my scripts will pick it up
and all is good.  I can handle this crazy notation you all feel that
works for you, but I reserve the right to complain.

This original patch, however, was sent only to stable and it seemed to
indicate that I needed to pick it up because it already was upstream (I
saw the cherry-pick line.)  As that is not the case here, fine, no harm,
no foul, let's go get more coffee...

greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH i-g-t v5] tests/i915/gem_exec_async: Update with engine discovery

2019-07-30 Thread Chris Wilson
Quoting Tvrtko Ursulin (2019-07-30 16:20:08)
> 
> On 30/07/2019 09:04, Ramalingam C wrote:
> > On 2019-07-30 at 13:05:27 +0100, Tvrtko Ursulin wrote:
> >>
> >> On 30/07/2019 04:58, Ramalingam C wrote:
> >>> +bool gem_eb_flags_are_different_engines(unsigned eb_flag1, unsigned 
> >>> eb_flag2)
> >>
> >> I think we try to avoid implied int but not sure in this case whether to 
> >> suggest unsigned int, long or uint64_t. If we are suggesting in the 
> >> function name that any flags can be passed in perhaps it should be 
> >> uint64_t and then we filter on the engine bits (flags.. &= 
> >> I915_EXEC_RING_MASK | (3 << 13)) before checking. Yeah, I think that would 
> >> be more robust for a generic helper.
> >>
> >> And add a doc blurb for this helper since it is non-obvious why we went 
> >> for different and not same. My thinking was the name different would be 
> >> clearer to express kind of tri-state nature of this check. (Flags may be 
> >> different, but engines are not guaranteed to be different.) Have I 
> >> over-complicated it? Do we need to make it clearer by naming it 
> >> gem_eb_flags_are_guaranteed_different_engines? :)
> > For me current shape looks good enough :) I will use the uint64_t for
> > parameter types.
> 
> Okay but please add some documentation for the helper (we've been very 
> bad in this work in this respect so far) and also filter out non-engine 
> selection bits from the flags before doing the checks.
> 
> >>
> >>> +{
> >>> +   if (eb_flag1 == eb_flag2)
> >>> +   return false;
> >>> +
> >>> +   /* DEFAULT stands for RENDER in legacy uAPI*/
> >>> +   if ((eb_flag1 == I915_EXEC_DEFAULT && eb_flag2 == I915_EXEC_RENDER) ||
> >>> +(eb_flag1 == I915_EXEC_RENDER && eb_flag2 == I915_EXEC_DEFAULT))
> >>> +   return false;
> >>> +
> >>> +   /*
> >>> +* BSD could be executed on BSD1/BSD2. So BSD and BSD-n could be
> >>> +* same engine.
> >>> +*/
> >>> +   if ((eb_flag1 == I915_EXEC_BSD) &&
> >>> +   (eb_flag2 & ~I915_EXEC_BSD_MASK) == I915_EXEC_BSD)
> >>> +   return false;
> >>> +
> >>> +   if ((eb_flag2 == I915_EXEC_BSD) &&
> >>> +   (eb_flag1 & ~I915_EXEC_BSD_MASK) == I915_EXEC_BSD)
> >>> +   return false;
> >>
> >> I think this works.
> >>
> >> I've also come up with something to merge the two checks, not 100% it's 
> >> correct or more readable:
> >>
> >> if (((flag1 | flag2) & I915_EXEC_RING_MASK)) == I915_EXEC_BSD && // at 
> >> least one is BSD
> >>  !((flag1 ^ flag2) & I915_EXEC_RING_MASK) && // both are BSD
> >>  (((flag1 | flag2) & (3 << 13))) != 3) // not guaranteed different
> >>  return false;
> >>
> >> Would need feeding in some values and checking it works as expected. 
> >> Probably not worth it since I doubt it is more readable.
> > readability perspective, we could stick to the original version. If we
> > want to go ahead we need to do below ops:
> 
> Stick with your version I think.
> 
> Chris is being quiet BTW. Either we are below his radar and he'll scream 
> later, or we managed to approach something he finds passable. ;)

Just waiting until I have to use it in anger :)

Gut feeling is that I won't have to use it, in that if I have two
different timelines pointing to the same physical engine, do I really
care? The situations where I would have distinct engine mappings strike
me as being cases where I'm testing timelines; otherwise I would create
contexts with the same ctx->engines[] map.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Rodrigo Vivi

On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > Hi Greg,
> > > > 
> > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan 
> > > > > > > wrote:
> > > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > > element
> > > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > > define
> > > > > > > > this PSR2 field for each of the PSR table entries. As a result, 
> > > > > > > > the
> > > > > > > > PSR1
> > > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > > with bdb
> > > > > > > > version >= 226 will also be wrong.
> > > > > > > > 
> > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > Cc: José Roberto de Souza 
> > > > > > > > Cc: sta...@vger.kernel.org
> > > > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > 
> > > > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > > > Acked-by: Rodrigo Vivi 
> > > > > > > > Tested-by: François Guerraz 
> > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > Link: 
> > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > > > > > (cherry picked from commit
> > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > 
> > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > 
> > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > 
> > > > > This line is automatically added by "dim" tool when
> > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > 
> > > > What do you need her from us to accept this patch?
> > > 
> > > Um, you have read the stable kernel rules, right?
> > > 
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > >
> > > That's what I need for it to go into a stable kernel release.
> > 
> > Yes, I have read it. Maybe what I don't understand is just the fact that we 
> > will
> > let customers facing issues for 6 weeks or more while the original patch
> > doesn't land on Linus tree. :(
> 
> Then get the patch into Linus's tree!
> Nothing I can do until that happens, you know this...

-ENOTENOUGHCOFFEE sorry.
For some reason I thought this thread had started as the reject of your scripts.

This patch is already queued on our drm-intel-fixes and will probably land on
Linus tree next week. Than your scripts will just get it.

So, back to your original concern:

The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
exist until 5.3 merge window though.

My question now is regarding our fixes flow adding these future references.
Do you have any concern with that?

Sorry and Thanks,
Rodrigo.

> 
> greg k-h
___
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/selftests: Pass intel_context to igt_spinner

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Pass intel_context to igt_spinner
URL   : https://patchwork.freedesktop.org/series/64440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6582 -> Patchwork_13804


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-u3:  [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#109100])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
- fi-cml-u:   [PASS][3] -> [INCOMPLETE][4] ([fdo#110566])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-cml-u/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_reloc@basic-gtt-noreloc:
- fi-icl-dsi: [PASS][5] -> [DMESG-WARN][6] ([fdo#106107])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-dsi/igt@gem_exec_re...@basic-gtt-noreloc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-icl-dsi/igt@gem_exec_re...@basic-gtt-noreloc.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [PASS][7] -> [INCOMPLETE][8] ([fdo#107718])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [PASS][9] -> [FAIL][10] ([fdo#108511])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
- fi-skl-6600u:   [PASS][11] -> [INCOMPLETE][12] ([fdo#107807])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-skl-6600u/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-skl-6600u/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic-flip-a:
- fi-kbl-7567u:   [PASS][13] -> [SKIP][14] ([fdo#109271] / 
[fdo#109278]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html

  
 Possible fixes 

  * igt@i915_selftest@live_blt:
- fi-icl-dsi: [INCOMPLETE][15] ([fdo#107713]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-dsi/igt@i915_selftest@live_blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-icl-dsi/igt@i915_selftest@live_blt.html

  * igt@kms_busy@basic-flip-c:
- fi-kbl-7500u:   [SKIP][17] ([fdo#109271] / [fdo#109278]) -> 
[PASS][18] +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][19] ([fdo#109485]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13804/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566


Participating hosts (53 -> 44)
--

  Additional (1): fi-icl-u2 
  Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 
fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6582 -> Patchwork_13804

  CI-20190529: 20190529
  CI_DRM_6582: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Pass intel_context to mock_request

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Pass intel_context to mock_request
URL   : https://patchwork.freedesktop.org/series/64439/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6582 -> Patchwork_13803


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[PASS][1] -> [SKIP][2] ([fdo#109271]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][3] -> [WARN][4] ([fdo#109380])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][5] -> [SKIP][6] ([fdo#109271]) +23 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@i915_selftest@live_reset:
- fi-icl-u3:  [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@i915_selftest@live_reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-icl-u3/igt@i915_selftest@live_reset.html

  * igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u:   [SKIP][9] ([fdo#109271]) -> [PASS][10] +23 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6582/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13803/fi-icl-u3/igt@prime_v...@basic-fence-flip.html

  
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380


Participating hosts (53 -> 46)
--

  Additional (1): fi-icl-u2 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6582 -> Patchwork_13803

  CI-20190529: 20190529
  CI_DRM_6582: baef11a342abaa746712654a99bd33a11f8f61a3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5115: 21be7a02ac8a8ff46b561c36a69e4dd5a0c2938b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13803: 30129ba327a8f2dc3b06d5c0d082fd66d3c37f13 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

30129ba327a8 drm/i915/selftests: Pass intel_context to mock_request

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Avoid ce->gem_context->i915

2019-07-30 Thread Chris Wilson
My plan for the future is to have kernel contexts no have a GEM context
backpointer (as they will not belong to any GEM context). In a few
places, we use ce->gem_context to simply obtain the i915 backpointer,
which we can use ce->engine->i915 instead.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c| 4 ++--
 drivers/gpu/drm/i915/i915_perf.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 2312a0c6af89..997e122545bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -152,7 +152,7 @@ static void clear_pages_dma_fence_cb(struct dma_fence 
*fence,
 static void clear_pages_worker(struct work_struct *work)
 {
struct clear_pages_work *w = container_of(work, typeof(*w), work);
-   struct drm_i915_private *i915 = w->ce->gem_context->i915;
+   struct drm_i915_private *i915 = w->ce->engine->i915;
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
struct i915_request *rq;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b28c7ca681a8..eb2d28a37b58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1194,7 +1194,7 @@ __intel_context_reconfigure_sseu(struct intel_context *ce,
 {
int ret;
 
-   GEM_BUG_ON(INTEL_GEN(ce->gem_context->i915) < 8);
+   GEM_BUG_ON(INTEL_GEN(ce->engine->i915) < 8);
 
ret = intel_context_lock_pinned(ce);
if (ret)
@@ -1216,7 +1216,7 @@ __intel_context_reconfigure_sseu(struct intel_context *ce,
 static int
 intel_context_reconfigure_sseu(struct intel_context *ce, struct intel_sseu 
sseu)
 {
-   struct drm_i915_private *i915 = ce->gem_context->i915;
+   struct drm_i915_private *i915 = ce->engine->i915;
int ret;
 
ret = mutex_lock_interruptible(>drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 988a4092164e..f2cc69ccb635 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1667,7 +1667,7 @@ gen8_update_reg_state_unlocked(struct intel_context *ce,
   u32 *reg_state,
   const struct i915_oa_config *oa_config)
 {
-   struct drm_i915_private *i915 = ce->gem_context->i915;
+   struct drm_i915_private *i915 = ce->engine->i915;
u32 ctx_oactxctrl = i915->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = i915->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
-- 
2.22.0

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

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Greg KH
On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > Hi Greg,
> > > 
> > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > element
> > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > define
> > > > > > > this PSR2 field for each of the PSR table entries. As a result, 
> > > > > > > the
> > > > > > > PSR1
> > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > with bdb
> > > > > > > version >= 226 will also be wrong.
> > > > > > > 
> > > > > > > Cc: Rodrigo Vivi 
> > > > > > > Cc: José Roberto de Souza 
> > > > > > > Cc: sta...@vger.kernel.org
> > > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > > Acked-by: Rodrigo Vivi 
> > > > > > > Tested-by: François Guerraz 
> > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > Link: 
> > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > > > > (cherry picked from commit
> > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > 
> > > > > > There is no such commit in Linus's kernel tree :(
> > > > 
> > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > 
> > > > This line is automatically added by "dim" tool when
> > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > 
> > > What do you need her from us to accept this patch?
> > 
> > Um, you have read the stable kernel rules, right?
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> >
> > That's what I need for it to go into a stable kernel release.
> 
> Yes, I have read it. Maybe what I don't understand is just the fact that we 
> will
> let customers facing issues for 6 weeks or more while the original patch
> doesn't land on Linus tree. :(

Then get the patch into Linus's tree!
Nothing I can do until that happens, you know this...

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

Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction

2019-07-30 Thread Daniel Vetter
On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote:
> Support basic eviction for regions.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Abdiel Janulgue 

So from a very high level this looks like it was largely modelled after
i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're
running out of stuff" code). Any specific reasons?

I think i915_gem_evict is a lot closer match for what we want for vram (it
started out to manage severely limitted GTT on gen2/3/4) after all. With
the complication that we'll have to manage physical memory with multiple
virtual mappings of it on top, so unfortunately we can't just reuse the
locking patter Chris has come up with in his struct_mutex-removal branch.
But at least conceptually it should be a lot closer.

But I might be entirely off the track with reconstructing how this code
came to be, so please elaborate a bit.

Thanks, Daniel

> ---
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  7 ++
>  drivers/gpu/drm/i915/i915_gem.c   | 16 
>  drivers/gpu/drm/i915/intel_memory_region.c| 89 ++-
>  drivers/gpu/drm/i915/intel_memory_region.h| 10 +++
>  .../drm/i915/selftests/intel_memory_region.c  | 73 +++
>  drivers/gpu/drm/i915/selftests/mock_region.c  |  1 +
>  6 files changed, 192 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 8d760e852c4b..87000fc24ab3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -72,6 +72,13 @@ struct drm_i915_gem_object {
>* List of memory region blocks allocated for this object.
>*/
>   struct list_head blocks;
> + /**
> +  * Element within memory_region->objects or memory_region->purgeable if
> +  * the object is marked as DONTNEED. Access is protected by
> +  * memory_region->obj_lock.
> +  */
> + struct list_head region_link;
> + struct list_head eviction_link;
>  
>   struct {
>   /**
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index db3744b0bc80..85677ae89849 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1122,6 +1122,22 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void 
> *data,
>   !i915_gem_object_has_pages(obj))
>   i915_gem_object_truncate(obj);
>  
> + if (obj->memory_region) {
> + mutex_lock(>memory_region->obj_lock);
> +
> + switch (obj->mm.madv) {
> + case I915_MADV_WILLNEED:
> + list_move(>region_link, 
> >memory_region->objects);
> + break;
> + default:
> + list_move(>region_link,
> +   >memory_region->purgeable);
> + break;
> + }
> +
> + mutex_unlock(>memory_region->obj_lock);
> + }
> +
>   args->retained = obj->mm.madv != __I915_MADV_PURGED;
>   mutex_unlock(>mm.lock);
>  
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
> b/drivers/gpu/drm/i915/intel_memory_region.c
> index 4c89853a7769..721b47e46492 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -6,6 +6,56 @@
>  #include "intel_memory_region.h"
>  #include "i915_drv.h"
>  
> +int i915_memory_region_evict(struct intel_memory_region *mem,
> +  resource_size_t target)
> +{
> + struct drm_i915_gem_object *obj, *on;
> + resource_size_t found;
> + LIST_HEAD(purgeable);
> + int err;
> +
> + err = 0;
> + found = 0;
> +
> + mutex_lock(>obj_lock);
> +
> + list_for_each_entry(obj, >purgeable, region_link) {
> + if (!i915_gem_object_has_pages(obj))
> + continue;
> +
> + if (READ_ONCE(obj->pin_global))
> + continue;
> +
> + if (atomic_read(>bind_count))
> + continue;
> +
> + list_add(>eviction_link, );
> +
> + found += obj->base.size;
> + if (found >= target)
> + goto found;
> + }
> +
> + err = -ENOSPC;
> +found:
> + list_for_each_entry_safe(obj, on, , eviction_link) {
> + if (!err) {
> + __i915_gem_object_put_pages(obj, I915_MM_SHRINKER);
> +
> + mutex_lock_nested(>mm.lock, I915_MM_SHRINKER);
> + if (!i915_gem_object_has_pages(obj))
> + obj->mm.madv = __I915_MADV_PURGED;
> + mutex_unlock(>mm.lock);
> + }
> +
> + list_del(>eviction_link);
> + }
> +
> + mutex_unlock(>obj_lock);
> +
> + return err;
> +}
> +
>  static void
>  memory_region_free_pages(struct drm_i915_gem_object *obj,
>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Pass intel_context to igt_spinner

2019-07-30 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Pass intel_context to igt_spinner
URL   : https://patchwork.freedesktop.org/series/64440/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b93d1639435b drm/i915/selftests: Pass intel_context to igt_spinner
-:469: ERROR:SPACING: space required after that ',' (ctx:VxV)
#469: FILE: drivers/gpu/drm/i915/gt/selftest_workarounds.c:257:
+   rq = igt_spinner_create_request(spin, ce,MI_NOOP);
^

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

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

Re: [Intel-gfx] [PATCH v2 29/37] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET

2019-07-30 Thread Daniel Vetter
On Tue, Jul 30, 2019 at 03:28:11PM +0100, Matthew Auld wrote:
> On 30/07/2019 10:49, Daniel Vetter wrote:
> > On Thu, Jun 27, 2019 at 09:56:25PM +0100, Matthew Auld wrote:
> > > From: Abdiel Janulgue 
> > > 
> > > Add a new CPU mmap implementation that allows multiple fault handlers
> > > that depends on the object's backing pages.
> > > 
> > > Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
> > > and use the zero extending behaviour of drm to differentiate between
> > > them, when we inspect the flags.
> > > 
> > > Signed-off-by: Abdiel Janulgue 
> > > Signed-off-by: Matthew Auld 
> > > Cc: Joonas Lahtinen 
> > 
> > So I thought that the plan is to reject invalid mmaps, i.e. mmap modes
> > which are not compatibale with all placement options. Given that, why do
> > we need this?
> 
> We are meant to reject anything !wc for LMEM. There were some patches for
> that but I guess got lost under the radar...
> 
> > 
> > - cpu mmap with all the flags still keep working, as long as the only
> >placement you select is smem.
> > 
> > - for lmem/stolen the only option we have is a wc mapping, either through
> >the pci bar or through the gtt. So for objects only sitting in there
> >also no problem, we can just keep using the current gtt mmap stuff (but
> >redirect it internally).
> > 
> > - that leaves us with objects which can move around. Only option allows is
> >WC, and the gtt mmap ioctl does that already. When the object is in smem
> >we'll need to redirect it to a cpu wc mmap, but I think we need to do
> >that anyway.
> 
> So for legacy, gtt_mmap will still go through the aperture, otherwise if
> LMEM is supported then there is no aperture, so we just wc mmap via cpu or
> LMEMBAR depending on the final object placement. And cpu_mmap still works if
> we don't care about LMEM. Hmm, so do we even need most of the previous patch
> then? ALso does that mean we also have to track the placement of an object
> in igt?
> 
> gem_mmap__wc:
> 
> if (supports_lmem(dev))
>   gtt_mmap();
> else
>   gem_mmap(wc);
> 
> gem_mmap__wc:
> 
> if (placement_contains(obj, LMEM))
>   gtt_mmap();
> else
>   gem_mmap(wc);
> 
> ?

Well if you want cpu wc mmaps, then just allocate it as smem ... we might
need a new gem_mmap__lmem I guess to exercise all the possible ways to get
at stuff in lmem (including when it migrates around underneath us while we
access it through the mmap). I wouldn't try too hard to smash all these
use/testcases into one.

> > So not really seeing what the uapi problem is you're trying to solve here?
> > 
> > Can you pls explain why we need this?
> 
> The naming of gtt_mmap seemed confusing, since there is no aperture, and
> having one mmap ioctl to cover both smem and lmem seemed like a nice
> idea...also I think umd's stopped using gtt_mmap(or were told to?) but maybe
> those aren't good enough reasons.

We stopped using gtt mmap because for many cases cpu WC mmap is faster.

Wrt having a clean slate: Not sure why this would benefit us, we just
diverge a bit more from how this works on !lmem, so a bit more complexity
(not much) everywhere for not much gain.

I'm also not sure whether there will be a whole lot of uses of such a
magic LMEMBAR wc mapping. It's probably slow for the exact same reasons
gtt mmap is slow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Rodrigo Vivi
On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > Hi Greg,
> > 
> > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > element
> > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > define
> > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > PSR1
> > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > with bdb
> > > > > > version >= 226 will also be wrong.
> > > > > > 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Cc: José Roberto de Souza 
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > Reviewed-by: Ville Syrjälä 
> > > > > > Reviewed-by: José Roberto de Souza 
> > > > > > Acked-by: Rodrigo Vivi 
> > > > > > Tested-by: François Guerraz 
> > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > Link: 
> > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > > > (cherry picked from commit
> > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > 
> > > > > There is no such commit in Linus's kernel tree :(
> > > 
> > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > 
> > > This line is automatically added by "dim" tool when
> > > cherry-picking queued stuff for our drm-intel fixes branches.
> > 
> > What do you need her from us to accept this patch?
> 
> Um, you have read the stable kernel rules, right?
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
> That's what I need for it to go into a stable kernel release.

Yes, I have read it. Maybe what I don't understand is just the fact that we will
let customers facing issues for 6 weeks or more while the original patch
doesn't land on Linus tree. :(

> 
> thanks,
> 
> greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 34/37] drm/i915: Introduce GEM_OBJECT_SETPARAM with I915_PARAM_MEMORY_REGION

2019-07-30 Thread Daniel Vetter
On Thu, Jun 27, 2019 at 09:56:30PM +0100, Matthew Auld wrote:
> From: Abdiel Janulgue 
> 
> This call will specify which memory region an object should be placed.
> 
> Note that changing the object's backing storage should be immediately
> done after an object is created or if it's not yet in use, otherwise
> this will fail on a busy object.
> 
> Signed-off-by: Abdiel Janulgue 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c |  12 ++
>  drivers/gpu/drm/i915/gem/i915_gem_context.h |   2 +
>  drivers/gpu/drm/i915/gem/i915_gem_ioctls.h  |   2 +
>  drivers/gpu/drm/i915/gem/i915_gem_object.c  | 117 
>  drivers/gpu/drm/i915/i915_drv.c |   2 +-
>  include/uapi/drm/i915_drm.h |  27 +
>  6 files changed, 161 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 8a9787cf0cd0..157ca8247752 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -75,6 +75,7 @@
>  #include "i915_globals.h"
>  #include "i915_trace.h"
>  #include "i915_user_extensions.h"
> +#include "i915_gem_ioctls.h"
>  
>  #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
>  
> @@ -2357,6 +2358,17 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
> *dev, void *data,
>   return ret;
>  }
>  
> +int i915_gem_setparam_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_i915_gem_context_param *args = data;
> +
> + if (args->param <= I915_CONTEXT_PARAM_MAX)
> + return i915_gem_context_setparam_ioctl(dev, data, file);
> +
> + return i915_gem_object_setparam_ioctl(dev, data, file);
> +}
> +
>  int i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
>  void *data, struct drm_file *file)
>  {
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index 9691dd062f72..d5a9a63bb34c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -157,6 +157,8 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
> *dev, void *data,
>   struct drm_file *file_priv);
>  int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
> +int i915_gem_setparam_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file);
>  int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file);
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
> index 5abd5b2172f2..af7465bceebd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
> @@ -32,6 +32,8 @@ int i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void 
> *data,
>   struct drm_file *file);
>  int i915_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
> +int i915_gem_object_setparam_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file_priv);
>  int i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file);
>  int i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 691af388e4e7..bc95f449de50 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -551,6 +551,123 @@ int __init i915_global_objects_init(void)
>   return 0;
>  }
>  
> +static enum intel_region_id
> +__region_id(u32 region)
> +{
> + enum intel_region_id id;
> +
> + for (id = 0; id < ARRAY_SIZE(intel_region_map); ++id) {
> + if (intel_region_map[id] == region)
> + return id;
> + }
> +
> + return INTEL_MEMORY_UKNOWN;
> +}
> +
> +static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
> +  struct drm_i915_gem_object_param *args,
> +  struct drm_file *file,
> +  struct drm_i915_gem_object *obj)
> +{
> + struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
> + u32 __user *uregions = u64_to_user_ptr(args->data);
> + u32 uregions_copy[INTEL_MEMORY_UKNOWN];
> + int i, ret;
> +
> + if (args->size > ARRAY_SIZE(intel_region_map))
> + return -EINVAL;
> +
> + memset(uregions_copy, 0, sizeof(uregions_copy));
> + for (i = 0; i < args->size; i++) {
> + u32 region;
> +
> + 

Re: [Intel-gfx] [PATCH] drm/i915/uc: don't enable communication twice on resume

2019-07-30 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2019-07-30 17:05:19)
> 
> 
> On 7/30/19 1:14 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-07-29 23:28:00)
> >> When coming out of S3/S4 we sanitize and re-init the HW, which includes
> >> enabling communication during uc_init_hw. We therefore don't want to do
> >> that again in uc_resume and can just tell GuC to reload its state.
> >>
> >> Signed-off-by: Daniele Ceraolo Spurio 
> >> Cc: Michal Wajdeczko 
> >> Cc: Chris Wilson 
> >> ---
> >>   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++-
> >>   1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
> >> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> index fafa9be1e12a..34706a753793 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> @@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc 
> >> *guc)
> >>  guc->interrupts.disable(guc);
> >>   }
> >>   
> >> +static bool guc_communication_enabled(struct intel_guc *guc)
> >> +{
> >> +   return guc->send != intel_guc_send_nop;
> >> +}
> >> +
> >>   static int guc_enable_communication(struct intel_guc *guc)
> >>   {
> >>  struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> >>  int ret;
> >>   
> >> +   GEM_BUG_ON(guc_communication_enabled(guc));
> >> +
> >>  ret = intel_guc_ct_enable(>ct);
> >>  if (ret)
> >>  return ret;
> >> @@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
> >>  if (!intel_guc_is_running(guc))
> >>  return 0;
> >>   
> >> -   guc_enable_communication(guc);
> >> +   /*
> >> +* When coming out of S3/S4 we sanitize and re-init the HW, so
> >> +* communication is already re-enabled at this point and we just 
> >> need
> >> +* to tell GuC to reload its internal state. During runtime resume 
> >> we
> >> +* instead want to re-init everything.
> >> +*/
> >> +   if (!guc_communication_enabled(guc))
> >> +   guc_enable_communication(guc);
> > 
> > We distinguish runtime_suspend from suspend, but not runtime_resume from
> > resume. Is that distinction worthwhile, could we use it be more strict
> > over the expected state?
> 
> The actual actions we want to perform in both cases are the same, apart 
> from the communication side. What about:
> 
> static int __uc_resume(struct intel_uc *uc, bool enable_comm)
> {
> if (!intel_guc_is_running())
> return 0;
> 
> GEM_BUG_ON(enable comm == guc_communication_enabled());
> 
> if (enable_comm)
> guc_enable_communication();
> 
> err = intel_guc_resume();
> }
> 
> intel_uc_runtime_resume()
> {
> __uc_resume(uc, true);
> }
> 
> intel_uc_resume()
> {
> __uc_resume(uc, false);
> }

That works for me. Having uc->suspend unnerved me worrying about what
happens if gets out of sync. I like having the link from drm_resume ->
uc_resume and drm_runtime_resume -> uc_runtime_resume.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/uc: don't enable communication twice on resume

2019-07-30 Thread Daniele Ceraolo Spurio



On 7/30/19 1:14 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2019-07-29 23:28:00)

When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index fafa9be1e12a..34706a753793 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -233,11 +233,18 @@ static void guc_disable_interrupts(struct intel_guc *guc)
 guc->interrupts.disable(guc);
  }
  
+static bool guc_communication_enabled(struct intel_guc *guc)

+{
+   return guc->send != intel_guc_send_nop;
+}
+
  static int guc_enable_communication(struct intel_guc *guc)
  {
 struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
 int ret;
  
+   GEM_BUG_ON(guc_communication_enabled(guc));

+
 ret = intel_guc_ct_enable(>ct);
 if (ret)
 return ret;
@@ -558,7 +565,14 @@ int intel_uc_resume(struct intel_uc *uc)
 if (!intel_guc_is_running(guc))
 return 0;
  
-   guc_enable_communication(guc);

+   /*
+* When coming out of S3/S4 we sanitize and re-init the HW, so
+* communication is already re-enabled at this point and we just need
+* to tell GuC to reload its internal state. During runtime resume we
+* instead want to re-init everything.
+*/
+   if (!guc_communication_enabled(guc))
+   guc_enable_communication(guc);


We distinguish runtime_suspend from suspend, but not runtime_resume from
resume. Is that distinction worthwhile, could we use it be more strict
over the expected state?
-Chris



The actual actions we want to perform in both cases are the same, apart 
from the communication side. What about:


static int __uc_resume(struct intel_uc *uc, bool enable_comm)
{
if (!intel_guc_is_running())
return 0;

GEM_BUG_ON(enable comm == guc_communication_enabled());

if (enable_comm)
guc_enable_communication();

err = intel_guc_resume();
}

intel_uc_runtime_resume()
{
__uc_resume(uc, true);
}

intel_uc_resume()
{
__uc_resume(uc, false);
}

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

[Intel-gfx] [PATCH] drm/i915/selftests: Pass intel_context to igt_spinner

2019-07-30 Thread Chris Wilson
Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gem/selftests/i915_gem_context.c |  43 +++
 drivers/gpu/drm/i915/gt/selftest_lrc.c| 115 ++
 .../gpu/drm/i915/gt/selftest_workarounds.c|  23 +++-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |  32 +++--
 drivers/gpu/drm/i915/selftests/igt_spinner.h  |   6 +-
 5 files changed, 119 insertions(+), 100 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 7f9f6701b32c..c24430352a38 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -821,8 +821,7 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
 #define TEST_RESET BIT(2)
 
 static int
-__sseu_prepare(struct drm_i915_private *i915,
-  const char *name,
+__sseu_prepare(const char *name,
   unsigned int flags,
   struct intel_context *ce,
   struct igt_spinner **spin)
@@ -838,14 +837,11 @@ __sseu_prepare(struct drm_i915_private *i915,
if (!*spin)
return -ENOMEM;
 
-   ret = igt_spinner_init(*spin, i915);
+   ret = igt_spinner_init(*spin, ce->engine->gt);
if (ret)
goto err_free;
 
-   rq = igt_spinner_create_request(*spin,
-   ce->gem_context,
-   ce->engine,
-   MI_NOOP);
+   rq = igt_spinner_create_request(*spin, ce, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
goto err_fini;
@@ -871,8 +867,7 @@ __sseu_prepare(struct drm_i915_private *i915,
 }
 
 static int
-__read_slice_count(struct drm_i915_private *i915,
-  struct intel_context *ce,
+__read_slice_count(struct intel_context *ce,
   struct drm_i915_gem_object *obj,
   struct igt_spinner *spin,
   u32 *rpcs)
@@ -901,7 +896,7 @@ __read_slice_count(struct drm_i915_private *i915,
return ret;
}
 
-   if (INTEL_GEN(i915) >= 11) {
+   if (INTEL_GEN(ce->engine->i915) >= 11) {
s_mask = GEN11_RPCS_S_CNT_MASK;
s_shift = GEN11_RPCS_S_CNT_SHIFT;
} else {
@@ -944,8 +939,7 @@ __check_rpcs(const char *name, u32 rpcs, int slices, 
unsigned int expected,
 }
 
 static int
-__sseu_finish(struct drm_i915_private *i915,
- const char *name,
+__sseu_finish(const char *name,
  unsigned int flags,
  struct intel_context *ce,
  struct drm_i915_gem_object *obj,
@@ -962,14 +956,13 @@ __sseu_finish(struct drm_i915_private *i915,
goto out;
}
 
-   ret = __read_slice_count(i915, ce, obj,
+   ret = __read_slice_count(ce, obj,
 flags & TEST_RESET ? NULL : spin, );
ret = __check_rpcs(name, rpcs, ret, expected, "Context", "!");
if (ret)
goto out;
 
-   ret = __read_slice_count(i915, ce->engine->kernel_context, obj,
-NULL, );
+   ret = __read_slice_count(ce->engine->kernel_context, obj, NULL, );
ret = __check_rpcs(name, rpcs, ret, slices, "Kernel context", "!");
 
 out:
@@ -977,11 +970,12 @@ __sseu_finish(struct drm_i915_private *i915,
igt_spinner_end(spin);
 
if ((flags & TEST_IDLE) && ret == 0) {
-   ret = i915_gem_wait_for_idle(i915, 0, MAX_SCHEDULE_TIMEOUT);
+   ret = i915_gem_wait_for_idle(ce->engine->i915,
+0, MAX_SCHEDULE_TIMEOUT);
if (ret)
return ret;
 
-   ret = __read_slice_count(i915, ce, obj, NULL, );
+   ret = __read_slice_count(ce, obj, NULL, );
ret = __check_rpcs(name, rpcs, ret, expected,
   "Context", " after idle!");
}
@@ -990,8 +984,7 @@ __sseu_finish(struct drm_i915_private *i915,
 }
 
 static int
-__sseu_test(struct drm_i915_private *i915,
-   const char *name,
+__sseu_test(const char *name,
unsigned int flags,
struct intel_context *ce,
struct drm_i915_gem_object *obj,
@@ -1000,7 +993,7 @@ __sseu_test(struct drm_i915_private *i915,
struct igt_spinner *spin = NULL;
int ret;
 
-   ret = __sseu_prepare(i915, name, flags, ce, );
+   ret = __sseu_prepare(name, flags, ce, );
if (ret)
return ret;
 
@@ -1008,7 +1001,7 @@ __sseu_test(struct drm_i915_private *i915,
if (ret)
goto out_spin;
 
-   ret = __sseu_finish(i915, name, flags, ce, obj,
+   ret = 

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Greg KH
On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> Hi Greg,
> 
> On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > element
> > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > define
> > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > PSR1
> > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > with bdb
> > > > > version >= 226 will also be wrong.
> > > > > 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: José Roberto de Souza 
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: sta...@vger.kernel.org #v5.2
> > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > with PSR2 TP2/3 wakeup time")
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > Reviewed-by: Ville Syrjälä 
> > > > > Reviewed-by: José Roberto de Souza 
> > > > > Acked-by: Rodrigo Vivi 
> > > > > Tested-by: François Guerraz 
> > > > > Signed-off-by: Rodrigo Vivi 
> > > > > Link: 
> > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > > (cherry picked from commit
> > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > 
> > > > There is no such commit in Linus's kernel tree :(
> > 
> > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > 
> > This line is automatically added by "dim" tool when
> > cherry-picking queued stuff for our drm-intel fixes branches.
> 
> What do you need her from us to accept this patch?

Um, you have read the stable kernel rules, right?
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

That's what I need for it to go into a stable kernel release.

thanks,

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

Re: [Intel-gfx] [PATCH i-g-t v5] tests/i915/gem_exec_async: Update with engine discovery

2019-07-30 Thread Tvrtko Ursulin


On 30/07/2019 09:04, Ramalingam C wrote:

On 2019-07-30 at 13:05:27 +0100, Tvrtko Ursulin wrote:


On 30/07/2019 04:58, Ramalingam C wrote:

Legacy execbuf abi tests are prefixed with legacy. New test are added to
run on physical engines accessed through engine discovery.

So legacy tests run on the unconfigured (with engine map) context and
use a new helper gem_eb_flags_to_engine to look up the engine from the
intel_execution_engines2 static list. This is only to enable the core
test code to be shared.

Places where new contexts are created had to be updated to either
equally configure the contexts or not.

v2:
retained the test as it is for legacy uapi testing and duplciated for
new engine discovery [Tvrtko]
v3:
Few nits addressed [Tvrtko]
v4:
In legacy uAPI test path, iterate through for_each_engine [Tvrtko]
v5:
Function for exec_flag comparison [Tvrtko]

Signed-off-by: Ramalingam C 
---
   lib/igt_gt.c| 25 ++
   lib/igt_gt.h|  1 +
   tests/i915/gem_exec_async.c | 52 +++--
   3 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 78e3cd08925b..f594a46282bc 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -633,3 +633,28 @@ bool gem_ring_has_physical_engine(int fd, unsigned ring)
   
   	return gem_has_ring(fd, ring);

   }
+
+bool gem_eb_flags_are_different_engines(unsigned eb_flag1, unsigned eb_flag2)


I think we try to avoid implied int but not sure in this case whether to suggest unsigned 
int, long or uint64_t. If we are suggesting in the function name that any flags can be 
passed in perhaps it should be uint64_t and then we filter on the engine bits (flags.. 
&= I915_EXEC_RING_MASK | (3 << 13)) before checking. Yeah, I think that would 
be more robust for a generic helper.

And add a doc blurb for this helper since it is non-obvious why we went for 
different and not same. My thinking was the name different would be clearer to 
express kind of tri-state nature of this check. (Flags may be different, but 
engines are not guaranteed to be different.) Have I over-complicated it? Do we 
need to make it clearer by naming it 
gem_eb_flags_are_guaranteed_different_engines? :)

For me current shape looks good enough :) I will use the uint64_t for
parameter types.


Okay but please add some documentation for the helper (we've been very 
bad in this work in this respect so far) and also filter out non-engine 
selection bits from the flags before doing the checks.





+{
+   if (eb_flag1 == eb_flag2)
+   return false;
+
+   /* DEFAULT stands for RENDER in legacy uAPI*/
+   if ((eb_flag1 == I915_EXEC_DEFAULT && eb_flag2 == I915_EXEC_RENDER) ||
+(eb_flag1 == I915_EXEC_RENDER && eb_flag2 == I915_EXEC_DEFAULT))
+   return false;
+
+   /*
+* BSD could be executed on BSD1/BSD2. So BSD and BSD-n could be
+* same engine.
+*/
+   if ((eb_flag1 == I915_EXEC_BSD) &&
+   (eb_flag2 & ~I915_EXEC_BSD_MASK) == I915_EXEC_BSD)
+   return false;
+
+   if ((eb_flag2 == I915_EXEC_BSD) &&
+   (eb_flag1 & ~I915_EXEC_BSD_MASK) == I915_EXEC_BSD)
+   return false;


I think this works.

I've also come up with something to merge the two checks, not 100% it's correct 
or more readable:

if (((flag1 | flag2) & I915_EXEC_RING_MASK)) == I915_EXEC_BSD && // at least 
one is BSD
 !((flag1 ^ flag2) & I915_EXEC_RING_MASK) && // both are BSD
 (((flag1 | flag2) & (3 << 13))) != 3) // not guaranteed different
return false;

Would need feeding in some values and checking it works as expected. Probably 
not worth it since I doubt it is more readable.

readability perspective, we could stick to the original version. If we
want to go ahead we need to do below ops:


Stick with your version I think.

Chris is being quiet BTW. Either we are below his radar and he'll scream 
later, or we managed to approach something he finds passable. ;)


Regards,

Tvrtko



if (((flag1 | flag2) & I915_EXEC_BSD) &&  //Atleast one is BSD
 !((flag1 ^ flag2) & I915_EXEC_BSD) && //Both are BSD
 ((flag1 | flag2) & I915_EXEC_RING_MASK) != I915_EXEC_RING_MASK) //Not BSD0 
and BSD1
return false;



+
+   return true;
+}
diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index 73b5002a04bd..760b8baefc48 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -101,5 +101,6 @@ extern const struct intel_execution_engine2 {
   } intel_execution_engines2[];
   
   int gem_execbuf_flags_to_engine_class(unsigned int flags);

+bool gem_eb_flags_are_different_engines(unsigned eb_flag1, unsigned eb_flag2);
   
   #endif /* IGT_GT_H */

diff --git a/tests/i915/gem_exec_async.c b/tests/i915/gem_exec_async.c
index 9a06af7e29cb..5fdce5ac5b77 100644
--- a/tests/i915/gem_exec_async.c
+++ b/tests/i915/gem_exec_async.c
@@ -80,9 +80,10 @@ static void store_dword(int fd, unsigned ring,
   

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

2019-07-30 Thread Rodrigo Vivi
Hi Greg,

On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> On Wed, Jul 24, 2019 at 05:27:42PM +, Souza, Jose wrote:
> > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > element
> > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > define
> > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > PSR1
> > > > training pattern duration for any panel_type != 0 will be parsed
> > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > with bdb
> > > > version >= 226 will also be wrong.
> > > > 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: José Roberto de Souza 
> > > > Cc: sta...@vger.kernel.org
> > > > Cc: sta...@vger.kernel.org #v5.2
> > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > with PSR2 TP2/3 wakeup time")
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > Reviewed-by: Ville Syrjälä 
> > > > Reviewed-by: José Roberto de Souza 
> > > > Acked-by: Rodrigo Vivi 
> > > > Tested-by: François Guerraz 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandi...@intel.com
> > > > (cherry picked from commit
> > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > 
> > > There is no such commit in Linus's kernel tree :(
> 
> not yet... It is queued for 5.3 on drm-intel-next-queued.
> 
> This line is automatically added by "dim" tool when
> cherry-picking queued stuff for our drm-intel fixes branches.

What do you need her from us to accept this patch?

> 
> > > 
> > 
> > It is still on drm-intel/drm-intel-next-queued -
> > ssh://git.freedesktop.org/git/drm-intel
> > 
> > Rodrigo do you know when is the next pull-request to Linus?
> 
> I will start doing the pull requests to Dave and Daniel soon,
> but this doesn't reach Linus tree before next merge window.
> 
> Eventually it will be there.
> 
> If this is a blocker fell free to remove the line and merge the
> patch please, because this fix very critical issue that impact users.
> So we can continue the discussion in parallel on how to handle
> commit links like this in a better way.
> 
> Thanks,
> Rodrigo.
> 
> > ___
> > 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: stop genereating old header test files

2019-07-30 Thread Lucas De Marchi

On Tue, Jul 30, 2019 at 12:05:13PM +0300, Jani Nikula wrote:

On Mon, 29 Jul 2019, Lucas De Marchi  wrote:

Commit e846f0dc57f4 ("kbuild: add support for ensuring headers are
self-contained") replaced the old mechanism we had in i915 to test the
header files are self-contained, but later commits kept adding Makefiles
to subdirs. The end result is that after a build we have several
header_test_* files that are not used. Stop generating them.

Since now it's very simple to add the headers to the list of files to be
tested, a separate Makefile.header-test is overkill, so embed it in the
original Makefile.


Sorry, beat you to it with [1], which also uses header-test-pattern-y
instead of $(wildcard).


np, as long as I don't see the untracked files, I'm fine :)

Lucas De Marchi



Thanks,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/20190729140847.18557-1-jani.nik...@intel.com



Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/Makefile | 24 -
 drivers/gpu/drm/i915/Makefile.header-test | 27 ---
 drivers/gpu/drm/i915/display/Makefile |  2 +-
 .../gpu/drm/i915/display/Makefile.header-test | 16 ---
 drivers/gpu/drm/i915/gem/Makefile |  2 +-
 drivers/gpu/drm/i915/gem/Makefile.header-test | 16 ---
 drivers/gpu/drm/i915/gt/Makefile  |  2 +-
 drivers/gpu/drm/i915/gt/Makefile.header-test  | 16 ---
 drivers/gpu/drm/i915/gt/uc/Makefile   |  2 +-
 .../gpu/drm/i915/gt/uc/Makefile.header-test   | 16 ---
 10 files changed, 27 insertions(+), 96 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/Makefile.header-test
 delete mode 100644 drivers/gpu/drm/i915/display/Makefile.header-test
 delete mode 100644 drivers/gpu/drm/i915/gem/Makefile.header-test
 delete mode 100644 drivers/gpu/drm/i915/gt/Makefile.header-test
 delete mode 100644 drivers/gpu/drm/i915/gt/uc/Makefile.header-test

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42c17a7b0cb0..f11bf0225920 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -32,7 +32,29 @@ subdir-ccflags-y += \
$(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)

 # Extra header tests
-include $(src)/Makefile.header-test
+header-test-$(CONFIG_DRM_I915_WERROR) := \
+   i915_active_types.h \
+   i915_debugfs.h \
+   i915_drv.h \
+   i915_fixed.h \
+   i915_gem_gtt.h \
+   i915_globals.h \
+   i915_irq.h \
+   i915_params.h \
+   i915_priolist_types.h \
+   i915_pvinfo.h \
+   i915_reg.h \
+   i915_scheduler_types.h \
+   i915_utils.h \
+   i915_vgpu.h \
+   intel_csr.h \
+   intel_drv.h \
+   intel_gvt.h \
+   intel_pm.h \
+   intel_runtime_pm.h \
+   intel_sideband.h \
+   intel_uncore.h \
+   intel_wakeref.h

 subdir-ccflags-y += -I$(srctree)/$(src)

diff --git a/drivers/gpu/drm/i915/Makefile.header-test 
b/drivers/gpu/drm/i915/Makefile.header-test
deleted file mode 100644
index 59908b067942..
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ /dev/null
@@ -1,27 +0,0 @@
-# SPDX-License-Identifier: MIT
-# Copyright © 2019 Intel Corporation
-
-# Test the headers are compilable as standalone units
-header-test-$(CONFIG_DRM_I915_WERROR) := \
-   i915_active_types.h \
-   i915_debugfs.h \
-   i915_drv.h \
-   i915_fixed.h \
-   i915_gem_gtt.h \
-   i915_globals.h \
-   i915_irq.h \
-   i915_params.h \
-   i915_priolist_types.h \
-   i915_pvinfo.h \
-   i915_reg.h \
-   i915_scheduler_types.h \
-   i915_utils.h \
-   i915_vgpu.h \
-   intel_csr.h \
-   intel_drv.h \
-   intel_gvt.h \
-   intel_pm.h \
-   intel_runtime_pm.h \
-   intel_sideband.h \
-   intel_uncore.h \
-   intel_wakeref.h
diff --git a/drivers/gpu/drm/i915/display/Makefile 
b/drivers/gpu/drm/i915/display/Makefile
index eec6961015a1..12b446a82fef 100644
--- a/drivers/gpu/drm/i915/display/Makefile
+++ b/drivers/gpu/drm/i915/display/Makefile
@@ -2,4 +2,4 @@
 subdir-ccflags-y += -I$(srctree)/$(src)/..

 # Extra header tests
-include $(src)/Makefile.header-test
+header-test-$(CONFIG_DRM_I915_WERROR) := $(notdir $(filter-out 
%/intel_vbt_defs.h,$(wildcard $(src)/*.h)))
diff --git a/drivers/gpu/drm/i915/display/Makefile.header-test 
b/drivers/gpu/drm/i915/display/Makefile.header-test
deleted file mode 100644
index fc7d4e5bd2c6..
--- a/drivers/gpu/drm/i915/display/Makefile.header-test
+++ /dev/null
@@ -1,16 +0,0 @@
-# SPDX-License-Identifier: MIT
-# Copyright © 2019 Intel Corporation
-
-# Test the headers are compilable as standalone units
-header_test := $(notdir $(filter-out %/intel_vbt_defs.h,$(wildcard 
$(src)/*.h)))
-
-quiet_cmd_header_test = HDRTEST $@
-  cmd_header_test = echo "\#include \"$( $@
-
-header_test_%.c: %.h
-   $(call cmd,header_test)
-
-extra-$(CONFIG_DRM_I915_WERROR) += \
-   

Re: [Intel-gfx] [PATCH 2/6] drm/i915: move gt_cleanup_early out of gem_cleanup_early

2019-07-30 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2019-07-30 15:56:57)
> 
> 
> On 7/30/19 1:01 AM, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-30 08:19:18)
> >>
> >> On 30/07/2019 00:47, Daniele Ceraolo Spurio wrote:
> >>> We don't call the init_early function from within the gem code, so we
> >>> shouldn't do it for the cleanup either.
> >>>
> >>> Signed-off-by: Daniele Ceraolo Spurio 
> >>> Cc: Chris Wilson 
> >>> Cc: Tvrtko Ursulin 
> >>> ---
> >>>drivers/gpu/drm/i915/i915_drv.c | 2 ++
> >>>drivers/gpu/drm/i915/i915_gem.c | 2 --
> >>>2 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >>> b/drivers/gpu/drm/i915/i915_drv.c
> >>> index f2d3d754af37..934e605e2466 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>> @@ -951,6 +951,7 @@ static int i915_driver_early_probe(struct 
> >>> drm_i915_private *dev_priv)
> >>>intel_uc_cleanup_early(_priv->gt.uc);
> >>>i915_gem_cleanup_early(dev_priv);
> >>>err_workqueues:
> >>> + intel_gt_cleanup_early(_priv->gt);
> >>>i915_workqueues_cleanup(dev_priv);
> >>>return ret;
> >>>}
> >>> @@ -966,6 +967,7 @@ static void i915_driver_late_release(struct 
> >>> drm_i915_private *dev_priv)
> >>>intel_power_domains_cleanup(dev_priv);
> >>>intel_uc_cleanup_early(_priv->gt.uc);
> >>>i915_gem_cleanup_early(dev_priv);
> >>> + intel_gt_cleanup_early(_priv->gt);
> > 
> > Note the change in naming convention, intel_gt_driver_late_release().
> > -Chris
> > 
> 
> Does it make sense to flip only the gt function? it'd look terribly out 
> of place close to all those other cleanup_early() calls. I can follow up 
> with a patch to flip them all at the same time if that works for you.

Baby steps, the consistency is in the function callgraphs -- it looks
out of place to have late_release call cleanup_early :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: Pass intel_context to mock_request

2019-07-30 Thread Chris Wilson
Modernise the mock_request factory to take intel_context not a (GEM
context, intel_engine_cs) tuple.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_request.c | 38 +++
 drivers/gpu/drm/i915/selftests/mock_request.c |  6 +--
 drivers/gpu/drm/i915/selftests/mock_request.h |  4 +-
 3 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 86c299663934..2e0fd701bca7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -46,9 +46,7 @@ static int igt_add_request(void *arg)
/* Basic preliminary test to create a request and let it loose! */
 
mutex_lock(>drm.struct_mutex);
-   request = mock_request(i915->engine[RCS0],
-  i915->kernel_context,
-  HZ / 10);
+   request = mock_request(i915->engine[RCS0]->kernel_context, HZ / 10);
if (!request)
goto out_unlock;
 
@@ -70,7 +68,7 @@ static int igt_wait_request(void *arg)
/* Submit a request, then wait upon it */
 
mutex_lock(>drm.struct_mutex);
-   request = mock_request(i915->engine[RCS0], i915->kernel_context, T);
+   request = mock_request(i915->engine[RCS0]->kernel_context, T);
if (!request) {
err = -ENOMEM;
goto out_unlock;
@@ -143,7 +141,7 @@ static int igt_fence_wait(void *arg)
/* Submit a request, treat it as a fence and wait upon it */
 
mutex_lock(>drm.struct_mutex);
-   request = mock_request(i915->engine[RCS0], i915->kernel_context, T);
+   request = mock_request(i915->engine[RCS0]->kernel_context, T);
if (!request) {
err = -ENOMEM;
goto out_locked;
@@ -196,11 +194,15 @@ static int igt_request_rewind(void *arg)
struct drm_i915_private *i915 = arg;
struct i915_request *request, *vip;
struct i915_gem_context *ctx[2];
+   struct intel_context *ce;
int err = -EINVAL;
 
mutex_lock(>drm.struct_mutex);
ctx[0] = mock_context(i915, "A");
-   request = mock_request(i915->engine[RCS0], ctx[0], 2 * HZ);
+   ce = i915_gem_context_get_engine(ctx[0], RCS0);
+   GEM_BUG_ON(IS_ERR(ce));
+   request = mock_request(ce, 2 * HZ);
+   intel_context_put(ce);
if (!request) {
err = -ENOMEM;
goto err_context_0;
@@ -210,7 +212,10 @@ static int igt_request_rewind(void *arg)
i915_request_add(request);
 
ctx[1] = mock_context(i915, "B");
-   vip = mock_request(i915->engine[RCS0], ctx[1], 0);
+   ce = i915_gem_context_get_engine(ctx[1], RCS0);
+   GEM_BUG_ON(IS_ERR(ce));
+   vip = mock_request(ce, 0);
+   intel_context_put(ce);
if (!vip) {
err = -ENOMEM;
goto err_context_1;
@@ -259,22 +264,19 @@ struct smoketest {
struct i915_gem_context **contexts;
atomic_long_t num_waits, num_fences;
int ncontexts, max_batch;
-   struct i915_request *(*request_alloc)(struct i915_gem_context *,
- struct intel_engine_cs *);
+   struct i915_request *(*request_alloc)(struct intel_context *ce);
 };
 
 static struct i915_request *
-__mock_request_alloc(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
+__mock_request_alloc(struct intel_context *ce)
 {
-   return mock_request(engine, ctx, 0);
+   return mock_request(ce, 0);
 }
 
 static struct i915_request *
-__live_request_alloc(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
+__live_request_alloc(struct intel_context *ce)
 {
-   return igt_request_alloc(ctx, engine);
+   return intel_context_create_request(ce);
 }
 
 static int __igt_breadcrumbs_smoketest(void *arg)
@@ -333,10 +335,14 @@ static int __igt_breadcrumbs_smoketest(void *arg)
struct i915_gem_context *ctx =
t->contexts[order[n] % t->ncontexts];
struct i915_request *rq;
+   struct intel_context *ce;
 
mutex_lock(BKL);
 
-   rq = t->request_alloc(ctx, t->engine);
+   ce = i915_gem_context_get_engine(ctx, t->engine->id);
+   GEM_BUG_ON(IS_ERR(ce));
+   rq = t->request_alloc(ce);
+   intel_context_put(ce);
if (IS_ERR(rq)) {
mutex_unlock(BKL);
err = PTR_ERR(rq);
diff --git a/drivers/gpu/drm/i915/selftests/mock_request.c 
b/drivers/gpu/drm/i915/selftests/mock_request.c
index 9390fc09984b..09f747228dff 100644
--- a/drivers/gpu/drm/i915/selftests/mock_request.c
+++ b/drivers/gpu/drm/i915/selftests/mock_request.c
@@ -28,14 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Move aliasing_ppgtt underneath its i915_ggtt

2019-07-30 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Move aliasing_ppgtt underneath 
its i915_ggtt
URL   : https://patchwork.freedesktop.org/series/64438/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6581 -> Patchwork_13802


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-icl-u3/igt@gem_ctx_cre...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-icl-u3/igt@gem_ctx_cre...@basic.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   [PASS][3] -> [WARN][4] ([fdo#109380])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-dsi: [PASS][5] -> [DMESG-WARN][6] ([fdo#106107]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@gem_ctx_create@basic-files:
- {fi-icl-guc}:   [INCOMPLETE][9] ([fdo#107713] / [fdo#109100]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
- fi-cml-u:   [INCOMPLETE][11] ([fdo#110566]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-cml-u/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [INCOMPLETE][13] ([fdo#107718]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@module-reload:
- fi-icl-u3:  [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-icl-u3/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-icl-u3/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_reset:
- fi-icl-u2:  [INCOMPLETE][17] ([fdo#107713]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-icl-u2/igt@i915_selftest@live_reset.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-icl-u2/igt@i915_selftest@live_reset.html

  * igt@kms_chamelium@dp-edid-read:
- fi-cml-u2:  [FAIL][19] ([fdo#106766]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6581/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13802/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html

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

  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096


Participating hosts (55 -> 46)
--

  Missing(9): 

  1   2   3   >