[Intel-gfx] ✓ Fi.CI.IGT: success for Another small batch of reviewed Xe_LPD patches

[Patchwork]

== Series Details ==

Series: Another small batch of reviewed Xe_LPD patches
URL   : https://patchwork.freedesktop.org/series/90560/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20194_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][1] ([i915#3002])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-snb2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][5] ([i915#3354])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-snb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@full:
- shard-glk:  [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk8/igt@gem_exec_balan...@full.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-glk9/igt@gem_exec_balan...@full.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb6/igt@gem_exec_fair@basic-p...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-tglb5/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][12] -> [SKIP][13] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#2389])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#307])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-skl3/igt@gem_mmap_...@big-copy-xy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-skl1/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-apl:  [PASS][19] -> [INCOMPLETE][20] ([i915#3468])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-apl1/igt@gem_mmap_...@cpuset-basic-small-copy.html
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#3468])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb6/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-skl:  NOTRUN -> [INCOMPLETE][23] ([i915#198] / [i915#2910])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
- shard-kbl:  [PASS][24] -> [INCOMPLETE][25] ([i915#3468])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-kbl1/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html
   [25]: 

[Intel-gfx] [PATCH V2 0/1] drm/i915/gt: Introduce timeslicing for userspace

[Tejas Upadhyay]

Test-with: 20210524124806.241439-1-tejaskumarx.surendrakumar.upadh...@intel.com

Tejas Upadhyay (1):
  drm/i915/gt: Declare when we enabled timeslicing

 drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 2 insertions(+)

-- 
2.31.1

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

[Intel-gfx] [PATCH V2 1/1] drm/i915/gt: Declare when we enabled timeslicing

[Tejas Upadhyay]

Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

V3: %s/TIMESLICE_BIT/HAS_TIMESLICES

v2: Only declare timeslicing if we can safely preempt userspace.

Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 3cca7ea2d6ea..5123cc02efdb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+   MAP(HAS_TIMESLICES, TIMESLICING),
 #undef MAP
};
struct intel_engine_cs *engine;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c2c7759b7d2e..af2212d6113c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -572,6 +572,7 @@ typedef struct drm_i915_irq_wait {
 #define   I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
 #define   I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
 #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define   I915_SCHEDULER_CAP_TIMESLICING   (1ul << 5)
 
 #define I915_PARAM_HUC_STATUS   42
 
-- 
2.31.1

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: Add an API for exporting sync files (v11)

[Patchwork]

== Series Details ==

Series: dma-buf: Add an API for exporting sync files (v11)
URL   : https://patchwork.freedesktop.org/series/90555/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20193_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * {igt@dmabuf_sync_file@import-basic} (NEW):
- shard-iclb: NOTRUN -> [INCOMPLETE][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-iclb1/igt@dmabuf_sync_f...@import-basic.html
- shard-skl:  NOTRUN -> [INCOMPLETE][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-skl10/igt@dmabuf_sync_f...@import-basic.html
- shard-tglb: NOTRUN -> [INCOMPLETE][3] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-tglb8/igt@dmabuf_sync_f...@import-basic.html
- shard-kbl:  NOTRUN -> [INCOMPLETE][4] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-kbl7/igt@dmabuf_sync_f...@import-basic.html

  * {igt@dmabuf_sync_file@import-existing-exclusive} (NEW):
- shard-glk:  NOTRUN -> [INCOMPLETE][5] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-glk5/igt@dmabuf_sync_f...@import-existing-exclusive.html
- shard-snb:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-snb5/igt@dmabuf_sync_f...@import-existing-exclusive.html

  * igt@kms_big_fb@yf-tiled-32bpp-rotate-180:
- shard-glk:  [PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk2/igt@kms_big...@yf-tiled-32bpp-rotate-180.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-glk6/igt@kms_big...@yf-tiled-32bpp-rotate-180.html

  
New tests
-

  New tests have been introduced between CI_DRM_10133_full and 
Patchwork_20193_full:

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

  * igt@dmabuf_sync_file@export-basic:
- Statuses : 6 pass(s)
- Exec time: [0.00, 0.01] s

  * igt@dmabuf_sync_file@export-before-signal:
- Statuses : 7 pass(s)
- Exec time: [0.00, 0.02] s

  * igt@dmabuf_sync_file@export-multiwait:
- Statuses : 6 pass(s)
- Exec time: [0.00, 0.01] s

  * igt@dmabuf_sync_file@export-wait-after-attach:
- Statuses : 5 pass(s)
- Exec time: [0.00, 0.01] s

  * igt@dmabuf_sync_file@import-basic:
- Statuses : 5 incomplete(s)
- Exec time: [0.0] s

  * igt@dmabuf_sync_file@import-existing-exclusive:
- Statuses : 6 incomplete(s)
- Exec time: [0.0] s

  * igt@dmabuf_sync_file@import-existing-shared-1:
- Statuses : 6 pass(s)
- Exec time: [0.00, 0.02] s

  * igt@dmabuf_sync_file@import-existing-shared-32:
- Statuses : 6 pass(s)
- Exec time: [0.01, 0.13] s

  * igt@dmabuf_sync_file@import-existing-shared-5:
- Statuses : 5 pass(s)
- Exec time: [0.00, 0.01] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-kbl:  NOTRUN -> [DMESG-WARN][9] ([i915#2283])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-kbl3/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][10] ([i915#3002])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-snb2/igt@gem_cre...@create-massive.html
- shard-apl:  NOTRUN -> [DMESG-WARN][11] ([i915#3002])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-apl7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2410])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN 

[Intel-gfx] ✗ Fi.CI.IGT: failure for Non-interface changing GuC CTBs updates

[Patchwork]

== Series Details ==

Series: Non-interface changing GuC CTBs updates
URL   : https://patchwork.freedesktop.org/series/90552/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10133_full -> Patchwork_20192_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@suspend:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb2/igt@gem_...@suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-tglb8/igt@gem_...@suspend.html

  * igt@gem_eio@wait-1us:
- shard-glk:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk6/igt@gem_...@wait-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-glk1/igt@gem_...@wait-1us.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#1888] / [i915#3160])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk6/igt@gem_cre...@create-clear.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-glk1/igt@gem_cre...@create-clear.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][7] ([i915#3002])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-snb5/igt@gem_cre...@create-massive.html
- shard-apl:  NOTRUN -> [DMESG-WARN][8] ([i915#3002])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-apl3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_eio@in-flight-suspend:
- shard-tglb: [PASS][10] -> [DMESG-WARN][11] ([i915#2411]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb7/igt@gem_...@in-flight-suspend.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-tglb3/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#2369] / 
[i915#3063])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb5/igt@gem_...@unwedge-stress.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-tglb6/igt@gem_...@unwedge-stress.html
- shard-skl:  [PASS][14] -> [TIMEOUT][15] ([i915#2369] / 
[i915#3063])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-skl3/igt@gem_...@unwedge-stress.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-skl3/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][16] -> [TIMEOUT][17] ([i915#2369] / 
[i915#2481] / [i915#3070])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-iclb1/igt@gem_...@unwedge-stress.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][20] -> [FAIL][21] ([i915#2842]) +1 similar 
issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][22] ([i915#2389])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][23] -> [SKIP][24] ([i915#2190])
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for Another small batch of reviewed Xe_LPD patches

[Patchwork]

== Series Details ==

Series: Another small batch of reviewed Xe_LPD patches
URL   : https://patchwork.freedesktop.org/series/90560/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20194


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][1] ([i915#49]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-glk-dsi: [FAIL][3] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][4] ([i915#3363] / [k.org#202321])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-glk-dsi/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][5] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][6] ([i915#1436] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-kbl-soraka/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20194/fi-kbl-soraka/igt@run...@aborted.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
  [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (45 -> 41)
--

  Additional (1): fi-rkl-11500t 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10133 -> Patchwork_20194

  CI-20190529: 20190529
  CI_DRM_10133: 79cace2bbe3bb9cbff1aa14428adea42072b56b0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6092: d87087c321da07035d4f96d98c34e451b3ccb809 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20194: f918a8cdebdb95f8e26f12600e79e62b4cc805a8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f918a8cdebdb drm/i915/display: Remove a redundant function argument from 
intel_psr_enable_source()
1a22f3f8ec72 drm/i915/xelpd: Add VRR guardband for VRR CTL
6973fd1b00ee drm/i915/xelpd: Enhanced pipe underrun reporting

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Add relocation exceptions for two other platforms

[Dave Airlie]

On Wed, 12 May 2021 at 03:05, Daniel Vetter  wrote:
>
> On Tue, May 11, 2021 at 10:31:39AM +0200, Zbigniew Kempczyński wrote:
> > We have established previously we stop using relocations starting
> > from gen12 platforms with Tigerlake as an exception. Unfortunately
> > we need extend transition period and support relocations for two
> > other igfx platforms - Rocketlake and Alderlake.
> >
> > Signed-off-by: Zbigniew Kempczyński 
> > Cc: Dave Airlie 
> > Cc: Daniel Vetter 
> > Cc: Jason Ekstrand 
>
> So the annoying thing here is that now media-driver is fixed:
>
> https://github.com/intel/media-driver/commit/144020c37770083974bedf59902b70b8f444c799
>
> Which means igt is really the only thing left.
>
> Dave, is this still ok for an acked exception, or is this now leaning
> towards "just fix igt"?

Oh that isn't great is it, I had thought it was the media-driver,
keeping a big uAPI like this open just for the test code seems a bit
silly. I get the tests are testing more than just relocs, but it's a
pretty big interface to leave lying around if we can avoid it.

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Another small batch of reviewed Xe_LPD patches

[Patchwork]

== Series Details ==

Series: Another small batch of reviewed Xe_LPD patches
URL   : https://patchwork.freedesktop.org/series/90560/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1328:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Another small batch of reviewed Xe_LPD patches

[Patchwork]

== Series Details ==

Series: Another small batch of reviewed Xe_LPD patches
URL   : https://patchwork.freedesktop.org/series/90560/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6973fd1b00ee drm/i915/xelpd: Enhanced pipe underrun reporting
1a22f3f8ec72 drm/i915/xelpd: Add VRR guardband for VRR CTL
-:191: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#191: FILE: drivers/gpu/drm/i915/i915_reg.h:4389:
+#define  XELPD_VRR_CTL_VRR_GUARDBAND(x)
REG_FIELD_PREP(XELPD_VRR_CTL_VRR_GUARDBAND_MASK, (x))

total: 0 errors, 1 warnings, 0 checks, 142 lines checked
f918a8cdebdb drm/i915/display: Remove a redundant function argument from 
intel_psr_enable_source()


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

[Intel-gfx] [CI 1/3] drm/i915/xelpd: Enhanced pipe underrun reporting

[Matt Roper]

XE_LPD brings enhanced underrun recovery:  the hardware can somewhat
mitigate underruns by using an interpolated replacement pixel (soft
underrun) or the previous pixel (hard underrun).  Furthermore, underruns
can now be caused downstream by the port, even if the pipe itself is
operating properly.  The interrupt register and PIPE_STATUS register
give us extra bits to recognize hard/soft underruns and determine
whether the underrun was caused by the port, so we'll use that
information to print some more descriptive errors when underruns occur.

v2:
 - Keep ICL's PIPE_STATUS defined separately from the old GMCH pipe
   status register.  (Ville)
 - Only read/clear the PIPE_STATUS register on platforms with
   display ver >= 11. (Lucas)
v3:
 - Actually enable+unmask all the new underrun interrupts, clear stale
   bits out from PIPE_STATUS before enabling the interrupts, report all
   FIFO underruns errors at once, rename a bunch of stuff to unconfuse
   vs. PIPESTAT. (Ville)

Bspec: 50335
Bspec: 50366
Cc: Lucas De Marchi 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Stanislav Lisovskiy 
---
 .../drm/i915/display/intel_fifo_underrun.c| 57 +--
 drivers/gpu/drm/i915/i915_irq.c   | 19 ++-
 drivers/gpu/drm/i915/i915_irq.h   |  1 +
 drivers/gpu/drm/i915/i915_reg.h   |  9 +++
 4 files changed, 77 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
index 3315aa1d4d5a..eb841960840d 100644
--- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
@@ -185,15 +185,34 @@ static void ivb_set_fifo_underrun_reporting(struct 
drm_device *dev,
}
 }
 
+static u32
+icl_pipe_status_underrun_mask(struct drm_i915_private *dev_priv)
+{
+   u32 mask = PIPE_STATUS_UNDERRUN;
+
+   if (DISPLAY_VER(dev_priv) >= 13)
+   mask |= PIPE_STATUS_SOFT_UNDERRUN_XELPD |
+   PIPE_STATUS_HARD_UNDERRUN_XELPD |
+   PIPE_STATUS_PORT_UNDERRUN_XELPD;
+
+   return mask;
+}
+
 static void bdw_set_fifo_underrun_reporting(struct drm_device *dev,
enum pipe pipe, bool enable)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   u32 mask = gen8_de_pipe_underrun_mask(dev_priv);
 
-   if (enable)
-   bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_FIFO_UNDERRUN);
-   else
-   bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_FIFO_UNDERRUN);
+   if (enable) {
+   if (DISPLAY_VER(dev_priv) >= 11)
+   intel_de_write(dev_priv, ICL_PIPESTATUS(pipe),
+  icl_pipe_status_underrun_mask(dev_priv));
+
+   bdw_enable_pipe_irq(dev_priv, pipe, mask);
+   } else {
+   bdw_disable_pipe_irq(dev_priv, pipe, mask);
+   }
 }
 
 static void ibx_set_fifo_underrun_reporting(struct drm_device *dev,
@@ -373,6 +392,7 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 enum pipe pipe)
 {
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+   u32 underruns = 0;
 
/* We may be called too early in init, thanks BIOS! */
if (crtc == NULL)
@@ -383,10 +403,35 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
crtc->cpu_fifo_underrun_disabled)
return;
 
+   /*
+* Starting with display version 11, the PIPE_STAT register records
+* whether an underrun has happened, and on XELPD+, it will also record
+* whether the underrun was soft/hard and whether it was triggered by
+* the downstream port logic.  We should clear these bits (which use
+* write-1-to-clear logic) too.
+*
+* Note that although the IIR gives us the same underrun and soft/hard
+* information, PIPE_STAT is the only place we can find out whether
+* the underrun was caused by the downstream port.
+*/
+   if (DISPLAY_VER(dev_priv) >= 11) {
+   underruns = intel_de_read(dev_priv, ICL_PIPESTATUS(pipe)) &
+   icl_pipe_status_underrun_mask(dev_priv);
+   intel_de_write(dev_priv, ICL_PIPESTATUS(pipe), underruns);
+   }
+
if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false)) {
trace_intel_cpu_fifo_underrun(dev_priv, pipe);
-   drm_err(_priv->drm, "CPU pipe %c FIFO underrun\n",
-   pipe_name(pipe));
+
+   if (DISPLAY_VER(dev_priv) >= 11)
+   drm_err(_priv->drm, "CPU pipe %c FIFO underrun: 
%s%s%s%s\n",
+   pipe_name(pipe),
+   underruns & PIPE_STATUS_SOFT_UNDERRUN_XELPD ? 
"soft," : "",
+   

[Intel-gfx] [CI 2/3] drm/i915/xelpd: Add VRR guardband for VRR CTL

[Matt Roper]

From: Manasi Navare 

On XE_LPD, VRR CTL register adds a new VRR Guardband bitfield
replacing the pipeline full and deprecating the pipeline override
bit.

This patch adds this corresponding bitfield in the register defs,
crtc state vrr structure and populates this in vrr compute
config and vrr enable functions. It also adds the corresponding
HW state readout for this field.

Bspec: 50508
Cc: Aditya Swarup 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
Signed-off-by: Matt Roper 
Reviewed-by: Aditya Swarup 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  8 ++-
 .../drm/i915/display/intel_display_types.h|  2 +-
 drivers/gpu/drm/i915/display/intel_vrr.c  | 58 +--
 drivers/gpu/drm/i915/i915_drv.h   |  3 +
 drivers/gpu/drm/i915/i915_reg.h   |  2 +
 5 files changed, 53 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0bb2e582c87f..d1ee95512282 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7654,10 +7654,11 @@ static void intel_dump_pipe_config(const struct 
intel_crtc_state *pipe_config,
intel_hdmi_infoframe_enable(DP_SDP_VSC))
intel_dump_dp_vsc_sdp(dev_priv, _config->infoframes.vsc);
 
-   drm_dbg_kms(_priv->drm, "vrr: %s, vmin: %d, vmax: %d, pipeline 
full: %d, flipline: %d, vmin vblank: %d, vmax vblank: %d\n",
+   drm_dbg_kms(_priv->drm, "vrr: %s, vmin: %d, vmax: %d, pipeline 
full: %d, guardband: %d flipline: %d, vmin vblank: %d, vmax vblank: %d\n",
yesno(pipe_config->vrr.enable),
pipe_config->vrr.vmin, pipe_config->vrr.vmax,
-   pipe_config->vrr.pipeline_full, pipe_config->vrr.flipline,
+   pipe_config->vrr.pipeline_full, pipe_config->vrr.guardband,
+   pipe_config->vrr.flipline,
intel_vrr_vmin_vblank_start(pipe_config),
intel_vrr_vmax_vblank_start(pipe_config));
 
@@ -8663,6 +8664,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(vrr.vmax);
PIPE_CONF_CHECK_I(vrr.flipline);
PIPE_CONF_CHECK_I(vrr.pipeline_full);
+   PIPE_CONF_CHECK_I(vrr.guardband);
 
PIPE_CONF_CHECK_BOOL(has_psr);
PIPE_CONF_CHECK_BOOL(has_psr2);
@@ -12265,6 +12267,8 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
 
i915->framestart_delay = 1; /* 1-4 */
 
+   i915->window2_delay = 0; /* No DSB so no window2 delay */
+
intel_mode_config_init(i915);
 
ret = intel_cdclk_init(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce05475ad560..b8d1f702d808 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1202,7 +1202,7 @@ struct intel_crtc_state {
struct {
bool enable;
u8 pipeline_full;
-   u16 flipline, vmin, vmax;
+   u16 flipline, vmin, vmax, guardband;
} vrr;
 
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 046210ae1de0..c335b1dbafcf 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -68,7 +68,10 @@ static int intel_vrr_vblank_exit_length(const struct 
intel_crtc_state *crtc_stat
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
 
/* The hw imposes the extra scanline before frame start */
-   return crtc_state->vrr.pipeline_full + i915->framestart_delay + 1;
+   if (DISPLAY_VER(i915) >= 13)
+   return crtc_state->vrr.guardband + i915->framestart_delay + 1;
+   else
+   return crtc_state->vrr.pipeline_full + i915->framestart_delay + 
1;
 }
 
 int intel_vrr_vmin_vblank_start(const struct intel_crtc_state *crtc_state)
@@ -86,6 +89,8 @@ void
 intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
 struct drm_connector_state *conn_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
@@ -124,17 +129,26 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
 
/*
-* FIXME: s/4/framestart_delay+1/ to get consistent
-* earliest/latest points for register latching regardless
-* of the framestart_delay used?
-*
-* FIXME: this really needs the extra scanline to provide consistent
-* behaviour for 

[Intel-gfx] [CI 3/3] drm/i915/display: Remove a redundant function argument from intel_psr_enable_source()

[Matt Roper]

From: Gwan-gyeong Mun 

It removes intel_crtc_state from function argument of
intel_psr_enable_source() in order to use intel_psr_enable_source()
without intel_crtc_state on other psr internal functions.
And we can get cpu_trancoder from intel_psr, therefore we don't need to
pass intel_crtc_state to this function.

Cc: José Roberto de Souza 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Matt Roper 
Reviewed-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 1b27af872ba1..000e1ffe8c05 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -990,11 +990,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
intel_dp->psr.active = true;
 }
 
-static void intel_psr_enable_source(struct intel_dp *intel_dp,
-   const struct intel_crtc_state *crtc_state)
+static void intel_psr_enable_source(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
u32 mask;
 
/* Only HSW and BDW have PSR AUX registers that need to be setup. SKL+
@@ -1112,7 +,7 @@ static void intel_psr_enable_locked(struct intel_dp 
*intel_dp,
 _dp->psr.vsc);
intel_write_dp_vsc_sdp(encoder, crtc_state, _dp->psr.vsc);
intel_psr_enable_sink(intel_dp);
-   intel_psr_enable_source(intel_dp, crtc_state);
+   intel_psr_enable_source(intel_dp);
intel_dp->psr.enabled = true;
 
intel_psr_activate(intel_dp);
-- 
2.25.4

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

[Intel-gfx] [CI 0/3] Another small batch of reviewed Xe_LPD patches

[Matt Roper]

Another small collection of Xe_LPD patches that have r-b's now and just
need another CI pass to merge.

Gwan-gyeong Mun (1):
  drm/i915/display: Remove a redundant function argument from
intel_psr_enable_source()

Manasi Navare (1):
  drm/i915/xelpd: Add VRR guardband for VRR CTL

Matt Roper (1):
  drm/i915/xelpd: Enhanced pipe underrun reporting

 drivers/gpu/drm/i915/display/intel_display.c  |  8 ++-
 .../drm/i915/display/intel_display_types.h|  2 +-
 .../drm/i915/display/intel_fifo_underrun.c| 57 --
 drivers/gpu/drm/i915/display/intel_psr.c  |  7 +--
 drivers/gpu/drm/i915/display/intel_vrr.c  | 58 +--
 drivers/gpu/drm/i915/i915_drv.h   |  3 +
 drivers/gpu/drm/i915/i915_irq.c   | 19 +-
 drivers/gpu/drm/i915/i915_irq.h   |  1 +
 drivers/gpu/drm/i915/i915_reg.h   | 11 
 9 files changed, 133 insertions(+), 33 deletions(-)

-- 
2.25.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: Check HDMI sink deep color capabilities during .mode_valid() (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Check HDMI sink deep color capabilities during .mode_valid() 
(rev3)
URL   : https://patchwork.freedesktop.org/series/90036/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10132_full -> Patchwork_20191_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-tglb7/igt@kms_plane_multi...@atomic-pipe-c-tiling-y.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-tglb6/igt@kms_plane_multi...@atomic-pipe-c-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-iclb2/igt@feature_discov...@psr2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-iclb8/igt@feature_discov...@psr2.html

  * igt@gem_create@create-clear:
- shard-skl:  [PASS][5] -> [FAIL][6] ([i915#3160])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-skl10/igt@gem_cre...@create-clear.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-skl9/igt@gem_cre...@create-clear.html

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][7] ([i915#3002])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-skl8/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +9 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][9] ([i915#3354])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-snb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +4 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][12] -> [SKIP][13] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-skl8/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-apl:  NOTRUN -> [INCOMPLETE][15] ([i915#3468]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-apl1/igt@gem_mmap_...@cpuset-basic-small-copy.html
- shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#3468])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-tglb3/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-glk:  NOTRUN -> [INCOMPLETE][18] ([i915#2055] / [i915#3468])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-glk1/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
- shard-iclb: NOTRUN -> [INCOMPLETE][19] ([i915#3468])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/shard-iclb4/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-xy:
- shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([i915#3468] / 
[i915#750])
   [20]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Add an API for exporting sync files (v11)

[Patchwork]

== Series Details ==

Series: dma-buf: Add an API for exporting sync files (v11)
URL   : https://patchwork.freedesktop.org/series/90555/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20193


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([i915#1372])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][5] ([fdo#109271]) +5 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][6] ([i915#49]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-glk-dsi: [FAIL][8] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][9] ([i915#3363] / [k.org#202321])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-glk-dsi/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][10] ([i915#1602] / [i915#2029]) -> [FAIL][11] 
([i915#3462])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-bdw-5557u/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-bdw-5557u/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][12] ([i915#2082] / [i915#2426] / [i915#3363] / 
[i915#3462]) -> [FAIL][13] ([i915#3363] / [i915#3462])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-cml-u2/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20193/fi-cml-u2/igt@run...@aborted.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
  [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (45 -> 41)
--

  Additional (1): 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/90164/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10132_full -> Patchwork_20190_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-iclb2/igt@feature_discov...@psr2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-iclb1/igt@feature_discov...@psr2.html

  * igt@gem_create@create-massive:
- shard-skl:  NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-skl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-snb5/igt@gem_ctx_persiste...@engines-mixed-process.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_ctx_ringsize@plugged@vcs0:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-glk4/igt@gem_ctx_ringsize@plug...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-glk6/igt@gem_ctx_ringsize@plug...@vcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) +3 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@no-bsd:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-iclb6/igt@gem_exec_par...@no-bsd.html

  * igt@gem_huc_copy@huc-copy:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-skl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-apl:  NOTRUN -> [INCOMPLETE][15] ([i915#3468]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-apl2/igt@gem_mmap_...@cpuset-basic-small-copy.html
- shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#3468])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-tglb5/igt@gem_mmap_...@cpuset-basic-small-copy.html
- shard-kbl:  [PASS][18] -> [INCOMPLETE][19] ([i915#3468])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-kbl7/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-glk:  NOTRUN -> [INCOMPLETE][20] ([i915#2055] / [i915#3468])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-glk2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
- shard-iclb: NOTRUN -> [FAIL][21] ([i915#2428])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-glk:  [PASS][22] -> [FAIL][23] ([i915#307])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/shard-glk2/igt@gem_mmap_...@cpuset-medium-copy-odd.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/shard-glk3/igt@gem_mmap_...@cpuset-medium-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-xy:
- 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-buf: Add an API for exporting sync files (v11)

[Patchwork]

== Series Details ==

Series: dma-buf: Add an API for exporting sync files (v11)
URL   : https://patchwork.freedesktop.org/series/90555/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Add an API for exporting sync files (v11)

[Patchwork]

== Series Details ==

Series: dma-buf: Add an API for exporting sync files (v11)
URL   : https://patchwork.freedesktop.org/series/90555/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
225a57e84149 dma-buf: Add dma_fence_array_for_each (v2)
-:75: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fence' - possible 
side-effects?
#75: FILE: include/linux/dma-fence-array.h:86:
+#define dma_fence_array_for_each(fence, index, head)   \
+   for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))

-:75: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible 
side-effects?
#75: FILE: include/linux/dma-fence-array.h:86:
+#define dma_fence_array_for_each(fence, index, head)   \
+   for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))

-:75: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'head' - possible 
side-effects?
#75: FILE: include/linux/dma-fence-array.h:86:
+#define dma_fence_array_for_each(fence, index, head)   \
+   for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))

-:90: ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author '"Christian König" '

total: 1 errors, 0 warnings, 3 checks, 57 lines checked
a26f8ef33498 dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
-:68: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int *' to bare use of 'unsigned 
*'
#68: FILE: drivers/dma-buf/dma-resv.c:434:
+unsigned *pshared_count,

-:821: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int *' to bare use of 
'unsigned *'
#821: FILE: include/linux/dma-resv.h:283:
+unsigned *pshared_count,

total: 0 errors, 2 warnings, 0 checks, 601 lines checked
8f674ac01f2f dma-buf: Add dma_resv_get_singleton_unlocked (v5)
-:63: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#63: FILE: drivers/dma-buf/dma-resv.c:55:
+#define dma_fence_deep_dive_for_each(fence, chain, index, head)\
+   dma_fence_chain_for_each(chain, head)   \
+   dma_fence_array_for_each(fence, index, chain)

-:63: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'chain' - possible 
side-effects?
#63: FILE: drivers/dma-buf/dma-resv.c:55:
+#define dma_fence_deep_dive_for_each(fence, chain, index, head)\
+   dma_fence_chain_for_each(chain, head)   \
+   dma_fence_array_for_each(fence, index, chain)

-:117: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
#117: FILE: drivers/dma-buf/dma-resv.c:570:
+   fences = kmalloc_array(num_fences, sizeof(struct dma_fence*),

total: 2 errors, 0 warnings, 1 checks, 118 lines checked
94bae126528f dma-buf: Document DMA_BUF_IOCTL_SYNC
3dff9c2a dma-buf: Add an API for exporting sync files (v11)
46fac74a3274 RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked
f3982039cd8a RFC: dma-buf: Add an API for importing sync files (v7)


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

[Intel-gfx] ✓ Fi.CI.BAT: success for Non-interface changing GuC CTBs updates

[Patchwork]

== Series Details ==

Series: Non-interface changing GuC CTBs updates
URL   : https://patchwork.freedesktop.org/series/90552/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10133 -> Patchwork_20192


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0:
- fi-bsw-kefka:   [PASS][2] -> [INCOMPLETE][3] ([i915#2539])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-icl-y:   [PASS][5] -> [INCOMPLETE][6] ([i915#2782])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-icl-y/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][7] ([fdo#109271]) +5 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][8] ([i915#49]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][10] ([i915#1436] / [i915#3363]) -> [FAIL][11] 
([i915#1436] / [i915#2426] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-skl-6600u/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-skl-6600u/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][12] ([i915#1602] / [i915#2029]) -> [FAIL][13] 
([i915#3462])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-bdw-5557u/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][14] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][15] ([i915#1436] / [i915#3363])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-kbl-soraka/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][16] ([i915#2082] / [i915#2426] / [i915#3363] / 
[i915#3462]) -> [FAIL][17] ([i915#3363] / [i915#3462])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-cml-u2/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-cml-u2/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][18] ([i915#1436] / [i915#3363]) -> [FAIL][19] 
([i915#1436] / [i915#2426] / [i915#3363])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10133/fi-kbl-7567u/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20192/fi-kbl-7567u/igt@run...@aborted.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2539]: https://gitlab.freedesktop.org/drm/intel/issues/2539
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3012]: 

[Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

[Jason Ekstrand]

Modern userspace APIs like Vulkan are built on an explicit
synchronization model.  This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland.  The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.

The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor.  We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer.  With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer.  In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.

This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file.  It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later.  As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display.  This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.

v2 (Jason Ekstrand):
 - Use a wrapper dma_fence_array of all fences including the new one
   when importing an exclusive fence.

v3 (Jason Ekstrand):
 - Lock around setting shared fences as well as exclusive
 - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
 - Initialize ret to 0 in dma_buf_wait_sync_file

v4 (Jason Ekstrand):
 - Use the new dma_resv_get_singleton helper

v5 (Jason Ekstrand):
 - Rename the IOCTLs to import/export rather than wait/signal
 - Drop the WRITE flag and always get/set the exclusive fence

v6 (Jason Ekstrand):
 - Drop the sync_file import as it was all-around sketchy and not nearly
   as useful as import.
 - Re-introduce READ/WRITE flag support for export
 - Rework the commit message

v7 (Jason Ekstrand):
 - Require at least one sync flag
 - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
 - Use _rcu helpers since we're accessing the dma_resv read-only

v8 (Jason Ekstrand):
 - Return -ENOMEM if the sync_file_create fails
 - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)

v9 (Jason Ekstrand):
 - Add documentation for the new ioctl

v10 (Jason Ekstrand):
 - Go back to dma_buf_sync_file as the ioctl struct name

v11 (Daniel Vetter):
 - Go back to dma_buf_export_sync_file as the ioctl struct name
 - Better kerneldoc describing what the read/write flags do

Signed-off-by: Jason Ekstrand 
Acked-by: Simon Ser 
Acked-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-buf.c| 67 
 include/uapi/linux/dma-buf.h | 35 +++
 2 files changed, 102 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ed6451d55d663..65a9574ee04ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,6 +192,9 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
offset, int whence)
  * Note that this only signals the completion of the respective fences, i.e. 
the
  * DMA transfers are complete. Cache flushing and any other necessary
  * preparations before CPU access can begin still need to happen.
+ *
+ * As an alternative to poll(), the set of fences on DMA buffer can be
+ * exported as a _file using _buf_sync_file_export.
  */
 
 static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
@@ -362,6 +366,64 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const 
char __user *buf)
return ret;
 }
 
+#if IS_ENABLED(CONFIG_SYNC_FILE)
+static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
+void __user *user_data)
+{
+   struct dma_buf_export_sync_file arg;
+   struct dma_fence *fence = NULL;
+   struct sync_file *sync_file;
+   int fd, ret;
+
+   if (copy_from_user(, user_data, sizeof(arg)))
+   return -EFAULT;
+
+   if (arg.flags & ~DMA_BUF_SYNC_RW)
+   return -EINVAL;
+
+   if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
+   return -EINVAL;
+
+   fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fd < 0)
+   return fd;
+
+   if (arg.flags & DMA_BUF_SYNC_WRITE) {
+   fence = dma_resv_get_singleton_unlocked(dmabuf->resv);
+ 

[Intel-gfx] [PATCH 7/7] RFC: dma-buf: Add an API for importing sync files (v7)

[Jason Ekstrand]

This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf.  Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf.  Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence.  A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.

In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent.  Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync.  Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf.  We handle it in
Mesa today with the above mentioned dummy submit trick.  This ioctl
would allow us to set it directly without the dummy submit.

This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.

We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv.  There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best.  When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv.  This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts.  We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.

There is one downside here that's worth documenting:  If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same:  Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work.  The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock.  If two userspace submits race, one will happen before
the other.  You aren't guaranteed which but you are guaranteed that
they're strictly ordered.  If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved.  However, this is a
case of userspace racing with itself.  As long as we ensure userspace
can't back the kernel into a corner, it should be fine.

v2 (Jason Ekstrand):
 - Use a wrapper dma_fence_array of all fences including the new one
   when importing an exclusive fence.

v3 (Jason Ekstrand):
 - Lock around setting shared fences as well as exclusive
 - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
 - Initialize ret to 0 in dma_buf_wait_sync_file

v4 (Jason Ekstrand):
 - Use the new dma_resv_get_singleton helper

v5 (Jason Ekstrand):
 - Rename the IOCTLs to import/export rather than wait/signal
 - Drop the WRITE flag and always get/set the exclusive fence

v6 (Jason Ekstrand):
 - Split import and export into separate patches
 - New commit message

v7 (Daniel Vetter):
 - Fix the uapi header to use the right struct in the ioctl
 - Use a separate dma_buf_import_sync_file struct
 - Add kerneldoc for dma_buf_import_sync_file

Signed-off-by: Jason Ekstrand 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-buf.c| 36 
 include/uapi/linux/dma-buf.h | 22 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ea117de962903..098340222662b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -422,6 +422,40 @@ static long dma_buf_export_sync_file(struct dma_buf 
*dmabuf,
put_unused_fd(fd);
return ret;
 }
+
+static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
+const void __user *user_data)
+{
+   struct dma_buf_import_sync_file arg;
+   struct dma_fence *fence, *singleton = NULL;
+   int ret = 0;
+
+   if (copy_from_user(, user_data, sizeof(arg)))
+   return -EFAULT;
+
+   if (arg.flags != DMA_BUF_SYNC_RW)
+   return -EINVAL;
+
+   fence = sync_file_get_fence(arg.fd);
+   if (!fence)
+   return -EINVAL;
+

[Intel-gfx] [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC

[Jason Ekstrand]

This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
documentation for DMA_BUF_IOCTL_SYNC.

Signed-off-by: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Sumit Semwal 
---
 Documentation/driver-api/dma-buf.rst |  8 +++
 include/uapi/linux/dma-buf.h | 32 +++-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 7f37ec30d9fd7..784f84fe50a5e 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -88,6 +88,9 @@ consider though:
 - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below 
for
   details.
 
+- The DMA buffer FD also supports a few dma-buf-specific ioctls, see
+  `DMA Buffer ioctls`_ below for details.
+
 Basic Operation and Device DMA Access
 ~
 
@@ -106,6 +109,11 @@ Implicit Fence Poll Support
 .. kernel-doc:: drivers/dma-buf/dma-buf.c
:doc: implicit fence polling
 
+DMA Buffer ioctls
+~
+
+.. kernel-doc:: include/uapi/linux/dma-buf.h
+
 Kernel Functions and Structures Reference
 ~
 
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
index 7f30393b92c3b..1f67ced853b14 100644
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@ -22,8 +22,38 @@
 
 #include 
 
-/* begin/end dma-buf functions used for userspace mmap. */
+/**
+ * struct dma_buf_sync - Synchronize with CPU access.
+ *
+ * When a DMA buffer is accessed from the CPU via mmap, it is not always
+ * possible to guarantee coherency between the CPU-visible map and underlying
+ * memory.  To manage coherency, DMA_BUF_IOCTL_SYNC must be used to bracket
+ * any CPU access to give the kernel the chance to shuffle memory around if
+ * needed.
+ *
+ * Prior to accessing the map, the client should call DMA_BUF_IOCTL_SYNC
+ * with DMA_BUF_SYNC_START and the appropriate read/write flags.  Once the
+ * access is complete, the client should call DMA_BUF_IOCTL_SYNC with
+ * DMA_BUF_SYNC_END and the same read/write flags.
+ */
 struct dma_buf_sync {
+   /**
+* @flags: Set of access flags
+*
+* - DMA_BUF_SYNC_START: Indicates the start of a map access
+*   session.
+*
+* - DMA_BUF_SYNC_END: Indicates the end of a map access session.
+*
+* - DMA_BUF_SYNC_READ: Indicates that the mapped DMA buffer will
+*   be read by the client via the CPU map.
+*
+* - DMA_BUF_SYNC_READ: Indicates that the mapped DMA buffer will
+*   be written by the client via the CPU map.
+*
+* - DMA_BUF_SYNC_RW: An alias for DMA_BUF_SYNC_READ |
+*   DMA_BUF_SYNC_WRITE.
+*/
__u64 flags;
 };
 
-- 
2.31.1

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

[Intel-gfx] [PATCH 6/7] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked

[Jason Ekstrand]

For dma-buf sync_file import, we want to get all the fences on a
dma_resv plus one more.  We could wrap the fence we get back in an array
fence or we could make dma_resv_get_singleton_unlocked take "one more"
to make this case easier.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
Cc: Christian König 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-buf.c  |  2 +-
 drivers/dma-buf/dma-resv.c | 23 +--
 include/linux/dma-resv.h   |  3 ++-
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 65a9574ee04ed..ea117de962903 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -389,7 +389,7 @@ static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
return fd;
 
if (arg.flags & DMA_BUF_SYNC_WRITE) {
-   fence = dma_resv_get_singleton_unlocked(dmabuf->resv);
+   fence = dma_resv_get_singleton_unlocked(dmabuf->resv, NULL);
if (IS_ERR(fence)) {
ret = PTR_ERR(fence);
goto err_put_fd;
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 23db2181c8ad8..5a5e13a01e516 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -527,6 +527,7 @@ EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
 /**
  * dma_resv_get_singleton_unlocked - get a single fence for the dma_resv object
  * @obj: the reservation object
+ * @extra: extra fence to add to the resulting array
  *
  * Get a single fence representing all unsignaled fences in the dma_resv object
  * plus the given extra fence. If we got only one fence return a new
@@ -535,7 +536,8 @@ EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
  * RETURNS
  * The singleton dma_fence on success or an ERR_PTR on failure
  */
-struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj)
+struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj,
+ struct dma_fence *extra)
 {
struct dma_fence *result, **resv_fences, *fence, *chain, **fences;
struct dma_fence_array *array;
@@ -546,7 +548,7 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
dma_resv *obj)
if (err)
return ERR_PTR(err);
 
-   if (num_resv_fences == 0)
+   if (num_resv_fences == 0 && !extra)
return NULL;
 
num_fences = 0;
@@ -562,6 +564,16 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
dma_resv *obj)
}
}
 
+   if (extra) {
+   dma_fence_deep_dive_for_each(fence, chain, j, extra) {
+   if (dma_fence_is_signaled(fence))
+   continue;
+
+   result = fence;
+   ++num_fences;
+   }
+   }
+
if (num_fences <= 1) {
result = dma_fence_get(result);
goto put_resv_fences;
@@ -582,6 +594,13 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
dma_resv *obj)
}
}
 
+   if (extra) {
+   dma_fence_deep_dive_for_each(fence, chain, j, extra) {
+   if (dma_fence_is_signaled(fence))
+   fences[num_fences++] = dma_fence_get(fence);
+   }
+   }
+
if (num_fences <= 1) {
result = num_fences ? fences[0] : NULL;
kfree(fences);
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index c5fa09555eca5..4b1dabfa7017d 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -285,7 +285,8 @@ int dma_resv_get_fences_unlocked(struct dma_resv *obj,
 
 int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
 
-struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj);
+struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj,
+ struct dma_fence *extra);
 
 long dma_resv_wait_timeout_unlocked(struct dma_resv *obj, bool wait_all, bool 
intr,
unsigned long timeout);
-- 
2.31.1

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

[Intel-gfx] [PATCH 3/7] dma-buf: Add dma_resv_get_singleton_unlocked (v5)

[Jason Ekstrand]

Add a helper function to get a single fence representing
all fences in a dma_resv object.

This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.

v2 (Jason Ekstrand):
 - Take reference of fences both for creating the dma_fence_array and in
   the case where we return one fence.
 - Handle the case where dma_resv_get_list() returns NULL

v3 (Jason Ekstrand):
 - Add an _rcu suffix because it is read-only
 - Rewrite to use dma_resv_get_fences_rcu so it's RCU-safe
 - Add an EXPORT_SYMBOL_GPL declaration
 - Re-author the patch to Jason since very little is left of Christian
   König's original patch
 - Remove the extra fence argument

v4 (Jason Ekstrand):
 - Restore the extra fence argument

v5 (Daniel Vetter):
 - Rename from _rcu to _unlocked since it doesn't leak RCU details to
   the caller
 - Fix docs
 - Use ERR_PTR for error handling rather than an output dma_fence**

v5 (Jason Ekstrand):
 - Drop the extra fence param and leave that to a separate patch

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
Cc: Christian König 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-resv.c | 92 ++
 include/linux/dma-resv.h   |  2 +
 2 files changed, 94 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index d6f1ed4cd4d55..23db2181c8ad8 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -33,6 +33,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -49,6 +51,11 @@
  * write-side updates.
  */
 
+/* deep dive into the fence containers */
+#define dma_fence_deep_dive_for_each(fence, chain, index, head)\
+   dma_fence_chain_for_each(chain, head)   \
+   dma_fence_array_for_each(fence, index, chain)
+
 DEFINE_WD_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);
 
@@ -517,6 +524,91 @@ int dma_resv_get_fences_unlocked(struct dma_resv *obj,
 }
 EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
 
+/**
+ * dma_resv_get_singleton_unlocked - get a single fence for the dma_resv object
+ * @obj: the reservation object
+ *
+ * Get a single fence representing all unsignaled fences in the dma_resv object
+ * plus the given extra fence. If we got only one fence return a new
+ * reference to that, otherwise return a dma_fence_array object.
+ *
+ * RETURNS
+ * The singleton dma_fence on success or an ERR_PTR on failure
+ */
+struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj)
+{
+   struct dma_fence *result, **resv_fences, *fence, *chain, **fences;
+   struct dma_fence_array *array;
+   unsigned int num_resv_fences, num_fences;
+   unsigned int err, i, j;
+
+   err = dma_resv_get_fences_unlocked(obj, NULL, _resv_fences, 
_fences);
+   if (err)
+   return ERR_PTR(err);
+
+   if (num_resv_fences == 0)
+   return NULL;
+
+   num_fences = 0;
+   result = NULL;
+
+   for (i = 0; i < num_resv_fences; ++i) {
+   dma_fence_deep_dive_for_each(fence, chain, j, resv_fences[i]) {
+   if (dma_fence_is_signaled(fence))
+   continue;
+
+   result = fence;
+   ++num_fences;
+   }
+   }
+
+   if (num_fences <= 1) {
+   result = dma_fence_get(result);
+   goto put_resv_fences;
+   }
+
+   fences = kmalloc_array(num_fences, sizeof(struct dma_fence*),
+  GFP_KERNEL);
+   if (!fences) {
+   result = ERR_PTR(-ENOMEM);
+   goto put_resv_fences;
+   }
+
+   num_fences = 0;
+   for (i = 0; i < num_resv_fences; ++i) {
+   dma_fence_deep_dive_for_each(fence, chain, j, resv_fences[i]) {
+   if (!dma_fence_is_signaled(fence))
+   fences[num_fences++] = dma_fence_get(fence);
+   }
+   }
+
+   if (num_fences <= 1) {
+   result = num_fences ? fences[0] : NULL;
+   kfree(fences);
+   goto put_resv_fences;
+   }
+
+   array = dma_fence_array_create(num_fences, fences,
+  dma_fence_context_alloc(1),
+  1, false);
+   if (array) {
+   result = >base;
+   } else {
+   result = ERR_PTR(-ENOMEM);
+   while (num_fences--)
+   dma_fence_put(fences[num_fences]);
+   kfree(fences);
+   }
+
+put_resv_fences:
+   while (num_resv_fences--)
+   dma_fence_put(resv_fences[num_resv_fences]);
+   kfree(resv_fences);
+
+   return result;
+}
+EXPORT_SYMBOL_GPL(dma_resv_get_singleton_unlocked);
+
 /**
  * dma_resv_wait_timeout_unlocked - Wait on reservation's objects
  * shared and/or exclusive fences.
diff --git a/include/linux/dma-resv.h 

[Intel-gfx] [PATCH 2/7] dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)

[Jason Ekstrand]

None of these helpers actually leak any RCU details to the caller.  They
all assume you have a genuine reference, take the RCU read lock, and
retry if needed.  Naming them with an _rcu is likely to cause callers
more panic than needed.

v2 (Jason Ekstrand):
 - Fix function argument indentation

Signed-off-by: Jason Ekstrand 
Suggested-by: Daniel Vetter 
Cc: Christian König 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Lucas Stach 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: Huang Rui 
Cc: Gerd Hoffmann 
Cc: VMware Graphics 
---
 drivers/dma-buf/dma-buf.c |  4 +--
 drivers/dma-buf/dma-resv.c| 28 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c|  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 ++--
 drivers/gpu/drm/drm_gem.c | 10 +++
 drivers/gpu/drm/drm_gem_atomic_helper.c   |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  7 ++---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |  8 +++---
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 drivers/gpu/drm/i915/dma_resv_utils.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_busy.c  |  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  4 +--
 drivers/gpu/drm/i915/gem/i915_gem_wait.c  | 10 +++
 drivers/gpu/drm/i915/i915_request.c   |  6 ++--
 drivers/gpu/drm/i915/i915_sw_fence.c  |  4 +--
 drivers/gpu/drm/msm/msm_gem.c |  3 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |  4 +--
 drivers/gpu/drm/panfrost/panfrost_drv.c   |  4 +--
 drivers/gpu/drm/panfrost/panfrost_job.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_gem.c   |  6 ++--
 drivers/gpu/drm/radeon/radeon_mn.c|  4 +--
 drivers/gpu/drm/ttm/ttm_bo.c  | 18 ++--
 drivers/gpu/drm/vgem/vgem_fence.c |  4 +--
 drivers/gpu/drm/virtio/virtgpu_ioctl.c|  6 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|  2 +-
 include/linux/dma-resv.h  | 18 ++--
 36 files changed, 108 insertions(+), 110 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383eb..ed6451d55d663 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1147,8 +1147,8 @@ static int __dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
long ret;
 
/* Wait on any implicit rendering fences */
-   ret = dma_resv_wait_timeout_rcu(resv, write, true,
- MAX_SCHEDULE_TIMEOUT);
+   ret = dma_resv_wait_timeout_unlocked(resv, write, true,
+MAX_SCHEDULE_TIMEOUT);
if (ret < 0)
return ret;
 
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
dma_resv *src)
 EXPORT_SYMBOL(dma_resv_copy_fences);
 
 /**
- * dma_resv_get_fences_rcu - Get an object's shared and exclusive
+ * dma_resv_get_fences_unlocked - Get an object's shared and exclusive
  * fences without update side lock held
  * @obj: the reservation object
  * @pfence_excl: the returned exclusive fence (or NULL)
@@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences);
  * exclusive fence is not specified the fence is put into the array of the
  * shared fences as well. Returns either zero or -ENOMEM.
  */
-int dma_resv_get_fences_rcu(struct dma_resv *obj,
-   struct dma_fence **pfence_excl,
-   unsigned *pshared_count,
-   struct dma_fence ***pshared)
+int dma_resv_get_fences_unlocked(struct dma_resv *obj,
+struct dma_fence **pfence_excl,
+unsigned *pshared_count,
+struct dma_fence ***pshared)
 {
struct dma_fence **shared = NULL;
struct dma_fence *fence_excl;
@@ -515,10 +515,10 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
*pshared = shared;
return ret;
 }
-EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
+EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
 
 /**
- * dma_resv_wait_timeout_rcu - Wait on reservation's objects
+ * dma_resv_wait_timeout_unlocked - Wait on reservation's objects
  * 

[Intel-gfx] [PATCH 1/7] dma-buf: Add dma_fence_array_for_each (v2)

[Jason Ekstrand]

From: Christian König 

Add a helper to iterate over all fences in a dma_fence_array object.

v2 (Jason Ekstrand)
 - Return NULL from dma_fence_array_first if head == NULL.  This matches
   the iterator behavior of dma_fence_chain_for_each in that it iterates
   zero times if head == NULL.
 - Return NULL from dma_fence_array_next if index > array->num_fences.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Jason Ekstrand 
Reviewed-by: Christian König 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-fence-array.c | 27 +++
 include/linux/dma-fence-array.h   | 17 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index d3fbd950be944..2ac1afc697d0f 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -201,3 +201,30 @@ bool dma_fence_match_context(struct dma_fence *fence, u64 
context)
return true;
 }
 EXPORT_SYMBOL(dma_fence_match_context);
+
+struct dma_fence *dma_fence_array_first(struct dma_fence *head)
+{
+   struct dma_fence_array *array;
+
+   if (!head)
+   return NULL;
+
+   array = to_dma_fence_array(head);
+   if (!array)
+   return head;
+
+   return array->fences[0];
+}
+EXPORT_SYMBOL(dma_fence_array_first);
+
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+  unsigned int index)
+{
+   struct dma_fence_array *array = to_dma_fence_array(head);
+
+   if (!array || index >= array->num_fences)
+   return NULL;
+
+   return array->fences[index];
+}
+EXPORT_SYMBOL(dma_fence_array_next);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220fd..588ac8089dd61 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -74,6 +74,19 @@ to_dma_fence_array(struct dma_fence *fence)
return container_of(fence, struct dma_fence_array, base);
 }
 
+/**
+ * dma_fence_array_for_each - iterate over all fences in array
+ * @fence: current fence
+ * @index: index into the array
+ * @head: potential dma_fence_array object
+ *
+ * Test if @array is a dma_fence_array object and if yes iterate over all 
fences
+ * in the array. If not just iterate over the fence in @array itself.
+ */
+#define dma_fence_array_for_each(fence, index, head)   \
+   for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))
+
 struct dma_fence_array *dma_fence_array_create(int num_fences,
   struct dma_fence **fences,
   u64 context, unsigned seqno,
@@ -81,4 +94,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
 
 bool dma_fence_match_context(struct dma_fence *fence, u64 context);
 
+struct dma_fence *dma_fence_array_first(struct dma_fence *head);
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+  unsigned int index);
+
 #endif /* __LINUX_DMA_FENCE_ARRAY_H */
-- 
2.31.1

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

[Intel-gfx] [PATCH 0/7] dma-buf: Add an API for exporting sync files (v11)

[Jason Ekstrand]

Modern userspace APIs like Vulkan are built on an explicit
synchronization model.  This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland.  The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.

The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor.  We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer.  With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer.  In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.

This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file.  It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later.  As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display.  This allows to accurately turn
it into a VkFence or VkSemaphore without any over- synchronization.

This patch series actually contains two new ioctls.  There is the export
one mentioned above as well as an RFC for an import ioctl which provides
the other half.  The intention is to land the export ioctl since it seems
like there's no real disagreement on that one.  The import ioctl, however,
has a lot of debate around it so it's intended to be RFC-only for now.

Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/

v10 (Jason Ekstrand, Daniel Vetter):
 - Add reviews/acks
 - Add a patch to rename _rcu to _unlocked
 - Split things better so import is clearly RFC status

v11 (Daniel Vetter):
 - Add more CCs to try and get maintainers
 - Add a patch to document DMA_BUF_IOCTL_SYNC
 - Generally better docs
 - Use separate structs for import/export (easier to document)
 - Fix an issue in the import patch

Cc: Christian König 
Cc: Michel Dänzer 
Cc: Dave Airlie 
Cc: Bas Nieuwenhuizen 
Cc: Daniel Stone 
Cc: mesa-...@lists.freedesktop.org
Cc: wayland-de...@lists.freedesktop.org
Test-with: 20210524205225.872316-1-ja...@jlekstrand.net

Christian König (1):
  dma-buf: Add dma_fence_array_for_each (v2)

Jason Ekstrand (6):
  dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2)
  dma-buf: Add dma_resv_get_singleton_unlocked (v5)
  dma-buf: Document DMA_BUF_IOCTL_SYNC
  dma-buf: Add an API for exporting sync files (v11)
  RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked
  RFC: dma-buf: Add an API for importing sync files (v7)

 Documentation/driver-api/dma-buf.rst  |   8 +
 drivers/dma-buf/dma-buf.c | 107 +-
 drivers/dma-buf/dma-fence-array.c |  27 
 drivers/dma-buf/dma-resv.c| 139 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  14 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   6 +-
 drivers/gpu/drm/drm_gem.c |  10 +-
 drivers/gpu/drm/drm_gem_atomic_helper.c   |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |   7 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |   8 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   2 +-
 drivers/gpu/drm/i915/dma_resv_utils.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_busy.c  |   2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_wait.c  |  10 +-
 drivers/gpu/drm/i915/i915_request.c   |   6 +-
 drivers/gpu/drm/i915/i915_sw_fence.c  |   4 +-
 drivers/gpu/drm/msm/msm_gem.c |   3 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |   4 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c   |   4 +-
 drivers/gpu/drm/panfrost/panfrost_job.c   |   2 +-
 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates

[Patchwork]

== Series Details ==

Series: Non-interface changing GuC CTBs updates
URL   : https://patchwork.freedesktop.org/series/90552/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1328:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Non-interface changing GuC CTBs updates

[Patchwork]

== Series Details ==

Series: Non-interface changing GuC CTBs updates
URL   : https://patchwork.freedesktop.org/series/90552/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
232417d031b9 drm/i915/guc: skip disabling CTBs before sanitizing the GuC
341c70656750 drm/i915/guc: use probe_error log for CT enablement failure
-:57: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
#57: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:38:
+#define CT_PROBE_ERROR(_ct, _fmt, ...) \
+   i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__);

total: 0 errors, 1 warnings, 0 checks, 72 lines checked
b6b4993218ab drm/i915/guc: enable only the user interrupt when using GuC 
submission
7bc25d889ff7 drm/i915/guc: Remove sample_forcewake h2g action
-:11: WARNING:BAD_SIGN_OFF: Use a single space after Cc:
#11: 
Cc:  Vinay Belgaumkar 

total: 0 errors, 1 warnings, 0 checks, 55 lines checked
a02cb3e825d6 drm/i915/guc: Keep strict GuC ABI definitions
-:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#18: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 476 lines checked
776f36a2bce0 drm/i915/guc: Stop using fence/status from CTB descriptor
877a8bd1e6bd drm/i915: Promote ptrdiff() to i915_utils.h
62559d3051cf drm/i915/guc: Only rely on own CTB size
51f154fa0b01 drm/i915/guc: Don't repeat CTB layout calculations
23f84eb2bb28 drm/i915/guc: Replace CTB array with explicit members
ef402f00ed93 drm/i915/guc: Update sizes of CTB buffers
fcdee0ecb586 drm/i915/guc: Relax CTB response timeout
-:7: WARNING:TYPO_SPELLING: 'procesing' may be misspelled - perhaps 
'processing'?
#7: 
parallel to the GuC for procesing, so we shouldn't assume any more
^

total: 0 errors, 1 warnings, 0 checks, 35 lines checked
c48c38ded661 drm/i915/guc: Start protecting access to CTB descriptors
-:87: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#87: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h:36:
+   spinlock_t lock;

total: 0 errors, 0 warnings, 1 checks, 61 lines checked
7d0c670b963f drm/i915/guc: Ensure H2G buffer updates visible before tail update
-:23: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the 
next line
#23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:331:
+static void write_barrier(struct intel_guc_ct *ct) {

-:31: WARNING:MEMORY_BARRIER: memory barrier without comment
#31: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:339:
+   wmb();

total: 1 errors, 1 warnings, 0 checks, 30 lines checked
29bcbe2dea0e drm/i915/guc: Stop using mutex while sending CTB messages
5e9855bcaa3f drm/i915/guc: Don't receive all G2H messages in irq handler
b4f470d880ca drm/i915/guc: Always copy CT message to new allocation


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

[Intel-gfx] [PATCH 14/17] drm/i915/guc: Ensure H2G buffer updates visible before tail update

[Matthew Brost]

Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
barrier is simple wmb() for SMEM and is register write for LMEM. This is
needed if more than 1 H2G can be inflight at once.

Signed-off-by: Matthew Brost 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index e44f06fbf87a..732a8ffa52dc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -328,6 +328,18 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
 }
 
+static void write_barrier(struct intel_guc_ct *ct) {
+   struct intel_guc *guc = ct_to_guc(ct);
+   struct intel_gt *gt = guc_to_gt(guc);
+
+   if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+   GEM_BUG_ON(guc->send_regs.fw_domains);
+   intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
+   } else {
+   wmb();
+   }
+}
+
 /**
  * DOC: CTB Host to GuC request
  *
@@ -411,6 +423,12 @@ static int ct_write(struct intel_guc_ct *ct,
}
GEM_BUG_ON(tail > size);
 
+   /*
+* make sure H2G buffer update and LRC tail update (if this triggering a
+* submission) are visible before updating the descriptor tail
+*/
+   write_barrier(ct);
+
/* now update desc tail (back in bytes) */
desc->tail = tail * 4;
return 0;
-- 
2.28.0

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

[Intel-gfx] [PATCH 15/17] drm/i915/guc: Stop using mutex while sending CTB messages

[Matthew Brost]

From: Michal Wajdeczko 

We are no longer using descriptor to hold G2H replies and we are
protecting access to the descriptor and command buffer by the
separate spinlock, so we can stop using mutex.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 732a8ffa52dc..3b36757ebfd3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -552,7 +552,6 @@ static int ct_send(struct intel_guc_ct *ct,
 int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
  u32 *response_buf, u32 response_buf_size)
 {
-   struct intel_guc *guc = ct_to_guc(ct);
u32 status = ~0; /* undefined */
int ret;
 
@@ -561,8 +560,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
*action, u32 len,
return -ENODEV;
}
 
-   mutex_lock(>send_mutex);
-
ret = ct_send(ct, action, len, response_buf, response_buf_size, 
);
if (unlikely(ret < 0)) {
CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
@@ -572,7 +569,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
*action, u32 len,
 action[0], ret, ret);
}
 
-   mutex_unlock(>send_mutex);
return ret;
 }
 
-- 
2.28.0

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

[Intel-gfx] [PATCH 16/17] drm/i915/guc: Don't receive all G2H messages in irq handler

[Matthew Brost]

From: Michal Wajdeczko 

In irq handler try to receive just single G2H message, let other
messages to be received from tasklet.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  3 +
 2 files changed, 50 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3b36757ebfd3..fdfc5f36ad2f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -81,6 +81,7 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
 
 enum { CTB_OWNER_HOST = 0 };
 
+static void ct_receive_tasklet_func(struct tasklet_struct *t);
 static void ct_incoming_request_worker_func(struct work_struct *w);
 
 /**
@@ -95,6 +96,7 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
INIT_LIST_HEAD(>requests.pending);
INIT_LIST_HEAD(>requests.incoming);
INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
+   tasklet_setup(>receive_tasklet, ct_receive_tasklet_func);
 }
 
 static inline const char *guc_ct_buffer_type_to_str(u32 type)
@@ -244,6 +246,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
 {
GEM_BUG_ON(ct->enabled);
 
+   tasklet_kill(>receive_tasklet);
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
memset(ct, 0, sizeof(*ct));
 }
@@ -644,7 +647,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
 
desc->head = head * 4;
-   return 0;
+   return available - len;
 
 corrupted:
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
@@ -680,10 +683,10 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
u32 status;
u32 datalen;
struct ct_request *req;
+   unsigned long flags;
bool found = false;
 
GEM_BUG_ON(!ct_header_is_response(header));
-   GEM_BUG_ON(!in_irq());
 
/* Response payload shall at least include fence and status */
if (unlikely(len < 2)) {
@@ -703,7 +706,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
 
CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
 
-   spin_lock(>requests.lock);
+   spin_lock_irqsave(>requests.lock, flags);
list_for_each_entry(req, >requests.pending, link) {
if (unlikely(fence != req->fence)) {
CT_DEBUG(ct, "request %u awaits response\n",
@@ -722,7 +725,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
found = true;
break;
}
-   spin_unlock(>requests.lock);
+   spin_unlock_irqrestore(>requests.lock, flags);
 
if (!found)
CT_ERROR(ct, "Unsolicited response %*ph\n", msgsize, msg);
@@ -836,31 +839,55 @@ static int ct_handle_request(struct intel_guc_ct *ct, 
const u32 *msg)
return 0;
 }
 
+static int ct_receive(struct intel_guc_ct *ct)
+{
+   u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>ctbs.recv.lock, flags);
+   ret = ct_read(ct, msg);
+   spin_unlock_irqrestore(>ctbs.recv.lock, flags);
+   if (ret < 0)
+   return ret;
+
+   if (ct_header_is_response(msg[0]))
+   ct_handle_response(ct, msg);
+   else
+   ct_handle_request(ct, msg);
+
+   return ret;
+}
+
+static void ct_try_receive_message(struct intel_guc_ct *ct)
+{
+   int ret;
+
+   if (GEM_WARN_ON(!ct->enabled))
+   return;
+
+   ret = ct_receive(ct);
+   if (ret > 0)
+   tasklet_hi_schedule(>receive_tasklet);
+}
+
+static void ct_receive_tasklet_func(struct tasklet_struct *t)
+{
+   struct intel_guc_ct *ct = from_tasklet(ct, t, receive_tasklet);
+
+   ct_try_receive_message(ct);
+}
+
 /*
  * When we're communicating with the GuC over CT, GuC uses events
  * to notify us about new messages being posted on the RECV buffer.
  */
 void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
 {
-   u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
-   unsigned long flags;
-   int err = 0;
-
if (unlikely(!ct->enabled)) {
WARN(1, "Unexpected GuC event received while CT disabled!\n");
return;
}
 
-   do {
-   spin_lock_irqsave(>ctbs.recv.lock, flags);
-   err = ct_read(ct, msg);
-   spin_unlock_irqrestore(>ctbs.recv.lock, flags);
-   if (err)
-   break;
-
-   if (ct_header_is_response(msg[0]))
-   err = ct_handle_response(ct, msg);
-   else
-   err = ct_handle_request(ct, msg);
-   } while 

[Intel-gfx] [PATCH 17/17] drm/i915/guc: Always copy CT message to new allocation

[Matthew Brost]

From: Michal Wajdeczko 

Since most of future CT traffic will be based on G2H requests,
instead of copying incoming CT message to static buffer and then
create new allocation for such request, always copy incoming CT
message to new allocation. Also by doing it while reading CT
header, we can safely fallback if that atomic allocation fails.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 180 ++
 1 file changed, 120 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fdfc5f36ad2f..d862ae04f577 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -72,8 +72,9 @@ struct ct_request {
u32 *response_buf;
 };
 
-struct ct_incoming_request {
+struct ct_incoming_msg {
struct list_head link;
+   u32 size;
u32 msg[];
 };
 
@@ -590,7 +591,26 @@ static inline bool ct_header_is_response(u32 header)
return !!(header & GUC_CT_MSG_IS_RESPONSE);
 }
 
-static int ct_read(struct intel_guc_ct *ct, u32 *data)
+static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
+{
+   struct ct_incoming_msg *msg;
+
+   msg = kmalloc(sizeof(*msg) + sizeof(u32) * num_dwords, GFP_ATOMIC);
+   if (msg)
+   msg->size = num_dwords;
+   return msg;
+}
+
+static void ct_free_msg(struct ct_incoming_msg *msg)
+{
+   kfree(msg);
+}
+
+/*
+ * Return: number available remaining dwords to read (0 if empty)
+ * or a negative error code on failure
+ */
+static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
 {
struct intel_guc_ct_buffer *ctb = >ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -601,6 +621,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
s32 available;
unsigned int len;
unsigned int i;
+   u32 header;
 
if (unlikely(desc->is_in_error))
return -EPIPE;
@@ -616,8 +637,10 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
 
/* tail == head condition indicates empty */
available = tail - head;
-   if (unlikely(available == 0))
-   return -ENODATA;
+   if (unlikely(available == 0)) {
+   *msg = NULL;
+   return 0;
+   }
 
/* beware of buffer wrap case */
if (unlikely(available < 0))
@@ -625,14 +648,14 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
GEM_BUG_ON(available < 0);
 
-   data[0] = cmds[head];
+   header = cmds[head];
head = (head + 1) % size;
 
/* message len with header */
-   len = ct_header_get_len(data[0]) + 1;
+   len = ct_header_get_len(header) + 1;
if (unlikely(len > (u32)available)) {
CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
-4, data,
+4, ,
 4 * (head + available - 1 > size ?
  size - head : available - 1), [head],
 4 * (head + available - 1 > size ?
@@ -640,11 +663,24 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
goto corrupted;
}
 
+   *msg = ct_alloc_msg(len);
+   if (!*msg) {
+   CT_ERROR(ct, "No memory for message %*ph %*ph %*ph\n",
+4, ,
+4 * (head + available - 1 > size ?
+ size - head : available - 1), [head],
+4 * (head + available - 1 > size ?
+ available - 1 - size + head : 0), [0]);
+   return available;
+   }
+
+   (*msg)->msg[0] = header;
+
for (i = 1; i < len; i++) {
-   data[i] = cmds[head];
+   (*msg)->msg[i] = cmds[head];
head = (head + 1) % size;
}
-   CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
+   CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
 
desc->head = head * 4;
return available - len;
@@ -674,33 +710,33 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
  *   ^---len---^
  */
 
-static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
+static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg 
*response)
 {
-   u32 header = msg[0];
+   u32 header = response->msg[0];
u32 len = ct_header_get_len(header);
-   u32 msgsize = (len + 1) * sizeof(u32); /* msg size in bytes w/header */
u32 fence;
u32 status;
u32 datalen;
struct ct_request *req;
unsigned long flags;
bool found = false;
+   int err = 0;
 

[Intel-gfx] [PATCH 12/17] drm/i915/guc: Relax CTB response timeout

[Matthew Brost]

From: Michal Wajdeczko 

In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for procesing, so we shouldn't assume any more
that GuC will always reply without 10ms.

Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead.

v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/Kconfig.profile  | 9 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile
index 39328567c200..68ac707755d2 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -38,6 +38,15 @@ config DRM_I915_USERFAULT_AUTOSUSPEND
  May be 0 to disable the extra delay and solely use the device level
  runtime pm autosuspend delay tunable.
 
+config DRM_I915_GUC_CTB_TIMEOUT
+   int "How long to wait for the GuC to make forward progress on CTBs (ms)"
+   default 1500 # milliseconds
+   help
+ Configures the default timeout waiting for GuC the to make forward
+ progress on CTBs. e.g. Waiting for a response to requeset.
+
+ A minimum value of 10 ms is allowed.
+
 config DRM_I915_HEARTBEAT_INTERVAL
int "Interval between heartbeat pulses (ms)"
default 2500 # milliseconds
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index c87a0a8bef26..62b9b581ce03 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -436,6 +436,7 @@ static int ct_write(struct intel_guc_ct *ct,
  */
 static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
 {
+   long timeout;
int err;
 
/*
@@ -443,10 +444,12 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No GuC command should ever take longer than 10ms.
 */
+   timeout = max(10, CONFIG_DRM_I915_GUC_CTB_TIMEOUT);
+
 #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
err = wait_for_us(done, 10);
if (err)
-   err = wait_for(done, 10);
+   err = wait_for(done, timeout);
 #undef done
 
if (unlikely(err))
-- 
2.28.0

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

[Intel-gfx] [PATCH 08/17] drm/i915/guc: Only rely on own CTB size

[Matthew Brost]

From: Michal Wajdeczko 

In upcoming GuC firmware, CTB size will be removed from the CTB
descriptor so we must keep it locally for any calculations.

While around, improve some debug messages and helpers.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 55 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 +
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 4cc8c0b71699..dbece569fbe4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -90,6 +90,24 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc,
desc->owner = CTB_OWNER_HOST;
 }
 
+static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
+{
+   guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
+}
+
+static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
+  struct guc_ct_buffer_desc *desc,
+  u32 *cmds, u32 size)
+{
+   GEM_BUG_ON(size % 4);
+
+   ctb->desc = desc;
+   ctb->cmds = cmds;
+   ctb->size = size;
+
+   guc_ct_buffer_reset(ctb, 0);
+}
+
 static int guc_action_register_ct_buffer(struct intel_guc *guc,
 u32 desc_addr,
 u32 type)
@@ -148,7 +166,10 @@ static int ct_deregister_buffer(struct intel_guc_ct *ct, 
u32 type)
 int intel_guc_ct_init(struct intel_guc_ct *ct)
 {
struct intel_guc *guc = ct_to_guc(ct);
+   struct guc_ct_buffer_desc *desc;
+   u32 blob_size;
void *blob;
+   u32 *cmds;
int err;
int i;
 
@@ -176,19 +197,24 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
 * other code will need updating as well.
 */
 
-   err = intel_guc_allocate_and_map_vma(guc, PAGE_SIZE, >vma, );
+   blob_size = PAGE_SIZE;
+   err = intel_guc_allocate_and_map_vma(guc, blob_size, >vma, );
if (unlikely(err)) {
-   CT_ERROR(ct, "Failed to allocate CT channel (err=%d)\n", err);
+   CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
+  blob_size, ERR_PTR(err));
return err;
}
 
-   CT_DEBUG(ct, "vma base=%#x\n", intel_guc_ggtt_offset(guc, ct->vma));
+   CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma), 
blob_size);
 
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i !=  CTB_SEND) && (i != CTB_RECV));
-   ct->ctbs[i].desc = blob + PAGE_SIZE/4 * i;
-   ct->ctbs[i].cmds = blob + PAGE_SIZE/4 * i + PAGE_SIZE/2;
+
+   desc = blob + PAGE_SIZE / 4 * i;
+   cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+
+   guc_ct_buffer_init(>ctbs[i], desc, cmds, PAGE_SIZE / 4);
}
 
return 0;
@@ -217,7 +243,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
 int intel_guc_ct_enable(struct intel_guc_ct *ct)
 {
struct intel_guc *guc = ct_to_guc(ct);
-   u32 base, cmds, size;
+   u32 base, cmds;
int err;
int i;
 
@@ -232,10 +258,11 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+
cmds = base + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
-   size = PAGE_SIZE / 4;
-   CT_DEBUG(ct, "%d: addr=%#x size=%u\n", i, cmds, size);
-   guc_ct_buffer_desc_init(ct->ctbs[i].desc, cmds, size);
+   CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
+
+   guc_ct_buffer_reset(>ctbs[i], cmds);
}
 
/*
@@ -259,7 +286,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 err_deregister:
ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
 err_out:
-   CT_PROBE_ERROR(ct, "Failed to open channel (err=%d)\n", err);
+   CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
return err;
 }
 
@@ -314,7 +341,7 @@ static int ct_write(struct intel_guc_ct *ct,
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
-   u32 size = desc->size;
+   u32 size = ctb->size;
u32 used;
u32 header;
u32 *cmds = ctb->cmds;
@@ -323,7 +350,7 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->is_in_error))
return -EPIPE;
 
-   if (unlikely(!IS_ALIGNED(head | tail | size, 4) ||
+   if (unlikely(!IS_ALIGNED(head | tail, 4) ||
 (tail | head) >= size))
goto corrupted;
 
@@ -530,7 +557,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)

[Intel-gfx] [PATCH 13/17] drm/i915/guc: Start protecting access to CTB descriptors

[Matthew Brost]

From: Michal Wajdeczko 

We want to stop using guc.send_mutex while sending CTB messages
so we have to start protecting access to CTB send descriptor.

For completeness protect also CTB receive descriptor.

Add spinlock to struct intel_guc_ct_buffer and start using it.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 --
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 62b9b581ce03..e44f06fbf87a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -89,6 +89,8 @@ static void ct_incoming_request_worker_func(struct 
work_struct *w);
  */
 void intel_guc_ct_init_early(struct intel_guc_ct *ct)
 {
+   spin_lock_init(>ctbs.send.lock);
+   spin_lock_init(>ctbs.recv.lock);
spin_lock_init(>requests.lock);
INIT_LIST_HEAD(>requests.pending);
INIT_LIST_HEAD(>requests.incoming);
@@ -476,17 +478,22 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
 
+   spin_lock_irqsave(>ctbs.send.lock, flags);
+
fence = ct_get_next_fence(ct);
request.fence = fence;
request.status = 0;
request.response_len = response_buf_size;
request.response_buf = response_buf;
 
-   spin_lock_irqsave(>requests.lock, flags);
+   spin_lock(>requests.lock);
list_add_tail(, >requests.pending);
-   spin_unlock_irqrestore(>requests.lock, flags);
+   spin_unlock(>requests.lock);
 
err = ct_write(ct, action, len, fence);
+
+   spin_unlock_irqrestore(>ctbs.send.lock, flags);
+
if (unlikely(err))
goto unlink;
 
@@ -822,6 +829,7 @@ static int ct_handle_request(struct intel_guc_ct *ct, const 
u32 *msg)
 void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
 {
u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
+   unsigned long flags;
int err = 0;
 
if (unlikely(!ct->enabled)) {
@@ -830,7 +838,9 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
}
 
do {
+   spin_lock_irqsave(>ctbs.recv.lock, flags);
err = ct_read(ct, msg);
+   spin_unlock_irqrestore(>ctbs.recv.lock, flags);
if (err)
break;
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index fc9486779e87..bc52dc479a14 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -27,11 +27,13 @@ struct intel_guc;
  * record (command transport buffer descriptor) and the actual buffer which
  * holds the commands.
  *
+ * @lock: protects access to the commands buffer and buffer descriptor
  * @desc: pointer to the buffer descriptor
  * @cmds: pointer to the commands buffer
  * @size: size of the commands buffer
  */
 struct intel_guc_ct_buffer {
+   spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
-- 
2.28.0

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

[Intel-gfx] [PATCH 11/17] drm/i915/guc: Update sizes of CTB buffers

[Matthew Brost]

From: Michal Wajdeczko 

Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ---
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index c54a29176862..c87a0a8bef26 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct 
intel_guc_ct *ct)
 #define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__);
 
+/**
+ * DOC: CTB Blob
+ *
+ * We allocate single blob to hold both CTB descriptors and buffers:
+ *
+ *  ++---+--+
+ *  | offset | contents  | size |
+ *  ++===+==+
+ *  | 0x | H2G `CTB Descriptor`_ (send)  |  |
+ *  ++---+  4K  |
+ *  | 0x0800 | G2H `CTB Descriptor`_ (recv)  |  |
+ *  ++---+--+
+ *  | 0x1000 | H2G `CT Buffer`_ (send)   | n*4K |
+ *  ||   |  |
+ *  ++---+--+
+ *  | 0x1000 | G2H `CT Buffer`_ (recv)   | m*4K |
+ *  | + n*4K |   |  |
+ *  ++---+--+
+ *
+ * Size of each `CT Buffer`_ must be multiple of 4K.
+ * As we don't expect too many messages, for now use minimum sizes.
+ */
+#define CTB_DESC_SIZE  ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
+#define CTB_H2G_BUFFER_SIZE(SZ_4K)
+#define CTB_G2H_BUFFER_SIZE(SZ_4K)
+
 struct ct_request {
struct list_head link;
u32 fence;
@@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
 
GEM_BUG_ON(ct->vma);
 
-   /* We allocate 1 page to hold both descriptors and both buffers.
-*   ___.
-*  |desc (SEND)|   :
-*  |___|   PAGE/4
-*  :___:
-*  |desc (RECV)|   :
-*  |___|   PAGE/4
-*  :___:
-*  |cmds (SEND)|
-*  |   PAGE/4
-*  |___|
-*  |cmds (RECV)|
-*  |   PAGE/4
-*  |___|
-*
-* Each message can use a maximum of 32 dwords and we don't expect to
-* have more than 1 in flight at any time, so we have enough space.
-* Some logic further ahead will rely on the fact that there is only 1
-* page and that it is always mapped, so if the size is changed the
-* other code will need updating as well.
-*/
-
-   blob_size = PAGE_SIZE;
+   blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE + 
CTB_G2H_BUFFER_SIZE;
err = intel_guc_allocate_and_map_vma(guc, blob_size, >vma, );
if (unlikely(err)) {
CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
@@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
 
/* store pointers to desc and cmds for send ctb */
desc = blob;
-   cmds = blob + PAGE_SIZE / 2;
-   cmds_size = PAGE_SIZE / 4;
+   cmds = blob + 2 * CTB_DESC_SIZE;
+   cmds_size = CTB_H2G_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
 
guc_ct_buffer_init(>ctbs.send, desc, cmds, cmds_size);
 
/* store pointers to desc and cmds for recv ctb */
-   desc = blob + PAGE_SIZE / 4;
-   cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
-   cmds_size = PAGE_SIZE / 4;
+   desc = blob + CTB_DESC_SIZE;
+   cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
+   cmds_size = CTB_G2H_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "recv",
 ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
 
-- 
2.28.0

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

[Intel-gfx] [PATCH 10/17] drm/i915/guc: Replace CTB array with explicit members

[Matthew Brost]

From: Michal Wajdeczko 

Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 46 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  7 +++-
 2 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fbd6bd20f588..c54a29176862 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -168,10 +168,10 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
struct intel_guc *guc = ct_to_guc(ct);
struct guc_ct_buffer_desc *desc;
u32 blob_size;
+   u32 cmds_size;
void *blob;
u32 *cmds;
int err;
-   int i;
 
GEM_BUG_ON(ct->vma);
 
@@ -207,15 +207,23 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
 
CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma), 
blob_size);
 
-   /* store pointers to desc and cmds */
-   for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
-   GEM_BUG_ON((i !=  CTB_SEND) && (i != CTB_RECV));
+   /* store pointers to desc and cmds for send ctb */
+   desc = blob;
+   cmds = blob + PAGE_SIZE / 2;
+   cmds_size = PAGE_SIZE / 4;
+   CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
 
-   desc = blob + PAGE_SIZE / 4 * i;
-   cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+   guc_ct_buffer_init(>ctbs.send, desc, cmds, cmds_size);
 
-   guc_ct_buffer_init(>ctbs[i], desc, cmds, PAGE_SIZE / 4);
-   }
+   /* store pointers to desc and cmds for recv ctb */
+   desc = blob + PAGE_SIZE / 4;
+   cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
+   cmds_size = PAGE_SIZE / 4;
+   CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "recv",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
+
+   guc_ct_buffer_init(>ctbs.recv, desc, cmds, cmds_size);
 
return 0;
 }
@@ -246,7 +254,6 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
u32 base, cmds;
void *blob;
int err;
-   int i;
 
GEM_BUG_ON(ct->enabled);
 
@@ -257,28 +264,25 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 
/* blob should start with send descriptor */
blob = __px_vaddr(ct->vma->obj);
-   GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+   GEM_BUG_ON(blob != ct->ctbs.send.desc);
 
/* (re)initialize descriptors */
-   for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
-   GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+   cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+   guc_ct_buffer_reset(>ctbs.send, cmds);
 
-   cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
-   CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
-
-   guc_ct_buffer_reset(>ctbs[i], cmds);
-   }
+   cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+   guc_ct_buffer_reset(>ctbs.recv, cmds);
 
/*
 * Register both CT buffers starting with RECV buffer.
 * Descriptors are in first half of the blob.
 */
-   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc, 
blob),
+   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
 INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
 
-   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc, 
blob),
+   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
 INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
@@ -341,7 +345,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 len /* in dwords */,
u32 fence)
 {
-   struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
+   struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
@@ -557,7 +561,7 @@ static inline bool ct_header_is_response(u32 header)
 
 static int ct_read(struct intel_guc_ct *ct, u32 *data)
 {
-   struct intel_guc_ct_buffer *ctb = >ctbs[CTB_RECV];
+   struct intel_guc_ct_buffer *ctb = >ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 4009e2dd0de4..fc9486779e87 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h

[Intel-gfx] [PATCH 06/17] drm/i915/guc: Stop using fence/status from CTB descriptor

[Matthew Brost]

From: Michal Wajdeczko 

Stop using fence/status from CTB descriptor as future GuC ABI will
no longer support replies over CTB descriptor.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h |  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 72 ++-
 2 files changed, 6 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index ebd8c3e0e4bb..d38935f47ecf 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -71,8 +71,8 @@ struct guc_ct_buffer_desc {
u32 head;   /* offset updated by GuC*/
u32 tail;   /* offset updated by owner */
u32 is_in_error;/* error indicator */
-   u32 fence;  /* fence updated by GuC */
-   u32 status; /* status updated by GuC */
+   u32 reserved1;
+   u32 reserved2;
u32 owner;  /* id of the channel owner */
u32 owner_sub_id;   /* owner-defined field for extra tracking */
u32 reserved[5];
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 25618649048f..4cc8c0b71699 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -90,13 +90,6 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc,
desc->owner = CTB_OWNER_HOST;
 }
 
-static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
-{
-   desc->head = 0;
-   desc->tail = 0;
-   desc->is_in_error = 0;
-}
-
 static int guc_action_register_ct_buffer(struct intel_guc *guc,
 u32 desc_addr,
 u32 type)
@@ -315,8 +308,7 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
 static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
-   u32 fence,
-   bool want_response)
+   u32 fence)
 {
struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -360,8 +352,7 @@ static int ct_write(struct intel_guc_ct *ct,
 * DW2+: action data
 */
header = (len << GUC_CT_MSG_LEN_SHIFT) |
-(GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
-(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
+GUC_CT_MSG_SEND_STATUS |
 (action[0] << GUC_CT_MSG_ACTION_SHIFT);
 
CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
@@ -390,56 +381,6 @@ static int ct_write(struct intel_guc_ct *ct,
return -EPIPE;
 }
 
-/**
- * wait_for_ctb_desc_update - Wait for the CT buffer descriptor update.
- * @desc:  buffer descriptor
- * @fence: response fence
- * @status:placeholder for status
- *
- * Guc will update CT buffer descriptor with new fence and status
- * after processing the command identified by the fence. Wait for
- * specified fence and then read from the descriptor status of the
- * command.
- *
- * Return:
- * *   0 response received (status is valid)
- * *   -ETIMEDOUT no response within hardcoded timeout
- * *   -EPROTO no response, CT buffer is in error
- */
-static int wait_for_ctb_desc_update(struct guc_ct_buffer_desc *desc,
-   u32 fence,
-   u32 *status)
-{
-   int err;
-
-   /*
-* Fast commands should complete in less than 10us, so sample quickly
-* up to that length of time, then switch to a slower sleep-wait loop.
-* No GuC command should ever take longer than 10ms.
-*/
-#define done (READ_ONCE(desc->fence) == fence)
-   err = wait_for_us(done, 10);
-   if (err)
-   err = wait_for(done, 10);
-#undef done
-
-   if (unlikely(err)) {
-   DRM_ERROR("CT: fence %u failed; reported fence=%u\n",
- fence, desc->fence);
-
-   if (WARN_ON(desc->is_in_error)) {
-   /* Something went wrong with the messaging, try to reset
-* the buffer and hope for the best
-*/
-   guc_ct_buffer_desc_reset(desc);
-   err = -EPROTO;
-   }
-   }
-
-   *status = desc->status;
-   return err;
-}
-
 /**
  * wait_for_ct_request_update - Wait for CT request state update.
  * @req:   pointer to pending request
@@ -483,8 +424,6 @@ static int ct_send(struct intel_guc_ct *ct,
   u32 response_buf_size,
   u32 *status)
 {
-   struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
-   struct guc_ct_buffer_desc *desc = ctb->desc;
struct 

[Intel-gfx] [PATCH 09/17] drm/i915/guc: Don't repeat CTB layout calculations

[Matthew Brost]

From: Michal Wajdeczko 

We can retrieve offsets to cmds buffers and descriptor from
actual pointers that we already keep locally.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index dbece569fbe4..fbd6bd20f588 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -244,6 +244,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 {
struct intel_guc *guc = ct_to_guc(ct);
u32 base, cmds;
+   void *blob;
int err;
int i;
 
@@ -251,15 +252,18 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 
/* vma should be already allocated and map'ed */
GEM_BUG_ON(!ct->vma);
+   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(ct->vma->obj));
base = intel_guc_ggtt_offset(guc, ct->vma);
 
-   /* (re)initialize descriptors
-* cmds buffers are in the second half of the blob page
-*/
+   /* blob should start with send descriptor */
+   blob = __px_vaddr(ct->vma->obj);
+   GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+
+   /* (re)initialize descriptors */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
 
-   cmds = base + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+   cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
 
guc_ct_buffer_reset(>ctbs[i], cmds);
@@ -269,12 +273,12 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 * Register both CT buffers starting with RECV buffer.
 * Descriptors are in first half of the blob.
 */
-   err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_RECV,
+   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc, 
blob),
 INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
 
-   err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_SEND,
+   err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc, 
blob),
 INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
-- 
2.28.0

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

[Intel-gfx] [PATCH 07/17] drm/i915: Promote ptrdiff() to i915_utils.h

[Matthew Brost]

From: Michal Wajdeczko 

Generic helpers should be placed in i915_utils.h.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/i915_utils.h | 5 +
 drivers/gpu/drm/i915/i915_vma.h   | 5 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index f02f52ab5070..5259edacde38 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -201,6 +201,11 @@ __check_struct_size(size_t base, size_t arr, size_t count, 
size_t *size)
__T;\
 })
 
