[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Patchwork]

== Series Details ==

Series: drm/i915: add new "soc" sub-directory and move PCH and DRAM code there
URL   : https://patchwork.freedesktop.org/series/111780/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12484_full -> Patchwork_111780v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (14 -> 14)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_balancer@smoke:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/shard-skl2/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-skl3/igt@gem_exec_balan...@smoke.html

  * {igt@gem_softpin@evict-prime@all} (NEW):
- shard-skl:  NOTRUN -> [FAIL][3] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-skl2/igt@gem_softpin@evict-pr...@all.html

  
New tests
-

  New tests have been introduced between CI_DRM_12484_full and 
Patchwork_111780v1_full:

### New IGT tests (6) ###

  * igt@gem_softpin@evict-prime@all:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@gem_softpin@evict-prime@bcs0:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@gem_softpin@evict-prime@rcs0:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@gem_softpin@evict-prime@vcs0:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@gem_softpin@evict-prime@vecs0:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@kms_ccs:
- Statuses :
- Exec time: [None] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-ext-cpu-access-sanity-check:
- shard-iclb: NOTRUN -> [SKIP][4] ([i915#6335])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-iclb3/igt@gem_cre...@create-ext-cpu-access-sanity-check.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-iclb6/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

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

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

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

  * 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dp: Change aux_ctl reg read to polling read

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Change aux_ctl reg read to polling read
URL   : https://patchwork.freedesktop.org/series/111794/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/111794/revisions/1/mbox/ not 
applied
Applying: drm/i915/dp: Change aux_ctl reg read to polling read
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_dp_aux.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_dp_aux.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_dp_aux.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/dp: Change aux_ctl reg read to polling read
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] [PATCHv3] drm/i915/dp: Change aux_ctl reg read to polling read

[Arun R Murthy]

The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY or
Success.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period. Looks like there might be some
issue with interrupt-on-read. Hence changing the logic to polling read.

v2: replace interrupt with polling read
v3: use usleep_rang instead of msleep, updated commit msg

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

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 664bebdecea7..878452e6e37f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -40,21 +40,25 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
const unsigned int timeout_ms = 10;
u32 status;
-   bool done;
+   int try;
 
-#define C (((status = intel_uncore_read_notrace(>uncore, ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
- msecs_to_jiffies_timeout(timeout_ms));
+   for (try = 0; try < 10; try++) {
+   status = intel_uncore_read_notrace(>uncore, ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
+   break;
+   usleep_range(400, 500);
+   }
 
+   if (try == 3) {
+   status = intel_uncore_read_notrace(>uncore, ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) != 0)
+   drm_err(>drm,
+   "%s: did not complete or timeout within %ums 
(status 0x%08x)\n",
+   intel_dp->aux.name, timeout_ms, status);
+   }
/* just trace the final value */
trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
 
-   if (!done)
-   drm_err(>drm,
-   "%s: did not complete or timeout within %ums (status 
0x%08x)\n",
-   intel_dp->aux.name, timeout_ms, status);
-#undef C
-
return status;
 }
 
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: no need for gt/gen8_ppgtt.h

[Patchwork]

== Series Details ==

Series: drm/i915/display: no need for gt/gen8_ppgtt.h
URL   : https://patchwork.freedesktop.org/series/111775/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12483_full -> Patchwork_111775v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@evict:
- shard-skl:  NOTRUN -> [INCOMPLETE][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-skl2/igt@i915_selftest@l...@evict.html

  
 Suppressed 

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

  * igt@gem_ctx_isolation@preservation@vcs1:
- {shard-dg1}:NOTRUN -> [FAIL][2] +4 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-dg1-17/igt@gem_ctx_isolation@preservat...@vcs1.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([PASS][3], [PASS][4], [PASS][5], [PASS][6], 
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [FAIL][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4338])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb5/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/shard-snb4/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-snb4/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-snb4/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-snb4/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-snb4/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/shard-snb4/boot.html
   [33]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for GSC FW loading (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev4)
URL   : https://patchwork.freedesktop.org/series/70/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12485 -> Patchwork_70v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 25)
--

  Additional (1): fi-icl-u2 
  Missing(1): fi-kbl-8809g 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-icl-u2:  NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v4/fi-icl-u2/igt@debugfs_t...@basic-hwmon.html

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

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

  * igt@i915_selftest@live@mman:
- fi-rkl-guc: [PASS][4] -> [TIMEOUT][5] ([i915#6794])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12485/fi-rkl-guc/igt@i915_selftest@l...@mman.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v4/fi-rkl-guc/igt@i915_selftest@l...@mman.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2:  NOTRUN -> [SKIP][9] ([i915#3555])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v4/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([fdo#109295] / [i915#3301])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v4/fi-icl-u2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}:   [DMESG-WARN][11] ([i915#6434]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12485/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_70v4/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456


Build changes
-

  * Linux: CI_DRM_12485 -> Patchwork_70v4

  CI-20190529: 20190529
  CI_DRM_12485: 1c451657aa4c171d337db2d29623b0129008f12b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7086: ec1b164a207fdf06827beac4927ac83b3df65b39 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_70v4: 1c451657aa4c171d337db2d29623b0129008f12b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

0adc45c4c339 drm/i915/mtl: MTL has one GSC CS on the media GT
7a6c2ad03d8f drm/i915/gsc: Disable GSC engine and power well if FW is not 
selected
8af2eb61598b drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
60594ebf04f6 drm/i915/gsc: GSC firmware loading

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for GSC FW loading (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Add support for GSC FW loading (rev4)
URL   : https://patchwork.freedesktop.org/series/70/
State : warning

== Summary ==

Error: dim checkpatch failed
4cbbfea9dcfb drm/i915/uc: Introduce GSC FW
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#72: 
new file mode 100644

-:98: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#98: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c:22:
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);

-:184: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#184: FILE: drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h:32:
+   GEM_BUG_ON(__intel_uc_fw_status(>fw) == 
INTEL_UC_FIRMWARE_SELECTED);

-:289: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#289: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:22:
+   GEM_BUG_ON(type >= INTEL_UC_FW_NUM_TYPES);

-:356: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#356: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:67:
 };
+#define INTEL_UC_FW_NUM_TYPES 3

-:378: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#378: FILE: drivers/gpu/drm/i915/i915_params.c:196:
+i915_param_named_unsafe(gsc_firmware_path, charp, 0400,
+   "GSC firmware path to use instead of the default one");

total: 0 errors, 4 warnings, 2 checks, 306 lines checked
ebb5aca0c3bf drm/i915/gsc: Skip the version check when fetching the GSC FW
6ceb1ea7a80c drm/i915/gsc: GSC firmware loading
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:77: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#77: 
new file mode 100644

-:475: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#475: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:937:
+   GEM_BUG_ON(!intel_uc_fw_is_loadable(uc_fw));

total: 0 errors, 2 warnings, 0 checks, 428 lines checked
b932028d7c61 drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
53e74f36c675 drm/i915/gsc: Disable GSC engine and power well if FW is not 
selected
3930e95fc31c drm/i915/mtl: MTL has one GSC CS on the media GT

Re: [Intel-gfx] [PATCH v6 01/14] drm/i915/display: Add new member to configure PCON color conversion

[Ville Syrjälä]

On Fri, Dec 02, 2022 at 03:40:15PM +0530, Ankit Nautiyal wrote:
> The decision to use DFP output format conversion capabilities should be
> during compute_config phase.
> 
> This patch adds new member to crtc_state to represent the final
> output_format to the sink. In case of a DFP this can be different than
> the output_format, as per the format conversion done via the PCON.
> 
> This will help to store only the format conversion capabilities of the
> DP device in intel_dp->dfp, and use crtc_state to compute and store the
> configuration for color/format conversion for a given mode.
> 
> v2: modified the new member to crtc_state to represent the final
> output_format that eaches the sink, after possible conversion by
> PCON kind of devices. (Ville)
> 
> v3: Addressed comments from Ville:
> -Added comments to clarify difference between sink_format and
> output_format.
> -Corrected the order of setting sink_format and output_format.
> -Added readout for sink_format in get_pipe_config hooks.
> 
> v4: Set sink_format for intel_sdvo too. (Ville)
> 
> Signed-off-by: Ankit Nautiyal 
> Reviewed-by: Ville Syrjälä  (v3)
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c|  1 +
>  drivers/gpu/drm/i915/display/intel_crt.c  |  1 +
>  .../drm/i915/display/intel_crtc_state_dump.c  |  5 +--
>  drivers/gpu/drm/i915/display/intel_display.c  |  5 +++
>  .../drm/i915/display/intel_display_types.h| 11 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 34 +--
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  1 +
>  drivers/gpu/drm/i915/display/intel_dvo.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 24 +++--
>  drivers/gpu/drm/i915/display/intel_lvds.c |  1 +
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  1 +
>  drivers/gpu/drm/i915/display/intel_tv.c   |  1 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c|  1 +
>  13 files changed, 62 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index d16b30a2dded..0ca0d23f42c6 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1667,6 +1667,7 @@ static int gen11_dsi_compute_config(struct 
> intel_encoder *encoder,
>   _config->hw.adjusted_mode;
>   int ret;
>  
> + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>  
>   ret = intel_panel_compute_config(intel_connector, adjusted_mode);
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 797ad9489f7e..eb5964b3ff95 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -393,6 +393,7 @@ static int intel_crt_compute_config(struct intel_encoder 
> *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
> b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> index e3273fe8ddac..9b61884851fc 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> @@ -163,10 +163,11 @@ void intel_crtc_state_dump(const struct 
> intel_crtc_state *pipe_config,
>  
>   snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
>   drm_dbg_kms(>drm,
> - "active: %s, output_types: %s (0x%x), output format: %s\n",
> + "active: %s, output_types: %s (0x%x), output format: %s, 
> sink format: %s\n",
>   str_yes_no(pipe_config->hw.active),
>   buf, pipe_config->output_types,
> - output_formats(pipe_config->output_format));
> + output_formats(pipe_config->output_format),
> + output_formats(pipe_config->sink_format));
>  
>   drm_dbg_kms(>drm,
>   "cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 32b257157186..789667e1b2cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3242,6 +3242,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc 
> *crtc,
>   return false;
>  
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> + pipe_config->sink_format = pipe_config->output_format;
>   pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
>   pipe_config->shared_dpll = NULL;
>  
> @@ -3701,6 +3702,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
>   break;
>   }
>  
> + pipe_config->sink_format = pipe_config->output_format;

Re: [Intel-gfx] [PATCH v12 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Ceraolo Spurio, Daniele]

On 12/8/2022 10:05 AM, Alan Previn wrote:

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
   v11: - Reformat a comment (Tvrtko).
   v10: - Change the code flow for intel_pxp_init to make it more
  cleaner and readible with better comments explaining the
  difference between full-PXP-feature vs the partial-teelink
  inits depending on the platform. Additionally, only do
  the pxp allocation when we are certain the subsystem is
  needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
  explain the functional flow for when PXP is not supported
  but the backend-assets are needed for HuC authentication
  (Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
  PXP that need to be checking pxp ptrs before using them:
  intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
  (Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
  support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
  with that, do additional validity check on i915->pxp for
  intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
  and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
  flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
  through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
  after i915 loading failed without pxp being allocated, check
  i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
  because : [1] introduction of 'ctrl_gt' means we correct this
  for MTL's 

[Intel-gfx] [CI 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected

[Daniele Ceraolo Spurio]

From: Jonathan Cavitt 

The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.

IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements
between CS setup and forcewake idleness. See in-code comment for detail.

Signed-off-by: Jonathan Cavitt 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: John C Harrison 
Cc: Rodrigo Vivi 
Cc: Vinay Belgaumkar 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 ++
 drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..99c4b866addd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
engine_mask_apply_compute_fuses(gt);
engine_mask_apply_copy_fuses(gt);
 
+   /*
+* The only use of the GSC CS is to load and communicate with the GSC
+* FW, so we have no use for it if we don't have the FW.
+*
+* IMPORTANT: in cases where we don't have the GSC FW, we have a
+* catch-22 situation that breaks media C6 due to 2 requirements:
+* 1) once turned on, the GSC power well will not go to sleep unless the
+*GSC FW is loaded.
+* 2) to enable idling (which is required for media C6) we need to
+*initialize the IDLE_MSG register for the GSC CS and do at least 1
+*submission, which will wake up the GSC power well.
+*/
+   if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>uc)) {
+   drm_notice(>i915->drm,
+  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   info->engine_mask &= ~BIT(GSC0);
+   }
+
return info->engine_mask;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 64685393f031..8dee9e62a73e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
if (fw_domains & BIT(domain_id))
fw_domain_fini(uncore, domain_id);
}
+
+   if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
+   fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);
 }
 
 /*
-- 
2.37.3

[Intel-gfx] [CI 1/6] drm/i915/uc: Introduce GSC FW

[Daniele Ceraolo Spurio]

On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.

Similarly to the other FWs, the GSC FW path can be overridden via
modparam. The modparam can also be used to disable the GSC FW loading by
setting it to an empty string.

Note that the new structure has been called intel_gsc_uc to avoid
confusion with the existing intel_gsc, which instead represents the heci
gsc interfaces.

v2: re-order Makefile list to be properly sorted (Jani, Alan), better
comment (alan)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Jani Nikula 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile | 10 ++--
 drivers/gpu/drm/i915/gt/intel_gt.h|  5 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 70 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 36 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 17 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 29 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  7 ++-
 drivers/gpu/drm/i915/i915_params.c|  3 +
 drivers/gpu/drm/i915/i915_params.h|  1 +
 10 files changed, 172 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..69f6e9af1b56 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -188,9 +188,8 @@ i915-y += \
  i915_vma_resource.o
 
 # general-purpose microcontroller (GuC) support
-i915-y += gt/uc/intel_uc.o \
- gt/uc/intel_uc_debugfs.o \
- gt/uc/intel_uc_fw.o \
+i915-y += \
+ gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
  gt/uc/intel_guc_capture.o \
@@ -205,7 +204,10 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_guc_submission.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o
+ gt/uc/intel_huc_fw.o \
+ gt/uc/intel_uc.o \
+ gt/uc/intel_uc_debugfs.o \
+ gt/uc/intel_uc_fw.o
 
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e0365d556248..d2f4fbde5f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -39,6 +39,11 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
return container_of(huc, struct intel_gt, uc.huc);
 }
 
+static inline struct intel_gt *gsc_uc_to_gt(struct intel_gsc_uc *gsc_uc)
+{
+   return container_of(gsc_uc, struct intel_gt, uc.gsc);
+}
+
 static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
 {
return container_of(gsc, struct intel_gt, gsc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
new file mode 100644
index ..7a09f432
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include "gt/intel_gt.h"
+#include "intel_gsc_uc.h"
+#include "i915_drv.h"
+
+static bool gsc_engine_supported(struct intel_gt *gt)
+{
+   intel_engine_mask_t mask;
+
+   /*
+* We reach here from i915_driver_early_probe for the primary GT before
+* its engine mask is set, so we use the device info engine mask for it.
+* For other GTs we expect the GT-specific mask to be set before we
+* call this function.
+*/
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
+
+   if (gt_is_root(gt))
+   mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+   else
+   mask = gt->info.engine_mask;
+
+   return __HAS_ENGINE(mask, GSC0);
+}
+
+void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
+{
+   intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+
+   /* we can arrive here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence check device info's
+* engine mask
+*/
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))) {
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+   return;
+   }
+}
+
+int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
+{
+   struct drm_i915_private *i915 = gsc_uc_to_gt(gsc)->i915;
+   int err;
+
+   err = intel_uc_fw_init(>fw);
+   if (err)
+   goto out;
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
+
+   return 0;
+
+out:
+   i915_probe_error(i915, "failed with %d\n", err);
+   return err;
+}
+
+void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
+{
+   

[Intel-gfx] [CI 0/6] drm/i915: Add support for GSC FW loading

[Daniele Ceraolo Spurio]

Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).

The loading happens via a submission to the GSC engine. All subsequent
communication with the FW will also happen via the engine, although no
further messages are implemented as part of this series.

This series also adds the GSC engine flag to the MTL platform, with the
engine being runtime disabled if the FW is not selected, which makes the
FW definition (not included in the series) the ultimate enabler for the
whole GSC block.

Note that just loading the FW is not enough for it to be fully
functional. We'll also need to establish and handle a communication
channel between GSC and CSME (a.k.a. SW proxy). This will require a new
mei component to handle the CSME side of things, so it will be pushed as
a separate series.

Daniele Ceraolo Spurio (5):
  drm/i915/uc: Introduce GSC FW
  drm/i915/gsc: Skip the version check when fetching the GSC FW
  drm/i915/gsc: GSC firmware loading
  drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
  drm/i915/mtl: MTL has one GSC CS on the media GT

Jonathan Cavitt (1):
  drm/i915/gsc: Disable GSC engine and power well if FW is not selected

 drivers/gpu/drm/i915/Makefile|  11 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  18 ++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.h   |   5 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 210 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 137 
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  47 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  23 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  78 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   8 +-
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_uncore.c  |  59 ++
 drivers/gpu/drm/i915/intel_uncore.h  |  13 ++
 19 files changed, 624 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

-- 
2.37.3

[Intel-gfx] [CI 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

[Daniele Ceraolo Spurio]

If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-initiated FLR is not the same as PCI config space FLR in
that it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.

We perform the FLR as the last action before releasing the MMIO bar, so
that we don't have to care about the consequences of the reset on the
unload flow.

v2: rename FLR function, add comment to explain FLR impact (Rodrigo),
better explain why GSC needs FLR (Alan)

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 23 ++
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++
 drivers/gpu/drm/i915/intel_uncore.c   | 56 +++
 drivers/gpu/drm/i915/intel_uncore.h   | 13 ++
 4 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index f88069ab71ab..e73d4440c5e8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -166,6 +166,29 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
 
+   /*
+* GSC is only killed by an FLR, so we need to trigger one on unload to
+* make sure we stop it. This is because we assign a chunk of memory to
+* the GSC as part of the FW load , so we need to make sure it stops
+* using it when we release it to the system on driver unload. Note that
+* this is not a problem of the unload per-se, because the GSC will not
+* touch that memory unless there are requests for it coming from the
+* driver; therefore, no accesses will happen while i915 is not loaded,
+* but if we re-load the driver then the GSC might wake up and try to
+* access that old memory location again.
+* Given that an FLR is a very disruptive action (see the FLR function
+* for details), we want to do it as the last action before releasing
+* the access to the MMIO bar, which means we need to do it as part of
+* the primary uncore cleanup.
+* An alternative approach to the FLR would be to use a memory location
+* that survives driver unload, like e.g. stolen memory, and keep the
+* GSC loaded across reloads. However, this requires us to make sure we
+* preserve that memory location on unload and then determine and
+* reserve its offset on each subsequent load, which is not trivial, so
+* it is easier to just kill everything and start fresh.
+*/
+   intel_uncore_set_flr_on_fini(>i915->uncore);
+
err = gsc_fw_load(gsc);
if (err)
goto fail;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b90fe6a28f7..b95d533652a4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
 
 #define GU_CNTL_MMIO(0x101010)
 #define   LMEM_INITREG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
 
 #define GEN6_STOLEN_RESERVED   _MMIO(0x1082C0)
 #define GEN6_STOLEN_RESERVED_ADDR_MASK (0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 614013745fca..64685393f031 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,59 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
 }
 
+/*
+ * The driver-initiated FLR is the highest level of reset that we can trigger
+ * from within the driver. It is different from the PCI FLR in that it doesn't
+ * fully reset the SGUnit and doesn't modify the PCI config space and therefore
+ * it doesn't require a re-enumeration of the PCI BARs. However, the
+ * driver-initiated FLR does still cause a reset of both GT and display and a
+ * memory wipe of local and stolen memory, so recovery would require a full HW
+ * re-init and saving/restoring (or re-populating) the wiped memory. Since we
+ * perform the FLR as the very last action before releasing access to the HW
+ * during the driver release flow, we don't attempt recovery at all, because
+ * if/when a new instance of i915 is bound to the device it will do a full
+ * re-init anyway.
+ */
+static void driver_initiated_flr(struct intel_uncore *uncore)
+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+  

[Intel-gfx] [CI 6/6] drm/i915/mtl: MTL has one GSC CS on the media GT

[Daniele Ceraolo Spurio]

Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 414b4bfd514b..3f803c1280c0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1125,7 +1125,7 @@ static const struct intel_gt_definition xelpmp_extra_gt[] 
= {
.type = GT_MEDIA,
.name = "Standalone Media GT",
.gsi_offset = MTL_MEDIA_GSI_BASE,
-   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2) | BIT(GSC0),
},
{}
 };
-- 
2.37.3

[Intel-gfx] [CI 2/6] drm/i915/gsc: Skip the version check when fetching the GSC FW

[Daniele Ceraolo Spurio]

The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the code the same as for older FWs.

Since the GSC FW version is not currently required for functionality and
is only needed for debug purposes, we can skip the FW version for now at
fetch time and add it later on when we've agreed on the approach.

v2: rebased on uc_fw version struct changes.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Reviewed-by: Rodrigo Vivi  #v1
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 29 +++-
 1 file changed, 23 insertions(+), 6 deletions(-)

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 1d6249d4b8ef..78ab60c07a2b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -655,6 +655,26 @@ static bool guc_check_version_range(struct intel_uc_fw 
*uc_fw)
return true;
 }
 
+static int check_fw_header(struct intel_gt *gt,
+  const struct firmware *fw,
+  struct intel_uc_fw *uc_fw)
+{
+   int err = 0;
+
+   /* GSC FW version is queried after the FW is loaded */
+   if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
+   return 0;
+
+   if (uc_fw->loaded_via_gsc)
+   err = check_gsc_manifest(fw, uc_fw);
+   else
+   err = check_ccs_header(gt, fw, uc_fw);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  * @uc_fw: uC firmware
@@ -724,17 +744,14 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
 
-   if (uc_fw->loaded_via_gsc)
-   err = check_gsc_manifest(fw, uc_fw);
-   else
-   err = check_ccs_header(gt, fw, uc_fw);
+   err = check_fw_header(gt, fw, uc_fw);
if (err)
goto fail;
 
if (uc_fw->type == INTEL_UC_FW_TYPE_GUC && 
!guc_check_version_range(uc_fw))
goto fail;
 
-   if (uc_fw->file_wanted.ver.major) {
+   if (uc_fw->file_wanted.ver.major && uc_fw->file_selected.ver.major) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.ver.major != 
uc_fw->file_wanted.ver.major) {
drm_notice(>drm, "%s firmware %s: unexpected 
version: %u.%u != %u.%u\n",
@@ -751,7 +768,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
}
}
 
-   if (old_ver) {
+   if (old_ver && uc_fw->file_selected.ver.major) {
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal, 
sizeof(uc_fw->file_wanted));
 
-- 
2.37.3

[Intel-gfx] [CI 3/6] drm/i915/gsc: GSC firmware loading

[Daniele Ceraolo Spurio]

GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.

The GSC is not reset as part of GT reset, so we only need to load it on
first boot and S3/S4 exit.

v2: use REG_* for register fields definitions (Rodrigo), move to WQ
immediately

v3: mark worker function as static

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 187 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  69 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|   6 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 10 files changed, 313 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 69f6e9af1b56..dfa211451a1d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -189,6 +189,7 @@ i915-y += \
 
 # general-purpose microcontroller (GuC) support
 i915-y += \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..2af1ae3831df 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_SUBCLIENT_MASK0x1800
@@ -432,6 +433,12 @@
 #define COLOR_BLT ((0x2<<29)|(0x40<<22))
 #define SRC_COPY_BLT  ((0x2<<29)|(0x43<<22))
 
+#define GSC_INSTR(opcode, data, flags) \
+   (__INSTR(INSTR_GSC_CLIENT) | (opcode) << 22 | (data) << 9 | (flags))
+
+#define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
+#define   HECI1_FW_LIMIT_VALID (1 << 31)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
new file mode 100644
index ..f88069ab71ab
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_fw.h"
+
+#define GSC_FW_STATUS_REG  _MMIO(0x116C40)
+#define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
+#define   GSC_FW_CURRENT_STATE_RESET   0
+#define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
+
+static bool gsc_is_in_reset(struct intel_uncore *uncore)
+{
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_CURRENT_STATE_RESET;
+}
+
+bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
+}
+
+static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
+{
+   u32 offset = i915_ggtt_offset(gsc->local);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 4);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_FW_LOAD;
+   *cs++ 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v12,1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Patchwork]

