[Intel-gfx] ✗ Fi.CI.BAT: failure for Cleanup a few functions in C10/C20 handling

2023-10-18 Thread Patchwork
== Series Details ==

Series: Cleanup a few functions in C10/C20 handling
URL   : https://patchwork.freedesktop.org/series/125323/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13774 -> Patchwork_125323v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125323v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125323v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125323v1/index.html

Participating hosts (31 -> 28)
--

  Additional (1): fi-cfl-8109u 
  Missing(4): fi-ilk-650 fi-blb-e6850 fi-glk-j4005 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13774/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_parallel@engines@contexts:
- bat-dg1-5:  [PASS][4] -> [INCOMPLETE][5] ([i915#9541])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13774/bat-dg1-5/igt@gem_exec_parallel@engi...@contexts.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-dg1-5/igt@gem_exec_parallel@engi...@contexts.html

  * igt@gem_huc_copy@huc-copy:
- fi-cfl-8109u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html
- bat-jsl-1:  NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-8109u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-cfl-8109u:   NOTRUN -> [SKIP][10] ([fdo#109271]) +10 other tests 
skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/fi-cfl-8109u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1:  NOTRUN -> [SKIP][11] ([i915#4103]) +1 other test skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-jsl-1:  NOTRUN -> [SKIP][12] ([i915#3555]) +1 other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-jsl-1:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:NOTRUN -> [ABORT][14] ([i915#8668] / [i915#9451])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-c-dp-5.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- bat-jsl-1:  [INCOMPLETE][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13774/bat-jsl-1/igt@i915_module_l...@load.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v1/bat-jsl-1/igt@i915_module_l...@load.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-a-dp-5:
- bat-adlp-11:[DMESG-FAIL][17] ([i915#6868]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13774/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-a-dp-5.html
   [18]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Cleanup a few functions in C10/C20 handling

2023-10-18 Thread Patchwork
== Series Details ==

Series: Cleanup a few functions in C10/C20 handling
URL   : https://patchwork.freedesktop.org/series/125323/
State : warning

== Summary ==

Error: dim checkpatch failed
8ddc8e558b4d drm/i915/display: Abstract C10/C20 pll hw readout
ca3f8c7416f8 drm/i915/display: Abstract C10/C20 pll calculation
-:97: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#97: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:3863:
+   crtc_state->port_clock = intel_cx0pll_calc_port_clock(encoder, 
_state->cx0pll_state);

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




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lnl: Assign correct phys

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/lnl: Assign correct phys
URL   : https://patchwork.freedesktop.org/series/125322/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13774 -> Patchwork_125322v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125322v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125322v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125322v1/index.html

Participating hosts (31 -> 31)
--

  Additional (2): bat-dg2-9 fi-cfl-8109u 
  Missing(2): fi-kbl-x1275 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-cfl-8109u:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/fi-cfl-8109u/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-jsl-1:  NOTRUN -> [SKIP][2] ([i915#9318])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- bat-jsl-1:  NOTRUN -> [SKIP][4] ([i915#4613]) +3 other tests skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][5] ([i915#4083])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][6] ([i915#4077]) +2 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][7] ([i915#4079]) +1 other test skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@i915_pm_...@basic-api.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][9] ([i915#5190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][10] ([i915#4215] / [i915#5190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-9:  NOTRUN -> [SKIP][11] ([i915#4212]) +6 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-9:  NOTRUN -> [SKIP][12] ([i915#4212] / [i915#5608])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1:  NOTRUN -> [SKIP][14] ([i915#4103]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-jsl-1:  NOTRUN -> [SKIP][15] ([i915#3555]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-jsl-1/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg2-9:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125322v1/bat-dg2-9/igt@kms_force_connector_ba...@force-load-detect.html
- bat-jsl-1:  NOTRUN -> [SKIP][17] ([fdo#109285])
 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/lnl: Assign correct phys

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/lnl: Assign correct phys
URL   : https://patchwork.freedesktop.org/series/125322/
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.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG=y regression (rev4)

2023-10-18 Thread Patchwork
== Series Details ==

Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev4)
URL   : https://patchwork.freedesktop.org/series/125063/
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 fix DRM_USE_DYNAMIC_DEBUG=y regression (rev4)

2023-10-18 Thread Patchwork
== Series Details ==

Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev4)
URL   : https://patchwork.freedesktop.org/series/125063/
State : warning

== Summary ==

Error: dim checkpatch failed
de473fa889bf test-dyndbg: fixup CLASSMAP usage error
6120b244541c dyndbg: reword "class unknown, " to "class:_UNKNOWN_"
f126f978b435 dyndbg: make ddebug_class_param union members same size
aae94727a713 dyndbg: replace classmap list with a vector
66b5f39c8785 dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
1cdfc9d903fc dyndbg: split param_set_dyndbg_classes to module/wrapper fns
fc06b7feccfe dyndbg: drop NUM_TYPE_ARRAY
ffcb9f1f8636 dyndbg: reduce verbose/debug clutter
c866a539e406 dyndbg: silence debugs with no-change updates
4784ef035287 dyndbg: tighten ddebug_class_name() 1st arg type
3ac7b8d72fd2 dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
1da13b10463b dyndbg: reduce verbose=3 messages in ddebug_add_module
74131b274a45 dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
43de21a56b00 dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:451: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible 
side-effects?
#451: FILE: include/linux/dynamic_debug.h:121:
+#define DYNDBG_CLASSMAP_USE_(_var, _uname) \
+   extern struct ddebug_class_map _var;\
+   static struct ddebug_class_user __aligned(8) __used \
+   __section("__dyndbg_class_users") _uname = {\
+   .user_mod_name = KBUILD_MODNAME,\
+   .map = &_var,   \
}

-:771: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#771: FILE: lib/dynamic_debug.c:1254:
+   for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++) 
{
+

-:776: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#776: FILE: lib/dynamic_debug.c:1259:
+   if (!strcmp(cli->user_mod_name, dt->mod_name)) {
+

-:877: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'base' may be better as 
'(base)' to avoid precedence issues
#877: FILE: lib/test_dynamic_debug.c:36:
+#define CLASSMAP_BITMASK(width, base) (((1UL << (width)) - 1) << base)

-:992: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#992: 
new file mode 100644

total: 0 errors, 1 warnings, 4 checks, 738 lines checked
a01f9dca7c9a dyndbg: refactor ddebug_classparam_clamp_input
d22b3571321b dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
22dd04f68f6a dyndbg-doc: add classmap info to howto
bba3fca7dc81 dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
-:30: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#30: FILE: include/linux/dynamic_debug.h:41:
+#define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
  ^

total: 0 errors, 0 warnings, 1 checks, 7 lines checked
5de650a517eb dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
16edd46daddc dyndbg: refactor *dynamic_emit_prefix
3be6bca84bf4 dyndbg: change WARN_ON to WARN_ON_ONCE
fdb1745e66b1 drm: use correct ccflags-y spelling
57081bf5f017 drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
4f5d83495dc0 drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mst: MST modeset sequence fixes

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/mst: MST modeset sequence fixes
URL   : https://patchwork.freedesktop.org/series/125307/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_125307v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125307v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125307v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125307v1/index.html

Participating hosts (32 -> 32)
--

  Additional (3): bat-dg2-8 bat-adln-1 bat-adlm-1 
  Missing(3): bat-kbl-2 fi-snb-2520m fi-elk-e7500 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@fbdev@read:
- fi-ilk-650: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-ilk-650/igt@fb...@read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/fi-ilk-650/igt@fb...@read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#3826])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#2582]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#1849] / [i915#2582])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@fb...@info.html

  * igt@gem_exec_parallel@engines@fds:
- bat-dg2-9:  [PASS][7] -> [INCOMPLETE][8] ([i915#9541])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][10] ([i915#4083])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][11] ([i915#4077]) +2 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][12] ([i915#3282])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#3282])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@i915_pm_...@basic-api.html
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#6621])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#6645])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][18] ([i915#5190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][19] ([i915#4215] / [i915#5190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125307v1/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mst: MST modeset sequence fixes

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/mst: MST modeset sequence fixes
URL   : https://patchwork.freedesktop.org/series/125307/
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'
+./drivers/gpu/drm/i915/intel_uncore.h:351:1: warning: trying to copy 
expression type 31
+./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'

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add bigjoiner force enable option to debugfs (rev4)

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Add bigjoiner force enable option to debugfs (rev4)
URL   : https://patchwork.freedesktop.org/series/124730/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_124730v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_124730v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_124730v4, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_124730v4/index.html

Participating hosts (32 -> 33)
--

  Additional (2): bat-adln-1 bat-adlm-1 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-jsl-3:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/bat-jsl-3/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-jsl-3/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#3826])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#2582]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#1849] / [i915#2582])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#6621])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-adln-1: NOTRUN -> [SKIP][11] ([i915#4213]) +1 other test skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adln-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#1845]) +17 other tests 
skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  * igt@kms_dsc@dsc-basic:
- bat-adln-1: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adln-1/igt@kms_...@dsc-basic.html

  * igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#3637]) +3 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@kms_f...@basic-plain-flip.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adln-1: NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adln-1/igt@kms_force_connector_ba...@force-load-detect.html
- bat-adlm-1: NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#1849])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v4/bat-adlm-1/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-5:
- bat-adlp-11:[PASS][18] -> [ABORT][19] ([i915#8668] / 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL
URL   : https://patchwork.freedesktop.org/series/125293/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_125293v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125293v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125293v1, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125293v1/index.html

Participating hosts (32 -> 32)
--

  Additional (2): bat-adln-1 bat-adlm-1 
  Missing(2): fi-cfl-guc fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_close_race@basic-process:
- fi-kbl-guc: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-kbl-guc/igt@gem_close_r...@basic-process.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/fi-kbl-guc/igt@gem_close_r...@basic-process.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][3] ([i915#9318])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#3826])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#2582]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#1849] / [i915#2582])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@fb...@info.html

  * igt@gem_exec_parallel@engines@fds:
- bat-dg2-9:  [PASS][7] -> [INCOMPLETE][8] ([i915#9541])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-dg2-9/igt@gem_exec_parallel@engi...@fds.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][11] ([i915#3282])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#6621])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][13] -> [DMESG-FAIL][14] ([i915#5334])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-adln-1: NOTRUN -> [SKIP][15] ([i915#4213]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adln-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#1845]) +17 other tests 
skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  * igt@kms_dsc@dsc-basic:
- bat-adln-1: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#3840])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adln-1/igt@kms_...@dsc-basic.html

  * igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][18] ([i915#3637]) +3 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125293v1/bat-adlm-1/igt@kms_f...@basic-plain-flip.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adln-1:   

[Intel-gfx] [PATCH 2/2] drm/i915/display: Abstract C10/C20 pll calculation

2023-10-18 Thread Lucas De Marchi
As done with the hw readout, properly abstract the C10/C20 phy details
inside intel_cx0_phy.c.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  6 ++
 drivers/gpu/drm/i915/display/intel_ddi.c |  7 +--
 drivers/gpu/drm/i915/display/intel_dpll.c|  7 +--
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 252492ec6111..8ffa52464516 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2378,8 +2378,8 @@ static void intel_c20_pll_program(struct drm_i915_private 
*i915,
  BIT(0), cntx ? 0 : 1, MB_WRITE_COMMITTED);
 }
 
-int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
-const struct intel_c10pll_state *pll_state)
+static int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
+   const struct intel_c10pll_state 
*pll_state)
 {
unsigned int frac_quot = 0, frac_rem = 0, frac_den = 1;
unsigned int multiplier, tx_clk_div, hdmi_div, refclk = 38400;
@@ -2405,8 +2405,8 @@ int intel_c10pll_calc_port_clock(struct intel_encoder 
*encoder,
return tmpclk;
 }
 
-int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
-const struct intel_c20pll_state *pll_state)
+static int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
+   const struct intel_c20pll_state 
*pll_state)
 {
unsigned int frac, frac_en, frac_quot, frac_rem, frac_den;
unsigned int multiplier, refclk = 38400;
@@ -3065,3 +3065,15 @@ void intel_cx0pll_readout_hw_state(struct intel_encoder 
*encoder,
else
intel_c20pll_readout_hw_state(encoder, _state->c20);
 }
+
+int intel_cx0pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_cx0pll_state *pll_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+   if (intel_is_c10phy(i915, phy))
+   return intel_c10pll_calc_port_clock(encoder, _state->c10);
+
+   return intel_c20pll_calc_port_clock(encoder, _state->c20);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index ff7ccb7855aa..222aed16e739 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -33,17 +33,15 @@ intel_mtl_port_pll_type(struct intel_encoder *encoder,
 int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct 
intel_encoder *encoder);
 void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
   struct intel_cx0pll_state *pll_state);
+int intel_cx0pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_cx0pll_state *pll_state);
 
 void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
const struct intel_c10pll_state *hw_state);
-int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
-const struct intel_c10pll_state *pll_state);
 void intel_c10pll_state_verify(struct intel_atomic_state *state,
   struct intel_crtc *crtc);
 void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
const struct intel_c20pll_state *hw_state);
-int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
-const struct intel_c20pll_state *pll_state);
 void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state);
 int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 80a8ab7874db..c4dc1f71da4b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3854,18 +3854,13 @@ void intel_ddi_get_clock(struct intel_encoder *encoder,
 static void mtl_ddi_get_config(struct intel_encoder *encoder,
   struct intel_crtc_state *crtc_state)
 {
-   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
-   enum phy phy = intel_port_to_phy(i915, encoder->port);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
 
if (intel_tc_port_in_tbt_alt_mode(dig_port)) {
crtc_state->port_clock = intel_mtl_tbt_calc_port_clock(encoder);
-   } else if (intel_is_c10phy(i915, phy)) {
-   intel_cx0pll_readout_hw_state(encoder, 
_state->cx0pll_state);
-

[Intel-gfx] [PATCH 1/2] drm/i915/display: Abstract C10/C20 pll hw readout

2023-10-18 Thread Lucas De Marchi
intel_cx0_phy.[ch] should contain the details about C10/C20, not leaking
it to the rest of the driver. Start abstracting this by exporting a
single PLL hw readout that handles the differences between C20 and C10
internally to that compilation unit.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  8 +---
 drivers/gpu/drm/i915/display/intel_ddi.c |  4 ++--
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index e775f4721158..252492ec6111 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1850,8 +1850,8 @@ static int intel_c10pll_calc_state(struct 
intel_crtc_state *crtc_state,
return -EINVAL;
 }
 
-void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
-  struct intel_c10pll_state *pll_state)
+static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
+ struct intel_c10pll_state *pll_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
u8 lane = INTEL_CX0_LANE0;
@@ -2103,8 +2103,8 @@ static bool intel_c20_use_mplla(u32 clock)
return false;
 }
 
-void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
-  struct intel_c20pll_state *pll_state)
+static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
+ struct intel_c20pll_state *pll_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
bool cntx;
@@ -3053,3 +3053,15 @@ void intel_c10pll_state_verify(struct intel_atomic_state 
*state,
crtc->base.base.id, crtc->base.name,
mpllb_sw_state->cmn, mpllb_hw_state.cmn);
 }
+
+void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
+  struct intel_cx0pll_state *pll_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+   if (intel_is_c10phy(i915, phy))
+   intel_c10pll_readout_hw_state(encoder, _state->c10);
+   else
+   intel_c20pll_readout_hw_state(encoder, _state->c20);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 0e0a38dac8cd..ff7ccb7855aa 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -16,6 +16,7 @@ struct drm_i915_private;
 struct intel_atomic_state;
 struct intel_c10pll_state;
 struct intel_c20pll_state;
+struct intel_cx0pll_state;
 struct intel_crtc;
 struct intel_crtc_state;
 struct intel_encoder;
@@ -28,16 +29,17 @@ void intel_mtl_pll_disable(struct intel_encoder *encoder);
 enum icl_port_dpll_id
 intel_mtl_port_pll_type(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
-void intel_c10pll_readout_hw_state(struct intel_encoder *encoder, struct 
intel_c10pll_state *pll_state);
+
 int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct 
intel_encoder *encoder);
+void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
+  struct intel_cx0pll_state *pll_state);
+
 void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
const struct intel_c10pll_state *hw_state);
 int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
 const struct intel_c10pll_state *pll_state);
 void intel_c10pll_state_verify(struct intel_atomic_state *state,
   struct intel_crtc *crtc);
-void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
-  struct intel_c20pll_state *pll_state);
 void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
const struct intel_c20pll_state *hw_state);
 int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9151d5add960..80a8ab7874db 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3861,10 +3861,10 @@ static void mtl_ddi_get_config(struct intel_encoder 
*encoder,
if (intel_tc_port_in_tbt_alt_mode(dig_port)) {
crtc_state->port_clock = intel_mtl_tbt_calc_port_clock(encoder);
} else if (intel_is_c10phy(i915, phy)) {
-   intel_c10pll_readout_hw_state(encoder, 
_state->cx0pll_state.c10);
+   intel_cx0pll_readout_hw_state(encoder, 
_state->cx0pll_state);
crtc_state->port_clock = 

[Intel-gfx] [PATCH 0/2] Cleanup a few functions in C10/C20 handling

2023-10-18 Thread Lucas De Marchi
I started a cleanup on the c10/c20 while adding LNL, but had to stop due
to other priorities, so this is not a complete cleanup.  More details
and ask for feedback at https://patchwork.freedesktop.org/series/125322/

Maybe it's worth getting these in regardless.

Lucas De Marchi (2):
  drm/i915/display: Abstract C10/C20 pll hw readout
  drm/i915/display: Abstract C10/C20 pll calculation

 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 40 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h | 14 +++
 drivers/gpu/drm/i915/display/intel_ddi.c |  9 +
 drivers/gpu/drm/i915/display/intel_dpll.c|  7 +---
 4 files changed, 42 insertions(+), 28 deletions(-)

-- 
2.40.1



[Intel-gfx] [PATCH 0/2] drm/i915/lnl: Assign correct phys

2023-10-18 Thread Lucas De Marchi
For this series to work, we still need a separate patch on the xe side
so it defines the LNL platform macro to be used by display.

One thing missing for LNL during the previous patches was the
port <-> phy assignment. With the bspec now clarified, this is the
minimum changes needed for LNL.  As the commit messages say and after
looking at the history of the code, it seems we were thinking to go one
direction abstraction-wise with DG2, but reverted course with MTL. The
end result right now is a very confusing mix of port/phy/tc_port.
I was hoping to do a cleanup now, but we probably need some consensus on
the approach as it'd be an intrusive change.

Here are some thoughts after looking again at the current state of the
code:

1) What is the port -> phy conversion for? AFAIR this was because from
the display engine side we want, some registers have bit offsets based
on the port and others are based on the PHY. I think now we can

a) Remove enum tc_port and have only `enum port` and `enum phy`.
   Those should be sufficient for all platform needs afaics

b) Add phy to intel_encoder (or intel_digital_port). It's
   appalling number of places we convert from port to phy. That
   would just be initialized during init.

2) It looks we need to better abstract the phy handling. Right now it's
very confusing with dkl, c10/c20 (that leak the abstraction from
intel_cx0_phy.c to everywhere in the driver), snps and the older
combo/tc being a superset of them.  I'm still not sure what to do here.
One thing that we can probably do is to remove the dg2-special case and
let the "is tc" be about the **port being connected to a TC-capable phy**.
Bspec always refer to those as TC / USBC. Then dkl, c10, c20, snps
would all be in the same abstraction layer. Any thoughts?

Lucas De Marchi (2):
  drm/i915/lnl: Extend C10/C20 phy
  drm/i915/lnl: Fix check for TC phy

 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 3 files changed, 17 insertions(+), 15 deletions(-)

-- 
2.40.1



[Intel-gfx] [PATCH 2/2] drm/i915/lnl: Fix check for TC phy

2023-10-18 Thread Lucas De Marchi
With MTL adding PICA between the port and the real phy, the path
add for DG2 stopped being followed and newer platforms are simply using
the older path for TC phys. LNL is no different than MTL in this aspect,
so just add it to the mess. In future the phy and port designation and
deciding if it's TC should better be cleaned up.

To make it just a bit better, also change intel_phy_is_snps() to show
this is DG2-only.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 28d85e1e858e..0797ace31417 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1784,31 +1784,32 @@ bool intel_phy_is_combo(struct drm_i915_private 
*dev_priv, enum phy phy)
 
 bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
 {
+   /* DG2's "TC1" output uses a SNPS PHY and is handled separately */
if (IS_DG2(dev_priv))
-   /* DG2's "TC1" output uses a SNPS PHY */
return false;
-   else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) == 
IP_VER(14, 0))
+
+   /*
+* TODO: This should mostly match intel_port_to_phy(), considering the
+* ports already encode if they are connected to a TC phy in their name.
+*/
+   if (IS_LUNARLAKE(dev_priv) || IS_METEORLAKE(dev_priv) ||
+   IS_ALDERLAKE_P(dev_priv))
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
else if (IS_ICELAKE(dev_priv))
return phy >= PHY_C && phy <= PHY_F;
-   else
-   return false;
+
+   return false;
 }
 
 bool intel_phy_is_snps(struct drm_i915_private *dev_priv, enum phy phy)
 {
-   if (phy == PHY_NONE)
-   return false;
-   else if (IS_DG2(dev_priv))
-   /*
-* All four "combo" ports and the TC1 port (PHY E) use
-* Synopsis PHYs.
-*/
-   return phy <= PHY_E;
-
-   return false;
+   /*
+* For DG2, and for DG2 only, all four "combo" ports and the TC1 port
+* (PHY E) use Synopsis PHYs.
+*/
+   return IS_DG2(dev_priv) && phy > PHY_NONE && phy <= PHY_E;
 }
 
 enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