+static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
+{
+   return a - b;
+}
+
 /*
  * container_of_user: Extract the superclass from a pointer to a member.
  *
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index dc6926d89626..eca452a9851f 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -151,11 +151,6 @@ static inline void i915_vma_put(struct i915_vma *vma)
i915_gem_object_put(vma->obj);
 }
 
-static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
-{
-   return a - b;
-}
-
 static inline long
 i915_vma_compare(struct i915_vma *vma,
 struct i915_address_space *vm,
-- 
2.28.0

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

[Intel-gfx] [PATCH 03/17] drm/i915/guc: enable only the user interrupt when using GuC submission

[Matthew Brost]

From: Daniele Ceraolo Spurio 

In GuC submission mode the CS is owned by the GuC FW, so all CS status
interrupts are handled by it. We only need the user interrupt as that
signals request completion.

Since we're now starting the engines directly in GuC submission mode
when selected, we can stop switching back and forth between the
execlists and the GuC programming and select directly the correct
interrupt mask.

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
Cc: John Harrison 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c| 18 ++-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 ---
 2 files changed, 11 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index d29126c458ba..f88c10366e58 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -194,14 +194,18 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
 
 void gen11_gt_irq_postinstall(struct intel_gt *gt)
 {
-   const u32 irqs =
-   GT_CS_MASTER_ERROR_INTERRUPT |
-   GT_RENDER_USER_INTERRUPT |
-   GT_CONTEXT_SWITCH_INTERRUPT |
-   GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
-   const u32 dmask = irqs << 16 | irqs;
-   const u32 smask = irqs << 16;
+   u32 irqs = GT_RENDER_USER_INTERRUPT;
+   u32 dmask;
+   u32 smask;
+
+   if (!intel_uc_wants_guc_submission(>uc))
+   irqs |= GT_CS_MASTER_ERROR_INTERRUPT |
+   GT_CONTEXT_SWITCH_INTERRUPT |
+   GT_WAIT_SEMAPHORE_INTERRUPT;
+
+   dmask = irqs << 16 | irqs;
+   smask = irqs << 16;
 
BUILD_BUG_ON(irqs & 0x);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 335719f17490..38cda5d599a6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -432,32 +432,6 @@ void intel_guc_submission_fini(struct intel_guc *guc)
}
 }
 
-static void guc_interrupts_capture(struct intel_gt *gt)
-{
-   struct intel_uncore *uncore = gt->uncore;
-   u32 irqs = GT_CONTEXT_SWITCH_INTERRUPT;
-   u32 dmask = irqs << 16 | irqs;
-
-   GEM_BUG_ON(INTEL_GEN(gt->i915) < 11);
-
-   /* Don't handle the ctx switch interrupt in GuC submission mode */
-   intel_uncore_rmw(uncore, GEN11_RENDER_COPY_INTR_ENABLE, dmask, 0);
-   intel_uncore_rmw(uncore, GEN11_VCS_VECS_INTR_ENABLE, dmask, 0);
-}
-
-static void guc_interrupts_release(struct intel_gt *gt)
-{
-   struct intel_uncore *uncore = gt->uncore;
-   u32 irqs = GT_CONTEXT_SWITCH_INTERRUPT;
-   u32 dmask = irqs << 16 | irqs;
-
-   GEM_BUG_ON(INTEL_GEN(gt->i915) < 11);
-
-   /* Handle ctx switch interrupts again */
-   intel_uncore_rmw(uncore, GEN11_RENDER_COPY_INTR_ENABLE, 0, dmask);
-   intel_uncore_rmw(uncore, GEN11_VCS_VECS_INTR_ENABLE, 0, dmask);
-}
-
 static int guc_context_alloc(struct intel_context *ce)
 {
return lrc_alloc(ce, ce->engine);
@@ -722,9 +696,6 @@ int intel_guc_submission_setup(struct intel_engine_cs 
*engine)
 void intel_guc_submission_enable(struct intel_guc *guc)
 {
guc_stage_desc_init(guc);
-
-   /* Take over from manual control of ELSP (execlists) */
-   guc_interrupts_capture(guc_to_gt(guc));
 }
 
 void intel_guc_submission_disable(struct intel_guc *guc)
@@ -735,8 +706,6 @@ void intel_guc_submission_disable(struct intel_guc *guc)
 
/* Note: By the time we're here, GuC may have already been reset */
 
-   guc_interrupts_release(gt);
-
guc_stage_desc_fini(guc);
 }
 