== Series Details ==

Series: series starting with [v12,1/1] drm/i915/pxp: Promote pxp subsystem to 
top-level of i915
URL   : https://patchwork.freedesktop.org/series/111784/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12484 -> Patchwork_111784v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (26 -> 25)
--

  Missing(1): bat-dg1-6 

Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][3] ([i915#2582]) -> [PASS][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@fb...@read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111784v1/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][5] ([i915#7229]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111784v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][7] ([i915#6434]) -> [PASS][8] +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111784v1/bat-rpls-2/igt@i915_module_l...@reload.html

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

  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12484 -> Patchwork_111784v1

  CI-20190529: 20190529
  CI_DRM_12484: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7085: 11af20de3877b23a244b816453bfc41d83591a15 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111784v1: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

c121191df646 drm/i915/pxp: Promote pxp subsystem to top-level of i915

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/display: no need for gt/gen8_ppgtt.h

[Lucas De Marchi]

On Thu, Dec 08, 2022 at 03:36:38PM +0200, Jani Nikula wrote:

Remove an unnecessary include.

Signed-off-by: Jani Nikula 


maybe we should run a script/something to check for unneeded includes
and commit everything? Then we can add a check in CI

include-what-you-use  does this, but I'm not sure it can grok
kernel / i915

Anyway,

Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_display.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 32b257157186..6cdfdae2c712 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -70,8 +70,6 @@
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_object.h"

-#include "gt/gen8_ppgtt.h"
-
#include "g4x_dp.h"
#include "g4x_hdmi.h"
#include "hsw_ips.h"
--
2.34.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v12,1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Patchwork]

== Series Details ==

Series: series starting with [v12,1/1] drm/i915/pxp: Promote pxp subsystem to 
top-level of i915
URL   : https://patchwork.freedesktop.org/series/111784/
State : warning

== Summary ==

Error: dim checkpatch failed
87504ad1ee18 drm/i915/pxp: Promote pxp subsystem to top-level of i915
-:131: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#131: 
References: 
https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.ale...@intel.com

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/display: use fetch_and_zero if applicable

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: use fetch_and_zero if 
applicable
URL   : https://patchwork.freedesktop.org/series/111772/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12480_full -> Patchwork_111772v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (14 -> 14)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_create@hog-create@smem0:
- {shard-rkl}:[PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-rkl-5/igt@gem_create@hog-cre...@smem0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-rkl-6/igt@gem_create@hog-cre...@smem0.html
- {shard-dg1}:NOTRUN -> [CRASH][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-dg1-17/igt@gem_create@hog-cre...@smem0.html

  * igt@gem_ctx_isolation@preservation@vcs1:
- {shard-dg1}:NOTRUN -> [FAIL][4] +4 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-dg1-15/igt@gem_ctx_isolation@preservat...@vcs1.html

  * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs:
- {shard-tglu-9}: NOTRUN -> [SKIP][5] +18 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-tglu-9/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
- {shard-rkl}:[SKIP][6] ([i915#1845] / [i915#4098]) -> [FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-rkl-1/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-rkl-6/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@dmabuf@all@dma_fence_chain:
- shard-skl:  NOTRUN -> [INCOMPLETE][8] ([i915#6949])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-skl2/igt@dmabuf@all@dma_fence_chain.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-iclb1/igt@gem_exec_balan...@parallel-balancer.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-glk6/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271]) +186 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-skl4/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_whisper@basic-queues-priority:
- shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([i915#6453])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/shard-iclb2/igt@gem_exec_whis...@basic-queues-priority.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/shard-iclb2/igt@gem_exec_whis...@basic-queues-priority.html

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

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

  * igt@gem_spin_batch@user-each:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#2898])
   [21]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/display: kill fetch_and_zero usage

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/display: kill fetch_and_zero usage
URL   : https://patchwork.freedesktop.org/series/111782/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12484 -> Patchwork_111782v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (26 -> 26)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-skl-6700k2:  [PASS][1] -> [FAIL][2] ([i915#5032])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-skl-6700k2/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111782v1/fi-skl-6700k2/boot.html

  

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][3] ([i915#7229]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111782v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][5] ([i915#6434]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111782v1/bat-rpls-2/igt@i915_module_l...@reload.html

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

  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5032]: https://gitlab.freedesktop.org/drm/intel/issues/5032
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12484 -> Patchwork_111782v1

  CI-20190529: 20190529
  CI_DRM_12484: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7085: 11af20de3877b23a244b816453bfc41d83591a15 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111782v1: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

5a2388bc41db drm/i915: kill fetch_and_zero
72a0dabc2481 drm/i915/gvt: kill fetch_and_zero usage
2d414c0675fc drm/i915/gt: kill fetch_and_zero usage
5d4cee671e1e drm/i915/display: kill fetch_and_zero usage

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+

[Navare, Manasi]

On Wed, Dec 07, 2022 at 11:35:24PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2022 at 01:05:15PM -0800, Navare, Manasi wrote:
> > On Wed, Dec 07, 2022 at 05:10:54PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 05, 2022 at 12:34:25PM -0800, Navare, Manasi wrote:
> > > > On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > We are miscalculating both the guardband value, and the resulting
> > > > > vblank exit length on adl+. This means that our start of vblank
> > > > > (double buffered register latch point) is incorrect, and we also
> > > > > think that it's not where it actually is (hence vblank evasion/etc.
> > > > > may not work properly). Fix up the calculations to match the real
> > > > > hardware behaviour (as reverse engineered by intel_display_poller).
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > index 6655dd2c1684..753e7b211708 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > > @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const 
> > > > > struct intel_crtc_state *crtc_stat
> > > > >   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > >   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > > >  
> > > > > - /* The hw imposes the extra scanline before frame start */
> > > > >   if (DISPLAY_VER(i915) >= 13)
> > > > > - return crtc_state->vrr.guardband + 
> > > > > crtc_state->framestart_delay + 1;
> > > > > + return crtc_state->vrr.guardband;
> > > > 
> > > > This makes sense since with guardband, there is no framestart delay
> > > 
> > > framestart delay is still a thing. But it's not something that
> > > affects how the hardware interprets the guardband value.
> > > 
> > > > 
> > > > >   else
> > > > > + /* The hw imposes the extra scanline before frame start 
> > > > > */
> > > > >   return crtc_state->vrr.pipeline_full + 
> > > > > crtc_state->framestart_delay + 1;
> > > > >  }
> > > > >  
> > > > > @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state 
> > > > > *crtc_state,
> > > > >* number of scan lines. Assuming 0 for no DSB.
> > > > >*/
> > > > >   crtc_state->vrr.guardband =
> > > > > - crtc_state->vrr.vmin - 
> > > > > adjusted_mode->crtc_vdisplay;
> > > > > + crtc_state->vrr.vmin + 1 - 
> > > > > adjusted_mode->crtc_vdisplay;
> > > > 
> > > > Why are we adding + 1 here? The bspec says guardband should be :
> > > > Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0
> > > > If we need that + 1 to get this working, then perhaps we need to update
> > > > Bspec?
> > > 
> > > flipline is what actaully determines the start of vblank, and
> > > 'flipline>=vmin+1' always.
> > 
> > Flipline would be always >=vmin as per the bspec,
> 
> Not sure where in bspec you see that. All I see is >vmin,
> and it even says you et an extra line if you try to set them
> equal. Pretty sure I verified that behaviour on the hw on icl/tgl
> since I put the extra -1 to the vmin calculation. Though I haven't
> actually tested it on adl+.

You are right for these current platforms it still needs >=Vmin + 1.

Reviewed-by: Manasi Navare 

Manasi

> 
> > have we tried with
> > that or if that definitely doesnt work then we need to have this changed
> > in the bspec.
> > 
> > Either way if this is the only value that works then with this change
> > added to bspec:
> > 
> > Reviewed-by: Manasi Navare 
> > 
> > Manasi
> > 
> > > 
> > > > 
> > > > I kind of want to see if this is still breaking if we dont have that +
> > > > 1?
> > > 
> > > Without it start of vblank happens one line later than where we want it
> > > to happen.
> > > 
> > > > 
> > > > Manasi
> > > > 
> > > > >   } else {
> > > > >   crtc_state->vrr.pipeline_full =
> > > > >   min(255, crtc_state->vrr.vmin - 
> > > > > adjusted_mode->crtc_vdisplay -
> > > > > -- 
> > > > > 2.37.4
> > > > > 
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> 
> -- 
> Ville Syrjälä
> Intel

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/display: kill fetch_and_zero usage

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/display: kill fetch_and_zero usage
URL   : https://patchwork.freedesktop.org/series/111782/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function

[Navare, Manasi]

On Wed, Nov 23, 2022 at 12:05:51PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
> 
> v2: Removed multiple blank lines
> v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp
> to reflect its meaning more properly.
> (Manasi Navare)
> 
> Signed-off-by: Stanislav Lisovskiy 

Looks good now,

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 50 +
>  drivers/gpu/drm/i915/display/intel_dp.h |  1 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  1 -
>  3 files changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 44e2424a54c0..d78216fba0a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -672,6 +672,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
>   return 6144 * 8;
>  }
>  
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp, 
> u32 pipe_bpp)
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs 
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA 
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(>drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
>  u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
>   u32 link_clock, u32 lane_count,
>   u32 mode_clock, u32 mode_hdisplay,
> @@ -680,7 +710,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
> *i915,
>   u32 timeslots)
>  {
>   u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>  
>   /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -713,24 +742,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
> *i915,
>   bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
>   }
>  
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs 
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA 
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel, 
> pipe_bpp);
>  
>   /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..e4faccf87370 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
> lane_count)
>  }
>  
>  u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp, 
> u32 pipe_bpp);
>  
>  void intel_ddi_update_pipe(struct intel_atomic_state *state,
>  struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 59f80af8d17d..b4f01c01dc1c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -115,7 

[Intel-gfx] ✓ Fi.CI.BAT: success for ALSA: hda/hdmi: i915 keepalive fixes

[Patchwork]

== Series Details ==

Series: ALSA: hda/hdmi: i915 keepalive fixes
URL   : https://patchwork.freedesktop.org/series/111781/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12484 -> Patchwork_111781v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (26 -> 26)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][1] -> [FAIL][2] ([i915#6298])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111781v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][3] ([i915#2582]) -> [PASS][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@fb...@read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111781v1/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][5] ([i915#7229]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111781v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][7] ([i915#6434]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111781v1/bat-rpls-2/igt@i915_module_l...@reload.html

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

  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12484 -> Patchwork_111781v1

  CI-20190529: 20190529
  CI_DRM_12484: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7085: 11af20de3877b23a244b816453bfc41d83591a15 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111781v1: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

43e74c47eb1b ALSA: hda/hdmi: fix stream-id config keep-alive for rt suspend
8146c5bf0fbd ALSA: hda/hdmi: set default audio parameters for KAE silent-stream
a589063a9cd7 ALSA: hda/hdmi: fix i915 silent stream programming flow

== Logs ==

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

[Intel-gfx] [PATCH v12 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Alan Previn]

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
   (such as intel_pxp_enabled/active) will have to check implicitly
   if i915->pxp is valid as that structure will not be allocated
   for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
   ensuring that GT init happens before PXP init and vice versa
   for fini. This causes a minor ordering change whereby we previously
   called intel_pxp_suspend after intel_uc_suspend but now is before
   i915_gem_suspend_late but the change is required for correct
   dependency flows. Additionally, this re-order change doesn't
   have any impact because at that point in either case, the top level
   entry to i915 won't observe any PXP events (since the GPU was
   quiesced during suspend_prepare). Also, any PXP event doesn't
   really matter when we disable the PXP HW (global GT irqs are
   already off anyway, so even if there was a bug that generated
   spurious events we wouldn't see it and we would just clean it
   up on resume which is okay since the default fallback action
   for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
  v11: - Reformat a comment (Tvrtko).
  v10: - Change the code flow for intel_pxp_init to make it more
 cleaner and readible with better comments explaining the
 difference between full-PXP-feature vs the partial-teelink
 inits depending on the platform. Additionally, only do
 the pxp allocation when we are certain the subsystem is
 needed. (Tvrtko).
   v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
   - Add comments for intel_pxp_init and pxp_get_ctrl_gt that
 explain the functional flow for when PXP is not supported
 but the backend-assets are needed for HuC authentication
 (Daniele and Tvrtko).
   - Fix two remaining functions that are accessible outside
 PXP that need to be checking pxp ptrs before using them:
 intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
 (Tvrtko and Daniele).
   - User helper macro in pxp-debugfs (Tvrtko).
   v8: - Remove pxp_to_gt macro (Daniele).
   - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
 support GSC-FW on it. (Daniele).
   - Leave i915->pxp as NULL if we dont support PXP and in line
 with that, do additional validity check on i915->pxp for
 intel_pxp_is_supported/enabled/active (Daniele).
   - Remove unncessary include header from intel_gt_debugfs.c
 and check drm_minor i915->drm.primary (Daniele).
   - Other cosmetics / minor issues / more comments on suspend
 flow order change (Daniele).
   v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
 through out instead of local variable newpxp. (Rodrigo)
   - In the case intel_pxp_fini is called during driver unload but
 after i915 loading failed without pxp being allocated, check
 i915->pxp before referencing it. (Alan)
   v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
 because : [1] introduction of 'ctrl_gt' means we correct this
 for MTL's upcoming series now. [2] Also, this has little impact
 globally as its only used by 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Patchwork]

== Series Details ==

Series: drm/i915: add new "soc" sub-directory and move PCH and DRAM code there
URL   : https://patchwork.freedesktop.org/series/111780/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12484 -> Patchwork_111780v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (26 -> 24)
--

  Missing(2): fi-rkl-11600 bat-dg1-6 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-2}:   [FAIL][1] ([i915#6559]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@fbdev@read:
- {bat-rpls-2}:   [SKIP][5] ([i915#2582]) -> [PASS][6] +4 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/bat-rpls-2/igt@fb...@read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/bat-rpls-2/igt@fb...@read.html

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][7] ([i915#7229]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12484/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111780v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

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

  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12484 -> Patchwork_111780v1

  CI-20190529: 20190529
  CI_DRM_12484: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7085: 11af20de3877b23a244b816453bfc41d83591a15 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111780v1: 77e03ccd7fc350435bb8b82cb5d5126bea437113 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

e19f375030dc drm/i915: add new "soc" sub-directory and move PCH and DRAM code 
there

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Patchwork]

== Series Details ==

Series: drm/i915: add new "soc" sub-directory and move PCH and DRAM code there
URL   : https://patchwork.freedesktop.org/series/111780/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Patchwork]

== Series Details ==

Series: drm/i915: add new "soc" sub-directory and move PCH and DRAM code there
URL   : https://patchwork.freedesktop.org/series/111780/
State : warning

== Summary ==

Error: dim checkpatch failed
78cff63f4926 drm/i915: add new "soc" sub-directory and move PCH and DRAM code 
there
-:92: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#92: 
rename from drivers/gpu/drm/i915/intel_dram.c

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: Add OA support by enabling 32 bit OAG formats for MTL

[Umesh Nerlige Ramappa]

On Wed, Nov 30, 2022 at 05:05:35PM -0800, Umesh Nerlige Ramappa wrote:

Without an entry in oa_init_supported_formats, OA will not be functional
in MTL. Enable OA support by enabling 32 bit OAG formats for MTL.


Thanks Lionel for sharing the Mesa MR for MTL -
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20228

Regards,
Umesh


Signed-off-by: Umesh Nerlige Ramappa 
---
drivers/gpu/drm/i915/i915_perf.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8369ae4b850d..a735b9540113 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4772,6 +4772,7 @@ static void oa_init_supported_formats(struct i915_perf 
*perf)
break;

case INTEL_DG2:
+   case INTEL_METEORLAKE:
oa_format_add(perf, I915_OAR_FORMAT_A32u40_A4u32_B8_C8);
oa_format_add(perf, I915_OA_FORMAT_A24u40_A14u32_B8_C8);
break;
--
2.36.1

Re: [Intel-gfx] [PATCH v11 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Teres Alexis, Alan Previn]

On Thu, 2022-12-08 at 09:29 +, Tvrtko Ursulin wrote:
> Just some small comments and questions below.
> 
> On 08/12/2022 05:01, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > 
Alan:[snip]
> IMO this looks great now - pretty self-documenting, all the complicated 
> checks are contained to the init phase, and the comments are really good.
> 
> Hopefully someone who knows the flows can cross-check this approach and 
> r-b, Daniele I suspect (copied)? From me its an ack.
> 
> Acked-by: Tvrtko Ursulin 
> 

Alan: Thanks Tvrtko. As per offline email, i created an internal JIRA to track 
the other follow ups (intel_pxp_foo(pxp) -> intel_pxp_foo(i915) and inlines 
that could use
CONFIG_I915_PXP - something that was there before but was removed for DG2 - 
perhaps could be added back in with accommodation on the internal functions). 
I will rev v12 to fix the comments and Daniele has agreed to review the changes 
from v9 (prior RB point).

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915 and PAT attributes on Xen PV

[Patchwork]

== Series Details ==

Series: i915 and PAT attributes on Xen PV
URL   : https://patchwork.freedesktop.org/series/111776/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12483 -> Patchwork_111776v1


Summary
---

  **FAILURE**

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

Participating hosts (37 -> 37)
--

  Additional (2): fi-hsw-4770 bat-dg1-5 
  Missing(2): fi-rkl-11600 bat-dg1-6 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@busy@all:
- fi-glk-j4005:   [PASS][1] -> [FAIL][2] +19 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-glk-j4005/igt@gem_busy@b...@all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-glk-j4005/igt@gem_busy@b...@all.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-elk-e7500:   [PASS][3] -> [TIMEOUT][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@bcs0:
- fi-bsw-nick:[PASS][5] -> [FAIL][6] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html
- fi-bsw-kefka:   [PASS][7] -> [TIMEOUT][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@bcs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-glk-j4005:   [PASS][9] -> [TIMEOUT][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-glk-j4005/igt@gem_exec_fence@nb-aw...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-glk-j4005/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-bsw-nick:[PASS][11] -> [TIMEOUT][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_tiled_blits@basic:
- fi-ilk-650: NOTRUN -> [TIMEOUT][13] +6 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-ilk-650/igt@gem_tiled_bl...@basic.html

  * igt@i915_module_load@load:
- fi-ilk-650: NOTRUN -> [FAIL][14] +18 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-ilk-650/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-elk-e7500/igt@i915_selftest@l...@mman.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][17] -> [FAIL][18] +9 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@varying-size:
- fi-pnv-d510:[PASS][19] -> [FAIL][20] +4 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-pnv-d510/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@varying-size.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-pnv-d510/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@varying-size.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-ivb-3770:[PASS][21] -> [FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-ivb-3770/igt@kms_frontbuffer_track...@basic.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111776v1/fi-ivb-3770/igt@kms_frontbuffer_track...@basic.html
- fi-rkl-guc: [PASS][23] -> [FAIL][24]
   

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Andrzej Hajda]

On 08.12.2022 16:44, Tvrtko Ursulin wrote:


On 08/12/2022 15:02, Jani Nikula wrote:

On Thu, 08 Dec 2022, "Vivi, Rodrigo"  wrote:

On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:

On Thu, 08 Dec 2022, Andrzej Hajda  wrote:

Simplify the code.


Personally, I absolutely hate fetch_and_zero().

I understand the point, but there are two main traps:

First, the name implies atomicity, which there is none at all.

Second, the name implies it's part of a kernel core header, which it
isn't, and this just amplifies the first point.

It's surprising and misleading, and those are not things I like about
interfaces in the kernel.

I would not like to see this proliferate. If fetch_and_zero() was
atomic
*and* part of a core kernel header, it would be a different matter.
But
I don't think that's going to happen, exactly because it won't be
atomic
and the name implies it is.


+1 here.

Please let's go the other way around and try to kill macros like this.

we either kill or we ensure this gets accepted in the core kernel
libraries.


Agreed. I'd be fine with either:

1) Get something like this accepted in core kernel headers:

#define fetch_and_zero(ptr) xchg(ptr, 0)

2) Do this in i915:

@@
expression E;
@@

- fetch_and_zero(E)
+ xchg(E, 0)


We don't need atomic so both solution would IMO be bad.


Heh, too late, already sent :)



We could propose __fetch_and_zero and fetch_and_zero, to mimic 
__set_bit/set_bit for some consistency in terms of atomic vs 
non-atomic API flavour?




Or non-atomic xchg


Assuming of course people will think that the long-ish name of the 
utility macro brings an overall positive cost benefit.


Worth a try I guess.

First step I think we need a cocci script for finding the open coded 
"fetch and zero" pattern. Not my forte but I can try if no one else has 
an immediate solution or desire to drive the attempt.


About 1600 patterns:
x = y;
y = 0;

but I guess there could be more:
x = xchg(, 0);

x = y;
...
y = 0;

custom macros

Regards
Andrzej




Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 1/3] ALSA: hda/hdmi: fix i915 silent stream programming flow

[Amadeusz Sławiński]

On 12/8/2022 4:43 PM, Kai Vehmanen wrote:

The i915 display codec may not successfully transition to
normal audio streaming mode, if the stream id is programmed
while codec is actively transmitting data. This can happen
when silent stream is enabled in KAE mode.

Fix the issue by implementing a i915 specific programming
flow, where the silent streaming is temporarily stopped,
a small delay is applied to ensure display codec becomes
idle, and then proceed with reprogramming the stream ID.

Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7353
Signed-off-by: Kai Vehmanen 
Reviewed-by: Pierre-Louis Bossart 
Tested-by: Rodrigo Vivi 
---
  sound/pci/hda/patch_hdmi.c | 23 +--
  1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 7a40ddfd695a..a0ba24165ae2 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2879,9 +2879,28 @@ static int i915_hsw_setup_stream(struct hda_codec 
*codec, hda_nid_t cvt_nid,
 hda_nid_t pin_nid, int dev_id, u32 stream_tag,
 int format)
  {
+   struct hdmi_spec *spec = codec->spec;
+   int pin_idx = pin_id_to_pin_index(codec, pin_nid, dev_id);


Shouldn't return value from pin_id_to_pin_index() be checked? It seems 
that it can return -EINVAL.



+   struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
+   int res;
+
haswell_verify_D0(codec, cvt_nid, pin_nid);
-   return hdmi_setup_stream(codec, cvt_nid, pin_nid, dev_id,
-stream_tag, format);
+
+   if (spec->silent_stream_type == SILENT_STREAM_KAE && per_pin && 
per_pin->silent_stream) {
+   silent_stream_set_kae(codec, per_pin, false);
+   /* wait for pending transfers in codec to clear */
+   usleep_range(100, 200);
+   }
+
+   res = hdmi_setup_stream(codec, cvt_nid, pin_nid, dev_id,
+   stream_tag, format);
+
+   if (spec->silent_stream_type == SILENT_STREAM_KAE && per_pin && 
per_pin->silent_stream) {
+   usleep_range(100, 200);
+   silent_stream_set_kae(codec, per_pin, true);
+   }
+
+   return res;
  }
  
  /* pin_cvt_fixup ops override for HSW+ and VLV+ */

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 and PAT attributes on Xen PV

[Patchwork]

== Series Details ==

Series: i915 and PAT attributes on Xen PV
URL   : https://patchwork.freedesktop.org/series/111776/
State : warning

== Summary ==

Error: dim checkpatch failed
d4d2b7cd4c8c i915 and PAT attributes on Xen PV
-:59: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: no need for gt/gen8_ppgtt.h

[Patchwork]

== Series Details ==

Series: drm/i915/display: no need for gt/gen8_ppgtt.h
URL   : https://patchwork.freedesktop.org/series/111775/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12483 -> Patchwork_111775v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 25)
--

  Additional (1): fi-hsw-4770 
  Missing(13): fi-kbl-soraka fi-rkl-11600 bat-kbl-2 bat-adls-5 bat-adlp-9 
fi-bsw-n3050 bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 bat-jsl-3 bat-dg2-11 
fi-bsw-nick 

Known issues


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

### CI changes ###

 Possible fixes 

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

  

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][3] -> [FAIL][4] ([i915#7229])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-ilk-650: NOTRUN -> [SKIP][5] ([fdo#109271]) +20 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/fi-ilk-650/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +11 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

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

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

  * igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1072]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}:   [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][12] ([i915#6257]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12483/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111775v1/bat-rpls-2/igt@i915_selftest@l...@requests.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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7350]: https://gitlab.freedesktop.org/drm/intel/issues/7350


Build changes
-

  * Linux: CI_DRM_12483 -> Patchwork_111775v1

  CI-20190529: 20190529
  CI_DRM_12483: 365a519c3ad617b35a9c0eb49ba530614aa2c4f2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7085: 11af20de3877b23a244b816453bfc41d83591a15 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111775v1: 365a519c3ad617b35a9c0eb49ba530614aa2c4f2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

0f6e4c3e6a32 drm/i915/display: no need for gt/gen8_ppgtt.h

== Logs ==

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

[Intel-gfx] [PATCH 4/4] drm/i915: kill fetch_and_zero

[Andrzej Hajda]

Macro has been replaced with shorter and generic xchg(ptr, 0).

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 6 +++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
 drivers/gpu/drm/i915/i915_hwmon.c | 2 +-
 drivers/gpu/drm/i915/i915_perf.c  | 2 +-
 drivers/gpu/drm/i915/i915_query.c | 2 +-
 drivers/gpu/drm/i915/i915_request.c   | 4 ++--
 drivers/gpu/drm/i915/i915_utils.h | 6 --
 drivers/gpu/drm/i915/i915_vma.c   | 2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 2 +-
 drivers/gpu/drm/i915/intel_uncore.c   | 4 ++--
 drivers/gpu/drm/i915/intel_wakeref.c  | 4 ++--
 drivers/gpu/drm/i915/pxp/intel_pxp.c  | 2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  | 4 ++--
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 2 +-
 16 files changed, 23 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 05a27723ebb8cb..215d4cf6effb60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -209,7 +209,7 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object 
*obj)
 
assert_object_held_shared(obj);
 
-   pages = fetch_and_zero(>mm.pages);
+   pages = xchg(>mm.pages, NULL);
if (IS_ERR_OR_NULL(pages))
return pages;
 
@@ -515,7 +515,7 @@ void __i915_gem_object_release_map(struct 
drm_i915_gem_object *obj)
 * Furthermore, since this is an unsafe operation reserved only
 * for construction time manipulation, we ignore locking prudence.
 */
-   unmap_object(obj, page_mask_bits(fetch_and_zero(>mm.mapping)));
+   unmap_object(obj, page_mask_bits(xchg(>mm.mapping, 0)));
 
i915_gem_object_unpin_map(obj);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index bc952107880734..360609f482b45b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -652,7 +652,7 @@ static void
 i915_gem_object_release_stolen(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct drm_mm_node *stolen = fetch_and_zero(>stolen);
+   struct drm_mm_node *stolen = xchg(>stolen, NULL);
 
GEM_BUG_ON(!stolen);
i915_gem_stolen_remove_node(i915, stolen);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13e6..91f1165ed30b91 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -447,7 +447,7 @@ int i915_ttm_purge(struct drm_i915_gem_object *obj)
 */
shmem_truncate_range(file_inode(i915_tt->filp),
 0, (loff_t)-1);
-   fput(fetch_and_zero(_tt->filp));
+   fput(xchg(_tt->filp, 0));
}
 
obj->write_domain = 0;
@@ -779,7 +779,7 @@ static int __i915_ttm_get_pages(struct drm_i915_gem_object 
*obj,
int ret;
 
/* First try only the requested placement. No eviction. */
-   real_num_busy = fetch_and_zero(>num_busy_placement);
+   real_num_busy = xchg(>num_busy_placement, 0);
ret = ttm_bo_validate(bo, placement, );
if (ret) {
ret = i915_ttm_err_to_gem(ret);
@@ -905,7 +905,7 @@ static void i915_ttm_put_pages(struct drm_i915_gem_object 
*obj,
 */
 
if (obj->mm.rsgt)
-   i915_refct_sgt_put(fetch_and_zero(>mm.rsgt));
+   i915_refct_sgt_put(xchg(>mm.rsgt, 0));
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index ac02fb03659208..c78ac7f0e15f9c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -615,7 +615,7 @@ static void throttle_release(struct i915_request **q, int 
count)
if (IS_ERR_OR_NULL(q[i]))
continue;
 
-   i915_request_put(fetch_and_zero([i]));
+   i915_request_put(xchg([i], 0));
}
 }
 
@@ -1072,7 +1072,7 @@ __sseu_prepare(const char *name,
 err_fini:
igt_spinner_fini(*spin);
 err_free:
-   kfree(fetch_and_zero(spin));
+   kfree(xchg(spin, 0));
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index cca7a4350ec8fd..bbdffcde7300f5 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -732,5 +732,5 @@ void i915_hwmon_register(struct drm_i915_private 

[Intel-gfx] [PATCH 3/4] drm/i915/gvt: kill fetch_and_zero usage

[Andrzej Hajda]

Macro fetch_and_zero will be dropped.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 077892a9aa8fdc..dca775b874deaa 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1831,7 +1831,7 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 static void intel_gvt_clean_device(struct drm_i915_private *i915)
 {
-   struct intel_gvt *gvt = fetch_and_zero(>gvt);
+   struct intel_gvt *gvt = xchg(>gvt, NULL);
 
if (drm_WARN_ON(>drm, !gvt))
return;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 9cd8fcbf7cad16..f6cec1098a186b 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -826,7 +826,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
/* We might still need to add request with
 * clean ctx to retire it properly..
 */
-   rq = fetch_and_zero(>req);
+   rq = xchg(>req, NULL);
i915_request_put(rq);
}
 
@@ -1103,7 +1103,7 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
intel_vgpu_trigger_virtual_event(vgpu, event);
}
 
-   i915_request_put(fetch_and_zero(>req));
+   i915_request_put(xchg(>req, 0));
}
 
gvt_dbg_sched("ring id %d complete workload %p status %d\n",
-- 
2.34.1

[Intel-gfx] [PATCH 2/4] drm/i915/gt: kill fetch_and_zero usage

[Andrzej Hajda]

Macro fetch_and_zero will be dropped.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++--
 drivers/gpu/drm/i915/gt/intel_gsc.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c   | 4 ++--
 drivers/gpu/drm/i915/gt/intel_gt_pm.c| 2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 6 +++---
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_rps.c  | 2 +-
 drivers/gpu/drm/i915/gt/selftest_context.c   | 2 +-
 drivers/gpu/drm/i915/gt/selftest_ring_submission.c   | 2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c  | 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
 16 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d6702b..a756ac519a1e0b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1024,7 +1024,7 @@ static void cleanup_status_page(struct intel_engine_cs 
*engine)
/* Prevent writes into HWSP after returning the page to the system */
intel_engine_set_hwsp_writemask(engine, ~0u);
 
-   vma = fetch_and_zero(>status_page.vma);
+   vma = xchg(>status_page.vma, NULL);
if (!vma)
return;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 9a527e1f5be655..18d2be92e8a536 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -229,7 +229,7 @@ static void heartbeat(struct work_struct *wrk)
mutex_unlock(>timeline->mutex);
 out:
if (!engine->i915->params.enable_hangcheck || !next_heartbeat(engine))
-   i915_request_put(fetch_and_zero(>heartbeat.systole));
+   i915_request_put(xchg(>heartbeat.systole, 0));
intel_engine_pm_put(engine);
 }
 
@@ -244,7 +244,7 @@ void intel_engine_unpark_heartbeat(struct intel_engine_cs 
*engine)
 void intel_engine_park_heartbeat(struct intel_engine_cs *engine)
 {
if (cancel_delayed_work(>heartbeat.work))
-   i915_request_put(fetch_and_zero(>heartbeat.systole));
+   i915_request_put(xchg(>heartbeat.systole, 0));
 }
 
 void intel_gt_unpark_heartbeats(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 49a8f10d76c77b..f7c8f30baa17ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3197,7 +3197,7 @@ static void execlists_reset_cancel(struct intel_engine_cs 
*engine)
RB_CLEAR_NODE(rb);
 
spin_lock(>base.sched_engine->lock);
-   rq = fetch_and_zero(>request);
+   rq = xchg(>request, NULL);
if (rq) {
if (i915_request_mark_eio(rq)) {
rq->engine = engine;
@@ -3602,7 +3602,7 @@ static void rcu_virtual_context_destroy(struct 
work_struct *wrk)
 
spin_lock_irq(>base.sched_engine->lock);
 
-   old = fetch_and_zero(>request);
+   old = xchg(>request, NULL);
if (old) {
GEM_BUG_ON(!__i915_request_is_complete(old));
__i915_request_submit(old);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 0c7fe360f87331..a3980476cb3919 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -684,7 +684,7 @@ static void fini_aliasing_ppgtt(struct i915_ggtt *ggtt)
 {
struct i915_ppgtt *ppgtt;
 
-   ppgtt = fetch_and_zero(>alias);
+   ppgtt = xchg(>alias, NULL);
if (!ppgtt)
return;
 
@@ -1238,7 +1238,7 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
   was_bound);
 
if (obj) { /* only used during resume => exclusive access */
-   write_domain_objs |= fetch_and_zero(>write_domain);
+   write_domain_objs |= xchg(>write_domain, 0);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index bcc3605158dbde..836826ed75dc0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -70,7 +70,7 @@ gsc_ext_om_alloc(struct intel_gsc 

[Intel-gfx] [PATCH 1/4] drm/i915/display: kill fetch_and_zero usage

[Andrzej Hajda]

Macro fetch_and_zero will be dropped.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |  6 ++---
 drivers/gpu/drm/i915/display/intel_display.c  |  4 ++--
 .../drm/i915/display/intel_display_power.c| 22 +--
 drivers/gpu/drm/i915/display/intel_dmc.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |  6 ++---
 drivers/gpu/drm/i915/display/intel_fbdev.c|  3 ++-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  4 ++--
 drivers/gpu/drm/i915/display/intel_pps.c  |  4 ++--
 drivers/gpu/drm/i915/display/intel_tc.c   |  4 ++--
 10 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index d16b30a2dded33..505e21e5ae1df7 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1425,7 +1425,7 @@ static void gen11_dsi_disable_io_power(struct 
intel_encoder *encoder)
for_each_dsi_port(port, intel_dsi->ports) {
intel_wakeref_t wakeref;
 
-   wakeref = fetch_and_zero(_dsi->io_wakeref[port]);
+   wakeref = xchg(_dsi->io_wakeref[port], 0);
intel_display_power_put(dev_priv,
port == PORT_A ?
POWER_DOMAIN_PORT_DDI_IO_A :
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5f9a2410fc4c35..fca39847390a53 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -902,7 +902,7 @@ main_link_aux_power_domain_put(struct intel_digital_port 
*dig_port,
intel_ddi_main_link_aux_domain(dig_port, crtc_state);
intel_wakeref_t wf;
 
-   wf = fetch_and_zero(_port->aux_wakeref);
+   wf = xchg(_port->aux_wakeref, 0);
if (!wf)
return;
 
@@ -2678,7 +2678,7 @@ static void intel_ddi_post_disable_dp(struct 
intel_atomic_state *state,
if (!intel_tc_port_in_tbt_alt_mode(dig_port))
intel_display_power_put(dev_priv,
dig_port->ddi_io_power_domain,
-   
fetch_and_zero(_port->ddi_io_wakeref));
+   xchg(_port->ddi_io_wakeref, 0));
 
intel_ddi_disable_clock(encoder);
 }
@@ -2705,7 +2705,7 @@ static void intel_ddi_post_disable_hdmi(struct 
intel_atomic_state *state,
 
intel_display_power_put(dev_priv,
dig_port->ddi_io_power_domain,
-   fetch_and_zero(_port->ddi_io_wakeref));
+   xchg(_port->ddi_io_wakeref, 0));
 
intel_ddi_disable_clock(encoder);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 32b25715718644..16d55f9c8f9e91 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -964,7 +964,7 @@ void intel_display_finish_reset(struct drm_i915_private 
*i915)
if (!test_bit(I915_RESET_MODESET, _gt(i915)->reset.flags))
return;
 
-   state = fetch_and_zero(>display.restore.modeset_state);
+   state = xchg(>display.restore.modeset_state, NULL);
if (!state)
goto unlock;
 
@@ -7591,7 +7591,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
 * cleanup. So copy and reset the dsb structure to sync with
 * commit_done and later do dsb cleanup in cleanup_work.
 */
-   old_crtc_state->dsb = fetch_and_zero(_crtc_state->dsb);
+   old_crtc_state->dsb = xchg(_crtc_state->dsb, NULL);
}
 
/* Underruns don't always raise interrupts, so check manually */
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 3adba64937de68..f7640573683041 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -474,7 +474,7 @@ intel_display_power_grab_async_put_ref(struct 
drm_i915_private *dev_priv,
 
cancel_delayed_work(_domains->async_put_work);
intel_runtime_pm_put_raw(_priv->runtime_pm,
-
fetch_and_zero(_domains->async_put_wakeref));
+xchg(_domains->async_put_wakeref, 0));
 out_verify:
verify_async_put_domains_state(power_domains);
 
@@ -660,7 +660,7 @@ intel_display_power_put_async_work(struct work_struct *work)
 * Bail out if all the domain refs pending to be released were grabbed
 * by subsequent gets or a flush_work.
 */
-   old_work_wakeref = fetch_and_zero(_domains->async_put_wakeref);
+   old_work_wakeref = xchg(_domains->async_put_wakeref, 0);
 

Re: [Intel-gfx] [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use

[Andy Shevchenko]

On Thu, Dec 08, 2022 at 02:14:54PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 08, 2022 at 02:54:45PM +0200, Andy Shevchenko wrote:
> > On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote:
> > > Some of the existing users, and definitely will be new ones, want to
> > > count existing nodes in the list. Provide a generic API for that by
> > > moving code from i915 to list.h.
> > 
> > Greg, I believe this one is ready to be taken. Or please tell me what I need
> > to do.
> 
> Wait for me to get through the current backlog of patches that I have in
> my review queue.  Odds are, it will have to wait until after 6.2-rc1 is
> out based on when 6.1 is going to be released.

It's fine, no hurry and take your time!

> Don't worry, it's not lost.

Thank you, got it!

-- 
With Best Regards,
Andy Shevchenko

[Intel-gfx] [PATCH 3/3] ALSA: hda/hdmi: fix stream-id config keep-alive for rt suspend

[Kai Vehmanen]

When the new style KAE keep-alive implementation is used on compatible
Intel hardware, the clocks are maintained when codec is in D3. The
generic code in hda_cleanup_all_streams() can however interfere with
generation of audio samples in this mode, by setting the stream and
channel ids to zero.

To get full benefit of the keepalive, set the new
no_stream_clean_at_suspend quirk bit on affected Intel hardware. When
this bit is set, stream cleanup is skipped in hda_call_codec_suspend().

Special handling is needed for the case when system goes to suspend. The
stream id programming can be lost in this case. This will also cause
codec->cvt_setups to be out of sync. Handle this by implementing custom
suspend/resume handlers. If keep-alive is active for any converter, set
the quirk flags no_stream_clean_at_suspend and forced_resume. Upon
resume, keepalive programming is restored if needed.

Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
Signed-off-by: Kai Vehmanen 
Reviewed-by: Pierre-Louis Bossart 
---
 include/sound/hda_codec.h  |  1 +
 sound/pci/hda/hda_codec.c  |  3 +-
 sound/pci/hda/patch_hdmi.c | 90 +-
 3 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h
index 25ec8c181688..eba23daf2c29 100644
--- a/include/sound/hda_codec.h
+++ b/include/sound/hda_codec.h
@@ -258,6 +258,7 @@ struct hda_codec {
unsigned int link_down_at_suspend:1; /* link down at runtime suspend */
unsigned int relaxed_resume:1;  /* don't resume forcibly for jack */
unsigned int forced_resume:1; /* forced resume for jack */
+   unsigned int no_stream_clean_at_suspend:1; /* do not clean streams at 
suspend */
 
 #ifdef CONFIG_PM
unsigned long power_on_acct;
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index b4d1e658c556..edd653ece70d 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2886,7 +2886,8 @@ static unsigned int hda_call_codec_suspend(struct 
hda_codec *codec)
snd_hdac_enter_pm(>core);
if (codec->patch_ops.suspend)
codec->patch_ops.suspend(codec);
-   hda_cleanup_all_streams(codec);
+   if (!codec->no_stream_clean_at_suspend)
+   hda_cleanup_all_streams(codec);
state = hda_set_power_state(codec, AC_PWRST_D3);
update_power_acct(codec, true);
snd_hdac_leave_pm(>core);
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 1618419647aa..dfae3443f6bd 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2921,6 +2921,88 @@ static void i915_pin_cvt_fixup(struct hda_codec *codec,
}
 }
 
+#ifdef CONFIG_PM
+static int i915_adlp_hdmi_suspend(struct hda_codec *codec)
+{
+   struct hdmi_spec *spec = codec->spec;
+   bool silent_streams = false;
+   int pin_idx, res;
+
+   res = generic_hdmi_suspend(codec);
+
+   for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
+   struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
+
+   if (per_pin->silent_stream) {
+   silent_streams = true;
+   break;
+   }
+   }
+
+   if (silent_streams && spec->silent_stream_type == SILENT_STREAM_KAE) {
+   /*
+* stream-id should remain programmed when codec goes
+* to runtime suspend
+*/
+   codec->no_stream_clean_at_suspend = 1;
+
+   /*
+* the system might go to S3, in which case keep-alive
+* must be reprogrammed upon resume
+*/
+   codec->forced_resume = 1;
+
+   codec_dbg(codec, "HDMI: KAE active at suspend\n");
+   } else {
+   codec->no_stream_clean_at_suspend = 0;
+   codec->forced_resume = 0;
+   }
+
+   return res;
+}
+
+static int i915_adlp_hdmi_resume(struct hda_codec *codec)
+{
+   struct hdmi_spec *spec = codec->spec;
+   int pin_idx, res;
+
+   res = generic_hdmi_resume(codec);
+
+   /* KAE not programmed at suspend, nothing to do here */
+   if (!codec->no_stream_clean_at_suspend)
+   return res;
+
+   for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
+   struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
+
+   /*
+* If system was in suspend with monitor connected,
+* the codec setting may have been lost. Re-enable
+* keep-alive.
+*/
+   if (per_pin->silent_stream) {
+   unsigned int param;
+
+   param = snd_hda_codec_read(codec, per_pin->cvt_nid, 0,
+  AC_VERB_GET_CONV, 0);
+   if (!param) {
+   codec_dbg(codec, "HDMI: KAE: 

[Intel-gfx] [PATCH 2/3] ALSA: hda/hdmi: set default audio parameters for KAE silent-stream

[Kai Vehmanen]

If the stream-id is zero, the keep-alive (KAE) will only ensure clock is
generated, but no audio samples are sent over display link. This happens
before first real audio stream is played out to a newly connected
receiver.

Reuse the code in silent_stream_enable() to set up stream parameters
to sane defaults values, also when using the newer keep-alive flow.

Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
Signed-off-by: Kai Vehmanen 
Reviewed-by: Pierre-Louis Bossart 
Tested-by: Rodrigo Vivi 
---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index a0ba24165ae2..1618419647aa 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1738,6 +1738,7 @@ static void silent_stream_enable(struct hda_codec *codec,
 
switch (spec->silent_stream_type) {
case SILENT_STREAM_KAE:
+   silent_stream_enable_i915(codec, per_pin);
silent_stream_set_kae(codec, per_pin, true);
break;
case SILENT_STREAM_I915:
-- 
2.38.1

[Intel-gfx] [PATCH 1/3] ALSA: hda/hdmi: fix i915 silent stream programming flow

[Kai Vehmanen]

The i915 display codec may not successfully transition to
normal audio streaming mode, if the stream id is programmed
while codec is actively transmitting data. This can happen
when silent stream is enabled in KAE mode.

Fix the issue by implementing a i915 specific programming
flow, where the silent streaming is temporarily stopped,
a small delay is applied to ensure display codec becomes
idle, and then proceed with reprogramming the stream ID.

Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7353
Signed-off-by: Kai Vehmanen 
Reviewed-by: Pierre-Louis Bossart 
Tested-by: Rodrigo Vivi 
---
 sound/pci/hda/patch_hdmi.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 7a40ddfd695a..a0ba24165ae2 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2879,9 +2879,28 @@ static int i915_hsw_setup_stream(struct hda_codec 
*codec, hda_nid_t cvt_nid,
 hda_nid_t pin_nid, int dev_id, u32 stream_tag,
 int format)
 {
+   struct hdmi_spec *spec = codec->spec;
+   int pin_idx = pin_id_to_pin_index(codec, pin_nid, dev_id);
+   struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx);
+   int res;
+
haswell_verify_D0(codec, cvt_nid, pin_nid);
-   return hdmi_setup_stream(codec, cvt_nid, pin_nid, dev_id,
-stream_tag, format);
+
+   if (spec->silent_stream_type == SILENT_STREAM_KAE && per_pin && 
per_pin->silent_stream) {
+   silent_stream_set_kae(codec, per_pin, false);
+   /* wait for pending transfers in codec to clear */
+   usleep_range(100, 200);
+   }
+
+   res = hdmi_setup_stream(codec, cvt_nid, pin_nid, dev_id,
+   stream_tag, format);
+
+   if (spec->silent_stream_type == SILENT_STREAM_KAE && per_pin && 
per_pin->silent_stream) {
+   usleep_range(100, 200);
+   silent_stream_set_kae(codec, per_pin, true);
+   }
+
+   return res;
 }
 
 /* pin_cvt_fixup ops override for HSW+ and VLV+ */
-- 
2.38.1

[Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: i915 keepalive fixes

[Kai Vehmanen]

A series with multiple fixes to i915 keepalive (KAE)
functionality. First patch fixes issue that is hit on
some A750/770 cards:
https://gitlab.freedesktop.org/drm/intel/-/issues/7353

The two other improve behaviour especially with certain
USB-C docks.

Kai Vehmanen (3):
  ALSA: hda/hdmi: fix i915 silent stream programming flow
  ALSA: hda/hdmi: set default audio parameters for KAE silent-stream
  ALSA: hda/hdmi: fix stream-id config keep-alive for rt suspend

 include/sound/hda_codec.h  |   1 +
 sound/pci/hda/hda_codec.c  |   3 +-
 sound/pci/hda/patch_hdmi.c | 114 -
 3 files changed, 114 insertions(+), 4 deletions(-)


base-commit: 81a2da5a10a6eaa6ae16108eed4e74651cc296bf
-- 
2.38.1

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Tvrtko Ursulin]

On 08/12/2022 15:02, Jani Nikula wrote:

On Thu, 08 Dec 2022, "Vivi, Rodrigo"  wrote:

On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:

On Thu, 08 Dec 2022, Andrzej Hajda  wrote:

Simplify the code.


Personally, I absolutely hate fetch_and_zero().

I understand the point, but there are two main traps:

First, the name implies atomicity, which there is none at all.

Second, the name implies it's part of a kernel core header, which it
isn't, and this just amplifies the first point.

It's surprising and misleading, and those are not things I like about
interfaces in the kernel.

I would not like to see this proliferate. If fetch_and_zero() was
atomic
*and* part of a core kernel header, it would be a different matter.
But
I don't think that's going to happen, exactly because it won't be
atomic
and the name implies it is.


+1 here.

Please let's go the other way around and try to kill macros like this.

we either kill or we ensure this gets accepted in the core kernel
libraries.


Agreed. I'd be fine with either:

1) Get something like this accepted in core kernel headers:

#define fetch_and_zero(ptr) xchg(ptr, 0)

2) Do this in i915:

@@
expression E;
@@

- fetch_and_zero(E)
+ xchg(E, 0)


We don't need atomic so both solution would IMO be bad.

We could propose __fetch_and_zero and fetch_and_zero, to mimic 
__set_bit/set_bit for some consistency in terms of atomic vs 
non-atomic API flavour?


Assuming of course people will think that the long-ish name of the 
utility macro brings an overall positive cost benefit.


Worth a try I guess.

First step I think we need a cocci script for finding the open coded 
"fetch and zero" pattern. Not my forte but I can try if no one else has 
an immediate solution or desire to drive the attempt.


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915: Fix whitespace

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 8/9] drm/i915: Fix whitespace
> 
> From: Ville Syrjälä 
> 
> Stray spaces have snuck in where everything else uses tabs.
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index f6bc896338de..880c530d5832 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -535,7 +535,7 @@ void intel_pps_check_power_unlocked(struct
> intel_dp *intel_dp)  }
> 
>  #define IDLE_ON_MASK (PP_ON | PP_SEQUENCE_MASK | 0
> | PP_SEQUENCE_STATE_MASK)
> -#define IDLE_ON_VALUE(PP_ON | PP_SEQUENCE_NONE | 0
> | PP_SEQUENCE_STATE_ON_IDLE)
> +#define IDLE_ON_VALUE(PP_ON | PP_SEQUENCE_NONE | 0
> | PP_SEQUENCE_STATE_ON_IDLE)
> 
>  #define IDLE_OFF_MASK(PP_ON | PP_SEQUENCE_MASK | 0
> | 0)
>  #define IDLE_OFF_VALUE   (0 | PP_SEQUENCE_NONE | 0
> | 0)
> --
> 2.37.4

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Improve PPS debugs

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 9/9] drm/i915: Improve PPS debugs
> 
> From: Ville Syrjälä 
> 
> Always include both the encoder and PPS instance information in the debug
> prints so that we know what piece of hardware we're actually dealing with.
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 184 +++
>  1 file changed, 121 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 880c530d5832..98ae7836c8ab 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -22,6 +22,36 @@ static void vlv_steal_power_sequencer(struct
> drm_i915_private *dev_priv,  static void pps_init_delays(struct intel_dp
> *intel_dp);  static void pps_init_registers(struct intel_dp *intel_dp, bool
> force_disable_vdd);
> 
> +static const char *pps_name(struct drm_i915_private *i915,
> + struct intel_pps *pps)
> +{
> + if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> + switch (pps->pps_pipe) {
> + case PIPE_A:
> + return "PPS A";
> + case PIPE_B:
> + return "PPS B";
> + case PIPE_C:
> + return "PPS C";
> + default:
> + MISSING_CASE(pps->pps_pipe);
> + break;
> + }
> + } else {
> + switch (pps->pps_idx) {
> + case 0:
> + return "PPS 0";
> + case 1:
> + return "PPS 1";
> + default:
> + MISSING_CASE(pps->pps_idx);
> + break;
> + }
> + }
> +
> + return "PPS ";
> +}
> +
>  intel_wakeref_t intel_pps_lock(struct intel_dp *intel_dp)  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); @@ -
> 60,15 +90,15 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
> 
>   if (drm_WARN(_priv->drm,
>intel_de_read(dev_priv, intel_dp->output_reg) &
> DP_PORT_EN,
> -  "skipping pipe %c power sequencer kick due to
> [ENCODER:%d:%s] being active\n",
> -  pipe_name(pipe), dig_port->base.base.base.id,
> -  dig_port->base.base.name))
> +  "skipping %s kick due to [ENCODER:%d:%s] being
> active\n",
> +  pps_name(dev_priv, _dp->pps),
> +  dig_port->base.base.base.id, dig_port->base.base.name))
>   return;
> 
>   drm_dbg_kms(_priv->drm,
> - "kicking pipe %c power sequencer for
> [ENCODER:%d:%s]\n",
> - pipe_name(pipe), dig_port->base.base.base.id,
> - dig_port->base.base.name);
> + "kicking %s for [ENCODER:%d:%s]\n",
> + pps_name(dev_priv, _dp->pps),
> + dig_port->base.base.base.id, dig_port->base.base.name);
> 
>   /* Preserve the BIOS-computed detected bit. This is
>* supposed to be read-only.
> @@ -95,7 +125,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
> 
>   if (vlv_force_pll_on(dev_priv, pipe, vlv_get_dpll(dev_priv))) {
>   drm_err(_priv->drm,
> - "Failed to force on pll for pipe %c!\n",
> + "Failed to force on PLL for pipe %c!\n",
>   pipe_name(pipe));
>   return;
>   }
> @@ -190,10 +220,9 @@ vlv_power_sequencer_pipe(struct intel_dp
> *intel_dp)
>   intel_dp->pps.pps_pipe = pipe;
> 
>   drm_dbg_kms(_priv->drm,
> - "picked pipe %c power sequencer for
> [ENCODER:%d:%s]\n",
> - pipe_name(intel_dp->pps.pps_pipe),
> - dig_port->base.base.base.id,
> - dig_port->base.base.name);
> + "picked %s for [ENCODER:%d:%s]\n",
> + pps_name(dev_priv, _dp->pps),
> + dig_port->base.base.base.id, dig_port->base.base.name);
> 
>   /* init power sequencer on this pipe and port */
>   pps_init_delays(intel_dp);
> @@ -297,17 +326,15 @@ vlv_initial_power_sequencer_setup(struct intel_dp
> *intel_dp)
>   /* didn't find one? just let vlv_power_sequencer_pipe() pick one
> when needed */
>   if (intel_dp->pps.pps_pipe == INVALID_PIPE) {
>   drm_dbg_kms(_priv->drm,
> - "no initial power sequencer for
> [ENCODER:%d:%s]\n",
> - dig_port->base.base.base.id,
> - dig_port->base.base.name);
> + "[ENCODER:%d:%s] no initial power sequencer\n",
> + dig_port->base.base.base.id, 

Re: [Intel-gfx] [PATCH v2 7/9] drm/i915: Print the PPS registers using consistent format

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 7/9] drm/i915: Print the PPS registers using consistent
> format
> 
> From: Ville Syrjälä 
> 
> Use the consistent format when dumping out the PPS control/status
> registers. Helps with pattern matching.
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index d18c1c58dfcf..f6bc896338de 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -527,7 +527,8 @@ void intel_pps_check_power_unlocked(struct
> intel_dp *intel_dp)
>   if (!edp_have_panel_power(intel_dp) &&
> !edp_have_panel_vdd(intel_dp)) {
>   drm_WARN(_priv->drm, 1,
>"eDP powered off while attempting aux channel
> communication.\n");
> - drm_dbg_kms(_priv->drm, "Status 0x%08x Control
> 0x%08x\n",
> + drm_dbg_kms(_priv->drm,
> + "PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n",
>   intel_de_read(dev_priv, _pp_stat_reg(intel_dp)),
>   intel_de_read(dev_priv, _pp_ctrl_reg(intel_dp)));
>   }
> @@ -559,7 +560,7 @@ static void wait_panel_status(struct intel_dp
> *intel_dp,
>   pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
> 
>   drm_dbg_kms(_priv->drm,
> - "mask %08x value %08x status %08x control %08x\n",
> + "mask: 0x%08x value: 0x%08x PP_STATUS: 0x%08x
> PP_CONTROL:
> +0x%08x\n",
>   mask, value,
>   intel_de_read(dev_priv, pp_stat_reg),
>   intel_de_read(dev_priv, pp_ctrl_reg)); @@ -567,7 +568,7
> @@ static void wait_panel_status(struct intel_dp *intel_dp,
>   if (intel_de_wait_for_register(dev_priv, pp_stat_reg,
>  mask, value, 5000))
>   drm_err(_priv->drm,
> - "Panel status timeout: status %08x control %08x\n",
> + "Panel status timeout: PP_STATUS: 0x%08x
> PP_CONTROL: 0x%08x\n",
>   intel_de_read(dev_priv, pp_stat_reg),
>   intel_de_read(dev_priv, pp_ctrl_reg));
> 
> --
> 2.37.4

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Reject unusablee power sequencers

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 6/9] drm/i915: Reject unusablee power sequencers
> 
> From: Ville Syrjälä 
> 
> On ICP-ADP the pins used by the second PPS can be alternatively muxed to
> some other function. In that case the second power sequencer is unusable.
> 
> Unfortunately (on my ADL Thinkpad T14 gen3 at least) the BIOS still likes to
> enable the VDD on the second PPS (due to the VBT declaring the second
> bogus eDP panel) even when not correctly muxed, so we need to deal with it
> somehow.
> For now let's just initialize the PPS as normal, and then use the normal eDP
> probe failure VDD off path to turn it off (and release the wakeref the PPS 
> init
> grabbed). The alternative of just declaring that the platform has a single PPS
> doesn't really work since it would cause the second eDP probe to also try to
> use the first PPS and thus clobber the state for the first (real) eDP panel.
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c  | 12 -
> drivers/gpu/drm/i915/display/intel_pps.c | 34 +---
> drivers/gpu/drm/i915/display/intel_pps.h |  2 +-
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  4 files changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c1bebe77ed8e..9deaa5e3632a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5283,7 +5283,17 @@ static bool intel_edp_init_connector(struct
> intel_dp *intel_dp,
>   intel_bios_init_panel_early(dev_priv, _connector->panel,
>   encoder->devdata);
> 
> - intel_pps_init(intel_dp);
> + if (!intel_pps_init(intel_dp)) {
> + drm_info(_priv->drm,
> +  "[ENCODER:%d:%s] unusable PPS, disabling eDP\n",
> +  encoder->base.base.id, encoder->base.name);
> + /*
> +  * The BIOS may have still enabled VDD on the PPS even
> +  * though it's unusable. Make sure we turn it back off
> +  * and to release the power domain references/etc.
> +  */
> + goto out_vdd_off;
> + }
> 
>   /* Cache DPCD and EDID for edp. */
>   has_dpcd = intel_edp_init_dpcd(intel_dp); diff --git
> a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 77b0a4f27abc..d18c1c58dfcf 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -327,6 +327,18 @@ static int intel_num_pps(struct drm_i915_private
> *i915)
>   return 1;
>  }
> 
> +static bool intel_pps_is_valid(struct intel_dp *intel_dp) {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (intel_dp->pps.pps_idx == 1 &&
> + INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> + INTEL_PCH_TYPE(i915) < PCH_MTP)
> + return intel_de_read(i915, SOUTH_CHICKEN1) &
> +ICP_SECOND_PPS_IO_SELECT;
> +
> + return true;
> +}
> +
>  static int
>  bxt_initial_pps_idx(struct drm_i915_private *i915, pps_check check)  { @@ -
> 340,7 +352,7 @@ bxt_initial_pps_idx(struct drm_i915_private *i915,
> pps_check check)
>   return -1;
>  }
> 
> -static void
> +static bool
>  pps_initial_setup(struct intel_dp *intel_dp)  {
>   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> @@ -351,7 +363,7 @@ pps_initial_setup(struct intel_dp *intel_dp)
> 
>   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
>   vlv_initial_power_sequencer_setup(intel_dp);
> - return;
> + return true;
>   }
> 
>   /* first ask the VBT */
> @@ -377,13 +389,14 @@ pps_initial_setup(struct intel_dp *intel_dp)
>   "[ENCODER:%d:%s] no initial power sequencer,
> assuming %d\n",
>   encoder->base.base.id, encoder->base.name,
>   intel_dp->pps.pps_idx);
> - return;
> + } else {
> + drm_dbg_kms(>drm,
> + "[ENCODER:%d:%s] initial power sequencer:
> %d\n",
> + encoder->base.base.id, encoder->base.name,
> + intel_dp->pps.pps_idx);
>   }
> 
> - drm_dbg_kms(>drm,
> - "[ENCODER:%d:%s] initial power sequencer: %d\n",
> - encoder->base.base.id, encoder->base.name,
> - intel_dp->pps.pps_idx);
> + return intel_pps_is_valid(intel_dp);
>  }
> 
>  void intel_pps_reset_all(struct drm_i915_private *dev_priv) @@ -1504,9
> +1517,10 @@ void intel_pps_encoder_reset(struct intel_dp *intel_dp)
>   }
>  }
> 
> -void intel_pps_init(struct intel_dp *intel_dp)
> +bool intel_pps_init(struct intel_dp *intel_dp)

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: Extend dual PPS handlind for ICP+

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 5/9] drm/i915: Extend dual PPS handlind for ICP+
> 
> From: Ville Syrjälä 
> 
> On the PCH side the second PPS was introduced in ICP. Let's make sure we
> examine both power sequencer on ICP+ as well.
> 
> Note that DG1/2 south block only has the single PPS, so need to exclude the
> fake DG1/2 PCHs.
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 44 +---
>  1 file changed, 32 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index d8d2f22f3e0c..77b0a4f27abc 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -310,10 +310,27 @@ vlv_initial_power_sequencer_setup(struct intel_dp
> *intel_dp)
>   pipe_name(intel_dp->pps.pps_pipe));
>  }
> 
> +static int intel_num_pps(struct drm_i915_private *i915) {
> + if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> + return 2;
> +
> + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
> + return 2;
> +
> + if (INTEL_PCH_TYPE(i915) >= PCH_DG1)
> + return 1;
> +
> + if (INTEL_PCH_TYPE(i915) >= PCH_ICP)
> + return 2;
> +
> + return 1;
> +}
> +
>  static int
>  bxt_initial_pps_idx(struct drm_i915_private *i915, pps_check check)  {
> - int pps_idx, pps_num = 2;
> + int pps_idx, pps_num = intel_num_pps(i915);
> 
>   for (pps_idx = 0; pps_idx < pps_num; pps_idx++) {
>   if (check(i915, pps_idx))
> @@ -337,12 +354,13 @@ pps_initial_setup(struct intel_dp *intel_dp)
>   return;
>   }
> 
> - if (!IS_GEMINILAKE(i915) && !IS_BROXTON(i915))
> - return;
> -
>   /* first ask the VBT */
> - intel_dp->pps.pps_idx = connector->panel.vbt.backlight.controller;
> - if (drm_WARN_ON(>drm, intel_dp->pps.pps_idx >= 2))
> + if (intel_num_pps(i915) > 1)
> + intel_dp->pps.pps_idx = connector-
> >panel.vbt.backlight.controller;
> + else
> + intel_dp->pps.pps_idx = 0;
> +
> + if (drm_WARN_ON(>drm, intel_dp->pps.pps_idx >=
> +intel_num_pps(i915)))
>   intel_dp->pps.pps_idx = -1;
> 
>   /* VBT wasn't parsed yet? pick one where the panel is on */ @@ -
> 416,7 +434,7 @@ static void intel_pps_get_registers(struct intel_dp
> *intel_dp,
>   struct pps_registers *regs)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - int pps_idx = 0;
> + int pps_idx;
> 
>   memset(regs, 0, sizeof(*regs));
> 
> @@ -424,6 +442,8 @@ static void intel_pps_get_registers(struct intel_dp
> *intel_dp,
>   pps_idx = vlv_power_sequencer_pipe(intel_dp);
>   else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
>   pps_idx = bxt_power_sequencer_idx(intel_dp);
> + else
> + pps_idx = intel_dp->pps.pps_idx;
> 
>   regs->pp_ctrl = PP_CONTROL(pps_idx);
>   regs->pp_stat = PP_STATUS(pps_idx);
> @@ -1508,7 +1528,10 @@ static void pps_init_late(struct intel_dp *intel_dp)
>   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
>   struct intel_connector *connector = intel_dp->attached_connector;
> 
> - if (!IS_GEMINILAKE(i915) && !IS_BROXTON(i915))
> + if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> + return;
> +
> + if (intel_num_pps(i915) < 2)
>   return;
> 
>   drm_WARN(>drm, connector->panel.vbt.backlight.controller
> >= 0 && @@ -1551,10 +1574,7 @@ void intel_pps_unlock_regs_wa(struct
> drm_i915_private *dev_priv)
>* This w/a is needed at least on CPT/PPT, but to be sure apply it
>* everywhere where registers can be write protected.
>*/
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - pps_num = 2;
> - else
> - pps_num = 1;
> + pps_num = intel_num_pps(dev_priv);
> 
>   for (pps_idx = 0; pps_idx < pps_num; pps_idx++) {
>   u32 val = intel_de_read(dev_priv, PP_CONTROL(pps_idx));
> --
> 2.37.4

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Try to use the correct power sequencer intiially on bxt/glk

[Manna, Animesh]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, November 25, 2022 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh 
> Subject: [PATCH v2 4/9] drm/i915: Try to use the correct power sequencer
> intiially on bxt/glk
> 
> From: Ville Syrjälä 
> 
> Currently on bxt/glk we just grab the power sequencer index from the VBT
> data even though it may not have been parsed yet. That could lead us to
> using the incorrect power sequencer during the initial panel probe.
> 
> To avoid that let's try to read out the current state of the power sequencer
> from the hardware. Unfortunately the power sequencer no longer has
> anything in its registers to associate it with the port, so the best we can 
> do is
> just iterate through the power sequencers and pick the first one. This should
> be sufficient for single panel cases.
> 
> For the dual panel cases we probably need to go back to parsing the VBT
> before the panel probe (and hope that panel_type=0xff is never a thing in
> those cases). To that end the code always prefers the VBT panel sequencer, if
> available.
> 
> v2: Restructure a bit for upcoming icp+ dual PPS support
> 
> Cc: Animesh Manna 
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Animesh Manna 

> ---
>  .../drm/i915/display/intel_display_types.h| 22 +++--
>  drivers/gpu/drm/i915/display/intel_panel.c|  1 +
>  drivers/gpu/drm/i915/display/intel_pps.c  | 96 +--
>  3 files changed, 102 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index cc64e787e401..32e8b2fc3cc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -330,7 +330,7 @@ struct intel_vbt_panel_data {
>   bool present;
>   bool active_low_pwm;
>   u8 min_brightness;  /* min_brightness/255 of max */
> - u8 controller;  /* brightness controller number */
> + s8 controller;  /* brightness controller number */
>   enum intel_backlight_type type;
>   } backlight;
> 
> @@ -1570,11 +1570,19 @@ struct intel_pps {
>   ktime_t panel_power_off_time;
>   intel_wakeref_t vdd_wakeref;
> 
> - /*
> -  * Pipe whose power sequencer is currently locked into
> -  * this port. Only relevant on VLV/CHV.
> -  */
> - enum pipe pps_pipe;
> + union {
> + /*
> +  * Pipe whose power sequencer is currently locked into
> +  * this port. Only relevant on VLV/CHV.
> +  */
> + enum pipe pps_pipe;
> +
> + /*
> +  * Power sequencer index. Only relevant on BXT+.
> +  */
> + int pps_idx;
> + };
> +
>   /*
>* Pipe currently driving the port. Used for preventing
>* the use of the PPS for any pipe currentrly driving @@ -1583,7
> +1591,7 @@ struct intel_pps {
>   enum pipe active_pipe;
>   /*
>* Set if the sequencer may be reset due to a power transition,
> -  * requiring a reinitialization. Only relevant on BXT.
> +  * requiring a reinitialization. Only relevant on BXT+.
>*/
>   bool pps_reset;
>   struct edp_power_seq pps_delays;
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 609fcdbd7d58..3b1004b019a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -666,6 +666,7 @@ void intel_panel_init_alloc(struct intel_connector
> *connector)
>   struct intel_panel *panel = >panel;
> 
>   connector->panel.vbt.panel_type = -1;
> + connector->panel.vbt.backlight.controller = -1;
>   INIT_LIST_HEAD(>fixed_modes);
>  }
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 41ab12fcce0e..d8d2f22f3e0c 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -212,8 +212,7 @@ static int
>  bxt_power_sequencer_idx(struct intel_dp *intel_dp)  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - struct intel_connector *connector = intel_dp->attached_connector;
> - int backlight_controller = connector->panel.vbt.backlight.controller;
> + int pps_idx = intel_dp->pps.pps_idx;
> 
>   lockdep_assert_held(_priv->display.pps.mutex);
> 
> @@ -221,7 +220,7 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
>   drm_WARN_ON(_priv->drm, !intel_dp_is_edp(intel_dp));
> 
>   if (!intel_dp->pps.pps_reset)
> - return backlight_controller;
> + return pps_idx;
> 
>   intel_dp->pps.pps_reset = false;
> 
> @@ -231,7 +230,7 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
>*/
>   pps_init_registers(intel_dp, false);
> 
> - return 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Andrzej Hajda]

On 08.12.2022 14:36, Vivi, Rodrigo wrote:

On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:

On Thu, 08 Dec 2022, Andrzej Hajda  wrote:

Simplify the code.


Personally, I absolutely hate fetch_and_zero().

I understand the point, but there are two main traps:

First, the name implies atomicity, which there is none at all.

Second, the name implies it's part of a kernel core header, which it
isn't, and this just amplifies the first point.

It's surprising and misleading, and those are not things I like about
interfaces in the kernel.

I would not like to see this proliferate. If fetch_and_zero() was
atomic
*and* part of a core kernel header, it would be a different matter.
But
I don't think that's going to happen, exactly because it won't be
atomic
and the name implies it is.


+1 here.

Please let's go the other way around and try to kill macros like this.

we either kill or we ensure this gets accepted in the core kernel
libraries.



There is about 80 uses of the macro in i915. So I guessed this is 
accepted solution in i915 :) Moreover it looked to me as a nice

shortcut.

If not, I can replace it with xchg(ptr, 0), besides tiny overkill, 
assuming atomicity is not required here, it should work.


I can also expand it :) - quite big patch, but cocci should do the work.

Anyway I think it would be good to take some decision here, to avoid 
further confusions.


Regards
Andrzej





BR,
Jani.




Signed-off-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
  1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 907ab7526cb478..2972d7533da44e 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -304,10 +304,8 @@ static void i915_digport_work_func(struct
work_struct *work)
 u32 old_bits = 0;
  
 spin_lock_irq(_priv->irq_lock);

-   long_port_mask = dev_priv->display.hotplug.long_port_mask;
-   dev_priv->display.hotplug.long_port_mask = 0;
-   short_port_mask = dev_priv-

display.hotplug.short_port_mask;

-   dev_priv->display.hotplug.short_port_mask = 0;
+   long_port_mask = fetch_and_zero(_priv-

display.hotplug.long_port_mask);

+   short_port_mask = fetch_and_zero(_priv-

display.hotplug.short_port_mask);

 spin_unlock_irq(_priv->irq_lock);
  
 for_each_intel_encoder(_priv->drm, encoder) {

@@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct
work_struct *work)
  
 spin_lock_irq(_priv->irq_lock);
  
-   hpd_event_bits = dev_priv->display.hotplug.event_bits;

-   dev_priv->display.hotplug.event_bits = 0;
-   hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
-   dev_priv->display.hotplug.retry_bits = 0;
+   hpd_event_bits = fetch_and_zero(_priv-

display.hotplug.event_bits);

+   hpd_retry_bits = fetch_and_zero(_priv-

display.hotplug.retry_bits);
  
 /* Enable polling for connectors which had HPD IRQ storms

*/
 intel_hpd_irq_storm_switch_to_polling(dev_priv);

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Jani Nikula]

