Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Chris Wilson
Quoting Lionel Landwerlin (2019-11-13 18:33:59)
> On 13/11/2019 20:11, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-11-13 18:10:22)
> >> Quoting Lionel Landwerlin (2019-11-13 18:07:59)
> >>> On 13/11/2019 18:35, Chris Wilson wrote:
>  Quoting Lionel Landwerlin (2019-11-13 15:46:39)
> > I'm observing incoherence metric values, changing from run to run.
> >
> > It appears the patches introducing noa wait & reconfiguration from
> > command stream switched places in the series multiple times during the
> > review. This lead to the dependency of one onto the order to go
> > missing...
>  I don't think I dropped it; if I did my apologies. I do feel the
>  egg-on-face for writing a selftest to verify that noa_wait does what you
>  said it did, but completely missing that it went unused :)
> 
> 
> It was probably my mistake :)
> 
> 
> 
> > Signed-off-by: Lionel Landwerlin 
> > Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from 
> > command stream")
> > ---
> >drivers/gpu/drm/i915/i915_perf.c | 9 +++--
> >1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 507236bd41ae..31e47ee23357 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> > *stream,
> >   config_length += num_lri_dwords(oa_config->mux_regs_len);
> >   config_length += 
> > num_lri_dwords(oa_config->b_counter_regs_len);
> >   config_length += num_lri_dwords(oa_config->flex_regs_len);
> > -   config_length++; /* MI_BATCH_BUFFER_END */
> > +   config_length += 3; /* MI_BATCH_BUFFER_START */
> >   config_length = ALIGN(sizeof(u32) * config_length, 
> > I915_GTT_PAGE_SIZE);
> >
> >   obj = i915_gem_object_create_shmem(stream->perf->i915, 
> > config_length);
> > @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> > *stream,
> >oa_config->flex_regs,
> >oa_config->flex_regs_len);
> >
> > -   *cs++ = MI_BATCH_BUFFER_END;
> > +   /* Jump into the active wait. */
> > +   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
> > +MI_BATCH_BUFFER_START :
> > +MI_BATCH_BUFFER_START_GEN8);
> > +   *cs++ = i915_ggtt_offset(stream->noa_wait);
> > +   *cs++ = 0;
>  Yikes, stream->noa_wait is unused.
> 
>  Hmm, the noa_wait doesn't have any arbitration points internally, so we
>  probably do need to make it non-preemptable as well?
> 
>  With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
>  Reviewed-by: Chris Wilson 
> 
>  We need to wrap emit_oa_config() in a similar selftest and verify
>  that a read of the oa regs are correct and that the TIMESTAMP indicates
>  the appropriate delay before the read. If you feel bored.
>  -Chris
> >>>
> >>> As long as we wait long enough, it should be okay.
> >>>
> >>> Why making it nopreempt?
> >> Aiui, the batch buffer has no arbitration points so the delay may incur
> >> the wrath of the forced preemption. That is another request (of higher
> >> priority) wishing to run, but not being able to.
> > The alternative would be adding a MI_ARB_CHECK at the start of the loop
> > if you happy with being preempted out.
> > -Chris
> 
> I guess I'll do that :)

Ok, then have an 
Reviewed-by: Chris Wilson 
on the understanding you'll look at adding an MI_ARB_CHECK next :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [bug report] drm/i915: Initial selftests for exercising eviction