-- 
2.40.1



[Intel-gfx] [PATCH 1/2] drm/i915/lnl: Extend C10/C20 phy

2023-10-18 Thread Lucas De Marchi
For Lunar Lake, DDI-A is connected to C10 PHY, while TC1-TC3 are connected
to C20 phy, like in Meteor Lake. Update the check in intel_is_c10phy()
accordingly.

This reverts the change in commit e388ae97e225 ("drm/i915/display:
Eliminate IS_METEORLAKE checks") that turned that into a display engine
version check. The phy <-> port connection is very SoC-specific and not
related to that version.

IS_LUNARLAKE() is defined to 0 in i915 as it's expected that the
(upcoming) xe driver is the one defining the platform, with i915 only
driving the display side.

Bspec: 70818
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index d414f6b7f993..e775f4721158 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -31,7 +31,7 @@
 
 bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
 {
-   if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
+   if ((IS_LUNARLAKE(i915) || IS_METEORLAKE(i915)) && phy < PHY_C)
return true;
 
return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a2a78c61f21..259884b10d9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -575,6 +575,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_DG2(i915)   IS_PLATFORM(i915, INTEL_DG2)
 #define IS_PONTEVECCHIO(i915) IS_PLATFORM(i915, INTEL_PONTEVECCHIO)
 #define IS_METEORLAKE(i915) IS_PLATFORM(i915, INTEL_METEORLAKE)
+#define IS_LUNARLAKE(i915) 0
 
 #define IS_DG2_G10(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
-- 
2.40.1



[Intel-gfx] ✓ Fi.CI.BAT: success for display device info as a separate debugfs entry (rev6)

2023-10-18 Thread Patchwork
== Series Details ==

Series: display device info as a separate debugfs entry (rev6)
URL   : https://patchwork.freedesktop.org/series/125222/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_125222v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (32 -> 31)
--

  Additional (3): bat-dg2-8 bat-adln-1 bat-adlm-1 
  Missing(4): bat-dg2-14 fi-rkl-11600 fi-ivb-3770 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#3826])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +3 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#1849] / [i915#2582])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][9] ([i915#4079]) +1 other test skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-8:  NOTRUN -> [SKIP][11] ([i915#6621])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@i915_pm_...@basic-api.html
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#6621])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([i915#6645])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][14] ([i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#4215] / [i915#5190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#4212]) +6 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#4212] / [i915#5608])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-dg2-8/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-adln-1: NOTRUN -> [SKIP][18] ([i915#4213]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125222v6/bat-adln-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [19]: 

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add Wa_14019821291

2023-10-18 Thread Matt Roper
On Wed, Oct 18, 2023 at 01:34:43PM +0530, Dnyaneshwar Bhadane wrote:
> This workaround is primarily implemented by the BIOS.  However if the
> BIOS applies the workaround it will reserve a small piece of our DSM
> (which should be at the top, right below the WOPCM); we just need to
> keep that region reserved so that nothing else attempts to re-use it.
> 
> Signed-off-by: Dnyaneshwar Bhadane 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 18 ++
>  drivers/gpu/drm/i915/i915_reg.h|  2 ++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 1a766d8e7cce..b2bc5aab88d3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -409,6 +409,24 @@ static void icl_get_stolen_reserved(struct 
> drm_i915_private *i915,
>   *base -= *size;
>   else
>   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
> +
> + /* Wa_14019821291*/
> + if (IS_MEDIA_GT_IP_STEP(i915->media_gt, IP_VER(13, 0), STEP_A0, 
> STEP_C0)) {

When I check the workaround database I don't see this going away on C0
stepping.  It's just listed as a permanent workaround that applies to
all steppings as far as I can see.  So just

if (MEDIA_VER_FULL(i915) == IP_VER(13, 0))

should be sufficient.

> + /*
> +  * This workaround is primarily implemented by the BIOS.  We
> +  * just need to figure out whether the BIOS has applied the
> +  * workaround (meaning the programmed address falls within
> +  * the DSM) and, if so, reserve that part of the DSM to
> +  * prevent accidental reuse.  The DSM location should be just
> +  * below the WOPCM.
> +  */
> +
> + u64 gscpsmi_base = intel_uncore_read64_2x32(uncore,
> + 
> MTL_GSCPSMI_BASEADDR_LSB,
> + 
> MTL_GSCPSMI_BASEADDR_MSB);
> + if (gscpsmi_base >= *base && gscpsmi_base < *base + *size)
> + *size = gscpsmi_base - *base;
> + }
>  }
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 135e8d8dbdf0..31d0692a5620 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6399,5 +6399,7 @@ enum skl_power_gate {
>  #define   MTL_TRDPRE_MASKREG_GENMASK(7, 0)
>  
>  #define MTL_MEDIA_GSI_BASE   0x38
> +#define MTL_GSCPSMI_BASEADDR_LSB _MMIO(MTL_MEDIA_GSI_BASE + 
> 0x880c)
> +#define MTL_GSCPSMI_BASEADDR_MSB _MMIO(MTL_MEDIA_GSI_BASE + 
> 0x8810)

There's no need to manually add MTL_MEDIA_GSI_BASE into the register
offset; the intel_uncore_* functions take care of doing that
automatically when you read/write the register.  Just _MMIO(0x88xx) is
sufficient.

Also, since these are GT registers, they should probably be in
gt/intel_gt_regs.h instead of this header.


Matt

>  
>  #endif /* _I915_REG_H_ */
> -- 
> 2.34.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


[Intel-gfx] ✗ Fi.CI.BUILD: warning for display device info as a separate debugfs entry (rev6)

2023-10-18 Thread Patchwork
== Series Details ==

Series: display device info as a separate debugfs entry (rev6)
URL   : https://patchwork.freedesktop.org/series/125222/
State : warning

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/125222/revisions/6/mbox/ not 
found




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for display device info as a separate debugfs entry (rev6)

2023-10-18 Thread Patchwork
== Series Details ==

Series: display device info as a separate debugfs entry (rev6)
URL   : https://patchwork.freedesktop.org/series/125222/
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] ✗ Fi.CI.BAT: failure for drm/i915: Flush WC GGTT only on required platforms (rev9)

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush WC GGTT only on required platforms (rev9)
URL   : https://patchwork.freedesktop.org/series/125111/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_125111v9


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_125111v9 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_125111v9, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_125111v9/index.html

Participating hosts (32 -> 32)
--

  Additional (3): bat-dg2-8 bat-adln-1 bat-adlm-1 
  Missing(3): bat-dg2-9 fi-snb-2520m bat-dg1-5 

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- fi-ilk-650: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-ilk-650/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/fi-ilk-650/boot.html

  

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-kbl-7567u:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-kbl-7567u/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/fi-kbl-7567u/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@objects:
- fi-elk-e7500:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/fi-elk-e7500/igt@i915_selftest@l...@objects.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/fi-elk-e7500/igt@i915_selftest@l...@objects.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][7] ([i915#9318])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#3826])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#2582]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#1849] / [i915#2582])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@fb...@info.html

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3:  [PASS][11] -> [INCOMPLETE][12] ([i915#9275])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][13] ([i915#4613]) +3 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][14] ([i915#4083])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#4077]) +2 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][16] ([i915#3282])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#4079]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-dg2-8/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][18] ([i915#3282])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-8:  NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-dg2-8/igt@i915_pm_...@basic-api.html
- bat-adlm-1: NOTRUN -> [SKIP][20] ([i915#6621])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v9/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc:   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Reset message bus after each read/write operation (rev5)

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/display: Reset message bus after each read/write operation 
(rev5)
URL   : https://patchwork.freedesktop.org/series/124602/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_124602v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (32 -> 32)
--

  Additional (3): bat-dg2-8 bat-adln-1 bat-adlm-1 
  Missing(3): bat-dg2-9 fi-apl-guc fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#3826])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +3 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#1849] / [i915#2582])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_mmap@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-dg2-8:  NOTRUN -> [SKIP][9] ([i915#4079]) +1 other test skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-8:  NOTRUN -> [SKIP][11] ([i915#6621])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@i915_pm_...@basic-api.html
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#6621])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([i915#6645])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][14] ([i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][15] ([i915#4215] / [i915#5190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#4212]) +6 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#4212] / [i915#5608])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-dg2-8/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-adln-1: NOTRUN -> [SKIP][18] ([i915#4213]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v5/bat-adln-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [19]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Wa_14019821291

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Add Wa_14019821291
URL   : https://patchwork.freedesktop.org/series/125282/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13773 -> Patchwork_125282v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (32 -> 32)
--

  Additional (2): bat-adln-1 bat-adlm-1 
  Missing(2): fi-ilk-650 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adln-1: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html
- bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#3826])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +3 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#1849] / [i915#2582])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- bat-adln-1: NOTRUN -> [SKIP][6] ([i915#3282])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adln-1/igt@gem_tiled_pread_basic.html
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-adln-1: NOTRUN -> [SKIP][9] ([i915#4213]) +1 other test skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adln-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#1845]) +17 other tests 
skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  * igt@kms_dsc@dsc-basic:
- bat-adln-1: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#3840])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adln-1/igt@kms_...@dsc-basic.html

  * igt@kms_flip@basic-flip-vs-modeset@d-dp6:
- bat-adlp-11:[PASS][12] -> [DMESG-FAIL][13] ([i915#6868])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13773/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp6.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp6.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#3637])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-wf_vblank.html

  * igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3637]) +3 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@kms_f...@basic-plain-flip.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adln-1: NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adln-1/igt@kms_force_connector_ba...@force-load-detect.html
- bat-adlm-1: NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- bat-adlm-1: NOTRUN -> [SKIP][18] ([i915#1849])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@cursor_plane_move:
- bat-adlm-1: NOTRUN -> [SKIP][19] ([i915#1072]) +3 other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v1/bat-adlm-1/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlm-1: NOTRUN -> [SKIP][20] ([i915#3555])
   [20]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add Wa_14019821291

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Add Wa_14019821291
URL   : https://patchwork.freedesktop.org/series/125282/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy 
expression type 31




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-18 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV
URL   : https://patchwork.freedesktop.org/series/125268/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13772 -> Patchwork_125268v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 33)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][3] ([i915#4077]) +2 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-adlp-6/igt@gem_tiled_pread_basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][5] ([i915#4079]) +1 other test skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-mtlp-6: [PASS][6] -> [ABORT][7] ([i915#9414])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13772/bat-mtlp-6/igt@i915_hang...@error-state-basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-mtlp-6/igt@i915_hang...@error-state-basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@i915_pm_...@basic-api.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][9] ([i915#7978] / [i915#8668])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4212]) +7 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#4215])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][12] ([i915#4103] / [i915#5608]) +1 
other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-dg1-5:  NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1 
other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_dsc@dsc-basic:
- bat-adlp-6: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#3840])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-adlp-6/igt@kms_...@dsc-basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#3555] / [i915#3840])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_hdmi_inject@inject-audio:
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#433])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg1-5/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg2-11: NOTRUN -> [SKIP][19] ([i915#1845] / [i915#9197])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125268v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][20] -> [ABORT][21] ([i915#8668])
   [20]: 

Re: [Intel-gfx] [CI] PR for new GuC v70.13.1

2023-10-18 Thread John Harrison
Apologies, I sent this with the wrong subject. Please ignore. Will 
resend with the correct subject.


John.


On 10/18/2023 12:07, john.c.harri...@intel.com wrote:

The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b:

   Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +)

are available in the Git repository at:

   git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1

for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa:

   i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 
-0700)


John Harrison (1):
   i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL

  WHENCE   |   8 
  i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes
  i915/dg2_guc_70.bin  | Bin 385856 -> 443200 bytes
  i915/mtl_guc_70.bin  | Bin 308032 -> 365376 bytes
  i915/tgl_guc_70.bin  | Bin 285888 -> 330304 bytes
  5 files changed, 4 insertions(+), 4 deletions(-)




[Intel-gfx] PR for new GuC v70.13.1

2023-10-18 Thread John . C . Harrison
The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b:

  Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1

for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa:

  i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 -0700)


John Harrison (1):
  i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL

 WHENCE   |   8 
 i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes
 i915/dg2_guc_70.bin  | Bin 385856 -> 443200 bytes
 i915/mtl_guc_70.bin  | Bin 308032 -> 365376 bytes
 i915/tgl_guc_70.bin  | Bin 285888 -> 330304 bytes
 5 files changed, 4 insertions(+), 4 deletions(-)


[Intel-gfx] [CI] PR for new GuC v70.13.1

2023-10-18 Thread John . C . Harrison
The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b:

  Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1

for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa:

  i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 -0700)


John Harrison (1):
  i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL

 WHENCE   |   8 
 i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes
 i915/dg2_guc_70.bin  | Bin 385856 -> 443200 bytes
 i915/mtl_guc_70.bin  | Bin 308032 -> 365376 bytes
 i915/tgl_guc_70.bin  | Bin 285888 -> 330304 bytes
 5 files changed, 4 insertions(+), 4 deletions(-)


Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Ville Syrjälä
On Wed, Oct 18, 2023 at 07:13:12PM +0200, Maarten Lankhorst wrote:
> 
> 
> On 2023-10-18 17:38, Ville Syrjälä wrote:
> > On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:
> >> We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
> >> implementation. Lets drop i915_sw_fence usage from display code and
> >> use dma_fence interfaces directly.
> >>
> >> For this purpose stack dma fences from related objects into old and new
> >> plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
> >> stacked fences during atomic commit.
> >>
> >> There is no be need for separate GPU reset handling in
> >> intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
> >> detected and GPU is being reset.
> >>
> >> Cc: Ville Syrjälä 
> >> Cc: Maarten Lankhorst 
> >> Cc: José Roberto de Souza 
> >>
> >> Signed-off-by: Jouni Högander 
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
> >>   .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
> >>   drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
> >>   .../drm/i915/display/intel_display_types.h|  2 -
> >>   4 files changed, 37 insertions(+), 95 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> >> b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> index 5d18145da279..ec0d5168b503 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
> >> *_state)
> >>   
> >>drm_atomic_state_default_release(>base);
> >>kfree(state->global_objs);
> >> -
> >> -  i915_sw_fence_fini(>commit_ready);
> >> -
> >>kfree(state);
> >>   }
> >>   
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> >> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> index b1074350616c..d4f9168ec42c 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> @@ -32,6 +32,7 @@
> >>*/
> >>   
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   
> >> @@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> >>struct intel_atomic_state *state =
> >>to_intel_atomic_state(new_plane_state->uapi.state);
> >>struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> >> -  const struct intel_plane_state *old_plane_state =
> >> +  struct intel_plane_state *old_plane_state =
> >>intel_atomic_get_old_plane_state(state, plane);
> >>struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
> >>struct drm_i915_gem_object *old_obj = 
> >> intel_fb_obj(old_plane_state->hw.fb);
> >> @@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> >> * This should only fail upon a hung GPU, in which case we
> >> * can safely continue.
> >> */
> >> -  if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
> >> {
> >> -  ret = 
> >> i915_sw_fence_await_reservation(>commit_ready,
> >> -
> >> old_obj->base.resv,
> >> -false, 0,
> >> -GFP_KERNEL);
> >> +  if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
> >> &&
> >> +  !dma_resv_test_signaled(old_obj->base.resv,
> >> +  dma_resv_usage_rw(false))) {
> >> +  ret = drm_gem_plane_helper_prepare_fb(_plane, 
> >> _plane_state->uapi);
> > 
> > This I think is broken. The old plane state and its fence can still be
> > in use by the previous commit, so we cannot mutate it here. Thus we
> > really need to get the implicit fence from the old fb chained into the
> > new plane state's fence.
> Is it even needed though? If new_plane_state always calls prepare_fb.

It's explained in the comment.

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3

2023-10-18 Thread Andi Shyti
Hi Vinay,

On Tue, Oct 17, 2023 at 12:53:09PM -0700, Vinay Belgaumkar wrote:
> This bit does not cause an explicit L3 flush. We already use
> PIPE_CONTROL_DC_FLUSH_ENABLE for that purpose.
> 
> v2: Use FLUSH_L3 only pre-MTL since spec will likely remain
> the same going forward.
> 
> Cc: Nirmoy Das 
> Cc: Mika Kuoppala 
> Acked-by: Mika Kuoppala 
> Reviewed-by: Nirmoy Das 
> Signed-off-by: Vinay Belgaumkar 

pushed to drm-intel-gt-next.

Thanks,
Andi


Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Maarten Lankhorst




On 2023-10-18 17:38, Ville Syrjälä wrote:

On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:

We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
implementation. Lets drop i915_sw_fence usage from display code and
use dma_fence interfaces directly.

For this purpose stack dma fences from related objects into old and new
plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
stacked fences during atomic commit.

There is no be need for separate GPU reset handling in
intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
detected and GPU is being reset.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: José Roberto de Souza 

Signed-off-by: Jouni Högander 
---
  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
  .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
  .../drm/i915/display/intel_display_types.h|  2 -
  4 files changed, 37 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 5d18145da279..ec0d5168b503 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
*_state)
  
  	drm_atomic_state_default_release(>base);

kfree(state->global_objs);
-
-   i915_sw_fence_fini(>commit_ready);
-
kfree(state);
  }
  
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c

index b1074350616c..d4f9168ec42c 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -32,6 +32,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,

struct intel_atomic_state *state =
to_intel_atomic_state(new_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-   const struct intel_plane_state *old_plane_state =
+   struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
struct drm_i915_gem_object *old_obj = 
intel_fb_obj(old_plane_state->hw.fb);
@@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * This should only fail upon a hung GPU, in which case we
 * can safely continue.
 */
-   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
{
-   ret = 
i915_sw_fence_await_reservation(>commit_ready,
- 
old_obj->base.resv,
- false, 0,
- GFP_KERNEL);
+   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
&&
+   !dma_resv_test_signaled(old_obj->base.resv,
+   dma_resv_usage_rw(false))) {
+   ret = drm_gem_plane_helper_prepare_fb(_plane, 
_plane_state->uapi);


This I think is broken. The old plane state and its fence can still be
in use by the previous commit, so we cannot mutate it here. Thus we
really need to get the implicit fence from the old fb chained into the
new plane state's fence.

Is it even needed though? If new_plane_state always calls prepare_fb.

Cheers,
~Maarten


[Intel-gfx] [PATCH v7c 20/24] dyndbg: refactor *dynamic_emit_prefix

2023-10-18 Thread Jim Cromie
Refactor the split of duties between outer & inner fns.

The outer fn was previously just an inline unlikely forward to inner,
which did all the work.

Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.

No functional change.

But it does make the results of the inner-fn more cache-friendly
(fewer entries, reused more often):

1- no spurious [TID] or  noise
2- no LINE-number to bloat the cache (avg 9 pr_debugs/fn)
3- only LOOKUP stuff

Currently LOOKUPs are descriptor-field refs but could be replaced by
accessor functions.  This would allow the __dyndbg_sites section to be
de-duplicated and reclaimed; currently module, filename fields are
~90% repeated.  As the accessors get more expensive, the value of
caching part of the prefix goes up.

Also change inner-fn to return count of extra chars written to the
buffer, and drop "inline" from outer, let the compiler decide.  Maybe
also change name accordingly.

Signed-off-by: Jim Cromie 
---
fixup whitespace
---
 lib/dynamic_debug.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a6ee142668bf..9db797a0cf82 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -774,11 +774,28 @@ static int remaining(int wrote)
return 0;
 }
 
-static char *__dynamic_emit_prefix(const struct _ddebug *desc, char *buf)
+static int __dynamic_emit_prefix(const struct _ddebug *desc, char *buf, int 
pos)
+{
+   if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   desc->modname);
+   if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   desc->function);
+   if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
+   pos += snprintf(buf + pos, remaining(pos), "%s:",
+   trim_prefix(desc->filename));
+   return pos;
+}
+
+static char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
 {
int pos_after_tid;
int pos = 0;
 
+   if (likely(!(desc->flags & _DPRINTK_FLAGS_INCL_ANY)))
+   return buf;
+
if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
if (in_interrupt())
pos += snprintf(buf + pos, remaining(pos), " ");
@@ -787,15 +804,10 @@ static char *__dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
task_pid_vnr(current));
}
pos_after_tid = pos;
-   if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   desc->modname);
-   if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   desc->function);
-   if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
-   pos += snprintf(buf + pos, remaining(pos), "%s:",
-   trim_prefix(desc->filename));
+
+   if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_LOOKUP))
+   pos += __dynamic_emit_prefix(desc, buf, pos);
+
if (desc->flags & _DPRINTK_FLAGS_INCL_LINENO)
pos += snprintf(buf + pos, remaining(pos), "%d:",
desc->lineno);
@@ -807,13 +819,6 @@ static char *__dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
return buf;
 }
 