-- 
2.28.0

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

[Intel-gfx] [PATCH 05/17] drm/i915/guc: Keep strict GuC ABI definitions

[Matthew Brost]

From: Michal Wajdeczko 

Our fwif.h file is now mix of strict firmware ABI definitions and
set of our helpers. In anticipation of upcoming changes to the GuC
interface try to keep them separate in smaller maintainable files.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Reviewed-by: Michał Winiarski 
---
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  51 +
 .../gt/uc/abi/guc_communication_ctb_abi.h | 106 +
 .../gt/uc/abi/guc_communication_mmio_abi.h|  52 +
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |  14 ++
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h |  21 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   | 203 +-
 6 files changed, 250 insertions(+), 197 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
new file mode 100644
index ..90efef8a73e4
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2014-2021 Intel Corporation
+ */
+
+#ifndef _ABI_GUC_ACTIONS_ABI_H
+#define _ABI_GUC_ACTIONS_ABI_H
+
+enum intel_guc_action {
+   INTEL_GUC_ACTION_DEFAULT = 0x0,
+   INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
+   INTEL_GUC_ACTION_REQUEST_ENGINE_RESET = 0x3,
+   INTEL_GUC_ACTION_ALLOCATE_DOORBELL = 0x10,
+   INTEL_GUC_ACTION_DEALLOCATE_DOORBELL = 0x20,
+   INTEL_GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE = 0x30,
+   INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x40,
+   INTEL_GUC_ACTION_FORCE_LOG_BUFFER_FLUSH = 0x302,
+   INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
+   INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
+   INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
+   INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+   INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
+   INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
+   INTEL_GUC_ACTION_LIMIT
+};
+
+enum intel_guc_preempt_options {
+   INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q = 0x4,
+   INTEL_GUC_PREEMPT_OPTION_DROP_SUBMIT_Q = 0x8,
+};
+
+enum intel_guc_report_status {
+   INTEL_GUC_REPORT_STATUS_UNKNOWN = 0x0,
+   INTEL_GUC_REPORT_STATUS_ACKED = 0x1,
+   INTEL_GUC_REPORT_STATUS_ERROR = 0x2,
+   INTEL_GUC_REPORT_STATUS_COMPLETE = 0x4,
+};
+
+enum intel_guc_sleep_state_status {
+   INTEL_GUC_SLEEP_STATE_SUCCESS = 0x1,
+   INTEL_GUC_SLEEP_STATE_PREEMPT_TO_IDLE_FAILED = 0x2,
+   INTEL_GUC_SLEEP_STATE_ENGINE_RESET_FAILED = 0x3
+#define INTEL_GUC_SLEEP_STATE_INVALID_MASK 0x8000
+};
+
+#define GUC_LOG_CONTROL_LOGGING_ENABLED(1 << 0)
+#define GUC_LOG_CONTROL_VERBOSITY_SHIFT4
+#define GUC_LOG_CONTROL_VERBOSITY_MASK (0xF << GUC_LOG_CONTROL_VERBOSITY_SHIFT)
+#define GUC_LOG_CONTROL_DEFAULT_LOGGING(1 << 8)
+
+#endif /* _ABI_GUC_ACTIONS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
new file mode 100644
index ..ebd8c3e0e4bb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2014-2021 Intel Corporation
+ */
+
+#ifndef _ABI_GUC_COMMUNICATION_CTB_ABI_H
+#define _ABI_GUC_COMMUNICATION_CTB_ABI_H
+
+#include 
+
+/**
+ * DOC: CTB based communication
+ *
+ * The CTB (command transport buffer) communication between Host and GuC
+ * is based on u32 data stream written to the shared buffer. One buffer can
+ * be used to transmit data only in one direction (one-directional channel).
+ *
+ * Current status of the each buffer is stored in the buffer descriptor.
+ * Buffer descriptor holds tail and head fields that represents active data
+ * stream. The tail field is updated by the data producer (sender), and head
+ * field is updated by the data consumer (receiver)::
+ *
+ *  ++
+ *  | DESCRIPTOR |  +=+++
+ *  ++  | | MESSAGE(s) ||
+ *  | address|->+=+++
+ *  ++
+ *  | head   |  ^-head^
+ *  ++
+ *  | tail   |  ^-tail-^
+ *  ++
+ *  | size   |  ^---size^
+ *  ++
+ *
+ * Each message in data stream starts with the single u32 treated as a header,
+ * followed by optional set of u32 data that makes message specific payload::
+ *

[Intel-gfx] [PATCH 01/17] drm/i915/guc: skip disabling CTBs before sanitizing the GuC

[Matthew Brost]

From: Daniele Ceraolo Spurio 

If we're about to sanitize the GuC, something might have going wrong
beforehand, so we should avoid trying to talk to it. Even if GuC is
still running fine, the sanitize will reset its internal state and clear
the CTB registration, so there is still no need to explicitly do so.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/2469
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
Reviewed-by: Matthew Brost 
Cc: Michal Wajdeczko 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6abb8f2dc33d..892c1315ce49 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -504,7 +504,7 @@ static int __uc_init_hw(struct intel_uc *uc)
 
ret = intel_guc_sample_forcewake(guc);
if (ret)
-   goto err_communication;
+   goto err_log_capture;
 
if (intel_uc_uses_guc_submission(uc))
intel_guc_submission_enable(guc);
@@ -529,8 +529,6 @@ static int __uc_init_hw(struct intel_uc *uc)
/*
 * We've failed to load the firmware :(
 */