On Thu, 08 Dec 2022, "Vivi, Rodrigo"  wrote:
> On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:
>> On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
>> > Simplify the code.
>> 
>> Personally, I absolutely hate fetch_and_zero().
>> 
>> I understand the point, but there are two main traps:
>> 
>> First, the name implies atomicity, which there is none at all.
>> 
>> Second, the name implies it's part of a kernel core header, which it
>> isn't, and this just amplifies the first point.
>> 
>> It's surprising and misleading, and those are not things I like about
>> interfaces in the kernel.
>> 
>> I would not like to see this proliferate. If fetch_and_zero() was
>> atomic
>> *and* part of a core kernel header, it would be a different matter.
>> But
>> I don't think that's going to happen, exactly because it won't be
>> atomic
>> and the name implies it is.
>
> +1 here.
>
> Please let's go the other way around and try to kill macros like this.
>
> we either kill or we ensure this gets accepted in the core kernel
> libraries.

Agreed. I'd be fine with either:

1) Get something like this accepted in core kernel headers:

#define fetch_and_zero(ptr) xchg(ptr, 0)

2) Do this in i915:

@@
expression E;
@@

- fetch_and_zero(E)
+ xchg(E, 0)


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH] drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Jani Nikula]

Add a new sub-directory for things that aren't specifically about the
GPU and don't really belong in the i915 driver top level, but also don't
belong under any of the existing sub-directories either.

