Re: [Intel-gfx] [PATCH v2] drm/i915: Kill the fake lmem support

[Lucas De Marchi]

On Thu, Feb 17, 2022 at 06:09:53PM +, Matthew Auld wrote:

On Thu, 17 Feb 2022 at 17:55, Lucas De Marchi  wrote:


This was useful for early development of lmem, but it's not used
anymore, so remove it.

v2: Remove unneeded fields from struct intel_memory_region

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Auld 


Thanks, applied.

Lucas De Marchi

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Kill the fake lmem support (rev2)

[Lucas De Marchi]

On Fri, Feb 18, 2022 at 01:08:36PM +, Patchwork wrote:

== Series Details ==

Series: drm/i915: Kill the fake lmem support (rev2)
URL   : https://patchwork.freedesktop.org/series/100276/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22319_full


Summary
---

 **FAILURE**

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

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



Participating hosts (11 -> 11)
--

 No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt:
   - shard-tglb: [PASS][1] -> [DMESG-WARN][2]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html


this display issue can't be caused by the dead code removal in this
series. And the warning doesn't come from our driver, but rather from
acpi/thermal.

Lucas De Marchi




Known issues


 Here are the changes found in Patchwork_22319_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_22319/shard-apl2/igt@gem_cre...@create-massive.html

 * igt@gem_exec_balancer@parallel-balancer:
   - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
  [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb8/igt@gem_exec_balan...@parallel-balancer.html

 * igt@gem_exec_balancer@parallel-bb-first:
   - shard-kbl:  NOTRUN -> [DMESG-WARN][6] ([i915#5076])
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-kbl1/igt@gem_exec_balan...@parallel-bb-first.html

 * igt@gem_exec_fair@basic-pace-share@rcs0:
   - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
  [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
  [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

 * igt@gem_exec_fair@basic-throttle@rcs0:
   - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2849])
  [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
  [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

 * igt@gem_exec_params@secure-non-root:
   - shard-iclb: NOTRUN -> [SKIP][11] ([fdo#112283])
  [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb3/igt@gem_exec_par...@secure-non-root.html

 * igt@gem_huc_copy@huc-copy:
   - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190])
  [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb3/igt@gem_huc_c...@huc-copy.html
  [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb7/igt@gem_huc_c...@huc-copy.html

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

 * igt@gem_render_copy@y-tiled-to-vebox-yf-tiled:
   - shard-iclb: NOTRUN -> [SKIP][15] ([i915#768])
  [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb7/igt@gem_render_c...@y-tiled-to-vebox-yf-tiled.html

 * igt@gem_softpin@allocator-evict-all-engines:
   - shard-glk:  [PASS][16] -> [FAIL][17] ([i915#4171])
  [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk4/igt@gem_soft...@allocator-evict-all-engines.html
  [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-glk3/igt@gem_soft...@allocator-evict-all-engines.html

 * igt@gem_userptr_blits@dmabuf-sync:
   - shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
  [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-skl4/igt@gem_userptr_bl...@dmabuf-sync.html

 * igt@gen9_exec_parse@allowed-all:
   - shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856]) +1 similar issue
  [19]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Review of mode copies

[Patchwork]

== Series Details ==

Series: drm: Review of mode copies
URL   : https://patchwork.freedesktop.org/series/100394/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11248_full -> Patchwork_22330_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_self_import@export-vs-gem_close-race:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-snb5/igt@prime_self_import@export-vs-gem_close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-snb7/igt@prime_self_import@export-vs-gem_close-race.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@file:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-snb2/igt@gem_ctx_persiste...@file.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][6] -> [INCOMPLETE][7] ([i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-skl9/igt@gem_exec_capture@p...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-skl8/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][8] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-skl10/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk2/igt@gem_exec_whis...@basic-queues-forked-all.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-iclb3/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@parallel-multi:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-skl10/igt@gem_lmem_swapp...@parallel-multi.html

  * igt@gem_lmem_swapping@random-engines:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-apl7/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pread@exhaustion:
- shard-kbl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/shard-kbl1/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@y-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#768]) +1 similar 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add relocation exception

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Add relocation exception
URL   : https://patchwork.freedesktop.org/series/100433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11254 -> Patchwork_22338


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 41)
--

  Missing(3): fi-bsw-cyan bat-dg2-8 shard-tglu 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][2] -> [INCOMPLETE][3] ([i915#3303])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][5] ([i915#5127]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [INCOMPLETE][7] ([i915#2940]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][9] ([i915#541]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][13] ([i915#4269]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][15] ([i915#4494] / [i915#4957]) -> 
[DMESG-FAIL][16] ([i915#4957])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22338/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  

Re: [Intel-gfx] [PATCH 0/2] drm/i915/dg2: Do not use phy E

[Lucas De Marchi]

On Fri, Feb 18, 2022 at 01:54:36AM -0800, Lucas De Marchi wrote:

This is an alternative to
https://patchwork.freedesktop.org/series/100151/
("drm/i915/dg2: 5th Display output").


After talking with Matt Roper, it seems the issue calibrating the phy
happens sporadically on any phy. So, there isn't anything special with
phy E here.

Therefore, let's just go with the patch series adding the 5th port.

Applied the other series.

Lucas De Marchi



We tried to enable the 5th port in order to get rid of
the unclaimed register access, but even after the basic plumbing, we
are still getting and error that the phy failed to calibrate.

So, rather than enabling it and needing another fix on top later, let's
just fix the immediate issue: we are initializing only 4 ports/phys, but
intel_phy_is_snps() returns we have 5, so we access registers we
shouldn't.

I'm still bringing "drm/i915/dg2: Drop 38.4 MHz MPLLB tables", as that
is just eliminating dead code.

Lucas De Marchi (1):
 drm/i915/dg2: Do not use phy E

Matt Roper (1):
 drm/i915/dg2: Drop 38.4 MHz MPLLB tables

drivers/gpu/drm/i915/display/intel_display.c  |   5 +-
drivers/gpu/drm/i915/display/intel_snps_phy.c | 208 +-
2 files changed, 4 insertions(+), 209 deletions(-)

--
2.35.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for Improve anti-pre-emption w/a for compute workloads

[Patchwork]

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads
URL   : https://patchwork.freedesktop.org/series/100428/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11254 -> Patchwork_22337


Summary
---

  **FAILURE**

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

Participating hosts (44 -> 42)
--

  Missing(2): fi-bsw-cyan shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-glk-dsi: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-glk-dsi/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-glk-dsi/igt@i915_selftest@l...@execlists.html
- fi-cfl-8700k:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
- fi-glk-j4005:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-glk-j4005/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-glk-j4005/igt@i915_selftest@l...@execlists.html
- fi-skl-guc: [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-skl-guc/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-skl-guc/igt@i915_selftest@l...@execlists.html
- fi-skl-6700k2:  [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html
- fi-cfl-guc: [PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-cfl-guc/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-cfl-guc/igt@i915_selftest@l...@execlists.html
- fi-tgl-1115g4:  [PASS][15] -> [INCOMPLETE][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-tgl-1115g4/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-tgl-1115g4/igt@i915_selftest@l...@execlists.html
- fi-cml-u2:  [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-cml-u2/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-cml-u2/igt@i915_selftest@l...@execlists.html

  
 Suppressed 

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

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-ehl-2/igt@i915_selftest@l...@execlists.html
- {fi-jsl-1}: [PASS][21] -> [INCOMPLETE][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-jsl-1/igt@i915_selftest@l...@execlists.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-jsl-1/igt@i915_selftest@l...@execlists.html
- {bat-jsl-1}:[PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/bat-jsl-1/igt@i915_selftest@l...@execlists.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/bat-jsl-1/igt@i915_selftest@l...@execlists.html
- {fi-tgl-dsi}:   [PASS][25] -> [INCOMPLETE][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11254/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22337/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html

  
Known issues


  Here are the changes found 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Do not use phy E

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Do not use phy E
URL   : https://patchwork.freedesktop.org/series/100390/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11248_full -> Patchwork_22329_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-iclb4/igt@i915_pm_...@reg-read-ioctl.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb4/igt@i915_pm_...@reg-read-ioctl.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@file:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-snb4/igt@gem_ctx_persiste...@file.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb5/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-iclb: NOTRUN -> [INCOMPLETE][6] ([i915#3371])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb6/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-skl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-tglb8/igt@gem_huc_c...@huc-copy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-multi:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-skl3/igt@gem_lmem_swapp...@parallel-multi.html

  * igt@gem_lmem_swapping@random-engines:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-apl2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pread@exhaustion:
- shard-kbl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-kbl1/igt@gem_pr...@exhaustion.html

  * igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#4270]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb6/igt@gem_...@create-regular-context-1.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#3297])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-iclb6/igt@gem_userptr_bl...@unsync-unmap-cycles.html

  * igt@i915_selftest@live@gt_pm:
- shard-skl:  NOTRUN -> [DMESG-FAIL][17] ([i915#1886] / [i915#2291])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-skl9/igt@i915_selftest@live@gt_pm.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3777]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/shard-kbl1/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777]) +2 
similar issues
   [19]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Improve anti-pre-emption w/a for compute workloads

[Patchwork]

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads
URL   : https://patchwork.freedesktop.org/series/100428/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: fixup the mock_bo (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: fixup the mock_bo (rev2)
URL   : https://patchwork.freedesktop.org/series/100255/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11248_full -> Patchwork_22328_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@mock@memory_region:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-skl9/igt@i915_selftest@mock@memory_region.html
- shard-glk:  NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-glk1/igt@i915_selftest@mock@memory_region.html
- shard-apl:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-apl3/igt@i915_selftest@mock@memory_region.html
- shard-iclb: NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-iclb8/igt@i915_selftest@mock@memory_region.html
- shard-kbl:  NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-kbl1/igt@i915_selftest@mock@memory_region.html
- shard-snb:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/shard-snb2/igt@i915_selftest@mock@memory_region.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [FAIL][34], 
[PASS][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], 
[PASS][53], [PASS][54], [PASS][55], [PASS][56]) ([i915#4392])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk1/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk1/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk3/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk5/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk6/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk6/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk7/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk7/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/shard-glk9/boot.html
   [32]: 

Re: [Intel-gfx] [PATCH 15/15] drm/i915/gt: Clear compress metadata for Xe_HP platforms

[Matt Roper]

On Sat, Feb 19, 2022 at 12:17:52AM +0530, Ramalingam C wrote:
> From: Ayaz A Siddiqui 
> 
> Xe-HP and latest devices support Flat CCS which reserved a portion of
> the device memory to store compression metadata, during the clearing of
> device memory buffer object we also need to clear the associated
> CCS buffer.
> 
> Flat CCS memory can not be directly accessed by S/W.
> Address of CCS buffer associated main BO is automatically calculated
> by device itself. KMD/UMD can only access this buffer indirectly using
> XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.
> 
> v2: Fixed issues with platform naming [Lucas]
> v3: Rebased [Ram]
> Used the round_up funcs [Bob]
> v4: Fixed ccs blk calculation [Ram]
> Added Kdoc on flat-ccs.
> 
> Cc: CQ Tang 
> Signed-off-by: Ayaz A Siddiqui 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  15 ++
>  drivers/gpu/drm/i915/gt/intel_migrate.c  | 145 ++-
>  2 files changed, 156 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index f8253012d166..166de5436c4a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -203,6 +203,21 @@
>  #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
>  #define GFX_OP_DRAWRECT_INFO_I965  ((0x7900<<16)|0x2)
>  
> +#define XY_CTRL_SURF_INSTR_SIZE  5
> +#define MI_FLUSH_DW_SIZE 3
> +#define XY_CTRL_SURF_COPY_BLT((2 << 29) | (0x48 << 22) | 3)
> +#define   SRC_ACCESS_TYPE_SHIFT  21
> +#define   DST_ACCESS_TYPE_SHIFT  20
> +#define   CCS_SIZE_SHIFT 8

Rather than using a shift, it might be better to just define the
bitfield.  E.g.,

#define CCS_SIZEGENMASK(17, 8)

and then later

FIELD_PREP(CCS_SIZE, i - 1)

to refer to the proper value.

> +#define   XY_CTRL_SURF_MOCS_SHIFT25

Same here; we can use GENMASK(31, 25) to define the field.

> +#define   NUM_CCS_BYTES_PER_BLOCK256
> +#define   NUM_BYTES_PER_CCS_BYTE 256
> +#define   NUM_CCS_BLKS_PER_XFER  1024
> +#define   INDIRECT_ACCESS0
> +#define   DIRECT_ACCESS  1
> +#define  MI_FLUSH_LLCBIT(9)
> +#define  MI_FLUSH_CCSBIT(16)
> +
>  #define COLOR_BLT_CMD(2 << 29 | 0x40 << 22 | (5 - 2))
>  #define XY_COLOR_BLT_CMD (2 << 29 | 0x50 << 22)
>  #define SRC_COPY_BLT_CMD (2 << 29 | 0x43 << 22)
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 20444d6ceb3c..9f9cd2649377 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -16,6 +16,8 @@ struct insert_pte_data {
>  };
>  
>  #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
> +#define GET_CCS_BYTES(i915, size)(HAS_FLAT_CCS(i915) ? \
> +  DIV_ROUND_UP(size, 
> NUM_BYTES_PER_CCS_BYTE) : 0)
>  
>  static bool engine_supports_migration(struct intel_engine_cs *engine)
>  {
> @@ -467,6 +469,113 @@ static bool wa_1209644611_applies(int ver, u32 size)
>   return height % 4 == 3 && height <= 8;
>  }
>  
> +/**
> + * DOC: Flat-CCS - Memory compression for Local memory
> + *
> + * On Xe-HP and later devices, we use dedicated compression control state 
> (CCS)
> + * stored in local memory for each surface, to support the 3D and media
> + * compression formats.
> + *
> + * The memory required for the CCS of the entire local memory is 1/256 of the
> + * local memory size. So before the kernel boot, the required memory is 
> reserved
> + * for the CCS data and a secure register will be programmed with the CCS 
> base
> + * address.
> + *
> + * Flat CCS data needs to be cleared when a lmem object is allocated.
> + * And CCS data can be copied in and out of CCS region through
> + * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
> + *
> + * When we exaust the lmem, if the object's placements support smem, then we 
> can

Typo: exhaust

> + * directly decompress the compressed lmem object into smem and start using 
> it
> + * from smem itself.
> + *
> + * But when we need to swapout the compressed lmem object into a smem region
> + * though objects' placement doesn't support smem, then we copy the lmem 
> content
> + * as it is into smem region along with ccs data (using 
> XY_CTRL_SURF_COPY_BLT).
> + * When the object is referred, lmem content will be swaped in along with
> + * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
> + * location.
> + */
> +
> +static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
> +{
> + /* Mask the 3 LSB to use the PPGTT address space */

This comment implies that we'd be doing something like

*cmd++ = 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Initialize GuC submission locks and queues early

[John Harrison]

On 2/14/2022 17:11, Daniele Ceraolo Spurio wrote:

Move initialization of submission-related spinlock, lists and workers to
init_early. This fixes an issue where if the GuC init fails we might
still try to get the lock in the context cleanup code. Note that it is
safe to call the GuC context cleanup code even if the init failed
because all contexts are initialized with an invalid GuC ID, which will
cause the GuC side of the cleanup to be skipped, so it is easier to just
make sure the variables are initialized than to special case the cleanup
to handle the case when they're not.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/4932
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matthew Brost 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 27 ++-
  1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0da..2160da2c83cbf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1818,24 +1818,11 @@ int intel_guc_submission_init(struct intel_guc *guc)
 */
GEM_BUG_ON(!guc->lrc_desc_pool);
  
-	xa_init_flags(>context_lookup, XA_FLAGS_LOCK_IRQ);

-
-   spin_lock_init(>submission_state.lock);
-   INIT_LIST_HEAD(>submission_state.guc_id_list);
-   ida_init(>submission_state.guc_ids);
-   INIT_LIST_HEAD(>submission_state.destroyed_contexts);
-   INIT_WORK(>submission_state.destroyed_worker,
- destroyed_worker_func);
-   INIT_WORK(>submission_state.reset_fail_worker,
- reset_fail_worker_func);
-
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
if (!guc->submission_state.guc_ids_bitmap)
return -ENOMEM;
  
-	spin_lock_init(>timestamp.lock);

-   INIT_DELAYED_WORK(>timestamp.work, guc_timestamp_ping);
guc->timestamp.ping_delay = (POLL_TIME_CLKS / gt->clock_frequency + 1) 
* HZ;
guc->timestamp.shift = gpm_timestamp_shift(gt);
  
@@ -3831,6 +3818,20 @@ static bool __guc_submission_selected(struct intel_guc *guc)
  
  void intel_guc_submission_init_early(struct intel_guc *guc)

  {
+   xa_init_flags(>context_lookup, XA_FLAGS_LOCK_IRQ);
+
+   spin_lock_init(>submission_state.lock);
+   INIT_LIST_HEAD(>submission_state.guc_id_list);
+   ida_init(>submission_state.guc_ids);
+   INIT_LIST_HEAD(>submission_state.destroyed_contexts);
+   INIT_WORK(>submission_state.destroyed_worker,
+ destroyed_worker_func);
+   INIT_WORK(>submission_state.reset_fail_worker,
+ reset_fail_worker_func);
+
+   spin_lock_init(>timestamp.lock);
+   INIT_DELAYED_WORK(>timestamp.work, guc_timestamp_ping);
+
guc->submission_state.num_guc_ids = GUC_MAX_LRC_DESCRIPTORS;
guc->submission_supported = __guc_submission_supported(guc);
guc->submission_selected = __guc_submission_selected(guc);

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Expose client engine utilisation via fdinfo

[Umesh Nerlige Ramappa]

On Thu, Jan 06, 2022 at 04:55:36PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.

Example of the output:

 pos:0
 flags:  012
 mnt_id: 21
 drm-driver: i915
 drm-pdev:   :00:02.0
 drm-client-id:  7
 drm-engine-render:  9288864723 ns
 drm-engine-copy:2035071108 ns
 drm-engine-video:   0 ns
 drm-engine-video-enhance:   0 ns

v2:
* Update for removal of name and pid.

v3:
* Use drm_driver.name.

Signed-off-by: Tvrtko Ursulin 
Cc: David M Nieto 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Chris Healy 
Acked-by: Christian König 
---
Documentation/gpu/drm-usage-stats.rst  |  6 +++
Documentation/gpu/i915.rst | 27 ++
drivers/gpu/drm/i915/i915_driver.c |  3 ++
drivers/gpu/drm/i915/i915_drm_client.c | 73 ++
drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
5 files changed, 113 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index c669026be244..6952f8389d07 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -95,3 +95,9 @@ object belong to this client, in the respective memory region.

Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+
+===
+Driver specific implementations
+===
+
+:ref:`i915-usage-stats`
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index b7d801993bfa..29f412a0c3dc 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -708,3 +708,30 @@ The style guide for ``i915_reg.h``.

.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
   :doc: The i915 register macro definition style guide
+
+.. _i915-usage-stats:
+
+i915 DRM client usage stats implementation
+==
+
+The drm/i915 driver implements the DRM client usage stats specification as
+documented in :ref:`drm-client-usage-stats`.
+
+Example of the output showing the implemented key value pairs and entirety of
+the currenly possible format options:


s/currenly/currently/

lgtm, for the series 


Reviewed-by: Umesh Nerlige Ramappa 

Regards,
Umesh

Re: [Intel-gfx] [PATCH topic/core-for-CI] drm/i915/dg2: Add relocation exception

[Dixit, Ashutosh]

On Fri, 18 Feb 2022 14:38:53 -0800, Lucas De Marchi wrote:
>
> The move to softpin in igt is ongoing and should land soon.
> Meanwhile, like was done for ADL and RKL, add an exception to allow
> running the igt display tests before that conversion is complete
> so we can unblock CI.

One example failure we see on DG2 if we don't do this (reported by Lucas):

IGT-Version: 1.26-g9cb64a75 (x86_64) (Linux: 5.17.0-rc4-demarchi+ x86_64)
(testdisplay:10068) ioctl_wrappers-CRITICAL: Test assertion failure function 
gem_execbuf, file ../lib/ioctl_wrappers.c:674:
(testdisplay:10068) ioctl_wrappers-CRITICAL: Failed assertion: 
__gem_execbuf(fd, execbuf) == 0
(testdisplay:10068) ioctl_wrappers-CRITICAL: error: -22 != 0
Stack trace:
#0 ../lib/igt_core.c:1754 __igt_fail_assert()
#1 [gem_execbuf+0x48]
#2 ../lib/intel_batchbuffer.c:1053 igt_blitter_fast_copy__raw()
#3 ../lib/igt_fb.c:2497 blitcopy()
#4 ../lib/igt_fb.c:2646 setup_linear_mapping()
#5 ../lib/igt_fb.c:2671 create_cairo_surface__gpu()
#6 ../lib/igt_fb.c:3959 igt_get_cairo_surface()
#7 ../lib/igt_fb.c:3987 igt_get_cairo_ctx()
#8 ../lib/igt_fb.c:1980 igt_create_pattern_fb()
#9 ../tests/testdisplay.c:271 set_mode()
#10 ../tests/testdisplay.c:511 update_display()
#11 ../tests/testdisplay.c:763 main()
#12 ../csu/libc-start.c:342 __libc_start_main()
#13 [_start+0x2e]
Test testdisplay failed

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rps/tgl+: Remove RPS interrupt support

[Patchwork]

== Series Details ==

Series: drm/i915/rps/tgl+: Remove RPS interrupt support
URL   : https://patchwork.freedesktop.org/series/100426/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11253 -> Patchwork_22336


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Additional (2): bat-dg2-8 fi-rkl-guc 
  Missing(3): fi-bsw-cyan shard-tglu fi-pnv-d510 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   NOTRUN -> [FAIL][2] ([i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][3] -> [INCOMPLETE][4] ([i915#146])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@verify-random:
- fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-guc: NOTRUN -> [SKIP][6] ([i915#3282])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@gem_tiled_pread_basic.html

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

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4:  [PASS][8] -> [DMESG-FAIL][9] ([i915#3987])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.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_11253/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][12] -> [INCOMPLETE][13] ([i915#3921])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-guc: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][17] -> [DMESG-WARN][18] ([i915#4269])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-guc: NOTRUN -> [SKIP][19] ([i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-guc: NOTRUN -> [SKIP][20] ([i915#1072]) +3 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@kms_psr@sprite_plane_onoff.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-guc: NOTRUN -> [SKIP][21] ([i915#3301] / [i915#3708])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22336/fi-rkl-guc/igt@prime_v...@basic-userptr.html

  * 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Move #define wbvind_on_all_cpus (rev3)

[Patchwork]

== Series Details ==

Series: Move #define wbvind_on_all_cpus (rev3)
URL   : https://patchwork.freedesktop.org/series/1/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11253 -> Patchwork_22335


Summary
---

  **FAILURE**

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

Participating hosts (43 -> 41)
--

  Additional (1): fi-rkl-guc 
  Missing(3): fi-bsw-cyan bat-rpls-2 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@basic-busy@rcs0:
- fi-blb-e6850:   [PASS][1] -> [DMESG-WARN][2] +15 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] +15 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-glk-dsi/igt@gem_exec_fence@nb-aw...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-glk-dsi/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-guc: [PASS][5] -> [DMESG-WARN][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-bsw-nick:[PASS][7] -> [DMESG-WARN][8] +13 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html
- fi-glk-j4005:   [PASS][9] -> [DMESG-WARN][10] +15 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
- fi-kbl-x1275:   [PASS][11] -> [DMESG-WARN][12] +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-kbl-x1275/igt@gem_exec_suspend@basic...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-kbl-x1275/igt@gem_exec_suspend@basic...@smem.html
- fi-kbl-7567u:   [PASS][13] -> [DMESG-WARN][14] +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-kbl-7567u/igt@gem_exec_suspend@basic...@smem.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-kbl-7567u/igt@gem_exec_suspend@basic...@smem.html
- fi-bdw-5557u:   [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
- fi-skl-6600u:   [PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-elk-e7500:   [PASS][19] -> [DMESG-WARN][20] +15 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-elk-e7500/igt@gem_exec_suspend@basic...@smem.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-elk-e7500/igt@gem_exec_suspend@basic...@smem.html
- bat-dg1-6:  [PASS][21] -> [DMESG-WARN][22] +4 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
- fi-skl-6700k2:  [PASS][23] -> [DMESG-WARN][24] +3 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11253/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22335/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html
- fi-skl-guc: [PASS][25] -> [DMESG-WARN][26] +3 similar issues
   [25]: 

Re: [Intel-gfx] [PATCH] drm/i915/adl-n: Add PCH Support for Alder Lake N

[Srivatsa, Anusha]

> -Original Message-
> From: Intel-gfx  On Behalf Of Tejas
> Upadhyay
> Sent: Thursday, January 27, 2022 2:35 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/adl-n: Add PCH Support for Alder Lake
> N
> 
> Add the PCH ID for ADL-N.
> 
> Signed-off-by: Tejas Upadhyay
> 

Reviewed-by: Anusha Srivatsa 

> ---
>  drivers/gpu/drm/i915/intel_pch.c | 1 +
>  drivers/gpu/drm/i915/intel_pch.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index da8f82c2342f..4f7a61d5502e 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -130,6 +130,7 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id)
>   case INTEL_PCH_ADP_DEVICE_ID_TYPE:
>   case INTEL_PCH_ADP2_DEVICE_ID_TYPE:
>   case INTEL_PCH_ADP3_DEVICE_ID_TYPE:
> + case INTEL_PCH_ADP4_DEVICE_ID_TYPE:
>   drm_dbg_kms(_priv->drm, "Found Alder Lake PCH\n");
>   drm_WARN_ON(_priv->drm,
> !IS_ALDERLAKE_S(dev_priv) &&
>   !IS_ALDERLAKE_P(dev_priv));
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index 6bff77521094..6fd20408f7bf 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -58,6 +58,7 @@ enum intel_pch {
>  #define INTEL_PCH_ADP_DEVICE_ID_TYPE 0x7A80
>  #define INTEL_PCH_ADP2_DEVICE_ID_TYPE0x5180
>  #define INTEL_PCH_ADP3_DEVICE_ID_TYPE0x7A00
> +#define INTEL_PCH_ADP4_DEVICE_ID_TYPE0x5480
>  #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
>  #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
>  #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35
> has 2918 */
> --
> 2.34.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move #define wbvind_on_all_cpus (rev3)

[Patchwork]

== Series Details ==

Series: Move #define wbvind_on_all_cpus (rev3)
URL   : https://patchwork.freedesktop.org/series/1/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Move #define wbvind_on_all_cpus (rev3)

[Patchwork]

== Series Details ==

Series: Move #define wbvind_on_all_cpus (rev3)
URL   : https://patchwork.freedesktop.org/series/1/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8c5741d746ef drm_cache: Add logic for wbvind_on_all_cpus
-:34: WARNING:INCLUDE_LINUX: Use #include  instead of 
#34: FILE: include/drm/drm_cache.h:37:
+#include 

total: 0 errors, 1 warnings, 0 checks, 20 lines checked
ca2aac49253c drm/i915/gem: Remove logic for wbinvd_on_all_cpus
b80161c6c202 drm/i915/: Add drm_cache.h

[Intel-gfx] [PATCH topic/core-for-CI] drm/i915/dg2: Add relocation exception

[Lucas De Marchi]

The move to softpin in igt is ongoing and should land soon.
Meanwhile, like was done for ADL and RKL, add an exception to allow
running the igt display tests before that conversion is complete
so we can unblock CI.

Cc: Zbigniew Kempczynski 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: Rodrigo Vivi 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f8f07d0bd83b..85f4808957b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -504,7 +504,7 @@ static bool platform_has_relocs_enabled(const struct 
i915_execbuffer *eb)
 */
if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915) ||
IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
-   IS_ALDERLAKE_P(eb->i915))
+   IS_ALDERLAKE_P(eb->i915) || IS_DG2(eb->i915))
return true;
 
return false;
-- 
2.35.1

Re: [Intel-gfx] [drm-intel:topic/core-for-CI 1/1] drivers/gpu/drm/i915/intel_device_info.c:236:14: error: 'INTEL_SUBPLATFORM_G12' undeclared; did you mean 'INTEL_SUBPLATFORM_G10'?

[Lucas De Marchi]

On Thu, Feb 17, 2022 at 05:40:51PM +0800, kernel test robot wrote:

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   b56d8d7bad86a9badc1d1b9ea2d1730fa1d3978b
commit: b56d8d7bad86a9badc1d1b9ea2d1730fa1d3978b [1/1] drm/i915: Add DG2 PCI IDs
config: x86_64-randconfig-a011 
(https://download.01.org/0day-ci/archive/20220217/202202171718.0gtdm2wx-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
   git remote add drm-intel git://anongit.freedesktop.org/drm-intel
   git fetch --no-tags drm-intel topic/core-for-CI
   git checkout b56d8d7bad86a9badc1d1b9ea2d1730fa1d3978b
   # save the config file to linux build tree
   mkdir build_dir
   make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash

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

All errors (new ones prefixed by >>):

  In file included from include/linux/bits.h:6,
   from include/linux/ratelimit_types.h:5,
   from include/linux/printk.h:10,
   from include/drm/drm_print.h:30,
   from drivers/gpu/drm/i915/intel_device_info.c:25:
  drivers/gpu/drm/i915/intel_device_info.c: In function 
'intel_device_info_subplatform_init':

drivers/gpu/drm/i915/intel_device_info.c:236:14: error: 'INTEL_SUBPLATFORM_G12' 
undeclared (first use in this function); did you mean 'INTEL_SUBPLATFORM_G10'?

236 |   mask = BIT(INTEL_SUBPLATFORM_G12);
|  ^


I rebased the topic/core-for-CI branch an in the process squashed a define for
INTEL_SUBPLATFORM_G12 to fix this.

Lucas De Marchi

Re: [Intel-gfx] [PATCH v3] drm/i915/dg2: Define GuC firmware version for DG2

[Lucas De Marchi]

+Daniele, +Rodrigo

On Tue, Feb 08, 2022 at 11:14:57PM -0800, Lucas De Marchi wrote:

On Mon, Feb 07, 2022 at 12:36:42PM -0800, john.c.harri...@intel.com wrote:

From: John Harrison 

First release of GuC for DG2.

Signed-off-by: John Harrison 
CC: Tomasz Mistat 
CC: Ramalingam C 
CC: Daniele Ceraolo Spurio 



Reviewed-by: Lucas De Marchi 


I rebased topic/core-for-CI on v5.17-rc4 that is where drm/drm-next is
based at and applied this patch there. Even after the rebase there was a
small conflict that I fixed up.

As talked with Daniele, we decided to merge this in the topic branch so
we can enable CI first and don't risk needing 2 versions sent to
linux-firmware if something doesn't work.

However I think we can't leave this patch there for a long time,
otherwise it will cause conflicts for things merging in
drm-intel-gt-next soon.

Daniele, while merging this I forgot to add the r-b you gave in the
other email thread, sorry. We can add it when this goes to the normal
non-topic branch.

thanks
Lucas De Marchi

Re: [Intel-gfx] [PATCH v3 10/16] drm/i915/guc: Convert golden context prep to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:41AM -0800, Lucas De Marchi wrote:
> Use the saved ads_map to prepare the golden context. One difference from
> the init context is that this function can be called before there is a
> gem object (and thus the guc->ads_map) to calculare the size of the
> golden context that should be allocated for that object.
> 
> So in this case the function needs to be prepared for not having the
> system_info with enabled engines filled out. To accomplish that an
> info_map is prepared on the side to point either to the gem object
> or the local variable on the stack. This allows making
> fill_engine_enable_masks() operate always with a iosys_map
> argument.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 52 +-
>  1 file changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index d924486490c1..0077a63832ad 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -67,6 +67,12 @@ struct __guc_ads_blob {
>   iosys_map_wr_field(&(guc_)->ads_map, 0, struct __guc_ads_blob,  \
>  field_, val_)
>  
> +#define info_map_write(map_, field_, val_) \
> + iosys_map_wr_field(map_, 0, struct guc_gt_system_info, field_, val_)
> +
> +#define info_map_read(map_, field_) \
> + iosys_map_rd_field(map_, 0, struct guc_gt_system_info, field_)
> +
>  static u32 guc_ads_regset_size(struct intel_guc *guc)
>  {
>   GEM_BUG_ON(!guc->ads_regset_size);
> @@ -417,24 +423,24 @@ static void guc_mmio_reg_state_init(struct intel_guc 
> *guc,
>  }
>  
>  static void fill_engine_enable_masks(struct intel_gt *gt,
> -  struct guc_gt_system_info *info)
> +  struct iosys_map *info_map)
>  {
> - info->engine_enabled_masks[GUC_RENDER_CLASS] = 1;
> - info->engine_enabled_masks[GUC_BLITTER_CLASS] = 1;
> - info->engine_enabled_masks[GUC_VIDEO_CLASS] = VDBOX_MASK(gt);
> - info->engine_enabled_masks[GUC_VIDEOENHANCE_CLASS] = VEBOX_MASK(gt);
> + info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 1);
> + info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
> + info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS], 
> VDBOX_MASK(gt));
> + info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS], 
> VEBOX_MASK(gt));
>  }
>  
>  #define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
>  #define LRC_SKIP_SIZE (LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE)
> -static int guc_prep_golden_context(struct intel_guc *guc,
> -struct __guc_ads_blob *blob)
> +static int guc_prep_golden_context(struct intel_guc *guc)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
>   u32 addr_ggtt, offset;
>   u32 total_size = 0, alloc_size, real_size;
>   u8 engine_class, guc_class;
> - struct guc_gt_system_info *info, local_info;
> + struct guc_gt_system_info local_info;
> + struct iosys_map info_map;
>  
>   /*
>* Reserve the memory for the golden contexts and point GuC at it but
> @@ -448,14 +454,15 @@ static int guc_prep_golden_context(struct intel_guc 
> *guc,
>* GuC will also validate that the LRC base + size fall within the
>* allowed GGTT range.
>*/
> - if (blob) {
> + if (!iosys_map_is_null(>ads_map)) {
>   offset = guc_ads_golden_ctxt_offset(guc);
>   addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
> - info = >system_info;
> + info_map = IOSYS_MAP_INIT_OFFSET(>ads_map,
> +  offsetof(struct 
> __guc_ads_blob, system_info));
>   } else {
>   memset(_info, 0, sizeof(local_info));
> - info = _info;
> - fill_engine_enable_masks(gt, info);
> + iosys_map_set_vaddr(_map, _info);
> + fill_engine_enable_masks(gt, _map);
>   }
>  
>   for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS; 
> ++engine_class) {
> @@ -464,14 +471,14 @@ static int guc_prep_golden_context(struct intel_guc 
> *guc,
>  
>   guc_class = engine_class_to_guc_class(engine_class);
>  
> - if (!info->engine_enabled_masks[guc_class])
> + if (!info_map_read(_map, engine_enabled_masks[guc_class]))
>   continue;
>  
>   real_size = intel_engine_context_size(gt, engine_class);
>   alloc_size = PAGE_ALIGN(real_size);
>   total_size += alloc_size;
>  
> - if (!blob)
> + if (iosys_map_is_null(>ads_map))
>   continue;
>  
>   /*

[Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

[John . C . Harrison]

From: John Harrison 

Compute workloads are inherantly not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence the
next patch will re-enable the timeout but bumped up by an order of
magnititude.

However, the heartbeat might not respect that. Depending upon current
activity, a pre-emption to the heartbeat pulse might not even be
attempted until the last heartbeat period. Which means that only one
period is granted for the pre-emption to occur. With the aforesaid
bump, the pre-emption timeout could be significantly larger than this
heartbeat period.

So adjust the heartbeat code to take the pre-emption timeout into
account. When it reaches the final (high priority) period, it now
ensures the delay before hitting reset is bigger than the pre-emption
timeout.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index a3698f611f45..72a82a6085e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -22,9 +22,25 @@
 
 static bool next_heartbeat(struct intel_engine_cs *engine)
 {
+   struct i915_request *rq;
long delay;
 
delay = READ_ONCE(engine->props.heartbeat_interval_ms);
+
+   rq = engine->heartbeat.systole;
+   if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER) {
+   long longer;
+
+   /*
+* The final try is at the highest priority possible. Up until 
now
+* a pre-emption might not even have been attempted. So make 
sure
+* this last attempt allows enough time for a pre-emption to 
occur.
+*/
+   longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
+   if (longer > delay)
+   delay = longer;
+   }
+
if (!delay)
return false;
 
-- 
2.25.1

[Intel-gfx] [PATCH 3/3] drm/i915: Improve long running OCL w/a for GuC submission

[John . C . Harrison]

From: John Harrison 

A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.

However, this does not work well in GuC submission mode. In GuC mode,
the pre-emption timeout is how GuC detects hung contexts and triggers
a per engine reset. Thus, disabling the timeout means also losing all
per engine reset ability. A full GT reset will still occur when the
heartbeat finally expires, but that is a much more destructive and
undesirable mechanism.

The purpose of the workaround is actually to give OpenCL tasks longer
to reach a pre-emption point after a pre-emption request has been
issued. This is necessary because Gen12 does not support mid-thread
pre-emption and OpenCL can have long running threads.

So, rather than disabling the timeout completely, just set it to a
'long' value.

CC: Michal Mrozek 
Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2a1e9f36e6f5..64249301a227 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -385,9 +385,25 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->props.timeslice_duration_ms =
CONFIG_DRM_I915_TIMESLICE_DURATION;
 
-   /* Override to uninterruptible for OpenCL workloads. */
-   if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
-   engine->props.preempt_timeout_ms = 0;
+   /*
+* Mid-thread pre-emption is not available in Gen12. Unfortunately,
+* some OpenCL workloads run quite long threads. That means they get
+* reset due to not pre-empting in a timely manner. So, bump the
+* pre-emption timeout value to be much higher for compute engines.
+* Using three times the heartbeat period seems long enough for a
+* reasonable task to reach a pre-emption point but not so long as to
+* allow genuine hangs to go unresolved.
+*/
+   if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS) {
+   unsigned long triple_beat = engine->props.heartbeat_interval_ms 
* 3;
+
+   if (triple_beat > engine->props.preempt_timeout_ms) {
+   drm_info(>i915->drm, "Bumping pre-emption timeout 
from %ld to %ld on %s to allow slow compute pre-emption\n",
+engine->props.preempt_timeout_ms, triple_beat, 
engine->name);
+
+   engine->props.preempt_timeout_ms = triple_beat;
+   }
+   }
 
/* Cap timeouts to prevent overflow inside GuC */
if (intel_guc_submission_is_wanted(>uc.guc)) {
-- 
2.25.1

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

[John . C . Harrison]

From: John Harrison 

GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
then get confused by early timeouts, add limits when setting these
values.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 15 +++
 drivers/gpu/drm/i915/gt/sysfs_engines.c | 14 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  9 +
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e53008b4dd05..2a1e9f36e6f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -389,6 +389,21 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
engine->props.preempt_timeout_ms = 0;
 
+   /* Cap timeouts to prevent overflow inside GuC */
+   if (intel_guc_submission_is_wanted(>uc.guc)) {
+   if (engine->props.timeslice_duration_ms > 
GUC_POLICY_MAX_EXEC_QUANTUM_MS) {
+   drm_info(>i915->drm, "Warning, clamping 
timeslice duration to %d to prevent possibly overflow\n",
+GUC_POLICY_MAX_EXEC_QUANTUM_MS);
+   engine->props.timeslice_duration_ms = 
GUC_POLICY_MAX_EXEC_QUANTUM_MS;
+   }
+
+   if (engine->props.preempt_timeout_ms > 
GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS) {
+   drm_info(>i915->drm, "Warning, clamping 
pre-emption timeout to %d to prevent possibly overflow\n",
+GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS);
+   engine->props.preempt_timeout_ms = 
GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS;
+   }
+   }
+
engine->defaults = engine->props; /* never to change again */
 
engine->context_size = intel_engine_context_size(gt, engine->class);
diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c 
b/drivers/gpu/drm/i915/gt/sysfs_engines.c
index 967031056202..f57efe026474 100644
--- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
@@ -221,6 +221,13 @@ timeslice_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (duration > jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT))
return -EINVAL;
 
+   if (intel_uc_uses_guc_submission(>gt->uc) &&
+   duration > GUC_POLICY_MAX_EXEC_QUANTUM_MS) {
+   duration = GUC_POLICY_MAX_EXEC_QUANTUM_MS;
+   drm_info(>i915->drm, "Warning, clamping timeslice 
duration to %lld to prevent possibly overflow\n",
+duration);
+   }
+
WRITE_ONCE(engine->props.timeslice_duration_ms, duration);
 
if (execlists_active(>execlists))
@@ -325,6 +332,13 @@ preempt_timeout_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (timeout > jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT))
return -EINVAL;
 
+   if (intel_uc_uses_guc_submission(>gt->uc) &&
+   timeout > GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS) {
+   timeout = GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS;
+   drm_info(>i915->drm, "Warning, clamping pre-emption 
timeout to %lld to prevent possibly overflow\n",
+timeout);
+   }
+
WRITE_ONCE(engine->props.preempt_timeout_ms, timeout);
 
if (READ_ONCE(engine->execlists.pending[0]))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6a4612a852e2..ad131092f8df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -248,6 +248,15 @@ struct guc_lrc_desc {
 
 #define GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US 50
 
+/*
+ * GuC converts the timeout to clock ticks internally. Different platforms have
+ * different GuC clocks. Thus, the maximum value before overflow is platform
+ * dependent. Current worst case scenario is about 110s. So, limit to 100s to 
be
+ * safe.
+ */
+#define GUC_POLICY_MAX_EXEC_QUANTUM_MS (100 * 1000)
+#define GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS  (100 * 1000)
+
 struct guc_policies {
u32 submission_queue_depth[GUC_MAX_ENGINE_CLASSES];
/* In micro seconds. How much time to allow before DPC processing is
-- 
2.25.1

[Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

[John . C . Harrison]

From: John Harrison 

Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission as
the heartbeat is a full GT reset rather than a per engine reset and so
is much more destructive. Instead, just bump the pre-emption timeout
to a big value. Also, update the heartbeat to allow such a long
pre-emption delay in the final heartbeat period.

Signed-off-by: John Harrison 


John Harrison (3):
  drm/i915/guc: Limit scheduling properties to avoid overflow
  drm/i915/gt: Make the heartbeat play nice with long pre-emption
timeouts
  drm/i915: Improve long running OCL w/a for GuC submission

 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 37 +--
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 16 
 drivers/gpu/drm/i915/gt/sysfs_engines.c   | 14 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  9 +
 4 files changed, 73 insertions(+), 3 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] [PATCH 2/8] drm/i915/guc: Add an explicit 'submission_initialized' flag

[Ceraolo Spurio, Daniele]

On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

The LRC descriptor pool is going away. So, stop using it as a check
for whether submission has been initialised or not.

Signed-off-by: John Harrison 


grep confirmed those are the only places we use the pool that way, so:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +---
  2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d779de16613..568eb6352ef0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -137,6 +137,8 @@ struct intel_guc {
bool submission_supported;
/** @submission_selected: tracks whether the user enabled GuC 
submission */
bool submission_selected;
+   /** @submission_initialized: tracks whether GuC submission has been 
initialised */
+   bool submission_initialized;
/**
 * @rc_supported: tracks whether we support GuC rc on the current 
platform
 */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7fb889e14995..11bf56b5a266 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -511,7 +511,7 @@ static void guc_lrc_desc_pool_destroy(struct intel_guc *guc)
  
  static inline bool guc_submission_initialized(struct intel_guc *guc)

  {
-   return !!guc->lrc_desc_pool_vaddr;
+   return guc->submission_initialized;
  }
  
  static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)

@@ -1813,7 +1813,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
int ret;
  
-	if (guc->lrc_desc_pool)

+   if (guc->submission_initialized)
return 0;
  
  	ret = guc_lrc_desc_pool_create(guc);

@@ -1845,19 +1845,21 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_DELAYED_WORK(>timestamp.work, guc_timestamp_ping);
guc->timestamp.ping_delay = (POLL_TIME_CLKS / gt->clock_frequency + 1) 
* HZ;
guc->timestamp.shift = gpm_timestamp_shift(gt);
+   guc->submission_initialized = true;
  
  	return 0;

  }
  
  void intel_guc_submission_fini(struct intel_guc *guc)

  {
-   if (!guc->lrc_desc_pool)
+   if (!guc->submission_initialized)
return;
  
  	guc_flush_destroyed_contexts(guc);

guc_lrc_desc_pool_destroy(guc);
i915_sched_engine_put(guc->sched_engine);
bitmap_free(guc->submission_state.guc_ids_bitmap);
+   guc->submission_initialized = false;
  }
  
  static inline void queue_request(struct i915_sched_engine *sched_engine,

Re: [Intel-gfx] [PATCH v3 16/16] drm/i915/guc: Remove plain ads_blob pointer

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:47AM -0800, Lucas De Marchi wrote:
> Now we have the access to content of GuC ADS either using iosys_map
> API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
> be updates using the bare pointer anymore.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc.h | 3 +--
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 8 
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index f857e9190750..bf7079480d47 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -147,8 +147,7 @@ struct intel_guc {
>  
>   /** @ads_vma: object allocated to hold the GuC ADS */
>   struct i915_vma *ads_vma;
> - /** @ads_blob: contents of the GuC ADS */
> - struct __guc_ads_blob *ads_blob;
> + /** @ads_map: contents of the GuC ADS */
>   struct iosys_map ads_map;
>   /** @ads_regset_size: size of the save/restore regsets in the ADS */
>   u32 ads_regset_size;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index d0593063c0dc..847e00390b00 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -667,6 +667,7 @@ static void __guc_ads_init(struct intel_guc *guc)
>   */
>  int intel_guc_ads_create(struct intel_guc *guc)
>  {
> + void *ads_blob;
>   u32 size;
>   int ret;
>  
> @@ -691,14 +692,14 @@ int intel_guc_ads_create(struct intel_guc *guc)
>   size = guc_ads_blob_size(guc);
>  
>   ret = intel_guc_allocate_and_map_vma(guc, size, >ads_vma,
> -  (void **)>ads_blob);
> +  _blob);
>   if (ret)
>   return ret;
>  
>   if (i915_gem_object_is_lmem(guc->ads_vma->obj))
> - iosys_map_set_vaddr_iomem(>ads_map, (void __iomem 
> *)guc->ads_blob);
> + iosys_map_set_vaddr_iomem(>ads_map, (void __iomem 
> *)ads_blob);
>   else
> - iosys_map_set_vaddr(>ads_map, guc->ads_blob);
> + iosys_map_set_vaddr(>ads_map, ads_blob);
>  
>   __guc_ads_init(guc);
>  
> @@ -720,7 +721,6 @@ void intel_guc_ads_init_late(struct intel_guc *guc)
>  void intel_guc_ads_destroy(struct intel_guc *guc)
>  {
>   i915_vma_unpin_and_release(>ads_vma, I915_VMA_RELEASE_MAP);
> - guc->ads_blob = NULL;
>   iosys_map_clear(>ads_map);
>   kfree(guc->ads_regset);
>  }
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration

[Ceraolo Spurio, Daniele]

On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).

Also, rename the set/clear/query helper functions for context id
mappings to better reflect their purpose and to differentiate from
other registration related helper functions.

Signed-off-by: John Harrison 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
  1 file changed, 38 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0d..7fb889e14995 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -514,31 +514,20 @@ static inline bool guc_submission_initialized(struct 
intel_guc *guc)
return !!guc->lrc_desc_pool_vaddr;
  }
  
-static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)

+static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
  {
-   if (likely(guc_submission_initialized(guc))) {
-   struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
-   unsigned long flags;
-
-   memset(desc, 0, sizeof(*desc));
+   struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
  
-		/*

-* xarray API doesn't have xa_erase_irqsave wrapper, so calling
-* the lower level functions directly.
-*/
-   xa_lock_irqsave(>context_lookup, flags);
-   __xa_erase(>context_lookup, id);
-   xa_unlock_irqrestore(>context_lookup, flags);
-   }
+   memset(desc, 0, sizeof(*desc));
  }
  
-static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)

+static inline bool ctx_id_mapped(struct intel_guc *guc, u32 id)
  {
return __get_context(guc, id);
  }
  
-static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,

-  struct intel_context *ce)
+static inline void set_ctx_id_mapping(struct intel_guc *guc, u32 id,
+ struct intel_context *ce)
  {
unsigned long flags;
  
@@ -551,6 +540,24 @@ static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,

xa_unlock_irqrestore(>context_lookup, flags);
  }
  
+static inline void clr_ctx_id_mapping(struct intel_guc *guc, u32 id)

+{
+   unsigned long flags;
+
+   if (unlikely(!guc_submission_initialized(guc)))
+   return;
+
+   _reset_lrc_desc(guc, id);
+
+   /*
+* xarray API doesn't have xa_erase_irqsave wrapper, so calling
+* the lower level functions directly.
+*/
+   xa_lock_irqsave(>context_lookup, flags);
+   __xa_erase(>context_lookup, id);
+   xa_unlock_irqrestore(>context_lookup, flags);
+}
+
  static void decr_outstanding_submission_g2h(struct intel_guc *guc)
  {
if (atomic_dec_and_test(>outstanding_submission_g2h))
@@ -795,7 +802,7 @@ static int __guc_wq_item_append(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>guc_id.ref));
GEM_BUG_ON(context_guc_id_invalid(ce));
GEM_BUG_ON(context_wait_for_deregister_to_register(ce));
-   GEM_BUG_ON(!lrc_desc_registered(ce_to_guc(ce), ce->guc_id.id));
+   GEM_BUG_ON(!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id));
  
  	/* Insert NOOP if this work queue item will wrap the tail pointer. */

if (wqi_size > wq_space_until_wrap(ce)) {
@@ -923,7 +930,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
if (submit) {
struct intel_context *ce = request_to_scheduling_context(last);
  
-		if (unlikely(!lrc_desc_registered(guc, ce->guc_id.id) &&

+   if (unlikely(!ctx_id_mapped(guc, ce->guc_id.id) &&
 !intel_context_is_banned(ce))) {
ret = guc_lrc_desc_pin(ce, false);
if (unlikely(ret == -EPIPE)) {
@@ -1897,7 +1904,7 @@ static bool need_tasklet(struct intel_guc *guc, struct 
i915_request *rq)
  
  	return submission_disabled(guc) || guc->stalled_request ||

!i915_sched_engine_is_empty(sched_engine) ||
-   !lrc_desc_registered(guc, ce->guc_id.id);
+   !ctx_id_mapped(guc, ce->guc_id.id);
  }
  
  static void guc_submit_request(struct i915_request *rq)

@@ -1954,7 +1961,7 @@ static void __release_guc_id(struct intel_guc *guc, 
struct intel_context *ce)
else
ida_simple_remove(>submission_state.guc_ids,
  ce->guc_id.id);
-   reset_lrc_desc(guc, ce->guc_id.id);
+   clr_ctx_id_mapping(guc, ce->guc_id.id);
set_context_guc_id_invalid(ce);
}
if 

Re: [Intel-gfx] [PATCH v3 15/16] drm/i915/guc: Convert __guc_ads_init to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:46AM -0800, Lucas De Marchi wrote:
> Now that all the called functions from __guc_ads_init() are converted to
> use ads_map, stop using ads_blob in __guc_ads_init().
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 25 --
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 90cbb93a2945..d0593063c0dc 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -608,7 +608,6 @@ static void __guc_ads_init(struct intel_guc *guc)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
>   struct drm_i915_private *i915 = gt->i915;
> - struct __guc_ads_blob *blob = guc->ads_blob;
>   struct iosys_map info_map = IOSYS_MAP_INIT_OFFSET(>ads_map,
>   offsetof(struct __guc_ads_blob, system_info));
>   u32 base;
> @@ -619,17 +618,18 @@ static void __guc_ads_init(struct intel_guc *guc)
>   /* System info */
>   fill_engine_enable_masks(gt, _map);
>  
> - 
> blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_SLICE_ENABLED] =
> - hweight8(gt->info.sseu.slice_mask);
> - 
> blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_VDBOX_SFC_SUPPORT_MASK]
>  =
> - gt->info.vdbox_sfc_access;
> + ads_blob_write(guc, 
> system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_SLICE_ENABLED],
> +hweight8(gt->info.sseu.slice_mask));
> + ads_blob_write(guc, 
> system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_VDBOX_SFC_SUPPORT_MASK],
> +gt->info.vdbox_sfc_access);
>  
>   if (GRAPHICS_VER(i915) >= 12 && !IS_DGFX(i915)) {
>   u32 distdbreg = intel_uncore_read(gt->uncore,
> GEN12_DIST_DBS_POPULATED);
> - 
> blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI]
>  =
> - ((distdbreg >> GEN12_DOORBELLS_PER_SQIDI_SHIFT) &
> -  GEN12_DOORBELLS_PER_SQIDI) + 1;
> + ads_blob_write(guc,
> +
> system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI],
> +((distdbreg >> GEN12_DOORBELLS_PER_SQIDI_SHIFT)
> + & GEN12_DOORBELLS_PER_SQIDI) + 1);
>   }
>  
>   /* Golden contexts for re-initialising after a watchdog reset */
> @@ -643,14 +643,17 @@ static void __guc_ads_init(struct intel_guc *guc)
>   guc_capture_list_init(guc);
>  
>   /* ADS */
> - blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> - blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
> + ads_blob_write(guc, ads.scheduler_policies, base +
> +offsetof(struct __guc_ads_blob, policies));
> + ads_blob_write(guc, ads.gt_system_info, base +
> +offsetof(struct __guc_ads_blob, system_info));
>  
>   /* MMIO save/restore list */
>   guc_mmio_reg_state_init(guc);
>  
>   /* Private Data */
> - blob->ads.private_data = base + guc_ads_private_data_offset(guc);
> + ads_blob_write(guc, ads.private_data, base +
> +guc_ads_private_data_offset(guc));
>  
>   i915_gem_object_flush_map(guc->ads_vma->obj);
>  }
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH v3 14/16] drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:45AM -0800, Lucas De Marchi wrote:
> Now that the regset list is prepared, convert guc_mmio_reg_state_init()
> to use iosys_map to copy the array to the final location and
> initialize additional fields in ads.reg_state_list.
> 
> v2: Just use an offset instead of temporary iosys_map.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 28 --
>  1 file changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index ec0ccdf98dfa..90cbb93a2945 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -383,40 +383,44 @@ static long guc_mmio_reg_state_create(struct intel_guc 
> *guc)
>   return ret;
>  }
>  
> -static void guc_mmio_reg_state_init(struct intel_guc *guc,
> - struct __guc_ads_blob *blob)
> +static void guc_mmio_reg_state_init(struct intel_guc *guc)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
>   struct intel_engine_cs *engine;
> - struct guc_mmio_reg *ads_registers;
>   enum intel_engine_id id;
>   u32 addr_ggtt, offset;
>  
>   offset = guc_ads_regset_offset(guc);
>   addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
> - ads_registers = (struct guc_mmio_reg *)(((u8 *)blob) + offset);
>  
> - memcpy(ads_registers, guc->ads_regset, guc->ads_regset_size);
> + iosys_map_memcpy_to(>ads_map, offset, guc->ads_regset,
> + guc->ads_regset_size);
>  
>   for_each_engine(engine, gt, id) {
>   u32 count = guc->ads_regset_count[id];
> - struct guc_mmio_reg_set *ads_reg_set;
>   u8 guc_class;
>  
>   /* Class index is checked in class converter */
>   GEM_BUG_ON(engine->instance >= GUC_MAX_INSTANCES_PER_CLASS);
>  
>   guc_class = engine_class_to_guc_class(engine->class);
> - ads_reg_set = 
> >ads.reg_state_list[guc_class][engine->instance];
>  
>   if (!count) {
> - ads_reg_set->address = 0;
> - ads_reg_set->count = 0;
> + ads_blob_write(guc,
> +
> ads.reg_state_list[guc_class][engine->instance].address,
> +0);
> + ads_blob_write(guc,
> +
> ads.reg_state_list[guc_class][engine->instance].count,
> +0);
>   continue;
>   }
>  
> - ads_reg_set->address = addr_ggtt;
> - ads_reg_set->count = count;
> + ads_blob_write(guc,
> +
> ads.reg_state_list[guc_class][engine->instance].address,
> +addr_ggtt);
> + ads_blob_write(guc,
> +
> ads.reg_state_list[guc_class][engine->instance].count,
> +count);
>  
>   addr_ggtt += count * sizeof(struct guc_mmio_reg);
>   }
> @@ -643,7 +647,7 @@ static void __guc_ads_init(struct intel_guc *guc)
>   blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
>  
>   /* MMIO save/restore list */
> - guc_mmio_reg_state_init(guc, blob);
> + guc_mmio_reg_state_init(guc);
>  
>   /* Private Data */
>   blob->ads.private_data = base + guc_ads_private_data_offset(guc);
> -- 
> 2.35.1
> 

[Intel-gfx] [PATCH] drm/i915/rps/tgl+: Remove RPS interrupt support

[José Roberto de Souza]

TGL+ and newer platforms don't support RPS up and low interruption
limits.
It is not used for broadwell and newer plaforms that supports
execlist but here making sure that it is explicit not used even in
debug scenarios.

BSpec: 33301
BSpec: 52069
BSpec: 9520
HSD: 1405911647
Cc: Vinay Belgaumkar 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fd95449ed46da..c8124101aada2 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1486,7 +1486,7 @@ void intel_rps_enable(struct intel_rps *rps)
 
if (has_busy_stats(rps))
intel_rps_set_timer(rps);
-   else if (GRAPHICS_VER(i915) >= 6)
+   else if (GRAPHICS_VER(i915) >= 6 && GRAPHICS_VER(i915) <= 11)
intel_rps_set_interrupts(rps);
else
/* Ironlake currently uses intel_ips.ko */ {}
-- 
2.35.1

Re: [Intel-gfx] [PATCH v3 13/16] drm/i915/guc: Convert capture list to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:44AM -0800, Lucas De Marchi wrote:
> Use iosys_map to write the fields ads.capture_*.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index c3c31b679e79..ec0ccdf98dfa 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -580,7 +580,7 @@ static void guc_init_golden_context(struct intel_guc *guc)
>   GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
>  }
>  
> -static void guc_capture_list_init(struct intel_guc *guc, struct 
> __guc_ads_blob *blob)
> +static void guc_capture_list_init(struct intel_guc *guc)
>  {
>   int i, j;
>   u32 addr_ggtt, offset;
> @@ -592,11 +592,11 @@ static void guc_capture_list_init(struct intel_guc 
> *guc, struct __guc_ads_blob *
>  
>   for (i = 0; i < GUC_CAPTURE_LIST_INDEX_MAX; i++) {
>   for (j = 0; j < GUC_MAX_ENGINE_CLASSES; j++) {
> - blob->ads.capture_instance[i][j] = addr_ggtt;
> - blob->ads.capture_class[i][j] = addr_ggtt;
> + ads_blob_write(guc, ads.capture_instance[i][j], 
> addr_ggtt);
> + ads_blob_write(guc, ads.capture_class[i][j], addr_ggtt);
>   }
>  
> - blob->ads.capture_global[i] = addr_ggtt;
> + ads_blob_write(guc, ads.capture_global[i], addr_ggtt);
>   }
>  }
>  
> @@ -636,7 +636,7 @@ static void __guc_ads_init(struct intel_guc *guc)
>   base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>  
>   /* Capture list for hang debug */
> - guc_capture_list_init(guc, blob);
> + guc_capture_list_init(guc);
>  
>   /* ADS */
>   blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Chris Wilson]

Quoting Janusz Krzysztofik (2022-02-18 17:08:41)
> Hi Chris,
> 
> On Friday, 18 February 2022 17:03:01 CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> > > @@ -206,15 +229,19 @@ static struct pci_device 
> > > *__igt_device_get_pci_device(int fd)
> > > igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
> > >  pci_addr.domain, pci_addr.bus,
> > >  pci_addr.device, pci_addr.function);
> > > -   return NULL;
> > > +   goto cleanup;
> > > }
> > >  
> > > if (pci_device_probe(pci_dev)) {
> > > igt_warn("Couldn't probe PCI device\n");
> > > -   return NULL;
> > > +   goto cleanup;
> > > }
> > >  
> > > return pci_dev;
> > > +
> > > +cleanup:
> > > +   pci_system_cleanup();
> > 
> > This is a global cleanup of libpciaccess iirc, such that if anyone else
> > was using the library they would be affected.
> 
> Right, but shouldn't we also drop pci_system_init() from here and request 
> users to manage initialization and cleanup of that data themselves?  On each 
> call pci_system_init() abandons existing data and overwrites a pointer to it 
> with that of newly allocated memory, then tests calling 
> igt_device_get_pci_device() multiple times are going to suffer from 
> significant memory leaking.

Right, I thought it only inited once -- I just remember the issue with
calling pci_system_cleanup() while others were still using it.

Stick the call to init in an __attribute__((constructor)) or pthread_once.
-Chris

Re: [Intel-gfx] [PATCH v3 12/16] drm/i915/guc: Convert mapping table to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:43AM -0800, Lucas De Marchi wrote:
> Use iosys_map to write the fields system_info.mapping_table[][].
> Since we already have the info_map around where needed, just use it
> instead of going through guc->ads_map.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index b739781bd133..c3c31b679e79 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -204,7 +204,7 @@ int intel_guc_global_policies_update(struct intel_guc 
> *guc)
>  }
>  
>  static void guc_mapping_table_init(struct intel_gt *gt,
> -struct guc_gt_system_info *system_info)
> +struct iosys_map *info_map)
>  {
>   unsigned int i, j;
>   struct intel_engine_cs *engine;
> @@ -213,14 +213,14 @@ static void guc_mapping_table_init(struct intel_gt *gt,
>   /* Table must be set to invalid values for entries not used */
>   for (i = 0; i < GUC_MAX_ENGINE_CLASSES; ++i)
>   for (j = 0; j < GUC_MAX_INSTANCES_PER_CLASS; ++j)
> - system_info->mapping_table[i][j] =
> - GUC_MAX_INSTANCES_PER_CLASS;
> + info_map_write(info_map, mapping_table[i][j],
> +GUC_MAX_INSTANCES_PER_CLASS);
>  
>   for_each_engine(engine, gt, id) {
>   u8 guc_class = engine_class_to_guc_class(engine->class);
>  
> - 
> system_info->mapping_table[guc_class][ilog2(engine->logical_mask)] =
> - engine->instance;
> + info_map_write(info_map, 
> mapping_table[guc_class][ilog2(engine->logical_mask)],
> +engine->instance);
>   }
>  }
>  
> @@ -631,7 +631,7 @@ static void __guc_ads_init(struct intel_guc *guc)
>   /* Golden contexts for re-initialising after a watchdog reset */
>   guc_prep_golden_context(guc);
>  
> - guc_mapping_table_init(guc_to_gt(guc), >system_info);
> + guc_mapping_table_init(guc_to_gt(guc), _map);
>  
>   base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>  
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH v3 11/16] drm/i915/guc: Replace check for golden context size

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:42AM -0800, Lucas De Marchi wrote:
> In the other places in this function, guc->ads_map is being protected
> from access when it's not yet set. However the last check is actually
> about guc->ads_golden_ctxt_size been set before.  These checks should
> always match as the size is initialized on the first call to
> guc_prep_golden_context(), but it's clearer if we have a single return
> and check for guc->ads_golden_ctxt_size.
> 
> This is just a readability improvement, no change in behavior.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 0077a63832ad..b739781bd133 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -500,10 +500,10 @@ static int guc_prep_golden_context(struct intel_guc 
> *guc)
>   addr_ggtt += alloc_size;
>   }
>  
> - if (iosys_map_is_null(>ads_map))
> - return total_size;
> + /* Make sure current size matches what we calculated previously */
> + if (guc->ads_golden_ctxt_size)
> + GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
>  
> - GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
>   return total_size;
>  }
>  
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH v3 09/16] drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map

[Matthew Brost]

On Wed, Feb 16, 2022 at 09:41:40AM -0800, Lucas De Marchi wrote:
> Use iosys_map_memset() to zero the private data as ADS may be either
> on system or IO memory.
> 
> Cc: Matt Roper 
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Daniele Ceraolo Spurio 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index c61648ef3920..d924486490c1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -714,8 +714,8 @@ static void guc_ads_private_data_reset(struct intel_guc 
> *guc)
>   if (!size)
>   return;
>  
> - memset((void *)guc->ads_blob + guc_ads_private_data_offset(guc), 0,
> -size);
> + iosys_map_memset(>ads_map, guc_ads_private_data_offset(guc),
> +  0, size);
>  }
>  
>  /**
> -- 
> 2.35.1
> 

Re: [Intel-gfx] [PATCH] drm/i915/gt: use get_reset_domain() helper

[Rodrigo Vivi]

On Thu, Feb 17, 2022 at 06:02:23PM +0530, Tejas Upadhyay wrote:
> We dont need to implement reset_domain in intel_engine
> _setup(), but can be done as a helper. Implemented as
> engine->reset_domain = get_reset_domain().
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Tejas Upadhyay 

it is a good non-functional clean-up in the engine setup function and we
will need this soon to be called from more other places, so:

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 74 +--
>  1 file changed, 42 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index e53008b4dd05..e855c801ba28 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -293,6 +293,46 @@ static void nop_irq_handler(struct intel_engine_cs 
> *engine, u16 iir)
>   GEM_DEBUG_WARN_ON(iir);
>  }
>  
> +static u32 get_reset_domain(u8 ver, enum intel_engine_id id)
> +{
> + u32 reset_domain;
> +
> + if (ver >= 11) {
> + static const u32 engine_reset_domains[] = {
> + [RCS0]  = GEN11_GRDOM_RENDER,
> + [BCS0]  = GEN11_GRDOM_BLT,
> + [VCS0]  = GEN11_GRDOM_MEDIA,
> + [VCS1]  = GEN11_GRDOM_MEDIA2,
> + [VCS2]  = GEN11_GRDOM_MEDIA3,
> + [VCS3]  = GEN11_GRDOM_MEDIA4,
> + [VCS4]  = GEN11_GRDOM_MEDIA5,
> + [VCS5]  = GEN11_GRDOM_MEDIA6,
> + [VCS6]  = GEN11_GRDOM_MEDIA7,
> + [VCS7]  = GEN11_GRDOM_MEDIA8,
> + [VECS0] = GEN11_GRDOM_VECS,
> + [VECS1] = GEN11_GRDOM_VECS2,
> + [VECS2] = GEN11_GRDOM_VECS3,
> + [VECS3] = GEN11_GRDOM_VECS4,
> + };
> + GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||
> +!engine_reset_domains[id]);
> + reset_domain = engine_reset_domains[id];
> + } else {
> + static const u32 engine_reset_domains[] = {
> + [RCS0]  = GEN6_GRDOM_RENDER,
> + [BCS0]  = GEN6_GRDOM_BLT,
> + [VCS0]  = GEN6_GRDOM_MEDIA,
> + [VCS1]  = GEN8_GRDOM_MEDIA2,
> + [VECS0] = GEN6_GRDOM_VECS,
> + };
> + GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||
> +!engine_reset_domains[id]);
> + reset_domain = engine_reset_domains[id];
> + }
> +
> + return reset_domain;
> +}
> +
>  static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id,
> u8 logical_instance)
>  {
> @@ -328,38 +368,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> intel_engine_id id,
>   engine->id = id;
>   engine->legacy_idx = INVALID_ENGINE;
>   engine->mask = BIT(id);
> - if (GRAPHICS_VER(gt->i915) >= 11) {
> - static const u32 engine_reset_domains[] = {
> - [RCS0]  = GEN11_GRDOM_RENDER,
> - [BCS0]  = GEN11_GRDOM_BLT,
> - [VCS0]  = GEN11_GRDOM_MEDIA,
> - [VCS1]  = GEN11_GRDOM_MEDIA2,
> - [VCS2]  = GEN11_GRDOM_MEDIA3,
> - [VCS3]  = GEN11_GRDOM_MEDIA4,
> - [VCS4]  = GEN11_GRDOM_MEDIA5,
> - [VCS5]  = GEN11_GRDOM_MEDIA6,
> - [VCS6]  = GEN11_GRDOM_MEDIA7,
> - [VCS7]  = GEN11_GRDOM_MEDIA8,
> - [VECS0] = GEN11_GRDOM_VECS,
> - [VECS1] = GEN11_GRDOM_VECS2,
> - [VECS2] = GEN11_GRDOM_VECS3,
> - [VECS3] = GEN11_GRDOM_VECS4,
> - };
> - GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||
> -!engine_reset_domains[id]);
> - engine->reset_domain = engine_reset_domains[id];
> - } else {
> - static const u32 engine_reset_domains[] = {
> - [RCS0]  = GEN6_GRDOM_RENDER,
> - [BCS0]  = GEN6_GRDOM_BLT,
> - [VCS0]  = GEN6_GRDOM_MEDIA,
> - [VCS1]  = GEN8_GRDOM_MEDIA2,
> - [VECS0] = GEN6_GRDOM_VECS,
> - };
> - GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) ||
> -!engine_reset_domains[id]);
> - engine->reset_domain = engine_reset_domains[id];
> - }
> + engine->reset_domain = get_reset_domain(GRAPHICS_VER(gt->i915),
> + id);
>   engine->i915 = i915;
>   engine->gt = gt;
>   engine->uncore = gt->uncore;
> -- 
> 2.34.1
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Refactor ADS access to use iosys_map (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev4)
URL   : https://patchwork.freedesktop.org/series/99711/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11250 -> Patchwork_22334


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 43)
--

  Additional (2): fi-apl-guc fi-kbl-8809g 
  Missing(4): fi-bsw-cyan shard-rkl shard-dg1 shard-tglu 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@debugfs_test@read_all_entries:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][2] ([i915#1610])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-apl-guc/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][3] ([i915#4962]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-kbl-8809g/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271]) +54 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6600u:   NOTRUN -> [FAIL][7] ([i915#579])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-skl-6600u/igt@i915_pm_...@module-reload.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-skl-6600u:   NOTRUN -> [SKIP][10] ([fdo#109271]) +18 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-skl-6600u/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-apl-guc: NOTRUN -> [FAIL][11] ([i915#2426] / [i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-apl-guc/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][12] ([i915#2426] / [i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

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

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [FAIL][15] ([i915#4547]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22334/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
 Warnings 

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

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

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Refactor ADS access to use iosys_map (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev4)
URL   : https://patchwork.freedesktop.org/series/99711/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Refactor ADS access to use iosys_map (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev4)
URL   : https://patchwork.freedesktop.org/series/99711/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
554203971464 iosys-map: Add offset to iosys_map_memcpy_to()
5a68a5465b0a iosys-map: Add a few more helpers
-:103: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'map_' may be better as 
'(map_)' to avoid precedence issues
#103: FILE: include/linux/iosys-map.h:156:
+#define IOSYS_MAP_INIT_OFFSET(map_, offset_) ({
\
+   struct iosys_map copy = *map_;  \
+   iosys_map_incr(, offset_); \
+   copy;   \
+})

-:258: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'struct_offset__' may be 
better as '(struct_offset__)' to avoid precedence issues
#258: FILE: include/linux/iosys-map.h:432:
+#define iosys_map_rd_field(map__, struct_offset__, struct_type__, field__) ({  
\
+   struct_type__ *s;   
\
+   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__));   
\
+})

-:258: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'struct_type__' may be better 
as '(struct_type__)' to avoid precedence issues
#258: FILE: include/linux/iosys-map.h:432:
+#define iosys_map_rd_field(map__, struct_offset__, struct_type__, field__) ({  
\
+   struct_type__ *s;   
\
+   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__));   
\
+})

-:258: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'field__' - possible 
side-effects?
#258: FILE: include/linux/iosys-map.h:432:
+#define iosys_map_rd_field(map__, struct_offset__, struct_type__, field__) ({  
\
+   struct_type__ *s;   
\
+   iosys_map_rd(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__));   
\
+})

-:279: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'struct_offset__' may be 
better as '(struct_offset__)' to avoid precedence issues
#279: FILE: include/linux/iosys-map.h:453:
+#define iosys_map_wr_field(map__, struct_offset__, struct_type__, field__, 
val__) ({   \
+   struct_type__ *s;   
\
+   iosys_map_wr(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__), val__);
\
+})

-:279: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'struct_type__' may be better 
as '(struct_type__)' to avoid precedence issues
#279: FILE: include/linux/iosys-map.h:453:
+#define iosys_map_wr_field(map__, struct_offset__, struct_type__, field__, 
val__) ({   \
+   struct_type__ *s;   
\
+   iosys_map_wr(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__), val__);
\
+})

-:279: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'field__' - possible 
side-effects?
#279: FILE: include/linux/iosys-map.h:453:
+#define iosys_map_wr_field(map__, struct_offset__, struct_type__, field__, 
val__) ({   \
+   struct_type__ *s;   
\
+   iosys_map_wr(map__, struct_offset__ + offsetof(struct_type__, field__), 
\
+typeof(s->field__), val__);
\
+})

total: 0 errors, 0 warnings, 7 checks, 217 lines checked
5aed3fa10ede drm/i915/gt: Add helper for shmem copy to iosys_map
f7aaba839570 drm/i915/guc: Keep iosys_map of ads_blob around
4156cb519230 drm/i915/guc: Add read/write helpers for ADS blob
e71bbda4bf0f drm/i915/guc: Convert golden context init to iosys_map
49375cce81e4 drm/i915/guc: Convert policies update to iosys_map
234c1edc8ec8 drm/i915/guc: Convert engine record to iosys_map
13c3dafcbb9c drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map
e2af5d8aae81 drm/i915/guc: Convert golden context prep to iosys_map
0a9faaccb3d3 drm/i915/guc: Replace check for golden context size
6518310edc43 drm/i915/guc: Convert mapping table to iosys_map
cd0f41c2e8ba drm/i915/guc: Convert capture list to iosys_map
dea23b4eadd0 drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map
62befe7c758b drm/i915/guc: Convert __guc_ads_init to iosys_map
-:42: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:623:
+   ads_blob_write(guc, 
system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_VDBOX_SFC_SUPPORT_MASK],

-:52: 

Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support

[Jordan Justen]

Ramalingam C  writes:

> On 2022-02-18 at 18:06:00 +, Robert Beckett wrote:
>> 
>> If desired, we can make the wording clearer, maybe something like:
>> 
>> "To keep things simple for userland, we mandate that any GTT mappings
>> must be aligned to 2MB. The kernel will internally pad them out to the next
>> 2MB boundary"
>
> Added the extra information in next version @
> https://patchwork.freedesktop.org/patch/475166/?series=100419=1
>
> Jordan, hope this explanation clears your doubt.

Ok. It sounds like what we are doing in Mesa matches what is required by
hardware and the kernel. Thanks.

-Jordan

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable DG2

[Patchwork]

== Series Details ==

Series: drm/i915: Enable DG2
URL   : https://patchwork.freedesktop.org/series/100419/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11250 -> Patchwork_22333


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 41)
--

  Additional (2): fi-apl-guc fi-kbl-8809g 
  Missing(6): shard-tglu bat-dg2-8 fi-bsw-cyan fi-pnv-d510 shard-rkl 
shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- fi-apl-guc: NOTRUN -> [DMESG-WARN][1] ([i915#1610])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-apl-guc/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][2] ([i915#4962]) +1 similar 
issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-kbl-8809g/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   NOTRUN -> [INCOMPLETE][3] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271]) +54 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][7] -> [DMESG-FAIL][8] ([i915#5026])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-blb-e6850/igt@i915_selftest@l...@requests.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
- fi-cfl-8109u:   [PASS][12] -> [DMESG-FAIL][13] ([i915#295])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [PASS][15] -> [DMESG-WARN][16] ([i915#295]) +10 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- bat-dg1-5:  [PASS][17] -> [FAIL][18] ([fdo#103375])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/bat-dg1-5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/bat-dg1-5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@runner@aborted:
- fi-blb-e6850:   NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-blb-e6850/igt@run...@aborted.html
- fi-apl-guc: NOTRUN -> [FAIL][20] ([i915#2426] / [i915#4312])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22333/fi-apl-guc/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}:   [INCOMPLETE][21] ([i915#4898]) -> [PASS][22]
   [21]: 

Re: [Intel-gfx] [PATCH 01/15] drm/i915/dg2: Define GuC firmware version for DG2

[Ceraolo Spurio, Daniele]

On 2/18/2022 10:47 AM, Ramalingam C wrote:

From: John Harrison 

First release of GuC for DG2.

Signed-off-by: John Harrison 
CC: Tomasz Mistat 
CC: Ramalingam C 
CC: Daniele Ceraolo Spurio 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index c88113044494..55512db29183 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -52,6 +52,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
   * firmware as TGL.
   */
  #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(DG2,  0, guc_def(dg2,  69, 0, 3)) \
fw_def(ALDERLAKE_P,  0, guc_def(adlp, 69, 0, 3)) \
fw_def(ALDERLAKE_S,  0, guc_def(tgl,  69, 0, 3)) \
fw_def(DG1,  0, guc_def(dg1,  69, 0, 3)) \

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Enable DG2

[Patchwork]

== Series Details ==

Series: drm/i915: Enable DG2
URL   : https://patchwork.freedesktop.org/series/100419/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enable DG2

[Patchwork]

== Series Details ==

Series: drm/i915: Enable DG2
URL   : https://patchwork.freedesktop.org/series/100419/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ecf3a6aabe11 drm/i915/dg2: Define GuC firmware version for DG2
9d7f9f8a3467 drm/i915: Fix for PHY_MISC_TC1 offset
-:49: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'port' - possible 
side-effects?
#49: FILE: drivers/gpu/drm/i915/i915_reg.h:9366:
+#define DG2_PHY_MISC(port) ((port) == PHY_E ? _MMIO(_DG2_PHY_MISC_TC1) : \
+ICL_PHY_MISC(port))

total: 0 errors, 0 warnings, 1 checks, 20 lines checked
fa0f06c942c8 drm/i915/dg2: Drop 38.4 MHz MPLLB tables
fa9afbc030e6 drm/i915/dg2: Enable 5th port
b8a7971164dc drm/i915: add needs_compact_pt flag
34bad68c9936 drm/i915: enforce min GTT alignment for discrete cards
-:304: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#304: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:458:
+   if (offset < hole_start + 
aligned_size)

-:316: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#316: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:482:
+   if (offset + aligned_size > 
hole_end)

-:334: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#334: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:498:
+   if (offset < hole_start + 
aligned_size)

-:346: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#346: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:521:
+   if (offset + aligned_size > 
hole_end)

-:364: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#364: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:537:
+   if (offset < hole_start + 
aligned_size)

-:376: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#376: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:561:
+   if (offset + aligned_size > 
hole_end)

-:394: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#394: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:577:
+   if (offset < hole_start + 
aligned_size)

-:406: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code 
refactoring
#406: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:600:
+   if (offset + aligned_size > 
hole_end)

total: 0 errors, 8 warnings, 0 checks, 438 lines checked
2a36c620cd9c drm/i915: support 64K GTT pages for discrete cards
fcbf93599a67 drm/i915: add gtt misalignment test
c23f3ce9db9e drm/i915/gtt: allow overriding the pt alignment
720fb0c9e82d drm/i915/gtt: add xehpsdv_ppgtt_insert_entry
4f1f68863bfa drm/i915/migrate: add acceleration support for DG2
ce72b8e0634a drm/i915/uapi: document behaviour for DG2 64K support
eb2aa0aafb5a drm/i915/xehpsdv: Add has_flat_ccs to device info
f94b70011b2d drm/i915/lmem: Enable lmem for platforms with Flat CCS
96e999374594 drm/i915/gt: Clear compress metadata for Xe_HP platforms

Re: [Intel-gfx] [PATCH v5 00/19] drm/i915/dg2: Enabling 64k page size and flat ccs

[Ramalingam C]

Just a note here. To enable the dg2 with basic support sooner on CI we
have taken a subset of this series separtely at
https://patchwork.freedesktop.org/series/100419/

Remaining patches will be pursued on top the above series. Thanks for
the review comments. We will fix them working with reviewers. Thanks.

Ram.

On 2022-02-01 at 16:11:13 +0530, Ramalingam C wrote:
> This series introduces the enabling patches for new memory compression
> feature Flat CCS and 64k page support for i915 local memory, along with
> documentation on the uAPI impact. Included the details of the feature and
> the implications on the uAPI below. Which is also added into
> Documentation/gpu/rfc/i915_dg2.rst
> 
> DG2 64K page size support:
> =
> 
> On discrete platforms, starting from DG2, we have to contend with GTT
> page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> objects.  Specifically the hardware only supports 64K or larger GTT
> page sizes for such memory. The kernel will already ensure that all
> I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> sizes underneath.
> 
> Note that the returned size here will always reflect any required
> rounding up done by the kernel, i.e 4K will now become 64K on devices
> such as DG2.
> 
> Special DG2 GTT address alignment requirement:
> 
> The GTT alignment will also need to be at least 2M for such objects.
> 
> Note that due to how the hardware implements 64K GTT page support, we
> have some further complications:
> 
> 1) The entire PDE (which covers a 2MB virtual address range), must
> contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> PDE is forbidden by the hardware.
> 
> 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> objects.
> 
> To keep things simple for userland, we mandate that any GTT mappings
> must be aligned to and rounded up to 2MB. As this only wastes virtual
> address space and avoids userland having to copy any needlessly
> complicated PDE sharing scheme (coloring) and only affects DG2, this
> is deemed to be a good compromise.
> 
> Flat CCS support for lmem
> =
> On Xe-HP and later devices, we use dedicated compression control state
> (CCS) stored in local memory for each surface, to support the 3D and
> media compression formats.
> 
> The memory required for the CCS of the entire local memory is 1/256 of
> the local memory size. So before the kernel boot, the required memory is
> reserved for the CCS data and a secure register will be programmed with
> the CCS base address.
> 
> Flat CCS data needs to be cleared when a lmem object is allocated. And
> CCS data can be copied in and out of CCS region through
> XY_CTRL_SURF_COPY_BLT. CPU can’t access the CCS data directly.
> 
> When we exaust the lmem, if the object’s placements support smem, then
> we can directly decompress the compressed lmem object into smem and
> start using it from smem itself.
> 
> But when we need to swapout the compressed lmem object into a smem
> region though objects’ placement doesn’t support smem, then we copy the
> lmem content as it is into smem region along with ccs data (using
> XY_CTRL_SURF_COPY_BLT). When the object is referred, lmem content will
> be swaped in along with restoration of the CCS data (using
> XY_CTRL_SURF_COPY_BLT) at corresponding location.
> 
> Flat-CCS Modifiers for different compression formats
> 
> I915_FORMAT_MOD_4_TILED_DG2_RC_CCS - used to indicate the buffers of
> Flat CCS render compression formats. Though the general layout is same
> as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression
> algorithm is used. Render compression uses 128 byte compression blocks
> 
> I915_FORMAT_MOD_4_TILED_DG2_MC_CCS -used to indicate the buffers of Flat
> CCS media compression formats. Though the general layout is same as
> I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm
> is used. Media compression uses 256 byte compression blocks.
> 
> I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC - used to indicate the buffers of
> Flat CCS clear color render compression formats. Unified compression
> format for clear color render compression. The genral layout is a tiled
> layout using 4Kb tiles i.e Tile4 layout. Fast clear color value expected
> by HW is located in fb at offset 0 of plane#1
> 
> v2:
>   Fixed some formatting issues and platform naming issues
>   Added some more documentation on Flat-CCS
> 
> v3:
>   Plane programming is handled for flat-ccs and clear color
>   Tile4 and flat ccs modifier patches are rebased on table based
> modifier reference method
>   Three patches are squashed
>   Y tile is pruned for DG2.
>   flat_ccs_cc plane format info is added
>   Added mesa, compute and media ppl for required uAPI ack.
> 
> v4:
>   Rebasing of the patches
> 
> v5:
>   KDoc is enhanced for cc modifier. [Nanley & Lionel]
>   inbuild macro usage for functional fix [Bob]
>   Addressed 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: SAGV fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: SAGV fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/100091/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22327_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-kbl:  NOTRUN -> [DMESG-WARN][4] ([i915#5076])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-kbl3/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][5] ([i915#2846])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-kbl3/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-kbl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-kbl6/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl7/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl8/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3323])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl9/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk2/igt@kms_big...@x-tiled-32bpp-rotate-180.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-glk6/igt@kms_big...@x-tiled-32bpp-rotate-180.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#3743]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl8/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_big_fb@yf-tiled-16bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111615])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-tglb3/igt@kms_big...@yf-tiled-16bpp-rotate-270.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-apl2/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3777]) +4 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22327/shard-skl8/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html

  * 

Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support

[Ramalingam C]

On 2022-02-18 at 18:06:00 +, Robert Beckett wrote:
> 
> 
> On 18/02/2022 13:47, Ramalingam C wrote:
> > On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> > > Robert Beckett  writes:
> > > 
> > > > From: Matthew Auld 
> > > > 
> > > > On discrete platforms like DG2, we need to support a minimum page size
> > > > of 64K when dealing with device local-memory. This is quite tricky for
> > > > various reasons, so try to document the new implicit uapi for this.
> > > > 
> > > > v3: fix typos and less emphasis
> > > > v2: Fixed suggestions on formatting [Daniel]
> > > > 
> > > > Signed-off-by: Matthew Auld 
> > > > Signed-off-by: Ramalingam C 
> > > > Signed-off-by: Robert Beckett 
> > > > Acked-by: Jordan Justen 
> > > > Reviewed-by: Ramalingam C 
> > > > Reviewed-by: Thomas Hellström 
> > > > cc: Simon Ser 
> > > > cc: Pekka Paalanen 
> > > > Cc: Jordan Justen 
> > > > Cc: Kenneth Graunke 
> > > > Cc: mesa-...@lists.freedesktop.org
> > > > Cc: Tony Ye 
> > > > Cc: Slawomir Milczarek 
> > > > ---
> > > >   include/uapi/drm/i915_drm.h | 44 -
> > > >   1 file changed, 39 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 5e678917da70..77e5e74c32c1 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > > > /**
> > > >  * When the EXEC_OBJECT_PINNED flag is specified this is 
> > > > populated by
> > > >  * the user with the GTT offset at which this object will be 
> > > > pinned.
> > > > +*
> > > >  * When the I915_EXEC_NO_RELOC flag is specified this must 
> > > > contain the
> > > >  * presumed_offset of the object.
> > > > +*
> > > >  * During execbuffer2 the kernel populates it with the value of 
> > > > the
> > > >  * current GTT offset of the object, for future presumed_offset 
> > > > writes.
> > > > +*
> > > > +* See struct drm_i915_gem_create_ext for the rules when 
> > > > dealing with
> > > > +* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on 
> > > > devices with
> > > > +* minimum page sizes, like DG2.
> > > >  */
> > > > __u64 offset;
> > > > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > > >  *
> > > >  * The (page-aligned) allocated size for the object will be 
> > > > returned.
> > > >  *
> > > > -* Note that for some devices we have might have further minimum
> > > > -* page-size restrictions(larger than 4K), like for device 
> > > > local-memory.
> > > > -* However in general the final size here should always reflect 
> > > > any
> > > > -* rounding up, if for example using the 
> > > > I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > > > -* extension to place the object in device local-memory.
> > > > +*
> > > > +* DG2 64K min page size implications:
> > > > +*
> > > > +* On discrete platforms, starting from DG2, we have to contend 
> > > > with GTT
> > > > +* page size restrictions when dealing with 
> > > > I915_MEMORY_CLASS_DEVICE
> > > > +* objects.  Specifically the hardware only supports 64K or 
> > > > larger GTT
> > > > +* page sizes for such memory. The kernel will already ensure 
> > > > that all
> > > > +* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or 
> > > > larger page
> > > > +* sizes underneath.
> > > > +*
> > > > +* Note that the returned size here will always reflect any 
> > > > required
> > > > +* rounding up done by the kernel, i.e 4K will now become 64K 
> > > > on devices
> > > > +* such as DG2.
> > > > +*
> > > > +* Special DG2 GTT address alignment requirement:
> > > > +*
> > > > +* The GTT alignment will also need to be at least 2M for such 
> > > > objects.
> > > > +*
> > > > +* Note that due to how the hardware implements 64K GTT page 
> > > > support, we
> > > > +* have some further complications:
> > > > +*
> > > > +*   1) The entire PDE (which covers a 2MB virtual address 
> > > > range), must
> > > > +*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the 
> > > > same
> > > > +*   PDE is forbidden by the hardware.
> > > > +*
> > > > +*   2) We still need to support 4K PTEs for 
> > > > I915_MEMORY_CLASS_SYSTEM
> > > > +*   objects.
> > > > +*
> > > > +* To keep things simple for userland, we mandate that any GTT 
> > > > mappings
> > > > +* must be aligned to and rounded up to 2MB.
> > > 
> > > Could I get a clarification about this "rounded up" part.
> > > 
> > > Currently Mesa is aligning the start of each and every buffer VMA to be
> > > 2MiB aligned. But, we are *not* taking any 

[Intel-gfx] [PATCH 15/15] drm/i915/gt: Clear compress metadata for Xe_HP platforms

[Ramalingam C]

From: Ayaz A Siddiqui 

Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.

Flat CCS memory can not be directly accessed by S/W.
Address of CCS buffer associated main BO is automatically calculated
by device itself. KMD/UMD can only access this buffer indirectly using
XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.

v2: Fixed issues with platform naming [Lucas]
v3: Rebased [Ram]
Used the round_up funcs [Bob]
v4: Fixed ccs blk calculation [Ram]
Added Kdoc on flat-ccs.

Cc: CQ Tang 
Signed-off-by: Ayaz A Siddiqui 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  15 ++
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 145 ++-
 2 files changed, 156 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..166de5436c4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -203,6 +203,21 @@
 #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
 #define GFX_OP_DRAWRECT_INFO_I965  ((0x7900<<16)|0x2)
 
+#define XY_CTRL_SURF_INSTR_SIZE5
+#define MI_FLUSH_DW_SIZE   3
+#define XY_CTRL_SURF_COPY_BLT  ((2 << 29) | (0x48 << 22) | 3)
+#define   SRC_ACCESS_TYPE_SHIFT21
+#define   DST_ACCESS_TYPE_SHIFT20
+#define   CCS_SIZE_SHIFT   8
+#define   XY_CTRL_SURF_MOCS_SHIFT  25
+#define   NUM_CCS_BYTES_PER_BLOCK  256
+#define   NUM_BYTES_PER_CCS_BYTE   256
+#define   NUM_CCS_BLKS_PER_XFER1024
+#define   INDIRECT_ACCESS  0
+#define   DIRECT_ACCESS1
+#define  MI_FLUSH_LLC  BIT(9)
+#define  MI_FLUSH_CCS  BIT(16)
+
 #define COLOR_BLT_CMD  (2 << 29 | 0x40 << 22 | (5 - 2))
 #define XY_COLOR_BLT_CMD   (2 << 29 | 0x50 << 22)
 #define SRC_COPY_BLT_CMD   (2 << 29 | 0x43 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 20444d6ceb3c..9f9cd2649377 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -16,6 +16,8 @@ struct insert_pte_data {
 };
 
 #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
+#define GET_CCS_BYTES(i915, size)  (HAS_FLAT_CCS(i915) ? \
+DIV_ROUND_UP(size, 
NUM_BYTES_PER_CCS_BYTE) : 0)
 
 static bool engine_supports_migration(struct intel_engine_cs *engine)
 {
@@ -467,6 +469,113 @@ static bool wa_1209644611_applies(int ver, u32 size)
return height % 4 == 3 && height <= 8;
 }
 
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is 
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we 
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem 
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ */
+
+static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
+{
+   /* Mask the 3 LSB to use the PPGTT address space */
+   *cmd++ = MI_FLUSH_DW | flags;
+   *cmd++ = lower_32_bits(dst);
+   *cmd++ = upper_32_bits(dst);
+
+   return cmd;
+}
+
+static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
+{
+   u32 num_cmds, num_blks, total_size;
+
+   if (!GET_CCS_BYTES(i915, size))
+   return 0;
+
+   /*
+* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
+* blocks. one XY_CTRL_SURF_COPY_BLT command can
+* trnasfer upto 1024 blocks.
+*/
+   num_blks = DIV_ROUND_UP(GET_CCS_BYTES(i915, size),
+   NUM_CCS_BYTES_PER_BLOCK);
+   num_cmds = 

[Intel-gfx] [PATCH 14/15] drm/i915/lmem: Enable lmem for platforms with Flat CCS

[Ramalingam C]

From: Abdiel Janulgue 

A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”.
So to get effective device memory we need to subtract
total device memory by Flat CCS memory size.

v2:
  Addressed the small bar related issue [Matt]
  Removed a reduntant check [Matt]
v3:
  reg addr def is moved to intel_gt_regs.h [Lucas]
  removed a variable
  s/DRM_ERROR/drm_err [Lucas]

Cc: Matthew Auld 
Signed-off-by: Abdiel Janulgue 
Signed-off-by: Ramalingam C 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_gt.c  | 19 +++
 drivers/gpu/drm/i915/gt/intel_gt.h  |  1 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  3 +++
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 26 +++--
 4 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e8403fa53909..2da7dd0f66d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -913,6 +913,25 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt, 
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
 }
 
+u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg)
+{
+   int type;
+   u8 sliceid, subsliceid;
+
+   for (type = 0; type < NUM_STEERING_TYPES; type++) {
+   if (intel_gt_reg_needs_read_steering(gt, reg, type)) {
+   intel_gt_get_valid_steering(gt, type, ,
+   );
+   return intel_uncore_read_with_mcr_steering(gt->uncore,
+  reg,
+  sliceid,
+  subsliceid);
+   }
+   }
+
+   return intel_uncore_read(gt->uncore, reg);
+}
+
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 2dad46c3eff2..0f571c8ee22b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -85,6 +85,7 @@ static inline bool intel_gt_needs_read_steering(struct 
intel_gt *gt,
 }
 
 u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
+u32 intel_gt_read_register(struct intel_gt *gt, i915_reg_t reg);
 
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index bf4b942c62ee..935ba793a13b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -906,6 +906,9 @@
 #define XEHP_L3NODEARBCFG  _MMIO(0xb0b4)
 #define   XEHP_LNESPAREREG_BIT(19)
 
+#define XEHPSDV_FLAT_CCS_BASE_ADDR _MMIO(0x4910)
+#define   XEHPSDV_CCS_BASE_SHIFT   8
+
 #define GEN8_L3SQCREG1 _MMIO(0xb100)
 /*
  * Note that on CHV the following has an off-by-one error wrt. to BSpec.
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index cb3f66707b21..f3f0ce2c553a 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -12,6 +12,7 @@
 #include "gem/i915_gem_region.h"
 #include "gem/i915_gem_ttm.h"
 #include "gt/intel_gt.h"
+#include "gt/intel_gt_regs.h"
 
 static int init_fake_lmem_bar(struct intel_memory_region *mem)
 {
@@ -206,8 +207,29 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
if (!IS_DGFX(i915))
return ERR_PTR(-ENODEV);
 
-   /* Stolen starts from GSMBASE on DG1 */
-   lmem_size = intel_uncore_read64(uncore, GEN12_GSMBASE);
+   if (HAS_FLAT_CCS(i915)) {
+   u64 tile_stolen, flat_ccs_base;
+
+   lmem_size = pci_resource_len(pdev, 2);
+   flat_ccs_base = intel_gt_read_register(gt, 
XEHPSDV_FLAT_CCS_BASE_ADDR);
+   flat_ccs_base = (flat_ccs_base >> XEHPSDV_CCS_BASE_SHIFT) * 
SZ_64K;
+
+   if (GEM_WARN_ON(lmem_size < flat_ccs_base))
+   return ERR_PTR(-ENODEV);
+
+   tile_stolen = lmem_size - flat_ccs_base;
+
+   /* If the FLAT_CCS_BASE_ADDR register is not populated, flag an 
error */
+   if (tile_stolen == lmem_size)
+   drm_err(>drm,
+   "CCS_BASE_ADDR register did not have expected 
value\n");
+
+   lmem_size -= tile_stolen;
+   } else {
+   /* Stolen starts from GSMBASE without CCS */
+   lmem_size = intel_uncore_read64(>uncore, GEN12_GSMBASE);
+   }
+
 
   

[Intel-gfx] [PATCH 12/15] drm/i915/uapi: document behaviour for DG2 64K support

[Ramalingam C]

From: Matthew Auld 

On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.

v4: Kdoc modification.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Acked-by: Jordan Justen 
Reviewed-by: Ramalingam C 
Reviewed-by: Thomas Hellström 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
 include/uapi/drm/i915_drm.h | 45 -
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 914ebd9290e5..05c3642aaece 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
 * When the EXEC_OBJECT_PINNED flag is specified this is populated by
 * the user with the GTT offset at which this object will be pinned.
+*
 * When the I915_EXEC_NO_RELOC flag is specified this must contain the
 * presumed_offset of the object.
+*
 * During execbuffer2 the kernel populates it with the value of the
 * current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
 */
__u64 offset;
 
@@ -3144,11 +3150,40 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects.  Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+*   1) The entire PDE (which covers a 2MB virtual address range), must
+*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+*   PDE is forbidden by the hardware.
+*
+*   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+*   objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. The kernel will internally
+* pad them out to the next 2MB boundary. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
 */
__u64 size;
/**
-- 
2.20.1

[Intel-gfx] [PATCH 13/15] drm/i915/xehpsdv: Add has_flat_ccs to device info

[Ramalingam C]

From: CQ Tang 

Platforms of XeHP and beyond support 3D surface (buffer) compression and
various compression formats. This is accomplished by an additional
compression control state (CCS) stored for each surface.

Gen 12 devices(TGL family and DG1) stores compression states in a separate
region of memory. It is managed by user-space and has an associated set of
user-space managed page tables used by hardware for address translation.

In Xe HP and beyond (XEHPSDV, DG2, etc), there is a new feature introduced
i.e Flat CCS. It replaced AUX page tables with a flat indexed region of
device memory for storing compression states.

Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Signed-off-by: CQ Tang 
Signed-off-by: Ramalingam C 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  | 6 ++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a3ac66e777a..1c2f4ae4ebf9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1356,6 +1356,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
 #define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
 
+/*
+ * Platform has the dedicated compression control state for each lmem surfaces
+ * stored in lmem to support the 3D and media compression formats.
+ */
+#define HAS_FLAT_CCS(dev_priv)   (INTEL_INFO(dev_priv)->has_flat_ccs)
+
 #define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
 
 #define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 8df8887d76ae..f449c454b6f8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1005,6 +1005,7 @@ static const struct intel_device_info adl_p_info = {
XE_HP_PAGE_SIZES, \
.dma_mask_size = 46, \
.has_64bit_reloc = 1, \
+   .has_flat_ccs = 1, \
.has_global_mocs = 1, \
.has_gt_uc = 1, \
.has_llc = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index f75673da768d..2508a47fb3f5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -134,6 +134,7 @@ enum intel_ppgtt_type {
func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
+   func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_guc_deprivilege); \
-- 
2.20.1

[Intel-gfx] [PATCH 11/15] drm/i915/migrate: add acceleration support for DG2

[Ramalingam C]

From: Matthew Auld 

This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).

v2(Ram)
  - Document the ppGTT layout and add a better description for the
different windows.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
Reviewed-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 196 
 1 file changed, 164 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 18b44af56969..20444d6ceb3c 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -32,6 +32,38 @@ static bool engine_supports_migration(struct intel_engine_cs 
*engine)
return true;
 }
 
+static void xehpsdv_toggle_pdes(struct i915_address_space *vm,
+   struct i915_page_table *pt,
+   void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* Insert a dummy PTE into every PT that will map to LMEM to ensure
+* we have a correctly setup PDE structure for later use.
+*/
+   vm->insert_page(vm, 0, d->offset, I915_CACHE_NONE, PTE_LM);
+   GEM_BUG_ON(!pt->is_compact);
+   d->offset += SZ_2M;
+}
+
+static void xehpsdv_insert_pte(struct i915_address_space *vm,
+  struct i915_page_table *pt,
+  void *data)
+{
+   struct insert_pte_data *d = data;
+
+   /*
+* We are playing tricks here, since the actual pt, from the hw
+* pov, is only 256bytes with 32 entries, or 4096bytes with 512
+* entries, but we are still guaranteed that the physical
+* alignment is 64K underneath for the pt, and we are careful
+* not to access the space in the void.
+*/
+   vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE, PTE_LM);
+   d->offset += SZ_64K;
+}
+
 static void insert_pte(struct i915_address_space *vm,
   struct i915_page_table *pt,
   void *data)
@@ -74,7 +106,32 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * i.e. within the same non-preemptible window so that we do not switch
 * to another migration context that overwrites the PTE.
 *
-* TODO: Add support for huge LMEM PTEs
+* This changes quite a bit on platforms with HAS_64K_PAGES support,
+* where we instead have three windows, each CHUNK_SIZE in size. The
+* first is reserved for mapping system-memory, and that just uses the
+* 512 entry layout using 4K GTT pages. The other two windows just map
+* lmem pages and must use the new compact 32 entry layout using 64K GTT
+* pages, which ensures we can address any lmem object that the user
+* throws at us. We then also use the xehpsdv_toggle_pdes as a way of
+* just toggling the PDE bit(GEN12_PDE_64K) for us, to enable the
+* compact layout for each of these page-tables, that fall within the
+* [CHUNK_SIZE, 3 * CHUNK_SIZE) range.
+*
+* We lay the ppGTT out as:
+*
+* [0, CHUNK_SZ) -> first window/object, maps smem
+* [CHUNK_SZ, 2 * CHUNK_SZ) -> second window/object, maps lmem src
+* [2 * CHUNK_SZ, 3 * CHUNK_SZ) -> third window/object, maps lmem dst
+*
+* For the PTE window it's also quite different, since each PTE must
+* point to some 64K page, one for each PT(since it's in lmem), and yet
+* each is only <= 4096bytes, but since the unused space within that PTE
+* range is never touched, this should be fine.
+*
+* So basically each PT now needs 64K of virtual memory, instead of 4K,
+* which looks like:
+*
+* [3 * CHUNK_SZ, 3 * CHUNK_SZ + ((3 * CHUNK_SZ / SZ_2M) * SZ_64K)] -> 
PTE
 */
 
vm = i915_ppgtt_create(gt, I915_BO_ALLOC_PM_EARLY);
@@ -86,6 +143,9 @@ static struct i915_address_space *migrate_vm(struct intel_gt 
*gt)
goto err_vm;
}
 
+   if (HAS_64K_PAGES(gt->i915))
+   stash.pt_sz = I915_GTT_PAGE_SIZE_64K;
+
/*
 * Each engine instance is assigned its own chunk in the VM, so
 * that we can run multiple instances concurrently
@@ -105,14 +165,20 @@ static struct i915_address_space *migrate_vm(struct 
intel_gt *gt)
 * We copy in 8MiB chunks. Each PDE covers 2MiB, so we need
 * 4x2 page directories for source/destination.
 */
-   sz = 2 * CHUNK_SZ;
+   if (HAS_64K_PAGES(gt->i915))
+   sz = 3 * CHUNK_SZ;
+   else
+   sz = 2 * CHUNK_SZ;
d.offset = base + sz;
 
/*
 * We need another page directory setup so that 

[Intel-gfx] [PATCH 05/15] drm/i915: add needs_compact_pt flag

[Ramalingam C]

Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.

With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.

v6:
* minor doc formatting

Suggested-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_drv.h  | 11 ---
 drivers/gpu/drm/i915/i915_pci.c  |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f600d1cb01b3..4a3ac66e777a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1340,12 +1340,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 /*
  * Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
  */
 #define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
 
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
 #define HAS_IPC(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ipc)
 
 #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 91677a9f330c..8df8887d76ae 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1030,6 +1030,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1048,6 +1049,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+   .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 27dcfe6f2429..f75673da768d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -131,6 +131,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+   func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
-- 
2.20.1

[Intel-gfx] [PATCH 09/15] drm/i915/gtt: allow overriding the pt alignment

[Ramalingam C]

From: Matthew Auld 

On some platforms we have alignment restrictions when accessing LMEM
from the GTT. In the next few patches we need to be able to modify the
page-tables directly via the GTT itself.

Suggested-by: Ramalingam C 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
Reviewed-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 10 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c | 16 
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 5e038cef0d9f..9d83c2d3959c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -200,6 +200,14 @@ void *__px_vaddr(struct drm_i915_gem_object *p);
 struct i915_vm_pt_stash {
/* preallocated chains of page tables/directories */
struct i915_page_table *pt[2];
+   /*
+* Optionally override the alignment/size of the physical page that
+* contains each PT. If not set defaults back to the usual
+* I915_GTT_PAGE_SIZE_4K. This does not influence the other paging
+* structures. MUST be a power-of-two. ONLY applicable on discrete
+* platforms.
+*/
+   int pt_sz;
 };
 
 struct i915_vma_ops {
@@ -595,7 +603,7 @@ void free_scratch(struct i915_address_space *vm);
 
 struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int 
sz);
 struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int 
sz);
-struct i915_page_table *alloc_pt(struct i915_address_space *vm);
+struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz);
 struct i915_page_directory *alloc_pd(struct i915_address_space *vm);
 struct i915_page_directory *__alloc_pd(int npde);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 043652dc6892..d91e2beb7517 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -12,7 +12,7 @@
 #include "gen6_ppgtt.h"
 #include "gen8_ppgtt.h"
 
-struct i915_page_table *alloc_pt(struct i915_address_space *vm)
+struct i915_page_table *alloc_pt(struct i915_address_space *vm, int sz)
 {
struct i915_page_table *pt;
 
@@ -20,7 +20,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space 
*vm)
if (unlikely(!pt))
return ERR_PTR(-ENOMEM);
 
-   pt->base = vm->alloc_pt_dma(vm, I915_GTT_PAGE_SIZE_4K);
+   pt->base = vm->alloc_pt_dma(vm, sz);
if (IS_ERR(pt->base)) {
kfree(pt);
return ERR_PTR(-ENOMEM);
@@ -221,17 +221,25 @@ int i915_vm_alloc_pt_stash(struct i915_address_space *vm,
   u64 size)
 {
unsigned long count;
-   int shift, n;
+   int shift, n, pt_sz;
 
shift = vm->pd_shift;
if (!shift)
return 0;
 
+   pt_sz = stash->pt_sz;
+   if (!pt_sz)
+   pt_sz = I915_GTT_PAGE_SIZE_4K;
+   else
+   GEM_BUG_ON(!IS_DGFX(vm->i915));
+
+   GEM_BUG_ON(!is_power_of_2(pt_sz));
+
count = pd_count(size, shift);
while (count--) {
struct i915_page_table *pt;
 
-   pt = alloc_pt(vm);
+   pt = alloc_pt(vm, pt_sz);
if (IS_ERR(pt)) {
i915_vm_free_pt_stash(vm, stash);
return PTR_ERR(pt);
-- 
2.20.1

[Intel-gfx] [PATCH 10/15] drm/i915/gtt: add xehpsdv_ppgtt_insert_entry

[Ramalingam C]

From: Matthew Auld 

If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Ramalingam C 
Reviewed-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 50 ++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 62471730266c..f574da00eff1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -715,13 +715,56 @@ static void gen8_ppgtt_insert_entry(struct 
i915_address_space *vm,
gen8_pdp_for_page_index(vm, idx);
struct i915_page_directory *pd =
i915_pd_entry(pdp, gen8_pd_index(idx, 2));
+   struct i915_page_table *pt = i915_pt_entry(pd, gen8_pd_index(idx, 1));
gen8_pte_t *vaddr;
 
-   vaddr = px_vaddr(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
+   GEM_BUG_ON(pt->is_compact);
+
+   vaddr = px_vaddr(pt);
vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
clflush_cache_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
 }
 
+static void __xehpsdv_ppgtt_insert_entry_lm(struct i915_address_space *vm,
+   dma_addr_t addr,
+   u64 offset,
+   enum i915_cache_level level,
+   u32 flags)
+{
+   u64 idx = offset >> GEN8_PTE_SHIFT;
+   struct i915_page_directory * const pdp =
+   gen8_pdp_for_page_index(vm, idx);
+   struct i915_page_directory *pd =
+   i915_pd_entry(pdp, gen8_pd_index(idx, 2));
+   struct i915_page_table *pt = i915_pt_entry(pd, gen8_pd_index(idx, 1));
+   gen8_pte_t *vaddr;
+
+   GEM_BUG_ON(!IS_ALIGNED(addr, SZ_64K));
+   GEM_BUG_ON(!IS_ALIGNED(offset, SZ_64K));
+
+   if (!pt->is_compact) {
+   vaddr = px_vaddr(pd);
+   vaddr[gen8_pd_index(idx, 1)] |= GEN12_PDE_64K;
+   pt->is_compact = true;
+   }
+
+   vaddr = px_vaddr(pt);
+   vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+}
+
+static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
+  dma_addr_t addr,
+  u64 offset,
+  enum i915_cache_level level,
+  u32 flags)
+{
+   if (flags & PTE_LM)
+   return __xehpsdv_ppgtt_insert_entry_lm(vm, addr, offset,
+  level, flags);
+
+   return gen8_ppgtt_insert_entry(vm, addr, offset, level, flags);
+}
+
 static int gen8_init_scratch(struct i915_address_space *vm)
 {
u32 pte_flags;
@@ -921,7 +964,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 
ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
-   ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
+   if (HAS_64K_PAGES(gt->i915))
+   ppgtt->vm.insert_page = xehpsdv_ppgtt_insert_entry;
+   else
+   ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
ppgtt->vm.foreach = gen8_ppgtt_foreach;
-- 
2.20.1

[Intel-gfx] [PATCH 08/15] drm/i915: add gtt misalignment test

[Ramalingam C]

From: Robert Beckett 

add test to check handling of misaligned offsets and sizes

v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot 
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* handle stolen smem region returning -ENODEV due to
  uninitialized on some setups
* avoid trying to test bad alignments on single page hole regions

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 126 ++
 1 file changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 0d80509ef3c4..cc814abb0105 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -26,10 +26,12 @@
 #include 
 
 #include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
 #include "gem/i915_gem_internal.h"
 #include "gem/selftests/mock_context.h"
 #include "gt/intel_context.h"
 #include "gt/intel_gpu_commands.h"
+#include "gt/intel_gtt.h"
 
 #include "i915_random.h"
 #include "i915_selftest.h"
@@ -1068,6 +1070,118 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
 }
 
+static int misaligned_case(struct i915_address_space *vm, struct 
intel_memory_region *mr,
+  u64 addr, u64 size, unsigned long flags)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int err = 0;
+   u64 expected_vma_size, expected_node_size;
+   bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+mr->type == INTEL_MEMORY_STOLEN_LOCAL;
+
+   obj = i915_gem_object_create_region(mr, size, 0, 0);
+   if (IS_ERR(obj)) {
+   /* if iGVT-g or DMAR is active, stolen mem will be 
uninitialized */
+   if (PTR_ERR(obj) == -ENODEV && is_stolen)
+   return 0;
+   return PTR_ERR(obj);
+   }
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_put;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, addr | flags);
+   if (err)
+   goto err_put;
+   i915_vma_unpin(vma);
+
+   if (!drm_mm_node_allocated(>node)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+   err = -EINVAL;
+   goto err_put;
+   }
+
+   expected_vma_size = round_up(size, 1 << 
(ffs(vma->resource->page_sizes_gtt) - 1));
+   expected_node_size = expected_vma_size;
+
+   if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+   /* compact-pt should expand lmem node to 2MB */
+   expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+   expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+   }
+
+   if (vma->size != expected_vma_size || vma->node.size != 
expected_node_size) {
+   err = i915_vma_unbind_unlocked(vma);
+   err = -EBADSLT;
+   goto err_put;
+   }
+
+   err = i915_vma_unbind_unlocked(vma);
+   if (err)
+   goto err_put;
+
+   GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+   i915_gem_object_put(obj);
+   cleanup_freed_objects(vm->i915);
+   return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+   struct intel_memory_region *mr;
+   enum intel_region_id id;
+   unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+   int err = 0;
+   u64 hole_size = hole_end - hole_start;
+
+   if (i915_is_ggtt(vm))
+   flags |= PIN_GLOBAL;
+
+   for_each_memory_region(mr, vm->i915, id) {
+   u64 min_alignment = i915_vm_min_alignment(vm, (enum 
intel_memory_type)id);
+   u64 size = min_alignment;
+   u64 addr = round_down(hole_start + (hole_size / 2), 
min_alignment);
+
+   /* avoid -ENOSPC on very small hole setups */
+   if (hole_size < 3 * min_alignment)
+   continue;
+
+   /* we can't test < 4k alignment due to flags being encoded in 
lower bits */
+   if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+   err = misaligned_case(vm, mr, addr + (min_alignment / 
2), size, flags);
+   /* misaligned should error with -EINVAL*/
+   if (!err)
+   err = -EBADSLT;
+   if (err != -EINVAL)
+   return err;
+   }
+
+   /* test 

[Intel-gfx] [PATCH 07/15] drm/i915: support 64K GTT pages for discrete cards

[Ramalingam C]

From: Matthew Auld 

discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.

v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot 

Signed-off-by: Matthew Auld 
Signed-off-by: Stuart Summers 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  60 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 108 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   1 +
 4 files changed, 169 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 8424ee8c5eb8..0528fe1fc9b3 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1479,6 +1479,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
 }
 
+static int igt_ppgtt_compact(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct drm_i915_gem_object *obj;
+   int err;
+
+   /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+   if (!HAS_64K_PAGES(i915)) {
+   pr_info("device lacks compact 64K page support, skipping\n");
+   return 0;
+   }
+
+   if (!HAS_LMEM(i915)) {
+   pr_info("device lacks LMEM support, skipping\n");
+   return 0;
+   }
+
+   /* We want the range to cover multiple page-table boundaries. */
+   obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err)
+   goto out_put;
+
+   if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+   pr_info("LMEM compact unable to allocate huge-page(s)\n");
+   goto out_unpin;
+   }
+
+   /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+   obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+   err = igt_write_huge(i915, obj);
+   if (err)
+   pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+
+   if (err == -ENOMEM)
+   err = 0;
+
+   return err;
+}
+
 static int igt_tmpfs_fallback(void *arg)
 {
struct drm_i915_private *i915 = arg;
@@ -1736,6 +1795,7 @@ int i915_gem_huge_page_live_selftests(struct 
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+   SUBTEST(igt_ppgtt_compact),
};
 
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
   start, end, lvl);
} else {
unsigned int count;
+   unsigned int pte = gen8_pd_index(start, 0);
+   unsigned int num_ptes;
u64 *vaddr;
 
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * 
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
 
+   num_ptes = count;
+   if (pt->is_compact) {
+   GEM_BUG_ON(num_ptes % 16);
+   GEM_BUG_ON(pte % 16);
+   num_ptes /= 16;
+   pte /= 16;
+   }
+
vaddr = px_vaddr(pt);
-   memset64(vaddr + gen8_pd_index(start, 0),
+   memset64(vaddr + pte,
 vm->scratch[0]->encode,
-count);
+num_ptes);
 
  

[Intel-gfx] [PATCH 06/15] drm/i915: enforce min GTT alignment for discrete cards

[Ramalingam C]

From: Matthew Auld 

For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.

We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.

For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.

v3:
* use needs_compact_pt flag to discriminate between
  64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
  if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
  have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
v8:
* i915_vm_min_alignment protect against array overflow for mock region

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 .../i915/gem/selftests/i915_gem_client_blt.c  | 21 ++--
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 12 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 22 +
 drivers/gpu/drm/i915/i915_vma.c   |  9 ++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
 5 files changed, 119 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 8f28e46e8ee5..ddd0772fd828 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -40,6 +40,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+   u64 align;
u32 width;
u32 height;
 };