-err_communication:
-   guc_disable_communication(guc);
 err_log_capture:
__uc_capture_load_err_log(uc);
 err_out:
@@ -558,9 +556,6 @@ static void __uc_fini_hw(struct intel_uc *uc)
if (intel_uc_uses_guc_submission(uc))
intel_guc_submission_disable(guc);
 
-   if (guc_communication_enabled(guc))
-   guc_disable_communication(guc);
-
__uc_sanitize(uc);
 }
 
@@ -577,7 +572,6 @@ void intel_uc_reset_prepare(struct intel_uc *uc)
if (!intel_guc_is_ready(guc))
return;
 
-   guc_disable_communication(guc);
__uc_sanitize(uc);
 }
 
-- 
2.28.0

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

[Intel-gfx] [PATCH 00/17] Non-interface changing GuC CTBs updates

[Matthew Brost]

As discussed in [1] we are breaking that large series into a several
smaller ones. This series is the non-interface changing part of step #2
- it makes all the changes needed before updating the GuC firwmare to a
new version without breaking any old interfaces.

A follow on series will be squashed into a single patch that updates the
GuC firmware + the required interface changes.

Patch number #12 needs an Ack from Michal Wajdeczko.
Patch number #14 needs a review.

[1] https://patchwork.freedesktop.org/series/89844/

Signed-off-by: Matthew Brost 

Daniele Ceraolo Spurio (3):
  drm/i915/guc: skip disabling CTBs before sanitizing the GuC
  drm/i915/guc: use probe_error log for CT enablement failure
  drm/i915/guc: enable only the user interrupt when using GuC submission

Matthew Brost (1):
  drm/i915/guc: Ensure H2G buffer updates visible before tail update

Michal Wajdeczko (12):
  drm/i915/guc: Keep strict GuC ABI definitions
  drm/i915/guc: Stop using fence/status from CTB descriptor
  drm/i915: Promote ptrdiff() to i915_utils.h
  drm/i915/guc: Only rely on own CTB size
  drm/i915/guc: Don't repeat CTB layout calculations
  drm/i915/guc: Replace CTB array with explicit members
  drm/i915/guc: Update sizes of CTB buffers
  drm/i915/guc: Relax CTB response timeout
  drm/i915/guc: Start protecting access to CTB descriptors
  drm/i915/guc: Stop using mutex while sending CTB messages
  drm/i915/guc: Don't receive all G2H messages in irq handler
  drm/i915/guc: Always copy CT message to new allocation

Rodrigo Vivi (1):
  drm/i915/guc: Remove sample_forcewake h2g action

 drivers/gpu/drm/i915/Kconfig.profile  |   9 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  18 +-
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  51 ++
 .../gt/uc/abi/guc_communication_ctb_abi.h | 106 
 .../gt/uc/abi/guc_communication_mmio_abi.h|  52 ++
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |  14 +
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h |  21 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  16 -
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|   1 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 527 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  14 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   | 207 +--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  31 --
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  10 -
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 drivers/gpu/drm/i915/i915_vma.h   |   5 -
 16 files changed, 596 insertions(+), 491 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h

-- 
2.28.0

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

[Intel-gfx] [PATCH 04/17] drm/i915/guc: Remove sample_forcewake h2g action

[Matthew Brost]

From: Rodrigo Vivi 

This action is no-op in the GuC side for a few versions already
and it is getting entirely removed soon, in an upcoming version.

Time to remove before we face communication issues.

Cc:  Vinay Belgaumkar 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Matthew Brost 
Acked-by: Michal Wajdeczko 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c  | 16 
 drivers/gpu/drm/i915/gt/uc/intel_guc.h  |  1 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  4 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c   |  4 
 4 files changed, 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index adae04c47aab..ab2c8fe8cdfa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -469,22 +469,6 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc 
*guc,
return 0;
 }
 
