Re: [PATCH] drm/i915/dp: Fix DSC state HW readout for SST connectors

[Nautiyal, Ankit K]

On 3/11/2024 8:26 PM, Imre Deak wrote:

Commit a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout")
moved the DSC HW state readout to a connector specific hook, however
only added the hook for DP MST connectors, not for DP SST ones. Fix
adding the hook for SST connectors as well.

This fixes the following warn on platforms where BIOS enables DSC:

[   66.208601] i915 :00:02.0: drm_WARN_ON(!connector->dp.dsc_decompression_aux 
|| !connector->dp.dsc_decompression_enabled)
...
[   66.209024] RIP: 0010:intel_dp_sink_disable_decompression+0x76/0x110 [i915]
...
[   66.209333]  ? intel_dp_sink_disable_decompression+0x76/0x110 [i915]
...
[   66.210068]  intel_disable_ddi+0x135/0x1d0 [i915]
[   66.210302]  intel_encoders_disable+0x9b/0xc0 [i915]
[   66.210565]  hsw_crtc_disable+0x153/0x170 [i915]
[   66.210823]  intel_old_crtc_state_disables+0x52/0xb0 [i915]
[   66.211107]  intel_atomic_commit_tail+0x5cf/0x1330 [i915]
[   66.211366]  intel_atomic_commit+0x39d/0x3f0 [i915]
[   66.211612]  ? intel_atomic_commit+0x39d/0x3f0 [i915]
[   66.211872]  drm_atomic_commit+0x9d/0xd0 [drm]
[   66.211921]  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[   66.211975]  intel_initial_commit+0x1a8/0x260 [i915]
[   66.212234]  intel_display_driver_probe+0x2a/0x80 [i915]
[   66.212479]  i915_driver_probe+0x7c6/0xc60 [i915]
[   66.212664]  ? drm_privacy_screen_get+0x168/0x190 [drm]
[   66.212711]  i915_pci_probe+0xe2/0x1c0 [i915]

Fixes: a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout")
Cc: Ankit Nautiyal 
Signed-off-by: Imre Deak 


Reviewed-by: Ankit Nautiyal 

I think this should fix gitlab issue: 
https://gitlab.freedesktop.org/drm/intel/-/issues/10410


Regards,