@@ -411,14 +412,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_free;
}
 
-   hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+   t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+   t->align = max(t->align,
+  i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+   hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
-   hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+   hole_size += 2 * t->align; /* padding on either side */
 
mutex_lock(>ce->vm->mutex);
memset(, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
  0, U64_MAX,
  DRM_MM_INSERT_BEST);
if (!err)
@@ -429,7 +435,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct 
rnd_state *prng)
goto err_put;
}
 
-   t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+   t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
 
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -456,7 +462,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
 static int tiled_blits_prepare(struct tiled_blits *t,
   struct rnd_state *prng)
 {
-   u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+   u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -487,8 +493,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
 
 static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
 {
-   u64 offset =
-   round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+   u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
 
/* We want to check position invariant tiling across GTT eviction */
@@ -501,7 +506,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct 
rnd_state *prng)
 
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+>buffers[2], t->hole + t->align,
 >buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 49a8fb63e6e5..c548c193cd35 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -225,6 +225,18 @@ void i915_address_space_init(struct i915_address_space 
*vm, int subclass)
 
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 

[Intel-gfx] [PATCH 04/15] drm/i915/dg2: Enable 5th port

[Ramalingam C]

From: Matt Roper 

DG2 supports a 5th display output which the hardware refers to as "TC1,"
even though it isn't a Type-C output.  This behaves similarly to the TC1
on past platforms with just a couple minor differences:

 * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on
   ICP/TGP/ADP.
 * DG2 doesn't need the hpd inversion setting that we had to use on DG1

v2:
  intel_ddi_init(dev_priv, PORT_TC1); [Matt]

Cc: Swathi Dhanavanthri 
Cc: Lucas De Marchi 
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
Signed-off-by: Ramalingam C 
Reviewed-by: Lucas De Marchi 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display.c |  1 +
 drivers/gpu/drm/i915/display/intel_gmbus.c   | 16 ++--
 drivers/gpu/drm/i915/i915_irq.c  |  5 -
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 4 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index aaf2aee4da35..69e15ad2c253 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8757,6 +8757,7 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
intel_ddi_init(dev_priv, PORT_D_XELPD);
+   intel_ddi_init(dev_priv, PORT_TC1);
} else if (IS_ALDERLAKE_P(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 6ce8c10fe975..2fad03250661 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -98,11 +98,21 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {
[GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
 };
 
+static const struct gmbus_pin gmbus_pins_dg2[] = {
+   [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
+   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
+   return _pins_dg2[pin];
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
return _pins_dg1[pin];
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
return _pins_icp[pin];
@@ -123,7 +133,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
+   size = ARRAY_SIZE(gmbus_pins_dg2);
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
size = ARRAY_SIZE(gmbus_pins_dg1);
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
size = ARRAY_SIZE(gmbus_pins_icp);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fdd568ba4a16..4d81063b128c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -179,6 +179,7 @@ static const u32 hpd_sde_dg1[HPD_NUM_PINS] = {
[HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
[HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_C),
[HPD_PORT_D] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_D),
+   [HPD_PORT_TC1] = SDE_TC_HOTPLUG_DG2(HPD_PORT_TC1),
 };
 
 static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
@@ -4424,7 +4425,9 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (I915_HAS_HOTPLUG(dev_priv))
dev_priv->hotplug_funcs = _hpd_funcs;
} else {
-   if (HAS_PCH_DG1(dev_priv))
+   if (HAS_PCH_DG2(dev_priv))
+   dev_priv->hotplug_funcs = _hpd_funcs;
+   else if (HAS_PCH_DG1(dev_priv))
dev_priv->hotplug_funcs = _hpd_funcs;
else if (DISPLAY_VER(dev_priv) >= 11)
dev_priv->hotplug_funcs = _hpd_funcs;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc13918fe246..986fb30da9ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6059,6 +6059,7 @@
 /* south display engine interrupt: ICP/TGP */
 #define SDE_GMBUS_ICP  (1 << 23)
 #define SDE_TC_HOTPLUG_ICP(hpd_pin)REG_BIT(24 + _HPD_PIN_TC(hpd_pin))
+#define SDE_TC_HOTPLUG_DG2(hpd_pin)REG_BIT(25 + _HPD_PIN_TC(hpd_pin)) /* 
sigh */
 #define SDE_DDI_HOTPLUG_ICP(hpd_pin)   REG_BIT(16 + _HPD_PIN_DDI(hpd_pin))
 #define SDE_DDI_HOTPLUG_MASK_ICP   

[Intel-gfx] [PATCH 03/15] drm/i915/dg2: Drop 38.4 MHz MPLLB tables

[Ramalingam C]

From: Matt Roper 

Our early understanding of DG2 was incorrect; since the 5th display
isn't actually a Type-C output, 38.4 MHz input clocks are never used on
this platform and we can drop the corresponding MPLLB tables.

Cc: Anusha Srivatsa 
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
Signed-off-by: Ramalingam C 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Uma Shankar 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_snps_phy.c | 208 +-
 1 file changed, 1 insertion(+), 207 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
b/drivers/gpu/drm/i915/display/intel_snps_phy.c
index 4cdce0116883..7e6245b97fed 100644
--- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
@@ -250,197 +250,6 @@ static const struct intel_mpllb_state * const 
dg2_dp_100_tables[] = {
NULL,
 };
 
-/*
- * Basic DP link rates with 38.4 MHz reference clock.
- */
-
-static const struct intel_mpllb_state dg2_dp_rbr_38_4 = {
-   .clock = 162000,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 2),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 304),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 49152),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr1_38_4 = {
-   .clock = 27,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr2_38_4 = {
-   .clock = 54,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr3_38_4 = {
-   .clock = 81,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 6) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 26) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   

[Intel-gfx] [PATCH 02/15] drm/i915: Fix for PHY_MISC_TC1 offset

[Ramalingam C]

From: Jouni Högander 

Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E.
The PORT_TC1 port is not yet enabled properly in the driver, but
intel_phy_snps.c is relying on intel_phy_is_snps() to filter out
unavailable phys. That function was already considering the last phy as
available. Just correct the offset of the last phy to 0x64C14 as the
rest of the support for it is coming on next commits.

Signed-off-by: Matt Roper 
Signed-off-by: Jouni Högander 
Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Lucas De Marchi 
Acked-by: Ville Syrjälä 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
 drivers/gpu/drm/i915/i915_reg.h   | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
b/drivers/gpu/drm/i915/display/intel_snps_phy.c
index 8fd00de981fc..4cdce0116883 100644
--- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
@@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct 
drm_i915_private *i915)
if (!intel_phy_is_snps(i915, phy))
continue;
 
-   if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
+   if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
DG2_PHY_DP_TX_ACK_MASK, 25))
drm_err(>drm, "SNPS PHY %c failed to calibrate 
after 25ms.\n",
phy_name(phy));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e2e9f543fb83..cc13918fe246 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9361,8 +9361,10 @@ enum skl_power_gate {
 
 #define _ICL_PHY_MISC_A0x64C00
 #define _ICL_PHY_MISC_B0x64C04
-#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
-_ICL_PHY_MISC_B)
+#define _DG2_PHY_MISC_TC1  0x64C14 /* TC1="PHY E" but offset as if "PHY F" 
*/
+#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, 
_ICL_PHY_MISC_B)
+#define DG2_PHY_MISC(port) ((port) == PHY_E ? _MMIO(_DG2_PHY_MISC_TC1) : \
+ICL_PHY_MISC(port))
 #define  ICL_PHY_MISC_MUX_DDID (1 << 28)
 #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
 #define  DG2_PHY_DP_TX_ACK_MASKREG_GENMASK(23, 20)