2019-11-13 Thread Chris Wilson
Quoting Dan Carpenter (2019-11-14 06:54:37)
> Hello Chris Wilson,
> 
> The patch f40a7b7558ef: "drm/i915: Initial selftests for exercising
> eviction" from Feb 13, 2017, leads to the following static checker
> warning:
> 
> drivers/gpu/drm/i915/selftests/i915_gem_evict.c:202 igt_overcommit()
> warn: passing zero to 'PTR_ERR'
> 
> drivers/gpu/drm/i915/selftests/i915_gem_evict.c
>190  goto cleanup;
>191  
>192  obj = i915_gem_object_create_internal(gt->i915, 
> I915_GTT_PAGE_SIZE);
>193  if (IS_ERR(obj)) {
>194  err = PTR_ERR(obj);
>195  goto cleanup;
>196  }
>197  
>198  quirk_add(obj, );
>199  
>200  vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
>201  if (!IS_ERR(vma) || PTR_ERR(vma) != -ENOSPC) {
> 
> Is this reversed?

No, the setup is supposed to force the pin() to fail with ENOSPC.

if (vma != ERR_PTR(-ENOSPC))

would be a clearer way to write it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [bug report] drm/i915: Initial selftests for exercising eviction

2019-11-13 Thread Dan Carpenter
Hello Chris Wilson,

The patch f40a7b7558ef: "drm/i915: Initial selftests for exercising
eviction" from Feb 13, 2017, leads to the following static checker
warning:

drivers/gpu/drm/i915/selftests/i915_gem_evict.c:202 igt_overcommit()
warn: passing zero to 'PTR_ERR'

drivers/gpu/drm/i915/selftests/i915_gem_evict.c
   190  goto cleanup;
   191  
   192  obj = i915_gem_object_create_internal(gt->i915, 
I915_GTT_PAGE_SIZE);
   193  if (IS_ERR(obj)) {
   194  err = PTR_ERR(obj);
   195  goto cleanup;
   196  }
   197  
   198  quirk_add(obj, );
   199  
   200  vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
   201  if (!IS_ERR(vma) || PTR_ERR(vma) != -ENOSPC) {

Is this reversed?

   202  pr_err("Failed to evict+insert, 
i915_gem_object_ggtt_pin returned err=%d\n", (int)PTR_ERR(vma));

 ^

   203  err = -EINVAL;
   204  goto cleanup;
   205  }
   206  
   207  cleanup:
   208  cleanup_objects(ggtt, );
   209  return err;
   210  }


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: don't forget noa wait after oa config
URL   : https://patchwork.freedesktop.org/series/69409/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7331_full -> Patchwork_15250_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) 
+4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-iclb3/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_ctx_switch@all-light:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([fdo#111672])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb4/igt@gem_ctx_swi...@all-light.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb6/igt@gem_ctx_swi...@all-light.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#112081])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb5/igt@gem_...@in-flight-contexts-immediate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb6/igt@gem_...@in-flight-contexts-immediate.html

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

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-blt:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111606] / 
[fdo#111677])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb2/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html

  * igt@gem_exec_schedule@promotion-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-iclb7/igt@gem_exec_sched...@promotion-bsd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-iclb1/igt@gem_exec_sched...@promotion-bsd.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([fdo#111832])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb9/igt@gem_exec_susp...@basic-s0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb3/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-snb:  [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-snb2/igt@gem_userptr_bl...@dmabuf-sync.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-snb6/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-hsw:  [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-hsw5/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-hsw5/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111832] / 
[fdo#111850]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb6/igt@gem_workarou...@suspend-resume-context.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb5/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_selftest@live_gt_timelines:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111831])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb9/igt@i915_selftest@live_gt_timelines.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-tglb7/igt@i915_selftest@live_gt_timelines.html

  * igt@i915_selftest@live_perf:
- shard-hsw:  [PASS][23] -> [INCOMPLETE][24] ([fdo#103540])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-hsw4/igt@i915_selftest@live_perf.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/shard-hsw1/igt@i915_selftest@live_perf.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][25] -> [DMESG-WARN][26] ([fdo#108566]) +6 
similar issues
   [25]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Invalidate as we write the gen7 breadcrumb

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Invalidate as we write the gen7 breadcrumb
URL   : https://patchwork.freedesktop.org/series/69408/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7331_full -> Patchwork_15249_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-s3:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([fdo#111832])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb7/igt@gem_ctx_isolat...@vcs1-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-tglb1/igt@gem_ctx_isolat...@vcs1-s3.html

  * igt@gem_ctx_persistence@vcs1-cleanup:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) 
+2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-iclb4/igt@gem_ctx_persiste...@vcs1-cleanup.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-iclb6/igt@gem_ctx_persiste...@vcs1-cleanup.html

  * igt@gem_eio@in-flight-suspend:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111832] / 
[fdo#111850] / [fdo#112081])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb6/igt@gem_...@in-flight-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-tglb8/igt@gem_...@in-flight-suspend.html

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

  * igt@gem_exec_schedule@preempt-queue-blt:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111677]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb1/igt@gem_exec_sched...@preempt-queue-blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-tglb6/igt@gem_exec_sched...@preempt-queue-blt.html

  * igt@gem_exec_schedule@promotion-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-iclb7/igt@gem_exec_sched...@promotion-bsd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-iclb1/igt@gem_exec_sched...@promotion-bsd.html

  * igt@gem_softpin@noreloc-s3:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / 
[fdo#109100])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-iclb7/igt@gem_soft...@noreloc-s3.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-iclb3/igt@gem_soft...@noreloc-s3.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-snb:  [PASS][15] -> [DMESG-WARN][16] ([fdo#111870])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-snb2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html

  * igt@gem_userptr_blits@sync-unmap:
- shard-hsw:  [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-hsw4/igt@gem_userptr_bl...@sync-unmap.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-hsw5/igt@gem_userptr_bl...@sync-unmap.html

  * igt@gem_workarounds@suspend-resume:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111832] / 
[fdo#111850]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb7/igt@gem_workarou...@suspend-resume.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-tglb5/igt@gem_workarou...@suspend-resume.html

  * igt@i915_pm_rpm@system-suspend:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111747] / 
[fdo#111850])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-tglb4/igt@i915_pm_...@system-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-tglb2/igt@i915_pm_...@system-suspend.html

  * igt@i915_selftest@live_hangcheck:
- shard-hsw:  [PASS][23] -> [DMESG-FAIL][24] ([fdo#111991])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/shard-hsw4/igt@i915_selftest@live_hangcheck.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/shard-hsw6/igt@i915_selftest@live_hangcheck.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][25] -> [DMESG-WARN][26] ([fdo#108566]) +3 
similar issues
   [25]: 

[Intel-gfx] [PULL] drm-intel-fixes

2019-11-13 Thread Rodrigo Vivi
Hi Dave and Daniel,

Here goes drm-intel-fixes-2019-11-13:

- MOCS table fixes for EHL and TGL
- Update Display's rawclock on resume
- GVT's dmabuf reference drop fix

Thanks,
Rodrigo.

The following changes since commit 31f4f5b495a62c9a8b15b1c3581acd5efeb9af8c:

  Linux 5.4-rc7 (2019-11-10 16:17:15 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-11-13

for you to fetch changes up to 1c602006d1dcb7501ae1c569fdabe1b8e1f082a4:

  drm/i915/tgl: MOCS table update (2019-11-13 13:23:12 -0800)


- MOCS table fixes for EHL and TGL
- Update Display's rawclock on resume
- GVT's dmabuf reference drop fix


Jani Nikula (1):
  drm/i915: update rawclk also on resume

Matt Roper (2):
  Revert "drm/i915/ehl: Update MOCS table for EHL"
  drm/i915/tgl: MOCS table update

Pan Bian (1):
  drm/i915/gvt: fix dropping obj reference twice

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2019-11-12' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

 drivers/gpu/drm/i915/display/intel_display_power.c |  3 +++
 drivers/gpu/drm/i915/gt/intel_mocs.c   | 10 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  |  4 ++--
 drivers/gpu/drm/i915/i915_drv.c|  3 ---
 4 files changed, 6 insertions(+), 14 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/tgl: Wa_1606679103 (rev2)

2019-11-13 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/tgl: Wa_1606679103 (rev2)
URL   : https://patchwork.freedesktop.org/series/69420/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7341 -> Patchwork_15255


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@busy-all:
- fi-bsw-kefka:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-bsw-kefka/igt@gem_b...@busy-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-bsw-kefka/igt@gem_b...@busy-all.html
- fi-bsw-nick:[PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-bsw-nick/igt@gem_b...@busy-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-bsw-nick/igt@gem_b...@busy-all.html

  * igt@i915_selftest@live_sanitycheck:
- fi-skl-lmem:[PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-skl-lmem/igt@i915_selftest@live_sanitycheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-skl-lmem/igt@i915_selftest@live_sanitycheck.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-dsi: [DMESG-WARN][7] -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-icl-dsi/igt@gem_ba...@create-close.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-icl-dsi/igt@gem_ba...@create-close.html

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [DMESG-WARN][9] ([fdo#112260]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [FAIL][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-kbl-7560u/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gem_contexts:
- fi-bsw-kefka:   [INCOMPLETE][13] ([fdo# 111542]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-bsw-kefka/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r:   [DMESG-FAIL][15] ([fdo#111991]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html

  * igt@kms_busy@basic-flip-pipe-b:
- fi-skl-6770hq:  [DMESG-WARN][17] ([fdo#105541]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7341/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15255/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html

  
 Warnings 

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

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

  [fdo# 111542]: https://bugs.freedesktop.org/show_bug.cgi?id= 111542
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
  [fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260



[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix a bug calling sleep function in atomic context (rev4)

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix a bug calling sleep function in atomic context (rev4)
URL   : https://patchwork.freedesktop.org/series/69385/
State : failure

== Summary ==

Applying: drm/i915: Fix a bug calling sleep function in atomic context
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_gpu_error.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

___
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/fbdev: Fallback to non tiled mode if all tiles not present (rev3)

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/fbdev: Fallback to non tiled mode if all tiles not present (rev3)
URL   : https://patchwork.freedesktop.org/series/68838/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7340 -> Patchwork_15254


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#108840])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([fdo#106107])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-icl-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-icl-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][7] -> [WARN][8] ([fdo#112252])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@gem_busy@busy-all:
- fi-bsw-n3050:   [FAIL][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-bsw-n3050/igt@gem_b...@busy-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-bsw-n3050/igt@gem_b...@busy-all.html

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [INCOMPLETE][11] ([fdo#109964] / [fdo#110343]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [DMESG-FAIL][13] ([fdo#108511]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
- fi-skl-lmem:[DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7340/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15254/fi-skl-lmem/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#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (51 -> 45)
--

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


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7340 -> Patchwork_15254

  CI-20190529: 20190529
  CI_DRM_7340: e6ce7decbb7b0385ef311876f6c224f0f125d71f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5279: 828d2e6c0ee1ebdb41b5ccb99635d50d80e1ae13 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15254: 1c82cd0b9630aa2196806963cdb172abc67751be @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1c82cd0b9630 drm/fbdev: Fallback to non tiled mode if all tiles not present

== Logs ==

For more details see: 

[Intel-gfx] drm-next + i915 CVE yolo merge

2019-11-13 Thread Dave Airlie
The landing of the i915 CVE fixes into Linus tree has created a bit of
a mess in linux-next and downstream in drm-next trees.

I talked to Daniel and he had talked to Joonas a bit, and I decided to
go with what Daniel describes as the YOLO merge, where I just solve it
and pray, and everyone else verifies/fixes it.

In my favour I've been reading these patches for a couple of months
now and applied them to a lot of places, so I'm quite familiar with
what they are doing.

The worst culprit was the RC6 ctx corruption fix since the whole of
rc6 got refactored in next. However I also had access to a version of
this patch Jon wrote on drm-tip a couple of weeks ago.

I took that patch, applied it and fixed it up on top of drm-next. Then
I backmerged the commit that also went into Linus' tree. Then I
removed any evidence of the RC6 patch from Linus' tree and left the
newer version pieces in place. The other stuff mostly merged fine and
the results looked fine, but I'd definitely think everyone at Intel
should be staring at it, and my dinq tip resolutions ASAP and
hopefully it goes into CI and comes out smelling of something good.

Let me know if it's all horrible asap,
Thanks,
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Change .crtc_enable/disable() calling convention

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:15:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Just pass the atomic state+crtc to the .crtc_enable()
> .crtc_disable(). Life is easier when you don't have to think
> whether to pass the old or the new crtc state.
> 
> Signed-off-by: Ville Syrjälä 

makes total sens and indeed easier life,

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 58 +++-
>  drivers/gpu/drm/i915/i915_drv.h  |  8 +--
>  2 files changed, 37 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 11953fe06488..96eafd51296c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6460,10 +6460,11 @@ static void intel_disable_primary_plane(const struct 
> intel_crtc_state *crtc_stat
>   plane->disable_plane(plane, crtc_state);
>  }
>  
> -static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
> -  struct intel_atomic_state *state)
> +static void ironlake_crtc_enable(struct intel_atomic_state *state,
> +  struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe;
>  
> @@ -6590,10 +6591,11 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
> *crtc)
>   I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
>  }
>  
> -static void haswell_crtc_enable(struct intel_crtc_state *new_crtc_state,
> - struct intel_atomic_state *state)
> +static void haswell_crtc_enable(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
>   enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> @@ -6713,10 +6715,11 @@ static void ironlake_pfit_disable(const struct 
> intel_crtc_state *old_crtc_state)
>   }
>  }
>  
> -static void ironlake_crtc_disable(struct intel_crtc_state *old_crtc_state,
> -   struct intel_atomic_state *state)
> +static void ironlake_crtc_disable(struct intel_atomic_state *state,
> +   struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe;
>  
> @@ -6769,10 +6772,11 @@ static void ironlake_crtc_disable(struct 
> intel_crtc_state *old_crtc_state,
>   intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
>  }
>  
> -static void haswell_crtc_disable(struct intel_crtc_state *old_crtc_state,
> -  struct intel_atomic_state *state)
> +static void haswell_crtc_disable(struct intel_atomic_state *state,
> +  struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>  
> @@ -7004,10 +7008,11 @@ static void modeset_put_power_domains(struct 
> drm_i915_private *dev_priv,
>   intel_display_power_put_unchecked(dev_priv, domain);
>  }
>  
> -static void valleyview_crtc_enable(struct intel_crtc_state *new_crtc_state,
> -struct intel_atomic_state *state)
> +static void valleyview_crtc_enable(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe;
>  
> @@ -7067,10 +7072,11 @@ static void i9xx_set_pll_dividers(const struct 
> intel_crtc_state *crtc_state)
>   I915_WRITE(FP1(crtc->pipe), crtc_state->dpll_hw_state.fp1);
>  }
>  
> -static void i9xx_crtc_enable(struct intel_crtc_state *new_crtc_state,
> -  struct intel_atomic_state *state)
> +static 

Re: [Intel-gfx] [PATCH 09/10] drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:15:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
> The 'pipe_config' name is a zombie that we need to finally put down.

So basically use pipe_config only in atomic check functions
like compute_config() etc and then all atomic commit hooks replace that
with new_crtc_state ?

Replacements below look good,

Reviewed-by: Manasi Navare 

Manasi

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 175 +--
>  1 file changed, 86 insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b091b92a677c..11953fe06488 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6460,10 +6460,10 @@ static void intel_disable_primary_plane(const struct 
> intel_crtc_state *crtc_stat
>   plane->disable_plane(plane, crtc_state);
>  }
>  
> -static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
> +static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
>struct intel_atomic_state *state)
>  {
> - struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   enum pipe pipe = crtc->pipe;
>  
> @@ -6483,55 +6483,54 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
>   intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
>  
> - if (pipe_config->has_pch_encoder)
> - intel_prepare_shared_dpll(pipe_config);
> + if (new_crtc_state->has_pch_encoder)
> + intel_prepare_shared_dpll(new_crtc_state);
>  
> - if (intel_crtc_has_dp_encoder(pipe_config))
> - intel_dp_set_m_n(pipe_config, M1_N1);
> + if (intel_crtc_has_dp_encoder(new_crtc_state))
> + intel_dp_set_m_n(new_crtc_state, M1_N1);
>  
> - intel_set_pipe_timings(pipe_config);
> - intel_set_pipe_src_size(pipe_config);
> + intel_set_pipe_timings(new_crtc_state);
> + intel_set_pipe_src_size(new_crtc_state);
>  
> - if (pipe_config->has_pch_encoder) {
> - intel_cpu_transcoder_set_m_n(pipe_config,
> -  _config->fdi_m_n, NULL);
> - }
> + if (new_crtc_state->has_pch_encoder)
> + intel_cpu_transcoder_set_m_n(new_crtc_state,
> +  _crtc_state->fdi_m_n, NULL);
>  
> - ironlake_set_pipeconf(pipe_config);
> + ironlake_set_pipeconf(new_crtc_state);
>  
>   crtc->active = true;
>  
>   intel_encoders_pre_enable(state, crtc);
>  
> - if (pipe_config->has_pch_encoder) {
> + if (new_crtc_state->has_pch_encoder) {
>   /* Note: FDI PLL enabling _must_ be done before we enable the
>* cpu pipes, hence this is separate from all the other fdi/pch
>* enabling. */
> - ironlake_fdi_pll_enable(pipe_config);
> + ironlake_fdi_pll_enable(new_crtc_state);
>   } else {
>   assert_fdi_tx_disabled(dev_priv, pipe);
>   assert_fdi_rx_disabled(dev_priv, pipe);
>   }
>  
> - ironlake_pfit_enable(pipe_config);
> + ironlake_pfit_enable(new_crtc_state);
>  
>   /*
>* On ILK+ LUT must be loaded before the pipe is running but with
>* clocks enabled
>*/
> - intel_color_load_luts(pipe_config);
> - intel_color_commit(pipe_config);
> + intel_color_load_luts(new_crtc_state);
> + intel_color_commit(new_crtc_state);
>   /* update DSPCNTR to configure gamma for pipe bottom color */
> - intel_disable_primary_plane(pipe_config);
> + intel_disable_primary_plane(new_crtc_state);
>  
>   if (dev_priv->display.initial_watermarks)
>   dev_priv->display.initial_watermarks(state, crtc);
> - intel_enable_pipe(pipe_config);
> + intel_enable_pipe(new_crtc_state);
>  
> - if (pipe_config->has_pch_encoder)
> - ironlake_pch_enable(state, pipe_config);
> + if (new_crtc_state->has_pch_encoder)
> + ironlake_pch_enable(state, new_crtc_state);
>  
> - intel_crtc_vblank_on(pipe_config);
> + intel_crtc_vblank_on(new_crtc_state);
>  
>   intel_encoders_enable(state, crtc);
>  
> @@ -6544,7 +6543,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>* some interlaced HDMI modes. Let's do the double wait always
>* in case there are more corner cases we don't know about.
>*/
> - if (pipe_config->has_pch_encoder) {
> + if (new_crtc_state->has_pch_encoder) {
>   intel_wait_for_vblank(dev_priv, pipe);
> 

Re: [Intel-gfx] [PATCH 08/10] drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:15:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Get rid of the horrible aliasing drm_crtc and intel_crtc variables
> in the crtc enable/disable hooks.
> 
> Signed-off-by: Ville Syrjälä 

Great this addresses my concern on intel_crtc vs crtc on the previous patch

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 142 +--
>  1 file changed, 65 insertions(+), 77 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6afdbfbb3264..b091b92a677c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6463,13 +6463,11 @@ static void intel_disable_primary_plane(const struct 
> intel_crtc_state *crtc_stat
>  static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
>struct intel_atomic_state *state)
>  {
> - struct drm_crtc *crtc = pipe_config->uapi.crtc;
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> + struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
>  
> - if (WARN_ON(intel_crtc->active))
> + if (WARN_ON(crtc->active))
>   return;
>  
>   /*
> @@ -6501,9 +6499,9 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>  
>   ironlake_set_pipeconf(pipe_config);
>  
> - intel_crtc->active = true;
> + crtc->active = true;
>  
> - intel_encoders_pre_enable(state, intel_crtc);
> + intel_encoders_pre_enable(state, crtc);
>  
>   if (pipe_config->has_pch_encoder) {
>   /* Note: FDI PLL enabling _must_ be done before we enable the
> @@ -6527,7 +6525,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_disable_primary_plane(pipe_config);
>  
>   if (dev_priv->display.initial_watermarks)
> - dev_priv->display.initial_watermarks(state, intel_crtc);
> + dev_priv->display.initial_watermarks(state, crtc);
>   intel_enable_pipe(pipe_config);
>  
>   if (pipe_config->has_pch_encoder)
> @@ -6535,7 +6533,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>  
>   intel_crtc_vblank_on(pipe_config);
>  
> - intel_encoders_enable(state, intel_crtc);
> + intel_encoders_enable(state, crtc);
>  
>   if (HAS_PCH_CPT(dev_priv))
>   cpt_verify_modeset(dev_priv, pipe);
> @@ -6596,22 +6594,21 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
> *crtc)
>  static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
>   struct intel_atomic_state *state)
>  {
> - struct drm_crtc *crtc = pipe_config->uapi.crtc;
> - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe, hsw_workaround_pipe;
> + struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
>   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
>   bool psl_clkgate_wa;
>  
> - if (WARN_ON(intel_crtc->active))
> + if (WARN_ON(crtc->active))
>   return;
>  
> - intel_encoders_pre_pll_enable(state, intel_crtc);
> + intel_encoders_pre_pll_enable(state, crtc);
>  
>   if (pipe_config->shared_dpll)
>   intel_enable_shared_dpll(pipe_config);
>  
> - intel_encoders_pre_enable(state, intel_crtc);
> + intel_encoders_pre_enable(state, crtc);
>  
>   if (intel_crtc_has_dp_encoder(pipe_config))
>   intel_dp_set_m_n(pipe_config, M1_N1);
> @@ -6641,7 +6638,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>   bdw_set_pipemisc(pipe_config);
>  
> - intel_crtc->active = true;
> + crtc->active = true;
>  
>   /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
>   psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> @@ -6665,16 +6662,16 @@ static void haswell_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_disable_primary_plane(pipe_config);
>  
>   if (INTEL_GEN(dev_priv) >= 11)
> - icl_set_pipe_chicken(intel_crtc);
> + icl_set_pipe_chicken(crtc);
>  
>   if (!transcoder_is_dsi(cpu_transcoder))
>   intel_ddi_enable_transcoder_func(pipe_config);
>  
>   if (dev_priv->display.initial_watermarks)
> - 

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Pass dev_priv to cpt_verify_modeset()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:15:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Get rid of the last 'dev' usage in ironlake_crtc_enable() by
> passing dev_priv to cpt_verify_modeset().
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 77b739cda053..6afdbfbb3264 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5462,9 +5462,9 @@ static void lpt_pch_enable(const struct 
> intel_atomic_state *state,
>   lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
>  }
>  
> -static void cpt_verify_modeset(struct drm_device *dev, enum pipe pipe)
> +static void cpt_verify_modeset(struct drm_i915_private *dev_priv,
> +enum pipe pipe)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dev);
>   i915_reg_t dslreg = PIPEDSL(pipe);
>   u32 temp;
>  
> @@ -6538,7 +6538,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_encoders_enable(state, intel_crtc);
>  
>   if (HAS_PCH_CPT(dev_priv))
> - cpt_verify_modeset(dev, intel_crtc->pipe);
> + cpt_verify_modeset(dev_priv, pipe);
>  
>   /*
>* Must wait for vblank to avoid spurious PCH FIFO underruns.
> -- 
> 2.23.0
> 
> ___
> 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 06/10] drm/i915: Change watermark hook calling convention

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
> time for the caller when it doesn't have to think what to pass.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 32 +-
>  drivers/gpu/drm/i915/i915_drv.h  |  6 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 63 +++-
>  3 files changed, 53 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ffadfd90c3cf..77b739cda053 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6177,9 +6177,8 @@ static void intel_pre_plane_update(struct 
> intel_crtc_state *old_crtc_state,
>* we'll continue to update watermarks the old way, if flags tell
>* us to.
>*/
> - if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(intel_state,
> -  pipe_config);
> + if (dev_priv->display.initial_watermarks)
> + dev_priv->display.initial_watermarks(intel_state, crtc);
>   else if (pipe_config->update_wm_pre)
>   intel_update_watermarks(crtc);
>  }
> @@ -6527,8 +6526,8 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   /* update DSPCNTR to configure gamma for pipe bottom color */
>   intel_disable_primary_plane(pipe_config);
>  
> - if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(state, pipe_config);
> + if (dev_priv->display.initial_watermarks)
> + dev_priv->display.initial_watermarks(state, intel_crtc);
>   intel_enable_pipe(pipe_config);
>  
>   if (pipe_config->has_pch_encoder)
> @@ -6671,8 +6670,8 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   if (!transcoder_is_dsi(cpu_transcoder))
>   intel_ddi_enable_transcoder_func(pipe_config);
>  
> - if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(state, pipe_config);
> + if (dev_priv->display.initial_watermarks)
> + dev_priv->display.initial_watermarks(state, intel_crtc);
>  
>   if (INTEL_GEN(dev_priv) >= 11)
>   icl_pipe_mbus_enable(intel_crtc);
> @@ -7062,7 +7061,7 @@ static void valleyview_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   /* update DSPCNTR to configure gamma for pipe bottom color */
>   intel_disable_primary_plane(pipe_config);
>  
> - dev_priv->display.initial_watermarks(state, pipe_config);
> + dev_priv->display.initial_watermarks(state, intel_crtc);

Dont we need to make sure initial_watermarks is present or !NULL before calling 
it
like we do in all other hooks?

Also some places we use intel_crtc vs crtc even though both are of type struct 
intel_crtc*,
either in this patch or another cleanup patch we should change it all to keep 
either crtc or
intel_crtc else there is a confusion between crtc being of type intel_crtc or 
drm_crtc

What do you think?
But that could be a separate change so after adding a check for if 
(dev_priv->display.initial_watermarks)
in valleyview_crtc_enable(),

Reviewed-by: Manasi navare 

Manasi

>   intel_enable_pipe(pipe_config);
>  
>   intel_crtc_vblank_on(pipe_config);
> @@ -7117,9 +7116,8 @@ static void i9xx_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   /* update DSPCNTR to configure gamma for pipe bottom color */
>   intel_disable_primary_plane(pipe_config);
>  
> - if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(state,
> -  pipe_config);
> + if (dev_priv->display.initial_watermarks)
> + dev_priv->display.initial_watermarks(state, intel_crtc);
>   else
>   intel_update_watermarks(intel_crtc);
>   intel_enable_pipe(pipe_config);
> @@ -14291,6 +14289,7 @@ static void commit_pipe_config(struct 
> intel_atomic_state *state,
>  struct intel_crtc_state *old_crtc_state,
>  struct intel_crtc_state *new_crtc_state)
>  {
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   bool modeset = needs_modeset(new_crtc_state);
>  
> @@ -14314,8 +14313,7 @@ static void commit_pipe_config(struct 
> intel_atomic_state *state,
>   }
>  
>   if (dev_priv->display.atomic_update_watermarks)
> - dev_priv->display.atomic_update_watermarks(state,
> -new_crtc_state);
> + dev_priv->display.atomic_update_watermarks(state, crtc);

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Pass intel_crtc to ironlake_fdi_disable()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Switch to intel_crtc from drm_crtc.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e52ea9643790..ffadfd90c3cf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5049,12 +5049,10 @@ static void ironlake_fdi_pll_disable(struct 
> intel_crtc *intel_crtc)
>   udelay(100);
>  }
>  
> -static void ironlake_fdi_disable(struct drm_crtc *crtc)
> +static void ironlake_fdi_disable(struct intel_crtc *crtc)
>  {
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
>   i915_reg_t reg;
>   u32 temp;
>  
> @@ -6748,7 +6746,7 @@ static void ironlake_crtc_disable(struct 
> intel_crtc_state *old_crtc_state,
>   ironlake_pfit_disable(old_crtc_state);
>  
>   if (old_crtc_state->has_pch_encoder)
> - ironlake_fdi_disable(crtc);
> + ironlake_fdi_disable(intel_crtc);
>  
>   intel_encoders_post_disable(state, intel_crtc);
>  
> -- 
> 2.23.0
> 
> ___
> 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 04/10] drm/i915: Move crtc_state to tighter scope

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> intel_modeset_setup_hw_state() doesn't need the crtc_state at the
> top level scope. Move it to where it's needed.
> 
> Signed-off-by: Ville Syrjälä 

Looks good even though it does add to the code size since we need to derive it 
in
3 different places and might be more in the future.
But logically makes sense to limit its scop to for loops where its needed.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 89d150b45520..e52ea9643790 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17716,7 +17716,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc_state *crtc_state;
>   struct intel_encoder *encoder;
>   struct intel_crtc *crtc;
>   intel_wakeref_t wakeref;
> @@ -17749,7 +17748,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>* waits, so we need vblank interrupts restored beforehand.
>*/
>   for_each_intel_crtc(_priv->drm, crtc) {
> - crtc_state = to_intel_crtc_state(crtc->base.state);
> + struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
>  
>   drm_crtc_vblank_reset(>base);
>  
> @@ -17763,7 +17763,9 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>   intel_sanitize_encoder(encoder);
>  
>   for_each_intel_crtc(_priv->drm, crtc) {
> - crtc_state = to_intel_crtc_state(crtc->base.state);
> + struct intel_crtc_state *crtc_state =
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> +
>   intel_sanitize_crtc(crtc, ctx);
>   intel_dump_pipe_config(crtc_state, NULL, "[setup_hw_state]");
>   }
> @@ -17796,9 +17798,10 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>   }
>  
>   for_each_intel_crtc(dev, crtc) {
> + struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
>   u64 put_domains;
>  
> - crtc_state = to_intel_crtc_state(crtc->base.state);
>   put_domains = modeset_get_crtc_power_domains(crtc_state);
>   if (WARN_ON(put_domains))
>   modeset_put_power_domains(dev_priv, put_domains);
> -- 
> 2.23.0
> 
> ___
> 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 03/10] drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Move the assert_vblank_disabled() into intel_crtc_vblank_on()
> so that we don't have to inline it all over.
> 
> This does mean we now assert_vblank_disabled() during readout as well
> but that is totally fine as it happens after drm_crtc_vblank_reset().
> One can even argue it's what we want to do anyway to make sure
> the reset actually happened.

Yes this makes total sense to me and double checking with the code
it looks fine to have it during the readout after drm_crtc_vblank_reset()
hence,

Reviewed-by: Manasi Navare 

Manasi

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 194029ff8617..89d150b45520 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1826,6 +1826,7 @@ static void intel_crtc_vblank_on(const struct 
> intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> + assert_vblank_disabled(>base);
>   drm_crtc_set_max_vblank_count(>base,
> intel_crtc_max_vblank_count(crtc_state));
>   drm_crtc_vblank_on(>base);
> @@ -6535,7 +6536,6 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   if (pipe_config->has_pch_encoder)
>   ironlake_pch_enable(state, pipe_config);
>  
> - assert_vblank_disabled(crtc);
>   intel_crtc_vblank_on(pipe_config);
>  
>   intel_encoders_enable(state, intel_crtc);
> @@ -6689,7 +6689,6 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST))
>   intel_ddi_set_vc_payload_alloc(pipe_config, true);
>  
> - assert_vblank_disabled(crtc);
>   intel_crtc_vblank_on(pipe_config);
>  
>   intel_encoders_enable(state, intel_crtc);
> @@ -7068,7 +7067,6 @@ static void valleyview_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   dev_priv->display.initial_watermarks(state, pipe_config);
>   intel_enable_pipe(pipe_config);
>  
> - assert_vblank_disabled(crtc);
>   intel_crtc_vblank_on(pipe_config);
>  
>   intel_encoders_enable(state, intel_crtc);
> @@ -7128,7 +7126,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   intel_update_watermarks(intel_crtc);
>   intel_enable_pipe(pipe_config);
>  
> - assert_vblank_disabled(crtc);
>   intel_crtc_vblank_on(pipe_config);
>  
>   intel_encoders_enable(state, intel_crtc);
> -- 
> 2.23.0
> 
> ___
> 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 i-g-t 3/7] lib/i915: Add query to detect if engine accepts only ro batches

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:09)
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 5c15f177..ca6bef6a 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -652,7 +652,8 @@ static void semaphore_noskip(int i915)
> igt_spin_t *chain, *spin;
>  
> if (eb_ring(inner) == eb_ring(outer) ||
> -   !gem_can_store_dword(i915, eb_ring(inner)))
> +   !gem_can_store_dword(i915, eb_ring(inner)) ||
> +   !gem_engine_has_mutable_submission(i915, eb_ring(inner)))
> continue;
>  
> chain = __igt_spin_new(i915, .engine = eb_ring(outer));
> @@ -1157,6 +1158,9 @@ static void deep(int fd, unsigned ring)
> int dep_nreq;
> int n;
>  
> +   igt_require(gem_can_store_dword(fd, ring));
> +   igt_require(gem_engine_has_mutable_submission(fd, ring));
> +
> ctx = malloc(sizeof(*ctx) * MAX_CONTEXTS);
> for (n = 0; n < MAX_CONTEXTS; n++) {
> ctx[n] = gem_context_create(fd);

Works, no need to skip.

> diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
> index a3384760..45cc1437 100644
> --- a/tests/i915/gem_exec_whisper.c
> +++ b/tests/i915/gem_exec_whisper.c
> @@ -204,13 +204,15 @@ static void whisper(int fd, unsigned engine, unsigned 
> flags)
> nengine = 0;
> if (engine == ALL_ENGINES) {
> for_each_physical_engine(e, fd) {
> -   if (gem_can_store_dword(fd, eb_ring(e)))
> +   if (gem_can_store_dword(fd, eb_ring(e)) &&
> +   gem_engine_has_mutable_submission(fd, eb_ring(e)))
> engines[nengine++] = eb_ring(e);
> }
> } else {
> igt_assert(!(flags & ALL));
> igt_require(gem_has_ring(fd, engine));
> igt_require(gem_can_store_dword(fd, engine));
> +   igt_require(gem_engine_has_mutable_submission(fd, engine));
> engines[nengine++] = engine;
> }
> igt_require(nengine);

You should be able to handle the whisper; it's one of the basic does the
kernel work at all. All it is testing is relocation and scheduling...

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

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Add intel_crtc_vblank_off()

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We already have intel_crtc_vblank_on(). Add a counterpart so we
> don't have to inline the disable+assert all over.
> 
> Signed-off-by: Ville Syrjälä 

LGTM,

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index da01fa6928a2..194029ff8617 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1831,6 +1831,12 @@ static void intel_crtc_vblank_on(const struct 
> intel_crtc_state *crtc_state)
>   drm_crtc_vblank_on(>base);
>  }
>  
> +static void intel_crtc_vblank_off(struct intel_crtc *crtc)
> +{
> + drm_crtc_vblank_off(>base);
> + assert_vblank_disabled(>base);
> +}
> +
>  static void intel_enable_pipe(const struct intel_crtc_state *new_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> @@ -6736,8 +6742,7 @@ static void ironlake_crtc_disable(struct 
> intel_crtc_state *old_crtc_state,
>  
>   intel_encoders_disable(state, intel_crtc);
>  
> - drm_crtc_vblank_off(crtc);
> - assert_vblank_disabled(crtc);
> + intel_crtc_vblank_off(intel_crtc);
>  
>   intel_disable_pipe(old_crtc_state);
>  
> @@ -6786,8 +6791,7 @@ static void haswell_crtc_disable(struct 
> intel_crtc_state *old_crtc_state,
>  
>   intel_encoders_disable(state, intel_crtc);
>  
> - drm_crtc_vblank_off(crtc);
> - assert_vblank_disabled(crtc);
> + intel_crtc_vblank_off(intel_crtc);
>  
>   /* XXX: Do the pipe assertions at the right place for BXT DSI. */
>   if (!transcoder_is_dsi(cpu_transcoder))
> @@ -7163,8 +7167,7 @@ static void i9xx_crtc_disable(struct intel_crtc_state 
> *old_crtc_state,
>  
>   intel_encoders_disable(state, intel_crtc);
>  
> - drm_crtc_vblank_off(crtc);
> - assert_vblank_disabled(crtc);
> + intel_crtc_vblank_off(intel_crtc);
>  
>   intel_disable_pipe(old_crtc_state);
>  
> -- 
> 2.23.0
> 
> ___
> 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 01/10] drm/i915: Change intel_encoders_() calling convention

2019-11-13 Thread Manasi Navare
On Tue, Nov 12, 2019 at 04:14:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Just pass the atomic state and the crtc to intel_encoders_enable() & co.
> Make life simpler when you don't have to think which state (old vs. new)
> you have to pass in. Also constify the states while at it.
> 
> Signed-off-by: Ville Syrjälä 

Oh thank you for making life around the encoder functions easier

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 101 ++-
>  1 file changed, 54 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5f3340554149..da01fa6928a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6299,11 +6299,12 @@ static void intel_encoders_update_complete(struct 
> intel_atomic_state *state)
>   }
>  }
>  
> -static void intel_encoders_pre_pll_enable(struct intel_crtc *crtc,
> -   struct intel_crtc_state *crtc_state,
> -   struct intel_atomic_state *state)
> +static void intel_encoders_pre_pll_enable(struct intel_atomic_state *state,
> +   struct intel_crtc *crtc)
>  {
> - struct drm_connector_state *conn_state;
> + const struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> @@ -6319,11 +6320,12 @@ static void intel_encoders_pre_pll_enable(struct 
> intel_crtc *crtc,
>   }
>  }
>  
> -static void intel_encoders_pre_enable(struct intel_crtc *crtc,
> -   struct intel_crtc_state *crtc_state,
> -   struct intel_atomic_state *state)
> +static void intel_encoders_pre_enable(struct intel_atomic_state *state,
> +   struct intel_crtc *crtc)
>  {
> - struct drm_connector_state *conn_state;
> + const struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> @@ -6339,11 +6341,12 @@ static void intel_encoders_pre_enable(struct 
> intel_crtc *crtc,
>   }
>  }
>  
> -static void intel_encoders_enable(struct intel_crtc *crtc,
> -   struct intel_crtc_state *crtc_state,
> -   struct intel_atomic_state *state)
> +static void intel_encoders_enable(struct intel_atomic_state *state,
> +   struct intel_crtc *crtc)
>  {
> - struct drm_connector_state *conn_state;
> + const struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> @@ -6360,11 +6363,12 @@ static void intel_encoders_enable(struct intel_crtc 
> *crtc,
>   }
>  }
>  
> -static void intel_encoders_disable(struct intel_crtc *crtc,
> -struct intel_crtc_state *old_crtc_state,
> -struct intel_atomic_state *state)
> +static void intel_encoders_disable(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
>  {
> - struct drm_connector_state *old_conn_state;
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + const struct drm_connector_state *old_conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> @@ -6381,11 +6385,12 @@ static void intel_encoders_disable(struct intel_crtc 
> *crtc,
>   }
>  }
>  
> -static void intel_encoders_post_disable(struct intel_crtc *crtc,
> - struct intel_crtc_state *old_crtc_state,
> - struct intel_atomic_state *state)
> +static void intel_encoders_post_disable(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
>  {
> - struct drm_connector_state *old_conn_state;
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + const struct drm_connector_state *old_conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> @@ -6401,11 +6406,12 @@ static void intel_encoders_post_disable(struct 
> intel_crtc *crtc,
>   }
>  }
>  
> -static void intel_encoders_post_pll_disable(struct intel_crtc *crtc,
> - struct intel_crtc_state 
> *old_crtc_state,
> - struct intel_atomic_state *state)
> +static void intel_encoders_post_pll_disable(struct intel_atomic_state *state,
> +   

Re: [Intel-gfx] [PATCH i-g-t 3/7] lib/i915: Add query to detect if engine accepts only ro batches

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:09)
> From: "Kuoppala, Mika" 
> 
> If cmd parser is mandatory, batch can't be modified post execbuf.
> Some tests rely on modifying batch post execbuf. Give those
> tests a method to query if those modifications ever reach
> the actual engine command stream.
> 
> v2: pull in the test changes, doh
> v3: class based query
> v4: rebase
> 
> Signed-off-by: Kuoppala, Mika 
> ---
>  lib/i915/gem_submission.c  | 62 ++
>  lib/i915/gem_submission.h  |  2 ++
>  tests/i915/gem_busy.c  |  7 +++-
>  tests/i915/gem_exec_async.c|  3 ++
>  tests/i915/gem_exec_await.c|  7 +++-
>  tests/i915/gem_exec_fence.c|  8 +
>  tests/i915/gem_exec_latency.c  |  7 
>  tests/i915/gem_exec_nop.c  |  4 ++-
>  tests/i915/gem_exec_schedule.c |  6 +++-
>  tests/i915/gem_exec_whisper.c  |  4 ++-
>  tests/prime_busy.c |  3 ++
>  tests/prime_vgem.c |  6 
>  12 files changed, 114 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submission.c
> index 4f946493..9bdf28bc 100644
> --- a/lib/i915/gem_submission.c
> +++ b/lib/i915/gem_submission.c
> @@ -64,6 +64,22 @@ static bool has_semaphores(int fd, int dir)
> return val;
>  }
>  
> +static int cmd_parser_version(int fd)

gem_cmdparser_version() ?

Drop the engine parameter as it turns out you didn't need it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/tgl: Wa_1606679103

2019-11-13 Thread Chris Wilson
Quoting Radhakrishna Sripada (2019-11-13 23:19:53)
> Extend disabling SAMPLER_STATE prefetch workaround to gen12.
> 
> v2: Limit the WA to TGL A0 and update the WA no(Chris)
> 
> BSpec: 52890
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Radhakrishna Sripada 

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: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Bruce Chang
below is the call trace when this issue is hit

<3> [113.316247] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:4653
<3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: 
debugfs_test
<4> [113.319900] no locks held by debugfs_test/678.
<3> [113.321002] Preemption disabled at:
<4> [113.321130] [] i915_error_object_create+0x494/0x610 
[i915]
<4> [113.327259] Call Trace:
<4> [113.327871] dump_stack+0x67/0x9b
<4> [113.328683] ___might_sleep+0x167/0x250
<4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110
<4> [113.330731] ? ___slab_alloc.constprop.34+0x21c/0x380
<4> [113.331943] ? ___slab_alloc.constprop.34+0x21c/0x380
<4> [113.333169] ? __slab_alloc.isra.28.constprop.33+0x4d/0x70
<4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915]
<4> [113.335951] compress_page+0x7c/0x100 [i915]
<4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915]
<4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915]
<4> [113.339771] ? __lock_acquire+0x4ac/0x1e90
<4> [113.340785] ? _raw_spin_lock_irqsave_nested+0x1/0x50
<4> [113.342127] i915_gpu_info_open+0x44/0x70 [i915]
<4> [113.343243] full_proxy_open+0x139/0x1b0
<4> [113.344196] ? open_proxy_open+0xc0/0xc0
<4> [113.345149] do_dentry_open+0x1ce/0x3a0
<4> [113.346084] path_openat+0x4c9/0xac0
<4> [113.346967] do_filp_open+0x96/0x110
<4> [113.347848] ? __alloc_fd+0xe0/0x1f0
<4> [113.348736] ? do_sys_open+0x1b8/0x250
<4> [113.349647] do_sys_open+0x1b8/0x250
<4> [113.350526] do_syscall_64+0x55/0x1c0
<4> [113.351418] entry_SYSCALL_64_after_hwframe+0x49/0xbe

After the io_mapping_map_atomic_wc/kmap_atomic, the kernel enters atomic context
but after that, compress_page calls pool_alloc with GFP_KERNEL flag which can
potentially go to sleep.

In order to fix this issue, we either
1) not enter into atomic context, i.e., to use non atomic version of
functions like io_mapping_map_wc/kmap,
or
2) make compress_page run in atomic context.

To follow current design not to run compression in atomic context, so,
use 1) above in this patch.

Signed-off-by: Bruce Chang 
Reviewed-by: Brian Welty 
Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 1f2f266f26af..7118ecb7f144 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private *i915,
compress->wc = i915_gem_object_is_lmem(vma->obj) ||
   drm_mm_node_allocated(>error_capture);
 
ret = -EINVAL;
if (drm_mm_node_allocated(>error_capture)) {
void __iomem *s;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
ggtt->vm.insert_page(>vm, dma, slot,
 I915_CACHE_NONE, 0);
 
s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
ret = compress_page(compress, (void  __force *)s, dst);
io_mapping_unmap(s);
if (ret)
break;
}
} else if (i915_gem_object_is_lmem(vma->obj)) {
struct intel_memory_region *mem = vma->obj->mm.region;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
void __iomem *s;
 
-   s = io_mapping_map_atomic_wc(>iomap, dma);
+   s = io_mapping_map_wc(>iomap, dma, PAGE_SIZE);
ret = compress_page(compress, (void __force *)s, dst);
-   io_mapping_unmap_atomic(s);
+   io_mapping_unmap(s);
if (ret)
break;
}
} else {
struct page *page;
 
for_each_sgt_page(page, iter, vma->pages) {
void *s;
 
drm_clflush_pages(, 1);
 
-   s = kmap_atomic(page);
+   s = kmap(page);
ret = compress_page(compress, s, dst);
-   kunmap_atomic(s);
+   kunmap(s);
 
drm_clflush_pages(, 1);
 
if (ret)
break;
}
}
 
if (ret || compress_flush(compress, dst)) {
while (dst->page_count--)
pool_free(>pool, dst->pages[dst->page_count]);
kfree(dst);
dst = NULL;
}
compress_finish(compress);
 
return dst;
 }
 
 /*
  * Generate a semi-unique error code. The code is not meant to have meaning, 
The
  * code's only purpose is to try 

Re: [Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Chris Wilson
Quoting Bruce Chang (2019-11-13 23:11:04)
> below is the call trace when this issue is hit
> 
> <3> [113.316247] BUG: sleeping function called from invalid context at 
> mm/page_alloc.c:4653
> <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: 
> debugfs_test
> <4> [113.319900] no locks held by debugfs_test/678.
> <3> [113.321002] Preemption disabled at:
> <4> [113.321130] [] i915_error_object_create+0x494/0x610 
> [i915]
> <4> [113.327259] Call Trace:
> <4> [113.327871] dump_stack+0x67/0x9b
> <4> [113.328683] ___might_sleep+0x167/0x250
> <4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110
> <4> [113.330731] ? ___slab_alloc.constprop.34+0x21c/0x380
> <4> [113.331943] ? ___slab_alloc.constprop.34+0x21c/0x380
> <4> [113.333169] ? __slab_alloc.isra.28.constprop.33+0x4d/0x70
> <4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915]
> <4> [113.335951] compress_page+0x7c/0x100 [i915]
> <4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915]
> <4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915]
> <4> [113.339771] ? __lock_acquire+0x4ac/0x1e90
> <4> [113.340785] ? _raw_spin_lock_irqsave_nested+0x1/0x50
> <4> [113.342127] i915_gpu_info_open+0x44/0x70 [i915]
> <4> [113.343243] full_proxy_open+0x139/0x1b0
> <4> [113.344196] ? open_proxy_open+0xc0/0xc0
> <4> [113.345149] do_dentry_open+0x1ce/0x3a0
> <4> [113.346084] path_openat+0x4c9/0xac0
> <4> [113.346967] do_filp_open+0x96/0x110
> <4> [113.347848] ? __alloc_fd+0xe0/0x1f0
> <4> [113.348736] ? do_sys_open+0x1b8/0x250
> <4> [113.349647] do_sys_open+0x1b8/0x250
> <4> [113.350526] do_syscall_64+0x55/0x1c0
> <4> [113.351418] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> After the io_mapping_map_atomic_wc/kmap_atomic, the kernel enters atomic 
> context
> but after that, compress_page calls pool_alloc with GFP_KERNEL flag which can
> potentially go to sleep. When the kernel is in atomic context, sleeping is not
> allowed. This is why this bug got triggered.

The last 2 sentences are redundant.

> In order to fix this issue, we either
> 1) not enter into atomic context, i.e., to use non atomic version of
> functions like io_mapping_map_wc/kmap,
> or
> 2) make compress_page run in atomic context.
> 
> But it is not a good idea to run slow compression in atomic context, so,
> 1) above is preferred solution which is the implementation of this patch.

Reasonable, though we have and may have to do capture inside atomic
again. (Dropping the atomicity is a recent change that has a surprising
amount of controversy.)
 
> Signed-off-by: Bruce Chang 
> Reviewed-by: Brian Welty 
> Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
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 v2 1/2] drm/i915/tgl: Wa_1606679103

2019-11-13 Thread Radhakrishna Sripada
Extend disabling SAMPLER_STATE prefetch workaround to gen12.

v2: Limit the WA to TGL A0 and update the WA no(Chris)

BSpec: 52890
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e4bccc14602f..da27eb1cd7cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1370,11 +1370,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
GEN7_SARCHKMD,
GEN7_DISABLE_DEMAND_PREFETCH);
 
-   /* Wa_1606682166:icl */
-   wa_write_or(wal,
-   GEN7_SARCHKMD,
-   GEN7_DISABLE_SAMPLER_PREFETCH);
-
/* Wa_1409178092:icl */
wa_write_masked_or(wal,
   GEN11_SCRATCH2,
@@ -1382,6 +1377,16 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
   0);
}
 
+   if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0) || IS_GEN(i915, 11)) 
{
+   /*
+* Wa_1606682166:icl
+* Wa_1606679103:tgl
+*/
+   wa_write_or(wal,
+   GEN7_SARCHKMD,
+   GEN7_DISABLE_SAMPLER_PREFETCH);
+   }
+
if (IS_GEN_RANGE(i915, 9, 11)) {
/* 
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
wa_masked_en(wal,
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/psr: Share the computation of idle frames

2019-11-13 Thread Souza, Jose
On Wed, 2019-11-13 at 18:04 +0530, Anshuamn Gupta wrote:
> Looks good to me, there is a minor comment see below.
> On 2019-10-31 at 17:14:20 -0700, José Roberto de Souza wrote:
> > Both activate functions and the dc3co disable function were doing
> > the
> > same thing, so better move to a function and share.
> > Also while at it adding a WARN_ON to catch invalid values.
> > 
> > Cc: Anshuman Gupta 
> > Cc: Imre Deak 
> Acked-by: Anshuman Gupta 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 43 +++-
> > 
> >  1 file changed, 19 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 6a9f322d3fca..bb9b5349b72a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -451,22 +451,29 @@ static u32 intel_psr1_get_tp_time(struct
> > intel_dp *intel_dp)
> > return val;
> >  }
> >  
> > -static void hsw_activate_psr1(struct intel_dp *intel_dp)
> > +static u8 psr_compute_idle_frames(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > -   u32 max_sleep_time = 0x1f;
> > -   u32 val = EDP_PSR_ENABLE;
> > +   int idle_frames;
> >  
> > /* Let's use 6 as the minimum to cover all known cases
> > including the
> >  * off-by-one issue that HW has in some cases.
> >  */
> > -   int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > -
> > -   /* sink_sync_latency of 8 means source has to wait for more
> > than 8
> > -* frames, we'll go with 9 frames for now
> > -*/
> > +   idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > -   val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> > +
> > +   WARN_ON(idle_frames > 0xf);
> > +
> > +   return idle_frames;
> there would be return type mismatch warning.

There is not warning, the value will be truncated but if happens we
will get the warn_on above.


> > +}
> > +
> > +static void hsw_activate_psr1(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   u32 max_sleep_time = 0x1f;
> > +   u32 val = EDP_PSR_ENABLE;
> > +
> > +   val |= psr_compute_idle_frames(intel_dp) <<
> > EDP_PSR_IDLE_FRAME_SHIFT;
> >  
> > val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > if (IS_HASWELL(dev_priv))
> > @@ -490,13 +497,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > u32 val;
> >  
> > -   /* Let's use 6 as the minimum to cover all known cases
> > including the
> > -* off-by-one issue that HW has in some cases.
> > -*/
> > -   int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > -
> > -   idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > -   val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
> > +   val = psr_compute_idle_frames(intel_dp) <<
> > EDP_PSR2_IDLE_FRAME_SHIFT;
> >  
> > val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > @@ -563,16 +564,10 @@ static void tgl_psr2_enable_dc3co(struct
> > drm_i915_private *dev_priv)
> >  
> >  static void tgl_psr2_disable_dc3co(struct drm_i915_private
> > *dev_priv)
> >  {
> > -   int idle_frames;
> > +   struct intel_dp *intel_dp = dev_priv->psr.dp;
> >  
> > intel_display_power_set_target_dc_state(dev_priv,
> > DC_STATE_EN_UPTO_DC6);
> > -   /*
> > -* Restore PSR2 idle frame let's use 6 as the minimum to cover
> > all known
> > -* cases including the off-by-one issue that HW has in some
> > cases.
> > -*/
> > -   idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > -   idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency
> > + 1);
> > -   psr2_program_idle_frames(dev_priv, idle_frames);
> > +   psr2_program_idle_frames(dev_priv,
> > psr_compute_idle_frames(intel_dp));
> >  }
> >  
> >  static void tgl_dc5_idle_thread(struct work_struct *work)
> > -- 
> > 2.23.0
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ GitLab.Pipeline: warning for igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Patchwork
== Series Details ==

Series: igt: Use COND_BBEND for busy spinning on gen9
URL   : https://patchwork.freedesktop.org/series/69423/
State : warning

== Summary ==

Did not get list of undocumented tests for this run, something is wrong!

Other than that, pipeline status: FAILED.

see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/78836 for the 
overview.

build:tests-fedora has failed 
(https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/941381):
  ../lib/igt_dummyload.c: In function ‘emit_recursive_batch’:
  ../lib/igt_dummyload.c:218:20: error: request for member ‘relocation_count’ 
in something not a structure or union
218 |   r = [batch->relocation_count++];
|^~
  ../lib/igt_dummyload.c:221:27: error: request for member ‘handle’ in 
something not a structure or union
221 |   r->target_handle = batch->handle;
|   ^~
  ../lib/igt_dummyload.c:222:25: error: ‘batch_start’ undeclared (first use in 
this function); did you mean ‘va_start’?
222 |   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
| ^~~
| va_start
  ../lib/igt_dummyload.c:222:25: note: each undeclared identifier is reported 
only once for each function it appears in
  ninja: build stopped: subcommand failed.
  section_end:1573686639:build_script
  section_start:1573686639:after_script
  section_end:1573686640:after_script
  section_start:1573686640:upload_artifacts_on_failure
  section_end:1573686642:upload_artifacts_on_failure
  ERROR: Job failed: exit code 1
  

build:tests-fedora-no-libunwind has failed 
(https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/941382):
  ../lib/igt_dummyload.c: In function ‘emit_recursive_batch’:
  ../lib/igt_dummyload.c:218:20: error: request for member ‘relocation_count’ 
in something not a structure or union
218 |   r = [batch->relocation_count++];
|^~
  ../lib/igt_dummyload.c:221:27: error: request for member ‘handle’ in 
something not a structure or union
221 |   r->target_handle = batch->handle;
|   ^~
  ../lib/igt_dummyload.c:222:25: error: ‘batch_start’ undeclared (first use in 
this function); did you mean ‘va_start’?
222 |   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
| ^~~
| va_start
  ../lib/igt_dummyload.c:222:25: note: each undeclared identifier is reported 
only once for each function it appears in
  ninja: build stopped: subcommand failed.
  section_end:1573686660:build_script
  section_start:1573686660:after_script
  section_end:1573686662:after_script
  section_start:1573686662:upload_artifacts_on_failure
  section_end:1573686663:upload_artifacts_on_failure
  ERROR: Job failed: exit code 1
  

build:tests-fedora-oldest-meson has failed 
(https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/941383):
  ../lib/igt_dummyload.c: In function ‘emit_recursive_batch’:
  ../lib/igt_dummyload.c:218:20: error: request for member ‘relocation_count’ 
in something not a structure or union
218 |   r = [batch->relocation_count++];
|^~
  ../lib/igt_dummyload.c:221:27: error: request for member ‘handle’ in 
something not a structure or union
221 |   r->target_handle = batch->handle;
|   ^~
  ../lib/igt_dummyload.c:222:25: error: ‘batch_start’ undeclared (first use in 
this function); did you mean ‘va_start’?
222 |   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
| ^~~
| va_start
  ../lib/igt_dummyload.c:222:25: note: each undeclared identifier is reported 
only once for each function it appears in
  ninja: build stopped: subcommand failed.
  section_end:1573686689:build_script
  section_start:1573686689:after_script
  section_end:1573686691:after_script
  section_start:1573686691:upload_artifacts_on_failure
  section_end:1573686692:upload_artifacts_on_failure
  ERROR: Job failed: exit code 1
  

build:tests-fedora-clang has failed 
(https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/941384):
  r = [batch->relocation_count++];
  ~^ 
  ../lib/igt_dummyload.c:221:27: error: member reference base type 'uint32_t' 
(aka 'unsigned int') is not a structure or union
  r->target_handle = batch->handle;
 ~^ ~~
  ../lib/igt_dummyload.c:222:25: error: use of undeclared identifier 
'batch_start'
  r->offset = (cs + 2 - batch_start) * sizeof(*cs);
^
  ../lib/igt_dummyload.c:224:33: error: use of undeclared identifier 
'batch_start'
  r->delta = (spin->condition - 

[Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Bruce Chang
below is the call trace when this issue is hit

<3> [113.316247] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:4653
<3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: 
debugfs_test
<4> [113.319900] no locks held by debugfs_test/678.
<3> [113.321002] Preemption disabled at:
<4> [113.321130] [] i915_error_object_create+0x494/0x610 
[i915]
<4> [113.327259] Call Trace:
<4> [113.327871] dump_stack+0x67/0x9b
<4> [113.328683] ___might_sleep+0x167/0x250
<4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110
<4> [113.330731] ? ___slab_alloc.constprop.34+0x21c/0x380
<4> [113.331943] ? ___slab_alloc.constprop.34+0x21c/0x380
<4> [113.333169] ? __slab_alloc.isra.28.constprop.33+0x4d/0x70
<4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915]
<4> [113.335951] compress_page+0x7c/0x100 [i915]
<4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915]
<4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915]
<4> [113.339771] ? __lock_acquire+0x4ac/0x1e90
<4> [113.340785] ? _raw_spin_lock_irqsave_nested+0x1/0x50
<4> [113.342127] i915_gpu_info_open+0x44/0x70 [i915]
<4> [113.343243] full_proxy_open+0x139/0x1b0
<4> [113.344196] ? open_proxy_open+0xc0/0xc0
<4> [113.345149] do_dentry_open+0x1ce/0x3a0
<4> [113.346084] path_openat+0x4c9/0xac0
<4> [113.346967] do_filp_open+0x96/0x110
<4> [113.347848] ? __alloc_fd+0xe0/0x1f0
<4> [113.348736] ? do_sys_open+0x1b8/0x250
<4> [113.349647] do_sys_open+0x1b8/0x250
<4> [113.350526] do_syscall_64+0x55/0x1c0
<4> [113.351418] entry_SYSCALL_64_after_hwframe+0x49/0xbe

After the io_mapping_map_atomic_wc/kmap_atomic, the kernel enters atomic context
but after that, compress_page calls pool_alloc with GFP_KERNEL flag which can
potentially go to sleep. When the kernel is in atomic context, sleeping is not
allowed. This is why this bug got triggered.

In order to fix this issue, we either
1) not enter into atomic context, i.e., to use non atomic version of
functions like io_mapping_map_wc/kmap,
or
2) make compress_page run in atomic context.

But it is not a good idea to run slow compression in atomic context, so,
1) above is preferred solution which is the implementation of this patch.

Signed-off-by: Bruce Chang 
Reviewed-by: Brian Welty 
Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 1f2f266f26af..7118ecb7f144 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private *i915,
compress->wc = i915_gem_object_is_lmem(vma->obj) ||
   drm_mm_node_allocated(>error_capture);
 
ret = -EINVAL;
if (drm_mm_node_allocated(>error_capture)) {
void __iomem *s;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
ggtt->vm.insert_page(>vm, dma, slot,
 I915_CACHE_NONE, 0);
 
s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
ret = compress_page(compress, (void  __force *)s, dst);
io_mapping_unmap(s);
if (ret)
break;
}
} else if (i915_gem_object_is_lmem(vma->obj)) {
struct intel_memory_region *mem = vma->obj->mm.region;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
void __iomem *s;
 
-   s = io_mapping_map_atomic_wc(>iomap, dma);
+   s = io_mapping_map_wc(>iomap, dma, PAGE_SIZE);
ret = compress_page(compress, (void __force *)s, dst);
-   io_mapping_unmap_atomic(s);
+   io_mapping_unmap(s);
if (ret)
break;
}
} else {
struct page *page;
 
for_each_sgt_page(page, iter, vma->pages) {
void *s;
 
drm_clflush_pages(, 1);
 
-   s = kmap_atomic(page);
+   s = kmap(page);
ret = compress_page(compress, s, dst);
-   kunmap_atomic(s);
+   kunmap(s);
 
drm_clflush_pages(, 1);
 
if (ret)
break;
}
}
 
if (ret || compress_flush(compress, dst)) {
while (dst->page_count--)
pool_free(>pool, dst->pages[dst->page_count]);
kfree(dst);
dst = NULL;
}
compress_finish(compress);
 
 

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_reloc: Check that relocations do not block

2019-11-13 Thread Chris Wilson
With GPU relocations we avoid blocking inside execbuf and prevent
priority inversions where a low priority client can cause a denial of
service to higher priority clients.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 tests/i915/gem_exec_reloc.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 5f59fe99f..3c2c7d31d 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -324,6 +324,49 @@ static void active(int fd, unsigned engine)
gem_close(fd, obj[0].handle);
 }
 
+static unsigned int offset_in_page(void *addr)
+{
+   return (uintptr_t)addr & 4095;
+}
+
+static void active_spin(int fd, unsigned engine)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_execbuffer2 execbuf;
+   igt_spin_t *spin;
+
+   spin = igt_spin_new(fd, .engine = engine);
+
+   memset(obj, 0, sizeof(obj));
+   obj[0] = spin->obj[IGT_SPIN_BATCH];
+   obj[0].relocs_ptr = to_user_pointer();
+   obj[0].relocation_count = 1;
+   obj[1].handle = gem_create(fd, 4096);
+   gem_write(fd, obj[1].handle, 0, , sizeof(bbe));
+
+   memset(, 0, sizeof(reloc));
+   reloc.presumed_offset = -1;
+   reloc.offset = offset_in_page(spin->condition);
+   reloc.target_handle = obj[0].handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+   execbuf.flags = engine;
+
+   gem_execbuf(fd, );
+   gem_close(fd, obj[1].handle);
+   igt_assert_eq(*spin->condition, spin->cmd_precondition);
+
+   igt_spin_end(spin);
+   gem_sync(fd, spin->handle);
+
+   igt_assert_eq(*spin->condition, obj[0].offset);
+   igt_spin_free(fd, spin);
+}
+
 static bool has_64b_reloc(int fd)
 {
return intel_gen(intel_get_drm_devid(fd)) >= 8;
@@ -755,6 +798,8 @@ igt_main
 e->name; e++) {
igt_subtest_f("active-%s", e->name)
active(fd, eb_ring(e));
+   igt_subtest_f("spin-%s", e->name)
+   active_spin(fd, eb_ring(e));
}
igt_fixture
close(fd);
-- 
2.24.0

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

Re: [Intel-gfx] [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color

2019-11-13 Thread Chery, Nanley G
> From: Chery, Nanley G
> Sent: Tuesday, November 12, 2019 9:40 AM
> To: Sripada, Radhakrishna; intel-gfx@lists.freedesktop.org
> Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank; Antognolli, 
> Rafael; Ville Syrjala; Ekstrand, Jason
> Subject: RE: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel 
> Gen 12 render compression with Clear Color
> 
> > From: Sripada, Radhakrishna
> > Sent: Friday, November 01, 2019 12:00 AM
> > To: Chery, Nanley G; intel-gfx@lists.freedesktop.org
> > Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank; Antognolli, 
> > Rafael; Ville Syrjala; Ekstrand, Jason
> > Subject: RE: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for 
> > Intel Gen 12 render compression with Clear Color
> >
> > Hi Nanley,
> >
> > > -Original Message-
> > > From: Chery, Nanley G
> > > Sent: Tuesday, October 29, 2019 5:05 PM
> > > To: Sripada, Radhakrishna ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Pandiyan, Dhinakaran ; Syrjala, Ville
> > > ; Sharma, Shashank
> > > ; Antognolli, Rafael
> > > ; Ville Syrjala 
> > > ;
> > > Ekstrand, Jason 
> > > Subject: RE: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for 
> > > Intel
> > > Gen 12 render compression with Clear Color
> > >
> > > +Jason
> > >
> > > Maybe Jason and/or others have some thoughts on the following? Given the
> > > detailed description of the clear color struct, it seems like we'll have 
> > > to define
> > > a new modifier if the struct fields change in a future generation.
> > >
> > > On negative is that we might have to make new modifiers that provide no
> > > additional benefit (assuming the new/changed fields are unused). On
> > > positive is that it's probably a good thing that we mentioned the Raw 
> > > clear
> > > color fields because I think 3D uses it during rendering operations and 
> > > we'll
> > > be sharing from 3D-to-3D. Maybe we should specify how the channels
> > > should be formatted?
> > >
> > > I haven't thought through how fields like Color Discard Enable affect 
> > > buffer
> > > sharing...
> > >

After some more thought, I don't think it's a problem to have a detailed
description here. We have a lot of space allocated for making new modifiers
(and the header suggests doing so!).

We could go into more detail about the non-DE-specific fields, but I suppose
users can access PRMs.

> > > Another comment: I noticed that none of the Y+CCS modifiers explicitly 
> > > state
> > > that the CCS must be in the same BO as the Y-tiled main surface. We should
> > > at least fix that for newly defined modifiers right?
> > I have not tried to use separate bo for the different surfaces. That is 
> > probably worth a try.
> > I wonder if we are using that for any of the modifiers to have an explicit 
> > comment?
> 
> I didn't think it was possible to use a separate BO for the aux data. AFAICT
> the location of the aux data is specified as an offset from the main surface
> using the PLANE_AUX_DIST register.
> 

Great, I got some clarification that this is actually possible. 

Lastly, can we replace: 

* The raw clear color is consumed by the 3d engine and generates
* the converted clear color of size 64 bits.

with something like:

* The 3D engine can use the raw clear color and the surface format to
* generate a converted clear color of size 64 bits.

so that the subject is constant throughout the sentence and so that it's a bit
more obvious what is in the Converted Clear Color field? Also, we don't
explicitly state that the Converted Clear Color comes right after the raw clear
color, but I'd think the implication is strong enough.

With the above suggestion implemented, this patch is
Reviewed-by: Nanley Chery 

-Nanley

> -Nanley
> 
> >
> > Thanks,
> > RK
> > >
> > > -Nanley
> > >
> > > > 
> > > > From: Sripada, Radhakrishna
> > > > Sent: Monday, October 28, 2019 1:40 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank;
> > > > Antognolli, Rafael; Chery, Nanley G; Sripada, Radhakrishna; Ville
> > > > Syrjala; Kondapally, Kalyan
> > > > Subject: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for
> > > > Intel Gen 12 render compression with Clear Color
> > > >
> > > > Gen12 display can decompress surfaces compressed by render engine with
> > > > Clear Color, add a new modifier as the driver needs to know the
> > > > surface was compressed by render engine.
> > > >
> > > > V2: Description changes as suggested by Rafael.
> > > > V3: Mention the Clear Color size of 64 bits in the comments(DK)
> > > > v4: Fix trailing whitespaces
> > > > v5: Explain Clear Color in the documentation.
> > > > v6: Documentation Nitpicks(Nanley)
> > > >
> > > > Cc: Ville Syrjala 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Kalyan Kondapally 
> > > > Cc: Rafael Antognolli 
> > > > Cc: Nanley Chery 
> > > > Signed-off-by: Radhakrishna Sripada 
> > > > ---
> > > >  

[Intel-gfx] [CI v2] drm/fbdev: Fallback to non tiled mode if all tiles not present

2019-11-13 Thread Manasi Navare
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
if we dont find all the connectors for all tiles, then on a connector
with one tile, just fallback to the first available non tiled mode
to display over a single connector.
On the hotplug of the consecutive tiled connectors, if the tiled mode
no longer exists because of fbcon size limitation, then return
no modes for consecutive tiles but retain the non tiled mode
on the 0th tile.
Use the same logic in case of connected boot case as well.
This has been tested with Dell UP328K tiled monitor.

v2:
* Set the modes on consecutive hotplugged tiles to no mode
if tiled mode is pruned (Dave)
v1:
* Just handle the 1st connector hotplug case
* v1 Reviewed-by: Dave Airlie 

Suggested-by: Ville Syrjälä 
Suggested-by: Dave Airlie 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Signed-off-by: Manasi Navare 
Reviewed-by: Dave Airlie 
---
 drivers/gpu/drm/drm_client_modeset.c | 70 
 1 file changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 895b73f23079..f2150a0bac4c 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -114,6 +114,33 @@ drm_client_find_modeset(struct drm_client_dev *client, 
struct drm_crtc *crtc)
return NULL;
 }
 
+static struct drm_display_mode *
+drm_connector_get_tiled_mode(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, >modes, head) {
+   if (mode->hdisplay == connector->tile_h_size &&
+   mode->vdisplay == connector->tile_v_size)
+   return mode;
+   }
+   return NULL;
+}
+
+static struct drm_display_mode *
+drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, >modes, head) {
+   if (mode->hdisplay == connector->tile_h_size &&
+   mode->vdisplay == connector->tile_v_size)
+   continue;
+   return mode;
+   }
+   return NULL;
+}
+
 static struct drm_display_mode *
 drm_connector_has_preferred_mode(struct drm_connector *connector, int width, 
int height)
 {
@@ -348,8 +375,14 @@ static bool drm_client_target_preferred(struct 
drm_connector **connectors,
struct drm_connector *connector;
u64 conn_configured = 0;
int tile_pass = 0;
+   int num_tiled_conns = 0;
int i;
 
+   for (i = 0; i < connector_count; i++) {
+   if (connectors[i]->has_tile)
+   num_tiled_conns++;
+   }
+
 retry:
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
@@ -399,6 +432,28 @@ static bool drm_client_target_preferred(struct 
drm_connector **connectors,
list_for_each_entry(modes[i], >modes, head)
break;
}
+   /*
+* In case of tiled mode if all tiles not present fallback to
+* first available non tiled mode.
+* After all tiles are present, try to find the tiled mode
+* for all and if tiled mode not present due to fbcon size
+* limitations, use first non tiled mode only for
+* tile 0,0 and set to no mode for all other tiles.
+*/
+   if (connector->has_tile) {
+   if (num_tiled_conns <
+   connector->num_h_tile * connector->num_v_tile ||
+   (connector->tile_h_loc == 0 &&
+connector->tile_v_loc == 0 &&
+!drm_connector_get_tiled_mode(connector))) {
+   DRM_DEBUG_KMS("Falling back to non tiled mode 
on Connector %d\n",
+ connector->base.id);
+   modes[i] = 
drm_connector_fallback_non_tiled_mode(connector);
+   } else {
+   modes[i] = 
drm_connector_get_tiled_mode(connector);
+   }
+   }
+
DRM_DEBUG_KMS("found mode %s\n", modes[i] ? modes[i]->name :
  "none");
conn_configured |= BIT_ULL(i);
@@ -515,6 +570,7 @@ static bool drm_client_firmware_config(struct 
drm_client_dev *client,
bool fallback = true, ret = true;
int num_connectors_enabled = 0;
int num_connectors_detected = 0;
+   int num_tiled_conns = 0;
struct drm_modeset_acquire_ctx ctx;
 
if (!drm_drv_uses_atomic_modeset(dev))
@@ -532,6 +588,10 @@ static bool 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Wa_1606679103

2019-11-13 Thread Chris Wilson
Quoting Radhakrishna Sripada (2019-11-13 19:18:39)
> Extend disabling SAMPLER_STATE prefetch workaround to gen12.
> 
> BSpec: 52890
> Cc: Mika Kuoppala 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index e4bccc14602f..6818d6b3cc90 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1370,11 +1370,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
> GEN7_SARCHKMD,
> GEN7_DISABLE_DEMAND_PREFETCH);
>  
> -   /* Wa_1606682166:icl */
> -   wa_write_or(wal,
> -   GEN7_SARCHKMD,
> -   GEN7_DISABLE_SAMPLER_PREFETCH);
> -
> /* Wa_1409178092:icl */
> wa_write_masked_or(wal,
>GEN11_SCRATCH2,
> @@ -1382,6 +1377,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>0);
> }
>  
> +   if (IS_GEN_RANGE(i915, 11, 12)) {
> +   /* Wa_1606682166:icl,tgl */

Wa_1606679103:tgl

as they insist on giving it a new id.

But this is explicitly A0 only, so IS_TGL_REVID(A0, A0).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase
v9: simplify by using bb end as conditional (Chris)

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
 lib/i830_reg.h  |  3 --
 lib/igt_dummyload.c | 39 +++--
 lib/intel_reg.h |  3 ++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7e..b8ad2ac00 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,9 +43,6 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
-#define MI_DO_COMPARE  (1<<21)
-
 #define MI_BATCH_BUFFER_END(0xA << 23)
 
 /* Noop */
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index b9e239db3..cfd0e75a8 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -75,7 +75,7 @@ emit_recursive_batch(igt_spin_t *spin,
 #define SCRATCH 0
 #define BATCH IGT_SPIN_BATCH
const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_relocation_entry relocs[2], *r;
+   struct drm_i915_gem_relocation_entry relocs[3], *r;
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *obj;
unsigned int flags[GEM_MAX_ENGINES];
@@ -205,7 +205,42 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   /*
+* When using a cmdparser, the batch is copied into a read only location
+* and validated. We are then unable to alter the executing batch,
+* breaking the older *spin->condition = MI_BB_END termination.
+* Instead we can use a conditional MI_BB_END here that looks at
+* the user's copy of the batch and terminates when they modified it,
+* no matter how they modify it (from either the GPU or CPU).
+*/
+   if (gen >= 8) { /* arbitrary cutoff between ring/execlists submission */
+   r = [obj[BATCH].relocation_count++];
+
+   /*
+* On Sandybridge+ the comparison is a strict greater-than:
+* if the value at spin->condition is greater than BB_END,
+* we loop back to the beginning.
+* Beginning with Kabylake, we can select the comparison mode
+* and loop back to the beginning if spin->condition != BB_END
+* (using 5 << 12).
+* For simplicity, we try to stick to a one-size fits all.
+*/
+   spin->condition = batch + BATCH_SIZE / sizeof(*batch) - 1;
+   *spin->condition = 0x;
+
+   r->presumed_offset = 0;
+   r->target_handle = obj[BATCH].handle;
+   r->offset = (cs + 2 - batch) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = (spin->condition - batch) * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 2;
+   *cs++ = MI_BATCH_BUFFER_END;
+   *cs++ = r->delta;
+   *cs++ = 0;
+   }
 
/* recurse */
r = [obj[BATCH].relocation_count++];
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 069440cb7..7b11fedd9 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #define MI_BATCH_BUFFER((0x30 << 23) | 1)
 #define MI_BATCH_BUFFER_START  (0x31 << 23)
 #define MI_BATCH_BUFFER_END(0xA << 23)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
+#define MI_DO_COMPARE   (1 << 21)
+
 #define MI_BATCH_NON_SECURE(1)
 #define MI_BATCH_NON_SECURE_I965   (1 << 8)
 #define MI_BATCH_NON_SECURE_HSW(1<<13) /* Additional bit for 
RCS */
diff --git a/tests/i915/gem_double_irq_loop.c 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 20:20:31)
> From: Jon Bloomfield 
> 
> gen9+ introduces a cmdparser for the BLT engine which copies the
> incoming BB to a kmd owned buffer for submission (to prevent changes
> being made after the bb has been safely scanned). This breaks the
> spin functionality because it relies on changing the submitted spin
> buffers in order to terminate them.
> 
> Instead, for gen9+, we change the semantics by introducing a COND_BB_END
> into the infinite loop, to wait until a memory flag (in anothe bo) is
> cleared.
> 
> v2: Correct nop length to avoid overwriting bb_end instr when using
> a dependency bo (cork)
> v3: fix conflicts on igt_dummyload (Mika)
> v4: s/bool running/uint32_t running, fix r->delta (Mika)
> v5: remove overzealous assert (Mika)
> v6: rebase on top of lib changes (Mika)
> v7: rework on top of public igt lib changes (Mika)
> v8: rebase
> v9: simplify by using bb end as conditional (Chris)
> 
> Signed-off-by: Jon Bloomfield  (v2)
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Mika Kuoppala 
> Signed-off-by: Mika Kuoppala 
> ---
> Compile after rebase!
> ---
>  lib/i830_reg.h  |  2 +-
>  lib/igt_dummyload.c | 27 +++--
>  lib/intel_reg.h |  3 +++
>  tests/i915/gem_double_irq_loop.c|  2 --
>  tests/i915/gem_write_read_ring_switch.c |  2 +-
>  5 files changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/i830_reg.h b/lib/i830_reg.h
> index a57691c7e..410202567 100644
> --- a/lib/i830_reg.h
> +++ b/lib/i830_reg.h
> @@ -43,7 +43,7 @@
>  /* broadwater flush bits */
>  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
>  
> -#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
> +#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
>  #define MI_DO_COMPARE  (1<<21)
>  
>  #define MI_BATCH_BUFFER_END(0xA << 23)
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index b9e239db3..563a451da 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -75,7 +75,7 @@ emit_recursive_batch(igt_spin_t *spin,
>  #define SCRATCH 0
>  #define BATCH IGT_SPIN_BATCH
> const int gen = intel_gen(intel_get_drm_devid(fd));
> -   struct drm_i915_gem_relocation_entry relocs[2], *r;
> +   struct drm_i915_gem_relocation_entry relocs[3], *r;
> struct drm_i915_gem_execbuffer2 *execbuf;
> struct drm_i915_gem_exec_object2 *obj;
> unsigned int flags[GEM_MAX_ENGINES];
> @@ -205,7 +205,30 @@ emit_recursive_batch(igt_spin_t *spin,
>  * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
>  */
> if (!(opts->flags & IGT_SPIN_FAST))
> -   cs += 1000;
> +   cs += 960;
> +
> +   /*
> +* When using a cmdparser, the batch is copied into a read only 
> location
> +* and validated. We are then unable to alter the executing batch,
> +* breaking the older *spin->condition = MI_BB_END termination.
> +* Instead we can use a conditional MI_BB_END here that looks at
> +* the user's copy of the batch and terminates when they modified it,
> +* no matter how they modify it (from either the GPU or CPU).
> +*/
> +   if (gen >= 9) {
> +   r = [obj[BATCH].relocation_count++];
> +
> +   r->presumed_offset = 0;
> +   r->target_handle = obj[BATCH].handle;
> +   r->offset = (cs + 2 - batch) * sizeof(*cs);
> +   r->read_domains = I915_GEM_DOMAIN_COMMAND;
> +   r->delta = (spin->condition - batch) * sizeof(*cs);
> +
> +   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;

Great the magic 5<<12 worked on kbl in testing, but we did not fare so
lucky on skl! One slight adjustment later...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_mocs_settings: Update TGL MOCS table

2019-11-13 Thread Lucas De Marchi

On Wed, Nov 13, 2019 at 08:51:03AM -0800, Matt Roper wrote:

The TGL MOCS table was corrected in the bspec and the kernel.  Since
this test hardcodes its own copy of the MOCS table, we need to make
corresponding fixes here.

References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
References: bfb0e8e63d86 ("drm/i915/tgl: MOCS table update")
Cc: Prathap Kumar Valsan 
Cc: Lucas De Marchi 
Cc: Francisco Jerez 
Cc: Tomasz Lis 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
tests/i915/gem_mocs_settings.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/i915/gem_mocs_settings.c b/tests/i915/gem_mocs_settings.c
index fc2ccb21..8f8f0768 100644
--- a/tests/i915/gem_mocs_settings.c
+++ b/tests/i915/gem_mocs_settings.c
@@ -95,8 +95,6 @@ static const struct mocs_entry 
tigerlake_mocs_table[GEN11_NUM_MOCS_ENTRIES] = {
[13] = { 0x0057, 0x0030, 0x1},
[14] = { 0x0067, 0x0010, 0x1},
[15] = { 0x0067, 0x0030, 0x1},
-   [16] = { 0x4005, 0x0010, 0x1},
-   [17] = { 0x4005, 0x0030, 0x1},
[18] = { 0x00060037, 0x0030, 0x1},
[19] = { 0x0737, 0x0030, 0x1},
[20] = { 0x0337, 0x0030, 0x1},
@@ -108,7 +106,7 @@ static const struct mocs_entry 
tigerlake_mocs_table[GEN11_NUM_MOCS_ENTRIES] = {
[50] = { 0x0037, 0x0010, 0x1},
[51] = { 0x0005, 0x0010, 0x1},
[60] = { 0x0037, 0x0010, 0x1},
-   [61] = { 0x4005, 0x0030, 0x1},
+   [61] = { 0x0005, 0x0030, 0x1},
[62] = { 0x0037, 0x0010, 0x1},
[63] = { 0x0037, 0x0010, 0x1},
};
--
2.21.0


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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display: Fix TRANS_DDI_MST_TRANSPORT_SELECT definition

2019-11-13 Thread Souza, Jose
On Sat, 2019-11-09 at 10:47 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915/display: Fix
> TRANS_DDI_MST_TRANSPORT_SELECT definition
> URL   : https://patchwork.freedesktop.org/series/69160/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7290_full -> Patchwork_15187_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.


Pushed to dinq, thanks for the reviews Lucas.

>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_15187_full that come from
> known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@bcs0-s3:
> - shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#108566])
> +3 similar issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-apl2/igt@gem_ctx_isolat...@bcs0-s3.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html
> 
>   * igt@gem_ctx_isolation@vcs1-dirty-create:
> - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] /
> [fdo#112080]) +1 similar issue
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-iclb7/igt@gem_ctx_isolat...@vcs1-dirty-create.html
> 
>   * igt@gem_ctx_isolation@vcs1-s3:
> - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111832])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-tglb4/igt@gem_ctx_isolat...@vcs1-s3.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-tglb5/igt@gem_ctx_isolat...@vcs1-s3.html
> 
>   * igt@gem_ctx_switch@vcs1-heavy:
> - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +3
> similar issues
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-iclb2/igt@gem_ctx_swi...@vcs1-heavy.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-iclb5/igt@gem_ctx_swi...@vcs1-heavy.html
> 
>   * igt@gem_eio@suspend:
> - shard-tglb: [PASS][9] -> [INCOMPLETE][10]
> ([fdo#111850])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-tglb3/igt@gem_...@suspend.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-tglb3/igt@gem_...@suspend.html
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-snb:  [PASS][11] -> [FAIL][12] ([fdo#109661])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-snb6/igt@gem_...@unwedge-stress.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-snb1/igt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_balancer@smoke:
> - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#110854])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-iclb4/igt@gem_exec_balan...@smoke.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-iclb5/igt@gem_exec_balan...@smoke.html
> 
>   * igt@gem_exec_nop@basic-parallel:
> - shard-tglb: [PASS][15] -> [INCOMPLETE][16]
> ([fdo#111747])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-tglb2/igt@gem_exec_...@basic-parallel.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-tglb7/igt@gem_exec_...@basic-parallel.html
> 
>   * igt@gem_exec_schedule@preempt-queue-bsd1:
> - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109276]) +9
> similar issues
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd1.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html
> 
>   * igt@gem_exec_schedule@preemptive-hang-bsd:
> - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +4
> similar issues
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html
> 
>   * igt@gem_sync@basic-all:
> - shard-kbl:  [PASS][21] -> [DMESG-WARN][22]
> ([fdo#103558] / [fdo#105602]) +2 similar issues
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-kbl7/igt@gem_s...@basic-all.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15187/shard-kbl2/igt@gem_s...@basic-all.html
> 
>   * igt@gem_userptr_blits@dmabuf-unsync:
> - shard-snb:  [PASS][23] -> [DMESG-WARN][24]
> ([fdo#111870])
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7290/shard-snb7/igt@gem_userptr_bl...@dmabuf-unsync.html
>[24]: 
> 

Re: [Intel-gfx] [PATCH v6] drm/i915: Enable second dbuf slice for ICL and TGL

2019-11-13 Thread Matt Roper
On Fri, Nov 08, 2019 at 03:45:00PM +0200, Stanislav Lisovskiy wrote:
> Also implemented algorithm for choosing DBuf slice configuration
> based on active pipes, pipe ratio as stated in BSpec 12716.
> 
> Now pipe allocation still stays proportional to pipe width as before,
> however within allowed DBuf slice for this particular configuration.
> 
> v2: Remove unneeded check from commit as ddb enabled slices might
> now differ from hw state.
> 
> v3: - Added new field "supported_slices" to ddb to separate max
>   supported slices vs currently enabled, to avoid confusion.
> - Removed obsolete comments and code related to DBuf(Matthew Roper).
> - Some code style and long line removal(Matthew Roper).
> - Added WARN_ON to new ddb range offset calc function(Matthew Roper).
> - Removed platform specific call to calc pipe ratio from ddb
>   allocation function and fixed the return value(Matthew Roper)
> - Refactored DBUF slice allocation table to improve readability
> - Added DBUF slice allocation for TGL as well.
> - ICL(however not TGL) seems to voluntarily enable second DBuf slice
>   after pm suspend/resume causing a mismatch failure, because we
>   update DBuf slices only if we do a modeset, however this check
>   is done always. Fixed it to be done only when modeset for ICL.
> 
> v4: - Now enabled slices is not actually a number, but a bitmask,
>   because we might need to enable second slice only and number
>   of slices would still 1 and that current code doesn't allow.
> - Remove redundant duplicate code to have some unified way of
>   enabling dbuf slices instead of hardcoding.
> 
> v5: - Fix failing gen9_assert_dbuf_enabled as it was naively thinking
>   that we have only one DBUF_CTL slice. Now another version for
>   gen11 will check both slices as only second one can be enabled,
>   to keep CI happy.
> 
> v6: - Removed enabled dbuf assertion completely. Previous code
>   was keeping dbuf enabled, even(!) when _dbuf_disable is called.
>   Currently we enable/disable dbuf slices based on requrement
>   so no point in asserting this here.
> - Removed unnecessary modeset check from verify_wm_state(Matthew Roper)
> - Slices intersection after union is same as final result(Matthew Roper)
> - Moved DBuf slices to intel_device_info(Matthew Roper)
> - Some macros added(Matthew Roper)
> - ddb range is now always less or equal to ddb size - no need for 
> additional
>   checks(previously needed as we had some bandwidth checks in there which
>   could "suddenly" return ddb_size smaller than it is.
> 
> Signed-off-by: Stanislav Lisovskiy 
> Cc: Matthew Roper 
> Cc: Ville Syrjälä 
> Cc: James Ausmus 

A handful of comments inline below but most of them are cosmetic, so
I'll leave it up to you whether you agree or not.  The only one I see
that doesn't appear to match the spec is on your TGL pipe A+B dbuf
assignment.

Otherwise,

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  26 +-
>  .../drm/i915/display/intel_display_power.c|  98 ++---
>  .../drm/i915/display/intel_display_power.h|   2 +
>  drivers/gpu/drm/i915/i915_drv.c   |   5 +
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   7 +-
>  drivers/gpu/drm/i915/i915_reg.h   |   8 +-
>  drivers/gpu/drm/i915/intel_device_info.h  |   1 +
>  drivers/gpu/drm/i915/intel_pm.c   | 384 --
>  9 files changed, 429 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 876fc25968bf..bd7aff675198 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13387,7 +13387,7 @@ static void verify_wm_state(struct intel_crtc *crtc,
>  
>   if (INTEL_GEN(dev_priv) >= 11 &&
>   hw->ddb.enabled_slices != sw_ddb->enabled_slices)
> - DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
> + DRM_ERROR("mismatch in DBUF Slices (expected %x, got %x)\n",
> sw_ddb->enabled_slices,
> hw->ddb.enabled_slices);
>  
> @@ -14614,15 +14614,24 @@ static void skl_commit_modeset_enables(struct 
> intel_atomic_state *state)
>   u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
>   u8 required_slices = state->wm_results.ddb.enabled_slices;
>   struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
> + u8 slices_union = hw_enabled_slices | required_slices;
> + u8 slices_intersection = required_slices;

We can probably just drop this variable and use required_slices directly
in the one place below.

>  
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i)
>   /* ignore allocations for crtc's that have been 

[Intel-gfx] [PULL] drm-misc-next-fixes

2019-11-13 Thread Sean Paul

Hi Dave & Daniel,
Just one msm patch this week. Looks like -misc is going to be perfect when merge
window rolls around :-)


drm-misc-next-fixes-2019-11-13:
- Fix memory leak in gpu debugfs node's release (Johan)

Cc: Johan Hovold 

Cheers, Sean


The following changes since commit 3ca3a9eab7085b3c938b5d088c3020269cfecdc8:

  Merge tag 'drm-misc-next-fixes-2019-11-06' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-11-08 16:48:22 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-11-13

for you to fetch changes up to a64fc11b9a520c55ca34d82e5ca32274f49b6b15:

  drm/msm: fix memleak on release (2019-11-13 15:34:15 -0500)


- Fix memory leak in gpu debugfs node's release (Johan)

Cc: Johan Hovold 


Johan Hovold (1):
  drm/msm: fix memleak on release

 drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_blits: Use common igt_fls()

2019-11-13 Thread Summers, Stuart
On Sat, 2019-11-09 at 15:10 +, Chris Wilson wrote:
> igt_aux.h already provides the optimal igt_fls(), so use that in
> preference to open coding the brute force version.
> 
> Reported-by: Stuart Summers 
> Signed-off-by: Chris Wilson 
> Cc: Stuart Summers 

Thanks for the look here Chris :)

-Stuart

> ---
>  tests/i915/gem_blits.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/tests/i915/gem_blits.c b/tests/i915/gem_blits.c
> index e0346a7c7..f9cb12bb8 100644
> --- a/tests/i915/gem_blits.c
> +++ b/tests/i915/gem_blits.c
> @@ -57,16 +57,6 @@ enum mode {
>   WC,
>  };
>  
> -static int fls(uint64_t x)
> -{
> - int t;
> -
> - for (t = 0; x >> t; t++)
> - ;
> -
> - return t;
> -}
> -
>  static unsigned int
>  get_tiling_stride(const struct device *device,
> unsigned int width, unsigned int tiling)
> @@ -81,7 +71,7 @@ get_tiling_stride(const struct device *device,
>   else
>   stride = ALIGN(stride, 128);
>   if (device->gen < 4)
> - stride = 1 << fls(stride - 1);
> + stride = 1 << igt_fls(stride - 1);
>   } else {
>   if (device->gen >= 8)
>   stride = ALIGN(stride, 64);


smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase
v9: simplify by using bb end as conditional (Chris)

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
Compile after rebase!
---
 lib/i830_reg.h  |  2 +-
 lib/igt_dummyload.c | 27 +++--
 lib/intel_reg.h |  3 +++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 5 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7e..410202567 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,7 +43,7 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
 #define MI_DO_COMPARE  (1<<21)
 
 #define MI_BATCH_BUFFER_END(0xA << 23)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index b9e239db3..563a451da 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -75,7 +75,7 @@ emit_recursive_batch(igt_spin_t *spin,
 #define SCRATCH 0
 #define BATCH IGT_SPIN_BATCH
const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_relocation_entry relocs[2], *r;
+   struct drm_i915_gem_relocation_entry relocs[3], *r;
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *obj;
unsigned int flags[GEM_MAX_ENGINES];
@@ -205,7 +205,30 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   /*
+* When using a cmdparser, the batch is copied into a read only location
+* and validated. We are then unable to alter the executing batch,
+* breaking the older *spin->condition = MI_BB_END termination.
+* Instead we can use a conditional MI_BB_END here that looks at
+* the user's copy of the batch and terminates when they modified it,
+* no matter how they modify it (from either the GPU or CPU).
+*/
+   if (gen >= 9) {
+   r = [obj[BATCH].relocation_count++];
+
+   r->presumed_offset = 0;
+   r->target_handle = obj[BATCH].handle;
+   r->offset = (cs + 2 - batch) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = (spin->condition - batch) * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;
+   *cs++ = MI_BATCH_BUFFER_END;
+   *cs++ = r->delta;
+   *cs++ = 0;
+   }
 
/* recurse */
r = [obj[BATCH].relocation_count++];
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 069440cb7..10ca760a2 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #define MI_BATCH_BUFFER((0x30 << 23) | 1)
 #define MI_BATCH_BUFFER_START  (0x31 << 23)
 #define MI_BATCH_BUFFER_END(0xA << 23)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
+#define MI_DO_COMPARE   (1<<21)
+
 #define MI_BATCH_NON_SECURE(1)
 #define MI_BATCH_NON_SECURE_I965   (1 << 8)
 #define MI_BATCH_NON_SECURE_HSW(1<<13) /* Additional bit for 
RCS */
diff --git a/tests/i915/gem_double_irq_loop.c b/tests/i915/gem_double_irq_loop.c
index b326fc58a..f17f61c19 100644
--- a/tests/i915/gem_double_irq_loop.c
+++ b/tests/i915/gem_double_irq_loop.c
@@ -52,8 +52,6 @@ static drm_intel_bo *target_buffer, *blt_bo;
 IGT_TEST_DESCRIPTION("Basic check for missed IRQs on blt ring.");
 
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
-#define MI_DO_COMPARE  (1<<21)
 static void
 dummy_reloc_loop(void)
 {
diff --git a/tests/i915/gem_write_read_ring_switch.c 
b/tests/i915/gem_write_read_ring_switch.c
index ef229cc59..095c13c34 100644
--- a/tests/i915/gem_write_read_ring_switch.c
+++ b/tests/i915/gem_write_read_ring_switch.c

[Intel-gfx] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase
v9: simplify by using bb end as conditional (Chris)

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
 lib/i830_reg.h  |  2 +-
 lib/igt_dummyload.c | 24 +++-
 lib/intel_reg.h |  3 +++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 5 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7e..410202567 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,7 +43,7 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
 #define MI_DO_COMPARE  (1<<21)
 
 #define MI_BATCH_BUFFER_END(0xA << 23)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index b9e239db3..f5855376a 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -205,7 +205,29 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   /*
+* When using a cmdparser, the batch is copied into a read only location
+* and validated. We are then unable to alter the executing batch,
+* breaking the older *spin->condition = MI_BB_END termination.
+* Instead we can use a conditional MI_BB_END here that looks at
+* the user's copy of the batch and terminates when they modified it.
+*/
+   if (gen >= 9) {
+   r = [batch->relocation_count++];
+
+   r->presumed_offset = 0;
+   r->target_handle = batch->handle;
+   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = (spin->condition - batch_start) * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;
+   *cs++ = MI_BATCH_BUFFER_END;
+   *cs++ = r->delta;
+   *cs++ = 0;
+   }
 
/* recurse */
r = [obj[BATCH].relocation_count++];
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 069440cb7..10ca760a2 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #define MI_BATCH_BUFFER((0x30 << 23) | 1)
 #define MI_BATCH_BUFFER_START  (0x31 << 23)
 #define MI_BATCH_BUFFER_END(0xA << 23)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
+#define MI_DO_COMPARE   (1<<21)
+
 #define MI_BATCH_NON_SECURE(1)
 #define MI_BATCH_NON_SECURE_I965   (1 << 8)
 #define MI_BATCH_NON_SECURE_HSW(1<<13) /* Additional bit for 
RCS */
diff --git a/tests/i915/gem_double_irq_loop.c b/tests/i915/gem_double_irq_loop.c
index b326fc58a..f17f61c19 100644
--- a/tests/i915/gem_double_irq_loop.c
+++ b/tests/i915/gem_double_irq_loop.c
@@ -52,8 +52,6 @@ static drm_intel_bo *target_buffer, *blt_bo;
 IGT_TEST_DESCRIPTION("Basic check for missed IRQs on blt ring.");
 
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
-#define MI_DO_COMPARE  (1<<21)
 static void
 dummy_reloc_loop(void)
 {
diff --git a/tests/i915/gem_write_read_ring_switch.c 
b/tests/i915/gem_write_read_ring_switch.c
index ef229cc59..095c13c34 100644
--- a/tests/i915/gem_write_read_ring_switch.c
+++ b/tests/i915/gem_write_read_ring_switch.c
@@ -115,7 +115,7 @@ static void run_test(int ring)
 * otherwise the obj->last_write_seqno will be updated. */
if (ring == I915_EXEC_RENDER) {
BEGIN_BATCH(4, 1);
-   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 1);
OUT_BATCH(0x); /* compare dword */
OUT_RELOC(target_bo, I915_GEM_DOMAIN_RENDER, 0, 0);
OUT_BATCH(MI_NOOP);
-- 
2.24.0


Re: [Intel-gfx] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Bloomfield, Jon
> -Original Message-
> From: Chris Wilson 
> Sent: Wednesday, November 13, 2019 11:47 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Bloomfield, Jon ; Lahtinen, Joonas
> ; Vivi, Rodrigo ;
> Kuoppala, Mika ; Mika Kuoppala
> 
> Subject: [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9
> 
> From: Jon Bloomfield 
> 
> gen9+ introduces a cmdparser for the BLT engine which copies the
> incoming BB to a kmd owned buffer for submission (to prevent changes
> being made after the bb has been safely scanned). This breaks the
> spin functionality because it relies on changing the submitted spin
> buffers in order to terminate them.
> 
> Instead, for gen9+, we change the semantics by introducing a COND_BB_END
> into the infinite loop, to wait until a memory flag (in anothe bo) is
> cleared.
> 
> v2: Correct nop length to avoid overwriting bb_end instr when using
> a dependency bo (cork)
> v3: fix conflicts on igt_dummyload (Mika)
> v4: s/bool running/uint32_t running, fix r->delta (Mika)
> v5: remove overzealous assert (Mika)
> v6: rebase on top of lib changes (Mika)
> v7: rework on top of public igt lib changes (Mika)
> v8: rebase
> v9: simplify by using bb end as conditional (Chris)
> 
> Signed-off-by: Jon Bloomfield  (v2)
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Mika Kuoppala 
> Signed-off-by: Mika Kuoppala 
> ---
>  lib/i830_reg.h  |  2 +-
>  lib/igt_dummyload.c | 24 +++-
>  lib/intel_reg.h |  3 +++
>  tests/i915/gem_double_irq_loop.c|  2 --
>  tests/i915/gem_write_read_ring_switch.c |  2 +-
>  5 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/i830_reg.h b/lib/i830_reg.h
> index a57691c7e..410202567 100644
> --- a/lib/i830_reg.h
> +++ b/lib/i830_reg.h
> @@ -43,7 +43,7 @@
>  /* broadwater flush bits */
>  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
> 
> -#define MI_COND_BATCH_BUFFER_END (0x36<<23 | 1)
> +#define MI_COND_BATCH_BUFFER_END (0x36 << 23)
>  #define MI_DO_COMPARE(1<<21)
> 
>  #define MI_BATCH_BUFFER_END  (0xA << 23)
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index c079bd045..93b8b6bc6 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -208,7 +208,29 @@ emit_recursive_batch(igt_spin_t *spin,
>* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
>*/
>   if (!(opts->flags & IGT_SPIN_FAST))
> - cs += 1000;
> + cs += 960;
> +
> + /*
> +  * When using a cmdparser, the batch is copied into a read only
> location
> +  * and validated. We are then unable to alter the executing batch,
> +  * breaking the older *spin->condition = MI_BB_END termination.
> +  * Instead we can use a conditional MI_BB_END here that looks at
> +  * the user's copy of the batch and terminates when they modified it.
> +  */
> + if (gen >= 9) {
> + r = [batch->relocation_count++];
> +
> + r->presumed_offset = 0;
> + r->target_handle = batch->handle;
> + r->offset = (cs + 2 - batch_start) * sizeof(*cs);
> + r->read_domains = I915_GEM_DOMAIN_COMMAND;
> + r->delta = (spin->condition - batch_start) * sizeof(*cs);
> +
> + *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 |
> 2;
> + *cs++ = MI_BATCH_BUFFER_END;
> + *cs++ = r->delta;
> + *cs++ = 0;
> + }
> 
>   /* recurse */
>   r = [batch->relocation_count++];
> diff --git a/lib/intel_reg.h b/lib/intel_reg.h
> index 069440cb7..10ca760a2 100644
> --- a/lib/intel_reg.h
> +++ b/lib/intel_reg.h
> @@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE SOFTWARE.
>  #define MI_BATCH_BUFFER  ((0x30 << 23) | 1)
>  #define MI_BATCH_BUFFER_START(0x31 << 23)
>  #define MI_BATCH_BUFFER_END  (0xA << 23)
> +#define MI_COND_BATCH_BUFFER_END (0x36 << 23)
> +#define MI_DO_COMPARE   (1<<21)
> +
>  #define MI_BATCH_NON_SECURE  (1)
>  #define MI_BATCH_NON_SECURE_I965 (1 << 8)
>  #define MI_BATCH_NON_SECURE_HSW  (1<<13) /* Additional
> bit for RCS */
> diff --git a/tests/i915/gem_double_irq_loop.c
> b/tests/i915/gem_double_irq_loop.c
> index b326fc58a..f17f61c19 100644
> --- a/tests/i915/gem_double_irq_loop.c
> +++ b/tests/i915/gem_double_irq_loop.c
> @@ -52,8 +52,6 @@ static drm_intel_bo *target_buffer, *blt_bo;
>  IGT_TEST_DESCRIPTION("Basic check for missed IRQs on blt ring.");
> 
> 
> -#define MI_COND_BATCH_BUFFER_END (0x36<<23 | 1)
> -#define MI_DO_COMPARE(1<<21)
>  static void
>  dummy_reloc_loop(void)
>  {
> diff --git a/tests/i915/gem_write_read_ring_switch.c
> b/tests/i915/gem_write_read_ring_switch.c
> index ef229cc59..095c13c34 100644
> --- a/tests/i915/gem_write_read_ring_switch.c
> +++ b/tests/i915/gem_write_read_ring_switch.c
> @@ -115,7 +115,7 @@ static void 

Re: [Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Chris Wilson
Quoting Bruce Chang (2019-11-13 19:52:44)
> There are quite a few reports regarding "BUG: sleeping function called from
> invalid context at mm/page_alloc.c"
> 
> Basically after the io_mapping_map_atomic_wc/kmap_atomic, it enters atomic
> context, but compress_page cannot be called in atomic context as it will
> call pool_alloc with GFP_KERNEL flag which can go to sleep. This is why
> the bug got reported.

Just a trimmed stack trace showing the bug will do fine; as the distance
to might_sleep_if() is short.

Then all you need to do is a quick description of why that is a problem,
and why you choose to fix it as you did. The latter is so that we can
assess if you've considered the alternatives, though in this case it is
trivial although the reason why GFP_KERNEL works for us here is not.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree (rev2)

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Split i915_active.mutex into an irq-safe spinlock for the 
rbtree (rev2)
URL   : https://patchwork.freedesktop.org/series/69399/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7332 -> Patchwork_15253


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic:
- fi-icl-guc: [PASS][3] -> [FAIL][4] ([fdo#111699])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-icl-guc/igt@gem_exec_susp...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-icl-guc/igt@gem_exec_susp...@basic.html

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [PASS][5] -> [DMESG-FAIL][6] ([fdo#112147])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([fdo#109635 ])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][9] -> [WARN][10] ([fdo#112252])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

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

  * igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[DMESG-WARN][13] ([fdo#112261]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-skl-lmem/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r:   [DMESG-FAIL][15] ([fdo#111991]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][17] ([fdo#111407]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15253/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
  [fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
  [fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (52 -> 45)

[Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Bruce Chang
There are quite a few reports regarding "BUG: sleeping function called from
invalid context at mm/page_alloc.c"

Basically after the io_mapping_map_atomic_wc/kmap_atomic, it enters atomic
context, but compress_page cannot be called in atomic context as it will
call pool_alloc with GFP_KERNEL flag which can go to sleep. This is why
the bug got reported.

So, changed to non atomic version instead.

Signed-off-by: Bruce Chang 
Reviewed-by: Brian Welty 
Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 1f2f266f26af..7118ecb7f144 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private *i915,
compress->wc = i915_gem_object_is_lmem(vma->obj) ||
   drm_mm_node_allocated(>error_capture);
 
ret = -EINVAL;
if (drm_mm_node_allocated(>error_capture)) {
void __iomem *s;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
ggtt->vm.insert_page(>vm, dma, slot,
 I915_CACHE_NONE, 0);
 
s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
ret = compress_page(compress, (void  __force *)s, dst);
io_mapping_unmap(s);
if (ret)
break;
}
} else if (i915_gem_object_is_lmem(vma->obj)) {
struct intel_memory_region *mem = vma->obj->mm.region;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
void __iomem *s;
 
-   s = io_mapping_map_atomic_wc(>iomap, dma);
+   s = io_mapping_map_wc(>iomap, dma, PAGE_SIZE);
ret = compress_page(compress, (void __force *)s, dst);
-   io_mapping_unmap_atomic(s);
+   io_mapping_unmap(s);
if (ret)
break;
}
} else {
struct page *page;
 
for_each_sgt_page(page, iter, vma->pages) {
void *s;
 
drm_clflush_pages(, 1);
 
-   s = kmap_atomic(page);
+   s = kmap(page);
ret = compress_page(compress, s, dst);
-   kunmap_atomic(s);
+   kunmap(s);
 
drm_clflush_pages(, 1);
 
if (ret)
break;
}
}
 
if (ret || compress_flush(compress, dst)) {
while (dst->page_count--)
pool_free(>pool, dst->pages[dst->page_count]);
kfree(dst);
dst = NULL;
}
compress_finish(compress);
 
return dst;
 }
 
 /*
  * Generate a semi-unique error code. The code is not meant to have meaning, 
The
  * code's only purpose is to try to prevent false duplicated bug reports by
  * grossly estimating a GPU error state.
  *
  * TODO Ideally, hashing the batchbuffer would be a very nice way to determine
-- 
2.24.0

___
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_create: Check for cache bypass around zeroed pages

2019-11-13 Thread Matthew Auld
On Wed, 13 Nov 2019 at 14:05, Chris Wilson  wrote:
>
> Check that even if userspace tries to sneak around the CPU caches of its
> zeroed pages, it sees nothing but zeroes.
>
> Suggested-by: Joonas Lahtinen 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase
v9: simplify by using bb end as conditional (Chris)

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
 lib/i830_reg.h  |  2 +-
 lib/igt_dummyload.c | 24 +++-
 lib/intel_reg.h |  3 +++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 5 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7e..410202567 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,7 +43,7 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
 #define MI_DO_COMPARE  (1<<21)
 
 #define MI_BATCH_BUFFER_END(0xA << 23)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index c079bd045..93b8b6bc6 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -208,7 +208,29 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   /*
+* When using a cmdparser, the batch is copied into a read only location
+* and validated. We are then unable to alter the executing batch,
+* breaking the older *spin->condition = MI_BB_END termination.
+* Instead we can use a conditional MI_BB_END here that looks at
+* the user's copy of the batch and terminates when they modified it.
+*/
+   if (gen >= 9) {
+   r = [batch->relocation_count++];
+
+   r->presumed_offset = 0;
+   r->target_handle = batch->handle;
+   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = (spin->condition - batch_start) * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;
+   *cs++ = MI_BATCH_BUFFER_END;
+   *cs++ = r->delta;
+   *cs++ = 0;
+   }
 
/* recurse */
r = [batch->relocation_count++];
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 069440cb7..10ca760a2 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #define MI_BATCH_BUFFER((0x30 << 23) | 1)
 #define MI_BATCH_BUFFER_START  (0x31 << 23)
 #define MI_BATCH_BUFFER_END(0xA << 23)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
+#define MI_DO_COMPARE   (1<<21)
+
 #define MI_BATCH_NON_SECURE(1)
 #define MI_BATCH_NON_SECURE_I965   (1 << 8)
 #define MI_BATCH_NON_SECURE_HSW(1<<13) /* Additional bit for 
RCS */
diff --git a/tests/i915/gem_double_irq_loop.c b/tests/i915/gem_double_irq_loop.c
index b326fc58a..f17f61c19 100644
--- a/tests/i915/gem_double_irq_loop.c
+++ b/tests/i915/gem_double_irq_loop.c
@@ -52,8 +52,6 @@ static drm_intel_bo *target_buffer, *blt_bo;
 IGT_TEST_DESCRIPTION("Basic check for missed IRQs on blt ring.");
 
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
-#define MI_DO_COMPARE  (1<<21)
 static void
 dummy_reloc_loop(void)
 {
diff --git a/tests/i915/gem_write_read_ring_switch.c 
b/tests/i915/gem_write_read_ring_switch.c
index ef229cc59..095c13c34 100644
--- a/tests/i915/gem_write_read_ring_switch.c
+++ b/tests/i915/gem_write_read_ring_switch.c
@@ -115,7 +115,7 @@ static void run_test(int ring)
 * otherwise the obj->last_write_seqno will be updated. */
if (ring == I915_EXEC_RENDER) {
BEGIN_BATCH(4, 1);
-   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 1);
OUT_BATCH(0x); /* compare dword */
OUT_RELOC(target_bo, I915_GEM_DOMAIN_RENDER, 0, 0);
OUT_BATCH(MI_NOOP);
-- 
2.24.0


Re: [Intel-gfx] [PATCH i-g-t 3/3] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:42:06)
> Quoting Chris Wilson (2019-11-13 18:28:08)
> > From: Jon Bloomfield 
> > 
> > gen9+ introduces a cmdparser for the BLT engine which copies the
> > incoming BB to a kmd owned buffer for submission (to prevent changes
> > being made after the bb has been safely scanned). This breaks the
> > spin functionality because it relies on changing the submitted spin
> > buffers in order to terminate them.
> > 
> > Instead, for gen9+, we change the semantics by introducing a COND_BB_END
> > into the infinite loop, to wait until a memory flag (in anothe bo) is
> > cleared.
> > 
> > v2: Correct nop length to avoid overwriting bb_end instr when using
> > a dependency bo (cork)
> > v3: fix conflicts on igt_dummyload (Mika)
> > v4: s/bool running/uint32_t running, fix r->delta (Mika)
> > v5: remove overzealous assert (Mika)
> > v6: rebase on top of lib changes (Mika)
> > v7: rework on top of public igt lib changes (Mika)
> > v8: rebase
> > v9: simplify by using bb end as conditional (Chris)
> > 
> > Signed-off-by: Jon Bloomfield  (v2)
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: Mika Kuoppala 
> > Signed-off-by: Mika Kuoppala 
> > ---
> >  lib/i830_reg.h  |  2 +-
> >  lib/igt_dummyload.c | 17 -
> >  lib/intel_reg.h |  3 +++
> >  tests/i915/gem_double_irq_loop.c|  2 --
> >  tests/i915/gem_write_read_ring_switch.c |  2 +-
> >  5 files changed, 21 insertions(+), 5 deletions(-)
> > 
> > diff --git a/lib/i830_reg.h b/lib/i830_reg.h
> > index a57691c7e..410202567 100644
> > --- a/lib/i830_reg.h
> > +++ b/lib/i830_reg.h
> > @@ -43,7 +43,7 @@
> >  /* broadwater flush bits */
> >  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
> >  
> > -#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
> > +#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
> >  #define MI_DO_COMPARE  (1<<21)
> >  
> >  #define MI_BATCH_BUFFER_END(0xA << 23)
> > diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> > index c079bd045..652d469a0 100644
> > --- a/lib/igt_dummyload.c
> > +++ b/lib/igt_dummyload.c
> > @@ -208,7 +208,22 @@ emit_recursive_batch(igt_spin_t *spin,
> >  * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
> >  */
> > if (!(opts->flags & IGT_SPIN_FAST))
> > -   cs += 1000;
> > +   cs += 960;
> > +
> > +   if (gen >= 8) {
> 
> If we push this back to gen>7 it will allow us to use it with its
> cmdparser as well.
> 
> Hmm? I guess we could just do gen>6 so that there's some systematic
> cutoff point.

Oh, well, it appears the magic compare mode doesn't exist until Skylake.
Fortunately, it exists!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-13 Thread Brian Welty


On 11/12/2019 4:28 PM, Bruce Chang wrote:
> There are quite a few reports regarding "BUG: sleeping function called from
> invalid context at mm/page_alloc.c"
> 
> Basically after the io_mapping_map_atomic_wc/kmap_atomic, it enters atomic
> context, but compress_page cannot be called in atomic context as it will
> call pool_alloc with GFP_KERNEL flag which can go to sleep. This is why
> the bug got reported.
> 
> So, changed to non atomic version instead.

The atomic functions were recently added, so seems worth a note that 
you are fixing that patch by adding:
Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")

And your fix here looks correct to me, so:
Reviewed-by: Brian Welty 


> 
> Signed-off-by: Bruce Chang 
> ---
>  drivers/gpu/drm/i915/i915_gpu_error.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 1f2f266f26af..7118ecb7f144 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private 
> *i915,
>   compress->wc = i915_gem_object_is_lmem(vma->obj) ||
>  drm_mm_node_allocated(>error_capture);
>  
>   ret = -EINVAL;
>   if (drm_mm_node_allocated(>error_capture)) {
>   void __iomem *s;
>   dma_addr_t dma;
>  
>   for_each_sgt_daddr(dma, iter, vma->pages) {
>   ggtt->vm.insert_page(>vm, dma, slot,
>I915_CACHE_NONE, 0);
>  
>   s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
>   ret = compress_page(compress, (void  __force *)s, dst);
>   io_mapping_unmap(s);
>   if (ret)
>   break;
>   }
>   } else if (i915_gem_object_is_lmem(vma->obj)) {
>   struct intel_memory_region *mem = vma->obj->mm.region;
>   dma_addr_t dma;
>  
>   for_each_sgt_daddr(dma, iter, vma->pages) {
>   void __iomem *s;
>  
> - s = io_mapping_map_atomic_wc(>iomap, dma);
> + s = io_mapping_map_wc(>iomap, dma, PAGE_SIZE);
>   ret = compress_page(compress, (void __force *)s, dst);
> - io_mapping_unmap_atomic(s);
> + io_mapping_unmap(s);
>   if (ret)
>   break;
>   }
>   } else {
>   struct page *page;
>  
>   for_each_sgt_page(page, iter, vma->pages) {
>   void *s;
>  
>   drm_clflush_pages(, 1);
>  
> - s = kmap_atomic(page);
> + s = kmap(page);
>   ret = compress_page(compress, s, dst);
> - kunmap_atomic(s);
> + kunmap(s);
>  
>   drm_clflush_pages(, 1);
>  
>   if (ret)
>   break;
>   }
>   }
>  
>   if (ret || compress_flush(compress, dst)) {
>   while (dst->page_count--)
>   pool_free(>pool, dst->pages[dst->page_count]);
>   kfree(dst);
>   dst = NULL;
>   }
>   compress_finish(compress);
>  
>   return dst;
>  }
>  
>  /*
>   * Generate a semi-unique error code. The code is not meant to have meaning, 
> The
>   * code's only purpose is to try to prevent false duplicated bug reports by
>   * grossly estimating a GPU error state.
>   *
>   * TODO Ideally, hashing the batchbuffer would be a very nice way to 
> determine
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Restore physical addresses for fb_mmap()

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:06:33)
> fbdev uses the physical address of our framebuffer for its fb_mmap()
> routine. While we need to adapt this address for the new io BAR, we have
> to fix v5.4 first! The simplest fix is to restore the smem back to v5.4
> and we will then probably have to implement our fbops->fb_mmap() call
> back to handle local memory.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
> Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
Testcase: igt/fbdev/mmap
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests: Add exercise for fbdev

2019-11-13 Thread Chris Wilson
I broke fb_mmap() proving that we need a test in CI!

References: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|  1 +
 tests/fbdev.c | 69 +++
 tests/intel-ci/fast-feedback.testlist |  1 +
 tests/meson.build |  1 +
 4 files changed, 72 insertions(+)
 create mode 100644 tests/fbdev.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index abf1e2fc1..6b1d4cb22 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -24,6 +24,7 @@ TESTS_progs = \
drm_import_export \
drm_mm \
drm_read \
+   fbdev \
kms_3d \
kms_addfb_basic \
kms_atomic \
diff --git a/tests/fbdev.c b/tests/fbdev.c
new file mode 100644
index 0..170f5dd52
--- /dev/null
+++ b/tests/fbdev.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "config.h"
+
+#include "igt.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "igt.h"
+
+igt_main
+{
+   struct fb_var_screeninfo var_info;
+   struct fb_fix_screeninfo fix_info;
+   int fd = -1;
+
+   igt_fixture {
+   fd = open("/dev/fb0", O_RDWR);
+   igt_require_f(fd != -1, "/dev/fb0\n");
+
+   igt_require(ioctl(fd, FBIOGET_VSCREENINFO, _info) == 0);
+   igt_require(ioctl(fd, FBIOGET_FSCREENINFO, _info) == 0);
+   }
+
+   igt_subtest("mmap") {
+   unsigned long size;
+   void *map;
+
+   size = var_info.yres * fix_info.line_length;
+   map = mmap(NULL, size, PROT_WRITE, MAP_SHARED, fd, 0);
+   igt_assert(map != MAP_FAILED);
+
+   memset(map, 0, size);
+   munmap(map, size);
+   }
+
+   igt_fixture {
+   close(fd);
+   }
+}
diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index 9dd27b42e..dec6fdda1 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -2,6 +2,7 @@
 
 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
diff --git a/tests/meson.build b/tests/meson.build
index 98f2db555..44bddd027 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -9,6 +9,7 @@ test_progs = [
'drm_import_export',
'drm_mm',
'drm_read',
+   'fbdev',
'kms_3d',
'kms_addfb_basic',
'kms_atomic',
-- 
2.24.0

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree (rev2)

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Split i915_active.mutex into an irq-safe spinlock for the 
rbtree (rev2)
URL   : https://patchwork.freedesktop.org/series/69399/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
70ca71d22f04 drm/i915: Split i915_active.mutex into an irq-safe spinlock for 
the rbtree
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#12: 
References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in 
IRQ contexts")

-:201: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#201: FILE: drivers/gpu/drm/i915/i915_active_types.h:51:
+   spinlock_t tree_lock;

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

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

[Intel-gfx] [PATCH 1/2] drm/i915/tgl: Wa_1606679103

2019-11-13 Thread Radhakrishna Sripada
Extend disabling SAMPLER_STATE prefetch workaround to gen12.

BSpec: 52890
Cc: Mika Kuoppala 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e4bccc14602f..6818d6b3cc90 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1370,11 +1370,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
GEN7_SARCHKMD,
GEN7_DISABLE_DEMAND_PREFETCH);
 
-   /* Wa_1606682166:icl */
-   wa_write_or(wal,
-   GEN7_SARCHKMD,
-   GEN7_DISABLE_SAMPLER_PREFETCH);
-
/* Wa_1409178092:icl */
wa_write_masked_or(wal,
   GEN11_SCRATCH2,
@@ -1382,6 +1377,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
   0);
}
 
+   if (IS_GEN_RANGE(i915, 11, 12)) {
+   /* Wa_1606682166:icl,tgl */
+   wa_write_or(wal,
+   GEN7_SARCHKMD,
+   GEN7_DISABLE_SAMPLER_PREFETCH);
+   }
+
if (IS_GEN_RANGE(i915, 9, 11)) {
/* 
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
wa_masked_en(wal,
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/2] drm/i915/tgl: Add Wa_1408615072

2019-11-13 Thread Radhakrishna Sripada
Disable VS Unit Clockgating.

BSpec: 52857
Cc: Mika Kuoppala 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2ffcc21670b7..3714eb641124 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4172,6 +4172,7 @@ enum {
 
 #define UNSLICE_UNIT_LEVEL_CLKGATE _MMIO(0x9434)
 #define  VFUNIT_CLKGATE_DIS(1 << 20)
+#define  VSUNIT_CLKGATE_DIS(1 << 3)
 
 #define INF_UNIT_LEVEL_CLKGATE _MMIO(0x9560)
 #define   CGPSF_CLKGATE_DIS(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2d389e437e87..fe32c0433971 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6572,6 +6572,10 @@ static void tgl_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
I915_WRITE(POWERGATE_ENABLE,
   I915_READ(POWERGATE_ENABLE) | vd_pg_enable);
+
+   /* Wa_1408615072:tgl */
+   I915_WRITE(UNSLICE_UNIT_LEVEL_CLKGATE,
+  I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE) | VFUNIT_CLKGATE_DIS);
 }
 
 static void cnp_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-13 Thread Lucas De Marchi

On Tue, Nov 12, 2019 at 09:16:57AM -0800, Matt Roper wrote:

On Tue, Nov 05, 2019 at 05:45:00PM -0800, José Roberto de Souza wrote:

PSR2 HW only support a limited number of bits per pixel, if mode has
more than supported PSR2 should not be enabled.

BSpec: 50422
BSpec: 7713
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index c1d133362b76..0d84ea28bc6f 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
-   int psr_max_h = 0, psr_max_v = 0;
+   int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;

if (!dev_priv->psr.sink_psr2_support)
return false;
@@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (INTEL_GEN(dev_priv) >= 12) {
psr_max_h = 5120;
psr_max_v = 3200;
+   max_bpp = 30;
} else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
psr_max_h = 4096;
psr_max_v = 2304;
+   max_bpp = 24;
} else if (IS_GEN(dev_priv, 9)) {
psr_max_h = 3640;
psr_max_v = 2304;
+   max_bpp = 24;
}

if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
@@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}

+   if (crtc_state->pipe_bpp > max_bpp) {
+   DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max supported 
%d\n",
+ crtc_state->pipe_bpp, max_bpp);
+   return false;
+   }


The wording of the bspec is "PSR2 is limited to 30bpp 10:10:10" and
"PSR2 is limited to 24bpp 8:8:8" --- that wording makes it sound like
you need to use that one specific mode rather than it being an upper
limit?  I.e., do we need an == test here rather than >?


I understand "limited" here rather as a limit, not as the only mode it
works in. Yes, it's confusing, but I don't think it makes much sense to
support just one bpp.

Lucas De Marchi




Matt


+
/*
 * HW sends SU blocks of size four scan lines, which means the starting
 * X coordinate and Y granularity requirements will always be met. We
--
2.24.0

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


--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
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 1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-13 Thread Lucas De Marchi

On Tue, Nov 05, 2019 at 05:45:00PM -0800, Jose Souza wrote:

PSR2 HW only support a limited number of bits per pixel, if mode has
more than supported PSR2 should not be enabled.

BSpec: 50422
BSpec: 7713


matches both specs


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index c1d133362b76..0d84ea28bc6f 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
-   int psr_max_h = 0, psr_max_v = 0;
+   int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;

if (!dev_priv->psr.sink_psr2_support)
return false;
@@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (INTEL_GEN(dev_priv) >= 12) {
psr_max_h = 5120;
psr_max_v = 3200;
+   max_bpp = 30;
} else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
psr_max_h = 4096;
psr_max_v = 2304;
+   max_bpp = 24;
} else if (IS_GEN(dev_priv, 9)) {
psr_max_h = 3640;
psr_max_v = 2304;
+   max_bpp = 24;
}

if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
@@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}

+   if (crtc_state->pipe_bpp > max_bpp) {
+   DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max supported 
%d\n",
+ crtc_state->pipe_bpp, max_bpp);
+   return false;
+   }
+
/*
 * HW sends SU blocks of size four scan lines, which means the starting
 * X coordinate and Y granularity requirements will always be met. We
--
2.24.0

___
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 3/3] drm/i915/display/mst: Enable virtual channel payload allocation earlier

2019-11-13 Thread Lucas De Marchi

On Thu, Nov 07, 2019 at 11:18:37PM +, Jose Souza wrote:

On Thu, 2019-11-07 at 15:10 -0800, Lucas De Marchi wrote:

On Thu, Nov 07, 2019 at 10:56:09PM +, Jose Souza wrote:
> On Thu, 2019-11-07 at 14:44 -0800, Lucas De Marchi wrote:
> > On Thu, Nov 07, 2019 at 01:45:59PM -0800, Jose Souza wrote:
> > > This register was being enabled after enable TRANS_DDI_FUNC_CTL
> > > and
> > > PIPECONF/TRANS_CONF while BSpec states that it should be set
> > > when
> > > enabling TRANS_DDI_FUNC_CTL.
> > >
> > > BSpec: 49190
> >
> > not what I read here.
> >
> > 8j. Configure TRANS_DDI_FUNC_CTL2 if port sync mode needs to be
> > configured.
> > Then configure and enable TRANS_DDI_FUNC_CTL.
>
> We call icl_enable_trans_port_sync() in haswell_crtc_enable() and
> then
> a few lines later intel_ddi_enable_transcoder_func(), if not do
> that
> right away was a problem people working in port sync would get this
> issue.

not what I meant. I meant the spec says to enable TRANS_DDI_FUNC_CTL,
do step 8k, and then enable pipe VC payload allocation.

We aren't doing step 8k anywhere though, as I noted below.


8k is a VRR step that we don't support yet.


if we ever add it, then this would need to be split again. Anyway, I
think it's ok for now.

Reviewed-by: Lucas De Marchi 

Lucas De Marchi




Lucas De Marchi

> > 8l. If DisplayPort multistream - Enable pipe VC payload
> > allocation in
> > TRANS_DDI_FUNC_CTL
> >
> > But yes, this needs to be done before TRANS_CONF.
> >
> > > BSpec: 22243
> >
> > same here.  But as long as we don't do step 8k, I think they can
> > in
> > fact
> > be combined.
> >
> > These cover TGL and ICL only, while the code goes until haswell.
> > Are
> > you
> > sure it's safe for the others?
> >
>
> I had only checked if the register exist since HSW but now I
> checked
> HSW, BDW and SKL sequence all of then requires this.
>
> BSpec: 4223
> BSpec: 4163
> BSpec: 4231
>
>
> > thanks
> > Lucas De Marchi
> >
> > > Cc: Lucas De Marchi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 18 ++---
> > > 
> > > -
> > > drivers/gpu/drm/i915/display/intel_display.c |  6 --
> > > 2 files changed, 2 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 398c6f054a6e..3d5fce878600 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -1803,22 +1803,6 @@ void intel_ddi_set_dp_msa(const struct
> > > intel_crtc_state *crtc_state,
> > >  I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> > > }
> > >
> > > -void intel_ddi_set_vc_payload_alloc(const struct
> > > intel_crtc_state
> > > *crtc_state,
> > > -bool state)
> > > -{
> > > -struct intel_crtc *crtc = to_intel_crtc(crtc_state-
> > > >uapi.crtc);
> > > -struct drm_i915_private *dev_priv = to_i915(crtc-
> > > >base.dev);
> > > -enum transcoder cpu_transcoder = crtc_state-
> > > >cpu_transcoder;
> > > -u32 temp;
> > > -
> > > -temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > > -if (state == true)
> > > -temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> > > -else
> > > -temp &= ~TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> > > -I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> > > -}
> > > -
> > > /*
> > >  * Returns the TRANS_DDI_FUNC_CTL value based on CRTC state.
> > >  *
> > > @@ -1924,6 +1908,8 @@ void
> > > intel_ddi_enable_transcoder_func(const
> > > struct intel_crtc_state *crtc_state)
> > >  u32 temp;
> > >
> > >  temp =
> > > intel_ddi_transcoder_func_reg_val_get(crtc_state);
> > > +if (intel_crtc_has_type(crtc_state,
> > > INTEL_OUTPUT_DP_MST))
> > > +temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> > >  I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 551de2baa569..3b4aea253f8c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -6670,9 +6670,6 @@ static void haswell_crtc_enable(struct
> > > intel_crtc_state *pipe_config,
> > >  if (pipe_config->has_pch_encoder)
> > >  lpt_pch_enable(state, pipe_config);
> > >
> > > -if (intel_crtc_has_type(pipe_config,
> > > INTEL_OUTPUT_DP_MST))
> > > -intel_ddi_set_vc_payload_alloc(pipe_config,
> > > true);
> > > -
> > >  assert_vblank_disabled(crtc);
> > >  intel_crtc_vblank_on(pipe_config);
> > >
> > > @@ -6783,9 +6780,6 @@ static void haswell_crtc_disable(struct
> > > intel_crtc_state *old_crtc_state,
> > >  if (!transcoder_is_dsi(cpu_transcoder))
> > >  intel_disable_pipe(old_crtc_state);
> > >
> > > -if (intel_crtc_has_type(old_crtc_state,
> > > 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/display/dsi: Add support to pipe D

2019-11-13 Thread Lucas De Marchi

On Thu, Nov 07, 2019 at 01:45:58PM -0800, Jose Souza wrote:

Adding pipe D support to DSI transcoder.
Not adding it for EDP transcoder code paths as only TGL has 4 pipes
and it do not have a EDP transcoder.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/icl_dsi.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 8eb2d7f29c82..f688207932e0 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -745,6 +745,9 @@ gen11_dsi_configure_transcoder(struct intel_encoder 
*encoder,
case PIPE_C:
tmp |= TRANS_DDI_EDP_INPUT_C_ONOFF;
break;
+   case PIPE_D:
+   tmp |= TRANS_DDI_EDP_INPUT_D_ONOFF;
+   break;
}

/* enable DDI buffer */
@@ -1325,6 +1328,9 @@ static bool gen11_dsi_get_hw_state(struct intel_encoder 
*encoder,
case TRANS_DDI_EDP_INPUT_C_ONOFF:
*pipe = PIPE_C;
break;
+   case TRANS_DDI_EDP_INPUT_D_ONOFF:
+   *pipe = PIPE_D;
+   break;
default:
DRM_ERROR("Invalid PIPE input\n");
goto out;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 70459a3d93e3..88d1430a6800 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9665,6 +9665,7 @@ enum skl_power_gate {
#define  TRANS_DDI_EDP_INPUT_A_ONOFF(4 << 12)
#define  TRANS_DDI_EDP_INPUT_B_ONOFF(5 << 12)
#define  TRANS_DDI_EDP_INPUT_C_ONOFF(6 << 12)
+#define  TRANS_DDI_EDP_INPUT_D_ONOFF   (7 << 12)
#define  TRANS_DDI_MST_TRANSPORT_SELECT_MASKREG_GENMASK(11, 10)
#define  TRANS_DDI_MST_TRANSPORT_SELECT(trans)  \
REG_FIELD_PREP(TRANS_DDI_MST_TRANSPORT_SELECT_MASK, trans)
--
2.24.0

___
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] drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree

2019-11-13 Thread Chris Wilson
As we want to be able to run inside atomic context for retiring the
i915_active, and we are no longer allowed to abuse mutex_trylock, split
the tree management portion of i915_active.mutex into an irq-safe
spinlock.

References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in 
IRQ contexts")
References: https://bugs.freedesktop.org/show_bug.cgi?id=111626
Fixes: 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_active.c   | 57 ++--
 drivers/gpu/drm/i915/i915_active_types.h |  1 +
 drivers/gpu/drm/i915/selftests/i915_active.c |  4 +-
 3 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 207383dda84d..5448f37c8102 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -91,14 +91,15 @@ static void debug_active_init(struct i915_active *ref)
 
 static void debug_active_activate(struct i915_active *ref)
 {
-   lockdep_assert_held(>mutex);
+   spin_lock_irq(>tree_lock);
if (!atomic_read(>count)) /* before the first inc */
debug_object_activate(ref, _debug_desc);
+   spin_unlock_irq(>tree_lock);
 }
 
 static void debug_active_deactivate(struct i915_active *ref)
 {
-   lockdep_assert_held(>mutex);
+   lockdep_assert_held(>tree_lock);
if (!atomic_read(>count)) /* after the last dec */
debug_object_deactivate(ref, _debug_desc);
 }
@@ -128,29 +129,22 @@ __active_retire(struct i915_active *ref)
 {
struct active_node *it, *n;
struct rb_root root;
-   bool retire = false;
+   unsigned long flags;
 
-   lockdep_assert_held(>mutex);
GEM_BUG_ON(i915_active_is_idle(ref));
 
/* return the unused nodes to our slabcache -- flushing the allocator */
-   if (atomic_dec_and_test(>count)) {
-   debug_active_deactivate(ref);
-   root = ref->tree;
-   ref->tree = RB_ROOT;
-   ref->cache = NULL;
-   retire = true;
-   }
-
-   mutex_unlock(>mutex);
-   if (!retire)
+   if (!atomic_dec_and_lock_irqsave(>count, >tree_lock, flags))
return;
 
GEM_BUG_ON(rcu_access_pointer(ref->excl.fence));
-   rbtree_postorder_for_each_entry_safe(it, n, , node) {
-   GEM_BUG_ON(i915_active_fence_isset(>base));
-   kmem_cache_free(global.slab_cache, it);
-   }
+   debug_active_deactivate(ref);
+
+   root = ref->tree;
+   ref->tree = RB_ROOT;
+   ref->cache = NULL;
+
+   spin_unlock_irqrestore(>tree_lock, flags);
 
/* After the final retire, the entire struct may be freed */
if (ref->retire)
@@ -158,6 +152,11 @@ __active_retire(struct i915_active *ref)
 
/* ... except if you wait on it, you must manage your own references! */
wake_up_var(ref);
+
+   rbtree_postorder_for_each_entry_safe(it, n, , node) {
+   GEM_BUG_ON(i915_active_fence_isset(>base));
+   kmem_cache_free(global.slab_cache, it);
+   }
 }
 
 static void
@@ -169,7 +168,6 @@ active_work(struct work_struct *wrk)
if (atomic_add_unless(>count, -1, 1))
return;
 
-   mutex_lock(>mutex);
__active_retire(ref);
 }
 
@@ -180,9 +178,7 @@ active_retire(struct i915_active *ref)
if (atomic_add_unless(>count, -1, 1))
return;
 
-   /* If we are inside interrupt context (fence signaling), defer */
-   if (ref->flags & I915_ACTIVE_RETIRE_SLEEPS ||
-   !mutex_trylock(>mutex)) {
+   if (ref->flags & I915_ACTIVE_RETIRE_SLEEPS) {
queue_work(system_unbound_wq, >work);
return;
}
@@ -227,7 +223,7 @@ active_instance(struct i915_active *ref, struct 
intel_timeline *tl)
if (!prealloc)
return NULL;
 
-   mutex_lock(>mutex);
+   spin_lock_irq(>tree_lock);
GEM_BUG_ON(i915_active_is_idle(ref));
 
parent = NULL;
@@ -257,7 +253,7 @@ active_instance(struct i915_active *ref, struct 
intel_timeline *tl)
 
 out:
ref->cache = node;
-   mutex_unlock(>mutex);
+   spin_unlock_irq(>tree_lock);
 
BUILD_BUG_ON(offsetof(typeof(*node), base));
return >base;
@@ -278,8 +274,10 @@ void __i915_active_init(struct i915_active *ref,
if (bits & I915_ACTIVE_MAY_SLEEP)
ref->flags |= I915_ACTIVE_RETIRE_SLEEPS;
 
+   spin_lock_init(>tree_lock);
ref->tree = RB_ROOT;
ref->cache = NULL;
+
init_llist_head(>preallocated_barriers);
atomic_set(>count, 0);
__mutex_init(>mutex, "i915_active", key);
@@ -510,7 +508,7 @@ static struct active_node *reuse_idle_barrier(struct 
i915_active *ref, u64 idx)
if (RB_EMPTY_ROOT(>tree))
return NULL;
 
-   mutex_lock(>mutex);

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fbdev: Restore physical addresses for fb_mmap()

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Restore physical addresses for fb_mmap()
URL   : https://patchwork.freedesktop.org/series/69416/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7332 -> Patchwork_15252


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_exec@basic:
- fi-icl-dsi: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-icl-dsi/igt@gem_ctx_e...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-icl-dsi/igt@gem_ctx_e...@basic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4] ([fdo#112261])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [PASS][5] -> [DMESG-WARN][6] ([fdo#105541])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
 Possible fixes 

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [INCOMPLETE][7] ([fdo#109964] / [fdo#110343]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

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

  * igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r:   [DMESG-FAIL][11] ([fdo#111991]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][13] ([fdo#111407]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (52 -> 45)
--

  Missing(7): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7332 -> Patchwork_15252

  CI-20190529: 20190529
  CI_DRM_7332: e8c9ce4930c1451ad4a43449fdf2c882da8921e8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5276: 868d38c2bc075b6756ebed486db6e7152ed2c5be @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15252: 139b7cf86417380ff28bbad8a8cd9d64525a3e84 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

139b7cf86417 drm/i915/fbdev: Restore physical addresses for fb_mmap()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15252/index.html

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Restore physical addresses for fb_mmap()

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:06:33)
> fbdev uses the physical address of our framebuffer for its fb_mmap()
> routine. While we need to adapt this address for the new io BAR, we have
> to fix v5.4 first! The simplest fix is to restore the smem back to v5.4
> and we will then probably have to implement our fbops->fb_mmap() call
> back to handle local memory.
 
Reported-by: Neil MacLeod 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
> Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
Tested-by: Neil MacLeod 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 3/3] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:28:08)
> From: Jon Bloomfield 
> 
> gen9+ introduces a cmdparser for the BLT engine which copies the
> incoming BB to a kmd owned buffer for submission (to prevent changes
> being made after the bb has been safely scanned). This breaks the
> spin functionality because it relies on changing the submitted spin
> buffers in order to terminate them.
> 
> Instead, for gen9+, we change the semantics by introducing a COND_BB_END
> into the infinite loop, to wait until a memory flag (in anothe bo) is
> cleared.
> 
> v2: Correct nop length to avoid overwriting bb_end instr when using
> a dependency bo (cork)
> v3: fix conflicts on igt_dummyload (Mika)
> v4: s/bool running/uint32_t running, fix r->delta (Mika)
> v5: remove overzealous assert (Mika)
> v6: rebase on top of lib changes (Mika)
> v7: rework on top of public igt lib changes (Mika)
> v8: rebase
> v9: simplify by using bb end as conditional (Chris)
> 
> Signed-off-by: Jon Bloomfield  (v2)
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Mika Kuoppala 
> Signed-off-by: Mika Kuoppala 
> ---
>  lib/i830_reg.h  |  2 +-
>  lib/igt_dummyload.c | 17 -
>  lib/intel_reg.h |  3 +++
>  tests/i915/gem_double_irq_loop.c|  2 --
>  tests/i915/gem_write_read_ring_switch.c |  2 +-
>  5 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/i830_reg.h b/lib/i830_reg.h
> index a57691c7e..410202567 100644
> --- a/lib/i830_reg.h
> +++ b/lib/i830_reg.h
> @@ -43,7 +43,7 @@
>  /* broadwater flush bits */
>  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
>  
> -#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
> +#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
>  #define MI_DO_COMPARE  (1<<21)
>  
>  #define MI_BATCH_BUFFER_END(0xA << 23)
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index c079bd045..652d469a0 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -208,7 +208,22 @@ emit_recursive_batch(igt_spin_t *spin,
>  * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
>  */
> if (!(opts->flags & IGT_SPIN_FAST))
> -   cs += 1000;
> +   cs += 960;
> +
> +   if (gen >= 8) {

If we push this back to gen>7 it will allow us to use it with its
cmdparser as well.

Hmm? I guess we could just do gen>6 so that there's some systematic
cutoff point.

> +   r = [batch->relocation_count++];
> +
> +   r->presumed_offset = 0;
> +   r->target_handle = batch->handle;
> +   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
> +   r->read_domains = I915_GEM_DOMAIN_COMMAND;
> +   r->delta = (spin->condition - batch_start) * sizeof(*cs);
> +
> +   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;
> +   *cs++ = MI_BATCH_BUFFER_END;
> +   *cs++ = r->delta;
> +   *cs++ = 0;

I think this approach should do the trick even for my attempts to
frustrate you.

With consensus on when to use COND_BB_END and verification I haven't
caused havoc...

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

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_dummyload: Send batch as first

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:28:07)
> From: Mika Kuoppala 
> 
> To simplify emitting the recursive batch, make batch
> always the first object on the execbuf list.
> 
> This will require kernel v4.13 or greater.
> 
> v2: set handles early, poll_ptr indecency (Chris)
> v3: allow dep with poll
> v4: fix gem_exec_schedule
> v5: rebase
> v6: rebase
> v6: gem_ctx_shared
> v7: conditional close of poll handle
> v8: bw compat note (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 

Do we still require it?

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

Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Lionel Landwerlin

On 13/11/2019 20:11, Chris Wilson wrote:

Quoting Chris Wilson (2019-11-13 18:10:22)

Quoting Lionel Landwerlin (2019-11-13 18:07:59)

On 13/11/2019 18:35, Chris Wilson wrote:

Quoting Lionel Landwerlin (2019-11-13 15:46:39)

I'm observing incoherence metric values, changing from run to run.

It appears the patches introducing noa wait & reconfiguration from
command stream switched places in the series multiple times during the
review. This lead to the dependency of one onto the order to go
missing...

I don't think I dropped it; if I did my apologies. I do feel the
egg-on-face for writing a selftest to verify that noa_wait does what you
said it did, but completely missing that it went unused :)



It was probably my mistake :)


   

Signed-off-by: Lionel Landwerlin 
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command 
stream")
---
   drivers/gpu/drm/i915/i915_perf.c | 9 +++--
   1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 507236bd41ae..31e47ee23357 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
  config_length += num_lri_dwords(oa_config->mux_regs_len);
  config_length += num_lri_dwords(oa_config->b_counter_regs_len);
  config_length += num_lri_dwords(oa_config->flex_regs_len);
-   config_length++; /* MI_BATCH_BUFFER_END */
+   config_length += 3; /* MI_BATCH_BUFFER_START */
  config_length = ALIGN(sizeof(u32) * config_length, 
I915_GTT_PAGE_SIZE);
   
  obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);

@@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
   oa_config->flex_regs,
   oa_config->flex_regs_len);
   
-   *cs++ = MI_BATCH_BUFFER_END;

+   /* Jump into the active wait. */
+   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
+MI_BATCH_BUFFER_START :
+MI_BATCH_BUFFER_START_GEN8);
+   *cs++ = i915_ggtt_offset(stream->noa_wait);
+   *cs++ = 0;

Yikes, stream->noa_wait is unused.

Hmm, the noa_wait doesn't have any arbitration points internally, so we
probably do need to make it non-preemptable as well?

With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
Reviewed-by: Chris Wilson 

We need to wrap emit_oa_config() in a similar selftest and verify
that a read of the oa regs are correct and that the TIMESTAMP indicates
the appropriate delay before the read. If you feel bored.
-Chris


As long as we wait long enough, it should be okay.

Why making it nopreempt?

Aiui, the batch buffer has no arbitration points so the delay may incur
the wrath of the forced preemption. That is another request (of higher
priority) wishing to run, but not being able to.

The alternative would be adding a MI_ARB_CHECK at the start of the loop
if you happy with being preempted out.
-Chris


I guess I'll do that :)


-Lionel

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

Re: [Intel-gfx] [PATCH i-g-t 1/3] i915: Skip if secure batches is not available

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:28:06)
> From: "Kuoppala, Mika" 
> 
> If we can't do secure execbuf, there is no point in trying.
> 
> Signed-off-by: Kuoppala, Mika 
Reviewed-by: Chris Wilson 

There are a few more I915_EXEC_SECURE users, as MI_STORE_DWORD requires
it on gen4/5; but they are off the beaten path.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 1/3] i915: Skip if secure batches is not available

2019-11-13 Thread Chris Wilson
From: "Kuoppala, Mika" 

If we can't do secure execbuf, there is no point in trying.

Signed-off-by: Kuoppala, Mika 
---
 tests/i915/gem_exec_params.c   | 22 --
 tests/i915/gem_mocs_settings.c | 14 ++
 tests/perf_pmu.c   | 14 ++
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index 8f15e6454..9c3525698 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -193,6 +193,19 @@ static void test_batch_first(int fd)
gem_close(fd, obj[0].handle);
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp = {
+   .param = I915_PARAM_HAS_SECURE_BATCHES,
+   .value = ,
+   };
+
+   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+
+   return v > 0;
+}
+
 struct drm_i915_gem_execbuffer2 execbuf;
 struct drm_i915_gem_exec_object2 gem_exec[1];
 uint32_t batch[2] = {MI_BATCH_BUFFER_END};
@@ -340,6 +353,8 @@ igt_main
}
 
igt_subtest("secure-non-root") {
+   igt_require(has_secure_batches(fd));
+
igt_fork(child, 1) {
igt_drop_root();
 
@@ -351,9 +366,12 @@ igt_main
}
 
igt_subtest("secure-non-master") {
-   igt_require(__igt_device_set_master(fd) == 0); /* Requires root 
privilege */
+   igt_require(has_secure_batches(fd));
+
+   /* Requires root privilege... */
+   igt_require(__igt_device_set_master(fd) == 0);
+   igt_device_drop_master(fd); /* ... to drop master! */
 
-   igt_device_drop_master(fd);
execbuf.flags = I915_EXEC_RENDER | I915_EXEC_SECURE;
RUN_FAIL(EPERM);
 
diff --git a/tests/i915/gem_mocs_settings.c b/tests/i915/gem_mocs_settings.c
index fc2ccb216..9627d828f 100644
--- a/tests/i915/gem_mocs_settings.c
+++ b/tests/i915/gem_mocs_settings.c
@@ -225,6 +225,19 @@ static uint32_t get_engine_base(int fd, uint32_t engine)
}
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp = {
+   .param = I915_PARAM_HAS_SECURE_BATCHES,
+   .value = ,
+   };
+
+   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+
+   return v > 0;
+}
+
 #define MI_STORE_REGISTER_MEM_64_BIT_ADDR  ((0x24 << 23) | 2)
 
 static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
@@ -566,6 +579,7 @@ igt_main
igt_require_gem(fd);
gem_require_mocs_registers(fd);
igt_require(get_mocs_settings(fd, , false));
+   igt_require(has_secure_batches(fd));
}
 
for (e = intel_execution_engines; e->name; e++) {
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e2bd2cc55..54842784c 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -893,6 +893,19 @@ static int wait_vblank(int fd, union drm_wait_vblank *vbl)
return err;
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp = {
+   .param = I915_PARAM_HAS_SECURE_BATCHES,
+   .value = ,
+   };
+
+   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+
+   return v > 0;
+}
+
 static void
 event_wait(int gem_fd, const struct intel_execution_engine2 *e)
 {
@@ -910,6 +923,7 @@ event_wait(int gem_fd, const struct intel_execution_engine2 
*e)
 
devid = intel_get_drm_devid(gem_fd);
igt_require(intel_gen(devid) >= 7);
+   igt_require(has_secure_batches(fd));
igt_skip_on(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
 
kmstest_set_vt_graphics_mode();
-- 
2.24.0

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

[Intel-gfx] [PATCH i-g-t 3/3] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase
v9: simplify by using bb end as conditional (Chris)

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
 lib/i830_reg.h  |  2 +-
 lib/igt_dummyload.c | 17 -
 lib/intel_reg.h |  3 +++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 5 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7e..410202567 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,7 +43,7 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
 #define MI_DO_COMPARE  (1<<21)
 
 #define MI_BATCH_BUFFER_END(0xA << 23)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index c079bd045..652d469a0 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -208,7 +208,22 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   if (gen >= 8) {
+   r = [batch->relocation_count++];
+
+   r->presumed_offset = 0;
+   r->target_handle = batch->handle;
+   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = (spin->condition - batch_start) * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 5 << 12 | 2;
+   *cs++ = MI_BATCH_BUFFER_END;
+   *cs++ = r->delta;
+   *cs++ = 0;
+   }
 
/* recurse */
r = [batch->relocation_count++];
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 069440cb7..10ca760a2 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2593,6 +2593,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 #define MI_BATCH_BUFFER((0x30 << 23) | 1)
 #define MI_BATCH_BUFFER_START  (0x31 << 23)
 #define MI_BATCH_BUFFER_END(0xA << 23)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
+#define MI_DO_COMPARE   (1<<21)
+
 #define MI_BATCH_NON_SECURE(1)
 #define MI_BATCH_NON_SECURE_I965   (1 << 8)
 #define MI_BATCH_NON_SECURE_HSW(1<<13) /* Additional bit for 
RCS */
diff --git a/tests/i915/gem_double_irq_loop.c b/tests/i915/gem_double_irq_loop.c
index b326fc58a..f17f61c19 100644
--- a/tests/i915/gem_double_irq_loop.c
+++ b/tests/i915/gem_double_irq_loop.c
@@ -52,8 +52,6 @@ static drm_intel_bo *target_buffer, *blt_bo;
 IGT_TEST_DESCRIPTION("Basic check for missed IRQs on blt ring.");
 
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
-#define MI_DO_COMPARE  (1<<21)
 static void
 dummy_reloc_loop(void)
 {
diff --git a/tests/i915/gem_write_read_ring_switch.c 
b/tests/i915/gem_write_read_ring_switch.c
index ef229cc59..095c13c34 100644
--- a/tests/i915/gem_write_read_ring_switch.c
+++ b/tests/i915/gem_write_read_ring_switch.c
@@ -115,7 +115,7 @@ static void run_test(int ring)
 * otherwise the obj->last_write_seqno will be updated. */
if (ring == I915_EXEC_RENDER) {
BEGIN_BATCH(4, 1);
-   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE);
+   OUT_BATCH(MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 1);
OUT_BATCH(0x); /* compare dword */
OUT_RELOC(target_bo, I915_GEM_DOMAIN_RENDER, 0, 0);
OUT_BATCH(MI_NOOP);
-- 
2.24.0

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

[Intel-gfx] [PATCH i-g-t 2/3] lib/igt_dummyload: Send batch as first

2019-11-13 Thread Chris Wilson
From: Mika Kuoppala 

To simplify emitting the recursive batch, make batch
always the first object on the execbuf list.

This will require kernel v4.13 or greater.

v2: set handles early, poll_ptr indecency (Chris)
v3: allow dep with poll
v4: fix gem_exec_schedule
v5: rebase
v6: rebase
v6: gem_ctx_shared
v7: conditional close of poll handle
v8: bw compat note (Chris)

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 lib/igt_dummyload.c| 115 +
 lib/igt_dummyload.h|   8 ++-
 tests/i915/gem_exec_balancer.c |   8 +--
 tests/i915/gem_spin_batch.c|  13 ++--
 4 files changed, 75 insertions(+), 69 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index b9e239db3..c079bd045 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -63,6 +63,7 @@
 #define MI_ARB_CHK (0x5 << 23)
 
 static const int BATCH_SIZE = 4096;
+static const int POLL_SIZE = 4096;
 static const int LOOP_START_OFFSET = 64;
 
 static IGT_LIST_HEAD(spin_list);
@@ -72,16 +73,23 @@ static int
 emit_recursive_batch(igt_spin_t *spin,
 int fd, const struct igt_spin_factory *opts)
 {
-#define SCRATCH 0
+
 #define BATCH IGT_SPIN_BATCH
+#define POLL 1
+#define DEP 2
const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_relocation_entry relocs[2], *r;
+   struct drm_i915_gem_exec_object2 * const batch =
+   >obj[BATCH];
+   struct drm_i915_gem_exec_object2 * const poll =
+   >obj[POLL];
+   struct drm_i915_gem_exec_object2 * const dep =
+   >obj[DEP];
+   struct drm_i915_gem_relocation_entry relocs[4], *r;
struct drm_i915_gem_execbuffer2 *execbuf;
-   struct drm_i915_gem_exec_object2 *obj;
unsigned int flags[GEM_MAX_ENGINES];
unsigned int nengine;
int fence_fd = -1;
-   uint32_t *cs, *batch;
+   uint32_t *cs, *batch_start;
int i;
 
nengine = 0;
@@ -103,64 +111,48 @@ emit_recursive_batch(igt_spin_t *spin,
memset(>execbuf, 0, sizeof(spin->execbuf));
execbuf = >execbuf;
memset(spin->obj, 0, sizeof(spin->obj));
-   obj = spin->obj;
memset(relocs, 0, sizeof(relocs));
 
-   obj[BATCH].handle = gem_create(fd, BATCH_SIZE);
-   batch = __gem_mmap__wc(fd, obj[BATCH].handle,
-  0, BATCH_SIZE, PROT_WRITE);
-   if (!batch)
-   batch = gem_mmap__gtt(fd, obj[BATCH].handle,
- BATCH_SIZE, PROT_WRITE);
+   batch->handle = gem_create(fd, BATCH_SIZE);
+   spin->handle = batch->handle;
 
-   gem_set_domain(fd, obj[BATCH].handle,
+   batch_start = __gem_mmap__wc(fd, batch->handle,
+0, BATCH_SIZE, PROT_WRITE);
+   if (!batch_start)
+   batch_start = gem_mmap__gtt(fd, batch->handle,
+   BATCH_SIZE, PROT_WRITE);
+   gem_set_domain(fd, batch->handle,
   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
execbuf->buffer_count++;
-   cs = batch;
-
-   if (opts->dependency) {
-   igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
-
-   r = [obj[BATCH].relocation_count++];
+   cs = batch_start;
 
-   /* dummy write to dependency */
-   obj[SCRATCH].handle = opts->dependency;
-   r->presumed_offset = 0;
-   r->target_handle = obj[SCRATCH].handle;
-   r->offset = sizeof(uint32_t) * 1020;
-   r->delta = 0;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = I915_GEM_DOMAIN_RENDER;
-
-   execbuf->buffer_count++;
-   } else if (opts->flags & IGT_SPIN_POLL_RUN) {
-   r = [obj[BATCH].relocation_count++];
+   poll->handle = gem_create(fd, POLL_SIZE);
+   spin->poll_handle = poll->handle;
+   execbuf->buffer_count++;
 
-   igt_assert(!opts->dependency);
+   if (opts->flags & IGT_SPIN_POLL_RUN) {
+   r = [batch->relocation_count++];
 
if (gen == 4 || gen == 5) {
execbuf->flags |= I915_EXEC_SECURE;
igt_require(__igt_device_set_master(fd) == 0);
}
 
-   spin->poll_handle = gem_create(fd, 4096);
-   obj[SCRATCH].handle = spin->poll_handle;
-
-   if (__gem_set_caching(fd, spin->poll_handle,
+   if (__gem_set_caching(fd, poll->handle,
  I915_CACHING_CACHED) == 0)
-   spin->poll = gem_mmap__cpu(fd, spin->poll_handle,
-  0, 4096,
+   spin->poll = gem_mmap__cpu(fd, poll->handle,
+  0, POLL_SIZE,
   PROT_READ | PROT_WRITE);
else
-  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Hide smem_start from userspace

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Hide smem_start from userspace
URL   : https://patchwork.freedesktop.org/series/69415/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7332 -> Patchwork_15251


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-bsw-n3050:   [PASS][1] -> [DMESG-FAIL][2] ([fdo#112176])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-bsw-n3050/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-bsw-n3050/igt@i915_selftest@live_blt.html

  * igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2:  [PASS][3] -> [TIMEOUT][4] ([fdo#111800])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-skl-6770hq:  [PASS][5] -> [FAIL][6] ([fdo#109495])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-6770hq/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-skl-6770hq/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [INCOMPLETE][7] ([fdo#109964] / [fdo#110343]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

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

  * igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[DMESG-WARN][11] ([fdo#112261]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-skl-lmem/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r:   [DMESG-FAIL][13] ([fdo#111991]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html

  
 Warnings 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111045] 
/ [fdo#111096])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7332/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15251/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109495]: https://bugs.freedesktop.org/show_bug.cgi?id=109495
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111800]: https://bugs.freedesktop.org/show_bug.cgi?id=111800
  [fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
  [fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (52 -> 45)
--

  Missing(7): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7332 -> Patchwork_15251

  CI-20190529: 20190529
  CI_DRM_7332: e8c9ce4930c1451ad4a43449fdf2c882da8921e8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5276: 868d38c2bc075b6756ebed486db6e7152ed2c5be @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15251: 0392ce3a572195877ea44aa6cdbfe8b36b81abe1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Chris Wilson
Quoting Chris Wilson (2019-11-13 18:10:22)
> Quoting Lionel Landwerlin (2019-11-13 18:07:59)
> > On 13/11/2019 18:35, Chris Wilson wrote:
> > > Quoting Lionel Landwerlin (2019-11-13 15:46:39)
> > >> I'm observing incoherence metric values, changing from run to run.
> > >>
> > >> It appears the patches introducing noa wait & reconfiguration from
> > >> command stream switched places in the series multiple times during the
> > >> review. This lead to the dependency of one onto the order to go
> > >> missing...
> > > I don't think I dropped it; if I did my apologies. I do feel the
> > > egg-on-face for writing a selftest to verify that noa_wait does what you
> > > said it did, but completely missing that it went unused :)
> > >   
> > >> Signed-off-by: Lionel Landwerlin 
> > >> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from 
> > >> command stream")
> > >> ---
> > >>   drivers/gpu/drm/i915/i915_perf.c | 9 +++--
> > >>   1 file changed, 7 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> > >> b/drivers/gpu/drm/i915/i915_perf.c
> > >> index 507236bd41ae..31e47ee23357 100644
> > >> --- a/drivers/gpu/drm/i915/i915_perf.c
> > >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> > >> @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> > >> *stream,
> > >>  config_length += num_lri_dwords(oa_config->mux_regs_len);
> > >>  config_length += num_lri_dwords(oa_config->b_counter_regs_len);
> > >>  config_length += num_lri_dwords(oa_config->flex_regs_len);
> > >> -   config_length++; /* MI_BATCH_BUFFER_END */
> > >> +   config_length += 3; /* MI_BATCH_BUFFER_START */
> > >>  config_length = ALIGN(sizeof(u32) * config_length, 
> > >> I915_GTT_PAGE_SIZE);
> > >>   
> > >>  obj = i915_gem_object_create_shmem(stream->perf->i915, 
> > >> config_length);
> > >> @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> > >> *stream,
> > >>   oa_config->flex_regs,
> > >>   oa_config->flex_regs_len);
> > >>   
> > >> -   *cs++ = MI_BATCH_BUFFER_END;
> > >> +   /* Jump into the active wait. */
> > >> +   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
> > >> +MI_BATCH_BUFFER_START :
> > >> +MI_BATCH_BUFFER_START_GEN8);
> > >> +   *cs++ = i915_ggtt_offset(stream->noa_wait);
> > >> +   *cs++ = 0;
> > > Yikes, stream->noa_wait is unused.
> > >
> > > Hmm, the noa_wait doesn't have any arbitration points internally, so we
> > > probably do need to make it non-preemptable as well?
> > >
> > > With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
> > > Reviewed-by: Chris Wilson 
> > >
> > > We need to wrap emit_oa_config() in a similar selftest and verify
> > > that a read of the oa regs are correct and that the TIMESTAMP indicates
> > > the appropriate delay before the read. If you feel bored.
> > > -Chris
> > 
> > 
> > As long as we wait long enough, it should be okay.
> > 
> > Why making it nopreempt?
> 
> Aiui, the batch buffer has no arbitration points so the delay may incur
> the wrath of the forced preemption. That is another request (of higher
> priority) wishing to run, but not being able to.

The alternative would be adding a MI_ARB_CHECK at the start of the loop
if you happy with being preempted out.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Chris Wilson
Quoting Lionel Landwerlin (2019-11-13 18:07:59)
> On 13/11/2019 18:35, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-11-13 15:46:39)
> >> I'm observing incoherence metric values, changing from run to run.
> >>
> >> It appears the patches introducing noa wait & reconfiguration from
> >> command stream switched places in the series multiple times during the
> >> review. This lead to the dependency of one onto the order to go
> >> missing...
> > I don't think I dropped it; if I did my apologies. I do feel the
> > egg-on-face for writing a selftest to verify that noa_wait does what you
> > said it did, but completely missing that it went unused :)
> >   
> >> Signed-off-by: Lionel Landwerlin 
> >> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command 
> >> stream")
> >> ---
> >>   drivers/gpu/drm/i915/i915_perf.c | 9 +++--
> >>   1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> >> b/drivers/gpu/drm/i915/i915_perf.c
> >> index 507236bd41ae..31e47ee23357 100644
> >> --- a/drivers/gpu/drm/i915/i915_perf.c
> >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >> @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> >> *stream,
> >>  config_length += num_lri_dwords(oa_config->mux_regs_len);
> >>  config_length += num_lri_dwords(oa_config->b_counter_regs_len);
> >>  config_length += num_lri_dwords(oa_config->flex_regs_len);
> >> -   config_length++; /* MI_BATCH_BUFFER_END */
> >> +   config_length += 3; /* MI_BATCH_BUFFER_START */
> >>  config_length = ALIGN(sizeof(u32) * config_length, 
> >> I915_GTT_PAGE_SIZE);
> >>   
> >>  obj = i915_gem_object_create_shmem(stream->perf->i915, 
> >> config_length);
> >> @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream 
> >> *stream,
> >>   oa_config->flex_regs,
> >>   oa_config->flex_regs_len);
> >>   
> >> -   *cs++ = MI_BATCH_BUFFER_END;
> >> +   /* Jump into the active wait. */
> >> +   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
> >> +MI_BATCH_BUFFER_START :
> >> +MI_BATCH_BUFFER_START_GEN8);
> >> +   *cs++ = i915_ggtt_offset(stream->noa_wait);
> >> +   *cs++ = 0;
> > Yikes, stream->noa_wait is unused.
> >
> > Hmm, the noa_wait doesn't have any arbitration points internally, so we
> > probably do need to make it non-preemptable as well?
> >
> > With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
> > Reviewed-by: Chris Wilson 
> >
> > We need to wrap emit_oa_config() in a similar selftest and verify
> > that a read of the oa regs are correct and that the TIMESTAMP indicates
> > the appropriate delay before the read. If you feel bored.
> > -Chris
> 
> 
> As long as we wait long enough, it should be okay.
> 
> Why making it nopreempt?

Aiui, the batch buffer has no arbitration points so the delay may incur
the wrath of the forced preemption. That is another request (of higher
priority) wishing to run, but not being able to.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Lionel Landwerlin

On 13/11/2019 18:35, Chris Wilson wrote:

Quoting Lionel Landwerlin (2019-11-13 15:46:39)

I'm observing incoherence metric values, changing from run to run.

It appears the patches introducing noa wait & reconfiguration from
command stream switched places in the series multiple times during the
review. This lead to the dependency of one onto the order to go
missing...

I don't think I dropped it; if I did my apologies. I do feel the
egg-on-face for writing a selftest to verify that noa_wait does what you
said it did, but completely missing that it went unused :)
  

Signed-off-by: Lionel Landwerlin 
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command 
stream")
---
  drivers/gpu/drm/i915/i915_perf.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 507236bd41ae..31e47ee23357 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
 config_length += num_lri_dwords(oa_config->mux_regs_len);
 config_length += num_lri_dwords(oa_config->b_counter_regs_len);
 config_length += num_lri_dwords(oa_config->flex_regs_len);
-   config_length++; /* MI_BATCH_BUFFER_END */
+   config_length += 3; /* MI_BATCH_BUFFER_START */
 config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
  
 obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);

@@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
  oa_config->flex_regs,
  oa_config->flex_regs_len);
  
-   *cs++ = MI_BATCH_BUFFER_END;

+   /* Jump into the active wait. */
+   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
+MI_BATCH_BUFFER_START :
+MI_BATCH_BUFFER_START_GEN8);
+   *cs++ = i915_ggtt_offset(stream->noa_wait);
+   *cs++ = 0;

Yikes, stream->noa_wait is unused.

Hmm, the noa_wait doesn't have any arbitration points internally, so we
probably do need to make it non-preemptable as well?

With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
Reviewed-by: Chris Wilson 

We need to wrap emit_oa_config() in a similar selftest and verify
that a read of the oa regs are correct and that the TIMESTAMP indicates
the appropriate delay before the read. If you feel bored.
-Chris



As long as we wait long enough, it should be okay.

Why making it nopreempt?


-Lionel

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

[Intel-gfx] [PATCH] drm/i915/fbdev: Restore physical addresses for fb_mmap()

2019-11-13 Thread Chris Wilson
fbdev uses the physical address of our framebuffer for its fb_mmap()
routine. While we need to adapt this address for the new io BAR, we have
to fix v5.4 first! The simplest fix is to restore the smem back to v5.4
and we will then probably have to implement our fbops->fb_mmap() call
back to handle local memory.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 3d1061470e76..48c960ca12fb 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -234,6 +234,11 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->apertures->ranges[0].base = ggtt->gmadr.start;
info->apertures->ranges[0].size = ggtt->mappable_end;
 
+   /* Our framebuffer is the entirety of fbdev's system memory */
+   info->fix.smem_start =
+   (unsigned long)(ggtt->gmadr.start + vma->node.start);
+   info->fix.smem_len = vma->node.size;
+
vaddr = i915_vma_pin_iomap(vma);
if (IS_ERR(vaddr)) {
DRM_ERROR("Failed to remap framebuffer into virtual memory\n");
@@ -243,10 +248,6 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->screen_base = vaddr;
info->screen_size = vma->node.size;
 
-   /* Our framebuffer is the entirety of fbdev's system memory */
-   info->fix.smem_start = (unsigned long)info->screen_base;
-   info->fix.smem_len = info->screen_size;
-
drm_fb_helper_fill_info(info, >helper, sizes);
 
/* If the object is shmemfs backed, it will have given us zeroed pages.
-- 
2.24.0

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/fbdev: Hide smem_start from userspace

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Hide smem_start from userspace
URL   : https://patchwork.freedesktop.org/series/69415/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0392ce3a5721 drm/i915/fbdev: Hide smem_start from userspace
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit da6c7707caf3 ("fbdev: Add 
FBINFO_HIDE_SMEM_START flag")'
#12: 
References: da6c7707caf3 ("fbdev: Add FBINFO_HIDE_SMEM_START flag")

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

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

[Intel-gfx] [PATCH] drm/i915/fbdev: Hide smem_start from userspace

2019-11-13 Thread Chris Wilson
Do not leak our internal kernel address for random userspace to abuse.
Daniel added the support to fbdev to filter out the physical addresses
being exposed by fbdev, put that to use to protect ourselves.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base")
References: da6c7707caf3 ("fbdev: Add FBINFO_HIDE_SMEM_START flag")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 3d1061470e76..bff311561597 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -226,8 +226,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unpin;
}
 
-   ifbdev->helper.fb = >fb->base;
-
+   /* don't leak any physical addresses to userspace */
+   info->flags |= FBINFO_HIDE_SMEM_START;
info->fbops = _ops;
 
/* setup aperture base/size for vesafb takeover */
@@ -247,6 +247,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->fix.smem_start = (unsigned long)info->screen_base;
info->fix.smem_len = info->screen_size;
 
+   ifbdev->helper.fb = >fb->base;
drm_fb_helper_fill_info(info, >helper, sizes);
 
/* If the object is shmemfs backed, it will have given us zeroed pages.
-- 
2.24.0

___
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 2/7] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-11-13 15:49:08)
>> From: Jon Bloomfield 
>> 
>> gen9+ introduces a cmdparser for the BLT engine which copies the
>> incoming BB to a kmd owned buffer for submission (to prevent changes
>> being made after the bb has been safely scanned). This breaks the
>> spin functionality because it relies on changing the submitted spin
>> buffers in order to terminate them.
>> 
>> Instead, for gen9+, we change the semantics by introducing a COND_BB_END
>> into the infinite loop, to wait until a memory flag (in anothe bo) is
>> cleared.
>> 
>> v2: Correct nop length to avoid overwriting bb_end instr when using
>> a dependency bo (cork)
>> v3: fix conflicts on igt_dummyload (Mika)
>> v4: s/bool running/uint32_t running, fix r->delta (Mika)
>> v5: remove overzealous assert (Mika)
>> v6: rebase on top of lib changes (Mika)
>> v7: rework on top of public igt lib changes (Mika)
>> v8: rebase
>> 
>> Signed-off-by: Jon Bloomfield  (v2)
>> Cc: Joonas Lahtinen 
>> Cc: Rodrigo Vivi 
>> Cc: Mika Kuoppala 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  lib/i830_reg.h  |  2 +-
>>  lib/igt_dummyload.c | 46 +++--
>>  lib/igt_dummyload.h |  3 ++
>>  lib/intel_reg.h |  3 ++
>>  tests/i915/gem_double_irq_loop.c|  2 --
>>  tests/i915/gem_write_read_ring_switch.c |  2 +-
>>  6 files changed, 52 insertions(+), 6 deletions(-)
>> 
>> diff --git a/lib/i830_reg.h b/lib/i830_reg.h
>> index a57691c7..41020256 100644
>> --- a/lib/i830_reg.h
>> +++ b/lib/i830_reg.h
>> @@ -43,7 +43,7 @@
>>  /* broadwater flush bits */
>>  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
>>  
>> -#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
>> +#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
>>  #define MI_DO_COMPARE  (1<<21)
>>  
>>  #define MI_BATCH_BUFFER_END(0xA << 23)
>> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
>> index c079bd04..a88c8582 100644
>> --- a/lib/igt_dummyload.c
>> +++ b/lib/igt_dummyload.c
>> @@ -130,7 +130,15 @@ emit_recursive_batch(igt_spin_t *spin,
>> spin->poll_handle = poll->handle;
>> execbuf->buffer_count++;
>>  
>> -   if (opts->flags & IGT_SPIN_POLL_RUN) {
>> +   /*
>> +* For gen9+ we use a conditional loop rather than an
>> +* infinite loop, because we are unable to modify the
>> +* BB's once they have been scanned by the cmdparser
>> +* We share the poll buffer for the conditional test
>> +* and is always the first buffer in the batch list
>> +*/
>> +
>> +   if (gen >= 9 || (opts->flags & IGT_SPIN_POLL_RUN)) {
>
> Nah, you could just sample the batch buffer rather than always adding
> the poll buffer (since the cmdparser implicitly creates the second buffer
> for you). Using the comparison value of MI_BATCH_BUFFER_END you wouldn't
> even have to worry about altering callers.

That is a neat trick! bb start is greater than bb end so
we have that opportunity. Might lead also to much less fixing
on mutables.

-Mika
___
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/perf: don't forget noa wait after oa config

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: don't forget noa wait after oa config
URL   : https://patchwork.freedesktop.org/series/69409/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7331 -> Patchwork_15250


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-skl-6770hq:  [PASS][1] -> [DMESG-WARN][2] ([fdo#105541])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-skl-6770hq/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-skl-6770hq/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live_gt_heartbeat:
- fi-cfl-8700k:   [PASS][3] -> [DMESG-FAIL][4] ([fdo#112096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [PASS][5] -> [WARN][6] ([fdo#109483])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [INCOMPLETE][9] ([fdo#109964] / [fdo#110343]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2:  [FAIL][11] ([fdo#109635 ]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][13] ([fdo#109483]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15250/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

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

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#112096]: https://bugs.freedesktop.org/show_bug.cgi?id=112096
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (53 -> 45)
--

  Missing(8): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7331 -> Patchwork_15250

  CI-20190529: 20190529
  CI_DRM_7331: 4ea40d641218a45e90dd213b89a207ce8bec34dd @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5276: 868d38c2bc075b6756ebed486db6e7152ed2c5be @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15250: b43a5337ee5d797fa7cc87b4b1332fcf97bcc01e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b43a5337ee5d drm/i915/perf: don't forget noa wait after oa config

== Logs ==

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

[Intel-gfx] [PATCH i-g-t] i915/gem_mocs_settings: Update TGL MOCS table

2019-11-13 Thread Matt Roper
The TGL MOCS table was corrected in the bspec and the kernel.  Since
this test hardcodes its own copy of the MOCS table, we need to make
corresponding fixes here.

References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
References: bfb0e8e63d86 ("drm/i915/tgl: MOCS table update")
Cc: Prathap Kumar Valsan 
Cc: Lucas De Marchi 
Cc: Francisco Jerez 
Cc: Tomasz Lis 
Signed-off-by: Matt Roper 
---
 tests/i915/gem_mocs_settings.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/i915/gem_mocs_settings.c b/tests/i915/gem_mocs_settings.c
index fc2ccb21..8f8f0768 100644
--- a/tests/i915/gem_mocs_settings.c
+++ b/tests/i915/gem_mocs_settings.c
@@ -95,8 +95,6 @@ static const struct mocs_entry 
tigerlake_mocs_table[GEN11_NUM_MOCS_ENTRIES] = {
[13] = { 0x0057, 0x0030, 0x1},
[14] = { 0x0067, 0x0010, 0x1},
[15] = { 0x0067, 0x0030, 0x1},
-   [16] = { 0x4005, 0x0010, 0x1},
-   [17] = { 0x4005, 0x0030, 0x1},
[18] = { 0x00060037, 0x0030, 0x1},
[19] = { 0x0737, 0x0030, 0x1},
[20] = { 0x0337, 0x0030, 0x1},
@@ -108,7 +106,7 @@ static const struct mocs_entry 
tigerlake_mocs_table[GEN11_NUM_MOCS_ENTRIES] = {
[50] = { 0x0037, 0x0010, 0x1},
[51] = { 0x0005, 0x0010, 0x1},
[60] = { 0x0037, 0x0010, 0x1},
-   [61] = { 0x4005, 0x0030, 0x1},
+   [61] = { 0x0005, 0x0030, 0x1},
[62] = { 0x0037, 0x0010, 0x1},
[63] = { 0x0037, 0x0010, 0x1},
 };
-- 
2.21.0

___
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 series starting with [v3,1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"

2019-11-13 Thread Matt Roper
On Wed, Nov 13, 2019 at 11:49:53AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v3,1/2] Revert "drm/i915/ehl: Update MOCS table 
> for EHL"
> URL   : https://patchwork.freedesktop.org/series/69383/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7323_full -> Patchwork_15245_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_15245_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_15245_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_15245_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_mocs_settings@mocs-rc6-ctx-render:
> - shard-tglb: NOTRUN -> [FAIL][1] +1 similar issue
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-tglb4/igt@gem_mocs_setti...@mocs-rc6-ctx-render.html
> 
>   * igt@gem_mocs_settings@mocs-settings-ctx-render:
> - shard-tglb: [PASS][2] -> [FAIL][3] +10 similar issues
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-tglb8/igt@gem_mocs_setti...@mocs-settings-ctx-render.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-tglb7/igt@gem_mocs_setti...@mocs-settings-ctx-render.html

These are expected failures from this change --- this IGT test hardcodes
the expected MOCS table into the test, so corrections to the bspec like
this also need to be reflected in IGT.  I'll send along an IGT patch to
address this shortly.

Since the rest of the results are correct, added a Cc:stable to the
first patch and pushed to dinq.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_15245_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_persistence@vcs1-cleanup:
> - shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#109276] / [fdo#112080])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-iclb1/igt@gem_ctx_persiste...@vcs1-cleanup.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-iclb6/igt@gem_ctx_persiste...@vcs1-cleanup.html
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-snb:  [PASS][6] -> [FAIL][7] ([fdo#109661])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-snb2/igt@gem_...@unwedge-stress.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-snb7/igt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_balancer@smoke:
> - shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#110854])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-iclb1/igt@gem_exec_balan...@smoke.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-iclb3/igt@gem_exec_balan...@smoke.html
> 
>   * igt@gem_exec_create@basic:
> - shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111736])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-tglb9/igt@gem_exec_cre...@basic.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-tglb6/igt@gem_exec_cre...@basic.html
> 
>   * igt@gem_exec_parallel@vcs1-fds:
> - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112080]) +7 similar 
> issues
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-iclb6/igt@gem_exec_paral...@vcs1-fds.html
> 
>   * igt@gem_exec_schedule@fifo-bsd:
> - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +1 similar 
> issue
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-iclb7/igt@gem_exec_sched...@fifo-bsd.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-iclb1/igt@gem_exec_sched...@fifo-bsd.html
> 
>   * igt@gem_persistent_relocs@forked:
> - shard-hsw:  [PASS][16] -> [INCOMPLETE][17] ([fdo#103540])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-hsw1/igt@gem_persistent_rel...@forked.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-hsw8/igt@gem_persistent_rel...@forked.html
> 
>   * igt@gem_sync@basic-store-each:
> - shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([fdo#111647] / 
> [fdo#111747])
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/shard-tglb4/igt@gem_s...@basic-store-each.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/shard-tglb6/igt@gem_s...@basic-store-each.html
> 
>   * 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/7] Add tests/gem_blt_parse

2019-11-13 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-11-13 15:49:11)
>> From: Mika Kuoppala 
>> 
>> For testing blitter engine command parser on gen9.
>> 
>> v2: bad jump offset
>> v3: rebase
>> v4: improve bb start and subcase it
>> v5: fix presumed offsets (Jon)
>> 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  tests/Makefile.sources|   3 +
>>  tests/i915/gem_blt_parse.c| 997 ++
>
> I was thinking gem_exec_parse_blt.c so the relationship with the
> previous gem_exec_parse is clearer (both that this cmdparser, and that
> this is a subset of the execbuf ABI).
>
>>  tests/intel-ci/fast-feedback.testlist |   1 +
>>  tests/meson.build |   1 +
>>  4 files changed, 1002 insertions(+)
>>  create mode 100644 tests/i915/gem_blt_parse.c
>> 
>> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
>> index abf1e2fc..75c79edb 100644
>> --- a/tests/Makefile.sources
>> +++ b/tests/Makefile.sources
>> @@ -244,6 +244,9 @@ gem_exec_params_SOURCES = i915/gem_exec_params.c
>>  TESTS_progs += gem_exec_parse
>>  gem_exec_parse_SOURCES = i915/gem_exec_parse.c
>>  
>> +TESTS_progs += gem_blt_parse
>> +gem_blt_parse_SOURCES = i915/gem_blt_parse.c
>> +
>>  TESTS_progs += gem_exec_reloc
>>  gem_exec_reloc_SOURCES = i915/gem_exec_reloc.c
>>  
>> diff --git a/tests/i915/gem_blt_parse.c b/tests/i915/gem_blt_parse.c
>> new file mode 100644
>> index ..607afba9
>> --- /dev/null
>> +++ b/tests/i915/gem_blt_parse.c
>> @@ -0,0 +1,997 @@
>> +/*
>> + * Copyright © 2018 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + */
>> +
>> +#include "igt.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#ifndef I915_PARAM_CMD_PARSER_VERSION
>> +#define I915_PARAM_CMD_PARSER_VERSION   28
>> +#endif
>> +
>> +#ifndef I915_PARAM_HAS_SECURE_BATCHES
>> +#define I915_PARAM_HAS_SECURE_BATCHES   23
>> +#endif
>
> Now pulled in from uapi/i915_drm.h
>
>> +
>> +/* To help craft commands known to be invalid across all engines */
>> +#define INSTR_CLIENT_SHIFT 29
>> +#define   INSTR_INVALID_CLIENT  0x7
>> +
>> +#define MI_LOAD_REGISTER_REG (0x2a << 23)
>> +#define MI_STORE_REGISTER_MEM (0x24 << 23)
>> +#define MI_ARB_ON_OFF (0x8 << 23)
>> +#define MI_USER_INTERRUPT (0x02 << 23)
>> +#define MI_FLUSH_DW (0x26 << 23)
>> +#define MI_ARB_CHECK (0x05 << 23)
>> +#define MI_REPORT_HEAD (0x07 << 23)
>> +#define MI_SUSPEND_FLUSH (0x0b << 23)
>> +#define MI_LOAD_SCAN_LINES_EXCL (0x13 << 23)
>> +#define MI_UPDATE_GTT (0x23 << 23)
>> +
>> +#define BCS_SWCTRL 0x22200
>> +#define BCS_GPR_BASE   0x22600
>> +#define BCS_GPR(n) (0x22600 + (n) * 8)
>> +#define BCS_GPR_UDW(n) (0x22600 + (n) * 8 + 4)
>> +
>> +#define HANDLE_SIZE  4096
>> +
>> +static int parser_version;
>> +
>> +static int command_parser_version(int fd)
>> +{
>> +   int version = -1;
>> +   drm_i915_getparam_t gp;
>> +
>> +   gp.param = I915_PARAM_CMD_PARSER_VERSION;
>> +   gp.value = 
>> +
>> +   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) == 0)
>> +   return version;
>> +
>> +   return -1;
>> +}
>> +
>> +static int  __exec_batch_patched(int fd, int engine,
>> +uint32_t cmd_bo, const uint32_t *cmds, int 
>> size,
>> +uint32_t target_bo, uint64_t target_offset, 
>> uint64_t target_delta)
>> +{
>> +   struct drm_i915_gem_execbuffer2 execbuf;
>> +   struct drm_i915_gem_exec_object2 obj[2];
>> +   struct drm_i915_gem_relocation_entry reloc[1];
>> +
>> +   gem_write(fd, cmd_bo, 0, cmds, size);
>> +
>> +   memset(obj, 0, sizeof(obj));
>> +   obj[0].handle = target_bo;
>> +   obj[1].handle = cmd_bo;
>> +
>> +   memset(reloc, 0, sizeof(reloc));
>> +   reloc[0].offset = target_offset;
>> +   

Re: [Intel-gfx] [PATCH] drm/i915/perf: don't forget noa wait after oa config

2019-11-13 Thread Chris Wilson
Quoting Lionel Landwerlin (2019-11-13 15:46:39)
> I'm observing incoherence metric values, changing from run to run.
> 
> It appears the patches introducing noa wait & reconfiguration from
> command stream switched places in the series multiple times during the
> review. This lead to the dependency of one onto the order to go
> missing...

I don't think I dropped it; if I did my apologies. I do feel the
egg-on-face for writing a selftest to verify that noa_wait does what you
said it did, but completely missing that it went unused :)
 
> Signed-off-by: Lionel Landwerlin 
> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command 
> stream")
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 507236bd41ae..31e47ee23357 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1870,7 +1870,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
> config_length += num_lri_dwords(oa_config->mux_regs_len);
> config_length += num_lri_dwords(oa_config->b_counter_regs_len);
> config_length += num_lri_dwords(oa_config->flex_regs_len);
> -   config_length++; /* MI_BATCH_BUFFER_END */
> +   config_length += 3; /* MI_BATCH_BUFFER_START */
> config_length = ALIGN(sizeof(u32) * config_length, 
> I915_GTT_PAGE_SIZE);
>  
> obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
> @@ -1895,7 +1895,12 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
>  oa_config->flex_regs,
>  oa_config->flex_regs_len);
>  
> -   *cs++ = MI_BATCH_BUFFER_END;
> +   /* Jump into the active wait. */
> +   *cs++ = (INTEL_GEN(stream->perf->i915) < 8 ?
> +MI_BATCH_BUFFER_START :
> +MI_BATCH_BUFFER_START_GEN8);
> +   *cs++ = i915_ggtt_offset(stream->noa_wait);
> +   *cs++ = 0;

Yikes, stream->noa_wait is unused.

Hmm, the noa_wait doesn't have any arbitration points internally, so we
probably do need to make it non-preemptable as well?

With a rq->flags |= I915_REQUEST_NOPREEMPT in emit_oa_config,
Reviewed-by: Chris Wilson 

We need to wrap emit_oa_config() in a similar selftest and verify
that a read of the oa regs are correct and that the TIMESTAMP indicates
the appropriate delay before the read. If you feel bored.
-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/gt: Invalidate as we write the gen7 breadcrumb

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Invalidate as we write the gen7 breadcrumb
URL   : https://patchwork.freedesktop.org/series/69408/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7331 -> Patchwork_15249


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#106070] / 
[fdo#111700])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][3] -> [FAIL][4] ([fdo#109483])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][5] -> [WARN][6] ([fdo#112252])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][7] ([fdo#112261]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2:  [FAIL][9] ([fdo#109635 ]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [FAIL][11] ([fdo#109483]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][13] ([fdo#111045] / [fdo#111096]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][17] ([fdo#109271]) -> [FAIL][18] ([fdo#110829])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15249/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#110829]: https://bugs.freedesktop.org/show_bug.cgi?id=110829
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
  [fdo#111887]: https://bugs.freedesktop.org/show_bug.cgi?id=111887
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261


Participating hosts (53 -> 46)
--

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


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7331 -> Patchwork_15249

  CI-20190529: 

Re: [Intel-gfx] [PATCH] drm/i915/tgl: allow DVI/HDMI on port A

2019-11-13 Thread Matt Roper
On Tue, Nov 12, 2019 at 06:19:35PM -0800, Lucas De Marchi wrote:
> Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT
> says regarding HDMI to workaround broken VBTs, see commit
> 2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this apply
> gen12+ so they inherit the TGL behavior.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 7c0ca733bef8..e6da98729e1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1450,7 +1450,7 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv,
>   is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) 
> == 0;
>   is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
>  
> - if (port == PORT_A && is_dvi) {
> + if (port == PORT_A && is_dvi && INTEL_GEN(dev_priv) < 12) {
>   DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
> is_hdmi ? "/HDMI" : "");
>   is_dvi = false;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index ed4a68fb351f..659a03b08849 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3140,7 +3140,7 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   DRM_DEBUG_KMS("Adding HDMI connector on [ENCODER:%d:%s]\n",
> intel_encoder->base.base.id, intel_encoder->base.name);
>  
> - if (WARN_ON(port == PORT_A))
> + if (INTEL_GEN(dev_priv) < 12 && WARN_ON(port == PORT_A))
>   return;
>  
>   if (WARN(intel_dig_port->max_lanes < 4,
> -- 
> 2.24.0
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Invalidate as we write the gen7 breadcrumb

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:59:53)
> Chris Wilson  writes:
> 
> > Still the saga of the hsw live_blt incoherency continues. While it did
> > seem that the invalidate before the breadcrumb had improved the mtbf,
> > nevertheless live_blt still failed. Mika's next idea was to pull the
> > invalidate-stall into the breadcrumb write itself.
> >
> > References: 860afa086841 ("drm/i915/gt: Flush gen7 even harder")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
> > Testcase: igt/i915_selftest/live_blt
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_ring_submission.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> > b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > index e8bee44add34..f25ceccb335e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > @@ -454,12 +454,8 @@ static u32 *gen7_xcs_emit_breadcrumb(struct 
> > i915_request *rq, u32 *cs)
> >   GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
> > rq->engine->status_page.vma);
> >   
> > GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
> > I915_GEM_HWS_SEQNO_ADDR);
> >  
> > - *cs++ = (MI_FLUSH_DW | MI_INVALIDATE_TLB |
> > -  MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW);
> > - *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
> > - *cs++ = 0;
> > -
> > - *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | 
> > MI_FLUSH_DW_STORE_INDEX;
> > + *cs++ = MI_FLUSH_DW | MI_INVALIDATE_TLB |
> > + MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
> >   *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
> >   *cs++ = rq->fence.seqno;
> 
> In both would have been the shotgun approach. You favour sniper.

At the end of the day, we stop when live_blt stops failing -- and we
hope that it's in the simplest form when we forget about it :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 7/7] test/i915: Add i915_rc6_ctx_corruption

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:13)
> From: Imre Deak 
> 
> Add a test to exercise the kernel's mechanism to detection of RC6
> context corruptions, take the necessary action in response (disable
> RC6 and runtime PM) and recover when possible (after system
> suspend/resume).
> 
> v2:
> - Skip test on non-existing engines.
> - Fix for old kernels where the command parser returned EINVAL
>   instead of EACCESS for a banned privilidged command.
> 
> Signed-off-by: Imre Deak 
> ---
>  tests/Makefile.sources   |   3 +
>  tests/i915/i915_rc6_ctx_corruption.c | 196 +++
>  tests/meson.build|   1 +
>  3 files changed, 200 insertions(+)
>  create mode 100644 tests/i915/i915_rc6_ctx_corruption.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 75c79edb..c0f401c7 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -529,6 +529,9 @@ i915_pm_sseu_SOURCES = i915/i915_pm_sseu.c
>  TESTS_progs += i915_query
>  i915_query_SOURCES = i915/i915_query.c
>  
> +TESTS_progs += i915_rc6_ctx_corruption
> +i915_rc6_ctx_corruption_SOURCES = i915/i915_rc6_ctx_corruption.c
> +
>  TESTS_progs += i915_selftest
>  i915_selftest_SOURCES = i915/i915_selftest.c
>  
> diff --git a/tests/i915/i915_rc6_ctx_corruption.c 
> b/tests/i915/i915_rc6_ctx_corruption.c
> new file mode 100644
> index ..a3326307
> --- /dev/null
> +++ b/tests/i915/i915_rc6_ctx_corruption.c
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright © 2019 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include 
> +
> +#include "igt.h"
> +#include "igt_gt.h"
> +#include "igt_device.h"
> +
> +#define CTX_INFO_REG   0xA300
> +
> +static int drm_fd;
> +static struct pci_device *pci_dev;
> +static uint32_t devid;
> +
> +static int read_reg_on_engine(const struct intel_execution_engine2 *engine,
> + int reg_address, uint32_t *reg_val)
> +{
> +   const bool r64b = intel_gen(devid) >= 8;
> +   struct drm_i915_gem_exec_object2 obj[2];
> +   struct drm_i915_gem_relocation_entry reloc[1];
> +   struct drm_i915_gem_execbuffer2 execbuf;
> +   uint32_t *batch;
> +   uint32_t *dst_buf;
> +   int ret;
> +   int i;
> +
> +   memset(obj, 0, sizeof(obj));
> +   obj[0].handle = gem_create(drm_fd, 4096);
> +   obj[1].handle = gem_create(drm_fd, 4096);
> +   obj[1].relocs_ptr = to_user_pointer(reloc);
> +   obj[1].relocation_count = 1;
> +
> +   batch = gem_mmap__cpu(drm_fd, obj[1].handle, 0, 4096, PROT_WRITE);
> +   gem_set_domain(drm_fd, obj[1].handle,
> +  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
> +
> +   i = 0;
> +   batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */
> +   batch[i++] = reg_address;
> +   reloc[0].target_handle = obj[0].handle;
> +   reloc[0].presumed_offset = obj[0].offset;
> +   reloc[0].offset = i * sizeof(uint32_t);
> +   reloc[0].delta = 0;
> +   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
> +   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
> +   batch[i++] = reloc[0].delta;
> +   if (r64b)
> +   batch[i++] = 0;
> +
> +   batch[i++] = MI_BATCH_BUFFER_END;
> +   munmap(batch, 4096);
> +
> +   memset(, 0, sizeof(execbuf));
> +   execbuf.buffers_ptr = to_user_pointer(obj);
> +   execbuf.buffer_count = 2;
> +   execbuf.flags = engine->flags;
> +
> +   ret = __gem_execbuf(drm_fd, );
> +   gem_close(drm_fd, obj[1].handle);
> +
> +   if (ret)
> +   goto err;
> +
> +   if (reg_val) {
> +   dst_buf = gem_mmap__cpu(drm_fd, obj[0].handle, 0, 4096,
> +   PROT_READ);
> +   gem_set_domain(drm_fd, obj[0].handle, I915_GEM_DOMAIN_CPU, 0);
> +
> +   

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/7] Add tests/gem_blt_parse

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:11)
> From: Mika Kuoppala 
> 
> For testing blitter engine command parser on gen9.
> 
> v2: bad jump offset
> v3: rebase
> v4: improve bb start and subcase it
> v5: fix presumed offsets (Jon)
> 
> Signed-off-by: Mika Kuoppala 
> ---
>  tests/Makefile.sources|   3 +
>  tests/i915/gem_blt_parse.c| 997 ++

I was thinking gem_exec_parse_blt.c so the relationship with the
previous gem_exec_parse is clearer (both that this cmdparser, and that
this is a subset of the execbuf ABI).

>  tests/intel-ci/fast-feedback.testlist |   1 +
>  tests/meson.build |   1 +
>  4 files changed, 1002 insertions(+)
>  create mode 100644 tests/i915/gem_blt_parse.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index abf1e2fc..75c79edb 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -244,6 +244,9 @@ gem_exec_params_SOURCES = i915/gem_exec_params.c
>  TESTS_progs += gem_exec_parse
>  gem_exec_parse_SOURCES = i915/gem_exec_parse.c
>  
> +TESTS_progs += gem_blt_parse
> +gem_blt_parse_SOURCES = i915/gem_blt_parse.c
> +
>  TESTS_progs += gem_exec_reloc
>  gem_exec_reloc_SOURCES = i915/gem_exec_reloc.c
>  
> diff --git a/tests/i915/gem_blt_parse.c b/tests/i915/gem_blt_parse.c
> new file mode 100644
> index ..607afba9
> --- /dev/null
> +++ b/tests/i915/gem_blt_parse.c
> @@ -0,0 +1,997 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#ifndef I915_PARAM_CMD_PARSER_VERSION
> +#define I915_PARAM_CMD_PARSER_VERSION   28
> +#endif
> +
> +#ifndef I915_PARAM_HAS_SECURE_BATCHES
> +#define I915_PARAM_HAS_SECURE_BATCHES   23
> +#endif

Now pulled in from uapi/i915_drm.h

> +
> +/* To help craft commands known to be invalid across all engines */
> +#define INSTR_CLIENT_SHIFT 29
> +#define   INSTR_INVALID_CLIENT  0x7
> +
> +#define MI_LOAD_REGISTER_REG (0x2a << 23)
> +#define MI_STORE_REGISTER_MEM (0x24 << 23)
> +#define MI_ARB_ON_OFF (0x8 << 23)
> +#define MI_USER_INTERRUPT (0x02 << 23)
> +#define MI_FLUSH_DW (0x26 << 23)
> +#define MI_ARB_CHECK (0x05 << 23)
> +#define MI_REPORT_HEAD (0x07 << 23)
> +#define MI_SUSPEND_FLUSH (0x0b << 23)
> +#define MI_LOAD_SCAN_LINES_EXCL (0x13 << 23)
> +#define MI_UPDATE_GTT (0x23 << 23)
> +
> +#define BCS_SWCTRL 0x22200
> +#define BCS_GPR_BASE   0x22600
> +#define BCS_GPR(n) (0x22600 + (n) * 8)
> +#define BCS_GPR_UDW(n) (0x22600 + (n) * 8 + 4)
> +
> +#define HANDLE_SIZE  4096
> +
> +static int parser_version;
> +
> +static int command_parser_version(int fd)
> +{
> +   int version = -1;
> +   drm_i915_getparam_t gp;
> +
> +   gp.param = I915_PARAM_CMD_PARSER_VERSION;
> +   gp.value = 
> +
> +   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) == 0)
> +   return version;
> +
> +   return -1;
> +}
> +
> +static int  __exec_batch_patched(int fd, int engine,
> +uint32_t cmd_bo, const uint32_t *cmds, int 
> size,
> +uint32_t target_bo, uint64_t target_offset, 
> uint64_t target_delta)
> +{
> +   struct drm_i915_gem_execbuffer2 execbuf;
> +   struct drm_i915_gem_exec_object2 obj[2];
> +   struct drm_i915_gem_relocation_entry reloc[1];
> +
> +   gem_write(fd, cmd_bo, 0, cmds, size);
> +
> +   memset(obj, 0, sizeof(obj));
> +   obj[0].handle = target_bo;
> +   obj[1].handle = cmd_bo;
> +
> +   memset(reloc, 0, sizeof(reloc));
> +   reloc[0].offset = target_offset;
> +   reloc[0].target_handle = target_bo;
> +   reloc[0].delta = target_delta;
> +   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
> +   reloc[0].write_domain = 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Invalidate as we write the gen7 breadcrumb

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Invalidate as we write the gen7 breadcrumb
URL   : https://patchwork.freedesktop.org/series/69408/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f30aa89cb9aa drm/i915/gt: Invalidate as we write the gen7 breadcrumb
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 860afa086841 ("drm/i915/gt: 
Flush gen7 even harder")'
#11: 
References: 860afa086841 ("drm/i915/gt: Flush gen7 even harder")

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

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-13 Thread Mika Kuoppala
Chris Wilson  writes:

> Be consistent in our mocs setup on Tigerlake and set the unused control
> value to follow the PTE entry as we previously have done. The unused
> values are beyond the defines of the ABI, the consistency simplifies our
> checking.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 6e881c735b20..d2b445d6c258 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -489,7 +489,7 @@ static void intel_mocs_init_global(struct intel_gt *gt)
>   for (; index < table.n_entries; index++)
>   intel_uncore_write(uncore,
>  GEN12_GLOBAL_MOCS(index),
> -table.table[0].control_value);
> +table.table[I915_MOCS_PTE].control_value);
>  }
>  
>  void intel_mocs_init(struct intel_gt *gt)
> -- 
> 2.24.0
___
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 2/7] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:08)
> From: Jon Bloomfield 
> 
> gen9+ introduces a cmdparser for the BLT engine which copies the
> incoming BB to a kmd owned buffer for submission (to prevent changes
> being made after the bb has been safely scanned). This breaks the
> spin functionality because it relies on changing the submitted spin
> buffers in order to terminate them.
> 
> Instead, for gen9+, we change the semantics by introducing a COND_BB_END
> into the infinite loop, to wait until a memory flag (in anothe bo) is
> cleared.
> 
> v2: Correct nop length to avoid overwriting bb_end instr when using
> a dependency bo (cork)
> v3: fix conflicts on igt_dummyload (Mika)
> v4: s/bool running/uint32_t running, fix r->delta (Mika)
> v5: remove overzealous assert (Mika)
> v6: rebase on top of lib changes (Mika)
> v7: rework on top of public igt lib changes (Mika)
> v8: rebase
> 
> Signed-off-by: Jon Bloomfield  (v2)
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Mika Kuoppala 
> Signed-off-by: Mika Kuoppala 
> ---
>  lib/i830_reg.h  |  2 +-
>  lib/igt_dummyload.c | 46 +++--
>  lib/igt_dummyload.h |  3 ++
>  lib/intel_reg.h |  3 ++
>  tests/i915/gem_double_irq_loop.c|  2 --
>  tests/i915/gem_write_read_ring_switch.c |  2 +-
>  6 files changed, 52 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/i830_reg.h b/lib/i830_reg.h
> index a57691c7..41020256 100644
> --- a/lib/i830_reg.h
> +++ b/lib/i830_reg.h
> @@ -43,7 +43,7 @@
>  /* broadwater flush bits */
>  #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
>  
> -#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
> +#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
>  #define MI_DO_COMPARE  (1<<21)
>  
>  #define MI_BATCH_BUFFER_END(0xA << 23)
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index c079bd04..a88c8582 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -130,7 +130,15 @@ emit_recursive_batch(igt_spin_t *spin,
> spin->poll_handle = poll->handle;
> execbuf->buffer_count++;
>  
> -   if (opts->flags & IGT_SPIN_POLL_RUN) {
> +   /*
> +* For gen9+ we use a conditional loop rather than an
> +* infinite loop, because we are unable to modify the
> +* BB's once they have been scanned by the cmdparser
> +* We share the poll buffer for the conditional test
> +* and is always the first buffer in the batch list
> +*/
> +
> +   if (gen >= 9 || (opts->flags & IGT_SPIN_POLL_RUN)) {

Nah, you could just sample the batch buffer rather than always adding
the poll buffer (since the cmdparser implicitly creates the second buffer
for you). Using the comparison value of MI_BATCH_BUFFER_END you wouldn't
even have to worry about altering callers.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree

2019-11-13 Thread Patchwork
== Series Details ==

Series: drm/i915: Split i915_active.mutex into an irq-safe spinlock for the 
rbtree
URL   : https://patchwork.freedesktop.org/series/69399/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7331 -> Patchwork_15248


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_create@basic-files:
- fi-skl-6770hq:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-skl-6770hq/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-skl-6770hq/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_create@basic:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-u3/igt@gem_exec_cre...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-icl-u3/igt@gem_exec_cre...@basic.html
- fi-icl-dsi: [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-dsi/igt@gem_exec_cre...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-icl-dsi/igt@gem_exec_cre...@basic.html
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-apl-guc/igt@gem_exec_cre...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-apl-guc/igt@gem_exec_cre...@basic.html
- fi-icl-guc: [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-guc/igt@gem_exec_cre...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-icl-guc/igt@gem_exec_cre...@basic.html

  * igt@gem_exec_fence@nb-await-default:
- fi-bsw-nick:[PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-bsw-nick/igt@gem_exec_fe...@nb-await-default.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-bsw-nick/igt@gem_exec_fe...@nb-await-default.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-guc: [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-kbl-guc/igt@gem_exec_susp...@basic-s0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-kbl-guc/igt@gem_exec_susp...@basic-s0.html
- fi-icl-y:   [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-y/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-icl-y/igt@gem_exec_susp...@basic-s0.html
- fi-icl-u2:  [PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-icl-u2/igt@gem_exec_susp...@basic-s0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-icl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bsw-kefka:   [PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-bsw-kefka/igt@gem_exec_susp...@basic-s3.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-bsw-kefka/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-hsw-4770r:   [PASS][21] -> [DMESG-WARN][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-hsw-4770r/igt@gem_exec_susp...@basic-s4-devices.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-hsw-4770r/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:NOTRUN -> [DMESG-WARN][23]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html

  * igt@i915_selftest@live_hangcheck:
- fi-cfl-8700k:   [PASS][24] -> [DMESG-WARN][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-cfl-8700k/igt@i915_selftest@live_hangcheck.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15248/fi-cfl-8700k/igt@i915_selftest@live_hangcheck.html
- fi-cml-u2:  [PASS][26] -> [DMESG-WARN][27]
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7331/fi-cml-u2/igt@i915_selftest@live_hangcheck.html
   [27]: 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Invalidate as we write the gen7 breadcrumb

2019-11-13 Thread Mika Kuoppala
Chris Wilson  writes:

> Still the saga of the hsw live_blt incoherency continues. While it did
> seem that the invalidate before the breadcrumb had improved the mtbf,
> nevertheless live_blt still failed. Mika's next idea was to pull the
> invalidate-stall into the breadcrumb write itself.
>
> References: 860afa086841 ("drm/i915/gt: Flush gen7 even harder")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
> Testcase: igt/i915_selftest/live_blt
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/gt/intel_ring_submission.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index e8bee44add34..f25ceccb335e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -454,12 +454,8 @@ static u32 *gen7_xcs_emit_breadcrumb(struct i915_request 
> *rq, u32 *cs)
>   GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
> rq->engine->status_page.vma);
>   
> GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
> I915_GEM_HWS_SEQNO_ADDR);
>  
> - *cs++ = (MI_FLUSH_DW | MI_INVALIDATE_TLB |
> -  MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW);
> - *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
> - *cs++ = 0;
> -
> - *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
> + *cs++ = MI_FLUSH_DW | MI_INVALIDATE_TLB |
> + MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
>   *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
>   *cs++ = rq->fence.seqno;

In both would have been the shotgun approach. You favour sniper.

Acked-by: Mika Kuoppala 

>  
> @@ -474,6 +470,7 @@ static u32 *gen7_xcs_emit_breadcrumb(struct i915_request 
> *rq, u32 *cs)
>   *cs++ = 0;
>  
>   *cs++ = MI_USER_INTERRUPT;
> + *cs++ = MI_NOOP;
>  
>   rq->tail = intel_ring_offset(rq, cs);
>   assert_ring_tail_valid(rq->ring, rq->tail);
> -- 
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/7] lib/igt_dummyload: Send batch as first

2019-11-13 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-13 15:49:07)
> To simplify emitting the recursive batch, make batch
> always the first object on the execbuf list.

Requires v4.13. Useful to leave as a note. Fwiw, looks like 3.16 and
4.14 are still rotting away slowly.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 6/7] lib/igt_aux: Add helper to query suspend-to-mem modes

2019-11-13 Thread Mika Kuoppala
From: Imre Deak 

Add a helper to query the supported and currently selected
suspend-to-mem modes.

v2:
- Fix for old kernels where the mem_sleep sysfs file didn't yet exist.

Signed-off-by: Imre Deak 
---
 lib/igt_aux.c | 81 +++
 lib/igt_aux.h | 24 +++
 2 files changed, 105 insertions(+)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 578f8579..f2cb3247 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -827,6 +827,87 @@ static uint32_t get_supported_suspend_states(int power_dir)
return state_mask;
 }
 
+static const char *suspend_to_mem_mode_name[] = {
+   [SUSPEND_TO_MEM_S2IDLE] = "s2idle",
+   [SUSPEND_TO_MEM_SHALLOW] = "shallow",
+   [SUSPEND_TO_MEM_DEEP] = "deep",
+};
+
+static uint32_t
+get_supported_suspend_to_mem_modes(int power_dir,
+  enum igt_suspend_to_mem_mode *selected_mode)
+{
+   char *modes;
+   char *mode_name;
+   uint32_t mode_mask;
+   bool selected_found = false;
+
+   /*
+* Other modes than deep sleep were only introduced with the mem_sleep
+* sysfs file.
+*/
+   modes = igt_sysfs_get(power_dir, "mem_sleep");
+   if (!modes) {
+   *selected_mode = SUSPEND_TO_MEM_DEEP;
+   return 1 << SUSPEND_TO_MEM_DEEP;
+   }
+
+   mode_mask = 0;
+   for (mode_name = strtok(modes, " "); mode_name;
+mode_name = strtok(NULL, " ")) {
+   enum igt_suspend_to_mem_mode mode;
+   bool selected = false;
+
+   if (mode_name[0] == '[') {
+   char *e = _name[strlen(mode_name) - 1];
+
+   igt_assert(!selected_found);
+   igt_assert(*e == ']');
+   mode_name++;
+   *e = '\0';
+
+   selected = true;
+   }
+
+   for (mode = SUSPEND_TO_MEM_S2IDLE;
+mode < SUSPEND_TO_MEM_NUM;
+mode++)
+   if (strcmp(mode_name,
+  suspend_to_mem_mode_name[mode]) == 0)
+   break;
+   igt_assert(mode < SUSPEND_TO_MEM_NUM);
+   mode_mask |= 1 << mode;
+   if (selected) {
+   selected_found = true;
+   if (selected_mode)
+   *selected_mode = mode;
+   }
+   }
+
+   igt_assert(selected_found);
+
+   free(modes);
+
+   return mode_mask;
+}
+
+/**
+ * igt_get_suspend_to_mem_mode:
+ *
+ * Returns the currently selected @igt_suspend_to_mem_mode.
+ */
+enum igt_suspend_to_mem_mode igt_get_suspend_to_mem_mode(void)
+{
+   int power_dir;
+   enum igt_suspend_to_mem_mode mode;
+
+   igt_require((power_dir = open("/sys/power", O_RDONLY)) >= 0);
+   (void)get_supported_suspend_to_mem_modes(power_dir, );
+   close(power_dir);
+
+   return mode;
+}
+
 /**
  * igt_system_suspend_autoresume:
  * @state: an #igt_suspend_state, the target suspend state
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 04d22904..7ccaa8c4 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -184,10 +184,34 @@ enum igt_suspend_test {
SUSPEND_TEST_NUM,
 };
 
+/**
+ * igt_suspend_to_mem_mode:
+ * @SUSPEND_TO_MEM_S2IDLE: suspend to mem maps to @SUSPEND_STATE_FREEZE
+ * @SUSPEND_TO_MEM_SHALLOW: suspend to mem maps to @SUSPEND_STATE_STANDBY
+ * @SUSPEND_TO_MEM_DEEP: suspend to mem will target the ACPI S3 state
+ *
+ * The target system state when suspending to mem:
+ * - Suspending with @SUSPEND_STATE_MEM/@SUSPEND_TO_MEM_S2IDLE is equivalent to
+ *   suspending with @SUSPEND_STATE_FREEZE.
+ * - Suspending with @SUSPEND_STATE_MEM/@SUSPEND_TO_MEM_SHALLOW is equivalent 
to
+ *   suspending with @SUSPEND_STATE_STANDBY.
+ * - Suspending with @SUSPEND_STATE_MEM/@SUSPEND_TO_MEM_DEEP will target the
+ *   ACPI S3 state.
+ */
+enum igt_suspend_to_mem_mode {
+   SUSPEND_TO_MEM_S2IDLE,
+   SUSPEND_TO_MEM_SHALLOW,
+   SUSPEND_TO_MEM_DEEP,
+
+   /*< private >*/
+   SUSPEND_TO_MEM_NUM,
+};
+
 void igt_system_suspend_autoresume(enum igt_suspend_state state,
   enum igt_suspend_test test);
 void igt_set_autoresume_delay(int delay_secs);
 int igt_get_autoresume_delay(enum igt_suspend_state state);
+enum igt_suspend_to_mem_mode igt_get_suspend_to_mem_mode(void);
 
 /* dropping priviledges */
 void igt_drop_root(void);
-- 
2.17.1

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

[Intel-gfx] [PATCH i-g-t 5/7] Add tests/gem_blt_parse

2019-11-13 Thread Mika Kuoppala
From: Mika Kuoppala 

For testing blitter engine command parser on gen9.

v2: bad jump offset
v3: rebase
v4: improve bb start and subcase it
v5: fix presumed offsets (Jon)

Signed-off-by: Mika Kuoppala 
---
 tests/Makefile.sources|   3 +
 tests/i915/gem_blt_parse.c| 997 ++
 tests/intel-ci/fast-feedback.testlist |   1 +
 tests/meson.build |   1 +
 4 files changed, 1002 insertions(+)
 create mode 100644 tests/i915/gem_blt_parse.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index abf1e2fc..75c79edb 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -244,6 +244,9 @@ gem_exec_params_SOURCES = i915/gem_exec_params.c
 TESTS_progs += gem_exec_parse
 gem_exec_parse_SOURCES = i915/gem_exec_parse.c
 
+TESTS_progs += gem_blt_parse
+gem_blt_parse_SOURCES = i915/gem_blt_parse.c
+
 TESTS_progs += gem_exec_reloc
 gem_exec_reloc_SOURCES = i915/gem_exec_reloc.c
 
diff --git a/tests/i915/gem_blt_parse.c b/tests/i915/gem_blt_parse.c
new file mode 100644
index ..607afba9
--- /dev/null
+++ b/tests/i915/gem_blt_parse.c
@@ -0,0 +1,997 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#ifndef I915_PARAM_CMD_PARSER_VERSION
+#define I915_PARAM_CMD_PARSER_VERSION   28
+#endif
+
+#ifndef I915_PARAM_HAS_SECURE_BATCHES
+#define I915_PARAM_HAS_SECURE_BATCHES   23
+#endif
+
+/* To help craft commands known to be invalid across all engines */
+#define INSTR_CLIENT_SHIFT 29
+#define   INSTR_INVALID_CLIENT  0x7
+
+#define MI_LOAD_REGISTER_REG (0x2a << 23)
+#define MI_STORE_REGISTER_MEM (0x24 << 23)
+#define MI_ARB_ON_OFF (0x8 << 23)
+#define MI_USER_INTERRUPT (0x02 << 23)
+#define MI_FLUSH_DW (0x26 << 23)
+#define MI_ARB_CHECK (0x05 << 23)
+#define MI_REPORT_HEAD (0x07 << 23)
+#define MI_SUSPEND_FLUSH (0x0b << 23)
+#define MI_LOAD_SCAN_LINES_EXCL (0x13 << 23)
+#define MI_UPDATE_GTT (0x23 << 23)
+
+#define BCS_SWCTRL 0x22200
+#define BCS_GPR_BASE   0x22600
+#define BCS_GPR(n) (0x22600 + (n) * 8)
+#define BCS_GPR_UDW(n) (0x22600 + (n) * 8 + 4)
+
+#define HANDLE_SIZE  4096
+
+static int parser_version;
+
+static int command_parser_version(int fd)
+{
+   int version = -1;
+   drm_i915_getparam_t gp;
+
+   gp.param = I915_PARAM_CMD_PARSER_VERSION;
+   gp.value = 
+
+   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) == 0)
+   return version;
+
+   return -1;
+}
+
+static int  __exec_batch_patched(int fd, int engine,
+uint32_t cmd_bo, const uint32_t *cmds, int 
size,
+uint32_t target_bo, uint64_t target_offset, 
uint64_t target_delta)
+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[1];
+
+   gem_write(fd, cmd_bo, 0, cmds, size);
+
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = target_bo;
+   obj[1].handle = cmd_bo;
+
+   memset(reloc, 0, sizeof(reloc));
+   reloc[0].offset = target_offset;
+   reloc[0].target_handle = target_bo;
+   reloc[0].delta = target_delta;
+   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
+   reloc[0].presumed_offset = -1;
+
+   obj[1].relocs_ptr = to_user_pointer(reloc);
+   obj[1].relocation_count = 1;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+   execbuf.batch_len = size;
+   execbuf.flags = engine;
+
+   return __gem_execbuf(fd, );
+}
+
+static void exec_batch_patched(int fd, int engine,
+  uint32_t cmd_bo, const uint32_t *cmds,
+  int 

[Intel-gfx] [PATCH i-g-t 1/7] lib/igt_dummyload: Send batch as first

2019-11-13 Thread Mika Kuoppala
To simplify emitting the recursive batch, make batch
always the first object on the execbuf list.

v2: set handles early, poll_ptr indecency (Chris)
v3: allow dep with poll
v4: fix gem_exec_schedule
v5: rebase
v6: rebase
v6: gem_ctx_shared
v7: conditional close of poll handle

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 lib/igt_dummyload.c| 111 +
 lib/igt_dummyload.h|   8 ++-
 tests/i915/gem_exec_balancer.c |   8 +--
 tests/i915/gem_spin_batch.c|  13 ++--
 4 files changed, 73 insertions(+), 67 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index b9e239db..c079bd04 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -63,6 +63,7 @@
 #define MI_ARB_CHK (0x5 << 23)
 
 static const int BATCH_SIZE = 4096;
+static const int POLL_SIZE = 4096;
 static const int LOOP_START_OFFSET = 64;
 
 static IGT_LIST_HEAD(spin_list);
@@ -72,16 +73,23 @@ static int
 emit_recursive_batch(igt_spin_t *spin,
 int fd, const struct igt_spin_factory *opts)
 {
-#define SCRATCH 0
+
 #define BATCH IGT_SPIN_BATCH
+#define POLL 1
+#define DEP 2
const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_relocation_entry relocs[2], *r;
+   struct drm_i915_gem_exec_object2 * const batch =
+   >obj[BATCH];
+   struct drm_i915_gem_exec_object2 * const poll =
+   >obj[POLL];
+   struct drm_i915_gem_exec_object2 * const dep =
+   >obj[DEP];
+   struct drm_i915_gem_relocation_entry relocs[4], *r;
struct drm_i915_gem_execbuffer2 *execbuf;
-   struct drm_i915_gem_exec_object2 *obj;
unsigned int flags[GEM_MAX_ENGINES];
unsigned int nengine;
int fence_fd = -1;
-   uint32_t *cs, *batch;
+   uint32_t *cs, *batch_start;
int i;
 
nengine = 0;
@@ -103,64 +111,48 @@ emit_recursive_batch(igt_spin_t *spin,
memset(>execbuf, 0, sizeof(spin->execbuf));
execbuf = >execbuf;
memset(spin->obj, 0, sizeof(spin->obj));
-   obj = spin->obj;
memset(relocs, 0, sizeof(relocs));
 
-   obj[BATCH].handle = gem_create(fd, BATCH_SIZE);
-   batch = __gem_mmap__wc(fd, obj[BATCH].handle,
+   batch->handle = gem_create(fd, BATCH_SIZE);
+   spin->handle = batch->handle;
+
+   batch_start = __gem_mmap__wc(fd, batch->handle,
 0, BATCH_SIZE, PROT_WRITE);
-   if (!batch)
-   batch = gem_mmap__gtt(fd, obj[BATCH].handle,
+   if (!batch_start)
+   batch_start = gem_mmap__gtt(fd, batch->handle,
BATCH_SIZE, PROT_WRITE);
-
-   gem_set_domain(fd, obj[BATCH].handle,
+   gem_set_domain(fd, batch->handle,
   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
execbuf->buffer_count++;
-   cs = batch;
-
-   if (opts->dependency) {
-   igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
-
-   r = [obj[BATCH].relocation_count++];
-
-   /* dummy write to dependency */
-   obj[SCRATCH].handle = opts->dependency;
-   r->presumed_offset = 0;
-   r->target_handle = obj[SCRATCH].handle;
-   r->offset = sizeof(uint32_t) * 1020;
-   r->delta = 0;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = I915_GEM_DOMAIN_RENDER;
+   cs = batch_start;
 
+   poll->handle = gem_create(fd, POLL_SIZE);
+   spin->poll_handle = poll->handle;
execbuf->buffer_count++;
-   } else if (opts->flags & IGT_SPIN_POLL_RUN) {
-   r = [obj[BATCH].relocation_count++];
 
-   igt_assert(!opts->dependency);
+   if (opts->flags & IGT_SPIN_POLL_RUN) {
+   r = [batch->relocation_count++];
 
if (gen == 4 || gen == 5) {
execbuf->flags |= I915_EXEC_SECURE;
igt_require(__igt_device_set_master(fd) == 0);
}
 
-   spin->poll_handle = gem_create(fd, 4096);
-   obj[SCRATCH].handle = spin->poll_handle;
-
-   if (__gem_set_caching(fd, spin->poll_handle,
+   if (__gem_set_caching(fd, poll->handle,
  I915_CACHING_CACHED) == 0)
-   spin->poll = gem_mmap__cpu(fd, spin->poll_handle,
-  0, 4096,
+   spin->poll = gem_mmap__cpu(fd, poll->handle,
+  0, POLL_SIZE,
   PROT_READ | PROT_WRITE);
else
-   spin->poll = gem_mmap__wc(fd, spin->poll_handle,
- 0, 4096,
+   spin->poll = gem_mmap__wc(fd, poll->handle,
+ 0, 

[Intel-gfx] [PATCH i-g-t 2/7] igt: Use COND_BBEND for busy spinning on gen9

2019-11-13 Thread Mika Kuoppala
From: Jon Bloomfield 

gen9+ introduces a cmdparser for the BLT engine which copies the
incoming BB to a kmd owned buffer for submission (to prevent changes
being made after the bb has been safely scanned). This breaks the
spin functionality because it relies on changing the submitted spin
buffers in order to terminate them.

Instead, for gen9+, we change the semantics by introducing a COND_BB_END
into the infinite loop, to wait until a memory flag (in anothe bo) is
cleared.

v2: Correct nop length to avoid overwriting bb_end instr when using
a dependency bo (cork)
v3: fix conflicts on igt_dummyload (Mika)
v4: s/bool running/uint32_t running, fix r->delta (Mika)
v5: remove overzealous assert (Mika)
v6: rebase on top of lib changes (Mika)
v7: rework on top of public igt lib changes (Mika)
v8: rebase

Signed-off-by: Jon Bloomfield  (v2)
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Mika Kuoppala 
Signed-off-by: Mika Kuoppala 
---
 lib/i830_reg.h  |  2 +-
 lib/igt_dummyload.c | 46 +++--
 lib/igt_dummyload.h |  3 ++
 lib/intel_reg.h |  3 ++
 tests/i915/gem_double_irq_loop.c|  2 --
 tests/i915/gem_write_read_ring_switch.c |  2 +-
 6 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/lib/i830_reg.h b/lib/i830_reg.h
index a57691c7..41020256 100644
--- a/lib/i830_reg.h
+++ b/lib/i830_reg.h
@@ -43,7 +43,7 @@
 /* broadwater flush bits */
 #define BRW_MI_GLOBAL_SNAPSHOT_RESET   (1 << 3)
 
-#define MI_COND_BATCH_BUFFER_END   (0x36<<23 | 1)
+#define MI_COND_BATCH_BUFFER_END   (0x36 << 23)
 #define MI_DO_COMPARE  (1<<21)
 
 #define MI_BATCH_BUFFER_END(0xA << 23)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index c079bd04..a88c8582 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -130,7 +130,15 @@ emit_recursive_batch(igt_spin_t *spin,
spin->poll_handle = poll->handle;
execbuf->buffer_count++;
 
-   if (opts->flags & IGT_SPIN_POLL_RUN) {
+   /*
+* For gen9+ we use a conditional loop rather than an
+* infinite loop, because we are unable to modify the
+* BB's once they have been scanned by the cmdparser
+* We share the poll buffer for the conditional test
+* and is always the first buffer in the batch list
+*/
+
+   if (gen >= 9 || (opts->flags & IGT_SPIN_POLL_RUN)) {
r = [batch->relocation_count++];
 
if (gen == 4 || gen == 5) {
@@ -150,6 +158,13 @@ emit_recursive_batch(igt_spin_t *spin,
 
igt_assert_eq(spin->poll[SPIN_POLL_START_IDX], 0);
 
+   /*
+* 2nd word used to control conditional end, and is cleared
+* to terminate batch. Must be >=1 to spin
+*/
+   spin->poll[SPIN_POLL_END_IDX] = 1;
+   __sync_synchronize();
+
/* batch is first */
r->presumed_offset = BATCH_SIZE;
r->target_handle = poll->handle;
@@ -208,7 +223,26 @@ emit_recursive_batch(igt_spin_t *spin,
 * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
 */
if (!(opts->flags & IGT_SPIN_FAST))
-   cs += 1000;
+   cs += 960;
+
+   igt_assert_eq(spin->using_cond_end, 0);
+   if (gen >= 9) {
+   r = [batch->relocation_count++];
+
+   /* batch is first, so poll is second */
+   r->presumed_offset = BATCH_SIZE;
+   r->target_handle = poll->handle;
+   r->offset = (cs + 2 - batch_start) * sizeof(*cs);
+   r->read_domains = I915_GEM_DOMAIN_COMMAND;
+   r->delta = SPIN_POLL_END_IDX * sizeof(*cs);
+
+   *cs++ = MI_COND_BATCH_BUFFER_END | 1 << 21 | 2;
+   *cs++ = 0; /* Reference value */
+   *cs++ = r->presumed_offset + r->delta;
+   *cs++ = 0;
+
+   spin->using_cond_end = 1;
+   }
 
/* recurse */
r = [batch->relocation_count++];
@@ -401,6 +435,9 @@ void igt_spin_set_timeout(igt_spin_t *spin, int64_t ns)
  */
 void igt_spin_reset(igt_spin_t *spin)
 {
+   if (spin->using_cond_end)
+   spin->poll[SPIN_POLL_END_IDX] = 1;
+
if (igt_spin_has_poll(spin))
spin->poll[SPIN_POLL_START_IDX] = 0;
 
@@ -419,7 +456,12 @@ void igt_spin_end(igt_spin_t *spin)
if (!spin)
return;
 
+   if (spin->using_cond_end) {
+   spin->poll[SPIN_POLL_END_IDX] = 0;
+   } else {
*spin->condition = MI_BATCH_BUFFER_END;
+   }
+
__sync_synchronize();
 }
 
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index de5781d7..e9310b4e 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -51,6 +51,9 @@ typedef struct igt_spin {
uint32_t poll_handle;
uint32_t *poll;
 #define SPIN_POLL_START_IDX 0
+#define 

[Intel-gfx] [PATCH i-g-t 7/7] test/i915: Add i915_rc6_ctx_corruption

2019-11-13 Thread Mika Kuoppala
From: Imre Deak 

Add a test to exercise the kernel's mechanism to detection of RC6
context corruptions, take the necessary action in response (disable
RC6 and runtime PM) and recover when possible (after system
suspend/resume).

v2:
- Skip test on non-existing engines.
- Fix for old kernels where the command parser returned EINVAL
  instead of EACCESS for a banned privilidged command.

Signed-off-by: Imre Deak 
---
 tests/Makefile.sources   |   3 +
 tests/i915/i915_rc6_ctx_corruption.c | 196 +++
 tests/meson.build|   1 +
 3 files changed, 200 insertions(+)
 create mode 100644 tests/i915/i915_rc6_ctx_corruption.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 75c79edb..c0f401c7 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -529,6 +529,9 @@ i915_pm_sseu_SOURCES = i915/i915_pm_sseu.c
 TESTS_progs += i915_query
 i915_query_SOURCES = i915/i915_query.c
 
+TESTS_progs += i915_rc6_ctx_corruption
+i915_rc6_ctx_corruption_SOURCES = i915/i915_rc6_ctx_corruption.c
+
 TESTS_progs += i915_selftest
 i915_selftest_SOURCES = i915/i915_selftest.c
 
diff --git a/tests/i915/i915_rc6_ctx_corruption.c 
b/tests/i915/i915_rc6_ctx_corruption.c
new file mode 100644
index ..a3326307
--- /dev/null
+++ b/tests/i915/i915_rc6_ctx_corruption.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+
+#include "igt.h"
+#include "igt_gt.h"
+#include "igt_device.h"
+
+#define CTX_INFO_REG   0xA300
+
+static int drm_fd;
+static struct pci_device *pci_dev;
+static uint32_t devid;
+
+static int read_reg_on_engine(const struct intel_execution_engine2 *engine,
+ int reg_address, uint32_t *reg_val)
+{
+   const bool r64b = intel_gen(devid) >= 8;
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[1];
+   struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t *batch;
+   uint32_t *dst_buf;
+   int ret;
+   int i;
+
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = gem_create(drm_fd, 4096);
+   obj[1].handle = gem_create(drm_fd, 4096);
+   obj[1].relocs_ptr = to_user_pointer(reloc);
+   obj[1].relocation_count = 1;
+
+   batch = gem_mmap__cpu(drm_fd, obj[1].handle, 0, 4096, PROT_WRITE);
+   gem_set_domain(drm_fd, obj[1].handle,
+  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+
+   i = 0;
+   batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */
+   batch[i++] = reg_address;
+   reloc[0].target_handle = obj[0].handle;
+   reloc[0].presumed_offset = obj[0].offset;
+   reloc[0].offset = i * sizeof(uint32_t);
+   reloc[0].delta = 0;
+   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
+   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
+   batch[i++] = reloc[0].delta;
+   if (r64b)
+   batch[i++] = 0;
+
+   batch[i++] = MI_BATCH_BUFFER_END;
+   munmap(batch, 4096);
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+   execbuf.flags = engine->flags;
+
+   ret = __gem_execbuf(drm_fd, );
+   gem_close(drm_fd, obj[1].handle);
+
+   if (ret)
+   goto err;
+
+   if (reg_val) {
+   dst_buf = gem_mmap__cpu(drm_fd, obj[0].handle, 0, 4096,
+   PROT_READ);
+   gem_set_domain(drm_fd, obj[0].handle, I915_GEM_DOMAIN_CPU, 0);
+
+   *reg_val = dst_buf[0];
+   munmap(dst_buf, 4096);
+   }
+
+err:
+   gem_close(drm_fd, obj[0].handle);
+
+   return ret;
+}
+
+static bool need_ctx_corruption_wa(void)
+{
+   return IS_BROADWELL(devid) || intel_gen(devid) == 9;
+}
+
+static void test_read_on_engine(const struct 

[Intel-gfx] [PATCH i-g-t 4/7] tests/i915: Skip if secure batches is not available

2019-11-13 Thread Mika Kuoppala
From: "Kuoppala, Mika" 

If we can't do secure execbuf, there is no point in trying.

Signed-off-by: Kuoppala, Mika 
---
 tests/i915/gem_exec_params.c   | 16 
 tests/i915/gem_mocs_settings.c | 14 ++
 tests/perf_pmu.c   | 11 +++
 3 files changed, 41 insertions(+)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index 8f15e645..c5517b07 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -193,6 +193,19 @@ static void test_batch_first(int fd)
gem_close(fd, obj[0].handle);
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp;
+
+   gp.param = I915_PARAM_HAS_SECURE_BATCHES;
+   gp.value = 
+
+   igt_assert_eq(drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ), 0);
+
+   return v;
+}
+
 struct drm_i915_gem_execbuffer2 execbuf;
 struct drm_i915_gem_exec_object2 gem_exec[1];
 uint32_t batch[2] = {MI_BATCH_BUFFER_END};
@@ -340,6 +353,8 @@ igt_main
}
 
igt_subtest("secure-non-root") {
+   igt_require(has_secure_batches(fd));
+
igt_fork(child, 1) {
igt_drop_root();
 
@@ -352,6 +367,7 @@ igt_main
 
igt_subtest("secure-non-master") {
igt_require(__igt_device_set_master(fd) == 0); /* Requires root 
privilege */
+   igt_require(has_secure_batches(fd));
 
igt_device_drop_master(fd);
execbuf.flags = I915_EXEC_RENDER | I915_EXEC_SECURE;
diff --git a/tests/i915/gem_mocs_settings.c b/tests/i915/gem_mocs_settings.c
index fc2ccb21..82eb8a3f 100644
--- a/tests/i915/gem_mocs_settings.c
+++ b/tests/i915/gem_mocs_settings.c
@@ -225,6 +225,19 @@ static uint32_t get_engine_base(int fd, uint32_t engine)
}
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp;
+
+   gp.param = I915_PARAM_HAS_SECURE_BATCHES;
+   gp.value = 
+
+   igt_assert_eq(drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ), 0);
+
+   return v;
+}
+
 #define MI_STORE_REGISTER_MEM_64_BIT_ADDR  ((0x24 << 23) | 2)
 
 static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
@@ -566,6 +579,7 @@ igt_main
igt_require_gem(fd);
gem_require_mocs_registers(fd);
igt_require(get_mocs_settings(fd, , false));
+   igt_require(has_secure_batches(fd));
}
 
for (e = intel_execution_engines; e->name; e++) {
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e2bd2cc5..296d04c6 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -893,6 +893,16 @@ static int wait_vblank(int fd, union drm_wait_vblank *vbl)
return err;
 }
 
+static int has_secure_batches(const int fd)
+{
+   int v = -1;
+   drm_i915_getparam_t gp;
+   gp.param = I915_PARAM_HAS_SECURE_BATCHES;
+   gp.value = 
+   igt_assert_eq(drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ), 0);
+   return v;
+}
+
 static void
 event_wait(int gem_fd, const struct intel_execution_engine2 *e)
 {
@@ -910,6 +920,7 @@ event_wait(int gem_fd, const struct intel_execution_engine2 
*e)
 
devid = intel_get_drm_devid(gem_fd);
igt_require(intel_gen(devid) >= 7);
+   igt_require(has_secure_batches(fd));
igt_skip_on(IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid));
 
kmstest_set_vt_graphics_mode();
-- 
2.17.1

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

[Intel-gfx] [PATCH i-g-t 3/7] lib/i915: Add query to detect if engine accepts only ro batches

2019-11-13 Thread Mika Kuoppala
From: "Kuoppala, Mika" 

If cmd parser is mandatory, batch can't be modified post execbuf.
Some tests rely on modifying batch post execbuf. Give those
tests a method to query if those modifications ever reach
the actual engine command stream.

v2: pull in the test changes, doh
v3: class based query
v4: rebase

Signed-off-by: Kuoppala, Mika 
---
 lib/i915/gem_submission.c  | 62 ++
 lib/i915/gem_submission.h  |  2 ++
 tests/i915/gem_busy.c  |  7 +++-
 tests/i915/gem_exec_async.c|  3 ++
 tests/i915/gem_exec_await.c|  7 +++-
 tests/i915/gem_exec_fence.c|  8 +
 tests/i915/gem_exec_latency.c  |  7 
 tests/i915/gem_exec_nop.c  |  4 ++-
 tests/i915/gem_exec_schedule.c |  6 +++-
 tests/i915/gem_exec_whisper.c  |  4 ++-
 tests/prime_busy.c |  3 ++
 tests/prime_vgem.c |  6 
 12 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submission.c
index 4f946493..9bdf28bc 100644
--- a/lib/i915/gem_submission.c
+++ b/lib/i915/gem_submission.c
@@ -64,6 +64,22 @@ static bool has_semaphores(int fd, int dir)
return val;
 }
 
+static int cmd_parser_version(int fd)
+{
+   int val = 0;
+   struct drm_i915_getparam gp = {
+   gp.param = I915_PARAM_CMD_PARSER_VERSION,
+   gp.value = ,
+   };
+
+   if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, ) < 0) {
+   val = -errno;
+   igt_assert(val < 0);
+   }
+
+   return val;
+}
+
 /**
  * gem_submission_method:
  * @fd: open i915 drm file descriptor
@@ -253,3 +269,49 @@ void gem_require_blitter(int i915)
 {
igt_require(gem_has_blitter(i915));
 }
+
+static bool gem_engine_has_immutable_submission(int i915, int class)
+{
+   const int gen = intel_gen(intel_get_drm_devid(i915));
+int parser_version;
+
+   parser_version = cmd_parser_version(i915);
+
+   if (parser_version < 0)
+   return false;
+
+   if (gen == 9 && class == I915_ENGINE_CLASS_COPY && parser_version > 9)
+   return true;
+
+   return false;
+}
+
+
+/**
+ * gem_class_has_mutable_submission:
+ * @i915: open i915 drm file descriptor
+ * @class: engine class
+ *
+ * Returns boolean value if the engine class allows batch modifications
+ * post execbuf.
+ */
+
+bool
+gem_class_has_mutable_submission(int fd, int class)
+{
+   return !gem_engine_has_immutable_submission(fd, class);
+}
+
+/**
+ * gem_engine_has_mutable_submission:
+ * @i915: open i915 drm file descriptor
+ * @engine: the engine (I915_EXEC_RING id) of target
+ *
+ * Returns boolean value if the engine allows batch modifications
+ * post execbuf.
+ */
+bool gem_engine_has_mutable_submission(int i915, unsigned int engine)
+{
+   return gem_class_has_mutable_submission(i915,
+   
gem_execbuf_flags_to_engine_class(engine));
+}
diff --git a/lib/i915/gem_submission.h b/lib/i915/gem_submission.h
index 6deb7e2d..acd24bcb 100644
--- a/lib/i915/gem_submission.h
+++ b/lib/i915/gem_submission.h
@@ -34,6 +34,8 @@ void gem_submission_print_method(int fd);
 bool gem_has_semaphores(int fd);
 bool gem_has_execlists(int fd);
 bool gem_has_guc_submission(int fd);
+bool gem_engine_has_mutable_submission(int fd, unsigned int engine);
+bool gem_class_has_mutable_submission(int fd, int class);
 
 int gem_cmdparser_version(int i915, uint32_t engine);
 static inline bool gem_has_cmdparser(int i915, uint32_t engine)
diff --git a/tests/i915/gem_busy.c b/tests/i915/gem_busy.c
index a8388149..b84e2bd1 100644
--- a/tests/i915/gem_busy.c
+++ b/tests/i915/gem_busy.c
@@ -243,6 +243,10 @@ static void one(int fd, const struct 
intel_execution_engine2 *e, unsigned test_f
i++;
 
igt_assert(i < size/sizeof(*batch));
+
+   if ((test_flags & HANG) == 0)
+   igt_require(gem_class_has_mutable_submission(fd, e->class));
+
igt_require(__gem_execbuf(fd, ) == 0);
 
__gem_busy(fd, obj[SCRATCH].handle, [SCRATCH], [SCRATCH]);
@@ -256,7 +260,8 @@ static void one(int fd, const struct 
intel_execution_engine2 *e, unsigned test_f
e2->instance == e->instance)
continue;
 
-   if (!gem_class_can_store_dword(fd, e2->class))
+   if (!gem_class_can_store_dword(fd, e2->class) ||
+   !gem_class_has_mutable_submission(fd, e2->class))
continue;
 
igt_debug("Testing %s in parallel\n", e2->name);
diff --git a/tests/i915/gem_exec_async.c b/tests/i915/gem_exec_async.c
index d83e9f6d..b9859ffa 100644
--- a/tests/i915/gem_exec_async.c
+++ b/tests/i915/gem_exec_async.c
@@ -138,6 +138,9 @@ static void one(int fd, unsigned ring, uint32_t flags)
execbuf.buffers_ptr = to_user_pointer(obj);
execbuf.buffer_count = 2;
execbuf.flags = ring | flags;
+
+   

  1   2   >