[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add HBR and HBR2+ voltage swing table

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add HBR and HBR2+ voltage swing table
URL   : https://patchwork.freedesktop.org/series/77934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573_full -> Patchwork_17847_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-skl:  [PASS][1] -> [FAIL][2] ([i915#1528])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#1185] / 
[i915#189])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb4/igt@i915_pm_...@system-suspend-execbuf.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-iclb4/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl3/igt@i915_susp...@forcewake.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-kbl4/igt@i915_susp...@forcewake.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#54] / [i915#93] / 
[i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#70] / [i915#95])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl2/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl8/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#1525] / [i915#95])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl2/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#1188])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl4/igt@kms_...@bpc-switch.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl8/igt@kms_...@bpc-switch.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html

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

  
 Possible fixes 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
- shard-skl:  [FAIL][21] ([i915#1528]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html

  * {igt@i915_selftest@perf@request}:
- shard-tglb: [DMESG-FAIL][23] ([i915#1823]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-tglb5/igt@i915_selftest@p...@request.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/shard-tglb3/igt@i915_selftest@p...@request.html

  * igt@kms_big_fb@linear-64bpp-rotate-0:
- shard-glk:  

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Implement WA_16011163337

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Implement WA_16011163337
URL   : https://patchwork.freedesktop.org/series/77933/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8573_full -> Patchwork_17846_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17846_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17846_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_17846_full:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-hsw6/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][2] -> [DMESG-WARN][3] ([i915#1436] / 
[i915#716])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-glk1/igt@gen9_exec_pa...@allowed-all.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-glk5/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_pm_dc@dc5-dpms:
- shard-skl:  [PASS][4] -> [INCOMPLETE][5] ([i915#198])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl4/igt@i915_pm...@dc5-dpms.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-skl4/igt@i915_pm...@dc5-dpms.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#54] / [i915#93] / 
[i915#95])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw:  [PASS][8] -> [INCOMPLETE][9] ([i915#1926] / [i915#61])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html

  * igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-kbl:  [PASS][10] -> [DMESG-WARN][11] ([i915#128])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl2/igt@kms_cursor_leg...@pipe-c-torture-bo.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-kbl7/igt@kms_cursor_leg...@pipe-c-torture-bo.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][12] -> [FAIL][13] ([i915#1188])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl8/igt@kms_...@bpc-switch-suspend.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-skl9/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_psr@no_drrs:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#173])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb2/igt@kms_psr@no_drrs.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_dpms:
- shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109441]) +2 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb2/igt@kms_psr@psr2_dpms.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-iclb6/igt@kms_psr@psr2_dpms.html

  
 Possible fixes 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
- shard-skl:  [FAIL][20] ([i915#1528]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html

  * {igt@i915_selftest@perf@request}:
- shard-tglb: [DMESG-FAIL][22] -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-tglb5/igt@i915_selftest@p...@request.html
   

Re: [Intel-gfx] [PATCH] drm/i915: Drop i915_request.i915 backpointer

2020-06-02 Thread Abodunrin, Akeem G



> -Original Message-
> From: Intel-gfx  On Behalf Of Chris
> Wilson
> Sent: Tuesday, June 02, 2020 3:10 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: [Intel-gfx] [PATCH] drm/i915: Drop i915_request.i915 backpointer
> 
> We infrequently use the direct i915 backpointer from the i915_request, so do
> we really need to waste the space in the struct for it? 8 bytes from the most
> frequently allocated struct vs an 3 bytes and pointer chasing in using rq-
> >engine->i915?
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  |  4 ++--
>  drivers/gpu/drm/i915/gt/gen2_engine_cs.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_context_sseu.c|  2 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  6 ++
>  drivers/gpu/drm/i915/gt/intel_lrc.c |  6 +++---
>  drivers/gpu/drm/i915/gt/intel_ring_submission.c |  6 +++---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c |  4 ++--
>  drivers/gpu/drm/i915/gt/selftest_engine_cs.c|  2 +-
>  drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
>  drivers/gpu/drm/i915/gt/selftest_rc6.c  |  9 -
>  drivers/gpu/drm/i915/gt/selftest_timeline.c |  4 ++--
>  drivers/gpu/drm/i915/gvt/scheduler.c|  4 ++--
>  drivers/gpu/drm/i915/i915_request.c | 12 ++--
>  drivers/gpu/drm/i915/i915_request.h |  3 ---
>  drivers/gpu/drm/i915/i915_trace.h   | 10 +-
>  drivers/gpu/drm/i915/selftests/i915_perf.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/igt_spinner.c| 14 +++---
>  17 files changed, 43 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 219a36995b96..02a5c0ce39ca 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1910,8 +1910,8 @@ static int i915_reset_gen7_sol_offsets(struct
> i915_request *rq)
>   u32 *cs;
>   int i;
> 
> - if (!IS_GEN(rq->i915, 7) || rq->engine->id != RCS0) {
> - drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
> + if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
> + drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs
> only\n");
>   return -EINVAL;
>   }
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> index 8d2e85081247..3fb0dc1fb910 100644
> --- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> @@ -77,7 +77,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>   cmd = MI_FLUSH;
>   if (mode & EMIT_INVALIDATE) {
>   cmd |= MI_EXE_FLUSH;
> - if (IS_G4X(rq->i915) || IS_GEN(rq->i915, 5))
> + if (IS_G4X(rq->engine->i915) || IS_GEN(rq->engine->i915, 5))
>   cmd |= MI_INVALIDATE_ISP;
>   }
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
> b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
> index 487299cb91f2..27ae48049239 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
> @@ -30,7 +30,7 @@ static int gen8_emit_rpcs_config(struct i915_request
> *rq,
>   *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>   *cs++ = lower_32_bits(offset);
>   *cs++ = upper_32_bits(offset);
> - *cs++ = intel_sseu_make_rpcs(rq->i915, );
> + *cs++ = intel_sseu_make_rpcs(rq->engine->i915, );
> 
>   intel_ring_advance(rq, cs);
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index c8c14981eb5d..e37490d459c2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -661,7 +661,6 @@ static int measure_breadcrumb_dw(struct
> intel_context *ce)
>   if (!frame)
>   return -ENOMEM;
> 
> - frame->rq.i915 = engine->i915;
>   frame->rq.engine = engine;
>   frame->rq.context = ce;
>   rcu_assign_pointer(frame->rq.timeline, ce->timeline); @@ -1192,8
> +1191,7 @@ bool intel_engine_can_store_dword(struct intel_engine_cs
> *engine)
>   }
>  }
> 
> -static int print_sched_attr(struct drm_i915_private *i915,
> - const struct i915_sched_attr *attr,
> +static int print_sched_attr(const struct i915_sched_attr *attr,
>   char *buf, int x, int len)
>  {
>   if (attr->priority == I915_PRIORITY_INVALID) @@ -1213,7 +1211,7
> @@ static void print_request(struct drm_printer *m,
>   char buf[80] = "";
>   int x = 0;
> 
> - x = print_sched_attr(rq->i915, >sched.attr, buf, x, sizeof(buf));
> + x = print_sched_attr(>sched.attr, buf, x, sizeof(buf));
> 
>   drm_printf(m, "%s %llx:%llx%s%s %s @ %dms: %s\n",
>  prefix,
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77922/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573_full -> Patchwork_17845_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge:
- shard-apl:  [PASS][1] -> [FAIL][2] ([i915#70] / [i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl2/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-apl7/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][3] -> [FAIL][4] ([i915#1188])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl4/igt@kms_...@bpc-switch.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-skl10/igt@kms_...@bpc-switch.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#69]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-skl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_dpms:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-iclb2/igt@kms_psr@psr2_dpms.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-iclb8/igt@kms_psr@psr2_dpms.html

  
 Possible fixes 

  * {igt@i915_selftest@perf@request}:
- shard-tglb: [DMESG-FAIL][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-tglb5/igt@i915_selftest@p...@request.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-tglb1/igt@i915_selftest@p...@request.html

  * igt@kms_big_fb@linear-64bpp-rotate-0:
- shard-glk:  [FAIL][17] ([i915#1119] / [i915#118] / [i915#95]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-glk5/igt@kms_big...@linear-64bpp-rotate-0.html

  * {igt@kms_flip@2x-flip-vs-blocking-wf-vblank@bc-hdmi-a1-hdmi-a2}:
- shard-glk:  [FAIL][19] ([i915#1928]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-glk2/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@bc-hdmi-a1-hdmi-a2.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-glk4/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@bc-hdmi-a1-hdmi-a2.html

  * {igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1}:
- shard-skl:  [FAIL][21] ([i915#79]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@c-dp1}:
- shard-apl:  [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +8 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/shard-apl4/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
   [24]: 

Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: reset vblank on crtc reset

2020-06-02 Thread Laurent Pinchart
Hi Daniel,

Thank you for the patch.

May I remind you about the -v option to git-format-patch ? :-) Seriously
speaking, it really helps review.

On Tue, Jun 02, 2020 at 11:51:38AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
> 
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
> 
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
> 
> Big thanks to Tetsuo for helping track down what's going wrong here.
> 
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
>   __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
>   motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> 
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
> 
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
> 
> v2: Use the drm_dev_has_vblank() helper.
> 
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
> 
> Cc: Laurent Pinchart 
> Reviewed-by: Laurent Pinchart 
> Reviewed-by: Boris Brezillon 
> Acked-by: Liviu Dudau 
> Acked-by: Thierry Reding 
> Link: 
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa 
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa 
> Cc: "James (Qian) Wang" 
> Cc: Liviu Dudau 
> Cc: Mihail Atanassov 
> Cc: Brian Starkey 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Brian Masney 
> Cc: Emil Velikov 
> Cc: zhengbin 
> Cc: Thomas Gleixner 
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
>  drivers/gpu/drm/arm/malidp_drv.c | 1 -
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
>  drivers/gpu/drm/drm_atomic_state_helper.c| 4 
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 3 ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 3 ---
>  drivers/gpu/drm/tegra/dc.c   | 1 -
>  drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
>  drivers/gpu/drm/tidss/tidss_kms.c| 4 
>  10 files changed, 9 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
>   crtc->state = NULL;
>  
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
>  }
>  
>  static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>   return err;
>  
>   drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>  
>   crtc->port = kcrtc->master->of_output_port;
>  
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c2507b7d8512..02904392e370 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
>   

[Intel-gfx] linux-next: manual merge of the drm-intel-fixes tree with Linus' tree

2020-06-02 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel-fixes tree got a conflict in:

  drivers/gpu/drm/i915/gt/intel_lrc.c

between commit:

  f53ae29c0ea1 ("drm/i915/gt: Include a few tracek for timeslicing")

from Linus' tree and commit:

  00febf644648 ("drm/i915/gt: Incorporate the virtual engine into timeslicing")

from the drm-intel-fixes tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/gt/intel_lrc.c
index 87e6c5bdd2dc,e77f89b43e5f..
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@@ -1971,20 -1853,12 +1990,19 @@@ static void set_timeslice(struct intel_
if (!intel_engine_has_timeslices(engine))
return;
  
 -  set_timer_ms(>execlists.timer, active_timeslice(engine));
 +  duration = active_timeslice(engine);
 +  ENGINE_TRACE(engine, "bump timeslicing, interval:%lu", duration);
 +
 +  set_timer_ms(>execlists.timer, duration);
  }
  
- static void start_timeslice(struct intel_engine_cs *engine)
+ static void start_timeslice(struct intel_engine_cs *engine, int prio)
  {
struct intel_engine_execlists *execlists = >execlists;
-   const int prio = queue_prio(execlists);
 +  unsigned long duration;
 +
 +  if (!intel_engine_has_timeslices(engine))
 +  return;
  
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
@@@ -2140,13 -1994,8 +2158,13 @@@ static void execlists_dequeue(struct in
__unwind_incomplete_requests(engine);
  
last = NULL;
-   } else if (need_timeslice(engine, last) &&
+   } else if (need_timeslice(engine, last, rb) &&
   timeslice_expired(execlists, last)) {
 +  if (i915_request_completed(last)) {
 +  tasklet_hi_schedule(>tasklet);
 +  return;
 +  }
 +
ENGINE_TRACE(engine,
 "expired last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
 last->fence.context,


pgpwGlYBwDPwV.pgp
Description: OpenPGP digital signature
___
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/params: fix i915.reset module param type

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/params: fix i915.reset module param type
URL   : https://patchwork.freedesktop.org/series/77923/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8572_full -> Patchwork_17844_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17844_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17844_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_17844_full:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-hsw8/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +2 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#1119] / [i915#118] / 
[i915#95])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-glk1/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_hdr@bpc-switch-dpms:
- shard-skl:  [PASS][6] -> [FAIL][7] ([i915#1188])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-skl10/igt@kms_...@bpc-switch-dpms.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-skl5/igt@kms_...@bpc-switch-dpms.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl:  [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +3 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][10] -> [FAIL][11] ([fdo#108145] / [i915#265]) 
+2 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109441])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-iclb5/igt@kms_psr@psr2_cursor_plane_onoff.html

  
 Possible fixes 

  * {igt@gem_exec_reloc@basic-concurrent0}:
- shard-apl:  [FAIL][14] ([i915#1930]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-apl2/igt@gem_exec_re...@basic-concurrent0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-apl7/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [INCOMPLETE][16] -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-apl7/igt@gem_workarou...@suspend-resume-fd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-apl1/igt@gem_workarou...@suspend-resume-fd.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [DMESG-WARN][18] ([i915#1436] / [i915#716]) -> 
[PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-skl3/igt@gen9_exec_pa...@allowed-single.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-skl4/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-hsw:  [WARN][20] ([i915#1519]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-idle.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-idle.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk:  [FAIL][22] ([i915#1119] / [i915#118] / [i915#95]) -> 
[PASS][23]
   [22]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop i915_request.i915 backpointer

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Drop i915_request.i915 backpointer
URL   : https://patchwork.freedesktop.org/series/77936/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573 -> Patchwork_17848


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17848/index.html

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [SKIP][1] ([fdo#109271]) -> [FAIL][2] ([i915#62] / 
[i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8573/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17848/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (51 -> 44)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8573 -> Patchwork_17848

  CI-20190529: 20190529
  CI_DRM_8573: 7dd051b025ee88fc5e358bc7d3438e1764f68257 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17848: d2ad01d6c2e69f34b4b905ce168aae955b948d12 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d2ad01d6c2e6 drm/i915: Drop i915_request.i915 backpointer

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Drop i915_request.i915 backpointer

2020-06-02 Thread Chris Wilson
We infrequently use the direct i915 backpointer from the i915_request,
so do we really need to waste the space in the struct for it? 8 bytes
from the most frequently allocated struct vs an 3 bytes and pointer
chasing in using rq->engine->i915?

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  |  4 ++--
 drivers/gpu/drm/i915/gt/gen2_engine_cs.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_context_sseu.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  6 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c |  6 +++---
 drivers/gpu/drm/i915/gt/intel_ring_submission.c |  6 +++---
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  4 ++--
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_rc6.c  |  9 -
 drivers/gpu/drm/i915/gt/selftest_timeline.c |  4 ++--
 drivers/gpu/drm/i915/gvt/scheduler.c|  4 ++--
 drivers/gpu/drm/i915/i915_request.c | 12 ++--
 drivers/gpu/drm/i915/i915_request.h |  3 ---
 drivers/gpu/drm/i915/i915_trace.h   | 10 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c  |  2 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c| 14 +++---
 17 files changed, 43 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 219a36995b96..02a5c0ce39ca 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1910,8 +1910,8 @@ static int i915_reset_gen7_sol_offsets(struct 
i915_request *rq)
u32 *cs;
int i;
 
-   if (!IS_GEN(rq->i915, 7) || rq->engine->id != RCS0) {
-   drm_dbg(>i915->drm, "sol reset is gen7/rcs only\n");
+   if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
+   drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 8d2e85081247..3fb0dc1fb910 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -77,7 +77,7 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
cmd = MI_FLUSH;
if (mode & EMIT_INVALIDATE) {
cmd |= MI_EXE_FLUSH;
-   if (IS_G4X(rq->i915) || IS_GEN(rq->i915, 5))
+   if (IS_G4X(rq->engine->i915) || IS_GEN(rq->engine->i915, 5))
cmd |= MI_INVALIDATE_ISP;
}
 
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 487299cb91f2..27ae48049239 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -30,7 +30,7 @@ static int gen8_emit_rpcs_config(struct i915_request *rq,
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
-   *cs++ = intel_sseu_make_rpcs(rq->i915, );
+   *cs++ = intel_sseu_make_rpcs(rq->engine->i915, );
 
intel_ring_advance(rq, cs);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c8c14981eb5d..e37490d459c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -661,7 +661,6 @@ static int measure_breadcrumb_dw(struct intel_context *ce)
if (!frame)
return -ENOMEM;
 
-   frame->rq.i915 = engine->i915;
frame->rq.engine = engine;
frame->rq.context = ce;
rcu_assign_pointer(frame->rq.timeline, ce->timeline);
@@ -1192,8 +1191,7 @@ bool intel_engine_can_store_dword(struct intel_engine_cs 
*engine)
}
 }
 
-static int print_sched_attr(struct drm_i915_private *i915,
-   const struct i915_sched_attr *attr,
+static int print_sched_attr(const struct i915_sched_attr *attr,
char *buf, int x, int len)
 {
if (attr->priority == I915_PRIORITY_INVALID)
@@ -1213,7 +1211,7 @@ static void print_request(struct drm_printer *m,
char buf[80] = "";
int x = 0;
 
-   x = print_sched_attr(rq->i915, >sched.attr, buf, x, sizeof(buf));
+   x = print_sched_attr(>sched.attr, buf, x, sizeof(buf));
 
drm_printf(m, "%s %llx:%llx%s%s %s @ %dms: %s\n",
   prefix,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 6fc0966b75ff..aac8da18694f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3533,7 +3533,7 @@ static int emit_pdps(struct i915_request *rq)
int err, i;
u32 *cs;
 
-   GEM_BUG_ON(intel_vgpu_active(rq->i915));
+   GEM_BUG_ON(intel_vgpu_active(rq->engine->i915));
 
/*
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add HBR and HBR2+ voltage swing table

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add HBR and HBR2+ voltage swing table
URL   : https://patchwork.freedesktop.org/series/77934/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573 -> Patchwork_17847


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17847/index.html


Changes
---

  No changes found


Participating hosts (51 -> 45)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8573 -> Patchwork_17847

  CI-20190529: 20190529
  CI_DRM_8573: 7dd051b025ee88fc5e358bc7d3438e1764f68257 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17847: 6c49c456cc63e42fd77667b19ef3e88780a047dc @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6c49c456cc63 drm/i915/tgl: Add HBR and HBR2+ voltage swing table

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/tgl: Add HBR and HBR2+ voltage swing table

2020-06-02 Thread José Roberto de Souza
As latest update we have now 2 voltage swing tables for DP over DKL
PHY with only one difference in Level 0 pre-emphasis 3.
So with 2 tables for DP is time to have one single function to return
all DKL voltage swing tables.

BSpec: 49292
Cc: Khaled Almahallawy 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 50 
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cd211f48c401..763d76056ca9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -641,6 +641,20 @@ static const struct tgl_dkl_phy_ddi_buf_trans 
tgl_dkl_phy_dp_ddi_trans[] = {
{ 0x7, 0x0, 0x00 }, /* 00   400mV   0 dB */
{ 0x5, 0x0, 0x05 }, /* 01   400mV   3.5 dB */
{ 0x2, 0x0, 0x0B }, /* 02   400mV   6 dB */
+   { 0x0, 0x0, 0x18 }, /* 03   400mV   9.5 dB */
+   { 0x5, 0x0, 0x00 }, /* 10   600mV   0 dB */
+   { 0x2, 0x0, 0x08 }, /* 11   600mV   3.5 dB */
+   { 0x0, 0x0, 0x14 }, /* 12   600mV   6 dB */
+   { 0x2, 0x0, 0x00 }, /* 20   800mV   0 dB */
+   { 0x0, 0x0, 0x0B }, /* 21   800mV   3.5 dB */
+   { 0x0, 0x0, 0x00 }, /* 30   1200mV  0 dB HDMI 
default */
+};
+
+static const struct tgl_dkl_phy_ddi_buf_trans tgl_dkl_phy_dp_ddi_trans_hbr2[] 
= {
+   /* VS   pre-emp Non-trans mVPre-emph dB */
+   { 0x7, 0x0, 0x00 }, /* 00   400mV   0 dB */
+   { 0x5, 0x0, 0x05 }, /* 01   400mV   3.5 dB */
+   { 0x2, 0x0, 0x0B }, /* 02   400mV   6 dB */
{ 0x0, 0x0, 0x19 }, /* 03   400mV   9.5 dB */
{ 0x5, 0x0, 0x00 }, /* 10   600mV   0 dB */
{ 0x2, 0x0, 0x08 }, /* 11   600mV   3.5 dB */
@@ -1014,6 +1028,22 @@ tgl_get_combo_buf_trans(struct drm_i915_private 
*dev_priv, int type, int rate,
return tgl_combo_phy_ddi_translations_dp_hbr;
 }
 
+static const struct tgl_dkl_phy_ddi_buf_trans *
+tgl_get_dkl_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+ int *n_entries)
+{
+   if (type == INTEL_OUTPUT_HDMI) {
+   *n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
+   return tgl_dkl_phy_hdmi_ddi_trans;
+   } else if (rate > 27) {
+   *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans_hbr2);
+   return tgl_dkl_phy_dp_ddi_trans_hbr2;
+   }
+
+   *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
+   return tgl_dkl_phy_dp_ddi_trans;
+}
+
 static int intel_ddi_hdmi_level(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -1025,7 +1055,8 @@ static int intel_ddi_hdmi_level(struct intel_encoder 
*encoder)
tgl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
0, _entries);
else
-   n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
+   tgl_get_dkl_buf_trans(dev_priv, INTEL_OUTPUT_HDMI, 0,
+ _entries);
default_entry = n_entries - 1;
} else if (INTEL_GEN(dev_priv) == 11) {
if (intel_phy_is_combo(dev_priv, phy))
@@ -2108,7 +2139,8 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder)
tgl_get_combo_buf_trans(dev_priv, encoder->type,
intel_dp->link_rate, 
_entries);
else
-   n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
+   tgl_get_dkl_buf_trans(dev_priv, encoder->type,
+ intel_dp->link_rate, _entries);
} else if (INTEL_GEN(dev_priv) == 11) {
if (IS_ELKHARTLAKE(dev_priv))
ehl_get_combo_buf_trans(dev_priv, encoder->type,
@@ -2585,15 +2617,17 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder 
*encoder, int link_clock,
enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder->port);
const struct tgl_dkl_phy_ddi_buf_trans *ddi_translations;
u32 n_entries, val, ln, dpcnt_mask, dpcnt_val;
+   int rate = 0;
 
-   if (encoder->type == INTEL_OUTPUT_HDMI) {
-   n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
-   ddi_translations = tgl_dkl_phy_hdmi_ddi_trans;
-   } else {
-   n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
-   ddi_translations = tgl_dkl_phy_dp_ddi_trans;
+   if (encoder->type != INTEL_OUTPUT_HDMI) {
+   struct intel_dp 

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Implement WA_16011163337

2020-06-02 Thread Chris Wilson
Quoting clinton.a.tay...@intel.com (2020-06-02 20:25:01)
> From: Clint Taylor 
> 
> Set GS Timer to 224. Combine with Wa_1604555607 due to register FF_MODE2
> not being able to be read.
> 
> Cc: Caz Yokoyama 
> Cc: Matt Atwood 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 
>  drivers/gpu/drm/i915/i915_reg.h | 2 ++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index fa1e15657663..7bc6474cce0e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -594,11 +594,11 @@ static void tgl_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>  * Wa_1604555607:gen12 and Wa_1608008084:gen12
>  * FF_MODE2 register will return the wrong value when read. The 
> default
>  * value for this register is zero for all fields and there are no bit
> -* masks. So instead of doing a RMW we should just write the TDS timer
> -* value for Wa_1604555607.
> +* masks. So instead of doing a RMW we should just write the GS Timer
> +* and TDS timer values for Wa_1604555607 and Wa_16011163337.
>  */
> -   wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK,
> -  FF_MODE2_TDS_TIMER_128, 0);
> +   wa_add(wal, FF_MODE2, FF_MODE2_GS_TIMER_MASK & 
> FF_MODE2_TDS_TIMER_MASK,

GS_TIMER_MASK & TDS_TIMER_MASK is 0

I think you meant |
-Chris
___
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/tgl: Implement WA_16011163337

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Implement WA_16011163337
URL   : https://patchwork.freedesktop.org/series/77933/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573 -> Patchwork_17846


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17846/index.html


Changes
---

  No changes found


Participating hosts (51 -> 44)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8573 -> Patchwork_17846

  CI-20190529: 20190529
  CI_DRM_8573: 7dd051b025ee88fc5e358bc7d3438e1764f68257 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17846: fd295d4b23d0b98f18f5be0f265d525bb3f9ebce @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fd295d4b23d0 drm/i915/tgl: Implement WA_16011163337

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Souza, Jose
On Tue, 2020-06-02 at 16:48 +0100, Chris Wilson wrote:
> For reasons that be, the HW only allows usersace to read its own
> CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for
> all by adding it to the whitelists.
> 
> v2: The change took effect from Cometlake.
> v3: Ignore timestamps that autoincrement when validating the whitelist

I would have separated add the register to the whitelist from the selftest but 
anyways looks good.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 25 ++-
>  .../gpu/drm/i915/gt/selftest_workarounds.c| 17 +
>  2 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 6e1accbcc045..0731bbcef06c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1206,6 +1206,18 @@ static void cfl_whitelist_build(struct intel_engine_cs 
> *engine)
> RING_FORCE_TO_NONPRIV_RANGE_4);
>  }
>  
> +static void cml_whitelist_build(struct intel_engine_cs *engine)
> +{
> + struct i915_wa_list *w = >whitelist;
> +
> + if (engine->class != RENDER_CLASS)
> + whitelist_reg_ext(w,
> +   RING_CTX_TIMESTAMP(engine->mmio_base),
> +   RING_FORCE_TO_NONPRIV_ACCESS_RD);
> +
> + cfl_whitelist_build(engine);
> +}
> +
>  static void cnl_whitelist_build(struct intel_engine_cs *engine)
>  {
>   struct i915_wa_list *w = >whitelist;
> @@ -1256,9 +1268,15 @@ static void icl_whitelist_build(struct intel_engine_cs 
> *engine)
>   /* hucStatus2RegOffset */
>   whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
> RING_FORCE_TO_NONPRIV_ACCESS_RD);
> + whitelist_reg_ext(w,
> +   RING_CTX_TIMESTAMP(engine->mmio_base),
> +   RING_FORCE_TO_NONPRIV_ACCESS_RD);
>   break;
>  
>   default:
> + whitelist_reg_ext(w,
> +   RING_CTX_TIMESTAMP(engine->mmio_base),
> +   RING_FORCE_TO_NONPRIV_ACCESS_RD);
>   break;
>   }
>  }
> @@ -1290,6 +1308,9 @@ static void tgl_whitelist_build(struct intel_engine_cs 
> *engine)
>   whitelist_reg(w, HIZ_CHICKEN);
>   break;
>   default:
> + whitelist_reg_ext(w,
> +   RING_CTX_TIMESTAMP(engine->mmio_base),
> +   RING_FORCE_TO_NONPRIV_ACCESS_RD);
>   break;
>   }
>  }
> @@ -1307,7 +1328,9 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
> *engine)
>   icl_whitelist_build(engine);
>   else if (IS_CANNONLAKE(i915))
>   cnl_whitelist_build(engine);
> - else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
> + else if (IS_COMETLAKE(i915))
> + cml_whitelist_build(engine);
> + else if (IS_COFFEELAKE(i915))
>   cfl_whitelist_build(engine);
>   else if (IS_GEMINILAKE(i915))
>   glk_whitelist_build(engine);
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c 
> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index 32785463ec9e..febc9e6692ba 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -417,6 +417,20 @@ static bool wo_register(struct intel_engine_cs *engine, 
> u32 reg)
>   return false;
>  }
>  
> +static bool timestamp(const struct intel_engine_cs *engine, u32 reg)
> +{
> + reg = (reg - engine->mmio_base) & ~RING_FORCE_TO_NONPRIV_ACCESS_MASK;
> + switch (reg) {
> + case 0x358:
> + case 0x35c:
> + case 0x3a8:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
>  static bool ro_register(u32 reg)
>  {
>   if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
> @@ -497,6 +511,9 @@ static int check_dirty_whitelist(struct intel_context *ce)
>   if (wo_register(engine, reg))
>   continue;
>  
> + if (timestamp(engine, reg))
> + continue; /* timestamps are expected to autoincrement */
> +
>   ro_reg = ro_register(reg);
>  
>   /* Clear non priv flags */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Souza, Jose
On Tue, 2020-06-02 at 15:05 +0100, Chris Wilson wrote:
> Cometlake is small refresh of Coffeelake, but since we have found out a
> difference in the plaforms, we need to identify the separate platforms.
> 
> Since we previously took Coffeelake/Cometlake as identical, update all
> IS_COFFEELAKE() to also include IS_COMETLAKE().

No IS_COFFEELAKE() check left without a IS_COMETLAKE().

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/display/intel_csr.c|  4 ++-
>  drivers/gpu/drm/i915/display/intel_ddi.c| 34 +--
>  drivers/gpu/drm/i915/display/intel_hdcp.c   |  7 ++--
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +++
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  2 +-
>  drivers/gpu/drm/i915/gvt/display.c  | 30 +++--
>  drivers/gpu/drm/i915/gvt/edid.c |  2 +-
>  drivers/gpu/drm/i915/gvt/handlers.c | 17 ++
>  drivers/gpu/drm/i915/i915_drv.h |  9 ++
>  drivers/gpu/drm/i915/i915_pci.c | 22 ++---
>  drivers/gpu/drm/i915/intel_device_info.c|  1 +
>  drivers/gpu/drm/i915/intel_device_info.h|  1 +
>  drivers/gpu/drm/i915/intel_gvt.c|  2 ++
>  drivers/gpu/drm/i915/intel_pch.c| 36 ++---
>  drivers/gpu/drm/i915/intel_pm.c | 10 --
>  15 files changed, 140 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
> b/drivers/gpu/drm/i915/display/intel_csr.c
> index 319932b03e88..9843c9af6c13 100644
> --- a/drivers/gpu/drm/i915/display/intel_csr.c
> +++ b/drivers/gpu/drm/i915/display/intel_csr.c
> @@ -707,7 +707,9 @@ void intel_csr_ucode_init(struct drm_i915_private 
> *dev_priv)
>   csr->fw_path = GLK_CSR_PATH;
>   csr->required_version = GLK_CSR_VERSION_REQUIRED;
>   csr->max_fw_size = GLK_CSR_MAX_FW_SIZE;
> - } else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
> + } else if (IS_KABYLAKE(dev_priv) ||
> +IS_COFFEELAKE(dev_priv) ||
> +IS_COMETLAKE(dev_priv)) {
>   csr->fw_path = KBL_CSR_PATH;
>   csr->required_version = KBL_CSR_VERSION_REQUIRED;
>   csr->max_fw_size = KBL_CSR_MAX_FW_SIZE;
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index cd211f48c401..bb8107ab5a51 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -722,10 +722,14 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>  static const struct ddi_buf_trans *
>  kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> - if (IS_KBL_ULX(dev_priv) || IS_CFL_ULX(dev_priv)) {
> + if (IS_KBL_ULX(dev_priv) ||
> + IS_CFL_ULX(dev_priv) ||
> + IS_CML_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
>   return kbl_y_ddi_translations_dp;
> - } else if (IS_KBL_ULT(dev_priv) || IS_CFL_ULT(dev_priv)) {
> + } else if (IS_KBL_ULT(dev_priv) ||
> +IS_CFL_ULT(dev_priv) ||
> +IS_CML_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
>   return kbl_u_ddi_translations_dp;
>   } else {
> @@ -738,12 +742,16 @@ static const struct ddi_buf_trans *
>  skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
>   if (dev_priv->vbt.edp.low_vswing) {
> - if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv) ||
> - IS_CFL_ULX(dev_priv)) {
> + if (IS_SKL_ULX(dev_priv) ||
> + IS_KBL_ULX(dev_priv) ||
> + IS_CFL_ULX(dev_priv) ||
> + IS_CML_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_y_ddi_translations_edp);
>   return skl_y_ddi_translations_edp;
> - } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv) ||
> -IS_CFL_ULT(dev_priv)) {
> + } else if (IS_SKL_ULT(dev_priv) ||
> +IS_KBL_ULT(dev_priv) ||
> +IS_CFL_ULT(dev_priv) ||
> +IS_CML_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_u_ddi_translations_edp);
>   return skl_u_ddi_translations_edp;
>   } else {
> @@ -752,7 +760,9 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>   }
>   }
>  
> - if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
> + if (IS_KABYLAKE(dev_priv) ||
> + IS_COFFEELAKE(dev_priv) ||
> + IS_COMETLAKE(dev_priv))
>   return kbl_get_buf_trans_dp(dev_priv, n_entries);
>   else
>   return skl_get_buf_trans_dp(dev_priv, n_entries);
> @@ -761,8 +771,10 @@ skl_get_buf_trans_edp(struct drm_i915_private 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/atomic-helper: reset vblank on crtc reset (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/atomic-helper: reset vblank on crtc 
reset (rev2)
URL   : https://patchwork.freedesktop.org/series/77908/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8571_full -> Patchwork_17839_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17839_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17839_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_17839_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_persistence@replace-hostile@rcs0:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-skl10/igt@gem_ctx_persistence@replace-host...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-skl2/igt@gem_ctx_persistence@replace-host...@rcs0.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-tglb8/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-tglb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_workarounds@suspend-resume-fd:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#69])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-skl4/igt@gem_workarou...@suspend-resume-fd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-skl9/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_pm_rpm@gem-evict-pwrite:
- shard-tglb: [PASS][9] -> [SKIP][10] ([i915#579])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-tglb8/igt@i915_pm_...@gem-evict-pwrite.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-tglb5/igt@i915_pm_...@gem-evict-pwrite.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#1119] / [i915#118] / 
[i915#95]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-glk7/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#54] / [i915#93] / 
[i915#95])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw:  [PASS][15] -> [FAIL][16] ([i915#57])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_cursor_legacy@cursora-vs-flipb-toggle:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#1926])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-glk7/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-glk2/igt@kms_cursor_leg...@cursora-vs-flipb-toggle.html

  * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk:  [PASS][19] -> [DMESG-FAIL][20] ([i915#1925] / 
[i915#1926])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-glk8/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/shard-glk6/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109349])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
   [22]: 

[Intel-gfx] [PATCH] drm/i915/tgl: Implement WA_16011163337

2020-06-02 Thread clinton . a . taylor
From: Clint Taylor 

Set GS Timer to 224. Combine with Wa_1604555607 due to register FF_MODE2
not being able to be read.

Cc: Caz Yokoyama 
Cc: Matt Atwood 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index fa1e15657663..7bc6474cce0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -594,11 +594,11 @@ static void tgl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
 * Wa_1604555607:gen12 and Wa_1608008084:gen12
 * FF_MODE2 register will return the wrong value when read. The default
 * value for this register is zero for all fields and there are no bit
-* masks. So instead of doing a RMW we should just write the TDS timer
-* value for Wa_1604555607.
+* masks. So instead of doing a RMW we should just write the GS Timer
+* and TDS timer values for Wa_1604555607 and Wa_16011163337.
 */
-   wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK,
-  FF_MODE2_TDS_TIMER_128, 0);
+   wa_add(wal, FF_MODE2, FF_MODE2_GS_TIMER_MASK & FF_MODE2_TDS_TIMER_MASK,
+  FF_MODE2_GS_TIMER_224 & FF_MODE2_TDS_TIMER_128, 0);
 
/* WaDisableGPGPUMidThreadPreemption:tgl */
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 578cfe11cbb9..96d351fbeebb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8004,6 +8004,8 @@ enum {
 #define   PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
 
 #define FF_MODE2   _MMIO(0x6604)
+#define   FF_MODE2_GS_TIMER_MASK   REG_GENMASK(31, 24)
+#define   FF_MODE2_GS_TIMER_224
REG_FIELD_PREP(FF_MODE2_GS_TIMER_MASK, 224)
 #define   FF_MODE2_TDS_TIMER_MASK  REG_GENMASK(23, 16)
 #define   FF_MODE2_TDS_TIMER_128   REG_FIELD_PREP(FF_MODE2_TDS_TIMER_MASK, 
4)
 
-- 
2.26.0

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


Re: [Intel-gfx] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 0x00000080

2020-06-02 Thread Peter Zijlstra
On Tue, Jun 02, 2020 at 06:08:03PM +, Souza, Jose wrote:
> Hi Peter
> Please file a bug by follow this instructions: 
> https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

*sigh*, top posting and webforms :-(

Steps to reproduce: Boot into X

How often: Always

uname -r: 5.6.0-2-amd64

Machine: Supermicro X11SSZ-F

Display connector:

[14.907] (II) intel(0): switch to mode 3840x2160@60.0 on DP2 using pipe 0, 
position (0, 0), rotation normal, reflection none
[14.918] (II) intel(0): switch to mode 3840x2160@60.0 on DP3 using pipe 1, 
position (0, 0), rotation normal, reflection none


I'll add the kernel parameters next time I reboot this thing, I'll also
add the latest drm next time I build a kernel for this machine.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 0x00000080

2020-06-02 Thread Souza, Jose
Hi Peter
Please file a bug by follow this instructions: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

On Tue, 2020-06-02 at 19:46 +0200, Peter Zijlstra wrote:
> Hi All,
> 
> My desktop (Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz) is spewing tons
> and tons of:
> 
> [  778.461227] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe 
> B: 0x0080
> [  778.477763] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe 
> B: 0x0080
> [  778.577718] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe 
> B: 0x0080
> [  778.577824] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe 
> B: 0x0080
> 
> at a rate of ~3 per second, and X isn't as stable as one would like (it
> crashes every few days, sometimes taking the whole kernel along). Sadly,
> this being my desktop, I don't actually have a serial line connected to
> it, although I could hook one up if required.
> 
> It is currently running 5.6.14-1 (as per debian testing), but it seems
> to have done this for a while, I only now got around to reporting it :/
> 
> What else I you need to know, want me to try etc.. ?
> 
> ~ Peter
> 
> 
> ___
> 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] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 0x00000080

2020-06-02 Thread Peter Zijlstra
Hi All,

My desktop (Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz) is spewing tons
and tons of:

[  778.461227] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 
0x0080
[  778.477763] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 
0x0080
[  778.577718] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 
0x0080
[  778.577824] [drm:gen8_de_irq_handler [i915]] *ERROR* Fault errors on pipe B: 
0x0080

at a rate of ~3 per second, and X isn't as stable as one would like (it
crashes every few days, sometimes taking the whole kernel along). Sadly,
this being my desktop, I don't actually have a serial line connected to
it, although I could hook one up if required.

It is currently running 5.6.14-1 (as per debian testing), but it seems
to have done this for a while, I only now got around to reporting it :/

What else I you need to know, want me to try etc.. ?

~ Peter


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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77922/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8573 -> Patchwork_17845


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17845/index.html


Changes
---

  No changes found


Participating hosts (51 -> 45)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8573 -> Patchwork_17845

  CI-20190529: 20190529
  CI_DRM_8573: 7dd051b025ee88fc5e358bc7d3438e1764f68257 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17845: 444c42325fd7dc34d47e11e6a4d63d10e0cabc29 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

444c42325fd7 drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs
a71c14019fde drm/i915: Identify Cometlake platform

== Logs ==

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


Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest

2020-06-02 Thread Nirmoy

Hi Christian,

On 6/2/20 2:47 PM, Christian König wrote:
Nirmoy please keep in mind that your current implementation doesn't 
fully solve the issue the test case is exercising.


In other words what you have implement is fast skipping of fragmented 
address space for bottom-up and top-down.


But what this test here exercises is the fast skipping of aligned 
allocations. You should probably adjust the test case a bit.



Allocations with size=4k and aign = 8k is known to introduce 
fragmentation, do you mean I should only test bottom-up and top-down


for now ?


Regards,

Nirmoy





Regards,
Christian.

Am 29.05.20 um 23:01 schrieb Nirmoy:


On 5/29/20 5:52 PM, Chris Wilson wrote:

Quoting Nirmoy (2020-05-29 16:40:53)

This works correctly most of the times but sometimes



I have to take my word back. In another machine,  20k insertions in

best mode takes 6-9 times more than 10k insertions, all most all the 
time.


evict, bottom-up and top-down modes remains in 2-5 times range.


If I reduce the insertions to 1k and 2k then scaling factor for best 
mode stays  below 4 most of the time.


evict, bottom-up and top-down modes remains in 2-3 times range.


I wonder if it makes sense to test with only 1k and 2k insertions and 
tolerate more than error if the mode == best.


Regards,

Nirmoy



20k insertions can take more than 8 times of 10k insertion time.

The pressure is on to improve then :)


Regards,

Nirmoy

On 5/29/20 6:33 PM, Nirmoy Das wrote:

This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.

Output:

[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), 
with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128

[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 
512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 
1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 
1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 
1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 
512: free

[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 
insertions took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 
2 insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 
2 insertions took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 
insertions took 8 and 20 msecs



Signed-off-by: Nirmoy Das 
---
   drivers/gpu/drm/selftests/drm_mm_selftests.h |  1 +
   drivers/gpu/drm/selftests/test-drm_mm.c  | 73 


   2 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h 
b/drivers/gpu/drm/selftests/drm_mm_selftests.h

index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
   selftest(replace, igt_replace)
   selftest(insert_range, igt_insert_range)
   selftest(align, igt_align)
+selftest(frag, igt_frag)
   selftest(align32, igt_align32)
   selftest(align64, igt_align64)
   selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c

index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
   return 0;
   }
   +static int get_insert_time(unsigned int num_insert,
+    const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
+ if (!nodes)
+ goto err;
+
+ start = jiffies;

Use ktime_t start = ktime_now();


+ for (i = 0; i < num_insert; i++) {
+ if (!expect_insert(, [i], size, align, i, 
mode)) {

+ pr_err("%s insert failed\n", mode->name);
+ goto out;
+ }
+ }
+
+ ret = jiffies_to_msecs(jiffies - start);

ret = ktime_sub(ktime_now(), start);

The downside to using ktime is remembering it is s64 and so requires 
care

and attention in doing math.


+out:
+ drm_mm_for_each_node_safe(node, next, )
+ drm_mm_remove_node(node);
+ drm_mm_takedown();
+ vfree(nodes);
+err:
+ return ret;
+
+}
+
+static int igt_frag(void 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77922/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77922/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a71c14019fde drm/i915: Identify Cometlake platform
-:367: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#367: FILE: drivers/gpu/drm/i915/i915_drv.h:1471:
+#define IS_CML_GT2(dev_priv)   (IS_COMETLAKE(dev_priv) && \
+INTEL_INFO(dev_priv)->gt == 2)

-:381: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#381: FILE: drivers/gpu/drm/i915/i915_pci.c:769:
+#define CML_PLATFORM \
+   GEN9_FEATURES, \
+   PLATFORM(INTEL_COMETLAKE)

total: 1 errors, 0 warnings, 1 checks, 448 lines checked
444c42325fd7 drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

___
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/params: fix i915.reset module param type

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/params: fix i915.reset module param type
URL   : https://patchwork.freedesktop.org/series/77923/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8572 -> Patchwork_17844


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/index.html

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17844/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (51 -> 44)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8572 -> Patchwork_17844

  CI-20190529: 20190529
  CI_DRM_8572: 8a7011d0518058c59f13f10af147d1f97b0a1cd0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17844: b693251369b3179f16a1789d74a0d7395ef3a7a8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b693251369b3 drm/i915/params: fix i915.reset module param type

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Chris Wilson
For reasons that be, the HW only allows usersace to read its own
CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for
all by adding it to the whitelists.

v2: The change took effect from Cometlake.
v3: Ignore timestamps that autoincrement when validating the whitelist

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 25 ++-
 .../gpu/drm/i915/gt/selftest_workarounds.c| 17 +
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6e1accbcc045..0731bbcef06c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1206,6 +1206,18 @@ static void cfl_whitelist_build(struct intel_engine_cs 
*engine)
  RING_FORCE_TO_NONPRIV_RANGE_4);
 }
 
+static void cml_whitelist_build(struct intel_engine_cs *engine)
+{
+   struct i915_wa_list *w = >whitelist;
+
+   if (engine->class != RENDER_CLASS)
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+   cfl_whitelist_build(engine);
+}
+
 static void cnl_whitelist_build(struct intel_engine_cs *engine)
 {
struct i915_wa_list *w = >whitelist;
@@ -1256,9 +1268,15 @@ static void icl_whitelist_build(struct intel_engine_cs 
*engine)
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
  RING_FORCE_TO_NONPRIV_ACCESS_RD);
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
 
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1290,6 +1308,9 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
whitelist_reg(w, HIZ_CHICKEN);
break;
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1307,7 +1328,9 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
icl_whitelist_build(engine);
else if (IS_CANNONLAKE(i915))
cnl_whitelist_build(engine);
-   else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
+   else if (IS_COMETLAKE(i915))
+   cml_whitelist_build(engine);
+   else if (IS_COFFEELAKE(i915))
cfl_whitelist_build(engine);
else if (IS_GEMINILAKE(i915))
glk_whitelist_build(engine);
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c 
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 32785463ec9e..febc9e6692ba 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -417,6 +417,20 @@ static bool wo_register(struct intel_engine_cs *engine, 
u32 reg)
return false;
 }
 
+static bool timestamp(const struct intel_engine_cs *engine, u32 reg)
+{
+   reg = (reg - engine->mmio_base) & ~RING_FORCE_TO_NONPRIV_ACCESS_MASK;
+   switch (reg) {
+   case 0x358:
+   case 0x35c:
+   case 0x3a8:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
 static bool ro_register(u32 reg)
 {
if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
@@ -497,6 +511,9 @@ static int check_dirty_whitelist(struct intel_context *ce)
if (wo_register(engine, reg))
continue;
 
+   if (timestamp(engine, reg))
+   continue; /* timestamps are expected to autoincrement */
+
ro_reg = ro_register(reg);
 
/* Clear non priv flags */
-- 
2.20.1

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


Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Dont forget to clean up the connector on error (rev3)

2020-06-02 Thread Souza, Jose
On Tue, 2020-06-02 at 11:22 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dsi: Dont forget to clean up the connector on error (rev3)
> URL   : https://patchwork.freedesktop.org/series/77011/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_8568_full -> Patchwork_17838_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_17838_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_17838_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_17838_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_reloc@basic-cpu-read:
> - shard-skl:  [PASS][1] -> [TIMEOUT][2] +2 similar issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl5/igt@gem_exec_re...@basic-cpu-read.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl9/igt@gem_exec_re...@basic-cpu-read.html
> 
>   * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
> - shard-iclb: [PASS][3] -> [FAIL][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-iclb6/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-iclb1/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html
> 
> 

Not related to this changes.
Pushed to dinq, thanks for the patch.

>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_17838_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
> - shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 
> similar issues
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
> - shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#648] / 
> [i915#69])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
> 
>   * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
> - shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) 
> +1 similar issue
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
> 
>   * igt@kms_psr@psr2_cursor_render:
> - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +1 similar 
> issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-iclb5/igt@kms_psr@psr2_cursor_render.html
> 
>   * igt@kms_vblank@pipe-c-wait-idle-hang:
> - shard-apl:  [PASS][13] -> [TIMEOUT][14] ([i915#1635]) +2 
> similar issues
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@kms_vbl...@pipe-c-wait-idle-hang.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl6/igt@kms_vbl...@pipe-c-wait-idle-hang.html
> 
>   
>  Possible fixes 
> 
>   * {igt@gem_exec_schedule@implicit-write-read@rcs0}:
> - shard-snb:  [INCOMPLETE][15] ([i915#82]) -> [PASS][16]
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-snb6/igt@gem_exec_schedule@implicit-write-r...@rcs0.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-snb5/igt@gem_exec_schedule@implicit-write-r...@rcs0.html
> 
>   * igt@gem_workarounds@suspend-resume-fd:
> - shard-apl:  [INCOMPLETE][17] -> [PASS][18]
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html
> 
>   * {igt@kms_flip@flip-vs-suspend@a-dp1}:
> - shard-apl:  [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +3 
> similar issues
>[19]: 
> 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/params: fix i915.reset module param type

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/params: fix i915.reset module param type
URL   : https://patchwork.freedesktop.org/series/77923/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b693251369b3 drm/i915/params: fix i915.reset module param type
-:25: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#25: FILE: drivers/gpu/drm/i915/i915_params.c:78:
+i915_param_named_unsafe(reset, uint, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");

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

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


Re: [Intel-gfx] [PATCH] drm/i915/dsi: Dont forget to clean up the connector on error (v2)

2020-06-02 Thread Souza, Jose
On Fri, 2020-05-22 at 13:26 -0700, Vivek Kasireddy wrote:
> If an error is encountered during the DSI initialization setup, the
> drm connector object also needs to be cleaned up along with the encoder.
> The error can happen due to a missing mode in the VBT or for other
> reasons.
> 
> v2: Rephrase the commit message to make it more clear.
> 

Reviewed-by: José Roberto de Souza 

> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Signed-off-by: Vivek Kasireddy 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 4fec5bd64920..f93f72463df5 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1954,6 +1954,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
>   return;
>  
>  err:
> + drm_connector_cleanup(connector);
>   drm_encoder_cleanup(>base);
>   kfree(intel_dsi);
>   kfree(intel_connector);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform
URL   : https://patchwork.freedesktop.org/series/77922/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8572 -> Patchwork_17843


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17843 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17843, 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_17843/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-cml-s:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-cml-s/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-cml-s/igt@i915_selftest@l...@workarounds.html
- fi-icl-y:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-icl-y/igt@i915_selftest@l...@workarounds.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-icl-y/igt@i915_selftest@l...@workarounds.html
- fi-tgl-y:   [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
- fi-icl-guc: [PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
- fi-icl-u2:  [PASS][9] -> [DMESG-FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-icl-u2/igt@i915_selftest@l...@workarounds.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-icl-u2/igt@i915_selftest@l...@workarounds.html
- fi-cml-u2:  [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-cml-u2/igt@i915_selftest@l...@workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-cml-u2/igt@i915_selftest@l...@workarounds.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@workarounds:
- {fi-tgl-dsi}:   [PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
- {fi-ehl-1}: [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
- {fi-tgl-u}: [PASS][17] -> [DMESG-FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-tgl-u/igt@i915_selftest@l...@workarounds.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-tgl-u/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [FAIL][19] ([i915#62]) -> [SKIP][20] ([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8572/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17843/fi-kbl-x1275/igt@i915_pm_...@module-reload.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Participating hosts (51 -> 44)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8572 -> Patchwork_17843

  CI-20190529: 20190529
  CI_DRM_8572: 8a7011d0518058c59f13f10af147d1f97b0a1cd0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17843: 

Re: [Intel-gfx] [PATCH] pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-06-02 Thread Andy Shevchenko
On Tue, Jun 02, 2020 at 06:23:17PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 02, 2020 at 02:21:30PM +0200, Hans de Goede wrote:

...

> Wouldn't be simple below fix the issue?
> 
> @@ -1171,14 +1171,10 @@ static int byt_gpio_direction_input(struct gpio_chip 
> *chip, unsigned int offset)
>  static int byt_gpio_direction_output(struct gpio_chip *chip,
>  unsigned int offset, int value)
>  {
> -   int ret = pinctrl_gpio_direction_output(chip->base + offset);
> -
> -   if (ret)
> -   return ret;
> -
> +   /* Set value first to avoid a glitch */
> byt_gpio_set(chip, offset, value);
>  
> -   return 0;
> +   return pinctrl_gpio_direction_output(chip->base + offset);
>  }
>  
> 
> P.S. It's mangled, sorry.

Cherrytrail does this way, btw, 549e783f6a1.

-- 
With Best Regards,
Andy Shevchenko


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


Re: [Intel-gfx] [PATCH] pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-06-02 Thread Andy Shevchenko
On Tue, Jun 02, 2020 at 02:21:30PM +0200, Hans de Goede wrote:
> The pins on the Bay Trail SoC have separate input-buffer and output-buffer
> enable bits and a read of the level bit of the value register will always
> return the value from the input-buffer.
> 
> The BIOS of a device may configure a pin in output-only mode, only enabling
> the output buffer, and write 1 to the level bit to drive the pin high.
> This 1 written to the level bit will be stored inside the data-latch of the
> output buffer.
> 
> But a subsequent read of the value register will return 0 for the level bit
> because the input-buffer is disabled. This causes a read-modify-write as
> done by byt_gpio_set_direction() to write 0 to the level bit, driving the
> pin low!
> 
> Before this commit byt_gpio_direction_output() relied on
> pinctrl_gpio_direction_output() to set the direction, followed by a call
> to byt_gpio_set() to apply the selected value. This causes the pin to
> go low between the pinctrl_gpio_direction_output() and byt_gpio_set()
> calls.
> 
> Change byt_gpio_direction_output() to directly make the register
> modifications itself instead. Replacing the 2 subsequent writes to the
> value register with a single write.
> 
> Note that the pinctrl code does not keep track internally of the direction,
> so not going through pinctrl_gpio_direction_output() is not an issue.
> 
> This issue was noticed on a Trekstor SurfTab Twin 10.1. When the panel is
> already on at boot (no external monitor connected), then the i915 driver
> does a gpiod_get(..., GPIOD_OUT_HIGH) for the panel-enable GPIO. The
> temporarily going low of that GPIO was causing the panel to reset itself
> after which it would not show an image until it was turned off and back on
> again (until a full modeset was done on it). This commit fixes this.

No Fixes tag?

> Cc: sta...@vger.kernel.org
> Signed-off-by: Hans de Goede 

...

> +static void byt_gpio_direct_irq_check(struct intel_pinctrl *vg,
> +   unsigned int offset)
> +{
> + void __iomem *conf_reg = byt_gpio_reg(vg, offset, BYT_CONF0_REG);
> +
> + /*
> +  * Before making any direction modifications, do a check if gpio is set

> +  * for direct IRQ.  On baytrail, setting GPIO to output does not make

Since we change this, perhaps

'IRQ.  On baytrail' -> 'IRQ. On Baytrail' (one space and capital 'B').

> +  * sense, so let's at least inform the caller before they shoot
> +  * themselves in the foot.
> +  */
> + if (readl(conf_reg) & BYT_DIRECT_IRQ_EN)
> + dev_info_once(vg->dev, "Potential Error: Setting GPIO with 
> direct_irq_en to output");
> +}

...

>  static int byt_gpio_direction_output(struct gpio_chip *chip,
>unsigned int offset, int value)
>  {
> - int ret = pinctrl_gpio_direction_output(chip->base + offset);
> + struct intel_pinctrl *vg = gpiochip_get_data(chip);
> + void __iomem *val_reg = byt_gpio_reg(vg, offset, BYT_VAL_REG);
> + unsigned long flags;
> + u32 reg;
>  
> - if (ret)
> - return ret;
> + raw_spin_lock_irqsave(_lock, flags);
>  
> - byt_gpio_set(chip, offset, value);
> + byt_gpio_direct_irq_check(vg, offset);
>  
> + reg = readl(val_reg);
> + reg &= ~BYT_DIR_MASK;
> + if (value)
> + reg |= BYT_LEVEL;
> + else
> + reg &= ~BYT_LEVEL;
> +
> + writel(reg, val_reg);
> +
> + raw_spin_unlock_irqrestore(_lock, flags);
>   return 0;
>  }

Wouldn't be simple below fix the issue?

@@ -1171,14 +1171,10 @@ static int byt_gpio_direction_input(struct gpio_chip 
*chip, unsigned int offset)
 static int byt_gpio_direction_output(struct gpio_chip *chip,
 unsigned int offset, int value)
 {
-   int ret = pinctrl_gpio_direction_output(chip->base + offset);
-
-   if (ret)
-   return ret;
-
+   /* Set value first to avoid a glitch */
byt_gpio_set(chip, offset, value);
 
-   return 0;
+   return pinctrl_gpio_direction_output(chip->base + offset);
 }
 

P.S. It's mangled, sorry.

-- 
With Best Regards,
Andy Shevchenko


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


Re: [Intel-gfx] [PATCH] drm/i915/params: fix i915.reset module param type

2020-06-02 Thread Chris Wilson
Quoting Jani Nikula (2020-06-02 16:11:26)
> The reset member in i915_params was previously changed to unsigned, but
> this failed to change the actual module parameter.
> 
> Fixes: aae970d8454b ("drm/i915: Mark i915.reset as unsigned")
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Jani Nikula 
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/params: fix i915.reset module param type

2020-06-02 Thread Jani Nikula
The reset member in i915_params was previously changed to unsigned, but
this failed to change the actual module parameter.

Fixes: aae970d8454b ("drm/i915: Mark i915.reset as unsigned")
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index ace44ad7e6df..fd3b14caf4ce 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -74,7 +74,7 @@ i915_param_named_unsafe(vbt_sdvo_panel_type, int, 0400,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-i915_param_named_unsafe(reset, int, 0400,
+i915_param_named_unsafe(reset, uint, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");
 
 i915_param_named_unsafe(vbt_firmware, charp, 0400,
-- 
2.20.1

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform
URL   : https://patchwork.freedesktop.org/series/77922/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Identify Cometlake platform
URL   : https://patchwork.freedesktop.org/series/77922/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cb7a71f01dd4 drm/i915: Identify Cometlake platform
-:367: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#367: FILE: drivers/gpu/drm/i915/i915_drv.h:1471:
+#define IS_CML_GT2(dev_priv)   (IS_COMETLAKE(dev_priv) && \
+INTEL_INFO(dev_priv)->gt == 2)

-:381: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#381: FILE: drivers/gpu/drm/i915/i915_pci.c:769:
+#define CML_PLATFORM \
+   GEN9_FEATURES, \
+   PLATFORM(INTEL_COMETLAKE)

total: 1 errors, 0 warnings, 1 checks, 448 lines checked
fd76a0e5a47e drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

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


Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest

2020-06-02 Thread Christian König

Am 02.06.20 um 16:13 schrieb Nirmoy:

Hi Christian,

On 6/2/20 2:47 PM, Christian König wrote:
Nirmoy please keep in mind that your current implementation doesn't 
fully solve the issue the test case is exercising.


In other words what you have implement is fast skipping of fragmented 
address space for bottom-up and top-down.


But what this test here exercises is the fast skipping of aligned 
allocations. You should probably adjust the test case a bit.



Allocations with size=4k and aign = 8k is known to introduce 
fragmentation,


Yes, but this fragmentation can't be avoided with what we already 
implemented. For this we would need the extension with the alignment I 
already explained.



do you mean I should only test bottom-up and top-down

for now ?


Yes and no.

What we need to test is the following:

1. Make tons of allocations with size=4k and align=0.

2. Free every other of those allocations.

3. Make tons of allocations with size=8k and align=0.

Previously bottom-up and top-down would have checked all the holes 
created in step #2.


With your change they can immediately see that this doesn't make sense 
and shortcut to the leftmost/rightmost leaf node in the tree with the 
large free block.


That we can handle the alignment as well is the next step of that.

Regards,
Christian.




Regards,

Nirmoy





Regards,
Christian.

Am 29.05.20 um 23:01 schrieb Nirmoy:


On 5/29/20 5:52 PM, Chris Wilson wrote:

Quoting Nirmoy (2020-05-29 16:40:53)

This works correctly most of the times but sometimes



I have to take my word back. In another machine,  20k insertions in

best mode takes 6-9 times more than 10k insertions, all most all the 
time.


evict, bottom-up and top-down modes remains in 2-5 times range.


If I reduce the insertions to 1k and 2k then scaling factor for best 
mode stays  below 4 most of the time.


evict, bottom-up and top-down modes remains in 2-3 times range.


I wonder if it makes sense to test with only 1k and 2k insertions 
and tolerate more than error if the mode == best.


Regards,

Nirmoy



20k insertions can take more than 8 times of 10k insertion time.

The pressure is on to improve then :)


Regards,

Nirmoy

On 5/29/20 6:33 PM, Nirmoy Das wrote:

This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.

Output:

[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), 
with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128

[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 
512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 
1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 
1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 
1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 
512: free

[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 
insertions took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 
2 insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 
2 insertions took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 
insertions took 8 and 20 msecs



Signed-off-by: Nirmoy Das 
---
   drivers/gpu/drm/selftests/drm_mm_selftests.h |  1 +
   drivers/gpu/drm/selftests/test-drm_mm.c  | 73 


   2 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h 
b/drivers/gpu/drm/selftests/drm_mm_selftests.h

index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
   selftest(replace, igt_replace)
   selftest(insert_range, igt_insert_range)
   selftest(align, igt_align)
+selftest(frag, igt_frag)
   selftest(align32, igt_align32)
   selftest(align64, igt_align64)
   selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c

index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
   return 0;
   }
   +static int get_insert_time(unsigned int num_insert,
+    const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = 

[Intel-gfx] [PATCH 1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Chris Wilson
Cometlake is small refresh of Coffeelake, but since we have found out a
difference in the plaforms, we need to identify the separate platforms.

Since we previously took Coffeelake/Cometlake as identical, update all
IS_COFFEELAKE() to also include IS_COMETLAKE().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/display/intel_csr.c|  4 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c| 34 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c   |  7 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  2 +-
 drivers/gpu/drm/i915/gvt/display.c  | 30 +++--
 drivers/gpu/drm/i915/gvt/edid.c |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 17 ++
 drivers/gpu/drm/i915/i915_drv.h |  9 ++
 drivers/gpu/drm/i915/i915_pci.c | 22 ++---
 drivers/gpu/drm/i915/intel_device_info.c|  1 +
 drivers/gpu/drm/i915/intel_device_info.h|  1 +
 drivers/gpu/drm/i915/intel_gvt.c|  2 ++
 drivers/gpu/drm/i915/intel_pch.c| 36 ++---
 drivers/gpu/drm/i915/intel_pm.c | 10 --
 15 files changed, 140 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 319932b03e88..9843c9af6c13 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -707,7 +707,9 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
csr->fw_path = GLK_CSR_PATH;
csr->required_version = GLK_CSR_VERSION_REQUIRED;
csr->max_fw_size = GLK_CSR_MAX_FW_SIZE;
-   } else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
+   } else if (IS_KABYLAKE(dev_priv) ||
+  IS_COFFEELAKE(dev_priv) ||
+  IS_COMETLAKE(dev_priv)) {
csr->fw_path = KBL_CSR_PATH;
csr->required_version = KBL_CSR_VERSION_REQUIRED;
csr->max_fw_size = KBL_CSR_MAX_FW_SIZE;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cd211f48c401..bb8107ab5a51 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -722,10 +722,14 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
int *n_entries)
 static const struct ddi_buf_trans *
 kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
 {
-   if (IS_KBL_ULX(dev_priv) || IS_CFL_ULX(dev_priv)) {
+   if (IS_KBL_ULX(dev_priv) ||
+   IS_CFL_ULX(dev_priv) ||
+   IS_CML_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
return kbl_y_ddi_translations_dp;
-   } else if (IS_KBL_ULT(dev_priv) || IS_CFL_ULT(dev_priv)) {
+   } else if (IS_KBL_ULT(dev_priv) ||
+  IS_CFL_ULT(dev_priv) ||
+  IS_CML_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
return kbl_u_ddi_translations_dp;
} else {
@@ -738,12 +742,16 @@ static const struct ddi_buf_trans *
 skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
 {
if (dev_priv->vbt.edp.low_vswing) {
-   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv) ||
-   IS_CFL_ULX(dev_priv)) {
+   if (IS_SKL_ULX(dev_priv) ||
+   IS_KBL_ULX(dev_priv) ||
+   IS_CFL_ULX(dev_priv) ||
+   IS_CML_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_edp);
return skl_y_ddi_translations_edp;
-   } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv) ||
-  IS_CFL_ULT(dev_priv)) {
+   } else if (IS_SKL_ULT(dev_priv) ||
+  IS_KBL_ULT(dev_priv) ||
+  IS_CFL_ULT(dev_priv) ||
+  IS_CML_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_edp);
return skl_u_ddi_translations_edp;
} else {
@@ -752,7 +760,9 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
}
}
 
-   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
+   if (IS_KABYLAKE(dev_priv) ||
+   IS_COFFEELAKE(dev_priv) ||
+   IS_COMETLAKE(dev_priv))
return kbl_get_buf_trans_dp(dev_priv, n_entries);
else
return skl_get_buf_trans_dp(dev_priv, n_entries);
@@ -761,8 +771,10 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
 static const struct ddi_buf_trans *
 skl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
 {
-   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv) ||
-   IS_CFL_ULX(dev_priv)) {
+   

[Intel-gfx] [PATCH 2/2] drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Chris Wilson
For reasons that be, the HW only allows usersace to read its own
CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for
all by adding it to the whitelists.

v2: The change took effect from Cometlake.
v3: Ignore timestamps that autoincrement when validating the whitelist

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 25 ++-
 .../gpu/drm/i915/gt/selftest_workarounds.c| 16 
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6e1accbcc045..0731bbcef06c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1206,6 +1206,18 @@ static void cfl_whitelist_build(struct intel_engine_cs 
*engine)
  RING_FORCE_TO_NONPRIV_RANGE_4);
 }
 
+static void cml_whitelist_build(struct intel_engine_cs *engine)
+{
+   struct i915_wa_list *w = >whitelist;
+
+   if (engine->class != RENDER_CLASS)
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+   cfl_whitelist_build(engine);
+}
+
 static void cnl_whitelist_build(struct intel_engine_cs *engine)
 {
struct i915_wa_list *w = >whitelist;
@@ -1256,9 +1268,15 @@ static void icl_whitelist_build(struct intel_engine_cs 
*engine)
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
  RING_FORCE_TO_NONPRIV_ACCESS_RD);
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
 
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1290,6 +1308,9 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
whitelist_reg(w, HIZ_CHICKEN);
break;
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1307,7 +1328,9 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
icl_whitelist_build(engine);
else if (IS_CANNONLAKE(i915))
cnl_whitelist_build(engine);
-   else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
+   else if (IS_COMETLAKE(i915))
+   cml_whitelist_build(engine);
+   else if (IS_COFFEELAKE(i915))
cfl_whitelist_build(engine);
else if (IS_GEMINILAKE(i915))
glk_whitelist_build(engine);
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c 
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 32785463ec9e..e61af5bcf1c6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -417,6 +417,19 @@ static bool wo_register(struct intel_engine_cs *engine, 
u32 reg)
return false;
 }
 
+static bool timestamp(const struct intel_engine_cs *engine, u32 reg)
+{
+   switch (reg - engine->mmio_base) {
+   case 0x358:
+   case 0x35c:
+   case 0x3a8:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
 static bool ro_register(u32 reg)
 {
if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
@@ -497,6 +510,9 @@ static int check_dirty_whitelist(struct intel_context *ce)
if (wo_register(engine, reg))
continue;
 
+   if (timestamp(engine, reg))
+   continue; /* timestamps are expected to autoincrement */
+
ro_reg = ro_register(reg);
 
/* Clear non priv flags */
-- 
2.20.1

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


Re: [Intel-gfx] [PULL] gvt-next-fixes

2020-06-02 Thread Joonas Lahtinen
Quoting Zhenyu Wang (2020-05-28 06:35:59)
> 
> Hi,
> 
> Here's two queued warning fixes for gvt-next. One is for clang warning
> on debug only function and another one from coccicheck to use ARRAY_SIZE.

Pulled now, thanks for the PR.

Regards, Joonas

> 
> Thanks
> --
> The following changes since commit 3a36aa237e4ed04553c0998cf5f47eda3e206e4f:
> 
>   drm/i915: Update DRIVER_DATE to 20200515 (2020-05-15 14:49:24 +0300)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux tags/gvt-next-fixes-2020-05-28
> 
> for you to fetch changes up to cb7ee52284a244fd14caec73df0d49e02891aac4:
> 
>   drm/i915/gvt: Use ARRAY_SIZE for vgpu_types (2020-05-19 17:18:50 +0800)
> 
> 
> gvt-next-fixes-2020-05-28
> 
> - Fix one clang warning on debug only function (Nathan)
> - Use ARRAY_SIZE for coccicheck warn (Aishwarya)
> 
> 
> Aishwarya Ramakrishnan (1):
>   drm/i915/gvt: Use ARRAY_SIZE for vgpu_types
> 
> Nathan Chancellor (1):
>   drm/i915: Mark check_shadow_context_ppgtt as maybe unused
> 
>  drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-06-02 Thread Patchwork
== Series Details ==

Series: pinctrl: baytrail: Fix pin being driven low for a while on 
gpiod_get(..., GPIOD_OUT_HIGH)
URL   : https://patchwork.freedesktop.org/series/77917/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8571 -> Patchwork_17842


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17842 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17842, 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_17842/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17842/fi-icl-y/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2:  [PASS][3] -> [FAIL][4] ([i915#262])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17842/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html

  
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262


Participating hosts (50 -> 45)
--

  Additional (1): fi-kbl-7560u 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8571 -> Patchwork_17842

  CI-20190529: 20190529
  CI_DRM_8571: 0536dff30eff69abcf6355bdd9b9fdf45a560099 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17842: 3632b22bc93f0e4441d082dfeebfaaf05976684c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3632b22bc93f pinctrl: baytrail: Fix pin being driven low for a while on 
gpiod_get(..., GPIOD_OUT_HIGH)

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77916/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8571 -> Patchwork_17841


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17841 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17841, 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_17841/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-icl-y:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-y/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-icl-y/igt@i915_selftest@l...@workarounds.html
- fi-tgl-y:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
- fi-icl-guc: [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
- fi-icl-u2:  [PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-u2/igt@i915_selftest@l...@workarounds.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-icl-u2/igt@i915_selftest@l...@workarounds.html

  * igt@runner@aborted:
- fi-cml-u2:  NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-cml-u2/igt@run...@aborted.html
- fi-cml-s:   NOTRUN -> [FAIL][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-cml-s/igt@run...@aborted.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@workarounds:
- {fi-tgl-dsi}:   [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
- {fi-ehl-1}: [PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
- {fi-tgl-u}: [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-u/igt@i915_selftest@l...@workarounds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17841/fi-tgl-u/igt@i915_selftest@l...@workarounds.html

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



Participating hosts (50 -> 45)
--

  Additional (1): fi-kbl-7560u 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8571 -> Patchwork_17841

  CI-20190529: 20190529
  CI_DRM_8571: 0536dff30eff69abcf6355bdd9b9fdf45a560099 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17841: e06a98a107857728c714419a7849f41ba2c6dd11 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e06a98a10785 drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs
b57ebeadf460 drm/i915: Identify Cometlake platform

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77916/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant 
expression in case statement
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer 
constant expression
+drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant 
expression
+drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:408:9: warning: context imbalance in 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/i915: Identify Cometlake platform (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with drm/i915: Identify Cometlake platform (rev2)
URL   : https://patchwork.freedesktop.org/series/77916/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b57ebeadf460 drm/i915: Identify Cometlake platform
-:354: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#354: FILE: drivers/gpu/drm/i915/i915_drv.h:1471:
+#define IS_CML_GT2(dev_priv)   (IS_COMETLAKE(dev_priv) && \
+INTEL_INFO(dev_priv)->gt == 2)

-:368: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#368: FILE: drivers/gpu/drm/i915/i915_pci.c:769:
+#define CML_PLATFORM \
+   GEN9_FEATURES, \
+   PLATFORM(INTEL_COMETLAKE)

total: 1 errors, 0 warnings, 1 checks, 433 lines checked
e06a98a10785 drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

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


Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-02 Thread Shankar, Uma


> -Original Message-
> From: Gupta, Anshuman 
> Sent: Tuesday, June 2, 2020 5:37 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs
> 
> On 2020-06-01 at 18:19:44 +0530, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Anshuman Gupta
> > > Sent: Monday, June 1, 2020 3:45 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: sta...@vger.kernel.org
> > > Subject: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs
> > >
> > > Gen12 hw are failing to enable lpsp configuration due to PG3 was
> > > left on due to valid usgae count of POWER_DOMAIN_AUDIO.
> > > It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling
> > > a crtc, it should be always i915_audio_component request to get/put
> > > AUDIO_POWER_DOMAIN.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Ville Syrjälä 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Anshuman Gupta 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 6c3b11de2daf..f31a579d7a52 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct
> > > intel_crtc_state *crtc_state)
> > >   mask |= BIT_ULL(intel_encoder->power_domain);
> > >   }
> > >
> > > - if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> > > + /*
> > > +  * Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
> > > +  * enable AUDIO power in order to enable a crtc.
> > > +  */
> > > + if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) &&
> > > +crtc_state->has_audio)
> > >   mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
> >
> > As part of ddi_get_config we determine has_audio using power well enabled:
> > pipe_config->has_audio =
> > intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
> IMO AUDIO power will also be requested by i915_audio_component get request,
> we can always use HDMI display without audio playback, AUDIO power should
> be enabled when audio driver request for it.
> if we get AUDIO_POWER_DOMAIN while enabling crtc PG3 will always kept on till
> CRTC is disabled, that is the issue required to be addressed here.

Yes HDMI can be enabled without audio, but if we want audio we will need to 
notify
audio driver through HSW_AUD_PIN_ELD_CP_VLD and also prepare and write ELD data
in hardware register. If I understand correctly this will need power and by 
this time audio
driver would not have requested for it. Hence this will fail audio detection.

> This is just RFC to initiate a discussion around it.
> Thanks,
> Anshuman Gupta.
> >
> > If audio power domain is not enabled, we may end up with this as false.
> > Later this may get checked in intel_enable_ddi_hdmi to call audio
> > codec enable
> >
> > if (crtc_state->has_audio)
> > intel_audio_codec_enable(encoder, crtc_state,
> > conn_state);
> >
> > This may cause detection to fail. Please verify this usecase once and 
> > confirm.
> >
> > Regards,
> > Uma Shankar
> >
> > >   if (crtc_state->shared_dpll)
> > > --
> > > 2.26.2
> > >
> > > ___
> > > 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/malidp: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Liviu Dudau
Hi Daniel,

On Tue, Jun 02, 2020 at 11:55:05AM +0200, Daniel Vetter wrote:
> This is already done as part of the drm_atomic_helper_shutdown(),
> and in that case only for the crtc which are actually on.
> 
> v2: I overlooked that malidp also needs to have it's interrupt shut
> down reordered.

Got confused by the subject not having any version of the patch, so I've
acked the other one, but this is the one I've meant to Ack.

So, Acked-by: Liviu Dudau 

Best regards,
Liviu

> 
> Signed-off-by: Daniel Vetter 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 02904392e370..cdb817a7c611 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -928,11 +928,10 @@ static void malidp_unbind(struct device *dev)
>   drm_dev_unregister(drm);
>   drm_kms_helper_poll_fini(drm);
>   pm_runtime_get_sync(dev);
> - drm_crtc_vblank_off(>crtc);
> + drm_atomic_helper_shutdown(drm);
>   malidp_se_irq_fini(hwdev);
>   malidp_de_irq_fini(hwdev);
>   drm->irq_enabled = false;
> - drm_atomic_helper_shutdown(drm);
>   component_unbind_all(dev, drm);
>   of_node_put(malidp->crtc.port);
>   malidp->crtc.port = NULL;
> -- 
> 2.26.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/hdlcd: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Liviu Dudau
On Tue, Jun 02, 2020 at 11:51:40AM +0200, Daniel Vetter wrote:
> This is already taken care of by drm_atomic_helper_shutdown(), and
> in that case only for the CRTC which are actually on.
> 
> Only tricky bit here is that we kill the interrupt handling before we
> shut down crtc, so need to reorder that.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Liviu Dudau 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> Cc: Brian Starkey 
> Cc:
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 194419f47c5e..26bc5d7766f5 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -347,9 +347,8 @@ static void hdlcd_drm_unbind(struct device *dev)
>   of_node_put(hdlcd->crtc.port);
>   hdlcd->crtc.port = NULL;
>   pm_runtime_get_sync(dev);
> - drm_crtc_vblank_off(>crtc);
> - drm_irq_uninstall(drm);
>   drm_atomic_helper_shutdown(drm);
> + drm_irq_uninstall(drm);
>   pm_runtime_put(dev);
>   if (pm_runtime_enabled(dev))
>   pm_runtime_disable(dev);
> -- 
> 2.26.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs
URL   : https://patchwork.freedesktop.org/series/77910/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8571 -> Patchwork_17840


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17840 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17840, 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_17840/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-icl-y:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-y/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-icl-y/igt@i915_selftest@l...@workarounds.html
- fi-tgl-y:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-tgl-y/igt@i915_selftest@l...@workarounds.html
- fi-icl-guc: [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-icl-guc/igt@i915_selftest@l...@workarounds.html
- fi-icl-u2:  [PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-icl-u2/igt@i915_selftest@l...@workarounds.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-icl-u2/igt@i915_selftest@l...@workarounds.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@workarounds:
- {fi-tgl-dsi}:   [PASS][9] -> [DMESG-FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-tgl-dsi/igt@i915_selftest@l...@workarounds.html
- {fi-ehl-1}: [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-ehl-1/igt@i915_selftest@l...@workarounds.html
- {fi-tgl-u}: [PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8571/fi-tgl-u/igt@i915_selftest@l...@workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17840/fi-tgl-u/igt@i915_selftest@l...@workarounds.html

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



Participating hosts (50 -> 44)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8571 -> Patchwork_17840

  CI-20190529: 20190529
  CI_DRM_8571: 0536dff30eff69abcf6355bdd9b9fdf45a560099 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17840: ecf32dcbc65f20a3c18eab819236813936a61e10 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ecf32dcbc65f drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/3] drm/malidp: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Liviu Dudau
Hi Daniel,

On Tue, Jun 02, 2020 at 11:51:39AM +0200, Daniel Vetter wrote:
> This is already done as part of the drm_atomic_helper_shutdown(),
> and in that case only for the crtc which are actually on.
>

I'm pretty sure that it didn't used to be the case when I wrote the code
and I was hitting warnings from 84014b0a39eef6df ("drm/atomic-helper: check that
drivers call drm_crtc_vblank_off"), but I'm happy that things have now been 
fixed.

> Signed-off-by: Daniel Vetter 
> Cc: Liviu Dudau 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> Cc: Brian Starkey 
> Cc:
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 02904392e370..db6ba5c78042 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -928,7 +928,6 @@ static void malidp_unbind(struct device *dev)
>   drm_dev_unregister(drm);
>   drm_kms_helper_poll_fini(drm);
>   pm_runtime_get_sync(dev);
> - drm_crtc_vblank_off(>crtc);
>   malidp_se_irq_fini(hwdev);
>   malidp_de_irq_fini(hwdev);
>   drm->irq_enabled = false;
> -- 
> 2.26.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest

2020-06-02 Thread Christian König
Nirmoy please keep in mind that your current implementation doesn't 
fully solve the issue the test case is exercising.


In other words what you have implement is fast skipping of fragmented 
address space for bottom-up and top-down.


But what this test here exercises is the fast skipping of aligned 
allocations. You should probably adjust the test case a bit.


Regards,
Christian.

Am 29.05.20 um 23:01 schrieb Nirmoy:


On 5/29/20 5:52 PM, Chris Wilson wrote:

Quoting Nirmoy (2020-05-29 16:40:53)

This works correctly most of the times but sometimes



I have to take my word back. In another machine,  20k insertions in

best mode takes 6-9 times more than 10k insertions, all most all the 
time.


evict, bottom-up and top-down modes remains in 2-5 times range.


If I reduce the insertions to 1k and 2k then scaling factor for best 
mode stays  below 4 most of the time.


evict, bottom-up and top-down modes remains in 2-3 times range.


I wonder if it makes sense to test with only 1k and 2k insertions and 
tolerate more than error if the mode == best.


Regards,

Nirmoy



20k insertions can take more than 8 times of 10k insertion time.

The pressure is on to improve then :)


Regards,

Nirmoy

On 5/29/20 6:33 PM, Nirmoy Das wrote:

This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel scheduler's jitters.

Output:

[ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), 
with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128

[ 8092.653520] drm_mm: igt_sanitycheck - ok!
[ 8092.653525] igt_debug 0x-0x0200: 
512: free
[ 8092.653526] igt_debug 0x0200-0x0600: 
1024: used
[ 8092.653527] igt_debug 0x0600-0x0a00: 
1024: free
[ 8092.653528] igt_debug 0x0a00-0x0e00: 
1024: used
[ 8092.653529] igt_debug 0x0e00-0x1000: 
512: free

[ 8092.653529] igt_debug total: 4096, used 2048 free 2048
[ 8112.569813] drm_mm: best fragmented insert of 1 and 2 
insertions took 504 and 1996 msecs
[ 8112.723254] drm_mm: bottom-up fragmented insert of 1 and 
2 insertions took 44 and 108 msecs
[ 8112.813212] drm_mm: top-down fragmented insert of 1 and 
2 insertions took 40 and 44 msecs
[ 8112.847733] drm_mm: evict fragmented insert of 1 and 2 
insertions took 8 and 20 msecs



Signed-off-by: Nirmoy Das 
---
   drivers/gpu/drm/selftests/drm_mm_selftests.h |  1 +
   drivers/gpu/drm/selftests/test-drm_mm.c  | 73 


   2 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h 
b/drivers/gpu/drm/selftests/drm_mm_selftests.h

index 6b943ea1c57d..8c87c964176b 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -14,6 +14,7 @@ selftest(insert, igt_insert)
   selftest(replace, igt_replace)
   selftest(insert_range, igt_insert_range)
   selftest(align, igt_align)
+selftest(frag, igt_frag)
   selftest(align32, igt_align32)
   selftest(align64, igt_align64)
   selftest(evict, igt_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c

index 9aabe82dcd3a..05d8f3659b4d 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
   return 0;
   }
   +static int get_insert_time(unsigned int num_insert,
+    const struct insert_mode *mode)
+{
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int size = 4096, align = 8192;
+ unsigned long start;
+ unsigned int i;
+ int ret = -EINVAL;
+
+ drm_mm_init(, 1, U64_MAX - 2);
+ nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
+ if (!nodes)
+ goto err;
+
+ start = jiffies;

Use ktime_t start = ktime_now();


+ for (i = 0; i < num_insert; i++) {
+ if (!expect_insert(, [i], size, align, i, 
mode)) {

+ pr_err("%s insert failed\n", mode->name);
+ goto out;
+ }
+ }
+
+ ret = jiffies_to_msecs(jiffies - start);

ret = ktime_sub(ktime_now(), start);

The downside to using ktime is remembering it is s64 and so requires 
care

and attention in doing math.


+out:
+ drm_mm_for_each_node_safe(node, next, )
+ drm_mm_remove_node(node);
+ drm_mm_takedown();
+ vfree(nodes);
+err:
+ return ret;
+
+}
+
+static int igt_frag(void *ignored)
+{
+ const struct insert_mode *mode;
+ unsigned int insert_time1, insert_time2;
+ unsigned int insert_size = 1;
+ unsigned int scale_factor = 4;
+ /* tolerate 10% excess insertion duration */
+   

Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-02 Thread Anshuman Gupta
On 2020-06-01 at 17:11:32 +0300, Ville Syrjälä wrote:
> On Mon, Jun 01, 2020 at 03:45:16PM +0530, Anshuman Gupta wrote:
> > Gen12 hw are failing to enable lpsp configuration due to PG3 was left on
> > due to valid usgae count of POWER_DOMAIN_AUDIO.
> > It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling
> > a crtc, it should be always i915_audio_component request to get/put
> > AUDIO_POWER_DOMAIN.
> > 
> > Cc: sta...@vger.kernel.org
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 6c3b11de2daf..f31a579d7a52 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct 
> > intel_crtc_state *crtc_state)
> > mask |= BIT_ULL(intel_encoder->power_domain);
> > }
> >  
> > -   if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> > +   /*
> > +* Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
> > +* enable AUDIO power in order to enable a crtc
> 
> Nothing requires audio power to enable a crtc. What this is saying is
> that if we want audio then we must enable the audio power. If you
> didn't want audio then you wouldn't have .has_audio set.
IMO i915_audio_component_get_power also enables audio power, and
i915_audio_component_put_power releases the usage count based upon audio
runtime idleness but here get_crtc_power_domains() gets the POWER_DOMAIN_AUDIO 
usages
count, which will be released only when this crtc get disbaled.
It may enable AUDIO power despite of fact that audio driver has released the
usage count.
Please correct me if i am wrong here.

> 
> That said, looks like audio is moving into the always on well, but not
> yet in tgl.
Still some of audio functional stuff lies in PG3, not completely removed
from PG3.
Thanks,
Anshuman Gupta.
> 
> .
> > +*/
> > +   if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) && 
> > crtc_state->has_audio)
> > mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
> >  
> > if (crtc_state->shared_dpll)
> > -- 
> > 2.26.2
> 
> -- 
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/atomic-helper: reset vblank on crtc reset (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/atomic-helper: reset vblank on crtc 
reset (rev2)
URL   : https://patchwork.freedesktop.org/series/77908/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8571 -> Patchwork_17839


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17839/index.html


Changes
---

  No changes found


Participating hosts (50 -> 44)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8571 -> Patchwork_17839

  CI-20190529: 20190529
  CI_DRM_8571: 0536dff30eff69abcf6355bdd9b9fdf45a560099 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5690: bea881189520a9cccbb1c1cb454ac5b6fdaea40e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17839: 011586de521b2df487223c8f7c1739f041bd7d07 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

011586de521b drm/hdlcd: Don't call drm_crtc_vblank_off on unbind
e80c8ed59e03 drm/malidp: Don't call drm_crtc_vblank_off on unbind
c9cd581c2623 drm/atomic-helper: reset vblank on crtc reset

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Identify Cometlake platform

2020-06-02 Thread Chris Wilson
Cometlake is small refresh of Coffeelake, but since we have found out a
difference in the plaforms, we need to identify the separate platforms.

Since we previously took Coffeelake/Cometlake as identical, update all
IS_COFFEELAKE() to also include IS_COMETLAKE().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/display/intel_csr.c|  4 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c| 34 +--
 drivers/gpu/drm/i915/display/intel_hdcp.c   |  7 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +++
 drivers/gpu/drm/i915/gvt/display.c  | 30 +++--
 drivers/gpu/drm/i915/gvt/edid.c |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 17 ++
 drivers/gpu/drm/i915/i915_drv.h |  9 ++
 drivers/gpu/drm/i915/i915_pci.c | 22 ++---
 drivers/gpu/drm/i915/intel_device_info.h|  1 +
 drivers/gpu/drm/i915/intel_gvt.c|  2 ++
 drivers/gpu/drm/i915/intel_pch.c| 36 ++---
 drivers/gpu/drm/i915/intel_pm.c | 10 --
 13 files changed, 138 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 319932b03e88..9843c9af6c13 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -707,7 +707,9 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
csr->fw_path = GLK_CSR_PATH;
csr->required_version = GLK_CSR_VERSION_REQUIRED;
csr->max_fw_size = GLK_CSR_MAX_FW_SIZE;
-   } else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
+   } else if (IS_KABYLAKE(dev_priv) ||
+  IS_COFFEELAKE(dev_priv) ||
+  IS_COMETLAKE(dev_priv)) {
csr->fw_path = KBL_CSR_PATH;
csr->required_version = KBL_CSR_VERSION_REQUIRED;
csr->max_fw_size = KBL_CSR_MAX_FW_SIZE;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cd211f48c401..bb8107ab5a51 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -722,10 +722,14 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
int *n_entries)
 static const struct ddi_buf_trans *
 kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
 {
-   if (IS_KBL_ULX(dev_priv) || IS_CFL_ULX(dev_priv)) {
+   if (IS_KBL_ULX(dev_priv) ||
+   IS_CFL_ULX(dev_priv) ||
+   IS_CML_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
return kbl_y_ddi_translations_dp;
-   } else if (IS_KBL_ULT(dev_priv) || IS_CFL_ULT(dev_priv)) {
+   } else if (IS_KBL_ULT(dev_priv) ||
+  IS_CFL_ULT(dev_priv) ||
+  IS_CML_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
return kbl_u_ddi_translations_dp;
} else {
@@ -738,12 +742,16 @@ static const struct ddi_buf_trans *
 skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
 {
if (dev_priv->vbt.edp.low_vswing) {
-   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv) ||
-   IS_CFL_ULX(dev_priv)) {
+   if (IS_SKL_ULX(dev_priv) ||
+   IS_KBL_ULX(dev_priv) ||
+   IS_CFL_ULX(dev_priv) ||
+   IS_CML_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_edp);
return skl_y_ddi_translations_edp;
-   } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv) ||
-  IS_CFL_ULT(dev_priv)) {
+   } else if (IS_SKL_ULT(dev_priv) ||
+  IS_KBL_ULT(dev_priv) ||
+  IS_CFL_ULT(dev_priv) ||
+  IS_CML_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_edp);
return skl_u_ddi_translations_edp;
} else {
@@ -752,7 +760,9 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
}
}
 
-   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
+   if (IS_KABYLAKE(dev_priv) ||
+   IS_COFFEELAKE(dev_priv) ||
+   IS_COMETLAKE(dev_priv))
return kbl_get_buf_trans_dp(dev_priv, n_entries);
else
return skl_get_buf_trans_dp(dev_priv, n_entries);
@@ -761,8 +771,10 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
 static const struct ddi_buf_trans *
 skl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv, int *n_entries)
 {
-   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv) ||
-   IS_CFL_ULX(dev_priv)) {
+   if (IS_SKL_ULX(dev_priv) ||
+   IS_KBL_ULX(dev_priv) ||
+   IS_CFL_ULX(dev_priv) ||
+  

[Intel-gfx] [PATCH] pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-06-02 Thread Hans de Goede
The pins on the Bay Trail SoC have separate input-buffer and output-buffer
enable bits and a read of the level bit of the value register will always
return the value from the input-buffer.

The BIOS of a device may configure a pin in output-only mode, only enabling
the output buffer, and write 1 to the level bit to drive the pin high.
This 1 written to the level bit will be stored inside the data-latch of the
output buffer.

But a subsequent read of the value register will return 0 for the level bit
because the input-buffer is disabled. This causes a read-modify-write as
done by byt_gpio_set_direction() to write 0 to the level bit, driving the
pin low!

Before this commit byt_gpio_direction_output() relied on
pinctrl_gpio_direction_output() to set the direction, followed by a call
to byt_gpio_set() to apply the selected value. This causes the pin to
go low between the pinctrl_gpio_direction_output() and byt_gpio_set()
calls.

Change byt_gpio_direction_output() to directly make the register
modifications itself instead. Replacing the 2 subsequent writes to the
value register with a single write.

Note that the pinctrl code does not keep track internally of the direction,
so not going through pinctrl_gpio_direction_output() is not an issue.

This issue was noticed on a Trekstor SurfTab Twin 10.1. When the panel is
already on at boot (no external monitor connected), then the i915 driver
does a gpiod_get(..., GPIOD_OUT_HIGH) for the panel-enable GPIO. The
temporarily going low of that GPIO was causing the panel to reset itself
after which it would not show an image until it was turned off and back on
again (until a full modeset was done on it). This commit fixes this.

Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
Note the factoring out of the direct IRQ mode warning is deliberately not
split into a separate patch to make backporting this easier.
---
 drivers/pinctrl/intel/pinctrl-baytrail.c | 46 +---
 1 file changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c 
b/drivers/pinctrl/intel/pinctrl-baytrail.c
index 9b821c9cbd16..83be13b83eb5 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -800,6 +800,21 @@ static void byt_gpio_disable_free(struct pinctrl_dev 
*pctl_dev,
pm_runtime_put(vg->dev);
 }
 
+static void byt_gpio_direct_irq_check(struct intel_pinctrl *vg,
+ unsigned int offset)
+{
+   void __iomem *conf_reg = byt_gpio_reg(vg, offset, BYT_CONF0_REG);
+
+   /*
+* Before making any direction modifications, do a check if gpio is set
+* for direct IRQ.  On baytrail, setting GPIO to output does not make
+* sense, so let's at least inform the caller before they shoot
+* themselves in the foot.
+*/
+   if (readl(conf_reg) & BYT_DIRECT_IRQ_EN)
+   dev_info_once(vg->dev, "Potential Error: Setting GPIO with 
direct_irq_en to output");
+}
+
 static int byt_gpio_set_direction(struct pinctrl_dev *pctl_dev,
  struct pinctrl_gpio_range *range,
  unsigned int offset,
@@ -807,7 +822,6 @@ static int byt_gpio_set_direction(struct pinctrl_dev 
*pctl_dev,
 {
struct intel_pinctrl *vg = pinctrl_dev_get_drvdata(pctl_dev);
void __iomem *val_reg = byt_gpio_reg(vg, offset, BYT_VAL_REG);
-   void __iomem *conf_reg = byt_gpio_reg(vg, offset, BYT_CONF0_REG);
unsigned long flags;
u32 value;
 
@@ -817,14 +831,8 @@ static int byt_gpio_set_direction(struct pinctrl_dev 
*pctl_dev,
value &= ~BYT_DIR_MASK;
if (input)
value |= BYT_OUTPUT_EN;
-   else if (readl(conf_reg) & BYT_DIRECT_IRQ_EN)
-   /*
-* Before making any direction modifications, do a check if gpio
-* is set for direct IRQ.  On baytrail, setting GPIO to output
-* does not make sense, so let's at least inform the caller 
before
-* they shoot themselves in the foot.
-*/
-   dev_info_once(vg->dev, "Potential Error: Setting GPIO with 
direct_irq_en to output");
+   else
+   byt_gpio_direct_irq_check(vg, offset);
 
writel(value, val_reg);
 
@@ -1171,13 +1179,25 @@ static int byt_gpio_direction_input(struct gpio_chip 
*chip, unsigned int offset)
 static int byt_gpio_direction_output(struct gpio_chip *chip,
 unsigned int offset, int value)
 {
-   int ret = pinctrl_gpio_direction_output(chip->base + offset);
+   struct intel_pinctrl *vg = gpiochip_get_data(chip);
+   void __iomem *val_reg = byt_gpio_reg(vg, offset, BYT_VAL_REG);
+   unsigned long flags;
+   u32 reg;
 
-   if (ret)
-   return ret;
+   raw_spin_lock_irqsave(_lock, flags);
 
-   byt_gpio_set(chip, offset, value);
+   

Re: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs

2020-06-02 Thread Anshuman Gupta
On 2020-06-01 at 18:19:44 +0530, Shankar, Uma wrote:
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Anshuman Gupta
> > Sent: Monday, June 1, 2020 3:45 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: sta...@vger.kernel.org
> > Subject: [Intel-gfx] [RFC] drm/i915: lpsp with hdmi/dp outputs
> > 
> > Gen12 hw are failing to enable lpsp configuration due to PG3 was left on 
> > due to
> > valid usgae count of POWER_DOMAIN_AUDIO.
> > It is not required to get POWER_DOMAIN_AUDIO ref-count when enabling a crtc,
> > it should be always i915_audio_component request to get/put
> > AUDIO_POWER_DOMAIN.
> > 
> > Cc: sta...@vger.kernel.org
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 6c3b11de2daf..f31a579d7a52 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7356,7 +7356,11 @@ static u64 get_crtc_power_domains(struct
> > intel_crtc_state *crtc_state)
> > mask |= BIT_ULL(intel_encoder->power_domain);
> > }
> > 
> > -   if (HAS_DDI(dev_priv) && crtc_state->has_audio)
> > +   /*
> > +* Gen12 can drive lpsp on hdmi/dp outpus, it doesn't require to
> > +* enable AUDIO power in order to enable a crtc.
> > +*/
> > +   if (INTEL_GEN(dev_priv) < 12 && HAS_DDI(dev_priv) &&
> > +crtc_state->has_audio)
> > mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
> 
> As part of ddi_get_config we determine has_audio using power well enabled:
> pipe_config->has_audio =
> intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
IMO AUDIO power will also be requested by i915_audio_component get request, 
we can always use HDMI display without audio playback, AUDIO power should be 
enabled when audio driver request for it. 
if we get AUDIO_POWER_DOMAIN while enabling crtc PG3 will always kept on till 
CRTC is disabled,
that is the issue required to be addressed here.
This is just RFC to initiate a discussion around it.
Thanks,
Anshuman Gupta.
> 
> If audio power domain is not enabled, we may end up with this as false.
> Later this may get checked in intel_enable_ddi_hdmi to call audio codec enable
> 
> if (crtc_state->has_audio)
> intel_audio_codec_enable(encoder, crtc_state, conn_state);
> 
> This may cause detection to fail. Please verify this usecase once and confirm.
> 
> Regards,
> Uma Shankar
> 
> > if (crtc_state->shared_dpll)
> > --
> > 2.26.2
> > 
> > ___
> > 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] [PATCH 2/2] drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Chris Wilson
For reasons that be, the HW only allows usersace to read its own
CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for
all by adding it to the whitelists.

v2: The change took effect from Cometlake.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6e1accbcc045..0731bbcef06c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1206,6 +1206,18 @@ static void cfl_whitelist_build(struct intel_engine_cs 
*engine)
  RING_FORCE_TO_NONPRIV_RANGE_4);
 }
 
+static void cml_whitelist_build(struct intel_engine_cs *engine)
+{
+   struct i915_wa_list *w = >whitelist;
+
+   if (engine->class != RENDER_CLASS)
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
+
+   cfl_whitelist_build(engine);
+}
+
 static void cnl_whitelist_build(struct intel_engine_cs *engine)
 {
struct i915_wa_list *w = >whitelist;
@@ -1256,9 +1268,15 @@ static void icl_whitelist_build(struct intel_engine_cs 
*engine)
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
  RING_FORCE_TO_NONPRIV_ACCESS_RD);
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
 
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1290,6 +1308,9 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
whitelist_reg(w, HIZ_CHICKEN);
break;
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1307,7 +1328,9 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
icl_whitelist_build(engine);
else if (IS_CANNONLAKE(i915))
cnl_whitelist_build(engine);
-   else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
+   else if (IS_COMETLAKE(i915))
+   cml_whitelist_build(engine);
+   else if (IS_COFFEELAKE(i915))
cfl_whitelist_build(engine);
else if (IS_GEMINILAKE(i915))
glk_whitelist_build(engine);
-- 
2.20.1

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


[Intel-gfx] [PATCH 1/2] drm/i915: Identify Cometlake platform

2020-06-02 Thread Chris Wilson
Cometlake is small refresh of Coffeelake, but since we have found out a
difference in the plaforms, we need to identify the separate platforms.

Since we previously took Coffeelake/Cometlake as identical, update all
IS_COFFEELAKE() to also include IS_COMETLAKE().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/display/intel_csr.c|  4 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c|  8 +++--
 drivers/gpu/drm/i915/display/intel_hdcp.c   |  7 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +++
 drivers/gpu/drm/i915/gvt/display.c  | 30 +++--
 drivers/gpu/drm/i915/gvt/edid.c |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 17 ++
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_pci.c | 22 ++---
 drivers/gpu/drm/i915/intel_device_info.h|  1 +
 drivers/gpu/drm/i915/intel_gvt.c|  2 ++
 drivers/gpu/drm/i915/intel_pch.c| 36 ++---
 drivers/gpu/drm/i915/intel_pm.c | 10 --
 13 files changed, 112 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 319932b03e88..9843c9af6c13 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -707,7 +707,9 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
csr->fw_path = GLK_CSR_PATH;
csr->required_version = GLK_CSR_VERSION_REQUIRED;
csr->max_fw_size = GLK_CSR_MAX_FW_SIZE;
-   } else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
+   } else if (IS_KABYLAKE(dev_priv) ||
+  IS_COFFEELAKE(dev_priv) ||
+  IS_COMETLAKE(dev_priv)) {
csr->fw_path = KBL_CSR_PATH;
csr->required_version = KBL_CSR_VERSION_REQUIRED;
csr->max_fw_size = KBL_CSR_MAX_FW_SIZE;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cd211f48c401..c8b8f96a3ae2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -752,7 +752,9 @@ skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
}
}
 
-   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))
+   if (IS_KABYLAKE(dev_priv) ||
+   IS_COFFEELAKE(dev_priv) ||
+   IS_COMETLAKE(dev_priv))
return kbl_get_buf_trans_dp(dev_priv, n_entries);
else
return skl_get_buf_trans_dp(dev_priv, n_entries);
@@ -784,7 +786,9 @@ static const struct ddi_buf_trans *
 intel_ddi_get_buf_trans_dp(struct drm_i915_private *dev_priv,
   enum port port, int *n_entries)
 {
-   if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
+   if (IS_KABYLAKE(dev_priv) ||
+   IS_COFFEELAKE(dev_priv) ||
+   IS_COMETLAKE(dev_priv)) {
const struct ddi_buf_trans *ddi_translations =
kbl_get_buf_trans_dp(dev_priv, n_entries);
*n_entries = skl_buf_trans_num_entries(port, *n_entries);
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..815b054bb167 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1923,8 +1923,11 @@ static bool is_hdcp2_supported(struct drm_i915_private 
*dev_priv)
if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
return false;
 
-   return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
-   IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv));
+   return (INTEL_GEN(dev_priv) >= 10 ||
+   IS_GEMINILAKE(dev_priv) ||
+   IS_KABYLAKE(dev_priv) ||
+   IS_COFFEELAKE(dev_priv) ||
+   IS_COMETLAKE(dev_priv));
 }
 
 void intel_hdcp_component_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 94d66a9d760d..6e1accbcc045 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -361,7 +361,10 @@ static void gen9_ctx_workarounds_init(struct 
intel_engine_cs *engine,
  HDC_FORCE_NON_COHERENT);
 
/* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
-   if (IS_SKYLAKE(i915) || IS_KABYLAKE(i915) || IS_COFFEELAKE(i915))
+   if (IS_SKYLAKE(i915) ||
+   IS_KABYLAKE(i915) ||
+   IS_COFFEELAKE(i915) ||
+   IS_COMETLAKE(i915))
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
  GEN8_SAMPLER_POWER_BYPASS_DIS);
 
@@ -636,7 +639,7 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
icl_ctx_workarounds_init(engine, wal);
else if (IS_CANNONLAKE(i915))
 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/atomic-helper: reset vblank on crtc reset (rev2)

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/atomic-helper: reset vblank on crtc 
reset (rev2)
URL   : https://patchwork.freedesktop.org/series/77908/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c9cd581c2623 drm/atomic-helper: reset vblank on crtc reset
-:247: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 113 lines checked
e80c8ed59e03 drm/malidp: Don't call drm_crtc_vblank_off on unbind
-:32: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 12 lines checked
011586de521b drm/hdlcd: Don't call drm_crtc_vblank_off on unbind
-:15: WARNING:BAD_SIGN_OFF: Use a single space after Cc:
#15: 
Cc:

-:15: ERROR:BAD_SIGN_OFF: Unrecognized email address: ''
#15: 
Cc:

-:31: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

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

___
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/dsi: Dont forget to clean up the connector on error (rev3)

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Dont forget to clean up the connector on error (rev3)
URL   : https://patchwork.freedesktop.org/series/77011/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8568_full -> Patchwork_17838_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17838_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17838_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_17838_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_reloc@basic-cpu-read:
- shard-skl:  [PASS][1] -> [TIMEOUT][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl5/igt@gem_exec_re...@basic-cpu-read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl9/igt@gem_exec_re...@basic-cpu-read.html

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-iclb6/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-iclb1/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#648] / [i915#69])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-iclb5/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_vblank@pipe-c-wait-idle-hang:
- shard-apl:  [PASS][13] -> [TIMEOUT][14] ([i915#1635]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@kms_vbl...@pipe-c-wait-idle-hang.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl6/igt@kms_vbl...@pipe-c-wait-idle-hang.html

  
 Possible fixes 

  * {igt@gem_exec_schedule@implicit-write-read@rcs0}:
- shard-snb:  [INCOMPLETE][15] ([i915#82]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-snb6/igt@gem_exec_schedule@implicit-write-r...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-snb5/igt@gem_exec_schedule@implicit-write-r...@rcs0.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html

  * {igt@kms_flip@flip-vs-suspend@a-dp1}:
- shard-apl:  [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +3 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl1/igt@kms_flip@flip-vs-susp...@a-dp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17838/shard-apl7/igt@kms_flip@flip-vs-susp...@a-dp1.html

  * {igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1}:
- shard-skl:  [FAIL][21] ([i915#1928]) -> [PASS][22]
   [21]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add Wa_1409371443

2020-06-02 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add Wa_1409371443
URL   : https://patchwork.freedesktop.org/series/77892/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8568_full -> Patchwork_17837_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl:  [PASS][1] -> [FAIL][2] ([i915#1528])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl1/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +5 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw:  [PASS][5] -> [FAIL][6] ([i915#57])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#108145] / [i915#265]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109441]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-iclb7/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_vblank@pipe-a-ts-continuation-idle-hang:
- shard-snb:  [PASS][11] -> [SKIP][12] ([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-snb1/igt@kms_vbl...@pipe-a-ts-continuation-idle-hang.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-snb6/igt@kms_vbl...@pipe-a-ts-continuation-idle-hang.html

  * igt@kms_vblank@pipe-c-wait-idle-hang:
- shard-apl:  [PASS][13] -> [TIMEOUT][14] ([i915#1635]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@kms_vbl...@pipe-c-wait-idle-hang.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-apl8/igt@kms_vbl...@pipe-c-wait-idle-hang.html

  
 Possible fixes 

  * {igt@gem_ctx_isolation@preservation-s3@rcs0}:
- shard-apl:  [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-apl6/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_pm_rpm@system-suspend-devices:
- shard-hsw:  [INCOMPLETE][19] ([i915#151] / [i915#61]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-hsw8/igt@i915_pm_...@system-suspend-devices.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-hsw8/igt@i915_pm_...@system-suspend-devices.html

  * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge:
- shard-apl:  [FAIL][21] ([i915#70] / [i915#95]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-apl4/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17837/shard-apl8/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html

  * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk:  [DMESG-WARN][23] ([i915#1926]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8568/shard-glk9/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
   [24]: 

[Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 448 +
 1 file changed, 448 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..5274e2c83 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,439 @@ static void measure_semaphore_power(int i915)
rapl_close();
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   while (offset_in_page(cs) & 63)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   /* Delay between SRM and COND_BBE to post the writes */
+   for (int n = 0; n < 8; n++) {
+   *cs++ = MI_STORE_DWORD_IMM;
+   *cs++ = addr + 4064;
+   *cs++ = addr >> 32;
+   *cs++ = 0;
+   }
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + 

[Intel-gfx] [PATCH i-g-t 2/2] HAX:fair

2020-06-02 Thread Chris Wilson
---
 tests/intel-ci/fast-feedback.testlist | 163 +-
 1 file changed, 3 insertions(+), 160 deletions(-)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index 04f6affcf..9cf460894 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -1,162 +1,5 @@
 # Keep alphabetically sorted by default
 
-igt@core_auth@basic-auth
-igt@debugfs_test@read_all_entries
-igt@fbdev@mmap
-igt@gem_basic@bad-close
-igt@gem_basic@create-close
-igt@gem_basic@create-fd-close
-igt@gem_busy@busy@all
-igt@gem_close_race@basic-process
-igt@gem_close_race@basic-threads
-igt@gem_ctx_create@basic
-igt@gem_ctx_create@basic-files
-igt@gem_ctx_exec@basic
-igt@gem_exec_basic@basic
-igt@gem_exec_create@basic
-igt@gem_exec_fence@basic-busy
-igt@gem_exec_fence@basic-wait
-igt@gem_exec_fence@basic-await
-igt@gem_exec_fence@nb-await
-igt@gem_exec_gttfill@basic
-igt@gem_exec_parallel@engines
-igt@gem_exec_store@basic
-igt@gem_exec_suspend@basic-s0
-igt@gem_exec_suspend@basic-s3
-igt@gem_flink_basic@bad-flink
-igt@gem_flink_basic@bad-open
-igt@gem_flink_basic@basic
-igt@gem_flink_basic@double-flink
-igt@gem_flink_basic@flink-lifetime
-igt@gem_linear_blits@basic
-igt@gem_mmap@basic
-igt@gem_mmap_gtt@basic
-igt@gem_render_linear_blits@basic
-igt@gem_render_tiled_blits@basic
-igt@gem_ringfill@basic-all
-igt@gem_sync@basic-all
-igt@gem_sync@basic-each
-igt@gem_tiled_blits@basic
-igt@gem_tiled_fence_blits@basic
-igt@gem_tiled_pread_basic
-igt@gem_wait@busy@all
-igt@gem_wait@wait@all
-igt@i915_getparams_basic@basic-eu-total
-igt@i915_getparams_basic@basic-subslice-total
-igt@i915_hangman@error-state-basic
-igt@kms_addfb_basic@addfb25-bad-modifier
-igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling
-igt@kms_addfb_basic@addfb25-modifier-no-flag
-igt@kms_addfb_basic@addfb25-x-tiled
-igt@kms_addfb_basic@addfb25-x-tiled-mismatch
-igt@kms_addfb_basic@addfb25-yf-tiled
-igt@kms_addfb_basic@addfb25-y-tiled
-igt@kms_addfb_basic@addfb25-y-tiled-small
-igt@kms_addfb_basic@bad-pitch-0
-igt@kms_addfb_basic@bad-pitch-1024
-igt@kms_addfb_basic@bad-pitch-128
-igt@kms_addfb_basic@bad-pitch-256
-igt@kms_addfb_basic@bad-pitch-32
-igt@kms_addfb_basic@bad-pitch-63
-igt@kms_addfb_basic@bad-pitch-65536
-igt@kms_addfb_basic@bad-pitch-999
-igt@kms_addfb_basic@basic
-igt@kms_addfb_basic@basic-x-tiled
-igt@kms_addfb_basic@basic-y-tiled
-igt@kms_addfb_basic@bo-too-small
-igt@kms_addfb_basic@bo-too-small-due-to-tiling
-igt@kms_addfb_basic@clobberred-modifier
-igt@kms_addfb_basic@framebuffer-vs-set-tiling
-igt@kms_addfb_basic@invalid-get-prop
-igt@kms_addfb_basic@invalid-get-prop-any
-igt@kms_addfb_basic@invalid-set-prop
-igt@kms_addfb_basic@invalid-set-prop-any
-igt@kms_addfb_basic@no-handle
-igt@kms_addfb_basic@size-max
-igt@kms_addfb_basic@small-bo
-igt@kms_addfb_basic@tile-pitch-mismatch
-igt@kms_addfb_basic@too-high
-igt@kms_addfb_basic@too-wide
-igt@kms_addfb_basic@unused-handle
-igt@kms_addfb_basic@unused-modifier
-igt@kms_addfb_basic@unused-offsets
-igt@kms_addfb_basic@unused-pitches
-igt@kms_busy@basic
-igt@kms_chamelium@dp-hpd-fast
-igt@kms_chamelium@dp-edid-read
-igt@kms_chamelium@dp-crc-fast
-igt@kms_chamelium@hdmi-hpd-fast
-igt@kms_chamelium@hdmi-edid-read
-igt@kms_chamelium@hdmi-crc-fast
-igt@kms_chamelium@vga-hpd-fast
-igt@kms_chamelium@vga-edid-read
-igt@kms_chamelium@common-hpd-after-suspend
-igt@kms_prop_blob@basic
-igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic
-igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy
-igt@kms_cursor_legacy@basic-flip-after-cursor-atomic
-igt@kms_cursor_legacy@basic-flip-after-cursor-legacy
-igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size
-igt@kms_cursor_legacy@basic-flip-before-cursor-atomic
-igt@kms_cursor_legacy@basic-flip-before-cursor-legacy
-igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size
-igt@kms_flip@basic-flip-vs-dpms
-igt@kms_flip@basic-flip-vs-modeset
-igt@kms_flip@basic-flip-vs-wf_vblank
-igt@kms_flip@basic-plain-flip
-igt@kms_force_connector_basic@force-connector-state
-igt@kms_force_connector_basic@force-edid
-igt@kms_force_connector_basic@force-load-detect
-igt@kms_force_connector_basic@prune-stale-modes
-igt@kms_frontbuffer_tracking@basic
-igt@kms_pipe_crc_basic@hang-read-crc-pipe-a
-igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a
-igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence
-igt@kms_pipe_crc_basic@read-crc-pipe-a
-igt@kms_pipe_crc_basic@read-crc-pipe-b
-igt@kms_pipe_crc_basic@read-crc-pipe-c
-igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence
-igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
-igt@kms_psr@primary_page_flip
-igt@kms_psr@cursor_plane_move
-igt@kms_psr@sprite_plane_onoff
-igt@kms_psr@primary_mmap_gtt
-igt@kms_setmode@basic-clone-single-crtc
-igt@i915_pm_backlight@basic-brightness
-igt@i915_pm_rpm@basic-pci-d3-state
-igt@i915_pm_rpm@basic-rte
-igt@i915_pm_rps@basic-api
-igt@prime_self_import@basic-llseek-bad

[Intel-gfx] [PATCH] drm/i915/gt: Make the CTX_TIMESTAMP readable on !rcs

2020-06-02 Thread Chris Wilson
For reasons that be, the HW only allows usersace to read its own
CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for
all by adding it to the whitelists.

Signed-off-by: Chris Wilson 
---
This probably means the change occurred in the glk/cfl timeframe...
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 94d66a9d760d..7afe5792d68c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1253,9 +1253,15 @@ static void icl_whitelist_build(struct intel_engine_cs 
*engine)
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
  RING_FORCE_TO_NONPRIV_ACCESS_RD);
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
 
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
@@ -1287,6 +1293,9 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
whitelist_reg(w, HIZ_CHICKEN);
break;
default:
+   whitelist_reg_ext(w,
+ RING_CTX_TIMESTAMP(engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
}
 }
-- 
2.20.1

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


[Intel-gfx] [PATCH] drm/malidp: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Daniel Vetter
This is already done as part of the drm_atomic_helper_shutdown(),
and in that case only for the crtc which are actually on.

v2: I overlooked that malidp also needs to have it's interrupt shut
down reordered.

Signed-off-by: Daniel Vetter 
Cc: Liviu Dudau 
Cc: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 02904392e370..cdb817a7c611 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -928,11 +928,10 @@ static void malidp_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
-   drm_crtc_vblank_off(>crtc);
+   drm_atomic_helper_shutdown(drm);
malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
-   drm_atomic_helper_shutdown(drm);
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-- 
2.26.2

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


[Intel-gfx] [PATCH 3/3] drm/hdlcd: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Daniel Vetter
This is already taken care of by drm_atomic_helper_shutdown(), and
in that case only for the CRTC which are actually on.

Only tricky bit here is that we kill the interrupt handling before we
shut down crtc, so need to reorder that.

Signed-off-by: Daniel Vetter 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc:
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 194419f47c5e..26bc5d7766f5 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -347,9 +347,8 @@ static void hdlcd_drm_unbind(struct device *dev)
of_node_put(hdlcd->crtc.port);
hdlcd->crtc.port = NULL;
pm_runtime_get_sync(dev);
-   drm_crtc_vblank_off(>crtc);
-   drm_irq_uninstall(drm);
drm_atomic_helper_shutdown(drm);
+   drm_irq_uninstall(drm);
pm_runtime_put(dev);
if (pm_runtime_enabled(dev))
pm_runtime_disable(dev);
-- 
2.26.2

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


[Intel-gfx] [PATCH 1/3] drm/atomic-helper: reset vblank on crtc reset

2020-06-02 Thread Daniel Vetter
Only when vblanks are supported ofc.

Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve this once
and for all in shared helper code.

Aside from moving the few existing calls to drm_crtc_vblank_reset into
helpers (i915 doesn't use helpers, so keeps its own) I think the
regression risk is minimal: atomic helpers already rely on drivers
calling drm_crtc_vblank_on/off correctly in their hooks when they
support vblanks. And driver that's failing to handle vblanks after
this is missing those calls already, and vblanks could only work by
accident when enabling a CRTC for the first time right after boot.

Big thanks to Tetsuo for helping track down what's going wrong here.

There's only a few drivers which already had the necessary call and
needed some updating:
- komeda, atmel and tidss also needed to be changed to call
  __drm_atomic_helper_crtc_reset() intead of open coding it
- tegra and msm even had it in the same place already, just code
  motion, and malidp already uses __drm_atomic_helper_crtc_reset().

Only call left is in i915, which doesn't use drm_mode_config_reset,
but has its own fastboot infrastructure. So that's the only case where
we actually want this in the driver still.

I've also reviewed all other drivers which set up vblank support with
drm_vblank_init. After the previous patch fixing mxsfb all atomic
drivers do call drm_crtc_vblank_on/off as they should, the remaining
drivers are either legacy kms or legacy dri1 drivers, so not affected
by this change to atomic helpers.

v2: Use the drm_dev_has_vblank() helper.

v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
instead of drm_crtc_vblank_reset. Adjust them too.

Cc: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Boris Brezillon 
Acked-by: Liviu Dudau 
Acked-by: Thierry Reding 
Link: 
https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Reported-by: Tetsuo Handa 
Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
Cc: Tetsuo Handa 
Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
Cc: Mihail Atanassov 
Cc: Brian Starkey 
Cc: Sam Ravnborg 
Cc: Boris Brezillon 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: Brian Masney 
Cc: Emil Velikov 
Cc: zhengbin 
Cc: Thomas Gleixner 
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
 drivers/gpu/drm/arm/malidp_drv.c | 1 -
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
 drivers/gpu/drm/drm_atomic_state_helper.c| 4 
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
 drivers/gpu/drm/omapdrm/omap_drv.c   | 3 ---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 3 ---
 drivers/gpu/drm/tegra/dc.c   | 1 -
 drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
 drivers/gpu/drm/tidss/tidss_kms.c| 4 
 10 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 56bd938961ee..f33418d6e1a0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
crtc->state = NULL;
 
state = kzalloc(sizeof(*state), GFP_KERNEL);
-   if (state) {
-   crtc->state = >base;
-   crtc->state->crtc = crtc;
-   }
+   if (state)
+   __drm_atomic_helper_crtc_reset(crtc, >base);
 }
 
 static struct drm_crtc_state *
@@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
return err;
 
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   drm_crtc_vblank_reset(crtc);
 
crtc->port = kcrtc->master->of_output_port;
 
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c2507b7d8512..02904392e370 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
drm->irq_enabled = true;
 
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
-   drm_crtc_vblank_reset(>crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
goto vblank_fail;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 10985134ce0b..ce246b96330b 100644
--- 

[Intel-gfx] [PATCH 2/3] drm/malidp: Don't call drm_crtc_vblank_off on unbind

2020-06-02 Thread Daniel Vetter
This is already done as part of the drm_atomic_helper_shutdown(),
and in that case only for the crtc which are actually on.

Signed-off-by: Daniel Vetter 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc:
---
 drivers/gpu/drm/arm/malidp_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 02904392e370..db6ba5c78042 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -928,7 +928,6 @@ static void malidp_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
-   drm_crtc_vblank_off(>crtc);
malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
-- 
2.26.2

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


Re: [Intel-gfx] [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

2020-06-02 Thread Maarten Lankhorst
Op 12-05-2020 om 11:08 schreef Christian König:
> Am 12.05.20 um 10:59 schrieb Daniel Vetter:
>> But only for non-zero timeout, to avoid false positives.
>>
>> One question here is whether the might_sleep should be unconditional,
>> or only for real timeouts. I'm not sure, so went with the more
>> defensive option. But in the interest of locking down the cross-driver
>> dma_fence rules we might want to be more aggressive.
>>
>> Cc: linux-me...@vger.kernel.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-r...@vger.kernel.org
>> Cc: amd-...@lists.freedesktop.org
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: Chris Wilson 
>> Cc: Maarten Lankhorst 
>> Cc: Christian König 
>> Signed-off-by: Daniel Vetter 
>> ---
>>   drivers/dma-buf/dma-fence.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 052a41e2451c..6802125349fb 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -208,6 +208,9 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool 
>> intr, signed long timeout)
>>   if (WARN_ON(timeout < 0))
>>   return -EINVAL;
>>   +    if (timeout > 0)
>> +    might_sleep();
>> +
>
> I would rather like to see might_sleep() called here all the time even with 
> timeout==0.
>
> IIRC I removed the code in TTM abusing this in atomic context quite a while 
> ago, but could be that some leaked in again or it is called in atomic context 
> elsewhere as well. 


Same, glad I'm not the only one who wants it. :)

~Maarten

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


Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

2020-06-02 Thread Daniel Vetter
On Sat, May 30, 2020 at 06:22:58AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> Thank you for the patch.
> 
> On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> > 
> > Some drivers do this already, but most unfortunately missed it. This
> > opens up bugs after driver load, before the crtc is enabled for the
> > first time. syzbot spotted this when loading vkms as a secondary
> > output. Given how many drivers are buggy it's best to solve this once
> > and for all in shared helper code.
> > 
> > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > regression risk is minimal: atomic helpers already rely on drivers
> > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > support vblanks. And driver that's failing to handle vblanks after
> > this is missing those calls already, and vblanks could only work by
> > accident when enabling a CRTC for the first time right after boot.
> > 
> > Big thanks to Tetsuo for helping track down what's going wrong here.
> > 
> > There's only a few drivers which already had the necessary call and
> > needed some updating:
> > - komeda, atmel and tidss also needed to be changed to call
> >   __drm_atomic_helper_crtc_reset() intead of open coding it
> > - tegra and msm even had it in the same place already, just code
> >   motion, and malidp already uses __drm_atomic_helper_crtc_reset().
> 
> Have you intentionally not touched drivers that use
> drm_crtc_vblank_off() at init time instead of drm_crtc_vblank_reset() ?
> I'm thinking about omapdrm and rcar-du that both call neither
> drm_crtc_vblank_reset() nor __drm_atomic_helper_crtc_reset() in their
> CRTC reset handler, and call drm_crtc_vblank_off() at init time. Should
> these (and likely other) drivers be updated ?

Good catch, I think we should remove those too with this patch.

I also used that opportunity to review all callers fo drm_crtc_vblank_off,
and I found two bogus callers in malidp and hdlcd. But only in the unload
code, so doesn't matter much.

I'll resend a new version.
-Daniel

> Other than that the patch looks good to me,
> 
> Reviewed-by: Laurent Pinchart 
> 
> > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > but has its own fastboot infrastructure. So that's the only case where
> > we actually want this in the driver still.
> > 
> > I've also reviewed all other drivers which set up vblank support with
> > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > by this change to atomic helpers.
> > 
> > v2: Use the drm_dev_has_vblank() helper.
> > 
> > Link: 
> > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > Reported-by: Tetsuo Handa 
> > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > Cc: Tetsuo Handa 
> > Cc: "James (Qian) Wang" 
> > Cc: Liviu Dudau 
> > Cc: Mihail Atanassov 
> > Cc: Brian Starkey 
> > Cc: Sam Ravnborg 
> > Cc: Boris Brezillon 
> > Cc: Nicolas Ferre 
> > Cc: Alexandre Belloni 
> > Cc: Ludovic Desroches 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Thierry Reding 
> > Cc: Jonathan Hunter 
> > Cc: Jyri Sarha 
> > Cc: Tomi Valkeinen 
> > Cc: Rob Clark 
> > Cc: Sean Paul 
> > Cc: Brian Masney 
> > Cc: Emil Velikov 
> > Cc: zhengbin 
> > Cc: Thomas Gleixner 
> > Cc: linux-te...@vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> >  drivers/gpu/drm/arm/malidp_drv.c | 1 -
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
> >  drivers/gpu/drm/drm_atomic_state_helper.c| 4 
> >  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> >  drivers/gpu/drm/tegra/dc.c   | 1 -
> >  drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
> >  drivers/gpu/drm/tidss/tidss_kms.c| 4 
> >  8 files changed, 9 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 56bd938961ee..f33418d6e1a0 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> > crtc->state = NULL;
> >  
> > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > -   if (state) {
> > -   crtc->state = >base;
> > -   crtc->state->crtc = crtc;
> > -   }
> > +   if (state)
> > +   __drm_atomic_helper_crtc_reset(crtc, >base);
> >  }
> >  
> >  static struct drm_crtc_state *
> > @@ -616,7 +614,6 @@ static int 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Chris Wilson
Quoting Mika Kuoppala (2020-06-02 10:18:34)
> Chris Wilson  writes:
> 
> > An important property for multi-client systems is that each client gets
> > a 'fair' allotment of system time. (Where fairness is at the whim of the
> > context properties, such as priorities.) This test forks N independent
> > clients (albeit they happen to share a single vm), and does an equal
> > amount of work in client and asserts that they take an equal amount of
> > time.
> >
> > Though we have never claimed to have a completely fair scheduler, that
> > is what is expected.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Ramalingam C 
> > ---
> >  tests/i915/gem_exec_schedule.c | 418 +
> >  1 file changed, 418 insertions(+)
> >
> > diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> > index 56c638833..d1121ecd2 100644
> > --- a/tests/i915/gem_exec_schedule.c
> > +++ b/tests/i915/gem_exec_schedule.c
> > @@ -2495,6 +2495,417 @@ static void measure_semaphore_power(int i915)
> >   rapl_close();
> >  }
> >  
> > +static int read_timestamp_frequency(int i915)
> > +{
> > + int value = 0;
> > + drm_i915_getparam_t gp = {
> > + .value = ,
> > + .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
> > + };
> > + ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
> > + return value;
> > +}
> > +
> > +static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
> > +{
> > + return (x + y - 1) / y;
> > +}
> > +
> > +static uint64_t ns_to_ticks(int i915, uint64_t ns)
> > +{
> > + return div64_u64_round_up(ns * read_timestamp_frequency(i915),
> > +   NSEC_PER_SEC);
> > +}
> > +
> > +static uint64_t ticks_to_ns(int i915, uint64_t ticks)
> > +{
> > + return div64_u64_round_up(ticks * NSEC_PER_SEC,
> > +   read_timestamp_frequency(i915));
> > +}
> > +
> > +#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
> > +
> > +#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
> > +#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | 
> > (op2))
> > +/* Opcodes for MI_MATH_INSTR */
> > +#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
> > +#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
> > +#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
> > +#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
> > +#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
> > +#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
> > +#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
> > +#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
> > +#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
> > +#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
> > +#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
> > +#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
> > +/* Registers used as operands in MI_MATH_INSTR */
> > +#define   MI_MATH_REG(x)(x)
> > +#define   MI_MATH_REG_SRCA  0x20
> > +#define   MI_MATH_REG_SRCB  0x21
> > +#define   MI_MATH_REG_ACCU  0x31
> > +#define   MI_MATH_REG_ZF0x32
> > +#define   MI_MATH_REG_CF0x33
> 
> Are you thinking that we should just pull in the driver gpu_commands.h
> as is into lib?

Yes. We should at least share the header for mi commands between the
kernel and igt.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Mika Kuoppala
Chris Wilson  writes:

> An important property for multi-client systems is that each client gets
> a 'fair' allotment of system time. (Where fairness is at the whim of the
> context properties, such as priorities.) This test forks N independent
> clients (albeit they happen to share a single vm), and does an equal
> amount of work in client and asserts that they take an equal amount of
> time.
>
> Though we have never claimed to have a completely fair scheduler, that
> is what is expected.
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Ramalingam C 
> ---
>  tests/i915/gem_exec_schedule.c | 418 +
>  1 file changed, 418 insertions(+)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 56c638833..d1121ecd2 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -2495,6 +2495,417 @@ static void measure_semaphore_power(int i915)
>   rapl_close();
>  }
>  
> +static int read_timestamp_frequency(int i915)
> +{
> + int value = 0;
> + drm_i915_getparam_t gp = {
> + .value = ,
> + .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
> + };
> + ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
> + return value;
> +}
> +
> +static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
> +{
> + return (x + y - 1) / y;
> +}
> +
> +static uint64_t ns_to_ticks(int i915, uint64_t ns)
> +{
> + return div64_u64_round_up(ns * read_timestamp_frequency(i915),
> +   NSEC_PER_SEC);
> +}
> +
> +static uint64_t ticks_to_ns(int i915, uint64_t ticks)
> +{
> + return div64_u64_round_up(ticks * NSEC_PER_SEC,
> +   read_timestamp_frequency(i915));
> +}
> +
> +#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
> +
> +#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
> +#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | 
> (op2))
> +/* Opcodes for MI_MATH_INSTR */
> +#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
> +#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
> +#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
> +#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
> +#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
> +#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
> +#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
> +#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
> +#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
> +#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
> +#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
> +#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
> +/* Registers used as operands in MI_MATH_INSTR */
> +#define   MI_MATH_REG(x)(x)
> +#define   MI_MATH_REG_SRCA  0x20
> +#define   MI_MATH_REG_SRCB  0x21
> +#define   MI_MATH_REG_ACCU  0x31
> +#define   MI_MATH_REG_ZF0x32
> +#define   MI_MATH_REG_CF0x33

Are you thinking that we should just pull in the driver gpu_commands.h
as is into lib?

-Mika

> +
> +#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
> +
> +static void delay(int i915,
> +   const struct intel_execution_engine2 *e,
> +   uint32_t handle,
> +   uint64_t addr,
> +   uint64_t ns)
> +{
> + const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
> + const uint32_t base = gem_engine_mmio_base(i915, e->name);
> +#define CS_GPR(x) (base + 0x600 + 8 * (x))
> +#define TIMESTAMP (base + 0x3a8)
> + enum { START_TS, NOW_TS };
> + uint32_t *map, *cs, *jmp;
> +
> + igt_require(base);
> +
> + cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
> +
> + *cs++ = MI_LOAD_REGISTER_IMM;
> + *cs++ = CS_GPR(START_TS) + 4;
> + *cs++ = 0;
> + *cs++ = MI_LOAD_REGISTER_REG;
> + *cs++ = TIMESTAMP;
> + *cs++ = CS_GPR(START_TS);
> +
> + if (offset_in_page(cs) & 4)
> + *cs++ = 0;
> + jmp = cs;
> +
> + *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
> +
> + *cs++ = MI_LOAD_REGISTER_IMM;
> + *cs++ = CS_GPR(NOW_TS) + 4;
> + *cs++ = 0;
> + *cs++ = MI_LOAD_REGISTER_REG;
> + *cs++ = TIMESTAMP;
> + *cs++ = CS_GPR(NOW_TS);
> +
> + *cs++ = MI_MATH(4);
> + *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
> + *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
> + *cs++ = MI_MATH_SUB;
> + *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
> +
> + *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
> + *cs++ = CS_GPR(NOW_TS);
> + *cs++ = addr + 4000;
> + *cs++ = addr >> 32;
> +
> + *cs++ = MI_COND_BATCH_BUFFER_END | 

Re: [Intel-gfx] [PATCH 03/36] drm/i915/gt: Move legacy context wa to intel_workarounds

2020-06-02 Thread Mika Kuoppala
Chris Wilson  writes:

> Use the central mechanism for recording and verifying that we restore
> the w/a for the older devices as well.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  .../gpu/drm/i915/gt/intel_ring_submission.c   | 28 -
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 31 +++
>  2 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 96881cd8b17b..d9c1701061b9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -429,32 +429,6 @@ static void reset_finish(struct intel_engine_cs *engine)
>  {
>  }
>  
> -static int rcs_resume(struct intel_engine_cs *engine)
> -{
> - struct drm_i915_private *i915 = engine->i915;
> - struct intel_uncore *uncore = engine->uncore;
> -
> - /*
> -  * Disable CONSTANT_BUFFER before it is loaded from the context
> -  * image. For as it is loaded, it is executed and the stored
> -  * address may no longer be valid, leading to a GPU hang.
> -  *
> -  * This imposes the requirement that userspace reload their
> -  * CONSTANT_BUFFER on every batch, fortunately a requirement
> -  * they are already accustomed to from before contexts were
> -  * enabled.
> -  */
> - if (IS_GEN(i915, 4))
> - intel_uncore_write(uncore, ECOSKPD,
> -_MASKED_BIT_ENABLE(ECO_CONSTANT_BUFFER_SR_DISABLE));
> -
> - if (IS_GEN_RANGE(i915, 6, 7))
> - intel_uncore_write(uncore, INSTPM,
> -_MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
> -
> - return xcs_resume(engine);
> -}
> -
>  static void reset_cancel(struct intel_engine_cs *engine)
>  {
>   struct i915_request *request;
> @@ -1139,8 +1113,6 @@ static void setup_rcs(struct intel_engine_cs *engine)
>  
>   if (IS_HASWELL(i915))
>   engine->emit_bb_start = hsw_emit_bb_start;
> -
> - engine->resume = rcs_resume;
>  }
>  
>  static void setup_vcs(struct intel_engine_cs *engine)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index fa1e15657663..94d66a9d760d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -199,6 +199,18 @@ wa_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, 
> u32 val)
>  #define WA_SET_FIELD_MASKED(addr, mask, value) \
>   wa_write_masked_or(wal, (addr), 0, _MASKED_FIELD((mask), (value)))
>  
> +static void gen6_ctx_workarounds_init(struct intel_engine_cs *engine,
> +   struct i915_wa_list *wal)
> +{
> + WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
> +}
> +
> +static void gen7_ctx_workarounds_init(struct intel_engine_cs *engine,
> +   struct i915_wa_list *wal)
> +{
> + WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
> +}
> +
>  static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>  {
> @@ -638,6 +650,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs 
> *engine,
>   chv_ctx_workarounds_init(engine, wal);
>   else if (IS_BROADWELL(i915))
>   bdw_ctx_workarounds_init(engine, wal);
> + else if (IS_GEN(i915, 7))
> + gen7_ctx_workarounds_init(engine, wal);
> + else if (IS_GEN(i915, 6))
> + gen6_ctx_workarounds_init(engine, wal);
>   else if (INTEL_GEN(i915) < 8)
>   return;
>   else
> @@ -1583,6 +1599,21 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>  0, _MASKED_BIT_ENABLE(VS_TIMER_DISPATCH),
>  /* XXX bit doesn't stick on Broadwater */
>  IS_I965G(i915) ? 0 : VS_TIMER_DISPATCH);
> +
> + if (IS_GEN(i915, 4))
> + /*
> +  * Disable CONSTANT_BUFFER before it is loaded from the context
> +  * image. For as it is loaded, it is executed and the stored
> +  * address may no longer be valid, leading to a GPU hang.
> +  *
> +  * This imposes the requirement that userspace reload their
> +  * CONSTANT_BUFFER on every batch, fortunately a requirement
> +  * they are already accustomed to from before contexts were
> +  * enabled.
> +  */
> + wa_add(wal, ECOSKPD,
> +0, _MASKED_BIT_ENABLE(ECO_CONSTANT_BUFFER_SR_DISABLE),
> +0 /* XXX bit doesn't stick on Broadwater */);
>  }
>  
>  static void
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/36] drm/i915/gt: Split low level gen2-7 CS emitters

2020-06-02 Thread Mika Kuoppala
Chris Wilson  writes:

> Pull the routines for writing CS packets out of intel_ring_submission
> into their own files. These are low level operations for building CS
> instructions, rather than the logic for filling the global ring buffer
> with requests, and we will wnat to reuse them outside of this context.

*want.

Acked-by: Mika Kuoppala 

>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Makefile |   2 +
>  drivers/gpu/drm/i915/gt/gen2_engine_cs.c  | 340 +++
>  drivers/gpu/drm/i915/gt/gen2_engine_cs.h  |  38 +
>  drivers/gpu/drm/i915/gt/gen6_engine_cs.c  | 455 ++
>  drivers/gpu/drm/i915/gt/gen6_engine_cs.h  |  39 +
>  drivers/gpu/drm/i915/gt/intel_engine.h|   1 -
>  .../gpu/drm/i915/gt/intel_ring_submission.c   | 832 +-
>  7 files changed, 901 insertions(+), 806 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>  create mode 100644 drivers/gpu/drm/i915/gt/gen2_engine_cs.h
>  create mode 100644 drivers/gpu/drm/i915/gt/gen6_engine_cs.c
>  create mode 100644 drivers/gpu/drm/i915/gt/gen6_engine_cs.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b0da6ea6e3f1..41a27fd5dbc7 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -78,6 +78,8 @@ gt-y += \
>   gt/debugfs_engines.o \
>   gt/debugfs_gt.o \
>   gt/debugfs_gt_pm.o \
> + gt/gen2_engine_cs.o \
> + gt/gen6_engine_cs.o \
>   gt/gen6_ppgtt.o \
>   gt/gen7_renderclear.o \
>   gt/gen8_ppgtt.o \
> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> new file mode 100644
> index ..8d2e85081247
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
> @@ -0,0 +1,340 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +#include "gen2_engine_cs.h"
> +#include "i915_drv.h"
> +#include "intel_engine.h"
> +#include "intel_gpu_commands.h"
> +#include "intel_gt.h"
> +#include "intel_gt_irq.h"
> +#include "intel_ring.h"
> +
> +int gen2_emit_flush(struct i915_request *rq, u32 mode)
> +{
> + unsigned int num_store_dw;
> + u32 cmd, *cs;
> +
> + cmd = MI_FLUSH;
> + num_store_dw = 0;
> + if (mode & EMIT_INVALIDATE)
> + cmd |= MI_READ_FLUSH;
> + if (mode & EMIT_FLUSH)
> + num_store_dw = 4;
> +
> + cs = intel_ring_begin(rq, 2 + 3 * num_store_dw);
> + if (IS_ERR(cs))
> + return PTR_ERR(cs);
> +
> + *cs++ = cmd;
> + while (num_store_dw--) {
> + *cs++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> + *cs++ = intel_gt_scratch_offset(rq->engine->gt,
> + INTEL_GT_SCRATCH_FIELD_DEFAULT);
> + *cs++ = 0;
> + }
> + *cs++ = MI_FLUSH | MI_NO_WRITE_FLUSH;
> +
> + intel_ring_advance(rq, cs);
> +
> + return 0;
> +}
> +
> +int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
> +{
> + u32 cmd, *cs;
> + int i;
> +
> + /*
> +  * read/write caches:
> +  *
> +  * I915_GEM_DOMAIN_RENDER is always invalidated, but is
> +  * only flushed if MI_NO_WRITE_FLUSH is unset.  On 965, it is
> +  * also flushed at 2d versus 3d pipeline switches.
> +  *
> +  * read-only caches:
> +  *
> +  * I915_GEM_DOMAIN_SAMPLER is flushed on pre-965 if
> +  * MI_READ_FLUSH is set, and is always flushed on 965.
> +  *
> +  * I915_GEM_DOMAIN_COMMAND may not exist?
> +  *
> +  * I915_GEM_DOMAIN_INSTRUCTION, which exists on 965, is
> +  * invalidated when MI_EXE_FLUSH is set.
> +  *
> +  * I915_GEM_DOMAIN_VERTEX, which exists on 965, is
> +  * invalidated with every MI_FLUSH.
> +  *
> +  * TLBs:
> +  *
> +  * On 965, TLBs associated with I915_GEM_DOMAIN_COMMAND
> +  * and I915_GEM_DOMAIN_CPU in are invalidated at PTE write and
> +  * I915_GEM_DOMAIN_RENDER and I915_GEM_DOMAIN_SAMPLER
> +  * are flushed at any MI_FLUSH.
> +  */
> +
> + cmd = MI_FLUSH;
> + if (mode & EMIT_INVALIDATE) {
> + cmd |= MI_EXE_FLUSH;
> + if (IS_G4X(rq->i915) || IS_GEN(rq->i915, 5))
> + cmd |= MI_INVALIDATE_ISP;
> + }
> +
> + i = 2;
> + if (mode & EMIT_INVALIDATE)
> + i += 20;
> +
> + cs = intel_ring_begin(rq, i);
> + if (IS_ERR(cs))
> + return PTR_ERR(cs);
> +
> + *cs++ = cmd;
> +
> + /*
> +  * A random delay to let the CS invalidate take effect? Without this
> +  * delay, the GPU relocation path fails as the CS does not see
> +  * the updated contents. Just as important, if we apply the flushes
> +  * to the EMIT_FLUSH branch (i.e. immediately after the relocation
> +  * write and before the invalidate on the next batch), the relocations
> +  * still fail. This implies that is a delay following invalidation
> +  

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Disable pre-parser for rewritten batches

2020-06-02 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2020-06-01 15:56:55)
>> Chris Wilson  writes:
>> 
>> > As we rewrite the batches on the fly to implement the non-preemptible
>> > lock, we need to tell Tigerlake to read the batch afresh each time.
>> > Amusingly, the disable is a part of an arb-check, so we have to be
>> > careful not to include the arbitration point inside our unpreemptible
>> > loop.
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  tests/i915/gem_exec_balancer.c | 13 +
>> >  1 file changed, 9 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/tests/i915/gem_exec_balancer.c 
>> > b/tests/i915/gem_exec_balancer.c
>> > index 026f8347e..0e3b52900 100644
>> > --- a/tests/i915/gem_exec_balancer.c
>> > +++ b/tests/i915/gem_exec_balancer.c
>> > @@ -1350,6 +1350,11 @@ static void __bonded_dual(int i915,
>> >   *out = cycles;
>> >  }
>> >  
>> > +static uint32_t preparser_disable(void)
>> > +{
>> > + return 0x5 << 23 | 1 << 8 | 1; /* preparser masked disable */
>> 
>> there is MI_ARB_CHECK
>> 
>> > +}
>> > +
>> >  static uint32_t sync_from(int i915, uint32_t addr, uint32_t target)
>> >  {
>> >   uint32_t handle = gem_create(i915, 4096);
>> > @@ -1363,14 +1368,14 @@ static uint32_t sync_from(int i915, uint32_t addr, 
>> > uint32_t target)
>> >   *cs++ = 0;
>> >   *cs++ = 0;
>> >  
>> > - *cs++ = MI_NOOP;
>> > + *cs++ = preparser_disable();
>> >   *cs++ = MI_NOOP;
>> >   *cs++ = MI_NOOP;
>> >   *cs++ = MI_NOOP;
>> >  
>> >   /* wait for them to cancel us */
>> >   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
>> > - *cs++ = addr + 16;
>> > + *cs++ = addr + 24;
>> 
>> I must be totally confused about the layout as I can't get
>> the +8. You take one nop out and put one arb check in
>> and everything moves with 8?
>
> It's just skipping over the MI_ARB_CHECK, +4, aligned to the next qword
> because some old habits die hard.

Well that explains it,
Reviewed-by: Mika Kuoppala 

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


[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 442 +
 1 file changed, 442 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..ced9ee571 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,433 @@ static void measure_semaphore_power(int i915)
rapl_close();
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 440 +
 1 file changed, 440 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..911379cad 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,431 @@ static void measure_semaphore_power(int i915)
rapl_close();
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Try to spot unfairness

2020-06-02 Thread Chris Wilson
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 436 +
 1 file changed, 436 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 56c638833..3045eeb62 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -2495,6 +2495,429 @@ static void measure_semaphore_power(int i915)
rapl_close();
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define TIMESTAMP (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(START_TS);
+
+   if (offset_in_page(cs) & 4)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = TIMESTAMP;
+   *cs++ = CS_GPR(NOW_TS);
+
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   *cs++ = 0x24 << 23 | (1 + use_64b); /* SRM */
+   *cs++ = CS_GPR(NOW_TS);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | (1 + use_64b);
+   *cs++ = ~ns_to_ticks(i915, ns);
+   *cs++ = addr + 4000;
+   *cs++ = addr >> 32;
+
+   *cs++ = MI_BATCH_BUFFER_START | 1 << 8 | use_64b;
+   *cs++ = addr + offset_in_page(jmp);
+   *cs++ = addr >> 32;
+
+   munmap(map, 4096);

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-06-02 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77889/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8567_full -> Patchwork_17836_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl7/igt@i915_susp...@forcewake.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-kbl1/igt@i915_susp...@forcewake.html
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#636] / [i915#69])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl1/igt@i915_susp...@forcewake.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl2/igt@i915_susp...@forcewake.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-apl6/igt@i915_susp...@sysfs-reader.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-apl4/igt@i915_susp...@sysfs-reader.html

  * igt@kms_color@pipe-b-degamma:
- shard-hsw:  [PASS][7] -> [INCOMPLETE][8] ([i915#1927] / [i915#61])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-hsw1/igt@kms_co...@pipe-b-degamma.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-hsw1/igt@kms_co...@pipe-b-degamma.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-render:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#49])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-render.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-render.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#1188])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl7/igt@kms_...@bpc-switch.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl5/igt@kms_...@bpc-switch.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

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

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([i915#69])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-skl4/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-skl7/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html

  
 Possible fixes 

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-tglb: [INCOMPLETE][19] ([i915#750]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-tglb7/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-tglb6/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html

  * igt@kms_draw_crc@fill-fb:
- shard-kbl:  [FAIL][21] ([i915#52] / [i915#93] / [i915#95]) -> 
[PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-kbl1/igt@kms_draw_...@fill-fb.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-kbl2/igt@kms_draw_...@fill-fb.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@b-hdmi-a1}:
- shard-hsw:  [INCOMPLETE][23] ([i915#61]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8567/shard-hsw8/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17836/shard-hsw6/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [DMESG-WARN][25] ([i915#180] / [i915#95]) -> 
[PASS][26]