-- 
2.20.1

[Intel-gfx] [PATCH 01/15] drm/i915/dg2: Define GuC firmware version for DG2

[Ramalingam C]

From: John Harrison 

First release of GuC for DG2.

Signed-off-by: John Harrison 
CC: Tomasz Mistat 
CC: Ramalingam C 
CC: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index c88113044494..55512db29183 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -52,6 +52,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  * firmware as TGL.
  */
 #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+   fw_def(DG2,  0, guc_def(dg2,  69, 0, 3)) \
fw_def(ALDERLAKE_P,  0, guc_def(adlp, 69, 0, 3)) \
fw_def(ALDERLAKE_S,  0, guc_def(tgl,  69, 0, 3)) \
fw_def(DG1,  0, guc_def(dg1,  69, 0, 3)) \
-- 
2.20.1

[Intel-gfx] [PATCH 00/15] drm/i915: Enable DG2

[Ramalingam C]

Enabling the Dg2 on drm/i915.

This series adds support for 64k pagesize and documents the uapi
impacts. And also adds basic flat-ccs enabling patches to
support the local memory initialization and object creation. Kdoc is
added to document the Flat-ccs support.

Flat-ccs modifiers will be enabled in upcoming patches.

Note:
This is subset of https://patchwork.freedesktop.org/series/95686/ The
remaining patches of the series will be pursued in subsequent series.