-static inline char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
-{
-   if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_ANY))
-   return __dynamic_emit_prefix(desc, buf);
-   return buf;
-}
-
 void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
 {
va_list args;
-- 
2.41.0



[Intel-gfx] [PATCH v7c 24/24] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

2023-10-18 Thread Jim Cromie
Lots of burn-in testing needed before signing, upstreaming.

NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3caa020391c7..708f5e8cb205 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -55,8 +55,7 @@ config DRM_DEBUG_MM
 
 config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
-   default n
-   depends on BROKEN
+   default y
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
-- 
2.41.0



[Intel-gfx] [PATCH v7c 23/24] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers

2023-10-18 Thread Jim Cromie
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files.  For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.

Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'd prdbgs stuck in the initial
(disabled, but for DEBUG) state.

The stuck sites are evident in /proc/dynamic_debug/control as:

   class:_UNKNOWN_ _id:N# control's last column

rather than a proper "enumeration":

   class:DRM_UT_CORE

This set of updates was found by choosing M for all DRM-config items I
found (not allmodconfig), building & modprobing them, and grepping
"class unknown," control.  There may yet be others.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++
 drivers/gpu/drm/gud/gud_drv.c  | 2 ++
 drivers/gpu/drm/mgag200/mgag200_drv.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_drv.c  | 2 ++
 drivers/gpu/drm/radeon/radeon_drv.c| 2 ++
 drivers/gpu/drm/udl/udl_main.c | 2 ++
 drivers/gpu/drm/vkms/vkms_drv.c| 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 ++
 8 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e435f986cd13..066d906e3199 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_IMPORT_NS(DMA_BUF);
 
 /**
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..5b555045fce4 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -31,6 +31,8 @@
 
 #include "gud_internal.h"
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 /* Only used internally */
 static const struct drm_format_info gud_drm_format_r1 = {
.format = GUD_DRM_FORMAT_R1,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index abddf37f0ea1..d678eb8e028d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -24,6 +24,8 @@ static int mgag200_modeset = -1;
 MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
 module_param_named(modeset, mgag200_modeset, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2)
 {
struct device *dev = >dev;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index b30ede1cf62d..91942ffcc2b4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400);
 MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)");
 module_param_named(num_heads, qxl_num_crtc, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct drm_driver qxl_driver;
 static struct pci_driver qxl_pci_driver;
 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa531493b111..ab29945af657 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -247,6 +247,8 @@ int radeon_cik_support = 1;
 MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = 
disabled)");
 module_param_named(cik_support, radeon_cik_support, int, 0444);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 3ebe2ce55dfd..ba57c14454e5 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -19,6 +19,8 @@
 
 #define NR_USB_REQUEST_CHANNEL 0x12
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
 #define WRITES_IN_FLIGHT (20)
 #define MAX_VENDOR_DESCRIPTOR_SIZE 256
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index dd0af086e7fa..086797c4b82b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -39,6 +39,8 @@
 
 static struct vkms_config *default_config;
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static bool enable_cursor = true;
 module_param_named(enable_cursor, enable_cursor, bool, 0444);
 MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8b24ecf60e3e..9cb6be422621 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -275,6 +275,8 @@ static int vmw_probe(struct pci_dev *, const struct 
pci_device_id *);
 static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
  void *ptr);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
 module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
 

[Intel-gfx] [PATCH v7c 21/24] dyndbg: change WARN_ON to WARN_ON_ONCE

2023-10-18 Thread Jim Cromie
This shouldn't ever happen, and 1st 2 conditions never have.

The 3rd condition did happen, due to corrupt linkage due to a missing
align(8) in DYNDBG_CLASSMAP_USE, on the static struct allocation into
the __dyndbg_class_users section.

Not sure whether changing to _ONCE is appropriate - this is a
module-load activity, so it won't continuously spam syslog.

Signed-off-by: Jim Cromie 
---
undo BUG_ON addition
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 9db797a0cf82..213110ec1e9c 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1281,7 +1281,7 @@ static void ddebug_attach_user_module_classes(struct 
ddebug_table *dt,
 */
for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++) 
{
 
-   if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
+   if (WARN_ON_ONCE(!cli || !cli->map || !cli->user_mod_name))
continue;
 
if (!strcmp(cli->user_mod_name, dt->mod_name)) {
-- 
2.41.0



[Intel-gfx] [PATCH v7c 17/24] dyndbg-doc: add classmap info to howto

2023-10-18 Thread Jim Cromie
Add some basic info on classmap usage and api

cc: linux-...@vger.kernel.org
Signed-off-by: Jim Cromie 
---
v5- adjustments per Randy Dunlap, me
v7b- checkpatch fixes
---
 .../admin-guide/dynamic-debug-howto.rst   | 60 ++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
b/Documentation/admin-guide/dynamic-debug-howto.rst
index 0b3d39c610d9..028c2cb5b4c5 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -225,7 +225,6 @@ the ``p`` flag has meaning, other flags are ignored.
 Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification.
 To clear all flags at once, use ``=_`` or ``-fslmpt``.
 
-
 Debug messages during Boot Process
 ==
 
@@ -375,3 +374,62 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``.
 For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
 its ``prefix_str`` argument, if it is constant string; or ``hexdump``
 in case ``prefix_str`` is built dynamically.
+
+Dynamic Debug classmaps
+===
+
+Dyndbg allows selection/grouping of *prdbg* callsites using structural
+info: module, file, function, line.  Classmaps allow authors to add
+their own domain-oriented groupings using class-names.  Classmaps are
+exported, so they referencable from other modules.
+
+  # enable classes individually
+  :#> ddcmd class DRM_UT_CORE +p
+  :#> ddcmd class DRM_UT_KMS +p
+  # or more selectively
+  :#> ddcmd class DRM_UT_CORE module drm +p
+
+The "class FOO" syntax protects class'd prdbgs from generic overwrite::
+
+  # IOW this doesn't wipe any DRM.debug settings
+  :#> ddcmd -p
+
+To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all
+classes in a classmap, mapping param-bits 0..N onto the classes:
+DRM_UT_<*> for the DRM use-case.
+
+Dynamic Debug Classmap API
+==
+
+DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming
+each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and
+type, and mapping the class-names to consecutive _class_ids.
+
+By doing so, modules tell dyndbg that they are have prdbgs with those
+class_ids, and they authorize dyndbg to accept "class FOO" for the
+module defining that classname.
+
+There are 2 types of classmaps:
+
+ DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug
+ DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2)
+
+DYNDBG_CLASSMAP_PARAM - refers to a DEFINEd classmap, exposing the set
+of defined classes to manipulation as a group.  This interface
+enforces the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed
+classmaps; all classes are independent in the >control parser itself.
+
+DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the CLASSMAP that
+drm DEFINEs.  This shares the classmap definition, and authorizes
+dyndbg to apply changes to the user module's class'd pr_debugs.  It
+also tells dyndbg how to initialize the user's prdbgs at modprobe,
+based upon the current setting of the parent's controlling param.
+
+Modules or module-groups (drm & drivers) can define multiple
+classmaps, as long as they share the limited 0..62 per-module-group
+_class_id range, without overlap.
+
+``#define DEBUG`` will enable all pr_debugs in scope, including any
+class'd ones.  This won't be reflected in the PARAM readback value,
+but the pr_debug callsites can be toggled into agreement with the
+param.
-- 
2.41.0



[Intel-gfx] [PATCH v7c 22/24] drm: use correct ccflags-y spelling

2023-10-18 Thread Jim Cromie
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:

CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n

Also add subdir-ccflags so that all drivers pick up the addition.

Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory 
macro")
Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..22b1984cc982 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,7 +3,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
+ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+= 
-DDYNAMIC_DEBUG_MODULE
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
 
 drm-y := \
drm_aperture.o \
-- 
2.41.0



[Intel-gfx] [PATCH v7c 18/24] dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED

2023-10-18 Thread Jim Cromie
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.

Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres another factor; the 3 columns in the __dyndbg
section are highly redundant and compressible, but to get the
compression, we need field accessors, which will rebalance the
tradeoff.

So, for now, its just the bit reservation.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index f182f95caabb..927cb14f24e0 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -38,6 +38,7 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
 #define _DPRINTK_FLAGS_INCL_TID(1<<4)
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
+#define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
 #define _DPRINTK_FLAGS_INCL_ANY\
(_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-- 
2.41.0



[Intel-gfx] [PATCH v7c 07/24] dyndbg: drop NUM_TYPE_ARRAY

2023-10-18 Thread Jim Cromie
ARRAY_SIZE works here, since array decl is complete.

no functional change

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b53217e4b711..8116d0a0d33a 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -106,11 +106,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.41.0



[Intel-gfx] [PATCH v7c 14/24] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression

2023-10-18 Thread Jim Cromie
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".

When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when DRM.debug
categories are enabled.

Worse, it causes the CONFIG_DRM_USE_DYNAMIC_DEBUG=Y regression; 1st
drm.ko loads, and dyndbg initializes its DRM.debug callsites, then a
drm-driver loads, but too late - it missed the DRM.debug enablement.

So replace it with 2 macros:
  DYNDBG_CLASSMAP_DEFINE - invoked once from core - drm.ko
  DYNDBG_CLASSMAP_USE- from all drm drivers and helpers.

DYNDBG_CLASSMAP_DEFINE: based on DECLARE_DYNDBG_CLASSMAP, but now it
drops the static on the constructed classmap variable, and exports it
instead.

DYNDBG_CLASSMAP_USE: then refers to the exported var by name:
* used from drivers, helper-mods
* lets us drop the repetitive "classname" args
* fixes 2nd-defn problem
* creates a ddebug_class_user record in new __dyndbg_class_users section
  this allows ddebug_add_module(etal) to handle them per-module.

The distinction, and the usage record, allows dyndbg to initialize the
driver's DRM.debug callsites separately after it is modprobed.

Since DRM now needs updates to use the new macros, it also gets 2
wrappers: DRM_CLASSMAP_DEFINE, DRM_CLASSMAP_USE which declutter the
users by hiding the ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG.

To review, dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.
. DYNDBG_CLASSMAP_DEFINE(and old one) creates classmaps in this section.

This patch adds __dyndbg_class_users[] section:

. catalogs uses/references to the classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. DYNDBG_CLASSMAP_USE() creates classmap-user records in this section.

Now ddebug_add_module(etal) can handle classmap-uses like (and after)
classmaps; when a dependent module is loaded, its parent's kernel
params are scanned to find the param wired to dyndbg-param-ops, whose
classmap matches the one ref'd by the client.

To support this, theres a few data/header changes:

. new struct ddebug_class_user
  contains: user-module-name, 
  it records drm-driver's use of a classmap in the section, allowing lookup

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_users, num_class_users.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

vmlinux.lds.h: new BOUNDED_SECTION for __dyndbg_class_users

dynamic_debug.c has 2 changes in ddebug_add_module(), ddebug_change():

ddebug_add_module() already calls ddebug_attach_module_classes()
to handle classmaps DEFINEd by a module, now it also calls
ddebug_attach_user_module_classes() to handle USEd classmaps.  To
avoid this work when possible, 1st scan the module's descriptors and
count the number of class'd pr_debugs.

ddebug_attach_user_module_classes() scans the module's class_users
section, follows the refs to the parent's classmap, and calls
ddebug_apply_params() on each.  It also avoids work by checking the
module's class-ct.

ddebug_apply_params(new fn):

It scans module's/builtin kernel-params, calls ddebug_match_apply_kparam
for each to find the params/sysfs-nodes which may be wired to a classmap.

ddebug_match_apply_kparam(new fn):

1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state, and to the classmap defining the param's handling.

2nd, it requires that the classmap ref'd by the kparam is the one
we're called for; modules can use many separate classmaps (as
test_dynamic_debug does).

Then apply the "parent" kparam's setting to the dependent module,
using ddebug_apply_class_bitmap().

ddebug_change(and callees) also gets adjustments:

ddebug_find_valid_class(): This does a search over the module's
classmaps, looking for the class FOO echo'd to >control.  So now it
searches over __dyndbg_class_users[] after __dyndbg_classes[].

ddebug_class_name(): return class-names for defined AND used classes.

test_dynamic_debug.c, test_dynamic_debug_submod.c:

This (already) demonstrates the 2 types of classmaps & sysfs-params,
following the 4-part recipe:

1. define an enum for the classmap: DRM.debug has DRM_UT_{CORE,KMS,...}
   multiple classes must share 0-62 classid space.
2. DYNDBG_CLASSMAP_DEFINE(.. DRM_UT_{CORE,KMS,...})
3. DYNDBG_CLASSMAP_PARAM* (classmap)
4. DYNDBG_CLASSMAP_USE()
   by _submod only, skipping 2,3

Move all the enum declarations together, to better explain how they
share the 0..62 class-id space available to a module (non-overlapping
subranges).

reorg macros 2,3 by name.  This gives a tabular format, making it easy
to see the pattern of repetition, and the points of change.

And 

[Intel-gfx] [PATCH v7c 11/24] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap

2023-10-18 Thread Jim Cromie
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn.  Disallow this.
And constify new_bits while here.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8158943b350d..8beb98a831f5 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -593,7 +593,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits,
+const unsigned long *new_bits,
+const unsigned long old_bits,
 const char *query_modname)
 {
 #define QUERY_SIZE 128
@@ -602,12 +603,12 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
-   if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
+   if (test_bit(bi, new_bits) == test_bit(bi, _bits))
continue;
 
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
@@ -619,9 +620,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
return matches;
 }
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
*dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -742,7 +743,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -755,7 +756,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
-- 
2.41.0