-int intel_guc_sample_forcewake(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_gt(guc)->i915;
-   u32 action[2];
-
-   action[0] = INTEL_GUC_ACTION_SAMPLE_FORCEWAKE;
-   /* WaRsDisableCoarsePowerGating:skl,cnl */
-   if (!HAS_RC6(dev_priv) || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
-   action[1] = 0;
-   else
-   /* bit 0 and 1 are for Render and Media domain separately */
-   action[1] = GUC_FORCEWAKE_RENDER | GUC_FORCEWAKE_MEDIA;
-
-   return intel_guc_send(guc, action, ARRAY_SIZE(action));
-}
-
 /**
  * intel_guc_auth_huc() - Send action to GuC to authenticate HuC ucode
  * @guc: intel_guc structure
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index bc2ba7d0626c..c20f3839de12 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -128,7 +128,6 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
u32 *response_buf, u32 response_buf_size);
 int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
   const u32 *payload, u32 len);
-int intel_guc_sample_forcewake(struct intel_guc *guc);
 int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
 int intel_guc_suspend(struct intel_guc *guc);
 int intel_guc_resume(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 79c560d9c0b6..0f9afcde1d0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -302,9 +302,6 @@ struct guc_ct_buffer_desc {
 #define GUC_CT_MSG_ACTION_SHIFT16
 #define GUC_CT_MSG_ACTION_MASK 0x
 
-#define GUC_FORCEWAKE_RENDER   (1 << 0)
-#define GUC_FORCEWAKE_MEDIA(1 << 1)
-
 #define GUC_POWER_UNSPECIFIED  0
 #define GUC_POWER_D0   1
 #define GUC_POWER_D1   2
@@ -558,7 +555,6 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
-   INTEL_GUC_ACTION_SAMPLE_FORCEWAKE = 0x3005,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 892c1315ce49..ab0789d66e06 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -502,10 +502,6 @@ static int __uc_init_hw(struct intel_uc *uc)
 
intel_huc_auth(huc);
 
-   ret = intel_guc_sample_forcewake(guc);
-   if (ret)
-   goto err_log_capture;
-
if (intel_uc_uses_guc_submission(uc))
intel_guc_submission_enable(guc);
 
-- 
2.28.0

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

[Intel-gfx] [PATCH 02/17] drm/i915/guc: use probe_error log for CT enablement failure

[Matthew Brost]

From: Daniele Ceraolo Spurio 

We have a couple of failure injection points in the CT enablement path,
so we need to use i915_probe_error() to select the appropriate log level.
A new macro (CT_PROBE_ERROR) has been added to the set of CT logging
macros to be used in this scenario and upcoming ones.

While adding the new macros, fix the underlying logging mechanics used
by the existing ones (DRM_DEV_* -> drm_*) and move the inlines to
before they're used inside the macros.

Signed-off-by: Matthew Brost 
Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 48 ---
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fa9e048cc65f..25618649048f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -7,14 +7,36 @@
 #include "intel_guc_ct.h"
 #include "gt/intel_gt.h"
 
+static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
+{
+   return container_of(ct, struct intel_guc, ct);
+}
+
+static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)
+{
+   return guc_to_gt(ct_to_guc(ct));
+}
+
+static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
+{
+   return ct_to_gt(ct)->i915;
+}
+
+static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
+{
+   return _to_i915(ct)->drm;
+}
+
 #define CT_ERROR(_ct, _fmt, ...) \
-   DRM_DEV_ERROR(ct_to_dev(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
 #ifdef CONFIG_DRM_I915_DEBUG_GUC
 #define CT_DEBUG(_ct, _fmt, ...) \
-   DRM_DEV_DEBUG_DRIVER(ct_to_dev(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
 #else
 #define CT_DEBUG(...)  do { } while (0)
 #endif
+#define CT_PROBE_ERROR(_ct, _fmt, ...) \
+   i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__);
 
 struct ct_request {
struct list_head link;
@@ -47,26 +69,6 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
 }
 
-static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
-{
-   return container_of(ct, struct intel_guc, ct);
-}
-
-static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)
-{
-   return guc_to_gt(ct_to_guc(ct));
-}
-
-static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
-{
-   return ct_to_gt(ct)->i915;
-}
-
-static inline struct device *ct_to_dev(struct intel_guc_ct *ct)
-{
-   return ct_to_i915(ct)->drm.dev;
-}
-
 static inline const char *guc_ct_buffer_type_to_str(u32 type)
 {
switch (type) {
@@ -264,7 +266,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
 err_deregister:
ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
 err_out:
-   CT_ERROR(ct, "Failed to open open CT channel (err=%d)\n", err);
+   CT_PROBE_ERROR(ct, "Failed to open channel (err=%d)\n", err);
return err;
 }
 
-- 
2.28.0

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

Re: [Intel-gfx] [PATCH v4 09/17] drm/i915/pxp: Implement arb session teardown

[kernel test robot]

Hi Daniele,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next char-misc/char-misc-testing v5.13-rc3 
next-20210525]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Daniele-Ceraolo-Spurio/drm-i915-Introduce-Intel-PXP/20210525-135106
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/b3c322331aa6685d40bb5b4cbf90b1d8ed48c9e0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Daniele-Ceraolo-Spurio/drm-i915-Introduce-Intel-PXP/20210525-135106
git checkout b3c322331aa6685d40bb5b4cbf90b1d8ed48c9e0
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c:94:5: error: no previous prototype 
>> for 'intel_pxp_terminate_session' [-Werror=missing-prototypes]
  94 | int intel_pxp_terminate_session(struct intel_pxp *pxp, u32 id)
 | ^~~
   cc1: all warnings being treated as errors


vim +/intel_pxp_terminate_session +94 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c

93  
  > 94  int intel_pxp_terminate_session(struct intel_pxp *pxp, u32 id)
95  {
96  struct i915_request *rq;
97  struct intel_context *ce = pxp->ce;
98  u32 *cs;
99  int err;
   100  
   101  if (!intel_pxp_is_enabled(pxp))
   102  return 0;
   103  
   104  rq = i915_request_create(ce);
   105  if (IS_ERR(rq))
   106  return PTR_ERR(rq);
   107  
   108  if (ce->engine->emit_init_breadcrumb) {
   109  err = ce->engine->emit_init_breadcrumb(rq);
   110  if (err)
   111  goto out_rq;
   112  }
   113  
   114  cs = intel_ring_begin(rq, SESSION_TERMINATION_LEN(1) + 
WAIT_LEN);
   115  if (IS_ERR(cs)) {
   116  err = PTR_ERR(cs);
   117  goto out_rq;
   118  }
   119  
   120  cs = pxp_emit_session_termination(cs, id);
   121  cs = pxp_emit_wait(cs);
   122  
   123  intel_ring_advance(rq, cs);
   124  
   125  out_rq:
   126  i915_request_get(rq);
   127  
   128  if (unlikely(err))
   129  i915_request_set_error_once(rq, err);
   130  
   131  pxp_request_commit(rq);
   132  
   133  if (!err && i915_request_wait(rq, 0, HZ / 5) < 0)
   134  err = -ETIME;
   135  
   136  i915_request_put(rq);
   137  
   138  return err;
   139  }
   140  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove the repeated declaration

[Patchwork]

== Series Details ==

Series: drm/i915: Remove the repeated declaration
URL   : https://patchwork.freedesktop.org/series/90524/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10131_full -> Patchwork_20187_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_10131_full and 
Patchwork_20187_full:

### New IGT tests (1) ###

  * igt@i915_pm_lpsp@kms-lpsp:
- Statuses :
- Exec time: [None] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2842]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#3468])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-iclb1/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-iclb8/igt@gem_mmap_...@cpuset-basic-small-copy.html
- shard-kbl:  [PASS][10] -> [INCOMPLETE][11] ([i915#3468])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-tglb: [PASS][12] -> [INCOMPLETE][13] ([i915#2910] / 
[i915#3468])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-tglb8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2428])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-xy:
- shard-apl:  [PASS][16] -> [INCOMPLETE][17] ([i915#3468])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-apl2/igt@gem_mmap_...@cpuset-medium-copy-xy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-apl7/igt@gem_mmap_...@cpuset-medium-copy-xy.html

  * igt@gem_mmap_offset@clear:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#3160])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-skl3/igt@gem_mmap_off...@clear.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-skl1/igt@gem_mmap_off...@clear.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][20] -> [DMESG-WARN][21] ([i915#1436] / 
[i915#716])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-skl5/igt@gen9_exec_pa...@allowed-single.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-skl5/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@batch-invalid-length:
- shard-snb:  NOTRUN -> [SKIP][22] ([fdo#109271]) +329 similar 
issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/shard-snb2/igt@gen9_exec_pa...@batch-invalid-length.html

  * igt@i915_pm_rpm@gem-execbuf-stress:
- shard-glk:  [PASS][23] -> [DMESG-WARN][24] ([i915#118] / 
[i915#95])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/shard-glk8/igt@i915_pm_...@gem-execbuf-stress.html
   [24]: 

Re: [Intel-gfx] [RFC PATCH 18/97] drm/i915/guc: Don't receive all G2H messages in irq handler

[Michal Wajdeczko]

On 25.05.2021 20:15, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko 
>>
>> In irq handler try to receive just single G2H message, let other
>> messages to be received from tasklet.
>>
>> Signed-off-by: Michal Wajdeczko 
>> Signed-off-by: Matthew Brost 
>> ---
>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---
>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  3 +
>>  2 files changed, 50 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index cb58fa7f970c..d630ec32decf 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -81,6 +81,7 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
>>  
>>  enum { CTB_OWNER_HOST = 0 };
>>  
>> +static void ct_receive_tasklet_func(unsigned long data);
>>  static void ct_incoming_request_worker_func(struct work_struct *w);
>>  
>>  /**
>> @@ -95,6 +96,7 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>>  INIT_LIST_HEAD(>requests.pending);
>>  INIT_LIST_HEAD(>requests.incoming);
>>  INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
>> +tasklet_init(>receive_tasklet, ct_receive_tasklet_func, (unsigned 
>> long)ct);
> 
> This function is deprecated. tasklet_setup should be used.
> I can fix this up when I post the CTB patches.

I didn't notice that, but yes, passing struct to callback will be
cleaner, so please fix it

Thanks,
Michal

> 
>>  }
>>  
>>  static inline const char *guc_ct_buffer_type_to_str(u32 type)
>> @@ -244,6 +246,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>>  {
>>  GEM_BUG_ON(ct->enabled);
>>  
>> +tasklet_kill(>receive_tasklet);
>>  i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
>>  memset(ct, 0, sizeof(*ct));
>>  }
>> @@ -629,7 +632,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>>  CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
>>  
>>  desc->head = head * 4;
>> -return 0;
>> +return available - len;
>>  
>>  corrupted:
>>  CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
>> @@ -665,10 +668,10 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
>> const u32 *msg)
>>  u32 status;
>>  u32 datalen;
>>  struct ct_request *req;
>> +unsigned long flags;
>>  bool found = false;
>>  
>>  GEM_BUG_ON(!ct_header_is_response(header));
>> -GEM_BUG_ON(!in_irq());
>>  
>>  /* Response payload shall at least include fence and status */
>>  if (unlikely(len < 2)) {
>> @@ -688,7 +691,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
>> const u32 *msg)
>>  
>>  CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
>>  
>> -spin_lock(>requests.lock);
>> +spin_lock_irqsave(>requests.lock, flags);
>>  list_for_each_entry(req, >requests.pending, link) {
>>  if (unlikely(fence != req->fence)) {
>>  CT_DEBUG(ct, "request %u awaits response\n",
>> @@ -707,7 +710,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
>> const u32 *msg)
>>  found = true;
>>  break;
>>  }
>> -spin_unlock(>requests.lock);
>> +spin_unlock_irqrestore(>requests.lock, flags);
>>  
>>  if (!found)
>>  CT_ERROR(ct, "Unsolicited response %*ph\n", msgsize, msg);
>> @@ -821,31 +824,55 @@ static int ct_handle_request(struct intel_guc_ct *ct, 
>> const u32 *msg)
>>  return 0;
>>  }
>>  
>> +static int ct_receive(struct intel_guc_ct *ct)
>> +{
>> +u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
>> +unsigned long flags;
>> +int ret;
>> +
>> +spin_lock_irqsave(>ctbs.recv.lock, flags);
>> +ret = ct_read(ct, msg);
>> +spin_unlock_irqrestore(>ctbs.recv.lock, flags);
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (ct_header_is_response(msg[0]))
>> +ct_handle_response(ct, msg);
>> +else
>> +ct_handle_request(ct, msg);
>> +
>> +return ret;
>> +}
>> +
>> +static void ct_try_receive_message(struct intel_guc_ct *ct)
>> +{
>> +int ret;
>> +
>> +if (GEM_WARN_ON(!ct->enabled))
>> +return;
>> +
>> +ret = ct_receive(ct);
>> +if (ret > 0)
>> +tasklet_hi_schedule(>receive_tasklet);
>> +}
>> +
>> +static void ct_receive_tasklet_func(unsigned long data)
>> +{
> 
> As mentioned above tasklet_init is deprecated. The callback now accepts
> the tasklet structure and ct can be looked up via container_of macro.
> 
> Everything else looks good.
> 
> With that and changing to the new tasklet API:
> Reviewed-by: Matthew Brost 
> 
>> +struct intel_guc_ct *ct = (struct intel_guc_ct *)data;
>> +
>> +ct_try_receive_message(ct);
>> +}
>> +
>>  /*
>>   * When we're communicating with the GuC over CT, GuC uses events
>>   * to notify us about new messages being posted on the RECV 

Re: [Intel-gfx] [RFC PATCH 15/97] drm/i915/guc: Relax CTB response timeout

[Michal Wajdeczko]

On 25.05.2021 20:08, Matthew Brost wrote:
> On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko 
>>
>> In upcoming patch we will allow more CTB requests to be sent in
>> parallel to the GuC for procesing, so we shouldn't assume any more
>> that GuC will always reply without 10ms.
>>
>> Use bigger value from CONFIG_DRM_I915_HEARTBEAT_INTERVAL instead.
>>
> 
> I think this should be its own config option or we combine it with a
> config option suggested in patch 37.
> 
> What do you think Michal? If you agree I can fix this up in the post of
> these patches.

+ Tvrtko

yep, use of dedicated GuC CONFIG is what we also agree internally,
existing HEARTBEAT_INTERVAL was just fastest way to bypass 10ms

so, yes, please go ahead and do it right

> 
> Matt
> 
>> Signed-off-by: Michal Wajdeczko 
>> Signed-off-by: Matthew Brost 
>> ---
>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index c87a0a8bef26..a4b2e7fe318b 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -436,17 +436,23 @@ static int ct_write(struct intel_guc_ct *ct,
>>   */
>>  static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
>>  {
>> +long timeout;
>>  int err;
>>  
>>  /*
>>   * Fast commands should complete in less than 10us, so sample quickly
>>   * up to that length of time, then switch to a slower sleep-wait loop.
>>   * No GuC command should ever take longer than 10ms.
>> + *
>> + * However, there might be other CT requests in flight before this one,
>> + * so use @CONFIG_DRM_I915_HEARTBEAT_INTERVAL as backup timeout value.
>>   */
>> +timeout = max(10, CONFIG_DRM_I915_HEARTBEAT_INTERVAL);
>> +
>>  #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
>>  err = wait_for_us(done, 10);
>>  if (err)
>> -err = wait_for(done, 10);
>> +err = wait_for(done, timeout);
>>  #undef done
>>  
>>  if (unlikely(err))
>> -- 
>> 2.28.0
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

[Daniel Vetter]

On Tue, May 25, 2021 at 9:19 PM Jason Ekstrand  wrote:
>
> On Tue, May 25, 2021 at 10:37 AM Daniel Vetter  wrote:
> >
> > On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> > > This patch is analogous to the previous sync file export patch in that
> > > it allows you to import a sync_file into a dma-buf.  Unlike the previous
> > > patch, however, this does add genuinely new functionality to dma-buf.
> > > Without this, the only way to attach a sync_file to a dma-buf is to
> > > submit a batch to your driver of choice which waits on the sync_file and
> > > claims to write to the dma-buf.  Even if said batch is a no-op, a submit
> > > is typically way more overhead than just attaching a fence.  A submit
> > > may also imply extra synchronization with other work because it happens
> > > on a hardware queue.
> > >
> > > In the Vulkan world, this is useful for dealing with the out-fence from
> > > vkQueuePresent.  Current Linux window-systems (X11, Wayland, etc.) all
> > > rely on dma-buf implicit sync.  Since Vulkan is an explicit sync API, we
> > > get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
> > > those as an exclusive (write) fence on the dma-buf.  We handle it in
> > > Mesa today with the above mentioned dummy submit trick.  This ioctl
> > > would allow us to set it directly without the dummy submit.
> > >
> > > This may also open up possibilities for GPU drivers to move away from
> > > implicit sync for their kernel driver uAPI and instead provide sync
> > > files and rely on dma-buf import/export for communicating with other
> > > implicit sync clients.
> > >
> > > We make the explicit choice here to only allow setting RW fences which
> > > translates to an exclusive fence on the dma_resv.  There's no use for
> > > read-only fences for communicating with other implicit sync userspace
> > > and any such attempts are likely to be racy at best.  When we got to
> > > insert the RW fence, the actual fence we set as the new exclusive fence
> > > is a combination of the sync_file provided by the user and all the other
> > > fences on the dma_resv.  This ensures that the newly added exclusive
> > > fence will never signal before the old one would have and ensures that
> > > we don't break any dma_resv contracts.  We require userspace to specify
> > > RW in the flags for symmetry with the export ioctl and in case we ever
> > > want to support read fences in the future.
> > >
> > > There is one downside here that's worth documenting:  If two clients
> > > writing to the same dma-buf using this API race with each other, their
> > > actions on the dma-buf may happen in parallel or in an undefined order.
> > > Both with and without this API, the pattern is the same:  Collect all
> > > the fences on dma-buf, submit work which depends on said fences, and
> > > then set a new exclusive (write) fence on the dma-buf which depends on
> > > said work.  The difference is that, when it's all handled by the GPU
> > > driver's submit ioctl, the three operations happen atomically under the
> > > dma_resv lock.  If two userspace submits race, one will happen before
> > > the other.  You aren't guaranteed which but you are guaranteed that
> > > they're strictly ordered.  If userspace manages the fences itself, then
> > > these three operations happen separately and the two render operations
> > > may happen genuinely in parallel or get interleaved.  However, this is a
> > > case of userspace racing with itself.  As long as we ensure userspace
> > > can't back the kernel into a corner, it should be fine.
> > >
> > > v2 (Jason Ekstrand):
> > >  - Use a wrapper dma_fence_array of all fences including the new one
> > >when importing an exclusive fence.
> > >
> > > v3 (Jason Ekstrand):
> > >  - Lock around setting shared fences as well as exclusive
> > >  - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> > >  - Initialize ret to 0 in dma_buf_wait_sync_file
> > >
> > > v4 (Jason Ekstrand):
> > >  - Use the new dma_resv_get_singleton helper
> > >
> > > v5 (Jason Ekstrand):
> > >  - Rename the IOCTLs to import/export rather than wait/signal
> > >  - Drop the WRITE flag and always get/set the exclusive fence
> > >
> > > v5 (Jason Ekstrand):
> > >  - Split import and export into separate patches
> > >  - New commit message
> > >
> > > Signed-off-by: Jason Ekstrand 
> > > ---
> > >  drivers/dma-buf/dma-buf.c| 34 ++
> > >  include/uapi/linux/dma-buf.h |  1 +
> > >  2 files changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index f23d939e0e833..0a50c19dcf015 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -419,6 +419,38 @@ static long dma_buf_export_sync_file(struct dma_buf 
> > > *dmabuf,
> > >   put_unused_fd(fd);
> > >   return ret;
> > >  }
> > > +
> > > +static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
> > > + 

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

[Jason Ekstrand]

On Tue, May 25, 2021 at 10:37 AM Daniel Vetter  wrote:
>
> On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> > This patch is analogous to the previous sync file export patch in that
> > it allows you to import a sync_file into a dma-buf.  Unlike the previous
> > patch, however, this does add genuinely new functionality to dma-buf.
> > Without this, the only way to attach a sync_file to a dma-buf is to
> > submit a batch to your driver of choice which waits on the sync_file and
> > claims to write to the dma-buf.  Even if said batch is a no-op, a submit
> > is typically way more overhead than just attaching a fence.  A submit
> > may also imply extra synchronization with other work because it happens
> > on a hardware queue.
> >
> > In the Vulkan world, this is useful for dealing with the out-fence from
> > vkQueuePresent.  Current Linux window-systems (X11, Wayland, etc.) all
> > rely on dma-buf implicit sync.  Since Vulkan is an explicit sync API, we
> > get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
> > those as an exclusive (write) fence on the dma-buf.  We handle it in
> > Mesa today with the above mentioned dummy submit trick.  This ioctl
> > would allow us to set it directly without the dummy submit.
> >
> > This may also open up possibilities for GPU drivers to move away from
> > implicit sync for their kernel driver uAPI and instead provide sync
> > files and rely on dma-buf import/export for communicating with other
> > implicit sync clients.
> >
> > We make the explicit choice here to only allow setting RW fences which
> > translates to an exclusive fence on the dma_resv.  There's no use for
> > read-only fences for communicating with other implicit sync userspace
> > and any such attempts are likely to be racy at best.  When we got to
> > insert the RW fence, the actual fence we set as the new exclusive fence
> > is a combination of the sync_file provided by the user and all the other
> > fences on the dma_resv.  This ensures that the newly added exclusive
> > fence will never signal before the old one would have and ensures that
> > we don't break any dma_resv contracts.  We require userspace to specify
> > RW in the flags for symmetry with the export ioctl and in case we ever
> > want to support read fences in the future.
> >
> > There is one downside here that's worth documenting:  If two clients
> > writing to the same dma-buf using this API race with each other, their
> > actions on the dma-buf may happen in parallel or in an undefined order.
> > Both with and without this API, the pattern is the same:  Collect all
> > the fences on dma-buf, submit work which depends on said fences, and
> > then set a new exclusive (write) fence on the dma-buf which depends on
> > said work.  The difference is that, when it's all handled by the GPU
> > driver's submit ioctl, the three operations happen atomically under the
> > dma_resv lock.  If two userspace submits race, one will happen before
> > the other.  You aren't guaranteed which but you are guaranteed that
> > they're strictly ordered.  If userspace manages the fences itself, then
> > these three operations happen separately and the two render operations
> > may happen genuinely in parallel or get interleaved.  However, this is a
> > case of userspace racing with itself.  As long as we ensure userspace
> > can't back the kernel into a corner, it should be fine.
> >
> > v2 (Jason Ekstrand):
> >  - Use a wrapper dma_fence_array of all fences including the new one
> >when importing an exclusive fence.
> >
> > v3 (Jason Ekstrand):
> >  - Lock around setting shared fences as well as exclusive
> >  - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> >  - Initialize ret to 0 in dma_buf_wait_sync_file
> >
> > v4 (Jason Ekstrand):
> >  - Use the new dma_resv_get_singleton helper
> >
> > v5 (Jason Ekstrand):
> >  - Rename the IOCTLs to import/export rather than wait/signal
> >  - Drop the WRITE flag and always get/set the exclusive fence
> >
> > v5 (Jason Ekstrand):
> >  - Split import and export into separate patches
> >  - New commit message
> >
> > Signed-off-by: Jason Ekstrand 
> > ---
> >  drivers/dma-buf/dma-buf.c| 34 ++
> >  include/uapi/linux/dma-buf.h |  1 +
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index f23d939e0e833..0a50c19dcf015 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -419,6 +419,38 @@ static long dma_buf_export_sync_file(struct dma_buf 
> > *dmabuf,
> >   put_unused_fd(fd);
> >   return ret;
> >  }
> > +
> > +static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
> > +  const void __user *user_data)
> > +{
> > + struct dma_buf_sync_file arg;
> > + struct dma_fence *fence, *singleton = NULL;
> > + int ret = 0;
> > +
> > + if (copy_from_user(, user_data, sizeof(arg)))
> > + 

Re: [Intel-gfx] [PATCH v4 14/17] drm/i915/pxp: User interface for Protected buffer

[Tang, CQ]

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Daniele Ceraolo Spurio
> Sent: Monday, May 24, 2021 10:48 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vetter, Daniel ; Huang Sean Z
> ; dri-de...@lists.freedesktop.org; Chris Wilson
> ; Kondapally Kalyan
> ; Bommu, Krishnaiah
> 
> Subject: [Intel-gfx] [PATCH v4 14/17] drm/i915/pxp: User interface for
> Protected buffer
> 
> From: Bommu Krishnaiah 
> 
> This api allow user mode to create Protected buffers. Only contexts marked
> as protected are allowed to operate on protected buffers.
> 
> We only allow setting the flags at creation time.
> 
> All protected objects that have backing storage will be considered invalid
> when the session is destroyed and they won't be usable anymore.

Then these protected objects will be hanging in the system till user call 
gem_close() to free them?
If the objects won't be usable anymore, why don't we automatically free these 
objects when the session is destroyed?

How is a session started/destroyed?  From the code, intel_pxp_init() is called 
when loading i915 driver, so I think session lifetime is the same as i915 
driver lifetime.
Can we start multiple sessions after loading the driver?

--CQ

> 
> Given that the PXP HW supports multiple modes (but we currently only care
> about one), a flag variable has been reserved in the structure used in the
> create_ext ioctl for possible future updates.
> 
> This is a rework of the original code by Bommu Krishnaiah. I've kept
> authorship unchanged since significant chunks have not been modified.
> 
> v2: split context changes, fix defines and improve documentation (Chris),
> add object invalidation logic
> v3: fix spinlock definition and usage, only validate objects when
> they're first added to a context lut, only remove them once (Chris),
> make protected context flag not mandatory in protected object execbuf
> to avoid abuse (Lionel)
> v4: rebase to new gem_create_ext
> 
> Signed-off-by: Bommu Krishnaiah 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Telukuntla Sreedhar 
> Cc: Kondapally Kalyan 
> Cc: Gupta Anshuman 
> Cc: Huang Sean Z 
> Cc: Chris Wilson 
> Cc: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_create.c| 26 
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +++
>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  6 +++
>  drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 41 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  | 13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  5 +++
>  include/uapi/drm/i915_drm.h   | 33 ++-
>  9 files changed, 163 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index 548ddf39d853..c14be3882c35 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -6,6 +6,7 @@
>  #include "gem/i915_gem_ioctls.h"
>  #include "gem/i915_gem_lmem.h"
>  #include "gem/i915_gem_region.h"
> +#include "pxp/intel_pxp.h"
> 
>  #include "i915_drv.h"
>  #include "i915_trace.h"
> @@ -99,7 +100,11 @@ i915_gem_setup(struct drm_i915_gem_object *obj,
> u64 size)
> 
>   GEM_BUG_ON(size != obj->base.size);
> 
> + if (obj->user_flags & I915_GEM_OBJECT_PROTECTED)
> + intel_pxp_object_add(obj);
> +
>   trace_i915_gem_object_create(obj);
> +
>   return 0;
>  }
> 
> @@ -344,8 +349,29 @@ static int ext_set_placements(struct
> i915_user_extension __user *base,
>   return set_placements(, data);
>  }
> 
> +static int ext_set_protected(struct i915_user_extension __user *base,
> +void *data) {
> + struct drm_i915_gem_create_ext_protected_content ext;
> + struct create_ext *ext_data = data;
> +
> + if (copy_from_user(, base, sizeof(ext)))
> + return -EFAULT;
> +
> + if (ext.flags)
> + return -EINVAL;
> +
> + if (!intel_pxp_is_enabled(_data->i915->gt.pxp))
> + return -ENODEV;
> +
> + ext_data->vanilla_object->user_flags |=
> I915_GEM_OBJECT_PROTECTED;
> +
> + return 0;
> +}
> +
> +
>  static const i915_user_extension_fn create_extensions[] = {
>   [I915_GEM_CREATE_EXT_MEMORY_REGIONS] =
> ext_set_placements,
> + [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] =
> ext_set_protected,
>  };
> 
>  /**
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index c08e28847064..5dd813d04a9f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -839,6 +839,21 @@ static struct i915_vma *eb_lookup_vma(struct
> i915_execbuffer *eb, u32 handle)
>   if (unlikely(!obj))
>   return ERR_PTR(-ENOENT);
> 
> +  

Re: [Intel-gfx] [RFC PATCH 19/97] drm/i915/guc: Always copy CT message to new allocation

[Matthew Brost]

On Thu, May 06, 2021 at 12:13:33PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> Since most of future CT traffic will be based on G2H requests,
> instead of copying incoming CT message to static buffer and then
> create new allocation for such request, always copy incoming CT
> message to new allocation. Also by doing it while reading CT
> header, we can safely fallback if that atomic allocation fails.
> 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 
> Cc: Piotr Piórkowski 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 180 ++
>  1 file changed, 120 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index d630ec32decf..a174978c6a27 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -72,8 +72,9 @@ struct ct_request {
>   u32 *response_buf;
>  };
>  
> -struct ct_incoming_request {
> +struct ct_incoming_msg {
>   struct list_head link;
> + u32 size;
>   u32 msg[];
>  };
>  
> @@ -575,7 +576,26 @@ static inline bool ct_header_is_response(u32 header)
>   return !!(header & GUC_CT_MSG_IS_RESPONSE);
>  }
>  
> -static int ct_read(struct intel_guc_ct *ct, u32 *data)
> +static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
> +{
> + struct ct_incoming_msg *msg;
> +
> + msg = kmalloc(sizeof(*msg) + sizeof(u32) * num_dwords, GFP_ATOMIC);
> + if (msg)
> + msg->size = num_dwords;
> + return msg;
> +}
> +
> +static void ct_free_msg(struct ct_incoming_msg *msg)
> +{
> + kfree(msg);
> +}
> +
> +/*
> + * Return: number available remaining dwords to read (0 if empty)
> + * or a negative error code on failure
> + */
> +static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
>  {
>   struct intel_guc_ct_buffer *ctb = >ctbs.recv;
>   struct guc_ct_buffer_desc *desc = ctb->desc;
> @@ -586,6 +606,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>   s32 available;
>   unsigned int len;
>   unsigned int i;
> + u32 header;
>  
>   if (unlikely(desc->is_in_error))
>   return -EPIPE;
> @@ -601,8 +622,10 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>  
>   /* tail == head condition indicates empty */
>   available = tail - head;
> - if (unlikely(available == 0))
> - return -ENODATA;
> + if (unlikely(available == 0)) {
> + *msg = NULL;
> + return 0;
> + }
>  
>   /* beware of buffer wrap case */
>   if (unlikely(available < 0))
> @@ -610,14 +633,14 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>   CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
>   GEM_BUG_ON(available < 0);
>  
> - data[0] = cmds[head];
> + header = cmds[head];
>   head = (head + 1) % size;
>  
>   /* message len with header */
> - len = ct_header_get_len(data[0]) + 1;
> + len = ct_header_get_len(header) + 1;
>   if (unlikely(len > (u32)available)) {
>   CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
> -  4, data,
> +  4, ,
>4 * (head + available - 1 > size ?
> size - head : available - 1), [head],
>4 * (head + available - 1 > size ?
> @@ -625,11 +648,24 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>   goto corrupted;
>   }
>  
> + *msg = ct_alloc_msg(len);
> + if (!*msg) {
> + CT_ERROR(ct, "No memory for message %*ph %*ph %*ph\n",
> +  4, ,
> +  4 * (head + available - 1 > size ?
> +   size - head : available - 1), [head],
> +  4 * (head + available - 1 > size ?
> +   available - 1 - size + head : 0), [0]);
> + return available;
> + }
> +
> + (*msg)->msg[0] = header;
> +
>   for (i = 1; i < len; i++) {
> - data[i] = cmds[head];
> + (*msg)->msg[i] = cmds[head];
>   head = (head + 1) % size;
>   }
> - CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
> + CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
>  
>   desc->head = head * 4;
>   return available - len;
> @@ -659,33 +695,33 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>   *   ^---len---^
>   */
>  
> -static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
> +static int ct_handle_response(struct intel_guc_ct *ct, struct 
> ct_incoming_msg *response)
>  {
> - u32 header = msg[0];
> + u32 header = response->msg[0];
>   u32 len = ct_header_get_len(header);
> - u32 msgsize = (len + 1) * sizeof(u32); /* msg size in bytes w/header */
>   u32 

Re: [Intel-gfx] [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

[Noralf Trønnes]

> It's tedious to review this all the time, and my audit showed that
> arcpgu actually forgot to set this.
>
> Make this the default and stop worrying.
>
> Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
> strange combinations of hooks: cleanup_fb without prepare_fb doesn't
> make sense, and since simpler drivers are all new they better be GEM
> based drivers.
>
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 12 ++--
>  include/drm/drm_simple_kms_helper.h |  7 +--
>  2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0b095a313c44..1a97571d97d9 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -9,6 +9,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -225,8 +227,14 @@ static int drm_simple_kms_plane_prepare_fb(struct
drm_plane *plane,
>   struct drm_simple_display_pipe *pipe;
>
>   pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> - if (!pipe->funcs || !pipe->funcs->prepare_fb)
> - return 0;
> + if (!pipe->funcs || !pipe->funcs->prepare_fb) {
> + if (WARN_ON_ONCE(drm_core_check_feature(plane->dev, 
> DRIVER_GEM)))

Shouldn't this check be inverted? Looks like it warns on GEM drivers.

With that considered:

Acked-by: Noralf Trønnes 

Hopefully this reply will thread correctly, I had to reply from lore (I
wasn't cc'ed) and I don't know if Thunderbird sets In-Reply-To. I'm not
subscribed to dri-devel anymore since I'm winding down my Linux work and
dri-devel is such a high volume list.

Noralf

> + return 0;
> +
> + WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb);
> +
> + return drm_gem_simple_display_pipe_prepare_fb(pipe, state);
> + }
>
>   return pipe->funcs->prepare_fb(pipe, state);
>  }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 18/97] drm/i915/guc: Don't receive all G2H messages in irq handler

[Matthew Brost]

On Thu, May 06, 2021 at 12:13:32PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> In irq handler try to receive just single G2H message, let other
> messages to be received from tasklet.
> 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  3 +
>  2 files changed, 50 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index cb58fa7f970c..d630ec32decf 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -81,6 +81,7 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
>  
>  enum { CTB_OWNER_HOST = 0 };
>  
> +static void ct_receive_tasklet_func(unsigned long data);
>  static void ct_incoming_request_worker_func(struct work_struct *w);
>  
>  /**
> @@ -95,6 +96,7 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>   INIT_LIST_HEAD(>requests.pending);
>   INIT_LIST_HEAD(>requests.incoming);
>   INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
> + tasklet_init(>receive_tasklet, ct_receive_tasklet_func, (unsigned 
> long)ct);

This function is deprecated. tasklet_setup should be used.
I can fix this up when I post the CTB patches.

>  }
>  
>  static inline const char *guc_ct_buffer_type_to_str(u32 type)
> @@ -244,6 +246,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>  {
>   GEM_BUG_ON(ct->enabled);
>  
> + tasklet_kill(>receive_tasklet);
>   i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
>   memset(ct, 0, sizeof(*ct));
>  }
> @@ -629,7 +632,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
>   CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
>  
>   desc->head = head * 4;
> - return 0;
> + return available - len;
>  
>  corrupted:
>   CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
> @@ -665,10 +668,10 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
> const u32 *msg)
>   u32 status;
>   u32 datalen;
>   struct ct_request *req;
> + unsigned long flags;
>   bool found = false;
>  
>   GEM_BUG_ON(!ct_header_is_response(header));
> - GEM_BUG_ON(!in_irq());
>  
>   /* Response payload shall at least include fence and status */
>   if (unlikely(len < 2)) {
> @@ -688,7 +691,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
> const u32 *msg)
>  
>   CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
>  
> - spin_lock(>requests.lock);
> + spin_lock_irqsave(>requests.lock, flags);
>   list_for_each_entry(req, >requests.pending, link) {
>   if (unlikely(fence != req->fence)) {
>   CT_DEBUG(ct, "request %u awaits response\n",
> @@ -707,7 +710,7 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
> const u32 *msg)
>   found = true;
>   break;
>   }
> - spin_unlock(>requests.lock);
> + spin_unlock_irqrestore(>requests.lock, flags);
>  
>   if (!found)
>   CT_ERROR(ct, "Unsolicited response %*ph\n", msgsize, msg);
> @@ -821,31 +824,55 @@ static int ct_handle_request(struct intel_guc_ct *ct, 
> const u32 *msg)
>   return 0;
>  }
>  
> +static int ct_receive(struct intel_guc_ct *ct)
> +{
> + u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(>ctbs.recv.lock, flags);
> + ret = ct_read(ct, msg);
> + spin_unlock_irqrestore(>ctbs.recv.lock, flags);
> + if (ret < 0)
> + return ret;
> +
> + if (ct_header_is_response(msg[0]))
> + ct_handle_response(ct, msg);
> + else
> + ct_handle_request(ct, msg);
> +
> + return ret;
> +}
> +
> +static void ct_try_receive_message(struct intel_guc_ct *ct)
> +{
> + int ret;
> +
> + if (GEM_WARN_ON(!ct->enabled))
> + return;
> +
> + ret = ct_receive(ct);
> + if (ret > 0)
> + tasklet_hi_schedule(>receive_tasklet);
> +}
> +
> +static void ct_receive_tasklet_func(unsigned long data)
> +{

As mentioned above tasklet_init is deprecated. The callback now accepts
the tasklet structure and ct can be looked up via container_of macro.

Everything else looks good.

With that and changing to the new tasklet API:
Reviewed-by: Matthew Brost 

> + struct intel_guc_ct *ct = (struct intel_guc_ct *)data;
> +
> + ct_try_receive_message(ct);
> +}
> +
>  /*
>   * When we're communicating with the GuC over CT, GuC uses events
>   * to notify us about new messages being posted on the RECV buffer.
>   */
>  void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
>  {
> - u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
> - unsigned long flags;
> - int err = 0;
> -
>   if (unlikely(!ct->enabled)) {
>  

Re: [Intel-gfx] [RFC PATCH 15/97] drm/i915/guc: Relax CTB response timeout

[Matthew Brost]

On Thu, May 06, 2021 at 12:13:29PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> In upcoming patch we will allow more CTB requests to be sent in
> parallel to the GuC for procesing, so we shouldn't assume any more
> that GuC will always reply without 10ms.
> 
> Use bigger value from CONFIG_DRM_I915_HEARTBEAT_INTERVAL instead.
> 

I think this should be its own config option or we combine it with a
config option suggested in patch 37.

What do you think Michal? If you agree I can fix this up in the post of
these patches.

Matt

> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index c87a0a8bef26..a4b2e7fe318b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -436,17 +436,23 @@ static int ct_write(struct intel_guc_ct *ct,
>   */
>  static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
>  {
> + long timeout;
>   int err;
>  
>   /*
>* Fast commands should complete in less than 10us, so sample quickly
>* up to that length of time, then switch to a slower sleep-wait loop.
>* No GuC command should ever take longer than 10ms.
> +  *
> +  * However, there might be other CT requests in flight before this one,
> +  * so use @CONFIG_DRM_I915_HEARTBEAT_INTERVAL as backup timeout value.
>*/
> + timeout = max(10, CONFIG_DRM_I915_HEARTBEAT_INTERVAL);
> +
>  #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
>   err = wait_for_us(done, 10);
>   if (err)
> - err = wait_for(done, 10);
> + err = wait_for(done, timeout);
>  #undef done
>  
>   if (unlikely(err))
> -- 
> 2.28.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines

[Matthew Brost]

On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:14, Matthew Brost wrote:
> > From: John Harrison 
> > 
> > The serial number tracking of engines happens at the backend of
> > request submission and was expecting to only be given physical
> > engines. However, in GuC submission mode, the decomposition of virtual
> > to physical engines does not happen in i915. Instead, requests are
> > submitted to their virtual engine mask all the way through to the
> > hardware (i.e. to GuC). This would mean that the heart beat code
> > thinks the physical engines are idle due to the serial number not
> > incrementing.
> > 
> > This patch updates the tracking to decompose virtual engines into
> > their physical constituents and tracks the request against each. This
> > is not entirely accurate as the GuC will only be issuing the request
> > to one physical engine. However, it is the best that i915 can do given
> > that it has no knowledge of the GuC's scheduling decisions.
> 
> Commit text sounds a bit defeatist. I think instead of making up the serial
> counts, which has downsides (could you please document in the commit what
> they are), we should think how to design things properly.
> 

IMO, I don't think fixing serial counts is the scope of this series. We
should focus on getting GuC submission in not cleaning up all the crap
that is in the i915. Let's make a note of this though so we can revisit
later.

Matt

> Regards,
> 
> Tvrtko
> 
> > Signed-off-by: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_engine_types.h |  2 ++
> >   .../gpu/drm/i915/gt/intel_execlists_submission.c |  6 ++
> >   drivers/gpu/drm/i915/gt/intel_ring_submission.c  |  6 ++
> >   drivers/gpu/drm/i915/gt/mock_engine.c|  6 ++
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16 
> >   drivers/gpu/drm/i915/i915_request.c  |  4 +++-
> >   6 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 86302e6d86b2..e2b5cda6dbc4 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -389,6 +389,8 @@ struct intel_engine_cs {
> > void(*park)(struct intel_engine_cs *engine);
> > void(*unpark)(struct intel_engine_cs *engine);
> > +   void(*bump_serial)(struct intel_engine_cs *engine);
> > +
> > void(*set_default_submission)(struct intel_engine_cs 
> > *engine);
> > const struct intel_context_ops *cops;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index ae12d7f19ecd..02880ea5d693 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3199,6 +3199,11 @@ static void execlists_release(struct intel_engine_cs 
> > *engine)
> > lrc_fini_wa_ctx(engine);
> >   }
> > +static void execlist_bump_serial(struct intel_engine_cs *engine)
> > +{
> > +   engine->serial++;
> > +}
> > +
> >   static void
> >   logical_ring_default_vfuncs(struct intel_engine_cs *engine)
> >   {
> > @@ -3208,6 +3213,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
> > *engine)
> > engine->cops = _context_ops;
> > engine->request_alloc = execlists_request_alloc;
> > +   engine->bump_serial = execlist_bump_serial;
> > engine->reset.prepare = execlists_reset_prepare;
> > engine->reset.rewind = execlists_reset_rewind;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> > b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > index 14aa31879a37..39dd7c4ed0a9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > @@ -1045,6 +1045,11 @@ static void setup_irq(struct intel_engine_cs *engine)
> > }
> >   }
> > +static void ring_bump_serial(struct intel_engine_cs *engine)
> > +{
> > +   engine->serial++;
> > +}
> > +
> >   static void setup_common(struct intel_engine_cs *engine)
> >   {
> > struct drm_i915_private *i915 = engine->i915;
> > @@ -1064,6 +1069,7 @@ static void setup_common(struct intel_engine_cs 
> > *engine)
> > engine->cops = _context_ops;
> > engine->request_alloc = ring_request_alloc;
> > +   engine->bump_serial = ring_bump_serial;
> > /*
> >  * Using a global execution timeline; the previous final breadcrumb is
> > diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c 
> > b/drivers/gpu/drm/i915/gt/mock_engine.c
> > index bd005c1b6fd5..97b10fd60b55 100644
> > --- a/drivers/gpu/drm/i915/gt/mock_engine.c
> > +++ b/drivers/gpu/drm/i915/gt/mock_engine.c
> > @@ -292,6 +292,11 @@ static void mock_engine_release(struct intel_engine_cs 
> > *engine)
> > intel_engine_fini_retire(engine);
> >   }
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check HDMI sink deep color capabilities during .mode_valid() (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Check HDMI sink deep color capabilities during .mode_valid() 
(rev3)
URL   : https://patchwork.freedesktop.org/series/90036/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10132 -> Patchwork_20191


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2:  [PASS][4] -> [FAIL][5] ([i915#2416])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2:  [PASS][6] -> [FAIL][7] ([i915#49])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][9] ([i915#1372]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [DMESG-FAIL][11] ([i915#3462]) -> [INCOMPLETE][12] 
([i915#2782] / [i915#3462])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2:  [DMESG-FAIL][13] ([i915#3462]) -> [INCOMPLETE][14] 
([i915#3462])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-tgl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][16] ([i915#1436] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-skl-6600u/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][17] ([i915#2426] / [i915#2782] / [i915#3363]) 
-> [FAIL][18] ([i915#2782] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-icl-u2/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-icl-u2/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][19] ([i915#1602] / [i915#2029]) -> [FAIL][20] 
([i915#3462])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-bdw-5557u/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][22] ([i915#1436] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-kbl-guc/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20191/fi-kbl-guc/igt@run...@aborted.html

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

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

Re: [Intel-gfx] [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

[Daniel Vetter]

On Tue, May 25, 2021 at 07:48:12PM +0200, Noralf Trønnes wrote:
> > It's tedious to review this all the time, and my audit showed that
> > arcpgu actually forgot to set this.
> >
> > Make this the default and stop worrying.
> >
> > Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
> > strange combinations of hooks: cleanup_fb without prepare_fb doesn't
> > make sense, and since simpler drivers are all new they better be GEM
> > based drivers.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_simple_kms_helper.c | 12 ++--
> >  include/drm/drm_simple_kms_helper.h |  7 +--
> >  2 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 0b095a313c44..1a97571d97d9 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -9,6 +9,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -225,8 +227,14 @@ static int drm_simple_kms_plane_prepare_fb(struct
> drm_plane *plane,
> > struct drm_simple_display_pipe *pipe;
> >
> > pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> > -   if (!pipe->funcs || !pipe->funcs->prepare_fb)
> > -   return 0;
> > +   if (!pipe->funcs || !pipe->funcs->prepare_fb) {
> > +   if (WARN_ON_ONCE(drm_core_check_feature(plane->dev, 
> > DRIVER_GEM)))
> 
> Shouldn't this check be inverted? Looks like it warns on GEM drivers.

Ah yes, I'll fix.

> With that considered:
> 
> Acked-by: Noralf Trønnes 
> 
> Hopefully this reply will thread correctly, I had to reply from lore (I
> wasn't cc'ed) and I don't know if Thunderbird sets In-Reply-To. I'm not
> subscribed to dri-devel anymore since I'm winding down my Linux work and
> dri-devel is such a high volume list.

Thanks a lot for taking a look, threaded all correctly.
-Daniel

> Noralf
> 
> > +   return 0;
> > +
> > +   WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb);
> > +
> > +   return drm_gem_simple_display_pipe_prepare_fb(pipe, state);
> > +   }
> >
> > return pipe->funcs->prepare_fb(pipe, state);
> >  }

-- 
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] [RFC PATCH 38/97] drm/i915/guc: Optimize CTB writes and reads

[Matthew Brost]

On Mon, May 24, 2021 at 03:31:25PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 06.05.2021 21:13, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail, size) which could result in accesses across the PCIe
> 
> size was removed from the descriptor in 25/97
> 

Yep, stale comment.

> > bus, store shadow local copies and only read/write the descriptor
> > values when absolutely necessary.
> 
> maybe worth to add some words about caching available space ?
> 

Yea.

> > 
> > Signed-off-by: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 78 +--
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
> >  2 files changed, 52 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 4eab319d61be..77dfbc94dcc3 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -127,6 +127,10 @@ static void guc_ct_buffer_desc_init(struct 
> > guc_ct_buffer_desc *desc)
> >  static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> >  {
> > ctb->broken = false;
> > +   ctb->tail = 0;
> > +   ctb->head = 0;
> > +   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> > +
> > guc_ct_buffer_desc_init(ctb->desc);
> >  }
> >  
> > @@ -371,10 +375,8 @@ static int ct_write(struct intel_guc_ct *ct,
> >  {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > -   u32 head = desc->head;
> > -   u32 tail = desc->tail;
> > +   u32 tail = ctb->tail;
> > u32 size = ctb->size;
> > -   u32 used;
> > u32 header;
> > u32 hxg;
> > u32 *cmds = ctb->cmds;
> > @@ -386,25 +388,14 @@ static int ct_write(struct intel_guc_ct *ct,
> > if (unlikely(desc->status))
> > goto corrupted;
> >  
> > -   if (unlikely((tail | head) >= size)) {
> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
> > +   if (unlikely((desc->tail | desc->head) >= size)) {
> > CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> > -head, tail, size);
> > +desc->head, desc->tail, size);
> > desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > goto corrupted;
> 
> nit: as we are now caching tail value, we can start comparing it with
> the value in descriptor and report GUC_CTB_STATUS_MISMATCH if needed
>

Sure.
 
> > }
> > -
> > -   /*
> > -* tail == head condition indicates empty. GuC FW does not support
> > -* using up the entire buffer to get tail == head meaning full.
> > -*/
> > -   if (tail < head)
> > -   used = (size - head) + tail;
> > -   else
> > -   used = tail - head;
> > -
> > -   /* make sure there is a space including extra dw for the fence */
> > -   if (unlikely(used + len + 1 >= size))
> > -   return -ENOSPC;
> > +#endif
> >  
> > /*
> >  * dw0: CT header (including fence)
> > @@ -444,7 +435,9 @@ static int ct_write(struct intel_guc_ct *ct,
> > write_barrier(ct);
> >  
> > /* now update descriptor */
> > +   ctb->tail = tail;
> > WRITE_ONCE(desc->tail, tail);
> > +   ctb->space -= len + 1;
> >  
> > return 0;
> >  
> > @@ -460,7 +453,7 @@ static int ct_write(struct intel_guc_ct *ct,
> >   * @req:   pointer to pending request
> >   * @status:placeholder for status
> >   *
> > - * For each sent request, Guc shall send bac CT response message.
> > + * For each sent request, GuC shall send back CT response message.
> >   * Our message handler will update status of tracked request once
> >   * response message with given fence is received. Wait here and
> >   * check for valid response status value.
> > @@ -508,24 +501,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct 
> > *ct)
> > return ret;
> >  }
> >  
> > -static inline bool ctb_has_room(struct intel_guc_ct_buffer *ctb, u32 
> > len_dw)
> > +static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
> 
> this function was introduced moment ago ...
> can we minimize number of changes between patches ?
>

Yep.
 
> >  {
> > -   struct guc_ct_buffer_desc *desc = ctb->desc;
> > -   u32 head = READ_ONCE(desc->head);
> > +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > +   u32 head;
> > u32 space;
> >  
> > -   space = CIRC_SPACE(desc->tail, head, ctb->size);
> > +   if (ctb->space >= len_dw)
> > +   return true;
> > +
> > +   head = READ_ONCE(ctb->desc->head);
> > +   if (unlikely(head > ctb->size)) {
> > +   CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u size=%u\n",
> > + ctb->desc->head, ctb->desc->tail, ctb->size);
> > +   ctb->desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > +   ctb->broken = true;
> > +   return false;
> > +   }

Re: [Intel-gfx] [RFC PATCH 35/97] drm/i915/guc: Improve error message for unsolicited CT response

[Matthew Brost]

On Mon, May 24, 2021 at 01:59:54PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 06.05.2021 21:13, Matthew Brost wrote:
> > Improve the error message when a unsolicited CT response is received by
> > printing fence that couldn't be found, the last fence, and all requests
> > with a response outstanding.
> > 
> > Signed-off-by: Matthew Brost 
> > ---
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 217ab3ebd1af..a76603537fa8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -703,12 +703,16 @@ static int ct_handle_response(struct intel_guc_ct 
> > *ct, struct ct_incoming_msg *r
> > found = true;
> > break;
> > }
> > -   spin_unlock_irqrestore(>requests.lock, flags);
> > -
> > if (!found) {
> > CT_ERROR(ct, "Unsolicited response (fence %u)\n", fence);
> > -   return -ENOKEY;
> > +   CT_ERROR(ct, "Could not find fence=%u, last_fence=%u\n", fence,
> > +ct->requests.last_fence);
> 
> nit: this new wording may suggest that it's our fault, but that's not
> necessary true
> 

I don't think is implies whos fault this is either way.

> > +   list_for_each_entry(req, >requests.pending, link)
> > +   CT_ERROR(ct, "request %u awaits response\n",
> > +req->fence);
> 
> usually we don't send multiple requests that expects responses, so it's
> very likely that list with pending requests will be empty, and even if
> list is not empty, I'm not sure what is the relation between those
> pending requests to this unsolicited response, thus wondering how these
> extra errors could improve our debugging experience ?
> 

The more information when this occurs the better.

Matt

> > +   err = -ENOKEY;
> > }
> > +   spin_unlock_irqrestore(>requests.lock, flags);
> >  
> > if (unlikely(err))
> > return err;
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

[Matthew Brost]

On Mon, May 24, 2021 at 02:21:42PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 06.05.2021 21:13, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. In order to
> > support a non blocking CTB send function a spin lock is needed to
> 
> spin lock was added in 16/97
> 
> > protect the CTB descriptors fields. Also the non blocking call must not
> > update the fence value as this value is owned by the blocking call
> > (intel_guc_send).
> 
> all H2G messages are using "fence", nb variant also needs to update it
> 
> > 
> > The blocking CTB now must have a flow control mechanism to ensure the
> 
> s/blocking/non-blocking
> 

Will fix the comments as these are a bit stale.

> > buffer isn't overrun. A lazy spin wait is used as we believe the flow
> > control condition should be rare with properly sized buffer.
> 
> as this new nb function is still not used in this patch, then maybe
> better to move flow control to separate patch for easier review ?
>

You can't do non-blocking without flow control, it just doesn't work.
IMO that makes the review harder.
 
> > 
> > The function, intel_guc_send_nb, is exported in this patch but unused.
> > Several patches later in the series make use of this function.
> > 
> > Signed-off-by: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >  drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 ++-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 96 +--
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  7 +-
> >  3 files changed, 105 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index c20f3839de12..4c0a367e41d8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -75,7 +75,15 @@ static inline struct intel_guc *log_to_guc(struct 
> > intel_guc_log *log)
> >  static
> >  inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 
> > len)
> >  {
> > -   return intel_guc_ct_send(>ct, action, len, NULL, 0);
> > +   return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> > +}
> > +
> > +#define INTEL_GUC_SEND_NB  BIT(31)
> > +static
> > +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32 
> > len)
> > +{
> > +   return intel_guc_ct_send(>ct, action, len, NULL, 0,
> > +INTEL_GUC_SEND_NB);
> >  }
> >  
> >  static inline int
> > @@ -83,7 +91,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const 
> > u32 *action, u32 len,
> >u32 *response_buf, u32 response_buf_size)
> >  {
> > return intel_guc_ct_send(>ct, action, len,
> > -response_buf, response_buf_size);
> > +response_buf, response_buf_size, 0);
> >  }
> >  
> >  static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index a76603537fa8..af7314d45a78 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -3,6 +3,11 @@
> >   * Copyright © 2016-2019 Intel Corporation
> >   */
> >  
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #include "i915_drv.h"
> >  #include "intel_guc_ct.h"
> >  #include "gt/intel_gt.h"
> > @@ -308,6 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> > if (unlikely(err))
> > goto err_deregister;
> >  
> > +   ct->requests.last_fence = 1;
> 
> not needed
>

Yep.
 
> > ct->enabled = true;
> >  
> > return 0;
> > @@ -343,10 +349,22 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
> > return ++ct->requests.last_fence;
> >  }
> >  
> > +static void write_barrier(struct intel_guc_ct *ct) {
> > +   struct intel_guc *guc = ct_to_guc(ct);
> > +   struct intel_gt *gt = guc_to_gt(guc);
> > +
> > +   if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
> > +   GEM_BUG_ON(guc->send_regs.fw_domains);
> > +   intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
> > +   } else {
> > +   wmb();
> > +   }
> > +}
> 
> this chunk seems to be good candidate for separate patch that could be
> introduced earlier
>