And few patches are reviewed at and pulled from many series like
https://patchwork.freedesktop.org/series/99119/
https://patchwork.freedesktop.org/series/100373/
https://patchwork.freedesktop.org/series/97544/

Abdiel Janulgue (1):
  drm/i915/lmem: Enable lmem for platforms with Flat CCS

Ayaz A Siddiqui (1):
  drm/i915/gt: Clear compress metadata for Xe_HP platforms

CQ Tang (1):
  drm/i915/xehpsdv: Add has_flat_ccs to device info

John Harrison (1):
  drm/i915/dg2: Define GuC firmware version for DG2

Jouni Högander (1):
  drm/i915: Fix for PHY_MISC_TC1 offset

Matt Roper (2):
  drm/i915/dg2: Drop 38.4 MHz MPLLB tables
  drm/i915/dg2: Enable 5th port

Matthew Auld (6):
  drm/i915: enforce min GTT alignment for discrete cards
  drm/i915: support 64K GTT pages for discrete cards
  drm/i915/gtt: allow overriding the pt alignment
  drm/i915/gtt: add xehpsdv_ppgtt_insert_entry
  drm/i915/migrate: add acceleration support for DG2
  drm/i915/uapi: document behaviour for DG2 64K support

Ramalingam C (1):
  drm/i915: add needs_compact_pt flag