[Intel-gfx] [PATCH v7c 15/24] dyndbg: refactor ddebug_classparam_clamp_input

2023-10-18 Thread Jim Cromie
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former.  It takes kernel-param arg, so it can complain
about "foo: bad input".

Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate inputs from parent's params, just like our own.
To support that reuse, alter ddebug_sync_classbits() and caller to
pass kp instead of kp->arg.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 70 ++---
 1 file changed, 47 insertions(+), 23 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c9517d403e06..a6ee142668bf 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -653,6 +653,30 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
+static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct 
kernel_param *kp)
+{
+   const struct ddebug_class_param *dcp = kp->arg;
+   const struct ddebug_class_map *map = dcp->map;
+
+   switch (map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   /* expect bits. mask and warn if too many */
+   if (*inrep & ~CLASSMAP_BITMASK(map->length)) {
+   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
+   KP_NAME(kp), *inrep, 
CLASSMAP_BITMASK(map->length));
+   *inrep &= CLASSMAP_BITMASK(map->length);
+   }
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   /* input is bitpos, of highest verbosity to be enabled */
+   if (*inrep > map->length) {
+   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
+   KP_NAME(kp), *inrep, map->length);
+   *inrep = map->length;
+   }
+   break;
+   }
+}
 static int param_set_dyndbg_module_classes(const char *instr,
   const struct kernel_param *kp,
   const char *modnm)
@@ -671,26 +695,15 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
pr_err("expecting numeric input, not: %s > %s\n", instr, 
KP_NAME(kp));
return -EINVAL;
}
+   ddebug_class_param_clamp_input(, kp);
 
switch (map->map_type) {
case DD_CLASS_TYPE_DISJOINT_BITS:
-   /* expect bits. mask and warn if too many */
-   if (inrep & ~CLASSMAP_BITMASK(map->length)) {
-   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
-   KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
-   inrep &= CLASSMAP_BITMASK(map->length);
-   }
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
-   /* input is bitpos, of highest verbosity to be enabled */
-   if (inrep > map->length) {
-   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
-   KP_NAME(kp), inrep, map->length);
-   inrep = map->length;
-   }
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
@@ -1157,16 +1170,27 @@ static const char * const ddebug_classmap_typenames[] = 
{
  ddebug_classmap_typenames[_cm->map_type]);\
})
 
-static void ddebug_sync_classbits(const struct ddebug_class_param *dcp, const 
char *modname)
+static void ddebug_sync_classbits(const struct kernel_param *kp, const char 
*modname)
 {
-   /* clamp initial bitvec, mask off hi-bits */
-   if (*dcp->bits & ~CLASSMAP_BITMASK(dcp->map->length)) {
-   *dcp->bits &= CLASSMAP_BITMASK(dcp->map->length);
-   v2pr_info("preset classbits: %lx\n", *dcp->bits);
+   struct ddebug_class_param *dcp = kp->arg;
+   unsigned long new_bits;
+
+   ddebug_class_param_clamp_input(dcp->bits, kp);
+
+   switch (dcp->map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   v2pr_info("  %s: classbits: 0x%lx\n", KP_NAME(kp), *dcp->bits);
+   ddebug_apply_class_bitmap(dcp, dcp->bits, 0UL, modname);
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   new_bits = CLASSMAP_BITMASK(*dcp->lvl);
+   v2pr_info("  %s: lvl:%ld bits:0x%lx\n", KP_NAME(kp), *dcp->lvl, 
new_bits);
+   ddebug_apply_class_bitmap(dcp, _bits, 0UL, modname);
+   break;
+   default:
+   

[Intel-gfx] [PATCH v7c 19/24] dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP

2023-10-18 Thread Jim Cromie
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.

When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.

This string (or part of it) could be cached once its 1st generated,
and retrieved thereafter, as long as its deleted any time the
callsite's flags are changed afterwards.

So consider the prefix/decoration flags: 'tmfsl', and what should be
in the cache:

-t  thread-id. not part of the "callsite" info, derived from current.
doesn't belong in the cache. it would be wrong.
can be done in outer: dynamic_emit_prefix()

-l  line number
this could be part of the prefix, but would bloat the cache
can also be done in outer: dynamic_emit_prefix()

-mfs  module, function, source-file
we cache these, composed into a sub-string.
they are "lookups", currently to descriptor fields,
could be accessor macros to "compressed" tables.
cache saves more access work.

All enabled together, they compose a prefix string like:

  # outer   -inner--   outer
  "[tid] module:function:sourcfile:line: "

So this patch extracts _DPRINTK_FLAGS_INCL_LOOKUP macro out of
_DPRINTK_FLAGS_INCL_ANY macro, then redefs latter.

Next re-refactor dynamic_emit_prefix inner/outer fns accordingly.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 927cb14f24e0..2237d454bc19 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -40,10 +40,12 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
 #define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
-#define _DPRINTK_FLAGS_INCL_ANY\
-   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-_DPRINTK_FLAGS_INCL_LINENO  | _DPRINTK_FLAGS_INCL_TID |\
+#define _DPRINTK_FLAGS_INCL_LOOKUP \
+   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |   \
 _DPRINTK_FLAGS_INCL_SOURCENAME)
+#define _DPRINTK_FLAGS_INCL_ANY
\
+   (_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID | \
+_DPRINTK_FLAGS_INCL_LOOKUP)
 
 #if defined DEBUG
 #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
-- 
2.41.0



[Intel-gfx] [PATCH v7c 16/24] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API

2023-10-18 Thread Jim Cromie
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:

1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before

2.DYNDBG_CLASSMAP_PARAM
new user (test_dynamic_debug) doesn't need to share state,
decls a static long unsigned int to store the bitvec.

__DYNDBG_CLASSMAP_PARAM
   bottom layer - allocate,init a ddebug-class-param, module-param-cb.

Also clean up and improve comments in test-code, and add
MODULE_DESCRIPTIONs.

Signed-off-by: Jim Cromie 
---
---
 drivers/gpu/drm/drm_print.c |  8 ++
 include/drm/drm_print.h |  6 ++--
 include/linux/dynamic_debug.h   | 37 +++-
 lib/test_dynamic_debug.c| 50 +
 lib/test_dynamic_debug_submod.c |  9 +-
 5 files changed, 69 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dabcfa0dd279..8f4b609353a5 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS,
"DRM_UT_DP",
"DRM_UT_DRMRES");
 
-static struct ddebug_class_param drm_debug_bitmap = {
-   .bits = &__drm_debug,
-   .flags = "p",
-   .map = _debug_classes,
-};
-module_param_cb(debug, _ops_dyndbg_classes, _debug_bitmap, 0600);
+DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p);
+
 #endif
 
 void __drm_puts_coredump(struct drm_printer *p, const char *str)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 706afc97c79c..94d4f5500030 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -322,11 +322,13 @@ enum drm_debug_category {
 };
 
 #ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
-#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
-#define DRM_CLASSMAP_USE(name)   DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_DEFINE(...)   DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
+#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__)
 #else
 #define DRM_CLASSMAP_DEFINE(...)
 #define DRM_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)
 #endif
 
 static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 1b027be2cdc4..f182f95caabb 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -91,7 +91,7 @@ struct ddebug_class_map {
  * used to validate a "class FOO .." >control command on the module
  */
 #define DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \
-   const char *_var##_classnames[] = { __VA_ARGS__ };  \
+   static const char *_var##_classnames[] = { __VA_ARGS__ };   \
struct ddebug_class_map __aligned(8) __used \
__section("__dyndbg_classes") _var = {  \
.mod = THIS_MODULE, \
@@ -145,6 +145,41 @@ struct ddebug_class_param {
const struct ddebug_class_map *map;
 };
 
+/**
+ * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param
+ * @_name  sysfs node name
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classes defined by the
+ * classmap.  Keeps bits in a private/static
+ */
+#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \
+   static unsigned long _name##_bvec;  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags)
+
+/**
+ * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling 
sys-param
+ * @_name  sysfs node name
+ * @_bits  name of the module's unsigned long bit-vector, ex: __drm_debug
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classmap, keeping bitvec in user 
@_bits.
+ * This lets drm use __drm_debug elsewhere too.
+ */
+#define DYNDBG_CLASSMAP_PARAM_REF(_name, _bits, _var, _flags)  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)
+
+#define __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)\
+   static struct ddebug_class_param _name##_##_flags = {   \
+   .bits = &(_bits),   \
+   .flags = #_flags,   \
+   .map = &(_var), \
+   };  \
+   module_param_cb(_name, _ops_dyndbg_classes,   \
+

[Intel-gfx] [PATCH v7c 13/24] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code

2023-10-18 Thread Jim Cromie
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:

  echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names

The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things for now.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  19 ++-
 lib/dynamic_debug.c   | 103 +++---
 lib/test_dynamic_debug.c  |  26 -
 3 files changed, 12 insertions(+), 136 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8116d0a0d33a..8eaf8eabdc8d 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -61,24 +61,13 @@ struct _ddebug {
 enum class_map_type {
DD_CLASS_TYPE_DISJOINT_BITS,
/**
-* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
-* expecting hex input. Built for drm.debug, basis for other types.
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to 
bits[0..N].
+* Expects hex input. Built for drm.debug, basis for other types.
 */
DD_CLASS_TYPE_LEVEL_NUM,
/**
-* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
-* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
-*/
-   DD_CLASS_TYPE_DISJOINT_NAMES,
-   /**
-* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* classes are independent, like _DISJOINT_BITS.
-*/
-   DD_CLASS_TYPE_LEVEL_NAMES,
-   /**
-* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* intended for names like: INFO,DEBUG,TRACE, with a module prefix
-* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N.
+* Input N turns on bits 0..N-1
 */
 };
 
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45870a699507..91c8b67fd8f8 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -632,77 +632,6 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
-/* accept comma-separated-list of [+-] classnames */
-static int param_set_dyndbg_classnames(const char *instr, const struct 
kernel_param *kp)
-{
-   const struct ddebug_class_param *dcp = kp->arg;
-   const struct ddebug_class_map *map = dcp->map;
-   unsigned long curr_bits, old_bits;
-   char *cl_str, *p, *tmp;
-   int cls_id, totct = 0;
-   bool wanted;
-
-   cl_str = tmp = kstrdup(instr, GFP_KERNEL);
-   p = strchr(cl_str, '\n');
-   if (p)
-   *p = '\0';
-
-   /* start with previously set state-bits, then modify */
-   curr_bits = old_bits = *dcp->bits;
-   vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits);
-
-   for (; cl_str; cl_str = p) {
-   p = strchr(cl_str, ',');
-   if (p)
-   *p++ = '\0';
-
-   if (*cl_str == '-') {
-   wanted = false;
-   cl_str++;
-   } else {
-   wanted = true;
-   if (*cl_str == '+')
-   cl_str++;
-   }
-   cls_id = match_string(map->class_names, map->length, cl_str);
-   if (cls_id < 0) {
-   pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp));
-   continue;
-   }
-
-   /* have one or more valid class_ids of one *_NAMES type */
-   switch (map->map_type) {
-   case DD_CLASS_TYPE_DISJOINT_NAMES:
-   /* the +/- pertains to a single bit */
-   if (test_bit(cls_id, _bits) == wanted) {
-   v3pr_info("no change on %s\n", cl_str);
-   continue;
-   }
-   curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
*dcp->bits, NULL);
-   *dcp->bits = curr_bits;
-   v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
- map->class_names[cls_id]);
-   break;
-   case DD_CLASS_TYPE_LEVEL_NAMES:
-   /* cls_id = N in 0..max. wanted +/- determines N or N-1 
*/
-   old_bits = CLASSMAP_BITMASK(*dcp->lvl);
-   curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
-
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
old_bits, NULL);
-   *dcp->lvl = (cls_id + (wanted ? 1 : 0));
-   v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
- 

[Intel-gfx] [PATCH v7c 12/24] dyndbg: reduce verbose=3 messages in ddebug_add_module

2023-10-18 Thread Jim Cromie
The fn currently says "add-module", then "skipping" if the module has
no prdbgs.  Just check 1st and return quietly.

no functional change

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8beb98a831f5..45870a699507 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1242,11 +1242,10 @@ static int ddebug_add_module(struct _ddebug_info *di, 
const char *modname)
 {
struct ddebug_table *dt;
 
-   v3pr_info("add-module: %s.%d sites\n", modname, di->num_descs);
-   if (!di->num_descs) {
-   v3pr_info(" skip %s\n", modname);
+   if (!di->num_descs)
return 0;
-   }
+
+   v3pr_info("add-module: %s %d sites\n", modname, di->num_descs);
 
dt = kzalloc(sizeof(*dt), GFP_KERNEL);
if (dt == NULL) {
-- 
2.41.0



[Intel-gfx] [PATCH v7c 10/24] dyndbg: tighten ddebug_class_name() 1st arg type

2023-10-18 Thread Jim Cromie
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b07aab422604..8158943b350d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1117,12 +1117,12 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 #define class_in_range(class_id, map)  \
(class_id >= map->base && class_id < map->base + map->length)
 
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map = iter->table->classes;
-   int i, nc = iter->table->num_classes;
+   struct ddebug_class_map *map = dt->classes;
+   int i;
 
-   for (i = 0; i < nc; i++, map++)
+   for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1156,7 +1156,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
 
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
-   class = ddebug_class_name(iter, dp);
+   class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
-- 
2.41.0



[Intel-gfx] [PATCH v7c 08/24] dyndbg: reduce verbose/debug clutter

2023-10-18 Thread Jim Cromie
currently, for verbose=3, these are logged (blank lines for clarity):

 dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
 dyndbg: split into words: "class" "DRM_UT_CORE" "+p"

 dyndbg: op='+'
 dyndbg: flags=0x1
 dyndbg: *flagsp=0x1 *maskp=0x

 dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: no matches for query
 dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: processed 1 queries, with 0 matches, 0 errs

That is excessive, so this patch:
 - shrinks 3 lines of 2nd stanza to single line
 - drops 1st 2 lines of 3rd stanza
   3rd is like 1st, with result, not procedure.
   2nd is just status, retold in 4th, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b67c9b137447..b0e11f6bfaa2 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -266,9 +266,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -497,7 +494,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
-   v3pr_info("op='%c'\n", op);
 
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -511,7 +507,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
return -EINVAL;
}
}
-   v3pr_info("flags=0x%x\n", modifiers->flags);
 
/* calculate final flags, mask based upon op */
switch (op) {
@@ -527,7 +522,7 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
-   v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags, 
modifiers->mask);
+   v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags, 
modifiers->mask);
 
return 0;
 }
@@ -537,7 +532,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -555,10 +550,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(, );
-   vpr_info_dq(, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(, );
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.41.0



[Intel-gfx] [PATCH v7c 09/24] dyndbg: silence debugs with no-change updates

2023-10-18 Thread Jim Cromie
check for actual changes before announcing them, declutter logs.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b0e11f6bfaa2..b07aab422604 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -591,7 +591,7 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
return nfound;
 }
 
