[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: wait on timeout before retry (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: wait on timeout before retry (rev3)
URL   : https://patchwork.freedesktop.org/series/105660/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11840_full -> Patchwork_105660v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-skl7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  
 Suppressed 

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

  * igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1:
- {shard-dg1}:NOTRUN -> [FAIL][2] +5 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-dg1-19/igt@kms_flip@wf_vblank-ts-check-interrupti...@c-hdmi-a1.html

  * igt@kms_plane_scaling@planes-upscale-20x20@pipe-d-hdmi-a-1:
- {shard-dg1}:NOTRUN -> [SKIP][3] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-dg1-19/igt@kms_plane_scaling@planes-upscale-20...@pipe-d-hdmi-a-1.html

  

### Piglit changes ###

 Possible regressions 

  * 
spec@arb_gpu_shader_fp64@execution@conversion@vert-conversion-explicit-dvec2-uvec2:
- pig-glk-j5005:  NOTRUN -> [CRASH][4] +4 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/pig-glk-j5005/spec@arb_gpu_shader_fp64@execution@convers...@vert-conversion-explicit-dvec2-uvec2.html

  * spec@arb_texture_rg@texwrap formats-float offset:
- pig-skl-6260u:  NOTRUN -> [CRASH][5]
   [5]: None

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-snb:  [PASS][6] -> [TIMEOUT][7] ([i915#5748])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-snb5/igt@gem_b...@close-race.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-snb6/igt@gem_b...@close-race.html

  * igt@gem_ctx_engines@execute-one:
- shard-glk:  [PASS][8] -> [INCOMPLETE][9] ([i915#6310]) +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-glk3/igt@gem_ctx_engi...@execute-one.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-glk2/igt@gem_ctx_engi...@execute-one.html

  * igt@gem_ctx_persistence@smoketest:
- shard-apl:  [PASS][10] -> [INCOMPLETE][11] ([i915#6310])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-apl4/igt@gem_ctx_persiste...@smoketest.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-apl6/igt@gem_ctx_persiste...@smoketest.html
- shard-skl:  NOTRUN -> [INCOMPLETE][12] ([i915#6310])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-skl9/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-iclb5/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][18] -> [FAIL][19] ([i915#2842]) +2 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [19]: 
htt

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
URL   : https://patchwork.freedesktop.org/series/105883/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11842 -> Patchwork_105883v1


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 44)
--

  Additional (1): fi-bxt-dsi 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_pm:
- {bat-adln-1}:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/bat-adln-1/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@engines@fds:
- fi-bsw-kefka:   [PASS][5] -> [INCOMPLETE][6] ([i915#6310])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/fi-bsw-kefka/igt@gem_exec_parallel@engi...@fds.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-bsw-kefka/igt@gem_exec_parallel@engi...@fds.html

  * igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271]) +12 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][10] -> [DMESG-FAIL][11] ([i915#4494] / 
[i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [PASS][14] -> [INCOMPLETE][15] ([i915#5982])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@modeset:
- fi-tgl-u2:  [PASS][16] -> [DMESG-WARN][17] ([i915#402])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/fi-tgl-u2/igt@kms_busy@ba...@modeset.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-tgl-u2/igt@kms_busy@ba...@modeset.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-ivb-3770:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-ivb-3770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-bsw-n3050:   NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v1/fi-bsw-n3050/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pat

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
URL   : https://patchwork.freedesktop.org/series/105883/
State : warning

== Summary ==

Error: dim checkpatch failed
044b58d3ed70 drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
-:135: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#135: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.c:509:
+void intel_gt_mcr_get_ss_steering(struct intel_gt *gt, unsigned int dss,
+  unsigned int *group, unsigned int *instance)

-:166: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt_' - possible 
side-effects?
#166: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:43:
+#define _HAS_SS(ss_, gt_, group_, instance_) ( \
+   GRAPHICS_VER_FULL(gt_->i915) >= IP_VER(12, 50) ? \
+   intel_sseu_has_subslice(&(gt_)->info.sseu, 0, ss_) : \
+   intel_sseu_has_subslice(&(gt_)->info.sseu, group_, instance_))

-:166: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'gt_' may be better as 
'(gt_)' to avoid precedence issues
#166: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:43:
+#define _HAS_SS(ss_, gt_, group_, instance_) ( \
+   GRAPHICS_VER_FULL(gt_->i915) >= IP_VER(12, 50) ? \
+   intel_sseu_has_subslice(&(gt_)->info.sseu, 0, ss_) : \
+   intel_sseu_has_subslice(&(gt_)->info.sseu, group_, instance_))

-:175: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ss_' - possible 
side-effects?
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

-:175: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt_' - possible 
side-effects?
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

-:175: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'group_' - possible 
side-effects?
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

-:175: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'group_' may be better as 
'(group_)' to avoid precedence issues
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

-:175: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'instance_' - possible 
side-effects?
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

-:175: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'instance_' may be better as 
'(instance_)' to avoid precedence issues
#175: FILE: drivers/gpu/drm/i915/gt/intel_gt_mcr.h:52:
+#define for_each_ss_steering(ss_, gt_, group_, instance_) \
+   for (ss_ = 0, intel_gt_mcr_get_ss_steering(gt_, 0, &group_, 
&instance_); \
+ss_ < I915_MAX_SS_FUSE_BITS; \
+ss_++, intel_gt_mcr_get_ss_steering(gt_, ss_, &group_, 
&instance_)) \
+   for_each_if(_HAS_SS(ss_, gt_, group_, instance_))

total: 0 errors, 0 warnings, 9 checks, 237 lines checked

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: switch DP, HDMI and LVDS to drm_edid

[Patchwork]

== Series Details ==

Series: drm/i915: switch DP, HDMI and LVDS to drm_edid
URL   : https://patchwork.freedesktop.org/series/105857/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11840_full -> Patchwork_105857v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@api_intel_allocator@fork-simple-stress:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-tglb2/igt@api_intel_alloca...@fork-simple-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-tglb5/igt@api_intel_alloca...@fork-simple-stress.html

  * igt@gem_exec_reloc@basic-range:
- shard-glk:  [PASS][3] -> [TIMEOUT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-glk7/igt@gem_exec_re...@basic-range.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-glk2/igt@gem_exec_re...@basic-range.html

  * igt@i915_pm_rpm@gem-execbuf-stress@extra-wait-smem0:
- shard-apl:  [PASS][5] -> [INCOMPLETE][6] +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-apl4/igt@i915_pm_rpm@gem-execbuf-str...@extra-wait-smem0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-apl2/igt@i915_pm_rpm@gem-execbuf-str...@extra-wait-smem0.html
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-kbl4/igt@i915_pm_rpm@gem-execbuf-str...@extra-wait-smem0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-kbl7/igt@i915_pm_rpm@gem-execbuf-str...@extra-wait-smem0.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-glk:  [PASS][9] -> [FAIL][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-glk2/igt@i915_pm_...@system-suspend-execbuf.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-glk1/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_3d:
- shard-kbl:  [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-kbl7/igt@kms_3d.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-kbl6/igt@kms_3d.html
- shard-snb:  NOTRUN -> [DMESG-FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-snb6/igt@kms_3d.html
- shard-skl:  [PASS][14] -> [DMESG-FAIL][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-skl10/igt@kms_3d.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-skl4/igt@kms_3d.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
- shard-apl:  [PASS][16] -> [DMESG-WARN][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-apl6/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-apl3/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-fullscreen:
- shard-apl:  NOTRUN -> [TIMEOUT][18] +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-apl1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-fullscreen.html

  * igt@kms_hdmi_inject@inject-4k:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-skl4/igt@kms_hdmi_inj...@inject-4k.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-skl9/igt@kms_hdmi_inj...@inject-4k.html

  * igt@kms_hdmi_inject@inject-audio:
- shard-kbl:  NOTRUN -> [INCOMPLETE][21]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-kbl7/igt@kms_hdmi_inj...@inject-audio.html
- shard-snb:  [PASS][22] -> [INCOMPLETE][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/shard-snb5/igt@kms_hdmi_inj...@inject-audio.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-snb6/igt@kms_hdmi_inj...@inject-audio.html
- shard-skl:  NOTRUN -> [INCOMPLETE][24]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/shard-skl6/igt@kms_hdmi_

Re: [Intel-gfx] [PATCH] drm/i915/display: clean up comments

[Matt Roper]

On Fri, Jul 01, 2022 at 04:32:36PM -0400, Tom Rix wrote:
> spelling changes
> resoluition -> resolution
> dont-> don't
> commmit -> commit
> Invalidade  -> Invalidate
> 
> Signed-off-by: Tom Rix 

Reviewed-by: Matt Roper 

and applied to drm-intel-next.  Thanks for the patch.


Matt

> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7d61c55184e5..e6a870641cd2 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>   /*
>* TODO: 7 lines of IO_BUFFER_WAKE and FAST_WAKE are default
>* values from BSpec. In order to setting an optimal power
> -  * consumption, lower than 4k resoluition mode needs to decrese
> +  * consumption, lower than 4k resolution mode needs to decrease
>* IO_BUFFER_WAKE and FAST_WAKE. And higher than 4K resolution
>* mode needs to increase IO_BUFFER_WAKE and FAST_WAKE.
>*/
> @@ -959,7 +959,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   int psr_setup_time;
>  
>   /*
> -  * Current PSR panels dont work reliably with VRR enabled
> +  * Current PSR panels don't work reliably with VRR enabled
>* So if VRR is enabled, do not enable PSR.
>*/
>   if (crtc_state->vrr.enable)
> @@ -1664,7 +1664,7 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
> struct intel_crtc_state *c
>   *
>   * Plane scaling and rotation is not supported by selective fetch and both
>   * properties can change without a modeset, so need to be check at every
> - * atomic commmit.
> + * atomic commit.
>   */
>  static bool psr2_sel_fetch_plane_state_supported(const struct 
> intel_plane_state *plane_state)
>  {
> @@ -2203,7 +2203,7 @@ static void _psr_invalidate_handle(struct intel_dp 
> *intel_dp)
>  }
>  
>  /**
> - * intel_psr_invalidate - Invalidade PSR
> + * intel_psr_invalidate - Invalidate PSR
>   * @dev_priv: i915 device
>   * @frontbuffer_bits: frontbuffer plane tracking bits
>   * @origin: which operation caused the invalidate
> -- 
> 2.27.0
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH v8 0/3] drm/doc/rfc: i915 VM_BIND feature design + uapi

[Matt Roper]

On Thu, Jun 30, 2022 at 05:31:07PM -0700, Niranjana Vishwanathapura wrote:
> This is the i915 driver VM_BIND feature design RFC patch series along
> with the required uapi definition and description of intended use cases.
> 
> v2: Reduce the scope to simple Mesa use case.
> Remove all compute related uapi, vm_bind/unbind queue support and
> only support a timeline out fence instead of an in/out timeline
> fence array.
> v3: Expand documentation on dma-resv usage, TLB flushing, execbuf3 and
> VM_UNBIND. Add FENCE_VALID and TLB_FLUSH flags.
> v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
> uapi documentation for vm_bind/unbind.
> v5: Update TLB flushing documentation.
> Add version support to stage implementation.
> v6: Define and use drm_i915_gem_timeline_fence structure for
> execbuf3 and vm_bind/unbind timeline fences.
> v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
> Update documentation on async vm_bind/unbind and versioning.
> Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
> batch_count field and I915_EXEC3_SECURE flag.
> v8: Remove I915_GEM_VM_BIND_READONLY and minor documentation
> updates.
> 
> Signed-off-by: Niranjana Vishwanathapura 
> Reviewed-by: Daniel Vetter 
> Acked-by: Paulo Zanoni 

Series applied to drm-intel-gt-next.  Thanks for the patches and
reviews.


Matt

> 
> Niranjana Vishwanathapura (3):
>   drm/doc/rfc: VM_BIND feature design document
>   drm/i915: Update i915 uapi documentation
>   drm/doc/rfc: VM_BIND uapi definition
> 
>  Documentation/gpu/rfc/i915_vm_bind.h   | 291 +
>  Documentation/gpu/rfc/i915_vm_bind.rst | 245 +
>  Documentation/gpu/rfc/index.rst|   4 +
>  include/uapi/drm/i915_drm.h| 205 +
>  4 files changed, 700 insertions(+), 45 deletions(-)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
> 
> -- 
> 2.21.0.rc0.32.g243a4c7e27
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/vm_bind: Add VM_BIND functionality

[Patchwork]

== Series Details ==

Series: drm/i915/vm_bind: Add VM_BIND functionality
URL   : https://patchwork.freedesktop.org/series/105879/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11841 -> Patchwork_105879v1


Summary
---

  **FAILURE**

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

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

Participating hosts (41 -> 40)
--

  Additional (2): fi-hsw-4770 bat-jsl-1 
  Missing(3): bat-dg2-8 fi-icl-u2 fi-tgl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-ilk-650: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-ilk-650/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-ilk-650/igt@i915_module_l...@load.html
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-blb-e6850/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-blb-e6850/igt@i915_module_l...@load.html
- fi-pnv-d510:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-pnv-d510/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-pnv-d510/igt@i915_module_l...@load.html
- fi-snb-2520m:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-snb-2520m/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-snb-2520m/igt@i915_module_l...@load.html
- fi-elk-e7500:   [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-elk-e7500/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-elk-e7500/igt@i915_module_l...@load.html
- fi-hsw-g3258:   [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-hsw-g3258/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-hsw-g3258/igt@i915_module_l...@load.html
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-hsw-4770/igt@i915_module_l...@load.html
- fi-ivb-3770:[PASS][14] -> [INCOMPLETE][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-ivb-3770/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-ivb-3770/igt@i915_module_l...@load.html
- fi-snb-2600:[PASS][16] -> [INCOMPLETE][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-snb-2600/igt@i915_module_l...@load.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-snb-2600/igt@i915_module_l...@load.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u:   [PASS][18] -> [INCOMPLETE][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html

  * igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-kbl-soraka:  [PASS][20] -> [INCOMPLETE][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-bad-modifier.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-bad-modifier.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-8809g:   [PASS][23] -> [DMESG-FAIL][24] ([i915#5334])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-kbl-8809g/igt@i915_selftest@live@gt_heartbeat.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105879v1/fi-kbl-8809g/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][25

Re: [Intel-gfx] [PATCH 2/2] drm/i915: DG2 and ATS-M device ID updates

[Matt Roper]

On Fri, Jul 01, 2022 at 09:59:50AM -0700, Lucas De Marchi wrote:
> On Fri, Jul 01, 2022 at 08:22:31AM -0700, Matt Roper wrote:
> > Small BAR support has now landed, which allows us to add the PCI IDs
> > that correspond to add-in card designs of DG2 and ATS-M.  There's also
> > one additional MB-down PCI ID that recently appeared (0x5698) so we add
> > it too.
> > 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Matt Roper 
> 
> 
> Reviewed-by: Lucas De Marchi 

Thanks.  Applied to drm-intel-gt-next (since that's the branch that has
the small BAR patches that were a pre-req to adding these IDs) and
dropped the equivalent patch from topic/core-from-CI.


Matt

> 
> Lucas De Marchi

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

[Intel-gfx] [PATCH] drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr

[Matt Roper]

Although all DSS belong to a single pool on Xe_HP platforms (i.e.,
they're not organized into slices from a topology point of view), we do
still need to pass 'group' and 'instance' targets when steering register
accesses to a specific instance of a per-DSS multicast register.  The
rules for how to determine group and instance IDs (which previously used
legacy terms "slice" and "subslice") varies by platform.  Some platforms
determine steering by gslice membership, some platforms by cslice
membership, and future platforms may have other rules.

Since looping over each DSS and performing steered unicast register
accesses is a relatively common pattern, let's add a dedicated iteration
macro to handle this (and replace the platform-specific "instdone" loop
we were using previously.  This will avoid the calling code needing to
figure out the details about how to obtain steering IDs for a specific
DSS.

Most of the places where we use this new loop are in the GPU errorstate
code at the moment, but we do have some additional features coming in
the future that will also need to loop over each DSS and steer some
register accesses accordingly.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 34 ++-
 drivers/gpu/drm/i915/gt/intel_engine_types.h  | 22 
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 25 ++
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 24 +
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 13 ---
 drivers/gpu/drm/i915/i915_gpu_error.c | 32 ++---
 6 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 283870c65991..37fa813af766 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1517,7 +1517,6 @@ void intel_engine_get_instdone(const struct 
intel_engine_cs *engine,
   struct intel_instdone *instdone)
 {
struct drm_i915_private *i915 = engine->i915;
-   const struct sseu_dev_info *sseu = &engine->gt->info.sseu;
struct intel_uncore *uncore = engine->uncore;
u32 mmio_base = engine->mmio_base;
int slice;
@@ -1542,32 +1541,19 @@ void intel_engine_get_instdone(const struct 
intel_engine_cs *engine,
intel_uncore_read(uncore, 
GEN12_SC_INSTDONE_EXTRA2);
}
 
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
-   for_each_instdone_gslice_dss_xehp(i915, sseu, iter, 
slice, subslice) {
-   instdone->sampler[slice][subslice] =
-   intel_gt_mcr_read(engine->gt,
- GEN7_SAMPLER_INSTDONE,
- slice, subslice);
-   instdone->row[slice][subslice] =
-   intel_gt_mcr_read(engine->gt,
- GEN7_ROW_INSTDONE,
- slice, subslice);
-   }
-   } else {
-   for_each_instdone_slice_subslice(i915, sseu, slice, 
subslice) {
-   instdone->sampler[slice][subslice] =
-   intel_gt_mcr_read(engine->gt,
- GEN7_SAMPLER_INSTDONE,
- slice, subslice);
-   instdone->row[slice][subslice] =
-   intel_gt_mcr_read(engine->gt,
- GEN7_ROW_INSTDONE,
- slice, subslice);
-   }
+   for_each_ss_steering(iter, engine->gt, slice, subslice) {
+   instdone->sampler[slice][subslice] =
+   intel_gt_mcr_read(engine->gt,
+ GEN7_SAMPLER_INSTDONE,
+ slice, subslice);
+   instdone->row[slice][subslice] =
+   intel_gt_mcr_read(engine->gt,
+ GEN7_ROW_INSTDONE,
+ slice, subslice);
}
 
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
-   for_each_instdone_gslice_dss_xehp(i915, sseu, iter, 
slice, subslice)
+   for_each_ss_steering(iter, engine->gt, slice, subslice)
instdone->geom_svg[slice][subslice] =
intel_gt_mcr_read(engine->gt,
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/vm_bind: Add VM_BIND functionality

[Patchwork]

== Series Details ==

Series: drm/i915/vm_bind: Add VM_BIND functionality
URL   : https://patchwork.freedesktop.org/series/105879/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality

[Patchwork]

== Series Details ==

Series: drm/i915/vm_bind: Add VM_BIND functionality
URL   : https://patchwork.freedesktop.org/series/105879/
State : warning

== Summary ==

Error: dim checkpatch failed
9a618f815c5e drm/i915/vm_bind: Introduce VM_BIND ioctl
-:196: WARNING:LONG_LINE: line length of 118 exceeds 100 columns
#196: FILE: include/uapi/drm/i915_drm.h:539:
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)

-:197: WARNING:LONG_LINE: line length of 122 exceeds 100 columns
#197: FILE: include/uapi/drm/i915_drm.h:540:
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_unbind)

total: 0 errors, 2 warnings, 0 checks, 368 lines checked
b021c9cf1fd7 drm/i915/vm_bind: Bind and unbind mappings
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:73: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#73: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 443 lines checked
6375255bdb22 drm/i915/vm_bind: Support private and shared BOs
bc88aa1c4e77 drm/i915/vm_bind: Add out fence support
150c21055b0e drm/i915/vm_bind: Handle persistent vmas
bd2c34d240da drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:44: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#44: 
new file mode 100644

-:232: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects?
#232: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c:184:
+#define for_each_batch_create_order(_eb, _i) \
+   for ((_i) = 0; (_i) < (_eb)->num_batches; ++(_i))

-:234: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements 
should be enclosed in a do - while loop
#234: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c:186:
+#define for_each_batch_add_order(_eb, _i) \
+   BUILD_BUG_ON(!typecheck(int, _i)); \
+   for ((_i) = (_eb)->num_batches - 1; (_i) >= 0; --(_i))

-:234: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_i' - possible side-effects?
#234: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c:186:
+#define for_each_batch_add_order(_eb, _i) \
+   BUILD_BUG_ON(!typecheck(int, _i)); \
+   for ((_i) = (_eb)->num_batches - 1; (_i) >= 0; --(_i))

-:1119: WARNING:LONG_LINE: line length of 126 exceeds 100 columns
#1119: FILE: include/uapi/drm/i915_drm.h:542:
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)

total: 1 errors, 2 warnings, 2 checks, 1153 lines checked
05108f6c5754 drm/i915/vm_bind: Handle persistent vmas in execbuf3
481d633a73ce drm/i915/vm_bind: userptr dma-resv changes
aaafeac528d6 drm/i915/vm_bind: Skip vma_lookup for persistent vmas
27b31d00e6b0 drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting

[Intel-gfx] [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3

[Niranjana Vishwanathapura]

Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.

Signed-off-by: Niranjana Vishwanathapura 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 176 +-
 1 file changed, 175 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 13121df72e3d..2079f5ca9010 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -22,6 +22,7 @@
 #include "i915_gem_vm_bind.h"
 #include "i915_trace.h"
 
+#define __EXEC3_HAS_PINBIT_ULL(33)
 #define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
 #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
 
@@ -45,7 +46,9 @@
  * execlist. Hence, no support for implicit sync.
  *
  * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
  *
  * The execbuf3 ioctl directly specifies the batch addresses instead of as
  * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -61,6 +64,13 @@
  * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
  * vma lookup table, implicit sync, vma active reference tracking etc., are not
  * applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
  */
 
 struct eb_fence {
@@ -124,6 +134,19 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
 }
 
+static void eb_scoop_unbound_vmas(struct i915_address_space *vm)
+{
+   struct i915_vma *vma, *vn;
+
+   spin_lock(&vm->vm_rebind_lock);
+   list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list, vm_rebind_link) {
+   list_del_init(&vma->vm_rebind_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->vm_rebind_lock);
+}
+
 static int eb_lookup_vmas(struct i915_execbuffer *eb)
 {
unsigned int i, current_batch = 0;
@@ -138,11 +161,118 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
++current_batch;
}
 
+   eb_scoop_unbound_vmas(eb->context->vm);
+
+   return 0;
+}
+
+static int eb_lock_vmas(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int err;
+
+   err = i915_gem_vm_priv_lock(eb->context->vm, &eb->ww);
+   if (err)
+   return err;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   err = i915_gem_object_lock(vma->obj, &eb->ww);
+   if (err)
+   return err;
+   }
+
return 0;
 }
 
+static void eb_release_persistent_vmas(struct i915_execbuffer *eb, bool final)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma, *vn;
+
+   assert_vm_bind_held(vm);
+
+   if (!(eb->args->flags & __EXEC3_HAS_PIN))
+   return;
+
+   assert_vm_priv_held(vm);
+
+   list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link)
+   __i915_vma_unpin(vma);
+
+   eb->args->flags &= ~__EXEC3_HAS_PIN;
+   if (!final)
+   return;
+
+   list_for_each_entry_safe(vma, vn, &vm->vm_bind_list, vm_bind_link)
+   if (i915_vma_is_bind_complete(vma))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bound_list);
+}
+
 static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
 {
+   eb_release_persistent_vmas(eb, final);
+   eb_unpin_engine(eb);
+}
+
+static int eb_reserve_fence_for_persistent_vmas(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int ret;
+
+   ret = dma_resv_reserve_fences(vm->root_obj->base.resv, 1);
+   if (ret)
+   return ret;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   ret = dma_resv_reserve_fences(vma->obj->base.resv, 1);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int eb_validate_persistent_vmas(struct i915_execbuffer *eb)
+{
+   struct i915_addre

[Intel-gfx] [RFC 05/10] drm/i915/vm_bind: Handle persistent vmas

[Niranjana Vishwanathapura]

Treat VM_BIND vmas as persistent and handle them during the
request submission in the execbuff path.

Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  1 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  3 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 12 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 +
 drivers/gpu/drm/i915/i915_gem_gtt.h   | 22 ++
 drivers/gpu/drm/i915/i915_vma.c   | 32 +++-
 drivers/gpu/drm/i915/i915_vma.h   | 78 +--
 drivers/gpu/drm/i915/i915_vma_types.h | 23 ++
 9 files changed, 163 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index ccec4055fde3..5121f02ba95c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -38,6 +38,7 @@
 #include "i915_gem_mman.h"
 #include "i915_gem_object.h"
 #include "i915_gem_ttm.h"
+#include "i915_gem_vm_bind.h"
 #include "i915_memcpy.h"
 #include "i915_trace.h"
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 849bf3c1061e..eaadf5a6ab09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -6,6 +6,7 @@
 #ifndef __I915_GEM_VM_BIND_H
 #define __I915_GEM_VM_BIND_H
 
+#include 
 #include "i915_drv.h"
 
 #define assert_vm_bind_held(vm)   lockdep_assert_held(&(vm)->vm_bind_lock)
@@ -26,6 +27,8 @@ static inline void i915_gem_vm_bind_unlock(struct 
i915_address_space *vm)
mutex_unlock(&vm->vm_bind_lock);
 }
 
+#define assert_vm_priv_held(vm)   assert_object_held((vm)->root_obj)
+
 static inline int i915_gem_vm_priv_lock(struct i915_address_space *vm,
struct i915_gem_ww_ctx *ww)
 {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 96f139cc8060..1a8efa83547f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -85,6 +85,13 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool 
release_obj)
 {
assert_vm_bind_held(vma->vm);
 
+   spin_lock(&vma->vm->vm_rebind_lock);
+   if (!list_empty(&vma->vm_rebind_link))
+   list_del_init(&vma->vm_rebind_link);
+   i915_vma_set_purged(vma);
+   i915_vma_set_freed(vma);
+   spin_unlock(&vma->vm->vm_rebind_lock);
+
if (!list_empty(&vma->vm_bind_link)) {
list_del_init(&vma->vm_bind_link);
list_del_init(&vma->non_priv_vm_bind_link);
@@ -220,6 +227,7 @@ static struct i915_vma *vm_bind_get_vma(struct 
i915_address_space *vm,
 
vma->start = va->start;
vma->last = va->start + va->length - 1;
+   i915_vma_set_persistent(vma);
 
return vma;
 }
@@ -304,8 +312,10 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
 
i915_vm_bind_put_fence(vma);
 put_vma:
-   if (ret)
+   if (ret) {
+   i915_vma_set_freed(vma);
i915_vma_destroy(vma);
+   }
 
i915_gem_ww_ctx_fini(&ww);
 unlock_vm:
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index df0a8459c3c6..55d5389b2c6c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -293,6 +293,8 @@ void i915_address_space_init(struct i915_address_space *vm, 
int subclass)
INIT_LIST_HEAD(&vm->non_priv_vm_bind_list);
vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
GEM_BUG_ON(IS_ERR(vm->root_obj));
+   INIT_LIST_HEAD(&vm->vm_rebind_list);
+   spin_lock_init(&vm->vm_rebind_lock);
 }
 
 void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index f538ce9115c9..fe5485c4a1cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -265,6 +265,8 @@ struct i915_address_space {
struct mutex vm_bind_lock;  /* Protects vm_bind lists */
struct list_head vm_bind_list;
struct list_head vm_bound_list;
+   struct list_head vm_rebind_list;
+   spinlock_t vm_rebind_lock;   /* Protects vm_rebind_list */
/* va tree of persistent vmas */
struct rb_root_cached va;
struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8c2f57eb5dda..09b89d1913fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -51,4 +51,26 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 
 #define PIN_OFFSET_MASKI915_GTT

[Intel-gfx] [RFC 04/10] drm/i915/vm_bind: Add out fence support

[Niranjana Vishwanathapura]

Add support for handling out fence of vm_bind call.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  2 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 74 +++
 drivers/gpu/drm/i915/i915_vma.c   |  6 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  7 ++
 4 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index ee6e4c52e80e..849bf3c1061e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -45,5 +45,7 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
 struct drm_file *file);
 int i915_gem_vm_unbind_obj(struct i915_address_space *vm,
   struct drm_i915_gem_vm_unbind *va);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence);
 
 #endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3201204c8e74..96f139cc8060 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -5,6 +5,8 @@
 
 #include 
 
+#include 
+
 #include "gem/i915_gem_vm_bind.h"
 #include "gt/gen8_engine_cs.h"
 
@@ -94,6 +96,68 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma, bool 
release_obj)
}
 }
 
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+   struct drm_syncobj *syncobj;
+
+   syncobj = drm_syncobj_find(file, handle);
+   if (!syncobj) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   return -ENOENT;
+   }
+
+   /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+   if (point) {
+   vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+   if (!vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_put(syncobj);
+   return -ENOMEM;
+   }
+   } else {
+   vma->vm_bind_fence.chain_fence = NULL;
+   }
+
+   vma->vm_bind_fence.syncobj = syncobj;
+   vma->vm_bind_fence.value = point;
+
+   return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+   if (!vma->vm_bind_fence.syncobj)
+   return;
+
+   drm_syncobj_put(vma->vm_bind_fence.syncobj);
+   dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+}
+
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence)
+{
+   struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+   if (!syncobj)
+   return;
+
+   if (vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+   /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+   vma->vm_bind_fence.chain_fence = NULL;
+   } else {
+   drm_syncobj_replace_fence(syncobj, fence);
+   }
+}
+
 int i915_gem_vm_unbind_obj(struct i915_address_space *vm,
   struct drm_i915_gem_vm_unbind *va)
 {
@@ -202,6 +266,14 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
}
 
i915_gem_ww_ctx_init(&ww, true);
+
+   if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+   ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+va->fence.value);
+   if (ret)
+   goto put_vma;
+   }
+
pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER;
 retry:
ret = i915_gem_object_lock(vma->obj, &ww);
@@ -230,6 +302,8 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
goto retry;
}
 
+   i915_vm_bind_put_fence(vma);
+put_vma:
if (ret)
i915_vma_destroy(vma);
 
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index f0226581d342..6737236b7884 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1510,8 +1510,12 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
 err_vma_res:
i915_vma_resource_free(vma_res);
 err_fence:
-   if (work)
+   if (work) {
+   if (i915_vma_is_persistent(vma))
+   i915_vm_bind_signal_fence(vma, &work->base.dma);
+
dma_fence_work_commit_imm(&work->base);
+   }
 err_rpm:
if (wakeref)
intel_runtime_pm_put(&vma->vm->i915->runti

[Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes

[Niranjana Vishwanathapura]

For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions

Signed-off-by: Niranjana Vishwanathapura 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 67 +++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 16 +
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  1 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  1 +
 4 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 2079f5ca9010..bf13dd6d642e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -22,6 +22,7 @@
 #include "i915_gem_vm_bind.h"
 #include "i915_trace.h"
 
+#define __EXEC3_USERPTR_USED   BIT_ULL(34)
 #define __EXEC3_HAS_PINBIT_ULL(33)
 #define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
 #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -147,10 +148,36 @@ static void eb_scoop_unbound_vmas(struct 
i915_address_space *vm)
spin_unlock(&vm->vm_rebind_lock);
 }
 
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *last_vma = NULL;
+   struct i915_vma *vma;
+   int err;
+
+   assert_vm_bind_held(vm);
+
+   list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
+   if (i915_gem_object_is_userptr(vma->obj)) {
+   err = i915_gem_object_userptr_submit_init(vma->obj);
+   if (err)
+   return err;
+
+   last_vma = vma;
+   }
+   }
+
+   if (last_vma)
+   eb->args->flags |= __EXEC3_USERPTR_USED;
+
+   return 0;
+}
+
 static int eb_lookup_vmas(struct i915_execbuffer *eb)
 {
unsigned int i, current_batch = 0;
struct i915_vma *vma;
+   int err = 0;
 
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb->batch_addresses[i]);
@@ -163,6 +190,10 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 
eb_scoop_unbound_vmas(eb->context->vm);
 
+   err = eb_lookup_persistent_userptr_vmas(eb);
+   if (err)
+   return err;
+
return 0;
 }
 
@@ -358,15 +389,51 @@ static void eb_persistent_vmas_move_to_active(struct 
i915_execbuffer *eb)
 
 static int eb_move_to_gpu(struct i915_execbuffer *eb)
 {
+   int err = 0, j;
+
assert_vm_bind_held(eb->context->vm);
assert_vm_priv_held(eb->context->vm);
 
eb_persistent_vmas_move_to_active(eb);
 
+#ifdef CONFIG_MMU_NOTIFIER
+   if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+   struct i915_vma *vma;
+
+   assert_vm_bind_held(eb->context->vm);
+   assert_vm_priv_held(eb->context->vm);
+
+   read_lock(&eb->i915->mm.notifier_lock);
+   list_for_each_entry(vma, &eb->context->vm->vm_bind_list,
+   vm_bind_link) {
+   if (!i915_gem_object_is_userptr(vma->obj))
+   continue;
+
+   err = i915_gem_object_userptr_submit_done(vma->obj);
+   if (err)
+   break;
+   }
+
+   read_unlock(&eb->i915->mm.notifier_lock);
+   }
+#endif
+
+   if (unlikely(err))
+   goto err_skip;
+
/* Unconditionally flush any chipset caches (for streaming writes). */
intel_gt_chipset_flush(eb->gt);
 
return 0;
+
+err_skip:
+   for_each_batch_create_order(eb, j) {
+   if (!eb->requests[j])
+   break;
+
+   i915_request_set_error_once(eb->requests[j], err);
+   }
+   return err;
 }
 
 static int eb_request_submit(struct i915_execbuffer *eb,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 1a8efa83547f..cae282b91618 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -263,6 +263,12 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
goto put_obj;
}
 
+   if (i915_gem_object_is_userptr(obj)) {
+   ret = i915_gem_object_userptr_submit_init(obj);
+   if (ret)
+   goto put_obj;
+   }
+
ret = i915_gem_vm_bind_lock_interruptible(vm);
if (ret)
goto put_obj;
@@ -295,6 +301,16 @@ int i915_gem_vm_bind_obj(struct i915_address_space *vm,
/* Make it evictable */
__i915_vma_unpin(vma);
 
+#ifdef CONFIG_MMU_NOTIFIER
+   if (i915_gem_object_is_userptr(obj)) {
+   write_lock(&vm->i915->mm.notifier_lock);
+   ret = i915_gem_object_userptr_submi

[Intel-gfx] [RFC 02/10] drm/i915/vm_bind: Bind and unbind mappings

[Niranjana Vishwanathapura]

Bind and unbind the mappings upon VM_BIND and VM_UNBIND calls.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   2 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  38 +++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 233 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   7 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   9 +
 drivers/gpu/drm/i915/i915_driver.c|  11 +-
 drivers/gpu/drm/i915/i915_vma.c   |   7 +-
 drivers/gpu/drm/i915/i915_vma.h   |   2 -
 drivers/gpu/drm/i915/i915_vma_types.h |   8 +
 11 files changed, 318 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..4e1627e96c6e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -165,6 +165,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+   gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..927a87e5ec59 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -15,10 +15,10 @@
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 
-static u32 object_max_page_size(struct intel_memory_region **placements,
-   unsigned int n_placements)
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
 {
-   u32 max_page_size = 0;
+   u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
 
for (i = 0; i < n_placements; i++) {
@@ -28,7 +28,6 @@ static u32 object_max_page_size(struct intel_memory_region 
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
 
-   GEM_BUG_ON(!max_page_size);
return max_page_size;
 }
 
@@ -99,7 +98,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private 
*i915, u64 size,
 
i915_gem_flush_free_objects(i915);
 
-   size = round_up(size, object_max_page_size(placements, n_placements));
+   size = round_up(size, i915_gem_object_max_page_size(placements,
+   n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 6f0a3ce35567..650de2224843 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
 }
 
 void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
 
 void i915_objects_module_exit(void);
 int i915_objects_module_init(void);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..642cdb559f17
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include "i915_drv.h"
+
+#define assert_vm_bind_held(vm)   lockdep_assert_held(&(vm)->vm_bind_lock)
+
+static inline void i915_gem_vm_bind_lock(struct i915_address_space *vm)
+{
+   mutex_lock(&vm->vm_bind_lock);
+}
+
+static inline int
+i915_gem_vm_bind_lock_interruptible(struct i915_address_space *vm)
+{
+   return mutex_lock_interruptible(&vm->vm_bind_lock);
+}
+
+static inline void i915_gem_vm_bind_unlock(struct i915_address_space *vm)
+{
+   mutex_unlock(&vm->vm_bind_lock);
+}
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj);
+int i915_gem_vm_bind_obj(struct i915_address_space *vm,
+struct drm_i915_gem_vm_bind *va,
+struct drm_file *file);
+int i915_gem_vm_unbind_obj(struct i915_address_space *vm,
+  struct drm_i915_gem_vm_unbind *va);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..43ceb4dcca6c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i9

[Intel-gfx] [RFC 10/10] drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting

[Niranjana Vishwanathapura]

VM_BIND functionality maintain that vm->vm_bind_mutex will never be taken
while holding vm->mutex.
However, while closing 'vm', vma is destroyed while holding vm->mutex.
But vma releasing needs to take vm->vm_bind_mutex in order to delete vma
from the vm_bind_list. To avoid this, destroy the vma outside vm->mutex
while closing the 'vm'.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gt/intel_gtt.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 4ab3bda644ff..4f707d0eb3ef 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -109,7 +109,8 @@ int map_pt_dma_locked(struct i915_address_space *vm, struct 
drm_i915_gem_object
return 0;
 }
 
-static void clear_vm_list(struct list_head *list)
+static void clear_vm_list(struct list_head *list,
+ struct list_head *destroy_list)
 {
struct i915_vma *vma, *vn;
 
@@ -138,8 +139,7 @@ static void clear_vm_list(struct list_head *list)
i915_vm_resv_get(vma->vm);
vma->vm_ddestroy = true;
} else {
-   i915_vma_destroy_locked(vma);
-   i915_gem_object_put(obj);
+   list_move_tail(&vma->vm_link, destroy_list);
}
 
}
@@ -147,16 +147,29 @@ static void clear_vm_list(struct list_head *list)
 
 static void __i915_vm_close(struct i915_address_space *vm)
 {
+   struct i915_vma *vma, *vn;
+   struct list_head list;
+
+   INIT_LIST_HEAD(&list);
+
mutex_lock(&vm->mutex);
 
-   clear_vm_list(&vm->bound_list);
-   clear_vm_list(&vm->unbound_list);
+   clear_vm_list(&vm->bound_list, &list);
+   clear_vm_list(&vm->unbound_list, &list);
 
/* Check for must-fix unanticipated side-effects */
GEM_BUG_ON(!list_empty(&vm->bound_list));
GEM_BUG_ON(!list_empty(&vm->unbound_list));
 
mutex_unlock(&vm->mutex);
+
+   /* Destroy vmas outside vm->mutex */
+   list_for_each_entry_safe(vma, vn, &list, vm_link) {
+   struct drm_i915_gem_object *obj = vma->obj;
+
+   i915_vma_destroy(vma);
+   i915_gem_object_put(obj);
+   }
 }
 
 /* lock the vm into the current ww, if we lock one, we lock all */
-- 
2.21.0.rc0.32.g243a4c7e27

[Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs

[Niranjana Vishwanathapura]

Add uapi allowing user to specify a BO as private to a specified VM
during the BO creation.
VM private BOs can only be mapped on the specified VM and can't be
dma_buf exported. VM private BOs share a single common dma_resv object,
hence has a performance advantage requiring a single dma_resv object
update in the execbuf path compared to non-private (shared) BOs.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 41 ++-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  6 +++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   | 11 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  9 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 +
 drivers/gpu/drm/i915/i915_vma.c   |  1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  2 +
 include/uapi/drm/i915_drm.h   | 30 ++
 11 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 927a87e5ec59..7e264566b51f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
 #include "pxp/intel_pxp.h"
 
 #include "i915_drv.h"
+#include "i915_gem_context.h"
 #include "i915_gem_create.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -243,6 +244,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   u32 vm_id;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -392,9 +394,24 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct drm_i915_gem_create_ext_vm_private ext;
+   struct create_ext *ext_data = data;
+
+   if (copy_from_user(&ext, base, sizeof(ext)))
+   return -EFAULT;
+
+   ext_data->vm_id = ext.vm_id;
+
+   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,
+   [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
 };
 
 /**
@@ -410,6 +427,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+   struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
 
@@ -423,6 +441,12 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (ret)
return ret;
 
+   if (ext_data.vm_id) {
+   vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+   if (unlikely(!vm))
+   return -ENOENT;
+   }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -449,8 +473,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto vm_put;
+   }
+
+   if (vm) {
+   obj->base.resv = vm->root_obj->base.resv;
+   obj->priv_root = i915_gem_object_get(vm->root_obj);
+   i915_vm_put(vm);
+   }
 
return i915_gem_publish(obj, file, &args->size, &args->handle);
+vm_put:
+   if (vm)
+   i915_vm_put(vm);
+
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..6433173c3e84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -218,6 +218,12 @@ struct dma_buf *i915_gem_prime_export(struct 
drm_gem_object *gem_obj, int flags)
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
+   if (obj->priv_root) {
+   drm_dbg(obj->base.dev,
+   "Exporting VM private objects is not allowed\n");
+   return ERR_PTR(-EINVAL);
+   }
+
exp_info.ops = &i915_dmabuf_ops;
exp_info.size = gem_obj->size;
exp_info.flags = flags;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915

[Intel-gfx] [RFC 09/10] drm/i915/vm_bind: Skip vma_lookup for persistent vmas

[Niranjana Vishwanathapura]

vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6adb013579be..9aa38b772b5b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -197,6 +197,10 @@ vma_create(struct drm_i915_gem_object *obj,
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}
 
+   if (!i915_vma_is_ggtt(vma) &&
+   (view && view->type == I915_GGTT_VIEW_PARTIAL))
+   goto skip_rb_insert;
+
rb = NULL;
p = &obj->vma.tree.rb_node;
while (*p) {
@@ -221,6 +225,7 @@ vma_create(struct drm_i915_gem_object *obj,
rb_link_node(&vma->obj_node, rb, p);
rb_insert_color(&vma->obj_node, &obj->vma.tree);
 
+skip_rb_insert:
if (i915_vma_is_ggtt(vma))
/*
 * We put the GGTT vma at the start of the vma-list, followed
@@ -292,13 +297,16 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_ggtt_view *view)
 {
-   struct i915_vma *vma;
+   struct i915_vma *vma = NULL;
 
GEM_BUG_ON(!kref_read(&vm->ref));
 
-   spin_lock(&obj->vma.lock);
-   vma = i915_vma_lookup(obj, vm, view);
-   spin_unlock(&obj->vma.lock);
+   if (i915_is_ggtt(vm) || !view ||
+   view->type != I915_GGTT_VIEW_PARTIAL) {
+   spin_lock(&obj->vma.lock);
+   vma = i915_vma_lookup(obj, vm, view);
+   spin_unlock(&obj->vma.lock);
+   }
 
/* vma_create() will resolve the race if another creates the vma */
if (unlikely(!vma))
@@ -1670,7 +1678,8 @@ static void release_references(struct i915_vma *vma, bool 
vm_ddestroy)
 
spin_lock(&obj->vma.lock);
list_del(&vma->obj_link);
-   if (!RB_EMPTY_NODE(&vma->obj_node))
+   if (!i915_vma_is_persistent(vma) &&
+   !RB_EMPTY_NODE(&vma->obj_node))
rb_erase(&vma->obj_node, &obj->vma.tree);
 
spin_unlock(&obj->vma.lock);
-- 
2.21.0.rc0.32.g243a4c7e27

[Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl

[Niranjana Vishwanathapura]

Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any execlist support
and all the legacy support like relocations etc are removed.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/Makefile |1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|5 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 1029 +
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
 drivers/gpu/drm/i915/i915_driver.c|1 +
 include/uapi/drm/i915_drm.h   |   67 +-
 6 files changed, 1104 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4e1627e96c6e..38cd1c5bc1a5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b7b2c14fd9e1..37bb1383ab8f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -782,6 +782,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
 
+   if (ctx->vm->vm_bind_mode) {
+   i915_gem_context_put(ctx);
+   return -EOPNOTSUPP;
+   }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..13121df72e3d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,1029 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_file_private.h"
+#include "i915_gem_context.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+struct eb_fence {
+   struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+   struct dma_fence *dma_fence;
+   u64 value;
+   struct dma_fence_chain *chain_fence;
+};
+
+struct i915_execbuffer {
+   struct drm_i915_private *i915; /** i915 backpointer */
+   struct drm_file *file; /** per-file lookup tables and limits */
+   struct drm_i915_gem_execbuffer3 *args; /** ioctl parameters */
+
+   struct intel_gt *gt; /* gt for the execbuf */
+   struct intel_context *context; /* logical state for the request */
+ 

[Intel-gfx] [RFC 01/10] drm/i915/vm_bind: Introduce VM_BIND ioctl

[Niranjana Vishwanathapura]

Add VM_BIND and VM_UNBIND ioctls to bind/unbind a section of an
object at the specified GPU virtual addresses.

Add I915_PARAM_VM_BIND_VERSION to indicate version of VM_BIND feature
supported and I915_VM_CREATE_FLAGS_USE_VM_BIND for UMDs to select the
vm_bind mode of binding.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  20 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.h |  15 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h |   6 +
 drivers/gpu/drm/i915/i915_driver.c  |  30 +++
 drivers/gpu/drm/i915/i915_getparam.c|   3 +
 include/uapi/drm/i915_drm.h | 192 +++-
 6 files changed, 248 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dabdfe09f5e5..e3f5fbf2ac05 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -81,7 +81,6 @@
 
 #include "pxp/intel_pxp.h"
 
-#include "i915_file_private.h"
 #include "i915_gem_context.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -346,20 +345,6 @@ static int proto_context_register(struct 
drm_i915_file_private *fpriv,
return ret;
 }
 
-static struct i915_address_space *
-i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
-{
-   struct i915_address_space *vm;
-
-   xa_lock(&file_priv->vm_xa);
-   vm = xa_load(&file_priv->vm_xa, id);
-   if (vm)
-   kref_get(&vm->ref);
-   xa_unlock(&file_priv->vm_xa);
-
-   return vm;
-}
-
 static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
struct i915_gem_proto_context *pc,
const struct drm_i915_gem_context_param *args)
@@ -1799,7 +1784,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
 
-   if (args->flags)
+   if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
 
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
@@ -1819,6 +1804,9 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (err)
goto err_put;
 
+   if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND)
+   ppgtt->vm.vm_bind_mode = true;
+
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1fe..723bf446c934 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -12,6 +12,7 @@
 #include "gt/intel_context.h"
 
 #include "i915_drv.h"
+#include "i915_file_private.h"
 #include "i915_gem.h"
 #include "i915_scheduler.h"
 #include "intel_device_info.h"
@@ -139,6 +140,20 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
 int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file);
 
+static inline struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+   struct i915_address_space *vm;
+
+   xa_lock(&file_priv->vm_xa);
+   vm = xa_load(&file_priv->vm_xa, id);
+   if (vm)
+   kref_get(&vm->ref);
+   xa_unlock(&file_priv->vm_xa);
+
+   return vm;
+}
+
 struct i915_gem_context *
 i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e639434e97fd..c812aa9708ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -271,6 +271,12 @@ struct i915_address_space {
/* Skip pte rewrite on unbind for suspend. Protected by @mutex */
bool skip_pte_rewrite:1;
 
+   /**
+* true: allow only vm_bind method of binding.
+* false: allow only legacy execbuff method of binding.
+*/
+   bool vm_bind_mode:1;
+
u8 top;
u8 pd_shift;
u8 scratch_order;
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..ccf990dfd99b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1778,6 +1778,34 @@ i915_gem_reject_pin_ioctl(struct drm_device *dev, void 
*data,
return -ENODEV;
 }
 
+static int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+   struct drm_i915_gem_vm_bind *args = data;
+   struct i915_address_space *vm;
+
+   vm = i915_gem_vm_lookup(file->driver_priv, args->vm_id);
+   if (unlikely(!vm))
+   return -ENOENT;
+
+   i915_vm_put(vm);
+   return -EINVAL;
+}
+
+static int i915_gem_vm_unbind_ioctl(struct drm_dev

[Intel-gfx] [RFC 00/10] drm/i915/vm_bind: Add VM_BIND functionality

[Niranjana Vishwanathapura]

DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs at specified GPU virtual
addresses on a specified address space (VM). Multiple mappings can map
to the same physical pages of an object (aliasing). These mappings (also
referred to as persistent mappings) will be persistent across multiple
GPU submissions (execbuf calls) issued by the UMD, without user having
to provide a list of all required mappings during each submission (as
required by older execbuf mode).

This patch series support VM_BIND version 1, as described by the param
I915_PARAM_VM_BIND_VERSION.

Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in
vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any execlist support and all the
legacy support like relocations etc., are removed.

TODOs:
* Support out fence for VM_UNBIND ioctl.
* Async VM_UNBIND support.
* Share code between execbuf2 and execbuf3 where possible.
* Cleanups and optimizations.

NOTEs:
* It is based on below VM_BIND design+uapi patch series.
  https://lists.freedesktop.org/archives/intel-gfx/2022-July/300760.html

* The IGT RFC series is posted as,
  [RFC 0/5] vm_bind: Add VM_BIND validation support

Signed-off-by: Niranjana Vishwanathapura 

Niranjana Vishwanathapura (10):
  drm/i915/vm_bind: Introduce VM_BIND ioctl
  drm/i915/vm_bind: Bind and unbind mappings
  drm/i915/vm_bind: Support private and shared BOs
  drm/i915/vm_bind: Add out fence support
  drm/i915/vm_bind: Handle persistent vmas
  drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl
  drm/i915/vm_bind: Handle persistent vmas in execbuf3
  drm/i915/vm_bind: userptr dma-resv changes
  drm/i915/vm_bind: Skip vma_lookup for persistent vmas
  drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting

 drivers/gpu/drm/i915/Makefile |2 +
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   20 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |   15 +
 drivers/gpu/drm/i915/gem/i915_gem_create.c|   51 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|6 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|5 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 1270 +
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
 drivers/gpu/drm/i915/gem/i915_gem_object.c|1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|2 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |3 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |3 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |   54 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  342 +
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   37 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   20 +
 drivers/gpu/drm/i915/i915_driver.c|   38 +
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   22 +
 drivers/gpu/drm/i915/i915_getparam.c  |3 +
 drivers/gpu/drm/i915/i915_vma.c   |   59 +-
 drivers/gpu/drm/i915/i915_vma.h   |   80 +-
 drivers/gpu/drm/i915/i915_vma_types.h |   40 +
 include/uapi/drm/i915_drm.h   |  289 +++-
 23 files changed, 2316 insertions(+), 48 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

-- 
2.21.0.rc0.32.g243a4c7e27

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: clean up comments

[Patchwork]

== Series Details ==

Series: drm/i915/display: clean up comments
URL   : https://patchwork.freedesktop.org/series/105877/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11841 -> Patchwork_105877v1


Summary
---

  **FAILURE**

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

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

Participating hosts (41 -> 41)
--

  Additional (3): fi-hsw-4770 bat-dg2-9 bat-jsl-1 
  Missing(3): fi-bsw-kefka fi-tgl-dsi fi-tgl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html

  
 Suppressed 

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

  * igt@i915_selftest@live@coherency:
- {bat-adln-1}:   NOTRUN -> [DMESG-FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/bat-adln-1/igt@i915_selftest@l...@coherency.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [FAIL][4] ([fdo#103375])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@basic:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][5] ([fdo#109271]) +31 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-bdw-gvtdvm/igt@gem_lmem_swapp...@basic.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][8] -> [INCOMPLETE][9] ([i915#5847])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][10] ([i915#4528])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][11] -> [DMESG-FAIL][12] ([i915#4494] / 
[i915#4957])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][13] ([i915#4817])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([i915#5903])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][15] -> [DMESG-WARN][16] ([i915#3576]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#111827])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([fdo#111827])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105877v1/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_c

[Intel-gfx] [PATCH] drm/i915/display: clean up comments

[Tom Rix]

spelling changes
resoluition -> resolution
dont-> don't
commmit -> commit
Invalidade  -> Invalidate

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7d61c55184e5..e6a870641cd2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
/*
 * TODO: 7 lines of IO_BUFFER_WAKE and FAST_WAKE are default
 * values from BSpec. In order to setting an optimal power
-* consumption, lower than 4k resoluition mode needs to decrese
+* consumption, lower than 4k resolution mode needs to decrease
 * IO_BUFFER_WAKE and FAST_WAKE. And higher than 4K resolution
 * mode needs to increase IO_BUFFER_WAKE and FAST_WAKE.
 */
@@ -959,7 +959,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
int psr_setup_time;
 
/*
-* Current PSR panels dont work reliably with VRR enabled
+* Current PSR panels don't work reliably with VRR enabled
 * So if VRR is enabled, do not enable PSR.
 */
if (crtc_state->vrr.enable)
@@ -1664,7 +1664,7 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
struct intel_crtc_state *c
  *
  * Plane scaling and rotation is not supported by selective fetch and both
  * properties can change without a modeset, so need to be check at every
- * atomic commmit.
+ * atomic commit.
  */
 static bool psr2_sel_fetch_plane_state_supported(const struct 
intel_plane_state *plane_state)
 {
@@ -2203,7 +2203,7 @@ static void _psr_invalidate_handle(struct intel_dp 
*intel_dp)
 }
 
 /**
- * intel_psr_invalidate - Invalidade PSR
+ * intel_psr_invalidate - Invalidate PSR
  * @dev_priv: i915 device
  * @frontbuffer_bits: frontbuffer plane tracking bits
  * @origin: which operation caused the invalidate
-- 
2.27.0

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/doc/rfc: i915 VM_BIND feature design + uapi

[Patchwork]

== Series Details ==

Series: drm/doc/rfc: i915 VM_BIND feature design + uapi
URL   : https://patchwork.freedesktop.org/series/105845/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11837_full -> Patchwork_105845v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_query@query-regions-unallocated:
- {shard-dg1}:NOTRUN -> [SKIP][1] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/shard-dg1-17/igt@i915_qu...@query-regions-unallocated.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.50@execution@built-in-functions@gs-max-uvec2-uvec2:
- pig-skl-6260u:  NOTRUN -> [CRASH][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/pig-skl-6260u/spec@glsl-1.50@execution@built-in-functi...@gs-max-uvec2-uvec2.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][3], [PASS][4], [PASS][5], [PASS][6], 
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [FAIL][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk2/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11837/shard-glk2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/shard-glk6/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/shard-glk6/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/shard-glk5/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/shard-glk5/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105845v1/sha

Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown

[Umesh Nerlige Ramappa]

On Fri, Jul 01, 2022 at 09:37:20AM +0100, Tvrtko Ursulin wrote:


On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:

On Thu, Jun 30, 2022 at 09:00:28PM +, Stuart Summers wrote:

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue

Signed-off-by: Stuart Summers 
---


I thought this is likely happening because intel_gpu_top is running 
in the background when i915 is unloaded. I tried a quick repro, I 
don't see the unload succeed ("fatal module in use", not sure if 
this was a partial unload), but when I try to kill intel_gpu_top, I 
get an NPD. This is in the event disable path - i915_pmu_event_stop 
-> i915_pmu_disable.


So i915 failed to unload (as expected - with perf events open we 
elevate the module ref count via i915_pmu_event_init -> drm_dev_get), 
then you quit intel_gpu_top and get NPD?


I was just trying to point out an instance of the failure that I saw 
when running this execution sequence. This is without any of Stuart's 
changes.



On the engine lookup?


Don't know if it is specifically engine lookup, but it's in the path of 
i915_pmu_event_stop which executes on killing intel_gpu_top.



With the re-ordered init/fini sequence as from this patch?

No, without any changes from this thread.



With elevated module count there shouldn't be any unloading happening 
so I am intrigued.


It's likely that you are seeing a different path (unload) leading to 
the same issue.


I think in i915_pmu_disable/disable should be aware of 
event->hw.state and or pmu->closed states before accessing the 
event. Maybe like,


if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event)) {

@Tvrtko, wondering if this case is tested by 
igt@perf_pmu@module-unload.


A bit yes. From what Stuart wrote it seems the test would need to be 
extended to cover the case where PMU is getting opened while module 
unload is in progress.


But the NPD you saw is for the moment confusing so I don't know what 
is happening.


I guess it's a separate issue. I can check if Stuart's patches resolve 
it and if not, will create a bug.


Regards,
Umesh



I am not clear if we should use event->hw.state or pmu->closed here 
and if/how they are related. IMO, for this issue, the engine check 
is good enough too, so we don't really need the pmu state checks.  
Thoughts?


Engine check at the moment feels like papering.

Indeed as you say I think the pmu->closed might be the solution. 
Perhaps the race is as mentioned above. PMU open happening in parallel 
to unload..


If the sequence of events userspace triggers is:

 i915_pmu_event_init
 i915_pmu_event_start
 i915_pmu_enable
 i915_pmu_event_read

I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
would be the effect of that.. We'd try to get a module reference while 
in the process of unloading. Which is probably very bad.. So possibly 
a final check on pmu->close is needed there. Ho hum.. can it be made 
safe is the question.


It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps the 
evens open all the time. So I think more info needed, for me at least.


Regards,

Tvrtko



Regards,
Umesh


drivers/gpu/drm/i915/i915_driver.c | 11 ++---
drivers/gpu/drm/i915/i915_pmu.c    | 72 +-
2 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c

index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)

struct drm_device *dev = &dev_priv->drm;

i915_gem_driver_register(dev_priv);
-    i915_pmu_register(dev_priv);

intel_vgpu_register(dev_priv);

@@ -731,11 +730,12 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)

i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);

+    intel_gt_driver_register(to_gt(dev_priv));
+
/* Depends on sysfs having been initialized */
+    i915_pmu_register(dev_priv);
i915_perf_register(dev_priv);

-    intel_gt_driver_register(to_gt(dev_priv));
-
intel_display_driver_register(dev_priv);

intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)


intel_display_driver_unregister(dev_priv);

-    intel_gt_driver_unregister(to_gt(dev_priv));
-
i915_per

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix NPD in PMU during driver teardown (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown (rev4)
URL   : https://patchwork.freedesktop.org/series/105790/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11841 -> Patchwork_105790v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 43)
--

  Additional (3): fi-hsw-4770 bat-dg2-9 bat-jsl-1 
  Missing(1): fi-icl-u2 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adln-1}:   NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/bat-adln-1/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][3] ([fdo#109271]) +31 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-bdw-gvtdvm/igt@gem_lmem_swapp...@basic.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@gem_softpin@safe-alignment:
- fi-bsw-n3050:   [PASS][5] -> [DMESG-WARN][6] ([i915#6310])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-bsw-n3050/igt@gem_soft...@safe-alignment.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-bsw-n3050/igt@gem_soft...@safe-alignment.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576]) +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][10] ([i915#4785])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][11] -> [DMESG-FAIL][12] ([i915#4494] / 
[i915#4957])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][13] ([i915#4817])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [PASS][17] -> [FAIL][18] ([i915#6298])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11841/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v4/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
- fi-tgl-u2:  [PASS][19] -> [DMESG-WARN]

Re: [Intel-gfx] [PATCH 1/2] Revert "topic/core-for-CI: Add remaining DG2 and ATS-M device IDs"

[Lucas De Marchi]

On Fri, Jul 01, 2022 at 08:22:30AM -0700, Matt Roper wrote:

This reverts commit f7d7dddaab81eeae4508197b5f38f0b974d97b8c.

In reality we'll just rebase this patch out of the topic/core-for-CI
branch after landing the "real" copy in drm-intel.  But to prevent
pre-merge CI from getting confused, we send it as an explicit revert on
the mailing list.


ack on the approach

Lucas De Marchi

Re: [Intel-gfx] [PATCH 2/2] drm/i915: DG2 and ATS-M device ID updates

[Lucas De Marchi]

On Fri, Jul 01, 2022 at 08:22:31AM -0700, Matt Roper wrote:

Small BAR support has now landed, which allows us to add the PCI IDs
that correspond to add-in card designs of DG2 and ATS-M.  There's also
one additional MB-down PCI ID that recently appeared (0x5698) so we add
it too.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown (rev3)
URL   : https://patchwork.freedesktop.org/series/105790/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11836_full -> Patchwork_105790v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 13)
--

  Additional (4): shard-dg1 pig-glk-j5005 shard-rkl shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-c-edp-1:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-skl4/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-c-edp-1.html

  
 Suppressed 

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

  * igt@gem_create@create-ext-cpu-access-sanity-check:
- {shard-dg1}:NOTRUN -> [SKIP][2] +9 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-dg1-18/igt@gem_cre...@create-ext-cpu-access-sanity-check.html
- {shard-tglu}:   NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-tglu-2/igt@gem_cre...@create-ext-cpu-access-sanity-check.html

  * igt@i915_query@query-regions-unallocated:
- {shard-rkl}:NOTRUN -> [SKIP][4] +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-rkl-1/igt@i915_qu...@query-regions-unallocated.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1:
- {shard-dg1}:NOTRUN -> [FAIL][5] +5 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-dg1-17/igt@kms_flip@wf_vblank-ts-check-interrupti...@c-hdmi-a1.html

  

### Piglit changes ###

 Possible regressions 

  * 
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-add-float-mat2:
- pig-glk-j5005:  NOTRUN -> [CRASH][6] +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/pig-glk-j5005/spec@arb_tessellation_shader@execution@built-in-functi...@tcs-op-add-float-mat2.html

  * spec@nv_conditional_render@copyteximage:
- pig-skl-6260u:  NOTRUN -> [CRASH][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/pig-skl-6260u/spec@nv_conditional_ren...@copyteximage.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl:  [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +5 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11836/shard-apl8/igt@gem_ctx_isolation@preservation...@bcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-apl8/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][10] -> [INCOMPLETE][11] ([i915#4793])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11836/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-skl3/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@smoketest:
- shard-glk:  NOTRUN -> [INCOMPLETE][12] ([i915#6310])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-glk6/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11836/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-iclb8/igt@gem_exec_balan...@parallel-keep-submit-fence.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-kbl:  NOTRUN -> [FAIL][15] ([i915#6117])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v3/shard-kbl7/igt@gem_exec_balan...@parallel-ordering.html

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

  * igt@gem_exec_fair@basic-

[Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown

[Stuart Summers]

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue
v2: Use drm_WARN_ONCE instead of a debug print

Signed-off-by: Stuart Summers 
---
 drivers/gpu/drm/i915/i915_driver.c | 11 ++---
 drivers/gpu/drm/i915/i915_pmu.c| 70 +-
 2 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = &dev_priv->drm;
 
i915_gem_driver_register(dev_priv);
-   i915_pmu_register(dev_priv);
 
intel_vgpu_register(dev_priv);
 
@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
 
+   intel_gt_driver_register(to_gt(dev_priv));
+
/* Depends on sysfs having been initialized */
+   i915_pmu_register(dev_priv);
i915_perf_register(dev_priv);
 
-   intel_gt_driver_register(to_gt(dev_priv));
-
intel_display_driver_register(dev_priv);
 
intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
 
intel_display_driver_unregister(dev_priv);
 
-   intel_gt_driver_unregister(to_gt(dev_priv));
-
i915_perf_unregister(dev_priv);
+   /* GT should be available until PMU is gone */
i915_pmu_unregister(dev_priv);
 
+   intel_gt_driver_unregister(to_gt(dev_priv));
+
i915_teardown_sysfs(dev_priv);
drm_dev_unplug(&dev_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf1..adc81f5293d3 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,27 @@ static void i915_pmu_enable(struct perf_event *event)
if (is_engine_event(event)) {
u8 sample = engine_event_sample(event);
struct intel_engine_cs *engine;
-
-   engine = intel_engine_lookup_user(i915,
- engine_event_class(event),
- engine_event_instance(event));
-
-   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
-I915_ENGINE_SAMPLE_COUNT);
-   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
-I915_ENGINE_SAMPLE_COUNT);
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
-   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
-   GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-
-   engine->pmu.enable |= BIT(sample);
-   engine->pmu.enable_count[sample]++;
+   u8 class = engine_event_class(event);
+   u8 instance = engine_event_instance(event);
+
+   engine = intel_engine_lookup_user(i915, class, instance);
+   if (!drm_WARN_ONCE(&i915->drm,
+  !engine,
+  "Invalid engine event: { class:%d, inst:%d 
}\n",
+  class, instance)) {
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+I915_ENGINE_SAMPLE_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.sample) !=
+I915_ENGINE_SAMPLE_COUNT);
+   GEM_BUG_ON(sample >=
+  ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >=
+  ARRAY_SIZE(engine->pmu.sample));
+   GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
+
+   engine->pmu.enable |= BIT(sample);
+   engine->pmu.enable_count[sample]++;
+   }
}
 
spin_unlock_irqrestore(&pmu->lock, flags);
@@ -714,21 +720,25 @@ static void i915_pmu_disable(struct perf_event *event)
if (is_engine_event(event)) {
u8 sample = engine_event_sample(event);
struct intel_engine_cs *engine;
-
-   engine = intel_engine

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] Revert "topic/core-for-CI: Add remaining DG2 and ATS-M device IDs"

[Patchwork]

== Series Details ==

Series: series starting with [1/2] Revert "topic/core-for-CI: Add remaining DG2 
and ATS-M device IDs"
URL   : https://patchwork.freedesktop.org/series/105870/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11840 -> Patchwork_105870v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Additional (2): bat-dg2-8 fi-bxt-dsi 
  Missing(3): fi-ivb-3770 fi-ilk-650 fi-tgl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@engines@fds:
- fi-bsw-kefka:   [PASS][1] -> [INCOMPLETE][2] ([i915#6310])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-bsw-kefka/igt@gem_exec_parallel@engi...@fds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bsw-kefka/igt@gem_exec_parallel@engi...@fds.html

  * igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271]) +12 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][6] -> [DMESG-FAIL][7] ([i915#4494] / 
[i915#4957])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576]) +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][12] ([i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-bsw-kefka/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_mocs:
- {bat-adln-1}:   [DMESG-FAIL][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adln-1/igt@i915_selftest@live@gt_mocs.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/bat-adln-1/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][15] ([i915#3921]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- fi-apl-guc: [DMESG-FAIL][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-apl-guc/igt@i915_selftest@l...@hugepages.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/fi-apl-guc/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-adlp-6}:   [DMESG-FAIL][19] ([i915#4983]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/bat-adlp-6/igt@i915_selftest@l...@reset.html

  * igt@kms_busy@basic@modeset:
- {bat-adln-1}:   [DMESG-WARN][21] ([i915#3576]) -> [PASS][22] +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adln-1/igt@kms_busy@ba...@modeset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105870v1/bat-adln-1/igt@kms_busy@ba...@modeset.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}:   [DMESG-WARN][23] ([i91

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Implement w/a 16016694945

[Matt Roper]

On Fri, Jul 01, 2022 at 12:52:21PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/pvc: Implement w/a 16016694945
> URL   : https://patchwork.freedesktop.org/series/105837/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11835_full -> Patchwork_105837v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_105837v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_105837v1_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (13 -> 13)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_105837v1_full:
> 
> ### IGT changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_create@create-ext-cpu-access-big:
> - {shard-rkl}:NOTRUN -> [SKIP][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-rkl-5/igt@gem_cre...@create-ext-cpu-access-big.html
> 
>   * igt@i915_query@query-regions-unallocated:
> - {shard-dg1}:NOTRUN -> [SKIP][2] +2 similar issues
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-dg1-16/igt@i915_qu...@query-regions-unallocated.html

These both look like new tests that were just added to exercise small
BAR support; I believe the skips were expected until the corresponding
kernel changes from Matt Auld landed (which just happened this morning,
probably after this series was tested).  Not related to Gustavo's patch
here.

>   
> 
> ### Piglit changes ###
> 
>  Possible regressions 
> 
>   * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-3-unorm-2drect-const:
> - pig-glk-j5005:  NOTRUN -> [CRASH][3] +1 similar issue
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/pig-glk-j5005/spec@arb_gpu_shader5@texturegatheroff...@vs-rgba-3-unorm-2drect-const.html
> 
>   * spec@ext_texture_snorm@fbo-colormask-formats:
> - pig-skl-6260u:  NOTRUN -> [INCOMPLETE][4]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/pig-skl-6260u/spec@ext_texture_sn...@fbo-colormask-formats.html

The PVC workaround wouldn't have impacted execution on old gen9
platforms like GLK and SKL.  Not related to Gustavo's patch.


Applied to drm-intel-gt-next.  Thanks for the patch.

Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_105837v1_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_persistence@hang:
> - shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +116 similar 
> issues
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-skl6/igt@gem_ctx_persiste...@hang.html
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#5784])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_...@unwedge-stress.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-tglb5/igt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_balancer@parallel-bb-first:
> - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar 
> issue
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html
> 
>   * igt@gem_exec_fair@basic-none@vcs0:
> - shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
> issue
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-apl7/igt@gem_exec_fair@basic-n...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace@vcs0:
> - shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842])
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html
> 
>   * igt@gem_exec_fair@basic-throttle@rcs0:
> - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849]

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] Revert "topic/core-for-CI: Add remaining DG2 and ATS-M device IDs"

[Patchwork]

== Series Details ==

Series: series starting with [1/2] Revert "topic/core-for-CI: Add remaining DG2 
and ATS-M device IDs"
URL   : https://patchwork.freedesktop.org/series/105870/
State : warning

== Summary ==

Error: dim checkpatch failed
4863bd4151f5 Revert "topic/core-for-CI: Add remaining DG2 and ATS-M device IDs"
576e6bc96bca drm/i915: DG2 and ATS-M device ID updates
-:96: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#96: FILE: include/drm/i915_pciids.h:733:
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)

-:96: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#96: FILE: include/drm/i915_pciids.h:733:
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)

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

[Intel-gfx] [PATCH 1/2] Revert "topic/core-for-CI: Add remaining DG2 and ATS-M device IDs"

[Matt Roper]

This reverts commit f7d7dddaab81eeae4508197b5f38f0b974d97b8c.

In reality we'll just rebase this patch out of the topic/core-for-CI
branch after landing the "real" copy in drm-intel.  But to prevent
pre-merge CI from getting confused, we send it as an explicit revert on
the mailing list.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_pci.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c |  2 --
 include/drm/i915_pciids.h| 25 +++-
 3 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0cdd6513fbb7..5edc8fbf1dff 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1075,6 +1075,7 @@ static const struct intel_device_info dg2_info = {
.require_force_probe = 1,
 };
 
+__maybe_unused
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
.display = { 0 },
@@ -1188,7 +1189,6 @@ static const struct pci_device_id pciidlist[] = {
INTEL_RPLS_IDS(&adl_s_info),
INTEL_RPLP_IDS(&adl_p_info),
INTEL_DG2_IDS(&dg2_info),
-   INTEL_ATS_M_IDS(&ats_m_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index f0bf23726ed8..7eb893666595 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -189,12 +189,10 @@ static const u16 subplatform_rpl_ids[] = {
 
 static const u16 subplatform_g10_ids[] = {
INTEL_DG2_G10_IDS(0),
-   INTEL_ATS_M150_IDS(0),
 };
 
 static const u16 subplatform_g11_ids[] = {
INTEL_DG2_G11_IDS(0),
-   INTEL_ATS_M75_IDS(0),
 };
 
 static const u16 subplatform_g12_ids[] = {
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 4585fed4e41e..283dadfbb4db 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -696,41 +696,22 @@
 #define INTEL_DG2_G10_IDS(info) \
INTEL_VGA_DEVICE(0x5690, info), \
INTEL_VGA_DEVICE(0x5691, info), \
-   INTEL_VGA_DEVICE(0x5692, info), \
-   INTEL_VGA_DEVICE(0x56A0, info), \
-   INTEL_VGA_DEVICE(0x56A1, info), \
-   INTEL_VGA_DEVICE(0x56A2, info)
+   INTEL_VGA_DEVICE(0x5692, info)
 
 #define INTEL_DG2_G11_IDS(info) \
INTEL_VGA_DEVICE(0x5693, info), \
INTEL_VGA_DEVICE(0x5694, info), \
INTEL_VGA_DEVICE(0x5695, info), \
-   INTEL_VGA_DEVICE(0x56A5, info), \
-   INTEL_VGA_DEVICE(0x56A6, info), \
-   INTEL_VGA_DEVICE(0x56B0, info), \
-   INTEL_VGA_DEVICE(0x56B1, info)
+   INTEL_VGA_DEVICE(0x56B0, info)
 
 #define INTEL_DG2_G12_IDS(info) \
INTEL_VGA_DEVICE(0x5696, info), \
INTEL_VGA_DEVICE(0x5697, info), \
-   INTEL_VGA_DEVICE(0x56A3, info), \
-   INTEL_VGA_DEVICE(0x56A4, info), \
-   INTEL_VGA_DEVICE(0x56B2, info), \
-   INTEL_VGA_DEVICE(0x56B3, info)
+   INTEL_VGA_DEVICE(0x56B2, info)
 
 #define INTEL_DG2_IDS(info) \
INTEL_DG2_G10_IDS(info), \
INTEL_DG2_G11_IDS(info), \
INTEL_DG2_G12_IDS(info)
 
-#define INTEL_ATS_M150_IDS(info) \
-   INTEL_VGA_DEVICE(0x56C0, info)
-
-#define INTEL_ATS_M75_IDS(info) \
-   INTEL_VGA_DEVICE(0x56C1, info)
-
-#define INTEL_ATS_M_IDS(info) \
-   INTEL_ATS_M150_IDS(info), \
-   INTEL_ATS_M75_IDS(info)
-
 #endif /* _I915_PCIIDS_H */
-- 
2.36.1

[Intel-gfx] [PATCH 2/2] drm/i915: DG2 and ATS-M device ID updates

[Matt Roper]

Small BAR support has now landed, which allows us to add the PCI IDs
that correspond to add-in card designs of DG2 and ATS-M.  There's also
one additional MB-down PCI ID that recently appeared (0x5698) so we add
it too.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_pci.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c |  2 ++
 include/drm/i915_pciids.h| 26 +---
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5edc8fbf1dff..0cdd6513fbb7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1075,7 +1075,6 @@ static const struct intel_device_info dg2_info = {
.require_force_probe = 1,
 };
 
-__maybe_unused
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
.display = { 0 },
@@ -1189,6 +1188,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_RPLS_IDS(&adl_s_info),
INTEL_RPLP_IDS(&adl_p_info),
INTEL_DG2_IDS(&dg2_info),
+   INTEL_ATS_M_IDS(&ats_m_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 7eb893666595..f0bf23726ed8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -189,10 +189,12 @@ static const u16 subplatform_rpl_ids[] = {
 
 static const u16 subplatform_g10_ids[] = {
INTEL_DG2_G10_IDS(0),
+   INTEL_ATS_M150_IDS(0),
 };
 
 static const u16 subplatform_g11_ids[] = {
INTEL_DG2_G11_IDS(0),
+   INTEL_ATS_M75_IDS(0),
 };
 
 static const u16 subplatform_g12_ids[] = {
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 283dadfbb4db..1bd0420a213d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -696,22 +696,42 @@
 #define INTEL_DG2_G10_IDS(info) \
INTEL_VGA_DEVICE(0x5690, info), \
INTEL_VGA_DEVICE(0x5691, info), \
-   INTEL_VGA_DEVICE(0x5692, info)
+   INTEL_VGA_DEVICE(0x5692, info), \
+   INTEL_VGA_DEVICE(0x56A0, info), \
+   INTEL_VGA_DEVICE(0x56A1, info), \
+   INTEL_VGA_DEVICE(0x56A2, info)
 
 #define INTEL_DG2_G11_IDS(info) \
INTEL_VGA_DEVICE(0x5693, info), \
INTEL_VGA_DEVICE(0x5694, info), \
INTEL_VGA_DEVICE(0x5695, info), \
-   INTEL_VGA_DEVICE(0x56B0, info)
+   INTEL_VGA_DEVICE(0x5698, info), \
+   INTEL_VGA_DEVICE(0x56A5, info), \
+   INTEL_VGA_DEVICE(0x56A6, info), \
+   INTEL_VGA_DEVICE(0x56B0, info), \
+   INTEL_VGA_DEVICE(0x56B1, info)
 
 #define INTEL_DG2_G12_IDS(info) \
INTEL_VGA_DEVICE(0x5696, info), \
INTEL_VGA_DEVICE(0x5697, info), \
-   INTEL_VGA_DEVICE(0x56B2, info)
+   INTEL_VGA_DEVICE(0x56A3, info), \
+   INTEL_VGA_DEVICE(0x56A4, info), \
+   INTEL_VGA_DEVICE(0x56B2, info), \
+   INTEL_VGA_DEVICE(0x56B3, info)
 
 #define INTEL_DG2_IDS(info) \
INTEL_DG2_G10_IDS(info), \
INTEL_DG2_G11_IDS(info), \
INTEL_DG2_G12_IDS(info)
 
+#define INTEL_ATS_M150_IDS(info) \
+   INTEL_VGA_DEVICE(0x56C0, info)
+
+#define INTEL_ATS_M75_IDS(info) \
+   INTEL_VGA_DEVICE(0x56C1, info)
+
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.36.1

Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown

[Summers, Stuart]

On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
> On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
> > On Thu, Jun 30, 2022 at 09:00:28PM +, Stuart Summers wrote:
> > > In the driver teardown, we are unregistering the gt prior
> > > to unregistering the PMU. This means there is a small window
> > > of time in which the application can request metrics from the
> > > PMU, some of which are calling into the uapi engines list,
> > > while the engines are not available. In this case we can
> > > see null pointer dereferences.
> > > 
> > > Fix this ordering in both the driver load and unload sequences.
> > > 
> > > Additionally add a check for engine presence to prevent this
> > > NPD in the event this ordering is accidentally reversed. Print
> > > a debug message indicating when they aren't available.
> > > 
> > > v1: Actually address the driver load/unload ordering issue
> > > 
> > > Signed-off-by: Stuart Summers 
> > > ---
> > 
> > I thought this is likely happening because intel_gpu_top is running
> > in 
> > the background when i915 is unloaded. I tried a quick repro, I
> > don't see 
> > the unload succeed ("fatal module in use", not sure if this was a 
> > partial unload), but when I try to kill intel_gpu_top, I get an
> > NPD. 
> > This is in the event disable path - i915_pmu_event_stop -> 
> > i915_pmu_disable.
> 
> So i915 failed to unload (as expected - with perf events open we
> elevate 
> the module ref count via i915_pmu_event_init -> drm_dev_get), then
> you 
> quit intel_gpu_top and get NPD? On the engine lookup? With the 
> re-ordered init/fini sequence as from this patch?
> 
> With elevated module count there shouldn't be any unloading happening
> so 
> I am intrigued.
> 
> > It's likely that you are seeing a different path (unload) leading
> > to the 
> > same issue.
> > 
> > I think in i915_pmu_disable/disable should be aware of event-
> > >hw.state 
> > and or pmu->closed states before accessing the event. Maybe like,
> > 
> > if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event))
> > {
> > 
> > @Tvrtko, wondering if this case is tested by igt@perf
> > _pmu@module-unload. 
> 
> A bit yes. From what Stuart wrote it seems the test would need to be 
> extended to cover the case where PMU is getting opened while module 
> unload is in progress.
> 
> But the NPD you saw is for the moment confusing so I don't know what
> is 
> happening.
> 
> > I am not clear if we should use event->hw.state or pmu->closed here
> > and 
> > if/how they are related. IMO, for this issue, the engine check is
> > good 
> > enough too, so we don't really need the pmu state checks. 
> > Thoughts?
> 
> Engine check at the moment feels like papering.
> 
> Indeed as you say I think the pmu->closed might be the solution.
> Perhaps 
> the race is as mentioned above. PMU open happening in parallel to
> unload..
> 
> If the sequence of events userspace triggers is:
> 
>i915_pmu_event_init
>i915_pmu_event_start
>i915_pmu_enable
>i915_pmu_event_read
> 
> I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
> would be the effect of that.. We'd try to get a module reference
> while 
> in the process of unloading. Which is probably very bad.. So possibly
> a 
> final check on pmu->close is needed there. Ho hum.. can it be made
> safe 
> is the question.
> 
> It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps
> the 
> evens open all the time. So I think more info needed, for me at
> least.

So one thing here is this doesn't have to do with module unload, but
module unbind specifically (while perf is open). I don't know if the
NPD from Umesh is the same as what we're seeing here. I'd really like
to separate these unless you know for sure that's related. Also it
would be interesting to know if this patch fixes your issue as well.

I still think the re-ordering in i915_driver.c should be enough and we
shouldn't need to check pmu->closed. The unregister should be enough to
ensure the perf tools are notified that new events aren't allowed, and
at that time the engine structures are still intact. And even if for
some reason the perf code still calls in to our function pointers, we
have these engine checks as a failsafe.

I'm by the way uploading one more version here with a drm_WARN_ONCE
instead of the debug print.

Thanks,
Stuart

> 
> Regards,
> 
> Tvrtko
> 
> > Regards,
> > Umesh
> > 
> > > drivers/gpu/drm/i915/i915_driver.c | 11 ++---
> > > drivers/gpu/drm/i915/i915_pmu.c| 72 +--
> > > ---
> > > 2 files changed, 48 insertions(+), 35 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index deb8a8b76965..ee4dcb85d206 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -717,7 +717,6 @@ static void i915_driver_register(struct 
> > > drm_i915_private *dev_priv)
> > > struct drm_device *dev = &dev_priv->drm;

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix NPD in PMU during driver teardown (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix NPD in PMU during driver teardown (rev2)
URL   : https://patchwork.freedesktop.org/series/105790/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11835_full -> Patchwork_105790v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  

### Piglit changes ###

 Possible regressions 

  * 
spec@glsl-4.20@execution@vs_in@vs-input-float_mat2-double_dmat4x2_array2-position:
- pig-glk-j5005:  NOTRUN -> [CRASH][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/pig-glk-j5005/spec@glsl-4.20@execution@vs_in@vs-input-float_mat2-double_dmat4x2_array2-position.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +5 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +120 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-skl7/igt@gem_ctx_persiste...@hang.html

  * igt@gem_ctx_persistence@smoketest:
- shard-kbl:  [PASS][7] -> [INCOMPLETE][8] ([i915#6310])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl1/igt@gem_ctx_persiste...@smoketest.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl6/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#3063])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb2/igt@gem_...@in-flight-contexts-10ms.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb1/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#5784])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_...@unwedge-stress.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-tglb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@gem_exec_balan...@parallel.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb8/igt@gem_exec_balan...@parallel.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-glk8/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105790v2/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_schedule@pi-distinct-iova@vecs0:
- shard-glk:  [PASS][20] -> [INCOMPLETE][21] ([i915#

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke PCH_MCC

[Jani Nikula]

On Fri, 01 Jul 2022, Ville Syrjälä  wrote:
> On Fri, Jul 01, 2022 at 12:55:43PM +0300, Jani Nikula wrote:
>> On Thu, 30 Jun 2022, Ville Syrjala  wrote:
>> > From: Ville Syrjälä 
>> >
>> > MCC is derived from TGP, and we have no real need to
>> > differentiate between the two. Thus remove PCH_MCC and
>> > just declare it to be PCH_TGP compatible.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_ddi.c  | 2 +-
>> >  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
>> >  drivers/gpu/drm/i915/intel_pch.c  | 3 ++-
>> >  drivers/gpu/drm/i915/intel_pch.h  | 4 +---
>> >  4 files changed, 5 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>> > b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > index 272e1bf6006b..2330604b0bcc 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > @@ -4179,7 +4179,7 @@ static enum hpd_pin ehl_hpd_pin(struct 
>> > drm_i915_private *dev_priv,
>> >if (port == PORT_D)
>> >return HPD_PORT_A;
>> >  
>> > -  if (HAS_PCH_MCC(dev_priv))
>> > +  if (HAS_PCH_TGP(dev_priv))
>> >return icl_hpd_pin(dev_priv, port);
>> >  
>> >return HPD_PORT_A + port - PORT_A;
>> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
>> > b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > index 1ae09431f53a..ebd91aa69dd2 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> > @@ -2852,7 +2852,7 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder 
>> > *encoder)
>> >ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
>> >else if (DISPLAY_VER(dev_priv) == 9 && HAS_PCH_TGP(dev_priv))
>> >ddc_pin = gen9bc_tgp_port_to_ddc_pin(dev_priv, port);
>> > -  else if (HAS_PCH_MCC(dev_priv))
>> > +  else if (IS_JSL_EHL(dev_priv) && HAS_PCH_TGP(dev_priv))
>> >ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
>> 
>> Nitpick, mcc_ prefix is now an outlier here, and could be named after
>> the CPU/PCH combo like above for gen 9 and TGP. But no big deal.
>
> I want to rewrite these entirely. They should be doing 99% the same
> thing as the foo_hpd_pin() functions, yet they are written in all
> various kinds of different ways (none of which match the hpd_pin()
> stuff).
>
> Also while looking at that I stumbled on the VBT code doing a
> slightly different variant of the same stuff using arrays. And on
> top of that we have the VBT AUX CH mapping code as well, written
> in yet another style. So I think I want to try to unify it all
> to a common approach.

Ack. I've looked at all of this before, but haven't really come up with
anything neat, just grumbling about how it's split between VBT parsing
and this.

> I'm thinking the array approach might be the easiest to parse for
> mere mortals, so kinda leaning towards that. What do you think?

Sounds good, and it has a better separation of platforms, instead of a
bunch of magic conditions. OTOH I'm not overly enthusiastic about how
dvo_port_to_port() ended up looking, and why it needs to be platform
specific at all, oh well. I think you'll only know for real when you've
played with the code and have half the implementation written...

> Although one hurdle between me and arrays for the VBT AUX CH stuff
> is the VBT values which are shifted up into the upper nibble of
> the byte. So using those directly would result in giant arrays
> which are mostly empty. But I could redefine the VBT values as
> just the upper four bits and shift down when parsing the VBT.

If we can hide that in intel_bios.c or something, should be fine I
think.

BR,
Jani.

>
>> 
>> Reviewed-by: Jani Nikula 
>
> Thanks.
>
>> 
>> 
>> 
>> >else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>> >ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
>> > diff --git a/drivers/gpu/drm/i915/intel_pch.c 
>> > b/drivers/gpu/drm/i915/intel_pch.c
>> > index 94446cac6605..b45c504c6f03 100644
>> > --- a/drivers/gpu/drm/i915/intel_pch.c
>> > +++ b/drivers/gpu/drm/i915/intel_pch.c
>> > @@ -116,7 +116,8 @@ intel_pch_type(const struct drm_i915_private 
>> > *dev_priv, unsigned short id)
>> >case INTEL_PCH_MCC_DEVICE_ID_TYPE:
>> >drm_dbg_kms(&dev_priv->drm, "Found Mule Creek Canyon PCH\n");
>> >drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
>> > -  return PCH_MCC;
>> > +  /* MCC is TGP compatible */
>> > +  return PCH_TGP;
>> >case INTEL_PCH_TGP_DEVICE_ID_TYPE:
>> >case INTEL_PCH_TGP2_DEVICE_ID_TYPE:
>> >drm_dbg_kms(&dev_priv->drm, "Found Tiger Lake LP PCH\n");
>> > diff --git a/drivers/gpu/drm/i915/intel_pch.h 
>> > b/drivers/gpu/drm/i915/intel_pch.h
>> > index b7a8cf409d48..07f6f5517968 100644
>> > --- a/drivers/gpu/drm/i915/intel_pch.h
>> > +++ b/drivers/gpu/drm/i915/intel_pch.h
>> > @@ -24,8 +24,7 @@ enum intel_pch {
>> >PCH_CNP,/* Cannon/Comet Lake PCH */
>> >

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid

[Ville Syrjälä]

On Fri, Jul 01, 2022 at 11:55:38AM +0300, Jani Nikula wrote:
> Convert all the connectors that use cached connector edid and
> detect_edid to drm_edid.
> 
> Since drm_get_edid() calls drm_connector_update_edid_property() while
> drm_edid_read*() do not, we need to call drm_edid_connector_update()
> separately, in part due to the EDID caching behaviour in HDMI and
> DP. Especially DP depends on the details parsed from EDID. (The big
> behavioural change conflating EDID reading with parsing and property
> update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
> drm_connector"))
> 
> v4: Call drm_edid_connector_update() after reading HDMI/DP EDID
> 
> v3: Don't leak vga switcheroo EDID in LVDS init (Ville)
> 
> v2: Don't leak opregion fallback EDID (Ville)
> 
> Signed-off-by: Jani Nikula 
> ---
>  .../gpu/drm/i915/display/intel_connector.c|  4 +-
>  .../drm/i915/display/intel_display_types.h|  4 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 80 +++
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
>  drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
>  5 files changed, 87 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 1dcc268927a2..d83b2a64f618 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector 
> *connector)
>  {
>   struct intel_connector *intel_connector = to_intel_connector(connector);
>  
> - kfree(intel_connector->detect_edid);
> + drm_edid_free(intel_connector->detect_edid);
>  
>   intel_hdcp_cleanup(intel_connector);
>  
>   if (!IS_ERR_OR_NULL(intel_connector->edid))
> - kfree(intel_connector->edid);
> + drm_edid_free(intel_connector->edid);
>  
>   intel_panel_fini(intel_connector);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0da9b208d56e..d476df0ac9df 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -592,8 +592,8 @@ struct intel_connector {
>   struct intel_panel panel;
>  
>   /* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
> - struct edid *edid;
> - struct edid *detect_edid;
> + const struct drm_edid *edid;
> + const struct drm_edid *detect_edid;
>  
>   /* Number of times hotplug detection was tried after an HPD interrupt */
>   int hotplug_retries;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 32292c0be2bd..8a3b2dbebe04 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3577,12 +3577,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp 
> *intel_dp)
>   intel_dp->aux.i2c_defer_count);
>   intel_dp->compliance.test_data.edid = 
> INTEL_DP_RESOLUTION_FAILSAFE;
>   } else {
> - struct edid *block = intel_connector->detect_edid;
> + /* FIXME: Get rid of drm_edid_raw() */
> + const struct edid *block = 
> drm_edid_raw(intel_connector->detect_edid);
>  
> - /* We have to write the checksum
> -  * of the last block read
> -  */
> - block += intel_connector->detect_edid->extensions;
> + /* We have to write the checksum of the last block read */
> + block += block->extensions;
>  
>   if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_EDID_CHECKSUM,
>  block->checksum) <= 0)
> @@ -4461,7 +4460,7 @@ bool intel_digital_port_connected(struct intel_encoder 
> *encoder)
>   return is_connected;
>  }
>  
> -static struct edid *
> +static const struct drm_edid *
>  intel_dp_get_edid(struct intel_dp *intel_dp)
>  {
>   struct intel_connector *intel_connector = intel_dp->attached_connector;
> @@ -4472,18 +4471,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
>   if (IS_ERR(intel_connector->edid))
>   return NULL;
>  
> - return drm_edid_duplicate(intel_connector->edid);
> + return drm_edid_dup(intel_connector->edid);
>   } else
> - return drm_get_edid(&intel_connector->base,
> - &intel_dp->aux.ddc);
> + return drm_edid_read_ddc(&intel_connector->base,
> +  &intel_dp->aux.ddc);
>  }
>  
>  static void
>  intel_dp_update_dfp(struct intel_dp *intel_dp,
> - const struct edid *edid)
> + const struct drm_edid *drm_edid)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   struct intel_connector *connector = 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Implement w/a 16016694945

[Patchwork]

== Series Details ==

Series: drm/i915/pvc: Implement w/a 16016694945
URL   : https://patchwork.freedesktop.org/series/105837/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11835_full -> Patchwork_105837v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_create@create-ext-cpu-access-big:
- {shard-rkl}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-rkl-5/igt@gem_cre...@create-ext-cpu-access-big.html

  * igt@i915_query@query-regions-unallocated:
- {shard-dg1}:NOTRUN -> [SKIP][2] +2 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-dg1-16/igt@i915_qu...@query-regions-unallocated.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-3-unorm-2drect-const:
- pig-glk-j5005:  NOTRUN -> [CRASH][3] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/pig-glk-j5005/spec@arb_gpu_shader5@texturegatheroff...@vs-rgba-3-unorm-2drect-const.html

  * spec@ext_texture_snorm@fbo-colormask-formats:
- pig-skl-6260u:  NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/pig-skl-6260u/spec@ext_texture_sn...@fbo-colormask-formats.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +116 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-skl6/igt@gem_ctx_persiste...@hang.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#5784])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-apl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_schedule@u-submit-late-slice@bcs0:
- shard-glk:  [PASS][17] -> [INCOMPLETE][18] ([i915#6310])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-glk9/igt@gem_exec_schedule@u-submit-late-sl...@bcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105837v1/shard-glk2/igt@gem_exec_schedule@u-submit-late-sl...@bcs0.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [19]: 
https://

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke PCH_MCC

[Ville Syrjälä]

On Fri, Jul 01, 2022 at 12:55:43PM +0300, Jani Nikula wrote:
> On Thu, 30 Jun 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > MCC is derived from TGP, and we have no real need to
> > differentiate between the two. Thus remove PCH_MCC and
> > just declare it to be PCH_TGP compatible.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c  | 2 +-
> >  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> >  drivers/gpu/drm/i915/intel_pch.c  | 3 ++-
> >  drivers/gpu/drm/i915/intel_pch.h  | 4 +---
> >  4 files changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 272e1bf6006b..2330604b0bcc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4179,7 +4179,7 @@ static enum hpd_pin ehl_hpd_pin(struct 
> > drm_i915_private *dev_priv,
> > if (port == PORT_D)
> > return HPD_PORT_A;
> >  
> > -   if (HAS_PCH_MCC(dev_priv))
> > +   if (HAS_PCH_TGP(dev_priv))
> > return icl_hpd_pin(dev_priv, port);
> >  
> > return HPD_PORT_A + port - PORT_A;
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > index 1ae09431f53a..ebd91aa69dd2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > @@ -2852,7 +2852,7 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder 
> > *encoder)
> > ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
> > else if (DISPLAY_VER(dev_priv) == 9 && HAS_PCH_TGP(dev_priv))
> > ddc_pin = gen9bc_tgp_port_to_ddc_pin(dev_priv, port);
> > -   else if (HAS_PCH_MCC(dev_priv))
> > +   else if (IS_JSL_EHL(dev_priv) && HAS_PCH_TGP(dev_priv))
> > ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
> 
> Nitpick, mcc_ prefix is now an outlier here, and could be named after
> the CPU/PCH combo like above for gen 9 and TGP. But no big deal.

I want to rewrite these entirely. They should be doing 99% the same
thing as the foo_hpd_pin() functions, yet they are written in all
various kinds of different ways (none of which match the hpd_pin()
stuff).

Also while looking at that I stumbled on the VBT code doing a
slightly different variant of the same stuff using arrays. And on
top of that we have the VBT AUX CH mapping code as well, written
in yet another style. So I think I want to try to unify it all
to a common approach.

I'm thinking the array approach might be the easiest to parse for
mere mortals, so kinda leaning towards that. What do you think?

Although one hurdle between me and arrays for the VBT AUX CH stuff
is the VBT values which are shifted up into the upper nibble of
the byte. So using those directly would result in giant arrays
which are mostly empty. But I could redefine the VBT values as
just the upper four bits and shift down when parsing the VBT.

> 
> Reviewed-by: Jani Nikula 

Thanks.

> 
> 
> 
> > else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> > ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> > diff --git a/drivers/gpu/drm/i915/intel_pch.c 
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index 94446cac6605..b45c504c6f03 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -116,7 +116,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
> > unsigned short id)
> > case INTEL_PCH_MCC_DEVICE_ID_TYPE:
> > drm_dbg_kms(&dev_priv->drm, "Found Mule Creek Canyon PCH\n");
> > drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
> > -   return PCH_MCC;
> > +   /* MCC is TGP compatible */
> > +   return PCH_TGP;
> > case INTEL_PCH_TGP_DEVICE_ID_TYPE:
> > case INTEL_PCH_TGP2_DEVICE_ID_TYPE:
> > drm_dbg_kms(&dev_priv->drm, "Found Tiger Lake LP PCH\n");
> > diff --git a/drivers/gpu/drm/i915/intel_pch.h 
> > b/drivers/gpu/drm/i915/intel_pch.h
> > index b7a8cf409d48..07f6f5517968 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.h
> > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > @@ -24,8 +24,7 @@ enum intel_pch {
> > PCH_CNP,/* Cannon/Comet Lake PCH */
> > PCH_ICP,/* Ice Lake PCH */
> > PCH_JSP,/* Jasper Lake PCH */
> > -   PCH_MCC,/* Mule Creek Canyon PCH */
> > -   PCH_TGP,/* Tiger Lake PCH */
> > +   PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
> > PCH_ADP,/* Alder Lake PCH */
> >  
> > /* Fake PCHs, functionality handled on the same PCI dev */
> > @@ -69,7 +68,6 @@ enum intel_pch {
> >  #define HAS_PCH_ADP(dev_priv)  
> > (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
> >  #define HAS_PCH_DG1(dev_priv)  
> > (INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
> >  #define HAS_PCH_JSP(dev_priv)  
> > (INTEL_PCH_TYPE(dev_priv) == PCH_JSP)
> > -#define HAS_PCH_MCC(d

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: wait on timeout before retry (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: wait on timeout before retry (rev3)
URL   : https://patchwork.freedesktop.org/series/105660/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11840 -> Patchwork_105660v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 40)
--

  Additional (2): fi-bxt-dsi fi-icl-u2 
  Missing(2): fi-hsw-4770 fi-rkl-guc 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@workarounds:
- {bat-adlp-6}:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/bat-adlp-6/igt@i915_selftest@l...@workarounds.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +12 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][8] -> [DMESG-FAIL][9] ([i915#4494] / 
[i915#4957])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([i915#5903])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][11] -> [DMESG-WARN][12] ([i915#3576]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([i915#4103])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2:  NOTRUN -> [WARN][17] ([i915#6008])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([fdo#109285])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v3/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2:  NOTRUN -> [SKIP][19] ([i915#3555]

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Clean up drm_crtc.h (rev6)

[Patchwork]

== Series Details ==

Series: drm: Clean up drm_crtc.h (rev6)
URL   : https://patchwork.freedesktop.org/series/105073/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11835_full -> Patchwork_105073v6_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_query@query-regions-unallocated:
- {shard-dg1}:NOTRUN -> [SKIP][1] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-dg1-15/igt@i915_qu...@query-regions-unallocated.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_gpu_shader5@texturegather@vs-rgb-2-int-2d:
- pig-glk-j5005:  NOTRUN -> [CRASH][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/pig-glk-j5005/spec@arb_gpu_shader5@texturegat...@vs-rgb-2-int-2d.html

  * spec@ext_framebuffer_multisample@sample-alpha-to-coverage 8 color:
- pig-skl-6260u:  NOTRUN -> [CRASH][3]
   [3]: None

  * spec@ext_transform_feedback@builtin-varyings gl_position:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][4]
   [4]: None

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][5] ([i915#4991])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-apl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#6268])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb1/igt@gem_ctx_e...@basic-nohangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +11 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +120 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-skl4/igt@gem_ctx_persiste...@hang.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#5784])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-tglb7/igt@gem_...@unwedge-stress.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb2/igt@gem_exec_balan...@parallel.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-iclb5/igt@gem_exec_balan...@parallel.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: NOTRUN -> [FAIL][15] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-glk1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11835/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v6/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_parallel@engines@fds:
- shard-glk:  [PASS][20] -> [INCOMPLETE][21] ([i915#6310]) +1 
si

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: wait on timeout before retry (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: wait on timeout before retry (rev2)
URL   : https://patchwork.freedesktop.org/series/105660/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11840 -> Patchwork_105660v2


Summary
---

  **FAILURE**

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

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

Participating hosts (40 -> 40)
--

  Additional (3): bat-dg2-8 fi-bxt-dsi fi-icl-u2 
  Missing(3): bat-adlp-4 fi-snb-2520m fi-pnv-d510 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@client:
- fi-bdw-5557u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-bdw-5557u/igt@i915_selftest@l...@client.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-bdw-5557u/igt@i915_selftest@l...@client.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +12 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u:   [PASS][8] -> [DMESG-FAIL][9] ([i915#62])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-cfl-8109u/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][10] -> [INCOMPLETE][11] ([i915#4983])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][12] -> [INCOMPLETE][13] ([i915#4785])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5:  [PASS][14] -> [DMESG-FAIL][15] ([i915#4494] / 
[i915#4957])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [PASS][16] -> [DMESG-WARN][17] ([i915#5904]) +11 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
- fi-bsw-nick:[PASS][18] -> [DMESG-FAIL][19] ([i915#3428])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105660v2/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u:   [PASS][20] -> [DMESG-WARN][21] ([i915#5904] / 
[i915#62])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pat

Re: [Intel-gfx] [PATCHv3] drm/i915/dp: wait on timeout before retry

[Jani Nikula]

On Fri, 01 Jul 2022, Arun R Murthy  wrote:
> On linktraining error/timeout before retry need to wait for 400usec as
> per the DP CTS spec1.2
>
> The patch with commit 74ebf294a1dd ("drm/i915: Add a delay in Displayport
> AUX transactions for compliance testing")
> removes this delay mentioning the hardware already meets this requirement,
> but as per the spec the delay mentioned in the spec specifies how long to
> wait for the receiver response before timeout. So the delay here to wait
> for timeout and not a delay after timeout. The DP spec specifies a delay
> after timeout and hence adding this delay.
>
> v2: fixed checkpatch warning and error
> v3: used proper indentation
>
> Signed-off-by: Arun R Murthy 

Based on the description alone,

Acked-by: Jani Nikula 

but would be good if you could get someone to double check the details
against bspec and CTS.

> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 2bc119374555..722c9f210690 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   /*
>* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
>*   400us delay required for errors and timeouts
> -  *   Timeout errors from the HW already meet this
> -  *   requirement so skip to next iteration
>*/
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> -
> - if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> + if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
> +   DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
>   usleep_range(400, 500);
>   continue;
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCHv3] drm/i915/dp: wait on timeout before retry

[Arun R Murthy]

On linktraining error/timeout before retry need to wait for 400usec as
per the DP CTS spec1.2

The patch with commit 74ebf294a1dd ("drm/i915: Add a delay in Displayport
AUX transactions for compliance testing")
removes this delay mentioning the hardware already meets this requirement,
but as per the spec the delay mentioned in the spec specifies how long to
wait for the receiver response before timeout. So the delay here to wait
for timeout and not a delay after timeout. The DP spec specifies a delay
after timeout and hence adding this delay.

v2: fixed checkpatch warning and error
v3: used proper indentation

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 2bc119374555..722c9f210690 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
/*
 * DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
 *   400us delay required for errors and timeouts
-*   Timeout errors from the HW already meet this
-*   requirement so skip to next iteration
 */
-   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
-   continue;
-
-   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
+   if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
+ DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
usleep_range(400, 500);
continue;
}
-- 
2.25.1

Re: [Intel-gfx] [PATCHv2] drm/i915/dp: wait on timeout before retry

[Jani Nikula]

On Fri, 01 Jul 2022, Arun R Murthy  wrote:
> On linktraining error/timeout before retry need to wait for 400usec as
> per the DP CTS spec1.2
>
> The patch with commit 74ebf294a1dd ("drm/i915: Add a delay in Displayport
> AUX transactions for compliance testing")
> removes this delay mentioning the hardware already meets this requirement,
> but as per the spec the delay mentioned in the spec specifies how long to
> wait for the receiver response before timeout. So the delay here to wait
> for timeout and not a delay after timeout. The DP spec specifies a delay
> after timeout and hence adding this delay.
>
> v2: fixed checkpatch errors and warnings
>
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 2bc119374555..3fcff3995009 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   /*
>* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
>*   400us delay required for errors and timeouts
> -  *   Timeout errors from the HW already meet this
> -  *   requirement so skip to next iteration
>*/
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> -
> - if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> + if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
> + DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
>   usleep_range(400, 500);
>   continue;
>   }

Hate to be a nag, but this is what the indentation should look like:

-   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
+   if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
+ DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
usleep_range(400, 500);
continue;
}

i.e. leading tabs, then spaces. It'll pay off to have the editor do this
for you.

BR,
Jani.


-- 
2.30.2





-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCHv2] drm/i915/dp: wait on timeout before retry

[Arun R Murthy]

On linktraining error/timeout before retry need to wait for 400usec as
per the DP CTS spec1.2

The patch with commit 74ebf294a1dd ("drm/i915: Add a delay in Displayport
AUX transactions for compliance testing")
removes this delay mentioning the hardware already meets this requirement,
but as per the spec the delay mentioned in the spec specifies how long to
wait for the receiver response before timeout. So the delay here to wait
for timeout and not a delay after timeout. The DP spec specifies a delay
after timeout and hence adding this delay.

v2: fixed checkpatch errors and warnings

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 2bc119374555..3fcff3995009 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
/*
 * DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
 *   400us delay required for errors and timeouts
-*   Timeout errors from the HW already meet this
-*   requirement so skip to next iteration
 */
-   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
-   continue;
-
-   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
+   if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
+   DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
usleep_range(400, 500);
continue;
}
-- 
2.25.1

Re: [Intel-gfx] [PATCH v6] drm/i915/dsi: add payload receiving code

[Jani Nikula]

On Wed, 22 Jun 2022, William Tseng  wrote:
> To support Host to read data from Peripheral after
> a DCS read command is sent over DSI.

Please find a couple of comments inline below. Basically with them fixed
this is

Acked-by: Jani Nikula 

I'm afraid I just don't have the time for further detailed review right
now. I do note that this has no regression potential for the existing
DSI write paths, so (apart from the potential buffer overflow I note
below) this should be a pretty safe change, as long as it's tested to
work.


BR,
Jani.


>
> v1: initial version.
> v2:
> - adding error message when failing to place BTA.
> - returning byte number instead of 0 for the read
> function dsi_read_pkt_payld().
> v3: fixing coding style warning.
> v4:
> - correcting the data type of returning data for
> the read function dsi_read_pkt_payld().
> v5: adding change history as part of commit messages.
> v6: according to the review comments from Jani,
> - drop the commented out variable "hdr_data".
> - use int insteaf of u8 as the data type of the loop
> variable i.
> - use intel_de_rmw() for read-modify-write.
> - add new function place_bta_request() to keep
> payload receive function clean.
> - explicitly clear the READ_UNLOADS_DW bit of
> DSI_CMD_RXCTL before reading receive payload.
> - use two loops to copy received data.
> - remove the unrelated change from this patch,
> which is made to gen11_dsi_setup_timeouts().
> - drop the comment in gen11_dsi_host_transfer().
> - change the condition to call the payload
> receive function in gen11_dsi_host_transfer().
>
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Vandita Kulkarni 
> Cc: Lee Shawn C 
> Signed-off-by: William Tseng 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c  | 76 -
>  drivers/gpu/drm/i915/display/icl_dsi_regs.h | 13 
>  2 files changed, 86 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 19bf717fd4cb..edf20016af91 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -201,6 +201,75 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
>   return 0;
>  }
>  
> +static bool place_bta_request(struct intel_dsi_host *host)
> +{
> + struct intel_dsi *intel_dsi = host->intel_dsi;
> + struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
> + enum transcoder dsi_trans = dsi_port_to_transcoder(host->port);
> +
> + /* step2a(i): specify Turn-Around timeout */
> + intel_de_rmw(dev_priv, DSI_TA_TO(dsi_trans), TA_TIMEOUT_VALUE_MASK,
> +  TA_TIMEOUT_VALUE(intel_dsi->turn_arnd_val));
> +
> +  /* step2a(ii): specify maximum allowed time */
> + intel_de_rmw(dev_priv, DSI_LPRX_HOST_TO(dsi_trans), 
> ~LPRX_TIMEOUT_VALUE_MASK,
> +  LPRX_TIMEOUT_VALUE(intel_dsi->lp_rx_timeout));
> +
> + /* check if header credit available */
> + if (!wait_for_header_credits(dev_priv, dsi_trans, 1)) {
> + drm_err(&dev_priv->drm, "not ready to recive payload\n");
> + return false;
> + }
> +
> + /* place BTA request */
> + intel_de_rmw(dev_priv, DSI_LP_MSG(dsi_trans), LINK_BTA, LINK_BTA);
> +
> + return true;
> +}
> +
> +static int dsi_read_pkt_payld(struct intel_dsi_host *host,
> +   u8 *rx_buf, size_t rx_len)
> +{
> + struct intel_dsi *intel_dsi = host->intel_dsi;
> + struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
> + enum transcoder dsi_trans = dsi_port_to_transcoder(host->port);
> + u32 tmp, payld_data;
> + u32 payld_dw;
> + int i, j;
> +
> + if (rx_len <= 0)
> + return 0;
> +
> + /* do not unload receive queue */
> + tmp = intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans));
> + tmp &= ~READ_UNLOADS_DW;
> + intel_de_write(dev_priv, DSI_CMD_RXCTL(dsi_trans), tmp);
> +
> + /* step2: place a BTA request */
> + if (!place_bta_request(host))
> + return -EBUSY;
> +
> + /* step4a: wait and read payload */
> + if (wait_for_us(((intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans)) &
> + NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT) > 0, 
> 10)) {
> + drm_err(&dev_priv->drm, "DSI fails to receive payload\n");
> + return -EBUSY;
> + }
> +
> + tmp = intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans));
> + payld_dw = (tmp & NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT;
> +
> + for (i = 0; i < payld_dw; i++) {
> +
> + payld_data = intel_de_read(dev_priv, DSI_CMD_RXPYLD(dsi_trans));
> +
> + for (j = 0; j < min_t(u32, rx_len - (i * 4), 4); j++)
> + *(rx_buf + (i * 4 + j)) = (payld_data >> 8 * j) & 0xff;

Mmh, no matter what the hardware returns, you can't overflow rx_len in
rx_buf.

> + }
> +
> + return ((i - 1) * 4 + j);
> +}
> +
>  void icl_dsi_frame_update(str

Re: [Intel-gfx] [PATCH] drm/i915/dp: wait on timeout before retry

[Murthy, Arun R]

> On Mon, 27 Jun 2022, Arun R Murthy  wrote:
> > On linktraining error/timeout before retry need to wait for 400usec as
> > per the DP CTS spec1.2 The patch with commit id
> > 74ebf294a1dd816bdc248ac733009a8915d59eb5
> > drm/i915: Add a delay in Displayport AUX transactions for compliance
> > testing
> 
> Please reference other commits like this: commit 74ebf294a1dd
> ("drm/i915: Add a delay in Displayport AUX transactions for compliance
> testing")
> 
> I've got this git alias in my .gitconfig:
> 
>   cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e
> 's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"
> 
> And you can use 'git cite ' to give you the right format.
> 

Will correct this!

> > removes this delay mentioning the hardware already meets this
> > requirement, but as per the spec the delay mentioned in the spec
> > specifies how long to wait for the receiver response before timeout.
> > So the delay here to wait for timeout and not a delay after timeout.
> > The DP spec specifies a delay after timeout and hence adding this delay.
> 
> Please try to reflow commit messages to about 72 characters.
> 

Commit msg is maintained to be 72 char, but the patch details added might be 
misleading.
Will correct them!

> I had a bit of a hard time parsing the above, but basically you're saying that
> the hardware handles and flags the timeout, but the DP spec says we need to
> wait 400 us *after* the error condition. Makes sense, though I didn't have
> the time to read the specs to verify.
> 
> >
> > Signed-off-by: Arun R Murthy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
> >  1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > index 2bc119374555..a1fef1645d6a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > @@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> > /*
> >  * DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
> >  *   400us delay required for errors and timeouts
> > -*   Timeout errors from the HW already meet this
> > -*   requirement so skip to next iteration
> >  */
> > -   if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> > -   continue;
> > -
> > -   if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> > +   if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
> > +
>   DP_AUX_CH_CTL_TIME_OUT_ERROR)) {
> 
> Please check the indentation here. The DP_AUX_CH_* should start in the
> same column.
> 

Done!

Thanks and Regards,
Arun R Murthy

Re: [Intel-gfx] [PATCH] drm/i915/dp: wait on timeout before retry

[Jani Nikula]

On Mon, 27 Jun 2022, Arun R Murthy  wrote:
> On linktraining error/timeout before retry need to wait for 400usec as
> per the DP CTS spec1.2
> The patch with commit id
> 74ebf294a1dd816bdc248ac733009a8915d59eb5
> drm/i915: Add a delay in Displayport AUX transactions for
> compliance testing

Please reference other commits like this: commit 74ebf294a1dd
("drm/i915: Add a delay in Displayport AUX transactions for compliance
testing")

I've got this git alias in my .gitconfig:

cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e 
's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"

And you can use 'git cite ' to give you the right format.

> removes this delay mentioning the hardware already meets this
> requirement, but as per the spec the delay mentioned in the spec
> specifies how long to wait for the receiver response before timeout. So
> the delay here to wait for timeout and not a delay after timeout. The DP
> spec specifies a delay after timeout and hence adding this delay.

Please try to reflow commit messages to about 72 characters.

I had a bit of a hard time parsing the above, but basically you're
saying that the hardware handles and flags the timeout, but the DP spec
says we need to wait 400 us *after* the error condition. Makes sense,
though I didn't have the time to read the specs to verify.

>
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 2bc119374555..a1fef1645d6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -286,13 +286,9 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   /*
>* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
>*   400us delay required for errors and timeouts
> -  *   Timeout errors from the HW already meet this
> -  *   requirement so skip to next iteration
>*/
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> -
> - if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> + if (status & (DP_AUX_CH_CTL_RECEIVE_ERROR |
> + DP_AUX_CH_CTL_TIME_OUT_ERROR)) {

Please check the indentation here. The DP_AUX_CH_* should start in the
same column.

BR,
Jani.

>   usleep_range(400, 500);
>   continue;
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: switch DP, HDMI and LVDS to drm_edid

[Patchwork]

== Series Details ==

Series: drm/i915: switch DP, HDMI and LVDS to drm_edid
URL   : https://patchwork.freedesktop.org/series/105857/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11840 -> Patchwork_105857v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 43)
--

  Additional (3): fi-bxt-dsi fi-icl-u2 bat-dg2-9 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-icl-u2:  NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271]) +12 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][5] -> [INCOMPLETE][6] ([i915#4785])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#3576]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2:  NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-tgl-u2:  [PASS][12] -> [DMESG-WARN][13] ([i915#402])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html

  * igt@kms_flip@basic-plain-flip@a-edp1:
- fi-icl-u2:  NOTRUN -> [DMESG-WARN][14] ([i915#4890])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-icl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#4312] / 
[i915#5594] / [i915#6246])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-hsw-4770/igt@run...@aborted.html
- fi-icl-u2:  NOTRUN -> [FAIL][16] ([i915#3690] / [i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-icl-u2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [DMESG-WARN][17] ([i915#1888] / [i915#3576]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hugepages:
- fi-apl-guc: [DMESG-FAIL][19] -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/fi-apl-guc/igt@i915_selftest@l...@hugepages.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v1/fi-apl-guc/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-adlp-6}:   [DMESG-FAIL][21] ([i915#4983]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11840/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105857v

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Nuke PCH_JSP

[Jani Nikula]

On Thu, 30 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> JSP is based on ICP and we don't really need to differentiate
> between the two. So let's just delcare JSP to be ICP.
>
> The only slight change here is for Wa_14011294188 which we
> used to apply for JSP but now we'll only apply to MCC. This
> should be fine since the issue being dealt with was introduced
> in TGP and inherited into MCC. JSP being derived from ICP
> should not need this workaround.

I'll take your word for it.

Reviewed-by: Jani Nikula 


>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>  drivers/gpu/drm/i915/intel_pch.c   | 3 ++-
>  drivers/gpu/drm/i915/intel_pch.h   | 4 +---
>  3 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index a9cb27f1c964..589af257edeb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1608,7 +1608,7 @@ static void icl_display_core_init(struct 
> drm_i915_private *dev_priv,
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  
>   /* Wa_14011294188:ehl,jsl,tgl,rkl,adl-s */
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_JSP &&
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP &&
>   INTEL_PCH_TYPE(dev_priv) < PCH_DG1)
>   intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D, 0,
>PCH_DPMGUNIT_CLOCK_GATE_DISABLE);
> diff --git a/drivers/gpu/drm/i915/intel_pch.c 
> b/drivers/gpu/drm/i915/intel_pch.c
> index b45c504c6f03..0fec25be146a 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -128,7 +128,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
> unsigned short id)
>   case INTEL_PCH_JSP_DEVICE_ID_TYPE:
>   drm_dbg_kms(&dev_priv->drm, "Found Jasper Lake PCH\n");
>   drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
> - return PCH_JSP;
> + /* JSP is ICP compatible */
> + return PCH_ICP;
>   case INTEL_PCH_ADP_DEVICE_ID_TYPE:
>   case INTEL_PCH_ADP2_DEVICE_ID_TYPE:
>   case INTEL_PCH_ADP3_DEVICE_ID_TYPE:
> diff --git a/drivers/gpu/drm/i915/intel_pch.h 
> b/drivers/gpu/drm/i915/intel_pch.h
> index 07f6f5517968..7c8ce9781d1a 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -22,8 +22,7 @@ enum intel_pch {
>   PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
>   PCH_SPT,/* Sunrisepoint/Kaby Lake PCH */
>   PCH_CNP,/* Cannon/Comet Lake PCH */
> - PCH_ICP,/* Ice Lake PCH */
> - PCH_JSP,/* Jasper Lake PCH */
> + PCH_ICP,/* Ice Lake/Jasper Lake PCH */
>   PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
>   PCH_ADP,/* Alder Lake PCH */
>  
> @@ -67,7 +66,6 @@ enum intel_pch {
>  #define HAS_PCH_DG2(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG2)
>  #define HAS_PCH_ADP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
>  #define HAS_PCH_DG1(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
> -#define HAS_PCH_JSP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_JSP)
>  #define HAS_PCH_TGP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_TGP)
>  #define HAS_PCH_ICP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
>  #define HAS_PCH_CNP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke PCH_MCC

[Jani Nikula]

On Thu, 30 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> MCC is derived from TGP, and we have no real need to
> differentiate between the two. Thus remove PCH_MCC and
> just declare it to be PCH_TGP compatible.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
>  drivers/gpu/drm/i915/intel_pch.c  | 3 ++-
>  drivers/gpu/drm/i915/intel_pch.h  | 4 +---
>  4 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 272e1bf6006b..2330604b0bcc 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4179,7 +4179,7 @@ static enum hpd_pin ehl_hpd_pin(struct drm_i915_private 
> *dev_priv,
>   if (port == PORT_D)
>   return HPD_PORT_A;
>  
> - if (HAS_PCH_MCC(dev_priv))
> + if (HAS_PCH_TGP(dev_priv))
>   return icl_hpd_pin(dev_priv, port);
>  
>   return HPD_PORT_A + port - PORT_A;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 1ae09431f53a..ebd91aa69dd2 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2852,7 +2852,7 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder 
> *encoder)
>   ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
>   else if (DISPLAY_VER(dev_priv) == 9 && HAS_PCH_TGP(dev_priv))
>   ddc_pin = gen9bc_tgp_port_to_ddc_pin(dev_priv, port);
> - else if (HAS_PCH_MCC(dev_priv))
> + else if (IS_JSL_EHL(dev_priv) && HAS_PCH_TGP(dev_priv))
>   ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);

Nitpick, mcc_ prefix is now an outlier here, and could be named after
the CPU/PCH combo like above for gen 9 and TGP. But no big deal.

Reviewed-by: Jani Nikula 



>   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>   ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/intel_pch.c 
> b/drivers/gpu/drm/i915/intel_pch.c
> index 94446cac6605..b45c504c6f03 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -116,7 +116,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
> unsigned short id)
>   case INTEL_PCH_MCC_DEVICE_ID_TYPE:
>   drm_dbg_kms(&dev_priv->drm, "Found Mule Creek Canyon PCH\n");
>   drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
> - return PCH_MCC;
> + /* MCC is TGP compatible */
> + return PCH_TGP;
>   case INTEL_PCH_TGP_DEVICE_ID_TYPE:
>   case INTEL_PCH_TGP2_DEVICE_ID_TYPE:
>   drm_dbg_kms(&dev_priv->drm, "Found Tiger Lake LP PCH\n");
> diff --git a/drivers/gpu/drm/i915/intel_pch.h 
> b/drivers/gpu/drm/i915/intel_pch.h
> index b7a8cf409d48..07f6f5517968 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -24,8 +24,7 @@ enum intel_pch {
>   PCH_CNP,/* Cannon/Comet Lake PCH */
>   PCH_ICP,/* Ice Lake PCH */
>   PCH_JSP,/* Jasper Lake PCH */
> - PCH_MCC,/* Mule Creek Canyon PCH */
> - PCH_TGP,/* Tiger Lake PCH */
> + PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
>   PCH_ADP,/* Alder Lake PCH */
>  
>   /* Fake PCHs, functionality handled on the same PCI dev */
> @@ -69,7 +68,6 @@ enum intel_pch {
>  #define HAS_PCH_ADP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
>  #define HAS_PCH_DG1(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
>  #define HAS_PCH_JSP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_JSP)
> -#define HAS_PCH_MCC(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_MCC)
>  #define HAS_PCH_TGP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_TGP)
>  #define HAS_PCH_ICP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
>  #define HAS_PCH_CNP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use short PCH names consistently

[Jani Nikula]

On Thu, 30 Jun 2022, Ville Syrjälä  wrote:
> On Thu, Jun 30, 2022 at 03:50:15PM +, Murthy, Arun R wrote:
>> > From: Ville Syrjälä 
>> > 
>> > The comments regarding PCH compatibility use long vs.
>> > short names inconsistently. Just use short names always.
>> > 
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/intel_pch.c | 10 +-
>> >  1 file changed, 5 insertions(+), 5 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_pch.c
>> > b/drivers/gpu/drm/i915/intel_pch.c
>> > index e2b2bbdc0714..94446cac6605 100644
>> > --- a/drivers/gpu/drm/i915/intel_pch.c
>> > +++ b/drivers/gpu/drm/i915/intel_pch.c
>> > @@ -25,7 +25,7 @@ intel_pch_type(const struct drm_i915_private
>> > *dev_priv, unsigned short id)
>> >drm_dbg_kms(&dev_priv->drm, "Found PantherPoint
>> > PCH\n");
>> >drm_WARN_ON(&dev_priv->drm,
>> >GRAPHICS_VER(dev_priv) != 6 &&
>> > !IS_IVYBRIDGE(dev_priv));
>> > -  /* PantherPoint is CPT compatible */
>> > +  /* PPT is CPT compatible */
>> 
>> 
>> This is not the code but only comment, I feel elaborated names makes it more 
>> readable than abbreviation.
>
> We rarely type out the full names for anything.

And we still keep debug logging the full names right there.

Reviewed-by: Jani Nikula 


-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: PCH type cleanup

[Patchwork]

== Series Details ==

Series: drm/i915: PCH type cleanup
URL   : https://patchwork.freedesktop.org/series/105822/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11834_full -> Patchwork_105822v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_create@create-ext-cpu-access-sanity-check:
- {shard-rkl}:NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-rkl-1/igt@gem_cre...@create-ext-cpu-access-sanity-check.html

  

### Piglit changes ###

 Possible regressions 

  * spec@!opengl 1.5@normal3b3s-invariance-short:
- pig-glk-j5005:  NOTRUN -> [INCOMPLETE][2]
   [2]: None

  * spec@ext_framebuffer_multisample@interpolation 0 non-centroid-disabled:
- pig-kbl-iris:   NOTRUN -> [CRASH][3]
   [3]: None

  * spec@glsl-1.50@execution@built-in-functions@gs-op-assign-bitxor-ivec4-ivec4:
- pig-skl-6260u:  NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/pig-skl-6260u/spec@glsl-1.50@execution@built-in-functi...@gs-op-assign-bitxor-ivec4-ivec4.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-persistence.html

  * igt@gem_ctx_persistence@smoketest:
- shard-glk:  [PASS][6] -> [INCOMPLETE][7] ([i915#6310]) +2 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-glk1/igt@gem_ctx_persiste...@smoketest.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-glk5/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-iclb6/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-iclb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#4525])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-iclb8/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-iclb6/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-kbl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-kbl4/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-multi.html
- shard-glk:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-glk7/igt@gem_lmem_swapp...@heavy-verify-multi.html
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-iclb8/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_pxp@create-protected-buffer:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105822v1/shard-iclb8/igt@gem_...@create-protected-buffer.html

  * igt@gem_pxp

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: switch DP, HDMI and LVDS to drm_edid

[Patchwork]

== Series Details ==

Series: drm/i915: switch DP, HDMI and LVDS to drm_edid
URL   : https://patchwork.freedesktop.org/series/105857/
State : warning

== Summary ==

Error: dim checkpatch failed
4db4abe80683 drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
-:281: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "drm_edid"
#281: FILE: drivers/gpu/drm/i915/display/intel_hdmi.c:2431:
+   intel_hdmi_dp_dual_mode_detect(connector, drm_edid != NULL);

total: 0 errors, 0 warnings, 1 checks, 316 lines checked
8ca9c1cc58de drm/i915/bios: convert intel_bios_init_panel() to drm_edid

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid

[Jani Nikula]

On Fri, 01 Jul 2022, Jani Nikula  wrote:
> Convert all the connectors that use cached connector edid and
> detect_edid to drm_edid.
>
> Since drm_get_edid() calls drm_connector_update_edid_property() while
> drm_edid_read*() do not, we need to call drm_edid_connector_update()
> separately, in part due to the EDID caching behaviour in HDMI and
> DP. Especially DP depends on the details parsed from EDID. (The big
> behavioural change conflating EDID reading with parsing and property
> update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
> drm_connector"))
>
> v4: Call drm_edid_connector_update() after reading HDMI/DP EDID

v3 was Reviewed-by: Ville. I did mean to include the R-b here, but just
as well that I didn't because of this change. Also amended the commit
message around this. This might also explain some of the earlier CI
results.

BR,
Jani.

>
> v3: Don't leak vga switcheroo EDID in LVDS init (Ville)
>
> v2: Don't leak opregion fallback EDID (Ville)
>
> Signed-off-by: Jani Nikula 
> ---
>  .../gpu/drm/i915/display/intel_connector.c|  4 +-
>  .../drm/i915/display/intel_display_types.h|  4 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 80 +++
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
>  drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
>  5 files changed, 87 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 1dcc268927a2..d83b2a64f618 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector 
> *connector)
>  {
>   struct intel_connector *intel_connector = to_intel_connector(connector);
>  
> - kfree(intel_connector->detect_edid);
> + drm_edid_free(intel_connector->detect_edid);
>  
>   intel_hdcp_cleanup(intel_connector);
>  
>   if (!IS_ERR_OR_NULL(intel_connector->edid))
> - kfree(intel_connector->edid);
> + drm_edid_free(intel_connector->edid);
>  
>   intel_panel_fini(intel_connector);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0da9b208d56e..d476df0ac9df 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -592,8 +592,8 @@ struct intel_connector {
>   struct intel_panel panel;
>  
>   /* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
> - struct edid *edid;
> - struct edid *detect_edid;
> + const struct drm_edid *edid;
> + const struct drm_edid *detect_edid;
>  
>   /* Number of times hotplug detection was tried after an HPD interrupt */
>   int hotplug_retries;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 32292c0be2bd..8a3b2dbebe04 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3577,12 +3577,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp 
> *intel_dp)
>   intel_dp->aux.i2c_defer_count);
>   intel_dp->compliance.test_data.edid = 
> INTEL_DP_RESOLUTION_FAILSAFE;
>   } else {
> - struct edid *block = intel_connector->detect_edid;
> + /* FIXME: Get rid of drm_edid_raw() */
> + const struct edid *block = 
> drm_edid_raw(intel_connector->detect_edid);
>  
> - /* We have to write the checksum
> -  * of the last block read
> -  */
> - block += intel_connector->detect_edid->extensions;
> + /* We have to write the checksum of the last block read */
> + block += block->extensions;
>  
>   if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_EDID_CHECKSUM,
>  block->checksum) <= 0)
> @@ -4461,7 +4460,7 @@ bool intel_digital_port_connected(struct intel_encoder 
> *encoder)
>   return is_connected;
>  }
>  
> -static struct edid *
> +static const struct drm_edid *
>  intel_dp_get_edid(struct intel_dp *intel_dp)
>  {
>   struct intel_connector *intel_connector = intel_dp->attached_connector;
> @@ -4472,18 +4471,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
>   if (IS_ERR(intel_connector->edid))
>   return NULL;
>  
> - return drm_edid_duplicate(intel_connector->edid);
> + return drm_edid_dup(intel_connector->edid);
>   } else
> - return drm_get_edid(&intel_connector->base,
> - &intel_dp->aux.ddc);
> + return drm_edid_read_ddc(&intel_connector->base,
> +  &intel_dp->aux.ddc);
>  }
>  
>  static void
>  intel_dp_update_dfp(struct intel_dp *intel_dp,
> -

[Intel-gfx] [PATCH v4 2/2] drm/i915/bios: convert intel_bios_init_panel() to drm_edid

[Jani Nikula]

Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().

v2: Rebase

Signed-off-by: Jani Nikula 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 19 ++-
 drivers/gpu/drm/i915/display/intel_bios.h |  4 ++--
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
 4 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 51dde5bfd956..2fa296d8e69d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -606,14 +606,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
 
 static int opregion_get_panel_type(struct drm_i915_private *i915,
   const struct intel_bios_encoder_data 
*devdata,
-  const struct edid *edid)
+  const struct drm_edid *drm_edid)
 {
return intel_opregion_get_panel_type(i915);
 }
 
 static int vbt_get_panel_type(struct drm_i915_private *i915,
  const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
 {
const struct bdb_lvds_options *lvds_options;
 
@@ -638,12 +638,13 @@ static int vbt_get_panel_type(struct drm_i915_private 
*i915,
 
 static int pnpid_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
-   const struct edid *edid)
+   const struct drm_edid *drm_edid)
 {
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
const struct lvds_pnp_id *edid_id;
struct lvds_pnp_id edid_id_nodate;
+   const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
int i, best = -1;
 
if (!edid)
@@ -685,7 +686,7 @@ static int pnpid_get_panel_type(struct drm_i915_private 
*i915,
 
 static int fallback_get_panel_type(struct drm_i915_private *i915,
   const struct intel_bios_encoder_data 
*devdata,
-  const struct edid *edid)
+  const struct drm_edid *drm_edid)
 {
return 0;
 }
@@ -699,13 +700,13 @@ enum panel_type {
 
 static int get_panel_type(struct drm_i915_private *i915,
  const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
 {
struct {
const char *name;
int (*get_panel_type)(struct drm_i915_private *i915,
  const struct intel_bios_encoder_data 
*devdata,
- const struct edid *edid);
+ const struct drm_edid *drm_edid);
int panel_type;
} panel_types[] = {
[PANEL_TYPE_OPREGION] = {
@@ -728,7 +729,7 @@ static int get_panel_type(struct drm_i915_private *i915,
int i;
 
for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
-   panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
devdata, edid);
+   panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
devdata, drm_edid);
 
drm_WARN_ON(&i915->drm, panel_types[i].panel_type > 0xf &&
panel_types[i].panel_type != 0xff);
@@ -3144,11 +3145,11 @@ void intel_bios_init(struct drm_i915_private *i915)
 void intel_bios_init_panel(struct drm_i915_private *i915,
   struct intel_panel *panel,
   const struct intel_bios_encoder_data *devdata,
-  const struct edid *edid)
+  const struct drm_edid *drm_edid)
 {
init_vbt_panel_defaults(panel);
 
-   panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
+   panel->vbt.panel_type = get_panel_type(i915, devdata, drm_edid);
 
parse_panel_options(i915, panel);
parse_generic_dtd(i915, panel);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index e47582b0de0a..defea578a768 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -32,8 +32,8 @@
 
 #include 
 
+struct drm_edid;
 struct drm_i915_private;
-struct edid;
 struct intel_bios_encoder_data;
 struct intel_crtc_state;
 struct intel_encoder;
@@ -235,7 +235,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv);
 void intel_bios_init_panel(struct drm_i915_private *dev_priv,
   struct intel_panel *panel,
   const struct int

[Intel-gfx] [PATCH v4 0/2] drm/i915: switch DP, HDMI and LVDS to drm_edid

[Jani Nikula]

The remaining patches to add HF-EEODB support to i915 by switching to
using drm_edid in certain encoders. This depends on the drm_edid work in
drm-misc-next, and either needs to be merged via drm-misc-next, or we'll
need the dependencies merged to drm-intel-next via drm-misc-next pull
request -> drm-next -> backmerge.

Jani Nikula (2):
  drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
  drm/i915/bios: convert intel_bios_init_panel() to drm_edid

 drivers/gpu/drm/i915/display/intel_bios.c | 19 ++---
 drivers/gpu/drm/i915/display/intel_bios.h |  4 +-
 .../gpu/drm/i915/display/intel_connector.c|  4 +-
 .../drm/i915/display/intel_display_types.h|  4 +-
 drivers/gpu/drm/i915/display/intel_dp.c   | 80 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
 drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
 7 files changed, 99 insertions(+), 77 deletions(-)

-- 
2.30.2

[Intel-gfx] [PATCH v4 1/2] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid

[Jani Nikula]

Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.

Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Especially DP depends on the details parsed from EDID. (The big
behavioural change conflating EDID reading with parsing and property
update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector"))

v4: Call drm_edid_connector_update() after reading HDMI/DP EDID

v3: Don't leak vga switcheroo EDID in LVDS init (Ville)

v2: Don't leak opregion fallback EDID (Ville)

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_connector.c|  4 +-
 .../drm/i915/display/intel_display_types.h|  4 +-
 drivers/gpu/drm/i915/display/intel_dp.c   | 80 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
 drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
 5 files changed, 87 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index 1dcc268927a2..d83b2a64f618 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector 
*connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
 
-   kfree(intel_connector->detect_edid);
+   drm_edid_free(intel_connector->detect_edid);
 
intel_hdcp_cleanup(intel_connector);
 
if (!IS_ERR_OR_NULL(intel_connector->edid))
-   kfree(intel_connector->edid);
+   drm_edid_free(intel_connector->edid);
 
intel_panel_fini(intel_connector);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..d476df0ac9df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -592,8 +592,8 @@ struct intel_connector {
struct intel_panel panel;
 
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
-   struct edid *edid;
-   struct edid *detect_edid;
+   const struct drm_edid *edid;
+   const struct drm_edid *detect_edid;
 
/* Number of times hotplug detection was tried after an HPD interrupt */
int hotplug_retries;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 32292c0be2bd..8a3b2dbebe04 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3577,12 +3577,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid = 
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
-   struct edid *block = intel_connector->detect_edid;
+   /* FIXME: Get rid of drm_edid_raw() */
+   const struct edid *block = 
drm_edid_raw(intel_connector->detect_edid);
 
-   /* We have to write the checksum
-* of the last block read
-*/
-   block += intel_connector->detect_edid->extensions;
+   /* We have to write the checksum of the last block read */
+   block += block->extensions;
 
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_EDID_CHECKSUM,
   block->checksum) <= 0)
@@ -4461,7 +4460,7 @@ bool intel_digital_port_connected(struct intel_encoder 
*encoder)
return is_connected;
 }
 
-static struct edid *
+static const struct drm_edid *
 intel_dp_get_edid(struct intel_dp *intel_dp)
 {
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -4472,18 +4471,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
if (IS_ERR(intel_connector->edid))
return NULL;
 
-   return drm_edid_duplicate(intel_connector->edid);
+   return drm_edid_dup(intel_connector->edid);
} else
-   return drm_get_edid(&intel_connector->base,
-   &intel_dp->aux.ddc);
+   return drm_edid_read_ddc(&intel_connector->base,
+&intel_dp->aux.ddc);
 }
 
 static void
 intel_dp_update_dfp(struct intel_dp *intel_dp,
-   const struct edid *edid)
+   const struct drm_edid *drm_edid)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
+   const struct edid *edid;
+
+   /* FIXME: Get rid of drm_edid_raw() */
+   edid = drm_edid_raw(drm_edid);
 
intel_dp->dfp.max_bpc =
drm_dp

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: stop HPD workers before display driver unregister (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: stop HPD workers before display driver unregister 
(rev2)
URL   : https://patchwork.freedesktop.org/series/105557/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11834_full -> Patchwork_105557v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 12)
--

  Missing(1): pig-glk-j5005 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/shard-skl1/igt@kms_cursor_legacy@cursor-vs-f...@atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor@varying-size:
- shard-iclb: [PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-iclb6/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html

  * igt@perf@non-zero-reason:
- shard-kbl:  [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-kbl7/igt@p...@non-zero-reason.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/shard-kbl6/igt@p...@non-zero-reason.html

  
 Suppressed 

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

  * igt@gem_create@create-ext-cpu-access-sanity-check:
- {shard-rkl}:NOTRUN -> [SKIP][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/shard-rkl-1/igt@gem_cre...@create-ext-cpu-access-sanity-check.html

  

### Piglit changes ###

 Possible regressions 

  * spec@arb_texture_multisample@texelfetch@16-vs-isampler2dmsarray:
- pig-kbl-iris:   NOTRUN -> [CRASH][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/pig-kbl-iris/spec@arb_texture_multisample@texelfe...@16-vs-isampler2dmsarray.html

  * spec@glsl-1.30@execution@texelfetch@fs-texelfetch-sampler2darray-swizzle:
- pig-skl-6260u:  NOTRUN -> [INCOMPLETE][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/pig-skl-6260u/spec@glsl-1.30@execution@texelfe...@fs-texelfetch-sampler2darray-swizzle.html

  
New tests
-

  New tests have been introduced between CI_DRM_11834_full and 
Patchwork_105557v2_full:

### New IGT tests (13) ###

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.28] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.18] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.17] s

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.20] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.19] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.19] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.21] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.19] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.20] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#6268])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-tglb5/igt@gem_ctx_e...@basic-nohangcheck.

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

[Matthew Auld]

On 30/06/2022 17:23, Matthew Auld wrote:

On 30/06/2022 16:34, Jason Ekstrand wrote:
On Thu, Jun 30, 2022 at 10:14 AM Matthew Auld > wrote:


    On 30/06/2022 06:11, Jason Ekstrand wrote:
 > On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura
 > mailto:niranjana.vishwanathap...@intel.com>
 > >> wrote:
 >
 >     VM_BIND and related uapi definitions
 >
 >     v2: Reduce the scope to simple Mesa use case.
 >     v3: Expand VM_UNBIND documentation and add
 >          I915_GEM_VM_BIND/UNBIND_FENCE_VALID
 >          and I915_GEM_VM_BIND_TLB_FLUSH flags.
 >     v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
 >          documentation for vm_bind/unbind.
 >     v5: Remove TLB flush requirement on VM_UNBIND.
 >          Add version support to stage implementation.
 >     v6: Define and use drm_i915_gem_timeline_fence structure for
 >          all timeline fences.
 >     v7: Rename I915_PARAM_HAS_VM_BIND to 
I915_PARAM_VM_BIND_VERSION.
 >          Update documentation on async vm_bind/unbind and 
versioning.
 >          Remove redundant vm_bind/unbind FENCE_VALID flag, 
execbuf3

 >          batch_count field and I915_EXEC3_SECURE flag.
 >
 >     Signed-off-by: Niranjana Vishwanathapura
 >     mailto:niranjana.vishwanathap...@intel.com>
 >     >>
 >     Reviewed-by: Daniel Vetter mailto:daniel.vet...@ffwll.ch>
 >     >>

 >     ---
 >       Documentation/gpu/rfc/i915_vm_bind.h | 280
    +++
 >       1 file changed, 280 insertions(+)
 >       create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
 >
 >     diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
 >     b/Documentation/gpu/rfc/i915_vm_bind.h
 >     new file mode 100644
 >     index ..a93e08bceee6
 >     --- /dev/null
 >     +++ b/Documentation/gpu/rfc/i915_vm_bind.h
 >     @@ -0,0 +1,280 @@
 >     +/* SPDX-License-Identifier: MIT */
 >     +/*
 >     + * Copyright © 2022 Intel Corporation
 >     + */
 >     +
 >     +/**
 >     + * DOC: I915_PARAM_VM_BIND_VERSION
 >     + *
 >     + * VM_BIND feature version supported.
 >     + * See typedef drm_i915_getparam_t param.
 >     + *
 >     + * Specifies the VM_BIND feature version supported.
 >     + * The following versions of VM_BIND have been defined:
 >     + *
 >     + * 0: No VM_BIND support.
 >     + *
 >     + * 1: In VM_UNBIND calls, the UMD must specify the exact
    mappings
 >     created
 >     + *    previously with VM_BIND, the ioctl will not support
    unbinding
 >     multiple
 >     + *    mappings or splitting them. Similarly, VM_BIND calls
    will not
 >     replace
 >     + *    any existing mappings.
 >     + *
 >     + * 2: The restrictions on unbinding partial or multiple
    mappings is
 >     + *    lifted, Similarly, binding will replace any mappings
    in the
 >     given range.
 >     + *
 >     + * See struct drm_i915_gem_vm_bind and struct
    drm_i915_gem_vm_unbind.
 >     + */
 >     +#define I915_PARAM_VM_BIND_VERSION     57
 >     +
 >     +/**
 >     + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
 >     + *
 >     + * Flag to opt-in for VM_BIND mode of binding during VM
    creation.
 >     + * See struct drm_i915_gem_vm_control flags.
 >     + *
 >     + * The older execbuf2 ioctl will not support VM_BIND mode of
    operation.
 >     + * For VM_BIND mode, we have new execbuf3 ioctl which will 
not

 >     accept any
 >     + * execlist (See struct drm_i915_gem_execbuffer3 for more
    details).
 >     + */
 >     +#define I915_VM_CREATE_FLAGS_USE_VM_BIND       (1 << 0)
 >     +
 >     +/* VM_BIND related ioctls */
 >     +#define DRM_I915_GEM_VM_BIND           0x3d
 >     +#define DRM_I915_GEM_VM_UNBIND         0x3e
 >     +#define DRM_I915_GEM_EXECBUFFER3       0x3f
 >     +
 >     +#define DRM_IOCTL_I915_GEM_VM_BIND
 >       DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct
 >     drm_i915_gem_vm_bind)
 >     +#define DRM_IOCTL_I915_GEM_VM_UNBIND
 >       DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
 >     drm_i915_gem_vm_bind)
 >     +#define DRM_IOCTL_I915_GEM_EXECBUFFER3
 >       DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct
 >     drm_i915_gem_execbuffer3)
 >     +
 >     +/**
 >     + * struct drm_i915_gem_timeline_fence - An input or output
    timeline
 >     fence.
 >     + *
 >     + * The operat

Re: [Intel-gfx] [PATCH] drm/i915: Fix NPD in PMU during driver teardown

[Tvrtko Ursulin]

On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:

On Thu, Jun 30, 2022 at 09:00:28PM +, Stuart Summers wrote:

In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.

Fix this ordering in both the driver load and unload sequences.

Additionally add a check for engine presence to prevent this
NPD in the event this ordering is accidentally reversed. Print
a debug message indicating when they aren't available.

v1: Actually address the driver load/unload ordering issue

Signed-off-by: Stuart Summers 
---


I thought this is likely happening because intel_gpu_top is running in 
the background when i915 is unloaded. I tried a quick repro, I don't see 
the unload succeed ("fatal module in use", not sure if this was a 
partial unload), but when I try to kill intel_gpu_top, I get an NPD. 
This is in the event disable path - i915_pmu_event_stop -> 
i915_pmu_disable.


So i915 failed to unload (as expected - with perf events open we elevate 
the module ref count via i915_pmu_event_init -> drm_dev_get), then you 
quit intel_gpu_top and get NPD? On the engine lookup? With the 
re-ordered init/fini sequence as from this patch?


With elevated module count there shouldn't be any unloading happening so 
I am intrigued.


It's likely that you are seeing a different path (unload) leading to the 
same issue.


I think in i915_pmu_disable/disable should be aware of event->hw.state 
and or pmu->closed states before accessing the event. Maybe like,


if (event->hw.state != PERF_HES_STOPPED && is_engine_event(event)) {

@Tvrtko, wondering if this case is tested by igt@perf_pmu@module-unload. 


A bit yes. From what Stuart wrote it seems the test would need to be 
extended to cover the case where PMU is getting opened while module 
unload is in progress.


But the NPD you saw is for the moment confusing so I don't know what is 
happening.


I am not clear if we should use event->hw.state or pmu->closed here and 
if/how they are related. IMO, for this issue, the engine check is good 
enough too, so we don't really need the pmu state checks.  Thoughts?


Engine check at the moment feels like papering.

Indeed as you say I think the pmu->closed might be the solution. Perhaps 
the race is as mentioned above. PMU open happening in parallel to unload..


If the sequence of events userspace triggers is:

  i915_pmu_event_init
  i915_pmu_event_start
  i915_pmu_enable
  i915_pmu_event_read

I guess pmu->closed can get set halfway in i915_pmu_event_init. What 
would be the effect of that.. We'd try to get a module reference while 
in the process of unloading. Which is probably very bad.. So possibly a 
final check on pmu->close is needed there. Ho hum.. can it be made safe 
is the question.


It doesn't explain the NPD on Ctrl-C though.. intel_gpu_top keeps the 
evens open all the time. So I think more info needed, for me at least.


Regards,

Tvrtko



Regards,
Umesh


drivers/gpu/drm/i915/i915_driver.c | 11 ++---
drivers/gpu/drm/i915/i915_pmu.c    | 72 +-
2 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c

index deb8a8b76965..ee4dcb85d206 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)

struct drm_device *dev = &dev_priv->drm;

i915_gem_driver_register(dev_priv);
-    i915_pmu_register(dev_priv);

intel_vgpu_register(dev_priv);

@@ -731,11 +730,12 @@ static void i915_driver_register(struct 
drm_i915_private *dev_priv)

i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);

+    intel_gt_driver_register(to_gt(dev_priv));
+
/* Depends on sysfs having been initialized */
+    i915_pmu_register(dev_priv);
i915_perf_register(dev_priv);

-    intel_gt_driver_register(to_gt(dev_priv));
-
intel_display_driver_register(dev_priv);

intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)


intel_display_driver_unregister(dev_priv);

-    intel_gt_driver_unregister(to_gt(dev_priv));
-
i915_perf_unregister(dev_priv);
+    /* GT should be available until PMU is gone */
i915_pmu_unregister(dev_priv);

+    intel_gt_driver_unregister(to_gt(dev_priv));
+
i915_teardown_sysfs(dev_priv);
drm_dev_unplug(&dev_priv->drm);

diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
b/drivers/gpu/drm/i915/i915_pmu.c

index 958b37123bf1..796a1d8e36f2 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -670,21 +670,28 @@ static void i915_pmu_enable(struct perf_event 
*event)

if (is_engi

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction

[Matthew Auld]

On Mon, 20 Jun 2022 at 13:37, Thomas Hellström
 wrote:
>
> In vma destruction, the following race may occur:
>
> Thread 1: Thread 2:
> i915_vma_destroy();
>
>   ...
>   list_del_init(vma->vm_link);
>   ...
>   mutex_unlock(vma->vm->mutex);
>   __i915_vm_release();
> release_references();
>
> And in release_reference() we dereference vma->vm to get to the
> vm gt pointer, leading to a use-after free.
>
> However, __i915_vm_release() grabs the vm->mutex so the vm won't be
> destroyed before vma->vm->mutex is released, so extract the gt pointer
> under the vm->mutex to avoid the vma->vm dereference in
> release_references().
>
> v2: Fix a typo in the commit message (Andi Shyti)
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
> Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")
>
> Cc: Niranjana Vishwanathapura 
> Cc: Matthew Auld 
> Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 

Re: [Intel-gfx] [PATCH v6 3/3] drm/doc/rfc: VM_BIND uapi definition

[Tvrtko Ursulin]

On 30/06/2022 17:22, Niranjana Vishwanathapura wrote:

On Thu, Jun 30, 2022 at 08:59:09AM +0100, Tvrtko Ursulin wrote:


On 30/06/2022 07:08, Niranjana Vishwanathapura wrote:

On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:

On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
    I915_GEM_VM_BIND/UNBIND_FENCE_VALID
    and I915_GEM_VM_BIND_TLB_FLUSH flags.
v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
    documentation for vm_bind/unbind.
v5: Remove TLB flush requirement on VM_UNBIND.
    Add version support to stage implementation.
v6: Define and use drm_i915_gem_timeline_fence structure for
    all timeline fences.
v7: Rename I915_PARAM_HAS_VM_BIND to I915_PARAM_VM_BIND_VERSION.
    Update documentation on async vm_bind/unbind and versioning.
    Remove redundant vm_bind/unbind FENCE_VALID flag, execbuf3
    batch_count field and I915_EXEC3_SECURE flag.

Signed-off-by: Niranjana Vishwanathapura 


Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/rfc/i915_vm_bind.h | 280 
+++

 1 file changed, 280 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h

new file mode 100644
index ..a93e08bceee6
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_VM_BIND_VERSION
+ *
+ * VM_BIND feature version supported.
+ * See typedef drm_i915_getparam_t param.
+ *
+ * Specifies the VM_BIND feature version supported.
+ * The following versions of VM_BIND have been defined:
+ *
+ * 0: No VM_BIND support.
+ *
+ * 1: In VM_UNBIND calls, the UMD must specify the exact mappings 
created
+ *    previously with VM_BIND, the ioctl will not support 
unbinding multiple
+ *    mappings or splitting them. Similarly, VM_BIND calls will 
not replace

+ *    any existing mappings.
+ *
+ * 2: The restrictions on unbinding partial or multiple mappings is
+ *    lifted, Similarly, binding will replace any mappings in the 
given range.

+ *
+ * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
+ */
+#define I915_PARAM_VM_BIND_VERSION   57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of 
operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not 
accept any

+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND   0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)

+
+/**
+ * struct drm_i915_gem_timeline_fence - An input or output 
timeline fence.

+ *
+ * The operation will wait for input fence to signal.
+ *
+ * The returned output fence will be signaled after the completion 
of the

+ * operation.
+ */
+struct drm_i915_gem_timeline_fence {
+ /** @handle: User's handle for a drm_syncobj to wait on or 
signal. */

+ __u32 handle;
+
+ /**
+  * @flags: Supported flags are:
+  *
+  * I915_TIMELINE_FENCE_WAIT:
+  * Wait for the input fence before the operation.
+  *
+  * I915_TIMELINE_FENCE_SIGNAL:
+  * Return operation completion fence as output.
+  */
+ __u32 flags;
+#define I915_TIMELINE_FENCE_WAIT    (1 << 0)
+#define I915_TIMELINE_FENCE_SIGNAL  (1 << 1)
+#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS 
(-(I915_TIMELINE_FENCE_SIGNAL << 1))

+
+ /**
+  * @value: A point in the timeline.
+  * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+  * timeline drm_syncobj is invalid as it turns a drm_syncobj 
into a

+  * binary one.
+  */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the 
mapping of GPU
+ * virtual address (VA) range to the section of an object that 
should be bound

+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently 
bound) and can
+ * be mapped to whole object or a section of the object (partial 
binding).
+ * Multiple VA mappings can be cre

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Serialize GRDOM access between multiple engine resets

[Tvrtko Ursulin]

On 30/06/2022 17:01, Mauro Carvalho Chehab wrote:

Em Thu, 30 Jun 2022 09:12:41 +0100
Tvrtko Ursulin  escreveu:


On 30/06/2022 08:32, Mauro Carvalho Chehab wrote:

Em Wed, 29 Jun 2022 17:02:59 +0100
Tvrtko Ursulin  escreveu:
   

On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:

On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin  wrote:
  

.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.

Then we have the current patch 2 which is open/unknown (to me at least).

And the rest seem like optimisations which shouldn't be tagged as fixes.

Apart from patch 5 which should be cc: stable, but no fixes as agreed.

Could you please double check if what I am suggesting here is feasible
to implement and if it is just send those minimal patches out alone?


Tested and porting just those 3 patches are enough to fix the Broadwell
bug.

So, I submitted a v2 of this series with just those. They all need to
be backported to stable.


I would really like to give even a smaller fix a try. Something like, although 
not even compile tested:

commit 4d5e94aef164772f4d85b3b4c1a46eac9a2bd680
Author: Chris Wilson 
Date:   Wed Jun 29 16:25:24 2022 +0100

   drm/i915/gt: Serialize TLB invalidates with GT resets
   
   Avoid trying to invalidate the TLB in the middle of performing an

   engine reset, as this may result in the reset timing out. Currently,
   the TLB invalidate is only serialised by its own mutex, forgoing the
   uncore lock, but we can take the uncore->lock as well to serialise
   the mmio access, thereby serialising with the GDRST.
   
   Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with

   i915 selftest/hangcheck.
   
   Cc: sta...@vger.kernel.org

   Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing 
store")
   Reported-by: Mauro Carvalho Chehab 
   Tested-by: Mauro Carvalho Chehab 
   Reviewed-by: Mauro Carvalho Chehab 
   Signed-off-by: Chris Wilson 
   Cc: Tvrtko Ursulin 
   Acked-by: Thomas Hellström 
   Reviewed-by: Andi Shyti 
   Signed-off-by: Mauro Carvalho Chehab 
   Signed-off-by: Tvrtko Ursulin 

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8da3314bb6bf..aaadd0b02043 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -952,7 +952,23 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
   mutex_lock(>->tlb_invalidate_lock);
   intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);

+   spin_lock_irq(&uncore->lock); /* serialise invalidate with GT reset */

+
+   for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
+   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
+   if (!i915_mmio_reg_offset(rb.reg))
+   continue;
+
+   intel_uncore_write_fw(uncore, rb.reg, rb.bit);
+   }
+
+   spin_unlock_irq(&uncore->lock);
+
   for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
   /*
* HW architecture suggest typical invalidation time at 40us,
* with pessimistic cases up to 100us and a recommendation to
@@ -960,13 +976,11 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
*/
   const unsigned int timeout_us = 100;
   const unsigned int timeout_ms = 4;
-   struct reg_and_bit rb;

   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);

   if (!i915_mmio_reg_offset(rb.reg))
   continue;

-   intel_uncore_write_fw(uncore, rb.reg, rb.bit);

   if (__intel_wait_for_register_fw(uncore,
rb.reg, rb.bit, 0,
timeout_us, timeout_ms,
  


This won't work, as it is not serializing TLB cache invalidation with
i915 resets. Besides that, this is more or less merging patches 1 and 3,


Could you explain why you think it is not doing exactly that? In both
versions end result is TLB flush requests are under the uncore lock and
waits are outside it.


Sure, but patch 2/3 (see v2) serializes i915 reset with TLB cache changes.
This is needed in order to fix the regression.


Not "the" regression, and not even _a_ *regression*. 2/3 fixes an pre-existing 
and unrelated problem. Or only tangentially related if you want. 2/3 fixes a hang if two 
engine resets would happen to coincide. Nothing about TLB flushing.


placing patches with different rationales altogether. Upstream rule is
to have one logical change per patch.


I don't think it applies in this case. It is simply splitting into two
loops so lock can be held across all mmio writes. I think of it this way
- what is the rationale f

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Remove flush_scheduled_work() from live_execlists

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Remove flush_scheduled_work() from live_execlists
URL   : https://patchwork.freedesktop.org/series/105816/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11834_full -> Patchwork_105816v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_busy@extended-modeset-hang-oldfb@pipe-a:
- shard-kbl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-kbl6/igt@kms_busy@extended-modeset-hang-ol...@pipe-a.html

  * igt@kms_cursor_legacy@flip-vs-cursor@varying-size:
- shard-iclb: [PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-iclb6/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@varying-size.html

  * igt@kms_cursor_legacy@torture-bo@pipe-c:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-tglb5/igt@kms_cursor_legacy@torture...@pipe-c.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-tglb2/igt@kms_cursor_legacy@torture...@pipe-c.html

  
 Suppressed 

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

  * igt@gem_create@create-ext-cpu-access-sanity-check:
- {shard-rkl}:NOTRUN -> [SKIP][6] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-rkl-6/igt@gem_cre...@create-ext-cpu-access-sanity-check.html

  * igt@kms_3d:
- {shard-dg1}:[SKIP][7] ([i915#2575]) -> [SKIP][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-dg1-17/igt@kms_3d.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-dg1-12/igt@kms_3d.html

  * igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
- {shard-dg1}:[SKIP][9] ([i915#2575]) -> [FAIL][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-dg1-17/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-dg1-12/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a1:
- {shard-dg1}:NOTRUN -> [FAIL][11] +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-dg1-12/igt@kms_flip@wf_vblank-ts-check-interrupti...@c-hdmi-a1.html

  * igt@kms_plane_scaling@planes-upscale-20x20@pipe-d-hdmi-a-1:
- {shard-dg1}:NOTRUN -> [SKIP][12] +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-dg1-12/igt@kms_plane_scaling@planes-upscale-20...@pipe-d-hdmi-a-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@nonpriv-switch@rcs0:
- shard-glk:  [PASS][13] -> [INCOMPLETE][14] ([i915#6310])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-glk9/igt@gem_ctx_isolation@nonpriv-swi...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-glk6/igt@gem_ctx_isolation@nonpriv-swi...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1099])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-persistence.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][16] -> [TIMEOUT][17] ([i915#3070])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11834/shard-iclb6/igt@gem_...@unwedge-stress.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-iclb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4525])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105816v1/shard-iclb7/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL]

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ttm for stolen (rev5)

[Tvrtko Ursulin]

On 30/06/2022 15:20, Robert Beckett wrote:



On 29/06/2022 13:51, Robert Beckett wrote:



On 28/06/2022 17:22, Robert Beckett wrote:



On 28/06/2022 09:46, Tvrtko Ursulin wrote:


On 27/06/2022 18:08, Robert Beckett wrote:



On 22/06/2022 10:05, Tvrtko Ursulin wrote:


On 21/06/2022 20:11, Robert Beckett wrote:



On 21/06/2022 18:37, Patchwork wrote:

*Patch Details*
*Series:*    drm/i915: ttm for stolen (rev5)
*URL:*    https://patchwork.freedesktop.org/series/101396/ 


*State:*    failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v5/index.html 
 




  CI Bug Log - changes from CI_DRM_11790 -> Patchwork_101396v5


    Summary

*FAILURE*

Serious unknown changes coming with Patchwork_101396v5 
absolutely need to be

verified manually.

If you think the reported changes have nothing to do with the 
changes
introduced in Patchwork_101396v5, please notify your bug team to 
allow them
to document this new failure mode, which will reduce false 
positives in CI.


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




    Participating hosts (40 -> 41)

Additional (2): fi-icl-u2 bat-dg2-9
Missing (1): fi-bdw-samus


    Possible new issues

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



  IGT changes


    Possible regressions

  * igt@i915_selftest@live@reset:
  o bat-adlp-4: PASS
 


    -> DMESG-FAIL
 





I keep hitting clobbered pages during engine resets on bat-adlp-4.
It seems to happen most of the time on that machine and 
occasionally on bat-adlp-6.


Should bat-adlp-4 be considered an unreliable machine like 
bat-adlp-6 is for now?


Alternatively, seeing the history of this in

commit 3da3c5c1c9825c24168f27b021339e90af37e969 "drm/i915: 
Exclude low pages (128KiB) of stolen from use"


could this be an indication that maybe the original issue is 
worse on adlp machines?
I have only ever seen page page 135 or 136 clobbered across many 
runs via trybot, so it looks fairly consistent.

Though excluding the use of over 540K of stolen might be too severe.


Don't know but I see that on the latest version you even hit pages 
165/166.


Any history of hitting this in CI without your series? If not, are 
there some other changes which could explain it? Are you touching 
the selftest itself?


Hexdump of the clobbered page looks quite complex. Especially 
POISON_FREE. Any idea how that ends up there?



(see 
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_105517v4/fi-rkl-guc/igt@i915_selftest@l...@reset.html#dmesg-warnings702) 



after lots of slow debug via CI, it looks like the issue is that a 
ring buffer was allocated and taking up that page during the 
initial crc capture in the test, but by the time it came to check 
for corruption, it had been freed from that page.


The test has a number of weaknesses:

1. the busy check is done twice, without taking in to account any 
change in between. I assume previously this could be relied on 
never to occur, but now it can for some reason (more on that later)


You mean the stolen page used/unused test? Probably the premise is 
that the test controls the driver completely ie. is the sole user 
and the two checks are run at the time where nothing else could have 
changed the state.


With the nerfed request (as with GuC) this actually should hold. In 
the generic case I am less sure, my working knowledge faded a bit, 
but perhaps there was something guaranteeing the spinner couldn't 
have been retired yet at the time of the second check. Would need 
clarifying at least in comments.


2. the engine reset returns early with an error for guc submission 
engines, but it is silently ignored in the test. Perhaps it should 
ignore guc submission engines as it is a largely useless test for 
those situations.


Yes looks dodgy indeed. You will need to summon the owners of the 
GuC backend to comment on this.


However even if the test should be skipped with GuC it is extremely 
interesting that you are hitting this so I suspect there is a more 
serious issue at play.


indeed. That's why I am keen to get to the root cause instead of just 
slapping in a fix.




A quick obvious fix is to have a busy bitmask that remembers each 
page's busy state initially and only check for corruption if it was 
busy during both checks.


However, the main question is why this is occurring now with my 
changes.
I have added more debug to check where the stolen memory is being 
freed, but the first run last night didn't hit the issue for once.
I am running again now, will report back if I figure out where it 
is being freed.


I am pretty sur