Name it "soc", and move the PCH and DRAM code there.

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 

---

Naming, always the naming! soc? ext? offcore? In the Makefile I'm adding
comment "core peripheral code", which is also silly. *facepalm*
---
 drivers/gpu/drm/i915/Makefile   | 7 +--
 drivers/gpu/drm/i915/i915_driver.c  | 3 ++-
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/{ => soc}/intel_dram.c | 0
 drivers/gpu/drm/i915/{ => soc}/intel_dram.h | 0
 drivers/gpu/drm/i915/{ => soc}/intel_pch.c  | 0
 drivers/gpu/drm/i915/{ => soc}/intel_pch.h  | 0
 7 files changed, 9 insertions(+), 4 deletions(-)
 rename drivers/gpu/drm/i915/{ => soc}/intel_dram.c (100%)
 rename drivers/gpu/drm/i915/{ => soc}/intel_dram.h (100%)
 rename drivers/gpu/drm/i915/{ => soc}/intel_pch.c (100%)
 rename drivers/gpu/drm/i915/{ => soc}/intel_pch.h (100%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..7046e435a155 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -48,9 +48,7 @@ i915-y += i915_driver.o \
  i915_sysfs.o \
  i915_utils.o \
  intel_device_info.o \
- intel_dram.o \
  intel_memory_region.o \
- intel_pch.o \
  intel_pcode.o \
  intel_pm.o \
  intel_region_ttm.o \
@@ -62,6 +60,11 @@ i915-y += i915_driver.o \
  vlv_sideband.o \
  vlv_suspend.o
 
+# core peripheral code
+i915-y += \
+   soc/intel_dram.o \
+   soc/intel_pch.o
+
 # core library code
 i915-y += \
i915_memcpy.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 4cc3ced83959..6c87cfa0d7c8 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -75,6 +75,8 @@
 
 #include "pxp/intel_pxp_pm.h"
 
+#include "soc/intel_dram.h"
+
 #include "i915_file_private.h"
 #include "i915_debugfs.h"
 #include "i915_driver.h"
@@ -93,7 +95,6 @@
 #include "i915_sysfs.h"
 #include "i915_utils.h"
 #include "i915_vgpu.h"
-#include "intel_dram.h"
 #include "intel_gvt.h"
 #include "intel_memory_region.h"
 #include "intel_pci_config.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a8a5bd426e78..b6d0c12ffeea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,8 @@
 #include "gt/intel_workarounds.h"
 #include "gt/uc/intel_uc.h"
 
+#include "soc/intel_pch.h"
+
 #include "i915_drm_client.h"
 #include "i915_gem.h"
 #include "i915_gpu_error.h"
@@ -58,7 +60,6 @@
 #include "i915_utils.h"
 #include "intel_device_info.h"
 #include "intel_memory_region.h"
-#include "intel_pch.h"
 #include "intel_runtime_pm.h"
 #include "intel_step.h"
 #include "intel_uncore.h"
diff --git a/drivers/gpu/drm/i915/intel_dram.c 
b/drivers/gpu/drm/i915/soc/intel_dram.c
similarity index 100%
rename from drivers/gpu/drm/i915/intel_dram.c
rename to drivers/gpu/drm/i915/soc/intel_dram.c
diff --git a/drivers/gpu/drm/i915/intel_dram.h 
b/drivers/gpu/drm/i915/soc/intel_dram.h
similarity index 100%
rename from drivers/gpu/drm/i915/intel_dram.h
rename to drivers/gpu/drm/i915/soc/intel_dram.h
diff --git a/drivers/gpu/drm/i915/intel_pch.c 
b/drivers/gpu/drm/i915/soc/intel_pch.c
similarity index 100%
rename from drivers/gpu/drm/i915/intel_pch.c
rename to drivers/gpu/drm/i915/soc/intel_pch.c
diff --git a/drivers/gpu/drm/i915/intel_pch.h 
b/drivers/gpu/drm/i915/soc/intel_pch.h
similarity index 100%
rename from drivers/gpu/drm/i915/intel_pch.h
rename to drivers/gpu/drm/i915/soc/intel_pch.h
-- 
2.34.1

Re: [Intel-gfx] [PATCH] drm/i915: add new "soc" sub-directory and move PCH and DRAM code there

[Rodrigo Vivi]

On Thu, Dec 08, 2022 at 04:23:47PM +0200, Jani Nikula wrote:
> Add a new sub-directory for things that aren't specifically about the
> GPU and don't really belong in the i915 driver top level, but also don't
> belong under any of the existing sub-directories either.
> 
> Name it "soc", and move the PCH and DRAM code there.
> 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Naming, always the naming! soc? ext? offcore? In the Makefile I'm adding
> comment "core peripheral code", which is also silly. *facepalm*
> ---
>  drivers/gpu/drm/i915/Makefile   | 7 +--
>  drivers/gpu/drm/i915/i915_driver.c  | 3 ++-
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/{ => soc}/intel_dram.c | 0
>  drivers/gpu/drm/i915/{ => soc}/intel_dram.h | 0
>  drivers/gpu/drm/i915/{ => soc}/intel_pch.c  | 0
>  drivers/gpu/drm/i915/{ => soc}/intel_pch.h  | 0
>  7 files changed, 9 insertions(+), 4 deletions(-)
>  rename drivers/gpu/drm/i915/{ => soc}/intel_dram.c (100%)
>  rename drivers/gpu/drm/i915/{ => soc}/intel_dram.h (100%)
>  rename drivers/gpu/drm/i915/{ => soc}/intel_pch.c (100%)
>  rename drivers/gpu/drm/i915/{ => soc}/intel_pch.h (100%)
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 01974b82d205..7046e435a155 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -48,9 +48,7 @@ i915-y += i915_driver.o \
> i915_sysfs.o \
> i915_utils.o \
> intel_device_info.o \
> -   intel_dram.o \
> intel_memory_region.o \
> -   intel_pch.o \
> intel_pcode.o \

should pcode be moved as well?

> intel_pm.o \
> intel_region_ttm.o \
> @@ -62,6 +60,11 @@ i915-y += i915_driver.o \
> vlv_sideband.o \

and also maybe the sideband?

anyway,

Acked-by: Rodrigo Vivi 

> vlv_suspend.o
>  
> +# core peripheral code
> +i915-y += \
> + soc/intel_dram.o \
> + soc/intel_pch.o
> +
>  # core library code
>  i915-y += \
>   i915_memcpy.o \
> diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> b/drivers/gpu/drm/i915/i915_driver.c
> index 4cc3ced83959..6c87cfa0d7c8 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -75,6 +75,8 @@
>  
>  #include "pxp/intel_pxp_pm.h"
>  
> +#include "soc/intel_dram.h"
> +
>  #include "i915_file_private.h"
>  #include "i915_debugfs.h"
>  #include "i915_driver.h"
> @@ -93,7 +95,6 @@
>  #include "i915_sysfs.h"
>  #include "i915_utils.h"
>  #include "i915_vgpu.h"
> -#include "intel_dram.h"
>  #include "intel_gvt.h"
>  #include "intel_memory_region.h"
>  #include "intel_pci_config.h"
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a8a5bd426e78..b6d0c12ffeea 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -49,6 +49,8 @@
>  #include "gt/intel_workarounds.h"
>  #include "gt/uc/intel_uc.h"
>  
> +#include "soc/intel_pch.h"
> +
>  #include "i915_drm_client.h"
>  #include "i915_gem.h"
>  #include "i915_gpu_error.h"
> @@ -58,7 +60,6 @@
>  #include "i915_utils.h"
>  #include "intel_device_info.h"
>  #include "intel_memory_region.h"
> -#include "intel_pch.h"
>  #include "intel_runtime_pm.h"
>  #include "intel_step.h"
>  #include "intel_uncore.h"
> diff --git a/drivers/gpu/drm/i915/intel_dram.c 
> b/drivers/gpu/drm/i915/soc/intel_dram.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_dram.c
> rename to drivers/gpu/drm/i915/soc/intel_dram.c
> diff --git a/drivers/gpu/drm/i915/intel_dram.h 
> b/drivers/gpu/drm/i915/soc/intel_dram.h
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_dram.h
> rename to drivers/gpu/drm/i915/soc/intel_dram.h
> diff --git a/drivers/gpu/drm/i915/intel_pch.c 
> b/drivers/gpu/drm/i915/soc/intel_pch.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_pch.c
> rename to drivers/gpu/drm/i915/soc/intel_pch.c
> diff --git a/drivers/gpu/drm/i915/intel_pch.h 
> b/drivers/gpu/drm/i915/soc/intel_pch.h
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_pch.h
> rename to drivers/gpu/drm/i915/soc/intel_pch.h
> -- 
> 2.34.1
> 

[Intel-gfx] [PATCH v4 2/2] drm/i915/mtl: Limit scaler input to 4k in plane scaling

[Luca Coelho]

From: Animesh Manna 

As part of die area reduction max input source modified to 4096
for MTL so modified range check logic of scaler.

Signed-off-by: Jos� Roberto de Souza 
Signed-off-by: Animesh Manna 
Signed-off-by: Luca Coelho 
---
 drivers/gpu/drm/i915/display/skl_scaler.c | 31 +--
 1 file changed, 23 insertions(+), 8 deletions(-)

In v2:
   * No changes;

In v3:
   * Removed stray reviewed-by tag;
   * Added my s-o-b.

In v4:
   * No changes.

diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c 
b/drivers/gpu/drm/i915/display/skl_scaler.c
index d7390067b7d4..6baa07142b03 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -103,6 +103,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool 
force_detach,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
+   int min_src_w, min_src_h, min_dst_w, min_dst_h;
+   int max_src_w, max_src_h, max_dst_w, max_dst_h;
 
/*
 * Src coordinates are already rotated by 270 degrees for
@@ -157,15 +159,28 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
return -EINVAL;
}
 
+   min_src_w = SKL_MIN_SRC_W;
+   min_src_h = SKL_MIN_SRC_H;
+   min_dst_w = SKL_MIN_DST_W;
+   min_dst_h = SKL_MIN_DST_H;
+
+   if (DISPLAY_VER(dev_priv) >= 11 && DISPLAY_VER(dev_priv) < 14) {
+   max_src_w = ICL_MAX_SRC_W;
+   max_src_h = ICL_MAX_SRC_H;
+   max_dst_w = ICL_MAX_DST_W;
+   max_dst_h = ICL_MAX_DST_H;
+   } else {
+   max_src_w = SKL_MAX_SRC_W;
+   max_src_h = SKL_MAX_SRC_H;
+   max_dst_w = SKL_MAX_DST_W;
+   max_dst_h = SKL_MAX_DST_H;
+   }
+
/* range checks */
-   if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
-   dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
-   (DISPLAY_VER(dev_priv) >= 11 &&
-(src_w > ICL_MAX_SRC_W || src_h > ICL_MAX_SRC_H ||
- dst_w > ICL_MAX_DST_W || dst_h > ICL_MAX_DST_H)) ||
-   (DISPLAY_VER(dev_priv) < 11 &&
-(src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
- dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H))) {
+   if (src_w < min_src_w || src_h < min_src_h ||
+   dst_w < min_dst_w || dst_h < min_dst_h ||
+   src_w > max_src_w || src_h > max_src_h ||
+   dst_w > max_dst_w || dst_h > max_dst_h) {
drm_dbg_kms(_priv->drm,
"scaler_user index %u.%u: src %ux%u dst %ux%u "
"size is out of scaler range\n",
-- 
2.38.1

[Intel-gfx] [PATCH v4 1/2] drm/i915/mtl: limit second scaler vertical scaling in ver >= 14

[Luca Coelho]

In newer hardware versions (i.e. display version >= 14), the second
scaler doesn't support vertical scaling.

The current implementation of the scaling limits is simplified and
only occurs when the planes are created, so we don't know which scaler
is being used.

In order to handle separate scaling limits for horizontal and vertical
scaling, and different limits per scaler, split the checks in two
phases.  We first do a simple check during plane creation and use the
best-case scenario (because we don't know the scaler that may be used
at a later point) and then do a more specific check when the scalers
are actually being set up.

Signed-off-by: Luca Coelho 
---
 drivers/gpu/drm/i915/display/intel_atomic.c | 83 ++---
 1 file changed, 73 insertions(+), 10 deletions(-)

In v2:
   * fix DRM_PLANE_NO_SCALING renamed macros;

In v3:
   * No changes.

In v4:
   * Got rid of the changes in the general planes max scale code;
   * Added a couple of FIXMEs;
   * Made intel_atomic_setup_scaler() return an int with errors;
   

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 6621aa245caf..8373be283d8b 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -41,6 +41,7 @@
 #include "intel_global_state.h"
 #include "intel_hdcp.h"
 #include "intel_psr.h"
+#include "intel_fb.h"
 #include "skl_universal_plane.h"
 
 /**
@@ -310,11 +311,11 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
kfree(crtc_state);
 }
 
-static void intel_atomic_setup_scaler(struct intel_crtc_scaler_state 
*scaler_state,
- int num_scalers_need, struct intel_crtc 
*intel_crtc,
- const char *name, int idx,
- struct intel_plane_state *plane_state,
- int *scaler_id)
+static int intel_atomic_setup_scaler(struct intel_crtc_scaler_state 
*scaler_state,
+int num_scalers_need, struct intel_crtc 
*intel_crtc,
+const char *name, int idx,
+struct intel_plane_state *plane_state,
+int *scaler_id)
 {
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
int j;
@@ -334,7 +335,7 @@ static void intel_atomic_setup_scaler(struct 
intel_crtc_scaler_state *scaler_sta
 
if (drm_WARN(_priv->drm, *scaler_id < 0,
 "Cannot find scaler for %s:%d\n", name, idx))
-   return;
+   return -EBUSY;
 
/* set scaler mode */
if (plane_state && plane_state->hw.fb &&
@@ -375,9 +376,69 @@ static void intel_atomic_setup_scaler(struct 
intel_crtc_scaler_state *scaler_sta
mode = SKL_PS_SCALER_MODE_DYN;
}
 
+   /*
+* FIXME: we should also check the scaler factors for pfit, so
+* this shouldn't be tied directly to planes.
+*/
+   if (plane_state && plane_state->hw.fb) {
+   const struct drm_framebuffer *fb = plane_state->hw.fb;
+   struct drm_rect *src = _state->uapi.src;
+   struct drm_rect *dst = _state->uapi.dst;
+   int hscale, vscale, max_vscale, max_hscale;
+
+   /*
+* FIXME: When two scalers are needed, but only one of
+* them needs to downscale, we should make sure that
+* the one that needs downscaling support is assigned
+* as the first scaler, so we don't reject downscaling
+* unnecessarily.
+*/
+
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   /*
+* On versions 14 and up, only the first
+* scaler supports a vertical scaling factor
+* of more than 1.0, while a horizontal
+* scaling factor of 3.0 is supported.
+*/
+   max_hscale = 0x3 - 1;
+   if (*scaler_id == 0)
+   max_vscale = 0x3 - 1;
+   else
+   max_vscale = 0x1;
+
+   } else if (DISPLAY_VER(dev_priv) >= 10 ||
+  !intel_format_info_is_yuv_semiplanar(fb->format, 
fb->modifier)) {
+   max_hscale = 0x3 - 1;
+   max_vscale = 0x3 - 1;
+   } else {
+   max_hscale = 0x2 - 1;
+   max_vscale = 0x2 - 1;
+   }
+
+   /* Check if required scaling is within limits */
+   hscale = drm_rect_calc_hscale(src, dst, 1, max_hscale);
+   vscale = drm_rect_calc_vscale(src, dst, 1, max_vscale);
+
+   if (hscale < 0 || vscale < 0) {
+   

[Intel-gfx] i915 and PAT attributes on Xen PV

[Marek Marczykowski-Górecki]

Hi,

There is an issue with i915 on Xen PV (dom0). The end result is a lot of
glitches, like here: https://openqa.qubes-os.org/tests/54748#step/startup/8
(this one is on ADL, Linux 6.1-rc7 as a Xen PV dom0). It's using Xorg
with "modesetting" driver.

After some iterations of debugging, we narrowed it down to i915 handling
caching. The main difference is that PAT is setup differently on Xen PV
than on native Linux. Normally, Linux does have appropriate abstraction
for that, but apparently something related to i915 doesn't play well
with it. The specific difference is:
native linux:
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
xen pv:
x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC
  ~~  ~~  ~~  ~~

The specific impact depends on kernel version and the hardware. The most
severe issues I see on >=ADL, but some older hardware is affected too -
sometimes only if composition is disabled in the window manager.
Some more information is collected at
https://github.com/QubesOS/qubes-issues/issues/4782 (and few linked
duplicates...).

Kind-of related commit is here:
https://github.com/torvalds/linux/commit/bdd8b6c98239cad ("drm/i915:
replace X86_FEATURE_PAT with pat_enabled()") - it is the place where
i915 explicitly checks for PAT support, so I'm cc-ing people mentioned
there too.

Any ideas?

The issue can be easily reproduced without Xen too, by adjusting PAT in
Linux:
-8<-
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index 66a209f7eb86..319ab60c8d8c 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -400,8 +400,8 @@ void pat_init(void)
 * The reserved slots are unused, but mapped to their
 * corresponding types in the presence of PAT errata.
 */
-   pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
- PAT(4, WB) | PAT(5, WP) | PAT(6, UC_MINUS) | PAT(7, WT);
+   pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
+ PAT(4, WC) | PAT(5, WP) | PAT(6, UC)   | PAT(7, UC);
}
 
if (!pat_bp_initialized) {
-8<-

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings

[Niranjana Vishwanathapura]

On Tue, Dec 06, 2022 at 05:40:54PM +, Matthew Auld wrote:

On 01/12/2022 18:43, Niranjana Vishwanathapura wrote:

On Thu, Dec 01, 2022 at 07:27:31AM -0800, Niranjana Vishwanathapura wrote:

On Thu, Dec 01, 2022 at 10:49:15AM +, Matthew Auld wrote:

On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:

Support dump capture of persistent mappings upon user request.

Signed-off-by: Brian Welty 
Signed-off-by: Niranjana Vishwanathapura 


---
.../drm/i915/gem/i915_gem_vm_bind_object.c    | 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c   |  3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h   |  5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
drivers/gpu/drm/i915/i915_vma.c   |  1 +
drivers/gpu/drm/i915/i915_vma_types.h |  2 ++
include/uapi/drm/i915_drm.h   |  3 ++-
7 files changed, 43 insertions(+), 1 deletion(-)

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

index 78e7c0642c5f..50969613daf6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct 
i915_vma *vma, bool release_obj)

{
lockdep_assert_held(>vm->vm_bind_lock);
+    spin_lock(>vm->vm_capture_lock);
+    if (!list_empty(>vm_capture_link))
+    list_del_init(>vm_capture_link);
+    spin_unlock(>vm->vm_capture_lock);
+
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
    list_del_init(>vm_rebind_link);
@@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct 
i915_address_space *vm,

    continue;
    }
+    if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+    spin_lock(>vm_capture_lock);
+    list_add_tail(>vm_capture_link, 
>vm_capture_list);

+    spin_unlock(>vm_capture_lock);
+    }
+
    list_add_tail(>vm_bind_link, >vm_bound_list);
    i915_vm_bind_it_insert(vma, >va);
    if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c

index ebf6830574a0..bdabe13fc30e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,9 @@ void i915_address_space_init(struct 
i915_address_space *vm, int subclass)

spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+    INIT_LIST_HEAD(>vm_capture_list);
+    spin_lock_init(>vm_capture_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h

index 87e5b6568a00..8e4ddd073348 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,11 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private 
objects */

struct drm_i915_gem_object *root_obj;
+    /* @vm_capture_list: list of vm captures */
+    struct list_head vm_capture_list;
+    /* @vm_capture_lock: protects vm_capture_list */
+    spinlock_t vm_capture_lock;
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c

index 9d5d5a397b64..3b2b12a739f7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct 
intel_engine_capture_vma *next,

return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+    struct i915_address_space *vm, gfp_t gfp)
+{
+    struct i915_vma *vma;
+
+    spin_lock(>vm_capture_lock);


Does it make sense to move this into the eb3 submission stage, 
like we do for eb2? IIRC the gfp flags here are quite limiting 
due to potentially being in a fence critical section. If we can 
use rq->capture_list for eb3, we shouldn't need to change much 
here?




But that will add latency on submission path as we will have to iterate
over capture_list in each submission. Besides, unlike eb2 case, we can't
just transfer the list to rq->capture_list as we will have to do this
for each submission. It was discussed long time back and decided not to
bother the fast path (submision) scenario with this error capture which
is only required upon gpu hang (slow path).


Maybe add some of this to the commit message, just to give a bit more 
back story/history. From my pov I'm coming into this semi-blind.




Ok, will add.



Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should 
we take that into account?




Ok, will fix.

+    /* vma->resource must be valid here as persistent vmas 
are bound */

+    list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+    capture = capture_vma_snapshot(capture, vma->resource,
+   gfp, "user");
+    spin_unlock(>vm_capture_lock);
+

Re: [Intel-gfx] [PATCH] drm/i915: Fix VLV/CHV HDMI/DP audio enable

[Jani Nikula]

On Thu, 08 Dec 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Despite what I claimed in commit c3c5dc1d9224
> ("drm/i915/audio: Do the vblank waits") the vblank
> interrupts are in fact not enabled yet when we do the
> audio enable sequence on VLV/CHV (all other platforms are
> fine).
>
> Reorder the enable sequence on VLV/CHV to match that of the
> other platforms so that the audio enable happens after the
> pipe has been enabled.
>
> Fixes: c3c5dc1d9224 ("drm/i915/audio: Do the vblank waits")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/g4x_dp.c   |  4 +--
>  drivers/gpu/drm/i915/display/g4x_hdmi.c | 41 -
>  2 files changed, 29 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index 3593938dcd87..24ef36ec2d3d 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -673,8 +673,6 @@ static void intel_enable_dp(struct intel_atomic_state 
> *state,
>   intel_dp_pcon_dsc_configure(intel_dp, pipe_config);
>   intel_dp_start_link_train(intel_dp, pipe_config);
>   intel_dp_stop_link_train(intel_dp, pipe_config);
> -
> - intel_audio_codec_enable(encoder, pipe_config, conn_state);
>  }
>  
>  static void g4x_enable_dp(struct intel_atomic_state *state,
> @@ -683,6 +681,7 @@ static void g4x_enable_dp(struct intel_atomic_state 
> *state,
> const struct drm_connector_state *conn_state)
>  {
>   intel_enable_dp(state, encoder, pipe_config, conn_state);
> + intel_audio_codec_enable(encoder, pipe_config, conn_state);
>   intel_edp_backlight_on(pipe_config, conn_state);
>  }
>  
> @@ -691,6 +690,7 @@ static void vlv_enable_dp(struct intel_atomic_state 
> *state,
> const struct intel_crtc_state *pipe_config,
> const struct drm_connector_state *conn_state)
>  {
> + intel_audio_codec_enable(encoder, pipe_config, conn_state);
>   intel_edp_backlight_on(pipe_config, conn_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c 
> b/drivers/gpu/drm/i915/display/g4x_hdmi.c
> index 121caeaa409b..c3580d96765c 100644
> --- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
> @@ -157,24 +157,32 @@ static void intel_hdmi_get_config(struct intel_encoder 
> *encoder,
>_config->infoframes.hdmi);
>  }
>  
> +static void g4x_hdmi_enable_port(struct intel_encoder *encoder,
> +  const struct intel_crtc_state *pipe_config)
> +{
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);

Could clean up some of the drm_device and dev_priv on top.

Reviewed-by: Jani Nikula 


> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> + u32 temp;
> +
> + temp = intel_de_read(dev_priv, intel_hdmi->hdmi_reg);
> +
> + temp |= SDVO_ENABLE;
> + if (pipe_config->has_audio)
> + temp |= HDMI_AUDIO_ENABLE;
> +
> + intel_de_write(dev_priv, intel_hdmi->hdmi_reg, temp);
> + intel_de_posting_read(dev_priv, intel_hdmi->hdmi_reg);
> +}
> +
>  static void g4x_enable_hdmi(struct intel_atomic_state *state,
>   struct intel_encoder *encoder,
>   const struct intel_crtc_state *pipe_config,
>   const struct drm_connector_state *conn_state)
>  {
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> - u32 temp;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
> - temp = intel_de_read(dev_priv, intel_hdmi->hdmi_reg);
> -
> - temp |= SDVO_ENABLE;
> - if (pipe_config->has_audio)
> - temp |= HDMI_AUDIO_ENABLE;
> -
> - intel_de_write(dev_priv, intel_hdmi->hdmi_reg, temp);
> - intel_de_posting_read(dev_priv, intel_hdmi->hdmi_reg);
> + g4x_hdmi_enable_port(encoder, pipe_config);
>  
>   drm_WARN_ON(_priv->drm, pipe_config->has_audio &&
>   !pipe_config->has_hdmi_sink);
> @@ -294,6 +302,11 @@ static void vlv_enable_hdmi(struct intel_atomic_state 
> *state,
>   const struct intel_crtc_state *pipe_config,
>   const struct drm_connector_state *conn_state)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + drm_WARN_ON(_priv->drm, pipe_config->has_audio &&
> + !pipe_config->has_hdmi_sink);
> + intel_audio_codec_enable(encoder, pipe_config, conn_state);
>  }
>  
>  static void intel_disable_hdmi(struct intel_atomic_state *state,
> @@ -415,7 +428,7 @@ static void vlv_hdmi_pre_enable(struct intel_atomic_state 
> *state,
> pipe_config->has_infoframe,
> 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Vivi, Rodrigo]

On Thu, 2022-12-08 at 14:32 +0200, Jani Nikula wrote:
> On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
> > Simplify the code.
> 
> Personally, I absolutely hate fetch_and_zero().
> 
> I understand the point, but there are two main traps:
> 
> First, the name implies atomicity, which there is none at all.
> 
> Second, the name implies it's part of a kernel core header, which it
> isn't, and this just amplifies the first point.
> 
> It's surprising and misleading, and those are not things I like about
> interfaces in the kernel.
> 
> I would not like to see this proliferate. If fetch_and_zero() was
> atomic
> *and* part of a core kernel header, it would be a different matter.
> But
> I don't think that's going to happen, exactly because it won't be
> atomic
> and the name implies it is.

+1 here.

Please let's go the other way around and try to kill macros like this.

we either kill or we ensure this gets accepted in the core kernel
libraries.

> 
> 
> BR,
> Jani.
> 
> 
> > 
> > Signed-off-by: Andrzej Hajda 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 907ab7526cb478..2972d7533da44e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -304,10 +304,8 @@ static void i915_digport_work_func(struct
> > work_struct *work)
> > u32 old_bits = 0;
> >  
> > spin_lock_irq(_priv->irq_lock);
> > -   long_port_mask = dev_priv->display.hotplug.long_port_mask;
> > -   dev_priv->display.hotplug.long_port_mask = 0;
> > -   short_port_mask = dev_priv-
> > >display.hotplug.short_port_mask;
> > -   dev_priv->display.hotplug.short_port_mask = 0;
> > +   long_port_mask = fetch_and_zero(_priv-
> > >display.hotplug.long_port_mask);
> > +   short_port_mask = fetch_and_zero(_priv-
> > >display.hotplug.short_port_mask);
> > spin_unlock_irq(_priv->irq_lock);
> >  
> > for_each_intel_encoder(_priv->drm, encoder) {
> > @@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct
> > work_struct *work)
> >  
> > spin_lock_irq(_priv->irq_lock);
> >  
> > -   hpd_event_bits = dev_priv->display.hotplug.event_bits;
> > -   dev_priv->display.hotplug.event_bits = 0;
> > -   hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
> > -   dev_priv->display.hotplug.retry_bits = 0;
> > +   hpd_event_bits = fetch_and_zero(_priv-
> > >display.hotplug.event_bits);
> > +   hpd_retry_bits = fetch_and_zero(_priv-
> > >display.hotplug.retry_bits);
> >  
> > /* Enable polling for connectors which had HPD IRQ storms
> > */
> > intel_hpd_irq_storm_switch_to_polling(dev_priv);
> 

[Intel-gfx] [PATCH] drm/i915/display: no need for gt/gen8_ppgtt.h

[Jani Nikula]

Remove an unnecessary include.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 32b257157186..6cdfdae2c712 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -70,8 +70,6 @@
 #include "gem/i915_gem_lmem.h"
 #include "gem/i915_gem_object.h"
 
-#include "gt/gen8_ppgtt.h"
-
 #include "g4x_dp.h"
 #include "g4x_hdmi.h"
 #include "hsw_ips.h"
-- 
2.34.1

Re: [Intel-gfx] [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use

[Greg Kroah-Hartman]

On Thu, Dec 08, 2022 at 02:54:45PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote:
> > Some of the existing users, and definitely will be new ones, want to
> > count existing nodes in the list. Provide a generic API for that by
> > moving code from i915 to list.h.
> 
> Greg, I believe this one is ready to be taken. Or please tell me what I need
> to do.

Wait for me to get through the current backlog of patches that I have in
my review queue.  Odds are, it will have to wait until after 6.2-rc1 is
out based on when 6.1 is going to be released.

Don't worry, it's not lost.

thanks,

greg k-h

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915/de: Add more macros to remove all direct calls to uncore

[Jani Nikula]

On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
> On 07.12.2022 18:17, Jani Nikula wrote:
>> From: Maarten Lankhorst 
>> 
>> Add more de helpers to be able to avoid direct calls to uncore.
>> 
>> v3 by Jani:
>> - drop intel_de_write_samevalue/intel_de_rewrite_fw altogether
>> 
>> v2 by Jani:
>> - drop pcode stuff for now
>> - rename intel_de_write_samevalue -> intel_de_rewrite_fw
>> 
>> Signed-off-by: Maarten Lankhorst 
>> Signed-off-by: Jani Nikula 
>> ---
>>   drivers/gpu/drm/i915/display/intel_de.h | 35 +
>>   1 file changed, 35 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_de.h 
>> b/drivers/gpu/drm/i915/display/intel_de.h
>> index 9c104f65e4c8..004f01906fd7 100644
>> --- a/drivers/gpu/drm/i915/display/intel_de.h
>> +++ b/drivers/gpu/drm/i915/display/intel_de.h
>> @@ -16,6 +16,12 @@ intel_de_read(struct drm_i915_private *i915, i915_reg_t 
>> reg)
>>  return intel_uncore_read(>uncore, reg);
>>   }
>>   
>> +static inline u8
>> +intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg)
>> +{
>> +return intel_uncore_read8(>uncore, reg);
>> +}
>> +
>>   static inline void
>>   intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg)
>>   {
>> @@ -41,6 +47,23 @@ intel_de_wait_for_register(struct drm_i915_private *i915, 
>> i915_reg_t reg,
>>  return intel_wait_for_register(>uncore, reg, mask, value, 
>> timeout);
>>   }
>>   
>> +static inline int
>> +intel_de_wait_for_register_fw(struct drm_i915_private *i915, i915_reg_t reg,
>> +  u32 mask, u32 value, unsigned int timeout)
>> +{
>> +return intel_wait_for_register_fw(>uncore, reg, mask, value, 
>> timeout);
>> +}
>> +
>> +static inline int
>> +__intel_de_wait_for_register(struct drm_i915_private *i915, i915_reg_t reg,
>> + u32 mask, u32 value,
>> + unsigned int fast_timeout_us,
>> + unsigned int slow_timeout_ms, u32 *out_value)
>> +{
>> +return __intel_wait_for_register(>uncore, reg, mask, value,
>> + fast_timeout_us, slow_timeout_ms, 
>> out_value);
>> +}
>> +
>>   static inline int
>>   intel_de_wait_for_set(struct drm_i915_private *i915, i915_reg_t reg,
>>u32 mask, unsigned int timeout)
>> @@ -81,4 +104,16 @@ intel_de_write_fw(struct drm_i915_private *i915, 
>> i915_reg_t reg, u32 val)
>>  intel_uncore_write_fw(>uncore, reg, val);
>>   }
>>   
>> +static inline u32
>> +intel_de_read_notrace(struct drm_i915_private *i915, i915_reg_t reg)
>> +{
>> +return intel_uncore_read_notrace(>uncore, reg);
>> +}
>> +
>> +static inline void
>> +intel_de_write_notrace(struct drm_i915_private *i915, i915_reg_t reg, u32 
>> val)
>> +{
>> +intel_uncore_write_notrace(>uncore, reg, val);
>> +}
>> +
>
> I wonder why intel_de_* helpers are only in display subsystem, I guess 
> whole i915 could benefit from it.

I guess the rest of i915 needs to remain aware of gt specific uncores?

> Reviewed-by: Andrzej Hajda 

Thanks, pushed the series to din.

BR,
Jani.

>
> Regards
> Andrzej
>
>
>>   #endif /* __INTEL_DE_H__ */
>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use

[Andy Shevchenko]

On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote:
> Some of the existing users, and definitely will be new ones, want to
> count existing nodes in the list. Provide a generic API for that by
> moving code from i915 to list.h.

Greg, I believe this one is ready to be taken. Or please tell me what I need
to do.

-- 
With Best Regards,
Andy Shevchenko

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Jani Nikula]

On Thu, 08 Dec 2022, Jani Nikula  wrote:
> On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
>> Simplify the code.
>
> Personally, I absolutely hate fetch_and_zero().
>
> I understand the point, but there are two main traps:
>
> First, the name implies atomicity, which there is none at all.
>
> Second, the name implies it's part of a kernel core header, which it
> isn't, and this just amplifies the first point.
>
> It's surprising and misleading, and those are not things I like about
> interfaces in the kernel.
>
> I would not like to see this proliferate. If fetch_and_zero() was atomic
> *and* part of a core kernel header, it would be a different matter. But
> I don't think that's going to happen, exactly because it won't be atomic
> and the name implies it is.

PS. The origin is commit 78ef2d9abad6 ("drm/i915: Add fetch_and_zero()
macro") which presents the idea of making it a pattern that can be
extended for atomic use, but six years and counting, that never
happened.


>
>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
>>  1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
>> b/drivers/gpu/drm/i915/display/intel_hotplug.c
>> index 907ab7526cb478..2972d7533da44e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
>> @@ -304,10 +304,8 @@ static void i915_digport_work_func(struct work_struct 
>> *work)
>>  u32 old_bits = 0;
>>  
>>  spin_lock_irq(_priv->irq_lock);
>> -long_port_mask = dev_priv->display.hotplug.long_port_mask;
>> -dev_priv->display.hotplug.long_port_mask = 0;
>> -short_port_mask = dev_priv->display.hotplug.short_port_mask;
>> -dev_priv->display.hotplug.short_port_mask = 0;
>> +long_port_mask = 
>> fetch_and_zero(_priv->display.hotplug.long_port_mask);
>> +short_port_mask = 
>> fetch_and_zero(_priv->display.hotplug.short_port_mask);
>>  spin_unlock_irq(_priv->irq_lock);
>>  
>>  for_each_intel_encoder(_priv->drm, encoder) {
>> @@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct work_struct 
>> *work)
>>  
>>  spin_lock_irq(_priv->irq_lock);
>>  
>> -hpd_event_bits = dev_priv->display.hotplug.event_bits;
>> -dev_priv->display.hotplug.event_bits = 0;
>> -hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
>> -dev_priv->display.hotplug.retry_bits = 0;
>> +hpd_event_bits = fetch_and_zero(_priv->display.hotplug.event_bits);
>> +hpd_retry_bits = fetch_and_zero(_priv->display.hotplug.retry_bits);
>>  
>>  /* Enable polling for connectors which had HPD IRQ storms */
>>  intel_hpd_irq_storm_switch_to_polling(dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Jani Nikula]

On Thu, 08 Dec 2022, Andrzej Hajda  wrote:
> Simplify the code.

Personally, I absolutely hate fetch_and_zero().

I understand the point, but there are two main traps:

First, the name implies atomicity, which there is none at all.

Second, the name implies it's part of a kernel core header, which it
isn't, and this just amplifies the first point.

It's surprising and misleading, and those are not things I like about
interfaces in the kernel.

I would not like to see this proliferate. If fetch_and_zero() was atomic
*and* part of a core kernel header, it would be a different matter. But
I don't think that's going to happen, exactly because it won't be atomic
and the name implies it is.


BR,
Jani.


>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 907ab7526cb478..2972d7533da44e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -304,10 +304,8 @@ static void i915_digport_work_func(struct work_struct 
> *work)
>   u32 old_bits = 0;
>  
>   spin_lock_irq(_priv->irq_lock);
> - long_port_mask = dev_priv->display.hotplug.long_port_mask;
> - dev_priv->display.hotplug.long_port_mask = 0;
> - short_port_mask = dev_priv->display.hotplug.short_port_mask;
> - dev_priv->display.hotplug.short_port_mask = 0;
> + long_port_mask = 
> fetch_and_zero(_priv->display.hotplug.long_port_mask);
> + short_port_mask = 
> fetch_and_zero(_priv->display.hotplug.short_port_mask);
>   spin_unlock_irq(_priv->irq_lock);
>  
>   for_each_intel_encoder(_priv->drm, encoder) {
> @@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct work_struct 
> *work)
>  
>   spin_lock_irq(_priv->irq_lock);
>  
> - hpd_event_bits = dev_priv->display.hotplug.event_bits;
> - dev_priv->display.hotplug.event_bits = 0;
> - hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
> - dev_priv->display.hotplug.retry_bits = 0;
> + hpd_event_bits = fetch_and_zero(_priv->display.hotplug.event_bits);
> + hpd_retry_bits = fetch_and_zero(_priv->display.hotplug.retry_bits);
>  
>   /* Enable polling for connectors which had HPD IRQ storms */
>   intel_hpd_irq_storm_switch_to_polling(dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: use fetch_and_zero if applicable

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: use fetch_and_zero if 
applicable
URL   : https://patchwork.freedesktop.org/series/111772/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12480 -> Patchwork_111772v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 39)
--

  Additional (1): fi-rkl-11600 
  Missing(1): bat-dg1-6 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

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

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

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

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][6] -> [INCOMPLETE][7] ([i915#6972])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][12] -> [FAIL][13] ([i915#6298])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12480/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([i915#3546])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111772v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [19]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display: use fetch_and_zero if applicable

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: use fetch_and_zero if 
applicable
URL   : https://patchwork.freedesktop.org/series/111772/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'

[Intel-gfx] [PATCH 1/2] drm/i915/display: use fetch_and_zero if applicable

[Andrzej Hajda]

Simplify the code.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 907ab7526cb478..2972d7533da44e 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -304,10 +304,8 @@ static void i915_digport_work_func(struct work_struct 
*work)
u32 old_bits = 0;
 
spin_lock_irq(_priv->irq_lock);
-   long_port_mask = dev_priv->display.hotplug.long_port_mask;
-   dev_priv->display.hotplug.long_port_mask = 0;
-   short_port_mask = dev_priv->display.hotplug.short_port_mask;
-   dev_priv->display.hotplug.short_port_mask = 0;
+   long_port_mask = 
fetch_and_zero(_priv->display.hotplug.long_port_mask);
+   short_port_mask = 
fetch_and_zero(_priv->display.hotplug.short_port_mask);
spin_unlock_irq(_priv->irq_lock);
 
for_each_intel_encoder(_priv->drm, encoder) {
@@ -379,10 +377,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
 
spin_lock_irq(_priv->irq_lock);
 
-   hpd_event_bits = dev_priv->display.hotplug.event_bits;
-   dev_priv->display.hotplug.event_bits = 0;
-   hpd_retry_bits = dev_priv->display.hotplug.retry_bits;
-   dev_priv->display.hotplug.retry_bits = 0;
+   hpd_event_bits = fetch_and_zero(_priv->display.hotplug.event_bits);
+   hpd_retry_bits = fetch_and_zero(_priv->display.hotplug.retry_bits);
 
/* Enable polling for connectors which had HPD IRQ storms */
intel_hpd_irq_storm_switch_to_polling(dev_priv);
-- 
2.34.1

[Intel-gfx] [PATCH 2/2] drm/i915/gt: use fetch_and_zero if applicable

[Andrzej Hajda]

Simplify the code.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/selftest_context.c| 6 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c 
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 76fbae358072df..307dbbe853a3e9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -227,8 +227,7 @@ static int __live_active_context(struct intel_engine_cs 
*engine)
if (IS_ERR(ce))
return PTR_ERR(ce);
 
-   saved_heartbeat = engine->props.heartbeat_interval_ms;
-   engine->props.heartbeat_interval_ms = 0;
+   saved_heartbeat = fetch_and_zero(>props.heartbeat_interval_ms);
 
for (pass = 0; pass <= 2; pass++) {
struct i915_request *rq;
@@ -385,8 +384,7 @@ static int __live_remote_context(struct intel_engine_cs 
*engine)
goto err_remote;
}
 
-   saved_heartbeat = engine->props.heartbeat_interval_ms;
-   engine->props.heartbeat_interval_ms = 0;
+   saved_heartbeat = fetch_and_zero(>props.heartbeat_interval_ms);
intel_engine_pm_get(engine);
 
for (pass = 0; pass <= 2; pass++) {
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 53f7f599cde3a2..f9dd77838917f6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4747,8 +4747,7 @@ static void reset_fail_worker_func(struct work_struct *w)
unsigned long flags;
 
spin_lock_irqsave(>submission_state.lock, flags);
-   reset_fail_mask = guc->submission_state.reset_fail_mask;
-   guc->submission_state.reset_fail_mask = 0;
+   reset_fail_mask = 
fetch_and_zero(>submission_state.reset_fail_mask);
spin_unlock_irqrestore(>submission_state.lock, flags);
 
if (likely(reset_fail_mask))
-- 
2.34.1

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915/tc: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

---
  drivers/gpu/drm/i915/display/intel_tc.c | 55 -
  1 file changed, 18 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 70624b4b2d38..f45328712bff 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -5,6 +5,7 @@
  
  #include "i915_drv.h"

  #include "i915_reg.h"
+#include "intel_de.h"
  #include "intel_display.h"
  #include "intel_display_power_map.h"
  #include "intel_display_types.h"
@@ -120,11 +121,9 @@ assert_tc_cold_blocked(struct intel_digital_port *dig_port)
  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port)
  {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   struct intel_uncore *uncore = >uncore;
u32 lane_mask;
  
-	lane_mask = intel_uncore_read(uncore,

- PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
+   lane_mask = intel_de_read(i915, 
PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
  
  	drm_WARN_ON(>drm, lane_mask == 0x);

assert_tc_cold_blocked(dig_port);
@@ -136,11 +135,9 @@ u32 intel_tc_port_get_lane_mask(struct intel_digital_port 
*dig_port)
  u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port *dig_port)
  {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   struct intel_uncore *uncore = >uncore;
u32 pin_mask;
  
-	pin_mask = intel_uncore_read(uncore,

-PORT_TX_DFLEXPA1(dig_port->tc_phy_fia));
+   pin_mask = intel_de_read(i915, PORT_TX_DFLEXPA1(dig_port->tc_phy_fia));
  
  	drm_WARN_ON(>drm, pin_mask == 0x);

assert_tc_cold_blocked(dig_port);
@@ -186,7 +183,6 @@ void intel_tc_port_set_fia_lane_count(struct 
intel_digital_port *dig_port,
  {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
-   struct intel_uncore *uncore = >uncore;
u32 val;
  
  	drm_WARN_ON(>drm,

@@ -194,8 +190,7 @@ void intel_tc_port_set_fia_lane_count(struct 
intel_digital_port *dig_port,
  
  	assert_tc_cold_blocked(dig_port);
  
-	val = intel_uncore_read(uncore,

-   PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia));
+   val = intel_de_read(i915, PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia));
val &= ~DFLEXDPMLE1_DPMLETC_MASK(dig_port->tc_phy_fia_idx);
  
  	switch (required_lanes) {

@@ -216,8 +211,7 @@ void intel_tc_port_set_fia_lane_count(struct 
intel_digital_port *dig_port,
MISSING_CASE(required_lanes);
}
  
-	intel_uncore_write(uncore,

-  PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia), val);
+   intel_de_write(i915, PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia), val);
  }
  
  static void tc_port_fixup_legacy_flag(struct intel_digital_port *dig_port,

@@ -246,13 +240,11 @@ static void tc_port_fixup_legacy_flag(struct 
intel_digital_port *dig_port,
  static u32 icl_tc_port_live_status_mask(struct intel_digital_port *dig_port)
  {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   struct intel_uncore *uncore = >uncore;
u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
u32 mask = 0;
u32 val;
  
-	val = intel_uncore_read(uncore,

-   PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
+   val = intel_de_read(i915, PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
  
  	if (val == 0x) {

drm_dbg_kms(>drm,
@@ -266,7 +258,7 @@ static u32 icl_tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
if (val & TC_LIVE_STATE_TC(dig_port->tc_phy_fia_idx))
mask |= BIT(TC_PORT_DP_ALT);
  
-	if (intel_uncore_read(uncore, SDEISR) & isr_bit)

+   if (intel_de_read(i915, SDEISR) & isr_bit)
mask |= BIT(TC_PORT_LEGACY);
  
  	/* The sink can be connected only in a single mode. */

@@ -281,7 +273,6 @@ static u32 adl_tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
-   struct intel_uncore *uncore = >uncore;
u32 val, mask = 0;
  
  	/*

@@ -289,13 +280,13 @@ static u32 adl_tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
 * registers in IOM. Note that this doesn't apply to PHY and FIA
 * registers.
 */
-   val = intel_uncore_read(uncore, TCSS_DDI_STATUS(tc_port));
+   val = intel_de_read(i915, TCSS_DDI_STATUS(tc_port));
if (val & 

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915/snps: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_snps_phy.c | 15 +++
  1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
b/drivers/gpu/drm/i915/display/intel_snps_phy.c
index c799e891f8b5..9494cfd45519 100644
--- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
@@ -44,18 +44,18 @@ void intel_snps_phy_wait_for_calibration(struct 
drm_i915_private *i915)
}
  }
  
-void intel_snps_phy_update_psr_power_state(struct drm_i915_private *dev_priv,

+void intel_snps_phy_update_psr_power_state(struct drm_i915_private *i915,
   enum phy phy, bool enable)
  {
u32 val;
  
-	if (!intel_phy_is_snps(dev_priv, phy))

+   if (!intel_phy_is_snps(i915, phy))
return;
  
  	val = REG_FIELD_PREP(SNPS_PHY_TX_REQ_LN_DIS_PWR_STATE_PSR,

 enable ? 2 : 3);
-   intel_uncore_rmw(_priv->uncore, SNPS_PHY_TX_REQ(phy),
-SNPS_PHY_TX_REQ_LN_DIS_PWR_STATE_PSR, val);
+   intel_de_rmw(i915, SNPS_PHY_TX_REQ(phy),
+SNPS_PHY_TX_REQ_LN_DIS_PWR_STATE_PSR, val);
  }
  
  void intel_snps_phy_set_signal_levels(struct intel_encoder *encoder,

@@ -1785,7 +1785,7 @@ void intel_mpllb_enable(struct intel_encoder *encoder,
 */
  
  	/* 5. Software sets DPLL_ENABLE [PLL Enable] to "1". */

-   intel_uncore_rmw(_priv->uncore, enable_reg, 0, PLL_ENABLE);
+   intel_de_rmw(dev_priv, enable_reg, 0, PLL_ENABLE);
  
  	/*

 * 9. Software sets SNPS_PHY_MPLLB_DIV dp_mpllb_force_en to "1". This
@@ -1830,14 +1830,13 @@ void intel_mpllb_disable(struct intel_encoder *encoder)
 */
  
  	/* 2. Software programs DPLL_ENABLE [PLL Enable] to "0" */

-   intel_uncore_rmw(>uncore, enable_reg, PLL_ENABLE, 0);
+   intel_de_rmw(i915, enable_reg, PLL_ENABLE, 0);
  
  	/*

 * 4. Software programs SNPS_PHY_MPLLB_DIV dp_mpllb_force_en to "0".
 * This will allow the PLL to stop running.
 */
-   intel_uncore_rmw(>uncore, SNPS_PHY_MPLLB_DIV(phy),
-SNPS_PHY_MPLLB_FORCE_EN, 0);
+   intel_de_rmw(i915, SNPS_PHY_MPLLB_DIV(phy), SNPS_PHY_MPLLB_FORCE_EN, 0);
  
  	/*

 * 5. Software polls DPLL_ENABLE [PLL Lock] for PHY acknowledgment

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/wm: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/skl_watermark.c | 42 +---
  1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
b/drivers/gpu/drm/i915/display/skl_watermark.c
index e0766d1be966..ae4e9e680c2e 100644
--- a/drivers/gpu/drm/i915/display/skl_watermark.c
+++ b/drivers/gpu/drm/i915/display/skl_watermark.c
@@ -45,8 +45,7 @@ u8 intel_enabled_dbuf_slices_mask(struct drm_i915_private 
*i915)
enum dbuf_slice slice;
  
  	for_each_dbuf_slice(i915, slice) {

-   if (intel_uncore_read(>uncore,
- DBUF_CTL_S(slice)) & DBUF_POWER_STATE)
+   if (intel_de_read(i915, DBUF_CTL_S(slice)) & DBUF_POWER_STATE)
enabled_slices |= BIT(slice);
}
  
@@ -75,7 +74,7 @@ intel_sagv_block_time(struct drm_i915_private *i915)

if (DISPLAY_VER(i915) >= 14) {
u32 val;
  
-		val = intel_uncore_read(>uncore, MTL_LATENCY_SAGV);

+   val = intel_de_read(i915, MTL_LATENCY_SAGV);
  
  		return REG_FIELD_GET(MTL_LATENCY_QCLK_SAGV, val);

} else if (DISPLAY_VER(i915) >= 12) {
@@ -756,18 +755,18 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private *i915,
  
  	/* Cursor doesn't support NV12/planar, so no extra calculation needed */

if (plane_id == PLANE_CURSOR) {
-   val = intel_uncore_read(>uncore, CUR_BUF_CFG(pipe));
+   val = intel_de_read(i915, CUR_BUF_CFG(pipe));
skl_ddb_entry_init_from_hw(ddb, val);
return;
}
  
-	val = intel_uncore_read(>uncore, PLANE_BUF_CFG(pipe, plane_id));

+   val = intel_de_read(i915, PLANE_BUF_CFG(pipe, plane_id));
skl_ddb_entry_init_from_hw(ddb, val);
  
  	if (DISPLAY_VER(i915) >= 11)

return;
  
-	val = intel_uncore_read(>uncore, PLANE_NV12_BUF_CFG(pipe, plane_id));

+   val = intel_de_read(i915, PLANE_NV12_BUF_CFG(pipe, plane_id));
skl_ddb_entry_init_from_hw(ddb_y, val);
  }
  
@@ -2821,36 +2820,32 @@ static void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
  
  		for (level = 0; level <= max_level; level++) {

if (plane_id != PLANE_CURSOR)
-   val = intel_uncore_read(>uncore, 
PLANE_WM(pipe, plane_id, level));
+   val = intel_de_read(i915, PLANE_WM(pipe, 
plane_id, level));
else
-   val = intel_uncore_read(>uncore, 
CUR_WM(pipe, level));
+   val = intel_de_read(i915, CUR_WM(pipe, level));
  
  			skl_wm_level_from_reg_val(val, >wm[level]);

}
  
  		if (plane_id != PLANE_CURSOR)

-   val = intel_uncore_read(>uncore, 
PLANE_WM_TRANS(pipe, plane_id));
+   val = intel_de_read(i915, PLANE_WM_TRANS(pipe, 
plane_id));
else
-   val = intel_uncore_read(>uncore, 
CUR_WM_TRANS(pipe));
+   val = intel_de_read(i915, CUR_WM_TRANS(pipe));
  
  		skl_wm_level_from_reg_val(val, >trans_wm);
  
  		if (HAS_HW_SAGV_WM(i915)) {

if (plane_id != PLANE_CURSOR)
-   val = intel_uncore_read(>uncore,
-   PLANE_WM_SAGV(pipe, 
plane_id));
+   val = intel_de_read(i915, PLANE_WM_SAGV(pipe, 
plane_id));
else
-   val = intel_uncore_read(>uncore,
-   CUR_WM_SAGV(pipe));
+   val = intel_de_read(i915, CUR_WM_SAGV(pipe));
  
  			skl_wm_level_from_reg_val(val, >sagv.wm0);
  
  			if (plane_id != PLANE_CURSOR)

-   val = intel_uncore_read(>uncore,
-   
PLANE_WM_SAGV_TRANS(pipe, plane_id));
+   val = intel_de_read(i915, 
PLANE_WM_SAGV_TRANS(pipe, plane_id));
else
-   val = intel_uncore_read(>uncore,
-   
CUR_WM_SAGV_TRANS(pipe));
+   val = intel_de_read(i915, 
CUR_WM_SAGV_TRANS(pipe));
  
  			skl_wm_level_from_reg_val(val, >sagv.trans_wm);

} else if (DISPLAY_VER(i915) >= 12) {
@@ -3126,8 +3121,8 @@ void skl_watermark_ipc_update(struct drm_i915_private 
*i915)
if (!HAS_IPC(i915))
return;
  
-	intel_uncore_rmw(>uncore, DISP_ARB_CTL2, DISP_IPC_ENABLE,

-skl_watermark_ipc_enabled(i915) ? DISP_IPC_ENABLE : 0);
+   intel_de_rmw(i915, DISP_ARB_CTL2, DISP_IPC_ENABLE,
+skl_watermark_ipc_enabled(i915) 

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915/gmbus: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_gmbus.c | 46 --
  1 file changed, 17 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index a5840a28a69d..0bc4f6b48e80 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -255,14 +255,12 @@ static void bxt_gmbus_clock_gating(struct 
drm_i915_private *i915,
  static u32 get_reserved(struct intel_gmbus *bus)
  {
struct drm_i915_private *i915 = bus->i915;
-   struct intel_uncore *uncore = >uncore;
u32 reserved = 0;
  
  	/* On most chips, these bits must be preserved in software. */

if (!IS_I830(i915) && !IS_I845G(i915))
-   reserved = intel_uncore_read_notrace(uncore, bus->gpio_reg) &
-  (GPIO_DATA_PULLUP_DISABLE |
-   GPIO_CLOCK_PULLUP_DISABLE);
+   reserved = intel_de_read_notrace(i915, bus->gpio_reg) &
+   (GPIO_DATA_PULLUP_DISABLE | GPIO_CLOCK_PULLUP_DISABLE);
  
  	return reserved;

  }
@@ -270,37 +268,31 @@ static u32 get_reserved(struct intel_gmbus *bus)
  static int get_clock(void *data)
  {
struct intel_gmbus *bus = data;
-   struct intel_uncore *uncore = >i915->uncore;
+   struct drm_i915_private *i915 = bus->i915;
u32 reserved = get_reserved(bus);
  
-	intel_uncore_write_notrace(uncore,

-  bus->gpio_reg,
-  reserved | GPIO_CLOCK_DIR_MASK);
-   intel_uncore_write_notrace(uncore, bus->gpio_reg, reserved);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved | 
GPIO_CLOCK_DIR_MASK);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved);
  
-	return (intel_uncore_read_notrace(uncore, bus->gpio_reg) &

-   GPIO_CLOCK_VAL_IN) != 0;
+   return (intel_de_read_notrace(i915, bus->gpio_reg) & GPIO_CLOCK_VAL_IN) 
!= 0;
  }
  
  static int get_data(void *data)

  {
struct intel_gmbus *bus = data;
-   struct intel_uncore *uncore = >i915->uncore;
+   struct drm_i915_private *i915 = bus->i915;
u32 reserved = get_reserved(bus);
  
-	intel_uncore_write_notrace(uncore,

-  bus->gpio_reg,
-  reserved | GPIO_DATA_DIR_MASK);
-   intel_uncore_write_notrace(uncore, bus->gpio_reg, reserved);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved | 
GPIO_DATA_DIR_MASK);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved);
  
-	return (intel_uncore_read_notrace(uncore, bus->gpio_reg) &

-   GPIO_DATA_VAL_IN) != 0;
+   return (intel_de_read_notrace(i915, bus->gpio_reg) & GPIO_DATA_VAL_IN) 
!= 0;
  }
  
  static void set_clock(void *data, int state_high)

  {
struct intel_gmbus *bus = data;
-   struct intel_uncore *uncore = >i915->uncore;
+   struct drm_i915_private *i915 = bus->i915;
u32 reserved = get_reserved(bus);
u32 clock_bits;
  
@@ -310,16 +302,14 @@ static void set_clock(void *data, int state_high)

clock_bits = GPIO_CLOCK_DIR_OUT | GPIO_CLOCK_DIR_MASK |
 GPIO_CLOCK_VAL_MASK;
  
-	intel_uncore_write_notrace(uncore,

-  bus->gpio_reg,
-  reserved | clock_bits);
-   intel_uncore_posting_read(uncore, bus->gpio_reg);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved | clock_bits);
+   intel_de_posting_read(i915, bus->gpio_reg);
  }
  
  static void set_data(void *data, int state_high)

  {
struct intel_gmbus *bus = data;
-   struct intel_uncore *uncore = >i915->uncore;
+   struct drm_i915_private *i915 = bus->i915;
u32 reserved = get_reserved(bus);
u32 data_bits;
  
@@ -329,8 +319,8 @@ static void set_data(void *data, int state_high)

data_bits = GPIO_DATA_DIR_OUT | GPIO_DATA_DIR_MASK |
GPIO_DATA_VAL_MASK;
  
-	intel_uncore_write_notrace(uncore, bus->gpio_reg, reserved | data_bits);

-   intel_uncore_posting_read(uncore, bus->gpio_reg);
+   intel_de_write_notrace(i915, bus->gpio_reg, reserved | data_bits);
+   intel_de_posting_read(i915, bus->gpio_reg);
  }
  
  static int

@@ -439,9 +429,7 @@ gmbus_wait_idle(struct drm_i915_private *i915)
add_wait_queue(>display.gmbus.wait_queue, );
intel_de_write_fw(i915, GMBUS4(i915), irq_enable);
  
-	ret = intel_wait_for_register_fw(>uncore,

-GMBUS2(i915), GMBUS_ACTIVE, 0,
-10);
+   ret = intel_de_wait_for_register_fw(i915, GMBUS2(i915), GMBUS_ACTIVE, 
0, 10);
  
  	intel_de_write_fw(i915, GMBUS4(i915), 

Re: [Intel-gfx] [PATCH v2 07/11] drm/i915/dp-aux: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_dp_aux.c | 29 +
  1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 664bebdecea7..91c93c93e5fc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -6,6 +6,7 @@
  #include "i915_drv.h"
  #include "i915_reg.h"
  #include "i915_trace.h"
+#include "intel_de.h"
  #include "intel_display_types.h"
  #include "intel_dp_aux.h"
  #include "intel_pps.h"
@@ -42,7 +43,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
u32 status;
bool done;
  
-#define C (((status = intel_uncore_read_notrace(>uncore, ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)

+#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
  msecs_to_jiffies_timeout(timeout_ms));
  
@@ -191,7 +192,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,

struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *i915 =
to_i915(dig_port->base.base.dev);
-   struct intel_uncore *uncore = >uncore;
enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
bool is_tc_port = intel_phy_is_tc(i915, phy);
i915_reg_t ch_ctl, ch_data[5];
@@ -235,7 +235,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
  
  	/* Try to wait for any previous AUX channel activity */

for (try = 0; try < 3; try++) {
-   status = intel_uncore_read_notrace(uncore, ch_ctl);
+   status = intel_de_read_notrace(i915, ch_ctl);
if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
break;
msleep(1);
@@ -244,7 +244,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
  
  	if (try == 3) {

-   const u32 status = intel_uncore_read(uncore, ch_ctl);
+   const u32 status = intel_de_read(i915, ch_ctl);
  
  		if (status != intel_dp->aux_busy_last_status) {

drm_WARN(>drm, 1,
@@ -274,23 +274,20 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
for (try = 0; try < 5; try++) {
/* Load the send data into the aux channel data 
registers */
for (i = 0; i < send_bytes; i += 4)
-   intel_uncore_write(uncore,
-  ch_data[i >> 2],
-  intel_dp_aux_pack(send + i,
-send_bytes 
- i));
+   intel_de_write(i915, ch_data[i >> 2],
+  intel_dp_aux_pack(send + i,
+send_bytes - 
i));
  
  			/* Send the command and wait for it to complete */

-   intel_uncore_write(uncore, ch_ctl, send_ctl);
+   intel_de_write(i915, ch_ctl, send_ctl);
  
  			status = intel_dp_aux_wait_done(intel_dp);
  
  			/* Clear done status and any errors */

-   intel_uncore_write(uncore,
-  ch_ctl,
-  status |
-  DP_AUX_CH_CTL_DONE |
-  DP_AUX_CH_CTL_TIME_OUT_ERROR |
-  DP_AUX_CH_CTL_RECEIVE_ERROR);
+   intel_de_write(i915, ch_ctl,
+  status | DP_AUX_CH_CTL_DONE |
+  DP_AUX_CH_CTL_TIME_OUT_ERROR |
+  DP_AUX_CH_CTL_RECEIVE_ERROR);
  
  			/*

 * DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
@@ -361,7 +358,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
recv_bytes = recv_size;
  
  	for (i = 0; i < recv_bytes; i += 4)

-   intel_dp_aux_unpack(intel_uncore_read(uncore, ch_data[i >> 2]),
+   intel_dp_aux_unpack(intel_de_read(i915, ch_data[i >> 2]),
recv + i, recv_bytes - i);
  
  	ret = recv_bytes;

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/dmc: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

---
  drivers/gpu/drm/i915/display/intel_dmc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index eff3add70611..f107b8cd3c9e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -433,9 +433,9 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
  
  	for (id = 0; id < DMC_FW_MAX; id++) {

for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
-   intel_uncore_write_fw(_priv->uncore,
- 
DMC_PROGRAM(dmc->dmc_info[id].start_mmioaddr, i),
- dmc->dmc_info[id].payload[i]);
+   intel_de_write_fw(dev_priv,
+ 
DMC_PROGRAM(dmc->dmc_info[id].start_mmioaddr, i),
+ dmc->dmc_info[id].payload[i]);
}
}
  

Re: [Intel-gfx] [PATCH v2 05/11] drm/i915/power: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 3adba64937de..1a23ecd4623a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1673,7 +1673,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12) {
val = DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM |
  DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR;
-   intel_uncore_rmw(_priv->uncore, GEN11_CHICKEN_DCPR_2, 0, 
val);
+   intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0, val);
}
  
  	/* Wa_14011503030:xelpd */

Re: [Intel-gfx] [PATCH v2 04/11] drm/i915/crt: switch to intel_de_* register accessors in display code

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Just curious if compiler is able to keep the code size with such changes.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_crt.c | 42 +++-
  1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index ed94ba5c0302..7267ffc7f539 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -682,7 +682,6 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
  {
struct drm_device *dev = crt->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_uncore *uncore = _priv->uncore;
u32 save_bclrpat;
u32 save_vtotal;
u32 vtotal, vactive;
@@ -694,9 +693,9 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
  
  	drm_dbg_kms(_priv->drm, "starting load-detect on CRT\n");
  
-	save_bclrpat = intel_uncore_read(uncore, BCLRPAT(pipe));

-   save_vtotal = intel_uncore_read(uncore, VTOTAL(pipe));
-   vblank = intel_uncore_read(uncore, VBLANK(pipe));
+   save_bclrpat = intel_de_read(dev_priv, BCLRPAT(pipe));
+   save_vtotal = intel_de_read(dev_priv, VTOTAL(pipe));
+   vblank = intel_de_read(dev_priv, VBLANK(pipe));
  
  	vtotal = ((save_vtotal >> 16) & 0xfff) + 1;

vactive = (save_vtotal & 0x7ff) + 1;
@@ -705,23 +704,23 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
vblank_end = ((vblank >> 16) & 0xfff) + 1;
  
  	/* Set the border color to purple. */

-   intel_uncore_write(uncore, BCLRPAT(pipe), 0x500050);
+   intel_de_write(dev_priv, BCLRPAT(pipe), 0x500050);
  
  	if (DISPLAY_VER(dev_priv) != 2) {

-   u32 pipeconf = intel_uncore_read(uncore, PIPECONF(pipe));
-   intel_uncore_write(uncore,
-  PIPECONF(pipe),
-  pipeconf | PIPECONF_FORCE_BORDER);
-   intel_uncore_posting_read(uncore, PIPECONF(pipe));
+   u32 pipeconf = intel_de_read(dev_priv, PIPECONF(pipe));
+
+   intel_de_write(dev_priv, PIPECONF(pipe),
+  pipeconf | PIPECONF_FORCE_BORDER);
+   intel_de_posting_read(dev_priv, PIPECONF(pipe));
/* Wait for next Vblank to substitue
 * border color for Color info */
intel_crtc_wait_for_next_vblank(intel_crtc_for_pipe(dev_priv, 
pipe));
-   st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
+   st00 = intel_de_read8(dev_priv, _VGA_MSR_WRITE);
status = ((st00 & (1 << 4)) != 0) ?
connector_status_connected :
connector_status_disconnected;
  
-		intel_uncore_write(uncore, PIPECONF(pipe), pipeconf);

+   intel_de_write(dev_priv, PIPECONF(pipe), pipeconf);
} else {
bool restore_vblank = false;
int count, detect;
@@ -735,10 +734,8 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
u32 vsync_start = (vsync & 0x) + 1;
  
  			vblank_start = vsync_start;

-   intel_uncore_write(uncore,
-  VBLANK(pipe),
-  (vblank_start - 1) |
-  ((vblank_end - 1) << 16));
+   intel_de_write(dev_priv, VBLANK(pipe),
+  (vblank_start - 1) | ((vblank_end - 1) 
<< 16));
restore_vblank = true;
}
/* sample in the vertical border, selecting the larger one */
@@ -750,10 +747,9 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
/*
 * Wait for the border to be displayed
 */
-   while (intel_uncore_read(uncore, PIPEDSL(pipe)) >= vactive)
+   while (intel_de_read(dev_priv, PIPEDSL(pipe)) >= vactive)
;
-   while ((dsl = intel_uncore_read(uncore, PIPEDSL(pipe))) <=
-  vsample)
+   while ((dsl = intel_de_read(dev_priv, PIPEDSL(pipe))) <= 
vsample)
;
/*
 * Watch ST00 for an entire scanline
@@ -763,14 +759,14 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
do {
count++;
/* Read the ST00 VGA status register */
-   st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
+   st00 = intel_de_read8(dev_priv, _VGA_MSR_WRITE);
if (st00 & (1 << 4))
detect++;
-   } while ((intel_uncore_read(uncore, PIPEDSL(pipe)) == 

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915/crt: drop a bunch of unnecessary register variables

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

There's no need to save the register offsets. Drop the variables.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_crt.c | 39 +---
  1 file changed, 15 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 797ad9489f7e..ed94ba5c0302 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -689,23 +689,14 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
u32 vsample;
u32 vblank, vblank_start, vblank_end;
u32 dsl;
-   i915_reg_t bclrpat_reg, vtotal_reg,
-   vblank_reg, vsync_reg, pipeconf_reg, pipe_dsl_reg;
u8 st00;
enum drm_connector_status status;
  
  	drm_dbg_kms(_priv->drm, "starting load-detect on CRT\n");
  
-	bclrpat_reg = BCLRPAT(pipe);

-   vtotal_reg = VTOTAL(pipe);
-   vblank_reg = VBLANK(pipe);
-   vsync_reg = VSYNC(pipe);
-   pipeconf_reg = PIPECONF(pipe);
-   pipe_dsl_reg = PIPEDSL(pipe);
-
-   save_bclrpat = intel_uncore_read(uncore, bclrpat_reg);
-   save_vtotal = intel_uncore_read(uncore, vtotal_reg);
-   vblank = intel_uncore_read(uncore, vblank_reg);
+   save_bclrpat = intel_uncore_read(uncore, BCLRPAT(pipe));
+   save_vtotal = intel_uncore_read(uncore, VTOTAL(pipe));
+   vblank = intel_uncore_read(uncore, VBLANK(pipe));
  
  	vtotal = ((save_vtotal >> 16) & 0xfff) + 1;

vactive = (save_vtotal & 0x7ff) + 1;
@@ -714,14 +705,14 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
vblank_end = ((vblank >> 16) & 0xfff) + 1;
  
  	/* Set the border color to purple. */

-   intel_uncore_write(uncore, bclrpat_reg, 0x500050);
+   intel_uncore_write(uncore, BCLRPAT(pipe), 0x500050);
  
  	if (DISPLAY_VER(dev_priv) != 2) {

-   u32 pipeconf = intel_uncore_read(uncore, pipeconf_reg);
+   u32 pipeconf = intel_uncore_read(uncore, PIPECONF(pipe));
intel_uncore_write(uncore,
-  pipeconf_reg,
+  PIPECONF(pipe),
   pipeconf | PIPECONF_FORCE_BORDER);
-   intel_uncore_posting_read(uncore, pipeconf_reg);
+   intel_uncore_posting_read(uncore, PIPECONF(pipe));
/* Wait for next Vblank to substitue
 * border color for Color info */
intel_crtc_wait_for_next_vblank(intel_crtc_for_pipe(dev_priv, 
pipe));
@@ -730,7 +721,7 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
connector_status_connected :
connector_status_disconnected;
  
-		intel_uncore_write(uncore, pipeconf_reg, pipeconf);

+   intel_uncore_write(uncore, PIPECONF(pipe), pipeconf);
} else {
bool restore_vblank = false;
int count, detect;
@@ -740,12 +731,12 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
* Yes, this will flicker
*/
if (vblank_start <= vactive && vblank_end >= vtotal) {
-   u32 vsync = intel_de_read(dev_priv, vsync_reg);
+   u32 vsync = intel_de_read(dev_priv, VSYNC(pipe));
u32 vsync_start = (vsync & 0x) + 1;
  
  			vblank_start = vsync_start;

intel_uncore_write(uncore,
-  vblank_reg,
+  VBLANK(pipe),
   (vblank_start - 1) |
   ((vblank_end - 1) << 16));
restore_vblank = true;
@@ -759,9 +750,9 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
/*
 * Wait for the border to be displayed
 */
-   while (intel_uncore_read(uncore, pipe_dsl_reg) >= vactive)
+   while (intel_uncore_read(uncore, PIPEDSL(pipe)) >= vactive)
;
-   while ((dsl = intel_uncore_read(uncore, pipe_dsl_reg)) <=
+   while ((dsl = intel_uncore_read(uncore, PIPEDSL(pipe))) <=
   vsample)
;
/*
@@ -775,11 +766,11 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
if (st00 & (1 << 4))
detect++;
-   } while ((intel_uncore_read(uncore, pipe_dsl_reg) == dsl));
+   } while ((intel_uncore_read(uncore, PIPEDSL(pipe)) == dsl));
  
  		/* restore vblank if necessary */

if (restore_vblank)
-   intel_uncore_write(uncore, vblank_reg, vblank);
+

Re: [Intel-gfx] [PATCH v2 02/11] drm/i915/de: return the old register value from intel_de_rmw()

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

A similar thing was added in intel_uncore_rmw(). Make it available for
display too.

Cc: Maarten Lankhorst 
Signed-off-by: Jani Nikula 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_de.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_de.h 
b/drivers/gpu/drm/i915/display/intel_de.h
index 004f01906fd7..3dbd76fdabd6 100644
--- a/drivers/gpu/drm/i915/display/intel_de.h
+++ b/drivers/gpu/drm/i915/display/intel_de.h
@@ -34,10 +34,10 @@ intel_de_write(struct drm_i915_private *i915, i915_reg_t 
reg, u32 val)
intel_uncore_write(>uncore, reg, val);
  }
  
-static inline void

+static inline u32
  intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg, u32 clear, u32 
set)
  {
-   intel_uncore_rmw(>uncore, reg, clear, set);
+   return intel_uncore_rmw(>uncore, reg, clear, set);
  }
  
  static inline int

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915/de: Add more macros to remove all direct calls to uncore

[Andrzej Hajda]

On 07.12.2022 18:17, Jani Nikula wrote:

From: Maarten Lankhorst 

Add more de helpers to be able to avoid direct calls to uncore.

v3 by Jani:
- drop intel_de_write_samevalue/intel_de_rewrite_fw altogether

v2 by Jani:
- drop pcode stuff for now
- rename intel_de_write_samevalue -> intel_de_rewrite_fw

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/display/intel_de.h | 35 +
  1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_de.h 
b/drivers/gpu/drm/i915/display/intel_de.h
index 9c104f65e4c8..004f01906fd7 100644
--- a/drivers/gpu/drm/i915/display/intel_de.h
+++ b/drivers/gpu/drm/i915/display/intel_de.h
@@ -16,6 +16,12 @@ intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)
return intel_uncore_read(>uncore, reg);
  }
  
+static inline u8

+intel_de_read8(struct drm_i915_private *i915, i915_reg_t reg)
+{
+   return intel_uncore_read8(>uncore, reg);
+}
+
  static inline void
  intel_de_posting_read(struct drm_i915_private *i915, i915_reg_t reg)
  {
@@ -41,6 +47,23 @@ intel_de_wait_for_register(struct drm_i915_private *i915, 
i915_reg_t reg,
return intel_wait_for_register(>uncore, reg, mask, value, 
timeout);
  }
  
+static inline int

+intel_de_wait_for_register_fw(struct drm_i915_private *i915, i915_reg_t reg,
+ u32 mask, u32 value, unsigned int timeout)
+{
+   return intel_wait_for_register_fw(>uncore, reg, mask, value, 
timeout);
+}
+
+static inline int
+__intel_de_wait_for_register(struct drm_i915_private *i915, i915_reg_t reg,
+u32 mask, u32 value,
+unsigned int fast_timeout_us,
+unsigned int slow_timeout_ms, u32 *out_value)
+{
+   return __intel_wait_for_register(>uncore, reg, mask, value,
+fast_timeout_us, slow_timeout_ms, 
out_value);
+}
+
  static inline int
  intel_de_wait_for_set(struct drm_i915_private *i915, i915_reg_t reg,
  u32 mask, unsigned int timeout)
@@ -81,4 +104,16 @@ intel_de_write_fw(struct drm_i915_private *i915, i915_reg_t 
reg, u32 val)
intel_uncore_write_fw(>uncore, reg, val);
  }
  
+static inline u32

+intel_de_read_notrace(struct drm_i915_private *i915, i915_reg_t reg)
+{
+   return intel_uncore_read_notrace(>uncore, reg);
+}
+
+static inline void
+intel_de_write_notrace(struct drm_i915_private *i915, i915_reg_t reg, u32 val)
+{
+   intel_uncore_write_notrace(>uncore, reg, val);
+}
+


I wonder why intel_de_* helpers are only in display subsystem, I guess 
whole i915 could benefit from it.


Reviewed-by: Andrzej Hajda 

Regards
Andrzej



  #endif /* __INTEL_DE_H__ */

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v6,1/3] drm/i915/migrate: Account for the reserved_space

[Matthew Auld]

On 02/12/2022 14:06, Patchwork wrote:

*Patch Details*
*Series:*	series starting with [v6,1/3] drm/i915/migrate: Account for 
the reserved_space
*URL:*	https://patchwork.freedesktop.org/series/111583/ 


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




  CI Bug Log - changes from CI_DRM_12462 -> Patchwork_111583v1


Summary

*FAILURE*

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

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



Participating hosts (42 -> 42)

Additional (3): fi-hsw-4770 bat-dg1-7 bat-adlp-9
Missing (3): fi-ilk-m540 fi-rkl-11600 bat-atsm-1


Possible new issues

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



  IGT changes


Possible regressions

  * igt@i915_selftest@live@guc_multi_lrc:
  o fi-kbl-soraka: PASS


 -> INCOMPLETE 




Unrelated it seems.



Suppressed

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

  * igt@i915_selftest@live@requests:
  o {bat-dg2-11}: PASS


 -> INCOMPLETE 



Known issues

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



  IGT changes


Issues hit

  *

igt@core_hotunplug@unbind-rebind:

  o fi-apl-guc: PASS


 -> INCOMPLETE 

 (i915#7073 )
  *

igt@gem_softpin@allocator-basic-reserve:

  o fi-hsw-4770: NOTRUN -> SKIP


 (fdo#109271 ) +11 similar issues
  *

igt@i915_selftest@live@hangcheck:

  o

fi-hsw-4770: NOTRUN -> INCOMPLETE


 (i915#4785 )

  o

fi-ivb-3770: PASS


 -> INCOMPLETE 

 (i915#3303  / i915#7122 
)

  *

igt@kms_chamelium@dp-crc-fast:

  o fi-hsw-4770: NOTRUN -> SKIP


 (fdo#109271  / fdo#111827 
) +7 similar issues
  *

igt@kms_psr@sprite_plane_onoff:

  o fi-hsw-4770: NOTRUN -> SKIP


 (fdo#109271  / i915#1072 
) +3 similar issues
  *

igt@runner@aborted:

  o

fi-hsw-4770: NOTRUN -> FAIL

 
(fdo#109271  / i915#4312 
 / i915#5594 
)

  o

fi-ivb-3770: NOTRUN -> FAIL


 (fdo#109271  / i915#4312 
)


Possible fixes

  *

igt@gem_exec_suspend@basic-s3@smem:

  o 

Re: [Intel-gfx] [PATCH v11 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Tvrtko Ursulin]

Just some small comments and questions below.

On 08/12/2022 05:01, Alan Previn wrote:

Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readibility and maintainibility to many external-to-pxp subsystems


readability and maintainability


which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
(such as intel_pxp_enabled/active) will have to check implicitly
if i915->pxp is valid as that structure will not be allocated
for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
ensuring that GT init happens before PXP init and vice versa
for fini. This causes a minor ordering change whereby we previously
called intel_pxp_suspend after intel_uc_suspend but now is before
i915_gem_suspend_late but the change is required for correct
dependency flows. Additionally, this re-order change doesn't
have any impact because at that point in either case, the top level
entry to i915 won't observe any PXP events (since the GPU was
quiesced during suspend_prepare). Also, any PXP event doesn't
really matter when we disable the PXP HW (global GT irqs are
already off anyway, so even if there was a bug that generated
spurious events we wouldn't see it and we would just clean it
up on resume which is okay since the default fallback action
for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
   v10: - Change the code flow for intel_pxp_init to make it more
  cleaner and readible with better comments explaining the
  difference between full-PXP-feature vs the partial-teelink
  inits depending on the platform. Additionally, only do
  the pxp allocation when we are certain the subsystem is
  needed. (Tvrtko).
v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
- Add comments for intel_pxp_init and pxp_get_ctrl_gt that
  explain the functional flow for when PXP is not supported
  but the backend-assets are needed for HuC authentication
  (Daniele and Tvrtko).
- Fix two remaining functions that are accessible outside
  PXP that need to be checking pxp ptrs before using them:
  intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
  (Tvrtko and Daniele).
- User helper macro in pxp-debugfs (Tvrtko).
v8: - Remove pxp_to_gt macro (Daniele).
- Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
  support GSC-FW on it. (Daniele).
- Leave i915->pxp as NULL if we dont support PXP and in line
  with that, do additional validity check on i915->pxp for
  intel_pxp_is_supported/enabled/active (Daniele).
- Remove unncessary include header from intel_gt_debugfs.c
  and check drm_minor i915->drm.primary (Daniele).
- Other cosmetics / minor issues / more comments on suspend
  flow order change (Daniele).
v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
  through out instead of local variable newpxp. (Rodrigo)
- In the case intel_pxp_fini is called during driver unload but
  after i915 loading failed without pxp being allocated, check
  i915->pxp before referencing it. (Alan)
v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
  because : [1] introduction of 'ctrl_gt' 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Initial display workarounds (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Initial display workarounds (rev2)
URL   : https://patchwork.freedesktop.org/series/111592/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12478_full -> Patchwork_111592v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (14 -> 14)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@drm_read@short-buffer-wakeup:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-dg1-18/igt@drm_r...@short-buffer-wakeup.html

  * igt@gem_ctx_isolation@nonpriv@vcs0:
- {shard-dg1}:NOTRUN -> [FAIL][2] +5 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-dg1-18/igt@gem_ctx_isolation@nonp...@vcs0.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:NOTRUN -> [FAIL][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@kms_content_protection@legacy:
- {shard-tglu-9}: NOTRUN -> [SKIP][4] +12 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-tglu-9/igt@kms_content_protect...@legacy.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[FAIL][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]) ([i915#4386]) -> ([PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][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])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl1/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl7/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12478/shard-apl1/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-apl7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-apl2/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-apl2/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111592v2/shard-apl3/boot.html
   [34]: 

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

[Maxime Ripard]

Hi,

Here's this week drm-misc-next-fixes PR

All of those patches seems to have been applied to both drm-misc-next
and drm-misc-next-fixes and were part of the final drm-misc-next PR for
6.2.

So we shouldn't have any new patch per se, but it aligns all our
branches and fixes this odd situation.

Maxime

drm-misc-next-fixes-2022-12-08:
Some deferred-io and damage worker reworks revert and make a fb function
static
The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6:

  Merge tag 'drm-intel-next-2022-11-18' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2022-12-08

for you to fetch changes up to b02897e56b4e1fa6445be695ce5d605bb098435c:

  Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper" 
(2022-11-23 09:11:32 +0100)


Some deferred-io and damage worker reworks revert and make a fb function
static


Thomas Zimmermann (6):
  Merge drm/drm-next into drm-misc-next-fixes
  Merge drm/drm-next into drm-misc-next-fixes
  fbdev: Make fb_modesetting_disabled() static inline
  Revert "drm/fb-helper: Remove damage worker"
  Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to 
framebuffer"
  Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper"

 drivers/gpu/drm/drm_fb_helper.c | 30 +-
 drivers/video/fbdev/core/fb_defio.c | 16 
 include/drm/drm_fb_helper.h |  2 ++
 include/linux/fb.h  |  3 +--
 4 files changed, 16 insertions(+), 35 deletions(-)


signature.asc
Description: PGP signature

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3 1/2] lib/dmabuf_sync_file: move common stuff into lib

[Das, Nirmoy]

LGTM the series is Reviewed-by: Nirmoy Das 

On 12/7/2022 5:52 PM, Matthew Auld wrote:

So we can use this across different tests.

v2
   - Add docs for everything (Petri)
   - Add missing copyright and fix headers slightly (Kamil)
v3:
   - Just return true/false, for the has() family of functions, instead
 of tripping up an assert() (Kamil)

Signed-off-by: Matthew Auld 
Cc: Kamil Konieczny 
Cc: Petri Latvala 
Cc: Andrzej Hajda 
Cc: Nirmoy Das 
---
  .../igt-gpu-tools/igt-gpu-tools-docs.xml  |   1 +
  lib/dmabuf_sync_file.c| 208 ++
  lib/dmabuf_sync_file.h|  26 +++
  lib/meson.build   |   1 +
  tests/dmabuf_sync_file.c  | 133 +--
  5 files changed, 240 insertions(+), 129 deletions(-)
  create mode 100644 lib/dmabuf_sync_file.c
  create mode 100644 lib/dmabuf_sync_file.h

diff --git a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml 
b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
index 1ce842f4..102c8a89 100644
--- a/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
+++ b/docs/reference/igt-gpu-tools/igt-gpu-tools-docs.xml
@@ -15,6 +15,7 @@
  


  API Reference
+
  
  
  
diff --git a/lib/dmabuf_sync_file.c b/lib/dmabuf_sync_file.c
new file mode 100644
index ..7803ec67
--- /dev/null
+++ b/lib/dmabuf_sync_file.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "igt.h"
+#include "igt_vgem.h"
+#include "sw_sync.h"
+
+#include "dmabuf_sync_file.h"
+
+/**
+ * SECTION: dmabuf_sync_file
+ * @short_description: DMABUF importing/exporting fencing support library
+ * @title: DMABUF Sync File
+ * @include: dmabuf_sync_file.h
+ */
+
+struct igt_dma_buf_sync_file {
+   __u32 flags;
+   __s32 fd;
+};
+
+#define IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct 
igt_dma_buf_sync_file)
+#define IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct 
igt_dma_buf_sync_file)
+
+/**
+ * has_dmabuf_export_sync_file:
+ * @fd: The open drm fd
+ *
+ * Check if the kernel supports exporting a sync file from dmabuf.
+ */
+bool has_dmabuf_export_sync_file(int fd)
+{
+   struct vgem_bo bo;
+   int dmabuf, ret;
+   struct igt_dma_buf_sync_file arg;
+
+   bo.width = 1;
+   bo.height = 1;
+   bo.bpp = 32;
+   vgem_create(fd, );
+
+   dmabuf = prime_handle_to_fd(fd, bo.handle);
+   gem_close(fd, bo.handle);
+
+   arg.flags = DMA_BUF_SYNC_WRITE;
+   arg.fd = -1;
+
+   ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
+   close(dmabuf);
+
+   return (ret == 0 || errno == ENOTTY);
+}
+
+/**
+ * dmabuf_export_sync_file:
+ * @dmabuf: The dmabuf fd
+ * @flags: The flags to control the behaviour
+ *
+ * Take a snapshot of the current dma-resv fences in the dmabuf, and export as 
a
+ * syncfile. The @flags should at least specify either DMA_BUF_SYNC_WRITE or
+ * DMA_BUF_SYNC_READ, depending on if we care about the read or write fences.
+ */
+int dmabuf_export_sync_file(int dmabuf, uint32_t flags)
+{
+   struct igt_dma_buf_sync_file arg;
+
+   arg.flags = flags;
+   arg.fd = -1;
+   do_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_EXPORT_SYNC_FILE, );
+
+   return arg.fd;
+}
+
+/**
+ * has_dmabuf_import_sync_file:
+ * @fd: The open drm fd
+ *
+ * Check if the kernel supports importing a sync file into a dmabuf.
+ */
+bool has_dmabuf_import_sync_file(int fd)
+{
+   struct vgem_bo bo;
+   int dmabuf, timeline, fence, ret;
+   struct igt_dma_buf_sync_file arg;
+
+   bo.width = 1;
+   bo.height = 1;
+   bo.bpp = 32;
+   vgem_create(fd, );
+
+   dmabuf = prime_handle_to_fd(fd, bo.handle);
+   gem_close(fd, bo.handle);
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_timeline_create_fence(timeline, 1);
+   sw_sync_timeline_inc(timeline, 1);
+
+   arg.flags = DMA_BUF_SYNC_RW;
+   arg.fd = fence;
+
+   ret = igt_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE, );
+   close(dmabuf);
+   close(fence);
+   return (ret == 0 || errno == ENOTTY);
+}
+
+/**
+ * dmabuf_import_sync_file:
+ * @dmabuf: The dmabuf fd
+ * @flags: The flags to control the behaviour
+ * @sync_fd: The sync file (i.e our fence) to import
+ *
+ * Import the sync file @sync_fd, into the dmabuf. The @flags should at least
+ * specify DMA_BUF_SYNC_WRITE or DMA_BUF_SYNC_READ, depending on if we are
+ * importing the @sync_fd as a read or write fence.
+ */
+void dmabuf_import_sync_file(int dmabuf, uint32_t flags, int sync_fd)
+{
+   struct igt_dma_buf_sync_file arg;
+
+   arg.flags = flags;
+   arg.fd = sync_fd;
+   do_ioctl(dmabuf, IGT_DMA_BUF_IOCTL_IMPORT_SYNC_FILE, );
+}
+
+/**
+ * dmabuf_import_timeline_fence:
+ * @dmabuf: The dmabuf fd
+ * @flags: The flags to control the behaviour
+ * @timeline: The sync file timeline where the new fence is created
+