-/* apply a new bitmap to the sys-knob's current bit-state */
+/* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
 unsigned long *new_bits, unsigned long 
*old_bits,
 const char *query_modname)
@@ -602,8 +602,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,8 +619,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
return matches;
 }
-- 
2.41.0



[Intel-gfx] [PATCH v7c 06/24] dyndbg: split param_set_dyndbg_classes to module/wrapper fns

2023-10-18 Thread Jim Cromie
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new.  New arg allows caller to specify that only one module
is affected by a prdbgs update.

Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope of changes
made.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ba41fdeaaf98..b67c9b137447 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -708,18 +708,9 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
return 0;
 }
 
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+  const struct kernel_param *kp,
+  const char *modnm)
 {
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -756,8 +747,8 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
-   v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
+   v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -770,7 +761,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -779,6 +770,22 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
 }
+
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+   return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
 EXPORT_SYMBOL(param_set_dyndbg_classes);
 
 /**
-- 
2.41.0



[Intel-gfx] [PATCH v7c 05/24] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it

2023-10-18 Thread Jim Cromie
Add query_module param to ddebug_apply_class_bitmap().  This allows
its caller to update just one module, or all (as currently).  We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a3be2e7c8c84..ba41fdeaaf98 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -601,7 +601,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -609,7 +610,8 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,12 +620,15 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
+
return matches;
 }
 
@@ -679,7 +684,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -689,7 +694,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -752,7 +757,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -765,7 +770,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);

[Intel-gfx] [PATCH v7c 03/24] dyndbg: make ddebug_class_param union members same size

2023-10-18 Thread Jim Cromie
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 2 +-
 lib/dynamic_debug.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 4fcbf4d4fd0a..5231aaf361c4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -124,7 +124,7 @@ struct _ddebug_info {
 struct ddebug_class_param {
union {
unsigned long *bits;
-   unsigned int *lvl;
+   unsigned long *lvl;
};
char flags[8];
const struct ddebug_class_map *map;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ceb3067a5c83..b984ce338921 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -796,7 +796,7 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
 
case DD_CLASS_TYPE_LEVEL_NAMES:
case DD_CLASS_TYPE_LEVEL_NUM:
-   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
+   return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl);
default:
return -1;
}
-- 
2.41.0



[Intel-gfx] [PATCH v7c 02/24] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"

2023-10-18 Thread Jim Cromie
This appears in the control-file to report an unknown class-name, which
indicates that the class_id is not authorized, and dyndbg will ignore
changes to it.  Generally, this means that a DYNDBG_CLASSMAP_DEFINE or
DYNDBG_CLASSMAP_USE is missing.

But the word "unknown" appears in quite a few prdbg formats, so thats
a suboptimal search term to find occurrences of the problem.  Thus
change it to "_UNKNOWN_" which properly shouts the condition.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 6fba6423cc10..ceb3067a5c83 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1151,7 +1151,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
if (class)
seq_printf(m, " class:%s", class);
else
-   seq_printf(m, " class unknown, _id:%d", dp->class_id);
+   seq_printf(m, " class:_UNKNOWN_ _id:%d", dp->class_id);
}
seq_puts(m, "\n");
 
-- 
2.41.0



[Intel-gfx] [PATCH v7c 04/24] dyndbg: replace classmap list with a vector

2023-10-18 Thread Jim Cromie
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list-head link.

struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

no functional changes

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 5231aaf361c4..b53217e4b711 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -83,7 +83,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b984ce338921..a3be2e7c8c84 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -147,13 +148,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, >maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -164,7 +167,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -,9 +1113,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, >table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1197,30 +1200,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section.  Save the start
+* and length of the subrange 

[Intel-gfx] [PATCH v7c 01/24] test-dyndbg: fixup CLASSMAP usage error

2023-10-18 Thread Jim Cromie
more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  I intentionally coded in an error, but
forgot to verify its detection and remove it.

RFC:

This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone.  As noted in test-mod comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__.  Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.

[1] name changes later to DYNDBG_CLASSMAP_DEFINE

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.41.0



[Intel-gfx] [PATCH v7c 00/24] fix DRM_USE_DYNAMIC_DEBUG=y regression

2023-10-18 Thread Jim Cromie


hi Jason, DRM-folk

(v7c now with all checkpatch fixes)

This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.

The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K rule:
"define once, refer many".  In patch 14 it is replaced by:

 DYNDBG_CLASSMAP_DEFINE - define and export a struct ddebug_class_map
 DYNDBG_CLASSMAP_USE - ref the exported struct

test-dynamic-debug is also extended with a -submod.ko, in order to
recapitulate the drm & drivers initialization scenario.

They're on v6.6-rc6 now, and recently applied cleanly to drm-tip/drm-tip.

Ive been running recent revs on rc3+, on my desktop and laptop.

The final blocker was a missing __align(8) on the ddebug_class_user
record inserted by DYNDBG_CLASSMAP_USE.  This caused DRM=y (builtin
only) to have a corrupt record for drm_kms_helper (a builtin dependent).
Curiously, a clang build did not exhibit this problem.

Heres a part of dmesg, for a DRM=y kernel, booted with
 dynamic_debug.verbose=3 drm.debug=0x10

[0.466747] dyndbg: add-module: drm 406 sites
[0.467569] dyndbg: classes[0]: module:drm base:0 len:10 type:DISJOINT_BITS
[0.467743] dyndbg: module:drm attached 1 classes
[0.468557] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.468742] dyndbg:  found kp:drm.debug =0x10
[0.468743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.469742] dyndbg:   drm.debug: classbits: 0x10
[0.470573] dyndbg: apply bitmap: 0x10 to: 0x0 for drm
[0.470743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm
[0.471743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.472743] dyndbg: op='+' flags=0x1 maskp=0x
[0.473679] dyndbg: parsed: func="" file="" module="drm" format="" 
lineno=0-0 class=DRM_UT_ATOMIC
[0.473749] dyndbg: processed 1 queries, with 0 matches, 0 errs
[0.474742] dyndbg: bit_4: 0 matches on class: DRM_UT_ATOMIC -> 0x10
[0.475742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm
[0.476686] dyndbg: 406 debug prints in module drm
[0.476743] dyndbg: add-module: drm_kms_helper 93 sites
[0.477727] dyndbg: class_ref[0] drm_kms_helper -> drm module:drm base:0 
len:10 type:DISJOINT_BITS
[0.477743] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.478742] dyndbg:  found kp:drm.debug =0x10
[0.478743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.479743] dyndbg:   drm.debug: classbits: 0x10
[0.480592] dyndbg: apply bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.480743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm_kms_helper
[0.481743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.482743] dyndbg: op='+' flags=0x1 maskp=0x
[0.483743] dyndbg: parsed: func="" file="" module="drm_kms_helper" 
format="" lineno=0-0 class=DRM_UT_ATOMIC
[0.484750] dyndbg: class-ref: drm_kms_helper.DRM_UT_ATOMIC  
module:drm_kms_helper nd:93 nc:0 nu:1
[0.485809] dyndbg: processed 1 queries, with 44 matches, 0 errs
[0.486742] dyndbg: bit_4: 44 matches on class: DRM_UT_ATOMIC -> 0x10
[0.487742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.488743] dyndbg: attach-client-module:  module:drm_kms_helper nd:93 nc:0 
nu:1
[0.489742] dyndbg:  93 debug prints in module drm_kms_helper

Widespread testing is appreciated.
I have scripts if anyone wants them.
lkp-robot reported success on dd-fix-7b, no report yet on 7c

Patches are also at https://github.com/jimc/linux/tree/dd-fix-7c

Jim Cromie (24):
  test-dyndbg: fixup CLASSMAP usage error
  dyndbg: reword "class unknown," to "class:_UNKNOWN_"
  dyndbg: make ddebug_class_param union members same size
  dyndbg: replace classmap list with a vector
  dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
  dyndbg: split param_set_dyndbg_classes to module/wrapper fns
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg: silence debugs with no-change updates
  dyndbg: tighten ddebug_class_name() 1st arg type
  dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
  dyndbg: reduce verbose=3 messages in ddebug_add_module
  dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
  dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
  dyndbg: refactor ddebug_classparam_clamp_input
  dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
  dyndbg-doc: add classmap info to howto
  dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
  dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
  dyndbg: refactor *dynamic_emit_prefix
  dyndbg: change WARN_ON to WARN_ON_ONCE
  drm: use correct ccflags-y spelling
  drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
  drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

 .../admin-guide/dynamic-debug-howto.rst   |  60 ++-
 MAINTAINERS   |   2 +-
 drivers/gpu/drm/Kconfig   |   3 +-
 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 (rev5)

2023-10-18 Thread Andi Shyti
Hi Vinay,

> Possible regressions
> 
>   • igt@gem_exec_nop@basic-series:
> 
>   □ shard-glk: PASS -> INCOMPLETE +1 other test incomplete
>   • igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
> 
>   □ shard-dg2: PASS -> TIMEOUT
>   • igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-1:
> 
>   □ shard-tglu: PASS -> INCOMPLETE
>   • igt@kms_psr@psr2_suspend:
> 
>   □ shard-mtlp: NOTRUN -> FAIL

these failures look unrelated and besides they are not related to
MTL.

Andi


Re: [Intel-gfx] [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against CT-loss

2023-10-18 Thread Gupta, Anshuman



> -Original Message-
> From: Teres Alexis, Alan Previn 
> Sent: Saturday, October 14, 2023 6:34 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Vivi, Rodrigo ; Ceraolo
> Spurio, Daniele ; Harrison, John C
> ; Gupta, Anshuman
> ; Ursulin, Tvrtko ;
> Jana, Mousumi 
> Subject: [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against
> CT-loss
> 
> If we are at the end of suspend or very early in resume its possible an async
> fence signal (via rcu_call) is triggered to free_engines which could lead us 
> to
> the execution of the context destruction worker (after a prior worker flush).
> 
> Thus, when suspending, insert rcu_barriers at the start of i915_gem_suspend
> (part of driver's suspend prepare) and again in i915_gem_suspend_late so
> that all such cases have completed and context destruction list isn't missing
> anything.
Acked-by: Anshuman Gupta 
For rcu barrier usage.
> 
> In destroyed_worker_func, close the race against CT-loss by checking that CT 
> is
> enabled before calling into deregister_destroyed_contexts.
> 
> Based on testing, guc_lrc_desc_unpin may still race and fail as we traverse 
> the
> GuC's context-destroy list because the CT could be disabled right before 
> calling
> GuC's CT send function.
> 
> We've witnessed this race condition once every ~6000-8000 suspend-resume
> cycles while ensuring workloads that render something onscreen is
> continuously started just before we suspend (and the workload is small
> enough to complete and trigger the queued engine/context free-up either
> very late in suspend or very early in resume).
> 
> In such a case, we need to unroll the entire process because guc-lrc-unpin
> takes a gt wakeref which only gets released in the G2H IRQ reply that never
> comes through in this corner case. Without the unroll, the taken wakeref is
> leaked and will cascade into a kernel hang later at the tail end of suspend 
> in this
> function:
> 
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
> 
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_- contexts
> if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so it can get 
> picked
> up on the next destroy worker invocation (if suspend aborted) or get fully
> purged as part of a GuC sanitization (end of suspend) or a reset flow.
> 
> Signed-off-by: Alan Previn 
> Signed-off-by: Anshuman Gupta 
> Tested-by: Mousumi Jana 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ---
>  2 files changed, 80 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private
> *i915)
>   GEM_TRACE("%s\n", dev_name(i915->drm.dev));
> 
>   intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> +  * On rare occasions, we've observed the fence completion triggers
> +  * free_engines asynchronously via rcu_call. Ensure those are done.
> +  * This path is only called on suspend, so it's an acceptable cost.
> +  */
> + rcu_barrier();
> +
>   flush_workqueue(i915->wq);
> 
>   /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct
> drm_i915_private *i915)
>* machine in an unusable condition.
>*/
> 
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
>   for_each_gt(gt, i915, i)
>   intel_gt_suspend_late(gt);
> 
> 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 a5b68f77e494..9806b33c8561 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -235,6 +235,13 @@ set_context_destroyed(struct intel_context *ce)
>   ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;  }
> 
> +static inline void
> +clr_context_destroyed(struct intel_context *ce) {
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED; }
> +
>  static inline bool context_pending_disable(struct intel_context *ce)  {
>   return ce->guc_state.sched_state &
> SCHED_STATE_PENDING_DISABLE; @@ -612,6 +619,8 @@ static int
> guc_submission_send_busy_loop(struct intel_guc *guc,
>u32 g2h_len_dw,
>bool loop)
>  {
> + int ret;
> +
>   /*
>* We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
>* so we don't handle the case where we don't get a reply because we

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c

2023-10-18 Thread Zhao Liu
Hi Rodrigo and Tvrtko,

It seems this series is missed in v6.5.
This work should not be forgotten. Let me rebase and refresh the version.

Regards,
Zhao

On Mon, Apr 17, 2023 at 10:53:28AM -0400, Rodrigo Vivi wrote:
> Date: Mon, 17 Apr 2023 10:53:28 -0400
> From: Rodrigo Vivi 
> Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in
>  gem/i915_gem_execbuffer.c
> 
> On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin wrote:
> > 
> > On 14/04/2023 11:45, Zhao Liu wrote:
> > > Hi Tvrtko,
> > > 
> > > On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > [snip]
> > > 
> > > > > 
> > > > > [snip]
> > > > > > However I am unsure if disabling pagefaulting is needed or not. 
> > > > > > Thomas,
> > > > > > Matt, being the last to touch this area, perhaps you could have a 
> > > > > > look?
> > > > > > Because I notice we have a fallback iomap path which still uses
> > > > > > io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local 
> > > > > > conversion is
> > > > > > safe, does the iomap side also needs converting to
> > > > > > io_mapping_map_local_wc? Or they have separate requirements?
> > > > > 
> > > > > AFAIK, the requirements for io_mapping_map_local_wc() are the same as 
> > > > > for
> > > > > kmap_local_page(): the kernel virtual address is _only_ valid in the 
> > > > > caller
> > > > > context, and map/unmap nesting must be done in stack-based ordering 
> > > > > (LIFO).
> > > > > 
> > > > > I think a follow up patch could safely switch to 
> > > > > io_mapping_map_local_wc() /
> > > > > io_mapping_unmap_local_wc since the address is local to context.
> > > > > 
> > > > > However, not being an expert, reading your note now I suspect that 
> > > > > I'm missing
> > > > > something. Can I ask why you think that page-faults disabling might be
> > > > > necessary?
> > > > 
> > > > I am not saying it is, was just unsure and wanted some people who 
> > > > worked on this code most recently to take a look and confirm.
> > > > 
> > > > I guess it will work since the copying is done like this anyway:
> > > > 
> > > > /*
> > > >  * This is the fast path and we cannot handle a 
> > > > pagefault
> > > >  * whilst holding the struct mutex lest the user pass 
> > > > in the
> > > >  * relocations contained within a mmaped bo. For in 
> > > > such a case
> > > >  * we, the page fault handler would call 
> > > > i915_gem_fault() and
> > > >  * we would try to acquire the struct mutex again. 
> > > > Obviously
> > > >  * this is bad and so lockdep complains vehemently.
> > > >  */
> > > > pagefault_disable();
> > > > copied = __copy_from_user_inatomic(r, urelocs, count * 
> > > > sizeof(r[0]));
> > > > pagefault_enable();
> > > > if (unlikely(copied)) {
> > > > remain = -EFAULT;
> > > > goto out;
> > > > }
> > > > 
> > > > Comment is a bit outdated since we don't use that global "struct mutex" 
> > > > any longer, but in any case, if there is a page fault on the mapping 
> > > > where we need to recurse into i915 again to satisfy if, we seem to have 
> > > > code already to handle it. So kmap_local conversion I *think* can't 
> > > > regress anything.
> > > 
> > > Thanks for your explanation!
> > > 
> > > > 
> > > > Patch to convert the io_mapping_map_atomic_wc can indeed come later.
> > > 
> > > Okay, I will also look at this.
> > > 
> > > > 
> > > > In terms of logistics - if we landed this series to out branch it would 
> > > > be queued only for 6.5. Would that work for you?
> > > 
> > > Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
> > 
> > Yes, but just because we failed to review and merge in time, not because you
> > did not provide patches in time.
> 
> It is worth mentioning that under drm we close the merge window earlier.
> Around -rc5.
> 
> So, Linus' merge window for 6.4 didn't happen yet. But our drm-next that
> is going to be sent there is already closed.
> 
> > 
> > Regards,
> > 
> > Tvrtko
> > 


[Intel-gfx] [PATCH 4/4] drm/i915/mst: Always write CHICKEN_TRANS

2023-10-18 Thread Ville Syrjala
From: Ville Syrjälä 

Since we're asked to disable FECSTALL_DIS_DPTSTREAM_DPTTG when
the transcoder is disabled it seems prudent to also clear it
when enabliing the transcoder w/o FEC, just in case
someone else left it enabled by mistake.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3c66a3e3cc5e..38ad81d3bbe6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -817,12 +817,14 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
drm_dp_add_payload_part2(_dp->mst_mgr, >base,
 drm_atomic_get_mst_payload_state(mst_state, 
connector->port));
 
-   if (DISPLAY_VER(dev_priv) >= 14 && pipe_config->fec_enable)
-   intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(trans), 0,
-FECSTALL_DIS_DPTSTREAM_DPTTG);
-   else if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
-   intel_de_rmw(dev_priv, CHICKEN_TRANS(trans), 0,
-FECSTALL_DIS_DPTSTREAM_DPTTG);
+   if (DISPLAY_VER(dev_priv) >= 14)
+   intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(trans),
+FECSTALL_DIS_DPTSTREAM_DPTTG,
+pipe_config->fec_enable ? 
FECSTALL_DIS_DPTSTREAM_DPTTG : 0);
+   else if (DISPLAY_VER(dev_priv) >= 12)
+   intel_de_rmw(dev_priv, CHICKEN_TRANS(trans),
+FECSTALL_DIS_DPTSTREAM_DPTTG,
+pipe_config->fec_enable ? 
FECSTALL_DIS_DPTSTREAM_DPTTG : 0);
 
intel_audio_sdp_split_update(pipe_config);
 
-- 
2.41.0



[Intel-gfx] [PATCH 3/4] drm/i915/mst: Clear ACT just before triggering payload allocation

2023-10-18 Thread Ville Syrjala
From: Ville Syrjälä 

Follow the bspec sequqnece more closely and clear ACT sent just
before triggering the allocation. Can't see why we'd want to
deviate from the spec sequence here.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 57eb581b8a50..3c66a3e3cc5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -791,8 +791,6 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
drm_WARN_ON(_priv->drm, pipe_config->has_pch_encoder);
 
