[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow privileged user to map the OA buffer (rev7)

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

Series: Allow privileged user to map the OA buffer (rev7)
URL   : https://patchwork.freedesktop.org/series/79460/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18279_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@debugfs-reader:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl7/igt@i915_susp...@debugfs-reader.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-skl10/igt@i915_susp...@debugfs-reader.html

  * igt@perf_pmu@module-unload:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb8/igt@perf_...@module-unload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-tglb2/igt@perf_...@module-unload.html
- shard-kbl:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl6/igt@perf_...@module-unload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-kbl4/igt@perf_...@module-unload.html
- shard-iclb: [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb8/igt@perf_...@module-unload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-iclb4/igt@perf_...@module-unload.html
- shard-glk:  [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk2/igt@perf_...@module-unload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-glk8/igt@perf_...@module-unload.html

  * igt@runner@aborted:
- shard-iclb: NOTRUN -> [FAIL][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-iclb4/igt@run...@aborted.html
- shard-tglb: NOTRUN -> [FAIL][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-tglb2/igt@run...@aborted.html

  
 Warnings 

  * igt@perf_pmu@module-unload:
- shard-skl:  [DMESG-WARN][13] ([i915#1982]) -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl9/igt@perf_...@module-unload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-skl3/igt@perf_...@module-unload.html

  
New tests
-

  New tests have been introduced between CI_DRM_8817_full and 
Patchwork_18279_full:

### New IGT tests (9) ###

  * igt@perf@closed-fd-and-unmapped-access:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.32] s

  * igt@perf@invalid-map-oa-buffer:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.17] s

  * igt@perf@map-oa-buffer:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.31] s

  * igt@perf@non-privileged-access-vaddr:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.29] s

  * igt@perf@non-privileged-map-oa-buffer:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.22] s

  * igt@perf@oa-regs-not-whitelisted:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.21] s

  * igt@perf@oa-regs-whitelisted:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 0.26] s

  * igt@perf@triggered-oa-reports-paranoid-0:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 3.60] s

  * igt@perf@triggered-oa-reports-paranoid-1:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 3.27] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#1930])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_exec_reloc@basic-cpu-wc:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / 