Robert Beckett (1):
  drm/i915: add gtt misalignment test

 drivers/gpu/drm/i915/display/intel_display.c  |   1 +
 drivers/gpu/drm/i915/display/intel_gmbus.c|  16 +-
 drivers/gpu/drm/i915/display/intel_snps_phy.c | 210 +--
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  60 
 .../i915/gem/selftests/i915_gem_client_blt.c  |  21 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 158 +++-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  15 +
 drivers/gpu/drm/i915/gt/intel_gt.c|  19 +
 drivers/gpu/drm/i915/gt/intel_gt.h|   1 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  12 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  35 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 337 --
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  17 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  26 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |  17 +-
 drivers/gpu/drm/i915/i915_irq.c   |   5 +-
 drivers/gpu/drm/i915/i915_pci.c   |   3 +
 drivers/gpu/drm/i915/i915_reg.h   |   7 +-
 drivers/gpu/drm/i915/i915_vma.c   |   9 +
 drivers/gpu/drm/i915/intel_device_info.h  |   2 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 222 ++--
 include/uapi/drm/i915_drm.h   |  45 ++-
 24 files changed, 934 insertions(+), 308 deletions(-)

-- 
2.20.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround 
(rev2)
URL   : https://patchwork.freedesktop.org/series/100404/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11250 -> Patchwork_22332


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 40)
--

  Additional (1): fi-kbl-8809g 
  Missing(6): shard-tglu shard-rkl fi-bsw-cyan fi-pnv-d510 fi-blb-e6850 
shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][1] ([i915#4962]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-kbl-8809g/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][2] -> [FAIL][3] ([i915#4547])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g:   NOTRUN -> [SKIP][6] ([fdo#109271]) +54 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-guc: [PASS][7] -> [DMESG-FAIL][8] ([i915#2291] / 
[i915#541])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [PASS][13] -> [DMESG-WARN][14] ([i915#295]) +11 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11250/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22332/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  
 Possible fixes 

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#4962]: https://gitlab.freedesktop.org/drm/intel/issues/4962
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Build changes
-

  * Linux: CI_DRM_11250 -> Patchwork_22332

  

Re: [Intel-gfx] [PATCH 1/2] drm/doc: remove rfc section for dg1

[Lucas De Marchi]

On Fri, Feb 18, 2022 at 11:22:41AM +, Matthew Auld wrote:

We already completed the steps for this.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org


I was indeed wondering why that was still there and why we were going a
similar route with DG2, but this time adding it after the plan completed.

Reviewed-by: Lucas De Marchi 

thanks
Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround 
(rev2)
URL   : https://patchwork.freedesktop.org/series/100404/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support

[Robert Beckett]

On 18/02/2022 13:47, Ramalingam C wrote:

On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:

Robert Beckett  writes:


From: Matthew Auld 

On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.

v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]

Signed-off-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
Acked-by: Jordan Justen 
Reviewed-by: Ramalingam C 
Reviewed-by: Thomas Hellström 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
  include/uapi/drm/i915_drm.h | 44 -
  1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
 * When the EXEC_OBJECT_PINNED flag is specified this is populated by
 * the user with the GTT offset at which this object will be pinned.
+*
 * When the I915_EXEC_NO_RELOC flag is specified this must contain the
 * presumed_offset of the object.
+*
 * During execbuffer2 the kernel populates it with the value of the
 * current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
 */
__u64 offset;
  
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {

 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects.  Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+*   1) The entire PDE (which covers a 2MB virtual address range), must
+*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+*   PDE is forbidden by the hardware.
+*
+*   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+*   objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB.


Could I get a clarification about this "rounded up" part.

Currently Mesa is aligning the start of each and every buffer VMA to be
2MiB aligned. But, we are *not* taking any steps to "round up" the size
of buffers to 2MiB alignment.

Bob's Mesa MR from a while ago,

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599

was trying to add this "round up" size for buffers. We didn't accept
this MR because we thought if we have ensured that no other buffer will
use the same 2MiB VMA range, then it should not be required.

If what we are doing is ok, then maybe this "round up" language should
be dropped? Or, perhaps the "round up" mentioned here isn't implying we
must align the size of buffers that we create, and I'm misinterpreting
this.

Jordan,

as per my understanding this size rounding up to 2MB is for the VMA mapping,
not for the buffer size.

correct, only the vma is rounded up



Even if we drop this rounding up of vma size to 2MB but align the VMA
start to 2MB address then also this should be fine. Becasue the remaining of the
last PDE(2MB) will never be used for any other GTT mapping as the
starting addr wont align to 2MB.
The kernel 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Fix for PHY_MISC_TC1 offset

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Fix for PHY_MISC_TC1 offset
URL   : https://patchwork.freedesktop.org/series/100373/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22326_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-kbl:  NOTRUN -> [DMESG-WARN][4] ([i915#5076])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-kbl4/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][5] ([i915#4547])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl8/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][10] ([fdo#112283])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-iclb8/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@smem-oom:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl9/igt@gem_lmem_swapp...@smem-oom.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl9/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl9/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#2856])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-iclb7/igt@gen9_exec_pa...@allowed-all.html
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / 
[i915#716])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-glk3/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_module_load@reload-with-fault-injection:
- shard-skl:  NOTRUN -> [DMESG-WARN][19] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-kbl1/igt@i915_susp...@forcewake.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-kbl1/igt@i915_susp...@forcewake.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][22] -> [FAIL][23] ([i915#2521])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-skl4/igt@kms_async_fl...@alternate-sync-async-flip.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22326/shard-skl8/igt@kms_async_fl...@alternate-sync-async-flip.html

  * 

Re: [Intel-gfx] [PATCH 06/22] drm/bridge: Use drm_mode_copy()

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Fri, Feb 18, 2022 at 12:03:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list head of
> the destination mode.
> 
> Even if we know the destination mode is not on any list
> using drm_mode_copy() seems decent as it sets a good
> example. Bad examples of not using it might eventually
> get copied into code where preserving the list head
> actually matters.
> 
> Obviously one case not covered here is when the mode
> itself is embedded in a larger structure and the whole
> structure is copied. But if we are careful when copying
> into modes embedded in structures I think we can be a
> little more reassured that bogus list heads haven't been
> propagated in.
> 
> @is_mode_copy@
> @@
> drm_mode_copy(...)
> {
> ...
> }
> 
> @depends on !is_mode_copy@
> struct drm_display_mode *mode;
> expression E, S;
> @@
> (
> - *mode = E
> + drm_mode_copy(mode, )
> |
> - memcpy(mode, E, S)
> + drm_mode_copy(mode, E)
> )
> 
> @depends on !is_mode_copy@
> struct drm_display_mode mode;
> expression E;
> @@
> (
> - mode = E
> + drm_mode_copy(, )
> |
> - memcpy(, E, S)
> + drm_mode_copy(, E)
> )
> 
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
> 
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: Laurent Pinchart 
> Cc: Jonas Karlman 
> Cc: Jernej Skrabec 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/nwl-dsi.c  | 2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>  drivers/gpu/drm/bridge/tc358767.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c 
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 963a6794735f..881cf338d5cf 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -857,7 +857,7 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
>   /* Save the new desired phy config */
>   memcpy(>phy_cfg, _cfg, sizeof(new_cfg));
>  
> - memcpy(>mode, adjusted_mode, sizeof(dsi->mode));
> + drm_mode_copy(>mode, adjusted_mode);
>   drm_mode_debug_printmodeline(adjusted_mode);
>  
>   if (pm_runtime_resume_and_get(dev) < 0)
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 4befc104d220..a563460f8d20 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2830,7 +2830,7 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge 
> *bridge,
>   mutex_lock(>mutex);
>  
>   /* Store the display mode for plugin/DKMS poweron events */
> - memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
> + drm_mode_copy(>previous_mode, mode);
>  
>   mutex_unlock(>mutex);
>  }
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index c23e0abc65e8..7f9574b17caa 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1312,7 +1312,7 @@ static void tc_bridge_mode_set(struct drm_bridge 
> *bridge,
>  {
>   struct tc_data *tc = bridge_to_tc(bridge);
>  
> - tc->mode = *mode;
> + drm_mode_copy(>mode, mode);
>  }
>  
>  static struct edid *tc_get_edid(struct drm_bridge *bridge,

-- 
Regards,

Laurent Pinchart

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Janusz Krzysztofik]

Hi Chris,

On Friday, 18 February 2022 17:03:01 CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> > @@ -206,15 +229,19 @@ static struct pci_device 
> > *__igt_device_get_pci_device(int fd)
> > igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
> >  pci_addr.domain, pci_addr.bus,
> >  pci_addr.device, pci_addr.function);
> > -   return NULL;
> > +   goto cleanup;
> > }
> >  
> > if (pci_device_probe(pci_dev)) {
> > igt_warn("Couldn't probe PCI device\n");
> > -   return NULL;
> > +   goto cleanup;
> > }
> >  
> > return pci_dev;
> > +
> > +cleanup:
> > +   pci_system_cleanup();
> 
> This is a global cleanup of libpciaccess iirc, such that if anyone else
> was using the library they would be affected.

Right, but shouldn't we also drop pci_system_init() from here and request 
users to manage initialization and cleanup of that data themselves?  On each 
call pci_system_init() abandons existing data and overwrites a pointer to it 
with that of newly allocated memory, then tests calling 
igt_device_get_pci_device() multiple times are going to suffer from 
significant memory leaking.

Thanks,
Janusz

> 
> > +   return NULL;
> >  }
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for Prep work for next GuC release (rev2)

[Patchwork]

== Series Details ==

Series: Prep work for next GuC release (rev2)
URL   : https://patchwork.freedesktop.org/series/99805/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22325_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_self_import@export-vs-gem_close-race:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-snb7/igt@prime_self_import@export-vs-gem_close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-snb2/igt@prime_self_import@export-vs-gem_close-race.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#5076])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-kbl3/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_capture@pi@vecs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][6] ([i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl9/igt@gem_exec_capture@p...@vecs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl4/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2849])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl2/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][11] ([i915#2658])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl4/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3323])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl2/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-iclb8/igt@gen9_exec_pa...@allowed-all.html
- shard-glk:  [PASS][14] -> [DMESG-WARN][15] ([i915#1436] / 
[i915#716])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-glk2/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_module_load@reload-with-fault-injection:
- shard-skl:  NOTRUN -> [DMESG-WARN][16] ([i915#1982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-skl3/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][17] -> [INCOMPLETE][18] ([i915#3921])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-snb5/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22325/shard-snb2/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][19] -> [INCOMPLETE][20] ([i915#636])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-kbl1/igt@i915_susp...@forcewake.html
   [20]: 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dg2: Do not use phy E

[Souza, Jose]

On Fri, 2022-02-18 at 01:54 -0800, Lucas De Marchi wrote:
> PORT_TC1 is still not being initialized - that is the port that uses phy
> E.  However the intel_phy_is_snps() reports that phy as being present,
> which causes warnings about unclaimed access to the PHY_MISC register.
> Even with some basic wiring up for that port, it still gives the error:
> 
>   i915 :03:00.0: [drm] *ERROR* SNPS PHY E failed to calibrate after 
> 25ms.
> 
> So remove it for now.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59961621fe4a..c3bb2da9e93a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2148,9 +2148,10 @@ bool intel_phy_is_snps(struct drm_i915_private 
> *dev_priv, enum phy phy)
>   else if (IS_DG2(dev_priv))
>   /*
>* All four "combo" ports and the TC1 port (PHY E) use
> -  * Synopsis PHYs.
> +  * Synopsis PHYs. However the last will only be used when
> +  * PORT_TC1 is enabled.
>*/
> - return phy <= PHY_E;
> + return phy <= PHY_D;
>  
>   return false;
>  }

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915/dsi: disassociate VBT video transfer mode from register values

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915/dsi: disassociate VBT video 
transfer mode from register values
URL   : https://patchwork.freedesktop.org/series/100368/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22324_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][3] ([i915#2846])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-skl4/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2849])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-normal:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk5/igt@gem_exec_whis...@basic-normal.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-glk3/igt@gem_exec_whis...@basic-normal.html

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

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-skl7/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][11] ([i915#2658])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-skl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@y-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#768])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb6/igt@gem_render_c...@y-tiled-to-vebox-yf-tiled.html

  * igt@gem_spin_batch@spin-each:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#2898])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-apl1/igt@gem_spin_ba...@spin-each.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-apl8/igt@gem_spin_ba...@spin-each.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-skl4/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#2856]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb5/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#454])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb6/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_dc@dc9-dpms:
- shard-iclb: [PASS][18] -> [SKIP][19] ([i915#4281])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb5/igt@i915_pm...@dc9-dpms.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-iclb3/igt@i915_pm...@dc9-dpms.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][20] -> [INCOMPLETE][21] ([i915#3921])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-snb5/igt@i915_selftest@l...@hangcheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22324/shard-snb2/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][22] -> [INCOMPLETE][23] ([i915#636])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-kbl1/igt@i915_susp...@forcewake.html
   [23]: 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Chris Wilson]

Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> @@ -206,15 +229,19 @@ static struct pci_device 
> *__igt_device_get_pci_device(int fd)
> igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
>  pci_addr.domain, pci_addr.bus,
>  pci_addr.device, pci_addr.function);
> -   return NULL;
> +   goto cleanup;
> }
>  
> if (pci_device_probe(pci_dev)) {
> igt_warn("Couldn't probe PCI device\n");
> -   return NULL;
> +   goto cleanup;
> }
>  
> return pci_dev;
> +
> +cleanup:
> +   pci_system_cleanup();

This is a global cleanup of libpciaccess iirc, such that if anyone else
was using the library they would be affected.

> +   return NULL;
>  }

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede  
> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede 
>>>  wrote:
>>>
 What I'm reading in the above is that it is being considered to allow
 changing the panel-orientation value after the connector has been made
 available to userspace; and let userspace know about this through a uevent.

 I believe that this is a bad idea, it is important to keep in mind here
 what userspace (e.g. plymouth) uses this prorty for. This property is
 used to rotate the image being rendered / shown on the framebuffer to
 adjust for the panel orientation.

 So now lets assume we apply the correct upside-down orientation later
 on a device with an upside-down mounted LCD panel. Then on boot the
 following could happen:

 1. amdgpu exports a connector for the LCD panel to userspace without
 setting panel-orient=upside-down
 2. plymouth sees this and renders its splash normally, but since the
 panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
 I guess the initial modeline is inherited from the video-bios, but
 what about the physical size? Note that you cannot just change the
 physical size later either, that gets used to determine the hidpi
 scaling factor in the bootsplash, and changing that after the initial
 bootsplash dislay will also look ugly

 b) Why you need the edid for the panel-orientation property at all,
 typically the edid prom is part of the panel and the panel does not
 know that it is mounted e.g. upside down at all, that is a property
 of the system as a whole not of the panel as a standalone unit so
 in my experience getting panel-orient info is something which comes
 from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the 

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser  wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede  
> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede 
> > >  wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a 
> > >> uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go 
> > black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above 

[Intel-gfx] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Janusz Krzysztofik]

The library provides igt_device_get_pci_device() function that allows to
get access to a PCI device from an open DRM device file descriptor.  It
can be used on VF devices as long as a DRM driver is bound to them.
However, SR-IOV tests may want to exercise VF PCI devices created by a PF
without binding any DRM driver to them.

While keeping the API of igt_device_get_pci_device() untouched, extend API
of its underlying helper __igt_device_get_pci_device() with an extra
argument for specifying VF ID of the requested PCI device and expose this
function as public.

While being at it, fix pci_system_cleanup() not called on errors and
instruct users to call it for symmetry when the obtained struct pci_device
is no longer needed.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_device.c | 44 
 lib/igt_device.h |  1 +
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/lib/igt_device.c b/lib/igt_device.c
index 07bb0a0d41..56f66afc6f 100644
--- a/lib/igt_device.c
+++ b/lib/igt_device.c
@@ -149,9 +149,9 @@ struct igt_pci_addr {
unsigned int function;
 };
 
-static int igt_device_get_pci_addr(int fd, struct igt_pci_addr *pci)
+static int igt_device_get_pci_addr(int fd, unsigned int vf_id, struct 
igt_pci_addr *pci)
 {
-   char path[IGT_DEV_PATH_LEN];
+   char link[20], path[IGT_DEV_PATH_LEN];
char *buf;
int sysfs;
int len;
@@ -159,11 +159,21 @@ static int igt_device_get_pci_addr(int fd, struct 
igt_pci_addr *pci)
if (!igt_device_is_pci(fd))
return -ENODEV;
 
+   if (vf_id)
+   len = snprintf(link, sizeof(link), "device/virtfn%u", vf_id - 
1);
+   else
+   len = snprintf(link, sizeof(link), "device");
+   if (igt_warn_on_f(len > sizeof(link) || link[len -1],
+   "IGT bug: insufficient buffer space for rendering PCI device link 
name\n"))
+   return -ENOSPC;
+   else if (igt_debug_on_f(len < 0, "unexpected failure from 
snprintf()\n"))
+   return len;
+
sysfs = igt_sysfs_open(fd);
if (sysfs == -1)
return -ENOENT;
 
-   len = readlinkat(sysfs, "device", path, sizeof(path) - 1);
+   len = readlinkat(sysfs, link, path, sizeof(path) - 1);
close(sysfs);
if (len == -1)
return -ENOENT;
@@ -183,12 +193,25 @@ static int igt_device_get_pci_addr(int fd, struct 
igt_pci_addr *pci)
return 0;
 }
 
-static struct pci_device *__igt_device_get_pci_device(int fd)
+/**
+ * __igt_device_get_pci_device:
+ *
+ * @fd: DRM device file descriptor
+ * @vf_id: virtual function number (0 if native or PF)
+ *
+ * Looks up the graphics pci device using libpciaccess.
+ * Since pci_system_init() is called, users are expected to call 
pci_sytem_clenup() after use
+ * unless an error occurs and NULL is returned.
+ *
+ * Returns:
+ * The pci_device, NULL on any failures.
+ */
+struct pci_device *__igt_device_get_pci_device(int fd, unsigned int vf_id)
 {
struct igt_pci_addr pci_addr;
struct pci_device *pci_dev;
 
-   if (igt_device_get_pci_addr(fd, _addr)) {
+   if (igt_device_get_pci_addr(fd, vf_id, _addr)) {
igt_warn("Unable to find device PCI address\n");
return NULL;
}
@@ -206,15 +229,19 @@ static struct pci_device *__igt_device_get_pci_device(int 
fd)
igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
 pci_addr.domain, pci_addr.bus,
 pci_addr.device, pci_addr.function);
-   return NULL;
+   goto cleanup;
}
 
if (pci_device_probe(pci_dev)) {
igt_warn("Couldn't probe PCI device\n");
-   return NULL;
+   goto cleanup;
}
 
return pci_dev;
+
+cleanup:
+   pci_system_cleanup();
+   return NULL;
 }
 
 /**
@@ -223,6 +250,7 @@ static struct pci_device *__igt_device_get_pci_device(int 
fd)
  * @fd: the device
  *
  * Looks up the main graphics pci device using libpciaccess.
+ * Since pci_system_init() is called, users are expected to call 
pci_sytem_clenup() after use.
  *
  * Returns:
  * The pci_device, skips the test on any failures.
@@ -231,7 +259,7 @@ struct pci_device *igt_device_get_pci_device(int fd)
 {
struct pci_device *pci_dev;
 
-   pci_dev = __igt_device_get_pci_device(fd);
+   pci_dev = __igt_device_get_pci_device(fd, 0);
igt_require(pci_dev);
 
return pci_dev;
diff --git a/lib/igt_device.h b/lib/igt_device.h
index 278ba7a9b3..1aaa840e25 100644
--- a/lib/igt_device.h
+++ b/lib/igt_device.h
@@ -33,5 +33,6 @@ void igt_device_drop_master(int fd);
 
 int igt_device_get_card_index(int fd);
 struct pci_device *igt_device_get_pci_device(int fd);
+struct pci_device *__igt_device_get_pci_device(int fd, unsigned int vf_id);
 
 #endif /* __IGT_DEVICE_H__ */
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Fix flag query helper function to not modify state

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Fix flag query helper function to not modify state
URL   : https://patchwork.freedesktop.org/series/100364/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22323_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_self_import@export-vs-gem_close-race:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-snb7/igt@prime_self_import@export-vs-gem_close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-snb7/igt@prime_self_import@export-vs-gem_close-race.html

  
Known issues


  Here are the changes found in Patchwork_22323_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_22323/shard-apl1/igt@gem_cre...@create-massive.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#2481] / [i915#3070])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_...@unwedge-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-iclb4/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][6] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-skl7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

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

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][10] ([fdo#112283])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-iclb6/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-glk8/igt@gem_exec_whis...@basic-queues-forked-all.html

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

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-skl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@y-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#768])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-iclb3/igt@gem_render_c...@y-tiled-to-vebox-yf-tiled.html

  * igt@gem_softpin@allocator-evict-all-engines:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#4171])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk4/igt@gem_soft...@allocator-evict-all-engines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-glk4/igt@gem_soft...@allocator-evict-all-engines.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3323])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22323/shard-skl7/igt@gem_userptr_bl...@dmabuf-sync.html

  

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/display: Group PSR2 prog sequences and workarounds

[Souza, Jose]

On Fri, 2022-02-11 at 00:04 +, Patchwork wrote:
Patch Details
Series: series starting with [1/2] drm/i915/display: Group PSR2 prog sequences 
and workarounds
URL:https://patchwork.freedesktop.org/series/99989/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22245/index.html
CI Bug Log - changes from CI_DRM_11214_full -> Patchwork_22245_full
Summary

SUCCESS

No regressions found.

pushed to drm-intel-next, thanks for the review Jouni.

Participating hosts (11 -> 11)

No changes in participating hosts

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-skl: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 ([i915#5032])

IGT changes
Issues hit

  *   igt@gem_eio@kms:

 *   shard-tglb: 
PASS
 -> 
FAIL
 ([i915#232])
  *   igt@gem_exec_capture@pi@vecs0:

 *   shard-skl: NOTRUN -> 
INCOMPLETE
 ([i915#4547])
  *   igt@gem_exec_fair@basic-none@vcs1:

 *   shard-iclb: NOTRUN -> 
FAIL
 

[Intel-gfx] ✓ Fi.CI.BAT: success for doc/rfc for small BAR support

[Patchwork]

== Series Details ==

Series: doc/rfc for small BAR support
URL   : https://patchwork.freedesktop.org/series/100399/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11248 -> Patchwork_22331


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 43)
--

  Missing(2): fi-bsw-cyan shard-tglu 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-ilk-650: [PASS][1] -> [FAIL][2] ([i915#4684])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-ilk-650/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-ilk-650/boot.html

  

### IGT changes ###

 Issues hit 

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

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

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][8] ([i915#4269]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][10] ([i915#295]) -> [PASS][11] +12 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22331/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4684]: https://gitlab.freedesktop.org/drm/intel/issues/4684
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_11248 -> Patchwork_22331

  CI-20190529: 20190529
  CI_DRM_11248: 8861c3684bdcd4c8cb8385fbc37a2d9033dff955 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6347: 37ea4c86f97c0e05fcb6b04cff72ec927930536e @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22331: 5a0f497847eebbd1790fddf08216a8f49e82741f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5a0f497847ee drm/doc: add rfc section for small BAR uapi
b54660c8b559 drm/doc: remove rfc section for dg1

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc/slpc: Use wrapper for reading RP_STATE_CAP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc/slpc: Use wrapper for reading RP_STATE_CAP (rev2)
URL   : https://patchwork.freedesktop.org/series/100217/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22321_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@linear-16bpp-rotate-180:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb7/igt@kms_big...@linear-16bpp-rotate-180.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-iclb7/igt@kms_big...@linear-16bpp-rotate-180.html

  
Known issues


  Here are the changes found in Patchwork_22321_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_22321/shard-apl2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-apl7/igt@gem_ctx_isolation@preservation...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][8] ([i915#4547])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-skl1/igt@gem_exec_capture@p...@bcs0.html

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

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][10] ([fdo#112283])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-iclb8/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html

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

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-skl4/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb:  [PASS][15] -> [DMESG-FAIL][16] ([i915#3692] / 
[i915#4998])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][17] ([i915#2658])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-skl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22321/shard-iclb8/igt@gen9_exec_pa...@allowed-all.html

  * 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Review of mode copies

[Patchwork]

== Series Details ==

Series: drm: Review of mode copies
URL   : https://patchwork.freedesktop.org/series/100394/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11248 -> Patchwork_22330


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 44)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-bsw-cyan shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-adlp-6}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271]) +57 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][9] -> [INCOMPLETE][10] ([i915#3303])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][14] ([fdo#109271]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   NOTRUN -> [FAIL][16] ([i915#4547])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-hsw-4770/igt@run...@aborted.html
- fi-blb-e6850:   NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#2403] / 
[i915#2426] / [i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-blb-e6850/igt@run...@aborted.html
- fi-skl-6600u:   NOTRUN -> [FAIL][19] ([i915#4312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22330/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][20] ([i915#4494] / 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for doc/rfc for small BAR support

[Patchwork]

== Series Details ==

Series: doc/rfc for small BAR support
URL   : https://patchwork.freedesktop.org/series/100399/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b54660c8b559 drm/doc: remove rfc section for dg1
-:20: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#20: 
deleted file mode 100644

total: 0 errors, 1 warnings, 0 checks, 10 lines checked
5a0f497847ee drm/doc: add rfc section for small BAR uapi
-:20: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#20: 
new file mode 100644

-:25: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#25: FILE: Documentation/gpu/rfc/i915_small_bar.h:1:
+/**

-:173: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#173: FILE: Documentation/gpu/rfc/i915_small_bar.h:149:
+#define DRM_I915_QUERY_VMA_INFO_CPU_VISIBLE (1<<0)
   ^

-:184: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#184: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1:
+==

total: 0 errors, 3 warnings, 1 checks, 200 lines checked

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: 5th Display output (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: 5th Display output (rev3)
URL   : https://patchwork.freedesktop.org/series/100151/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22320_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2410])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-iclb5/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-kbl6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2849])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_parallel@engines@basic:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk3/igt@gem_exec_parallel@engi...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-glk8/igt@gem_exec_parallel@engi...@basic.html

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-iclb3/igt@gem_exec_par...@secure-non-root.html

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

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-skl7/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][16] ([i915#2658])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-skl8/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-skl9/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#2856])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-iclb6/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_big_fb@linear-32bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#110725] / [fdo#111614])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-iclb6/igt@kms_big...@linear-32bpp-rotate-270.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][20] ([i915#3743]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-skl8/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_big_fb@yf-tiled-16bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111615])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22320/shard-tglb5/igt@kms_big...@yf-tiled-16bpp-rotate-270.html

  * 

Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support

[Ramalingam C]

On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> Robert Beckett  writes:
> 
> > From: Matthew Auld 
> >
> > On discrete platforms like DG2, we need to support a minimum page size
> > of 64K when dealing with device local-memory. This is quite tricky for
> > various reasons, so try to document the new implicit uapi for this.
> >
> > v3: fix typos and less emphasis
> > v2: Fixed suggestions on formatting [Daniel]
> >
> > Signed-off-by: Matthew Auld 
> > Signed-off-by: Ramalingam C 
> > Signed-off-by: Robert Beckett 
> > Acked-by: Jordan Justen 
> > Reviewed-by: Ramalingam C 
> > Reviewed-by: Thomas Hellström 
> > cc: Simon Ser 
> > cc: Pekka Paalanen 
> > Cc: Jordan Justen 
> > Cc: Kenneth Graunke 
> > Cc: mesa-...@lists.freedesktop.org
> > Cc: Tony Ye 
> > Cc: Slawomir Milczarek 
> > ---
> >  include/uapi/drm/i915_drm.h | 44 -
> >  1 file changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 5e678917da70..77e5e74c32c1 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > /**
> >  * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> >  * the user with the GTT offset at which this object will be pinned.
> > +*
> >  * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> >  * presumed_offset of the object.
> > +*
> >  * During execbuffer2 the kernel populates it with the value of the
> >  * current GTT offset of the object, for future presumed_offset writes.
> > +*
> > +* See struct drm_i915_gem_create_ext for the rules when dealing with
> > +* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > +* minimum page sizes, like DG2.
> >  */
> > __u64 offset;
> >  
> > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> >  *
> >  * The (page-aligned) allocated size for the object will be returned.
> >  *
> > -* Note that for some devices we have might have further minimum
> > -* page-size restrictions(larger than 4K), like for device local-memory.
> > -* However in general the final size here should always reflect any
> > -* rounding up, if for example using the 
> > I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > -* extension to place the object in device local-memory.
> > +*
> > +* DG2 64K min page size implications:
> > +*
> > +* On discrete platforms, starting from DG2, we have to contend with GTT
> > +* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > +* objects.  Specifically the hardware only supports 64K or larger GTT
> > +* page sizes for such memory. The kernel will already ensure that all
> > +* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > +* sizes underneath.
> > +*
> > +* Note that the returned size here will always reflect any required
> > +* rounding up done by the kernel, i.e 4K will now become 64K on devices
> > +* such as DG2.
> > +*
> > +* Special DG2 GTT address alignment requirement:
> > +*
> > +* The GTT alignment will also need to be at least 2M for such objects.
> > +*
> > +* Note that due to how the hardware implements 64K GTT page support, we
> > +* have some further complications:
> > +*
> > +*   1) The entire PDE (which covers a 2MB virtual address range), must
> > +*   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > +*   PDE is forbidden by the hardware.
> > +*
> > +*   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > +*   objects.
> > +*
> > +* To keep things simple for userland, we mandate that any GTT mappings
> > +* must be aligned to and rounded up to 2MB.
> 
> Could I get a clarification about this "rounded up" part.
> 
> Currently Mesa is aligning the start of each and every buffer VMA to be
> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> of buffers to 2MiB alignment.
> 
> Bob's Mesa MR from a while ago,
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
> 
> was trying to add this "round up" size for buffers. We didn't accept
> this MR because we thought if we have ensured that no other buffer will
> use the same 2MiB VMA range, then it should not be required.
> 
> If what we are doing is ok, then maybe this "round up" language should
> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> must align the size of buffers that we create, and I'm misinterpreting
> this.
Jordan,

as per my understanding this size rounding up to 2MB is for the VMA mapping,
not for the buffer size. 

Even if we drop this rounding up of vma size to 2MB but align the VMA
start to 2MB address then also this should be fine. Becasue the remaining of the
last PDE(2MB) will never be 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Review of mode copies

[Patchwork]

== Series Details ==

Series: drm: Review of mode copies
URL   : https://patchwork.freedesktop.org/series/100394/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Group PSR2 prog sequences and workarounds

[Hogander, Jouni]

Reviewed-by: Jouni Högander 

for both patches.

On Thu, 2022-02-10 at 10:52 -0800, José Roberto de Souza wrote:
> Grouping inside of the same if all the programing sequences and
> workarounds of PSR2.
> The order of programing changed in intel_psr_enable_source() but
> it will not affect PSR2 as at this point PSR2_ENABLE is still
> disabled.
> 
> Cc: Jouni Högander 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 77 
> 
>  1 file changed, 37 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a1a663f362e7d..72bd8d3261e0c 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1069,25 +1069,6 @@ static void intel_psr_enable_source(struct
> intel_dp *intel_dp)
>   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
>   u32 mask;
>  
> - if (intel_dp->psr.psr2_enabled && DISPLAY_VER(dev_priv) == 9) {
> - i915_reg_t reg = CHICKEN_TRANS(cpu_transcoder);
> - u32 chicken = intel_de_read(dev_priv, reg);
> -
> - chicken |= PSR2_VSC_ENABLE_PROG_HEADER |
> -PSR2_ADD_VERTICAL_LINE_COUNT;
> - intel_de_write(dev_priv, reg, chicken);
> - }
> -
> - /*
> -  * Wa_16014451276:adlp
> -  * All supported adlp panels have 1-based X granularity, this
> may
> -  * cause issues if non-supported panels are used.
> -  */
> - if (IS_ALDERLAKE_P(dev_priv) &&
> - intel_dp->psr.psr2_enabled)
> - intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder),
> 0,
> -  ADLP_1_BASED_X_GRANULARITY);
> -
>   /*
>* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD
> also
>* mask LPSP to avoid dependency on other drivers that might
> block
> @@ -1126,18 +1107,33 @@ static void intel_psr_enable_source(struct
> intel_dp *intel_dp)
>intel_dp->psr.psr2_sel_fetch_enabled ?
>IGNORE_PSR2_HW_TRACKING : 0);
>  
> - /* Wa_16011168373:adl-p */
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) &&
> - intel_dp->psr.psr2_enabled)
> - intel_de_rmw(dev_priv,
> -  TRANS_SET_CONTEXT_LATENCY(intel_dp-
> >psr.transcoder),
> -  TRANS_SET_CONTEXT_LATENCY_MASK,
> -  TRANS_SET_CONTEXT_LATENCY_VALUE(1));
> + if (intel_dp->psr.psr2_enabled) {
> + if (DISPLAY_VER(dev_priv) == 9)
> + intel_de_rmw(dev_priv,
> CHICKEN_TRANS(cpu_transcoder), 0,
> +  PSR2_VSC_ENABLE_PROG_HEADER |
> +  PSR2_ADD_VERTICAL_LINE_COUNT);
>  
> - /* Wa_16012604467:adlp */
> - if (IS_ALDERLAKE_P(dev_priv) && intel_dp->psr.psr2_enabled)
> - intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> -  CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> + /*
> +  * Wa_16014451276:adlp
> +  * All supported adlp panels have 1-based X
> granularity, this may
> +  * cause issues if non-supported panels are used.
> +  */
> + if (IS_ALDERLAKE_P(dev_priv))
> + intel_de_rmw(dev_priv,
> CHICKEN_TRANS(cpu_transcoder), 0,
> +  ADLP_1_BASED_X_GRANULARITY);
> +
> + /* Wa_16011168373:adl-p */
> + if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + intel_de_rmw(dev_priv,
> +  TRANS_SET_CONTEXT_LATENCY(intel_dp
> ->psr.transcoder),
> +  TRANS_SET_CONTEXT_LATENCY_MASK,
> +  TRANS_SET_CONTEXT_LATENCY_VALUE(1)
> );
> +
> + /* Wa_16012604467:adlp */
> + if (IS_ALDERLAKE_P(dev_priv))
> + intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> +  CLKGATE_DIS_MISC_DMASC_GATING_DIS)
> ;
> + }
>  }
>  
>  static bool psr_interrupt_error_check(struct intel_dp *intel_dp)
> @@ -1290,17 +1286,18 @@ static void intel_psr_disable_locked(struct
> intel_dp *intel_dp)
>   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
>  
> - /* Wa_16011168373:adl-p */
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) &&
> - intel_dp->psr.psr2_enabled)
> - intel_de_rmw(dev_priv,
> -  TRANS_SET_CONTEXT_LATENCY(intel_dp-
> >psr.transcoder),
> -  TRANS_SET_CONTEXT_LATENCY_MASK, 0);
> + if (intel_dp->psr.psr2_enabled) {
> + /* Wa_16011168373:adl-p */
> + if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + intel_de_rmw(dev_priv,
> +

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Implement Wa_16013835468

[Hogander, Jouni]

On Wed, 2022-02-16 at 13:48 +, Souza, Jose wrote:
> On Tue, 2022-02-15 at 12:31 +, Hogander, Jouni wrote:
> > On Thu, 2022-02-10 at 10:52 -0800, José Roberto de Souza wrote:
> > > PSR2 workaround required when mode has delayed vblank.
> > > 
> > > BSpec: 52890
> > > BSpec: 49421
> > > Cc: Jouni Högander 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 40
> > > ++--
> > >  drivers/gpu/drm/i915/i915_reg.h  | 13 +---
> > >  2 files changed, 46 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 72bd8d3261e0c..2e0b092f4b6be 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1063,7 +1063,23 @@ static void intel_psr_activate(struct
> > > intel_dp
> > > *intel_dp)
> > >   intel_dp->psr.active = true;
> > >  }
> > > 
> > > -static void intel_psr_enable_source(struct intel_dp *intel_dp)
> > > +static u32 wa_16013835468_bit_get(struct intel_dp *intel_dp)
> > > +{
> > > + switch (intel_dp->psr.pipe) {
> > > + case PIPE_A:
> > > + return LATENCY_REPORTING_REMOVED_PIPE_A;
> > > + case PIPE_B:
> > > + return LATENCY_REPORTING_REMOVED_PIPE_B;
> > > + case PIPE_C:
> > > + return LATENCY_REPORTING_REMOVED_PIPE_C;
> > > + default:
> > > + MISSING_CASE(intel_dp->psr.pipe);
> > > + return 0;
> > > + }
> > > +}
> > > +
> > > +static void intel_psr_enable_source(struct intel_dp *intel_dp,
> > > + const struct intel_crtc_state
> > > *crtc_state)
> > >  {
> > >   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > >   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > > @@ -1133,6 +1149,20 @@ static void intel_psr_enable_source(struct
> > > intel_dp *intel_dp)
> > >   if (IS_ALDERLAKE_P(dev_priv))
> > >   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> > >CLKGATE_DIS_MISC_DMASC_GATING_
> > > DIS)
> > > ;
> > > +
> > > + /* Wa_16013835468:tgl[b0+], dg1 */
> > > + if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > > STEP_FOREVER) ||
> > > + IS_DG1(dev_priv)) {
> > > + u16 vtotal, vblank;
> > > +
> > > + vtotal = crtc_state-
> > > > uapi.adjusted_mode.crtc_vtotal -
> > > +  crtc_state-
> > > > uapi.adjusted_mode.crtc_vdisplay;
> > > + vblank = crtc_state-
> > > > uapi.adjusted_mode.crtc_vblank_end -
> > > +  crtc_state-
> > > > uapi.adjusted_mode.crtc_vblank_start;
> > > + if (vblank > vtotal)
> > 
> > Can you please explain how this calculation indicates we are using
> > "delayed vblank"?
> 
> Check the second box in Bspec 49265

Thank you for pointing this out.

> 
> 
> > Otherwise patch seems to be doing what is written in WA
> > description.
> > 
> > > + intel_de_rmw(dev_priv,
> > > GEN8_CHICKEN_DCPR_1, 0,
> > > +  wa_16013835468_bit_get
> > > (int
> > > el_dp));
> > > + }
> > >   }
> > >  }
> > > 
> > > @@ -1198,7 +1228,7 @@ static void intel_psr_enable_locked(struct
> > > intel_dp *intel_dp,
> > >   intel_write_dp_vsc_sdp(encoder, crtc_state, _state-
> > > > psr_vsc);
> > >   intel_snps_phy_update_psr_power_state(dev_priv, phy, true);
> > >   intel_psr_enable_sink(intel_dp);
> > > - intel_psr_enable_source(intel_dp);
> > > + intel_psr_enable_source(intel_dp, crtc_state);
> > >   intel_dp->psr.enabled = true;
> > >   intel_dp->psr.paused = false;
> > > 
> > > @@ -1297,6 +1327,12 @@ static void
> > > intel_psr_disable_locked(struct
> > > intel_dp *intel_dp)
> > >   if (IS_ALDERLAKE_P(dev_priv))
> > >   intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
> > >CLKGATE_DIS_MISC_DMASC_GATING_
> > > DIS,
> > > 0);
> > > +
> > > + /* Wa_16013835468:tgl[b0+], dg1 */
> > > + if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > > STEP_FOREVER) ||
> > > + IS_DG1(dev_priv))
> > > + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> > > +  wa_16013835468_bit_get(intel_d
> > > p),
> > > 0);
> > >   }
> > > 
> > >   intel_snps_phy_update_psr_power_state(dev_priv, phy,
> > > false);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 87c92314ee269..1cd4056400b63 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6040,11 +6040,14 @@
> > >  #define HSW_NDE_RSTWRN_OPT   _MMIO(0x46408)
> > >  #define  RESET_PCH_HANDSHAKE_ENABLE  (1 << 4)
> > 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Kill the fake lmem support (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Kill the fake lmem support (rev2)
URL   : https://patchwork.freedesktop.org/series/100276/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11244_full -> Patchwork_22319_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html

  
Known issues


  Here are the changes found in Patchwork_22319_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_22319/shard-apl2/igt@gem_cre...@create-massive.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb8/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-kbl:  NOTRUN -> [DMESG-WARN][6] ([i915#5076])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-kbl1/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2849])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][11] ([fdo#112283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb3/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-tglb3/igt@gem_huc_c...@huc-copy.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-tglb7/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_render_copy@y-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#768])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb7/igt@gem_render_c...@y-tiled-to-vebox-yf-tiled.html

  * igt@gem_softpin@allocator-evict-all-engines:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#4171])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11244/shard-glk4/igt@gem_soft...@allocator-evict-all-engines.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-glk3/igt@gem_soft...@allocator-evict-all-engines.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-skl4/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22319/shard-iclb3/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Do not use phy E

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Do not use phy E
URL   : https://patchwork.freedesktop.org/series/100390/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11248 -> Patchwork_22329


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 43)
--

  Missing(2): fi-bsw-cyan shard-tglu 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html

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

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][5] ([fdo#109271]) +21 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][9] ([i915#3921]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u:   [DMESG-WARN][11] ([i915#295]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][13] ([i915#4957]) -> [DMESG-FAIL][14] 
([i915#4494] / [i915#4957])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u:   [DMESG-WARN][15] ([i915#295]) -> [DMESG-FAIL][16] 
([i915#295])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22329/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_11248 -> Patchwork_22329

  CI-20190529: 20190529
  CI_DRM_11248: 8861c3684bdcd4c8cb8385fbc37a2d9033dff955 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6347: 37ea4c86f97c0e05fcb6b04cff72ec927930536e @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22329: 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section

[Ville Syrjälä]

On Fri, Feb 18, 2022 at 02:38:37PM +0200, Juha-Pekka Heikkila wrote:
> This patch set look all ok. That failed cursor test in ci run seem to be 
> flip flopping on other runs too on same icl box.

Yeah, some of those tests seem a bit flaky on the icls. 
Not sure what's causing that.

> 
> Reviewed-by: Juha-Pekka Heikkila 

Thanks.

> 
> On 2.2.2022 13.16, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We don't want any RMWs in the part of the commit that happens
> > under vblank evasion. Eventually we want to use the DSB to
> > handle that and it can't read registers at all. Also reads
> > are just slowing us down needlessly.
> > 
> > Let's move the whole PIPE_CHICKEN stuff out from the critical
> > section since we don't have anything there that needs to be
> > syncrhonized with other plane/pipe registers. If we ever need
> > to add such things then we have to move it back, but without
> > doing any reads.
> > 
> > TODO: should look into eliminating the RMW anyway...
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/display/intel_display.c | 7 ---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index c431076f98a1..05713b64d4bc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8121,9 +8121,6 @@ static void intel_pipe_fastset(const struct 
> > intel_crtc_state *old_crtc_state,
> > if (DISPLAY_VER(dev_priv) >= 9 ||
> > IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> > hsw_set_linetime_wm(new_crtc_state);
> > -
> > -   if (DISPLAY_VER(dev_priv) >= 11)
> > -   icl_set_pipe_chicken(new_crtc_state);
> >   }
> >   
> >   static void commit_pipe_pre_planes(struct intel_atomic_state *state,
> > @@ -8215,6 +8212,10 @@ static void intel_update_crtc(struct 
> > intel_atomic_state *state,
> >   
> > if (new_crtc_state->update_pipe)
> > intel_encoders_update_pipe(state, crtc);
> > +
> > +   if (DISPLAY_VER(dev_priv) >= 11 &&
> > +   new_crtc_state->update_pipe)
> > +   icl_set_pipe_chicken(new_crtc_state);
> > }
> >   
> > intel_fbc_update(state, crtc);

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move PIPE_CHICKEN RMW out from the vblank evade critical section

[Juha-Pekka Heikkila]

This patch set look all ok. That failed cursor test in ci run seem to be 
flip flopping on other runs too on same icl box.


Reviewed-by: Juha-Pekka Heikkila 

On 2.2.2022 13.16, Ville Syrjala wrote:

From: Ville Syrjälä 

We don't want any RMWs in the part of the commit that happens
under vblank evasion. Eventually we want to use the DSB to
handle that and it can't read registers at all. Also reads
are just slowing us down needlessly.

Let's move the whole PIPE_CHICKEN stuff out from the critical
section since we don't have anything there that needs to be
syncrhonized with other plane/pipe registers. If we ever need
to add such things then we have to move it back, but without
doing any reads.

TODO: should look into eliminating the RMW anyway...

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_display.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index c431076f98a1..05713b64d4bc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8121,9 +8121,6 @@ static void intel_pipe_fastset(const struct 
intel_crtc_state *old_crtc_state,
if (DISPLAY_VER(dev_priv) >= 9 ||
IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
hsw_set_linetime_wm(new_crtc_state);
-
-   if (DISPLAY_VER(dev_priv) >= 11)
-   icl_set_pipe_chicken(new_crtc_state);
  }
  
  static void commit_pipe_pre_planes(struct intel_atomic_state *state,

@@ -8215,6 +8212,10 @@ static void intel_update_crtc(struct intel_atomic_state 
*state,
  
  		if (new_crtc_state->update_pipe)

intel_encoders_update_pipe(state, crtc);
+
+   if (DISPLAY_VER(dev_priv) >= 11 &&
+   new_crtc_state->update_pipe)
+   icl_set_pipe_chicken(new_crtc_state);
}
  
  	intel_fbc_update(state, crtc);

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Do not use phy E

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Do not use phy E
URL   : https://patchwork.freedesktop.org/series/100390/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
58e2625786ba drm/i915/dg2: Drop 38.4 MHz MPLLB tables
a0ab07a6c339 drm/i915/dg2: Do not use phy E
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
i915 :03:00.0: [drm] *ERROR* SNPS PHY E failed to calibrate after 
25ms.

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

[Intel-gfx] [PATCH v2] drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround

[Imre Deak]

Add display workaround # 1309179469 , which fixes a PHY hang when
switching from TBT mode to DP-alt/legacy mode. The workaround also
requires an IFWI/PHY firmware change, before that this change has no
effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared).

HSDES: 18018237866
HSDES: 16014473319

v2: Add the WA comment and make the WA func name more accurate.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 20 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  6 ++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9dee12986991c..e6e26e4cd87d7 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3101,10 +3101,24 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state 
*state,

crtc_state->lane_lat_optim_mask);
 }
 
+/* Display WA #1309179469: adl-p */
+static void adlp_tbt_to_dp_alt_legacy_switch_wa(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum tc_port tc_port = intel_port_to_tc(i915, encoder->port);
+   int ln;
+
+   for (ln = 0; ln < 2; ln++) {
+   intel_de_write(i915, HIP_INDEX_REG(tc_port), 
HIP_INDEX_VAL(tc_port, ln));
+   intel_de_rmw(i915, DKL_PCS_DW5(tc_port), 
DKL_PCS_DW5_CORE_SOFTRESET, 0);
+   }
+}
+
 static void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp,
   const struct intel_crtc_state 
*crtc_state)
 {
-   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_encoder *encoder = _port->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
u32 dp_tp_ctl, ddi_buf_ctl;
@@ -3140,6 +3154,10 @@ static void intel_ddi_prepare_link_retrain(struct 
intel_dp *intel_dp,
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), dp_tp_ctl);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
 
+   if (IS_ALDERLAKE_P(dev_priv) &&
+   (intel_tc_port_in_dp_alt_mode(dig_port) || 
intel_tc_port_in_legacy_mode(dig_port)))
+   adlp_tbt_to_dp_alt_legacy_switch_wa(encoder);
+
intel_dp->DP |= DDI_BUF_CTL_ENABLE;
intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 26b496fa31972..8abbdc62b981f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,6 +7907,12 @@ enum skl_power_gate {
 #define _DKL_PHY6_BASE 0x16D000
 
 /* DEKEL PHY MMIO Address = Phy base + (internal address & ~index_mask) */
+#define _DKL_PCS_DW5   0x14
+#define DKL_PCS_DW5(tc_port)   _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+   _DKL_PHY2_BASE) + \
+   _DKL_PCS_DW5)
+#define   DKL_PCS_DW5_CORE_SOFTRESET   REG_BIT(11)
+
 #define _DKL_PLL_DIV0  0x200
 #define   DKL_PLL_DIV0_INTEG_COEFF(x)  ((x) << 16)
 #define   DKL_PLL_DIV0_INTEG_COEFF_MASK(0x1F << 16)
-- 
2.27.0

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: fixup the mock_bo (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: fixup the mock_bo (rev2)
URL   : https://patchwork.freedesktop.org/series/100255/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11248 -> Patchwork_22328


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 44)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-bsw-cyan shard-tglu 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +57 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][5] ([i915#3921])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271]) +21 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

  
 Possible fixes 

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

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [DMESG-WARN][13] ([i915#295]) -> [PASS][14] +12 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][15] ([i915#4957]) -> [DMESG-FAIL][16] 
([i915#4494] / [i915#4957])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11248/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22328/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  

[Intel-gfx] [PATCH] drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround

[Imre Deak]

Add display workaround # 1309179469 , which fixes a PHY hang when
switching from TBT mode to DP-alt/legacy mode. The workaround also
requires an IFWI/PHY firmware change, before that this change has no
effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared).

HSDES: 18018237866
HSDES: 16014473319

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 19 ++-
 drivers/gpu/drm/i915/i915_reg.h  |  6 ++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9dee12986991c..e4260806c2a40 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3101,10 +3101,23 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state 
*state,

crtc_state->lane_lat_optim_mask);
 }
 
+static void adlp_tbt_to_dp_alt_switch_wa(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum tc_port tc_port = intel_port_to_tc(i915, encoder->port);
+   int ln;
+
+   for (ln = 0; ln < 2; ln++) {
+   intel_de_write(i915, HIP_INDEX_REG(tc_port), 
HIP_INDEX_VAL(tc_port, ln));
+   intel_de_rmw(i915, DKL_PCS_DW5(tc_port), 
DKL_PCS_DW5_CORE_SOFTRESET, 0);
+   }
+}
+
 static void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp,
   const struct intel_crtc_state 
*crtc_state)
 {
-   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_encoder *encoder = _port->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
u32 dp_tp_ctl, ddi_buf_ctl;
@@ -3140,6 +3153,10 @@ static void intel_ddi_prepare_link_retrain(struct 
intel_dp *intel_dp,
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), dp_tp_ctl);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
 
+   if (IS_ALDERLAKE_P(dev_priv) &&
+   (intel_tc_port_in_dp_alt_mode(dig_port) || 
intel_tc_port_in_legacy_mode(dig_port)))
+   adlp_tbt_to_dp_alt_switch_wa(encoder);
+
intel_dp->DP |= DDI_BUF_CTL_ENABLE;
intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP);
intel_de_posting_read(dev_priv, DDI_BUF_CTL(port));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 26b496fa31972..8abbdc62b981f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,6 +7907,12 @@ enum skl_power_gate {
 #define _DKL_PHY6_BASE 0x16D000
 
 /* DEKEL PHY MMIO Address = Phy base + (internal address & ~index_mask) */
+#define _DKL_PCS_DW5   0x14
+#define DKL_PCS_DW5(tc_port)   _MMIO(_PORT(tc_port, _DKL_PHY1_BASE, \
+   _DKL_PHY2_BASE) + \
+   _DKL_PCS_DW5)
+#define   DKL_PCS_DW5_CORE_SOFTRESET   REG_BIT(11)
+
 #define _DKL_PLL_DIV0  0x200
 #define   DKL_PLL_DIV0_INTEG_COEFF(x)  ((x) << 16)
 #define   DKL_PLL_DIV0_INTEG_COEFF_MASK(0x1F << 16)
-- 
2.27.0

Re: [Intel-gfx] [PATCH 01/22] drm: Add drm_mode_init()

[Andrzej Hajda]

On 18.02.2022 12:56, Ville Syrjälä wrote:

On Fri, Feb 18, 2022 at 12:22:44PM +0100, Andrzej Hajda wrote:


On 18.02.2022 11:03, Ville Syrjala wrote:

From: Ville Syrjälä 

Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_modes.c | 17 +
   include/drm/drm_modes.h |  2 ++
   2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 96b13e36293c..40d4ce4a1da4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -892,6 +892,23 @@ void drm_mode_copy(struct drm_display_mode *dst, const 
struct drm_display_mode *
   }
   EXPORT_SYMBOL(drm_mode_copy);
   
+/**

+ * drm_mode_init - initialize the mode from another mode
+ * @dst: mode to overwrite
+ * @src: mode to copy
+ *
+ * Copy an existing mode into another mode, zeroing the
+ * list head of the destination mode. Typically used
+ * to guarantee the list head is not left with stack
+ * garbage in on-stack modes.
+ */
+void drm_mode_init(struct drm_display_mode *dst, const struct drm_display_mode 
*src)
+{
+   memset(dst, 0, sizeof(*dst));

Why not just clear the list head? Or maybe poison it? It would be more
cleaner.

Then we have two places that need to be updated if some other field
gets introduced that needs preserving. With a full memset() we only
have to care about drm_mode_copy(). Don't see much point in
micro-optimizing this thing.

In such case DOC should be modified to avoid updating it "if some other 
field..." :)


Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede  
wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede 
> >  wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.