-   clear_act_sent(encoder, pipe_config);
-
if (intel_dp_is_uhbr(pipe_config)) {
const struct drm_display_mode *adjusted_mode =
_config->hw.adjusted_mode;
@@ -806,6 +804,8 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
intel_ddi_enable_transcoder_func(encoder, pipe_config);
 
+   clear_act_sent(encoder, pipe_config);
+
intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(trans), 0,
 TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
 
-- 
2.41.0



[Intel-gfx] [PATCH 2/4] drm/i915/mst: Disable transcoder before deleting the payload

2023-10-18 Thread Ville Syrjala
From: Ville Syrjälä 

Bspec tells us that we should disable the transcoder before
deleting the payload. Looks like this has been reversed since
MST support was added.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 7b4628f4f124..57eb581b8a50 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -587,10 +587,6 @@ static void intel_mst_disable_dp(struct intel_atomic_state 
*state,
struct intel_dp *intel_dp = _port->dp;
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
-   struct drm_dp_mst_topology_state *new_mst_state =
-   drm_atomic_get_new_mst_topology_state(>base, 
_dp->mst_mgr);
-   struct drm_dp_mst_atomic_payload *new_payload =
-   drm_atomic_get_mst_payload_state(new_mst_state, 
connector->port);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
 
drm_dbg_kms(>drm, "active links %d\n",
@@ -598,8 +594,6 @@ static void intel_mst_disable_dp(struct intel_atomic_state 
*state,
 
intel_hdcp_disable(intel_mst->connector);
 
-   drm_dp_remove_payload_part1(_dp->mst_mgr, new_mst_state, 
new_payload);
-
intel_audio_codec_disable(encoder, old_crtc_state, old_conn_state);
 }
 
@@ -634,6 +628,8 @@ static void intel_mst_post_disable_dp(struct 
intel_atomic_state *state,
 
intel_disable_transcoder(old_crtc_state);
 
+   drm_dp_remove_payload_part1(_dp->mst_mgr, new_mst_state, 
new_payload);
+
clear_act_sent(encoder, old_crtc_state);
 
intel_de_rmw(dev_priv, 
TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
-- 
2.41.0



[Intel-gfx] [PATCH 1/4] drm/i915/mst: Swap TRANSCONF vs. FECSTALL_DIS_DPTSTREAM_DPTTG disable

2023-10-18 Thread Ville Syrjala
From: Ville Syrjälä 

The DP modeset sequence asks us to disable TRANSCONF before clearing
the FECSTALL_DIS_DPTSTREAM_DPTTG bit, although we are still asked
to wait for the transcoder to stop only after both steps have
been done.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 28d85e1e858e..a994fc2319a3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -485,6 +485,8 @@ void intel_disable_transcoder(const struct intel_crtc_state 
*old_crtc_state)
if (!IS_I830(dev_priv))
val &= ~TRANSCONF_ENABLE;
 
+   intel_de_write(dev_priv, reg, val);
+
if (DISPLAY_VER(dev_priv) >= 14)
intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(cpu_transcoder),
 FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
@@ -492,7 +494,6 @@ void intel_disable_transcoder(const struct intel_crtc_state 
*old_crtc_state)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder),
 FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
 
-   intel_de_write(dev_priv, reg, val);
if ((val & TRANSCONF_ENABLE) == 0)
intel_wait_for_pipe_off(old_crtc_state);
 }
-- 
2.41.0



[Intel-gfx] [PATCH 0/4] drm/i915/mst: MST modeset sequence fixes

2023-10-18 Thread Ville Syrjala
From: Ville Syrjälä 

Fixes for issues I noticed while perusing the MST modeset sequence.

Ville Syrjälä (4):
  drm/i915/mst: Swap TRANSCONF vs. FECSTALL_DIS_DPTSTREAM_DPTTG disable
  drm/i915/mst: Disable transcoder before deleting the payload
  drm/i915/mst: Clear ACT just before triggering payload allocation
  drm/i915/mst: Always write CHICKEN_TRANS

 drivers/gpu/drm/i915/display/intel_display.c |  3 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c  | 26 +---
 2 files changed, 14 insertions(+), 15 deletions(-)

-- 
2.41.0



Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Ville Syrjälä
On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:
> We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
> implementation. Lets drop i915_sw_fence usage from display code and
> use dma_fence interfaces directly.
> 
> For this purpose stack dma fences from related objects into old and new
> plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
> stacked fences during atomic commit.
> 
> There is no be need for separate GPU reset handling in
> intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
> detected and GPU is being reset.
> 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: José Roberto de Souza 
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
>  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
>  .../drm/i915/display/intel_display_types.h|  2 -
>  4 files changed, 37 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 5d18145da279..ec0d5168b503 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
> *_state)
>  
>   drm_atomic_state_default_release(>base);
>   kfree(state->global_objs);
> -
> - i915_sw_fence_fini(>commit_ready);
> -
>   kfree(state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index b1074350616c..d4f9168ec42c 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -32,6 +32,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>   struct intel_atomic_state *state =
>   to_intel_atomic_state(new_plane_state->uapi.state);
>   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct intel_plane_state *old_plane_state =
> + struct intel_plane_state *old_plane_state =
>   intel_atomic_get_old_plane_state(state, plane);
>   struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
>   struct drm_i915_gem_object *old_obj = 
> intel_fb_obj(old_plane_state->hw.fb);
> @@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>* This should only fail upon a hung GPU, in which case we
>* can safely continue.
>*/
> - if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
> {
> - ret = 
> i915_sw_fence_await_reservation(>commit_ready,
> -   
> old_obj->base.resv,
> -   false, 0,
> -   GFP_KERNEL);
> + if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
> &&
> + !dma_resv_test_signaled(old_obj->base.resv,
> + dma_resv_usage_rw(false))) {
> + ret = drm_gem_plane_helper_prepare_fb(_plane, 
> _plane_state->uapi);

This I think is broken. The old plane state and its fence can still be
in use by the previous commit, so we cannot mutate it here. Thus we
really need to get the implicit fence from the old fb chained into the
new plane state's fence.

>   if (ret < 0)
>   return ret;
>   }
>   }
>  
> - if (new_plane_state->uapi.fence) { /* explicit fencing */
> - i915_gem_fence_wait_priority(new_plane_state->uapi.fence,
> -  );
> - ret = i915_sw_fence_await_dma_fence(>commit_ready,
> - new_plane_state->uapi.fence,
> - 
> i915_fence_timeout(dev_priv),
> - GFP_KERNEL);
> - if (ret < 0)
> - return ret;
> - }
> -
>   if (!obj)
>   return 0;
>  
> -
>   ret = intel_plane_pin_fb(new_plane_state);
>   if (ret)
>   return ret;
>  
> - i915_gem_object_wait_priority(obj, 0, );
> -
> - if (!new_plane_state->uapi.fence) { /* implicit fencing */
> - struct dma_resv_iter cursor;
> - struct dma_fence *fence;
> + ret = drm_gem_plane_helper_prepare_fb(_plane, _plane_state->uapi);
> + if (ret < 0)
> + goto unpin_fb;
>  
> - ret = i915_sw_fence_await_reservation(>commit_ready,
> -   obj->base.resv, false,
> -  

Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Ville Syrjälä
On Wed, Oct 18, 2023 at 05:23:00PM +0200, Maarten Lankhorst wrote:
> 
> 
> On 2023-10-18 17:19, Ville Syrjälä wrote:
> > On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:
> >> We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
> >> implementation. Lets drop i915_sw_fence usage from display code and
> >> use dma_fence interfaces directly.
> >>
> >> For this purpose stack dma fences from related objects into old and new
> >> plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
> >> stacked fences during atomic commit.
> >>
> >> There is no be need for separate GPU reset handling in
> >> intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
> >> detected and GPU is being reset.
> >>
> >> Cc: Ville Syrjälä 
> >> Cc: Maarten Lankhorst 
> >> Cc: José Roberto de Souza 
> >>
> >> Signed-off-by: Jouni Högander 
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
> >>   .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
> >>   drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
> >>   .../drm/i915/display/intel_display_types.h|  2 -
> >>   4 files changed, 37 insertions(+), 95 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> >> b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> index 5d18145da279..ec0d5168b503 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
> >> *_state)
> >>   
> >>drm_atomic_state_default_release(>base);
> >>kfree(state->global_objs);
> >> -
> >> -  i915_sw_fence_fini(>commit_ready);
> >> -
> >>kfree(state);
> >>   }
> >>   
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> >> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> index b1074350616c..d4f9168ec42c 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >> @@ -32,6 +32,7 @@
> >>*/
> >>   
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   
> >> @@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> >>struct intel_atomic_state *state =
> >>to_intel_atomic_state(new_plane_state->uapi.state);
> >>struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> >> -  const struct intel_plane_state *old_plane_state =
> >> +  struct intel_plane_state *old_plane_state =
> >>intel_atomic_get_old_plane_state(state, plane);
> >>struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
> >>struct drm_i915_gem_object *old_obj = 
> >> intel_fb_obj(old_plane_state->hw.fb);
> >> @@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> >> * This should only fail upon a hung GPU, in which case we
> >> * can safely continue.
> >> */
> >> -  if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
> >> {
> >> -  ret = 
> >> i915_sw_fence_await_reservation(>commit_ready,
> >> -
> >> old_obj->base.resv,
> >> -false, 0,
> >> -GFP_KERNEL);
> >> +  if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
> >> &&
> >> +  !dma_resv_test_signaled(old_obj->base.resv,
> >> +  dma_resv_usage_rw(false))) {
> >> +  ret = drm_gem_plane_helper_prepare_fb(_plane, 
> >> _plane_state->uapi);
> >>if (ret < 0)
> >>return ret;
> >>}
> >>}
> >>   
> >> -  if (new_plane_state->uapi.fence) { /* explicit fencing */
> >> -  i915_gem_fence_wait_priority(new_plane_state->uapi.fence,
> >> -   );
> >> -  ret = i915_sw_fence_await_dma_fence(>commit_ready,
> >> -  new_plane_state->uapi.fence,
> >> -  
> >> i915_fence_timeout(dev_priv),
> >> -  GFP_KERNEL);
> >> -  if (ret < 0)
> >> -  return ret;
> >> -  }
> >> -
> >>if (!obj)
> >>return 0;
> >>   
> >> -
> >>ret = intel_plane_pin_fb(new_plane_state);
> >>if (ret)
> >>return ret;
> >>   
> >> -  i915_gem_object_wait_priority(obj, 0, );
> >> -
> >> -  if (!new_plane_state->uapi.fence) { /* implicit fencing */
> >> -  struct dma_resv_iter cursor;
> >> -  struct dma_fence *fence;
> >> +  ret = drm_gem_plane_helper_prepare_fb(_plane, _plane_state->uapi);
> > 
> > I don't think we can use that as is due to bigjoiner stuff.
> > I think we'd need a slightly lower level variant that takes
> 

Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Maarten Lankhorst




On 2023-10-18 17:19, Ville Syrjälä wrote:

On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:

We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
implementation. Lets drop i915_sw_fence usage from display code and
use dma_fence interfaces directly.

For this purpose stack dma fences from related objects into old and new
plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
stacked fences during atomic commit.

There is no be need for separate GPU reset handling in
intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
detected and GPU is being reset.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: José Roberto de Souza 

Signed-off-by: Jouni Högander 
---
  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
  .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
  .../drm/i915/display/intel_display_types.h|  2 -
  4 files changed, 37 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 5d18145da279..ec0d5168b503 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
*_state)
  
  	drm_atomic_state_default_release(>base);

kfree(state->global_objs);
-
-   i915_sw_fence_fini(>commit_ready);
-
kfree(state);
  }
  
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c

index b1074350616c..d4f9168ec42c 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -32,6 +32,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,

struct intel_atomic_state *state =
to_intel_atomic_state(new_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-   const struct intel_plane_state *old_plane_state =
+   struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
struct drm_i915_gem_object *old_obj = 
intel_fb_obj(old_plane_state->hw.fb);
@@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * This should only fail upon a hung GPU, in which case we
 * can safely continue.
 */
-   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
{
-   ret = 
i915_sw_fence_await_reservation(>commit_ready,
- 
old_obj->base.resv,
- false, 0,
- GFP_KERNEL);
+   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
&&
+   !dma_resv_test_signaled(old_obj->base.resv,
+   dma_resv_usage_rw(false))) {
+   ret = drm_gem_plane_helper_prepare_fb(_plane, 
_plane_state->uapi);
if (ret < 0)
return ret;
}
}
  
-	if (new_plane_state->uapi.fence) { /* explicit fencing */

-   i915_gem_fence_wait_priority(new_plane_state->uapi.fence,
-);
-   ret = i915_sw_fence_await_dma_fence(>commit_ready,
-   new_plane_state->uapi.fence,
-   
i915_fence_timeout(dev_priv),
-   GFP_KERNEL);
-   if (ret < 0)
-   return ret;
-   }
-
if (!obj)
return 0;
  
-

ret = intel_plane_pin_fb(new_plane_state);
if (ret)
return ret;
  
-	i915_gem_object_wait_priority(obj, 0, );

-
-   if (!new_plane_state->uapi.fence) { /* implicit fencing */
-   struct dma_resv_iter cursor;
-   struct dma_fence *fence;
+   ret = drm_gem_plane_helper_prepare_fb(_plane, _plane_state->uapi);


I don't think we can use that as is due to bigjoiner stuff.
I think we'd need a slightly lower level variant that takes
the fb+fence in explicitly instead of the full plane state.

And I suppose we already have a slight bug here where only the
master pipe's plane will consult the explicit fence and the rest
will take the implicit sync path.
Why would bigjoiner fail? If bigjoiner happens, the uapi fb will be 
fenced at least once.


Cheers,
~Maarten


Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Ville Syrjälä
On Mon, Oct 16, 2023 at 11:08:03AM +0300, Jouni Högander wrote:
> We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
> implementation. Lets drop i915_sw_fence usage from display code and
> use dma_fence interfaces directly.
> 
> For this purpose stack dma fences from related objects into old and new
> plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
> stacked fences during atomic commit.
> 
> There is no be need for separate GPU reset handling in
> intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
> detected and GPU is being reset.
> 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: José Roberto de Souza 
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
>  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
>  .../drm/i915/display/intel_display_types.h|  2 -
>  4 files changed, 37 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 5d18145da279..ec0d5168b503 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
> *_state)
>  
>   drm_atomic_state_default_release(>base);
>   kfree(state->global_objs);
> -
> - i915_sw_fence_fini(>commit_ready);
> -
>   kfree(state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index b1074350616c..d4f9168ec42c 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -32,6 +32,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>   struct intel_atomic_state *state =
>   to_intel_atomic_state(new_plane_state->uapi.state);
>   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct intel_plane_state *old_plane_state =
> + struct intel_plane_state *old_plane_state =
>   intel_atomic_get_old_plane_state(state, plane);
>   struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
>   struct drm_i915_gem_object *old_obj = 
> intel_fb_obj(old_plane_state->hw.fb);
> @@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>* This should only fail upon a hung GPU, in which case we
>* can safely continue.
>*/
> - if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
> {
> - ret = 
> i915_sw_fence_await_reservation(>commit_ready,
> -   
> old_obj->base.resv,
> -   false, 0,
> -   GFP_KERNEL);
> + if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
> &&
> + !dma_resv_test_signaled(old_obj->base.resv,
> + dma_resv_usage_rw(false))) {
> + ret = drm_gem_plane_helper_prepare_fb(_plane, 
> _plane_state->uapi);
>   if (ret < 0)
>   return ret;
>   }
>   }
>  
> - if (new_plane_state->uapi.fence) { /* explicit fencing */
> - i915_gem_fence_wait_priority(new_plane_state->uapi.fence,
> -  );
> - ret = i915_sw_fence_await_dma_fence(>commit_ready,
> - new_plane_state->uapi.fence,
> - 
> i915_fence_timeout(dev_priv),
> - GFP_KERNEL);
> - if (ret < 0)
> - return ret;
> - }
> -
>   if (!obj)
>   return 0;
>  
> -
>   ret = intel_plane_pin_fb(new_plane_state);
>   if (ret)
>   return ret;
>  
> - i915_gem_object_wait_priority(obj, 0, );
> -
> - if (!new_plane_state->uapi.fence) { /* implicit fencing */
> - struct dma_resv_iter cursor;
> - struct dma_fence *fence;
> + ret = drm_gem_plane_helper_prepare_fb(_plane, _plane_state->uapi);

I don't think we can use that as is due to bigjoiner stuff.
I think we'd need a slightly lower level variant that takes
the fb+fence in explicitly instead of the full plane state.

And I suppose we already have a slight bug here where only the
master pipe's plane will consult the explicit fence and the rest
will take the implicit sync path.

> + if (ret < 0)
> + goto unpin_fb;
>  
> - ret = 

Re: [Intel-gfx] [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Nirmoy Das



On 10/18/2023 3:00 PM, Andi Shyti wrote:

Hi Nirmoy,


gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
there are no reference in HW docs that forces us to use this on non-WC
backed GGTT.

This can also cause unwanted side-effects on XE_HP platforms where
GFX_FLSH_CNTL_GEN6 is not valid anymore.

v2: Add a func to detect wc ggtt detection (Ville)
v3: Improve commit log and add reference commit (Daniel)

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")

I'm wondering if this is the right Fixes, though. Should this
rather be:

Fixes: 6266992cf105 ("drm/i915/gt: remove GRAPHICS_VER == 10")

Hard to find a real Fixes for this. I just want to backport this to dg2
where we can have unwanted side-effects.

yes, this piece of code has moved around enough so to make it
diffuclt to track its origin.

I think the one I found should be the correct one,


That just removes a graphics ver, not related to WC GGTT map or XE_HP.


  but the dg2
force probe removeal can also become a placeholder for DG2 fixes.


Yes, I have no better ideas too.


Regards,

Nirmoy



I won't complain.

Andi


Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

2023-10-18 Thread Hans de Goede
Hi Sean,

On 10/17/23 11:17, Sean Young wrote:
> Some drivers require sleeping, for example if the pwm device is connected
> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
> with the generated IR signal when sleeping occurs.
> 
> This patch makes it possible to use pwm when the driver does not sleep,
> by introducing the pwm_can_sleep() function.
> 
> Signed-off-by: Sean Young 

I have no objection to this patch by itself, but it seems a bit
of unnecessary churn to change all current callers of pwm_apply_state()
to a new API.

Why not just keep pwm_apply_state() as is and introduce a new
pwm_apply_state_atomic() for callers which want to apply state
in a case where sleeping is not allowed ?

Regards,

Hans



> ---
>  Documentation/driver-api/pwm.rst  | 16 +++-
>  .../gpu/drm/i915/display/intel_backlight.c|  6 +-
>  drivers/gpu/drm/solomon/ssd130x.c |  2 +-
>  drivers/hwmon/pwm-fan.c   |  8 +-
>  drivers/input/misc/da7280.c   |  4 +-
>  drivers/input/misc/pwm-beeper.c   |  4 +-
>  drivers/input/misc/pwm-vibra.c|  8 +-
>  drivers/leds/leds-pwm.c   |  2 +-
>  drivers/leds/rgb/leds-pwm-multicolor.c|  4 +-
>  drivers/media/rc/pwm-ir-tx.c  |  4 +-
>  drivers/platform/x86/lenovo-yogabook.c|  2 +-
>  drivers/pwm/core.c| 75 ++-
>  drivers/pwm/pwm-renesas-tpu.c |  1 -
>  drivers/pwm/pwm-twl-led.c |  2 +-
>  drivers/pwm/pwm-vt8500.c  |  2 +-
>  drivers/pwm/sysfs.c   | 10 +--
>  drivers/regulator/pwm-regulator.c |  4 +-
>  drivers/video/backlight/lm3630a_bl.c  |  2 +-
>  drivers/video/backlight/lp855x_bl.c   |  2 +-
>  drivers/video/backlight/pwm_bl.c  |  6 +-
>  drivers/video/fbdev/ssd1307fb.c   |  2 +-
>  include/linux/pwm.h   | 57 ++
>  22 files changed, 147 insertions(+), 76 deletions(-)
> 
> diff --git a/Documentation/driver-api/pwm.rst 
> b/Documentation/driver-api/pwm.rst
> index 3fdc95f7a1d15..a2fb5f8f6e1f8 100644
> --- a/Documentation/driver-api/pwm.rst
> +++ b/Documentation/driver-api/pwm.rst
> @@ -41,7 +41,15 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also 
> exist.
>  
>  After being requested, a PWM has to be configured using::
>  
> - int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
> + int pwm_apply_cansleep(struct pwm_device *pwm, struct pwm_state *state);
> +
> +If the PWM support atomic mode, which can be determined with::
> +
> +bool pwm_is_atomic(struct pwm_device *pwm);
> +
> +Then the PWM can be configured with::
> +
> + int pwm_apply(struct pwm_device *pwm, struct pwm_state *state);
>  
>  This API controls both the PWM period/duty_cycle config and the
>  enable/disable state.
> @@ -57,13 +65,13 @@ If supported by the driver, the signal can be optimized, 
> for example to improve
>  EMI by phase shifting the individual channels of a chip.
>  
>  The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
> -around pwm_apply_state() and should not be used if the user wants to change
> +around pwm_apply_cansleep() and should not be used if the user wants to 
> change
>  several parameter at once. For example, if you see pwm_config() and
>  pwm_{enable,disable}() calls in the same function, this probably means you
> -should switch to pwm_apply_state().
> +should switch to pwm_apply_cansleep().
>  
>  The PWM user API also allows one to query the PWM state that was passed to 
> the
> -last invocation of pwm_apply_state() using pwm_get_state(). Note this is
> +last invocation of pwm_apply_cansleep() using pwm_get_state(). Note this is
>  different to what the driver has actually implemented if the request cannot 
> be
>  satisfied exactly with the hardware in use. There is currently no way for
>  consumers to get the actually implemented settings.
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 2e8f17c045222..cf516190cde8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct 
> drm_connector_state *conn_state,
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
>   pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
> - pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
> + pwm_apply_cansleep(panel->backlight.pwm, >backlight.pwm_state);
>  }
>  
>  static void
> @@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct 
> drm_connector_state *old_conn
>   intel_backlight_set_pwm_level(old_conn_state, level);
>  
>   panel->backlight.pwm_state.enabled = 

Re: [Intel-gfx] [PATCH v12 3/4] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123

2023-10-18 Thread Nirmoy Das



On 10/18/2023 3:24 PM, Andrzej Hajda wrote:

On 20.09.2023 23:07, Jonathan Cavitt wrote:

Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.

Co-developed-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt  > ---
  drivers/gpu/drm/i915/gt/intel_engine_regs.h |   3 +
  drivers/gpu/drm/i915/gt/intel_gt.h  |   4 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h    |   2 +
  drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
  drivers/gpu/drm/i915/gt/selftest_lrc.c  |  65 +
  5 files changed, 153 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h

index fdd4ddd3a978a..b8618ee3e3041 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
  #define   CCID_EXTENDED_STATE_RESTORE    BIT(2)
  #define   CCID_EXTENDED_STATE_SAVE    BIT(3)
  #define RING_BB_PER_CTX_PTR(base)    _MMIO((base) + 0x1c0) /* 
gen8+ */

+#define   PER_CTX_BB_FORCE    BIT(2)
+#define   PER_CTX_BB_VALID    BIT(0)
+
  #define RING_INDIRECT_CTX(base)    _MMIO((base) + 0x1c4) /* 
gen8+ */
  #define RING_INDIRECT_CTX_OFFSET(base)    _MMIO((base) + 0x1c8) 
/* gen8+ */

  #define ECOSKPD(base)    _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h

index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
    ##__VA_ARGS__);    \
  } while (0)
  +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+    IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+    engine->class == COPY_ENGINE_CLASS)