Ankit


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

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f98ef4b42a448..af7ca00e9bc0a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6557,6 +6557,7 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
intel_connector->get_hw_state = 
intel_ddi_connector_get_hw_state;
else
intel_connector->get_hw_state = intel_connector_get_hw_state;
+   intel_connector->sync_state = intel_dp_connector_sync_state;
  
  	if (!intel_edp_init_connector(intel_dp, intel_connector)) {

intel_dp_aux_fini(intel_dp);

✗ Fi.CI.BAT: failure for drm/i915/display: Fixed a screen flickering when turning on display from off (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/display: Fixed a screen flickering when turning on display 
from off (rev2)
URL   : https://patchwork.freedesktop.org/series/130780/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130780v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_130780v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_130780v2, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_130780v2/index.html

Participating hosts (34 -> 33)
--

  Additional (1): fi-glk-j4005 
  Missing(2): bat-dg1-7 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-arls-2: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-arls-2/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-arls-2/igt@i915_module_l...@load.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/fi-glk-j4005/igt@gem_lmem_swapp...@basic.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_130780v2/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.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_130780v2/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005:   NOTRUN -> [SKIP][9] +10 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_pipe_crc_basic@hang-read-crc:
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#9875] / [i915#9900]) +6 
other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html

  * igt@kms_pm_backlight@basic-brightness:
- bat-adlm-1: NOTRUN -> [SKIP][13] ([i915#5354])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@kms_pm_backli...@basic-brightness.html

  * igt@kms_psr@psr-sprite-plane-onoff:
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#9673] / [i915#9732]) +3 
other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@kms_...@psr-sprite-plane-onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3555])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#3708] / [i915#9900])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-write:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#3708]) +2 other tests skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130780v2/bat-adlm-1/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * 

✓ Fi.CI.BAT: success for Fix divide-by-zero regression on DP MST unplug with nouveau

[Patchwork]

== Series Details ==

Series: Fix divide-by-zero regression on DP MST unplug with nouveau
URL   : https://patchwork.freedesktop.org/series/131002/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_131002v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 33)
--

  Additional (1): fi-glk-j4005 
  Missing(2): bat-dg1-7 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 other tests skip
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html

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

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

  * igt@i915_selftest@live@gt_contexts:
- bat-dg2-14: [PASS][5] -> [ABORT][6] ([i915#10366])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-14/igt@i915_selftest@live@gt_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-dg2-14/igt@i915_selftest@live@gt_contexts.html

  * igt@i915_selftest@live@hangcheck:
- bat-adlp-6: [PASS][7] -> [ABORT][8] ([i915#10021])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005:   NOTRUN -> [SKIP][9] +10 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_pipe_crc_basic@hang-read-crc:
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#9875] / [i915#9900]) +6 
other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html

  * igt@kms_pm_backlight@basic-brightness:
- bat-adlm-1: NOTRUN -> [SKIP][13] ([i915#5354])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@kms_pm_backli...@basic-brightness.html

  * igt@kms_psr@psr-sprite-plane-onoff:
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#9673] / [i915#9732]) +3 
other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@kms_...@psr-sprite-plane-onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3555])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#3708] / [i915#9900])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-write:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#3708]) +2 other tests skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131002v1/bat-adlm-1/igt@prime_v...@basic-write.html

  
  [i915#10021]: https://gitlab.freedesktop.org/drm/intel/issues/10021
  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4342]: https://gitlab.freedesktop.org/drm/intel/issues/4342
  [i915#4613]: 

✗ Fi.CI.CHECKPATCH: warning for Fix divide-by-zero regression on DP MST unplug with nouveau

[Patchwork]

== Series Details ==

Series: Fix divide-by-zero regression on DP MST unplug with nouveau
URL   : https://patchwork.freedesktop.org/series/131002/
State : warning

== Summary ==

Error: dim checkpatch failed
0a773e72b268 Fix divide-by-zero regression on DP MST unplug with nouveau
-:14: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#14: 
 Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 
31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 
f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31

-:84: WARNING:BRACES: braces {} are not necessary for single statement blocks
#84: FILE: drivers/gpu/drm/display/drm_dp_helper.c:4114:
+   if (bpp_x16 == 0) {
+   DRM_DEBUG("drm_dp_bw_overhead called with bpp 0\n");
+   }

-:85: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 
'drm_dp_bw_overhead', this function's name, in a string
#85: FILE: drivers/gpu/drm/display/drm_dp_helper.c:4115:
+   DRM_DEBUG("drm_dp_bw_overhead called with bpp 0\n");

-:87: WARNING:BRACES: braces {} are not necessary for single statement blocks
#87: FILE: drivers/gpu/drm/display/drm_dp_helper.c:4117:
+   if (lane_count == 0 || hactive == 0 || bpp_x16 == 0) {
+   return 0;
+   }

total: 0 errors, 4 warnings, 0 checks, 13 lines checked

[PATCH] drm/i915/display: Fixed a screen flickering when turning on display from off

[gareth . yu]

From: Gareth Yu 

Turn on the panel from zero brightness of the last state, the panel was
set a maximum PWM in the flow. Once the panel initialization is completed,
the backlight is restored to xero brightness. There is a flckering
generated. This flicker happens in "Screen dimming and power off" of
Google's design and resume from sleep. The sample of DMESG is below.

(suspend)
[53949.248875] i915 :00:02.0: [drm:intel_edp_backlight_off]
[53949.452046] i915 :00:02.0: [drm:intel_backlight_set_pwm_level] set 
backlight PWM = 0

(wakeup)
[53986.067356] i915 :00:02.0: [drm:intel_edp_backlight_on]
[53986.067367] i915 :00:02.0: [drm:intel_backlight_enable] pipe A
[53986.067476] i915 :00:02.0: [drm:intel_backlight_set_pwm_level] set 
backlight PWM = 96000
[53986.119766] backlight intel_backlight: PM: calling backlight_resume+0x0/0x7a 
@ 4916, parent: card0-eDP-1
[53986.119781] backlight intel_backlight: PM: backlight_resume+0x0/0x7a 
returned 0 after 0 usecs
[53986.220068] [drm:intel_backlight_device_update_status] updating 
intel_backlight, brightness=26321/96000
[53986.220086] i915 :00:02.0: [drm:intel_panel_actually_set_backlight] set 
backlight level = 27961

Set the brightness to the minimum value when the brightness is less or
equal to the minimum value to mitigate this flickering.

Cc : Tejas Upadhyay 
Cc : Matt Roper 
Cc : Ville Syrjälä 
Signed-off-by: Gareth Yu 
---
 drivers/gpu/drm/i915/display/intel_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 3f3cd944a1c5..855d6ead905c 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -762,7 +762,7 @@ static void __intel_backlight_enable(const struct 
intel_crtc_state *crtc_state,
WARN_ON(panel->backlight.max == 0);
 
if (panel->backlight.level <= panel->backlight.min) {
-   panel->backlight.level = panel->backlight.max;
+   panel->backlight.level = panel->backlight.min;
if (panel->backlight.device)
panel->backlight.device->props.brightness =
scale_hw_to_user(connector,
-- 
2.25.1

✗ Fi.CI.BUILD: failure for drm/i915/gem: Execbuffer objects must have struct pages.

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Execbuffer objects must have struct pages.
URL   : https://patchwork.freedesktop.org/series/131000/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c: In function 
‘eb_requests_create’:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3318:60: error: ‘obj’ undeclared 
(first use in this function)
 3318 |   !i915_gem_object_has_struct_page(eb->batches[i]->vma-obj)) {
  |^~~
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3318:60: note: each undeclared 
identifier is reported only once for each function it appears in
make[6]: *** [scripts/Makefile.build:243: 
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o] Error 1
make[5]: *** [scripts/Makefile.build:481: drivers/gpu/drm/i915] Error 2
make[4]: *** [scripts/Makefile.build:481: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:481: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:481: drivers] Error 2
make[1]: *** [/home/kbuild/kernel/Makefile:1921: .] Error 2
make: *** [Makefile:240: __sub-make] Error 2
Build failed, no error log produced

✓ Fi.CI.BAT: success for drm/i915/hwmon: Fix locking inversion in sysfs getter (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Fix locking inversion in sysfs getter (rev2)
URL   : https://patchwork.freedesktop.org/series/130966/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130966v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 35)
--

  Additional (2): fi-glk-j4005 bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

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

  * igt@i915_selftest@live@gt_mocs:
- bat-dg2-8:  [PASS][11] -> [ABORT][12] ([i915#10366])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@i915_selftest@live@gt_mocs.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-dg2-8/igt@i915_selftest@live@gt_mocs.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4212]) +8 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

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

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-mtlp-8/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][17]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html
- bat-mtlp-8: NOTRUN -> [SKIP][18]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-mtlp-8/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#5274])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130966v2/bat-mtlp-8/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_frontbuffer_tracking@basic:
- bat-adlm-1: NOTRUN -> [SKIP][20] ([i915#1849] / 

✗ Fi.CI.CHECKPATCH: warning for drm/i915/hwmon: Fix locking inversion in sysfs getter (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hwmon: Fix locking inversion in sysfs getter (rev2)
URL   : https://patchwork.freedesktop.org/series/130966/
State : warning

== Summary ==

Error: dim checkpatch failed
876b08387035 drm/i915/hwmon: Fix locking inversion in sysfs getter
-:14: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#14: 
<4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
__kmalloc+0x9a/0x350

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

✗ Fi.CI.BAT: failure for series starting with drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers (rev3)

[Patchwork]

== Series Details ==

Series: series starting with drm/xe: Introduce xe_pm_runtime_get_noresume for 
inner callers (rev3)
URL   : https://patchwork.freedesktop.org/series/130995/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130995v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_130995v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_130995v3, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_130995v3/index.html

Participating hosts (34 -> 35)
--

  Additional (2): bat-kbl-2 bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_close_race@basic-process:
- bat-dg2-8:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@gem_close_r...@basic-process.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-dg2-8/igt@gem_close_r...@basic-process.html
- bat-mtlp-6: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-mtlp-6/igt@gem_close_r...@basic-process.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-mtlp-6/igt@gem_close_r...@basic-process.html

  * igt@gem_close_race@basic-threads:
- fi-kbl-guc: [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-kbl-guc/igt@gem_close_r...@basic-threads.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/fi-kbl-guc/igt@gem_close_r...@basic-threads.html

  * igt@gem_ctx_create@basic:
- bat-adlm-1: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-adlm-1/igt@gem_ctx_cre...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-adlm-1/igt@gem_ctx_cre...@basic.html

  * igt@i915_module_load@load:
- bat-atsm-1: [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-atsm-1/igt@i915_module_l...@load.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-atsm-1/igt@i915_module_l...@load.html
- fi-kbl-x1275:   [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-kbl-x1275/igt@i915_module_l...@load.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/fi-kbl-x1275/igt@i915_module_l...@load.html

  * igt@kms_busy@basic@flip:
- fi-pnv-d510:[PASS][13] -> [ABORT][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-pnv-d510/igt@kms_busy@ba...@flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/fi-pnv-d510/igt@kms_busy@ba...@flip.html

  * igt@kms_busy@basic@modeset:
- bat-dg1-7:  [PASS][15] -> [ABORT][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg1-7/igt@kms_busy@ba...@modeset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-dg1-7/igt@kms_busy@ba...@modeset.html
- bat-adln-1: [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-adln-1/igt@kms_busy@ba...@modeset.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-adln-1/igt@kms_busy@ba...@modeset.html
- bat-rplp-1: [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-rplp-1/igt@kms_busy@ba...@modeset.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-rplp-1/igt@kms_busy@ba...@modeset.html
- bat-arls-2: [PASS][21] -> [ABORT][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-arls-2/igt@kms_busy@ba...@modeset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/bat-arls-2/igt@kms_busy@ba...@modeset.html
- fi-ivb-3770:[PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-ivb-3770/igt@kms_busy@ba...@modeset.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/fi-ivb-3770/igt@kms_busy@ba...@modeset.html
- fi-ilk-650: [PASS][25] -> [INCOMPLETE][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-ilk-650/igt@kms_busy@ba...@modeset.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130995v3/fi-ilk-650/igt@kms_busy@ba...@modeset.html
- bat-arls-1: [PASS][27] -> [ABORT][28]
   [27]: 

✗ Fi.CI.SPARSE: warning for series starting with drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers (rev3)

[Patchwork]

== Series Details ==

Series: series starting with drm/xe: Introduce xe_pm_runtime_get_noresume for 
inner callers (rev3)
URL   : https://patchwork.freedesktop.org/series/130995/
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:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238: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'

✓ Fi.CI.BAT: success for drm/i915/dp: Fix DSC state HW readout for SST connectors

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Fix DSC state HW readout for SST connectors
URL   : https://patchwork.freedesktop.org/series/130986/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130986v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 35)
--

  Additional (2): fi-glk-j4005 bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-tgl-1115g4:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-tgl-1115g4/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/fi-tgl-1115g4/boot.html
- fi-cfl-8109u:   [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/fi-cfl-8109u/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/fi-cfl-8109u/boot.html

  

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html

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

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

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

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

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

  * igt@i915_pm_rpm@module-reload:
- bat-dg2-8:  [PASS][13] -> [SKIP][14] ([i915#9980])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/bat-dg2-8/igt@i915_pm_...@module-reload.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#6621])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/bat-mtlp-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_130986v1/bat-adlm-1/igt@i915_pm_...@basic-api.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#4212]) +8 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005:   NOTRUN -> [SKIP][19] +10 other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130986v1/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

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

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][21] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [21]: 

✗ Fi.CI.BAT: failure for Enable Adaptive Sync SDP Support for DP (rev17)

[Patchwork]

== Series Details ==

Series: Enable Adaptive Sync SDP Support for DP (rev17)
URL   : https://patchwork.freedesktop.org/series/126829/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_126829v17


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_126829v17 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_126829v17, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_126829v17/index.html

Participating hosts (34 -> 34)
--

  Additional (1): bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-arls-2: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-arls-2/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-arls-2/igt@i915_module_l...@load.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

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

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

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#6621])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-mtlp-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_126829v17/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@client:
- bat-dg2-9:  [PASS][13] -> [ABORT][14] ([i915#10366])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-9/igt@i915_selftest@l...@client.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-dg2-9/igt@i915_selftest@l...@client.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4212]) +8 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

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

  * igt@kms_dsc@dsc-basic:
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#3555] / [i915#3840] / 
[i915#9159])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v17/bat-mtlp-8/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- 

✗ Fi.CI.SPARSE: warning for Enable Adaptive Sync SDP Support for DP (rev17)

[Patchwork]

== Series Details ==

Series: Enable Adaptive Sync SDP Support for DP (rev17)
URL   : https://patchwork.freedesktop.org/series/126829/
State : warning

== Summary ==

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

✗ Fi.CI.CHECKPATCH: warning for Enable Adaptive Sync SDP Support for DP (rev17)

[Patchwork]

== Series Details ==

Series: Enable Adaptive Sync SDP Support for DP (rev17)
URL   : https://patchwork.freedesktop.org/series/126829/
State : warning

== Summary ==

Error: dim checkpatch failed
451ab13b0a0e drm/dp: Add support to indicate if sink supports AS SDP
cf5877afd69f drm: Add Adaptive Sync SDP logging
529200b2ef1b drm/i915/display: Add crtc state dump for Adaptive Sync SDP
8cfc759e1670 drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
a7d90662a729 drm/i915/dp: Add wrapper function to check AS SDP
69dde4f36a05 drm/i915/display: Compute AS SDP parameters
3da2b9b06759 drm/i915/display: Add state checker for Adaptive Sync SDP
-:72: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible 
side-effects?
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:5137:
+#define PIPE_CONF_CHECK_DP_AS_SDP(name) do { \
+   if (!intel_compare_dp_as_sdp(_config->infoframes.name, \
+ _config->infoframes.name)) { \
+   pipe_config_dp_as_sdp_mismatch(dev_priv, fastset, 
__stringify(name), \
+   
_config->infoframes.name, \
+   _config->infoframes.name); 
\
+   ret = false; \
+   } \
+} while (0)

total: 0 errors, 0 warnings, 1 checks, 70 lines checked
408e5b3132b5 drm/i915/display: Compute vrr_vsync params
8e3b370f2c2f drm/i915/display: Read/Write Adaptive Sync SDP

✗ Fi.CI.BAT: failure for drm: fix .get_modes() return values (rev2)

[Patchwork]

== Series Details ==

Series: drm: fix .get_modes() return values (rev2)
URL   : https://patchwork.freedesktop.org/series/130926/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130926v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_130926v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_130926v2, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_130926v2/index.html

Participating hosts (34 -> 34)
--

  Additional (2): fi-glk-j4005 bat-mtlp-8 
  Missing(2): bat-dg1-7 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@requests:
- bat-atsm-1: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-atsm-1/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130926v2/bat-atsm-1/igt@i915_selftest@l...@requests.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][5] ([i915#4613]) +3 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130926v2/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html

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

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

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

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

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

  * igt@i915_selftest@live@guc_multi_lrc:
- bat-dg2-8:  [PASS][11] -> [ABORT][12] ([i915#10366])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@i915_selftest@live@guc_multi_lrc.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130926v2/bat-dg2-8/igt@i915_selftest@live@guc_multi_lrc.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4212]) +8 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130926v2/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005:   NOTRUN -> [SKIP][15] +10 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130926v2/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

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

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

  * 

✗ Fi.CI.SPARSE: warning for drm: fix .get_modes() return values (rev2)

[Patchwork]

== Series Details ==

Series: drm: fix .get_modes() return values (rev2)
URL   : https://patchwork.freedesktop.org/series/130926/
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:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'

✓ Fi.CI.BAT: success for drm/i915/dp: Enable AUX based backlight for HDR (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Enable AUX based backlight for HDR (rev4)
URL   : https://patchwork.freedesktop.org/series/130729/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130729v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 35)
--

  Additional (2): fi-glk-j4005 bat-kbl-2 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- bat-adlp-9: [PASS][7] -> [ABORT][8] ([i915#10021])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-adlp-9/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlp-9/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-adlm-1: NOTRUN -> [SKIP][11] ([i915#9875] / [i915#9900]) +6 
other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html

  * igt@kms_pm_backlight@basic-brightness:
- bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#5354])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@kms_pm_backli...@basic-brightness.html

  * igt@kms_pm_rpm@basic-pci-d3-state:
- bat-dg2-8:  [PASS][13] -> [ABORT][14] ([i915#10367])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@kms_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-dg2-8/igt@kms_pm_...@basic-pci-d3-state.html

  * igt@kms_psr@psr-primary-page-flip:
- fi-glk-j4005:   NOTRUN -> [SKIP][15] +10 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/fi-glk-j4005/igt@kms_...@psr-primary-page-flip.html

  * igt@kms_psr@psr-sprite-plane-onoff:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#9673] / [i915#9732]) +3 
other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@kms_...@psr-sprite-plane-onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#3555])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- bat-adlm-1: NOTRUN -> [SKIP][18] ([i915#3708] / [i915#9900])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-write:
- bat-adlm-1: NOTRUN -> [SKIP][19] ([i915#3708]) +2 other tests skip
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130729v4/bat-adlm-1/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@i915_selftest@live@perf:
- bat-dg2-14: [ABORT][20] ([i915#10366]) -> [PASS][21]
   [20]: 

[drm-intel:for-linux-next 4/6] drivers/gpu/drm/i915/display/intel_bios.c:3417:24: error: implicit declaration of function 'intel_opregion_vbt_present'; did you mean 'intel_opregion_asle_present'?

[kernel test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   0e7dd6fe96020e6b7f5e068bf1c66078e0b145d3
commit: 9d9bb71f3e115b75ec5e38f087e159a87fc0413a [4/6] drm/i915: Extract 
opregion vbt presence check
config: sparc64-allmodconfig 
(https://download.01.org/0day-ci/archive/20240312/202403120756.jtkghcip-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240312/202403120756.jtkghcip-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202403120756.jtkghcip-...@intel.com/

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/display/intel_bios.c: In function 
'intel_bios_is_lvds_present':
>> drivers/gpu/drm/i915/display/intel_bios.c:3417:24: error: implicit 
>> declaration of function 'intel_opregion_vbt_present'; did you mean 
>> 'intel_opregion_asle_present'? [-Werror=implicit-function-declaration]
3417 | return intel_opregion_vbt_present(i915);
 |^~
 |intel_opregion_asle_present
   cc1: some warnings being treated as errors


vim +3417 drivers/gpu/drm/i915/display/intel_bios.c

  3374  
  3375  /**
  3376   * intel_bios_is_lvds_present - is LVDS present in VBT
  3377   * @i915:   i915 device instance
  3378   * @i2c_pin:i2c pin for LVDS if present
  3379   *
  3380   * Return true if LVDS is present. If no child devices were parsed from 
VBT,
  3381   * assume LVDS is present.
  3382   */
  3383  bool intel_bios_is_lvds_present(struct drm_i915_private *i915, u8 
*i2c_pin)
  3384  {
  3385  const struct intel_bios_encoder_data *devdata;
  3386  
  3387  if (list_empty(>display.vbt.display_devices))
  3388  return true;
  3389  
  3390  list_for_each_entry(devdata, 
>display.vbt.display_devices, node) {
  3391  const struct child_device_config *child = 
>child;
  3392  
  3393  /* If the device type is not LFP, continue.
  3394   * We have to check both the new identifiers as well as 
the
  3395   * old for compatibility with some BIOSes.
  3396   */
  3397  if (child->device_type != DEVICE_TYPE_INT_LFP &&
  3398  child->device_type != DEVICE_TYPE_LFP)
  3399  continue;
  3400  
  3401  if (intel_gmbus_is_valid_pin(i915, child->i2c_pin))
  3402  *i2c_pin = child->i2c_pin;
  3403  
  3404  /* However, we cannot trust the BIOS writers to populate
  3405   * the VBT correctly.  Since LVDS requires additional
  3406   * information from AIM blocks, a non-zero addin offset 
is
  3407   * a good indicator that the LVDS is actually present.
  3408   */
  3409  if (child->addin_offset)
  3410  return true;
  3411  
  3412  /* But even then some BIOS writers perform some black 
magic
  3413   * and instantiate the device without reference to any
  3414   * additional data.  Trust that if the VBT was written 
into
  3415   * the OpRegion then they have validated the LVDS's 
existence.
  3416   */
> 3417  return intel_opregion_vbt_present(i915);
  3418  }
  3419  
  3420  return false;
  3421  }
  3422  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

✗ Fi.CI.BAT: failure for drm/i915/dp: Increase idle pattern wait timeout to 2ms (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Increase idle pattern wait timeout to 2ms (rev4)
URL   : https://patchwork.freedesktop.org/series/130643/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14420 -> Patchwork_130643v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_130643v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_130643v4, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_130643v4/index.html

Participating hosts (34 -> 36)
--

  Additional (3): fi-glk-j4005 bat-kbl-2 bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_force_connector_basic@force-edid:
- bat-dg2-8:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-8/igt@kms_force_connector_ba...@force-edid.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-dg2-8/igt@kms_force_connector_ba...@force-edid.html

  * igt@vgem_basic@unload:
- bat-arls-2: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-arls-2/igt@vgem_ba...@unload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-arls-2/igt@vgem_ba...@unload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][8] +39 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
- bat-mtlp-8: NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-glk-j4005:   NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/fi-glk-j4005/igt@gem_lmem_swapp...@parallel-random-engines.html

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-14: [PASS][15] -> [ABORT][16] ([i915#10366])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14420/bat-dg2-14/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-dg2-14/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#4212]) +8 other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130643v4/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-mtlp-8: NOTRUN -> 

[PATCH v2] Fix divide-by-zero regression on DP MST unplug with nouveau

[Chris Bainbridge]

Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP
DisplaypPort 1.2 MST hub (the same regression does not appear when using
a Cable Matters DisplayPort 1.4 MST hub). Trace:

 divide error:  [#1] PREEMPT SMP PTI
 CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
 Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 
31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 
f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
 RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
 RAX:  RBX:  RCX: 00f59b00
 RDX:  RSI:  RDI: 
 RBP: b2c5c211fa48 R08: 0001 R09: 0020
 R10: 0004 R11:  R12: 00023b4a
 R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
 FS:  7f4a1ca3fa80() GS:91d6edbc() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0
 Call Trace:
  
  ? show_regs+0x6d/0x80
  ? die+0x37/0xa0
  ? do_trap+0xd4/0xf0
  ? do_error_trap+0x71/0xb0
  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
  ? exc_divide_error+0x3a/0x70
  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
  ? asm_exc_divide_error+0x1b/0x20
  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
  ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
  nv50_msto_atomic_check+0xda/0x120 [nouveau]
  drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
  drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
  nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
  drm_atomic_check_only+0x668/0xb20 [drm]
  ? drm_connector_list_iter_next+0x86/0xc0 [drm]
  drm_atomic_commit+0x58/0xd0 [drm]
  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
  drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
  drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
  ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
  drm_connector_property_set_ioctl+0x3b/0x60 [drm]
  drm_ioctl_kernel+0xb9/0x120 [drm]
  drm_ioctl+0x2d0/0x550 [drm]
  ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
  nouveau_drm_ioctl+0x61/0xc0 [nouveau]
  __x64_sys_ioctl+0xa0/0xf0
  do_syscall_64+0x76/0x140
  ? do_syscall_64+0x85/0x140
  ? do_syscall_64+0x85/0x140
  entry_SYSCALL_64_after_hwframe+0x6e/0x76
 RIP: 0033:0x7f4a1cd1a94f
 Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 
08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 
77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
 RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010
 RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
 RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
 RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0
 R10:  R11: 0246 R12: 56347938a220
 R13: 000f R14: 563479d9f3f0 R15: 
  
 Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat 
nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user 
xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp 
llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc 
snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci 
snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils 
snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress 
snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr 
intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp 
mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek 
snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg 
snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb 
videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul 
snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic 
snd_rawmidi
  ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd 
snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 mei_hdcp 
thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt cfg80211 
snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer i2c_smbus ecc 
snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek libahci idma64 
intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel msr parport_pc 
ppdev lp parport efi_pstore ip_tables x_tables autofs4 dm_crypt raid10 raid456 
libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx 
raid6_pq raid1 raid0 joydev input_leds hid_generic usbhid hid nouveau i915 
drm_ttm_helper gpu_sched drm_gpuvm drm_exec i2c_algo_bit drm_buddy ttm 
drm_display_helper drm_kms_helper cec rc_core drm nvme 

Re: [PATCH 6/8] drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changes

[Gustavo Sousa]

Quoting Lisovskiy, Stanislav (2024-03-11 18:01:04-03:00)
>On Mon, Mar 04, 2024 at 03:30:25PM -0300, Gustavo Sousa wrote:
>> Commit 394b4b7df9f7 ("drm/i915/lnl: Add CDCLK table") and commit
>> 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL") started
>> adding support for CDCLK programming support for Xe2LPD. One final piece
>> is missing, which is the programming necessary for changed in the ratio
>> between MDCLK and CDCLK. Let's do that now.
>> 
>> BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the
>> ratio between MDCLK and CDCLK changes. The updates must be done before
>> changing the CDCLK when decreasing the frequency; or after it when
>> increasing the frequency.
>> 
>> Ratio-related updates to MBUS_CTL also depend on the state of MBus
>> joining, so they are performed by either CDCLK change sequence or by
>> changes in MBus joining. Since one might happen independently of the
>> other, we need to make sure that both logics see the necessary state
>> values when programming that register. MBus joining logic needs to know
>> the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio
>> field of struct intel_dbuf_state.
>> 
>> For the CDCLK logic, we need to have something similar: we need to
>> propagate the status of MBus joining to struct intel_cdclk_state. Do
>> that by adding the field joined_mbus to struct intel_cdclk_config.
>> (Preferably, that field would be added to intel_cdclk_state, however
>> currently only intel_cdclk_config is passed down to the functions that
>> do the register programming. We might revisit this decision if we find
>> that refactoring the code to pass the whole intel_cdclk_state is worth
>> it.)
>> 
>> Bspec: 68864, 68868, 69090, 69482
>> Signed-off-by: Gustavo Sousa 
>> ---
>>  drivers/gpu/drm/i915/display/intel_cdclk.c| 31 ++
>>  drivers/gpu/drm/i915/display/intel_cdclk.h|  3 ++
>>  drivers/gpu/drm/i915/display/skl_watermark.c  | 40 +++
>>  drivers/gpu/drm/i915/display/skl_watermark.h  |  1 +
>>  .../gpu/drm/i915/display/skl_watermark_regs.h | 18 +
>>  5 files changed, 77 insertions(+), 16 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> index 04a6e9806254..12753589072d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> @@ -40,6 +40,7 @@
>>  #include "intel_psr.h"
>>  #include "intel_vdsc.h"
>>  #include "skl_watermark.h"
>> +#include "skl_watermark_regs.h"
>>  #include "vlv_sideband.h"
>>  
>>  /**
>> @@ -1683,6 +1684,8 @@ static void bxt_get_cdclk(struct drm_i915_private 
>> *dev_priv,
>>  }
>>  
>>   out:
>> +if (DISPLAY_VER(dev_priv) >= 20)
>> +cdclk_config->joined_mbus = intel_de_read(dev_priv, 
>> MBUS_CTL) & MBUS_JOIN;
>>  /*
>>   * Can't read this out :( Let's assume it's
>>   * at least what the CDCLK frequency requires.
>> @@ -1908,6 +1911,14 @@ u8 intel_mdclk_cdclk_ratio(struct drm_i915_private 
>> *i915,
>>  }
>>  }
>>  
>> +static void xe2lpd_mdclk_cdclk_ratio_program(struct drm_i915_private *i915,
>> + const struct 
>> intel_cdclk_config *cdclk_config)
>> +{
>> +intel_dbuf_mdclk_cdclk_ratio_update(i915,
>> +intel_mdclk_cdclk_ratio(i915, 
>> cdclk_config),
>> +cdclk_config->joined_mbus);
>> +}
>> +
>>  static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private 
>> *i915,
>>  const struct 
>> intel_cdclk_config *old_cdclk_config,
>>  const struct 
>> intel_cdclk_config *new_cdclk_config,
>> @@ -2089,6 +2100,9 @@ static void bxt_set_cdclk(struct drm_i915_private 
>> *dev_priv,
>>  return;
>>  }
>>  
>> +if (DISPLAY_VER(dev_priv) >= 20 && cdclk < 
>> dev_priv->display.cdclk.hw.cdclk)
>> +xe2lpd_mdclk_cdclk_ratio_program(dev_priv, cdclk_config);
>> +
>>  if (cdclk_compute_crawl_and_squash_midpoint(dev_priv, 
>> _priv->display.cdclk.hw,
>>  cdclk_config, 
>> _cdclk_config)) {
>>  _bxt_set_cdclk(dev_priv, _cdclk_config, pipe);
>> @@ -2097,6 +2111,9 @@ static void bxt_set_cdclk(struct drm_i915_private 
>> *dev_priv,
>>  _bxt_set_cdclk(dev_priv, cdclk_config, pipe);
>>  }
>>  
>> +if (DISPLAY_VER(dev_priv) >= 20 && cdclk > 
>> dev_priv->display.cdclk.hw.cdclk)
>> +xe2lpd_mdclk_cdclk_ratio_program(dev_priv, cdclk_config);
>> +
>>  if (DISPLAY_VER(dev_priv) >= 14)
>>  /*
>>   * NOOP - No Pcode communication needed for
>> @@ -3179,6 +3196,20 @@ int intel_cdclk_atomic_check(struct 
>> intel_atomic_state *state,

Re: [PATCH 6/8] drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changes

[Lisovskiy, Stanislav]

On Mon, Mar 04, 2024 at 03:30:25PM -0300, Gustavo Sousa wrote:
> Commit 394b4b7df9f7 ("drm/i915/lnl: Add CDCLK table") and commit
> 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL") started
> adding support for CDCLK programming support for Xe2LPD. One final piece
> is missing, which is the programming necessary for changed in the ratio
> between MDCLK and CDCLK. Let's do that now.
> 
> BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the
> ratio between MDCLK and CDCLK changes. The updates must be done before
> changing the CDCLK when decreasing the frequency; or after it when
> increasing the frequency.
> 
> Ratio-related updates to MBUS_CTL also depend on the state of MBus
> joining, so they are performed by either CDCLK change sequence or by
> changes in MBus joining. Since one might happen independently of the
> other, we need to make sure that both logics see the necessary state
> values when programming that register. MBus joining logic needs to know
> the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio
> field of struct intel_dbuf_state.
> 
> For the CDCLK logic, we need to have something similar: we need to
> propagate the status of MBus joining to struct intel_cdclk_state. Do
> that by adding the field joined_mbus to struct intel_cdclk_config.
> (Preferably, that field would be added to intel_cdclk_state, however
> currently only intel_cdclk_config is passed down to the functions that
> do the register programming. We might revisit this decision if we find
> that refactoring the code to pass the whole intel_cdclk_state is worth
> it.)
> 
> Bspec: 68864, 68868, 69090, 69482
> Signed-off-by: Gustavo Sousa 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c| 31 ++
>  drivers/gpu/drm/i915/display/intel_cdclk.h|  3 ++
>  drivers/gpu/drm/i915/display/skl_watermark.c  | 40 +++
>  drivers/gpu/drm/i915/display/skl_watermark.h  |  1 +
>  .../gpu/drm/i915/display/skl_watermark_regs.h | 18 +
>  5 files changed, 77 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 04a6e9806254..12753589072d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -40,6 +40,7 @@
>  #include "intel_psr.h"
>  #include "intel_vdsc.h"
>  #include "skl_watermark.h"
> +#include "skl_watermark_regs.h"
>  #include "vlv_sideband.h"
>  
>  /**
> @@ -1683,6 +1684,8 @@ static void bxt_get_cdclk(struct drm_i915_private 
> *dev_priv,
>   }
>  
>   out:
> + if (DISPLAY_VER(dev_priv) >= 20)
> + cdclk_config->joined_mbus = intel_de_read(dev_priv, MBUS_CTL) & 
> MBUS_JOIN;
>   /*
>* Can't read this out :( Let's assume it's
>* at least what the CDCLK frequency requires.
> @@ -1908,6 +1911,14 @@ u8 intel_mdclk_cdclk_ratio(struct drm_i915_private 
> *i915,
>   }
>  }
>  
> +static void xe2lpd_mdclk_cdclk_ratio_program(struct drm_i915_private *i915,
> +  const struct intel_cdclk_config 
> *cdclk_config)
> +{
> + intel_dbuf_mdclk_cdclk_ratio_update(i915,
> + intel_mdclk_cdclk_ratio(i915, 
> cdclk_config),
> + cdclk_config->joined_mbus);
> +}
> +
>  static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private 
> *i915,
>   const struct 
> intel_cdclk_config *old_cdclk_config,
>   const struct 
> intel_cdclk_config *new_cdclk_config,
> @@ -2089,6 +2100,9 @@ static void bxt_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   return;
>   }
>  
> + if (DISPLAY_VER(dev_priv) >= 20 && cdclk < 
> dev_priv->display.cdclk.hw.cdclk)
> + xe2lpd_mdclk_cdclk_ratio_program(dev_priv, cdclk_config);
> +
>   if (cdclk_compute_crawl_and_squash_midpoint(dev_priv, 
> _priv->display.cdclk.hw,
>   cdclk_config, 
> _cdclk_config)) {
>   _bxt_set_cdclk(dev_priv, _cdclk_config, pipe);
> @@ -2097,6 +2111,9 @@ static void bxt_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   _bxt_set_cdclk(dev_priv, cdclk_config, pipe);
>   }
>  
> + if (DISPLAY_VER(dev_priv) >= 20 && cdclk > 
> dev_priv->display.cdclk.hw.cdclk)
> + xe2lpd_mdclk_cdclk_ratio_program(dev_priv, cdclk_config);
> +
>   if (DISPLAY_VER(dev_priv) >= 14)
>   /*
>* NOOP - No Pcode communication needed for
> @@ -3179,6 +3196,20 @@ int intel_cdclk_atomic_check(struct intel_atomic_state 
> *state,
>   return 0;
>  }
>  
> +int intel_cdclk_state_set_joined_mbus(struct intel_atomic_state *state, bool 
> joined_mbus)
> +{
> + struct intel_cdclk_state *cdclk_state;
> +
> + cdclk_state = intel_atomic_get_cdclk_state(state);
> + if 

[PATCH] drm/i915/gem: Execbuffer objects must have struct pages.

[Jonathan Cavitt]

We cannot write requests to objects without struct pages, so escape
early if the requests are bound to objects that lack them.

Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3a771afb083e..e680f78ce34d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3313,6 +3313,13 @@ eb_requests_create(struct i915_execbuffer *eb, struct 
dma_fence *in_fence,
unsigned int i;
 
for_each_batch_create_order(eb, i) {
+   /* Do not write requests to objects without struct pages. */
+   if (eb->batches[i]->vma &&
+   !i915_gem_object_has_struct_page(eb->batches[i]->vma-obj)) {
+   out_fence = ERR_PTR(-EINVAL);
+   return out_fence;
+   }
+
/* Allocate a request for this batch buffer nice and early. */
eb->requests[i] = i915_request_create(eb_find_context(eb, i));
if (IS_ERR(eb->requests[i])) {
-- 
2.25.1

[PATCH v2] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Janusz Krzysztofik]

In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
rpm wakeref.  That results in lock inversion:

<4> [197.079335] ==
<4> [197.085473] WARNING: possible circular locking dependency detected
<4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
<4> [197.098096] --
<4> [197.104231] prometheus-node/839 is trying to acquire lock:
<4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
__kmalloc+0x9a/0x350
<4> [197.116939]
but task is already holding lock:
<4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
hwm_energy+0x4b/0x100 [i915]
<4> [197.131543]
which lock already depends on the new lock.
...
<4> [197.507922] Chain exists of:
  fs_reclaim --> >reset.mutex --> >hwmon_lock
<4> [197.518528]  Possible unsafe locking scenario:
<4> [197.524411]CPU0CPU1
<4> [197.528916]
<4> [197.533418]   lock(>hwmon_lock);
<4> [197.537237]lock(>reset.mutex);
<4> [197.543376]lock(>hwmon_lock);
<4> [197.549682]   lock(fs_reclaim);
...
<4> [197.632548] Call Trace:
<4> [197.634990]  
<4> [197.637088]  dump_stack_lvl+0x64/0xb0
<4> [197.640738]  check_noncircular+0x15e/0x180
<4> [197.652968]  check_prev_add+0xe9/0xce0
<4> [197.656705]  __lock_acquire+0x179f/0x2300
<4> [197.660694]  lock_acquire+0xd8/0x2d0
<4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
<4> [197.680478]  __kmalloc+0x9a/0x350
<4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
<4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
<4> [197.720608]  acpi_ns_get_node+0x3b/0x60
<4> [197.724428]  acpi_get_handle+0x57/0xb0
<4> [197.728164]  acpi_has_method+0x20/0x50
<4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
<4> [197.736485]  pci_power_up+0x24/0x1c0
<4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
<4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
<4> [197.753911]  __rpm_callback+0x3c/0x110
<4> [197.762586]  rpm_callback+0x58/0x70
<4> [197.766064]  rpm_resume+0x51e/0x730
<4> [197.769542]  rpm_resume+0x267/0x730
<4> [197.773020]  rpm_resume+0x267/0x730
<4> [197.776498]  rpm_resume+0x267/0x730
<4> [197.779974]  __pm_runtime_resume+0x49/0x90
<4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
<4> [197.789070]  hwm_energy+0x55/0x100 [i915]
<4> [197.793183]  hwm_read+0x9a/0x310 [i915]
<4> [197.797124]  hwmon_attr_show+0x36/0x120
<4> [197.800946]  dev_attr_show+0x15/0x60
<4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100

Acquire the wakeref before the lock and hold it as long as the lock is
also held.  Follow that pattern across the whole source file where similar
lock inversion can happen.

v2: Keep hardware read under the lock so the whole operation of updating
energy from hardware is still atomic (Guenter),
  - instead, acquire the rpm wakeref before the lock and hold it as long
as the lock is held,
  - use the same aproach for other similar places across the i915_hwmon.c
source file (Rodrigo).

Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
Signed-off-by: Janusz Krzysztofik 
Cc: Rodrigo Vivi 
Cc: Guenter Roeck 
Cc:  # v6.2+
---
 drivers/gpu/drm/i915/i915_hwmon.c | 37 ---
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8c3f443c8347e..b758fd110c204 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -72,12 +72,13 @@ hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata 
*ddat,
struct intel_uncore *uncore = ddat->uncore;
intel_wakeref_t wakeref;
 
-   mutex_lock(>hwmon_lock);
+   with_intel_runtime_pm(uncore->rpm, wakeref) {
+   mutex_lock(>hwmon_lock);
 
-   with_intel_runtime_pm(uncore->rpm, wakeref)
intel_uncore_rmw(uncore, reg, clear, set);
 
-   mutex_unlock(>hwmon_lock);
+   mutex_unlock(>hwmon_lock);
+   }
 }
 
 /*
@@ -136,20 +137,21 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
else
rgaddr = hwmon->rg.energy_status_all;
 
-   mutex_lock(>hwmon_lock);
+   with_intel_runtime_pm(uncore->rpm, wakeref) {
+   mutex_lock(>hwmon_lock);
 
-   with_intel_runtime_pm(uncore->rpm, wakeref)
reg_val = intel_uncore_read(uncore, rgaddr);
 
-   if (reg_val >= ei->reg_val_prev)
-   ei->accum_energy += reg_val - ei->reg_val_prev;
-   else
-   ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
-   ei->reg_val_prev = reg_val;
+   if (reg_val >= ei->reg_val_prev)
+   ei->accum_energy += reg_val - ei->reg_val_prev;
+   else
+   ei->accum_energy += UINT_MAX - ei->reg_val_prev + 
reg_val;
+   ei->reg_val_prev = reg_val;

[PATCH] drm/xe: Introduce intel_runtime_pm_get_noresume at compat-i915-headers for display

[Rodrigo Vivi]

The i915-display will start using the intel_runtime_pm_noresume.
So we need to add the compat header before it.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h 
b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
index fef969112b1d..ecaaef3df4bf 100644
--- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
+++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
@@ -176,6 +176,14 @@ static inline intel_wakeref_t 
intel_runtime_pm_get_if_in_use(struct xe_runtime_p
return xe_pm_runtime_get_if_in_use(xe);
 }
 
+static inline intel_wakeref_t intel_runtime_pm_get_noresume(struct 
xe_runtime_pm *pm)
+{
+   struct xe_device *xe = container_of(pm, struct xe_device, runtime_pm);
+
+   xe_pm_runtime_get_noresume(xe);
+   return true;
+}
+
 static inline void intel_runtime_pm_put_unchecked(struct xe_runtime_pm *pm)
 {
struct xe_device *xe = container_of(pm, struct xe_device, runtime_pm);
-- 
2.44.0

[PATCH] drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers

[Rodrigo Vivi]

Let's ensure that we have an option for inner callers that will
raise WARN if device is not active and not protected by outer callers.

Make this also a void function forcing every caller to unconditionally
put the reference back afterwards.

This will be very important for cases where we want to hold the
reference before scheduling a work in a queue. Then the work job
will be responsible for putting it back.

While at this, already convert a case from mem_access_ongoing where
it is not checking for the reference and put it back, what would
cause the underflow.

v2: Fix identation.

Reviewed-by: Matthew Auld 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_exec_queue.c |  2 +-
 drivers/gpu/drm/xe/xe_pm.c | 20 
 drivers/gpu/drm/xe/xe_pm.h |  1 +
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c 
b/drivers/gpu/drm/xe/xe_exec_queue.c
index 6a83bc57826a..f69a9c99329c 100644
--- a/drivers/gpu/drm/xe/xe_exec_queue.c
+++ b/drivers/gpu/drm/xe/xe_exec_queue.c
@@ -128,7 +128,7 @@ static int __xe_exec_queue_init(struct xe_exec_queue *q)
 * already grabbed the rpm ref outside any sensitive locks.
 */
if (!(q->flags & EXEC_QUEUE_FLAG_PERMANENT) && (q->flags & 
EXEC_QUEUE_FLAG_VM || !q->vm))
-   drm_WARN_ON(>drm, !xe_device_mem_access_get_if_ongoing(xe));
+   xe_pm_runtime_get_noresume(xe);
 
return 0;
 
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 9fbb6f6c598a..2e1362cf8deb 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -477,6 +477,26 @@ bool xe_pm_runtime_get_if_in_use(struct xe_device *xe)
return pm_runtime_get_if_in_use(xe->drm.dev) > 0;
 }
 
+/**
+ * xe_pm_runtime_get_noresume - Bump runtime PM usage counter without resuming
+ * @xe: xe device instance
+ *
+ * This function should be used in inner places where it is surely already
+ * protected by outer-bound callers of `xe_pm_runtime_get`.
+ * It will warn if not protected.
+ * The reference should be put back after this function regardless, since it
+ * will always bump the usage counter, regardless.
+ */
+void xe_pm_runtime_get_noresume(struct xe_device *xe)
+{
+   bool ref;
+
+   ref = xe_pm_runtime_get_if_in_use(xe);
+
+   if (drm_WARN(>drm, !ref, "Missing outer runtime PM protection\n"))
+   pm_runtime_get_noresume(xe->drm.dev);
+}
+
 /**
  * xe_pm_runtime_resume_and_get - Resume, then get a runtime_pm ref if awake.
  * @xe: xe device instance
diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h
index 0cb38ca244fe..119b630ad1d1 100644
--- a/drivers/gpu/drm/xe/xe_pm.h
+++ b/drivers/gpu/drm/xe/xe_pm.h
@@ -31,6 +31,7 @@ int xe_pm_runtime_get_ioctl(struct xe_device *xe);
 void xe_pm_runtime_put(struct xe_device *xe);
 int xe_pm_runtime_get_if_active(struct xe_device *xe);
 bool xe_pm_runtime_get_if_in_use(struct xe_device *xe);
+void xe_pm_runtime_get_noresume(struct xe_device *xe);
 bool xe_pm_runtime_resume_and_get(struct xe_device *xe);
 void xe_pm_assert_unbounded_bridge(struct xe_device *xe);
 int xe_pm_set_vram_threshold(struct xe_device *xe, u32 threshold);
-- 
2.44.0

Re: [PATCH 0/5] drm/i915: cleanup dead code

[Lucas De Marchi]

On Mon, Mar 11, 2024 at 05:43:00PM +, Tvrtko Ursulin wrote:


On 06/03/2024 19:36, Lucas De Marchi wrote:

Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by subsequent ones, so it's
not a huge amount of code being removed.


I had PVC and xehpsdv back in October but could not collect all acks. :(

Last two patches from https://patchwork.freedesktop.org/series/124705/.


oh... I was actually surprised we still had xehpsdv while removing a
WA for PVC, which made me look into removing these platforms.

rebasing your series and comparing yours..my-v2, where my-v2 only has
patches 2 and 4, I have the diff below. I think it's small enough that I
can just take your commits and squash delta. Is that ok to you?

my version is a little bit more aggressive, also doing some renames
s/xehpsdv/xehp/ and dropping some more code
(engine_mask_apply_copy_fuses(), unused registers, default ctx, fw
ranges).

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h
index 8a8fcd4fceac..bc26dc126104 100644
--- a/Documentation/gpu/rfc/i915_vm_bind.h
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence {
  * Multiple VA mappings can be created to the same section of the 
object
  * (aliasing).
  *
- * The @start, @offset and @length must be 4K page aligned. However 
the DG2
- * and XEHPSDV has 64K page size for device local memory and has 
compact page
- * table. On those platforms, for binding device local-memory objects, 
the
- * @start, @offset and @length must be 64K aligned. Also, UMDs should 
not mix
- * the local memory 64K page and the system memory 4K page bindings in 
the same
- * 2M range.
+ * The @start, @offset and @length must be 4K page aligned. However 
the DG2 has
+ * 64K page size for device local memory and has compact page table. 
On that
+ * platform, for binding device local-memory objects, the @start, 
@offset and
+ * @length must be 64K aligned. Also, UMDs should not mix the local 
memory 64K
+ * page and the system memory 4K page bindings in the same 2M range.
  *
  * Error code -EINVAL will be returned if @start, @offset and @length 
are not
  * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), 
error code
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 1495b6074492..d3300ae3053f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -386,7 +386,7 @@ struct drm_i915_gem_object {
 * and kernel mode driver for caching policy control after 
GEN12.
 * In the meantime platform specific tables are created to 
translate
 * i915_cache_level into pat index, for more details check the 
macros
-* defined i915/i915_pci.c, e.g. TGL_CACHELEVEL.
+* defined i915/i915_pci.c, e.g. MTL_CACHELEVEL.
 * For backward compatibility, this field contains values 
exactly match
 * the entries of enum i915_cache_level for pre-GEN12 platforms 
(See
 * LEGACY_CACHELEVEL), so that the PTE encode functions for 
these
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index fa46d2308b0e..1bd0e041e15c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -500,11 +500,11 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
 }
	 
	 static void

-xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
- struct i915_vma_resource *vma_res,
- struct sgt_dma *iter,
- unsigned int pat_index,
- u32 flags)
+xehp_ppgtt_insert_huge(struct i915_address_space *vm,
+  struct i915_vma_resource *vma_res,
+  struct sgt_dma *iter,
+  unsigned int pat_index,
+  u32 flags)
 {
const gen8_pte_t pte_encode = vm->pte_encode(0, pat_index, 
flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct 
i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
	 
		if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {

-   if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
-   xehpsdv_ppgtt_insert_huge(vm, vma_res, , 
pat_index, 

[PATCH 11/11] drm/xe: Kill xe_device_mem_access_{get*,put}

[Rodrigo Vivi]

Let's simply convert all the current callers towards direct
xe_pm_runtime access and remove this extra layer of indirection.

v2: Convert all the current callers instead of a big refactor
at once.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/display/xe_fb_pin.c |  7 ++---
 drivers/gpu/drm/xe/xe_bo.c |  8 +++---
 drivers/gpu/drm/xe/xe_device.c | 36 --
 drivers/gpu/drm/xe/xe_device.h |  3 ---
 drivers/gpu/drm/xe/xe_device_types.h   |  3 ---
 drivers/gpu/drm/xe/xe_exec_queue.c |  6 ++---
 drivers/gpu/drm/xe/xe_ggtt.c   |  9 ---
 drivers/gpu/drm/xe/xe_sched_job.c  |  5 ++--
 drivers/gpu/drm/xe/xe_vm.c |  6 ++---
 9 files changed, 22 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c 
b/drivers/gpu/drm/xe/display/xe_fb_pin.c
index 722c84a56607..403ed2d42f6b 100644
--- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
+++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
@@ -10,6 +10,7 @@
 #include "intel_fb_pin.h"
 #include "xe_ggtt.h"
 #include "xe_gt.h"
+#include "xe_pm.h"
 
 #include 
 
@@ -190,7 +191,7 @@ static int __xe_pin_fb_vma_ggtt(struct intel_framebuffer 
*fb,
/* TODO: Consider sharing framebuffer mapping?
 * embed i915_vma inside intel_framebuffer
 */
-   xe_device_mem_access_get(tile_to_xe(ggtt->tile));
+   xe_pm_runtime_get_noresume(tile_to_xe(ggtt->tile));
ret = mutex_lock_interruptible(>lock);
if (ret)
goto out;
@@ -242,7 +243,7 @@ static int __xe_pin_fb_vma_ggtt(struct intel_framebuffer 
*fb,
 out_unlock:
mutex_unlock(>lock);
 out:
-   xe_device_mem_access_put(tile_to_xe(ggtt->tile));
+   xe_pm_runtime_put(tile_to_xe(ggtt->tile));
return ret;
 }
 
@@ -381,4 +382,4 @@ struct i915_address_space *intel_dpt_create(struct 
intel_framebuffer *fb)
 void intel_dpt_destroy(struct i915_address_space *vm)
 {
return;
-}
\ No newline at end of file
+}
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index bc0cc5edc533..531c67083e2c 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -738,7 +738,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, 
bool evict,
 
xe_assert(xe, migrate);
trace_xe_bo_move(bo, new_mem->mem_type, old_mem_type, 
move_lacks_source);
-   xe_device_mem_access_get(xe);
+   xe_pm_runtime_get_noresume(xe);
 
if (xe_bo_is_pinned(bo) && !xe_bo_is_user(bo)) {
/*
@@ -762,7 +762,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, 
bool evict,
 
if (XE_WARN_ON(new_mem->start == 
XE_BO_INVALID_OFFSET)) {
ret = -EINVAL;
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
goto out;
}
 
@@ -780,7 +780,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, 
bool evict,
new_mem, handle_system_ccs);
if (IS_ERR(fence)) {
ret = PTR_ERR(fence);
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
goto out;
}
if (!move_lacks_source) {
@@ -805,7 +805,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, 
bool evict,
dma_fence_put(fence);
}
 
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
 
 out:
return ret;
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 58815e9bf242..e2e6b6dc8534 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -655,42 +655,6 @@ void xe_device_assert_mem_access(struct xe_device *xe)
XE_WARN_ON(xe_pm_runtime_suspended(xe));
 }
 
-void xe_device_mem_access_get(struct xe_device *xe)
-{
-   int ref;
-
-   /*
-* This looks racy, but should be fine since the pm_callback_task only
-* transitions from NULL -> current (and back to NULL again), during the
-* runtime_resume() or runtime_suspend() callbacks, for which there can
-* only be a single one running for our device. We only need to prevent
-* recursively calling the runtime_get or runtime_put from those
-* callbacks, as well as preventing triggering any access_ongoing
-* asserts.
-*/
-   if (xe_pm_read_callback_task(xe) == current)
-   return;
-
-   xe_pm_runtime_get_noresume(xe);
-   ref = atomic_inc_return(>mem_access.ref);
-
-   xe_assert(xe, ref != S32_MAX);
-
-}
-
-void xe_device_mem_access_put(struct xe_device *xe)
-{
-   int ref;
-
-   if (xe_pm_read_callback_task(xe) == current)
-   return;
-
-   ref = 

[PATCH 10/11] drm/xe: Ensure all the inner access are using the _noresume variant

[Rodrigo Vivi]

At this point mem_access references should be only used as inner
points of the execution and a get with synchronous resume previously
called at an outer point.

So, before killing mem_acces in favor of direct accsess, let's
ensure that we first convert them towards the new _noresume
variant that will WARN us if no inner caller happened.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/xe_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 6c7850dd70b5..58815e9bf242 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -671,7 +671,7 @@ void xe_device_mem_access_get(struct xe_device *xe)
if (xe_pm_read_callback_task(xe) == current)
return;
 
-   xe_pm_runtime_get(xe);
+   xe_pm_runtime_get_noresume(xe);
ref = atomic_inc_return(>mem_access.ref);
 
xe_assert(xe, ref != S32_MAX);
-- 
2.44.0

[PATCH 09/11] drm/xe: Convert mem_access_if_ongoing to direct xe_pm_runtime_get_if_active

[Rodrigo Vivi]

Now that assert_mem_access is relying directly on the pm_runtime state
instead of the counters, there's no reason why we cannot use
the pm_runtime functions directly.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/xe_device.c | 17 -
 drivers/gpu/drm/xe/xe_device.h |  1 -
 drivers/gpu/drm/xe/xe_guc_ct.c |  8 
 3 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index a9128bde85c1..6c7850dd70b5 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -655,23 +655,6 @@ void xe_device_assert_mem_access(struct xe_device *xe)
XE_WARN_ON(xe_pm_runtime_suspended(xe));
 }
 
-bool xe_device_mem_access_get_if_ongoing(struct xe_device *xe)
-{
-   bool active;
-
-   if (xe_pm_read_callback_task(xe) == current)
-   return true;
-
-   active = xe_pm_runtime_get_if_active(xe);
-   if (active) {
-   int ref = atomic_inc_return(>mem_access.ref);
-
-   xe_assert(xe, ref != S32_MAX);
-   }
-
-   return active;
-}
-
 void xe_device_mem_access_get(struct xe_device *xe)
 {
int ref;
diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
index 2327b6c0ae6a..b45592b0bf19 100644
--- a/drivers/gpu/drm/xe/xe_device.h
+++ b/drivers/gpu/drm/xe/xe_device.h
@@ -134,7 +134,6 @@ static inline struct xe_force_wake *gt_to_fw(struct xe_gt 
*gt)
 }
 
 void xe_device_mem_access_get(struct xe_device *xe);
-bool xe_device_mem_access_get_if_ongoing(struct xe_device *xe);
 void xe_device_mem_access_put(struct xe_device *xe);
 
 void xe_device_assert_mem_access(struct xe_device *xe);
diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 355edd4d758a..8d7b1b42b2e6 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -1203,7 +1203,7 @@ void xe_guc_ct_fast_path(struct xe_guc_ct *ct)
bool ongoing;
int len;
 
-   ongoing = xe_device_mem_access_get_if_ongoing(ct_to_xe(ct));
+   ongoing = xe_pm_runtime_get_if_active(ct_to_xe(ct));
if (!ongoing && xe_pm_read_callback_task(ct_to_xe(ct)) == NULL)
return;
 
@@ -1216,7 +1216,7 @@ void xe_guc_ct_fast_path(struct xe_guc_ct *ct)
spin_unlock(>fast_lock);
 
if (ongoing)
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
 }
 
 /* Returns less than zero on error, 0 on done, 1 on more available */
@@ -1273,7 +1273,7 @@ static void g2h_worker_func(struct work_struct *w)
 * responses, if the worker here is blocked on those callbacks
 * completing, creating a deadlock.
 */
-   ongoing = xe_device_mem_access_get_if_ongoing(ct_to_xe(ct));
+   ongoing = xe_pm_runtime_get_if_active(ct_to_xe(ct));
if (!ongoing && xe_pm_read_callback_task(ct_to_xe(ct)) == NULL)
return;
 
@@ -1292,7 +1292,7 @@ static void g2h_worker_func(struct work_struct *w)
} while (ret == 1);
 
if (ongoing)
-   xe_device_mem_access_put(ct_to_xe(ct));
+   xe_pm_runtime_put(ct_to_xe(ct));
 }
 
 static void guc_ctb_snapshot_capture(struct xe_device *xe, struct guc_ctb *ctb,
-- 
2.44.0

[PATCH 07/11] drm/xe: Convert xe_gem_fault to use direct xe_pm_runtime calls

[Rodrigo Vivi]

The gem page fault is one of the outer bound protections where
we want to ensure that the hardware is in D0 before proceeding
with memory access. Let's convert it towards the xe_pm_runtime
functions directly so we can then convert the mem_access to be
inner protection only and then Kill it for good.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/xe_bo.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index b89ac6db68a1..bc0cc5edc533 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -22,6 +22,7 @@
 #include "xe_gt.h"
 #include "xe_map.h"
 #include "xe_migrate.h"
+#include "xe_pm.h"
 #include "xe_preempt_fence.h"
 #include "xe_res_cursor.h"
 #include "xe_trace.h"
@@ -1136,7 +1137,7 @@ static vm_fault_t xe_gem_fault(struct vm_fault *vmf)
int idx, r = 0;
 
if (needs_rpm)
-   xe_device_mem_access_get(xe);
+   xe_pm_runtime_get(xe);
 
ret = ttm_bo_vm_reserve(tbo, vmf);
if (ret)
@@ -1176,7 +1177,7 @@ static vm_fault_t xe_gem_fault(struct vm_fault *vmf)
dma_resv_unlock(tbo->base.resv);
 out:
if (needs_rpm)
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
 
return ret;
 }
-- 
2.44.0

[PATCH 08/11] drm/xe: Removing extra mem_access protection from runtime pm

[Rodrigo Vivi]

This is not needed any longer, now that we have all the protection
in place with the runtime pm itself.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/xe_device.c | 8 
 drivers/gpu/drm/xe/xe_device.h | 1 -
 drivers/gpu/drm/xe/xe_pm.c | 3 ---
 3 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 49a413725c8f..a9128bde85c1 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -639,14 +639,6 @@ u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size)
DIV_ROUND_UP_ULL(size, NUM_BYTES_PER_CCS_BYTE(xe)) : 0;
 }
 
-bool xe_device_mem_access_ongoing(struct xe_device *xe)
-{
-   if (xe_pm_read_callback_task(xe) != NULL)
-   return true;
-
-   return atomic_read(>mem_access.ref);
-}
-
 /**
  * xe_device_assert_mem_access - Inspect the current runtime_pm state.
  * @xe: xe device instance
diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
index 2653f53bee4e..2327b6c0ae6a 100644
--- a/drivers/gpu/drm/xe/xe_device.h
+++ b/drivers/gpu/drm/xe/xe_device.h
@@ -138,7 +138,6 @@ bool xe_device_mem_access_get_if_ongoing(struct xe_device 
*xe);
 void xe_device_mem_access_put(struct xe_device *xe);
 
 void xe_device_assert_mem_access(struct xe_device *xe);
-bool xe_device_mem_access_ongoing(struct xe_device *xe);
 
 static inline bool xe_device_in_fault_mode(struct xe_device *xe)
 {
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 393f14411ae0..3e92f09b8d83 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -296,9 +296,6 @@ int xe_pm_runtime_suspend(struct xe_device *xe)
u8 id;
int err = 0;
 
-   if (xe->d3cold.allowed && xe_device_mem_access_ongoing(xe))
-   return -EBUSY;
-
/* Disable access_ongoing asserts and prevent recursive pm calls */
xe_pm_write_callback_task(xe, current);
 
-- 
2.44.0

[PATCH 06/11] drm/xe: Remove useless mem_access during probe

[Rodrigo Vivi]

xe_pm_init is the very last thing during the xe_pci_probe(),
hence these protections are useless from the point of view
of ensuring that the device is awake.

Let's remove it so we continue towards the goal of killing
xe_device_mem_access.

v2: Adding more cases
v3: Provide a separate fix for xe_tile_init_noalloc return (Matt)
Adding a new case where display HDCP init calls which
are also called at display probe time.

Cc: Matthew Auld 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/display/xe_hdcp_gsc.c |  2 --
 drivers/gpu/drm/xe/xe_ggtt.c |  2 --
 drivers/gpu/drm/xe/xe_gt.c   |  9 -
 drivers/gpu/drm/xe/xe_tile.c | 15 +--
 drivers/gpu/drm/xe/xe_uc.c   | 11 ---
 5 files changed, 5 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c 
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index a221f0cf4bac..b2bd56a9b76d 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -70,7 +70,6 @@ static int intel_hdcp_gsc_initialize_message(struct xe_device 
*xe,
int ret = 0;
 
/* allocate object of two page for HDCP command memory and store it */
-   xe_device_mem_access_get(xe);
bo = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe), NULL, 
PAGE_SIZE * 2,
  ttm_bo_type_kernel,
  XE_BO_CREATE_SYSTEM_BIT |
@@ -90,7 +89,6 @@ static int intel_hdcp_gsc_initialize_message(struct xe_device 
*xe,
hdcp_message->hdcp_cmd_in = cmd_in;
hdcp_message->hdcp_cmd_out = cmd_out;
 out:
-   xe_device_mem_access_put(xe);
return ret;
 }
 
diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
index 325337c38961..0f96b7db6dcc 100644
--- a/drivers/gpu/drm/xe/xe_ggtt.c
+++ b/drivers/gpu/drm/xe/xe_ggtt.c
@@ -206,14 +206,12 @@ static void xe_ggtt_initial_clear(struct xe_ggtt *ggtt)
u64 start, end;
 
/* Display may have allocated inside ggtt, so be careful with clearing 
here */
-   xe_device_mem_access_get(tile_to_xe(ggtt->tile));
mutex_lock(>lock);
drm_mm_for_each_hole(hole, >mm, start, end)
xe_ggtt_clear(ggtt, start, end - start);
 
xe_ggtt_invalidate(ggtt);
mutex_unlock(>lock);
-   xe_device_mem_access_put(tile_to_xe(ggtt->tile));
 }
 
 int xe_ggtt_init(struct xe_ggtt *ggtt)
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index 85408e7a932b..063b710a8c7b 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/gpu/drm/xe/xe_gt.c
@@ -347,7 +347,6 @@ static int gt_fw_domain_init(struct xe_gt *gt)
 {
int err, i;
 
-   xe_device_mem_access_get(gt_to_xe(gt));
err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
if (err)
goto err_hw_fence_irq;
@@ -389,7 +388,6 @@ static int gt_fw_domain_init(struct xe_gt *gt)
 
err = xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
XE_WARN_ON(err);
-   xe_device_mem_access_put(gt_to_xe(gt));
 
return 0;
 
@@ -399,7 +397,6 @@ static int gt_fw_domain_init(struct xe_gt *gt)
 err_hw_fence_irq:
for (i = 0; i < XE_ENGINE_CLASS_MAX; ++i)
xe_hw_fence_irq_finish(>fence_irq[i]);
-   xe_device_mem_access_put(gt_to_xe(gt));
 
return err;
 }
@@ -408,7 +405,6 @@ static int all_fw_domain_init(struct xe_gt *gt)
 {
int err, i;
 
-   xe_device_mem_access_get(gt_to_xe(gt));
err = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
if (err)
goto err_hw_fence_irq;
@@ -474,7 +470,6 @@ static int all_fw_domain_init(struct xe_gt *gt)
 
err = xe_force_wake_put(gt_to_fw(gt), XE_FORCEWAKE_ALL);
XE_WARN_ON(err);
-   xe_device_mem_access_put(gt_to_xe(gt));
 
return 0;
 
@@ -483,7 +478,6 @@ static int all_fw_domain_init(struct xe_gt *gt)
 err_hw_fence_irq:
for (i = 0; i < XE_ENGINE_CLASS_MAX; ++i)
xe_hw_fence_irq_finish(>fence_irq[i]);
-   xe_device_mem_access_put(gt_to_xe(gt));
 
return err;
 }
@@ -496,7 +490,6 @@ int xe_gt_init_hwconfig(struct xe_gt *gt)
 {
int err;
 
-   xe_device_mem_access_get(gt_to_xe(gt));
err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
if (err)
goto out;
@@ -519,8 +512,6 @@ int xe_gt_init_hwconfig(struct xe_gt *gt)
 out_fw:
xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
 out:
-   xe_device_mem_access_put(gt_to_xe(gt));
-
return err;
 }
 
diff --git a/drivers/gpu/drm/xe/xe_tile.c b/drivers/gpu/drm/xe/xe_tile.c
index 0650b2fa75ef..74ecb5f39438 100644
--- a/drivers/gpu/drm/xe/xe_tile.c
+++ b/drivers/gpu/drm/xe/xe_tile.c
@@ -160,24 +160,19 @@ int xe_tile_init_noalloc(struct xe_tile *tile)
 {
int err;
 
-   xe_device_mem_access_get(tile_to_xe(tile));
-
err = tile_ttm_mgr_init(tile);
if (err)
-   goto err_mem_access;
+   

[PATCH 05/11] drm/xe: Convert GSC HDCP from mem_access to direct xe_pm_runtime calls

[Rodrigo Vivi]

We need to convert so we can continue to kill the mem_access.

At this point we should be protected by the display wakerefs already,
so let's use the noresume variant.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c 
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 25c73602ef55..a221f0cf4bac 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -217,7 +217,7 @@ ssize_t intel_hdcp_gsc_msg_send(struct xe_device *xe, u8 
*msg_in,
addr_out_off = PAGE_SIZE;
 
host_session_id = xe_gsc_create_host_session_id();
-   xe_device_mem_access_get(xe);
+   xe_pm_runtime_get_noresume(xe);
addr_in_wr_off = xe_gsc_emit_header(xe, _message->hdcp_bo->vmap,
addr_in_wr_off, HECI_MEADDRESS_HDCP,
host_session_id, msg_in_len);
@@ -249,6 +249,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct xe_device *xe, u8 
*msg_in,
   msg_out_len);
 
 out:
-   xe_device_mem_access_put(xe);
+   xe_pm_runtime_put(xe);
return ret;
 }
-- 
2.44.0

[PATCH 04/11] drm/xe: Move lockdep protection from mem_access to xe_pm_runtime

[Rodrigo Vivi]

The mem_access itself is not holding any lock, but attempting
to train lockdep with possible scarring locks happening during
runtime pm. We are going soon to kill the mem_access get and put
helpers in favor of direct xe_pm_runtime calls, so let's just
move this lock around to where it now belongs.

v2: s/lockdep_training/lockdep_prime (Matt Auld)

Reviewed-by: Matthew Auld 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/xe_device.c | 23 -
 drivers/gpu/drm/xe/xe_device.h |  4 ---
 drivers/gpu/drm/xe/xe_pm.c | 45 --
 3 files changed, 37 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 919ad88f0495..49a413725c8f 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -45,12 +45,6 @@
 #include "xe_vm.h"
 #include "xe_wait_user_fence.h"
 
-#ifdef CONFIG_LOCKDEP
-struct lockdep_map xe_device_mem_access_lockdep_map = {
-   .name = "xe_device_mem_access_lockdep_map"
-};
-#endif
-
 static int xe_file_open(struct drm_device *dev, struct drm_file *file)
 {
struct xe_device *xe = to_xe_device(dev);
@@ -702,23 +696,6 @@ void xe_device_mem_access_get(struct xe_device *xe)
if (xe_pm_read_callback_task(xe) == current)
return;
 
-   /*
-* Since the resume here is synchronous it can be quite easy to deadlock
-* if we are not careful. Also in practice it might be quite timing
-* sensitive to ever see the 0 -> 1 transition with the callers locks
-* held, so deadlocks might exist but are hard for lockdep to ever see.
-* With this in mind, help lockdep learn about the potentially scary
-* stuff that can happen inside the runtime_resume callback by acquiring
-* a dummy lock (it doesn't protect anything and gets compiled out on
-* non-debug builds).  Lockdep then only needs to see the
-* mem_access_lockdep_map -> runtime_resume callback once, and then can
-* hopefully validate all the (callers_locks) -> mem_access_lockdep_map.
-* For example if the (callers_locks) are ever grabbed in the
-* runtime_resume callback, lockdep should give us a nice splat.
-*/
-   lock_map_acquire(_device_mem_access_lockdep_map);
-   lock_map_release(_device_mem_access_lockdep_map);
-
xe_pm_runtime_get(xe);
ref = atomic_inc_return(>mem_access.ref);
 
diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
index 14be34d9f543..2653f53bee4e 100644
--- a/drivers/gpu/drm/xe/xe_device.h
+++ b/drivers/gpu/drm/xe/xe_device.h
@@ -16,10 +16,6 @@ struct xe_file;
 #include "xe_force_wake.h"
 #include "xe_macros.h"
 
-#ifdef CONFIG_LOCKDEP
-extern struct lockdep_map xe_device_mem_access_lockdep_map;
-#endif
-
 static inline struct xe_device *to_xe_device(const struct drm_device *dev)
 {
return container_of(dev, struct xe_device, drm);
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 847b263afe70..393f14411ae0 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -68,6 +68,12 @@
  * management (RPS).
  */
 
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map xe_pm_runtime_lockdep_map = {
+   .name = "xe_pm_runtime_lockdep_map"
+};
+#endif
+
 /**
  * xe_pm_suspend - Helper for System suspend, i.e. S0->S3 / S0->S2idle
  * @xe: xe device instance
@@ -297,11 +303,11 @@ int xe_pm_runtime_suspend(struct xe_device *xe)
xe_pm_write_callback_task(xe, current);
 
/*
-* The actual xe_device_mem_access_put() is always async underneath, so
+* The actual xe_pm_runtime_put() is always async underneath, so
 * exactly where that is called should makes no difference to us. 
However
 * we still need to be very careful with the locks that this callback
 * acquires and the locks that are acquired and held by any callers of
-* xe_device_mem_access_get(). We already have the matching annotation
+* xe_runtime_pm_get(). We already have the matching annotation
 * on that side, but we also need it here. For example lockdep should be
 * able to tell us if the following scenario is in theory possible:
 *
@@ -309,15 +315,15 @@ int xe_pm_runtime_suspend(struct xe_device *xe)
 * lock(A)   |
 *   | xe_pm_runtime_suspend()
 *   |  lock(A)
-* xe_device_mem_access_get()|
+* xe_pm_runtime_get()   |
 *
 * This will clearly deadlock since rpm core needs to wait for
 * xe_pm_runtime_suspend() to complete, but here we are holding lock(A)
 * on CPU0 which prevents CPU1 making forward progress.  With the
-* annotation here and in xe_device_mem_access_get() lockdep will see
+* annotation here and in xe_pm_runtime_get() lockdep will see
 * the 

[PATCH 01/11] drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers

[Rodrigo Vivi]

Let's ensure that we have an option for inner callers that will
raise WARN if device is not active and not protected by outer callers.

Make this also a void function forcing every caller to unconditionally
put the reference back afterwards.

This will be very important for cases where we want to hold the
reference before scheduling a work in a queue. Then the work job
will be responsible for putting it back.

While at this, already convert a case from mem_access_ongoing where
it is not checking for the reference and put it back, what would
cause the underflow.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/xe/xe_exec_queue.c |  2 +-
 drivers/gpu/drm/xe/xe_pm.c | 20 
 drivers/gpu/drm/xe/xe_pm.h |  1 +
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c 
b/drivers/gpu/drm/xe/xe_exec_queue.c
index 6a83bc57826a..f69a9c99329c 100644
--- a/drivers/gpu/drm/xe/xe_exec_queue.c
+++ b/drivers/gpu/drm/xe/xe_exec_queue.c
@@ -128,7 +128,7 @@ static int __xe_exec_queue_init(struct xe_exec_queue *q)
 * already grabbed the rpm ref outside any sensitive locks.
 */
if (!(q->flags & EXEC_QUEUE_FLAG_PERMANENT) && (q->flags & 
EXEC_QUEUE_FLAG_VM || !q->vm))
-   drm_WARN_ON(>drm, !xe_device_mem_access_get_if_ongoing(xe));
+   xe_pm_runtime_get_noresume(xe);
 
return 0;
 
diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
index 9fbb6f6c598a..847b263afe70 100644
--- a/drivers/gpu/drm/xe/xe_pm.c
+++ b/drivers/gpu/drm/xe/xe_pm.c
@@ -477,6 +477,26 @@ bool xe_pm_runtime_get_if_in_use(struct xe_device *xe)
return pm_runtime_get_if_in_use(xe->drm.dev) > 0;
 }
 
+/**
+ * xe_pm_runtime_get_noresume - Bump runtime PM usage counter without resuming
+ * @xe: xe device instance
+ *
+ * This function should be used in inner places where it is surely already
+ * protected by outer-bound callers of `xe_pm_runtime_get`.
+ * It will warn if not protected.
+ * The reference should be put back after this function regardless, since it
+ * will always bump the usage counter, regardless.
+ */
+void xe_pm_runtime_get_noresume(struct xe_device *xe)
+{
+  bool ref;
+
+  ref = xe_pm_runtime_get_if_in_use(xe);
+
+  if (drm_WARN(>drm, !ref, "Missing outer runtime PM protection\n"))
+ pm_runtime_get_noresume(xe->drm.dev);
+}
+
 /**
  * xe_pm_runtime_resume_and_get - Resume, then get a runtime_pm ref if awake.
  * @xe: xe device instance
diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h
index 0cb38ca244fe..119b630ad1d1 100644
--- a/drivers/gpu/drm/xe/xe_pm.h
+++ b/drivers/gpu/drm/xe/xe_pm.h
@@ -31,6 +31,7 @@ int xe_pm_runtime_get_ioctl(struct xe_device *xe);
 void xe_pm_runtime_put(struct xe_device *xe);
 int xe_pm_runtime_get_if_active(struct xe_device *xe);
 bool xe_pm_runtime_get_if_in_use(struct xe_device *xe);
+void xe_pm_runtime_get_noresume(struct xe_device *xe);
 bool xe_pm_runtime_resume_and_get(struct xe_device *xe);
 void xe_pm_assert_unbounded_bridge(struct xe_device *xe);
 int xe_pm_set_vram_threshold(struct xe_device *xe, u32 threshold);
-- 
2.44.0

[PATCH 03/11] drm/i915/display: convert inner wakeref get towards get_if_in_use

[Rodrigo Vivi]

This patch brings no functional change. Since at this point of
the code we are already asserting a wakeref was held, it means
that we are with runtime_pm 'in_use' and in practical terms we
are only bumping the pm_runtime usage counter and moving on.

However, xe driver has a lockdep annotation that warned us that
if a sync resume was actually called at this point, we could have
a deadlock because we are inside the power_domains->lock locked
area and the resume would call the irq_reset, which would also
try to get the power_domains->lock.

For this reason, let's convert this call to a safer option and
calm lockdep on.

v2: use _noresume variant instead of get_in_use (Ville, Imre)

Cc: Ville Syrjälä 
Acked-by: Imre Deak 
Cc: Matthew Auld 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 6fd4fa52253a..048943d0a881 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -646,7 +646,7 @@ release_async_put_domains(struct i915_power_domains 
*power_domains,
 * power well disabling.
 */
assert_rpm_raw_wakeref_held(rpm);
-   wakeref = intel_runtime_pm_get(rpm);
+   wakeref = intel_runtime_pm_get_noresume(rpm);
 
for_each_power_domain(domain, mask) {
/* Clear before put, so put's sanity check is happy. */
-- 
2.44.0

[PATCH 02/11] drm/xe: Introduce intel_runtime_pm_get_noresume at compat-i915-headers for display

[Rodrigo Vivi]

The i915-display will start using the intel_runtime_pm_noresume.
So we need to add the compat header before it.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h 
b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
index fef969112b1d..84fda436faab 100644
--- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
+++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
@@ -176,6 +176,13 @@ static inline intel_wakeref_t 
intel_runtime_pm_get_if_in_use(struct xe_runtime_p
return xe_pm_runtime_get_if_in_use(xe);
 }
 
+static inline intel_wakeref_t intel_runtime_pm_get_noresume(struct 
xe_runtime_pm *pm)
+{
+   struct xe_device *xe = container_of(pm, struct xe_device, runtime_pm);
+   xe_pm_runtime_get_noresume(xe);
+   return true;
+}
+
 static inline void intel_runtime_pm_put_unchecked(struct xe_runtime_pm *pm)
 {
struct xe_device *xe = container_of(pm, struct xe_device, runtime_pm);
-- 
2.44.0

Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Rodrigo Vivi]

On Mon, Mar 11, 2024 at 07:14:09PM +0100, Janusz Krzysztofik wrote:
> On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> > On 3/11/24 09:58, Rodrigo Vivi wrote:
> > > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> > >> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> > >> rpm wakeref.  That results in lock inversion:
> > >>
> > >> <4> [197.079335] ==
> > >> <4> [197.085473] WARNING: possible circular locking dependency detected
> > >> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not 
> > >> tainted
> > >> <4> [197.098096] --
> > >> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> > >> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
> > >> __kmalloc+0x9a/0x350
> > >> <4> [197.116939]
> > >> but task is already holding lock:
> > >> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
> > >> hwm_energy+0x4b/0x100 [i915]
> > >> <4> [197.131543]
> > >> which lock already depends on the new lock.
> > >> ...
> > >> <4> [197.507922] Chain exists of:
> > >>fs_reclaim --> >reset.mutex --> >hwmon_lock
> > >> <4> [197.518528]  Possible unsafe locking scenario:
> > >> <4> [197.524411]CPU0CPU1
> > >> <4> [197.528916]
> > >> <4> [197.533418]   lock(>hwmon_lock);
> > >> <4> [197.537237]lock(>reset.mutex);
> > >> <4> [197.543376]lock(>hwmon_lock);
> > >> <4> [197.549682]   lock(fs_reclaim);
> > >> ...
> > >> <4> [197.632548] Call Trace:
> > >> <4> [197.634990]  
> > >> <4> [197.637088]  dump_stack_lvl+0x64/0xb0
> > >> <4> [197.640738]  check_noncircular+0x15e/0x180
> > >> <4> [197.652968]  check_prev_add+0xe9/0xce0
> > >> <4> [197.656705]  __lock_acquire+0x179f/0x2300
> > >> <4> [197.660694]  lock_acquire+0xd8/0x2d0
> > >> <4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
> > >> <4> [197.680478]  __kmalloc+0x9a/0x350
> > >> <4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
> > >> <4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
> > >> <4> [197.720608]  acpi_ns_get_node+0x3b/0x60
> > >> <4> [197.724428]  acpi_get_handle+0x57/0xb0
> > >> <4> [197.728164]  acpi_has_method+0x20/0x50
> > >> <4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
> > >> <4> [197.736485]  pci_power_up+0x24/0x1c0
> > >> <4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
> > >> <4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
> > >> <4> [197.753911]  __rpm_callback+0x3c/0x110
> > >> <4> [197.762586]  rpm_callback+0x58/0x70
> > >> <4> [197.766064]  rpm_resume+0x51e/0x730
> > >> <4> [197.769542]  rpm_resume+0x267/0x730
> > >> <4> [197.773020]  rpm_resume+0x267/0x730
> > >> <4> [197.776498]  rpm_resume+0x267/0x730
> > >> <4> [197.779974]  __pm_runtime_resume+0x49/0x90
> > >> <4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
> > >> <4> [197.789070]  hwm_energy+0x55/0x100 [i915]
> > >> <4> [197.793183]  hwm_read+0x9a/0x310 [i915]
> > >> <4> [197.797124]  hwmon_attr_show+0x36/0x120
> > >> <4> [197.800946]  dev_attr_show+0x15/0x60
> > >> <4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100
> > >>
> > >> However, the lock is only intended to protect either a hwmon overflow
> > >> counter or rmw hardware operations.  There is no need to hold the lock,
> > >> only the wakeref, while reading from hardware.
> > >>
> > >> Acquire the lock after hardware read under rpm wakeref.
> > >>
> > >> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> > >> Signed-off-by: Janusz Krzysztofik 
> > >> Cc:  # v6.2+
> > >> ---
> > >>   drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> > >>   1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> > >> b/drivers/gpu/drm/i915/i915_hwmon.c
> > >> index 8c3f443c8347e..faf7670de6e06 100644
> > >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > >> @@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
> > >>  else
> > >>  rgaddr = hwmon->rg.energy_status_all;
> > >>   
> > >> -mutex_lock(>hwmon_lock);
> > >> -
> > >>  with_intel_runtime_pm(uncore->rpm, wakeref)
> > >>  reg_val = intel_uncore_read(uncore, rgaddr);
> > >>   
> > >> +mutex_lock(>hwmon_lock);
> > >> +
> > > 
> > > This is not enough.
> > > check hwm_locked_with_pm_intel_uncore_rmw()
> > > 
> > > It looks like we need to rethink this lock entirely here.
> > > 
> > 
> > I would have assumed that the lock was supposed to ensure that
> > reading the register value and the subsequent update of accum_energy
> > and reg_val_prev was synchronized. This is no longer the case
> > after this patch has been applied. Given that, I would agree that
> > it would make sense to define what the lock is supposed to protect

Re: [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use

[Rodrigo Vivi]

On Mon, Mar 11, 2024 at 05:06:32PM +0200, Imre Deak wrote:
> On Fri, Mar 08, 2024 at 10:19:58AM -0500, Rodrigo Vivi wrote:
> > [...]
> > > 
> > > The difference between a wakeref (aka wakelock) and a raw-wakeref is
> > > that the former is required for accessing the HW, which is asserted when
> > > reading/writing a register. A raw-wakeref is not enough for this and is
> > > only taken to prevent runtime suspending, for instance held after
> > > dropping a display power reference, until the power well is actually
> > > disabled in a delayed manner. During this time any register access is
> > > considered invalid.
> > 
> > ah okay, so it is not just about the GT, but also about MMIO accesses.
> > So the ones in display looks better now. Thanks for this correction.
> > 
> > > 
> > > Both wakerefs and raw-wakerefs are tracked.
> > 
> > Indeed. And also it is worth to say that this patch doesn't introduce
> > any change on that.
> > 
> > both
> > intel_runtime_pm_get()
> > and
> > intel_runtime_pm_get_if_in_use()
> > 
> > calls
> > intel_runtime_pm_acquire(rpm, true);
> > return track_intel_runtime_pm_wakeref(rpm);
> > 
> > so, can we move forward with this change or do you guys see any blocker?
> 
> I also think intel_runtime_pm_get_noresume() would be more logical here,
> as it's already known that rpm->usecount is non-zero,
> intel_runtime_pm_get_if_in_use() also works though. Either way:

Well, I can also go with the noresume version since my plan is to merge
this through drm-xe-next anyway along with the rest of this series.

However I will need to move this to the top of the series,
because xe's noresume is introduced later. And introduce
the xe compat layer version of the intel_runtime_pm_get_noresume()

A stand alone version of this patch with the noresume would break
drm-tip build:

../drivers/gpu/drm/i915/display/intel_display_power.c: In function 
‘release_async_put_domains’:
../drivers/gpu/drm/i915/display/intel_display_power.c:649:19: error: implicit 
declaration of function ‘intel_runtime_pm_get_noresume’; did you mean 
‘intel_runtime_pm_get_if_in_use’? [-Werror=implicit-function-declaration]
  649 | wakeref = intel_runtime_pm_get_noresume(rpm);
  |   ^
  |   intel_runtime_pm_get_if_in_use
make[3]: *** [../drivers/gpu/drm/xe/Makefile:185: 
drivers/gpu/drm/xe/i915-display/intel_display_power.o] Error 1

> 
> Acked-by: Imre Deak 

Thank you.

> 
> > Thanks a lot,
> > Rodrigo.
> > 
> > > 
> > > > One thing that crossed my mind many times already is to simply entirely
> > > > remove the runtime_pm from display and do like other drivers simply
> > > > checking for crtc connection at runtime_idle.
> > > > 
> > > > But then there are places where current display code uses the rpm
> > > > in use to take different code paths, and also all the possible impact
> > > > with the dc states transitions and other cases that I always gave up
> > > > on the thought very quickly.
> > > > 
> > > > But you are right, we will have to comeback and clean things up
> > > > one way or another.
> > > > 
> > > > But I wish we can have at least this small change in first so I don't
> > > > get blocked by xe's lockdep annotation and I also don't have to
> > > > workaround the annotation itself.
> > > > 
> > > > > 
> > > > > >  
> > > > > > for_each_power_domain(domain, mask) {
> > > > > > /* Clear before put, so put's sanity check is happy. */
> > > > > > -- 
> > > > > > 2.43.2
> > > > > 
> > > > > -- 
> > > > > Ville Syrjälä
> > > > > Intel

Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Janusz Krzysztofik]

On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> On 3/11/24 09:58, Rodrigo Vivi wrote:
> > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> >> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> >> rpm wakeref.  That results in lock inversion:
> >>
> >> <4> [197.079335] ==
> >> <4> [197.085473] WARNING: possible circular locking dependency detected
> >> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
> >> <4> [197.098096] --
> >> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> >> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
> >> __kmalloc+0x9a/0x350
> >> <4> [197.116939]
> >> but task is already holding lock:
> >> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
> >> hwm_energy+0x4b/0x100 [i915]
> >> <4> [197.131543]
> >> which lock already depends on the new lock.
> >> ...
> >> <4> [197.507922] Chain exists of:
> >>fs_reclaim --> >reset.mutex --> >hwmon_lock
> >> <4> [197.518528]  Possible unsafe locking scenario:
> >> <4> [197.524411]CPU0CPU1
> >> <4> [197.528916]
> >> <4> [197.533418]   lock(>hwmon_lock);
> >> <4> [197.537237]lock(>reset.mutex);
> >> <4> [197.543376]lock(>hwmon_lock);
> >> <4> [197.549682]   lock(fs_reclaim);
> >> ...
> >> <4> [197.632548] Call Trace:
> >> <4> [197.634990]  
> >> <4> [197.637088]  dump_stack_lvl+0x64/0xb0
> >> <4> [197.640738]  check_noncircular+0x15e/0x180
> >> <4> [197.652968]  check_prev_add+0xe9/0xce0
> >> <4> [197.656705]  __lock_acquire+0x179f/0x2300
> >> <4> [197.660694]  lock_acquire+0xd8/0x2d0
> >> <4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
> >> <4> [197.680478]  __kmalloc+0x9a/0x350
> >> <4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
> >> <4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
> >> <4> [197.720608]  acpi_ns_get_node+0x3b/0x60
> >> <4> [197.724428]  acpi_get_handle+0x57/0xb0
> >> <4> [197.728164]  acpi_has_method+0x20/0x50
> >> <4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
> >> <4> [197.736485]  pci_power_up+0x24/0x1c0
> >> <4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
> >> <4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
> >> <4> [197.753911]  __rpm_callback+0x3c/0x110
> >> <4> [197.762586]  rpm_callback+0x58/0x70
> >> <4> [197.766064]  rpm_resume+0x51e/0x730
> >> <4> [197.769542]  rpm_resume+0x267/0x730
> >> <4> [197.773020]  rpm_resume+0x267/0x730
> >> <4> [197.776498]  rpm_resume+0x267/0x730
> >> <4> [197.779974]  __pm_runtime_resume+0x49/0x90
> >> <4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
> >> <4> [197.789070]  hwm_energy+0x55/0x100 [i915]
> >> <4> [197.793183]  hwm_read+0x9a/0x310 [i915]
> >> <4> [197.797124]  hwmon_attr_show+0x36/0x120
> >> <4> [197.800946]  dev_attr_show+0x15/0x60
> >> <4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100
> >>
> >> However, the lock is only intended to protect either a hwmon overflow
> >> counter or rmw hardware operations.  There is no need to hold the lock,
> >> only the wakeref, while reading from hardware.
> >>
> >> Acquire the lock after hardware read under rpm wakeref.
> >>
> >> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> >> Signed-off-by: Janusz Krzysztofik 
> >> Cc:  # v6.2+
> >> ---
> >>   drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> >> b/drivers/gpu/drm/i915/i915_hwmon.c
> >> index 8c3f443c8347e..faf7670de6e06 100644
> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> >> @@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
> >>else
> >>rgaddr = hwmon->rg.energy_status_all;
> >>   
> >> -  mutex_lock(>hwmon_lock);
> >> -
> >>with_intel_runtime_pm(uncore->rpm, wakeref)
> >>reg_val = intel_uncore_read(uncore, rgaddr);
> >>   
> >> +  mutex_lock(>hwmon_lock);
> >> +
> > 
> > This is not enough.
> > check hwm_locked_with_pm_intel_uncore_rmw()
> > 
> > It looks like we need to rethink this lock entirely here.
> > 
> 
> I would have assumed that the lock was supposed to ensure that
> reading the register value and the subsequent update of accum_energy
> and reg_val_prev was synchronized. This is no longer the case
> after this patch has been applied. Given that, I would agree that
> it would make sense to define what the lock is supposed to protect
> before changing its scope.

Right.  In that case, I propose to take the wakeref before the lock, and keep 
it while the lock is held around the calculations.  Would that be acceptable 
as a quick fix?  If yes then I can take the same approach to also fix other 
places in i915_hwmon.c for now where similar lock 

RE: [PATCH v2] drm/i915: Reuse RPLU cdclk fns for MTL+

[Sripada, Radhakrishna]

Merged the patch. Thanks for the reviews.

Regards,
Radhakrishna Sripada

> -Original Message-
> From: Sripada, Radhakrishna 
> Sent: Wednesday, February 28, 2024 1:49 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Sousa, Gustavo
> ; Nikula, Jani 
> Subject: [PATCH v2] drm/i915: Reuse RPLU cdclk fns for MTL+
> 
> MTL/LNL use the same cdclk functions as RPLU albeit with different
> tables. Having separate tables and not requiring special handling
> for the platforms, reuse RPLU cdclk functions.
> 
> v2: Update subject and the commit message(Jani)
> 
> Cc: Gustavo Sousa 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 22473c55b899..5b2688d8c644 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3559,13 +3559,6 @@ void intel_cdclk_debugfs_register(struct
> drm_i915_private *i915)
>   i915, _cdclk_info_fops);
>  }
> 
> -static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
> - .get_cdclk = bxt_get_cdclk,
> - .set_cdclk = bxt_set_cdclk,
> - .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
> - .calc_voltage_level = rplu_calc_voltage_level,
> -};
> -
>  static const struct intel_cdclk_funcs rplu_cdclk_funcs = {
>   .get_cdclk = bxt_get_cdclk,
>   .set_cdclk = bxt_set_cdclk,
> @@ -3709,10 +3702,10 @@ static const struct intel_cdclk_funcs
> i830_cdclk_funcs = {
>  void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
>  {
>   if (DISPLAY_VER(dev_priv) >= 20) {
> - dev_priv->display.funcs.cdclk = _cdclk_funcs;
> + dev_priv->display.funcs.cdclk = _cdclk_funcs;
>   dev_priv->display.cdclk.table = lnl_cdclk_table;
>   } else if (DISPLAY_VER(dev_priv) >= 14) {
> - dev_priv->display.funcs.cdclk = _cdclk_funcs;
> + dev_priv->display.funcs.cdclk = _cdclk_funcs;
>   dev_priv->display.cdclk.table = mtl_cdclk_table;
>   } else if (IS_DG2(dev_priv)) {
>   dev_priv->display.funcs.cdclk = _cdclk_funcs;
> --
> 2.34.1

Re: [PATCH 0/5] drm/i915: cleanup dead code

[Tvrtko Ursulin]

On 06/03/2024 19:36, Lucas De Marchi wrote:

Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by subsequent ones, so it's
not a huge amount of code being removed.


I had PVC and xehpsdv back in October but could not collect all acks. :(

Last two patches from https://patchwork.freedesktop.org/series/124705/.

Regards,

Tvrtko


drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h is also changed on the
xe side, but that should be ok: the defines are there only for compat
reasons while building the display side (and none of these platforms
have display, so it's build-issue only).

First patch is what motivated the others and was submitted alone
@ 20240306144723.1826977-1-lucas.demar...@intel.com .
While loooking at this WA I was wondering why we still had some of that
code around.

Build-tested only for now.

Lucas De Marchi (5):
   drm/i915: Drop WA 16015675438
   drm/i915: Drop dead code for xehpsdv
   drm/i915: Update IP_VER(12, 50)
   drm/i915: Drop dead code for pvc
   drm/i915: Remove special handling for !RCS_MASK()

  Documentation/gpu/rfc/i915_vm_bind.h  |  11 +-
  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 +-
  .../gpu/drm/i915/gem/selftests/huge_pages.c   |   4 +-
  .../i915/gem/selftests/i915_gem_client_blt.c  |   8 +-
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |   5 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  40 ++--
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  43 +---
  .../drm/i915/gt/intel_execlists_submission.c  |  10 +-
  drivers/gpu/drm/i915/gt/intel_gsc.c   |  15 --
  drivers/gpu/drm/i915/gt/intel_gt.c|   4 +-
  drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  52 +
  drivers/gpu/drm/i915/gt/intel_gt_mcr.h|   2 +-
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  59 --
  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   |  21 +-
  drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
  drivers/gpu/drm/i915/gt/intel_lrc.c   |  51 +
  drivers/gpu/drm/i915/gt/intel_migrate.c   |  22 +-
  drivers/gpu/drm/i915/gt/intel_mocs.c  |  52 +
  drivers/gpu/drm/i915/gt/intel_rps.c   |   6 +-
  drivers/gpu/drm/i915/gt/intel_sseu.c  |  13 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 193 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|   6 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|   4 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |   2 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   1 -
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   2 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc.c |   4 -
  drivers/gpu/drm/i915/i915_debugfs.c   |  12 --
  drivers/gpu/drm/i915/i915_drv.h   |  13 --
  drivers/gpu/drm/i915/i915_getparam.c  |   4 +-
  drivers/gpu/drm/i915/i915_gpu_error.c |   5 +-
  drivers/gpu/drm/i915/i915_hwmon.c |   6 -
  drivers/gpu/drm/i915/i915_pci.c   |  61 +-
  drivers/gpu/drm/i915/i915_perf.c  |  19 +-
  drivers/gpu/drm/i915/i915_query.c |   2 +-
  drivers/gpu/drm/i915/i915_reg.h   |   4 +-
  drivers/gpu/drm/i915/intel_clock_gating.c |  26 +--
  drivers/gpu/drm/i915/intel_device_info.c  |   2 -
  drivers/gpu/drm/i915/intel_device_info.h  |   2 -
  drivers/gpu/drm/i915/intel_step.c |  80 +---
  drivers/gpu/drm/i915/intel_uncore.c   | 159 +--
  drivers/gpu/drm/i915/selftests/intel_uncore.c |   3 -
  .../gpu/drm/xe/compat-i915-headers/i915_drv.h |   6 -
  43 files changed, 110 insertions(+), 928 deletions(-)

Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Guenter Roeck]

On 3/11/24 09:58, Rodrigo Vivi wrote:

On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:

In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
rpm wakeref.  That results in lock inversion:

<4> [197.079335] ==
<4> [197.085473] WARNING: possible circular locking dependency detected
<4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
<4> [197.098096] --
<4> [197.104231] prometheus-node/839 is trying to acquire lock:
<4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
__kmalloc+0x9a/0x350
<4> [197.116939]
but task is already holding lock:
<4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
hwm_energy+0x4b/0x100 [i915]
<4> [197.131543]
which lock already depends on the new lock.
...
<4> [197.507922] Chain exists of:
   fs_reclaim --> >reset.mutex --> >hwmon_lock
<4> [197.518528]  Possible unsafe locking scenario:
<4> [197.524411]CPU0CPU1
<4> [197.528916]
<4> [197.533418]   lock(>hwmon_lock);
<4> [197.537237]lock(>reset.mutex);
<4> [197.543376]lock(>hwmon_lock);
<4> [197.549682]   lock(fs_reclaim);
...
<4> [197.632548] Call Trace:
<4> [197.634990]  
<4> [197.637088]  dump_stack_lvl+0x64/0xb0
<4> [197.640738]  check_noncircular+0x15e/0x180
<4> [197.652968]  check_prev_add+0xe9/0xce0
<4> [197.656705]  __lock_acquire+0x179f/0x2300
<4> [197.660694]  lock_acquire+0xd8/0x2d0
<4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
<4> [197.680478]  __kmalloc+0x9a/0x350
<4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
<4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
<4> [197.720608]  acpi_ns_get_node+0x3b/0x60
<4> [197.724428]  acpi_get_handle+0x57/0xb0
<4> [197.728164]  acpi_has_method+0x20/0x50
<4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
<4> [197.736485]  pci_power_up+0x24/0x1c0
<4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
<4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
<4> [197.753911]  __rpm_callback+0x3c/0x110
<4> [197.762586]  rpm_callback+0x58/0x70
<4> [197.766064]  rpm_resume+0x51e/0x730
<4> [197.769542]  rpm_resume+0x267/0x730
<4> [197.773020]  rpm_resume+0x267/0x730
<4> [197.776498]  rpm_resume+0x267/0x730
<4> [197.779974]  __pm_runtime_resume+0x49/0x90
<4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
<4> [197.789070]  hwm_energy+0x55/0x100 [i915]
<4> [197.793183]  hwm_read+0x9a/0x310 [i915]
<4> [197.797124]  hwmon_attr_show+0x36/0x120
<4> [197.800946]  dev_attr_show+0x15/0x60
<4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100

However, the lock is only intended to protect either a hwmon overflow
counter or rmw hardware operations.  There is no need to hold the lock,
only the wakeref, while reading from hardware.

Acquire the lock after hardware read under rpm wakeref.

Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
Signed-off-by: Janusz Krzysztofik 
Cc:  # v6.2+
---
  drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8c3f443c8347e..faf7670de6e06 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
else
rgaddr = hwmon->rg.energy_status_all;
  
-	mutex_lock(>hwmon_lock);

-
with_intel_runtime_pm(uncore->rpm, wakeref)
reg_val = intel_uncore_read(uncore, rgaddr);
  
+	mutex_lock(>hwmon_lock);

+


This is not enough.
check hwm_locked_with_pm_intel_uncore_rmw()

It looks like we need to rethink this lock entirely here.



I would have assumed that the lock was supposed to ensure that
reading the register value and the subsequent update of accum_energy
and reg_val_prev was synchronized. This is no longer the case
after this patch has been applied. Given that, I would agree that
it would make sense to define what the lock is supposed to protect
before changing its scope.

Guenter

Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Rodrigo Vivi]

On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> rpm wakeref.  That results in lock inversion:
> 
> <4> [197.079335] ==
> <4> [197.085473] WARNING: possible circular locking dependency detected
> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
> <4> [197.098096] --
> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
> __kmalloc+0x9a/0x350
> <4> [197.116939]
> but task is already holding lock:
> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
> hwm_energy+0x4b/0x100 [i915]
> <4> [197.131543]
> which lock already depends on the new lock.
> ...
> <4> [197.507922] Chain exists of:
>   fs_reclaim --> >reset.mutex --> >hwmon_lock
> <4> [197.518528]  Possible unsafe locking scenario:
> <4> [197.524411]CPU0CPU1
> <4> [197.528916]
> <4> [197.533418]   lock(>hwmon_lock);
> <4> [197.537237]lock(>reset.mutex);
> <4> [197.543376]lock(>hwmon_lock);
> <4> [197.549682]   lock(fs_reclaim);
> ...
> <4> [197.632548] Call Trace:
> <4> [197.634990]  
> <4> [197.637088]  dump_stack_lvl+0x64/0xb0
> <4> [197.640738]  check_noncircular+0x15e/0x180
> <4> [197.652968]  check_prev_add+0xe9/0xce0
> <4> [197.656705]  __lock_acquire+0x179f/0x2300
> <4> [197.660694]  lock_acquire+0xd8/0x2d0
> <4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
> <4> [197.680478]  __kmalloc+0x9a/0x350
> <4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
> <4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
> <4> [197.720608]  acpi_ns_get_node+0x3b/0x60
> <4> [197.724428]  acpi_get_handle+0x57/0xb0
> <4> [197.728164]  acpi_has_method+0x20/0x50
> <4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
> <4> [197.736485]  pci_power_up+0x24/0x1c0
> <4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
> <4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
> <4> [197.753911]  __rpm_callback+0x3c/0x110
> <4> [197.762586]  rpm_callback+0x58/0x70
> <4> [197.766064]  rpm_resume+0x51e/0x730
> <4> [197.769542]  rpm_resume+0x267/0x730
> <4> [197.773020]  rpm_resume+0x267/0x730
> <4> [197.776498]  rpm_resume+0x267/0x730
> <4> [197.779974]  __pm_runtime_resume+0x49/0x90
> <4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
> <4> [197.789070]  hwm_energy+0x55/0x100 [i915]
> <4> [197.793183]  hwm_read+0x9a/0x310 [i915]
> <4> [197.797124]  hwmon_attr_show+0x36/0x120
> <4> [197.800946]  dev_attr_show+0x15/0x60
> <4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100
> 
> However, the lock is only intended to protect either a hwmon overflow
> counter or rmw hardware operations.  There is no need to hold the lock,
> only the wakeref, while reading from hardware.
> 
> Acquire the lock after hardware read under rpm wakeref.
> 
> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> Signed-off-by: Janusz Krzysztofik 
> Cc:  # v6.2+
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347e..faf7670de6e06 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
>   else
>   rgaddr = hwmon->rg.energy_status_all;
>  
> - mutex_lock(>hwmon_lock);
> -
>   with_intel_runtime_pm(uncore->rpm, wakeref)
>   reg_val = intel_uncore_read(uncore, rgaddr);
>  
> + mutex_lock(>hwmon_lock);
> +

This is not enough.
check hwm_locked_with_pm_intel_uncore_rmw()

It looks like we need to rethink this lock entirely here.


struct mutex hwmon_lock;/* counter overflow \
logic and rmw */

do we really need to protect the rmw?

This also shows me that we have other places with intel_uncore_rmw
without the with runtime_pm.

perhaps we need to stop using the with_rpm macro and use explicit
rpm calls before the hwmon_locks before the rmw?

perhaps we need a more granular lock?

notice that I'm just brainstorming/thinking out loud... someone need
to go there an run an deeper analisys on this lock and rpm calls
on hwmon.

>   if (reg_val >= ei->reg_val_prev)
>   ei->accum_energy += reg_val - ei->reg_val_prev;
>   else
> -- 
> 2.43.0
> 

Re: [PATCH 4/5] drm/i915: Drop dead code for pvc

[Rodrigo Vivi]

On Mon, Mar 11, 2024 at 10:35:20AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote:
> > > @@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs 
> > > *engine, struct i915_wa_list *wal
> > >   if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
> > >   general_render_compute_wa_init(engine, wal);
> > > 
> > > - if (engine->class == COMPUTE_CLASS)
> > > - ccs_engine_wa_init(engine, wal);
> > > - else if (engine->class == RENDER_CLASS)
> > 
> > I don't believe we need to remove this chunk since we are not deleting the 
> > ccs_engine_wa_init.
> > If we want to keep that as a placeholder we should also keep the caller as 
> > well.
> 
> right... I had removed it but brought it back since I noticed the
> kernel-doc mentions and forgot to bring back the caller too. I will fix
> this in next rev.

thanks!
with that:

Reviewed-by: Rodrigo Vivi 


> 
> 
> thanks
> Lucas De Marchi

Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)

[Rodrigo Vivi]

On Mon, Mar 11, 2024 at 10:29:45AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote:
> > On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> > > With no platform declaring graphics/media IP_VER(12, 50),
> > 
> > this is not true.
> > We still have
> > 
> > #define XE_HPM_FEATURES \
> > .__runtime.media.ip.ver = 12, \
> >.__runtime.media.ip.rel = 50
> 
> 
> 
> > > -#define XE_HPM_FEATURES \
> > > - .__runtime.media.ip.ver = 12, \
> > > - .__runtime.media.ip.rel = 50
> > > -
> 
> ^ being removed here since all the users, like below, are overriding it.
> 
> > >  #define DG2_FEATURES \
> > >   XE_HP_FEATURES, \
> > > - XE_HPM_FEATURES, \
> > >   DGFX_FEATURES, \
> > > + .__runtime.graphics.ip.ver = 12, \
> > >   .__runtime.graphics.ip.rel = 55, \
> > > + .__runtime.media.ip.ver = 12, \
> > >   .__runtime.media.ip.rel = 55, \
> 
> ^^
> 
> After applying until this patch:
> 
> $ git grep -e "rel[[:space:]]*=" -- drivers/gpu/drm/i915/i915_pci.c
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 10,
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 55, \
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 55, \
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 60,
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 60,
> drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 70,
> 
> should I reword anything in the commit message to make my intent
> clearer?

doh! sorry.. I read the first line of the commit message and stopped.

perhaps we could do that HPM removal in a separate patch before this one?

Reviewed-by: Rodrigo Vivi 

on the final result, whatever you decide to split or to rephrase the msg.

> 
> thanks
> Lucas De Marchi

Re: [PATCH] Fix divide-by-zero on DP unplug with nouveau

[Imre Deak]

On Mon, Mar 11, 2024 at 06:09:29PM +0200, Imre Deak wrote:
> On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:
> 
> Sorry for the delay.
> 
> > The following trace occurs when using nouveau and unplugging a DP MST
> > adaptor:
> > 
> >  divide error:  [#1] PREEMPT SMP PTI
> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
> >  Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 
> > c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 
> > 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
> >  RAX:  RBX:  RCX: 00f59b00
> >  RDX:  RSI:  RDI: 
> >  RBP: b2c5c211fa48 R08: 0001 R09: 0020
> >  R10: 0004 R11:  R12: 00023b4a
> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
> >  FS:  7f4a1ca3fa80() GS:91d6edbc() 
> > knlGS:
> >  CS:  0010 DS:  ES:  CR0: 80050033
> >  CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0
> >  Call Trace:
> >   
> >   ? show_regs+0x6d/0x80
> >   ? die+0x37/0xa0
> >   ? do_trap+0xd4/0xf0
> >   ? do_error_trap+0x71/0xb0
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? exc_divide_error+0x3a/0x70
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? asm_exc_divide_error+0x1b/0x20
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
> >   nv50_msto_atomic_check+0xda/0x120 [nouveau]
> >   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
> >   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
> >   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
> >   drm_atomic_check_only+0x668/0xb20 [drm]
> >   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
> >   drm_atomic_commit+0x58/0xd0 [drm]
> >   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
> >   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
> >   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
> >   drm_ioctl_kernel+0xb9/0x120 [drm]
> >   drm_ioctl+0x2d0/0x550 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
> >   __x64_sys_ioctl+0xa0/0xf0
> >   do_syscall_64+0x76/0x140
> >   ? do_syscall_64+0x85/0x140
> >   ? do_syscall_64+0x85/0x140
> >   entry_SYSCALL_64_after_hwframe+0x6e/0x76
> >  RIP: 0033:0x7f4a1cd1a94f
> >  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 
> > 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 
> > f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
> >  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010
> >  RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
> >  RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
> >  RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0
> >  R10:  R11: 0246 R12: 56347938a220
> >  R13: 000f R14: 563479d9f3f0 R15: 
> >   
> >  Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat 
> > nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user 
> > xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge 
> > stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc 
> > snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci 
> > snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils 
> > snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress 
> > snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr 
> > intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp 
> > mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek 
> > snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg 
> > snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass 
> > btusb videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch 
> > crc32_pclmul snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni 
> > polyval_generic snd_rawmidi
> >   ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd 
> > snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 
> > mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt 
> > cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer 
> > i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore 
> > realtek libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad 
> > 

Re: [PATCH] Fix divide-by-zero on DP unplug with nouveau

[Linux regression tracking (Thorsten Leemhuis)]

On 11.03.24 17:09, Imre Deak wrote:
> On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:
> Sorry for the delay.

Happens, thx for looking onto this!

>> The following trace occurs when using nouveau and unplugging a DP MST
>> adaptor:
> [...] 
>> +if (bpp_x16 == 0)
>> +return 0;
> 
> Could you please move the check to the beginnig of the function and add
> a debug message in case bpp_x16 is 0?
> 
> It looks odd that a driver calls this function with a 0 bpp_x16, and
> ideally it should be fixed in the driver. However as it's a regression
> and we don't have a better idea now:
> 
> Acked-by: Imre Deak 

Chris: as this went into 6.8, please consider adding a stable-tag to
ensure Greg picks this up.

Ciao, Thorsten

Re: [PATCH] Fix divide-by-zero on DP unplug with nouveau

[Imre Deak]

On Sat, Feb 10, 2024 at 09:24:59PM +, Chris Bainbridge wrote:

Sorry for the delay.

> The following trace occurs when using nouveau and unplugging a DP MST
> adaptor:
> 
>  divide error:  [#1] PREEMPT SMP PTI
>  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
>  Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
>  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 
> c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 
> c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
>  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
>  RAX:  RBX:  RCX: 00f59b00
>  RDX:  RSI:  RDI: 
>  RBP: b2c5c211fa48 R08: 0001 R09: 0020
>  R10: 0004 R11:  R12: 00023b4a
>  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
>  FS:  7f4a1ca3fa80() GS:91d6edbc() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0
>  Call Trace:
>   
>   ? show_regs+0x6d/0x80
>   ? die+0x37/0xa0
>   ? do_trap+0xd4/0xf0
>   ? do_error_trap+0x71/0xb0
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? exc_divide_error+0x3a/0x70
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? asm_exc_divide_error+0x1b/0x20
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
>   nv50_msto_atomic_check+0xda/0x120 [nouveau]
>   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
>   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
>   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
>   drm_atomic_check_only+0x668/0xb20 [drm]
>   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
>   drm_atomic_commit+0x58/0xd0 [drm]
>   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
>   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
>   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
>   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
>   drm_ioctl_kernel+0xb9/0x120 [drm]
>   drm_ioctl+0x2d0/0x550 [drm]
>   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
>   __x64_sys_ioctl+0xa0/0xf0
>   do_syscall_64+0x76/0x140
>   ? do_syscall_64+0x85/0x140
>   ? do_syscall_64+0x85/0x140
>   entry_SYSCALL_64_after_hwframe+0x6e/0x76
>  RIP: 0033:0x7f4a1cd1a94f
>  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 
> 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 
> ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
>  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010
>  RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
>  RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
>  RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0
>  R10:  R11: 0246 R12: 56347938a220
>  R13: 000f R14: 563479d9f3f0 R15: 
>   
>  Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat 
> nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user 
> xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp 
> llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc 
> snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci 
> snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils 
> snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress 
> snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr 
> intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp 
> mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek 
> snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg 
> snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb 
> videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul 
> snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic 
> snd_rawmidi
>   ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd 
> snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 
> mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt 
> cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer 
> i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek 
> libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel 
> msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 
> dm_crypt raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq 
> async_xor xor async_tx raid6_pq raid1 raid0 joydev input_leds hid_generic 
> 

RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Saarinen, Jani]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, 11 March 2024 18.03
> To: Saarinen, Jani ; Linux regressions mailing list
> ; Deak, Imre 
> Cc: Chris Bainbridge ; intel-gfx  g...@lists.freedesktop.org>; David Airlie ; Daniel Vetter
> ; ML dri-devel 
> Subject: RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with
> nouveau
> 
> On Mon, 11 Mar 2024, "Saarinen, Jani"  wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Linux regression tracking (Thorsten Leemhuis)
> >> Sent: Monday, 11 March 2024 17.53
> >> To: Deak, Imre 
> >> Cc: regressi...@lists.linux.dev; Chris Bainbridge
> >> ; intel-gfx
> >> ;
> >> David Airlie ; Daniel Vetter ; ML
> >> dri-devel 
> >> Subject: Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug
> >> with nouveau
> >>
> >> On 07.03.24 18:58, Chris Bainbridge wrote:
> >> > - Forwarded message from Chris Bainbridge
> >> >  -
> >> >
> >> > Date: Sat, 10 Feb 2024 21:24:59 +
> >>
> >> Hmm, it looks like nobody is looking into this regression. Is there a
> >> good reason?
> >>
> >> Imre, or did you maybe just miss that Chris' regression seems to be
> >> caused by a commit of yours? He initally proposed a fix (the
> >> forwarded mail that is quoted here) more a month ago already here:
> >> https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/
> >>
> >> Chris recently filed a ticket, too:
> >> https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36
> > Please file
> > https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.htm
> > l
> 
> Well, please don't. It's *not* an i915 bug.
Right, sorry about this. Let Imre to comment then. 

> 
> BR,
> Jani.
> 
> >>
> >> Mostly silence there as well. :-/
> >>
> >> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker'
> >> hat)
> >>
> >> P.S: Chris, sorry, I had missed that you initially proposed the fix a
> >> month ago; if I had noticed this earlier I had sent a mail like this one 
> >> earlier.
> >> --
> >> Everything you wanna know about Linux kernel regression tracking:
> >> https://linux-regtracking.leemhuis.info/about/#tldr
> >> If I did something stupid, please tell me, as explained on that page.
> >>
> >> > From: Chris Bainbridge 
> >> > To: dri-de...@lists.freedesktop.org
> >> > Cc: ly...@redhat.com, ville.syrj...@linux.intel.com,
> >> stanislav.lisovs...@intel.com,
> >> >  mrip...@kernel.org, imre.d...@intel.com
> >> > Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
> >> >
> >> > The following trace occurs when using nouveau and unplugging a DP
> >> > MST
> >> > adaptor:
> >> >>  divide error:  [#1] PREEMPT SMP PTI
> >> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744  Hardware
> >> > name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
> >> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1
> >> > 04
> >> > 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48>
> >> > f7
> >> > f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
> >> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
> >> >  RAX:  RBX:  RCX: 00f59b00
> >> >  RDX:  RSI:  RDI:
> >> 
> >> >  RBP: b2c5c211fa48 R08: 0001 R09:
> >> 0020
> >> >  R10: 0004 R11:  R12:
> >> 00023b4a
> >> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
> >> >  FS:  7f4a1ca3fa80() GS:91d6edbc()
> >> > knlGS:
> >> >  CS:  0010 DS:  ES:  CR0: 80050033
> >> >  CR2: 559491d49000 CR3: 00011d180002 CR4:
> >> 003706f0
> >> > Call Trace:
> >> >   
> >> >   ? show_regs+0x6d/0x80
> >> >   ? die+0x37/0xa0
> >> >   ? do_trap+0xd4/0xf0
> >> >   ? do_error_trap+0x71/0xb0
> >> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >   ? exc_divide_error+0x3a/0x70
> >> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >   ? asm_exc_divide_error+0x1b/0x20
> >> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
> >> >   nv50_msto_atomic_check+0xda/0x120 [nouveau]
> >> >   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
> >> >   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
> >> >   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
> >> >   drm_atomic_check_only+0x668/0xb20 [drm]
> >> >   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
> >> >   drm_atomic_commit+0x58/0xd0 [drm]
> >> >   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
> >> >   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
> >> >   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
> >> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >> >   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
> >> >   drm_ioctl_kernel+0xb9/0x120 [drm]
> >> >   drm_ioctl+0x2d0/0x550 

RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Jani Nikula]

On Mon, 11 Mar 2024, "Saarinen, Jani"  wrote:
> Hi, 
>
>> -Original Message-
>> From: Intel-gfx  On Behalf Of Linux
>> regression tracking (Thorsten Leemhuis)
>> Sent: Monday, 11 March 2024 17.53
>> To: Deak, Imre 
>> Cc: regressi...@lists.linux.dev; Chris Bainbridge
>> ; intel-gfx ;
>> David Airlie ; Daniel Vetter ; ML 
>> dri-devel
>> 
>> Subject: Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with
>> nouveau
>> 
>> On 07.03.24 18:58, Chris Bainbridge wrote:
>> > - Forwarded message from Chris Bainbridge
>> >  -
>> >
>> > Date: Sat, 10 Feb 2024 21:24:59 +
>> 
>> Hmm, it looks like nobody is looking into this regression. Is there a good
>> reason?
>> 
>> Imre, or did you maybe just miss that Chris' regression seems to be caused by
>> a commit of yours? He initally proposed a fix (the forwarded mail that is
>> quoted here) more a month ago already here:
>> https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/
>> 
>> Chris recently filed a ticket, too:
>> https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36
> Please file 
> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html 

Well, please don't. It's *not* an i915 bug.

BR,
Jani.

>> 
>> Mostly silence there as well. :-/
>> 
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> 
>> P.S: Chris, sorry, I had missed that you initially proposed the fix a month 
>> ago; if
>> I had noticed this earlier I had sent a mail like this one earlier.
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>> 
>> > From: Chris Bainbridge 
>> > To: dri-de...@lists.freedesktop.org
>> > Cc: ly...@redhat.com, ville.syrj...@linux.intel.com,
>> stanislav.lisovs...@intel.com,
>> >mrip...@kernel.org, imre.d...@intel.com
>> > Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
>> >
>> > The following trace occurs when using nouveau and unplugging a DP MST
>> > adaptor:
>> >>  divide error:  [#1] PREEMPT SMP PTI
>> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744  Hardware
>> > name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
>> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04
>> > 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7
>> > f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
>> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
>> >  RAX:  RBX:  RCX: 00f59b00
>> >  RDX:  RSI:  RDI:
>> 
>> >  RBP: b2c5c211fa48 R08: 0001 R09:
>> 0020
>> >  R10: 0004 R11:  R12:
>> 00023b4a
>> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
>> >  FS:  7f4a1ca3fa80() GS:91d6edbc()
>> > knlGS:
>> >  CS:  0010 DS:  ES:  CR0: 80050033
>> >  CR2: 559491d49000 CR3: 00011d180002 CR4:
>> 003706f0
>> > Call Trace:
>> >   
>> >   ? show_regs+0x6d/0x80
>> >   ? die+0x37/0xa0
>> >   ? do_trap+0xd4/0xf0
>> >   ? do_error_trap+0x71/0xb0
>> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>> >   ? exc_divide_error+0x3a/0x70
>> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>> >   ? asm_exc_divide_error+0x1b/0x20
>> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>> >   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
>> >   nv50_msto_atomic_check+0xda/0x120 [nouveau]
>> >   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
>> >   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
>> >   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
>> >   drm_atomic_check_only+0x668/0xb20 [drm]
>> >   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
>> >   drm_atomic_commit+0x58/0xd0 [drm]
>> >   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
>> >   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
>> >   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
>> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>> >   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
>> >   drm_ioctl_kernel+0xb9/0x120 [drm]
>> >   drm_ioctl+0x2d0/0x550 [drm]
>> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>> >   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
>> >   __x64_sys_ioctl+0xa0/0xf0
>> >   do_syscall_64+0x76/0x140
>> >   ? do_syscall_64+0x85/0x140
>> >   ? do_syscall_64+0x85/0x140
>> >   entry_SYSCALL_64_after_hwframe+0x6e/0x76
>> >  RIP: 0033:0x7f4a1cd1a94f
>> >  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48
>> > 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89
>> > c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
>> >  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX:
>> > 0010
>> >  RAX: 

RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Linux
> regression tracking (Thorsten Leemhuis)
> Sent: Monday, 11 March 2024 17.53
> To: Deak, Imre 
> Cc: regressi...@lists.linux.dev; Chris Bainbridge
> ; intel-gfx ;
> David Airlie ; Daniel Vetter ; ML dri-devel
> 
> Subject: Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with
> nouveau
> 
> On 07.03.24 18:58, Chris Bainbridge wrote:
> > - Forwarded message from Chris Bainbridge
> >  -
> >
> > Date: Sat, 10 Feb 2024 21:24:59 +
> 
> Hmm, it looks like nobody is looking into this regression. Is there a good
> reason?
> 
> Imre, or did you maybe just miss that Chris' regression seems to be caused by
> a commit of yours? He initally proposed a fix (the forwarded mail that is
> quoted here) more a month ago already here:
> https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/
> 
> Chris recently filed a ticket, too:
> https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36
Please file 
https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html 
> 
> Mostly silence there as well. :-/
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> P.S: Chris, sorry, I had missed that you initially proposed the fix a month 
> ago; if
> I had noticed this earlier I had sent a mail like this one earlier.
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> > From: Chris Bainbridge 
> > To: dri-de...@lists.freedesktop.org
> > Cc: ly...@redhat.com, ville.syrj...@linux.intel.com,
> stanislav.lisovs...@intel.com,
> > mrip...@kernel.org, imre.d...@intel.com
> > Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
> >
> > The following trace occurs when using nouveau and unplugging a DP MST
> > adaptor:
> >>  divide error:  [#1] PREEMPT SMP PTI
> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744  Hardware
> > name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04
> > 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7
> > f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
> >  RAX:  RBX:  RCX: 00f59b00
> >  RDX:  RSI:  RDI:
> 
> >  RBP: b2c5c211fa48 R08: 0001 R09:
> 0020
> >  R10: 0004 R11:  R12:
> 00023b4a
> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
> >  FS:  7f4a1ca3fa80() GS:91d6edbc()
> > knlGS:
> >  CS:  0010 DS:  ES:  CR0: 80050033
> >  CR2: 559491d49000 CR3: 00011d180002 CR4:
> 003706f0
> > Call Trace:
> >   
> >   ? show_regs+0x6d/0x80
> >   ? die+0x37/0xa0
> >   ? do_trap+0xd4/0xf0
> >   ? do_error_trap+0x71/0xb0
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? exc_divide_error+0x3a/0x70
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? asm_exc_divide_error+0x1b/0x20
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
> >   nv50_msto_atomic_check+0xda/0x120 [nouveau]
> >   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
> >   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
> >   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
> >   drm_atomic_check_only+0x668/0xb20 [drm]
> >   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
> >   drm_atomic_commit+0x58/0xd0 [drm]
> >   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
> >   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
> >   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
> >   drm_ioctl_kernel+0xb9/0x120 [drm]
> >   drm_ioctl+0x2d0/0x550 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
> >   __x64_sys_ioctl+0xa0/0xf0
> >   do_syscall_64+0x76/0x140
> >   ? do_syscall_64+0x85/0x140
> >   ? do_syscall_64+0x85/0x140
> >   entry_SYSCALL_64_after_hwframe+0x6e/0x76
> >  RIP: 0033:0x7f4a1cd1a94f
> >  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48
> > 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89
> > c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
> >  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX:
> > 0010
> >  RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
> >  RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
> >  RBP: c01064ab R08: 56347932deb8 R09:
> 56347a7d99c0
> >  R10:  R11: 

Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Linux regression tracking (Thorsten Leemhuis)]

On 07.03.24 18:58, Chris Bainbridge wrote:
> - Forwarded message from Chris Bainbridge  
> -
> 
> Date: Sat, 10 Feb 2024 21:24:59 +

Hmm, it looks like nobody is looking into this regression. Is there a
good reason?

Imre, or did you maybe just miss that Chris' regression seems to be
caused by a commit of yours? He initally proposed a fix (the forwarded
mail that is quoted here) more a month ago already here:
https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/

Chris recently filed a ticket, too:
https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36

Mostly silence there as well. :-/

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S: Chris, sorry, I had missed that you initially proposed the fix a
month ago; if I had noticed this earlier I had sent a mail like this one
earlier.
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

> From: Chris Bainbridge 
> To: dri-de...@lists.freedesktop.org
> Cc: ly...@redhat.com, ville.syrj...@linux.intel.com, 
> stanislav.lisovs...@intel.com,
>   mrip...@kernel.org, imre.d...@intel.com
> Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
> 
> The following trace occurs when using nouveau and unplugging a DP MST
> adaptor:
>>  divide error:  [#1] PREEMPT SMP PTI
>  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744
>  Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
>  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 
> c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 
> c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
>  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
>  RAX:  RBX:  RCX: 00f59b00
>  RDX:  RSI:  RDI: 
>  RBP: b2c5c211fa48 R08: 0001 R09: 0020
>  R10: 0004 R11:  R12: 00023b4a
>  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
>  FS:  7f4a1ca3fa80() GS:91d6edbc() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 559491d49000 CR3: 00011d180002 CR4: 003706f0
>  Call Trace:
>   
>   ? show_regs+0x6d/0x80
>   ? die+0x37/0xa0
>   ? do_trap+0xd4/0xf0
>   ? do_error_trap+0x71/0xb0
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? exc_divide_error+0x3a/0x70
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? asm_exc_divide_error+0x1b/0x20
>   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
>   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
>   nv50_msto_atomic_check+0xda/0x120 [nouveau]
>   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
>   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
>   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
>   drm_atomic_check_only+0x668/0xb20 [drm]
>   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
>   drm_atomic_commit+0x58/0xd0 [drm]
>   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
>   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
>   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
>   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
>   drm_ioctl_kernel+0xb9/0x120 [drm]
>   drm_ioctl+0x2d0/0x550 [drm]
>   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
>   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
>   __x64_sys_ioctl+0xa0/0xf0
>   do_syscall_64+0x76/0x140
>   ? do_syscall_64+0x85/0x140
>   ? do_syscall_64+0x85/0x140
>   entry_SYSCALL_64_after_hwframe+0x6e/0x76
>  RIP: 0033:0x7f4a1cd1a94f
>  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 
> 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 
> ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
>  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0010
>  RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
>  RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
>  RBP: c01064ab R08: 56347932deb8 R09: 56347a7d99c0
>  R10:  R11: 0246 R12: 56347938a220
>  R13: 000f R14: 563479d9f3f0 R15: 
>   
>  Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat 
> nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user 
> xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp 
> llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc 
> snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci 
> snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils 
> snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress 
> snd_sof_intel_hda_mlink 

Re: ✗ Fi.CI.IGT: failure for drm/i915: Drop WA 16015675438 (rev2)

[Lucas De Marchi]

On Thu, Mar 07, 2024 at 05:24:38PM -, Patchwork wrote:

== Series Details ==

Series: drm/i915: Drop WA 16015675438 (rev2)
URL   : https://patchwork.freedesktop.org/series/130815/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14400_full -> Patchwork_130815v2_full


Summary
---

 **FAILURE**

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

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_130815v2_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) to allow them
 to document this new failure mode, which will reduce false positives in CI.



Participating hosts (8 -> 8)
--

 No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

 * igt@i915_module_load@reload-with-fault-injection:
   - shard-tglu: [PASS][1] -> [INCOMPLETE][2]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14400/shard-tglu-2/igt@i915_module_l...@reload-with-fault-injection.html
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-tglu-6/igt@i915_module_l...@reload-with-fault-injection.html

 * igt@i915_selftest@live@requests:
   - shard-mtlp: [PASS][3] -> [ABORT][4]
  [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14400/shard-mtlp-3/igt@i915_selftest@l...@requests.html
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-mtlp-5/igt@i915_selftest@l...@requests.html

 * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
   - shard-glk:  NOTRUN -> [INCOMPLETE][5]
  [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

 * 
igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscaling@pipe-a-valid-mode:
   - shard-dg2:  NOTRUN -> [DMESG-WARN][6]
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-dg2-11/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscal...@pipe-a-valid-mode.html



this is the only one that might be related since we are removing wa from
pvc/dg2. But looking further, that warning shouldn't really be caused by
this patch.

Lucas De Marchi

Re: [PATCH 4/5] drm/i915: Drop dead code for pvc

[Lucas De Marchi]

On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote:

@@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs *engine, 
struct i915_wa_list *wal
if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
general_render_compute_wa_init(engine, wal);

-   if (engine->class == COMPUTE_CLASS)
-   ccs_engine_wa_init(engine, wal);
-   else if (engine->class == RENDER_CLASS)


I don't believe we need to remove this chunk since we are not deleting the 
ccs_engine_wa_init.
If we want to keep that as a placeholder we should also keep the caller as well.


right... I had removed it but brought it back since I noticed the
kernel-doc mentions and forgot to bring back the caller too. I will fix
this in next rev.


thanks
Lucas De Marchi

Re: [PATCH] drm/i915: Drop WA 16015675438

[Lucas De Marchi]

On Mon, Mar 11, 2024 at 10:54:57AM -0400, Rodrigo Vivi wrote:

On Wed, Mar 06, 2024 at 06:43:39AM -0800, Lucas De Marchi wrote:

With dynamic load-balancing disabled on the compute side, there's no
reason left to enable WA 16015675438. Drop it from both PVC and DG2.
Note that this can be done because now the driver always set a fixed
partition of EUs during initialization via the ccs_mode configuration.

The flag to GuC is still needed because of 18020744125, so update
the comment accordingly.

Cc: Rodrigo Vivi 
Acked-by: Mateusz Jablonski 
Acked-by: Michal Mrozek 
Signed-off-by: Lucas De Marchi 


Reviewed-by: Rodrigo Vivi 


applied to drm-intel-gt-next, thanks.

Lucas De Marchi

Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)

[Lucas De Marchi]

On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote:

On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:

With no platform declaring graphics/media IP_VER(12, 50),


this is not true.
We still have

#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
   .__runtime.media.ip.rel = 50





-#define XE_HPM_FEATURES \
-   .__runtime.media.ip.ver = 12, \
-   .__runtime.media.ip.rel = 50
-


^ being removed here since all the users, like below, are overriding it.


 #define DG2_FEATURES \
XE_HP_FEATURES, \
-   XE_HPM_FEATURES, \
DGFX_FEATURES, \
+   .__runtime.graphics.ip.ver = 12, \
.__runtime.graphics.ip.rel = 55, \
+   .__runtime.media.ip.ver = 12, \
.__runtime.media.ip.rel = 55, \


  ^^

After applying until this patch:

$ git grep -e "rel[[:space:]]*=" -- drivers/gpu/drm/i915/i915_pci.c
drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 10,
drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 55, \
drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 55, \
drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 60,
drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 60,
drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 70,

should I reword anything in the commit message to make my intent
clearer?

thanks
Lucas De Marchi

Re: [PATCH 4/5] drm/i915: Drop dead code for pvc

[Rodrigo Vivi]

On Wed, Mar 06, 2024 at 11:36:42AM -0800, Lucas De Marchi wrote:
> PCI IDs for PVC were never added and platform always marked with
> force_probe. Drop what's not used and rename some places as needed.
> 
> The registers not used anymore are also removed.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 +-
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |   3 -
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  33 
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  30 +---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   9 --
>  drivers/gpu/drm/i915/gt/intel_mocs.c  |  19 ---
>  drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +-
>  drivers/gpu/drm/i915/gt/intel_sseu.c  |   9 +-
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   |  90 +--
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c |   4 -
>  drivers/gpu/drm/i915/i915_debugfs.c   |  12 --
>  drivers/gpu/drm/i915/i915_drv.h   |   9 --
>  drivers/gpu/drm/i915/i915_pci.c   |  36 -
>  drivers/gpu/drm/i915/i915_reg.h   |   1 -
>  drivers/gpu/drm/i915/intel_clock_gating.c |  16 +-
>  drivers/gpu/drm/i915/intel_device_info.c  |   1 -
>  drivers/gpu/drm/i915/intel_device_info.h  |   1 -
>  drivers/gpu/drm/i915/intel_step.c |  70 +
>  drivers/gpu/drm/i915/intel_uncore.c   | 142 --
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |   2 -
>  .../gpu/drm/xe/compat-i915-headers/i915_drv.h |   4 -
>  21 files changed, 12 insertions(+), 485 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 0c5cdab278b6..d3300ae3053f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -386,7 +386,7 @@ struct drm_i915_gem_object {
>* and kernel mode driver for caching policy control after GEN12.
>* In the meantime platform specific tables are created to translate
>* i915_cache_level into pat index, for more details check the macros
> -  * defined i915/i915_pci.c, e.g. PVC_CACHELEVEL.
> +  * defined i915/i915_pci.c, e.g. MTL_CACHELEVEL.
>* For backward compatibility, this field contains values exactly match
>* the entries of enum i915_cache_level for pre-GEN12 platforms (See
>* LEGACY_CACHELEVEL), so that the PTE encode functions for these
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 24d1c28201fa..2e27bcb52e0d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -189,9 +189,6 @@ static bool gen12_needs_ccs_aux_inv(struct 
> intel_engine_cs *engine)
>  {
>   i915_reg_t reg = gen12_get_aux_inv_reg(engine);
>  
> - if (IS_PONTEVECCHIO(engine->i915))
> - return false;
> -
>   /*
>* So far platforms supported by i915 having flat ccs do not require
>* AUX invalidation. Check also whether the engine requires it.
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 75bde8c1aa5d..396f5fe993c3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -839,38 +839,6 @@ static void engine_mask_apply_compute_fuses(struct 
> intel_gt *gt)
>   }
>  }
>  
> -static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
> -{
> - struct drm_i915_private *i915 = gt->i915;
> - struct intel_gt_info *info = >info;
> - unsigned long meml3_mask;
> - unsigned long quad;
> -
> - if (!(GRAPHICS_VER_FULL(i915) >= IP_VER(12, 60) &&
> -   GRAPHICS_VER_FULL(i915) < IP_VER(12, 70)))
> - return;
> -
> - meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> - meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
> -
> - /*
> -  * Link Copy engines may be fused off according to meml3_mask. Each
> -  * bit is a quad that houses 2 Link Copy and two Sub Copy engines.
> -  */
> - for_each_clear_bit(quad, _mask, GEN12_MAX_MSLICES) {
> - unsigned int instance = quad * 2 + 1;
> - intel_engine_mask_t mask = GENMASK(_BCS(instance + 1),
> -_BCS(instance));
> -
> - if (mask & info->engine_mask) {
> - gt_dbg(gt, "bcs%u fused off\n", instance);
> - gt_dbg(gt, "bcs%u fused off\n", instance + 1);
> -
> - info->engine_mask &= ~mask;
> - }
> - }
> -}
> -
>  /*
>   * Determine which engines are fused off in our particular hardware.
>   * Note that we have a catch-22 situation where we need to be able to access
> @@ -889,7 +857,6 @@ static intel_engine_mask_t init_engine_mask(struct 
> intel_gt *gt)
>  
>   

Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)

[Rodrigo Vivi]

On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> With no platform declaring graphics/media IP_VER(12, 50),

this is not true.
We still have

#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
.__runtime.media.ip.rel = 50

 replace the
> checks throughout the code with IP_VER(12, 55) so the code makes sense
> by itself with no additional explanation of previous baggage.
> 
> The info override for the various _info is then changed so the version
> definition is clearer without pointless overrides.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  4 ++--
>  .../gpu/drm/i915/gem/selftests/i915_gem_client_blt.c |  8 
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  2 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c|  5 ++---
>  drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 10 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c   |  4 ++--
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.c   |  4 ++--
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.h   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/gt/intel_lrc.c  |  8 
>  drivers/gpu/drm/i915/gt/intel_migrate.c  |  4 ++--
>  drivers/gpu/drm/i915/gt/intel_mocs.c |  2 +-
>  drivers/gpu/drm/i915/gt/intel_sseu.c |  4 ++--
>  drivers/gpu/drm/i915/gt/intel_workarounds.c  |  4 ++--
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c   |  4 ++--
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c|  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c|  2 +-
>  drivers/gpu/drm/i915/i915_getparam.c |  4 ++--
>  drivers/gpu/drm/i915/i915_gpu_error.c|  5 ++---
>  drivers/gpu/drm/i915/i915_pci.c  | 12 
>  drivers/gpu/drm/i915/i915_perf.c |  8 
>  drivers/gpu/drm/i915/i915_query.c|  2 +-
>  drivers/gpu/drm/i915/intel_uncore.c  |  2 +-
>  24 files changed, 50 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index 3ff3d8889c6c..edb54903be0a 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -713,7 +713,7 @@ static int igt_ppgtt_huge_fill(void *arg)
>  {
>   struct drm_i915_private *i915 = arg;
>   unsigned int supported = RUNTIME_INFO(i915)->page_sizes;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
>   struct i915_address_space *vm;
>   struct i915_gem_context *ctx;
>   unsigned long max_pages;
> @@ -857,7 +857,7 @@ static int igt_ppgtt_huge_fill(void *arg)
>  static int igt_ppgtt_64K(void *arg)
>  {
>   struct drm_i915_private *i915 = arg;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
>   struct drm_i915_gem_object *obj;
>   struct i915_address_space *vm;
>   struct i915_gem_context *ctx;
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index 10a7847f1b04..bac15196b4d2 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -117,7 +117,7 @@ static bool fastblit_supports_x_tiling(const struct 
> drm_i915_private *i915)
>   if (gen < 12)
>   return true;
>  
> - if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
>   return false;
>  
>   return HAS_DISPLAY(i915);
> @@ -166,7 +166,7 @@ static int prepare_blit(const struct tiled_blits *t,
>   src_pitch = t->width; /* in dwords */
>   if (src->tiling == CLIENT_TILING_Y) {
>   src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >= 
> IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >= 
> IP_VER(12, 55))
>   src_4t = XY_FAST_COPY_BLT_D1_SRC_TILE4;
>   } else if (src->tiling == CLIENT_TILING_X) {
>   src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(TILE_X);
> @@ -177,7 +177,7 @@ static int prepare_blit(const struct tiled_blits *t,
>   dst_pitch = t->width; /* in dwords */
>   if (dst->tiling == CLIENT_TILING_Y) {
>   dst_tiles = XY_FAST_COPY_BLT_D0_DST_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >= 
> IP_VER(12, 50))
> + 

Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv

[Rodrigo Vivi]

On Wed, Mar 06, 2024 at 11:36:40AM -0800, Lucas De Marchi wrote:
> PCI IDs for XEHPSDV were never added and platform always marked with
> force_probe. Drop what's not used and rename some places to either be
> xehp or dg2, depending on the platform/IP checks.
> 
> The registers not used anymore are also removed.
> 
> Signed-off-by: Lucas De Marchi 
> ---
> 
> Potential problem here that needs a deeper look, the changes in
> __gen12_fw_ranges. Some ranges had comments saying they were XEHPSDV so
> I removed them, but it needs to be double checked with spec and CI
> results.

I have checked the specs and your patch looks right because those
bits should be reserved for DG2.

But the main issue I see is that we were using that (wrongly?) for
DG2 so far. So it probably deserves a separate patch anyway.

With this patch only removing the comments and a separate patch
to remove that for DG2 (and standalone CI run on that patch by itself):

Reviewed-by: Rodrigo Vivi 

> 
>  Documentation/gpu/rfc/i915_vm_bind.h  | 11 +--
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 40 
>  drivers/gpu/drm/i915/gt/intel_gsc.c   | 15 ---
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 20 +---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 50 --
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 21 ++--
>  drivers/gpu/drm/i915/gt/intel_lrc.c   | 43 -
>  drivers/gpu/drm/i915/gt/intel_migrate.c   | 18 ++--
>  drivers/gpu/drm/i915/gt/intel_mocs.c  | 31 --
>  drivers/gpu/drm/i915/gt/intel_rps.c   |  2 -
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 95 ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c |  4 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  4 -
>  drivers/gpu/drm/i915/i915_hwmon.c |  6 --
>  drivers/gpu/drm/i915/i915_pci.c   | 17 
>  drivers/gpu/drm/i915/i915_perf.c  | 11 +--
>  drivers/gpu/drm/i915/i915_reg.h   |  3 +-
>  drivers/gpu/drm/i915/intel_clock_gating.c | 10 --
>  drivers/gpu/drm/i915/intel_device_info.c  |  1 -
>  drivers/gpu/drm/i915/intel_device_info.h  |  1 -
>  drivers/gpu/drm/i915/intel_step.c | 10 --
>  drivers/gpu/drm/i915/intel_uncore.c   | 15 +--
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |  1 -
>  .../gpu/drm/xe/compat-i915-headers/i915_drv.h |  2 -
>  24 files changed, 51 insertions(+), 380 deletions(-)
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
> b/Documentation/gpu/rfc/i915_vm_bind.h
> index 8a8fcd4fceac..bc26dc126104 100644
> --- a/Documentation/gpu/rfc/i915_vm_bind.h
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence {
>   * Multiple VA mappings can be created to the same section of the object
>   * (aliasing).
>   *
> - * The @start, @offset and @length must be 4K page aligned. However the DG2
> - * and XEHPSDV has 64K page size for device local memory and has compact page
> - * table. On those platforms, for binding device local-memory objects, the
> - * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix
> - * the local memory 64K page and the system memory 4K page bindings in the 
> same
> - * 2M range.
> + * The @start, @offset and @length must be 4K page aligned. However the DG2 
> has
> + * 64K page size for device local memory and has compact page table. On that
> + * platform, for binding device local-memory objects, the @start, @offset and
> + * @length must be 64K aligned. Also, UMDs should not mix the local memory 
> 64K
> + * page and the system memory 4K page bindings in the same 2M range.
>   *
>   * Error code -EINVAL will be returned if @start, @offset and @length are not
>   * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error 
> code
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index fa46d2308b0e..1bd0e041e15c 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -500,11 +500,11 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
>  }
>  
>  static void
> -xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
> -   struct i915_vma_resource *vma_res,
> -   struct sgt_dma *iter,
> -   unsigned int pat_index,
> -   u32 flags)
> +xehp_ppgtt_insert_huge(struct i915_address_space *vm,
> +struct i915_vma_resource *vma_res,
> +struct sgt_dma *iter,
> +unsigned int pat_index,
> +u32 flags)
>  {
>   const gen8_pte_t pte_encode = vm->pte_encode(0, pat_index, flags);
>   unsigned int rem = sg_dma_len(iter->sg);
> @@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct i915_address_space 
> *vm,
>   struct sgt_dma iter = sgt_dma(vma_res);
>  
>   if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
> - 

Re: [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use

[Imre Deak]

On Fri, Mar 08, 2024 at 10:19:58AM -0500, Rodrigo Vivi wrote:
> [...]
> > 
> > The difference between a wakeref (aka wakelock) and a raw-wakeref is
> > that the former is required for accessing the HW, which is asserted when
> > reading/writing a register. A raw-wakeref is not enough for this and is
> > only taken to prevent runtime suspending, for instance held after
> > dropping a display power reference, until the power well is actually
> > disabled in a delayed manner. During this time any register access is
> > considered invalid.
> 
> ah okay, so it is not just about the GT, but also about MMIO accesses.
> So the ones in display looks better now. Thanks for this correction.
> 
> > 
> > Both wakerefs and raw-wakerefs are tracked.
> 
> Indeed. And also it is worth to say that this patch doesn't introduce
> any change on that.
> 
> both
> intel_runtime_pm_get()
> and
> intel_runtime_pm_get_if_in_use()
> 
> calls
> intel_runtime_pm_acquire(rpm, true);
> return track_intel_runtime_pm_wakeref(rpm);
> 
> so, can we move forward with this change or do you guys see any blocker?

I also think intel_runtime_pm_get_noresume() would be more logical here,
as it's already known that rpm->usecount is non-zero,
intel_runtime_pm_get_if_in_use() also works though. Either way:

Acked-by: Imre Deak 

> Thanks a lot,
> Rodrigo.
> 
> > 
> > > One thing that crossed my mind many times already is to simply entirely
> > > remove the runtime_pm from display and do like other drivers simply
> > > checking for crtc connection at runtime_idle.
> > > 
> > > But then there are places where current display code uses the rpm
> > > in use to take different code paths, and also all the possible impact
> > > with the dc states transitions and other cases that I always gave up
> > > on the thought very quickly.
> > > 
> > > But you are right, we will have to comeback and clean things up
> > > one way or another.
> > > 
> > > But I wish we can have at least this small change in first so I don't
> > > get blocked by xe's lockdep annotation and I also don't have to
> > > workaround the annotation itself.
> > > 
> > > > 
> > > > >  
> > > > >   for_each_power_domain(domain, mask) {
> > > > >   /* Clear before put, so put's sanity check is happy. */
> > > > > -- 
> > > > > 2.43.2
> > > > 
> > > > -- 
> > > > Ville Syrjälä
> > > > Intel

[PATCH] drm/i915/dp: Fix DSC state HW readout for SST connectors

[Imre Deak]

Commit a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout")
moved the DSC HW state readout to a connector specific hook, however
only added the hook for DP MST connectors, not for DP SST ones. Fix
adding the hook for SST connectors as well.

This fixes the following warn on platforms where BIOS enables DSC:

[   66.208601] i915 :00:02.0: 
drm_WARN_ON(!connector->dp.dsc_decompression_aux || 
!connector->dp.dsc_decompression_enabled)
...
[   66.209024] RIP: 0010:intel_dp_sink_disable_decompression+0x76/0x110 [i915]
...
[   66.209333]  ? intel_dp_sink_disable_decompression+0x76/0x110 [i915]
...
[   66.210068]  intel_disable_ddi+0x135/0x1d0 [i915]
[   66.210302]  intel_encoders_disable+0x9b/0xc0 [i915]
[   66.210565]  hsw_crtc_disable+0x153/0x170 [i915]
[   66.210823]  intel_old_crtc_state_disables+0x52/0xb0 [i915]
[   66.211107]  intel_atomic_commit_tail+0x5cf/0x1330 [i915]
[   66.211366]  intel_atomic_commit+0x39d/0x3f0 [i915]
[   66.211612]  ? intel_atomic_commit+0x39d/0x3f0 [i915]
[   66.211872]  drm_atomic_commit+0x9d/0xd0 [drm]
[   66.211921]  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[   66.211975]  intel_initial_commit+0x1a8/0x260 [i915]
[   66.212234]  intel_display_driver_probe+0x2a/0x80 [i915]
[   66.212479]  i915_driver_probe+0x7c6/0xc60 [i915]
[   66.212664]  ? drm_privacy_screen_get+0x168/0x190 [drm]
[   66.212711]  i915_pci_probe+0xe2/0x1c0 [i915]

Fixes: a62e14598150 ("drm/i915/dp: Fix connector DSC HW state readout")
Cc: Ankit Nautiyal 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f98ef4b42a448..af7ca00e9bc0a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6557,6 +6557,7 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
intel_connector->get_hw_state = 
intel_ddi_connector_get_hw_state;
else
intel_connector->get_hw_state = intel_connector_get_hw_state;
+   intel_connector->sync_state = intel_dp_connector_sync_state;
 
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
intel_dp_aux_fini(intel_dp);
-- 
2.43.3

Re: [PATCH] drm/i915: Drop WA 16015675438

[Rodrigo Vivi]

On Wed, Mar 06, 2024 at 06:43:39AM -0800, Lucas De Marchi wrote:
> With dynamic load-balancing disabled on the compute side, there's no
> reason left to enable WA 16015675438. Drop it from both PVC and DG2.
> Note that this can be done because now the driver always set a fixed
> partition of EUs during initialization via the ccs_mode configuration.
> 
> The flag to GuC is still needed because of 18020744125, so update
> the comment accordingly.
> 
> Cc: Rodrigo Vivi 
> Acked-by: Mateusz Jablonski 
> Acked-by: Michal Mrozek 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> This is the i915 counter part. The xe version of this patch
> (https://lore.kernel.org/intel-xe/20240304233103.1687412-1-lucas.demar...@intel.com/)
> was already merged in drm-xe-next. I'm keeping the acked-by as it also
> applies the same logic in i915.
> 
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c  | 2 +-
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..7f812409c30a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2928,14 +2928,10 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0, 
> DISABLE_D8_D16_COASLESCE);
>   }
>  
> - if (IS_PONTEVECCHIO(i915) || IS_DG2(i915)) {
> + if (IS_PONTEVECCHIO(i915) || IS_DG2(i915))
>   /* Wa_14015227452:dg2,pvc */
>   wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN4, XEHP_DIS_BBL_SYSPIPE);
>  
> - /* Wa_16015675438:dg2,pvc */
> - wa_masked_en(wal, FF_SLICE_CS_CHICKEN2, 
> GEN12_PERF_FIX_BALANCING_CFE_DISABLE);
> - }
> -
>   if (IS_DG2(i915)) {
>   /*
>* Wa_16011620976:dg2_g11
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index d2b7425bbdcc..c6603793af89 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -315,7 +315,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>   if (IS_DG2_G11(gt->i915))
>   flags |= GUC_WA_CONTEXT_ISOLATION;
>  
> - /* Wa_16015675438 */
> + /* Wa_18020744125 */
>   if (!RCS_MASK(gt))
>   flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST;
>  
> -- 
> 2.43.0
> 

Re: [PATCH] drm/ci: update device type for volteer devices

[David Heidelberg]

Reviewed-by: David Heidelberg 

If possible, please merge this ASAP, because major move of most of the 
devices

to type acer-cp514-2h-1130g7-volteer will happen tomorrow.

Thank you

On 05/03/2024 11:16, Vignesh Raman wrote:


Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these units
has an Intel Core i5-1130G7 CPU, while some of them have a
Intel Core i7-1160G7 CPU instead. So due to this difference,
new device type template is added for the Intel Core i5-1130G7
and i7-1160G7 variants of the Acer Chromebook Spin 514 (CP514-2H)
volteer Chromebooks. So update the same in drm-ci.

https://gitlab.collabora.com/lava/lava/-/merge_requests/149

Signed-off-by: Vignesh Raman 
---
  drivers/gpu/drm/ci/test.yml | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 0857773e5c5f..8bc63912fddb 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -252,11 +252,11 @@ i915:cml:
  i915:tgl:
extends:
  - .i915
-  parallel: 8
+  parallel: 5
variables:
-DEVICE_TYPE: asus-cx9400-volteer
+DEVICE_TYPE: acer-cp514-2h-1130g7-volteer
  GPU_VERSION: tgl
-RUNNER_TAG: mesa-ci-x86-64-lava-asus-cx9400-volteer
+RUNNER_TAG: mesa-ci-x86-64-lava-acer-cp514-2h-1130g7-volteer
  
  .amdgpu:

extends:


--
David Heidelberg
Consultant Software Engineer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718



OpenPGP_0x69F567861C1EC014.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 0/4] TTM unlockable restartable LRU list iteration

[Thomas Hellström]

On Fri, 2024-03-08 at 13:13 +0530, Somalapuram, Amaranath wrote:
> Patches are tested on AMD platform.
> Repeated stress test on Unigine Heaven, memory full (VRAM + GTT +
> system 
> SWAP), then free.
> No errors/warning in kernel log.
> Any suggestion specific tests?

We are testing locally against Intel Xe CI and Intel i915 CI which
should give rather good coverage. If there are some amdgpu tests that
exercise eviction / swapping also with a lot of local objects (Vulkan
apps?) that would be great.

Thanks,
Thomas



> 
> Regards,
> S.Amarnath
> On 3/6/2024 12:31 PM, Thomas Hellström wrote:
> > This patch-set is a prerequisite for a standalone TTM shrinker
> > and for exhaustive TTM eviction using sleeping dma_resv locks,
> > which is the motivation for it.
> > 
> > Currently when unlocking the TTM lru list lock, iteration needs
> > to be restarted from the beginning, rather from the next LRU list
> > node. This can potentially be a big problem, because if eviction
> > or shrinking fails for whatever reason after unlock, restarting
> > is likely to cause the same failure over and over again.
> > 
> > There are various schemes to be able to continue the list
> > iteration from where we left off. One such scheme used by the
> > GEM LRU list traversal is to pull items already considered off
> > the LRU list and reinsert them when iteration is done.
> > This has the drawback that concurrent list iteration doesn't see
> > the complete list (which is bad for exhaustive eviction) and also
> > doesn't lend itself well to bulk-move sublists since these will
> > be split in the process where items from those lists are
> > temporarily pulled from the list and moved to the list tail.
> > 
> > The approach taken here is that list iterators insert themselves
> > into the list next position using a special list node. Iteration
> > is then using that list node as starting point when restarting.
> > Concurrent iterators just skip over the special list nodes.
> > 
> > This is implemented in patch 1 and 2.
> > 
> > For bulk move sublist the approach is the same, but when a bulk
> > move sublist is moved to the tail, the iterator is also moved,
> > causing us to skip parts of the list. That is undesirable.
> > Patch 3 deals with that, and when iterator detects it is
> > traversing a sublist, it registers with the ttm_lru_bulk_move
> > struct using a linked list, and when that bulk move sublist
> > is moved to the tail, any iterator registered with it will
> > first be moved to the tail of the sublist.
> > This is implemented in patch 3.
> > 
> > The restartable property is used in patch 4 to restart swapout if
> > needed, but the main purpose is this paves the way for
> > shrinker- and exhaustive eviction.
> > 
> > v2:
> > - Rework patch 3 completely.
> > v3:
> > - Fix a NULL pointer dereference found by Xe CI.
> > v4:
> > - Remove some leftover code causing build problems.
> > 
> > Cc: Somalapuram Amaranath 
> > Cc: Christian König 
> > Cc: 
> > 
> > Thomas Hellström (4):
> >    drm/ttm: Allow TTM LRU list nodes of different types
> >    drm/ttm: Use LRU hitches
> >    drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk
> > sublist
> >  moves
> >    drm/ttm: Allow continued swapout after -ENOSPC falure
> > 
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |   4 +
> >   drivers/gpu/drm/ttm/ttm_bo.c   |   1 +
> >   drivers/gpu/drm/ttm/ttm_device.c   |  33 +++-
> >   drivers/gpu/drm/ttm/ttm_resource.c | 228
> > -
> >   drivers/gpu/drm/xe/xe_vm.c |   4 +
> >   include/drm/ttm/ttm_device.h   |   2 +
> >   include/drm/ttm/ttm_resource.h |  96 +--
> >   7 files changed, 308 insertions(+), 60 deletions(-)
> > 

Re: [PATCH v4 2/4] drm/ttm: Use LRU hitches

[Thomas Hellström]

Hi! Thanks for reviewing. 
On Fri, 2024-03-08 at 18:50 +0530, Somalapuram, Amaranath wrote:
> 
> On 3/6/2024 12:31 PM, Thomas Hellström wrote:
> > Have iterators insert themselves into the list they are iterating
> > over using hitch list nodes. Since only the iterator owner
> > can remove these list nodes from the list, it's safe to unlock
> > the list and when continuing, use them as a starting point. Due to
> > the way LRU bumping works in TTM, newly added items will not be
> > missed, and bumped items will be iterated over a second time before
> > reaching the end of the list.
> > 
> > The exception is list with bulk move sublists. When bumping a
> > sublist, a hitch that is part of that sublist will also be moved
> > and we might miss items if restarting from it. This will be
> > addressed in a later patch.
> > 
> > v2:
> > - Updated ttm_resource_cursor_fini() documentation.
> > 
> > Cc: Christian König 
> > Cc: Somalapuram Amaranath 
> > Cc: 
> > Signed-off-by: Thomas Hellström 
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c   |  1 +
> >   drivers/gpu/drm/ttm/ttm_device.c   |  9 ++-
> >   drivers/gpu/drm/ttm/ttm_resource.c | 94 -
> > -
> >   include/drm/ttm/ttm_resource.h | 16 +++--
> >   4 files changed, 82 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > b/drivers/gpu/drm/ttm/ttm_bo.c
> > index e059b1e1b13b..b6f75a0ff2e5 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -622,6 +622,7 @@ int ttm_mem_evict_first(struct ttm_device
> > *bdev,
> >     if (locked)
> >     dma_resv_unlock(res->bo->base.resv);
> >     }
> > +   ttm_resource_cursor_fini_locked();
> >   
> >     if (!bo) {
> >     if (busy_bo && !ttm_bo_get_unless_zero(busy_bo))
> > diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> > b/drivers/gpu/drm/ttm/ttm_device.c
> > index f27406e851e5..e8a6a1dab669 100644
> > --- a/drivers/gpu/drm/ttm/ttm_device.c
> > +++ b/drivers/gpu/drm/ttm/ttm_device.c
> > @@ -169,12 +169,17 @@ int ttm_device_swapout(struct ttm_device
> > *bdev, struct ttm_operation_ctx *ctx,
> >     num_pages = PFN_UP(bo->base.size);
> >     ret = ttm_bo_swapout(bo, ctx, gfp_flags);
> >     /* ttm_bo_swapout has dropped the lru_lock
> > */
> > -   if (!ret)
> > +   if (!ret) {
> > +   ttm_resource_cursor_fini();
> 
> is spin_unlock(>lru_lock) missing ?
> 
> >     return num_pages;
> > -   if (ret != -EBUSY)
> > +   }
> > +   if (ret != -EBUSY) {
> > +   ttm_resource_cursor_fini();
> 
> is spin_unlock(>lru_lock) missing ?

The ttm_bo_swapout() function returns unlocked depending on the error
code. IIRC it only returns locked on -EBUSY. That is something we
hopefully can change when this series is in place.

/Thomas


> 
> Regards,
> S.Amarnath
> >     return ret;
> > +   }
> >     }
> >     }
> > +   ttm_resource_cursor_fini_locked();
> >     spin_unlock(>lru_lock);
> >     return 0;
> >   }
> > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> > b/drivers/gpu/drm/ttm/ttm_resource.c
> > index ee1865f82cb4..971014fca10a 100644
> > --- a/drivers/gpu/drm/ttm/ttm_resource.c
> > +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> > @@ -32,6 +32,37 @@
> >   
> >   #include 
> >   
> > +/**
> > + * ttm_resource_cursor_fini_locked() - Finalize the LRU list
> > cursor usage
> > + * @cursor: The struct ttm_resource_cursor to finalize.
> > + *
> > + * The function pulls the LRU list cursor off any lists it was
> > previusly
> > + * attached to. Needs to be called with the LRU lock held. The
> > function
> > + * can be called multiple times after eachother.
> > + */
> > +void ttm_resource_cursor_fini_locked(struct ttm_resource_cursor
> > *cursor)
> > +{
> > +   lockdep_assert_held(>man->bdev->lru_lock);
> > +   list_del_init(>hitch.link);
> > +}
> > +
> > +/**
> > + * ttm_resource_cursor_fini() - Finalize the LRU list cursor usage
> > + * @cursor: The struct ttm_resource_cursor to finalize.
> > + *
> > + * The function pulls the LRU list cursor off any lists it was
> > previusly
> > + * attached to. Needs to be called without the LRU list lock held.
> > The
> > + * function can be called multiple times after eachother.
> > + */
> > +void ttm_resource_cursor_fini(struct ttm_resource_cursor *cursor)
> > +{
> > +   spinlock_t *lru_lock = >man->bdev->lru_lock;
> > +
> > +   spin_lock(lru_lock);
> > +   ttm_resource_cursor_fini_locked(cursor);
> > +   spin_unlock(lru_lock);
> > +}
> > +
> >   /**
> >    * ttm_lru_bulk_move_init - initialize a bulk move structure
> >    * @bulk: the structure to init
> > @@ -483,62 +514,63 @@ void ttm_resource_manager_debug(struct
> > ttm_resource_manager *man,
> >   EXPORT_SYMBOL(ttm_resource_manager_debug);
> >   
> >   /**
> > - * 

Re: [PATCH v2 00/16] drm: fix headers, add header test facility

[Jani Nikula]

On Fri, 08 Mar 2024, Jani Nikula  wrote:
> Follow-up to [1], with the already merged patches dropped, review
> comments addressed, some new patches added, etc.
>
> I did still leave in the FIXME comments in "drm/i2c: silence ch7006.h
> and sil164.h kernel-doc warnings", and just silenced the
> warnings. Fairly rarely used stuff, and mostly self-explanatory. I hope
> that's fine.

Pushed everything except the last patch to drm-misc-next. Thanks for all
the acks and reviews!

BR,
Jani.



>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/all/cover.1709749576.git.jani.nik...@intel.com/
>
> Geert Uytterhoeven (1):
>   m68k: pgtable: Add missing #include 
>
> Jani Nikula (15):
>   drm: add missing header guards to drm_crtc_internal.h
>   drm: add missing header guards to drm_crtc_helper_internal.h
>   drm/encoder: improve drm_encoder_slave.h kernel-doc
>   drm/i2c: silence ch7006.h and sil164.h kernel-doc warnings
>   drm/i915: fix i915_gsc_proxy_mei_interface.h kernel-doc
>   drm/i915/hdcp: fix i915_hdcp_interface.h kernel-doc warnings
>   drm/i915/pxp: fix i915_pxp_tee_interface.h kernel-doc warnings
>   drm/ttm: fix ttm_bo.h kernel-doc warnings
>   drm/ttm: make ttm_caching.h self-contained
>   drm/ttm: fix ttm_execbuf_util.h kernel-doc warnings
>   drm/ttm: fix ttm_kmap_iter.h kernel-doc warnings
>   drm/ttm: make ttm_pool.h self-contained
>   drm/dp_mst: avoid includes in drm_dp_mst_topology_internal.h
>   drm: avoid includes in drm_crtc_helper_internal.h
>   drm: ensure drm headers are self-contained and pass kernel-doc
>
>  Kbuild|  1 +
>  arch/m68k/include/asm/pgtable.h   |  2 +
>  drivers/gpu/drm/Kconfig   | 11 +++
>  drivers/gpu/drm/Makefile  | 18 
>  .../display/drm_dp_mst_topology_internal.h|  4 +-
>  drivers/gpu/drm/drm_crtc_helper_internal.h| 15 ++-
>  drivers/gpu/drm/drm_crtc_internal.h   |  5 +
>  include/Kbuild|  1 +
>  include/drm/Makefile  | 18 
>  include/drm/drm_encoder_slave.h   | 91 +++
>  include/drm/i2c/ch7006.h  |  1 +
>  include/drm/i2c/sil164.h  |  1 +
>  include/drm/i915_gsc_proxy_mei_interface.h|  4 +-
>  include/drm/i915_hdcp_interface.h | 18 +++-
>  include/drm/i915_pxp_tee_interface.h  | 27 --
>  include/drm/ttm/ttm_bo.h  | 18 ++--
>  include/drm/ttm/ttm_caching.h |  2 +
>  include/drm/ttm/ttm_execbuf_util.h|  7 +-
>  include/drm/ttm/ttm_kmap_iter.h   |  4 +-
>  include/drm/ttm/ttm_pool.h|  5 +-
>  20 files changed, 203 insertions(+), 50 deletions(-)
>  create mode 100644 include/Kbuild
>  create mode 100644 include/drm/Makefile

-- 
Jani Nikula, Intel

Re: [PATCH v2 16/16] drm: ensure drm headers are self-contained and pass kernel-doc

[Jani Nikula]

On Fri, 08 Mar 2024, Jani Nikula  wrote:
> Ensure drm headers build, are self-contained, have header guards, and
> have no kernel-doc warnings, when CONFIG_DRM_HEADER_TEST=y.
>
> The mechanism follows similar patters used in i915, xe, and usr/include.
>
> To cover include/drm, we need to recurse there using the top level
> Kbuild and the new include/Kbuild files.
>
> Suggested-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Masahiro Yamada 
> Acked-by: Thomas Zimmermann 
> Signed-off-by: Jani Nikula 

Masahiro, ack for merging this?

BR,
Jani.

> ---
>  Kbuild   |  1 +
>  drivers/gpu/drm/Kconfig  | 11 +++
>  drivers/gpu/drm/Makefile | 18 ++
>  include/Kbuild   |  1 +
>  include/drm/Makefile | 18 ++
>  5 files changed, 49 insertions(+)
>  create mode 100644 include/Kbuild
>  create mode 100644 include/drm/Makefile
>
> diff --git a/Kbuild b/Kbuild
> index 464b34a08f51..f327ca86990c 100644
> --- a/Kbuild
> +++ b/Kbuild
> @@ -97,3 +97,4 @@ obj-$(CONFIG_SAMPLES)   += samples/
>  obj-$(CONFIG_NET)+= net/
>  obj-y+= virt/
>  obj-y+= $(ARCH_DRIVERS)
> +obj-$(CONFIG_DRM_HEADER_TEST)+= include/
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c08e18108c2a..dd17685ef6e7 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -429,3 +429,14 @@ config DRM_WERROR
> this config option is disabled by default.
>  
> If in doubt, say N.
> +
> +config DRM_HEADER_TEST
> + bool "Ensure DRM headers are self-contained and pass kernel-doc"
> + depends on EXPERT
> + default n
> + help
> +   Ensure the DRM subsystem headers both under drivers/gpu/drm and
> +   include/drm compile, are self-contained, have header guards, and have
> +   no kernel-doc warnings.
> +
> +   If in doubt, say N.
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a73c04d2d7a3..6605d5686d01 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -218,3 +218,21 @@ obj-y+= solomon/
>  obj-$(CONFIG_DRM_SPRD) += sprd/
>  obj-$(CONFIG_DRM_LOONGSON) += loongson/
>  obj-$(CONFIG_DRM_POWERVR) += imagination/
> +
> +# Ensure drm headers are self-contained and pass kernel-doc
> +hdrtest-files := \
> + $(shell cd $(srctree)/$(src) && find . -maxdepth 1 -name 'drm_*.h') \
> + $(shell cd $(srctree)/$(src) && find display lib -name '*.h')
> +
> +always-$(CONFIG_DRM_HEADER_TEST) += \
> + $(patsubst %.h,%.hdrtest, $(hdrtest-files))
> +
> +# Include the header twice to detect missing include guard.
> +quiet_cmd_hdrtest = HDRTEST $(patsubst %.hdrtest,%.h,$@)
> +  cmd_hdrtest = \
> + $(CC) $(c_flags) -fsyntax-only -x c /dev/null -include $< 
> -include $<; \
> + $(srctree)/scripts/kernel-doc -none $(if 
> $(CONFIG_DRM_WERROR),-Werror) $<; \
> + touch $@
> +
> +$(obj)/%.hdrtest: $(src)/%.h FORCE
> + $(call if_changed_dep,hdrtest)
> diff --git a/include/Kbuild b/include/Kbuild
> new file mode 100644
> index ..5e76a599e2dd
> --- /dev/null
> +++ b/include/Kbuild
> @@ -0,0 +1 @@
> +obj-$(CONFIG_DRM_HEADER_TEST)+= drm/
> diff --git a/include/drm/Makefile b/include/drm/Makefile
> new file mode 100644
> index ..b9f391d7aadd
> --- /dev/null
> +++ b/include/drm/Makefile
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Ensure drm headers are self-contained and pass kernel-doc
> +hdrtest-files := \
> + $(shell cd $(srctree)/$(src) && find * -name '*.h' 2>/dev/null)
> +
> +always-$(CONFIG_DRM_HEADER_TEST) += \
> + $(patsubst %.h,%.hdrtest, $(hdrtest-files))
> +
> +# Include the header twice to detect missing include guard.
> +quiet_cmd_hdrtest = HDRTEST $(patsubst %.hdrtest,%.h,$@)
> +  cmd_hdrtest = \
> + $(CC) $(c_flags) -fsyntax-only -x c /dev/null -include $< 
> -include $<; \
> + $(srctree)/scripts/kernel-doc -none $(if 
> $(CONFIG_DRM_WERROR),-Werror) $<; \
> + touch $@
> +
> +$(obj)/%.hdrtest: $(src)/%.h FORCE
> + $(call if_changed_dep,hdrtest)

-- 
Jani Nikula, Intel

Re: [PATCH v5] drm/i915/dp: Increase idle pattern wait timeout to 2ms

[Gustavo Sousa]

Quoting Shekhar Chauhan (2024-03-11 01:15:04-03:00)
>The driver currently waits 1ms for idle patterns,
>but for Xe2LPD and possibly future display IPs,
>it requires a 1640us (rounded up to 2ms) timeout
>whilst waiting for idle patterns for MST streams.
>
>To simplify the code, the timeout is uniformly
>increased by 1ms across all platforms/display IPs.
>
>v1: Introduced the 2ms wait timeout.
>v2: Segregated the wait timeout for platforms before & after LNL.
>v3: Fixed 2 cosmetic changes.
>v4: Revert to v2 design with commit message enhancements.
>v5: Minor cosmetic changes to the commit message.
>
>BSpec: 68849
>Signed-off-by: Shekhar Chauhan 

Reviewed-by: Gustavo Sousa 

>---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>b/drivers/gpu/drm/i915/display/intel_ddi.c
>index bea441590204..05ba3642d486 100644
>--- a/drivers/gpu/drm/i915/display/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>@@ -3680,7 +3680,7 @@ static void intel_ddi_set_idle_link_train(struct 
>intel_dp *intel_dp,
> 
> if (intel_de_wait_for_set(dev_priv,
>   dp_tp_status_reg(encoder, crtc_state),
>-  DP_TP_STATUS_IDLE_DONE, 1))
>+  DP_TP_STATUS_IDLE_DONE, 2))
> drm_err(_priv->drm,
> "Timed out waiting for DP idle patterns\n");
> }
>-- 
>2.34.1
>

Re: [PATCH v3 0/6] VBT read cleanup

[Jani Nikula]

On Wed, 28 Feb 2024, Radhakrishna Sripada  
wrote:
> This series is originally based out of [1], and built on top of [2].
>
> The primary departure from [1] was that vbt is no longer cached. During vbt
> show, based on the source of vbt, it would simply be re-read reducing the
> read/cleanup complexity. With this series debugfs dump of vbt should work on
> all the platforms that support display.
>
> v3 of the series extracts opregion firmware check and harmonizes the memory
> handling of different variants viz. opregion/oprom/spi/fimrware
>
> 1. https://patchwork.freedesktop.org/series/128341/
> 2. https://patchwork.freedesktop.org/series/128683/

Thanks for the patches, pushed to din.

BR,
Jani.

>
>
> Radhakrishna Sripada (6):
>   drm/i915: Pass size to oprom_get_vbt
>   drm/i915: Pass size to spi_oprom_get_vbt
>   drm/i915: Move vbt read from firmware to intel_bios.c
>   drm/i915: Extract opregion vbt presence check
>   drm/i915: Duplicate opregion vbt memory
>   drm/i915: Show bios vbt when read from firmware/spi/oprom
>
>  drivers/gpu/drm/i915/display/intel_bios.c | 108 +-
>  drivers/gpu/drm/i915/display/intel_opregion.c |  58 ++
>  drivers/gpu/drm/i915/display/intel_opregion.h |   1 +
>  3 files changed, 92 insertions(+), 75 deletions(-)

-- 
Jani Nikula, Intel

[PATCH v17 8/9] drm/i915/display: Compute vrr_vsync params

[Mitul Golani]

Compute vrr_vsync_start/end, which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.

--v2:
- Updated VSYNC_START/END macros to VRR_VSYNC_START/END. (Ankit)
- Updated bit fields of VRR_VSYNC_START/END. (Ankit)

--v3:
- Add PIPE_CONF_CHECK_I(vrr.vsync_start/end).
- Read/write vrr_vsync params only when we intend to send
adaptive_sync sdp.

--v4:
- Use VRR_SYNC_START/END macros correctly.

Signed-off-by: Mitul Golani 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  2 ++
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_vrr.c  | 30 +--
 drivers/gpu/drm/i915/i915_reg.h   |  7 +
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f1d948408d3..fed4ed18d53b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5377,6 +5377,8 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(vrr.flipline);
PIPE_CONF_CHECK_I(vrr.pipeline_full);
PIPE_CONF_CHECK_I(vrr.guardband);
+   PIPE_CONF_CHECK_I(vrr.vsync_start);
+   PIPE_CONF_CHECK_I(vrr.vsync_end);
}
 
 #undef PIPE_CONF_CHECK_X
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8a286751dc39..c2e08f641989 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1430,6 +1430,7 @@ struct intel_crtc_state {
bool enable, in_range;
u8 pipeline_full;
u16 flipline, vmin, vmax, guardband;
+   u32 vsync_end, vsync_start;
} vrr;
 
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index eb5bd0743902..ed38fee196b8 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -9,6 +9,7 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_vrr.h"
+#include "intel_dp.h"
 
 bool intel_vrr_is_capable(struct intel_connector *connector)
 {
@@ -113,6 +114,7 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
const struct drm_display_info *info = >base.display_info;
int vmin, vmax;
@@ -165,6 +167,15 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
if (crtc_state->uapi.vrr_enabled) {
crtc_state->vrr.enable = true;
crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
+
+   if (intel_dp_as_sdp_supported(intel_dp)) {
+   crtc_state->vrr.vsync_start =
+   (crtc_state->hw.adjusted_mode.crtc_vtotal -
+   
crtc_state->hw.adjusted_mode.vsync_start);
+   crtc_state->vrr.vsync_end =
+   (crtc_state->hw.adjusted_mode.crtc_vtotal -
+   crtc_state->hw.adjusted_mode.vsync_end);
+   }
}
 }
 
@@ -204,6 +215,11 @@ void intel_vrr_set_transcoder_timings(const struct 
intel_crtc_state *crtc_state)
intel_de_write(dev_priv, TRANS_VRR_VMAX(cpu_transcoder), 
crtc_state->vrr.vmax - 1);
intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder), 
trans_vrr_ctl(crtc_state));
intel_de_write(dev_priv, TRANS_VRR_FLIPLINE(cpu_transcoder), 
crtc_state->vrr.flipline - 1);
+
+   if (crtc_state->vrr.vsync_end && crtc_state->vrr.vsync_start)
+   intel_de_write(dev_priv, TRANS_VRR_VSYNC(cpu_transcoder),
+  
VRR_VSYNC_END(crtc_state->hw.adjusted_mode.vsync_end) |
+  
VRR_VSYNC_START(crtc_state->hw.adjusted_mode.vsync_start));
 }
 
 void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
@@ -264,7 +280,7 @@ void intel_vrr_get_config(struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
-   u32 trans_vrr_ctl;
+   u32 trans_vrr_ctl, trans_vrr_vsync;
 
trans_vrr_ctl = intel_de_read(dev_priv, TRANS_VRR_CTL(cpu_transcoder));
 
@@ -284,6 +300,16 @@ void intel_vrr_get_config(struct intel_crtc_state 
*crtc_state)
crtc_state->vrr.vmin = intel_de_read(dev_priv, 
TRANS_VRR_VMIN(cpu_transcoder)) + 1;
}
 
-

[PATCH v17 9/9] drm/i915/display: Read/Write Adaptive Sync SDP

[Mitul Golani]

Add read/write calls for Adaptive Sync SDP.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c587a8efeafc..f164020a4773 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3972,6 +3972,7 @@ static void intel_ddi_get_config(struct intel_encoder 
*encoder,
 
intel_read_dp_sdp(encoder, pipe_config, 
HDMI_PACKET_TYPE_GAMUT_METADATA);
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
+   intel_read_dp_sdp(encoder, pipe_config, DP_SDP_ADAPTIVE_SYNC);
 
intel_audio_codec_get_config(encoder, pipe_config);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9ed0c66ea63..3f377a743bc4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4322,6 +4322,7 @@ void intel_dp_set_infoframes(struct intel_encoder 
*encoder,
return;
 
intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
+   intel_write_dp_sdp(encoder, crtc_state, DP_SDP_ADAPTIVE_SYNC);
 
intel_write_dp_sdp(encoder, crtc_state, 
HDMI_PACKET_TYPE_GAMUT_METADATA);
 }
-- 
2.25.1

[PATCH v17 7/9] drm/i915/display: Add state checker for Adaptive Sync SDP

[Mitul Golani]

Enable infoframe and add state checker for Adaptive Sync
SDP enablement.

--v1:
- crtc_state->infoframes.enable, to add on correct place holder.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_display.c | 46 
 1 file changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b88f214e111a..8f1d948408d3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4791,6 +4791,17 @@ intel_compare_dp_vsc_sdp(const struct drm_dp_vsc_sdp *a,
a->content_type == b->content_type;
 }
 
+static bool
+intel_compare_dp_as_sdp(const struct drm_dp_as_sdp *a,
+   const struct drm_dp_as_sdp *b)
+{
+   return a->vtotal == b->vtotal &&
+   a->target_rr == b->target_rr &&
+   a->duration_incr_ms == b->duration_incr_ms &&
+   a->duration_decr_ms == b->duration_decr_ms &&
+   a->mode == b->mode;
+}
+
 static bool
 intel_compare_buffer(const u8 *a, const u8 *b, size_t len)
 {
@@ -4846,6 +4857,30 @@ pipe_config_dp_vsc_sdp_mismatch(struct drm_i915_private 
*i915,
drm_dp_vsc_sdp_log(, b);
 }
 
+static void
+pipe_config_dp_as_sdp_mismatch(struct drm_i915_private *i915,
+  bool fastset, const char *name,
+  const struct drm_dp_as_sdp *a,
+  const struct drm_dp_as_sdp *b)
+{
+   struct drm_printer p;
+
+   if (fastset) {
+   p = drm_dbg_printer(>drm, DRM_UT_KMS, NULL);
+
+   drm_printf(, "fastset requirement not met in %s dp sdp\n", 
name);
+   } else {
+   p = drm_err_printer(>drm, NULL);
+
+   drm_printf(, "mismatch in %s dp sdp\n", name);
+   }
+
+   drm_printf(, "expected:\n");
+   drm_dp_as_sdp_log(, a);
+   drm_printf(, "found:\n");
+   drm_dp_as_sdp_log(, b);
+}
+
 /* Returns the length up to and including the last differing byte */
 static size_t
 memcmp_diff_len(const u8 *a, const u8 *b, size_t len)
@@ -5099,6 +5134,16 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
} \
 } while (0)
 
+#define PIPE_CONF_CHECK_DP_AS_SDP(name) do { \
+   if (!intel_compare_dp_as_sdp(_config->infoframes.name, \
+ _config->infoframes.name)) { \
+   pipe_config_dp_as_sdp_mismatch(dev_priv, fastset, 
__stringify(name), \
+   
_config->infoframes.name, \
+   _config->infoframes.name); 
\
+   ret = false; \
+   } \
+} while (0)
+
 #define PIPE_CONF_CHECK_BUFFER(name, len) do { \
BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
@@ -5280,6 +5325,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_INFOFRAME(hdmi);
PIPE_CONF_CHECK_INFOFRAME(drm);
PIPE_CONF_CHECK_DP_VSC_SDP(vsc);
+   PIPE_CONF_CHECK_DP_AS_SDP(as_sdp);
 
PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
PIPE_CONF_CHECK_I(master_transcoder);
-- 
2.25.1

[PATCH v17 5/9] drm/i915/dp: Add wrapper function to check AS SDP

[Mitul Golani]

Add a wrapper function to check if both the source and
sink support Adaptive Sync SDP.

--v1:
Just use drm/i915/dp in subject line.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 8 
 drivers/gpu/drm/i915/display/intel_dp.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index aea524713df2..3c8bca12dd6f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -123,6 +123,14 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
return dig_port->base.type == INTEL_OUTPUT_EDP;
 }
 
+bool intel_dp_as_sdp_supported(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   return HAS_AS_SDP(i915) &&
+   drm_dp_as_sdp_supported(_dp->aux, intel_dp->dpcd);
+}
+
 static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 
 /* Is link rate UHBR and thus 128b/132b? */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index c540d3a73fe7..9f880d7865d1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -88,6 +88,7 @@ void intel_dp_audio_compute_config(struct intel_encoder 
*encoder,
   struct drm_connector_state *conn_state);
 bool intel_dp_has_hdmi_sink(struct intel_dp *intel_dp);
 bool intel_dp_is_edp(struct intel_dp *intel_dp);
+bool intel_dp_as_sdp_supported(struct intel_dp *intel_dp);
 bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state);
 int intel_dp_link_symbol_size(int rate);
 int intel_dp_link_symbol_clock(int rate);
-- 
2.25.1

[PATCH v17 6/9] drm/i915/display: Compute AS SDP parameters

[Mitul Golani]

Add necessary function definitions to compute AS SDP data.
The new intel_dp_compute_as_sdp function computes AS SDP
values based on the display configuration, ensuring proper
handling of Variable Refresh Rate (VRR).

--v2:
- Added DP_SDP_ADAPTIVE_SYNC to infoframe_type_to_idx(). [Ankit]
- Separated patch for intel_read/write_dp_sdp. [Ankit]
- _HSW_VIDEO_DIP_ASYNC_DATA_A should be from ADL onward. [Ankit]
- Fixed indentation issues. [Ankit]

--v3:
- Added VIDEO_DIP_ENABLE_AS_HSW flag to intel_dp_set_infoframes.

--v4:
- Added HAS_VRR check before writing AS SDP.

--v5:
Added missed HAS_VRR check before reading AS SDP.

--v6:
- Used Adaptive Sync sink status as a check for read/write SDP. (Ankit)

--v7:
- Remove as_sdp_enable from crtc_state.
- Add a comment mentioning current support of
  DP_AS_SDP_AVT_FIXED_VTOTAL.
- Add state checker for AS_SDP infoframe enable.

--v8:
- Drop conn_state from intel_dp_compute_as_sdp, as not used.
- Remove fullstop in subject line.

--v9:
- Add vrr.enable instead of is_in_vrr_range.

--v10:
- remove vrefresh and connector, as they are no  longer required.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3c8bca12dd6f..a9ed0c66ea63 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2621,6 +2621,29 @@ static void intel_dp_compute_vsc_colorimetry(const 
struct intel_crtc_state *crtc
vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
 }
 
+static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
+   struct intel_crtc_state *crtc_state)
+{
+   struct drm_dp_as_sdp *as_sdp = _state->infoframes.as_sdp;
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+
+   if (!crtc_state->vrr.enable ||
+   !intel_dp_as_sdp_supported(intel_dp))
+   return;
+
+   crtc_state->infoframes.enable |= 
intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC);
+
+   /* Currently only DP_AS_SDP_AVT_FIXED_VTOTAL mode supported */
+   as_sdp->sdp_type = DP_SDP_ADAPTIVE_SYNC;
+   as_sdp->length = 0x9;
+   as_sdp->mode = DP_AS_SDP_AVT_FIXED_VTOTAL;
+   as_sdp->vtotal = adjusted_mode->vtotal;
+   as_sdp->target_rr = 0;
+   as_sdp->duration_incr_ms = 0;
+   as_sdp->duration_incr_ms = 0;
+}
+
 static void intel_dp_compute_vsc_sdp(struct intel_dp *intel_dp,
 struct intel_crtc_state *crtc_state,
 const struct drm_connector_state 
*conn_state)
@@ -2972,6 +2995,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
g4x_dp_set_clock(encoder, pipe_config);
 
intel_vrr_compute_config(pipe_config, conn_state);
+   intel_dp_compute_as_sdp(intel_dp, pipe_config);
intel_psr_compute_config(intel_dp, pipe_config, conn_state);
intel_dp_drrs_compute_config(connector, pipe_config, link_bpp_x16);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
-- 
2.25.1

[PATCH v17 4/9] drm/i915/dp: Add Read/Write support for Adaptive Sync SDP

[Mitul Golani]

Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.

--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]

--v3:
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)

--v4:
- Remove as_sdp_mode from crtc_state.
- Drop metadata keyword.
- For consistency, update ADL_ prefix or post fix as required.

--v5:
- Check if AS_SDP bit is set in crtc_state->infoframes.enable. If not
  return.
- Check for HAS_AS_SDP() before setting VIDEO_DIP_ENABLE_AS_ADL mask.

--v6:
- Rename intel_read_dp_infoframe_as_sdp to intel_read_dp_as_sdp.

--v7:
- Add read back for length and vtotal correction.

--v8:
- Use as_sdp->target_rr & 0xFF.
- Shift by 8 instead of 32, and drop casting to u64.
-  Remove changes which are does not belong to this patch.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 .../drm/i915/display/intel_display_device.h   |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 92 +++
 drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  8 ++
 4 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
b/drivers/gpu/drm/i915/display/intel_display_device.h
index fe4268813786..6399fbc6c738 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -68,6 +68,7 @@ struct drm_printer;
 #define HAS_TRANSCODER(i915, trans)
((DISPLAY_RUNTIME_INFO(i915)->cpu_transcoder_mask & \
  BIT(trans)) != 0)
 #define HAS_VRR(i915)  (DISPLAY_VER(i915) >= 11)
+#define HAS_AS_SDP(i915)   (DISPLAY_VER(i915) >= 13)
 #define INTEL_NUM_PIPES(i915)  
(hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
 #define I915_HAS_HOTPLUG(i915) (DISPLAY_INFO(i915)->has_hotplug)
 #define OVERLAY_NEEDS_PHYSICAL(i915)   
(DISPLAY_INFO(i915)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f98ef4b42a44..aea524713df2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4119,6 +4119,32 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state 
*crtc_state,
return false;
 }
 
+static ssize_t intel_dp_as_sdp_pack(const struct drm_dp_as_sdp *as_sdp,
+   struct dp_sdp *sdp, size_t size)
+{
+   size_t length = sizeof(struct dp_sdp);
+
+   if (size < length)
+   return -ENOSPC;
+
+   memset(sdp, 0, size);
+
+   /* Prepare AS (Adaptive Sync) SDP Header */
+   sdp->sdp_header.HB0 = 0;
+   sdp->sdp_header.HB1 = as_sdp->sdp_type;
+   sdp->sdp_header.HB2 = 0x02;
+   sdp->sdp_header.HB3 = as_sdp->length;
+
+   /* Fill AS (Adaptive Sync) SDP Payload */
+   sdp->db[0] = as_sdp->mode;
+   sdp->db[1] = as_sdp->vtotal & 0xFF;
+   sdp->db[2] = (as_sdp->vtotal >> 8) & 0xFF;
+   sdp->db[3] = as_sdp->target_rr & 0xFF;
+   sdp->db[4] = (as_sdp->target_rr >> 8) & 0x3;
+
+   return length;
+}
+
 static ssize_t
 intel_dp_hdr_metadata_infoframe_sdp_pack(struct drm_i915_private *i915,
 const struct hdmi_drm_infoframe 
*drm_infoframe,
@@ -4218,6 +4244,10 @@ static void intel_write_dp_sdp(struct intel_encoder 
*encoder,
   
_state->infoframes.drm.drm,
   , 
sizeof(sdp));
break;
+   case DP_SDP_ADAPTIVE_SYNC:
+   len = intel_dp_as_sdp_pack(_state->infoframes.as_sdp, ,
+  sizeof(sdp));
+   break;
default:
MISSING_CASE(type);
return;
@@ -4239,6 +4269,10 @@ void intel_dp_set_infoframes(struct intel_encoder 
*encoder,
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
 VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
 VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
+
+   if (HAS_AS_SDP(dev_priv))
+   dip_enable |= VIDEO_DIP_ENABLE_AS_ADL;
+
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
 
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
@@ -4260,6 +4294,37 @@ void intel_dp_set_infoframes(struct intel_encoder 
*encoder,
intel_write_dp_sdp(encoder, crtc_state, 
HDMI_PACKET_TYPE_GAMUT_METADATA);
 }
 
+static
+int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp,
+  const void *buffer, size_t size)
+{
+   const struct dp_sdp *sdp = 

[PATCH v17 2/9] drm: Add Adaptive Sync SDP logging

[Mitul Golani]

Add structure representing Adaptive Sync Secondary Data Packet (AS SDP).
Also, add Adaptive Sync SDP logging in drm_dp_helper.c to facilitate
debugging.

--v2:
- Update logging. [Jani, Ankit]
- Use 'as_sdp' instead of 'async' [Ankit]
- Correct define placeholders to where they are actually used. [Jani]
- Update members in 'as_sdp' structure to make it uniform. [Jani]

--v3:
- Added changes to dri-devel mailing list. No code changes.

--v4:
- Instead of directly using operation mode, use an enum to accommodate
all operation modes (Ankit).

--v5:
Nit-pick changes to commit message.

--v6:
- Add correct place holder and name change for AS_SDP_OP_MODE.
- Separate i915 changes from drm changes.
- Remove extra lines.

--v7:
- Add drm/i915/display in subject line.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 12 ++
 include/drm/display/drm_dp.h| 11 ++
 include/drm/display/drm_dp_helper.h | 29 +
 3 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index f2fabb673aa4..f880bc7b2153 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2948,6 +2948,18 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const 
struct drm_dp_vsc_sdp *vsc)
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
 
+void drm_dp_as_sdp_log(struct drm_printer *p, const struct drm_dp_as_sdp 
*as_sdp)
+{
+   drm_printf(p, "DP SDP: AS_SDP, revision %u, length %u\n",
+  as_sdp->revision, as_sdp->length);
+   drm_printf(p, "vtotal: %d\n", as_sdp->vtotal);
+   drm_printf(p, "target_rr: %d\n", as_sdp->target_rr);
+   drm_printf(p, "duration_incr_ms: %d\n", as_sdp->duration_incr_ms);
+   drm_printf(p, "duration_decr_ms: %d\n", as_sdp->duration_decr_ms);
+   drm_printf(p, "operation_mode: %d\n", as_sdp->mode);
+}
+EXPORT_SYMBOL(drm_dp_as_sdp_log);
+
 /**
  * drm_dp_as_sdp_supported() - check if adaptive sync sdp is supported
  * @aux: DisplayPort AUX channel
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 4891bd916d26..0b032faa8cf2 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1150,6 +1150,8 @@
 
 #define DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1 0x2214 /* 2.0 E11 */
 # define DP_ADAPTIVE_SYNC_SDP_SUPPORTED(1 << 0)
+# define DP_ADAPTIVE_SYNC_SDP_OPERATION_MODE   GENMASK(1, 0)
+# define DP_ADAPTIVE_SYNC_SDP_LENGTH   GENMASK(5, 0)
 # define DP_AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED (1 
<< 1)
 # define DP_VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED  (1 << 4)
 
@@ -1639,10 +1641,12 @@ enum drm_dp_phy {
 #define DP_SDP_AUDIO_COPYMANAGEMENT0x05 /* DP 1.2 */
 #define DP_SDP_ISRC0x06 /* DP 1.2 */
 #define DP_SDP_VSC 0x07 /* DP 1.2 */
+#define DP_SDP_ADAPTIVE_SYNC   0x22 /* DP 1.4 */
 #define DP_SDP_CAMERA_GENERIC(i)   (0x08 + (i)) /* 0-7, DP 1.3 */
 #define DP_SDP_PPS 0x10 /* DP 1.4 */
 #define DP_SDP_VSC_EXT_VESA0x20 /* DP 1.4 */
 #define DP_SDP_VSC_EXT_CEA 0x21 /* DP 1.4 */
+
 /* 0x80+ CEA-861 infoframe types */
 
 #define DP_SDP_AUDIO_INFOFRAME_HB2 0x1b
@@ -1798,4 +1802,11 @@ enum dp_content_type {
DP_CONTENT_TYPE_GAME = 0x04,
 };
 
+enum operation_mode {
+   DP_AS_SDP_AVT_DYNAMIC_VTOTAL = 0x00,
+   DP_AS_SDP_AVT_FIXED_VTOTAL = 0x01,
+   DP_AS_SDP_FAVT_TRR_NOT_REACHED = 0x02,
+   DP_AS_SDP_FAVT_TRR_REACHED = 0x03
+};
+
 #endif /* _DRM_DP_H_ */
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index 7df19acdc790..10147ae96326 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -98,6 +98,35 @@ struct drm_dp_vsc_sdp {
enum dp_content_type content_type;
 };
 
+/**
+ * struct drm_dp_as_sdp - drm DP Adaptive Sync SDP
+ *
+ * This structure represents a DP AS SDP of drm
+ * It is based on DP 2.1 spec [Table 2-126:  Adaptive-Sync SDP Header Bytes] 
and
+ * [Table 2-127: Adaptive-Sync SDP Payload for DB0 through DB8]
+ *
+ * @sdp_type: Secondary-data packet type
+ * @revision: Revision Number
+ * @length: Number of valid data bytes
+ * @vtotal: Minimum Vertical Vtotal
+ * @target_rr: Target Refresh
+ * @duration_incr_ms: Successive frame duration increase
+ * @duration_decr_ms: Successive frame duration decrease
+ * @operation_mode: Adaptive Sync Operation Mode
+ */
+struct drm_dp_as_sdp {
+   unsigned char sdp_type;
+   unsigned char revision;
+   unsigned char length;
+   int vtotal;
+   int target_rr;
+   int duration_incr_ms;
+   int duration_decr_ms;
+   enum operation_mode mode;
+};
+
+void drm_dp_as_sdp_log(struct drm_printer *p,
+  const struct drm_dp_as_sdp *as_sdp);
 void 

[PATCH v17 3/9] drm/i915/display: Add crtc state dump for Adaptive Sync SDP

[Mitul Golani]

Add crtc state dump for Adaptive Sync SDP to know which
crtc specifically caused the failure.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 .../gpu/drm/i915/display/intel_crtc_state_dump.c| 13 +
 drivers/gpu/drm/i915/display/intel_display_types.h  |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 4bcf446c75f4..1e4618271156 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -51,6 +51,15 @@ intel_dump_infoframe(struct drm_i915_private *i915,
hdmi_infoframe_log(KERN_DEBUG, i915->drm.dev, frame);
 }
 
+static void
+intel_dump_dp_as_sdp(struct drm_i915_private *i915,
+const struct drm_dp_as_sdp *as_sdp)
+{
+   struct drm_printer p = drm_dbg_printer(>drm, DRM_UT_KMS, 
"AS_SDP");
+
+   drm_dp_as_sdp_log(, as_sdp);
+}
+
 static void
 intel_dump_dp_vsc_sdp(struct drm_i915_private *i915,
  const struct drm_dp_vsc_sdp *vsc)
@@ -302,6 +311,10 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(DP_SDP_VSC))
intel_dump_dp_vsc_sdp(i915, _config->infoframes.vsc);
+   if (pipe_config->infoframes.enable &
+   intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC))
+   intel_dump_dp_as_sdp(i915, _config->infoframes.as_sdp);
+
 
if (pipe_config->has_audio)
intel_dump_buffer(i915, "ELD: ", pipe_config->eld,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e67cd5b02e84..8a286751dc39 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1345,6 +1345,7 @@ struct intel_crtc_state {
union hdmi_infoframe hdmi;
union hdmi_infoframe drm;
struct drm_dp_vsc_sdp vsc;
+   struct drm_dp_as_sdp as_sdp;
} infoframes;
 
u8 eld[MAX_ELD_BYTES];
-- 
2.25.1

[PATCH v17 1/9] drm/dp: Add support to indicate if sink supports AS SDP

[Mitul Golani]

Add an API that indicates support for Adaptive Sync SDP in
the sink, which can be utilized by the rest of the DP programming.

--v1:
- Format commit message properly.

Signed-off-by: Mitul Golani 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 25 +
 include/drm/display/drm_dp_helper.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 266826eac4a7..f2fabb673aa4 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2948,6 +2948,31 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const 
struct drm_dp_vsc_sdp *vsc)
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
 
+/**
+ * drm_dp_as_sdp_supported() - check if adaptive sync sdp is supported
+ * @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
+ *
+ * Returns true if adaptive sync sdp is supported, else returns false
+ */
+bool drm_dp_as_sdp_supported(struct drm_dp_aux *aux, const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   u8 rx_feature;
+
+   if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_13)
+   return false;
+
+   if (drm_dp_dpcd_readb(aux, DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1,
+ _feature) != 1) {
+   drm_dbg_dp(aux->drm_dev,
+  "Failed to read 
DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1\n");
+   return false;
+   }
+
+   return (rx_feature & DP_ADAPTIVE_SYNC_SDP_SUPPORTED);
+}
+EXPORT_SYMBOL(drm_dp_as_sdp_supported);
+
 /**
  * drm_dp_vsc_sdp_supported() - check if vsc sdp is supported
  * @aux: DisplayPort AUX channel
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index a62fcd051d4d..7df19acdc790 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -101,6 +101,7 @@ struct drm_dp_vsc_sdp {
 void drm_dp_vsc_sdp_log(struct drm_printer *p, const struct drm_dp_vsc_sdp 
*vsc);
 
 bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8 
dpcd[DP_RECEIVER_CAP_SIZE]);
+bool drm_dp_as_sdp_supported(struct drm_dp_aux *aux, const u8 
dpcd[DP_RECEIVER_CAP_SIZE]);
 
 int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
 
-- 
2.25.1

[PATCH v17 0/9] Enable Adaptive Sync SDP Support for DP

[Mitul Golani]

 An Adaptive-Sync-capable DP protocol converter indicates its
support by setting the related bit in the DPCD register. This
is valid for DP and edp as well.

Computes AS SDP values based on the display configuration,
ensuring proper handling of Variable Refresh Rate (VRR)
in the context of Adaptive Sync.

--v2:
- Update logging to Patch-1
- use as_sdp instead of async
- Put definitions to correct placeholders from where it is defined.
- Update member types of as_sdp for uniformity.
- Correct use of REG_BIT and REG_GENMASK.
- Remove unrelated comments and changes.
- Correct code indents.
- separate out patch changes for intel_read/write_dp_sdp.

--v3:
- Add VIDEO_DIP_ASYNC_DATA_SIZE definition and comment in as_sdp_pack
  function to patch 2 as originally used there. [Patch 2].
- Add VIDEO_DIP_ENABLE_AS_HSW flag to intel_dp_set_infoframes [Patch 3].

--v4:
- Add check for HAS_VRR before writing AS SDP. [Patch 3].

--v5:
- Add missing check for HAS_VRR before reading AS SDP as well [Patch 3].

--v6:
- Rebase all patches.
- Compute TRANS_VRR_VSYNC.

-v7:
- Move vrr_vsync_start/end to compute config.
- Use correct function for drm_debug_printer.

-v8:
- Code refactoring.
- Update, VSYNC_START/END macros to VRR_VSYNC_START/END.(Ankit)
- Update bit fields of VRR_VSYNC_START/END.(Ankit)
- Send patches to dri-devel.(Ankit)
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)
- Remove unused bitfield define, AS_SDP_ENABLE.
- Add support in drm for Adaptive Sync sink status, which can be
used later as a check for read/write sdp. (Ankit)

-v9:
- Add enum to operation mode to represent different AVT and
FAVT modes. (Ankit)
- Operation_mode, target_rr etc should be filled from as_sdp struct. (Ankit)
- Fill as_sdp->*All Params* from compute config, read from the sdp. (Ankit)
- Move configs to the appropriate patch where it used first.(Ankit)
- There should be a check if as sdp is enable is set or not. (Ankit)
- Add variables in crtc state->vrr for ad sdp enable and operation mode. (Ankit)
- Use above variables for tracking AS SDP. (Ankit)
- Revert unused changes. (Ankit)

-v10:
- Send Patches to dri-devel (Ankit).

-v11:
- Remove as_sdp_mode and enable from crtc_state.
- For consistency, update ADL_ prefix or post fix as required.
- Add a comment mentioning current support of
  DP_AS_SDP_AVT_FIXED_VTOTAL.
- Add state checker for AS_SDP infoframe enable.
- Add PIPE_CONF_CHECK_I(vrr.vsync_start/end).
- Read/write vrr_vsync params only when we intend to send
adaptive_sync sdp.

-v12:
- Update cover letter

-v13:
- Add correct place holder and name change for AS_SDP_OP_MODE.
- Separate i915 changes from drm changes.
- Remove extra lines.
- Check if AS_SDP bit is set in crtc_state->infoframes.enable. If not
  return.
- Check for HAS_AS_SDP() before setting VIDEO_DIP_ENABLE_AS_ADL mask.
- Just use drm/i915/dp in subject line.
- Drop conn_state from intel_dp_compute_as_sdp, as not used.
- Remove fullstop in subject line.
- crtc_state->infoframes.enable, to add on correct place holder.

--v14:
- Mistakenly dropped first patch, adding back.

--v15:
- Rename intel_read_dp_infoframe_as_sdp to intel_read_dp_as_sdp.
- Add an entry in g4x_infoframe_enable.
- Instead of intel_vrr_is_in_range, use crtc_state->vrr.enable in AS SDP
compute config.

--v16:
- Add drm/i915/display in subject line.
- Use as_sdp->target_rr & 0xFF.
- Shift by 8 instead of 32, and drop casting to u64.
- Remove does not belong to respective patch.
- Remove vrefresh and connector, as they are no longer required.
- Use VRR_SYNC_START/END macros correctly.
- Update commit message for Patch#9

--v17:
- Relocate vrr vsync params.

Signed-off-by: Mitul Golani 

Mitul Golani (9):
  drm/dp: Add support to indicate if sink supports AS SDP
  drm: Add Adaptive Sync SDP logging
  drm/i915/display: Add crtc state dump for Adaptive Sync SDP
  drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
  drm/i915/dp: Add wrapper function to check AS SDP
  drm/i915/display: Compute AS SDP parameters
  drm/i915/display: Add state checker for Adaptive Sync SDP
  drm/i915/display: Compute vrr_vsync params
  drm/i915/display: Read/Write Adaptive Sync SDP

 drivers/gpu/drm/display/drm_dp_helper.c   |  37 ++
 .../drm/i915/display/intel_crtc_state_dump.c  |  13 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  48 +++
 .../drm/i915/display/intel_display_device.h   |   1 +
 .../drm/i915/display/intel_display_types.h|   2 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 125 ++
 drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |  14 +-
 drivers/gpu/drm/i915/display/intel_vrr.c  |  30 -
 drivers/gpu/drm/i915/i915_reg.h   |  15 +++
 include/drm/display/drm_dp.h  |  11 ++
 include/drm/display/drm_dp_helper.h   |  30 +
 13 files changed, 325 

Re: [PATCH 2/2] drm/i915: Implement vblank synchronized MBUS join changes

[Lisovskiy, Stanislav]

On Fri, Mar 08, 2024 at 05:11:42PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 08, 2024 at 03:43:35PM +0200, Lisovskiy, Stanislav wrote:
> > On Fri, Mar 08, 2024 at 12:07:19PM +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2024 at 10:02:13AM +0200, Stanislav Lisovskiy wrote:
> > > > Currently we can't change MBUS join status without doing a modeset,
> > > > because we are lacking mechanism to synchronize those with vblank.
> > > > However then this means that we can't do a fastset, if there is a need
> > > > to change MBUS join state. Fix that by implementing such change.
> > > > We already call correspondent check and update at pre_plane dbuf update,
> > > > so the only thing left is to have a non-modeset version of that.
> > > > If active pipes stay the same then fastset is possible and only MBUS
> > > > join state/ddb allocation updates would be committed.
> > > > 
> > > > v2: Implement additional changes according to BSpec.
> > > > Vblank wait is needed after MBus/Dbuf programming in case if
> > > > no modeset is done and we are switching from single to multiple
> > > > displays, i.e mbus join state switches from "joined" to  
> > > > "non-joined"
> > > > state. Otherwise vblank wait is not needed according to spec.
> > > > 
> > > > v3: Split mbus and dbox programming into to pre/post plane update parts,
> > > > how it should be done according to BSpec.
> > > > 
> > > > v4: - Place "single display to multiple displays scenario" MBUS/DBOX 
> > > > programming
> > > >   after DDB reallocation, but before crtc enabling(that is where is 
> > > > has
> > > >   to be according to spec).
> > > > - Check if crtc is still active, not only the old state.
> > > > - Do a vblank wait if MBUX DBOX register was modified.
> > > > - And of course do vblank wait only if crtc was active.
> > > > - Do vblank wait only if we are not doing a modeset, if we are doing
> > > >   something before *commit_modeset_enables, because all crtcs might 
> > > > be
> > > >   disabled at this moment, so we will get WARN if try waiting for 
> > > > vblank
> > > >   then.
> > > > - Still getting FIFO underrun so try waiting for vblank in 
> > > > pre_plane update
> > > >   as well.
> > > > - Write also pipe that we need to sync with to MBUS_CTL register.
> > > > 
> > > > v5: - Do vblank wait only for the first pipe, if mbus is joined
> > > > - Check also if new/old_dbuf_state is not NULL, before getting 
> > > > single pipe
> > > >   and active pipes.
> > > > 
> > > > Signed-off-by: Stanislav Lisovskiy 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_display.c |  13 ++-
> > > >  drivers/gpu/drm/i915/display/skl_watermark.c | 104 +++
> > > >  drivers/gpu/drm/i915/display/skl_watermark.h |   1 +
> > > >  3 files changed, 96 insertions(+), 22 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 00ac65a140298..989818f5d342f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -6906,6 +6906,17 @@ static void skl_commit_modeset_enables(struct 
> > > > intel_atomic_state *state)
> > > > }
> > > > }
> > > >  
> > > > +   /*
> > > > +* Some MBUS/DBuf update scenarios(mbus join disable) require 
> > > > that
> > > > +* changes are done _after_ DDB reallocation, but _before_ crtc 
> > > > enabling.
> > > > +* Typically we are disabling resources in 
> > > > post_plane/crtc_enable hooks,
> > > > +* however in that case BSpec explicitly states that this 
> > > > should be done
> > > > +* before we enable additional displays.
> > > > +* FIXME: Should we still call this also there(post_plane hook)
> > > > +* for extra-safety? If so, how to make sure, we don't call it 
> > > > twice?
> > > > +*/
> > > > +   intel_dbuf_mbus_post_ddb_update(state);
> > > > +
> > > > update_pipes = modeset_pipes;
> > > >  
> > > > /*
> > > > @@ -7148,9 +7159,7 @@ static void intel_atomic_commit_tail(struct 
> > > > intel_atomic_state *state)
> > > > }
> > > >  
> > > > intel_encoders_update_prepare(state);
> > > > -
> > > > intel_dbuf_pre_plane_update(state);
> > > > -   intel_mbus_dbox_update(state);
> > > >  
> > > > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, 
> > > > i) {
> > > > if (new_crtc_state->do_async_flip)
> > > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
> > > > b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > index 606b7ba9db9ce..f0604ede399f7 100644
> > > > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > @@ -2628,13 +2628,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
> > > > if 

Re: Reminder: 2024 X.Org Board of Directors Elections timeline extended, request for nominations

[Christopher Michael]

This is a reminder that we are still looking for candidates for the 
upcoming X.Org Board of Directors elections, and that today is the last 
day to submit personal statements for nomination. X.org membership 
renewals are still open and will be needed to vote on those elections.



Please read below for more details.


Cheers,

Christopher Michael, on behalf of the X.Org BoD



On 3/5/24 05:49, Christopher Michael wrote:


This is a reminder that we are still looking for candidates for the 
upcoming X.Org Board of Directors elections, and that membership 
renewals are still open and will be needed to vote on those elections. 
Please read below for more details.



Cheers,

Christopher Michael, on behalf of the X.Org BoD


On 3/1/24 06:25, Christopher Michael wrote:


We are seeking nominations for candidates for election to the X.org 
Foundation Board of Directors. However, as we presently do not have 
enough nominations to start the election - the decision has been made 
to extend the timeline by 2 weeks. Note this is a fairly regular part 
of the elections process.



The new deadline for nominations to the X.org Board of Directors is 
23:59 UTC on 11 March 2024



The Board consists of directors elected from the membership. Each 
year, an election is held to bring the total number of directors to 
eight. The four members receiving the highest vote totals will serve 
as directors for two year terms.


The directors who received two year terms starting in 2023 were 
Arkadiusz Hiler, Christopher Michael, Lyude Paul, and Daniel Vetter. 
They will continue to serve until their term ends in 2024. Current 
directors whose term expires in 2024 are Emma Anholt, Mark Filion, 
Ricardo Garcia, and Alyssa Rosenzweig.



A director is expected to participate in the fortnightly IRC meeting 
to discuss current business and to attend the annual meeting of the 
X.Org Foundation, which will be held at a location determined in 
advance by the Board of Directors.


A member may nominate themselves or any other member they feel is 
qualified. Nominations should be sent to the Election Committee at 
electi...@x.org.


Nominees shall be required to be current members of the X.Org 
Foundation, and submit a personal statement of up to 200 words that 
will be provided to prospective voters. The collected statements, 
along with the statement of contribution to the X.Org Foundation in 
the member's account page on http://members.x.org, will be made 
available to all voters to help them make their voting decisions.


Nominations and completed personal statements must be received no 
later than 23:59 UTC on 11 March 2024.


The slate of candidates will be published 18 March 2024 and candidate 
Q will begin then. The deadline for Xorg membership applications 
and renewals has also been extended 2 weeks and is now 25 March 2024.



Cheers,

Christopher Michael, on behalf of the X.Org BoD

Re: [PATCH 7/8] drm/bridge: lt9611uxc: use int for holding number of modes

[Dmitry Baryshkov]

On Fri, 8 Mar 2024 at 18:04, Jani Nikula  wrote:
>
> lt9611uxc_connector_get_modes() propagates the return value of
> drm_edid_connector_add_modes() but stores the int temporarily in an
> unsigned int. Use the correct type.
>
> Cc: Andrzej Hajda 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Dmitry Baryshkov 



-- 
With best wishes
Dmitry

Re: [PATCH 7/8] drm/bridge: lt9611uxc: use int for holding number of modes

[Neil Armstrong]

On 08/03/2024 17:03, Jani Nikula wrote:

lt9611uxc_connector_get_modes() propagates the return value of
drm_edid_connector_add_modes() but stores the int temporarily in an
unsigned int. Use the correct type.

Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Robert Foss 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index bcf8bccd86d6..f4f593ad8f79 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -294,8 +294,8 @@ static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct 
lt9611uxc *lt9611uxc,
  static int lt9611uxc_connector_get_modes(struct drm_connector *connector)
  {
struct lt9611uxc *lt9611uxc = connector_to_lt9611uxc(connector);
-   unsigned int count;
const struct drm_edid *drm_edid;
+   int count;
  
  	drm_edid = drm_bridge_edid_read(>bridge, connector);

drm_edid_connector_update(connector, drm_edid);


Reviewed-by: Neil Armstrong 

Re: [PATCH 2/8] drm/panel: do not return negative error codes from drm_panel_get_modes()

[Neil Armstrong]

On 08/03/2024 17:03, Jani Nikula wrote:

None of the callers of drm_panel_get_modes() expect it to return
negative error codes. Either they propagate the return value in their
struct drm_connector_helper_funcs .get_modes() hook (which is also not
supposed to return negative codes), or add it to other counts leading to
bogus values.

On the other hand, many of the struct drm_panel_funcs .get_modes() hooks
do return negative error codes, so handle them gracefully instead of
propagating further.

Return 0 for no modes, whatever the reason.

Cc: Neil Armstrong 
Cc: Jessica Zhang 
Cc: Sam Ravnborg 
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/drm_panel.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index e814020bbcd3..cfbe020de54e 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -274,19 +274,24 @@ EXPORT_SYMBOL(drm_panel_disable);
   * The modes probed from the panel are automatically added to the connector
   * that the panel is attached to.
   *
- * Return: The number of modes available from the panel on success or a
- * negative error code on failure.
+ * Return: The number of modes available from the panel on success, or 0 on
+ * failure (no modes).
   */
  int drm_panel_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
  {
if (!panel)
-   return -EINVAL;
+   return 0;
  
-	if (panel->funcs && panel->funcs->get_modes)

-   return panel->funcs->get_modes(panel, connector);
+   if (panel->funcs && panel->funcs->get_modes) {
+   int num;
  
-	return -EOPNOTSUPP;

+   num = panel->funcs->get_modes(panel, connector);
+   if (num > 0)
+   return num;
+   }
+
+   return 0;
  }
  EXPORT_SYMBOL(drm_panel_get_modes);
  


Reviewed-by: Neil Armstrong 

[PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter

[Janusz Krzysztofik]

In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
rpm wakeref.  That results in lock inversion:

<4> [197.079335] ==
<4> [197.085473] WARNING: possible circular locking dependency detected
<4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
<4> [197.098096] --
<4> [197.104231] prometheus-node/839 is trying to acquire lock:
<4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at: 
__kmalloc+0x9a/0x350
<4> [197.116939]
but task is already holding lock:
<4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at: 
hwm_energy+0x4b/0x100 [i915]
<4> [197.131543]
which lock already depends on the new lock.
...
<4> [197.507922] Chain exists of:
  fs_reclaim --> >reset.mutex --> >hwmon_lock
<4> [197.518528]  Possible unsafe locking scenario:
<4> [197.524411]CPU0CPU1
<4> [197.528916]
<4> [197.533418]   lock(>hwmon_lock);
<4> [197.537237]lock(>reset.mutex);
<4> [197.543376]lock(>hwmon_lock);
<4> [197.549682]   lock(fs_reclaim);
...
<4> [197.632548] Call Trace:
<4> [197.634990]  
<4> [197.637088]  dump_stack_lvl+0x64/0xb0
<4> [197.640738]  check_noncircular+0x15e/0x180
<4> [197.652968]  check_prev_add+0xe9/0xce0
<4> [197.656705]  __lock_acquire+0x179f/0x2300
<4> [197.660694]  lock_acquire+0xd8/0x2d0
<4> [197.673009]  fs_reclaim_acquire+0xa1/0xd0
<4> [197.680478]  __kmalloc+0x9a/0x350
<4> [197.689063]  acpi_ns_internalize_name.part.0+0x4a/0xb0
<4> [197.694170]  acpi_ns_get_node_unlocked+0x60/0xf0
<4> [197.720608]  acpi_ns_get_node+0x3b/0x60
<4> [197.724428]  acpi_get_handle+0x57/0xb0
<4> [197.728164]  acpi_has_method+0x20/0x50
<4> [197.731896]  acpi_pci_set_power_state+0x43/0x120
<4> [197.736485]  pci_power_up+0x24/0x1c0
<4> [197.740047]  pci_pm_default_resume_early+0x9/0x30
<4> [197.744725]  pci_pm_runtime_resume+0x2d/0x90
<4> [197.753911]  __rpm_callback+0x3c/0x110
<4> [197.762586]  rpm_callback+0x58/0x70
<4> [197.766064]  rpm_resume+0x51e/0x730
<4> [197.769542]  rpm_resume+0x267/0x730
<4> [197.773020]  rpm_resume+0x267/0x730
<4> [197.776498]  rpm_resume+0x267/0x730
<4> [197.779974]  __pm_runtime_resume+0x49/0x90
<4> [197.784055]  __intel_runtime_pm_get+0x19/0xa0 [i915]
<4> [197.789070]  hwm_energy+0x55/0x100 [i915]
<4> [197.793183]  hwm_read+0x9a/0x310 [i915]
<4> [197.797124]  hwmon_attr_show+0x36/0x120
<4> [197.800946]  dev_attr_show+0x15/0x60
<4> [197.804509]  sysfs_kf_seq_show+0xb5/0x100

However, the lock is only intended to protect either a hwmon overflow
counter or rmw hardware operations.  There is no need to hold the lock,
only the wakeref, while reading from hardware.

Acquire the lock after hardware read under rpm wakeref.

Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
Signed-off-by: Janusz Krzysztofik 
Cc:  # v6.2+
---
 drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8c3f443c8347e..faf7670de6e06 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
else
rgaddr = hwmon->rg.energy_status_all;
 
-   mutex_lock(>hwmon_lock);
-
with_intel_runtime_pm(uncore->rpm, wakeref)
reg_val = intel_uncore_read(uncore, rgaddr);
 
+   mutex_lock(>hwmon_lock);
+
if (reg_val >= ei->reg_val_prev)
ei->accum_energy += reg_val - ei->reg_val_prev;
else
-- 
2.43.0