Yes. Will include patches 3-20 post as this technically is required once
the mutex is removed.
 
> > +
> >  static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > -   u32 fence)
> > +   u32 fence, u32 flags)
> >  {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -393,9 +411,13 @@ static int ct_write(struct intel_guc_ct *ct,
> >  FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> >  FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> >  
> > -   hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia()

[Souza, Jose]

On Tue, 2021-05-25 at 06:30 +, Patchwork wrote:
Patch Details
Series: series starting with [1/5] drm/i915/display/adl_p: Drop earlier return 
in tc_has_modular_fia()
URL:https://patchwork.freedesktop.org/series/90495/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20184/index.html
CI Bug Log - changes from CI_DRM_10128_full -> Patchwork_20184_full
Summary

SUCCESS

No regressions found.

Pushed, thanks for the reviews Clint.

Known issues

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

IGT changes
Issues hit

  *   igt@gem_ctx_isolation@preservation-s3@bcs0:

 *   shard-kbl: 
PASS
 -> 
DMESG-WARN
 ([i915#180]) +2 similar issues
  *   igt@gem_ctx_persistence@legacy-engines-mixed:

 *   shard-snb: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +5 similar issues
  *   igt@gem_exec_fair@basic-deadline:

 *   shard-apl: NOTRUN -> 
FAIL
 ([i915#2846])
  *   igt@gem_exec_fair@basic-pace-solo@rcs0:

 *   shard-iclb: NOTRUN -> 
FAIL
 ([i915#2842])

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-kbl: 
PASS
 -> 
SKIP
 ([fdo#109271])
  *   igt@gem_exec_fair@basic-pace@vcs1:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842])
  *   igt@gem_exec_flush@basic-batch-kernel-default-cmd:

 *   shard-iclb: NOTRUN -> 
SKIP
 ([fdo#109313])
  *   igt@gem_exec_params@no-bsd:

 *   shard-tglb: NOTRUN -> 
SKIP
 ([fdo#109283])
  *   igt@gem_exec_reloc@basic-wide-active@vcs1:

 *   shard-iclb: NOTRUN -> 
FAIL
 ([i915#2389])
  *   igt@gem_mmap_gtt@big-copy:

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#307])

 *   shard-skl: 
PASS
 -> 
FAIL
 ([i915#307])

  *   igt@gem_mmap_gtt@cpuset-basic-small-copy:

 *   shard-apl: NOTRUN -> 
INCOMPLETE
 ([i915#3468])
  *   igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:

 *   shard-iclb: NOTRUN -> 
INCOMPLETE
 ([i915#2910] / [i915#3468])
  *   igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
 ([i915#3468])

 *   shard-apl: 
PASS
 -> 
INCOMPLETE
 ([i915#3468])

  *   igt@gem_mmap_gtt@cpuset-big-copy-odd:

 *   shard-iclb: 
PASS
 -> 

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display/adl_p: Disable PSR2

[Souza, Jose]

On Tue, 2021-05-25 at 13:55 +0300, Jani Nikula wrote:
> On Mon, 24 May 2021, José Roberto de Souza  wrote:
> > We are missing the implementation of some workarounds to enabled PSR2
> > in Alderlake P, so to avoid any CI report of issues around PSR2
> > disabling it until all PSR2 workarounds are implemented.
> > 
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index c57210862206..46bd77669ead 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -765,6 +765,16 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> > return false;
> > }
> >  
> > +   /*
> > +* We are missing the implementation of some workarounds to enabled PSR2
> > +* also Windows team found issues in this stepping that are causing
> > +* issues in most PSR2 panels.
> 
> "this stepping"?
> 
> Maybe just say we need to implement certain workarounds before enabling
> PSR2?
> 

Fixed and pushed.

> BR,
> Jani.
> 
> 
> > +*/
> > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > +   drm_dbg_kms(_priv->drm, "PSR2 is missing the implementation 
> > of workarounds\n");
> > +   return false;
> > +   }
> > +
> > if (!transcoder_has_psr2(dev_priv, crtc_state->cpu_transcoder)) {
> > drm_dbg_kms(_priv->drm,
> > "PSR2 not supported in transcoder %s\n",
> 

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

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

[Matthew Brost]

On Tue, May 25, 2021 at 10:21:00AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. In order to
> > support a non blocking CTB send function a spin lock is needed to
> > protect the CTB descriptors fields. Also the non blocking call must not
> > update the fence value as this value is owned by the blocking call
> > (intel_guc_send).
> 
> Could the commit message say why the non-blocking send function is needed?
> 

Sure. Something like:

'CTBs will be used in the critical patch of GuC submission and there is
no need to wait for each CTB complete before moving on the i915'

> > 
> > The blocking CTB now must have a flow control mechanism to ensure the
> > buffer isn't overrun. A lazy spin wait is used as we believe the flow
> > control condition should be rare with properly sized buffer.
> > 
> > The function, intel_guc_send_nb, is exported in this patch but unused.
> > Several patches later in the series make use of this function.
> > 
> > Signed-off-by: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 ++-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 96 +--
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  7 +-
> >   3 files changed, 105 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index c20f3839de12..4c0a367e41d8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -75,7 +75,15 @@ static inline struct intel_guc *log_to_guc(struct 
> > intel_guc_log *log)
> >   static
> >   inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 
> > len)
> >   {
> > -   return intel_guc_ct_send(>ct, action, len, NULL, 0);
> > +   return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> > +}
> > +
> > +#define INTEL_GUC_SEND_NB  BIT(31)
> > +static
> > +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32 
> > len)
> > +{
> > +   return intel_guc_ct_send(>ct, action, len, NULL, 0,
> > +INTEL_GUC_SEND_NB);
> >   }
> >   static inline int
> > @@ -83,7 +91,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const 
> > u32 *action, u32 len,
> >u32 *response_buf, u32 response_buf_size)
> >   {
> > return intel_guc_ct_send(>ct, action, len,
> > -response_buf, response_buf_size);
> > +response_buf, response_buf_size, 0);
> >   }
> >   static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index a76603537fa8..af7314d45a78 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -3,6 +3,11 @@
> >* Copyright © 2016-2019 Intel Corporation
> >*/
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> >   #include "i915_drv.h"
> >   #include "intel_guc_ct.h"
> >   #include "gt/intel_gt.h"
> > @@ -308,6 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> > if (unlikely(err))
> > goto err_deregister;
> > +   ct->requests.last_fence = 1;
> > ct->enabled = true;
> > return 0;
> > @@ -343,10 +349,22 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
> > return ++ct->requests.last_fence;
> >   }
> > +static void write_barrier(struct intel_guc_ct *ct) {
> > +   struct intel_guc *guc = ct_to_guc(ct);
> > +   struct intel_gt *gt = guc_to_gt(guc);
> > +
> > +   if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
> > +   GEM_BUG_ON(guc->send_regs.fw_domains);
> > +   intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
> 
> It's safe to write to this reg? Does it need a comment to explain it?
>

Yes, it is same. IMO 'SCRATCH' in the name is enough documentation.
 
> > +   } else {
> > +   wmb();
> > +   }
> > +}
> > +
> >   static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > -   u32 fence)
> > +   u32 fence, u32 flags)
> >   {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -393,9 +411,13 @@ static int ct_write(struct intel_guc_ct *ct,
> >  FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> >  FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> > -   hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> > - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > -GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> > +   hxg = (flags & INTEL_GUC_SEND_NB) ?
> > +   (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> > +FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> > +   

Re: [Intel-gfx] [CI 3/3] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h

[Lucas De Marchi]

On Mon, May 24, 2021 at 12:21:03PM -0700, Anusha Srivatsa wrote:

Move struct intel_dmc from i915_drv.h to intel_dmc.h.

v2: Add includes along with moving the struct.

Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_dmc.h | 21 +
drivers/gpu/drm/i915/i915_drv.h  | 18 +-
2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 64816f4a71b6..4c22f567b61b 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -6,12 +6,33 @@
#ifndef __INTEL_DMC_H__
#define __INTEL_DMC_H__

+#include "i915_reg.h"
+#include "intel_wakeref.h"
+#include 
+
struct drm_i915_private;

#define DMC_VERSION(major, minor)   ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version)  ((version) >> 16)
#define DMC_VERSION_MINOR(version)  ((version) & 0x)

+struct intel_dmc {
+   struct work_struct work;
+   const char *fw_path;
+   u32 required_version;
+   u32 max_fw_size; /* bytes */
+   u32 *dmc_payload;
+   u32 dmc_fw_size; /* dwords */
+   u32 version;
+   u32 mmio_count;
+   i915_reg_t mmioaddr[20];
+   u32 mmiodata[20];
+   u32 dc_state;
+   u32 target_dc_state;
+   u32 allowed_dc_mask;
+   intel_wakeref_t wakeref;
+};
+
void intel_dmc_ucode_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_ucode_fini(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cb02618ba15..b5962768a1f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
#include "display/intel_bios.h"
#include "display/intel_display.h"
#include "display/intel_display_power.h"
+#include "display/intel_dmc.h"
#include "display/intel_dpll_mgr.h"
#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
@@ -328,23 +329,6 @@ struct drm_i915_display_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
};

-struct intel_dmc {
-   struct work_struct work;
-   const char *fw_path;
-   u32 required_version;
-   u32 max_fw_size; /* bytes */
-   u32 *dmc_payload;
-   u32 dmc_fw_size; /* dwords */
-   u32 version;
-   u32 mmio_count;
-   i915_reg_t mmioaddr[20];
-   u32 mmiodata[20];
-   u32 dc_state;
-   u32 target_dc_state;
-   u32 allowed_dc_mask;
-   intel_wakeref_t wakeref;
-};
-
enum i915_cache_level {
I915_CACHE_NONE = 0,
I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
--
2.25.0

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/90164/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10132 -> Patchwork_20190


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@mman:
- {fi-tgl-dsi}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-tgl-dsi/igt@i915_selftest@l...@mman.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-tgl-dsi/igt@i915_selftest@l...@mman.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][3] ([i915#1372]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-elk-e7500:   [SKIP][5] ([fdo#109271]) -> [PASS][6] +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-elk-e7500/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-elk-e7500/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][7] ([i915#2782] / [i915#2940] / 
[i915#3462]) -> [DMESG-FAIL][8] ([i915#3462])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2:  [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] 
([i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-tgl-u2/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-edid-read:
- fi-elk-e7500:   [SKIP][11] ([fdo#109271]) -> [SKIP][12] ([fdo#109271] 
/ [fdo#111827]) +8 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-elk-e7500/igt@kms_chamel...@dp-edid-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-elk-e7500/igt@kms_chamel...@dp-edid-read.html

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] / 
[i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-cfl-8700k/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-cfl-8700k/igt@run...@aborted.html
- fi-skl-6600u:   [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][16] ([i915#1436] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-skl-6600u/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-skl-6600u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][17] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][18] ([i915#1436] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-kbl-soraka/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-kbl-soraka/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][19] ([i915#2426] / [i915#3363]) -> [FAIL][20] 
([i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-cfl-guc/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-cfl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][22] ([i915#1436] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-kbl-7567u/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-kbl-7567u/igt@run...@aborted.html
- fi-skl-guc: [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][24] ([i915#1436] / [i915#3363])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10132/fi-skl-guc/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20190/fi-skl-guc/igt@run...@aborted.html
- fi-skl-6700k2:  [FAIL][25] ([i915#1436] / 

Re: [Intel-gfx] [RFC PATCH 39/97] drm/i915/guc: Increase size of CTB buffers

[Matthew Brost]

On Tue, May 25, 2021 at 10:24:09AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:13, Matthew Brost wrote:
> > With the introduction of non-blocking CTBs more than one CTB can be in
> > flight at a time. Increasing the size of the CTBs should reduce how
> > often software hits the case where no space is available in the CTB
> > buffer.
> 
> I'd move this before the patch which adds the non-blocking send since that
> one claims congestion should be rare with properly sized buffers. So it
> makes sense to have them sized properly back before that one.
>

IMO patch ordering is a bit of bikeshed. All these CTBs changes required
for GuC submission (34-40, 54) will get posted its own series and get
merged together. None of the individual patches break anything or is any
of this code really used until GuC submission is turned on. I can move
this when I post these patches by themselves but I just don't really see
the point either way.

Matt
 
> Regards,
> 
> Tvrtko
> 
> > Cc: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ---
> >   1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 77dfbc94dcc3..d6895d29ed2d 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -63,11 +63,16 @@ static inline struct drm_device *ct_to_drm(struct 
> > intel_guc_ct *ct)
> >*  ++---+--+
> >*
> >* Size of each `CT Buffer`_ must be multiple of 4K.
> > - * As we don't expect too many messages, for now use minimum sizes.
> > + * We don't expect too many messages in flight at any time, unless we are
> > + * using the GuC submission. In that case each request requires a minimum
> > + * 16 bytes which gives us a maximum 256 queue'd requests. Hopefully this
> > + * enough space to avoid backpressure on the driver. We increase the size
> > + * of the receive buffer (relative to the send) to ensure a G2H response
> > + * CTB has a landing spot.
> >*/
> >   #define CTB_DESC_SIZE ALIGN(sizeof(struct 
> > guc_ct_buffer_desc), SZ_2K)
> >   #define CTB_H2G_BUFFER_SIZE   (SZ_4K)
> > -#define CTB_G2H_BUFFER_SIZE(SZ_4K)
> > +#define CTB_G2H_BUFFER_SIZE(4 * CTB_H2G_BUFFER_SIZE)
> >   #define MAX_US_STALL_CTB  100
> > @@ -753,7 +758,7 @@ static int ct_read(struct intel_guc_ct *ct, struct 
> > ct_incoming_msg **msg)
> > /* beware of buffer wrap case */
> > if (unlikely(available < 0))
> > available += size;
> > -   CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
> > +   CT_DEBUG(ct, "available %d (%u:%u:%u)\n", available, head, tail, size);
> > GEM_BUG_ON(available < 0);
> > header = cmds[head];
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 44/97] drm/i915/guc: Implement GuC submission tasklet

[Matthew Brost]

On Tue, May 25, 2021 at 10:43:32AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Implement GuC submission tasklet for new interface. The new GuC
> > interface uses H2G to submit contexts to the GuC. Since H2G use a single
> > channel, a single tasklet submits is used for the submission path. As
> > such a global struct intel_engine_cs has been added to leverage the
> > existing scheduling code.
> > 
> > Also the per engine interrupt handler has been updated to disable the
> > rescheduling of the physical engine tasklet, when using GuC scheduling,
> > as the physical engine tasklet is no longer used.
> > 
> > In this patch the field, guc_id, has been added to intel_context and is
> > not assigned. Patches later in the series will assign this value.
> > 
> > Cc: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_context_types.h |   9 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h|   4 +
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 233 +-
> >   3 files changed, 127 insertions(+), 119 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index ed8c447a7346..bb6fef7eae52 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -136,6 +136,15 @@ struct intel_context {
> > struct intel_sseu sseu;
> > u8 wa_bb_page; /* if set, page num reserved for context workarounds */
> > +
> > +   /* GuC scheduling state that does not require a lock. */
> > +   atomic_t guc_sched_state_no_lock;
> > +
> > +   /*
> > +* GuC lrc descriptor ID - Not assigned in this patch but future patches
> > +* in the series will.
> > +*/
> > +   u16 guc_id;
> >   };
> >   #endif /* __INTEL_CONTEXT_TYPES__ */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 2eb6c497e43c..d32866fe90ad 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -30,6 +30,10 @@ struct intel_guc {
> > struct intel_guc_log log;
> > struct intel_guc_ct ct;
> > +   /* Global engine used to submit requests to GuC */
> > +   struct i915_sched_engine *sched_engine;
> > +   struct i915_request *stalled_request;
> > +
> > /* intel_guc_recv interrupt related state */
> > spinlock_t irq_lock;
> > unsigned int msg_enabled_mask;
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index c2b6d27404b7..0955a8b00ee8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -60,6 +60,30 @@
> >   #define GUC_REQUEST_SIZE 64 /* bytes */
> > +/*
> > + * Below is a set of functions which control the GuC scheduling state 
> > which do
> > + * not require a lock as all state transitions are mutually exclusive. 
> > i.e. It
> > + * is not possible for the context pinning code and submission, for the 
> > same
> > + * context, to be executing simultaneously.
> > + */
> 
> Is the statement that some other locks, or other guarantees, serialise
> modification of this state, and if so, why is it using atomics?
> 

This should probably be reworded. For the atomics the transitions are
happen at the same time but the transitions are safe, for the ones
protected by the locks some other state choices are made so we need a
lock when transitioning the state.

Matt

> Regards,
> 
> Tvrtko
> 
> > +#define SCHED_STATE_NO_LOCK_ENABLEDBIT(0)
> > +static inline bool context_enabled(struct intel_context *ce)
> > +{
> > +   return (atomic_read(>guc_sched_state_no_lock) &
> > +   SCHED_STATE_NO_LOCK_ENABLED);
> > +}
> > +
> > +static inline void set_context_enabled(struct intel_context *ce)
> > +{
> > +   atomic_or(SCHED_STATE_NO_LOCK_ENABLED, >guc_sched_state_no_lock);
> > +}
> > +
> > +static inline void clr_context_enabled(struct intel_context *ce)
> > +{
> > +   atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,
> > +  >guc_sched_state_no_lock);
> > +}
> > +
> >   static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> >   {
> > return rb_entry(rb, struct i915_priolist, node);
> > @@ -122,37 +146,29 @@ static inline void set_lrc_desc_registered(struct 
> > intel_guc *guc, u32 id,
> > xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
> >   }
> > -static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> > +static int guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> >   {
> > -   /* Leaving stub as this function will be used in future patches */
> > -}
> > +   int err;
> > +   struct intel_context *ce = rq->context;
> > +   u32 action[3];
> > +   int len = 0;
> > +   bool enabled = context_enabled(ce);
> > -/*
> > - * When we're doing submissions 

Re: [Intel-gfx] [RFC PATCH 55/97] drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC

[Matthew Brost]

On Tue, May 25, 2021 at 11:06:00AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:14, Matthew Brost wrote:
> > When running the GuC the GPU can't be considered idle if the GuC still
> > has contexts pinned. As such, a call has been added in
> > intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for
> > the number of unpinned contexts to go to zero.
> > 
> > Cc: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
> >   drivers/gpu/drm/i915/gt/intel_gt.c| 18 
> >   drivers/gpu/drm/i915/gt/intel_gt.h|  2 +
> >   drivers/gpu/drm/i915/gt/intel_gt_requests.c   | 22 ++---
> >   drivers/gpu/drm/i915/gt/intel_gt_requests.h   |  7 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h|  4 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  1 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  4 +
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
> >   drivers/gpu/drm/i915/gt/uc/intel_uc.h |  5 +
> >   drivers/gpu/drm/i915/i915_debugfs.c   |  1 +
> >   drivers/gpu/drm/i915/i915_gem_evict.c |  1 +
> >   .../gpu/drm/i915/selftests/igt_live_test.c|  2 +-
> >   .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 +-
> >   14 files changed, 137 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index 8598a1c78a4c..2f5295c9408d 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -634,7 +634,8 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
> > goto insert;
> > /* Attempt to reap some mmap space from dead objects */
> > -   err = intel_gt_retire_requests_timeout(>gt, MAX_SCHEDULE_TIMEOUT);
> > +   err = intel_gt_retire_requests_timeout(>gt, MAX_SCHEDULE_TIMEOUT,
> > +  NULL);
> > if (err)
> > goto err;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index 8d77dcbad059..1742a8561f69 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -574,6 +574,24 @@ static void __intel_gt_disable(struct intel_gt *gt)
> > GEM_BUG_ON(intel_gt_pm_is_awake(gt));
> >   }
> > +int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout)
> > +{
> > +   long rtimeout;
> > +
> > +   /* If the device is asleep, we have no requests outstanding */
> > +   if (!intel_gt_pm_is_awake(gt))
> > +   return 0;
> > +
> > +   while ((timeout = intel_gt_retire_requests_timeout(gt, timeout,
> > +  )) > 0) {
> > +   cond_resched();
> > +   if (signal_pending(current))
> > +   return -EINTR;
> > +   }
> > +
> > +   return timeout ? timeout : intel_uc_wait_for_idle(>uc, rtimeout);
> > +}
> > +
> >   int intel_gt_init(struct intel_gt *gt)
> >   {
> > int err;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt.h
> > index 7ec395cace69..c775043334bf 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> > @@ -48,6 +48,8 @@ void intel_gt_driver_release(struct intel_gt *gt);
> >   void intel_gt_driver_late_release(struct intel_gt *gt);
> > +int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
> > +
> >   void intel_gt_check_and_clear_faults(struct intel_gt *gt);
> >   void intel_gt_clear_error_registers(struct intel_gt *gt,
> > intel_engine_mask_t engine_mask);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > index 647eca9d867a..c6c702f236fa 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > @@ -13,6 +13,7 @@
> >   #include "intel_gt_pm.h"
> >   #include "intel_gt_requests.h"
> >   #include "intel_timeline.h"
> > +#include "uc/intel_uc.h"
> >   static bool retire_requests(struct intel_timeline *tl)
> >   {
> > @@ -130,7 +131,8 @@ void intel_engine_fini_retire(struct intel_engine_cs 
> > *engine)
> > GEM_BUG_ON(engine->retire);
> >   }
> > -long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout)
> > +long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout,
> > + long *rtimeout)
> 
> What is 'rtimeout', I know remaining, but it can be more self-descriptive to
> start with.
>

'remaining_timeout' it is.

> It feels a bit churny for what it is. How plausible would be alternatives to
> either change existing timeout to in/out, or measure sleep internally in
> this function, or just risk sleeping twice as long by passing the original
> timeout to uc idle as well?
>

Originally had it just passing in the same value, got review feedback
saying 

Re: [Intel-gfx] [PATCH 1/1] drm/i915/gt: Declare when we enabled timeslicing

[kernel test robot]

Hi Tejas,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.13-rc3 next-20210525]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Tejas-Upadhyay/drm-i915-gt-Introduce-timeslicing-for-userspace/20210525-221509
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-r005-20210525 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/f2b7eecbbed425bfed1aea378181b5629bbcb34f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Tejas-Upadhyay/drm-i915-gt-Introduce-timeslicing-for-userspace/20210525-221509
git checkout f2b7eecbbed425bfed1aea378181b5629bbcb34f
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All errors (new ones prefixed by >>):

   In file included from include/linux/kernel.h:13,
from include/linux/list.h:9,
from drivers/gpu/drm/i915/gt/intel_engine_user.c:6:
   drivers/gpu/drm/i915/gt/intel_engine_user.c: In function 
'set_scheduler_caps':
>> drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: error: 
>> 'I915_ENGINE_TIMESLICE_BIT' undeclared (first use in this function); did you 
>> mean 'I915_ENGINE_HAS_TIMESLICES'?
  97 | #define MAP(x, y) { ilog2(I915_ENGINE_##x), 
ilog2(I915_SCHEDULER_CAP_##y) }
 |   ^~~~
   include/linux/log2.h:158:23: note: in definition of macro 'ilog2'
 158 |  __builtin_constant_p(n) ? \
 |   ^
   drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of 
macro 'MAP'
 101 |   MAP(TIMESLICE_BIT, TIMESLICING),
 |   ^~~
   drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: note: each undeclared 
identifier is reported only once for each function it appears in
  97 | #define MAP(x, y) { ilog2(I915_ENGINE_##x), 
ilog2(I915_SCHEDULER_CAP_##y) }
 |   ^~~~
   include/linux/log2.h:158:23: note: in definition of macro 'ilog2'
 158 |  __builtin_constant_p(n) ? \
 |   ^
   drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of 
macro 'MAP'
 101 |   MAP(TIMESLICE_BIT, TIMESLICING),
 |   ^~~


vim +97 drivers/gpu/drm/i915/gt/intel_engine_user.c

750e76b4f9f63c Chris Wilson   2019-08-06   90  
750e76b4f9f63c Chris Wilson   2019-08-06   91  static void 
set_scheduler_caps(struct drm_i915_private *i915)
750e76b4f9f63c Chris Wilson   2019-08-06   92  {
750e76b4f9f63c Chris Wilson   2019-08-06   93   static const struct {
750e76b4f9f63c Chris Wilson   2019-08-06   94   u8 engine;
750e76b4f9f63c Chris Wilson   2019-08-06   95   u8 sched;
750e76b4f9f63c Chris Wilson   2019-08-06   96   } map[] = {
750e76b4f9f63c Chris Wilson   2019-08-06  @97  #define MAP(x, y) { 
ilog2(I915_ENGINE_##x), ilog2(I915_SCHEDULER_CAP_##y) }
750e76b4f9f63c Chris Wilson   2019-08-06   98   MAP(HAS_PREEMPTION, 
PREEMPTION),
750e76b4f9f63c Chris Wilson   2019-08-06   99   MAP(HAS_SEMAPHORES, 
SEMAPHORES),
750e76b4f9f63c Chris Wilson   2019-08-06  100   MAP(SUPPORTS_STATS, 
ENGINE_BUSY_STATS),
f2b7eecbbed425 Tejas Upadhyay 2021-05-25  101   MAP(TIMESLICE_BIT, 
TIMESLICING),
750e76b4f9f63c Chris Wilson   2019-08-06  102  #undef MAP
750e76b4f9f63c Chris Wilson   2019-08-06  103   };
750e76b4f9f63c Chris Wilson   2019-08-06  104   struct intel_engine_cs *engine;
750e76b4f9f63c Chris Wilson   2019-08-06  105   u32 enabled, disabled;
750e76b4f9f63c Chris Wilson   2019-08-06  106  
750e76b4f9f63c Chris Wilson   2019-08-06  107   enabled = 0;
750e76b4f9f63c Chris Wilson   2019-08-06  108   disabled = 0;
750e76b4f9f63c Chris Wilson   2019-08-06  109   for_each_uabi_engine(engine, 
i915) { /* all engines must agree! */
750e76b4f9f63c Chris Wilson   2019-08-06  110   int i;
750e76b4f9f63c Chris Wilson   2019-08-06  111  
750e76b4f9f63c Chris Wilson   2019-08-06  112   if (engine->schedule)
750e76b4f9f63c Chris Wilson   2019-08-06  113   enabled |= 
(I915_SCHEDULER_CAP_ENABLED |
750e76b4f9f63c Chris Wilson   2019-08-06  114   
I915_SCHEDULER_CAP_PRIORITY);
750e76b4f9f63c Chris Wilson   2019-08-06  115   else
750e76b4f9f63c Chris Wilson   2019-08-06  116   disabled |= 
(I915_SCHEDULER_CAP_ENABLED |
750e76b4f9f63c Chris Wilson   2019-08-06  117
I915_SCHEDULER_CAP_PRIORITY);
750e76b4f9f63

Re: [Intel-gfx] [RFC PATCH 53/97] drm/i915/guc: Disable semaphores when using GuC scheduling

[Matthew Brost]

On Tue, May 25, 2021 at 10:52:01AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:14, Matthew Brost wrote:
> > Disable semaphores when using GuC scheduling as semaphores are broken in
> > the current GuC firmware.
> 
> What is "current"? Given that the patch itself is like year and a half old.
> 

Stale comment. Semaphore work with the firmware we just haven't enabled
them in the i915 with GuC submission as this an optimization and not
required for functionality.

Matt

> Regards,
> 
> Tvrtko
> 
> > Cc: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 993faa213b41..d30260ffe2a7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -230,7 +230,8 @@ static void intel_context_set_gem(struct intel_context 
> > *ce,
> > ce->timeline = intel_timeline_get(ctx->timeline);
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > -   intel_engine_has_timeslices(ce->engine))
> > +   intel_engine_has_timeslices(ce->engine) &&
> > +   intel_engine_has_semaphores(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> > intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
> > @@ -1939,7 +1940,8 @@ static int __apply_priority(struct intel_context *ce, 
> > void *arg)
> > if (!intel_engine_has_timeslices(ce->engine))
> > return 0;
> > -   if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
> > +   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > +   intel_engine_has_semaphores(ce->engine))
> > intel_context_set_use_semaphores(ce);
> > else
> > intel_context_clear_use_semaphores(ce);
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 12/97] drm/i915/guc: Don't repeat CTB layout calculations

[Matthew Brost]

On Tue, May 25, 2021 at 03:07:06PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 25.05.2021 04:53, Matthew Brost wrote:
> > On Thu, May 06, 2021 at 12:13:26PM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko 
> >>
> >> We can retrieve offsets to cmds buffers and descriptor from
> >> actual pointers that we already keep locally.
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Signed-off-by: Matthew Brost 
> >> ---
> >>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++--
> >>  1 file changed, 10 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> >> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> index dbece569fbe4..fbd6bd20f588 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >> @@ -244,6 +244,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>  {
> >>struct intel_guc *guc = ct_to_guc(ct);
> >>u32 base, cmds;
> >> +  void *blob;
> >>int err;
> >>int i;
> >>  
> >> @@ -251,15 +252,18 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>  
> >>/* vma should be already allocated and map'ed */
> >>GEM_BUG_ON(!ct->vma);
> >> +  GEM_BUG_ON(!i915_gem_object_has_pinned_pages(ct->vma->obj));
> > 
> > This doesn't really have anything to do with this patch, but again this
> > patch will be squashed into a large patch updating the GuC firmware, so
> > I think this is fine.
> 
> again, no need to squash GuC patches up to 20/97
> 

Got it. As discussed I will post patches 4-20 after I done reviewing all
of them.

Matt 

> > 
> > With that:
> > Reviewed-by: Matthew Brost 
> > 
> >>base = intel_guc_ggtt_offset(guc, ct->vma);
> >>  
> >> -  /* (re)initialize descriptors
> >> -   * cmds buffers are in the second half of the blob page
> >> -   */
> >> +  /* blob should start with send descriptor */
> >> +  blob = __px_vaddr(ct->vma->obj);
> >> +  GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
> >> +
> >> +  /* (re)initialize descriptors */
> >>for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
> >>GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
> >>  
> >> -  cmds = base + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
> >> +  cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
> >>CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
> >>  
> >>guc_ct_buffer_reset(>ctbs[i], cmds);
> >> @@ -269,12 +273,12 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >> * Register both CT buffers starting with RECV buffer.
> >> * Descriptors are in first half of the blob.
> >> */
> >> -  err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_RECV,
> >> +  err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc, 
> >> blob),
> >> INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>if (unlikely(err))
> >>goto err_out;
> >>  
> >> -  err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_SEND,
> >> +  err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc, 
> >> blob),
> >> INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>if (unlikely(err))
> >>goto err_deregister;
> >> -- 
> >> 2.28.0
> >>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 37/97] drm/i915/guc: Add stall timer to non blocking CTB send function

[Matthew Brost]

On Tue, May 25, 2021 at 04:15:15PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 24.05.2021 20:35, Matthew Brost wrote:
> > On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 06.05.2021 21:13, Matthew Brost wrote:
> >>> Implement a stall timer which fails H2G CTBs once a period of time
> >>> with no forward progress is reached to prevent deadlock.
> >>>
> >>> Also update to ct_write to return -EDEADLK rather than -EPIPE on a
> >>> corrupted descriptor.
> >>
> >> broken descriptor is really separate issue compared to no progress from
> >> GuC side, I would really like to keep old error code
> >>
> > 
> > I know you do as you have brought it up several times. Again to the rest
> > of the stack these two things mean the exact same thing.
> 
> but I guess 'the rest of the stack' is only interested if returned error
> is EBUSY or not, as all other errors are treated in the same way, thus
> no need change existing error codes
> 

No, -ENODEV means something else too. I'd rather have a single explicit
error code which means H2G is broken, take action to fix it. This is a
bikeshed, we made a decession internally to return a single error code
we really need to move on.

> >  
> >> note that broken CTB descriptor is unrecoverable error, while on other
> >> hand, in theory, we could recover from temporary non-moving CTB
> >>
> > 
> > Yea but we don't, in both cases we disable submission which in turn
> > triggers a full GPU reset.
> 
> is this current limitation or long term design?
> 

Long term design.

> I would rather expect that decision to trigger full GPU is done on solid
> foundations, like definite lost communication with the GuC or missed
> heartbeats, not that we temporarily push CTB to the limit
> 

The intent is to have a large enough value here that if it is reached it
is assumed the GuC is toast and we need a full GPU reset.

> or if do we want to treat CTB processing as kind of hw health checkout
> too, what if heartbeat timeout and CTB stall time do not match ?
>

It is a health check of H2G channel.

No need for these two values to match. One is checking if the GuC can
continue make forward progress processing H2G the other is checking if
an engine can make forward progress.

Matt
 
> > 
> >>>
> >>> Signed-off-by: John Harrison 
> >>> Signed-off-by: Daniele Ceraolo Spurio 
> >>> Signed-off-by: Matthew Brost 
> >>> ---
> >>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 48 +--
> >>>  1 file changed, 45 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> index af7314d45a78..4eab319d61be 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> @@ -69,6 +69,8 @@ static inline struct drm_device *ct_to_drm(struct 
> >>> intel_guc_ct *ct)
> >>>  #define CTB_H2G_BUFFER_SIZE  (SZ_4K)
> >>>  #define CTB_G2H_BUFFER_SIZE  (SZ_4K)
> >>>  
> >>> +#define MAX_US_STALL_CTB 100
> >>
> >> nit: maybe we should make it a CONFIG value ?
> >>
> > 
> > Sure.
> > 
> >>> +
> >>>  struct ct_request {
> >>>   struct list_head link;
> >>>   u32 fence;
> >>> @@ -315,6 +317,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>  
> >>>   ct->requests.last_fence = 1;
> >>>   ct->enabled = true;
> >>> + ct->stall_time = KTIME_MAX;
> >>>  
> >>>   return 0;
> >>>  
> >>> @@ -378,7 +381,7 @@ static int ct_write(struct intel_guc_ct *ct,
> >>>   unsigned int i;
> >>>  
> >>>   if (unlikely(ctb->broken))
> >>> - return -EPIPE;
> >>> + return -EDEADLK;
> >>>  
> >>>   if (unlikely(desc->status))
> >>>   goto corrupted;
> >>> @@ -449,7 +452,7 @@ static int ct_write(struct intel_guc_ct *ct,
> >>>   CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> >>>desc->head, desc->tail, desc->status);
> >>>   ctb->broken = true;
> >>> - return -EPIPE;
> >>> + return -EDEADLK;
> >>>  }
> >>>  
> >>>  /**
> >>> @@ -494,6 +497,17 @@ static int wait_for_ct_request_update(struct 
> >>> ct_request *req, u32 *status)
> >>>   return err;
> >>>  }
> >>>  
> >>> +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
> >>> +{
> >>> + bool ret = ktime_us_delta(ktime_get(), ct->stall_time) >
> >>> + MAX_US_STALL_CTB;
> >>> +
> >>> + if (unlikely(ret))
> >>> + CT_ERROR(ct, "CT deadlocked\n");
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>>  static inline bool ctb_has_room(struct intel_guc_ct_buffer *ctb, u32 
> >>> len_dw)
> >>>  {
> >>>   struct guc_ct_buffer_desc *desc = ctb->desc;
> >>> @@ -505,6 +519,26 @@ static inline bool ctb_has_room(struct 
> >>> intel_guc_ct_buffer *ctb, u32 len_dw)
> >>>   return space >= len_dw;
> >>>  }
> >>>  
> >>> +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
> >>> +{
> >>> + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>> +
> >>> + lockdep_assert_held(>ctbs.send.lock);
> >>> +
> >>> + if 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/90164/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type 
in assignment (different address spaces)


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

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

[Matthew Brost]

On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote:
> 
> On 06/05/2021 20:13, Matthew Brost wrote:
> > Basic GuC submission support. This is the first bullet point in the
> > upstreaming plan covered in the following RFC [1].
> > 
> > At a very high level the GuC is a piece of firmware which sits between
> > the i915 and the GPU. It offloads some of the scheduling of contexts
> > from the i915 and programs the GPU to submit contexts. The i915
> > communicates with the GuC and the GuC communicates with the GPU.
> > 
> > GuC submission will be disabled by default on all current upstream
> > platforms behind a module parameter - enable_guc. A value of 3 will
> > enable submission and HuC loading via the GuC. GuC submission should
> > work on all gen11+ platforms assuming the GuC firmware is present.
> > 
> > This is a huge series and it is completely unrealistic to merge all of
> > these patches at once. Fortunately I believe we can break down the
> > series into different merges:
> > 
> > 1. Merge Chris Wilson's patches. These have already been reviewed
> > upstream and I fully agree with these patches as a precursor to GuC
> > submission.
> > 
> > 2. Update to GuC 60.1.2. These are largely Michal's patches.
> > 
> > 3. Turn on GuC/HuC auto mode by default.
> > 
> > 4. Additional patches needed to support GuC submission. This is any
> > patch not covered by 1-3 in the first 34 patches. e.g. 'Engine relative
> > MMIO'
> > 
> > 5. GuC submission support. Patches number 35+. These all don't have to
> > merge at once though as we don't actually allow GuC submission until the
> > last patch of this series.
> 
> For the GuC backend/submission part only - it seems to me none of my review
> comments I made in December 2019 have been implemented. At that point I

I wouldn't say none of the fixes have done, lots have just not
everything you wanted.

> stated, and this was all internally at the time mind you, that I do not
> think the series is ready and there were several high level issues that
> would need to be sorted out. I don't think I gave my ack or r-b back then
> and the promise was a few things would be worked on post (internal) merge.
> That was supposed to include upstream refactoring to enable GuC better
> slotting in as a backed. Fast forward a year and a half later and the only
> progress we had in this area has been deleted.
> 
> From the top of my head, and having glanced the series as posted:
> 
>  * Self-churn factor in the series is too high.

Not sure what you mean by this? The patches have been reworked
internally too much?

>  * Patch ordering issues.

We are going to clean up some of the ordering as these 97 patches are
posted in smaller mergeable series but at the end of the day this is a
bit of a bikeshed. GuC submission can't be turned until patch 97 so IMO
it really isn't all that big of a deal the order of which patches before
that land as we are not breaking anything.

>  * GuC context state machine is way too dodgy to have any confidence it can
> be read and race conditions understood.

I know you don't really like the state machine but no other real way to
not have DoS on resources and no real way to fairly distribute guc_ids
without it. I know you have had other suggestions here but none of your
suggestions either will work or they are no less complicated in the end.

For what it is worth, the state machine will get simplified when we hook
into the DRM scheduler as won't have to deal with submitting from IRQ
contexts in the backend or having more than 1 request in the backend at
a time.

>  * Context pinning code with it's magical two adds, subtract and cmpxchg is
> dodgy as well.

Daniele tried to remove this and it proved quite difficult + created
even more races in the backend code. This was prior to the pre-pin and
post-unpin code which makes this even more difficult to fix as I believe
these functions would need to be removed first. Not saying we can't
revisit this someday but I personally really like it - it is a clever
way to avoid reentering the pin / unpin code while asynchronous things
are happening rather than some complex locking scheme. Lastly, this code
has proved incredibly stable as I don't think we've had to fix a single
thing in this area since we've been using this code internally.

>  * Kludgy way of interfacing with rest of the driver instead of refactoring
> to fit (idling, breadcrumbs, scheduler, tasklets, ...).
>

Idling and breadcrumbs seem clean to me. Scheduler + tasklet are going
away once the DRM scheduler lands. No need rework those as we are just
going to rework this again.
 
> Now perhaps the latest plan is to ignore all these issues and still merge,
> then follow up with throwing it away, mostly or at least largely, in which
> case there isn't any point really to review the current state yet again. But
> it is sad that we got to this state. So just for the record - all this was
> reviewed in Nov/Dec 2019. By me among other folks and I at 

Re: [Intel-gfx] [RFC PATCH 17/97] drm/i915/guc: Stop using mutex while sending CTB messages

[Matthew Brost]

On Thu, May 06, 2021 at 12:13:31PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko 
> 
> We are no longer using descriptor to hold G2H replies and we are
> protecting access to the descriptor and command buffer by the
> separate spinlock, so we can stop using mutex.
> 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Matthew Brost 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index bee0958d8bae..cb58fa7f970c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -537,7 +537,6 @@ static int ct_send(struct intel_guc_ct *ct,
>  int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
> u32 *response_buf, u32 response_buf_size)
>  {
> - struct intel_guc *guc = ct_to_guc(ct);
>   u32 status = ~0; /* undefined */
>   int ret;
>  
> @@ -546,8 +545,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>   return -ENODEV;
>   }
>  
> - mutex_lock(>send_mutex);
> -
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> );
>   if (unlikely(ret < 0)) {
>   CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
> @@ -557,7 +554,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>action[0], ret, ret);
>   }
>  
> - mutex_unlock(>send_mutex);
>   return ret;
>  }
>  
> -- 
> 2.28.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default

[Daniel Vetter]

On Fri, May 21, 2021 at 04:09:13PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 21.05.2021 11.09, skrev Daniel Vetter:
> > Goes through all the drivers and deletes the default hook since it's
> > the default now.
> > 
> > Signed-off-by: Daniel Vetter 
> 
> Acked-by: Noralf Trønnes 

Can you perhaps also look at the prep patch right before this one?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

[Matthew Brost]

On Tue, May 25, 2021 at 04:27:49PM +0100, Tvrtko Ursulin wrote:
> 
> On 25/05/2021 14:56, Daniel Vetter wrote:
> > On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:
> > > As discussed in [1] start merging some support patches as a precursor to
> > > GuC submission the i915. This is step #1 mentioned in [1].
> > > 
> > > [1] https://patchwork.freedesktop.org/series/89844/
> > > 
> > > Signed-off-by: Matthew Brost 
> > 
> > Pushed to drm-intel-gt-next, thanks for patches Btw you can also
> > ping John H or Daniele for pushing stuff for you, should be quicker than
> > waiting for me to return from a lon w/e :-)
> > 
> > Plus I _really_ don't want to get back into the business of pushing other
> > people's work ...
> 
> To Matt - Also please take care to preserve r-b's when resurrecting patches
> because all of these three had mine from before which is now lost in git
> history.
>

Will do. Still getting used to the upstream rules and wasn't sure if
should have included your old R-Bs.

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

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

[Matthew Brost]

On Tue, May 25, 2021 at 03:56:56PM +0200, Daniel Vetter wrote:
> On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:
> > As discussed in [1] start merging some support patches as a precursor to
> > GuC submission the i915. This is step #1 mentioned in [1].
> > 
> > [1] https://patchwork.freedesktop.org/series/89844/
> > 
> > Signed-off-by: Matthew Brost 
> 
> Pushed to drm-intel-gt-next, thanks for patches Btw you can also
> ping John H or Daniele for pushing stuff for you, should be quicker than
> waiting for me to return from a lon w/e :-)
> 

Thanks for the push. I don't think John H has push rights upstream, I
know Daniele has rights but I don't think is up to date with the process
to merge patches. I can discuss this with him today and see if he can
get reenabled on this process.

Matt

> Plus I _really_ don't want to get back into the business of pushing other
> people's work ...
> 
> Cheers, Daniel
> 
> > 
> > Chris Wilson (3):
> >   drm/i915/gt: Move engine setup out of set_default_submission
> >   drm/i915/gt: Move submission_method into intel_gt
> >   drm/i915/gt: Move CS interrupt handler to the backend
> > 
> >  drivers/gpu/drm/i915/gt/intel_engine.h|  8 +-
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 19 +++-
> >  drivers/gpu/drm/i915/gt/intel_engine_types.h  | 14 +--
> >  .../drm/i915/gt/intel_execlists_submission.c  | 95 +--
> >  .../drm/i915/gt/intel_execlists_submission.h  |  3 -
> >  drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 +---
> >  drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 +
> >  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  7 ++
> >  drivers/gpu/drm/i915/gt/intel_reset.c |  7 +-
> >  .../gpu/drm/i915/gt/intel_ring_submission.c   | 12 ++-
> >  drivers/gpu/drm/i915/gt/intel_rps.c   |  2 +-
> >  drivers/gpu/drm/i915/gt/selftest_execlists.c  |  2 +-
> >  .../drm/i915/gt/selftest_ring_submission.c|  2 +-
> >  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 64 ++---
> >  .../gpu/drm/i915/gt/uc/intel_guc_submission.h |  1 -
> >  drivers/gpu/drm/i915/i915_irq.c   | 10 +-
> >  drivers/gpu/drm/i915/i915_perf.c  | 10 +-
> >  17 files changed, 199 insertions(+), 162 deletions(-)
> > 
> > -- 
> > 2.28.0
> > 
> 
> -- 
> 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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Introduce timeslicing for userspace

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Introduce timeslicing for userspace
URL   : https://patchwork.freedesktop.org/series/90539/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_user.o
In file included from ./include/linux/kernel.h:13,
 from ./include/linux/list.h:9,
 from drivers/gpu/drm/i915/gt/intel_engine_user.c:6:
drivers/gpu/drm/i915/gt/intel_engine_user.c: In function ‘set_scheduler_caps’:
drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: error: 
‘I915_ENGINE_TIMESLICE_BIT’ undeclared (first use in this function); did you 
mean ‘I915_ENGINE_HAS_TIMESLICES’?
 #define MAP(x, y) { ilog2(I915_ENGINE_##x), ilog2(I915_SCHEDULER_CAP_##y) }
   ^~~~
./include/linux/log2.h:158:23: note: in definition of macro ‘ilog2’
  __builtin_constant_p(n) ? \
   ^
drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of macro 
‘MAP’
   MAP(TIMESLICE_BIT, TIMESLICING),
   ^~~
drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: note: each undeclared 
identifier is reported only once for each function it appears in
 #define MAP(x, y) { ilog2(I915_ENGINE_##x), ilog2(I915_SCHEDULER_CAP_##y) }
   ^~~~
./include/linux/log2.h:158:23: note: in definition of macro ‘ilog2’
  __builtin_constant_p(n) ? \
   ^
drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of macro 
‘MAP’
   MAP(TIMESLICE_BIT, TIMESLICING),
   ^~~
scripts/Makefile.build:272: recipe for target 
'drivers/gpu/drm/i915/gt/intel_engine_user.o' failed
make[4]: *** [drivers/gpu/drm/i915/gt/intel_engine_user.o] Error 1
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1839: recipe for target 'drivers' failed
make: *** [drivers] Error 2


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

Re: [Intel-gfx] [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem

[Christian König]

Am 25.05.21 um 12:07 schrieb Thomas Hellström:

On Tue, 2021-05-25 at 10:58 +0100, Matthew Auld wrote:

On Tue, 25 May 2021 at 10:32, Thomas Hellström
 wrote:


On 5/25/21 11:18 AM, Matthew Auld wrote:

On Fri, 21 May 2021 at 16:33, Thomas Hellström
 wrote:

The internal ttm_bo_util memcpy uses ioremap functionality, and
while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() /
io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using
kmap_local()
semantics. As an additional benefit we then avoid the
occasional global
TLB flushes of ioremap() and consuming ioremap space,
elimination of a
critical point of failure and with a slight change of semantics
we could
also push the memcpy out async for testing and async driver
development
purposes.

A special linear iomem iterator is introduced internally to
mimic the
old ioremap behaviour for code-paths that can't immediately be
ported
over. This adds to the code size and should be considered a
temporary
solution.

Looking at the code we have a lot of checks for iomap tagged
pointers.
Ideally we should extend the core memremap functions to also
accept
uncached memory and kmap_local functionality. Then we could
strip a
lot of code.

Cc: Christian König 
Signed-off-by: Thomas Hellström <
thomas.hellst...@linux.intel.com>
---
v3:
- Split up in various TTM files and addressed review comments
by
    Christian König. Tested and fixed legacy iomap memcpy path
on i915.
---
   drivers/gpu/drm/ttm/ttm_bo_util.c  | 278 ++--
-
   drivers/gpu/drm/ttm/ttm_module.c   |  35 
   drivers/gpu/drm/ttm/ttm_resource.c | 166 +
   drivers/gpu/drm/ttm/ttm_tt.c   |  42 +
   include/drm/ttm/ttm_bo_driver.h    |  28 +++
   include/drm/ttm/ttm_caching.h  |   2 +
   include/drm/ttm/ttm_kmap_iter.h    |  61 +++
   include/drm/ttm/ttm_resource.h |  61 +++
   include/drm/ttm/ttm_tt.h   |  16 ++
   9 files changed, 508 insertions(+), 181 deletions(-)
   create mode 100644 include/drm/ttm/ttm_kmap_iter.h

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..912cbe8e60a2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device
*bdev,
  mem->bus.addr = NULL;
   }

-static int ttm_resource_ioremap(struct ttm_device *bdev,
-  struct ttm_resource *mem,
-  void **virtual)
+/**
+ * ttm_move_memcpy - Helper to perform a memcpy ttm move
operation.
+ * @bo: The struct ttm_buffer_object.
+ * @new_mem: The struct ttm_resource we're moving to (copy
destination).
+ * @new_iter: A struct ttm_kmap_iter representing the
destination resource.
+ * @src_iter: A struct ttm_kmap_iter representing the source
resource.
+ *
+ * This function is intended to be able to move out async
under a
+ * dma-fence if desired.
+ */
+void ttm_move_memcpy(struct ttm_buffer_object *bo,
+    struct ttm_resource *dst_mem,
+    struct ttm_kmap_iter *dst_iter,
+    struct ttm_kmap_iter *src_iter)
   {
-   int ret;
-   void *addr;
-
-   *virtual = NULL;
-   ret = ttm_mem_io_reserve(bdev, mem);
-   if (ret || !mem->bus.is_iomem)
-   return ret;
+   const struct ttm_kmap_iter_ops *dst_ops = dst_iter-

ops;

+   const struct ttm_kmap_iter_ops *src_ops = src_iter-

ops;

+   struct ttm_tt *ttm = bo->ttm;
+   struct dma_buf_map src_map, dst_map;
+   pgoff_t i;

-   if (mem->bus.addr) {
-   addr = mem->bus.addr;
-   } else {
-   size_t bus_size = (size_t)mem->num_pages <<
PAGE_SHIFT;
+   /* Single TTM move. NOP */
+   if (dst_ops->maps_tt && src_ops->maps_tt)
+   return;

-   if (mem->bus.caching == ttm_write_combined)
-   addr = ioremap_wc(mem->bus.offset,
bus_size);
-#ifdef CONFIG_X86
-   else if (mem->bus.caching == ttm_cached)
-   addr = ioremap_cache(mem->bus.offset,
bus_size);
-#endif
-   else
-   addr = ioremap(mem->bus.offset,
bus_size);
-   if (!addr) {
-   ttm_mem_io_free(bdev, mem);
-   return -ENOMEM;
+   /* Don't move nonexistent data. Clear destination
instead. */
+   if (src_ops->maps_tt && (!ttm ||
!ttm_tt_is_populated(ttm))) {
+   if (ttm && !(ttm->page_flags &
TTM_PAGE_FLAG_ZERO_ALLOC))
+   return;
+
+   for (i = 0; i < dst_mem->num_pages; ++i) {
+   dst_ops->map_local(dst_iter, _map,
i);
+   if (dst_map.is_iomem)
+   memset_io(dst_map.vaddr_iomem,
0, PAGE_SIZE);
+   else
+  

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Introduce timeslicing for userspace

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Introduce timeslicing for userspace
URL   : https://patchwork.freedesktop.org/series/90538/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gt/intel_engine_user.o
In file included from ./include/linux/kernel.h:13,
 from ./include/linux/list.h:9,
 from drivers/gpu/drm/i915/gt/intel_engine_user.c:6:
drivers/gpu/drm/i915/gt/intel_engine_user.c: In function ‘set_scheduler_caps’:
drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: error: 
‘I915_ENGINE_TIMESLICE_BIT’ undeclared (first use in this function); did you 
mean ‘I915_ENGINE_HAS_TIMESLICES’?
 #define MAP(x, y) { ilog2(I915_ENGINE_##x), ilog2(I915_SCHEDULER_CAP_##y) }
   ^~~~
./include/linux/log2.h:158:23: note: in definition of macro ‘ilog2’
  __builtin_constant_p(n) ? \
   ^
drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of macro 
‘MAP’
   MAP(TIMESLICE_BIT, TIMESLICING),
   ^~~
drivers/gpu/drm/i915/gt/intel_engine_user.c:97:27: note: each undeclared 
identifier is reported only once for each function it appears in
 #define MAP(x, y) { ilog2(I915_ENGINE_##x), ilog2(I915_SCHEDULER_CAP_##y) }
   ^~~~
./include/linux/log2.h:158:23: note: in definition of macro ‘ilog2’
  __builtin_constant_p(n) ? \
   ^
drivers/gpu/drm/i915/gt/intel_engine_user.c:101:3: note: in expansion of macro 
‘MAP’
   MAP(TIMESLICE_BIT, TIMESLICING),
   ^~~
scripts/Makefile.build:272: recipe for target 
'drivers/gpu/drm/i915/gt/intel_engine_user.o' failed
make[4]: *** [drivers/gpu/drm/i915/gt/intel_engine_user.o] Error 1
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1839: recipe for target 'drivers' failed
make: *** [drivers] Error 2


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove the repeated declaration

[Patchwork]

== Series Details ==

Series: drm/i915: Remove the repeated declaration
URL   : https://patchwork.freedesktop.org/series/90524/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10131 -> Patchwork_20187


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2:  [FAIL][7] ([i915#2416]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-tgl-u2:  [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] 
([i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-tgl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-bdw-5557u:   [FAIL][11] ([i915#1602] / [i915#2029]) -> [FAIL][12] 
([i915#3462])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-bdw-5557u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][14] ([i915#1436] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-kbl-soraka/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][15] ([i915#1436] / [i915#3363]) -> [FAIL][16] 
([i915#1436] / [i915#2426] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-kbl-guc/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-kbl-guc/igt@run...@aborted.html
- fi-skl-guc: [FAIL][17] ([i915#1436] / [i915#3363]) -> [FAIL][18] 
([i915#1436] / [i915#2426] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10131/fi-skl-guc/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20187/fi-skl-guc/igt@run...@aborted.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2416]: https://gitlab.freedesktop.org/drm/intel/issues/2416
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
  [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: 

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

[Alex Deucher]

On Fri, May 14, 2021 at 12:31 PM Jason Ekstrand  wrote:
>
> Pulling a few threads together...
>
> On Mon, May 10, 2021 at 1:39 PM Francisco Jerez  wrote:
> >
> > I agree with Martin on this.  Given that using GuC currently involves
> > making your open-source graphics stack rely on a closed-source
> > cryptographically-protected blob in order to submit commands to the GPU,
> > and given that it is /still/ possible to use the GPU without it, I'd
> > expect some strong material justification for making the switch (like,
> > it improves performance of test-case X and Y by Z%, or, we're truly
> > sorry but we cannot program your GPU anymore with a purely open-source
> > software stack).  Any argument based on the apparent direction of the
> > wind doesn't sound like a material engineering reason to me, and runs
> > the risk of being self-fulfilling if it leads us to do the worse thing
> > for our users just because we have the vague feeling that it is the
> > general trend, even though we may have had the means to obtain a better
> > compromise for them.
>
> I think it's important to distinguish between landing code to support
> GuC submission and requiring it in order to use the GPU.  We've got
> the execlist back-end and it's not going anywhere, at least not for
> older hardware, and it will likely keep working as long as execlists
> remain in the hardware.  What's being proposed here is a new back-end
> which, yes, depends on firmware and can be used for more features.
>
> I'm well aware of the slippery slope argument that's implicitly being
> used here even if no one is actually saying it:  If we land GuC
> support in i915 in any form then Intel HW engineers will say "See,
> Linux supports GuC now; we can rip out execlists" and we'll end up in
> the dystopia of closed-source firmware.  If upstream continues to push
> back on GuC in any form then they'll be forced to keep execlists.
> I'll freely admit that there is probably some truth to this.  However,
> I really doubt that it's going to work long-term.  If the HW
> architects are determined enough to rip it out, they will.

You want to stay on the same interfaces as Windows does, like it or
not.  The market is bigger and there is a lot more validation effort.
Even if support for the old way doesn't go away, it won't be as well
tested.  For AMD, we tried to stay on some of the older interfaces on
a number products in the past and ran into lots of subtle issues,
especially around power management related things like clock and power
gating.  There are just too many handshakes and stuff required to make
all of that work smoothly.  It can be especially challenging when the
issues show up well after launch and the firmware and hardware teams
have already moved on to the next projects and have to page the older
projects back into their minds.

Alex


>
> If GuC is really inevitable, then it's in our best interests to land
> at least beta support earlier.  There are a lot of questions that
> people have brought up around back-ports, dealing with stable kernels,
> stability concerns, etc.  The best way to sort those out is to land
> the code and start dealing with the issues.  We can't front-load
> solving every possible issue or the code will never land.  But maybe
> that's people's actual objective?
>
>
> On Wed, May 12, 2021 at 1:26 AM Martin Peres  wrote:
> >
> > On 11/05/2021 19:39, Matthew Brost wrote:
> > > On Tue, May 11, 2021 at 08:26:59AM -0700, Bloomfield, Jon wrote:
> > >>> On 10/05/2021 19:33, Daniel Vetter wrote:
> >  On Mon, May 10, 2021 at 3:55 PM Martin Peres 
> > >>> wrote:
> > >>>
> > >>> However, if the GuC is actually helping i915, then why not open source
> > >>> it and drop all the issues related to its stability? Wouldn't it be the
> > >>> perfect solution, as it would allow dropping execlist support for newer
> > >>> HW, and it would eliminate the concerns about maintenance of stable
> > >>> releases of Linux?
>
> I would like to see that happen.  I know there was some chatter about
> it for a while and then the discussions got killed.  I'm not sure what
> happened, to be honest.  However, I don't think we can make any
> guarantees or assumptions there, I'm afraid. :-(
>
> > >> That the major version of the FW is high is not due to bugs - Bugs don't 
> > >> trigger major version bumps anyway.
> >
> > Of course, where did I say they would?
>
> I think the concern here is that old kernels will require old major
> GuC versions because interfaces won't be backwards-compatible and then
> those kernels won't get bug fixes.  That's a legitimate concern.
> Given the Linux usage model, I think it's fair to require either
> backwards-compatibility with GuC interfaces and validation of that
> backwards-compatibility or stable releases with bug fixes for a good
> long while.  I honestly can't say whether or not we've really scoped
> that.  Jon?
>
> > >> We have been using GuC as the sole mechanism for submission on Windows 
> > >> since Gen8, 

Re: [Intel-gfx] [PATCH 6/6] RFC: dma-buf: Add an API for importing sync files (v6)

[Daniel Vetter]

On Mon, May 24, 2021 at 03:59:54PM -0500, Jason Ekstrand wrote:
> This patch is analogous to the previous sync file export patch in that
> it allows you to import a sync_file into a dma-buf.  Unlike the previous
> patch, however, this does add genuinely new functionality to dma-buf.
> Without this, the only way to attach a sync_file to a dma-buf is to
> submit a batch to your driver of choice which waits on the sync_file and
> claims to write to the dma-buf.  Even if said batch is a no-op, a submit
> is typically way more overhead than just attaching a fence.  A submit
> may also imply extra synchronization with other work because it happens
> on a hardware queue.
> 
> In the Vulkan world, this is useful for dealing with the out-fence from
> vkQueuePresent.  Current Linux window-systems (X11, Wayland, etc.) all
> rely on dma-buf implicit sync.  Since Vulkan is an explicit sync API, we
> get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
> those as an exclusive (write) fence on the dma-buf.  We handle it in
> Mesa today with the above mentioned dummy submit trick.  This ioctl
> would allow us to set it directly without the dummy submit.
> 
> This may also open up possibilities for GPU drivers to move away from
> implicit sync for their kernel driver uAPI and instead provide sync
> files and rely on dma-buf import/export for communicating with other
> implicit sync clients.
> 
> We make the explicit choice here to only allow setting RW fences which
> translates to an exclusive fence on the dma_resv.  There's no use for
> read-only fences for communicating with other implicit sync userspace
> and any such attempts are likely to be racy at best.  When we got to
> insert the RW fence, the actual fence we set as the new exclusive fence
> is a combination of the sync_file provided by the user and all the other
> fences on the dma_resv.  This ensures that the newly added exclusive
> fence will never signal before the old one would have and ensures that
> we don't break any dma_resv contracts.  We require userspace to specify
> RW in the flags for symmetry with the export ioctl and in case we ever
> want to support read fences in the future.
> 
> There is one downside here that's worth documenting:  If two clients
> writing to the same dma-buf using this API race with each other, their
> actions on the dma-buf may happen in parallel or in an undefined order.
> Both with and without this API, the pattern is the same:  Collect all
> the fences on dma-buf, submit work which depends on said fences, and
> then set a new exclusive (write) fence on the dma-buf which depends on
> said work.  The difference is that, when it's all handled by the GPU
> driver's submit ioctl, the three operations happen atomically under the
> dma_resv lock.  If two userspace submits race, one will happen before
> the other.  You aren't guaranteed which but you are guaranteed that
> they're strictly ordered.  If userspace manages the fences itself, then
> these three operations happen separately and the two render operations
> may happen genuinely in parallel or get interleaved.  However, this is a
> case of userspace racing with itself.  As long as we ensure userspace
> can't back the kernel into a corner, it should be fine.
> 
> v2 (Jason Ekstrand):
>  - Use a wrapper dma_fence_array of all fences including the new one
>when importing an exclusive fence.
> 
> v3 (Jason Ekstrand):
>  - Lock around setting shared fences as well as exclusive
>  - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
>  - Initialize ret to 0 in dma_buf_wait_sync_file
> 
> v4 (Jason Ekstrand):
>  - Use the new dma_resv_get_singleton helper
> 
> v5 (Jason Ekstrand):
>  - Rename the IOCTLs to import/export rather than wait/signal
>  - Drop the WRITE flag and always get/set the exclusive fence
> 
> v5 (Jason Ekstrand):
>  - Split import and export into separate patches
>  - New commit message
> 
> Signed-off-by: Jason Ekstrand 
> ---
>  drivers/dma-buf/dma-buf.c| 34 ++
>  include/uapi/linux/dma-buf.h |  1 +
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f23d939e0e833..0a50c19dcf015 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -419,6 +419,38 @@ static long dma_buf_export_sync_file(struct dma_buf 
> *dmabuf,
>   put_unused_fd(fd);
>   return ret;
>  }
> +
> +static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
> +  const void __user *user_data)
> +{
> + struct dma_buf_sync_file arg;
> + struct dma_fence *fence, *singleton = NULL;
> + int ret = 0;
> +
> + if (copy_from_user(, user_data, sizeof(arg)))
> + return -EFAULT;
> +
> + if (arg.flags != DMA_BUF_SYNC_RW)
> + return -EINVAL;
> +
> + fence = sync_file_get_fence(arg.fd);
> + if (!fence)
> + return -EINVAL;
> +
> + dma_resv_lock(dmabuf->resv, NULL);

Re: [Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915

[Tvrtko Ursulin]

On 25/05/2021 14:56, Daniel Vetter wrote:

On Fri, May 21, 2021 at 11:32:12AM -0700, Matthew Brost wrote:

As discussed in [1] start merging some support patches as a precursor to
GuC submission the i915. This is step #1 mentioned in [1].

[1] https://patchwork.freedesktop.org/series/89844/

Signed-off-by: Matthew Brost 


Pushed to drm-intel-gt-next, thanks for patches Btw you can also
ping John H or Daniele for pushing stuff for you, should be quicker than
waiting for me to return from a lon w/e :-)

Plus I _really_ don't want to get back into the business of pushing other
people's work ...


To Matt - Also please take care to preserve r-b's when resurrecting 
patches because all of these three had mine from before which is now 
lost in git history.


Regards,

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

Re: [Intel-gfx] [PATCH 5/6] RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked

[Daniel Vetter]

On Mon, May 24, 2021 at 03:59:53PM -0500, Jason Ekstrand wrote:
> For dma-buf sync_file import, we want to get all the fences on a
> dma_resv plus one more.  We could wrap the fence we get back in an array
> fence or we could make dma_resv_get_singleton_unlocked take "one more"
> to make this case easier.
> 
> Signed-off-by: Jason Ekstrand 

Ah now it makes very obviously sense.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/dma-buf/dma-buf.c  |  2 +-
>  drivers/dma-buf/dma-resv.c | 23 +--
>  include/linux/dma-resv.h   |  3 ++-
>  3 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 86efe71c0db96..f23d939e0e833 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -386,7 +386,7 @@ static long dma_buf_export_sync_file(struct dma_buf 
> *dmabuf,
>   return fd;
>  
>   if (arg.flags & DMA_BUF_SYNC_WRITE) {
> - fence = dma_resv_get_singleton_unlocked(dmabuf->resv);
> + fence = dma_resv_get_singleton_unlocked(dmabuf->resv, NULL);
>   if (IS_ERR(fence)) {
>   ret = PTR_ERR(fence);
>   goto err_put_fd;
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 312a3a59dac6a..3c0ef8d0f599b 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -527,6 +527,7 @@ EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
>  /**
>   * dma_resv_get_singleton_unlocked - get a single fence for the dma_resv 
> object
>   * @obj: the reservation object
> + * @extra: extra fence to add to the resulting array
>   * @result: resulting dma_fence
>   *
>   * Get a single fence representing all unsignaled fences in the dma_resv 
> object
> @@ -536,7 +537,8 @@ EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
>   * RETURNS
>   * Returns -NOMEM if allocations fail, zero otherwise.
>   */
> -struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj)
> +struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj,
> +   struct dma_fence *extra)
>  {
>   struct dma_fence *result, **resv_fences, *fence, *chain, **fences;
>   struct dma_fence_array *array;
> @@ -547,7 +549,7 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
> dma_resv *obj)
>   if (err)
>   return ERR_PTR(err);
>  
> - if (num_resv_fences == 0)
> + if (num_resv_fences == 0 && !extra)
>   return NULL;
>  
>   num_fences = 0;
> @@ -563,6 +565,16 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
> dma_resv *obj)
>   }
>   }
>  
> + if (extra) {
> + dma_fence_deep_dive_for_each(fence, chain, j, extra) {
> + if (dma_fence_is_signaled(fence))
> + continue;
> +
> + result = fence;
> + ++num_fences;
> + }
> + }
> +
>   if (num_fences <= 1) {
>   result = dma_fence_get(result);
>   goto put_resv_fences;
> @@ -583,6 +595,13 @@ struct dma_fence *dma_resv_get_singleton_unlocked(struct 
> dma_resv *obj)
>   }
>   }
>  
> + if (extra) {
> + dma_fence_deep_dive_for_each(fence, chain, j, extra) {
> + if (dma_fence_is_signaled(fence))
> + fences[num_fences++] = dma_fence_get(fence);
> + }
> + }
> +
>   if (num_fences <= 1) {
>   result = num_fences ? fences[0] : NULL;
>   kfree(fences);
> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> index c529ccee94bc5..156d989e95ab4 100644
> --- a/include/linux/dma-resv.h
> +++ b/include/linux/dma-resv.h
> @@ -285,7 +285,8 @@ int dma_resv_get_fences_unlocked(struct dma_resv *obj,
>  
>  int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
>  
> -struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj);
> +struct dma_fence *dma_resv_get_singleton_unlocked(struct dma_resv *obj,
> +   struct dma_fence *extra);
>  
>  long dma_resv_wait_timeout_unlocked(struct dma_resv *obj, bool wait_all, 
> bool intr,
>   unsigned long timeout);
> -- 
> 2.31.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

[Daniel Vetter]

On Tue, May 25, 2021 at 5:05 PM Christian König
 wrote:
>
> Hi Daniel,
>
> Am 25.05.21 um 15:05 schrieb Daniel Vetter:
> > Hi Christian,
> >
> > On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote:
> >> Am 21.05.21 um 20:31 schrieb Daniel Vetter:
> >> This works by adding the fence of the last eviction DMA operation to BOs
> >> when their backing store is newly allocated. That's what the
> >> ttm_bo_add_move_fence() function you stumbled over is good for: 
> >> https://elixir.bootlin.com/linux/v5.13-rc2/source/drivers/gpu/drm/ttm/ttm_bo.c#L692
> >>
> >> Now the problem is it is possible that the application is terminated before
> >> it can complete it's command submission. But since resource management only
> >> waits for the shared fences when there are some there is a chance that we
> >> free up memory while it is still in use.
> > Hm where is this code? Would help in my audit that I wanted to do this
> > week? If you look at most other places like
> > drm_gem_fence_array_add_implicit() I mentioned earlier, then we don't
> > treat the shared fences special and always also include the exclusive one.
>
> See amdgpu_gem_object_close():
>
> ...
>  fence = dma_resv_get_excl(bo->tbo.base.resv);
>  if (fence) {
>  amdgpu_bo_fence(bo, fence, true);
>  fence = NULL;
>  }
> ...
>
> We explicitly added that because resource management of some other
> driver was going totally bananas without that.
>
> But I'm not sure which one that was. Maybe dig a bit in the git and
> mailing history of that.

Hm I looked and it's

commit 82c416b13cb7d22b96ec0888b296a48dff8a09eb
Author: Christian König 
Date:   Thu Mar 12 12:03:34 2020 +0100

   drm/amdgpu: fix and cleanup amdgpu_gem_object_close v4

That sounded more like amdgpu itself needing this, not another driver?

But looking at amdgpu_vm_bo_update_mapping() it seems to pick the
right fencing mode for gpu pte clearing, so I'm really not sure what
the bug was that you worked around here?The implementation boils down
to amdgpu_sync_resv() which syncs for the exclusive fence, always. And
there's nothing else that I could find in public history at least, no
references to bug reports or anything. I think you need to dig
internally, because as-is I'm not seeing the problem here.

Or am I missing something here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: relax 2big checking around initial fb

[Imre Deak]

On Tue, May 25, 2021 at 02:25:15PM +0100, Matthew Auld wrote:
> On Fri, 7 May 2021 at 10:12, Matthew Auld  wrote:
> >
> > From: Chris Wilson 
> >
> > The kernel prefers enabling fbc over the initial fb, since this leads to
> > actual runtime power savings, so if the initial fb is deemed too big
> > using some heuristic, then we simply skip allocating stolen for it.
> > However if the kernel is not configured with fbcon then it should be
> > possible to relax this, since unlike with fbcon the display server
> > shouldn't preserve it when later replacing it, and so we should be able
> > to re-use the stolen memory for fbc and friends. This patch is reported
> > to fix some flicker seen during boot splash on some devices.
> >
> > Signed-off-by: Chris Wilson 
> > Signed-off-by: Matthew Auld 
> > Cc: Lee Shawn C 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> 
> Ville, Imre, or somebody else with display experience, does this at
> least look somewhat reasonable?
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index ec2d3fa60003..0ee1f0213fd9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1455,7 +1455,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> >  * important and we should probably use that space with FBC or other
> >  * features.
> >  */
> > -   if (size * 2 > i915->stolen_usable_size)
> > +   if (IS_ENABLED(FRAMEBUFFER_CONSOLE) && size * 2 > 
> > i915->stolen_usable_size)

Makes sense and aligns with how the FB object is allocated in intelfb_alloc():

Reviewed-by: Imre Deak 


> > return NULL;
> >
> > obj = i915_gem_object_create_stolen_for_preallocated(i915, base, 
> > size);
> > --
> > 2.26.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] dma-buf: Add an API for exporting sync files (v9)

[Daniel Vetter]

On Mon, May 24, 2021 at 03:59:52PM -0500, Jason Ekstrand wrote:
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model.  This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland.  The client -> compositor half of the synchronization isn't too
> bad, at least on intel, because we can control whether or not i915
> synchronizes on the buffer and whether or not it's considered written.
> 
> The harder part is the compositor -> client synchronization when we get
> the buffer back from the compositor.  We're required to be able to
> provide the client with a VkSemaphore and VkFence representing the point
> in time where the window system (compositor and/or display) finished
> using the buffer.  With current APIs, it's very hard to do this in such
> a way that we don't get confused by the Vulkan driver's access of the
> buffer.  In particular, once we tell the kernel that we're rendering to
> the buffer again, any CPU waits on the buffer or GPU dependencies will
> wait on some of the client rendering and not just the compositor.
> 
> This new IOCTL solves this problem by allowing us to get a snapshot of
> the implicit synchronization state of a given dma-buf in the form of a
> sync file.  It's effectively the same as a poll() or I915_GEM_WAIT only,
> instead of CPU waiting directly, it encapsulates the wait operation, at
> the current moment in time, in a sync_file so we can check/wait on it
> later.  As long as the Vulkan driver does the sync_file export from the
> dma-buf before we re-introduce it for rendering, it will only contain
> fences from the compositor or display.  This allows to accurately turn
> it into a VkFence or VkSemaphore without any over- synchronization.
> 
> v2 (Jason Ekstrand):
>  - Use a wrapper dma_fence_array of all fences including the new one
>when importing an exclusive fence.
> 
> v3 (Jason Ekstrand):
>  - Lock around setting shared fences as well as exclusive
>  - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
>  - Initialize ret to 0 in dma_buf_wait_sync_file
> 
> v4 (Jason Ekstrand):
>  - Use the new dma_resv_get_singleton helper
> 
> v5 (Jason Ekstrand):
>  - Rename the IOCTLs to import/export rather than wait/signal
>  - Drop the WRITE flag and always get/set the exclusive fence
> 
> v6 (Jason Ekstrand):
>  - Drop the sync_file import as it was all-around sketchy and not nearly
>as useful as import.
>  - Re-introduce READ/WRITE flag support for export
>  - Rework the commit message
> 
> v7 (Jason Ekstrand):
>  - Require at least one sync flag
>  - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
>  - Use _rcu helpers since we're accessing the dma_resv read-only
> 
> v8 (Jason Ekstrand):
>  - Return -ENOMEM if the sync_file_create fails
>  - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
> 
> v9 (Jason Ekstrand):
>  - Add documentation for the new ioctl
> 
> v10 (Jason Ekstrand):
>  - Go back to dma_buf_sync_file as the ioctl struct name
> 
> Signed-off-by: Jason Ekstrand 
> Acked-by: Simon Ser 
> Acked-by: Christian König 

So one thing we need to capture here is that for amdgpu currently this
misreports, because amdgpu doesn't store write fences in the exclusive
slot. So that's a bit annoying.

If userspace only uses this sync_file to avoid stalls, then I think that's
all fine, we just lie about the stall that will still happen and maybe
there's more judder than necessary.

More annoying is when this is used in e.g. a vulkan based compositor. But
with current amdgpu userspace the kernel forces synchronization, even with
vulkan. So again no problem.

The only thing where we really need to be careful about is that when we
add more fine-grained implicit sync support to amdgpu (which needs more
than these patches, you need a per-file opt-out of the kernel's automagic
sync), then we also must fix the amdgpu use of the exclusive slot. But
that's doable I think.

I couldn't poke holes in your argument checking.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/dma-buf/dma-buf.c| 64 
>  include/uapi/linux/dma-buf.h | 24 ++
>  2 files changed, 88 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d4529aa9d1a5a..86efe71c0db96 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -362,6 +363,64 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, 
> const char __user *buf)
>   return ret;
>  }
>  
> +#if IS_ENABLED(CONFIG_SYNC_FILE)
> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
> +  void __user *user_data)
> +{
> + struct dma_buf_sync_file arg;
> + struct dma_fence *fence = NULL;
> + struct sync_file *sync_file;
> + int fd, ret;
> +
> + if (copy_from_user(, user_data, 

Re: [Intel-gfx] [PATCH 2/6] dma-buf: Rename dma_resv helpers from _rcu to _unlocked

[Daniel Vetter]

On Mon, May 24, 2021 at 03:59:50PM -0500, Jason Ekstrand wrote:
> None of these helpers actually leak any RCU details to the caller.  They
> all assume you have a genuine reference, take the RCU read lock, and
> retry if needed.  Naming them with an _rcu is likely to cause callers
> more panic than needed.
> 
> Signed-off-by: Jason Ekstrand 
> Suggested-by: Daniel Vetter 

scripts/get_maintainer.pl gives you ideas whom to send this to. Somewhat
applies to most patches here since I don't think you've cc'ed Christian on
the entire pile.
-Daniel

> ---
>  drivers/dma-buf/dma-buf.c |  2 +-
>  drivers/dma-buf/dma-resv.c| 28 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  8 +++---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
>  drivers/gpu/drm/drm_gem.c |  6 ++--
>  drivers/gpu/drm/drm_gem_atomic_helper.c   |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c |  4 +--
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |  4 +--
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/dma_resv_utils.c |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_busy.c  |  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_wait.c  | 10 +++
>  drivers/gpu/drm/i915/i915_request.c   |  4 +--
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  4 +--
>  drivers/gpu/drm/msm/msm_gem.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/wndw.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c |  2 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  2 +-
>  drivers/gpu/drm/panfrost/panfrost_job.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c   |  6 ++--
>  drivers/gpu/drm/radeon/radeon_mn.c|  2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c  | 12 
>  drivers/gpu/drm/vgem/vgem_fence.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c|  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|  2 +-
>  include/linux/dma-resv.h  | 18 ++--
>  36 files changed, 79 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb..d4529aa9d1a5a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1147,7 +1147,7 @@ static int __dma_buf_begin_cpu_access(struct dma_buf 
> *dmabuf,
>   long ret;
>  
>   /* Wait on any implicit rendering fences */
> - ret = dma_resv_wait_timeout_rcu(resv, write, true,
> + ret = dma_resv_wait_timeout_unlocked(resv, write, true,
> MAX_SCHEDULE_TIMEOUT);
>   if (ret < 0)
>   return ret;
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 6ddbeb5dfbf65..d6f1ed4cd4d55 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -417,7 +417,7 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
> dma_resv *src)
>  EXPORT_SYMBOL(dma_resv_copy_fences);
>  
>  /**
> - * dma_resv_get_fences_rcu - Get an object's shared and exclusive
> + * dma_resv_get_fences_unlocked - Get an object's shared and exclusive
>   * fences without update side lock held
>   * @obj: the reservation object
>   * @pfence_excl: the returned exclusive fence (or NULL)
> @@ -429,10 +429,10 @@ EXPORT_SYMBOL(dma_resv_copy_fences);
>   * exclusive fence is not specified the fence is put into the array of the
>   * shared fences as well. Returns either zero or -ENOMEM.
>   */
> -int dma_resv_get_fences_rcu(struct dma_resv *obj,
> - struct dma_fence **pfence_excl,
> - unsigned *pshared_count,
> - struct dma_fence ***pshared)
> +int dma_resv_get_fences_unlocked(struct dma_resv *obj,
> +  struct dma_fence **pfence_excl,
> +  unsigned *pshared_count,
> +  struct dma_fence ***pshared)
>  {
>   struct dma_fence **shared = NULL;
>   struct dma_fence *fence_excl;
> @@ -515,10 +515,10 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
>   *pshared = shared;
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
> +EXPORT_SYMBOL_GPL(dma_resv_get_fences_unlocked);
>  
>  /**
> - * dma_resv_wait_timeout_rcu - Wait on reservation's objects
> + * 

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

[Daniel Vetter]

On Tue, May 25, 2021 at 03:19:47PM +0100, Tvrtko Ursulin wrote:
> 
> + dri-devel as per process
> 
> On 25/05/2021 14:55, Tejas Upadhyay wrote:
> > v2: Only declare timeslicing if we can safely preempt userspace.
> 
> Commit message got butchered up somehow so you'll need to fix that at some
> point.
> 
> Regards,
> 
> Tvrtko
> 
> > Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Reviewed-by: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
> >   include/uapi/drm/i915_drm.h | 1 +
> >   2 files changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 3cca7ea2d6ea..12d165566ed2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private 
> > *i915)
> > MAP(HAS_PREEMPTION, PREEMPTION),
> > MAP(HAS_SEMAPHORES, SEMAPHORES),
> > MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
> > +   MAP(TIMESLICE_BIT, TIMESLICING),
> >   #undef MAP
> > };
> > struct intel_engine_cs *engine;
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index c2c7759b7d2e..af2212d6113c 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -572,6 +572,7 @@ typedef struct drm_i915_irq_wait {
> >   #define   I915_SCHEDULER_CAP_PREEMPTION   (1ul << 2)
> >   #define   I915_SCHEDULER_CAP_SEMAPHORES   (1ul << 3)
> >   #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS(1ul << 4)
> > +#define   I915_SCHEDULER_CAP_TIMESLICING   (1ul << 5)

Since this is uapi I think we should at least have some nice kerneldoc
that explains what exactly this is, what for (link to userspace) and all
that. Ideally also minimally filing in the gaps in our uapi docs for stuff
this references.
-Daniel

> >   #define I915_PARAM_HUC_STATUS  42
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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

[Intel-gfx] drm-misc-next

[Thomas Zimmermann]

Hi Dave and Daniel,

here's this week's PR for drm-misc-next. Besides the usual round of 
fixes, amdgpu now supports hot unplug and GEM CMA supports cached page 
mappings.


No standard email this week, sorry. Dim pushed the tag into the repo, 
but then failed to create the rsp email from it.


Please merge from

git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-05-25

since

  30039405ac25 ("MAINTAINERS: repair reference in DRM DRIVER FOR SIMPLE 
FRAMEBUFFERS")


up to

  4a791cb6d34f ("drm/ingenic: Add option to alloc cached GEM buffers")


Best regards
Thomas

drm-misc-next-2021-05-25:
drm-misc-next for v5.14:



UAPI Changes:



 * DRM_IOCTL_IRQ_BUSID is now marked as legacy; returns -EINVAL if

   legacy drivers are disabled



Cross-subsystem Changes:



 * PCI: Add support for dev_groups



 * vgaarb: Use ACPI HID to find integrated GPU



Core Changes:



 * Log errors in drm_gem_fb_init_with_funcs()



 * Cleanups



 * gem-cma: Add support for non-coherent (i.e., cached) page mappings



 * legacy: Drop some unnecessary includes and code; Add missing unlocks

   and frees in drm_legacy_addbufs_pci()



 * sched: Make timeout timer rearm conditional; Fix data corruptions and

   hangs



 * ttm: Remap all page faults to per-process dummy page (for device 
removal);


   Documentation



Driver Changes:



 * drm/amdgpu: A long list of patches that enable device hot-unplug



 * drm/bridge: Lt66121: Fix error code and leak in probe; Anx7625: Use

   runtime PM and add synchronous suspend/resume hooks; Ti-sn65dsi86: Fix

   a returned value's type; Anx7688: Add driver plus DT bindings;



 * drm/ingenic: Fix pixcloc for 24-bit serial panels; Use non-coherent BO

   mappings with explict synchronization if possible



 * drm/panel: Simple-panel: Add missing pm_runtime_dont_use_autosuspend()



 * drm/tve200: Convert DT bindings to YAML



 * drm/vc4: Support BCM2711 VEC plus DT bindings; Pipeline setup fixes; 
HDMI


   fixes



 * drm/virtio: Fix NULL pointer in probe; Fix double-free in probe; Free

   virtqueues in probe



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

[Tvrtko Ursulin]

+ dri-devel as per process

On 25/05/2021 14:55, Tejas Upadhyay wrote:

v2: Only declare timeslicing if we can safely preempt userspace.


Commit message got butchered up somehow so you'll need to fix that at 
some point.


Regards,

Tvrtko


Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
  include/uapi/drm/i915_drm.h | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 3cca7ea2d6ea..12d165566ed2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+   MAP(TIMESLICE_BIT, TIMESLICING),
  #undef MAP
};
struct intel_engine_cs *engine;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c2c7759b7d2e..af2212d6113c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -572,6 +572,7 @@ typedef struct drm_i915_irq_wait {
  #define   I915_SCHEDULER_CAP_PREEMPTION   (1ul << 2)
  #define   I915_SCHEDULER_CAP_SEMAPHORES   (1ul << 3)
  #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS(1ul << 4)
+#define   I915_SCHEDULER_CAP_TIMESLICING   (1ul << 5)
  
  #define I915_PARAM_HUC_STATUS		 42
  


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

Re: [Intel-gfx] [RFC PATCH 37/97] drm/i915/guc: Add stall timer to non blocking CTB send function

[Michal Wajdeczko]

On 24.05.2021 20:35, Matthew Brost wrote:
> On Mon, May 24, 2021 at 02:58:12PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 06.05.2021 21:13, Matthew Brost wrote:
>>> Implement a stall timer which fails H2G CTBs once a period of time
>>> with no forward progress is reached to prevent deadlock.
>>>
>>> Also update to ct_write to return -EDEADLK rather than -EPIPE on a
>>> corrupted descriptor.
>>
>> broken descriptor is really separate issue compared to no progress from
>> GuC side, I would really like to keep old error code
>>
> 
> I know you do as you have brought it up several times. Again to the rest
> of the stack these two things mean the exact same thing.

but I guess 'the rest of the stack' is only interested if returned error
is EBUSY or not, as all other errors are treated in the same way, thus
no need change existing error codes

>  
>> note that broken CTB descriptor is unrecoverable error, while on other
>> hand, in theory, we could recover from temporary non-moving CTB
>>
> 
> Yea but we don't, in both cases we disable submission which in turn
> triggers a full GPU reset.

is this current limitation or long term design?

I would rather expect that decision to trigger full GPU is done on solid
foundations, like definite lost communication with the GuC or missed
heartbeats, not that we temporarily push CTB to the limit

or if do we want to treat CTB processing as kind of hw health checkout
too, what if heartbeat timeout and CTB stall time do not match ?

> 
>>>
>>> Signed-off-by: John Harrison 
>>> Signed-off-by: Daniele Ceraolo Spurio 
>>> Signed-off-by: Matthew Brost 
>>> ---
>>>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 48 +--
>>>  1 file changed, 45 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index af7314d45a78..4eab319d61be 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -69,6 +69,8 @@ static inline struct drm_device *ct_to_drm(struct 
>>> intel_guc_ct *ct)
>>>  #define CTB_H2G_BUFFER_SIZE(SZ_4K)
>>>  #define CTB_G2H_BUFFER_SIZE(SZ_4K)
>>>  
>>> +#define MAX_US_STALL_CTB   100
>>
>> nit: maybe we should make it a CONFIG value ?
>>
> 
> Sure.
> 
>>> +
>>>  struct ct_request {
>>> struct list_head link;
>>> u32 fence;
>>> @@ -315,6 +317,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>  
>>> ct->requests.last_fence = 1;
>>> ct->enabled = true;
>>> +   ct->stall_time = KTIME_MAX;
>>>  
>>> return 0;
>>>  
>>> @@ -378,7 +381,7 @@ static int ct_write(struct intel_guc_ct *ct,
>>> unsigned int i;
>>>  
>>> if (unlikely(ctb->broken))
>>> -   return -EPIPE;
>>> +   return -EDEADLK;
>>>  
>>> if (unlikely(desc->status))
>>> goto corrupted;
>>> @@ -449,7 +452,7 @@ static int ct_write(struct intel_guc_ct *ct,
>>> CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>>>  desc->head, desc->tail, desc->status);
>>> ctb->broken = true;
>>> -   return -EPIPE;
>>> +   return -EDEADLK;
>>>  }
>>>  
>>>  /**
>>> @@ -494,6 +497,17 @@ static int wait_for_ct_request_update(struct 
>>> ct_request *req, u32 *status)
>>> return err;
>>>  }
>>>  
>>> +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
>>> +{
>>> +   bool ret = ktime_us_delta(ktime_get(), ct->stall_time) >
>>> +   MAX_US_STALL_CTB;
>>> +
>>> +   if (unlikely(ret))
>>> +   CT_ERROR(ct, "CT deadlocked\n");
>>> +
>>> +   return ret;
>>> +}
>>> +
>>>  static inline bool ctb_has_room(struct intel_guc_ct_buffer *ctb, u32 
>>> len_dw)
>>>  {
>>> struct guc_ct_buffer_desc *desc = ctb->desc;
>>> @@ -505,6 +519,26 @@ static inline bool ctb_has_room(struct 
>>> intel_guc_ct_buffer *ctb, u32 len_dw)
>>> return space >= len_dw;
>>>  }
>>>  
>>> +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
>>> +{
>>> +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
>>> +
>>> +   lockdep_assert_held(>ctbs.send.lock);
>>> +
>>> +   if (unlikely(!ctb_has_room(ctb, len_dw))) {
>>> +   if (ct->stall_time == KTIME_MAX)
>>> +   ct->stall_time = ktime_get();
>>> +
>>> +   if (unlikely(ct_deadlocked(ct)))
>>> +   return -EDEADLK;
>>> +   else
>>> +   return -EBUSY;
>>> +   }
>>> +
>>> +   ct->stall_time = KTIME_MAX;
>>> +   return 0;
>>> +}
>>> +
>>>  static int ct_send_nb(struct intel_guc_ct *ct,
>>>   const u32 *action,
>>>   u32 len,
>>> @@ -517,7 +551,7 @@ static int ct_send_nb(struct intel_guc_ct *ct,
>>>  
>>> spin_lock_irqsave(>lock, spin_flags);
>>>  
>>> -   ret = ctb_has_room(ctb, len + 1);
>>> +   ret = has_room_nb(ct, len + 1);
>>> if (unlikely(ret))
>>> goto out;
>>>  
>>> @@ -561,11 +595,19 @@ static int ct_send(struct intel_guc_ct *ct,
>>>  retry:
>>> spin_lock_irqsave(>ctbs.send.lock, 

[Intel-gfx] [PATCH 0/1] drm/i915/gt: Introduce timeslicing for userspace

[Tejas Upadhyay]

Test-with: 20210524124806.241439-1-tejaskumarx.surendrakumar.upadh...@intel.com

Tejas Upadhyay (1):
  drm/i915/gt: Declare when we enabled timeslicing

 drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 2 insertions(+)

-- 
2.31.1

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

[Intel-gfx] [PATCH 1/1] drm/i915/gt: Declare when we enabled timeslicing

[Tejas Upadhyay]

Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

v2: Only declare timeslicing if we can safely preempt userspace.

Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 3cca7ea2d6ea..12d165566ed2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+   MAP(TIMESLICE_BIT, TIMESLICING),
 #undef MAP
};
struct intel_engine_cs *engine;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c2c7759b7d2e..af2212d6113c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -572,6 +572,7 @@ typedef struct drm_i915_irq_wait {
 #define   I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
 #define   I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
 #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define   I915_SCHEDULER_CAP_TIMESLICING   (1ul << 5)
 
 #define I915_PARAM_HUC_STATUS   42
 
-- 
2.31.1

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