+
  static inline bool gt_is_root(struct intel_gt *gt)
  {
  return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h

index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
    /* 8 bytes */
  INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+    INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
  };
    #define intel_gt_support_legacy_fencing(gt) 
((gt)->ggtt->num_fences > 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

index eaf66d9031665..db7088abeef38 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct 
intel_engine_cs *engine)

  return 0;
  }
  +static void
+lrc_setup_bb_per_ctx(u32 *regs,
+ const struct intel_engine_cs *engine,
+ u32 ctx_bb_ggtt_addr)
+{
+    GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+    regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+    ctx_bb_ggtt_addr |
+    PER_CTX_BB_FORCE |
+    PER_CTX_BB_VALID;
+}
+
  static void
  lrc_setup_indirect_ctx(u32 *regs,
 const struct intel_engine_cs *engine,
@@ -1020,7 +1032,13 @@ static u32 context_wa_bb_offset(const struct 
intel_context *ce)

  return PAGE_SIZE * ce->wa_bb_page;
  }
  -static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB.  When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
  {
  void *ptr;
  @@ -1029,6 +1047,7 @@ static u32 *context_indirect_bb(const struct 
intel_context *ce)

  ptr = ce->lrc_reg_state;
  ptr -= LRC_STATE_OFFSET; /* back to start of context image */
  ptr += context_wa_bb_offset(ce);
+    ptr += per_ctx ? PAGE_SIZE : 0;
    return ptr;
  }
@@ -1105,7 +1124,8 @@ __lrc_alloc_state(struct intel_context *ce, 
struct intel_engine_cs *engine)

    if (GRAPHICS_VER(engine->i915) >= 12) {
  ce->wa_bb_page = context_size / PAGE_SIZE;
-    context_size += PAGE_SIZE;
+    /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+    context_size += PAGE_SIZE * 2;
  }
    if (intel_context_is_parent(ce) && 
intel_engine_uses_guc(engine)) {
@@ -1407,12 +1427,85 @@ gen12_emit_indirect_ctx_xcs(const struct 
intel_context *ce, u32 *cs)

  return gen12_emit_aux_table_inv(ce->engine, cs);
  }
  +static u32 *xehp_emit_fastcolor_blt_wabb(const struct 
intel_context *ce, u32 *cs)

+{
+    struct intel_gt *gt = ce->engine->gt;
+    int mocs = gt->mocs.uc_index << 1;
+
+    /**
+ * Wa_16018031267 / Wa_16018063123 requires that SW forces the
+ * main copy engine arbitration into round robin mode.  We
+ * additionally need to submit the following WABB blt command
+ * to 

Re: [Intel-gfx] [PATCH v12 4/4] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123

2023-10-18 Thread Andrzej Hajda

On 20.09.2023 23:07, Jonathan Cavitt wrote:

Set copy engine arbitration into round robin mode
for part of Wa_16018031267 / Wa_16018063123 mitigation.

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++
  drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
  2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index b8618ee3e3041..c0c8c12edea10 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -124,6 +124,9 @@
  #define RING_INDIRECT_CTX(base)   _MMIO((base) + 0x1c4) 
/* gen8+ */
  #define RING_INDIRECT_CTX_OFFSET(base)_MMIO((base) + 0x1c8) 
/* gen8+ */
  #define ECOSKPD(base) _MMIO((base) + 0x1d0)
+#define   XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11)
+#define   XEHP_BLITTER_ROUND_ROBIN_MODE\
+   REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1)
  #define   ECO_CONSTANT_BUFFER_SR_DISABLE  REG_BIT(4)
  #define   ECO_GATING_CX_ONLY  REG_BIT(3)
  #define   GEN6_BLITTER_FBC_NOTIFY REG_BIT(3)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 660d4f358eab7..b8f3b991e4202 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2781,6 +2781,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
 RING_SEMA_WAIT_POLL(engine->mmio_base),
 1);
}
+   /* Wa_16018031267, Wa_16018063123 */
+   if (NEEDS_FASTCOLOR_BLT_WABB(engine))
+   wa_masked_field_set(wal, ECOSKPD(engine->mmio_base),
+   XEHP_BLITTER_SCHEDULING_MODE_MASK,
+   XEHP_BLITTER_ROUND_ROBIN_MODE);
  }
  
  static void




Re: [Intel-gfx] [PATCH v12 3/4] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123

2023-10-18 Thread Andrzej Hajda

On 20.09.2023 23:07, Jonathan Cavitt wrote:

Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.

Co-developed-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt  > ---
  drivers/gpu/drm/i915/gt/intel_engine_regs.h |   3 +
  drivers/gpu/drm/i915/gt/intel_gt.h  |   4 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h|   2 +
  drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
  drivers/gpu/drm/i915/gt/selftest_lrc.c  |  65 +
  5 files changed, 153 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index fdd4ddd3a978a..b8618ee3e3041 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
  #define   CCID_EXTENDED_STATE_RESTORE BIT(2)
  #define   CCID_EXTENDED_STATE_SAVEBIT(3)
  #define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+ 
*/
+#define   PER_CTX_BB_FORCE BIT(2)
+#define   PER_CTX_BB_VALID BIT(0)
+
  #define RING_INDIRECT_CTX(base)   _MMIO((base) + 0x1c4) 
/* gen8+ */
  #define RING_INDIRECT_CTX_OFFSET(base)_MMIO((base) + 0x1c8) 
/* gen8+ */
  #define ECOSKPD(base) _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
  ##__VA_ARGS__);   \
  } while (0)
  
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \

+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS)
+
  static inline bool gt_is_root(struct intel_gt *gt)
  {
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
  
  	/* 8 bytes */

INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+   INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
  };
  
  #define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eaf66d9031665..db7088abeef38 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct 
intel_engine_cs *engine)
return 0;
  }
  
+static void

+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+   GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+   regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+   ctx_bb_ggtt_addr |
+   PER_CTX_BB_FORCE |
+   PER_CTX_BB_VALID;
+}
+
  static void
  lrc_setup_indirect_ctx(u32 *regs,
   const struct intel_engine_cs *engine,
@@ -1020,7 +1032,13 @@ static u32 context_wa_bb_offset(const struct 
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
  }
  
-static u32 *context_indirect_bb(const struct intel_context *ce)

+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB.  When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
  {
void *ptr;
  
@@ -1029,6 +1047,7 @@ static u32 *context_indirect_bb(const struct intel_context *ce)

ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+   ptr += per_ctx ? PAGE_SIZE : 0;
  
  	return ptr;

  }
@@ -1105,7 +1124,8 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
  
  	if (GRAPHICS_VER(engine->i915) >= 12) {

ce->wa_bb_page = context_size / PAGE_SIZE;
-   context_size += PAGE_SIZE;
+   /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+   context_size += PAGE_SIZE * 2;
}
  
  	if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {

@@ -1407,12 +1427,85 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
  }
  
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32 *cs)

+{
+   struct intel_gt *gt = ce->engine->gt;
+   int mocs = gt->mocs.uc_index << 1;
+
+   /**
+* Wa_16018031267 / Wa_16018063123 requires that SW forces the
+

[Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs

2023-10-18 Thread Stanislav Lisovskiy
For validation purposes, it might be useful to be able to
force Bigjoiner mode, even if current dotclock/resolution
do not require that.
Lets add such to option to debugfs.

v2: - Apparently intel_dp_need_bigjoiner can't be used, when
  debugfs entry is created so lets just check manually
  the DISPLAY_VER.

v3: - Switch to intel_connector from drm_connector(Jani Nikula)
- Remove redundant modeset lock(Jani Nikula)
- Use kstrtobool_from_user for boolean value(Jani Nikula)

v4: - Apply the changes to proper function(Jani Nikula)

Signed-off-by: Stanislav Lisovskiy 
---
 .../drm/i915/display/intel_display_debugfs.c  | 66 +++
 .../drm/i915/display/intel_display_types.h|  2 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index fbe75d47a165..9b810c6f96ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1398,6 +1398,30 @@ out: 
drm_modeset_unlock(>mode_config.connection_mutex);
return ret;
 }
 
+static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
+{
+   struct intel_connector *connector = to_intel_connector(m->private);
+   struct drm_crtc *crtc;
+   struct intel_encoder *encoder = intel_attached_encoder(connector);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int ret = 0;
+
+   if (!encoder)
+   return -ENODEV;
+
+   crtc = connector->base.state->crtc;
+   if (connector->base.status != connector_status_connected || !crtc) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   seq_printf(m, "Bigjoiner enable: %d\n", 
intel_dp->force_bigjoiner_enable);
+
+out:
+
+   return ret;
+}
+
 static ssize_t i915_dsc_output_format_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
@@ -1419,12 +1443,39 @@ static ssize_t i915_dsc_output_format_write(struct file 
*file,
return len;
 }
 
+static ssize_t i915_bigjoiner_enable_fops_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   struct intel_connector *connector = m->private;
+   struct intel_encoder *encoder = intel_attached_encoder(connector);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   bool bigjoiner_en = 0;
+   int ret;
+
+   ret = kstrtobool_from_user(ubuf, len, _en);
+   if (ret < 0)
+   return ret;
+
+   intel_dp->force_bigjoiner_enable = bigjoiner_en;
+   *offp += len;
+
+   return len;
+}
+
 static int i915_dsc_output_format_open(struct inode *inode,
   struct file *file)
 {
return single_open(file, i915_dsc_output_format_show, inode->i_private);
 }
 
+static int i915_bigjoiner_enable_open(struct inode *inode,
+ struct file *file)
+{
+   return single_open(file, i915_bigjoiner_enable_show, inode->i_private);
+}
+
 static const struct file_operations i915_dsc_output_format_fops = {
.owner = THIS_MODULE,
.open = i915_dsc_output_format_open,
@@ -1434,6 +1485,15 @@ static const struct file_operations 
i915_dsc_output_format_fops = {
.write = i915_dsc_output_format_write
 };
 
+static const struct file_operations i915_bigjoiner_enable_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_bigjoiner_enable_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_bigjoiner_enable_fops_write
+};
+
 /*
  * Returns the Current CRTC's bpc.
  * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
@@ -1513,6 +1573,12 @@ void intel_connector_debugfs_add(struct intel_connector 
*intel_connector)
connector, _dsc_output_format_fops);
}
 
+   if (DISPLAY_VER(dev_priv) >= 11 &&
+   intel_connector->base.connector_type == 
DRM_MODE_CONNECTOR_DisplayPort) {
+   debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
+   _connector->base, 
_bigjoiner_enable_fops);
+   }
+
if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8d8b2f8d37a9..e0de6eeaf59e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ 

Re: [Intel-gfx] [PATCH v12 2/4] drm/i915: Reserve some kernel space per vm

2023-10-18 Thread Andrzej Hajda

On 20.09.2023 23:07, Jonathan Cavitt wrote:

Reserve two pages in each vm for kernel space to use for things
such as workarounds.

Signed-off-by: Jonathan Cavitt 
Suggested-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 7 +++
  drivers/gpu/drm/i915/gt/intel_gtt.h  | 1 +
  2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 84aa29715e0ac..6344d733fb2c4 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -230,6 +230,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space 
*vm)
 gen8_pd_top_count(vm), vm->top);
  
  	free_scratch(vm);

+   drm_mm_remove_node(>rsvd);
  }
  
  static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,

@@ -1014,6 +1015,12 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
ppgtt->vm.foreach = gen8_ppgtt_foreach;
ppgtt->vm.cleanup = gen8_ppgtt_cleanup;
  
+	ppgtt->vm.rsvd.start = ppgtt->vm.total - (SZ_4K * 2);

+   ppgtt->vm.rsvd.size = (SZ_4K * 2);
+   ppgtt->vm.rsvd.color = I915_COLOR_UNEVICTABLE;
+   GEM_BUG_ON(drm_mm_reserve_node(>vm.mm, >vm.rsvd));
+   ppgtt->vm.total -= (SZ_4K * 2);


I suspect you shouldn't decrease vm.total, otherwise api_intel_bb CI 
tests will complain and I guess vm.total means total, ie it should 
include reserved nodes as well.
Btw why not use i915_gem_gtt_reserve instead of hardcoding, I do not 
know this helper but it looks like good fit.


Regards
Andrzej



+
err = gen8_init_scratch(>vm);
if (err)
goto err_put;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 153ddfca0ae18..680ce27dda40c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -247,6 +247,7 @@ struct i915_address_space {
struct work_struct release_work;
  
  	struct drm_mm mm;

+   struct drm_mm_node rsvd;
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;




Re: [Intel-gfx] [PATCH v12 1/4] drm/i915: Enable NULL PTE support for vm scratch

2023-10-18 Thread Andrzej Hajda

On 20.09.2023 23:07, Jonathan Cavitt wrote:

Enable NULL PTE support for vm scratch pages.

The use of NULL PTEs in teh vm scratch pages requires us to change how
the i915 gem_contexts live selftest perform vm_isolation: instead of
checking the scratch pages are isolated and don't affect each other, we
check that all changes to the scratch pages are voided.

Signed-off-by: Jonathan Cavitt 
Suggested-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 ++
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 3 +++
  drivers/gpu/drm/i915/gt/intel_gtt.h   | 1 +
  drivers/gpu/drm/i915/i915_drv.h   | 2 ++
  drivers/gpu/drm/i915/i915_pci.c   | 2 ++
  drivers/gpu/drm/i915/intel_device_info.h  | 1 +
  6 files changed, 15 insertions(+)

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 7021b6e9b219e..48fc5990343bc 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1751,6 +1751,12 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
if (!vm)
return -ENODEV;
  
+	if (HAS_NULL_PAGE(vm->i915)) {

+   if (out)
+   *out = 0;
+   return 0;
+   }
+
if (!vm->scratch[0]) {
pr_err("No scratch page!\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 9895e18df0435..84aa29715e0ac 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -855,6 +855,9 @@ static int gen8_init_scratch(struct i915_address_space *vm)
  I915_CACHE_NONE),
   pte_flags);
  
+	if (HAS_NULL_PAGE(vm->i915))

+   vm->scratch[0]->encode |= PTE_NULL_PAGE;
+
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h

index 346ec8ec2edda..153ddfca0ae18 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -151,6 +151,7 @@ typedef u64 gen8_pte_t;
  
  #define GEN8_PAGE_PRESENT		BIT_ULL(0)

  #define GEN8_PAGE_RW  BIT_ULL(1)
+#define PTE_NULL_PAGE  BIT_ULL(9)
  
  #define GEN8_PDE_IPS_64K BIT(11)

  #define GEN8_PDE_PS_2M   BIT(7)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 87ffc477c3b1a..687a8fcdc3d54 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -782,6 +782,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
   */
  #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
  
+#define HAS_NULL_PAGE(dev_priv) (INTEL_INFO(dev_priv)->has_null_page)

+
  #define HAS_GT_UC(i915)   (INTEL_INFO(i915)->has_gt_uc)
  
  #define HAS_POOLED_EU(i915)	(RUNTIME_INFO(i915)->has_pooled_eu)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f79..80a65ea192107 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -642,6 +642,7 @@ static const struct intel_device_info jsl_info = {
GEN(12), \
TGL_CACHELEVEL, \
.has_global_mocs = 1, \
+   .has_null_page = 1, \
.has_pxp = 1, \
.max_pat_index = 3
  
@@ -721,6 +722,7 @@ static const struct intel_device_info adl_p_info = {

.has_mslice_steering = 1, \
.has_oa_bpc_reporting = 1, \
.has_oa_slice_contrib_limits = 1, \
+   .has_null_page = 1, \


Shouldn't be alpabetical order.



.has_oam = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 39817490b13fd..252f8dc0fe790 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -162,6 +162,7 @@ enum intel_ppgtt_type {
func(has_mslice_steering); \
func(has_oa_bpc_reporting); \
func(has_oa_slice_contrib_limits); \
+   func(has_null_page); \


ditto

Beside this:

Reviewed-by: Andrzej Hajda 

Btw do you want/have time to continue working on the series? If not I 
can take it over.


Regards
Andrzej


func(has_oam); \
func(has_one_eu_per_fuse_bit); \
func(has_pxp); \




Re: [Intel-gfx] [PATCH] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence

2023-10-18 Thread Maarten Lankhorst

Hey,

Thanks, this version looks a lot better than duplicating 
drm_gem_plane_helper_prepare_fb functionality. :)


Reviewed-by: Maarten Lankhorst 

On 2023-10-16 10:08, Jouni Högander wrote:

We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
implementation. Lets drop i915_sw_fence usage from display code and
use dma_fence interfaces directly.

For this purpose stack dma fences from related objects into old and new
plane states using drm_gem_plane_helper_prepare_fb. Then wait for these
stacked fences during atomic commit.

There is no be need for separate GPU reset handling in
intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
detected and GPU is being reset.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: José Roberto de Souza 

Signed-off-by: Jouni Högander 
---
  drivers/gpu/drm/i915/display/intel_atomic.c   |  3 -
  .../gpu/drm/i915/display/intel_atomic_plane.c | 49 +++-
  drivers/gpu/drm/i915/display/intel_display.c  | 78 ++-
  .../drm/i915/display/intel_display_types.h|  2 -
  4 files changed, 37 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 5d18145da279..ec0d5168b503 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state 
*_state)
  
  	drm_atomic_state_default_release(>base);

kfree(state->global_objs);
-
-   i915_sw_fence_fini(>commit_ready);
-
kfree(state);
  }
  
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c