[i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl2/igt@gem_exec_re...@basic-cpu-wc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/shard-apl6/igt@gem_exec_re...@basic-cpu-wc.html

  * igt@gen9_exec_parse@allowed-all:
- shard-apl:  [PASS][19] -> 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/kmb: Add support for KeemBay Display (rev2)

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

Series: drm/kmb: Add support for KeemBay Display (rev2)
URL   : https://patchwork.freedesktop.org/series/79615/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18278_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@parallel@vecs0:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +20 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl1/igt@gem_busy@paral...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-skl10/igt@gem_busy@paral...@vecs0.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd1:
- shard-kbl:  [PASS][3] -> [FAIL][4] ([i915#1528])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-kbl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd1.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-iclb: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb1/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@i915_module_load@reload:
- shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb8/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-tglb5/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@execlists:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#1795])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl2/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-skl3/igt@i915_selftest@l...@execlists.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk:  [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / 
[i915#95])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +5 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([i915#300])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk6/igt@kms_cursor_edge_w...@pipe-b-256x256-left-edge.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-glk4/igt@kms_cursor_edge_w...@pipe-b-256x256-left-edge.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank@b-edp1:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#2122]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl5/igt@kms_flip@flip-vs-blocking-wf-vbl...@b-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-skl4/igt@kms_flip@flip-vs-blocking-wf-vbl...@b-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-dp1:
- shard-apl:  [PASS][21] -> [FAIL][22] ([i915#1635] / [i915#79])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl4/igt@kms_flip@flip-vs-expired-vbl...@a-dp1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-apl2/igt@kms_flip@flip-vs-expired-vbl...@a-dp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([i915#1982])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/shard-kbl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html

  * 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Support multiple pinned timelines (rev3)

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

Series: drm/i915/gt: Support multiple pinned timelines (rev3)
URL   : https://patchwork.freedesktop.org/series/80098/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18277_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@mock@timelines:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl3/igt@i915_selftest@m...@timelines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-kbl7/igt@i915_selftest@m...@timelines.html
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb5/igt@i915_selftest@m...@timelines.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-iclb4/igt@i915_selftest@m...@timelines.html
- shard-glk:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk7/igt@i915_selftest@m...@timelines.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-glk2/igt@i915_selftest@m...@timelines.html
- shard-skl:  [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl8/igt@i915_selftest@m...@timelines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-skl10/igt@i915_selftest@m...@timelines.html
- shard-tglb: [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb2/igt@i915_selftest@m...@timelines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-tglb1/igt@i915_selftest@m...@timelines.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@parallel@vecs0:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +14 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl1/igt@gem_busy@paral...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-skl5/igt@gem_busy@paral...@vecs0.html

  * igt@gem_exec_whisper@basic-fds:
- shard-glk:  [PASS][13] -> [DMESG-WARN][14] ([i915#118] / 
[i915#95])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk1/igt@gem_exec_whis...@basic-fds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-glk5/igt@gem_exec_whis...@basic-fds.html

  * igt@i915_selftest@mock@timelines:
- shard-apl:  [PASS][15] -> [INCOMPLETE][16] ([i915#1635])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl8/igt@i915_selftest@m...@timelines.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-apl1/igt@i915_selftest@m...@timelines.html
- shard-snb:  [PASS][17] -> [INCOMPLETE][18] ([i915#82])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-snb2/igt@i915_selftest@m...@timelines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-snb2/igt@i915_selftest@m...@timelines.html

  * 
igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / 
[i915#1982]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-apl4/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +2 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-mmap-wc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-mmap-wc.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +3 
similar issues
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer (rev7)

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

Series: Allow privileged user to map the OA buffer (rev7)
URL   : https://patchwork.freedesktop.org/series/79460/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18279


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] / 
[i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- fi-bsw-n3050:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][15] ([i915#2089]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2:  [DMESG-FAIL][17] ([i915#1233]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload:
- fi-icl-u2:  [DMESG-WARN][21] ([i915#289]) -> [DMESG-WARN][22] 
([i915#1982] / [i915#289])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_module_l...@reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-icl-u2/igt@i915_module_l...@reload.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][24] ([i915#62] / [i915#92])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18279/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][25] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][26] ([i915#62] / [i915#92] 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer (rev7)

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

Series: Allow privileged user to map the OA buffer (rev7)
URL   : https://patchwork.freedesktop.org/series/79460/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers

2020-07-30 Thread Umesh Nerlige Ramappa
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.

A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.

v2:
- Bump up the perf revision (Lionel)
- Use indexing for counters (Lionel)
- Fix selftest for oa ticking register (Umesh)

v3: Pardon whitelisted registers for selftest (Umesh)

v4:
- Document whitelisted registers (Lionel)
- Fix live isolated whitelist for OA regs (Umesh)

v5:
- Free up whitelist slots. Remove GPU_TICKS and A20 counter (Piotr)
- Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)

v6: Move oa whitelist array to i915_perf (Chris)

Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_perf.c | 18 +-
 drivers/gpu/drm/i915/i915_reg.h  |  8 
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d644cb5118d6..8ff502719dfd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1350,11 +1350,19 @@ free_noa_wait(struct i915_perf_stream *stream)
 static struct i915_whitelist_reg gen9_oa_wl_regs[] = {
{ OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+   { OA_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
+   { GEN8_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
 };
 
 static struct i915_whitelist_reg gen12_oa_wl_regs[] = {
{ GEN12_OAG_OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ GEN12_OAG_OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+   { GEN12_OAG_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+   RING_FORCE_TO_NONPRIV_RANGE_4 },
+   { GEN12_OAG_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4 },
 };
 
 static void intel_engine_apply_oa_whitelist(struct i915_perf_stream *stream)
@@ -4515,8 +4523,16 @@ int i915_perf_ioctl_version(void)
 *into the OA buffer. This applies only to gen8+. The feature can
 *only be accessed if perf_stream_paranoid is set to 0 by privileged
 *user.
+*
+* 7: Whitelist below OA registers for user to identify the location of
+*triggered reports in the OA buffer. This applies only to gen8+.
+*The feature can only be accessed if perf_stream_paranoid is set to
+*0 by privileged user.
+*
+*- OA buffer head/tail/status/buffer registers for read only
+*- OA counters A18, A19, A20 for read/write
 */
-   return 6;
+   return 7;
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 377339399458..6b93a5686cba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -974,6 +974,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define OAREPORTTRIG8_NOA_SELECT_6_SHIFT24
 #define OAREPORTTRIG8_NOA_SELECT_7_SHIFT28
 
+/* Performance counters registers */
+#define OA_PERF_COUNTER_A(idx)   _MMIO(0x2800 + 8 * (idx))
+#define OA_PERF_COUNTER_A_UPPER(idx) _MMIO(0x2800 + 8 * (idx) + 4)
+
+/* Gen12 Performance counters registers */
+#define GEN12_OAG_PERF_COUNTER_A(idx)   _MMIO(0xD980 + 8 * (idx))
+#define GEN12_OAG_PERF_COUNTER_A_UPPER(idx) _MMIO(0xD980 + 8 * (idx) + 4)
+
 /* Same layout as OASTARTTRIGX */
 #define GEN12_OAG_OASTARTTRIG1 _MMIO(0xd900)
 #define GEN12_OAG_OASTARTTRIG2 _MMIO(0xd904)
-- 
2.20.1

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


[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query

2020-07-30 Thread Umesh Nerlige Ramappa
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggered reports within oa buffer.

Triggering reports into the OA buffer is achieved by writing into a
a trigger register. Optionally an unused counter/register is set with a
marker value such that a triggered report can be identified in the OA
buffer. Reports are usually triggered at the start and end of work that
is measured.

Since OA buffer is large and queries can be frequent, an efficient way
to look for triggered reports is required. By knowing the current head
and tail offsets into the OA buffer, it is easier to determine the
locality of the reports of interest.

Current perf OA interface does not expose head/tail information to the
user and it filters out invalid reports before sending data to user.
Also considering limited size of user buffer used during a query,
creating a 1:1 copy of the OA buffer at the user space added undesired
complexity.

The solution was to map the OA buffer to user space provided

(1) that it is accessed from a privileged user.
(2) OA report filtering is not used.

These 2 conditions would satisfy the safety criteria that the current
perf interface addresses.

To enable the query:
- Add an ioctl to expose head and tail to the user
- Add an ioctl to return size and offset of the OA buffer
- Map the OA buffer to the user space

v2:
- Improve commit message (Chris)
- Do not mmap based on gem object filp. Instead, use perf_fd and support
  mmap syscall (Chris)
- Pass non-zero offset in mmap to enforce the right object is
  mapped (Chris)
- Do not expose gpu_address (Chris)
- Verify start and length of vma for page alignment (Lionel)
- Move SQNTL config out (Lionel)

v3: (Chris)
- Omit redundant checks
- Return VM_FAULT_SIGBUS is old stream is closed
- Maintain reference counts to stream in vm_open and vm_close
- Use switch to identify object to be mapped

v4: Call kref_put on closing perf fd (Chris)
v5:
- Strip access to OA buffer from unprivileged child of a privileged
  parent. Use VM_DONTCOPY
- Enforce MAP_PRIVATE by checking for VM_MAYSHARE

v6:
(Chris)
- Use len of -1 in unmap_mapping_range
- Don't use stream->oa_buffer.vma->obj in vm_fault_oa
- Use kernel block comment style
- do_mmap gets a reference to the file and puts it in do_munmap, so
  no need to maintain a reference to i915_perf_stream. Hence, remove
  vm_open/vm_close and stream->closed hooks/checks.
(Umesh)
- Do not allow mmap if SAMPLE_OA_REPORT is not set during
  i915_perf_open_ioctl.
- Drop ioctl returning head/tail since this information is already
  whitelisted. Remove hooks to read head register.

v7: (Chris)
- unmap before destroy
- change ioctl argument struct

Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +
 drivers/gpu/drm/i915/i915_perf.c | 123 ++-
 include/uapi/drm/i915_drm.h  |  18 
 4 files changed, 143 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..7c4b9b0c334b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
return view;
 }
 
-static vm_fault_t i915_error_to_vmf_fault(int err)
+vm_fault_t i915_error_to_vmf_fault(int err)
 {
switch (err) {
default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..1190a3a228ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct 
drm_i915_gem_object *obj);
 
 void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
 
+vm_fault_t i915_error_to_vmf_fault(int err);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8ff502719dfd..8ac7944c24b8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,10 +192,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
 #include "gem/i915_gem_context.h"
+#include "gem/i915_gem_mman.h"
 #include "gt/intel_engine_pm.h"
 #include "gt/intel_engine_user.h"
 #include "gt/intel_gt.h"
@@ -3269,6 +3271,42 @@ static long i915_perf_config_locked(struct 
i915_perf_stream *stream,
return ret;
 }
 
+#define I915_PERF_OA_BUFFER_MMAP_OFFSET 1
+
+/**
+ * i915_perf_oa_buffer_info_locked - size and offset of the OA buffer
+ * @stream: i915 perf stream
+ * @arg: pointer to oa buffer info filled by this function.
+ */
+static int 

[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer

2020-07-30 Thread Umesh Nerlige Ramappa
This cover letter is included to trigger "Test-with" an IGT patch.

Tests - https://patchwork.freedesktop.org/series/80113/

Signed-off-by: Umesh Nerlige Ramappa 
Test-with: 20200730230002.55737-1-umesh.nerlige.rama...@intel.com

Piotr Maciejewski (1):
  drm/i915/perf: Ensure observation logic is not clock gated

Umesh Nerlige Ramappa (3):
  drm/i915/perf: Whitelist OA report trigger registers
  drm/i915/perf: Whitelist OA counter and buffer registers
  drm/i915/perf: Map OA buffer to user space for gen12 performance query

 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 109 +++--
 drivers/gpu/drm/i915/gt/intel_workarounds.h   |   7 +
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   5 +
 drivers/gpu/drm/i915/i915_perf.c  | 226 +-
 drivers/gpu/drm/i915/i915_perf_types.h|   6 +
 drivers/gpu/drm/i915/i915_reg.h   |  10 +
 include/uapi/drm/i915_drm.h   |  18 ++
 9 files changed, 358 insertions(+), 27 deletions(-)

-- 
2.20.1

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


[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated

2020-07-30 Thread Umesh Nerlige Ramappa
From: Piotr Maciejewski 

A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.

v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)

Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_perf.c | 13 +
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c6f6370283cf..fe408c327d3c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2493,6 +2493,14 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
(period_exponent << 
GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
: 0);
 
+   /*
+* Initialize Super Queue Internal Cnt Register
+* Set PMON Enable in order to collect valid metrics.
+*/
+   intel_uncore_write(uncore, GEN12_SQCNT1,
+  intel_uncore_read(uncore, GEN12_SQCNT1) |
+  GEN12_SQCNT1_PMON_ENABLE);
+
/*
 * Update all contexts prior writing the mux configurations as we need
 * to make sure all slices/subslices are ON before writing to NOA
@@ -2552,6 +2560,11 @@ static void gen12_disable_metric_set(struct 
i915_perf_stream *stream)
 
/* Make sure we disable noa to save power. */
intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
+
+   /* Reset PMON Enable to save power. */
+   intel_uncore_write(uncore, GEN12_SQCNT1,
+  intel_uncore_read(uncore, GEN12_SQCNT1) &
+  ~GEN12_SQCNT1_PMON_ENABLE);
 }
 
 static void gen7_oa_enable(struct i915_perf_stream *stream)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5eae593ee784..377339399458 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -696,6 +696,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define OABUFFER_SIZE_16M   (7 << 3)
 
 #define GEN12_OA_TLB_INV_CR _MMIO(0xceec)
+#define GEN12_SQCNT1 _MMIO(0x8718)
+#define  GEN12_SQCNT1_PMON_ENABLE (1 << 30)
 
 /* Gen12 OAR unit */
 #define GEN12_OAR_OACONTROL _MMIO(0x2960)
-- 
2.20.1

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


[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers

2020-07-30 Thread Umesh Nerlige Ramappa
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.

Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
enabled accordingly. On closing the perf fd, the whitelist is removed.

This ensures that the access to the whitelist is gated by
perf_stream_paranoid.

v2:
- Move related change to this patch (Lionel)
- Bump up perf revision (Lionel)

v3: Pardon whitelisted registers for selftest (Umesh)
v4: Document supported gens for the feature (Lionel)
v5: Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)
v6: Move oa whitelist array to i915_perf (Chris)

Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 109 ++
 drivers/gpu/drm/i915/gt/intel_workarounds.h   |   7 ++
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   5 +
 drivers/gpu/drm/i915/i915_perf.c  |  76 +++-
 drivers/gpu/drm/i915/i915_perf_types.h|   6 +
 5 files changed, 177 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index cef1c122696f..1d337c44d1b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -81,10 +81,50 @@ static void wa_init_finish(struct i915_wa_list *wal)
 wal->wa_count, wal->name, wal->engine_name);
 }
 
+static int _wa_index(struct i915_wa_list *wal, i915_reg_t reg)
+{
+   unsigned int addr = i915_mmio_reg_offset(reg);
+   int start = 0, end = wal->count;
+
+   /* addr and wal->list[].reg, both include the R/W flags */
+   while (start < end) {
+   int mid = start + (end - start) / 2;
+
+   if (i915_mmio_reg_offset(wal->list[mid].reg) < addr)
+   start = mid + 1;
+   else if (i915_mmio_reg_offset(wal->list[mid].reg) > addr)
+   end = mid;
+   else
+   return mid;
+   }
+
+   return -1;
+}
+
+static void _wa_remove(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
+{
+   int index;
+   struct i915_wa *wa = wal->list;
+
+   reg.reg |= flags;
+
+   index = _wa_index(wal, reg);
+   if (index < 0)
+   return;
+
+   memset(wa + index, 0, sizeof(*wa));
+
+   while (index < wal->count - 1) {
+   swap(wa[index], wa[index + 1]);
+   index++;
+   }
+
+   wal->count--;
+}
+
 static void _wa_add(struct i915_wa_list *wal, const struct i915_wa *wa)
 {
-   unsigned int addr = i915_mmio_reg_offset(wa->reg);
-   unsigned int start = 0, end = wal->count;
+   int index;
const unsigned int grow = WA_LIST_CHUNK;
struct i915_wa *wa_;
 
@@ -106,30 +146,23 @@ static void _wa_add(struct i915_wa_list *wal, const 
struct i915_wa *wa)
wal->list = list;
}
 
-   while (start < end) {
-   unsigned int mid = start + (end - start) / 2;
+   index = _wa_index(wal, wa->reg);
+   if (index >= 0) {
+   wa_ = >list[index];
 
-   if (i915_mmio_reg_offset(wal->list[mid].reg) < addr) {
-   start = mid + 1;
-   } else if (i915_mmio_reg_offset(wal->list[mid].reg) > addr) {
-   end = mid;
-   } else {
-   wa_ = >list[mid];
-
-   if ((wa->clr | wa_->clr) && !(wa->clr & ~wa_->clr)) {
-   DRM_ERROR("Discarding overwritten w/a for reg 
%04x (clear: %08x, set: %08x)\n",
- i915_mmio_reg_offset(wa_->reg),
- wa_->clr, wa_->set);
+   if ((wa->clr | wa_->clr) && !(wa->clr & ~wa_->clr)) {
+   DRM_ERROR("Discarding overwritten w/a for reg %04x 
(clear: %08x, set: %08x)\n",
+ i915_mmio_reg_offset(wa_->reg),
+ wa_->clr, wa_->set);
 
-   wa_->set &= ~wa->clr;
-   }
-
-   wal->wa_count++;
-   wa_->set |= wa->set;
-   wa_->clr |= wa->clr;
-   wa_->read |= wa->read;
-   return;
+   wa_->set &= ~wa->clr;
}
+
+   wal->wa_count++;
+   wa_->set |= wa->set;
+   wa_->clr |= wa->clr;
+   wa_->read |= wa->read;
+   return;
}
 
wal->wa_count++;
@@ -1954,6 +1987,36 @@ void intel_engine_init_workarounds(struct 
intel_engine_cs *engine)
wa_init_finish(wal);
 }
 
+void intel_engine_allow_user_register_access(struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/kmb: Add support for KeemBay Display (rev2)

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

Series: drm/kmb: Add support for KeemBay Display (rev2)
URL   : https://patchwork.freedesktop.org/series/79615/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18278


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-bsw-kefka:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-bsw-kefka/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [FAIL][5] ([i915#1888]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][11] ([i915#2089]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [DMESG-WARN][17] ([i915#2203]) -> [DMESG-FAIL][18] 
([i915#2203])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][20] ([i915#62] / [i915#92])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18278/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

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

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kmb: Add support for KeemBay Display (rev2)

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

Series: drm/kmb: Add support for KeemBay Display (rev2)
URL   : https://patchwork.freedesktop.org/series/79615/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
984b2ce8e7ed drm/kmb: Add support for KeemBay Display
-:55: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#55: 
new file mode 100644

-:144: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#144: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:58:
+   kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+   LCD_INT_VERT_COMP);

-:171: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#171: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:85:
+   drm_info(dev,
+   "vfp= %d vbp= %d vsyc_len=%d hfp=%d hbp=%d hsync_len=%d\n",

-:192: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#192: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:106:
+   drm_dbg(dev, "%s : %dactive height= %d vbp=%d vfp=%d vsync-w=%d 
h-active=%d h-bp=%d h-fp=%d hysnc-l=%d",
+   __func__, __LINE__,

-:197: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#197: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:111:
+   kmb_write_lcd(kmb, LCD_V_ACTIVEHEIGHT,
+   m->crtc_vdisplay - 1);

-:202: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#202: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:116:
+   kmb_write_lcd(kmb, LCD_H_ACTIVEWIDTH,
+   m->crtc_hdisplay - 1);

-:215: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#215: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:129:
+   kmb_write_lcd(kmb,
+   LCD_V_BACKPORCH_EVEN, vm.vback_porch);

-:217: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#217: FILE: drivers/gpu/drm/kmb/kmb_crtc.c:131:
+   kmb_write_lcd(kmb,
+   LCD_V_FRONTPORCH_EVEN, vm.vfront_porch);

-:411: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#411: FILE: drivers/gpu/drm/kmb/kmb_drv.c:60:
+   drm_err(>drm,
+   "Failed to enable MIPI_ECFG clock: %d\n", ret);

-:418: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#418: FILE: drivers/gpu/drm/kmb/kmb_drv.c:67:
+   drm_err(>drm,
+   "Failed to enable MIPI_CFG clock: %d\n", ret);

-:425: CHECK:LINE_SPACING: Please don't use multiple blank lines
#425: FILE: drivers/gpu/drm/kmb/kmb_drv.c:74:
+
+

-:461: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#461: FILE: drivers/gpu/drm/kmb/kmb_drv.c:110:
+   kmb->sys_clk_mhz = clk_get_rate(kmb_clk.clk_pll0)/100;
 ^

-:468: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#468: FILE: drivers/gpu/drm/kmb/kmb_drv.c:117:
+   drm_err(>drm, "failed to set to clk_lcd to %d\n",
+ KMB_LCD_DEFAULT_CLK);

-:477: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#477: FILE: drivers/gpu/drm/kmb/kmb_drv.c:126:
+   drm_err(>drm, "failed to set to clk_mipi to %d\n",
+ KMB_MIPI_DEFAULT_CLK);

-:504: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#504: FILE: drivers/gpu/drm/kmb/kmb_drv.c:153:
+   drm_err(>drm,
+   "failed to set clk_mipi_cfg to %d\n",

-:509: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#509: FILE: drivers/gpu/drm/kmb/kmb_drv.c:158:
+   drm_info(>drm,
+   "Get clk_mipi_cfg after set = %ld\n", clk);

-:559: CHECK:LINE_SPACING: Please don't use multiple blank lines
#559: FILE: drivers/gpu/drm/kmb/kmb_drv.c:208:
+
+

-:686: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#686: FILE: drivers/gpu/drm/kmb/kmb_drv.c:335:
+   if (status & LCD_INT_EOF) {
+

-:699: CHECK:CAMELCASE: Avoid CamelCase: 
#699: FILE: drivers/gpu/drm/kmb/kmb_drv.c:348:
+   LCD_LAYERn_DMA_CFG

-:704: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#704: FILE: drivers/gpu/drm/kmb/kmb_drv.c:353:
+   kmb_clr_bitmask_lcd(kmb, LCD_CONTROL,
+   plane_status[plane_id].ctrl);

-:731: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#731: FILE: drivers/gpu/drm/kmb/kmb_drv.c:380:
+
+   }

-:772: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#772: FILE: drivers/gpu/drm/kmb/kmb_drv.c:421:
+   drm_info(>drm,
+   "!LAYER0:VL0 DMA UNDERFLOW val = 
0x%lx,under_flow=%d",

-:785: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#785: FILE: drivers/gpu/drm/kmb/kmb_drv.c:434:
+

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

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

Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma 
page-directories (rev2)
URL   : https://patchwork.freedesktop.org/series/80045/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18274_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_ringsize@active@bcs0:
- shard-skl:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl6/igt@gem_ctx_ringsize@act...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-skl1/igt@gem_ctx_ringsize@act...@bcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@parallel@vecs0:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +14 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl1/igt@gem_busy@paral...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-skl6/igt@gem_busy@paral...@vecs0.html

  * igt@gem_ctx_shared@q-smoketest-all:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#1889])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb5/igt@gem_ctx_sha...@q-smoketest-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-tglb1/igt@gem_ctx_sha...@q-smoketest-all.html

  * igt@gem_exec_reloc@basic-concurrent0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#1930])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-iclb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb1/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@gen9_exec_parse@allowed-all:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / 
[i915#1635] / [i915#716])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-apl2/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_module_load@reload-with-fault-injection:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / 
[i915#1982]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl4/igt@i915_module_l...@reload-with-fault-injection.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-apl7/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk6/igt@kms_cursor_edge_w...@pipe-b-256x256-left-edge.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-glk3/igt@kms_cursor_edge_w...@pipe-b-256x256-left-edge.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw:  [PASS][17] -> [FAIL][18] ([i915#57])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1:
- shard-hsw:  [PASS][19] -> [INCOMPLETE][20] ([i915#2055])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-hsw6/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/shard-hsw1/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html

  * igt@kms_flip@plain-flip-fb-recreate@c-edp1:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#2122])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl3/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html
   [22]: 

[Intel-gfx] [PATCH v4] Add support for KeemBay DRM driver

2020-07-30 Thread Anitha Chrisanthus
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.

This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows

+--++-++---+
|LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter |
+--++-++---+

LCD controller and Mipi DSI transmitter are part of the SOC and
mipi to HDMI converter is ADV7535 for KMB EVM board.

The DRM driver is a basic KMS atomic modesetting display driver and
has no 2D or 3D graphics.It calls into the ADV bridge driver at
the connector level.

Only 1080p resolution and single plane is supported at this time.
The usecase is for debugging video and camera outputs.

Device tree patches are under review here
https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/

Changes since v1:
- Removed redundant license text, updated license
- Rearranged include blocks
- renamed global vars and removed extern in c
- Used upclassing for dev_private
- Used drm_dev_init in drm device create
- minor cleanups

Changes since v2:
- squashed all commits to a single commit
- logging changed to drm_info, drm_dbg etc.
- used devm_drm_dev_alloc()
- removed commented out sections and general cleanup

Changes since v3:
- renamed dev_p to kmb
- moved clocks under kmb_clock, consolidated clk initializations
- use drmm functions
- use DRM_GEM_CMA_DRIVER_OPS_VMAP
- more cleanups

Anitha Chrisanthus (1):
  drm/kmb: Add support for KeemBay Display

 drivers/gpu/drm/Kconfig |2 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/kmb/Kconfig |   13 +
 drivers/gpu/drm/kmb/Makefile|2 +
 drivers/gpu/drm/kmb/kmb_crtc.c  |  217 +
 drivers/gpu/drm/kmb/kmb_crtc.h  |   36 +
 drivers/gpu/drm/kmb/kmb_drv.c   |  733 
 drivers/gpu/drm/kmb/kmb_drv.h   |  172 
 drivers/gpu/drm/kmb/kmb_dsi.c   | 1834 +++
 drivers/gpu/drm/kmb/kmb_dsi.h   |  370 
 drivers/gpu/drm/kmb/kmb_plane.c |  518 +++
 drivers/gpu/drm/kmb/kmb_plane.h |  124 +++
 drivers/gpu/drm/kmb/kmb_regs.h  |  738 
 13 files changed, 4760 insertions(+)
 create mode 100644 drivers/gpu/drm/kmb/Kconfig
 create mode 100644 drivers/gpu/drm/kmb/Makefile
 create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
 create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h
 create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
 create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
 create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
 create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h
 create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
 create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
 create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h

-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Pull release of node->age under the spinlock

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

Series: drm/i915/gt: Pull release of node->age under the spinlock
URL   : https://patchwork.freedesktop.org/series/80094/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18273_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-queues-forked:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl3/igt@gem_exec_whis...@basic-queues-forked.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-skl7/igt@gem_exec_whis...@basic-queues-forked.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-glk3/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@gen9_exec_parse@allowed-all:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / 
[i915#1635] / [i915#716])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-apl7/igt@gen9_exec_pa...@allowed-all.html

  * 
igt@kms_atomic_transition@plane-use-after-nonblocking-unbind-fencing@edp-1-pipe-a:
- shard-skl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +17 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl9/igt@kms_atomic_transition@plane-use-after-nonblocking-unbind-fenc...@edp-1-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-skl3/igt@kms_atomic_transition@plane-use-after-nonblocking-unbind-fenc...@edp-1-pipe-a.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +6 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2122])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk6/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#1188])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl7/igt@kms_...@bpc-switch.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-skl7/igt@kms_...@bpc-switch.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl:  [PASS][17] -> [INCOMPLETE][18] ([i915#155])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][21] -> 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Pull release of node->age under the spinlock

2020-07-30 Thread Matthew Auld
On Thu, 30 Jul 2020 at 14:41, Chris Wilson  wrote:
>
> We need to ensure that the list is valid prior to marking the node as
> retrievable, otherwise we may see two threads compete over the same node
> in intel_gt_get_buffer_pool(). If the first thread acquires and releases
> the node in the same jiffie, the second thread may then acquire it (as
> the jiffie now again matches the expected value) and claim the node
> before it is put back into the list.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
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: Support multiple pinned timelines (rev3)

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

Series: drm/i915/gt: Support multiple pinned timelines (rev3)
URL   : https://patchwork.freedesktop.org/series/80098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18277


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-kbl-7560u}: [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-7560u/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-kbl-7560u/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] / 
[i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][17] ([i915#2089]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18277/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

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

  * igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][24] ([i915#62] / [i915#92])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
   [24]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for Expose crtc dither state and connector max bpc via debugfs (rev4)

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

Series: Expose crtc dither state and connector max bpc via debugfs (rev4)
URL   : https://patchwork.freedesktop.org/series/79664/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18272_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_dither@fb-10bpc-vs-panel-8bpc@dp-1-pipe-a} (NEW):
- shard-kbl:  NOTRUN -> [FAIL][1] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-kbl4/igt@kms_dither@fb-10bpc-vs-panel-8...@dp-1-pipe-a.html

  * {igt@kms_dither@fb-10bpc-vs-panel-8bpc@edp-1-pipe-a} (NEW):
- shard-skl:  NOTRUN -> [FAIL][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-skl10/igt@kms_dither@fb-10bpc-vs-panel-8...@edp-1-pipe-a.html

  * {igt@kms_dither@fb-16bpc-vs-panel-10bpc@hdmi-a-2-pipe-a} (NEW):
- shard-glk:  NOTRUN -> [FAIL][3] +5 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-glk8/igt@kms_dither@fb-16bpc-vs-panel-10...@hdmi-a-2-pipe-a.html

  * {igt@kms_dither@fb-16bpc-vs-panel-8bpc-suspend@edp-1-pipe-a} (NEW):
- shard-iclb: NOTRUN -> [FAIL][4] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-iclb7/igt@kms_dither@fb-16bpc-vs-panel-8bpc-susp...@edp-1-pipe-a.html

  * {igt@kms_dither@fb-8bpc-vs-panel-10bpc-suspend} (NEW):
- shard-iclb: NOTRUN -> [SKIP][5] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-iclb4/igt@kms_dit...@fb-8bpc-vs-panel-10bpc-suspend.html

  * {igt@kms_dither@fb-8bpc-vs-panel-8bpc} (NEW):
- shard-tglb: NOTRUN -> [SKIP][6] +11 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/shard-tglb1/igt@kms_dit...@fb-8bpc-vs-panel-8bpc.html

  
New tests
-

  New tests have been introduced between CI_DRM_8817_full and 
Patchwork_18272_full:

### New IGT tests (57) ###

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc:
- Statuses : 4 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc-suspend:
- Statuses : 4 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc-suspend@dp-1-pipe-a:
- Statuses : 2 pass(s)
- Exec time: [1.03, 1.44] s

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc-suspend@hdmi-a-1-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [1.38] s

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc@dp-1-pipe-a:
- Statuses : 2 pass(s)
- Exec time: [0.17, 0.19] s

  * igt@kms_dither@fb-10bpc-vs-panel-10bpc@hdmi-a-1-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [0.45] s

  * igt@kms_dither@fb-10bpc-vs-panel-6bpc:
- Statuses :
- Exec time: [None] s

  * igt@kms_dither@fb-10bpc-vs-panel-6bpc-suspend:
- Statuses : 2 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_dither@fb-10bpc-vs-panel-6bpc-suspend@dp-1-pipe-a:
- Statuses : 2 pass(s)
- Exec time: [1.01, 1.57] s

  * igt@kms_dither@fb-10bpc-vs-panel-6bpc-suspend@edp-1-pipe-a:
- Statuses : 3 pass(s)
- Exec time: [3.07, 3.77] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc:
- Statuses : 3 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc-suspend:
- Statuses : 2 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc-suspend@dp-1-pipe-a:
- Statuses : 2 fail(s)
- Exec time: [1.07, 1.56] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc-suspend@edp-1-pipe-a:
- Statuses : 2 fail(s)
- Exec time: [3.01, 3.54] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc-suspend@hdmi-a-1-pipe-a:
- Statuses : 1 fail(s)
- Exec time: [1.45] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc@dp-1-pipe-a:
- Statuses : 2 fail(s)
- Exec time: [0.15, 0.16] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc@edp-1-pipe-a:
- Statuses : 1 fail(s)
- Exec time: [1.38] s

  * igt@kms_dither@fb-10bpc-vs-panel-8bpc@hdmi-a-1-pipe-a:
- Statuses : 1 fail(s)
- Exec time: [0.31] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc:
- Statuses : 4 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc-suspend:
- Statuses : 4 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc-suspend@dp-1-pipe-a:
- Statuses : 2 fail(s)
- Exec time: [1.02, 1.60] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc-suspend@hdmi-a-1-pipe-a:
- Statuses : 1 fail(s)
- Exec time: [1.17] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc@dp-1-pipe-a:
- Statuses : 2 fail(s)
- Exec time: [0.17, 0.26] s

  * igt@kms_dither@fb-16bpc-vs-panel-10bpc@hdmi-a-2-pipe-a:
- Statuses : 1 fail(s)
- Exec time: [0.35] s

  * 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

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

Series: series starting with [01/21] drm/i915: Add a couple of missing 
i915_active_fini()
URL   : https://patchwork.freedesktop.org/series/80083/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817_full -> Patchwork_18271_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-glk6/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][3] -> [SKIP][4] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gen9_exec_parse@allowed-all:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / 
[i915#1635] / [i915#716])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-apl2/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_selftest@mock@requests:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#198] / 
[i915#2119])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl8/igt@i915_selftest@m...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-skl7/igt@i915_selftest@m...@requests.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_color@pipe-b-ctm-negative:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +11 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-skl1/igt@kms_co...@pipe-b-ctm-negative.html

  * 
igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / 
[i915#1982]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-apl6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-apl6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html

  * igt@kms_flip@plain-flip-fb-recreate@c-edp1:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#2122])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-skl3/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-skl2/igt@kms_flip@plain-flip-fb-recre...@c-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
- shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-kbl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +3 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +2 
similar issues
   [23]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines (rev3)

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

Series: drm/i915/gt: Support multiple pinned timelines (rev3)
URL   : https://patchwork.freedesktop.org/series/80098/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] [CI] drm/i915/gt: Support multiple pinned timelines

2020-07-30 Thread Chris Wilson
We may need to allocate more than one pinned context/timeline for each
engine which can utilise the per-engine HWSP, so we need to give each
a different offset within it.

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200730165231.545-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 +---
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 20 +++---
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  3 ++-
 drivers/gpu/drm/i915/gt/intel_timeline.c  | 12 ++-
 drivers/gpu/drm/i915/gt/intel_timeline.h  | 21 +--
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +++---
 8 files changed, 61 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index efc4ba34c06e..d8cccbab7a51 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -886,7 +886,7 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
struct intel_timeline *timeline;
 
-   timeline = intel_timeline_create(>gt, NULL);
+   timeline = intel_timeline_create(>gt);
if (IS_ERR(timeline)) {
context_close(ctx);
return ERR_CAST(timeline);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index dd1a42c4d344..86651bbef3a0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -785,9 +785,11 @@ intel_engine_init_active(struct intel_engine_cs *engine, 
unsigned int subclass)
 }
 
 static struct intel_context *
-create_kernel_context(struct intel_engine_cs *engine)
+create_pinned_context(struct intel_engine_cs *engine,
+ unsigned int hwsp,
+ struct lock_class_key *key,
+ const char *name)
 {
-   static struct lock_class_key kernel;
struct intel_context *ce;
int err;
 
@@ -796,6 +798,7 @@ create_kernel_context(struct intel_engine_cs *engine)
return ce;
 
__set_bit(CONTEXT_BARRIER_BIT, >flags);
+   ce->timeline = page_pack_bits(NULL, hwsp);
 
err = intel_context_pin(ce); /* perma-pin so it is always available */
if (err) {
@@ -809,11 +812,20 @@ create_kernel_context(struct intel_engine_cs *engine)
 * should we need to inject GPU operations during their request
 * construction.
 */
-   lockdep_set_class(>timeline->mutex, );
+   lockdep_set_class_and_name(>timeline->mutex, key, name);
 
return ce;
 }
 
+static struct intel_context *
+create_kernel_context(struct intel_engine_cs *engine)
+{
+   static struct lock_class_key kernel;
+
+   return create_pinned_context(engine, I915_GEM_HWS_SEQNO_ADDR,
+, "kernel_context");
+}
+
 /**
  * intel_engines_init_common - initialize cengine state which might require hw 
access
  * @engine: Engine to initialize.
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 353b1717fe84..0508347dca49 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5313,6 +5313,14 @@ populate_lr_context(struct intel_context *ce,
return 0;
 }
 
+static struct intel_timeline *pinned_timeline(struct intel_context *ce)
+{
+   struct intel_timeline *tl = fetch_and_zero(>timeline);
+
+   return intel_timeline_create_from_engine(ce->engine,
+page_unmask_bits(tl));
+}
+
 static int __execlists_context_alloc(struct intel_context *ce,
 struct intel_engine_cs *engine)
 {
@@ -5343,19 +5351,17 @@ static int __execlists_context_alloc(struct 
intel_context *ce,
goto error_deref_obj;
}
 
-   if (!ce->timeline) {
+   if (!page_mask_bits(ce->timeline)) {
struct intel_timeline *tl;
-   struct i915_vma *hwsp;
 
/*
 * Use the static global HWSP for the kernel context, and
 * a dynamically allocated cacheline for everyone else.
 */
-   hwsp = NULL;
-   if (unlikely(intel_context_is_barrier(ce)))
-   hwsp = engine->status_page.vma;
-
-   tl = intel_timeline_create(engine->gt, hwsp);
+   if (unlikely(ce->timeline))
+   tl = pinned_timeline(ce);
+   else
+   tl = intel_timeline_create(engine->gt);
if (IS_ERR(tl)) {
ret = PTR_ERR(tl);

Re: [Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

2020-07-30 Thread Matthew Auld
On Thu, 30 Jul 2020 at 17:52, Chris Wilson  wrote:
>
> We may need to allocate more than one pinned context/timeline for each
> engine which can utilise the per-engine HWSP, so we need to give each
> a different offset within it.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
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: Support multiple pinned timelines (rev2)

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

Series: drm/i915/gt: Support multiple pinned timelines (rev2)
URL   : https://patchwork.freedesktop.org/series/80098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18276


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#2203])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [FAIL][3] ([i915#1888]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][13] ([i915#2089]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][17] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18276/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

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

  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (42 -> 36)
--

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


Build changes
-

  * Linux: CI_DRM_8817 -> Patchwork_18276

  CI-20190529: 20190529
  CI_DRM_8817: 9694a4caf26c3c4f3d50f335415218c709029450 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5752: 3ecf9d88803a686354394ea60164551646235273 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18276: 08812d1d2fe7891e8244b7d7c73b9b1ec7e0b962 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines (rev2)

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

Series: drm/i915/gt: Support multiple pinned timelines (rev2)
URL   : https://patchwork.freedesktop.org/series/80098/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


___
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: Support multiple pinned timelines

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

Series: drm/i915/gt: Support multiple pinned timelines
URL   : https://patchwork.freedesktop.org/series/80098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18275


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / 
[i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-apl-guc/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-n3050:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-bsw-n3050/igt@i915_module_l...@reload.html
- fi-bsw-kefka:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-bsw-kefka/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- fi-bsw-n3050:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][19] ([i915#2089]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2:  [DMESG-FAIL][21] ([i915#1233]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html

  
 Warnings 

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18275/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

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

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Support multiple pinned timelines

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

Series: drm/i915/gt: Support multiple pinned timelines
URL   : https://patchwork.freedesktop.org/series/80098/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

2020-07-30 Thread Chris Wilson
We may need to allocate more than one pinned context/timeline for each
engine which can utilise the per-engine HWSP, so we need to give each
a different offset within it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 21 ---
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 20 +++---
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  3 ++-
 drivers/gpu/drm/i915/gt/intel_timeline.c  | 12 ++-
 drivers/gpu/drm/i915/gt/intel_timeline.h  | 21 +--
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +++---
 8 files changed, 64 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index efc4ba34c06e..d8cccbab7a51 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -886,7 +886,7 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
struct intel_timeline *timeline;
 
-   timeline = intel_timeline_create(>gt, NULL);
+   timeline = intel_timeline_create(>gt);
if (IS_ERR(timeline)) {
context_close(ctx);
return ERR_CAST(timeline);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index dd1a42c4d344..0d46c7020c68 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -785,9 +785,10 @@ intel_engine_init_active(struct intel_engine_cs *engine, 
unsigned int subclass)
 }
 
 static struct intel_context *
-create_kernel_context(struct intel_engine_cs *engine)
+create_pinned_context(struct intel_engine_cs *engine,
+ unsigned int hwsp,
+ struct lock_class_key *key)
 {
-   static struct lock_class_key kernel;
struct intel_context *ce;
int err;
 
@@ -796,6 +797,7 @@ create_kernel_context(struct intel_engine_cs *engine)
return ce;
 
__set_bit(CONTEXT_BARRIER_BIT, >flags);
+   ce->timeline = page_pack_bits(NULL, hwsp);
 
err = intel_context_pin(ce); /* perma-pin so it is always available */
if (err) {
@@ -809,7 +811,20 @@ create_kernel_context(struct intel_engine_cs *engine)
 * should we need to inject GPU operations during their request
 * construction.
 */
-   lockdep_set_class(>timeline->mutex, );
+   lockdep_set_class(>timeline->mutex, key);
+
+   return ce;
+}
+
+static struct intel_context *
+create_kernel_context(struct intel_engine_cs *engine)
+{
+   static struct lock_class_key kernel;
+   struct intel_context *ce;
+
+   ce = create_pinned_context(engine, I915_GEM_HWS_SEQNO_ADDR, );
+   if (IS_ERR(ce))
+   return ce;
 
return ce;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 353b1717fe84..0508347dca49 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5313,6 +5313,14 @@ populate_lr_context(struct intel_context *ce,
return 0;
 }
 
+static struct intel_timeline *pinned_timeline(struct intel_context *ce)
+{
+   struct intel_timeline *tl = fetch_and_zero(>timeline);
+
+   return intel_timeline_create_from_engine(ce->engine,
+page_unmask_bits(tl));
+}
+
 static int __execlists_context_alloc(struct intel_context *ce,
 struct intel_engine_cs *engine)
 {
@@ -5343,19 +5351,17 @@ static int __execlists_context_alloc(struct 
intel_context *ce,
goto error_deref_obj;
}
 
-   if (!ce->timeline) {
+   if (!page_mask_bits(ce->timeline)) {
struct intel_timeline *tl;
-   struct i915_vma *hwsp;
 
/*
 * Use the static global HWSP for the kernel context, and
 * a dynamically allocated cacheline for everyone else.
 */
-   hwsp = NULL;
-   if (unlikely(intel_context_is_barrier(ce)))
-   hwsp = engine->status_page.vma;
-
-   tl = intel_timeline_create(engine->gt, hwsp);
+   if (unlikely(ce->timeline))
+   tl = pinned_timeline(ce);
+   else
+   tl = intel_timeline_create(engine->gt);
if (IS_ERR(tl)) {
ret = PTR_ERR(tl);
goto error_deref_obj;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 94915f668715..87cef6d01141 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

2020-07-30 Thread Chris Wilson
Quoting Chris Wilson (2020-07-30 17:47:57)
>  #include "i915_active.h"
>  #include "i915_syncmap.h"
> -#include "gt/intel_timeline_types.h"
> +#include "intel_timeline_types.h"
> +
> +#define global_hwsp(H, C) page_pack_bits(H, C)

This argument packing did not survive.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/gt: Support multiple pinned timelines

2020-07-30 Thread Chris Wilson
We may need to allocate more than one pinned context/timeline for each
engine which can utilise the per-engine HWSP, if we give each a
different offset within it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 21 ++---
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 20 ++--
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  3 ++-
 drivers/gpu/drm/i915/gt/intel_timeline.c  | 12 ++
 drivers/gpu/drm/i915/gt/intel_timeline.h  | 23 +--
 drivers/gpu/drm/i915/gt/mock_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 ++---
 8 files changed, 66 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index efc4ba34c06e..d8cccbab7a51 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -886,7 +886,7 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
struct intel_timeline *timeline;
 
-   timeline = intel_timeline_create(>gt, NULL);
+   timeline = intel_timeline_create(>gt);
if (IS_ERR(timeline)) {
context_close(ctx);
return ERR_CAST(timeline);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index dd1a42c4d344..0d46c7020c68 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -785,9 +785,10 @@ intel_engine_init_active(struct intel_engine_cs *engine, 
unsigned int subclass)
 }
 
 static struct intel_context *
-create_kernel_context(struct intel_engine_cs *engine)
+create_pinned_context(struct intel_engine_cs *engine,
+ unsigned int hwsp,
+ struct lock_class_key *key)
 {
-   static struct lock_class_key kernel;
struct intel_context *ce;
int err;
 
@@ -796,6 +797,7 @@ create_kernel_context(struct intel_engine_cs *engine)
return ce;
 
__set_bit(CONTEXT_BARRIER_BIT, >flags);
+   ce->timeline = page_pack_bits(NULL, hwsp);
 
err = intel_context_pin(ce); /* perma-pin so it is always available */
if (err) {
@@ -809,7 +811,20 @@ create_kernel_context(struct intel_engine_cs *engine)
 * should we need to inject GPU operations during their request
 * construction.
 */
-   lockdep_set_class(>timeline->mutex, );
+   lockdep_set_class(>timeline->mutex, key);
+
+   return ce;
+}
+
+static struct intel_context *
+create_kernel_context(struct intel_engine_cs *engine)
+{
+   static struct lock_class_key kernel;
+   struct intel_context *ce;
+
+   ce = create_pinned_context(engine, I915_GEM_HWS_SEQNO_ADDR, );
+   if (IS_ERR(ce))
+   return ce;
 
return ce;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 353b1717fe84..0508347dca49 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5313,6 +5313,14 @@ populate_lr_context(struct intel_context *ce,
return 0;
 }
 
+static struct intel_timeline *pinned_timeline(struct intel_context *ce)
+{
+   struct intel_timeline *tl = fetch_and_zero(>timeline);
+
+   return intel_timeline_create_from_engine(ce->engine,
+page_unmask_bits(tl));
+}
+
 static int __execlists_context_alloc(struct intel_context *ce,
 struct intel_engine_cs *engine)
 {
@@ -5343,19 +5351,17 @@ static int __execlists_context_alloc(struct 
intel_context *ce,
goto error_deref_obj;
}
 
-   if (!ce->timeline) {
+   if (!page_mask_bits(ce->timeline)) {
struct intel_timeline *tl;
-   struct i915_vma *hwsp;
 
/*
 * Use the static global HWSP for the kernel context, and
 * a dynamically allocated cacheline for everyone else.
 */
-   hwsp = NULL;
-   if (unlikely(intel_context_is_barrier(ce)))
-   hwsp = engine->status_page.vma;
-
-   tl = intel_timeline_create(engine->gt, hwsp);
+   if (unlikely(ce->timeline))
+   tl = pinned_timeline(ce);
+   else
+   tl = intel_timeline_create(engine->gt);
if (IS_ERR(tl)) {
ret = PTR_ERR(tl);
goto error_deref_obj;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 94915f668715..87cef6d01141 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ 

Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

2020-07-30 Thread Intel


On 7/30/20 3:17 PM, Daniel Vetter wrote:

On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
 wrote:


On 7/28/20 3:58 PM, Daniel Vetter wrote:

GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.

So full hierarchy is now (ignore some of the other branches we already
have primed):

mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write

I hope that's not inconsistent with anything mm or fs does, adding
relevant people.


Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
don't allocate any memory AFAICT.

Since huge page-table-entry splitting may happen under the i_mmap_lock
from unmap_mapping_range() it might be worth figuring out how new page
directory pages are allocated, though.

ofc I'm not an mm expert at all, but I did try to scroll through all
i_mmap_lock_write/read callers. Found the following:

- kernel/events/uprobes.c in build_map_info:

 /*
  * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
  * reclaim. This is optimistic, no harm done if it fails.
  */

- I got lost in the hugetlb.c code and couldn't convince myself it's
not allocating page directories at various levels with something else
than GFP_KERNEL.

So looks like the recursion is clearly there and known, but the
hugepage code is too complex and flying over my head.
-Daniel


OK, so I inverted your annotation and ran a memory hog, and got the 
below splat. So clearly your proposed reclaim->i_mmap_lock locking order 
is an already established one.


So

Reviewed-by: Thomas Hellström 

8<-

[  308.324654] WARNING: possible circular locking dependency detected
[  308.324655] 5.8.0-rc2+ #16 Not tainted
[  308.324656] --
[  308.324657] kswapd0/98 is trying to acquire lock:
[  308.324658] 92a16f758428 (>i_mmap_rwsem){}-{3:3}, 
at: rmap_walk_file+0x1c0/0x2f0

[  308.324663]
   but task is already holding lock:
[  308.324664] b0960240 (fs_reclaim){+.+.}-{0:0}, at: 
__fs_reclaim_acquire+0x5/0x30

[  308.324666]
   which lock already depends on the new lock.

[  308.324667]
   the existing dependency chain (in reverse order) is:
[  308.324667]
   -> #1 (fs_reclaim){+.+.}-{0:0}:
[  308.324670]    fs_reclaim_acquire+0x34/0x40
[  308.324672]    dma_resv_lockdep+0x186/0x224
[  308.324675]    do_one_initcall+0x5d/0x2c0
[  308.324676]    kernel_init_freeable+0x222/0x288
[  308.324678]    kernel_init+0xa/0x107
[  308.324679]    ret_from_fork+0x1f/0x30
[  308.324680]
   -> #0 (>i_mmap_rwsem){}-{3:3}:
[  308.324682]    __lock_acquire+0x119f/0x1fc0
[  308.324683]    lock_acquire+0xa4/0x3b0
[  308.324685]    down_read+0x2d/0x110
[  308.324686]    rmap_walk_file+0x1c0/0x2f0
[  308.324687]    page_referenced+0x133/0x150
[  308.324689]    shrink_active_list+0x142/0x610
[  308.324690]    balance_pgdat+0x229/0x620
[  308.324691]    kswapd+0x200/0x470
[  308.324693]    kthread+0x11f/0x140
[  308.324694]    ret_from_fork+0x1f/0x30
[  308.324694]
   other info that might help us debug this:

[  308.324695]  Possible unsafe locking scenario:

[  308.324695]    CPU0    CPU1
[  308.324696]        
[  308.324696]   lock(fs_reclaim);
[  308.324697] lock(>i_mmap_rwsem);
[  308.324698]    lock(fs_reclaim);
[  308.324699]   lock(>i_mmap_rwsem);
[  308.324699]
    *** DEADLOCK ***

[  308.324700] 1 lock held by kswapd0/98:
[  308.324701]  #0: b0960240 (fs_reclaim){+.+.}-{0:0}, at: 
__fs_reclaim_acquire+0x5/0x30

[  308.324702]
   stack backtrace:
[  308.324704] CPU: 1 PID: 98 Comm: kswapd0 Not tainted 5.8.0-rc2+ #16
[  308.324705] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/29/2019

[  308.324706] Call Trace:
[  308.324710]  dump_stack+0x92/0xc8
[  308.324711]  check_noncircular+0x12d/0x150
[  308.324713]  __lock_acquire+0x119f/0x1fc0
[  308.324715]  lock_acquire+0xa4/0x3b0
[  308.324716]  ? rmap_walk_file+0x1c0/0x2f0
[  308.324717]  ? __lock_acquire+0x394/0x1fc0
[  308.324719]  down_read+0x2d/0x110
[  308.324720]  ? rmap_walk_file+0x1c0/0x2f0
[  308.324721]  rmap_walk_file+0x1c0/0x2f0
[  308.324722]  page_referenced+0x133/0x150
[  308.324724]  ? __page_set_anon_rmap+0x70/0x70
[  308.324725]  ? page_get_anon_vma+0x190/0x190
[  308.324726]  shrink_active_list+0x142/0x610
[  308.324728]  balance_pgdat+0x229/0x620
[  308.324730]  kswapd+0x200/0x470
[  308.324731]  ? lockdep_hardirqs_on_prepare+0xf5/0x170
[  308.324733]  ? finish_wait+0x80/0x80
[  308.324734]  ? balance_pgdat+0x620/0x620
[  

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev5)

2020-07-30 Thread Siddiqui, Ayaz A

I verified igt@kms_frontbuffer_tracking@basic with and without this patch on my 
local build
and observed that test is passing in both cases.

Test result with 9694a4caf26c drm-tip: 2020y-07m-30d-12h-33m-57s
UTC integration manifest

$ sudo ./build/tests/kms_frontbuffer_tracking --r basic
IGT-Version: 1.25-g3ecf9d888 (x86_64) (Linux: 5.8.0-rc7+ x86_64)
FBC last action not supported
Can't test PSR: not supported by sink.
Can't test DRRS: Not supported.
Starting subtest: basic
Subtest basic: SUCCESS (2.572s)

With “drm/i915/gt: Initialize reserved and unspecified MOCS indices”  on top of 
9694a4caf26c

$ sudo ./build/tests/kms_frontbuffer_tracking --r basic
IGT-Version: 1.25-g3ecf9d888 (x86_64) (Linux: 5.8.0-rc7+ x86_64)
FBC last action not supported
Can't test PSR: not supported by sink.
Can't test DRRS: Not supported.
Starting subtest: basic
Subtest basic: SUCCESS (2.585s)

Regards
-Ayaz

From: Patchwork 
Sent: Wednesday, July 29, 2020 6:59 PM
To: Siddiqui, Ayaz A 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/gt: Initialize reserved and 
unspecified MOCS indices (rev5)

Patch Details
Series:

drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev5)

URL:

https://patchwork.freedesktop.org/series/78012/

State:

Failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18266/index.html

CI Bug Log - changes from CI_DRM_8814 -> Patchwork_18266
Summary

FAILURE

Serious unknown changes coming with Patchwork_18266 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18266, 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_18266/index.html

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_frontbuffer_tracking@basic:

 *   fi-tgl-u2: NOTRUN -> 
FAIL

Suppressed

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

  *   igt@kms_frontbuffer_tracking@basic:

 *   {fi-tgl-dsi}: 
PASS
 -> 
FAIL

Known issues

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

IGT changes
Issues hit

  *   igt@i915_module_load@reload:

 *   fi-byt-j1900: 
PASS
 -> 
DMESG-WARN
 (i915#1982)

  *   igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:

 *   fi-icl-u2: 
PASS
 -> 
DMESG-WARN
 (i915#1982)

Possible fixes

  *   igt@debugfs_test@read_all_entries:

 *   {fi-kbl-7560u}: 
INCOMPLETE
 (i915#2175) -> 
PASS

  *   igt@i915_pm_rpm@basic-pci-d3-state:

 *   fi-bsw-kefka: 
DMESG-WARN
 (i915#1982) -> 
PASS

  *   igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:

 *   fi-byt-j1900: 
DMESG-WARN
 (i915#1982) -> 
PASS

  *   igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:

 *   fi-icl-u2: 
DMESG-WARN
 (i915#1982) -> 

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

2020-07-30 Thread Joonas Lahtinen
Hi Dave & Daniel,

(Covering for Jani here for drm-intel-next-fixes)

5 new commits over drm-intel-next here.

Fix for KASAN detected race condition and linux-next scheduler
WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU refcount
update.

CI machinery needed some kicking, so results didn't appear
at first. BAT now passed, shards should shortly be availabl

CI_DINF_202 at 
https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html?

Regards, Joonas

***

drm-intel-next-fixes-2020-07-30-1:

- Fixes for linux-next introduced scheduler races
- Fix for KASAN race in active execlists
- Fix for previous breadcrumb breadcrumb code to avoid IRQ spinlock
- Cc: stable patch for PMU refcount

The following changes since commit d524b87f77364db096855d7eb714ffacec974ddf:

  drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2020-07-30-1

for you to fetch changes up to 6bd0b413618ffb50f900ec770283d8c2217d069f:

  drm/i915: Filter wake_flags passed to default_wake_function (2020-07-30 
15:33:37 +0300)


- Fixes for linux-next introduced scheduler races
- Fix for KASAN race in active execlists
- Fix for previous breadcrumb breadcrumb code to avoid IRQ spinlock
- Cc: stable patch for PMU refcount


Abdiel Janulgue (2):
  drm/i915/dg1: add initial DG-1 definitions
  drm/i915/dg1: Add DG1 PCI IDs

Anshuman Gupta (1):
  drm/i915/hdcp: Update CP as per the kernel internal state

Anusha Srivatsa (1):
  drm/i915/dg1: Remove SHPD_FILTER_CNT register programming

Chris Wilson (27):
  drm/i915/gem: Only revoke the GGTT mmappings on aperture detiling changes
  drm/i915/gem: Only revoke mmap handlers if active
  drm/i915/gem: Drop forced struct_mutex from shrinker_taints_mutex
  drm/i915: Also drop vm.ref along error paths for vma construction
  drm/i915/gem: Split the context's obj:vma lut into its own mutex
  drm/i915: Export ppgtt_bind_vma
  drm/i915/gt: Pin the rings before marking active
  drm/i915: Update dma-attributes for our sg DMA
  drm/i915/gem: Unpin idle contexts from kswapd reclaim
  drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
  drm/i915: Release shortlived maps of longlived objects
  drm/i915: Remove i915_gem_object_get_dirty_page()
  drm/i915/gt: Optimise aliasing-ppgtt allocations
  drm/i915/selftest: Check that GPR are restored across noa_wait
  drm/i915/gt: Be defensive in the face of false CS events
  drm/i915: Pull printing GT capabilities on error to err_print_gt
  drm/i915/gt: Always reset the engine, even if inactive, on execlists 
failure
  drm/i915/gt: Ignore irq enabling on the virtual engines
  drm/i915/gt: Only swap to a random sibling once upon creation
  drm/i915: Skip signaling a signaled request
  drm/i915/gt: Trace placement of timeline HWSP
  drm/i915/gt: Assert the kernel context is using the HWSP
  drm/i915: Provide the perf pmu.module
  drm/i915: Be wary of data races when reading the active execlists
  drm/i915: Remove i915_request.lock requirement for execution callbacks
  drm/i915: Copy default modparams to mock i915_device
  drm/i915: Filter wake_flags passed to default_wake_function

Colin Ian King (1):
  drm/i915/selftest: fix an error return path where err is not being set

Dan Carpenter (1):
  drm/i915/selftest: Fix an error code in live_noa_gpr()

Daniele Ceraolo Spurio (8):
  drm/i915: Convert device_info to uncore/de_read
  drm/i915: Use the gt in HAS_ENGINE
  drm/i915: Move engine-related mmio init to engines_init_mmio
  drm/i915: Move the engine mask to intel_gt_info
  drm/i915: Introduce gt_init_mmio
  drm/i915/sseu: Move sseu detection and dump to intel_sseu
  drm/i915: gt-fy sseu debugfs
  drm/i915: Move sseu debugfs under gt/

Flavio Suligoi (1):
  drm/i915: Fix spelling mistake in i915_reg.h

Jani Nikula (1):
  drm/i915: Update DRIVER_DATE to 20200715

José Roberto de Souza (6):
  drm/i915/display: Implement new combo phy initialization step
  drm/i915/ehl: Add new PCI ids
  drm/i915/tgl: Implement WAs 18011464164 and 22010931296
  drm/i915/display: Replace drm_i915_private in voltage swing functions by 
intel_encoder
  drm/i915/display: Remove port and phy from voltage swing functions
  drm/i915/bios: Parse HOBL parameter

Lee Shawn C (1):
  drm/i915/mst: filter out the display mode exceed sink's capability

Lucas De Marchi (4):
  drm/i915/display: prefer dig_port to reference intel_digital_port
  drm/i915: do not read swizzle info if unavailable
  drm/i915/dg1: add support for the master unit interrupt
  drm/i915/dg1: Add fake PCH

Lyude Paul (1):
  drm/probe_helper: Add 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

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

Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma 
page-directories (rev2)
URL   : https://patchwork.freedesktop.org/series/80045/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18274


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1635] / 
[i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-apl-guc/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-n3050:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-bsw-n3050/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2:  [PASS][5] -> [INCOMPLETE][6] ([i915#2045])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] / 
[i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#2203])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [FAIL][13] ([i915#1888]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- fi-bsw-n3050:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][21] ([i915#2089]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18274/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][25] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [25]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev2)

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

Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma 
page-directories (rev2)
URL   : https://patchwork.freedesktop.org/series/80045/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


___
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: Pull release of node->age under the spinlock

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

Series: drm/i915/gt: Pull release of node->age under the spinlock
URL   : https://patchwork.freedesktop.org/series/80094/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18273


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bsw-kefka:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-bsw-kefka/igt@i915_module_l...@reload.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [FAIL][5] ([i915#1888]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-bsw-kefka/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][11] ([i915#2089]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [DMESG-WARN][13] ([i915#2203]) -> [DMESG-FAIL][14] 
([i915#2203])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][17] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18273/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (42 -> 36)
--

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


Build changes
-

  * Linux: CI_DRM_8817 -> Patchwork_18273

  CI-20190529: 20190529
  CI_DRM_8817: 9694a4caf26c3c4f3d50f335415218c709029450 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5752: 3ecf9d88803a686354394ea60164551646235273 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18273: 0436e90ae0de276341d271cc846804bbe6fb3393 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0436e90ae0de drm/i915/gt: Pull release of node->age under the spinlock

== Logs ==

For more details see: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Pull release of node->age under the spinlock

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

Series: drm/i915/gt: Pull release of node->age under the spinlock
URL   : https://patchwork.freedesktop.org/series/80094/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] ✓ Fi.CI.BAT: success for Expose crtc dither state and connector max bpc via debugfs (rev4)

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

Series: Expose crtc dither state and connector max bpc via debugfs (rev4)
URL   : https://patchwork.freedesktop.org/series/79664/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18272


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload:
- fi-bsw-kefka:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-bsw-kefka/igt@i915_module_l...@reload.html
- fi-icl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-y/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-icl-y/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1635] / 
[i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-apl-guc/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-apl-guc/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2:  [PASS][9] -> [INCOMPLETE][10] ([i915#2045])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][13] -> [DMESG-WARN][14] ([i915#2203])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][23] ([i915#2089]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18272/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][25] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [26]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose crtc dither state and connector max bpc via debugfs (rev4)

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

Series: Expose crtc dither state and connector max bpc via debugfs (rev4)
URL   : https://patchwork.freedesktop.org/series/79664/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f05f2b52683b i915/debug: Expose crtc dither state via debugfs
-:47: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not preferred. 
Consider using octal permissions '0444'.
#47: FILE: drivers/gpu/drm/i915/i915_debugfs.c:1674:
+   debugfs_create_file("dither", S_IRUGO, crtc->debugfs_entry, 
crtc,

-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/i915_debugfs.c:1675:
+   debugfs_create_file("dither", S_IRUGO, crtc->debugfs_entry, 
crtc,
+   _state_fops);

total: 0 errors, 1 warnings, 1 checks, 30 lines checked
0711a10a5a33 i915/debug: Expose Max BPC info via debugfs
-:48: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not preferred. 
Consider using octal permissions '0444'.
#48: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2255:
+   debugfs_create_file("output_bpc", S_IRUGO, root,

-:49: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#49: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2256:
+   debugfs_create_file("output_bpc", S_IRUGO, root,
+   connector, _bpc_fops);

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


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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Expose crtc dither state and connector max bpc via debugfs (rev4)

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

Series: Expose crtc dither state and connector max bpc via debugfs (rev4)
URL   : https://patchwork.freedesktop.org/series/79664/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

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

Series: series starting with [01/21] drm/i915: Add a couple of missing 
i915_active_fini()
URL   : https://patchwork.freedesktop.org/series/80083/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8817 -> Patchwork_18271


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [FAIL][3] ([i915#1888]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-tgl-dsi}:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-bsw-kefka/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][11] ([i915#2089]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [DMESG-WARN][15] ([i915#2203]) -> [DMESG-FAIL][16] 
([i915#2203])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275:   [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8817/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18271/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

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

  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95



[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

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

Series: series starting with [01/21] drm/i915: Add a couple of missing 
i915_active_fini()
URL   : https://patchwork.freedesktop.org/series/80083/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/21] drm/i915: Add a couple of missing i915_active_fini()

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

Series: series starting with [01/21] drm/i915: Add a couple of missing 
i915_active_fini()
URL   : https://patchwork.freedesktop.org/series/80083/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a0fa9abdd53b drm/i915: Add a couple of missing i915_active_fini()
67cc7c03075d drm/i915: Skip taking acquire mutex for no ref->active callback
a0e8fa99a854 drm/i915: Export a preallocate variant of i915_active_acquire()
262dde54a973 drm/i915: Keep the most recently used active-fence upon discard
924da40b21b0 drm/i915: Make the stale cached active node available for any 
timeline
84873e9f3274 drm/i915: Reduce locking around 
i915_active_acquire_preallocate_barrier()
bc7bca4d9864 drm/i915: Provide a fastpath for waiting on vma bindings
8a3376d81ddb drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source
e5dd3b861541 drm/i915/gem: Reduce ctx->engines_mutex for get_engines()
0fcbf16a7b94 drm/i915: Remove requirement for holding i915_request.lock for 
breadcrumbs
0620516e4506 drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs
cb5ecba76529 drm/i915/gt: Only transfer the virtual context to the new engine 
if active
-:28: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#28: 
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"

-:28: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 6d06779e8672 ("drm/i915: Load 
balancing across a virtual engine")'
#28: 
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"

total: 1 errors, 1 warnings, 0 checks, 81 lines checked
be5a292c6ab9 drm/i915/gt: Distinguish the virtual breadcrumbs from the irq 
breadcrumbs
-:212: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#212: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 513 lines checked
28e0222e4292 drm/i915/gt: Move intel_breadcrumbs_arm_irq earlier
10e0ecedd3dc drm/i915/gt: Hold context/request reference while breadcrumbs are 
active
ec7fa5b7b139 drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb 
spinlock
77ca5e185eed drm/i915/gt: Protect context lifetime with RCU
e7cea35077a1 drm/i915/gt: Split the breadcrumb spinlock between global and 
contexts
-:287: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#287: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:54:
+   spinlock_t signal_lock;

total: 0 errors, 0 warnings, 1 checks, 248 lines checked
9497a93cc244 drm/i915: Drop i915_request.lock serialisation around await_start
73380f416eca drm/i915: Drop i915_request.lock requirement for intel_rps_boost()


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


[Intel-gfx] [PATCH] drm/i915/gt: Pull release of node->age under the spinlock

2020-07-30 Thread Chris Wilson
We need to ensure that the list is valid prior to marking the node as
retrievable, otherwise we may see two threads compete over the same node
in intel_gt_get_buffer_pool(). If the first thread acquires and releases
the node in the same jiffie, the second thread may then acquire it (as
the jiffie now again matches the expected value) and claim the node
before it is put back into the list.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c 
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 9e938d4f6bfe..4b7671ac5dca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -134,9 +134,9 @@ static void pool_retire(struct i915_active *ref)
/* Return this object to the shrinker pool */
i915_gem_object_make_purgeable(node->obj);
 
-   WRITE_ONCE(node->age, jiffies ?: 1); /* 0 reserved for active nodes */
spin_lock_irqsave(>lock, flags);
list_add_rcu(>link, list);
+   WRITE_ONCE(node->age, jiffies ?: 1); /* 0 reserved for active nodes */
spin_unlock_irqrestore(>lock, flags);
 
schedule_delayed_work(>work,
-- 
2.20.1

___
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/gem: Delay tracking the GEM context until it is registered (rev3)

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

Series: drm/i915/gem: Delay tracking the GEM context until it is registered 
(rev3)
URL   : https://patchwork.freedesktop.org/series/79822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8815_full -> Patchwork_18270_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-glk7/igt@gem_exec_whis...@basic-fds-forked-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-glk9/igt@gem_exec_whis...@basic-fds-forked-all.html

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

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-c-128x128-left-edge:
- shard-skl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +14 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-skl7/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-skl3/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-glk7/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-glk3/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html

  * igt@kms_flip_tiling@flip-yf-tiled:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-kbl3/igt@kms_flip_til...@flip-yf-tiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-kbl4/igt@kms_flip_til...@flip-yf-tiled.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([i915#123])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-skl9/igt@kms_frontbuffer_track...@psr-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-skl6/igt@kms_frontbuffer_track...@psr-suspend.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html

  * igt@perf@blocking-parameterized:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#1542])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-iclb5/igt@p...@blocking-parameterized.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-iclb4/igt@p...@blocking-parameterized.html

  * igt@syncobj_basic@bad-handle-to-fd:
- shard-iclb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +1 
similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/shard-iclb4/igt@syncobj_ba...@bad-handle-to-fd.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/shard-iclb8/igt@syncobj_ba...@bad-handle-to-fd.html

  
 Possible fixes 


Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

2020-07-30 Thread Daniel Vetter
On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
 wrote:
>
>
> On 7/28/20 3:58 PM, Daniel Vetter wrote:
> > GPU drivers need this in their shrinkers, to be able to throw out
> > mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
> > but that loop is resolved by trylocking in shrinkers.
> >
> > So full hierarchy is now (ignore some of the other branches we already
> > have primed):
> >
> > mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
> >
> > I hope that's not inconsistent with anything mm or fs does, adding
> > relevant people.
> >
> Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but
> don't allocate any memory AFAICT.
>
> Since huge page-table-entry splitting may happen under the i_mmap_lock
> from unmap_mapping_range() it might be worth figuring out how new page
> directory pages are allocated, though.

ofc I'm not an mm expert at all, but I did try to scroll through all
i_mmap_lock_write/read callers. Found the following:

- kernel/events/uprobes.c in build_map_info:

/*
 * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion through
 * reclaim. This is optimistic, no harm done if it fails.
 */

- I got lost in the hugetlb.c code and couldn't convince myself it's
not allocating page directories at various levels with something else
than GFP_KERNEL.

So looks like the recursion is clearly there and known, but the
hugepage code is too complex and flying over my head.
-Daniel

>
> /Thomas
>
>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 27/66] drm/i915/gem: Pull execbuf dma resv under a single critical section

2020-07-30 Thread Intel


On 7/28/20 5:16 PM, Chris Wilson wrote:

Quoting Thomas Hellström (Intel) (2020-07-27 19:08:39)

On 7/15/20 1:51 PM, Chris Wilson wrote:

Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_(from|to)_user and mmap_sem).

Signed-off-by: Chris Wilson 
---
   .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 168 +-
   .../i915/gem/selftests/i915_gem_execbuffer.c  |   8 +-
   2 files changed, 87 insertions(+), 89 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ebabc0746d50..db433f3f18ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -20,6 +20,7 @@
   #include "gt/intel_gt_pm.h"
   #include "gt/intel_gt_requests.h"
   #include "gt/intel_ring.h"
+#include "mm/i915_acquire_ctx.h"
   
   #include "i915_drv.h"

   #include "i915_gem_clflush.h"
@@ -244,6 +245,8 @@ struct i915_execbuffer {
   struct intel_context *context; /* logical state for the request */
   struct i915_gem_context *gem_context; /** caller's context */
   
+ struct i915_acquire_ctx acquire; /** lock for _all_ DMA reservations */

+
   struct i915_request *request; /** our request to build */
   struct eb_vma *batch; /** identity of the batch obj/vma */
   
@@ -389,42 +392,6 @@ static void eb_vma_array_put(struct eb_vma_array *arr)

   kref_put(>kref, eb_vma_array_destroy);
   }
   
-static int

-eb_lock_vma(struct i915_execbuffer *eb, struct ww_acquire_ctx *acquire)
-{
- struct eb_vma *ev;
- int err = 0;
-
- list_for_each_entry(ev, >submit_list, submit_link) {
- struct i915_vma *vma = ev->vma;
-
- err = ww_mutex_lock_interruptible(>resv->lock, acquire);
- if (err == -EDEADLK) {
- struct eb_vma *unlock = ev, *en;
-
- list_for_each_entry_safe_continue_reverse(unlock, en,
-   
>submit_list,
-   submit_link) {
- ww_mutex_unlock(>vma->resv->lock);
- list_move_tail(>submit_link, 
>submit_list);
- }
-
- GEM_BUG_ON(!list_is_first(>submit_link, 
>submit_list));
- err = ww_mutex_lock_slow_interruptible(>resv->lock,
-acquire);
- }
- if (err) {
- list_for_each_entry_continue_reverse(ev,
-  >submit_list,
-  submit_link)
- ww_mutex_unlock(>vma->resv->lock);
- break;
- }
- }
-
- return err;
-}
-
   static int eb_create(struct i915_execbuffer *eb)
   {
   /* Allocate an extra slot for use by the sentinel */
@@ -668,6 +635,25 @@ eb_add_vma(struct i915_execbuffer *eb,
   }
   }
   
+static int eb_lock_mm(struct i915_execbuffer *eb)

+{
+ struct eb_vma *ev;
+ int err;
+
+ list_for_each_entry(ev, >bind_list, bind_link) {
+ err = i915_acquire_ctx_lock(>acquire, ev->vma->obj);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static int eb_acquire_mm(struct i915_execbuffer *eb)
+{
+ return i915_acquire_mm(>acquire);
+}
+
   struct eb_vm_work {
   struct dma_fence_work base;
   struct eb_vma_array *array;
@@ -1390,7 +1376,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
   unsigned long count;
   struct eb_vma *ev;
   unsigned int pass;
- int err = 0;
+ int err;
+
+ err = eb_lock_mm(eb);
+ if (err)
+ return err;
+
+ err = eb_acquire_mm(eb);
+ if (err)
+ return err;
   
   count = 0;

   INIT_LIST_HEAD();
@@ -1416,10 +1410,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
   if (count == 0)
   return 0;
   
+ /* We need to reserve page directories, release all, start over */

+ i915_acquire_ctx_fini(>acquire);
+
   pass = 0;
   do {
   struct eb_vm_work *work;
   
+ i915_acquire_ctx_init(>acquire);

Couldn't we do a i915_acquire_ctx_rollback() here to avoid losing our
ticket? That would mean deferring i915_acquire_ctx_done() until all
potential rollbacks have been performed.

We need to completely drop the acquire-class for catching up with userptr
(and anything else deferred that doesn't meet the current fence semantics).
Hmm, what other deferrered stuff are we doing that doesn't meet the 
current fence semantics? (Which I interpret as "everything deferred that 
we spawn 

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

2020-07-30 Thread Christian König

Am 28.07.20 um 15:58 schrieb Daniel Vetter:

GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.

So full hierarchy is now (ignore some of the other branches we already
have primed):

mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write

I hope that's not inconsistent with anything mm or fs does, adding
relevant people.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Dave Chinner 
Cc: Qian Cai 
Cc: linux-...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Thomas Hellström (Intel) 
Cc: Andrew Morton 
Cc: Jason Gunthorpe 
Cc: linux...@kvack.org
Cc: linux-r...@vger.kernel.org
Cc: Maarten Lankhorst 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-resv.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 0e6675ec1d11..9678162a4ac5 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void)
struct mm_struct *mm = mm_alloc();
struct ww_acquire_ctx ctx;
struct dma_resv obj;
+   struct address_space mapping;
int ret;
  
  	if (!mm)

return -ENOMEM;
  
  	dma_resv_init();

+   address_space_init_once();
  
  	mmap_read_lock(mm);

ww_acquire_init(, _ww_class);
@@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void)
if (ret == -EDEADLK)
dma_resv_lock_slow(, );
fs_reclaim_acquire(GFP_KERNEL);
+   /* for unmap_mapping_range on trylocked buffer objects in shrinkers */
+   i_mmap_lock_write();
+   i_mmap_unlock_write();
  #ifdef CONFIG_MMU_NOTIFIER
lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
__dma_fence_might_wait();


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


Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

2020-07-30 Thread Intel



On 7/28/20 4:50 PM, Chris Wilson wrote:


It's in the user critical path (the shortest path to perform their
sequence of operations), but it's before the dma-fence itself. I say
that's a particularly nasty false claim that it is not on the critical
path, but being where it is circumvents the whole argument.
  


Couldn't the following situation happen?

1. CS spawns userptr pinning work.
2. CS creates and publishes a DMA-fence that depends on that pinning work.
3. Another driver CS creates and publishes a second DMA-fence that 
depends on that first DMA-fence.
4. userptr pinning starts pinning pages, triggers a shrinker on the 
other driver

5. Other driver shrinker blocks on the second DMA-fence,
6. Deadlock.

Or do I misread the i915 userptr code?

/Thomas


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


Re: [Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

2020-07-30 Thread Intel



On 7/28/20 3:58 PM, Daniel Vetter wrote:

GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.

So full hierarchy is now (ignore some of the other branches we already
have primed):

mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write

I hope that's not inconsistent with anything mm or fs does, adding
relevant people.

Looks OK to me. The mapping_dirty_helpers run under the i_mmap_lock, but 
don't allocate any memory AFAICT.


Since huge page-table-entry splitting may happen under the i_mmap_lock 
from unmap_mapping_range() it might be worth figuring out how new page 
directory pages are allocated, though.


/Thomas



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


Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

2020-07-30 Thread Intel



On 7/28/20 4:50 PM, Chris Wilson wrote:

Quoting Thomas Hellström (Intel) (2020-07-27 10:24:24)

Hi, Chris,

It appears to me like this series is doing a lot of different things:

- Various optimizations
- Locking rework
- Adding schedulers
- Other misc fixes

Could you please separate out as much as possible the locking rework
prerequisites in one series with cover letter, and most importantly the
major part of the locking rework (only) with a more elaborate cover
letter discussing, if not trivial, how each patch fits in and on design
and future directions, Questions that I have stumbled on so far (being a
new-to-the-driver reviewer):

The locking depend on the former work to reduce the impact. It's still a
major issue that we introduce a broad lock that is held for several
hundred milliseconds across many objects that stalls game
  

- When are memory allocations disallowed? If we need to pre-allocate in
execbuf, when? why?

That should be mentioned in the code.


- When is the request dma-fence published?

There a big comment to that effect.


- Do we need to keep cpu asynchronous execbuf tasks after this? why?

Keep? Oh, you mean not immediately discard after publishing them, but
why we need them. Same reason as we need them before.


- What about userptr pinning ending up in the dma_fence critical path?

It's in the user critical path (the shortest path to perform their
sequence of operations), but it's before the dma-fence itself. I say
that's a particularly nasty false claim that it is not on the critical
path, but being where it is circumvents the whole argument.
  

And then move anything non-related to separate series?

Not related to what? Development of i915?
-Chris


So while it's true that a good prior understaning of the driver together 
with a detailed analysis of the code would provide answers to most of 
these questions, they were actually primarilly intended to serve as 
inspiration for an elaborate cover letter.


I believe a discussion touching these items would be a good aid to 
people embarking on reviewing the series.


/Thomas




___
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/gem: Delay tracking the GEM context until it is registered (rev3)

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

Series: drm/i915/gem: Delay tracking the GEM context until it is registered 
(rev3)
URL   : https://patchwork.freedesktop.org/series/79822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8815 -> Patchwork_18270


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-bsw-kefka:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-bsw-kefka/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-bsw-kefka/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-byt-j1900/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [DMESG-WARN][7] ([i915#1635] / [i915#1982]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-bxt-dsi/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-bxt-dsi/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  * igt@kms_setmode@basic-clone-single-crtc:
- {fi-kbl-7560u}: [WARN][13] ([i915#2100]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-kbl-7560u/igt@kms_setm...@basic-clone-single-crtc.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275:   [DMESG-FAIL][17] ([i915#62] / [i915#95]) -> 
[SKIP][18] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [SKIP][19] ([fdo#109271]) -> [DMESG-WARN][20] 
([i915#2203])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +6 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18270/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8815/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
   [24]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Delay tracking the GEM context until it is registered (rev3)

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

Series: drm/i915/gem: Delay tracking the GEM context until it is registered 
(rev3)
URL   : https://patchwork.freedesktop.org/series/79822/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.


___
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/gem: Delay tracking the GEM context until it is registered (rev3)

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

Series: drm/i915/gem: Delay tracking the GEM context until it is registered 
(rev3)
URL   : https://patchwork.freedesktop.org/series/79822/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9e47bf80906a drm/i915/gem: Delay tracking the GEM context until it is registered
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by 
each context in debugfs")

-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit f6e8aa387171 ("drm/i915: Report 
the number of closed vma held by each context in debugfs")'
#15: 
References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by 
each context in debugfs")

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


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


[Intel-gfx] [PATCH 2/2] i915/debug: Expose Max BPC info via debugfs

2020-07-30 Thread Bhanuprakash Modem
[Why]
It's useful to know the max supported panel BPC for IGT testing.

[How]
Expose the max supported BPC for the panel via a debugfs file on the
connector, "output_bpc".

Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc

Cc: Uma Shankar 
Cc: Rodrigo Vivi 
Signed-off-by: Bhanuprakash Modem 
---
 .../drm/i915/display/intel_display_debugfs.c| 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 3644752cc5ec..0877d029af77 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,20 @@ static const struct file_operations 
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
 };
 
+/*
+ * Returns the maximum output bpc for the connector.
+ * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ */
+static int output_bpc_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+
+   seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(output_bpc);
+
 /**
  * intel_connector_debugfs_add - add i915 specific connector debugfs files
  * @connector: pointer to a registered drm_connector
@@ -2235,5 +2249,8 @@ int intel_connector_debugfs_add(struct drm_connector 
*connector)
debugfs_create_file("i915_lpsp_capability", 0444, root,
connector, _lpsp_capability_fops);
 
+   debugfs_create_file("output_bpc", S_IRUGO, root,
+   connector, _bpc_fops);
+
return 0;
 }
-- 
2.20.1

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


[Intel-gfx] [PATCH 0/2] Expose crtc dither state and connector max bpc via debugfs

2020-07-30 Thread Bhanuprakash Modem
[why]
It's useful to know the max supported panel BPC and PIPE dither state
for IGT testing.

[how]
* Expose the connector max supported BPC for the panel via a debugfs file on the
  connector, "output_bpc".
  Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc

* Expose the dithering state for the crtc via a debugfs file "dither".
  Example: cat /sys/kernel/debug/dri/0/crtc-0/dither

Test-with: 20200729184152.9236-1-bhanuprakash.mo...@intel.com

Bhanuprakash Modem (2):
  i915/debug: Expose crtc dither state via debugfs
  i915/debug: Expose Max BPC info via debugfs

 .../drm/i915/display/intel_display_debugfs.c| 17 +
 drivers/gpu/drm/i915/i915_debugfs.c | 17 +
 2 files changed, 34 insertions(+)

-- 
2.20.1

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


[Intel-gfx] [PATCH 1/2] i915/debug: Expose crtc dither state via debugfs

2020-07-30 Thread Bhanuprakash Modem
[Why]
It's useful to know the dithering state for IGT testing.

[How]
Expose the dithering state for the crtc via a debugfs file "dither".

Example usage: cat /sys/kernel/debug/dri/0/crtc-0/dither

Cc: Uma Shankar 
Cc: Rodrigo Vivi 
Signed-off-by: Bhanuprakash Modem 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..7174fce05e6e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1650,13 +1650,30 @@ static const struct i915_debugfs_files {
 #endif
 };
 
+static int dither_state_show(struct seq_file *m, void *data)
+{
+   struct intel_crtc *crtc = to_intel_crtc(m->private);
+   struct intel_crtc_state *crtc_state = 
to_intel_crtc_state(crtc->base.state);
+
+   seq_printf(m, "Dither: %u\n", crtc_state->dither);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(dither_state);
+
 void i915_debugfs_register(struct drm_i915_private *dev_priv)
 {
struct drm_minor *minor = dev_priv->drm.primary;
+   struct drm_device *dev = _priv->drm;
+   struct drm_crtc *crtc;
int i;
 
i915_debugfs_params(dev_priv);
 
+   drm_for_each_crtc(crtc, dev)
+   debugfs_create_file("dither", S_IRUGO, crtc->debugfs_entry, 
crtc,
+   _state_fops);
+
debugfs_create_file("i915_forcewake_user", S_IRUSR, minor->debugfs_root,
to_i915(minor->dev), _forcewake_fops);
for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
-- 
2.20.1

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


[Intel-gfx] [PATCH 03/21] drm/i915: Export a preallocate variant of i915_active_acquire()

2020-07-30 Thread Chris Wilson
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.

v2: Refactor active_lookup() so it can be called again before/after
locking to resolve contention. Since we protect the rbtree until we
idle, we can do a lockfree lookup, with the caveat that if another
thread performs a concurrent insertion, the rotations from the insert
may cause us to not find our target. A second pass holding the treelock
will find the target if it exists, or the place to perform our
insertion.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |   4 +-
 drivers/gpu/drm/i915/i915_active.c| 150 ++
 drivers/gpu/drm/i915/i915_active.h|  12 +-
 4 files changed, 130 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b7a86cdec9b5..07cb2dd0f795 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1729,7 +1729,7 @@ __parser_mark_active(struct i915_vma *vma,
 {
struct intel_gt_buffer_pool_node *node = vma->private;
 
-   return i915_active_ref(>active, tl, fence);
+   return i915_active_ref(>active, tl->fence_context, fence);
 }
 
 static int
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c 
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 46d20f5f3ddc..acb43aebd669 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -484,7 +484,9 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
 * free it after the current request is retired, which ensures that
 * all writes into the cacheline from previous requests are complete.
 */
-   err = i915_active_ref(>hwsp_cacheline->active, tl, >fence);
+   err = i915_active_ref(>hwsp_cacheline->active,
+ tl->fence_context,
+ >fence);
if (err)
goto err_cacheline;
 
diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 500537889e66..3a728401c09c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -28,12 +28,14 @@ static struct i915_global_active {
 } global;
 
 struct active_node {
+   struct rb_node node;
struct i915_active_fence base;
struct i915_active *ref;
-   struct rb_node node;
u64 timeline;
 };
 
+#define fetch_node(x) rb_entry(READ_ONCE(x), typeof(struct active_node), node)
+
 static inline struct active_node *
 node_from_active(struct i915_active_fence *active)
 {
@@ -216,12 +218,9 @@ excl_retire(struct dma_fence *fence, struct dma_fence_cb 
*cb)
active_retire(container_of(cb, struct i915_active, excl.cb));
 }
 
-static struct i915_active_fence *
-active_instance(struct i915_active *ref, struct intel_timeline *tl)
+static struct active_node *__active_lookup(struct i915_active *ref, u64 idx)
 {
-   struct active_node *node, *prealloc;
-   struct rb_node **p, *parent;
-   u64 idx = tl->fence_context;
+   struct active_node *it;
 
/*
 * We track the most recently used timeline to skip a rbtree search
@@ -230,8 +229,39 @@ active_instance(struct i915_active *ref, struct 
intel_timeline *tl)
 * after the previous activity has been retired, or if it matches the
 * current timeline.
 */
-   node = READ_ONCE(ref->cache);
-   if (node && node->timeline == idx)
+   it = READ_ONCE(ref->cache);
+   if (it && it->timeline == idx)
+   return it;
+
+   BUILD_BUG_ON(offsetof(typeof(*it), node));
+
+   /* While active, the tree can only be built; not destroyed */
+   GEM_BUG_ON(i915_active_is_idle(ref));
+
+   it = fetch_node(ref->tree.rb_node);
+   while (it) {
+   if (it->timeline < idx) {
+   it = fetch_node(it->node.rb_right);
+   } else if (it->timeline > idx) {
+   it = fetch_node(it->node.rb_left);
+   } else {
+   WRITE_ONCE(ref->cache, it);
+   break;
+   }
+   }
+
+   /* NB: If the tree rotated beneath us, we may miss our target. */
+   return it;
+}
+
+static struct i915_active_fence *
+active_instance(struct i915_active *ref, u64 idx)
+{
+   struct active_node *node, *prealloc;
+   struct rb_node **p, *parent;
+
+   node = __active_lookup(ref, idx);
+   if (likely(node))
return >base;
 
/* Preallocate a replacement, just in case */
@@ -268,10 +298,9 @@ active_instance(struct i915_active *ref, struct 

[Intel-gfx] [PATCH 19/21] drm/i915: Drop i915_request.lock serialisation around await_start

2020-07-30 Thread Chris Wilson
Originally, we used the signal->lock as a means of following the
previous link in its timeline and peeking at the previous fence.
However, we have replaced the explicit serialisation with a series of
very careful probes that anticipate the links being deleted and the
fences recycled before we are able to acquire a strong reference to it.
We do not need the signal->lock crutch anymore, nor want the contention.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_request.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e36253bb6124..247e021203c2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -955,9 +955,16 @@ i915_request_await_start(struct i915_request *rq, struct 
i915_request *signal)
if (i915_request_started(signal))
return 0;
 
+   /*
+* The caller holds a reference on @signal, but we do not serialise
+* against it being retired and removed from the lists.
+*
+* We do not hold a reference to the request before @signal, and
+* so must be very careful to ensure that it is not _recycled_ as
+* we follow the link backwards.
+*/
fence = NULL;
rcu_read_lock();
-   spin_lock_irq(>lock);
do {
struct list_head *pos = READ_ONCE(signal->link.prev);
struct i915_request *prev;
@@ -988,7 +995,6 @@ i915_request_await_start(struct i915_request *rq, struct 
i915_request *signal)
 
fence = >fence;
} while (0);
-   spin_unlock_irq(>lock);
rcu_read_unlock();
if (!fence)
return 0;
-- 
2.20.1

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


[Intel-gfx] [PATCH 10/21] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs

2020-07-30 Thread Chris Wilson
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock within request submission.

The challenge in serialisation is around the unsubmission where we take
an active request that wants a breadcrumb on the signaling engine and
put it to sleep. We do not want a concurrent
dma_fence_enable_signaling() to attach a breadcrumb as we unsubmit, so
we must mark the request as no longer active before serialising with the
concurrent enable-signaling.

On retire, we serialise with the concurrent enable-signaling, but
instead of clearing ACTIVE, we mark it as SIGNALED.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 130 +---
 drivers/gpu/drm/i915/gt/intel_lrc.c |  14 ---
 drivers/gpu/drm/i915/i915_request.c |  39 +++---
 3 files changed, 100 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 91786310c114..3d211a0c2b5a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,17 +220,17 @@ static void signal_irq_work(struct irq_work *work)
}
 }
 
-static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
 
lockdep_assert_held(>irq_lock);
if (b->irq_armed)
-   return true;
+   return;
 
if (!intel_gt_pm_get_if_awake(engine->gt))
-   return false;
+   return;
 
/*
 * The breadcrumb irq will be disarmed on the interrupt after the
@@ -250,8 +250,6 @@ static bool __intel_breadcrumbs_arm_irq(struct 
intel_breadcrumbs *b)
 
if (!b->irq_enabled++)
irq_enable(engine);
-
-   return true;
 }
 
 void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine)
@@ -310,57 +308,99 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs 
*engine)
 {
 }
 
-bool i915_request_enable_breadcrumb(struct i915_request *rq)
+static void insert_breadcrumb(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
 {
-   lockdep_assert_held(>lock);
+   struct intel_context *ce = rq->context;
+   struct list_head *pos;
 
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
-   return true;
+   if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
+   return;
 
-   if (test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
-   struct intel_breadcrumbs *b = >engine->breadcrumbs;
-   struct intel_context *ce = rq->context;
-   struct list_head *pos;
+   __intel_breadcrumbs_arm_irq(b);
 
-   spin_lock(>irq_lock);
+   /*
+* We keep the seqno in retirement order, so we can break
+* inside intel_engine_signal_breadcrumbs as soon as we've
+* passed the last completed request (or seen a request that
+* hasn't event started). We could walk the timeline->requests,
+* but keeping a separate signalers_list has the advantage of
+* hopefully being much smaller than the full list and so
+* provides faster iteration and detection when there are no
+* more interrupts required for this context.
+*
+* We typically expect to add new signalers in order, so we
+* start looking for our insertion point from the tail of
+* the list.
+*/
+   list_for_each_prev(pos, >signals) {
+   struct i915_request *it =
+   list_entry(pos, typeof(*it), signal_link);
 
-   if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
-   goto unlock;
+   if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
+   break;
+   }
+   list_add(>signal_link, pos);
+   if (pos == >signals) /* catch transitions from empty list */
+   list_move_tail(>signal_link, >signalers);
+   GEM_BUG_ON(!check_signal_order(ce, rq));
 
-   if (!__intel_breadcrumbs_arm_irq(b))
-   goto unlock;
+   set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+}
 
-   /*
-* We keep the seqno in retirement order, so we can break
-* inside intel_engine_signal_breadcrumbs as soon as we've
-* passed the last completed request (or seen a request that
-* hasn't event started). We could walk the timeline->requests,
-* but keeping a separate 

[Intel-gfx] [PATCH 15/21] drm/i915/gt: Hold context/request reference while breadcrumbs are active

2020-07-30 Thread Chris Wilson
Currently we hold no actual reference to the request nor context while
they are attached to a breadcrumb. To avoid freeing the request/context
too early, we serialise with cancel-breadcrumbs by taking the irq
spinlock in i915_request_retire(). The alternative is to take a
reference for a new breadcrumb and release it upon signaling; removing
the more frequently hit contention point in i915_request_retire().

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 57 -
 drivers/gpu/drm/i915/i915_request.c |  9 ++--
 2 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 9dd99969fd07..fc6f0223d2c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -29,6 +29,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_breadcrumbs.h"
+#include "intel_context.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
 
@@ -99,6 +100,22 @@ static void __intel_breadcrumbs_disarm_irq(struct 
intel_breadcrumbs *b)
intel_gt_pm_put_async(b->irq_engine->gt);
 }
 
+static void add_signaling_context(struct intel_breadcrumbs *b,
+ struct intel_context *ce)
+{
+   intel_context_get(ce);
+   list_add_tail(>signal_link, >signalers);
+   if (list_is_first(>signal_link, >signalers))
+   __intel_breadcrumbs_arm_irq(b);
+}
+
+static void remove_signaling_context(struct intel_breadcrumbs *b,
+struct intel_context *ce)
+{
+   list_del(>signal_link);
+   intel_context_put(ce);
+}
+
 static inline bool __request_completed(const struct i915_request *rq)
 {
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
@@ -107,6 +124,9 @@ static inline bool __request_completed(const struct 
i915_request *rq)
 __maybe_unused static bool
 check_signal_order(struct intel_context *ce, struct i915_request *rq)
 {
+   if (rq->context != ce)
+   return false;
+
if (!list_is_last(>signal_link, >signals) &&
i915_seqno_passed(rq->fence.seqno,
  list_next_entry(rq, signal_link)->fence.seqno))
@@ -158,10 +178,11 @@ static bool __signal_request(struct i915_request *rq, 
struct list_head *signals)
 {
clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
 
-   if (!__dma_fence_signal(>fence))
+   if (!__dma_fence_signal(>fence)) {
+   i915_request_put(rq);
return false;
+   }
 
-   i915_request_get(rq);
list_add_tail(>signal_link, signals);
return true;
 }
@@ -209,8 +230,8 @@ static void signal_irq_work(struct irq_work *work)
/* Advance the list to the first incomplete request */
__list_del_many(>signals, pos);
if (>signals == pos) { /* now empty */
-   list_del_init(>signal_link);
add_retire(b, ce->timeline);
+   remove_signaling_context(b, ce);
}
}
}
@@ -279,6 +300,9 @@ void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
spin_lock_irqsave(>irq_lock, flags);
__intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(>irq_lock, flags);
+
+   if (!list_empty(>signalers))
+   irq_work_queue(>irq_work);
 }
 
 void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
@@ -295,6 +319,8 @@ static void insert_breadcrumb(struct i915_request *rq,
if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
 
+   i915_request_get(rq);
+
/*
 * If the request is already completed, we can transfer it
 * straight onto a signaled list, and queue the irq worker for
@@ -306,8 +332,6 @@ static void insert_breadcrumb(struct i915_request *rq,
return;
}
 
-   __intel_breadcrumbs_arm_irq(b);
-
/*
 * We keep the seqno in retirement order, so we can break
 * inside intel_engine_signal_breadcrumbs as soon as we've
@@ -322,16 +346,19 @@ static void insert_breadcrumb(struct i915_request *rq,
 * start looking for our insertion point from the tail of
 * the list.
 */
-   list_for_each_prev(pos, >signals) {
-   struct i915_request *it =
-   list_entry(pos, typeof(*it), signal_link);
-
-   if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
-   break;
+   if (list_empty(>signals)) {
+   add_signaling_context(b, ce);
+   pos = >signals;
+   } else {
+   list_for_each_prev(pos, >signals) {
+   struct i915_request *it =
+   list_entry(pos, typeof(*it), 

[Intel-gfx] [PATCH 11/21] drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs

2020-07-30 Thread Chris Wilson
After staring at the breadcrumb enabling/cancellation and coming to the
conclusion that the cause of the mysterious stale breadcrumbs must the
act of submitting a completed requests, we can then redirect those
completed requests onto a dedicated signaled_list at the time of
construction and so eliminate intel_engine_transfer_stale_breadcrumbs().

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 50 -
 drivers/gpu/drm/i915/gt/intel_engine.h  |  3 --
 drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
 drivers/gpu/drm/i915/i915_request.c |  5 +--
 4 files changed, 21 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 3d211a0c2b5a..fbdc465a5870 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -142,16 +142,16 @@ static void add_retire(struct intel_breadcrumbs *b, 
struct intel_timeline *tl)
intel_engine_add_retire(engine, tl);
 }
 
-static void __signal_request(struct i915_request *rq, struct list_head 
*signals)
+static bool __signal_request(struct i915_request *rq, struct list_head 
*signals)
 {
-   GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
 
if (!__dma_fence_signal(>fence))
-   return;
+   return false;
 
i915_request_get(rq);
list_add_tail(>signal_link, signals);
+   return true;
 }
 
 static void signal_irq_work(struct irq_work *work)
@@ -278,32 +278,6 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce)
-{
-   struct intel_breadcrumbs *b = >breadcrumbs;
-   unsigned long flags;
-
-   spin_lock_irqsave(>irq_lock, flags);
-   if (!list_empty(>signals)) {
-   struct i915_request *rq, *next;
-
-   /* Queue for executing the signal callbacks in the irq_work */
-   list_for_each_entry_safe(rq, next, >signals, signal_link) {
-   GEM_BUG_ON(rq->engine != engine);
-   GEM_BUG_ON(!__request_completed(rq));
-
-   __signal_request(rq, >signaled_requests);
-   }
-
-   INIT_LIST_HEAD(>signals);
-   list_del_init(>signal_link);
-
-   irq_work_queue(>irq_work);
-   }
-   spin_unlock_irqrestore(>irq_lock, flags);
-}
-
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
 {
 }
@@ -317,6 +291,17 @@ static void insert_breadcrumb(struct i915_request *rq,
if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
 
+   /*
+* If the request is already completed, we can transfer it
+* straight onto a signaled list, and queue the irq worker for
+* its signal completion.
+*/
+   if (__request_completed(rq)) {
+   if (__signal_request(rq, >signaled_requests))
+   irq_work_queue(>irq_work);
+   return;
+   }
+
__intel_breadcrumbs_arm_irq(b);
 
/*
@@ -344,8 +329,11 @@ static void insert_breadcrumb(struct i915_request *rq,
if (pos == >signals) /* catch transitions from empty list */
list_move_tail(>signal_link, >signalers);
GEM_BUG_ON(!check_signal_order(ce, rq));
-
set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+
+   /* Check after attaching to irq, interrupt may have already fired. */
+   if (__request_completed(rq))
+   irq_work_queue(>irq_work);
 }
 
 bool i915_request_enable_breadcrumb(struct i915_request *rq)
@@ -401,7 +389,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
 
spin_unlock(>irq_lock);
 
-   return !__request_completed(rq);
+   return true;
 }
 
 void i915_request_cancel_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index a9249a23903a..faf00a353e25 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -237,9 +237,6 @@ intel_engine_signal_breadcrumbs(struct intel_engine_cs 
*engine)
 void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
 
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce);
-
 void intel_engine_print_breadcrumbs(struct intel_engine_cs *engine,
struct drm_printer *p);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 

[Intel-gfx] [PATCH 01/21] drm/i915: Add a couple of missing i915_active_fini()

2020-07-30 Thread Chris Wilson
We use i915_active_fini() as a debug check on the i915_active state
before freeing. If we forget to call it, we may end up angering the
debugobjects contained within.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/display/intel_frontbuffer.c| 2 ++
 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 5 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 2979ed2588eb..d898b370d7a4 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -232,6 +232,8 @@ static void frontbuffer_release(struct kref *ref)
RCU_INIT_POINTER(obj->frontbuffer, NULL);
spin_unlock(_i915(obj->base.dev)->fb_tracking.lock);
 
+   i915_active_fini(>write);
+
i915_gem_object_put(obj);
kfree_rcu(front, rcu);
 }
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
index 73243ba59c7d..e73854dd2fe0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
@@ -47,7 +47,10 @@ static int pulse_active(struct i915_active *active)
 
 static void pulse_free(struct kref *kref)
 {
-   kfree(container_of(kref, struct pulse, kref));
+   struct pulse *p = container_of(kref, typeof(*p), kref);
+
+   i915_active_fini(>active);
+   kfree(p);
 }
 
 static void pulse_put(struct pulse *p)
-- 
2.20.1

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


[Intel-gfx] [PATCH 06/21] drm/i915: Reduce locking around i915_active_acquire_preallocate_barrier()

2020-07-30 Thread Chris Wilson
As the conversion between idle-barrier and full i915_active_fence is
already serialised by explicit memory barriers, we can reduce the
spinlock in i915_active_acquire_preallocate_barrier() for finding an
idle-barrier to reuse to an RCU read lock to ensure the fence remains
valid, only taking the spinlock for the update of the rbtree itself.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_active.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 7b51045c8461..5dd52bb6d38c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -807,7 +807,6 @@ static struct active_node *reuse_idle_barrier(struct 
i915_active *ref, u64 idx)
if (RB_EMPTY_ROOT(>tree))
return NULL;
 
-   spin_lock_irq(>tree_lock);
GEM_BUG_ON(i915_active_is_idle(ref));
 
/*
@@ -872,11 +871,10 @@ static struct active_node *reuse_idle_barrier(struct 
i915_active *ref, u64 idx)
goto match;
}
 
-   spin_unlock_irq(>tree_lock);
-
return NULL;
 
 match:
+   spin_lock_irq(>tree_lock);
rb_erase(p, >tree); /* Hide from waits and sibling allocations */
if (p == >cache->node)
WRITE_ONCE(ref->cache, NULL);
@@ -911,7 +909,9 @@ int i915_active_acquire_preallocate_barrier(struct 
i915_active *ref,
struct llist_node *prev = first;
struct active_node *node;
 
+   rcu_read_lock();
node = reuse_idle_barrier(ref, idx);
+   rcu_read_unlock();
if (!node) {
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
if (!node) {
-- 
2.20.1

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


[Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock

2020-07-30 Thread Chris Wilson
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 30 +++
 .../gpu/drm/i915/gt/intel_breadcrumbs_types.h |  2 +-
 drivers/gpu/drm/i915/i915_request.h   |  6 +++-
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fc6f0223d2c8..6a278bf0fc6b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -174,16 +174,13 @@ static void add_retire(struct intel_breadcrumbs *b, 
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
 }
 
-static bool __signal_request(struct i915_request *rq, struct list_head 
*signals)
+static bool __signal_request(struct i915_request *rq)
 {
-   clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
-
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
 
-   list_add_tail(>signal_link, signals);
return true;
 }
 
@@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
 {
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+   struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
-   LIST_HEAD(signal);
+
+   signal = NULL;
+   if (unlikely(!llist_empty(>signaled_requests)))
+   signal = llist_del_all(>signaled_requests);
 
spin_lock(>irq_lock);
 
-   if (list_empty(>signalers))
+   if (!signal && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
 
-   list_splice_init(>signaled_requests, );
-
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
GEM_BUG_ON(list_empty(>signals));
 
@@ -218,7 +217,11 @@ static void signal_irq_work(struct irq_work *work)
 * spinlock as the callback chain may end up adding
 * more signalers to the same context or engine.
 */
-   __signal_request(rq, );
+   clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+   if (__signal_request(rq)) {
+   rq->signal_node.next = signal;
+   signal = >signal_node;
+   }
}
 
/*
@@ -238,9 +241,9 @@ static void signal_irq_work(struct irq_work *work)
 
spin_unlock(>irq_lock);
 
-   list_for_each_safe(pos, next, ) {
+   llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
-   list_entry(pos, typeof(*rq), signal_link);
+   llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
 
spin_lock(>lock);
@@ -264,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
 
spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>signalers);
-   INIT_LIST_HEAD(>signaled_requests);
+   init_llist_head(>signaled_requests);
 
init_irq_work(>irq_work, signal_irq_work);
 
@@ -327,7 +330,8 @@ static void insert_breadcrumb(struct i915_request *rq,
 * its signal completion.
 */
if (__request_completed(rq)) {
-   if (__signal_request(rq, >signaled_requests))
+   if (__signal_request(rq) &&
+   llist_add(>signal_node, >signaled_requests))
irq_work_queue(>irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
 
struct list_head signalers;
-   struct list_head signaled_requests;
+   struct llist_head signaled_requests;
 
struct irq_work irq_work; /* for use from inside irq_lock */
 
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 16b721080195..874af6db6103 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -176,7 +176,11 @@ struct i915_request {
struct intel_context *context;
struct intel_ring *ring;
struct intel_timeline __rcu *timeline;
-   struct list_head signal_link;
+
+   union {
+   struct list_head signal_link;
+   struct llist_node signal_node;
+   };
 
/*
 * The rcu epoch of when this request was allocated. Used to judiciously
-- 
2.20.1


[Intel-gfx] [PATCH 18/21] drm/i915/gt: Split the breadcrumb spinlock between global and contexts

2020-07-30 Thread Chris Wilson
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 149 ++
 drivers/gpu/drm/i915/gt/intel_context.c   |   1 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |   1 +
 3 files changed, 84 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 6a278bf0fc6b..23fe647b50b3 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -103,17 +103,19 @@ static void __intel_breadcrumbs_disarm_irq(struct 
intel_breadcrumbs *b)
 static void add_signaling_context(struct intel_breadcrumbs *b,
  struct intel_context *ce)
 {
-   intel_context_get(ce);
-   list_add_tail(>signal_link, >signalers);
-   if (list_is_first(>signal_link, >signalers))
+   lockdep_assert_held(>irq_lock);
+
+   list_add_rcu(>signal_link, >signalers);
+   if (list_is_last(>signal_link, >signalers))
__intel_breadcrumbs_arm_irq(b);
 }
 
 static void remove_signaling_context(struct intel_breadcrumbs *b,
 struct intel_context *ce)
 {
-   list_del(>signal_link);
-   intel_context_put(ce);
+   spin_lock(>irq_lock);
+   list_del_rcu(>signal_link);
+   spin_unlock(>irq_lock);
 }
 
 static inline bool __request_completed(const struct i915_request *rq)
@@ -189,20 +191,30 @@ static void signal_irq_work(struct irq_work *work)
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
struct llist_node *signal, *sn;
-   struct intel_context *ce, *cn;
-   struct list_head *pos, *next;
+   struct intel_context *ce;
 
signal = NULL;
if (unlikely(!llist_empty(>signaled_requests)))
signal = llist_del_all(>signaled_requests);
 
-   spin_lock(>irq_lock);
+   if (!signal && READ_ONCE(b->irq_armed) && list_empty(>signalers)) {
+   if (spin_trylock(>irq_lock)) {
+   if (list_empty(>signalers))
+   __intel_breadcrumbs_disarm_irq(b);
+   spin_unlock(>irq_lock);
+   }
+   }
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ce, >signalers, signal_link) {
+   struct list_head *pos, *next;
+   bool release = false;
 
-   if (!signal && list_empty(>signalers))
-   __intel_breadcrumbs_disarm_irq(b);
+   if (!spin_trylock(>signal_lock))
+   continue;
 
-   list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
-   GEM_BUG_ON(list_empty(>signals));
+   if (list_empty(>signals))
+   goto unlock;
 
list_for_each_safe(pos, next, >signals) {
struct i915_request *rq =
@@ -235,11 +247,16 @@ static void signal_irq_work(struct irq_work *work)
if (>signals == pos) { /* now empty */
add_retire(b, ce->timeline);
remove_signaling_context(b, ce);
+   release = true;
}
}
-   }
 
-   spin_unlock(>irq_lock);
+unlock:
+   spin_unlock(>signal_lock);
+   if (release)
+   intel_context_put(ce);
+   }
+   rcu_read_unlock();
 
llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
@@ -313,9 +330,9 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
 }
 
-static void insert_breadcrumb(struct i915_request *rq,
- struct intel_breadcrumbs *b)
+static void insert_breadcrumb(struct i915_request *rq)
 {
+   struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
struct list_head *pos;
 
@@ -351,7 +368,33 @@ static void insert_breadcrumb(struct i915_request *rq,
 * the list.
 */
if (list_empty(>signals)) {
+   /*
+* rq->engine is locked by rq->engine->active.lock. That
+* however is not known until 

[Intel-gfx] [PATCH 04/21] drm/i915: Keep the most recently used active-fence upon discard

2020-07-30 Thread Chris Wilson
Whenever an i915_active idles, we prune its tree of old fence slots to
prevent a gradual leak should it be used to track many, many timelines.
The downside is that we then have to frequently reallocate the rbtree.
A compromise is that we keep the most recently used fence slot, and
reuse that for the next active reference as that is the most likely
timeline to be reused.

Signed-off-by: Chris Wilson 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_active.c | 27 ---
 drivers/gpu/drm/i915/i915_active.h |  4 
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index 3a728401c09c..b9bd5578ff54 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -130,8 +130,8 @@ static inline void debug_active_assert(struct i915_active 
*ref) { }
 static void
 __active_retire(struct i915_active *ref)
 {
+   struct rb_root root = RB_ROOT;
struct active_node *it, *n;
-   struct rb_root root;
unsigned long flags;
 
GEM_BUG_ON(i915_active_is_idle(ref));
@@ -143,9 +143,21 @@ __active_retire(struct i915_active *ref)
GEM_BUG_ON(rcu_access_pointer(ref->excl.fence));
debug_active_deactivate(ref);
 
-   root = ref->tree;
-   ref->tree = RB_ROOT;
-   ref->cache = NULL;
+   /* Even if we have not used the cache, we may still have a barrier */
+   if (!ref->cache)
+   ref->cache = fetch_node(ref->tree.rb_node);
+
+   /* Keep the MRU cached node for reuse */
+   if (ref->cache) {
+   /* Discard all other nodes in the tree */
+   rb_erase(>cache->node, >tree);
+   root = ref->tree;
+
+   /* Rebuild the tree with only the cached node */
+   rb_link_node(>cache->node, NULL, >tree.rb_node);
+   rb_insert_color(>cache->node, >tree);
+   GEM_BUG_ON(ref->tree.rb_node != >cache->node);
+   }
 
spin_unlock_irqrestore(>tree_lock, flags);
 
@@ -156,6 +168,7 @@ __active_retire(struct i915_active *ref)
/* ... except if you wait on it, you must manage your own references! */
wake_up_var(ref);
 
+   /* Finally free the discarded timeline tree  */
rbtree_postorder_for_each_entry_safe(it, n, , node) {
GEM_BUG_ON(i915_active_fence_isset(>base));
kmem_cache_free(global.slab_cache, it);
@@ -745,16 +758,16 @@ int i915_sw_fence_await_active(struct i915_sw_fence 
*fence,
return await_active(ref, flags, sw_await_fence, fence, fence);
 }
 
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
 void i915_active_fini(struct i915_active *ref)
 {
debug_active_fini(ref);
GEM_BUG_ON(atomic_read(>count));
GEM_BUG_ON(work_pending(>work));
-   GEM_BUG_ON(!RB_EMPTY_ROOT(>tree));
mutex_destroy(>mutex);
+
+   if (ref->cache)
+   kmem_cache_free(global.slab_cache, ref->cache);
 }
-#endif
 
 static inline bool is_idle_barrier(struct active_node *node, u64 idx)
 {
diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index 73ded3c52a04..b9e0394e2975 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -217,11 +217,7 @@ i915_active_is_idle(const struct i915_active *ref)
return !atomic_read(>count);
 }
 
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
 void i915_active_fini(struct i915_active *ref);
-#else
-static inline void i915_active_fini(struct i915_active *ref) { }
-#endif
 
 int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
struct intel_engine_cs *engine);
-- 
2.20.1

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


[Intel-gfx] [PATCH 09/21] drm/i915/gem: Reduce ctx->engines_mutex for get_engines()

2020-07-30 Thread Chris Wilson
Take a snapshot of the ctx->engines, so we can avoid taking the
ctx->engines_mutex for a mere read in get_engines().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 +
 1 file changed, 8 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b5b179f96d77..f43f0ca4eec9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1862,27 +1862,6 @@ set_engines(struct i915_gem_context *ctx,
return 0;
 }
 
-static struct i915_gem_engines *
-__copy_engines(struct i915_gem_engines *e)
-{
-   struct i915_gem_engines *copy;
-   unsigned int n;
-
-   copy = alloc_engines(e->num_engines);
-   if (!copy)
-   return ERR_PTR(-ENOMEM);
-
-   for (n = 0; n < e->num_engines; n++) {
-   if (e->engines[n])
-   copy->engines[n] = intel_context_get(e->engines[n]);
-   else
-   copy->engines[n] = NULL;
-   }
-   copy->num_engines = n;
-
-   return copy;
-}
-
 static int
 get_engines(struct i915_gem_context *ctx,
struct drm_i915_gem_context_param *args)
@@ -1890,19 +1869,17 @@ get_engines(struct i915_gem_context *ctx,
struct i915_context_param_engines __user *user;
struct i915_gem_engines *e;
size_t n, count, size;
+   bool user_engines;
int err = 0;
 
-   err = mutex_lock_interruptible(>engines_mutex);
-   if (err)
-   return err;
+   e = __context_engines_await(ctx, _engines);
+   if (!e)
+   return -ENOENT;
 
-   e = NULL;
-   if (i915_gem_context_user_engines(ctx))
-   e = __copy_engines(i915_gem_context_engines(ctx));
-   mutex_unlock(>engines_mutex);
-   if (IS_ERR_OR_NULL(e)) {
+   if (!user_engines) {
+   i915_sw_fence_complete(>fence);
args->size = 0;
-   return PTR_ERR_OR_ZERO(e);
+   return 0;
}
 
count = e->num_engines;
@@ -1953,7 +1930,7 @@ get_engines(struct i915_gem_context *ctx,
args->size = size;
 
 err_free:
-   free_engines(e);
+   i915_sw_fence_complete(>fence);
return err;
 }
 
-- 
2.20.1

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


[Intel-gfx] Breadcrumbs fixes and stall avoidance

2020-07-30 Thread Chris Wilson
All the breadcrumb fixes and low hanging fruit from staring at perf and
lockstat for too long to minimise the delays during submission.
-Chris


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


[Intel-gfx] [PATCH 13/21] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs

2020-07-30 Thread Chris Wilson
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as we need to ensure that we do not actually try and
enable interrupts and the powermanagement required for them on the
virtual engine, as they will never be disabled. Instead, let's
specify the physical engine used for interrupt handler on a particular
breadcrumb.

v2: Drop b->irq_armed = true mocking for no interrupt HW

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 76 ++-
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h   | 36 +
 .../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 47 
 drivers/gpu/drm/i915/gt/intel_engine.h| 17 -
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  3 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h  | 31 +---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 11 ++-
 drivers/gpu/drm/i915/gt/intel_reset.c |  1 +
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  3 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   |  1 +
 drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++-
 drivers/gpu/drm/i915/i915_irq.c   |  1 +
 drivers/gpu/drm/i915/i915_request.c   |  1 +
 drivers/gpu/drm/i915/i915_request.h   |  4 -
 16 files changed, 162 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
 create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fbdc465a5870..2ffd47a86656 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -28,6 +28,7 @@
 
 #include "i915_drv.h"
 #include "i915_trace.h"
+#include "intel_breadcrumbs.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
 
@@ -55,30 +56,28 @@ static void irq_disable(struct intel_engine_cs *engine)
 
 static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
 {
-   struct intel_engine_cs *engine =
-   container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
 
+   if (!b->irq_engine || !b->irq_armed)
+   return;
+
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
-   irq_disable(engine);
+   irq_disable(b->irq_engine);
 
WRITE_ONCE(b->irq_armed, false);
-   intel_gt_pm_put_async(engine->gt);
+   intel_gt_pm_put_async(b->irq_engine->gt);
 }
 
-void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
 {
-   struct intel_breadcrumbs *b = >breadcrumbs;
unsigned long flags;
 
if (!READ_ONCE(b->irq_armed))
return;
 
spin_lock_irqsave(>irq_lock, flags);
-   if (b->irq_armed)
-   __intel_breadcrumbs_disarm_irq(b);
+   __intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
@@ -133,13 +132,8 @@ __dma_fence_signal__notify(struct dma_fence *fence,
 
 static void add_retire(struct intel_breadcrumbs *b, struct intel_timeline *tl)
 {
-   struct intel_engine_cs *engine =
-   container_of(b, struct intel_engine_cs, breadcrumbs);
-
-   if (unlikely(intel_engine_is_virtual(engine)))
-   engine = intel_virtual_engine_get_sibling(engine, 0);
-
-   intel_engine_add_retire(engine, tl);
+   if (b->irq_engine)
+   intel_engine_add_retire(b->irq_engine, tl);
 }
 
 static bool __signal_request(struct i915_request *rq, struct list_head 
*signals)
@@ -164,7 +158,7 @@ static void signal_irq_work(struct irq_work *work)
 
spin_lock(>irq_lock);
 
-   if (b->irq_armed && list_empty(>signalers))
+   if (list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
 
list_splice_init(>signaled_requests, );
@@ -222,14 +216,12 @@ static void signal_irq_work(struct irq_work *work)
 
 static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
-   struct intel_engine_cs *engine =
-   container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
-   if (b->irq_armed)
+
+   if (!b->irq_engine || b->irq_armed)
return;
 
-   if (!intel_gt_pm_get_if_awake(engine->gt))
+   if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
return;
 
/*
@@ -249,37 +241,49 @@ static void __intel_breadcrumbs_arm_irq(struct 
intel_breadcrumbs *b)
 */
 
if (!b->irq_enabled++)
-   irq_enable(engine);
+ 

[Intel-gfx] [PATCH 05/21] drm/i915: Make the stale cached active node available for any timeline

2020-07-30 Thread Chris Wilson
Rather than require the next timeline after idling to match the MRU
before idling, reset the index on the node and allow it to match the
first request. However, this requires cmpxchg(u64) and so is not trivial
on 32b, so for compatibility we just fallback to keeping the cached node
pointing to the MRU timeline.

Signed-off-by: Chris Wilson 
Reviewed-by: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_active.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index b9bd5578ff54..7b51045c8461 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -157,6 +157,10 @@ __active_retire(struct i915_active *ref)
rb_link_node(>cache->node, NULL, >tree.rb_node);
rb_insert_color(>cache->node, >tree);
GEM_BUG_ON(ref->tree.rb_node != >cache->node);
+
+   /* Make the cached node available for reuse with any timeline */
+   if (IS_ENABLED(CONFIG_64BIT))
+   ref->cache->timeline = 0; /* needs cmpxchg(u64) */
}
 
spin_unlock_irqrestore(>tree_lock, flags);
@@ -235,6 +239,8 @@ static struct active_node *__active_lookup(struct 
i915_active *ref, u64 idx)
 {
struct active_node *it;
 
+   GEM_BUG_ON(idx == 0); /* 0 is the unordered timeline, rsvd for cache */
+
/*
 * We track the most recently used timeline to skip a rbtree search
 * for the common case, under typical loads we never need the rbtree
@@ -243,8 +249,28 @@ static struct active_node *__active_lookup(struct 
i915_active *ref, u64 idx)
 * current timeline.
 */
it = READ_ONCE(ref->cache);
-   if (it && it->timeline == idx)
-   return it;
+   if (it) {
+   u64 cached = READ_ONCE(it->timeline);
+
+   /* Once claimed, this slot will only belong to this idx */
+   if (cached == idx)
+   return it;
+
+#ifdef CONFIG_64BIT /* for cmpxchg(u64) */
+   /*
+* An unclaimed cache [.timeline=0] can only be claimed once.
+*
+* If the value is already non-zero, some other thread has
+* claimed the cache and we know that is does not match our
+* idx. If, and only if, the timeline is currently zero is it
+* worth competing to claim it atomically for ourselves (for
+* only the winner of that race will cmpxchg return the old
+* value of 0).
+*/
+   if (!cached && !cmpxchg(>timeline, 0, idx))
+   return it;
+#endif
+   }
 
BUILD_BUG_ON(offsetof(typeof(*it), node));
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 12/21] drm/i915/gt: Only transfer the virtual context to the new engine if active

2020-07-30 Thread Chris Wilson
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the context with the new register offsets and marked the virtual
engine as bound to the new engine (by calling swap on ve->siblings[]).
As we may have just retired the completed request, we may also be in the
middle of calling virtual_context_exit() to turn off the power management
associated with the virtual engine, and that in turn walks the
ve->siblings[]. If we happen to call swap() on the array as we walk, we
will call intel_engine_pm_put() twice on the same engine.

In this patch, we prevent this by only updating the bound engine after a
successful submission which weeds out the already completed requests.

Alternatively, we could walk a non-volatile array for the pm, such as
using the engine->mask. The small advantage to performing the update
after the submit is that we then only have to do a swap for active
requests.

Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: "Nayana, Venkata Ramana" 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 65 ++---
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a4959e8229ac..904e9b8bcbf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1805,6 +1805,33 @@ static bool virtual_matches(const struct virtual_engine 
*ve,
return true;
 }
 
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+   unsigned int n;
+
+   if (likely(engine == ve->siblings[0]))
+   return;
+
+   GEM_BUG_ON(READ_ONCE(ve->context.inflight));
+   if (!intel_engine_has_relative_mmio(engine))
+   virtual_update_register_offsets(ve->context.lrc_reg_state,
+   engine);
+
+   /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+   for (n = 1; n < ve->num_siblings; n++) {
+   if (ve->siblings[n] == engine) {
+   swap(ve->siblings[n], ve->siblings[0]);
+   break;
+   }
+   }
+}
+
 #define for_each_waiter(p__, rq__) \
list_for_each_entry_lockless(p__, \
 &(rq__)->sched.waiters_list, \
@@ -2253,35 +2280,23 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
GEM_BUG_ON(!(rq->execution_mask & engine->mask));
WRITE_ONCE(rq->engine, engine);
 
-   if (engine != ve->siblings[0]) {
-   u32 *regs = ve->context.lrc_reg_state;
-   unsigned int n;
-
-   GEM_BUG_ON(READ_ONCE(ve->context.inflight));
-
-   if (!intel_engine_has_relative_mmio(engine))
-   virtual_update_register_offsets(regs,
-   engine);
-
+   if (__i915_request_submit(rq)) {
/*
-* Move the bound engine to the top of the list
-* for future execution. We then kick this
-* tasklet first before checking others, so that
-* we preferentially reuse this set of bound
-* registers.
+* Only after we confirm that we will submit
+* this request (i.e. it has not already
+* completed), do we want to update the context.
+*
+* This serves two purposes. It avoids
+* unnecessary work if we are resubmitting an
+* already completed request after timeslicing.
+* But more importantly, it prevents us altering
+* ve->siblings[] on an idle context, where
+* we may be using ve->siblings[] in
+* virtual_context_enter / virtual_context_exit.
 */
-   for (n = 1; n < ve->num_siblings; n++) {
- 

[Intel-gfx] [PATCH 21/21] drm/i915/gem: Delay tracking the GEM context until it is registered

2020-07-30 Thread Chris Wilson
Avoid exposing a partially constructed context by deferring the
list_add() from the initial construction to the end of registration.
Otherwise, if we peek into the list of contexts from inside debugfs, we
may see the partially constructed context and chase down some dangling
incomplete pointers.

Reported-by: CQ Tang 
Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and 
registration to userspace")
References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by 
each context in debugfs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: CQ Tang 
Cc:  # v5.2+
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f43f0ca4eec9..d308cefb2b34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -713,6 +713,7 @@ __create_context(struct drm_i915_private *i915)
ctx->i915 = i915;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
mutex_init(>mutex);
+   INIT_LIST_HEAD(>link);
 
spin_lock_init(>stale.lock);
INIT_LIST_HEAD(>stale.engines);
@@ -740,10 +741,6 @@ __create_context(struct drm_i915_private *i915)
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
 
-   spin_lock(>gem.contexts.lock);
-   list_add_tail(>link, >gem.contexts.list);
-   spin_unlock(>gem.contexts.lock);
-
return ctx;
 
 err_free:
@@ -936,6 +933,7 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
 {
+   struct drm_i915_private *i915 = ctx->i915;
struct i915_address_space *vm;
int ret;
 
@@ -954,8 +952,16 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
if (ret)
-   put_pid(fetch_and_zero(>pid));
+   goto err_pid;
+
+   spin_lock(>gem.contexts.lock);
+   list_add_tail(>link, >gem.contexts.list);
+   spin_unlock(>gem.contexts.lock);
+
+   return 0;
 
+err_pid:
+   put_pid(fetch_and_zero(>pid));
return ret;
 }
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 14/21] drm/i915/gt: Move intel_breadcrumbs_arm_irq earlier

2020-07-30 Thread Chris Wilson
Move the __intel_breadcrumbs_arm_irq earlier, next to the disarm_irq, so
that we can make use of it in the following patch.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 84 ++---
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 2ffd47a86656..9dd99969fd07 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -54,6 +54,36 @@ static void irq_disable(struct intel_engine_cs *engine)
spin_unlock(>gt->irq_lock);
 }
 
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+{
+   lockdep_assert_held(>irq_lock);
+
+   if (!b->irq_engine || b->irq_armed)
+   return;
+
+   if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
+   return;
+
+   /*
+* The breadcrumb irq will be disarmed on the interrupt after the
+* waiters are signaled. This gives us a single interrupt window in
+* which we can add a new waiter and avoid the cost of re-enabling
+* the irq.
+*/
+   WRITE_ONCE(b->irq_armed, true);
+
+   /*
+* Since we are waiting on a request, the GPU should be busy
+* and should have its own rpm reference. This is tracked
+* by i915->gt.awake, we can forgo holding our own wakref
+* for the interrupt as before i915->gt.awake is released (when
+* the driver is idle) we disarm the breadcrumbs.
+*/
+
+   if (!b->irq_enabled++)
+   irq_enable(b->irq_engine);
+}
+
 static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
 {
lockdep_assert_held(>irq_lock);
@@ -69,18 +99,6 @@ static void __intel_breadcrumbs_disarm_irq(struct 
intel_breadcrumbs *b)
intel_gt_pm_put_async(b->irq_engine->gt);
 }
 
-void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
-{
-   unsigned long flags;
-
-   if (!READ_ONCE(b->irq_armed))
-   return;
-
-   spin_lock_irqsave(>irq_lock, flags);
-   __intel_breadcrumbs_disarm_irq(b);
-   spin_unlock_irqrestore(>irq_lock, flags);
-}
-
 static inline bool __request_completed(const struct i915_request *rq)
 {
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
@@ -214,36 +232,6 @@ static void signal_irq_work(struct irq_work *work)
}
 }
 
-static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
-{
-   lockdep_assert_held(>irq_lock);
-
-   if (!b->irq_engine || b->irq_armed)
-   return;
-
-   if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
-   return;
-
-   /*
-* The breadcrumb irq will be disarmed on the interrupt after the
-* waiters are signaled. This gives us a single interrupt window in
-* which we can add a new waiter and avoid the cost of re-enabling
-* the irq.
-*/
-   WRITE_ONCE(b->irq_armed, true);
-
-   /*
-* Since we are waiting on a request, the GPU should be busy
-* and should have its own rpm reference. This is tracked
-* by i915->gt.awake, we can forgo holding our own wakref
-* for the interrupt as before i915->gt.awake is released (when
-* the driver is idle) we disarm the breadcrumbs.
-*/
-
-   if (!b->irq_enabled++)
-   irq_enable(b->irq_engine);
-}
-
 struct intel_breadcrumbs *
 intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
 {
@@ -281,6 +269,18 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
+{
+   unsigned long flags;
+
+   if (!READ_ONCE(b->irq_armed))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+   __intel_breadcrumbs_disarm_irq(b);
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
 {
kfree(b);
-- 
2.20.1

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


[Intel-gfx] [PATCH 02/21] drm/i915: Skip taking acquire mutex for no ref->active callback

2020-07-30 Thread Chris Wilson
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_active.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..500537889e66 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -416,6 +416,14 @@ bool i915_active_acquire_if_busy(struct i915_active *ref)
return atomic_add_unless(>count, 1, 0);
 }
 
+static void __i915_active_activate(struct i915_active *ref)
+{
+   spin_lock_irq(>tree_lock); /* __active_retire() */
+   if (!atomic_fetch_inc(>count))
+   debug_active_activate(ref);
+   spin_unlock_irq(>tree_lock);
+}
+
 int i915_active_acquire(struct i915_active *ref)
 {
int err;
@@ -423,19 +431,19 @@ int i915_active_acquire(struct i915_active *ref)
if (i915_active_acquire_if_busy(ref))
return 0;
 
+   if (!ref->active) {
+   __i915_active_activate(ref);
+   return 0;
+   }
+
err = mutex_lock_interruptible(>mutex);
if (err)
return err;
 
if (likely(!i915_active_acquire_if_busy(ref))) {
-   if (ref->active)
-   err = ref->active(ref);
-   if (!err) {
-   spin_lock_irq(>tree_lock); /* __active_retire() */
-   debug_active_activate(ref);
-   atomic_inc(>count);
-   spin_unlock_irq(>tree_lock);
-   }
+   err = ref->active(ref);
+   if (!err)
+   __i915_active_activate(ref);
}
 
mutex_unlock(>mutex);
-- 
2.20.1

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


[Intel-gfx] [PATCH 08/21] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source

2020-07-30 Thread Chris Wilson
When cloning the engines from the source context, we need to ensure that
the engines are not freed as we copy them, and that the flags we clone
from the source correspond with the engines we copy across. To do this
we need only take a reference to the src->engines, rather than hold the
src->engine_mutex, so long as we verify that nothing changed under the
read.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0bdb6d447ed..b5b179f96d77 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -752,7 +752,8 @@ __create_context(struct drm_i915_private *i915)
 }
 
 static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx)
+__context_engines_await(const struct i915_gem_context *ctx,
+   bool *user_engines)
 {
struct i915_gem_engines *engines;
 
@@ -761,6 +762,10 @@ __context_engines_await(const struct i915_gem_context *ctx)
engines = rcu_dereference(ctx->engines);
GEM_BUG_ON(!engines);
 
+   if (user_engines)
+   *user_engines = i915_gem_context_user_engines(ctx);
+
+   /* successful await => strong mb */
if (unlikely(!i915_sw_fence_await(>fence)))
continue;
 
@@ -784,7 +789,7 @@ context_apply_all(struct i915_gem_context *ctx,
struct intel_context *ce;
int err = 0;
 
-   e = __context_engines_await(ctx);
+   e = __context_engines_await(ctx, NULL);
for_each_gem_engine(ce, e, it) {
err = fn(ce, data);
if (err)
@@ -1117,7 +1122,7 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
return err;
}
 
-   e = __context_engines_await(ctx);
+   e = __context_engines_await(ctx, NULL);
if (!e) {
i915_active_release(>base);
return -ENOENT;
@@ -2114,11 +2119,14 @@ static int copy_ring_size(struct intel_context *dst,
 static int clone_engines(struct i915_gem_context *dst,
 struct i915_gem_context *src)
 {
-   struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
-   struct i915_gem_engines *clone;
+   struct i915_gem_engines *clone, *e;
bool user_engines;
unsigned long n;
 
+   e = __context_engines_await(src, _engines);
+   if (!e)
+   return -ENOENT;
+
clone = alloc_engines(e->num_engines);
if (!clone)
goto err_unlock;
@@ -2160,9 +2168,7 @@ static int clone_engines(struct i915_gem_context *dst,
}
}
clone->num_engines = n;
-
-   user_engines = i915_gem_context_user_engines(src);
-   i915_gem_context_unlock_engines(src);
+   i915_sw_fence_complete(>fence);
 
/* Serialised by constructor */
engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
@@ -2173,7 +2179,7 @@ static int clone_engines(struct i915_gem_context *dst,
return 0;
 
 err_unlock:
-   i915_gem_context_unlock_engines(src);
+   i915_sw_fence_complete(>fence);
return -ENOMEM;
 }
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 07/21] drm/i915: Provide a fastpath for waiting on vma bindings

2020-07-30 Thread Chris Wilson
Before we can execute a request, we must wait for all of its vma to be
bound. This is a frequent operation for which we can optimise away a
few atomic operations (notably a cmpxchg) in lieu of the RCU protection.

Signed-off-by: Chris Wilson 
Reviewed-by: Thomas Hellström 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_active.h | 15 +++
 drivers/gpu/drm/i915/i915_vma.c|  9 +++--
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index b9e0394e2975..fb165d3f01cf 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -231,4 +231,19 @@ struct i915_active *i915_active_create(void);
 struct i915_active *i915_active_get(struct i915_active *ref);
 void i915_active_put(struct i915_active *ref);
 
+static inline int __i915_request_await_exclusive(struct i915_request *rq,
+struct i915_active *active)
+{
+   struct dma_fence *fence;
+   int err = 0;
+
+   fence = i915_active_fence_get(>excl);
+   if (fence) {
+   err = i915_request_await_dma_fence(rq, fence);
+   dma_fence_put(fence);
+   }
+
+   return err;
+}
+
 #endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bc64f773dcdb..cd12047c7791 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1167,6 +1167,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(>obj->userfault_link);
 }
 
+static int
+__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+   return __i915_request_await_exclusive(rq, >active);
+}
+
 int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request *rq)
 {
int err;
@@ -1174,8 +1180,7 @@ int __i915_vma_move_to_active(struct i915_vma *vma, 
struct i915_request *rq)
GEM_BUG_ON(!i915_vma_is_pinned(vma));
 
/* Wait for the vma to be bound before we start! */
-   err = i915_request_await_active(rq, >active,
-   I915_ACTIVE_AWAIT_EXCL);
+   err = __i915_request_await_bind(rq, vma);
if (err)
return err;
 
-- 
2.20.1

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


[Intel-gfx] [PATCH 17/21] drm/i915/gt: Protect context lifetime with RCU

2020-07-30 Thread Chris Wilson
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 330 +---
 drivers/gpu/drm/i915/i915_active.c  |  10 +
 drivers/gpu/drm/i915/i915_active.h  |   2 +
 drivers/gpu/drm/i915/i915_utils.h   |   7 +
 4 files changed, 202 insertions(+), 147 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..4e7924640ffa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -22,7 +22,7 @@ static struct i915_global_context {
 
 static struct intel_context *intel_context_alloc(void)
 {
-   return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+   return kmem_cache_alloc(global.slab_ce, GFP_KERNEL);
 }
 
 void intel_context_free(struct intel_context *ce)
@@ -30,6 +30,177 @@ void intel_context_free(struct intel_context *ce)
kmem_cache_free(global.slab_ce, ce);
 }
 
+static int __context_pin_state(struct i915_vma *vma)
+{
+   unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
+   int err;
+
+   err = i915_ggtt_pin(vma, 0, bias | PIN_HIGH);
+   if (err)
+   return err;
+
+   err = i915_active_acquire(>active);
+   if (err)
+   goto err_unpin;
+
+   /*
+* And mark it as a globally pinned object to let the shrinker know
+* it cannot reclaim the object until we release it.
+*/
+   i915_vma_make_unshrinkable(vma);
+   vma->obj->mm.dirty = true;
+
+   return 0;
+
+err_unpin:
+   i915_vma_unpin(vma);
+   return err;
+}
+
+static void __context_unpin_state(struct i915_vma *vma)
+{
+   i915_vma_make_shrinkable(vma);
+   i915_active_release(>active);
+   __i915_vma_unpin(vma);
+}
+
+static int __ring_active(struct intel_ring *ring)
+{
+   int err;
+
+   err = intel_ring_pin(ring);
+   if (err)
+   return err;
+
+   err = i915_active_acquire(>vma->active);
+   if (err)
+   goto err_pin;
+
+   return 0;
+
+err_pin:
+   intel_ring_unpin(ring);
+   return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+   i915_active_release(>vma->active);
+   intel_ring_unpin(ring);
+}
+
+__i915_active_call
+static void __intel_context_retire(struct i915_active *active)
+{
+   struct intel_context *ce = container_of(active, typeof(*ce), active);
+
+   CE_TRACE(ce, "retire runtime: { total:%lluns, avg:%lluns }\n",
+intel_context_get_total_runtime_ns(ce),
+intel_context_get_avg_runtime_ns(ce));
+
+   set_bit(CONTEXT_VALID_BIT, >flags);
+   if (ce->state)
+   __context_unpin_state(ce->state);
+
+   intel_timeline_unpin(ce->timeline);
+   __ring_retire(ce->ring);
+
+   intel_context_put(ce);
+}
+
+static int __intel_context_active(struct i915_active *active)
+{
+   struct intel_context *ce = container_of(active, typeof(*ce), active);
+   int err;
+
+   CE_TRACE(ce, "active\n");
+
+   intel_context_get(ce);
+
+   err = __ring_active(ce->ring);
+   if (err)
+   goto err_put;
+
+   err = intel_timeline_pin(ce->timeline);
+   if (err)
+   goto err_ring;
+
+   if (!ce->state)
+   return 0;
+
+   err = __context_pin_state(ce->state);
+   if (err)
+   goto err_timeline;
+
+   return 0;
+
+err_timeline:
+   intel_timeline_unpin(ce->timeline);
+err_ring:
+   __ring_retire(ce->ring);
+err_put:
+   intel_context_put(ce);
+   return err;
+}
+
+static void __intel_context_ctor(void *arg)
+{
+   struct intel_context *ce = arg;
+
+   INIT_LIST_HEAD(>signal_link);
+   INIT_LIST_HEAD(>signals);
+
+   atomic_set(>pin_count, 0);
+   mutex_init(>pin_mutex);
+
+   ce->active_count = 0;
+   i915_active_init(>active,
+__intel_context_active, __intel_context_retire);
+
+   ce->inflight = NULL;
+   ce->lrc_reg_state = NULL;
+   ce->lrc.desc = 0;
+}
+
+static void
+__intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
+{
+   GEM_BUG_ON(!engine->cops);
+   GEM_BUG_ON(!engine->gt->vm);
+
+   kref_init(>ref);
+   i915_active_reinit(>active);
+   mutex_reinit(>pin_mutex);
+
+   ce->engine = engine;
+   ce->ops = engine->cops;
+   ce->sseu = engine->sseu;
+
+   ce->wa_bb_page = 0;
+   ce->flags = 0;
+   ce->tag = 0;
+
+   memset(>runtime, 0, sizeof(ce->runtime));
+
+   

[Intel-gfx] [PATCH 20/21] drm/i915: Drop i915_request.lock requirement for intel_rps_boost()

2020-07-30 Thread Chris Wilson
Since we use a flag within i915_request.flags to indicate when we have
boosted the request (so that we only apply the boost) once, this can be
used as the serialisation with i915_request_retire() to avoid having to
explicitly take the i915_request.lock which is more heavily contended.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 15 ++-
 drivers/gpu/drm/i915/i915_request.c |  4 +---
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index e6a00eea0631..2a43e216e0d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -889,17 +889,15 @@ void intel_rps_park(struct intel_rps *rps)
 
 void intel_rps_boost(struct i915_request *rq)
 {
-   struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
-   unsigned long flags;
-
-   if (i915_request_signaled(rq) || !intel_rps_is_active(rps))
+   if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
return;
 
/* Serializes with i915_request_retire() */
-   spin_lock_irqsave(>lock, flags);
-   if (!i915_request_has_waitboost(rq) &&
-   !dma_fence_is_signaled_locked(>fence)) {
-   set_bit(I915_FENCE_FLAG_BOOST, >fence.flags);
+   if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, >fence.flags)) {
+   struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
+
+   if (!intel_rps_is_active(rps))
+   return;
 
GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",
 rq->fence.context, rq->fence.seqno);
@@ -910,7 +908,6 @@ void intel_rps_boost(struct i915_request *rq)
 
atomic_inc(>boosts);
}
-   spin_unlock_irqrestore(>lock, flags);
 }
 
 int intel_rps_set(struct intel_rps *rps, u8 val)
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 247e021203c2..43614d8fa18d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -306,10 +306,8 @@ bool i915_request_retire(struct i915_request *rq)
spin_unlock_irq(>lock);
}
 
-   if (i915_request_has_waitboost(rq)) {
-   GEM_BUG_ON(!atomic_read(>engine->gt->rps.num_waiters));
+   if (test_and_set_bit(I915_FENCE_FLAG_BOOST, >fence.flags))
atomic_dec(>engine->gt->rps.num_waiters);
-   }
 
/*
 * We only loosely track inflight requests across preemption,
-- 
2.20.1

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


[Intel-gfx] [CI] drm/i915/gem: Delay tracking the GEM context until it is registered

2020-07-30 Thread Chris Wilson
Avoid exposing a partially constructed context by deferring the
list_add() from the initial construction to the end of registration.
Otherwise, if we peek into the list of contexts from inside debugfs, we
may see the partially constructed context and chase down some dangling
incomplete pointers.

Reported-by: CQ Tang 
Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and 
registration to userspace")
References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by 
each context in debugfs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: CQ Tang 
Cc:  # v5.2+
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0bdb6d447ed..efc4ba34c06e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -713,6 +713,7 @@ __create_context(struct drm_i915_private *i915)
ctx->i915 = i915;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
mutex_init(>mutex);
+   INIT_LIST_HEAD(>link);
 
spin_lock_init(>stale.lock);
INIT_LIST_HEAD(>stale.engines);
@@ -740,10 +741,6 @@ __create_context(struct drm_i915_private *i915)
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
 
-   spin_lock(>gem.contexts.lock);
-   list_add_tail(>link, >gem.contexts.list);
-   spin_unlock(>gem.contexts.lock);
-
return ctx;
 
 err_free:
@@ -931,6 +928,7 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
 {
+   struct drm_i915_private *i915 = ctx->i915;
struct i915_address_space *vm;
int ret;
 
@@ -949,8 +947,16 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
if (ret)
-   put_pid(fetch_and_zero(>pid));
+   goto err_pid;
+
+   spin_lock(>gem.contexts.lock);
+   list_add_tail(>link, >gem.contexts.list);
+   spin_unlock(>gem.contexts.lock);
+
+   return 0;
 
+err_pid:
+   put_pid(fetch_and_zero(>pid));
return ret;
 }
 
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

2020-07-30 Thread Thierry Reding
On Wed, Jul 29, 2020 at 11:32:28AM +0200, Hans de Goede wrote:
> cHi,
> 
> On 7/29/20 10:23 AM, Andy Shevchenko wrote:
> > On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote:
> > > On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> > 
> > > I've applied patches 3 through 12 to the PWM tree. I thought it was a
> > > bit odd that only a handful of these patches had been reviewed and there
> > > were no Tested-bys, but I'm going to trust that you know what you're
> > > doing. =) If this breaks things for anyone I'm sure they'll complain.
> 
> Thank you for picking up these patches, but ...
> 
> > Can we postpone a bit?
> 
> I have to agree with Andy here, as mentioned my plan was to push the
> entire series through drm-intel-next-queued once the last few PWM
> patches are reviewed.
> 
> There are some fixes, to the pwm-crc driver which change behavior in
> a possibly undesirable way, unless combined with the i915 changes.
> 
> E.g. there is a fix which makes the pwm-crc driver actually honor
> the requested output frequency (it was not doing this due to a bug)
> and before the i915 changes, the i915 driver was hardcoding an output
> freq, rather then looking at the video-bios-tables as it should.
> 
> So having just the pwm-crc fix, will change the output frequency
> which some LCD panels might not like.
> 
> Note things are probably fine with the hardcoded output freq, but I
> would like to play it safe here.
> 
> Also Andy was still reviewing some of the PWM patches, and has requested
> changes to 1 patch, nothing functional just some code-reshuffling for
> cleaner code, so we could alternatively fix this up with a follow-up patch.
> 
> Either way please let us know how you want to proceed.

Okay, that's fine, I'll drop them again.

> > > That said I see that Rafael has acked patches 1-2 and Jani did so for
> > > patches 13-16. I'm not sure if you expect me to pick those patches up as
> > > well. As far as I can tell the ACPI, PWM and DRM parts are all
> > > independent, so these patches could be applied to the corresponding
> > > subsystem trees.
> > > 
> > > Anyway, if you want me to pick those all up into the PWM tree, I suppose
> > > that's something I can do as well.
> 
> drm-intel-next-queued is usually seeing quite a bit of churn, so the i915
> patches really should go upstream through that branch.

During my build tests I ran into a small issue caused by this series
interacting with the conversion of period and duty-cycle to u64 that
I've queued for v5.9. This causes a build failure on x86.

I have this local diff to fix that:

--- >8 ---
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 370ab826a20b..92e838797733 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -76,7 +76,9 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
if (pwm_get_duty_cycle(pwm) != state->duty_cycle ||
pwm_get_period(pwm) != state->period) {
-   int level = state->duty_cycle * PWM_MAX_LEVEL / state->period;
+   u64 level = state->duty_cycle * PWM_MAX_LEVEL;
+
+   do_div(level, state->period);
 
err = regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
if (err) {
@@ -141,10 +143,9 @@ static void crc_pwm_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
 
clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
 
-   state->period =
-   DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, PWM_BASE_CLK_MHZ);
-   state->duty_cycle =
-   DIV_ROUND_UP(duty_cycle_reg * state->period, PWM_MAX_LEVEL);
+   state->period = DIV_ROUND_UP(clk_div * NSEC_PER_USEC * 256, 
PWM_BASE_CLK_MHZ);
+   state->duty_cycle = duty_cycle_reg * state->period + PWM_MAX_LEVEL - 1;
+   do_div(state->duty_cycle, PWM_MAX_LEVEL);
state->polarity = PWM_POLARITY_NORMAL;
state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
 }
--- >8 ---

So perhaps you want to integrate that or something equivalent into your
series.

Also this could result in a tricky dependency between PWM and drm-misc,
although if you're targetting drm-misc it's too late for v5.9 anyway. In
that case you should be able to rebase your series on v5.9-rc1 when it's
out and then you'll get the prerequisite PWM changes for the u64
conversion as part of that. No need to track the dependency explicitly.

Thierry


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


Re: [Intel-gfx] [PATCH 6/6] drm/i915/perf: Map OA buffer to user space for gen12 performance query

2020-07-30 Thread Chris Wilson
Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:26)
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 00546062e023..36f6b9799ecd 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2048,6 +2048,22 @@ struct drm_i915_perf_open_param {
>   */
>  #define I915_PERF_IOCTL_CONFIG _IO('i', 0x2)
>  
> +/**
> + * Returns OA buffer properties to be used with mmap.
> + *
> + * This ioctl is available in perf revision 8.
> + */
> +#define I915_PERF_IOCTL_GET_OA_BUFFER_INFO _IO('i', 0x3)

This should be _IORW iirc.

> +
> +/**
> + * OA buffer size and offset.
> + */
> +struct drm_i915_perf_oa_buffer_info {
> +   __u32 size;
> +   __u32 offset;
> +   __u64 reserved[4];

5xu64? Might as well just trim it to 4xu64. Unless you have a reason for
a large reserved, we can always extend the struct later (or replace it
with a new ioctl).

However, I would suggest {
u32 type;  /* in */
u32 flags; /* in */
u64 size;   /* out */
u64 offset; /* out */
u64 rsvd; /* mbz */
};

Oh, and don't forget to check all unused members are 0.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 6/6] drm/i915/perf: Map OA buffer to user space for gen12 performance query

2020-07-30 Thread Chris Wilson
Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:26)
> @@ -3318,12 +3354,87 @@ static int i915_perf_release(struct inode *inode, 
> struct file *file)
> i915_perf_destroy_locked(stream);
> mutex_unlock(>lock);
>  
> +   /*
> +* User could have multiple vmas from multiple mmaps. We want to zap
> +* them all here.
> +*/
> +   unmap_mapping_range(file->f_mapping, 0, -1, 1);

I'd prefer to explicitly revoke the mapping before removing the
stream->oa_buffer (i.e. at the start of the release before
i915_perf_destroy). That way it takes far less thought to convince
oneself that there is no window for accessing the stale PTE. Include a
comment to explain that a fresh fault cannot occur as the mmap holds a
reference to the stream (via the vma->vm_file), and so before the user's
munmap, the stream cannot be destroy.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/6] drm/i915/perf: Whitelist OA report trigger registers

2020-07-30 Thread Chris Wilson
Quoting Umesh Nerlige Ramappa (2020-07-30 01:48:24)
> +void intel_engine_apply_oa_whitelist(struct intel_engine_cs *engine)
> +{
> +   struct i915_wa_list *w = >whitelist;
> +   struct drm_i915_private *i915 = engine->i915;
> +
> +   if (IS_GEN(i915, 12))
> +   whitelist_build_perf_counters(w, gen12_oa_regs,
> + ARRAY_SIZE(gen12_oa_regs));
> +   else if (INTEL_GEN(i915) > 8)
> +   whitelist_build_perf_counters(w, gen9_oa_regs,
> + ARRAY_SIZE(gen9_oa_regs));
> +   else
> +   return;
> +
> +   intel_engine_apply_whitelist(engine);
> +}
> +
> +void intel_engine_remove_oa_whitelist(struct intel_engine_cs *engine)
> +{
> +   struct i915_wa_list *w = >whitelist;
> +   struct drm_i915_private *i915 = engine->i915;
> +
> +   if (IS_GEN(i915, 12))
> +   whitelist_delete_perf_counters(w, gen12_oa_regs,
> +  ARRAY_SIZE(gen12_oa_regs));
> +   else if (INTEL_GEN(i915) > 8)
> +   whitelist_delete_perf_counters(w, gen9_oa_regs,
> +  ARRAY_SIZE(gen9_oa_regs));
> +   else
> +   return;

Keep the oa_regs in i915_perf, and make this pair of functions that
touch more generic by

intel_engine_add_whitelist(engine, i915_reg_t *reg, size_t count);

Hmm. The other can of worms would be to call it
intel_engine_allow_user_register_access()
intel_engine_deny_user_register_access()
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/display: Check for an LPSP encoder before dereferencing

2020-07-30 Thread Anshuman Gupta
On 2020-07-29 at 14:09:12 +0100, Chris Wilson wrote:
> Avoid a GPF at
> 
> <1>[   20.177320] BUG: kernel NULL pointer dereference, address: 
> 007c
> <1>[   20.177322] #PF: supervisor read access in kernel mode
> <1>[   20.177323] #PF: error_code(0x) - not-present page
> <6>[   20.177324] PGD 0 P4D 0
> <4>[   20.177327] Oops:  [#1] PREEMPT SMP PTI
> <4>[   20.177328] CPU: 1 PID: 944 Comm: debugfs_test Not tainted 
> 5.8.0-rc7-CI-CI_DRM_8814+ #1
> <4>[   20.177330] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 
> 07/09/2018
> <4>[   20.177372] RIP: 0010:i915_lpsp_capability_show+0x44/0xc0 [i915]
> <4>[   20.177374] Code: 0f b6 81 ca 0d 00 00 3c 0b 74 77 76 19 3c 0c 75 44 83 
> 7e 7c 01 7e 2f 48 c7 c6 d7 b9 47 a0 e8 43 df 06 e1 31 c0 c3 3c 09 72 2b <8b> 
> 46 7c 85 c0 75 e6 8b 82 e4 00 00 00 89 c2 83 e2 fb 83 fa 0a 74
> <4>[   20.177376] RSP: 0018:c9cebe38 EFLAGS: 00010246
> <4>[   20.177377] RAX: 0009 RBX: 888267fe6a58 RCX: 
> 888252d1
> <4>[   20.177378] RDX: 88824a9a4000 RSI:  RDI: 
> 888267fe6a30
> <4>[   20.177379] RBP:  R08:  R09: 
> 0001
> <4>[   20.177380] R10: 0001 R11:  R12: 
> c9cebf08
> <4>[   20.177381] R13:  R14: 0001 R15: 
> 888267fe6a30
> <4>[   20.177383] FS:  7f6f9c6b5e40() GS:88827648() 
> knlGS:
> <4>[   20.177384] CS:  0010 DS:  ES:  CR0: 80050033
> <4>[   20.177385] CR2: 007c CR3: 000255f04006 CR4: 
> 003606e0
> <4>[   20.177386] Call Trace:
> <4>[   20.177390]  seq_read+0xcb/0x420
> 
> which is presumably from having no encoder attached at that time.
> 
> Fixes: 8806211fe7b3 ("drm/i915: Add i915_lpsp_capability debugfs")
> Signed-off-by: Chris Wilson 
> Cc: Animesh Manna 
> Cc: Anshuman Gupta 
> Cc: Uma Shankar 
> Cc: "Ville Syrjälä" 
Reviewed-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 3644752cc5ec..5a5cfe25085b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2044,9 +2044,12 @@ DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
>  static int i915_lpsp_capability_show(struct seq_file *m, void *data)
>  {
>   struct drm_connector *connector = m->private;
> - struct intel_encoder *encoder =
> - intel_attached_encoder(to_intel_connector(connector));
>   struct drm_i915_private *i915 = to_i915(connector->dev);
> + struct intel_encoder *encoder;
> +
> + encoder = intel_attached_encoder(to_intel_connector(connector));
> + if (!encoder)
> + return -ENODEV;
>  
>   if (connector->status != connector_status_connected)
>   return -ENODEV;
> -- 
> 2.20.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Avoid modeset when content protection changes

2020-07-30 Thread Anshuman Gupta
On 2020-07-14 at 21:36:27 +0530, Sean Paul wrote:
> From: Sean Paul 
> 
> Instead of doing a full modeset to enable/disable content protection,
> simply go through the update_pipe flow which was introduced in the
> related patch below. This avoids flashing the screen every time the user
> starts viewing protected content.
> 
> Related: 634852d1f468 ("drm/i915: HDCP state handling in ddi_update_pipe")
> Cc: Ramalingam C 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 89a4d294822d..839ce1715253 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2191,7 +2191,7 @@ void intel_hdcp_atomic_check(struct drm_connector 
> *connector,
>   return;
>   }
>  
> - crtc_state->mode_changed = true;
> + to_intel_crtc_state(crtc_state)->update_pipe = true;
IMHO intel_crtc_check_fastset() make sure that every crtc_state->mode_changed
will not turn up to a modeset. It seems it is already being taken care.

Thanks,
Anshuman Gupta.

>  }
>  
>  /* Handles the CP_IRQ raised from the DP HDCP sink */
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 
> ___
> 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