index b1074350616c..d4f9168ec42c 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -32,6 +32,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -1035,7 +1036,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,

struct intel_atomic_state *state =
to_intel_atomic_state(new_plane_state->uapi.state);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-   const struct intel_plane_state *old_plane_state =
+   struct intel_plane_state *old_plane_state =
intel_atomic_get_old_plane_state(state, plane);
struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
struct drm_i915_gem_object *old_obj = 
intel_fb_obj(old_plane_state->hw.fb);
@@ -1057,56 +1058,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * This should only fail upon a hung GPU, in which case we
 * can safely continue.
 */
-   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)) 
{
-   ret = 
i915_sw_fence_await_reservation(>commit_ready,
- 
old_obj->base.resv,
- false, 0,
- GFP_KERNEL);
+   if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state) 
&&
+   !dma_resv_test_signaled(old_obj->base.resv,
+   dma_resv_usage_rw(false))) {
+   ret = drm_gem_plane_helper_prepare_fb(_plane, 
_plane_state->uapi);
if (ret < 0)
return ret;
}
}
  
-	if (new_plane_state->uapi.fence) { /* explicit fencing */

-   i915_gem_fence_wait_priority(new_plane_state->uapi.fence,
-);
-   ret = i915_sw_fence_await_dma_fence(>commit_ready,
-   new_plane_state->uapi.fence,
-   
i915_fence_timeout(dev_priv),
-   GFP_KERNEL);
-   if (ret < 0)
-   return ret;
-   }
-
if (!obj)
return 0;
  
-

ret = intel_plane_pin_fb(new_plane_state);
if (ret)
return ret;
  
-	i915_gem_object_wait_priority(obj, 0, );

-
-   if (!new_plane_state->uapi.fence) { /* implicit fencing */
-   struct dma_resv_iter cursor;
-   struct dma_fence *fence;
+   ret = drm_gem_plane_helper_prepare_fb(_plane, _plane_state->uapi);
+   if (ret < 0)
+   goto unpin_fb;
  
-		ret = i915_sw_fence_await_reservation(>commit_ready,

- obj->base.resv, false,
- 
i915_fence_timeout(dev_priv),
- GFP_KERNEL);
-   if (ret < 0)
-   goto unpin_fb;
+   if (new_plane_state->uapi.fence) {

Re: [Intel-gfx] [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Andi Shyti
Hi Nirmoy,

> > > gen8_ggtt_invalidate() is only needed for limited set of platforms
> > > where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
> > > commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
> > > there are no reference in HW docs that forces us to use this on non-WC
> > > backed GGTT.
> > > 
> > > This can also cause unwanted side-effects on XE_HP platforms where
> > > GFX_FLSH_CNTL_GEN6 is not valid anymore.
> > > 
> > > v2: Add a func to detect wc ggtt detection (Ville)
> > > v3: Improve commit log and add reference commit (Daniel)
> > > 
> > > Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> > I'm wondering if this is the right Fixes, though. Should this
> > rather be:
> > 
> > Fixes: 6266992cf105 ("drm/i915/gt: remove GRAPHICS_VER == 10")
> 
> Hard to find a real Fixes for this. I just want to backport this to dg2
> where we can have unwanted side-effects.

yes, this piece of code has moved around enough so to make it
diffuclt to track its origin.

I think the one I found should be the correct one, but the dg2
force probe removeal can also become a placeholder for DG2 fixes.

I won't complain.

Andi


Re: [Intel-gfx] [PATCH] drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

2023-10-18 Thread Kahola, Mika
> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Wednesday, October 18, 2023 2:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Syrjala, Ville 
> ; Sripada, Radhakrishna
> ; Murthy, Arun R ; 
> Borah, Chaitanya Kumar
> ; sta...@vger.kernel.org
> Subject: [PATCH] drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL
> 
> eDP specification supports HBR3 link rate since v1.4a. Moreover,
> C10 phy can support HBR3 link rate for both DP and eDP. Therefore, do not 
> clamp the supported rates for eDP at 6.75Gbps.
> 
> Cc: 
> 
> BSpec: 70073 74224
> 

Reviewed-by: Mika Kahola 

> Signed-off-by: Chaitanya Kumar Borah 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1891c0cc187d..2c1034578984 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -430,7 +430,7 @@ static int mtl_max_source_rate(struct intel_dp *intel_dp)
>   enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> 
>   if (intel_is_c10phy(i915, phy))
> - return intel_dp_is_edp(intel_dp) ? 675000 : 81;
> + return 81;
> 
>   return 200;
>  }
> --
> 2.25.1



Re: [Intel-gfx] [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-18 Thread Andy Shevchenko
On Wed, Oct 18, 2023 at 11:09:35AM +0200, Hans de Goede wrote:
> On 10/18/23 07:10, Andy Shevchenko wrote:
> > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> > talking to GPIO IP behind the actual driver's back. An attempt to fix
> > that is here.
> > 
> > If I understood correctly, my approach should work in the similar way as
> > the current IOSF GPIO. 
> > 
> > Hans, I believe you have some devices that use this piece of code,
> > is it possible to give a test run on (one of) them?
> 
> Yes I should be able to find a device or 2 which poke GPIOs from the
> VBT MIPI sequences. Unfortunately I don't know from the top of my head
> which devices actually use this, so I may need to try quite a few devices
> before finding one which actually uses this.
> 
> I'll try to get this series tested sometime the coming weeks,
> depending on when I can schedule some time for this.

No hurry. maybe you simply can add into your usual tree you run on your
devices?

-- 
With Best Regards,
Andy Shevchenko




Re: [Intel-gfx] [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Nirmoy Das

Hi Andi,

On 10/18/2023 1:49 PM, Andi Shyti wrote:

Hi Nirmoy,

On Wed, Oct 18, 2023 at 11:38:15AM +0200, Nirmoy Das wrote:

gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
there are no reference in HW docs that forces us to use this on non-WC
backed GGTT.

This can also cause unwanted side-effects on XE_HP platforms where
GFX_FLSH_CNTL_GEN6 is not valid anymore.

v2: Add a func to detect wc ggtt detection (Ville)
v3: Improve commit log and add reference commit (Daniel)

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")

I'm wondering if this is the right Fixes, though. Should this
rather be:

Fixes: 6266992cf105 ("drm/i915/gt: remove GRAPHICS_VER == 10")


Hard to find a real Fixes for this. I just want to backport this to dg2 
where we can have unwanted side-effects.



Regards,

Nirmoy



?

Andi


Re: [Intel-gfx] [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Andi Shyti
Hi Nirmoy,

On Wed, Oct 18, 2023 at 11:38:15AM +0200, Nirmoy Das wrote:
> gen8_ggtt_invalidate() is only needed for limited set of platforms
> where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
> commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
> there are no reference in HW docs that forces us to use this on non-WC
> backed GGTT.
> 
> This can also cause unwanted side-effects on XE_HP platforms where
> GFX_FLSH_CNTL_GEN6 is not valid anymore.
> 
> v2: Add a func to detect wc ggtt detection (Ville)
> v3: Improve commit log and add reference commit (Daniel)
> 
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")

I'm wondering if this is the right Fixes, though. Should this
rather be:

Fixes: 6266992cf105 ("drm/i915/gt: remove GRAPHICS_VER == 10")

?

Andi


[Intel-gfx] [PATCH] drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

2023-10-18 Thread Chaitanya Kumar Borah
eDP specification supports HBR3 link rate since v1.4a. Moreover,
C10 phy can support HBR3 link rate for both DP and eDP. Therefore,
do not clamp the supported rates for eDP at 6.75Gbps.

Cc: 

BSpec: 70073 74224

Signed-off-by: Chaitanya Kumar Borah 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1891c0cc187d..2c1034578984 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -430,7 +430,7 @@ static int mtl_max_source_rate(struct intel_dp *intel_dp)
enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
 
if (intel_is_c10phy(i915, phy))
-   return intel_dp_is_edp(intel_dp) ? 675000 : 81;
+   return 81;
 
return 200;
 }
-- 
2.25.1



Re: [Intel-gfx] [PATCH v2] drm/i915: Prevent potential null-ptr-deref in engine_init_common

2023-10-18 Thread Nirmoy Das

This now merged. CI errors are unrelated.

On 10/11/2023 2:25 PM, Nirmoy Das wrote:

If measure_breadcrumb_dw() returns an error and bce isn't created,
this commit ensures that intel_engine_destroy_pinned_context()
is not called with a NULL bce.

v2: Fix the subject s/UAF/null-ptr-deref(Jani)

Fixes: b35274993680 ("drm/i915: Create a kernel context for GGTT updates")
Cc: Oak Zeng 
Cc: Andi Shyti 
Cc: Jani Nikula 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 179d9546865b..4a11219e560e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1491,7 +1491,8 @@ static int engine_init_common(struct intel_engine_cs 
*engine)
return 0;
  
  err_bce_context:

-   intel_engine_destroy_pinned_context(bce);
+   if (bce)
+   intel_engine_destroy_pinned_context(bce);
  err_ce_context:
intel_engine_destroy_pinned_context(ce);
return ret;


[Intel-gfx] [PATCH v4 0/2] display device info as a separate debugfs entry

2023-10-18 Thread Vinod Govindapillai
Expose the display device info as a separate debugfs entry to list out
display device info and remove the same from i915_capabilities

v2: rename the debugs entry to i915_display_capabilities and patch
description changes

v3: Exclude the patch to remove display device and runtime info from
i915_capabilities from this patch series. Remove this only after
IGT starts using the i915_display_capabilities

v4: Add back the patch to remove the display info from i915_capabilities
and use test with tag to combine the IGT and kernel changes 

Test-with: 20231018063537.140125-1-swati2.sha...@intel.com

Vinod Govindapillai (2):
  drm/i915/display: debugfs entry to list display capabilities
  drm/i915: remove display device info from i915 capabilities

 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 
 drivers/gpu/drm/i915/i915_debugfs.c  |  1 -
 2 files changed, 12 insertions(+), 1 deletion(-)

-- 
2.34.1



[Intel-gfx] [PATCH v4 1/2] drm/i915/display: debugfs entry to list display capabilities

2023-10-18 Thread Vinod Govindapillai
Create a separate debugfs entry to list the display capabilities
IGT can rely on this debugfs entry for tests that depend on
display device and display runtime info for both xe and i915
drivers.

v2: rename the entry to i915_display_capabilities (Chaitanya)

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index fbe75d47a165..b0248dfa8dea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -641,6 +641,17 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_display_capabilities(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *i915 = node_to_i915(m->private);
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   intel_display_device_info_print(DISPLAY_INFO(i915),
+   DISPLAY_RUNTIME_INFO(i915), );
+
+   return 0;
+}
+
 static int i915_shared_dplls_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -1059,6 +1070,7 @@ static const struct drm_info_list 
intel_display_debugfs_list[] = {
{"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_display_info", i915_display_info, 0},
+   {"i915_display_capabilities", i915_display_capabilities, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
{"i915_ddb_info", i915_ddb_info, 0},
-- 
2.34.1



[Intel-gfx] [PATCH v4 2/2] drm/i915: remove display device info from i915 capabilities

2023-10-18 Thread Vinod Govindapillai
Display device and display runtime info is exposed as part of
i915_display_capabilities debugfs entry. Remove this information
from i915_ capabilities as it is now reduntant.

Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e9b79c2c37d8..bb48feb3b12e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -67,7 +67,6 @@ static int i915_capabilities(struct seq_file *m, void *data)
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(i915));
 
intel_device_info_print(INTEL_INFO(i915), RUNTIME_INFO(i915), );
-   intel_display_device_info_print(DISPLAY_INFO(i915), 
DISPLAY_RUNTIME_INFO(i915), );
i915_print_iommu_status(i915, );
intel_gt_info_print(_gt(i915)->info, );
intel_driver_caps_print(>caps, );
-- 
2.34.1



[Intel-gfx] [PATCH v3] drm/i915: Flush WC GGTT only on required platforms

2023-10-18 Thread Nirmoy Das
gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC. This was added as way to fix WC based GGTT in
commit 0f9b91c754b7 ("drm/i915: flush system agent TLBs on SNB") and
there are no reference in HW docs that forces us to use this on non-WC
backed GGTT.

This can also cause unwanted side-effects on XE_HP platforms where
GFX_FLSH_CNTL_GEN6 is not valid anymore.

v2: Add a func to detect wc ggtt detection (Ville)
v3: Improve commit log and add reference commit (Daniel)

Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Jonathan Cavitt 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc:  # v6.2+
Suggested-by: Matt Roper 
Signed-off-by: Nirmoy Das 
Reviewed-by: Matt Roper 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 35 +++-
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1c93e84278a0..15fc8e4703f4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -195,6 +195,21 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
spin_unlock_irq(>lock);
 }
 
+static bool needs_wc_ggtt_mapping(struct drm_i915_private *i915)
+{
+   /*
+* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
+* will be dropped. For WC mappings in general we have 64 byte burst
+* writes when the WC buffer is flushed, so we can't use it, but have to
+* resort to an uncached mapping. The WC issue is easily caught by the
+* readback check when writing GTT PTE entries.
+*/
+   if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
+   return true;
+
+   return false;
+}
+
 static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
 {
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
@@ -202,8 +217,12 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
/*
 * Note that as an uncached mmio write, this will flush the
 * WCB of the writes into the GGTT before it triggers the invalidate.
+*
+* Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
 */
-   intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   if (needs_wc_ggtt_mapping(ggtt->vm.i915))
+   intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
+ GFX_FLSH_CNTL_EN);
 }
 
 static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
@@ -1140,17 +1159,11 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, 
u64 size)
GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) != 
gen6_gttmmadr_size(i915));
phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) + 
gen6_gttadr_offset(i915);
 
-   /*
-* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
-* will be dropped. For WC mappings in general we have 64 byte burst
-* writes when the WC buffer is flushed, so we can't use it, but have to
-* resort to an uncached mapping. The WC issue is easily caught by the
-* readback check when writing GTT PTE entries.
-*/
-   if (IS_GEN9_LP(i915) || GRAPHICS_VER(i915) >= 11)
-   ggtt->gsm = ioremap(phys_addr, size);
-   else
+   if (needs_wc_ggtt_mapping(i915))
ggtt->gsm = ioremap_wc(phys_addr, size);
+   else
+   ggtt->gsm = ioremap(phys_addr, size);
+
if (!ggtt->gsm) {
drm_err(>drm, "Failed to map the ggtt page table\n");
return -ENOMEM;
-- 
2.41.0



Re: [Intel-gfx] [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-18 Thread Hans de Goede
Hi Andy,

On 10/18/23 07:10, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. An attempt to fix
> that is here.
> 
> If I understood correctly, my approach should work in the similar way as
> the current IOSF GPIO. 
> 
> Hans, I believe you have some devices that use this piece of code,
> is it possible to give a test run on (one of) them?

Yes I should be able to find a device or 2 which poke GPIOs from the
VBT MIPI sequences. Unfortunately I don't know from the top of my head
which devices actually use this, so I may need to try quite a few devices
before finding one which actually uses this.

I'll try to get this series tested sometime the coming weeks,
depending on when I can schedule some time for this.

Regards,

Hans




> 
> Andy Shevchenko (2):
>   drm/i915/dsi: Extract common soc_gpio_exec() helper
>   drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
> 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 150 +++
>  1 file changed, 58 insertions(+), 92 deletions(-)
> 



[Intel-gfx] [PATCH] drm/i915/mtl: Add Wa_14019821291

2023-10-18 Thread Dnyaneshwar Bhadane
This workaround is primarily implemented by the BIOS.  However if the
BIOS applies the workaround it will reserve a small piece of our DSM
(which should be at the top, right below the WOPCM); we just need to
keep that region reserved so that nothing else attempts to re-use it.

Signed-off-by: Dnyaneshwar Bhadane 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 18 ++
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 1a766d8e7cce..b2bc5aab88d3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -409,6 +409,24 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,
*base -= *size;
else
*base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
+
+   /* Wa_14019821291*/
+   if (IS_MEDIA_GT_IP_STEP(i915->media_gt, IP_VER(13, 0), STEP_A0, 
STEP_C0)) {
+   /*
+* This workaround is primarily implemented by the BIOS.  We
+* just need to figure out whether the BIOS has applied the
+* workaround (meaning the programmed address falls within
+* the DSM) and, if so, reserve that part of the DSM to
+* prevent accidental reuse.  The DSM location should be just
+* below the WOPCM.
+*/
+
+   u64 gscpsmi_base = intel_uncore_read64_2x32(uncore,
+   
MTL_GSCPSMI_BASEADDR_LSB,
+   
MTL_GSCPSMI_BASEADDR_MSB);
+   if (gscpsmi_base >= *base && gscpsmi_base < *base + *size)
+   *size = gscpsmi_base - *base;
+   }
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 135e8d8dbdf0..31d0692a5620 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6399,5 +6399,7 @@ enum skl_power_gate {
 #define   MTL_TRDPRE_MASK  REG_GENMASK(7, 0)
 
 #define MTL_MEDIA_GSI_BASE 0x38
+#define MTL_GSCPSMI_BASEADDR_LSB   _MMIO(MTL_MEDIA_GSI_BASE + 
0x880c)
+#define MTL_GSCPSMI_BASEADDR_MSB   _MMIO(MTL_MEDIA_GSI_BASE + 
0x8810)
 
 #endif /* _I915_REG_H_ */
-- 
2.34.1