[PATCH] drm/i915/audio: 'scheduling while atomic' during system resume

2024-04-08 Thread Brent Lu
The i915_audio_component_codec_wake_override() function will be called
during resume process so replace usleep_range() function calls with
udelay() to avoid the 'scheduling while atomic' error.

[22138.069052] BUG: scheduling while atomic: cras/2682/0x
[22138.069359] Call Trace:
[22138.069369]  
[22138.069380]  dump_stack_lvl+0x69/0x97
[22138.069407]  __schedule_bug+0x87/0x9a
[22138.069422]  __schedule+0x4f9/0xf88
[22138.069450]  schedule+0x4e/0xd0
[22138.069462]  schedule_hrtimeout_range_clock+0xab/0x11b
[22138.069488]  usleep_range_state+0x63/0x8c
[22138.069502]  i915_audio_component_codec_wake_override+0x8e/0xf2
[22138.069518]  snd_hdac_set_codec_wakeup+0x39/0x44 [snd_hda_core (HASH:381b 
97)]
[22138.069541]  hda_dsp_ctrl_init_chip+0x45/0x414 [snd_sof_intel_hda_common 
(HASH:ff4d 98)]
[22138.069578]  hda_resume+0x4c/0xf2 [snd_sof_intel_hda_common (HASH:ff4d 98)]
[22138.069598]  hda_dsp_runtime_resume+0x32/0x9f [snd_sof_intel_hda_common 
(HASH:ff4d 98)]
[22138.069618]  sof_resume+0x67/0x234 [snd_sof (HASH:ad31 99)]
[22138.069655]  __rpm_callback+0x87/0x130
[22138.069680]  rpm_callback+0x22/0x77
[22138.069691]  rpm_resume+0x3bb/0x508

Signed-off-by: Brent Lu 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 07e0c73204f3..9a85e6da63bf 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1120,12 +1120,12 @@ static void 
i915_audio_component_codec_wake_override(struct device *kdev,
 */
intel_de_rmw(i915, HSW_AUD_CHICKENBIT,
 SKL_AUD_CODEC_WAKE_SIGNAL, 0);
-   usleep_range(1000, 1500);
+   udelay(1000);
 
if (enable) {
intel_de_rmw(i915, HSW_AUD_CHICKENBIT,
 0, SKL_AUD_CODEC_WAKE_SIGNAL);
-   usleep_range(1000, 1500);
+   udelay(1000);
}
 
i915_audio_component_put_power(kdev, cookie);
-- 
2.34.1



Re: [PATCH 5/5] drm/vkms: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Maíra Canal

On 4/8/24 16:06, Ville Syrjala wrote:

From: Ville Syrjälä 

Replace the open coded drm_crtc_vblank_crtc() with the real
thing.

Cc: Rodrigo Siqueira 
Cc: Melissa Wen 
Cc: "Maíra Canal" 
Cc: Haneen Mohammed 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 


Reviewed-by: Maíra Canal 

Best Regards,
- Maíra


---
  drivers/gpu/drm/vkms/vkms_crtc.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 61e500b8c9da..40b4d084e3ce 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -61,9 +61,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
  
  static int vkms_enable_vblank(struct drm_crtc *crtc)

  {
-   struct drm_device *dev = crtc->dev;
-   unsigned int pipe = drm_crtc_index(crtc);
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
  
  	drm_calc_timestamping_constants(crtc, >mode);

@@ -88,10 +86,9 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
  bool in_vblank_irq)
  {
struct drm_device *dev = crtc->dev;
-   unsigned int pipe = crtc->index;
struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
struct vkms_output *output = >output;
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
  
  	if (!READ_ONCE(vblank->enabled)) {

*vblank_time = ktime_get();


✗ Fi.CI.BAT: failure for drm: debug logging improvements (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm: debug logging improvements (rev3)
URL   : https://patchwork.freedesktop.org/series/130881/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14545 -> Patchwork_130881v3


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 39)
--

  Additional (2): bat-dg1-7 bat-mtlp-8 
  Missing(3): bat-mtlp-9 fi-cfl-8109u bat-arls-3 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hugepages:
- bat-arls-2: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/bat-arls-2/igt@i915_selftest@l...@hugepages.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v3/bat-arls-2/igt@i915_selftest@l...@hugepages.html

  
Known issues


  Here are the changes found in Patchwork_130881v3 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_130881v3/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

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

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

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

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

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

  * igt@gem_tiled_pread_basic:
- bat-dg1-7:  NOTRUN -> [SKIP][10] ([i915#4079]) +1 other test skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v3/bat-dg1-7/igt@gem_tiled_pread_basic.html

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

  * igt@i915_selftest@live@active:
- fi-rkl-11600:   [PASS][13] -> [DMESG-FAIL][14] ([i915#10606])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/fi-rkl-11600/igt@i915_selftest@l...@active.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v3/fi-rkl-11600/igt@i915_selftest@l...@active.html

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

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-8:  NOTRUN -> [DMESG-FAIL][17] ([i915#9840])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v3/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#5190])
   [19]: 

✗ Fi.CI.CHECKPATCH: warning for drm: debug logging improvements (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm: debug logging improvements (rev3)
URL   : https://patchwork.freedesktop.org/series/130881/
State : warning

== Summary ==

Error: dim checkpatch failed
2e4e1a4bd898 drm/probe-helper: switch to drm device based logging
820abea6dcdd drm/modes: switch to drm device based error logging
f7ae9e2ecbbd drm/sysfs: switch to drm device based logging
3127d9f60980 drm/client: switch to drm device based logging, and more
-:328: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#328: FILE: drivers/gpu/drm/drm_client_modeset.c:875:
+   if (drm_WARN_ON_ONCE(dev, modeset->num_connectors == 
DRM_CLIENT_MAX_CLONED_CONNECTORS ||

-:329: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#329: FILE: drivers/gpu/drm/drm_client_modeset.c:876:
+(dev->mode_config.num_crtc > 1 && 
modeset->num_connectors == 1))) {

total: 0 errors, 2 warnings, 0 checks, 298 lines checked
324ed8d6c117 drm/crtc: switch to drm device based logging
78cf21b9285c drm/crtc-helper: switch to drm device based logging and warns
-:251: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#251: FILE: drivers/gpu/drm/drm_crtc_helper.c:785:
+   drm_dbg_kms(dev, "\t[CONNECTOR:%d:%s] set DPMS 
on\n", set->connectors[i]->base.id,

total: 0 errors, 1 warnings, 0 checks, 251 lines checked
d608e27cac44 drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
-:79: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#79: FILE: drivers/gpu/drm/drm_crtc_helper.c:769:
+   drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode 
from userspace: " DRM_MODE_FMT "\n",

-:118: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#118: FILE: drivers/gpu/drm/drm_modes.c:1816:
+   DRM_MODE_ARG(mode), 
drm_get_mode_status_name(mode->status));

total: 0 errors, 2 warnings, 0 checks, 86 lines checked




✗ Fi.CI.SPARSE: warning for drm: debug logging improvements (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm: debug logging improvements (rev3)
URL   : https://patchwork.freedesktop.org/series/130881/
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:147: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:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: 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:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./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:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./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: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:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./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:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./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: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:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./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:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238:9: 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:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92: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: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: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: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: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: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: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: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: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:14: warning: unreplaced 
symbol 'old'

✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()
URL   : https://patchwork.freedesktop.org/series/132178/
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 

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()
URL   : https://patchwork.freedesktop.org/series/132178/
State : warning

== Summary ==

Error: dim checkpatch failed
f6612e1c60a0 drm/vblank: Introduce drm_crtc_vblank_crtc()
-:10: WARNING:REPEATED_WORD: Possible repeated word: 'the'
#10: 
out the the correct drm_vblank_crtc for a given a drm_crtc.

total: 0 errors, 1 warnings, 0 checks, 209 lines checked
ce4c495ea428 drm/amdgpu: Use drm_crtc_vblank_crtc()
33d9627bcd50 drm/i915: Use drm_crtc_vblank_crtc()
98650d42f60b drm/nouveau: Use drm_crtc_vblank_crtc()
2b925ad9f869 drm/vkms: Use drm_crtc_vblank_crtc()




✓ Fi.CI.BAT: success for drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: drm_i915_private and xe_device cleanups
URL   : https://patchwork.freedesktop.org/series/132173/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14545 -> Patchwork_132173v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 37)
--

  Additional (2): bat-dg1-7 bat-mtlp-8 
  Missing(5): fi-bsw-n3050 fi-cfl-8109u fi-elk-e7500 fi-blb-e6850 bat-jsl-1 

Known issues


  Here are the changes found in Patchwork_132173v1 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_132173v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

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

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

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

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

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

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

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

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#5190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132173v1/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][13] ([i915#4212]) +8 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132173v1/bat-mtlp-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
- bat-dg1-7:  NOTRUN -> [SKIP][14] ([i915#4215])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132173v1/bat-dg1-7/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_132173v1/bat-mtlp-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-dg1-7:  NOTRUN -> [SKIP][16] ([i915#4103] / [i915#4213]) +1 
other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132173v1/bat-dg1-7/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_132173v1/bat-mtlp-8/igt@kms_...@dsc-basic.html
- bat-dg1-7:  NOTRUN -> [SKIP][18] ([i915#3555] / [i915#3840])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132173v1/bat-dg1-7/igt@kms_...@dsc-basic.html

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

✗ Fi.CI.SPARSE: warning for drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: drm_i915_private and xe_device cleanups
URL   : https://patchwork.freedesktop.org/series/132173/
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 drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: drm_i915_private and xe_device cleanups
URL   : https://patchwork.freedesktop.org/series/132173/
State : warning

== Summary ==

Error: dim checkpatch failed
05cfe53e63a7 drm/i915/gt: drop display clock info from gt debugfs
5d7d095a9116 drm/i915: move skl_preferred_vco_freq to display substruct
4d511c9004ea drm/i915: move max_dotclk_freq to display substruct
132429301270 drm/i915: move vblank_enabled to display substruct
-:47: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_display_irq.c:1215:
+   intel_uncore_write(>uncore, SCPD0, 
_MASKED_BIT_ENABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));

-:63: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#63: FILE: drivers/gpu/drm/i915/display/intel_display_irq.c:1323:
+   intel_uncore_write(>uncore, SCPD0, 
_MASKED_BIT_DISABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));

total: 0 errors, 2 warnings, 0 checks, 60 lines checked
7ec85b339bac drm/i915: move display_irqs_enabled to display substruct
9d3982f78beb drm/i915: move de_irq_mask to display substruct
f93ae50c2d5d drm/i915: move pipestat_irq_mask to display substruct
dfafacc34ffe drm/xe/display: remove unused xe->enabled_irq_mask




✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: move rawclk init to intel_cdclk_init()

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: move rawclk init to 
intel_cdclk_init()
URL   : https://patchwork.freedesktop.org/series/132168/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14545 -> Patchwork_132168v1


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 36)
--

  Additional (1): bat-dg1-7 
  Missing(5): fi-bsw-n3050 fi-cfl-8109u fi-elk-e7500 fi-kbl-8809g bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_self_import@basic-with_two_bos:
- bat-arls-2: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/bat-arls-2/igt@prime_self_import@basic-with_two_bos.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132168v1/bat-arls-2/igt@prime_self_import@basic-with_two_bos.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@i915_module_load@load:
- fi-bsw-nick:[PASS][6] -> [INCOMPLETE][7] ([i915#10311])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/fi-bsw-nick/igt@i915_module_l...@load.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132168v1/fi-bsw-nick/igt@i915_module_l...@load.html

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

  * igt@i915_selftest@live@active:
- bat-dg2-9:  [PASS][9] -> [ABORT][10] ([i915#10366])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/bat-dg2-9/igt@i915_selftest@l...@active.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132168v1/bat-dg2-9/igt@i915_selftest@l...@active.html

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

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

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

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

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-7:  NOTRUN -> [SKIP][15]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132168v1/bat-dg1-7/igt@kms_force_connector_ba...@force-load-detect.html

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

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

  * igt@kms_psr@psr-primary-page-flip:
- bat-dg1-7:  NOTRUN -> [SKIP][18] ([i915#1072] / [i915#9732]) +3 
other tests skip
   [18]: 

✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: move rawclk init to intel_cdclk_init()

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: move rawclk init to 
intel_cdclk_init()
URL   : https://patchwork.freedesktop.org/series/132168/
State : warning

== Summary ==

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




✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: remove small micro-optimizations in irq handling

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/display: remove small 
micro-optimizations in irq handling
URL   : https://patchwork.freedesktop.org/series/132152/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14545 -> Patchwork_132152v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 38)
--

  Additional (2): bat-dg1-7 bat-dg2-11 
  Missing(4): fi-kbl-7567u bat-jsl-1 fi-apl-guc fi-elk-e7500 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic@lmem0:
- bat-dg2-11: NOTRUN -> [FAIL][1] ([i915#10378])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132152v1/bat-dg2-11/igt@gem_lmem_swapping@ba...@lmem0.html

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

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

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

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

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

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

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

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

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

  * igt@kms_dsc@dsc-basic:
- bat-dg2-11: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#3840])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132152v1/bat-dg2-11/igt@kms_...@dsc-basic.html
- bat-dg1-7:  NOTRUN -> [SKIP][18] ([i915#3555] / [i915#3840])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132152v1/bat-dg1-7/igt@kms_...@dsc-basic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-7:  NOTRUN -> [SKIP][19]
   [19]: 

✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display: remove small micro-optimizations in irq handling

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/display: remove small 
micro-optimizations in irq handling
URL   : https://patchwork.freedesktop.org/series/132152/
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 

Re: [PATCH 4/5] drm/nouveau: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Lyude Paul
Reviewed-by: Lyude Paul 

On Mon, 2024-04-08 at 22:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Replace the open coded drm_crtc_vblank_crtc() with the real
> thing.
> 
> Cc: Karol Herbst 
> Cc: Lyude Paul 
> Cc: Danilo Krummrich 
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index f28f9a857458..aed5d5b51b43 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -83,7 +83,7 @@ static bool
>  nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos,
> int *hpos,
>   ktime_t *stime, ktime_t *etime)
>  {
> - struct drm_vblank_crtc *vblank = >dev-
> >vblank[drm_crtc_index(crtc)];
> + struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
>   struct nvif_head *head = _crtc(crtc)->head;
>   struct nvif_head_scanoutpos_v0 args;
>   int retry = 20;

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat



✓ Fi.CI.BAT: success for drm/i915/guc: Update w/a 14019159160 (rev4)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Update w/a 14019159160 (rev4)
URL   : https://patchwork.freedesktop.org/series/130890/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14545 -> Patchwork_130890v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 36)
--

  Missing(4): fi-kbl-7567u bat-jsl-1 fi-apl-guc fi-elk-e7500 

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@i915_selftest@live@migrate:
- bat-dg2-8:  [ABORT][1] ([i915#10366] / [i915#10677]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14545/bat-dg2-8/igt@i915_selftest@l...@migrate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130890v4/bat-dg2-8/igt@i915_selftest@l...@migrate.html

  
  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#10677]: https://gitlab.freedesktop.org/drm/intel/issues/10677


Build changes
-

  * Linux: CI_DRM_14545 -> Patchwork_130890v4

  CI-20190529: 20190529
  CI_DRM_14545: 9c78ecd17c19a10cdb73b12362d6b9bf914105b2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_130890v4: 9c78ecd17c19a10cdb73b12362d6b9bf914105b2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

597c17ee41bf drm/i915/guc: Update w/a 14019159160

== Logs ==

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


Re: [PATCH 0/8] drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Lucas De Marchi

On Tue, Apr 09, 2024 at 12:02:17AM +0300, Jani Nikula wrote:

On Mon, 08 Apr 2024, Jani Nikula  wrote:

Continue cleaning up the members from drm_i915_private and xe_device to
struct intel_display.


Lucas, there's a bunch of xe changes included here, ack for merging via
drm-intel-next?



Acked-by: Lucas De Marchi 

I skimmed through the series and left just one comment. It may be very
well because I skimmed through it too fast though. I agree on merging
it through drm-intel-next.

Lucas De Marchi


Re: [PATCH 6/8] drm/i915: move de_irq_mask to display substruct

2024-04-08 Thread Lucas De Marchi

On Mon, Apr 08, 2024 at 09:08:41PM +0300, Jani Nikula wrote:

The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
.../gpu/drm/i915/display/intel_display_core.h   |  2 ++
.../gpu/drm/i915/display/intel_display_irq.c| 17 +
drivers/gpu/drm/i915/i915_drv.h |  5 +
drivers/gpu/drm/xe/xe_device_types.h|  7 ++-
4 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 68aee44b4822..7a70b162b015 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -452,6 +452,8 @@ struct intel_display {

/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
+
+   u32 de_irq_mask[I915_MAX_PIPES];
} irq;

struct {
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index e9fcdac90efd..9b9548ae9797 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -117,13 +117,14 @@ static void bdw_update_pipe_irq(struct drm_i915_private 
*dev_priv,
if (drm_WARN_ON(_priv->drm, !intel_irqs_enabled(dev_priv)))
return;

-   new_val = dev_priv->de_irq_mask[pipe];
+   new_val = dev_priv->display.irq.de_irq_mask[pipe];



is this a good name though?  I'd expect to see something like
display.irq.mask in the code.

Lucas De Marchi


✗ Fi.CI.SPARSE: warning for drm/i915/guc: Update w/a 14019159160 (rev4)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Update w/a 14019159160 (rev4)
URL   : https://patchwork.freedesktop.org/series/130890/
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 drm/i915/guc: Update w/a 14019159160 (rev4)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Update w/a 14019159160 (rev4)
URL   : https://patchwork.freedesktop.org/series/130890/
State : warning

== Summary ==

Error: dim checkpatch failed
2949d5eceea7 drm/i915/guc: Update w/a 14019159160
-:20: WARNING:LONG_LINE_COMMENT: line length of 108 exceeds 100 columns
#20: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h:108:
+   GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE   = 
0x9001,   /* Wa_14019159160 */

-:21: WARNING:LONG_LINE_COMMENT: line length of 108 exceeds 100 columns
#21: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h:109:
+   GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE = 
0x9006,   /* Wa_14019159160 */

-:62: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#62: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:829:
+   GEM_BUG_ON(*remain < size);

total: 0 errors, 3 warnings, 0 checks, 62 lines checked




Re: [PATCH 0/8] drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Jani Nikula  wrote:
> Continue cleaning up the members from drm_i915_private and xe_device to
> struct intel_display.

Lucas, there's a bunch of xe changes included here, ack for merging via
drm-intel-next?

BR,
Jani.

>
> Jani Nikula (8):
>   drm/i915/gt: drop display clock info from gt debugfs
>   drm/i915: move skl_preferred_vco_freq to display substruct
>   drm/i915: move max_dotclk_freq to display substruct
>   drm/i915: move vblank_enabled to display substruct
>   drm/i915: move display_irqs_enabled to display substruct
>   drm/i915: move de_irq_mask to display substruct
>   drm/i915: move pipestat_irq_mask to display substruct
>   drm/xe/display: remove unused xe->enabled_irq_mask
>
>  drivers/gpu/drm/i915/display/intel_cdclk.c| 23 
>  drivers/gpu/drm/i915/display/intel_crt.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  6 +-
>  .../gpu/drm/i915/display/intel_display_core.h | 12 
>  .../gpu/drm/i915/display/intel_display_irq.c  | 57 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_dsi.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
>  .../gpu/drm/i915/display/intel_hotplug_irq.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  4 --
>  drivers/gpu/drm/i915/i915_drv.h   | 13 +
>  drivers/gpu/drm/i915/i915_irq.c   |  8 +--
>  drivers/gpu/drm/xe/display/xe_display.c   |  1 -
>  drivers/gpu/drm/xe/xe_device_types.h  | 15 +
>  19 files changed, 73 insertions(+), 88 deletions(-)

-- 
Jani Nikula, Intel


✓ Fi.CI.BAT: success for drm/i915/pps: move pps debugfs file to intel_pps.c

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: move pps debugfs file to intel_pps.c
URL   : https://patchwork.freedesktop.org/series/132148/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_132148v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 42)
--

  Additional (1): fi-kbl-7567u 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-7567u:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 other tests skip
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132148v1/fi-kbl-7567u/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][3] -> [ABORT][4] ([i915#10366] / [i915#10677])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132148v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-7567u:   NOTRUN -> [SKIP][5] +11 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132148v1/fi-kbl-7567u/igt@kms_...@dsc-basic.html

  
 Possible fixes 

  * igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}:   [DMESG-WARN][6] ([i915#10435]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132148v1/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html

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

  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#10435]: https://gitlab.freedesktop.org/drm/intel/issues/10435
  [i915#10677]: https://gitlab.freedesktop.org/drm/intel/issues/10677
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_132148v1

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_132148v1: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

18d87a549023 drm/i915/pps: move pps debugfs file to intel_pps.c

== Logs ==

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


✗ Fi.CI.CHECKPATCH: warning for drm/i915/pps: move pps debugfs file to intel_pps.c

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: move pps debugfs file to intel_pps.c
URL   : https://patchwork.freedesktop.org/series/132148/
State : warning

== Summary ==

Error: dim checkpatch failed
fa41b7dd74d8 drm/i915/pps: move pps debugfs file to intel_pps.c
-:106: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#106: FILE: drivers/gpu/drm/i915/display/intel_pps.c:1703:
+
+}

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




[PATCH 5/5] drm/vkms: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the open coded drm_crtc_vblank_crtc() with the real
thing.

Cc: Rodrigo Siqueira 
Cc: Melissa Wen 
Cc: "Maíra Canal" 
Cc: Haneen Mohammed 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 61e500b8c9da..40b4d084e3ce 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -61,9 +61,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
 
 static int vkms_enable_vblank(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   unsigned int pipe = drm_crtc_index(crtc);
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
 
drm_calc_timestamping_constants(crtc, >mode);
@@ -88,10 +86,9 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
  bool in_vblank_irq)
 {
struct drm_device *dev = crtc->dev;
-   unsigned int pipe = crtc->index;
struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
struct vkms_output *output = >output;
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
 
if (!READ_ONCE(vblank->enabled)) {
*vblank_time = ktime_get();
-- 
2.43.2



[PATCH 4/5] drm/nouveau: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the open coded drm_crtc_vblank_crtc() with the real
thing.

Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Danilo Krummrich 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index f28f9a857458..aed5d5b51b43 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -83,7 +83,7 @@ static bool
 nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime)
 {
-   struct drm_vblank_crtc *vblank = 
>dev->vblank[drm_crtc_index(crtc)];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
struct nvif_head *head = _crtc(crtc)->head;
struct nvif_head_scanoutpos_v0 args;
int retry = 20;
-- 
2.43.2



[PATCH 2/5] drm/amdgpu: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the open coded drm_crtc_vblank_crtc() with the real
thing.

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "Pan, Xinhui" 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 8 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 8baa2e0935cc..258703145161 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -65,9 +65,7 @@ static enum hrtimer_restart 
amdgpu_vkms_vblank_simulate(struct hrtimer *timer)
 
 static int amdgpu_vkms_enable_vblank(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   unsigned int pipe = drm_crtc_index(crtc);
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
struct amdgpu_vkms_output *out = drm_crtc_to_amdgpu_vkms_output(crtc);
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
 
@@ -91,10 +89,8 @@ static bool amdgpu_vkms_get_vblank_timestamp(struct drm_crtc 
*crtc,
 ktime_t *vblank_time,
 bool in_vblank_irq)
 {
-   struct drm_device *dev = crtc->dev;
-   unsigned int pipe = crtc->index;
struct amdgpu_vkms_output *output = 
drm_crtc_to_amdgpu_vkms_output(crtc);
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
 
if (!READ_ONCE(vblank->enabled)) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 71d2d44681b2..662d2d83473b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -528,7 +528,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
if (acrtc) {
vrr_active = amdgpu_dm_crtc_vrr_active_irq(acrtc);
drm_dev = acrtc->base.dev;
-   vblank = _dev->vblank[acrtc->base.index];
+   vblank = drm_crtc_vblank_crtc(>base);
previous_timestamp = 
atomic64_read(_params->previous_timestamp);
frame_duration_ns = vblank->time - previous_timestamp;
 
-- 
2.43.2



[PATCH 3/5] drm/i915: Use drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the open coded drm_crtc_vblank_crtc() with the real
thing.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_crtc.c   |  3 +--
 drivers/gpu/drm/i915/display/intel_vblank.c | 16 +---
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 25593f6aae7d..339010384b86 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -78,8 +78,7 @@ void intel_wait_for_vblank_if_active(struct drm_i915_private 
*i915,
 
 u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_vblank_crtc *vblank = 
>vblank[drm_crtc_index(>base)];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(>base);
 
if (!crtc->active)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c 
b/drivers/gpu/drm/i915/display/intel_vblank.c
index baf7354cb6e2..951190bcbc50 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -132,8 +132,7 @@ u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
 static u32 intel_crtc_scanlines_since_frame_timestamp(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct drm_vblank_crtc *vblank =
-   >base.dev->vblank[drm_crtc_index(>base)];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(>base);
const struct drm_display_mode *mode = >hwmode;
u32 htotal = mode->crtc_htotal;
u32 clock = mode->crtc_clock;
@@ -178,8 +177,7 @@ static u32 
intel_crtc_scanlines_since_frame_timestamp(struct intel_crtc *crtc)
  */
 static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
 {
-   struct drm_vblank_crtc *vblank =
-   >base.dev->vblank[drm_crtc_index(>base)];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(>base);
const struct drm_display_mode *mode = >hwmode;
u32 vblank_start = mode->crtc_vblank_start;
u32 vtotal = mode->crtc_vtotal;
@@ -200,17 +198,14 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   const struct drm_display_mode *mode;
-   struct drm_vblank_crtc *vblank;
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(>base);
+   const struct drm_display_mode *mode = >hwmode;
enum pipe pipe = crtc->pipe;
int position, vtotal;
 
if (!crtc->active)
return 0;
 
-   vblank = >base.dev->vblank[drm_crtc_index(>base)];
-   mode = >hwmode;
-
if (crtc->mode_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
return __intel_get_crtc_scanline_from_timestamp(crtc);
 
@@ -254,8 +249,7 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 
 int intel_crtc_scanline_to_hw(struct intel_crtc *crtc, int scanline)
 {
-   const struct drm_vblank_crtc *vblank =
-   >base.dev->vblank[drm_crtc_index(>base)];
+   const struct drm_vblank_crtc *vblank = 
drm_crtc_vblank_crtc(>base);
const struct drm_display_mode *mode = >hwmode;
int vtotal;
 
-- 
2.43.2



[PATCH 1/5] drm/vblank: Introduce drm_crtc_vblank_crtc()

2024-04-08 Thread Ville Syrjala
From: Ville Syrjälä 

Make life easier by providing a function that hands
out the the correct drm_vblank_crtc for a given a drm_crtc.

Also abstract the lower level internals of the vblank
code in a similar fashion.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_vblank.c  | 58 ++-
 drivers/gpu/drm/drm_vblank_work.c |  2 +-
 include/drm/drm_vblank.h  |  1 +
 3 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 702a12bc93bd..cc3571e25a9a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -166,11 +166,24 @@ module_param_named(timestamp_precision_usec, 
drm_timestamp_precision, int, 0600)
 MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable [msecs] 
(0: never disable, <0: disable immediately)");
 MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps [usecs]");
 
+static struct drm_vblank_crtc *
+drm_vblank_crtc(struct drm_device *dev, unsigned int pipe)
+{
+   return >vblank[pipe];
+}
+
+struct drm_vblank_crtc *
+drm_crtc_vblank_crtc(struct drm_crtc *crtc)
+{
+   return drm_vblank_crtc(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_crtc);
+
 static void store_vblank(struct drm_device *dev, unsigned int pipe,
 u32 vblank_count_inc,
 ktime_t t_vblank, u32 last)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
 
assert_spin_locked(>vblank_time_lock);
 
@@ -184,7 +197,7 @@ static void store_vblank(struct drm_device *dev, unsigned 
int pipe,
 
 static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int pipe)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
 
return vblank->max_vblank_count ?: dev->max_vblank_count;
 }
@@ -273,7 +286,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
bool in_vblank_irq)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
u32 cur_vblank, diff;
bool rc;
ktime_t t_vblank;
@@ -364,7 +377,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
 
 u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
u64 count;
 
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
@@ -438,7 +451,7 @@ static void __disable_vblank(struct drm_device *dev, 
unsigned int pipe)
  */
 void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
unsigned long irqflags;
 
assert_spin_locked(>vbl_lock);
@@ -600,7 +613,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc);
int linedur_ns = 0, framedur_ns = 0;
int dotclock = mode->crtc_clock;
 
@@ -930,7 +943,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_count);
 static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
 ktime_t *vblanktime)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
u64 vblank_count;
unsigned int seq;
 
@@ -985,7 +998,6 @@ EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
  */
 int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime)
 {
-   unsigned int pipe = drm_crtc_index(crtc);
struct drm_vblank_crtc *vblank;
struct drm_display_mode *mode;
u64 vblank_start;
@@ -993,7 +1005,7 @@ int drm_crtc_next_vblank_start(struct drm_crtc *crtc, 
ktime_t *vblanktime)
if (!drm_dev_has_vblank(crtc->dev))
return -EINVAL;
 
-   vblank = >dev->vblank[pipe];
+   vblank = drm_crtc_vblank_crtc(crtc);
mode = >hwmode;
 
if (!vblank->framedur_ns || !vblank->linedur_ns)
@@ -1147,7 +1159,7 @@ static int __enable_vblank(struct drm_device *dev, 
unsigned int pipe)
 
 static int drm_vblank_enable(struct drm_device *dev, unsigned int pipe)
 {
-   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
int ret = 0;
 
assert_spin_locked(>vbl_lock);
@@ -1185,7 +1197,7 @@ static int 

✗ Fi.CI.BAT: failure for drm: debug logging improvements (rev2)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm: debug logging improvements (rev2)
URL   : https://patchwork.freedesktop.org/series/130881/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_130881v2


Summary
---

  **FAILURE**

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

Participating hosts (41 -> 37)
--

  Missing(4): fi-glk-j4005 fi-cfl-8109u fi-apl-guc fi-kbl-8809g 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_mocs:
- bat-adlp-11:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-adlp-11/igt@i915_selftest@live@gt_mocs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-adlp-11/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@objects:
- bat-arls-2: [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-2/igt@i915_selftest@l...@objects.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-arls-2/igt@i915_selftest@l...@objects.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_mocs:
- {bat-arls-4}:   [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-4/igt@i915_selftest@live@gt_mocs.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-arls-4/igt@i915_selftest@live@gt_mocs.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}:   [DMESG-WARN][7] ([i915#10435]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html

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

  [i915#10435]: https://gitlab.freedesktop.org/drm/intel/issues/10435


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_130881v2

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_130881v2: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

fd8df2b8a798 drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
adc78f76eb2b drm/crtc-helper: switch to drm device based logging and warns
a83408378298 drm/crtc: switch to drm device based logging
bfd64144ecbc drm/client: switch to drm device based logging, and more
ac3c8a489c1f drm/sysfs: switch to drm device based logging
eddb4a71e3c1 drm/modes: switch to drm device based error logging
7830c15dc1f6 drm/probe-helper: switch to drm device based logging

== Logs ==

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


✗ Fi.CI.CHECKPATCH: warning for drm: debug logging improvements (rev2)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm: debug logging improvements (rev2)
URL   : https://patchwork.freedesktop.org/series/130881/
State : warning

== Summary ==

Error: dim checkpatch failed
8940559de49f drm/probe-helper: switch to drm device based logging
6624644e87e2 drm/modes: switch to drm device based error logging
35b6825ed9e2 drm/sysfs: switch to drm device based logging
dd9d4e27a486 drm/client: switch to drm device based logging, and more
-:328: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#328: FILE: drivers/gpu/drm/drm_client_modeset.c:875:
+   if (drm_WARN_ON_ONCE(dev, modeset->num_connectors == 
DRM_CLIENT_MAX_CLONED_CONNECTORS ||

-:329: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#329: FILE: drivers/gpu/drm/drm_client_modeset.c:876:
+(dev->mode_config.num_crtc > 1 && 
modeset->num_connectors == 1))) {

total: 0 errors, 2 warnings, 0 checks, 298 lines checked
cae0b6564ddc drm/crtc: switch to drm device based logging
e6b1e497351f drm/crtc-helper: switch to drm device based logging and warns
-:251: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#251: FILE: drivers/gpu/drm/drm_crtc_helper.c:785:
+   drm_dbg_kms(dev, "\t[CONNECTOR:%d:%s] set DPMS 
on\n", set->connectors[i]->base.id,

total: 0 errors, 1 warnings, 0 checks, 251 lines checked
0dc8e3ad21b1 drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
-:79: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#79: FILE: drivers/gpu/drm/drm_crtc_helper.c:769:
+   drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode 
from userspace: " DRM_MODE_FMT "\n",

-:118: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#118: FILE: drivers/gpu/drm/drm_modes.c:1816:
+   DRM_MODE_ARG(mode), 
drm_get_mode_status_name(mode->status));

total: 0 errors, 2 warnings, 0 checks, 86 lines checked




✓ Fi.CI.BAT: success for drm/edid: cleanups, resend

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/edid: cleanups, resend
URL   : https://patchwork.freedesktop.org/series/132142/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_132142v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 34)
--

  Missing(7): fi-bsw-n3050 fi-glk-j4005 fi-kbl-8809g fi-cfl-8109u 
fi-elk-e7500 bat-jsl-1 bat-arls-3 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_timelines:
- bat-dg2-8:  [PASS][1] -> [ABORT][2] ([i915#10366])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-dg2-8/igt@i915_selftest@live@gt_timelines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132142v1/bat-dg2-8/igt@i915_selftest@live@gt_timelines.html

  
 Possible fixes 

  * igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}:   [DMESG-WARN][3] ([i915#10435]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132142v1/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html

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

  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#10435]: https://gitlab.freedesktop.org/drm/intel/issues/10435
  [i915#10436]: https://gitlab.freedesktop.org/drm/intel/issues/10436


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_132142v1

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_132142v1: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ac3c99dcd507 drm/edid: make drm_edid_are_equal() more convenient for its single 
user
e591e9e56790 drm/edid: make drm_edid_are_equal() static
ef5a1cbb0773 drm/edid: avoid drm_edid_find_extension() internally
ec2c1cfe4070 drm/edid: rename drm_find_edid_extension() to 
drm_edid_find_extension()
9b8f8c94bfc3 drm/edid: group struct drm_edid based declarations together
481c13658abb drm/edid: move all internal declarations to drm_crtc_internal.h
aa06e8dcac95 drm/displayid: move drm_displayid.h to drm_displayd_internal.h

== Logs ==

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


Re: [PATCH 0/8] drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 09:08:35PM +0300, Jani Nikula wrote:
> Continue cleaning up the members from drm_i915_private and xe_device to
> struct intel_display.
> 
> Jani Nikula (8):
>   drm/i915/gt: drop display clock info from gt debugfs
>   drm/i915: move skl_preferred_vco_freq to display substruct
>   drm/i915: move max_dotclk_freq to display substruct
>   drm/i915: move vblank_enabled to display substruct
>   drm/i915: move display_irqs_enabled to display substruct
>   drm/i915: move de_irq_mask to display substruct
>   drm/i915: move pipestat_irq_mask to display substruct
>   drm/xe/display: remove unused xe->enabled_irq_mask

Looks reasonable.

Series is
Reviewed-by: Ville Syrjälä 

> 
>  drivers/gpu/drm/i915/display/intel_cdclk.c| 23 
>  drivers/gpu/drm/i915/display/intel_crt.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  6 +-
>  .../gpu/drm/i915/display/intel_display_core.h | 12 
>  .../gpu/drm/i915/display/intel_display_irq.c  | 57 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_dsi.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
>  .../gpu/drm/i915/display/intel_hotplug_irq.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  4 --
>  drivers/gpu/drm/i915/i915_drv.h   | 13 +
>  drivers/gpu/drm/i915/i915_irq.c   |  8 +--
>  drivers/gpu/drm/xe/display/xe_display.c   |  1 -
>  drivers/gpu/drm/xe/xe_device_types.h  | 15 +
>  19 files changed, 73 insertions(+), 88 deletions(-)
> 
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel


✗ Fi.CI.SPARSE: warning for drm/edid: cleanups, resend

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/edid: cleanups, resend
URL   : https://patchwork.freedesktop.org/series/132142/
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.CHECKPATCH: warning for drm/edid: cleanups, resend

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/edid: cleanups, resend
URL   : https://patchwork.freedesktop.org/series/132142/
State : warning

== Summary ==

Error: dim checkpatch failed
d6df9c755975 drm/displayid: move drm_displayid.h to drm_displayd_internal.h
-:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#31: 
rename from include/drm/drm_displayid.h

total: 0 errors, 1 warnings, 0 checks, 37 lines checked
dfc9c110a355 drm/edid: move all internal declarations to drm_crtc_internal.h
1c045914f6ae drm/edid: group struct drm_edid based declarations together
1e612609dcc8 drm/edid: rename drm_find_edid_extension() to 
drm_edid_find_extension()
4f4faac0b3be drm/edid: avoid drm_edid_find_extension() internally
cc870d1238bc drm/edid: make drm_edid_are_equal() static
198fc1a35758 drm/edid: make drm_edid_are_equal() more convenient for its single 
user




Re: [PATCH 1/4] drm/edid: add drm_edid_get_product_id()

2024-04-08 Thread Ville Syrjälä
On Thu, Mar 21, 2024 at 12:05:09PM +0200, Jani Nikula wrote:
> Add a struct drm_edid based function to get the vendor and product ID
> from an EDID. Add a separate struct for defining this part of the EDID,
> with defined byte order for product code and serial number.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 15 +++
>  include/drm/drm_edid.h | 25 -
>  2 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ea77577a3786..626a0e24e66a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2756,6 +2756,21 @@ const struct drm_edid *drm_edid_read(struct 
> drm_connector *connector)
>  }
>  EXPORT_SYMBOL(drm_edid_read);
>  
> +/**
> + * drm_edid_get_product_id - Get the vendor and product identification
> + * @drm_edid: EDID
> + * @id: Where to place the product id
> + */
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> +  struct drm_edid_product_id *id)
> +{
> + if (drm_edid && drm_edid->edid && drm_edid->size >= EDID_LENGTH)
> + memcpy(id, _edid->edid->product_id, sizeof(*id));
> + else
> + memset(id, 0, sizeof(*id));
> +}
> +EXPORT_SYMBOL(drm_edid_get_product_id);
> +
>  /**
>   * drm_edid_get_panel_id - Get a panel's ID from EDID
>   * @drm_edid: EDID that contains panel ID.
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 6f65bbf655a1..7911a2f8a672 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -272,14 +272,27 @@ struct detailed_timing {
>  #define DRM_EDID_DSC_MAX_SLICES  0xf
>  #define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES  0x3f
>  
> +struct drm_edid_product_id {
> + u8 manufacturer_name[2];

__be16?

> + __le16 product_code;
> + __le32 serial_number;
> + u8 week_of_manufacture;
> + u8 year_of_manufacture;
> +} __packed;
> +
>  struct edid {
>   u8 header[8];
>   /* Vendor & product info */
> - u8 mfg_id[2];
> - u8 prod_code[2];
> - u32 serial; /* FIXME: byte order */
> - u8 mfg_week;
> - u8 mfg_year;
> + union {
> + struct drm_edid_product_id product_id;
> + struct {
> + u8 mfg_id[2];
> + u8 prod_code[2];
> + u32 serial; /* FIXME: byte order */
> + u8 mfg_week;
> + u8 mfg_year;
> + } __packed;
> + } __packed;
>   /* EDID version */
>   u8 version;
>   u8 revision;
> @@ -466,6 +479,8 @@ int drm_edid_connector_update(struct drm_connector 
> *connector,
> const struct drm_edid *edid);
>  int drm_edid_connector_add_modes(struct drm_connector *connector);
>  bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> +  struct drm_edid_product_id *id);
>  
>  const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel


[PATCH 8/8] drm/xe/display: remove unused xe->enabled_irq_mask

2024-04-08 Thread Jani Nikula
The xe->enabled_irq_mask member has never been used for anything.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/xe/display/xe_display.c | 1 -
 drivers/gpu/drm/xe/xe_device_types.h| 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/xe/display/xe_display.c 
b/drivers/gpu/drm/xe/display/xe_display.c
index 6ec375c1c4b6..32a8242e1ef4 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -108,7 +108,6 @@ int xe_display_create(struct xe_device *xe)
xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
 
drmm_mutex_init(>drm, >sb_lock);
-   xe->enabled_irq_mask = ~0;
 
err = drmm_add_action_or_reset(>drm, display_destroy, NULL);
if (err)
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index faa32407efa5..536cb8a44ea4 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -503,8 +503,6 @@ struct xe_device {
/* only to allow build, not used functionally */
u32 irq_mask;
 
-   u32 enabled_irq_mask;
-
struct intel_uncore {
spinlock_t lock;
} uncore;
-- 
2.39.2



[PATCH 7/8] drm/i915: move pipestat_irq_mask to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_core.h |  1 +
 drivers/gpu/drm/i915/display/intel_display_irq.c  | 14 +++---
 drivers/gpu/drm/i915/i915_drv.h   |  1 -
 drivers/gpu/drm/xe/xe_device_types.h  |  1 -
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 7a70b162b015..db9b6492758e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -454,6 +454,7 @@ struct intel_display {
u8 vblank_enabled;
 
u32 de_irq_mask[I915_MAX_PIPES];
+   u32 pipestat_irq_mask[I915_MAX_PIPES];
} irq;
 
struct {
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index 9b9548ae9797..c337e0597541 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -180,7 +180,7 @@ void ibx_disable_display_interrupt(struct drm_i915_private 
*i915, u32 bits)
 u32 i915_pipestat_enable_mask(struct drm_i915_private *dev_priv,
  enum pipe pipe)
 {
-   u32 status_mask = dev_priv->pipestat_irq_mask[pipe];
+   u32 status_mask = dev_priv->display.irq.pipestat_irq_mask[pipe];
u32 enable_mask = status_mask << 16;
 
lockdep_assert_held(_priv->irq_lock);
@@ -234,10 +234,10 @@ void i915_enable_pipestat(struct drm_i915_private 
*dev_priv,
lockdep_assert_held(_priv->irq_lock);
drm_WARN_ON(_priv->drm, !intel_irqs_enabled(dev_priv));
 
-   if ((dev_priv->pipestat_irq_mask[pipe] & status_mask) == status_mask)
+   if ((dev_priv->display.irq.pipestat_irq_mask[pipe] & status_mask) == 
status_mask)
return;
 
-   dev_priv->pipestat_irq_mask[pipe] |= status_mask;
+   dev_priv->display.irq.pipestat_irq_mask[pipe] |= status_mask;
enable_mask = i915_pipestat_enable_mask(dev_priv, pipe);
 
intel_uncore_write(_priv->uncore, reg, enable_mask | status_mask);
@@ -257,10 +257,10 @@ void i915_disable_pipestat(struct drm_i915_private 
*dev_priv,
lockdep_assert_held(_priv->irq_lock);
drm_WARN_ON(_priv->drm, !intel_irqs_enabled(dev_priv));
 
-   if ((dev_priv->pipestat_irq_mask[pipe] & status_mask) == 0)
+   if ((dev_priv->display.irq.pipestat_irq_mask[pipe] & status_mask) == 0)
return;
 
-   dev_priv->pipestat_irq_mask[pipe] &= ~status_mask;
+   dev_priv->display.irq.pipestat_irq_mask[pipe] &= ~status_mask;
enable_mask = i915_pipestat_enable_mask(dev_priv, pipe);
 
intel_uncore_write(_priv->uncore, reg, enable_mask | status_mask);
@@ -402,7 +402,7 @@ void i9xx_pipestat_irq_reset(struct drm_i915_private 
*dev_priv)
   PIPESTAT_INT_STATUS_MASK |
   PIPE_FIFO_UNDERRUN_STATUS);
 
-   dev_priv->pipestat_irq_mask[pipe] = 0;
+   dev_priv->display.irq.pipestat_irq_mask[pipe] = 0;
}
 }
 
@@ -446,7 +446,7 @@ void i9xx_pipestat_irq_ack(struct drm_i915_private 
*dev_priv,
break;
}
if (iir & iir_bit)
-   status_mask |= dev_priv->pipestat_irq_mask[pipe];
+   status_mask |= 
dev_priv->display.irq.pipestat_irq_mask[pipe];
 
if (!status_mask)
continue;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 41add82ca369..ee0d7d5f135d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -241,7 +241,6 @@ struct drm_i915_private {
 
/** Cached value of IMR to avoid reads in updating the bitfield */
u32 irq_mask;
-   u32 pipestat_irq_mask[I915_MAX_PIPES];
 
bool preserve_bios_swizzle;
 
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index 359c912359fa..faa32407efa5 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -502,7 +502,6 @@ struct xe_device {
 
/* only to allow build, not used functionally */
u32 irq_mask;
-   u32 pipestat_irq_mask[I915_MAX_PIPES];
 
u32 enabled_irq_mask;
 
-- 
2.39.2



[PATCH 6/8] drm/i915: move de_irq_mask to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_display_core.h   |  2 ++
 .../gpu/drm/i915/display/intel_display_irq.c| 17 +
 drivers/gpu/drm/i915/i915_drv.h |  5 +
 drivers/gpu/drm/xe/xe_device_types.h|  7 ++-
 4 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 68aee44b4822..7a70b162b015 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -452,6 +452,8 @@ struct intel_display {
 
/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
+
+   u32 de_irq_mask[I915_MAX_PIPES];
} irq;
 
struct {
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index e9fcdac90efd..9b9548ae9797 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -117,13 +117,14 @@ static void bdw_update_pipe_irq(struct drm_i915_private 
*dev_priv,
if (drm_WARN_ON(_priv->drm, !intel_irqs_enabled(dev_priv)))
return;
 
-   new_val = dev_priv->de_irq_mask[pipe];
+   new_val = dev_priv->display.irq.de_irq_mask[pipe];
new_val &= ~interrupt_mask;
new_val |= (~enabled_irq_mask & interrupt_mask);
 
-   if (new_val != dev_priv->de_irq_mask[pipe]) {
-   dev_priv->de_irq_mask[pipe] = new_val;
-   intel_uncore_write(_priv->uncore, GEN8_DE_PIPE_IMR(pipe), 
dev_priv->de_irq_mask[pipe]);
+   if (new_val != dev_priv->display.irq.de_irq_mask[pipe]) {
+   dev_priv->display.irq.de_irq_mask[pipe] = new_val;
+   intel_uncore_write(_priv->uncore, GEN8_DE_PIPE_IMR(pipe),
+  dev_priv->display.irq.de_irq_mask[pipe]);
intel_uncore_posting_read(_priv->uncore, 
GEN8_DE_PIPE_IMR(pipe));
}
 }
@@ -1497,8 +1498,8 @@ void gen8_irq_power_well_post_enable(struct 
drm_i915_private *dev_priv,
 
for_each_pipe_masked(dev_priv, pipe, pipe_mask)
GEN8_IRQ_INIT_NDX(uncore, DE_PIPE, pipe,
- dev_priv->de_irq_mask[pipe],
- ~dev_priv->de_irq_mask[pipe] | extra_ier);
+ dev_priv->display.irq.de_irq_mask[pipe],
+ ~dev_priv->display.irq.de_irq_mask[pipe] | 
extra_ier);
 
spin_unlock_irq(_priv->irq_lock);
 }
@@ -1694,12 +1695,12 @@ void gen8_de_irq_postinstall(struct drm_i915_private 
*dev_priv)
}
 
for_each_pipe(dev_priv, pipe) {
-   dev_priv->de_irq_mask[pipe] = ~de_pipe_masked;
+   dev_priv->display.irq.de_irq_mask[pipe] = ~de_pipe_masked;
 
if (intel_display_power_is_enabled(dev_priv,
   POWER_DOMAIN_PIPE(pipe)))
GEN8_IRQ_INIT_NDX(uncore, DE_PIPE, pipe,
- dev_priv->de_irq_mask[pipe],
+ 
dev_priv->display.irq.de_irq_mask[pipe],
  de_pipe_enables);
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b3daca57f32c..41add82ca369 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -240,10 +240,7 @@ struct drm_i915_private {
struct pm_qos_request sb_qos;
 
/** Cached value of IMR to avoid reads in updating the bitfield */
-   union {
-   u32 irq_mask;
-   u32 de_irq_mask[I915_MAX_PIPES];
-   };
+   u32 irq_mask;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
bool preserve_bios_swizzle;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index 956a5f5289bb..359c912359fa 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -500,11 +500,8 @@ struct xe_device {
/* For pcode */
struct mutex sb_lock;
 
-   union {
-   /* only to allow build, not used functionally */
-   u32 irq_mask;
-   u32 de_irq_mask[I915_MAX_PIPES];
-   };
+   /* only to allow build, not used functionally */
+   u32 irq_mask;
u32 pipestat_irq_mask[I915_MAX_PIPES];
 
u32 enabled_irq_mask;
-- 
2.39.2



[PATCH 3/8] drm/i915: move max_dotclk_freq to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c| 6 +++---
 drivers/gpu/drm/i915/display/intel_crt.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 6 +++---
 drivers/gpu/drm/i915/display/intel_display_core.h | 1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 4 ++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_dsi.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_dvo.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
 drivers/gpu/drm/i915/display/intel_tv.c   | 2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 1 -
 drivers/gpu/drm/xe/xe_device_types.h  | 3 ---
 14 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 950942dc3d60..7a833b5f2de2 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3438,13 +3438,13 @@ void intel_update_max_cdclk(struct drm_i915_private 
*dev_priv)
dev_priv->display.cdclk.max_cdclk_freq = 
dev_priv->display.cdclk.hw.cdclk;
}
 
-   dev_priv->max_dotclk_freq = intel_compute_max_dotclk(dev_priv);
+   dev_priv->display.cdclk.max_dotclk_freq = 
intel_compute_max_dotclk(dev_priv);
 
drm_dbg(_priv->drm, "Max CD clock rate: %d kHz\n",
dev_priv->display.cdclk.max_cdclk_freq);
 
drm_dbg(_priv->drm, "Max dotclock rate: %d kHz\n",
-   dev_priv->max_dotclk_freq);
+   dev_priv->display.cdclk.max_dotclk_freq);
 }
 
 /**
@@ -3618,7 +3618,7 @@ static int i915_cdclk_info_show(struct seq_file *m, void 
*unused)
 
seq_printf(m, "Current CD clock frequency: %d kHz\n", 
i915->display.cdclk.hw.cdclk);
seq_printf(m, "Max CD clock frequency: %d kHz\n", 
i915->display.cdclk.max_cdclk_freq);
-   seq_printf(m, "Max pixel clock frequency: %d kHz\n", 
i915->max_dotclk_freq);
+   seq_printf(m, "Max pixel clock frequency: %d kHz\n", 
i915->display.cdclk.max_dotclk_freq);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 2e95093aa4d4..10e95dc425a6 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -348,7 +348,7 @@ intel_crt_mode_valid(struct drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   int max_dotclk = dev_priv->max_dotclk_freq;
+   int max_dotclk = dev_priv->display.cdclk.max_dotclk_freq;
enum drm_mode_status status;
int max_clock;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 41062b4fb6ae..74018de5a17f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2419,7 +2419,7 @@ static int intel_crtc_compute_pipe_mode(struct 
intel_crtc_state *crtc_state)
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
struct drm_display_mode *pipe_mode = _state->hw.pipe_mode;
-   int clock_limit = i915->max_dotclk_freq;
+   int clock_limit = i915->display.cdclk.max_dotclk_freq;
 
/*
 * Start with the adjusted_mode crtc timings, which
@@ -2443,7 +2443,7 @@ static int intel_crtc_compute_pipe_mode(struct 
intel_crtc_state *crtc_state)
 */
if (intel_crtc_supports_double_wide(crtc) &&
pipe_mode->crtc_clock > clock_limit) {
-   clock_limit = i915->max_dotclk_freq;
+   clock_limit = i915->display.cdclk.max_dotclk_freq;
crtc_state->double_wide = true;
}
}
@@ -7795,7 +7795,7 @@ void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
 
 static int max_dotclock(struct drm_i915_private *i915)
 {
-   int max_dotclock = i915->max_dotclk_freq;
+   int max_dotclock = i915->display.cdclk.max_dotclk_freq;
 
/* icl+ might use bigjoiner */
if (DISPLAY_VER(i915) >= 11)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index b577429ee6e9..eed9be8e9f49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,7 @@ struct intel_display {
struct intel_global_obj obj;
 
unsigned int max_cdclk_freq;
+   unsigned int max_dotclk_freq;
unsigned int skl_preferred_vco_freq;
} 

[PATCH 2/8] drm/i915: move skl_preferred_vco_freq to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c  | 17 -
 .../gpu/drm/i915/display/intel_display_core.h   |  1 +
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/xe/xe_device_types.h|  2 +-
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d61aa5b7cbdb..950942dc3d60 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1021,15 +1021,14 @@ static int skl_cdclk_decimal(int cdclk)
return DIV_ROUND_CLOSEST(cdclk - 1000, 500);
 }
 
-static void skl_set_preferred_cdclk_vco(struct drm_i915_private *dev_priv,
-   int vco)
+static void skl_set_preferred_cdclk_vco(struct drm_i915_private *i915, int vco)
 {
-   bool changed = dev_priv->skl_preferred_vco_freq != vco;
+   bool changed = i915->display.cdclk.skl_preferred_vco_freq != vco;
 
-   dev_priv->skl_preferred_vco_freq = vco;
+   i915->display.cdclk.skl_preferred_vco_freq = vco;
 
if (changed)
-   intel_update_max_cdclk(dev_priv);
+   intel_update_max_cdclk(i915);
 }
 
 static u32 skl_dpll0_link_rate(struct drm_i915_private *dev_priv, int vco)
@@ -1233,7 +1232,7 @@ static void skl_cdclk_init_hw(struct drm_i915_private 
*dev_priv)
 * Use the current vco as our initial
 * guess as to what the preferred vco is.
 */
-   if (dev_priv->skl_preferred_vco_freq == 0)
+   if (dev_priv->display.cdclk.skl_preferred_vco_freq == 0)
skl_set_preferred_cdclk_vco(dev_priv,

dev_priv->display.cdclk.hw.vco);
return;
@@ -1241,7 +1240,7 @@ static void skl_cdclk_init_hw(struct drm_i915_private 
*dev_priv)
 
cdclk_config = dev_priv->display.cdclk.hw;
 
-   cdclk_config.vco = dev_priv->skl_preferred_vco_freq;
+   cdclk_config.vco = dev_priv->display.cdclk.skl_preferred_vco_freq;
if (cdclk_config.vco == 0)
cdclk_config.vco = 810;
cdclk_config.cdclk = skl_calc_cdclk(0, cdclk_config.vco);
@@ -3011,7 +3010,7 @@ static int skl_dpll0_vco(struct intel_cdclk_state 
*cdclk_state)
 
vco = cdclk_state->logical.vco;
if (!vco)
-   vco = dev_priv->skl_preferred_vco_freq;
+   vco = dev_priv->display.cdclk.skl_preferred_vco_freq;
 
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
if (!crtc_state->hw.enable)
@@ -3397,7 +3396,7 @@ void intel_update_max_cdclk(struct drm_i915_private 
*dev_priv)
u32 limit = intel_de_read(dev_priv, SKL_DFSM) & 
SKL_DFSM_CDCLK_LIMIT_MASK;
int max_cdclk, vco;
 
-   vco = dev_priv->skl_preferred_vco_freq;
+   vco = dev_priv->display.cdclk.skl_preferred_vco_freq;
drm_WARN_ON(_priv->drm, vco != 810 && vco != 864);
 
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 2167dbee5eea..b577429ee6e9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -345,6 +345,7 @@ struct intel_display {
struct intel_global_obj obj;
 
unsigned int max_cdclk_freq;
+   unsigned int skl_preferred_vco_freq;
} cdclk;
 
struct {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf52d4adaa20..ba3c27c969f2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -251,7 +251,6 @@ struct drm_i915_private {
bool preserve_bios_swizzle;
 
unsigned int fsb_freq, mem_freq, is_ddr3;
-   unsigned int skl_preferred_vco_freq;
 
unsigned int max_dotclk_freq;
unsigned int hpll_freq;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index c710cec835a7..6f46234d1241 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -501,7 +501,7 @@ struct xe_device {
struct mutex sb_lock;
 
/* Should be in struct intel_display */
-   u32 skl_preferred_vco_freq, max_dotclk_freq;
+   u32 max_dotclk_freq;
 
union {
/* only to allow build, not used functionally */
-- 
2.39.2



[PATCH 5/8] drm/i915: move display_irqs_enabled to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_core.h |  2 ++
 drivers/gpu/drm/i915/display/intel_display_irq.c  | 14 +++---
 drivers/gpu/drm/i915/display/intel_hotplug_irq.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  2 --
 drivers/gpu/drm/i915/i915_irq.c   |  8 
 drivers/gpu/drm/xe/xe_device_types.h  |  1 -
 6 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 52f7d6e0324f..68aee44b4822 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -448,6 +448,8 @@ struct intel_display {
} ips;
 
struct {
+   bool display_irqs_enabled;
+
/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
} irq;
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index 6219b1a62210..e9fcdac90efd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -412,7 +412,7 @@ void i9xx_pipestat_irq_ack(struct drm_i915_private 
*dev_priv,
 
spin_lock(_priv->irq_lock);
 
-   if (!dev_priv->display_irqs_enabled) {
+   if (!dev_priv->display.irq.display_irqs_enabled) {
spin_unlock(_priv->irq_lock);
return;
}
@@ -1558,10 +1558,10 @@ void valleyview_enable_display_irqs(struct 
drm_i915_private *dev_priv)
 {
lockdep_assert_held(_priv->irq_lock);
 
-   if (dev_priv->display_irqs_enabled)
+   if (dev_priv->display.irq.display_irqs_enabled)
return;
 
-   dev_priv->display_irqs_enabled = true;
+   dev_priv->display.irq.display_irqs_enabled = true;
 
if (intel_irqs_enabled(dev_priv)) {
vlv_display_irq_reset(dev_priv);
@@ -1573,10 +1573,10 @@ void valleyview_disable_display_irqs(struct 
drm_i915_private *dev_priv)
 {
lockdep_assert_held(_priv->irq_lock);
 
-   if (!dev_priv->display_irqs_enabled)
+   if (!dev_priv->display.irq.display_irqs_enabled)
return;
 
-   dev_priv->display_irqs_enabled = false;
+   dev_priv->display.irq.display_irqs_enabled = false;
 
if (intel_irqs_enabled(dev_priv))
vlv_display_irq_reset(dev_priv);
@@ -1770,9 +1770,9 @@ void intel_display_irq_init(struct drm_i915_private *i915)
 * domain. We defer setting up the display irqs in this case to the
 * runtime pm.
 */
-   i915->display_irqs_enabled = true;
+   i915->display.irq.display_irqs_enabled = true;
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
-   i915->display_irqs_enabled = false;
+   i915->display.irq.display_irqs_enabled = false;
 
intel_hotplug_irq_init(i915);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c 
b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
index 76076509f771..d270bb7b9462 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug_irq.c
@@ -1444,7 +1444,7 @@ void intel_hpd_enable_detection(struct intel_encoder 
*encoder)
 
 void intel_hpd_irq_setup(struct drm_i915_private *i915)
 {
-   if (i915->display_irqs_enabled && i915->display.funcs.hotplug)
+   if (i915->display.irq.display_irqs_enabled && 
i915->display.funcs.hotplug)
i915->display.funcs.hotplug->hpd_irq_setup(i915);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a83553731538..b3daca57f32c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -235,8 +235,6 @@ struct drm_i915_private {
/* protects the irq masks */
spinlock_t irq_lock;
 
-   bool display_irqs_enabled;
-
/* Sideband mailbox protection */
struct mutex sb_lock;
struct pm_qos_request sb_qos;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8130f043693b..678d632ed043 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -702,7 +702,7 @@ static void valleyview_irq_reset(struct drm_i915_private 
*dev_priv)
gen5_gt_irq_reset(to_gt(dev_priv));
 
spin_lock_irq(_priv->irq_lock);
-   if (dev_priv->display_irqs_enabled)
+   if (dev_priv->display.irq.display_irqs_enabled)
vlv_display_irq_reset(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 }
@@ -767,7 +767,7 @@ static void cherryview_irq_reset(struct drm_i915_private 
*dev_priv)
GEN3_IRQ_RESET(uncore, GEN8_PCU_);
 
spin_lock_irq(_priv->irq_lock);
-   if (dev_priv->display_irqs_enabled)
+   if (dev_priv->display.irq.display_irqs_enabled)
 

[PATCH 4/8] drm/i915: move vblank_enabled to display substruct

2024-04-08 Thread Jani Nikula
The info is related to display, and should be placed under
i915->display. Start a new irq sub-substruct.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_core.h |  5 +
 drivers/gpu/drm/i915/display/intel_display_irq.c  | 12 ++--
 drivers/gpu/drm/i915/i915_drv.h   |  3 ---
 drivers/gpu/drm/xe/xe_device_types.h  |  1 -
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index eed9be8e9f49..52f7d6e0324f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -447,6 +447,11 @@ struct intel_display {
bool false_color;
} ips;
 
+   struct {
+   /* For i915gm/i945gm vblank irq workaround */
+   u8 vblank_enabled;
+   } irq;
+
struct {
wait_queue_head_t waitqueue;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index f846c5b108b5..6219b1a62210 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -1203,7 +1203,7 @@ int i8xx_enable_vblank(struct drm_crtc *crtc)
 
 int i915gm_enable_vblank(struct drm_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   struct drm_i915_private *i915 = to_i915(crtc->dev);
 
/*
 * Vblank interrupts fail to wake the device up from C2+.
@@ -1211,8 +1211,8 @@ int i915gm_enable_vblank(struct drm_crtc *crtc)
 * the problem. There is a small power cost so we do this
 * only when vblank interrupts are actually enabled.
 */
-   if (dev_priv->vblank_enabled++ == 0)
-   intel_uncore_write(_priv->uncore, SCPD0, 
_MASKED_BIT_ENABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));
+   if (i915->display.irq.vblank_enabled++ == 0)
+   intel_uncore_write(>uncore, SCPD0, 
_MASKED_BIT_ENABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));
 
return i8xx_enable_vblank(crtc);
 }
@@ -1315,12 +1315,12 @@ void i8xx_disable_vblank(struct drm_crtc *crtc)
 
 void i915gm_disable_vblank(struct drm_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   struct drm_i915_private *i915 = to_i915(crtc->dev);
 
i8xx_disable_vblank(crtc);
 
-   if (--dev_priv->vblank_enabled == 0)
-   intel_uncore_write(_priv->uncore, SCPD0, 
_MASKED_BIT_DISABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));
+   if (--i915->display.irq.vblank_enabled == 0)
+   intel_uncore_write(>uncore, SCPD0, 
_MASKED_BIT_DISABLE(CSTATE_RENDER_CLOCK_GATE_DISABLE));
 }
 
 void i965_disable_vblank(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ac8ad18c5fc2..a83553731538 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -348,9 +348,6 @@ struct drm_i915_private {
 
struct intel_pxp *pxp;
 
-   /* For i915gm/i945gm vblank irq workaround */
-   u8 vblank_enabled;
-
bool irq_enabled;
 
struct i915_pmu pmu;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index 6b3a22197322..d6236133b143 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -519,7 +519,6 @@ struct xe_device {
unsigned int hpll_freq;
unsigned int czclk_freq;
unsigned int fsb_freq, mem_freq, is_ddr3;
-   u8 vblank_enabled;
};
struct {
const char *dmc_firmware_path;
-- 
2.39.2



[PATCH 1/8] drm/i915/gt: drop display clock info from gt debugfs

2024-04-08 Thread Jani Nikula
The same info is available in i915_cdclk_info.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 37e8d50c99ed..4fcba42cfe34 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -392,10 +392,6 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt, 
struct drm_printer *p)
drm_puts(p, "no P-state info available\n");
}
 
-   drm_printf(p, "Current CD clock frequency: %d kHz\n", 
i915->display.cdclk.hw.cdclk);
-   drm_printf(p, "Max CD clock frequency: %d kHz\n", 
i915->display.cdclk.max_cdclk_freq);
-   drm_printf(p, "Max pixel clock frequency: %d kHz\n", 
i915->max_dotclk_freq);
-
intel_runtime_pm_put(uncore->rpm, wakeref);
 }
 
-- 
2.39.2



[PATCH 0/8] drm/i915: drm_i915_private and xe_device cleanups

2024-04-08 Thread Jani Nikula
Continue cleaning up the members from drm_i915_private and xe_device to
struct intel_display.

Jani Nikula (8):
  drm/i915/gt: drop display clock info from gt debugfs
  drm/i915: move skl_preferred_vco_freq to display substruct
  drm/i915: move max_dotclk_freq to display substruct
  drm/i915: move vblank_enabled to display substruct
  drm/i915: move display_irqs_enabled to display substruct
  drm/i915: move de_irq_mask to display substruct
  drm/i915: move pipestat_irq_mask to display substruct
  drm/xe/display: remove unused xe->enabled_irq_mask

 drivers/gpu/drm/i915/display/intel_cdclk.c| 23 
 drivers/gpu/drm/i915/display/intel_crt.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  6 +-
 .../gpu/drm/i915/display/intel_display_core.h | 12 
 .../gpu/drm/i915/display/intel_display_irq.c  | 57 ++-
 drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_dvo.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 .../gpu/drm/i915/display/intel_hotplug_irq.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  4 --
 drivers/gpu/drm/i915/i915_drv.h   | 13 +
 drivers/gpu/drm/i915/i915_irq.c   |  8 +--
 drivers/gpu/drm/xe/display/xe_display.c   |  1 -
 drivers/gpu/drm/xe/xe_device_types.h  | 15 +
 19 files changed, 73 insertions(+), 88 deletions(-)

-- 
2.39.2



Re: [PATCH 2/4] drm/edid: add drm_edid_print_product_id()

2024-04-08 Thread Ville Syrjälä
On Thu, Mar 21, 2024 at 12:05:10PM +0200, Jani Nikula wrote:
> Add a function to print a decoded EDID vendor and product id to a drm
> printer, optinally with the raw data.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 35 +++
>  include/drm/drm_edid.h |  3 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 626a0e24e66a..198986f0eb8b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -29,6 +29,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2771,6 +2772,40 @@ void drm_edid_get_product_id(const struct drm_edid 
> *drm_edid,
>  }
>  EXPORT_SYMBOL(drm_edid_get_product_id);
>  
> +/**
> + * drm_edid_print_product_id - Print decoded product id to printer
> + * @p: drm printer
> + * @id: EDID product id
> + * @raw: If true, also print the raw hex
> + */
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw)
> +{
> + u16 mfg_id = id->manufacturer_name[0] << 8 | id->manufacturer_name[1];
> + char *date;
> + char vend[4];
> +
> + drm_edid_decode_mfg_id(mfg_id, vend);
> +
> + if (id->week_of_manufacture == 0xff)

Didn't realize this had a loaded meaning. Maybe we should also
skip the week printout if week==0? Otherwise people might think
week==0 means the first week.

> + date = kasprintf(GFP_KERNEL, "model year: %d",
> +  id->year_of_manufacture + 1990);
> + else
> + date = kasprintf(GFP_KERNEL, "week: %d, year of manufacture: 
> %d",

The "week: %d" part feels a bit left out here. Maybe this should be
formatted as "week/year of manufacture: %d/%d"? 

Not sure I like the kasprintf(). Maybe use an on-stack buffer?

> +  id->week_of_manufacture,
> +  id->year_of_manufacture + 1990);
> +
> + drm_printf(p, "manufacturer name: %s, product code: %u, serial number: 
> %u, %s\n",
> +vend, le16_to_cpu(id->product_code),
> +le32_to_cpu(id->serial_number), date ?: "");
> +
> + if (raw)
> + drm_printf(p, "raw product id: %*ph\n", (int)sizeof(*id), id);
> +
> + kfree(date);
> +}
> +EXPORT_SYMBOL(drm_edid_print_product_id);
> +
>  /**
>   * drm_edid_get_panel_id - Get a panel's ID from EDID
>   * @drm_edid: EDID that contains panel ID.
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7911a2f8a672..c763ba1a0bbd 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -30,6 +30,7 @@ struct drm_connector;
>  struct drm_device;
>  struct drm_display_mode;
>  struct drm_edid;
> +struct drm_printer;
>  struct hdmi_avi_infoframe;
>  struct hdmi_vendor_infoframe;
>  struct i2c_adapter;
> @@ -481,6 +482,8 @@ int drm_edid_connector_add_modes(struct drm_connector 
> *connector);
>  bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>  void drm_edid_get_product_id(const struct drm_edid *drm_edid,
>struct drm_edid_product_id *id);
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw);
>  
>  const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel


✓ Fi.CI.BAT: success for Panel replay selective update support (rev6)

2024-04-08 Thread Patchwork
== Series Details ==

Series: Panel replay selective update support (rev6)
URL   : https://patchwork.freedesktop.org/series/128193/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_128193v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 35)
--

  Additional (1): fi-kbl-7567u 
  Missing(7): bat-dg1-7 bat-mtlp-9 fi-bsw-n3050 fi-glk-j4005 fi-elk-e7500 
bat-jsl-1 bat-arls-3 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_lmem_swapping@basic@lmem0:
- bat-dg2-8:  [PASS][3] -> [FAIL][4] ([i915#10378])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-dg2-8/igt@gem_lmem_swapping@ba...@lmem0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128193v6/bat-dg2-8/igt@gem_lmem_swapping@ba...@lmem0.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-9:  [PASS][5] -> [ABORT][6] ([i915#10366])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128193v6/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7567u:   NOTRUN -> [SKIP][7] +11 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128193v6/fi-kbl-7567u/igt@kms_force_connector_ba...@force-load-detect.html

  
  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#10378]: https://gitlab.freedesktop.org/drm/intel/issues/10378
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_128193v6

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_128193v6: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

96345b40b4d3 drm/i915/psr: Add panel replay sel update support to debugfs 
interface
062904b52d99 drm/i915/psr: Split intel_psr2_config_valid for panel replay
199db55732e5 drm/i915/psr: Update PSR module parameter descriptions
e260f99c4e8f drm/i915/psr: Do not apply workarounds in case of panel replay
e05125c223b1 drm/i915/psr: Panel replay uses SRD_STATUS to track it's status
6f7247d50d00 drm/i915/psr: Modify intel_dp_get_su_granularity to support panel 
replay
5781f289e483 drm/i915/psr: Detect panel replay selective update support
e4a6e60ce39d drm/panelreplay: dpcd register definition for panelreplay SU
0e5a4bb7994f drm/i915/psr: Rename psr2_enabled as sel_update_enabled
621ed5043528 drm/i915/psr: Rename has_psr2 as has_sel_update

== Logs ==

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


✗ Fi.CI.SPARSE: warning for Panel replay selective update support (rev6)

2024-04-08 Thread Patchwork
== Series Details ==

Series: Panel replay selective update support (rev6)
URL   : https://patchwork.freedesktop.org/series/128193/
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 Panel replay selective update support (rev6)

2024-04-08 Thread Patchwork
== Series Details ==

Series: Panel replay selective update support (rev6)
URL   : https://patchwork.freedesktop.org/series/128193/
State : warning

== Summary ==

Error: dim checkpatch failed
206b20dab9c8 drm/i915/psr: Rename has_psr2 as has_sel_update
-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/display/intel_crtc_state_dump.c:255:
+   drm_printf(, "psr: %s, selective update: %s, panel replay: 
%s, selective fetch: %s\n",
+   str_enabled_disabled(pipe_config->has_psr),

total: 0 errors, 0 warnings, 1 checks, 88 lines checked
479bf0afb6d8 drm/i915/psr: Rename psr2_enabled as sel_update_enabled
cea4b7ad5977 drm/panelreplay: dpcd register definition for panelreplay SU
926950299e1a drm/i915/psr: Detect panel replay selective update support
150ce40a7162 drm/i915/psr: Modify intel_dp_get_su_granularity to support panel 
replay
0b77f6341053 drm/i915/psr: Panel replay uses SRD_STATUS to track it's status
c42fb2f13d6c drm/i915/psr: Do not apply workarounds in case of panel replay
661eed5b5d71 drm/i915/psr: Update PSR module parameter descriptions
f30d13de3a0d drm/i915/psr: Split intel_psr2_config_valid for panel replay
b5841e7d6679 drm/i915/psr: Add panel replay sel update support to debugfs 
interface
-:13: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#13: 
Sink support: PSR = no, Panel Replay = yes, Panel Replay Selective Update = yes

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




Re: [PATCH 1/2] drm/i915: move rawclk init to intel_cdclk_init()

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 08:28:27PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 08, 2024 at 08:23:14PM +0300, Jani Nikula wrote:
> > The rawclk initialization is a bit out of place in
> > intel_device_info_runtime_init(). Move it to intel_cdclk_init(), with a
> > bit of refactoring on intel_read_rawclk().
> 
> rawclk is used outside of display.

The correct solution would likely be to extract a 
i9xx_fsb_freq(), and use that to populate both rawclk_freq
and fsb_freq (and switch over to fsb_freq in the
non-display code).

> 
> > 
> > Signed-off-by: Jani Nikula 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 23 +++---
> >  drivers/gpu/drm/i915/display/intel_cdclk.h |  1 -
> >  drivers/gpu/drm/i915/intel_device_info.c   |  4 
> >  3 files changed, 11 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index d61aa5b7cbdb..64a1cf4ed45c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -3210,6 +3210,8 @@ int intel_cdclk_state_set_joined_mbus(struct 
> > intel_atomic_state *state, bool joi
> > return intel_atomic_lock_global_state(_state->base);
> >  }
> >  
> > +static void intel_rawclk_init(struct drm_i915_private *dev_priv);
> > +
> >  int intel_cdclk_init(struct drm_i915_private *dev_priv)
> >  {
> > struct intel_cdclk_state *cdclk_state;
> > @@ -3221,6 +3223,8 @@ int intel_cdclk_init(struct drm_i915_private 
> > *dev_priv)
> > intel_atomic_global_obj_init(dev_priv, _priv->display.cdclk.obj,
> >  _state->base, _cdclk_funcs);
> >  
> > +   intel_rawclk_init(dev_priv);
> > +
> > return 0;
> >  }
> >  
> > @@ -3578,16 +3582,13 @@ static int i9xx_hrawclk(struct drm_i915_private 
> > *dev_priv)
> > }
> >  }
> >  
> > -/**
> > - * intel_read_rawclk - Determine the current RAWCLK frequency
> > - * @dev_priv: i915 device
> > - *
> > - * Determine the current RAWCLK frequency. RAWCLK is a fixed
> > - * frequency clock so this needs to done only once.
> > +/*
> > + * Initialize the current RAWCLK frequency. RAWCLK is a fixed frequency 
> > clock so
> > + * this needs to done only once.
> >   */
> > -u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
> > +static void intel_rawclk_init(struct drm_i915_private *dev_priv)
> >  {
> > -   u32 freq;
> > +   u32 freq = 0;
> >  
> > if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTL)
> > /*
> > @@ -3606,11 +3607,9 @@ u32 intel_read_rawclk(struct drm_i915_private 
> > *dev_priv)
> > freq = vlv_hrawclk(dev_priv);
> > else if (DISPLAY_VER(dev_priv) >= 3)
> > freq = i9xx_hrawclk(dev_priv);
> > -   else
> > -   /* no rawclk on other platforms, or no need to know it */
> > -   return 0;
> >  
> > -   return freq;
> > +   RUNTIME_INFO(dev_priv)->rawclk_freq = freq;
> > +   drm_dbg_kms(_priv->drm, "rawclk rate: %d kHz\n", freq);
> >  }
> >  
> >  static int i915_cdclk_info_show(struct seq_file *m, void *unused)
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h 
> > b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > index cfdcdec07a4d..a3f950d5a366 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > @@ -64,7 +64,6 @@ void intel_cdclk_uninit_hw(struct drm_i915_private *i915);
> >  void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv);
> >  void intel_update_max_cdclk(struct drm_i915_private *dev_priv);
> >  void intel_update_cdclk(struct drm_i915_private *dev_priv);
> > -u32 intel_read_rawclk(struct drm_i915_private *dev_priv);
> >  bool intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
> >const struct intel_cdclk_config *b);
> >  int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index a0a43ea07f11..48f0957392f9 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -370,10 +370,6 @@ void intel_device_info_runtime_init(struct 
> > drm_i915_private *dev_priv)
> >  "Disabling ppGTT for VT-d support\n");
> > runtime->ppgtt_type = INTEL_PPGTT_NONE;
> > }
> > -
> > -   runtime->rawclk_freq = intel_read_rawclk(dev_priv);
> > -   drm_dbg(_priv->drm, "rawclk rate: %d kHz\n", runtime->rawclk_freq);
> > -
> >  }
> >  
> >  /*
> > -- 
> > 2.39.2
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel


Re: [PATCH 1/2] drm/i915: move rawclk init to intel_cdclk_init()

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 08:23:14PM +0300, Jani Nikula wrote:
> The rawclk initialization is a bit out of place in
> intel_device_info_runtime_init(). Move it to intel_cdclk_init(), with a
> bit of refactoring on intel_read_rawclk().

rawclk is used outside of display.

> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 23 +++---
>  drivers/gpu/drm/i915/display/intel_cdclk.h |  1 -
>  drivers/gpu/drm/i915/intel_device_info.c   |  4 
>  3 files changed, 11 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index d61aa5b7cbdb..64a1cf4ed45c 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3210,6 +3210,8 @@ int intel_cdclk_state_set_joined_mbus(struct 
> intel_atomic_state *state, bool joi
>   return intel_atomic_lock_global_state(_state->base);
>  }
>  
> +static void intel_rawclk_init(struct drm_i915_private *dev_priv);
> +
>  int intel_cdclk_init(struct drm_i915_private *dev_priv)
>  {
>   struct intel_cdclk_state *cdclk_state;
> @@ -3221,6 +3223,8 @@ int intel_cdclk_init(struct drm_i915_private *dev_priv)
>   intel_atomic_global_obj_init(dev_priv, _priv->display.cdclk.obj,
>_state->base, _cdclk_funcs);
>  
> + intel_rawclk_init(dev_priv);
> +
>   return 0;
>  }
>  
> @@ -3578,16 +3582,13 @@ static int i9xx_hrawclk(struct drm_i915_private 
> *dev_priv)
>   }
>  }
>  
> -/**
> - * intel_read_rawclk - Determine the current RAWCLK frequency
> - * @dev_priv: i915 device
> - *
> - * Determine the current RAWCLK frequency. RAWCLK is a fixed
> - * frequency clock so this needs to done only once.
> +/*
> + * Initialize the current RAWCLK frequency. RAWCLK is a fixed frequency 
> clock so
> + * this needs to done only once.
>   */
> -u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
> +static void intel_rawclk_init(struct drm_i915_private *dev_priv)
>  {
> - u32 freq;
> + u32 freq = 0;
>  
>   if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTL)
>   /*
> @@ -3606,11 +3607,9 @@ u32 intel_read_rawclk(struct drm_i915_private 
> *dev_priv)
>   freq = vlv_hrawclk(dev_priv);
>   else if (DISPLAY_VER(dev_priv) >= 3)
>   freq = i9xx_hrawclk(dev_priv);
> - else
> - /* no rawclk on other platforms, or no need to know it */
> - return 0;
>  
> - return freq;
> + RUNTIME_INFO(dev_priv)->rawclk_freq = freq;
> + drm_dbg_kms(_priv->drm, "rawclk rate: %d kHz\n", freq);
>  }
>  
>  static int i915_cdclk_info_show(struct seq_file *m, void *unused)
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h 
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index cfdcdec07a4d..a3f950d5a366 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -64,7 +64,6 @@ void intel_cdclk_uninit_hw(struct drm_i915_private *i915);
>  void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv);
>  void intel_update_max_cdclk(struct drm_i915_private *dev_priv);
>  void intel_update_cdclk(struct drm_i915_private *dev_priv);
> -u32 intel_read_rawclk(struct drm_i915_private *dev_priv);
>  bool intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
>  const struct intel_cdclk_config *b);
>  int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index a0a43ea07f11..48f0957392f9 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -370,10 +370,6 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>"Disabling ppGTT for VT-d support\n");
>   runtime->ppgtt_type = INTEL_PPGTT_NONE;
>   }
> -
> - runtime->rawclk_freq = intel_read_rawclk(dev_priv);
> - drm_dbg(_priv->drm, "rawclk rate: %d kHz\n", runtime->rawclk_freq);
> -
>  }
>  
>  /*
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel


Re: [PATCH 11/12] drm/client: Streamline mode selection debugs

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 09:46:44AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 05.04.24 um 21:58 schrieb Ville Syrjälä:
> > On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> >>> From: Ville Syrjälä 
> >>>
> >>> Get rid of all the redundant debugs and just wait until the end
> >>> to print which mode (and of which type) we picked.
> >>>
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>drivers/gpu/drm/drm_client_modeset.c | 65 +---
> >>>1 file changed, 31 insertions(+), 34 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_client_modeset.c 
> >>> b/drivers/gpu/drm/drm_client_modeset.c
> >>> index 415d1799337b..ad88c11037d8 100644
> >>> --- a/drivers/gpu/drm/drm_client_modeset.c
> >>> +++ b/drivers/gpu/drm/drm_client_modeset.c
> >>> @@ -408,6 +408,8 @@ static bool drm_client_target_preferred(struct 
> >>> drm_device *dev,
> >>>
> >>>retry:
> >>>   for (i = 0; i < connector_count; i++) {
> >>> + const char *mode_type;
> >>> +
> >>>   connector = connectors[i];
> >>>
> >>>   if (conn_configured & BIT_ULL(i))
> >>> @@ -440,20 +442,20 @@ static bool drm_client_target_preferred(struct 
> >>> drm_device *dev,
> >>>   drm_client_get_tile_offsets(dev, connectors, 
> >>> connector_count, modes, offsets, i,
> >>>   
> >>> connector->tile_h_loc, connector->tile_v_loc);
> >>>   }
> >>> - drm_dbg_kms(dev, "looking for cmdline mode on 
> >>> [CONNECTOR:%d:%s]\n",
> >>> - connector->base.id, connector->name);
> >>>
> >>> - /* got for command line mode first */
> >>> + mode_type = "cmdline";
> >>>   modes[i] = drm_connector_pick_cmdline_mode(connector);
> >>> +
> >>>   if (!modes[i]) {
> >>> - drm_dbg_kms(dev, "looking for preferred mode on 
> >>> [CONNECTOR:%d:%s] (tile group: %d)\n",
> >>> - connector->base.id, connector->name,
> >>> - connector->tile_group ? 
> >>> connector->tile_group->id : 0);
> >>> + mode_type = "preferred";
> >>>   modes[i] = 
> >>> drm_connector_preferred_mode(connector, width, height);
> >>>   }
> >>> - /* No preferred modes, pick one off the list */
> >>> - if (!modes[i])
> >>> +
> >>> + if (!modes[i]) {
> >>> + mode_type = "first";
> >>>   modes[i] = drm_connector_first_mode(connector);
> >>> + }
> >>> +
> >>>   /*
> >>>* In case of tiled mode if all tiles not present 
> >>> fallback to
> >>>* first available non tiled mode.
> >>> @@ -468,16 +470,20 @@ static bool drm_client_target_preferred(struct 
> >>> drm_device *dev,
> >>>   (connector->tile_h_loc == 0 &&
> >>>connector->tile_v_loc == 0 &&
> >>>!drm_connector_get_tiled_mode(connector))) 
> >>> {
> >>> - drm_dbg_kms(dev, "Falling back to non tiled 
> >>> mode on [CONNECTOR:%d:%s]\n",
> >>> - connector->base.id, 
> >>> connector->name);
> >>> + mode_type = "non tiled";
> >>>   modes[i] = 
> >>> drm_connector_fallback_non_tiled_mode(connector);
> >>>   } else {
> >>> + mode_type = "tiled";
> >>>   modes[i] = 
> >>> drm_connector_get_tiled_mode(connector);
> >>>   }
> >>>   }
> >>>
> >>> - drm_dbg_kms(dev, "found mode %s\n",
> >>> - modes[i] ? modes[i]->name : "none");
> >>> + if (!modes[i])
> >>> + mode_type = "no";
> >>> +
> >>> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] found %s mode: %s\n",
> >>> + connector->base.id, connector->name,
> >>> + mode_type, modes[i] ? modes[i]->name : "none");
> >> Instead of tracking the whole mode_type thing, maybe just do
> >>
> >> if (!modes[i])
> >>       drm_dbg_kms(dev, "[CONNECTOR:%d:%s] found mode: " DRM_MODE_FMT,
> >> DRM_MODE_ARG(modes[i]) );
> >>
> >> to print the full mode.
> > The point of the mode_type is to indicate how we derived
> > that mode. Printing the full modeline doesn't help with that.
> 
> But do we care where the mode comes from? At least from my experience, 
> it's much more important to know which modes had been available.

The tiled vs. not-tiled at least could be quite interesting.
We know there are actual bugs in this code where some tiled 
connectors seem to incorrectly think they aren't tiled
while others correctly think they are tiled. Seeing that
spelled 

[PATCH 2/2] drm/i915: move rawclk from runtime to display runtime info

2024-04-08 Thread Jani Nikula
It's mostly about display, so move it under display.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_backlight.c | 10 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display_device.c|  2 ++
 drivers/gpu/drm/i915/display/intel_display_device.h|  2 ++
 .../gpu/drm/i915/display/intel_display_power_well.c|  4 ++--
 drivers/gpu/drm/i915/display/intel_dp_aux.c|  4 ++--
 drivers/gpu/drm/i915/display/intel_pps.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c   |  1 -
 drivers/gpu/drm/i915/intel_device_info.h   |  2 --
 10 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 4d4330410b4d..bbc1da3305be 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1011,7 +1011,7 @@ static u32 cnp_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
 
-   return DIV_ROUND_CLOSEST(KHz(RUNTIME_INFO(i915)->rawclk_freq),
+   return DIV_ROUND_CLOSEST(KHz(DISPLAY_RUNTIME_INFO(i915)->rawclk_freq),
 pwm_freq_hz);
 }
 
@@ -1073,7 +1073,7 @@ static u32 pch_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
 
-   return DIV_ROUND_CLOSEST(KHz(RUNTIME_INFO(i915)->rawclk_freq),
+   return DIV_ROUND_CLOSEST(KHz(DISPLAY_RUNTIME_INFO(i915)->rawclk_freq),
 pwm_freq_hz * 128);
 }
 
@@ -1091,7 +1091,7 @@ static u32 i9xx_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
int clock;
 
if (IS_PINEVIEW(i915))
-   clock = KHz(RUNTIME_INFO(i915)->rawclk_freq);
+   clock = KHz(DISPLAY_RUNTIME_INFO(i915)->rawclk_freq);
else
clock = KHz(i915->display.cdclk.hw.cdclk);
 
@@ -1109,7 +1109,7 @@ static u32 i965_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
int clock;
 
if (IS_G4X(i915))
-   clock = KHz(RUNTIME_INFO(i915)->rawclk_freq);
+   clock = KHz(DISPLAY_RUNTIME_INFO(i915)->rawclk_freq);
else
clock = KHz(i915->display.cdclk.hw.cdclk);
 
@@ -1133,7 +1133,7 @@ static u32 vlv_hz_to_pwm(struct intel_connector 
*connector, u32 pwm_freq_hz)
clock = MHz(25);
mul = 16;
} else {
-   clock = KHz(RUNTIME_INFO(i915)->rawclk_freq);
+   clock = KHz(DISPLAY_RUNTIME_INFO(i915)->rawclk_freq);
mul = 128;
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 64a1cf4ed45c..74515f6bb64e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3608,7 +3608,7 @@ static void intel_rawclk_init(struct drm_i915_private 
*dev_priv)
else if (DISPLAY_VER(dev_priv) >= 3)
freq = i9xx_hrawclk(dev_priv);
 
-   RUNTIME_INFO(dev_priv)->rawclk_freq = freq;
+   DISPLAY_RUNTIME_INFO(dev_priv)->rawclk_freq = freq;
drm_dbg_kms(_priv->drm, "rawclk rate: %d kHz\n", freq);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c 
b/drivers/gpu/drm/i915/display/intel_display_device.c
index b8903bd0e82a..6fefdd90c600 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -1142,6 +1142,8 @@ void intel_display_device_info_print(const struct 
intel_display_device_info *inf
drm_printf(p, "has_hdcp: %s\n", str_yes_no(runtime->has_hdcp));
drm_printf(p, "has_dmc: %s\n", str_yes_no(runtime->has_dmc));
drm_printf(p, "has_dsc: %s\n", str_yes_no(runtime->has_dsc));
+
+   drm_printf(p, "rawclk rate: %u kHz\n", runtime->rawclk_freq);
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
b/drivers/gpu/drm/i915/display/intel_display_device.h
index 66b51de86e38..969ad95a3e7c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -110,6 +110,8 @@ struct drm_printer;
(DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
 
 struct intel_display_runtime_info {
+   u32 rawclk_freq;
+
struct {
u16 ver;
u16 rel;
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c 
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index e4de40228997..ee18b88dabfd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -1168,9 +1168,9 @@ static void 

[PATCH 1/2] drm/i915: move rawclk init to intel_cdclk_init()

2024-04-08 Thread Jani Nikula
The rawclk initialization is a bit out of place in
intel_device_info_runtime_init(). Move it to intel_cdclk_init(), with a
bit of refactoring on intel_read_rawclk().

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 23 +++---
 drivers/gpu/drm/i915/display/intel_cdclk.h |  1 -
 drivers/gpu/drm/i915/intel_device_info.c   |  4 
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d61aa5b7cbdb..64a1cf4ed45c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3210,6 +3210,8 @@ int intel_cdclk_state_set_joined_mbus(struct 
intel_atomic_state *state, bool joi
return intel_atomic_lock_global_state(_state->base);
 }
 
+static void intel_rawclk_init(struct drm_i915_private *dev_priv);
+
 int intel_cdclk_init(struct drm_i915_private *dev_priv)
 {
struct intel_cdclk_state *cdclk_state;
@@ -3221,6 +3223,8 @@ int intel_cdclk_init(struct drm_i915_private *dev_priv)
intel_atomic_global_obj_init(dev_priv, _priv->display.cdclk.obj,
 _state->base, _cdclk_funcs);
 
+   intel_rawclk_init(dev_priv);
+
return 0;
 }
 
@@ -3578,16 +3582,13 @@ static int i9xx_hrawclk(struct drm_i915_private 
*dev_priv)
}
 }
 
-/**
- * intel_read_rawclk - Determine the current RAWCLK frequency
- * @dev_priv: i915 device
- *
- * Determine the current RAWCLK frequency. RAWCLK is a fixed
- * frequency clock so this needs to done only once.
+/*
+ * Initialize the current RAWCLK frequency. RAWCLK is a fixed frequency clock 
so
+ * this needs to done only once.
  */
-u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
+static void intel_rawclk_init(struct drm_i915_private *dev_priv)
 {
-   u32 freq;
+   u32 freq = 0;
 
if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTL)
/*
@@ -3606,11 +3607,9 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
freq = vlv_hrawclk(dev_priv);
else if (DISPLAY_VER(dev_priv) >= 3)
freq = i9xx_hrawclk(dev_priv);
-   else
-   /* no rawclk on other platforms, or no need to know it */
-   return 0;
 
-   return freq;
+   RUNTIME_INFO(dev_priv)->rawclk_freq = freq;
+   drm_dbg_kms(_priv->drm, "rawclk rate: %d kHz\n", freq);
 }
 
 static int i915_cdclk_info_show(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h 
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index cfdcdec07a4d..a3f950d5a366 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -64,7 +64,6 @@ void intel_cdclk_uninit_hw(struct drm_i915_private *i915);
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv);
 void intel_update_max_cdclk(struct drm_i915_private *dev_priv);
 void intel_update_cdclk(struct drm_i915_private *dev_priv);
-u32 intel_read_rawclk(struct drm_i915_private *dev_priv);
 bool intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
   const struct intel_cdclk_config *b);
 int intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a0a43ea07f11..48f0957392f9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -370,10 +370,6 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
 "Disabling ppGTT for VT-d support\n");
runtime->ppgtt_type = INTEL_PPGTT_NONE;
}
-
-   runtime->rawclk_freq = intel_read_rawclk(dev_priv);
-   drm_dbg(_priv->drm, "rawclk rate: %d kHz\n", runtime->rawclk_freq);
-
 }
 
 /*
-- 
2.39.2



✓ Fi.CI.BAT: success for drm/i915: use check_add_overflow() and drop local variants (rev2)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: use check_add_overflow() and drop local variants (rev2)
URL   : https://patchwork.freedesktop.org/series/132104/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_132104v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Additional (1): fi-kbl-7567u 
  Missing(2): bat-dg1-7 bat-mtlp-9 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_heartbeat:
- bat-dg2-14: [PASS][3] -> [ABORT][4] ([i915#10366] / [i915#10677])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-dg2-14/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132104v2/bat-dg2-14/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7567u:   NOTRUN -> [SKIP][5] +11 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132104v2/fi-kbl-7567u/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@runner@aborted:
- bat-arls-2: NOTRUN -> [FAIL][6] ([i915#10690])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132104v2/bat-arls-2/igt@run...@aborted.html

  
  [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
  [i915#10677]: https://gitlab.freedesktop.org/drm/intel/issues/10677
  [i915#10690]: https://gitlab.freedesktop.org/drm/intel/issues/10690
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_132104v2

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_132104v2: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

c1b23ced5610 drm/i915: use check_add_overflow() and drop local variants

== Logs ==

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


✗ Fi.CI.SPARSE: warning for drm/i915: use check_add_overflow() and drop local variants (rev2)

2024-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: use check_add_overflow() and drop local variants (rev2)
URL   : https://patchwork.freedesktop.org/series/132104/
State : warning

== Summary ==

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




[linux-next:master] BUILD REGRESSION 11cb68ad52ac78c81e33b806b531f097e68edfa2

2024-04-08 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 11cb68ad52ac78c81e33b806b531f097e68edfa2  Add linux-next specific 
files for 20240408

Error/Warning: (recently discovered and may have been fixed)

drivers/gpu/drm/drm_mm.c:152:1: error: unused function 
'drm_mm_interval_tree_insert' [-Werror,-Wunused-function]
drivers/gpu/drm/drm_mm.c:152:1: error: unused function 
'drm_mm_interval_tree_iter_next' [-Werror,-Wunused-function]
drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer type 
'enum lima_gpu_id' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
drivers/gpu/drm/pl111/pl111_versatile.c:488:24: error: cast to smaller integer 
type 'enum versatile_clcd' from 'const void *' 
[-Werror,-Wvoid-pointer-to-enum-cast]

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- arm-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- arm-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- csky-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- csky-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- loongarch-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- microblaze-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- microblaze-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- openrisc-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- parisc-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   |-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|   `-- 
drivers-gpu-drm-nouveau-nvif-object.c:error:memcpy-accessing-or-more-bytes-at-offsets-and-overlaps-bytes-at-offset
|-- parisc-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   |-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|   `-- 
drivers-gpu-drm-nouveau-nvif-object.c:error:memcpy-accessing-or-more-bytes-at-offsets-and-overlaps-bytes-at-offset
|-- powerpc-allmodconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
|-- s390-allyesconfig
|   |-- 
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
|   `-- 
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d

Re: [PATCH 05/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

2024-04-08 Thread Steven Rostedt
On Fri,  5 Apr 2024 16:18:23 +0200
Sebastian Andrzej Siewior  wrote:

> The order of the header files is important. If this header file is
> included after tracepoint.h was included then the NOTRACE here becomes a
> nop. Currently this happens for two .c files which use the tracepoitns
> behind DRM_I915_LOW_LEVEL_TRACEPOINTS.

The NOTRACE should not be included in the individual trace files.

Can you show where this is an issue. I think this is fixing the symptom
and not the bug itself.

-- Steve


> 
> Cc: Steven Rostedt 
> Signed-off-by: Sebastian Andrzej Siewior 
> Signed-off-by: Thomas Gleixner 
> ---
>  drivers/gpu/drm/i915/i915_trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index c54653cf72c95..3c51620d011b1 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -326,7 +326,7 @@ DEFINE_EVENT(i915_request, i915_request_add,
>TP_ARGS(rq)
>  );
>  
> -#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS) && !defined(NOTRACE)
>  DEFINE_EVENT(i915_request, i915_request_guc_submit,
>TP_PROTO(struct i915_request *rq),
>TP_ARGS(rq)



✗ Fi.CI.BAT: failure for series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)
URL   : https://patchwork.freedesktop.org/series/132028/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14543 -> Patchwork_132028v3


Summary
---

  **FAILURE**

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

Participating hosts (41 -> 39)
--

  Missing(2): bat-dg1-7 fi-kbl-8809g 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_tlb:
- bat-arls-1: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-1/igt@i915_selftest@live@gt_tlb.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132028v3/bat-arls-1/igt@i915_selftest@live@gt_tlb.html

  * igt@i915_selftest@live@memory_region:
- bat-arls-2: [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-2/igt@i915_selftest@live@memory_region.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132028v3/bat-arls-2/igt@i915_selftest@live@memory_region.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- bat-atsm-1: [PASS][5] -> [SKIP][6] ([i915#9980])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-atsm-1/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132028v3/bat-atsm-1/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}:   [DMESG-WARN][7] ([i915#10435]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132028v3/bat-mtlp-9/igt@kms_flip@basic-flip-vs-d...@a-dp6.html

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

  [i915#10435]: https://gitlab.freedesktop.org/drm/intel/issues/10435
  [i915#9980]: https://gitlab.freedesktop.org/drm/intel/issues/9980


Build changes
-

  * Linux: CI_DRM_14543 -> Patchwork_132028v3

  CI-20190529: 20190529
  CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7801: 7801
  Patchwork_132028v3: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

31ce31d7c0af drm/i915: Use the same vblank worker for atomic unpin
7f3932ae619b drm/i915: Use vblank worker to unpin old legacy cursor fb safely
33dc7e4c6709 drm: Add drm_vblank_work_flush_all().

== Logs ==

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


✗ Fi.CI.SPARSE: warning for series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)
URL   : https://patchwork.freedesktop.org/series/132028/
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 

✗ Fi.CI.CHECKPATCH: warning for series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)

2024-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [v2] drm: Add drm_vblank_work_flush_all(). (rev3)
URL   : https://patchwork.freedesktop.org/series/132028/
State : warning

== Summary ==

Error: dim checkpatch failed
59ee87364491 drm: Add drm_vblank_work_flush_all().
-:33: WARNING:WAITQUEUE_ACTIVE: waitqueue_active without comment
#33: FILE: drivers/gpu/drm/drm_vblank_work.c:249:
+   !waitqueue_active(>work_wait_queue),

total: 0 errors, 1 warnings, 0 checks, 41 lines checked
072f56481d10 drm/i915: Use vblank worker to unpin old legacy cursor fb safely
9908f94fa4b8 drm/i915: Use the same vblank worker for atomic unpin
-:107: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#107: FILE: drivers/gpu/drm/i915/display/intel_crtc.c:641:
+
drm_crtc_accurate_vblank_count(>base) + 1,

-:110: WARNING:LONG_LINE_COMMENT: line length of 110 exceeds 100 columns
#110: FILE: drivers/gpu/drm/i915/display/intel_crtc.c:644:
+   /* Remove plane from atomic state, cleanup/free 
is done from vblank worker. */

total: 0 errors, 2 warnings, 0 checks, 98 lines checked




Re: [PATCH 2/6] drm/i915/dmc: define firmware URL locally

2024-04-08 Thread Josh Boyer
On Fri, Apr 5, 2024 at 4:29 PM Lucas De Marchi  wrote:
>
> On Fri, Apr 05, 2024 at 10:37:39PM +0300, Jani Nikula wrote:
> >Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat
> >intel_uc_fw.h. If there needs to be duplication of the URL, at least
> >have the duplication in a sensible way.
> >
> >Cc: Lucas De Marchi 
> >Signed-off-by: Jani Nikula 
>
>
> Reviewed-by: Lucas De Marchi 
>
> but see below. +Josh
>
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c |  4 +++-
> > drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h|  1 -
> > drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h | 11 ---
> > 3 files changed, 3 insertions(+), 13 deletions(-)
> > delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 3fa851b5c7a6..e61e9c1b8947 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -38,6 +38,8 @@
> >  * low-power state and comes back to normal.
> >  */
> >
> >+#define INTEL_DMC_FIRMWARE_URL 
> >"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
>
> repo recently moved to gitlab, but as far as I know the one on
> kernel.org will still work. Do we want to change it?
>
> https://gitlab.com/kernel-firmware/linux-firmware

I don't think there's a need to change it right now.  I can't see us
removing the kernel.org linux-firmware tree.  Given it's firmware, I
don't think the defined macro is really trying to point to a
contribution site either so pointing to gitlab probably isn't
worthwhile.

josh

> thanks
> Lucas De Marchi
>
> >+
> > enum intel_dmc_id {
> >   DMC_FW_MAIN = 0,
> >   DMC_FW_PIPEA,
> >@@ -953,7 +955,7 @@ static void dmc_load_work_fn(struct work_struct *work)
> >  " Disabling runtime power management.\n",
> >  dmc->fw_path);
> >   drm_notice(>drm, "DMC firmware homepage: %s",
> >- INTEL_UC_FIRMWARE_URL);
> >+ INTEL_DMC_FIRMWARE_URL);
> >   }
> >
> >   release_firmware(fw);
> >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 a01d1b869c2d..837e95e3604e 100644
> >--- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
> >+++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
> >@@ -26,7 +26,6 @@
> > #include "i915_utils.h"
> > #include "intel_gt_types.h"
> > #include "intel_step.h"
> >-#include "intel_uc_fw.h"
> > #include "intel_uncore.h"
> > #include "intel_runtime_pm.h"
> > #include 
> >diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h 
> >b/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >deleted file mode 100644
> >index 009745328992..
> >--- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
> >+++ /dev/null
> >@@ -1,11 +0,0 @@
> >-/* SPDX-License-Identifier: MIT */
> >-/*
> >- * Copyright © 2023 Intel Corporation
> >- */
> >-
> >-#ifndef _INTEL_UC_FW_H_
> >-#define _INTEL_UC_FW_H_
> >-
> >-#define INTEL_UC_FIRMWARE_URL 
> >"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
> >-
> >-#endif
> >--
> >2.39.2
> >
>



Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/2/2024 1:29 AM, Simon Horman wrote:
> On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
>>
>> Compile tested, no functionality changes intended
>>
>> [1]: 
>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>
>> Signed-off-by: Easwar Hariharan 
> 
> Reviewed-by: Simon Horman 


Thank you, Simon, for reviewing. I believe that we are settling on 
controller/target
terminology from feedback on the other drivers in this series. Would you want 
to re-review
v1 with that change, or should I add you R-B in v1 despite the change?

Thanks,
Easwar


Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Martin Habets
On Thu, Apr 04, 2024 at 12:18:06PM -0700, Easwar Hariharan wrote:
> On 4/2/2024 2:00 AM, Martin Habets wrote:
> > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> >> with more appropriate terms. Inspired by and following on to Wolfram's
> >> series to fix drivers/i2c/[1], fix the terminology for users of
> >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> >> in the specification.
> >>
> >> Compile tested, no functionality changes intended
> >>
> >> [1]: 
> >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >>
> >> Signed-off-by: Easwar Hariharan 
> > 
> > Reviewed-by: Martin Habets 
> > 
> 
> Thank you, Martin, for reviewing. I believe that we are settling on 
> controller/target
> terminology from feedback on the other drivers in this series. Would you want 
> to re-review
> v1 with that change, or should I add your R-B in v1 despite the change?

You can add in my Reviewed-by.

Martin

> Thanks,
> Easwar
> 


Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Simon Horman
On Thu, Apr 04, 2024 at 12:17:26PM -0700, Easwar Hariharan wrote:
> On 4/2/2024 1:29 AM, Simon Horman wrote:
> > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> >> with more appropriate terms. Inspired by and following on to Wolfram's
> >> series to fix drivers/i2c/[1], fix the terminology for users of
> >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> >> in the specification.
> >>
> >> Compile tested, no functionality changes intended
> >>
> >> [1]: 
> >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >>
> >> Signed-off-by: Easwar Hariharan 
> > 
> > Reviewed-by: Simon Horman 
> 
> 
> Thank you, Simon, for reviewing. I believe that we are settling on 
> controller/target
> terminology from feedback on the other drivers in this series. Would you want 
> to re-review
> v1 with that change, or should I add you R-B in v1 despite the change?

Thanks for asking,

either way is fine by me.


Re: [PATCH 0/6] drm: enable W=1 warnings by default across the subsystem

2024-04-08 Thread Aishwarya TCV



On 05/04/2024 10:57, Jani Nikula wrote:
> On Thu, 04 Apr 2024, Aishwarya TCV  wrote:
>> Observed warning "include/drm/drm_print.h:536:35: warning: '%4.4s'
>> directive argument is null [-Wformat-overflow=]" when building the
>> modules with "defconfig+kselftest-ftrace"(
>> https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ftrace/config
>> ) against next-master(next-20240404) kernel with Arm64 in our CI.
>>
>> A bisect identified a61ddb4393ad1be61d2ffd92576d42707b05be17 as the
>> first bad commit. Bisected it on the tag "next-20240326" at repo
>> "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git;.
>>
>> I understand that you are turning on the warning here, thought worth
>> mentioning about the observation.
> 
> Thanks for the report. I can't reproduce this myself, but please see if
> [1] fixes the issue.
> 
> 
> BR,
> Jani.
> 
> [1] 
> https://lore.kernel.org/dri-devel/20240405092907.2334007-1-jani.nik...@intel.com
> 
> 

Thanks, as expected this fixes the issue. Tested the attached patch by
building the modules with "defconfig+kselftest-ftrace" against
next-20240405 kernel with Arm64.

Tested-by: Aishwarya TCV 


Re: [PATCH v0 02/14] drm/amdgpu,drm/radeon: Make I2C terminology more inclusive

2024-04-08 Thread Ville Syrjälä
On Fri, Mar 29, 2024 at 06:38:10PM +0100, Andi Shyti wrote:
> Hi,
> 
> On Fri, Mar 29, 2024 at 10:28:14AM -0700, Easwar Hariharan wrote:
> > On 3/29/2024 10:16 AM, Andi Shyti wrote:
> > > Hi Easwar,
> > > 
> > > On Fri, Mar 29, 2024 at 05:00:26PM +, Easwar Hariharan wrote:
> > >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> > > 
> > > I don't understand why we forget that i3c is 1.1.1 :-)
> > 
> > That's because it's a copy-paste error from Wolfram's cover letter. :) I'll 
> > update
> > next go-around.
> 
> not a binding comment, though. Just for completeness, because we
> are giving the version to the i2c and smbus, but not i3c.
> 
> > >> with more appropriate terms. Inspired by and following on to Wolfram's
> > >> series to fix drivers/i2c/[1], fix the terminology for users of
> > >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> > >> in the specification.
> > > 
> > > The specification talks about:
> > > 
> > >  - master -> controller
> > >  - slave -> target (and not client)
> > > 
> > > But both you and Wolfram have used client. I'd like to reach
> > > some more consistency here.
> > 
> > I had the impression that remote targets (i.e external to the device) were 
> > to be called clients,
> > e.g. the QSFP FRUs in drivers/infiniband, and internal ones targets.
> > I chose the terminology according to that understanding, but now I can't 
> > find where I got that
> > information.
> 
> The word "client" does not even appear in the documentation (only
> one instance in the i3c document), so that the change is not
> related to the document as stated in the commit log. Unless, of
> course, I am missing something.
> 
> I'm OK with choosing a "customized" naming, but we need to reach
> an agreement.
> 
> I raised the same question to Wolfram.

I don't know where that discussion happened, but my opinion
is NAK to "client". Life is already confusing enough with
these renames, so let's not make it even more confusing by
inventing new names nowhere to be found in the spec.

And let's especially not invent names that don't even fit
the purpose. "Client" makes me think of "client/server" or
some real world analogy. Neither of which seem to have any
resemblence to how the term would be used for i2c.

-- 
Ville Syrjälä
Intel


Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers

2024-04-08 Thread Easwar Hariharan
Hi Wolfram,

On 4/5/2024 3:18 AM, Wolfram Sang wrote:
> Hello Easwar,
> 
> On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of the
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
> 
> I really appreciate that you want to assist in this task to improve the
> I2C core. I do. I am afraid, however, that you took the second step
> before the first one, though. As I mentioned in my original cover
> letter, this is not only about renaming but also improving the I2C API
> (splitting up header files...). So, drivers are not a priority right
> now. They can be better fixed once the core is ready.
>

Sorry, got excited. :) There were drivers I'd been part of that I specifically
wanted to fixup, but then the scope grew to other users of algobit.

> It is true that I changed quite some controller drivers within the i2c
> realm. I did this to gain experience. As you also noticed quite some
> questions came up. We need to agree on answers first. And once we are
> happy with the answers we found, then IMO we can go outside of the i2c
> realm and send patches to other subsystems referencing agreed
> precedence. I intentionally did not go outside i2c yet. Since your
> patches are already there, you probably want to foster them until they
> are ready for inclusion.

Sorry, I don't quite follow what you mean by foster in this context. Are
you asking me to hold off on merging the series, or to follow through on
getting it merged?

 Yet, regarding further patches, my suggestion
> is to wait until the core is ready. That might take a while, though.
> However, there is enough to discuss until the core is ready. So, your
> collaboration there is highly appreciated!
> 
>> The last patch updating the .master_xfer method to .xfer depends on
>> patch 1 of Wolfram's series below, but the series is otherwise
>> independent. It may make sense for the last patch to go in with
> 
> Please drop the last patch from this series. It will nicely remove the
> dependency. Also, like above, I first want to gain experience with i2c
> before going to other subsystems. That was intended.
>

Will do, thanks!

> All the best and happy hacking,
> 
>Wolfram
> 



Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/2/2024 2:00 AM, Martin Habets wrote:
> On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
>>
>> Compile tested, no functionality changes intended
>>
>> [1]: 
>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>
>> Signed-off-by: Easwar Hariharan 
> 
> Reviewed-by: Martin Habets 
> 

Thank you, Martin, for reviewing. I believe that we are settling on 
controller/target
terminology from feedback on the other drivers in this series. Would you want 
to re-review
v1 with that change, or should I add your R-B in v1 despite the change?

Thanks,
Easwar



Re: [PATCH v0 13/14] drm/nouveau: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/5/2024 9:15 AM, Danilo Krummrich wrote:
> Hi Easwar,
> 
> On 3/29/24 18:00, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
>>
>> Compile tested, no functionality changes intended
>>
>> [1]: 
>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>
>> Signed-off-by: Easwar Hariharan 
>> ---
>>   drivers/gpu/drm/nouveau/dispnv04/dfp.c | 14 +++---
>>   .../gpu/drm/nouveau/include/nvkm/subdev/bios/dcb.h |  2 +-
>>   drivers/gpu/drm/nouveau/nouveau_bios.c |  4 ++--
>>   3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
>> b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
>> index d5b129dc623b..65b791006b19 100644
>> --- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
>> +++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
>> @@ -149,7 +149,7 @@ void nv04_dfp_update_fp_control(struct drm_encoder 
>> *encoder, int mode)
>>   }
>>   }
>>   -static struct drm_encoder *get_tmds_slave(struct drm_encoder *encoder)
>> +static struct drm_encoder *get_tmds_client(struct drm_encoder *encoder)
>>   {
>>   struct drm_device *dev = encoder->dev;
>>   struct dcb_output *dcb = nouveau_encoder(encoder)->dcb;
>> @@ -172,7 +172,7 @@ static struct drm_encoder *get_tmds_slave(struct 
>> drm_encoder *encoder)
>>   struct dcb_output *slave_dcb = nouveau_encoder(slave)->dcb;
>>     if (slave_dcb->type == DCB_OUTPUT_TMDS && get_slave_funcs(slave) 
>> &&
>> -    slave_dcb->tmdsconf.slave_addr == dcb->tmdsconf.slave_addr)
>> +    slave_dcb->tmdsconf.client_addr == dcb->tmdsconf.client_addr)
>>   return slave;
> 
> While, personally, I think master/slave was well suiting for the device 
> relationship
> on those busses, I think that if we change it up to conform with the change in
> specification, we should make sure to update drivers consistently.
> 
> We should make sure to also change the names of the sourrounding structures 
> and variable
> names, otherwise we just make this code harder to read.
> 
> - Danilo
> 

Thanks for the review, and for the appetite to go further! So we are on the 
same page, you would prefer
renaming to controller/target like the feedback on other drm drivers (i915, 
gma500, radeon)?

Thanks,
Easwar



Re: [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive

2024-04-08 Thread Dennis Dalessandro


On 4/3/24 4:30 AM, Leon Romanovsky wrote:
> On Fri, Mar 29, 2024 at 05:00:25PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's series
>> to fix drivers/i2c[1], fix the terminology where I had a role to play, now 
>> that
>> the approved verbiage exists in the specification.
>>
>> Compile tested, no functionality changes intended
>>
>> [1]: 
>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>
>> Signed-off-by: Easwar Hariharan 
>> ---
>>  drivers/infiniband/hw/hfi1/chip.c   |  6 ++--
>>  drivers/infiniband/hw/hfi1/chip.h   |  2 +-
>>  drivers/infiniband/hw/hfi1/chip_registers.h |  2 +-
>>  drivers/infiniband/hw/hfi1/file_ops.c   |  2 +-
>>  drivers/infiniband/hw/hfi1/firmware.c   | 22 ++---
>>  drivers/infiniband/hw/hfi1/pcie.c   |  2 +-
>>  drivers/infiniband/hw/hfi1/qsfp.c   | 36 ++---
>>  drivers/infiniband/hw/hfi1/user_exp_rcv.c   |  2 +-
>>  drivers/infiniband/hw/qib/qib_twsi.c|  6 ++--
>>  9 files changed, 40 insertions(+), 40 deletions(-)
> 
> hfi1 and qib work perfectly fine with the current terminology. There is
> no need to change old code just for the sake of change.
> 
> Let's drop this patch.

Agreed.


Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/2/2024 9:52 AM, Jani Nikula wrote:
> On Tue, 02 Apr 2024, Easwar Hariharan  wrote:
>> On 4/2/2024 7:32 AM, Jani Nikula wrote:
>>> On Tue, 02 Apr 2024, Easwar Hariharan  wrote:
 On 4/2/2024 12:48 AM, Jani Nikula wrote:
> On Fri, 29 Mar 2024, Easwar Hariharan  
> wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
>
> gma500 and i915 changes should be split. See MAINTAINERS.
>
> Might also split the i915 changes to smaller pieces, it's kind of
> random. And the changes here are not strictly related to I2C AFAICT, so
> the commit message should be updated.
>
> BR,
> Jani.
>
>

 

 I will split gma500 and i915 into their respective patches if possible in 
 v2.

 Can you say more about the changes being "not strictly related to I2C"? My
 heuristic was to grep for master/slave, and look in the surrounding 
 context for
 i2c-related terminology (i2c_pin, 7-bit address, struct i2c_adapter, 
 i2c_bus, etc)
 to confirm that they are i2c-related, then following the references around 
 to
 make the compiler happy. For e.g., I did not change the many references to 
 bigjoiner
 master and slave because I understood from context they were not i2c 
 references.

 A couple examples would help me restrict the changes to I2C, since as 
 mentioned in the
 discussion on Wolfram's thread, there are places where migrating away from 
 master/slave
 terms in the code would conflict with the original technical manuals and 
 reduce correlation
 and understanding of the code.
>>>
>>> I guess I was looking at the VBT changes in intel_bios.c. Granted, they
>>> do end up being used as i2c addresses. No big deal.
>>>
>>> I think I'd expect the treewide i2c adapter changes to land first, via
>>> i2c, and subsequent cleanups to happen next, via individual driver
>>> trees. There's quite a bit of conflict potential merging this outside of
>>> drm-intel-next, and there's really no need for that.
>>>
>>> BR,
>>> Jani.
>>>
>>
>> Great! Just so I'm clear, do you still want the i915 changes split up more, 
>> along with them being
>> split off from gma500?
> 
> If we can merge the i915 changes via drm-intel-next, it's probably fine
> as a big i915 patch. Just the gma500 separated. (The struct
> i2c_algorithm change etc. necessarily has to go via I2C tree of course.)
> 
> BR,
> Jani.
> 

Got it. I'll send the split out in v1 (not v2 as mentioned earlier) since this 
is v0.

Thanks,
Easwar



Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/2/2024 12:48 AM, Jani Nikula wrote:
> On Fri, 29 Mar 2024, Easwar Hariharan  wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the terminology for users of
>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>> in the specification.
> 
> gma500 and i915 changes should be split. See MAINTAINERS.
> 
> Might also split the i915 changes to smaller pieces, it's kind of
> random. And the changes here are not strictly related to I2C AFAICT, so
> the commit message should be updated.
> 
> BR,
> Jani.
> 
> 



I will split gma500 and i915 into their respective patches if possible in v2.

Can you say more about the changes being "not strictly related to I2C"? My
heuristic was to grep for master/slave, and look in the surrounding context for
i2c-related terminology (i2c_pin, 7-bit address, struct i2c_adapter, i2c_bus, 
etc)
to confirm that they are i2c-related, then following the references around to
make the compiler happy. For e.g., I did not change the many references to 
bigjoiner
master and slave because I understood from context they were not i2c references.

A couple examples would help me restrict the changes to I2C, since as mentioned 
in the
discussion on Wolfram's thread, there are places where migrating away from 
master/slave
terms in the code would conflict with the original technical manuals and reduce 
correlation
and understanding of the code.

Thanks,
Easwar



Re: [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/3/2024 8:54 AM, Dennis Dalessandro wrote:
> 
> On 4/3/24 4:30 AM, Leon Romanovsky wrote:
>> On Fri, Mar 29, 2024 at 05:00:25PM +, Easwar Hariharan wrote:
>>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>>> with more appropriate terms. Inspired by and following on to Wolfram's 
>>> series
>>> to fix drivers/i2c[1], fix the terminology where I had a role to play, now 
>>> that
>>> the approved verbiage exists in the specification.
>>>
>>> Compile tested, no functionality changes intended
>>>
>>> [1]: 
>>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>>
>>> Signed-off-by: Easwar Hariharan 
>>> ---
>>>  drivers/infiniband/hw/hfi1/chip.c   |  6 ++--
>>>  drivers/infiniband/hw/hfi1/chip.h   |  2 +-
>>>  drivers/infiniband/hw/hfi1/chip_registers.h |  2 +-
>>>  drivers/infiniband/hw/hfi1/file_ops.c   |  2 +-
>>>  drivers/infiniband/hw/hfi1/firmware.c   | 22 ++---
>>>  drivers/infiniband/hw/hfi1/pcie.c   |  2 +-
>>>  drivers/infiniband/hw/hfi1/qsfp.c   | 36 ++---
>>>  drivers/infiniband/hw/hfi1/user_exp_rcv.c   |  2 +-
>>>  drivers/infiniband/hw/qib/qib_twsi.c|  6 ++--
>>>  9 files changed, 40 insertions(+), 40 deletions(-)
>>
>> hfi1 and qib work perfectly fine with the current terminology. There is
>> no need to change old code just for the sake of change.
>>
>> Let's drop this patch.
> 
> Agreed.

Will drop in v1.

Thanks,
Easwar


Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Martin Habets
On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
> 
> Compile tested, no functionality changes intended
> 
> [1]: 
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> 
> Signed-off-by: Easwar Hariharan 

Reviewed-by: Martin Habets 

> ---
>  drivers/net/ethernet/sfc/falcon/falcon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/sfc/falcon/falcon.c 
> b/drivers/net/ethernet/sfc/falcon/falcon.c
> index 7a1c9337081b..147e7c8e3c02 100644
> --- a/drivers/net/ethernet/sfc/falcon/falcon.c
> +++ b/drivers/net/ethernet/sfc/falcon/falcon.c
> @@ -367,7 +367,7 @@ static const struct i2c_algo_bit_data 
> falcon_i2c_bit_operations = {
>   .getsda = falcon_getsda,
>   .getscl = falcon_getscl,
>   .udelay = 5,
> - /* Wait up to 50 ms for slave to let us pull SCL high */
> + /* Wait up to 50 ms for client to let us pull SCL high */
>   .timeout= DIV_ROUND_UP(HZ, 20),
>  };
>  
> -- 
> 2.34.1
> 


[REQUEST] Add support for Intel DPST (Display Power Saving Technology)

2024-04-08 Thread José Relvas
Hey folks,

I've noticed that power-profiles-daemon recently added support for AMD's panel 
power saving technology with this MR:
https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_requests/137

It appears to be controlled via a panel_power_saving SYSFS property.

This reminded that Intel has a similar technology. RPL's datasheets confirm 
this:
https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processors-datasheet-volume-1-of-2/display-power-savings-technologies/

> The Intel® DPST technique achieves back-light power savings while maintaining
> a good visual experience. This is accomplished by adaptively enhancing the
> displayed image while decreasing the back-light brightness simultaneously. 
> The goal of this technique is to provide equivalent end-user-perceived 
> image quality at a decreased back-light power level. 

> Intel® OPST solution uses same HW infrastructure as Intel® DPST. Frames are 
> processed using frame change threshold based interrupt mechanism similar
> to Intel® DPST. Intel® OPST SW algorithm determines which pixels in the 
> frame should be dimmed to save power keeping visual quality (such as 
> contrast, color) 
> impact to acceptable level. Since there is no backlight for OLED panels,
> the power savings come solely from pixel dimming. 

However, it doesn't seem like i915 has any support for this. Searching online 
was
ineffective too:

- I found mentions of /sys/class/drm/card0/power/i915_dpst, but it doesn't seem 
to exist,
at least not anymore.

- A i915.dpst parameter was also brought up, but it doesn't seem to exist 
either.

Interestingly, all mentions of dpst on Linux were referring to Android, so maybe
this was a downstream thing with Android?

In any case, I found this email in the archive which confirms
that DPST was not supported (at least in 2012):
https://lore.kernel.org/intel-gfx/50adffb3.8030...@linux.intel.com/

Since AMD's equivalent to DPST is now supported by their driver and being used 
by userspace,
it seems like a sensible idea to implement this for i915. I've confirmed that 
this feature
has existed since (at least) Haswell (released over a decade ago!) so 
implementing it
would likely net a few energy consumption improvements for a large chunk of 
Intel laptops.

The best approach here would probably be to expose a similar attribute to 
amdgpu's 
"panel_power_savings", with a scale that controls the feature's aggressiveness,
then update userspace tools, including power-profiles-daemon, to set the value
based on the intended energy scheme.

Thanks for reading,
José Relvas


Re: [PATCH 0/6] drm: enable W=1 warnings by default across the subsystem

2024-04-08 Thread Aishwarya TCV



On 10/01/2024 17:39, Jani Nikula wrote:
> This is v2 of [1] to enable most W=1 warnings across the drm
> subsystem. Some fixes first, and a CONFIG_DRM_WERROR on top.
> 
> I build tested this for x86 (both gcc and clang), arm and arm64.
> 
> BR,
> Jani.
> 
> 
> [1] https://lore.kernel.org/r/20231129181219.1237887-1-jani.nik...@intel.com
> 
> 
> 
> 
> Jani Nikula (6):
>   drm/nouveau/acr/ga102: remove unused but set variable
>   drm/nouveau/svm: remove unused but set variables
>   drm/amdgpu: prefer snprintf over sprintf
>   drm/imx: prefer snprintf over sprintf
>   drm: enable (most) W=1 warnings by default across the subsystem
>   drm: Add CONFIG_DRM_WERROR
> 
>  drivers/gpu/drm/Kconfig   | 18 +++
>  drivers/gpu/drm/Makefile  | 30 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c   |  3 +-
>  drivers/gpu/drm/imx/ipuv3/imx-ldb.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_svm.c | 10 ++-
>  .../gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c|  3 +-
>  6 files changed, 55 insertions(+), 11 deletions(-)
> 

Hi Jani,

Observed warning "include/drm/drm_print.h:536:35: warning: '%4.4s'
directive argument is null [-Wformat-overflow=]" when building the
modules with "defconfig+kselftest-ftrace"(
https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ftrace/config
) against next-master(next-20240404) kernel with Arm64 in our CI.

A bisect identified a61ddb4393ad1be61d2ffd92576d42707b05be17 as the
first bad commit. Bisected it on the tag "next-20240326" at repo
"https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git;.

I understand that you are turning on the warning here, thought worth
mentioning about the observation.

Build log:
---
In file included from ../include/drm/drm_mm.h:51,
 from ../include/drm/drm_vma_manager.h:26,
 from ../include/drm/drm_gem.h:42,
 from ../drivers/gpu/drm/msm/msm_drv.h:34,
 from ../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:20:
In function '_dpu_plane_set_qos_lut',
inlined from 'dpu_plane_sspp_update_pipe' at
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1078:2:
../include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument
is null [-Wformat-overflow=]
  536 | #define __drm_dbg(cat, fmt, ...)  ___drm_dbg(NULL, cat, fmt,
##__VA_ARGS__)
  |
^
../include/drm/drm_print.h:594:2: note: in expansion of macro '__drm_dbg'
  594 |  __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
  |  ^
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:30:39: note: in expansion
of macro 'DRM_DEBUG_ATOMIC'
   30 | #define DPU_DEBUG_PLANE(pl, fmt, ...) DRM_DEBUG_ATOMIC("plane%d
" fmt,\
  |   ^~~~
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:290:2: note: in expansion
of macro 'DPU_DEBUG_PLANE'
  290 |  DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s rt:%d fl:%u
lut:0x%llx\n",
  |  ^~~
  CC [M]  drivers/net/can/spi/mcp251xfd/mcp251xfd-ethtool.o



Bisect log:

git bisect start
# good: [4cece764965020c22cff7665b18a012006359095] Linux 6.9-rc1
git bisect good 4cece764965020c22cff7665b18a012006359095
# bad: [084c8e315db34b59d38d06e684b1a0dd07d30287] Add linux-next
specific files for 20240326
git bisect bad 084c8e315db34b59d38d06e684b1a0dd07d30287
# good: [1cc931629f2b3de04b7608b8d26692c6f6a52aeb] Merge branch
'nand/next' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
git bisect good 1cc931629f2b3de04b7608b8d26692c6f6a52aeb
# bad: [4f5a3415aaf8fdf945e4cb67b847254ddda2f583] Merge branch
'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel
git bisect bad 4f5a3415aaf8fdf945e4cb67b847254ddda2f583
# bad: [a13305486485d0657fbf09cee72fca9553d7d6cd] Merge branch
'drm-next' of https://gitlab.freedesktop.org/agd5f/linux
git bisect bad a13305486485d0657fbf09cee72fca9553d7d6cd
# good: [417f78a2a1c8c2d517db8b2e04785c1c94a563b4] drm/amdkfd: Cleanup
workqueue during module unload
git bisect good 417f78a2a1c8c2d517db8b2e04785c1c94a563b4
# bad: [57a4e3a94caee6cfda41700da877bee77eab939c] Revert "drm/panthor:
Fix undefined panthor_device_suspend/resume symbol issue"
git bisect bad 57a4e3a94caee6cfda41700da877bee77eab939c
# bad: [2cddf770be0cebb663af3d72c049b9e24928f335] drm/kunit: fix
drm_kunit_helpers.h kernel-doc
git bisect bad 2cddf770be0cebb663af3d72c049b9e24928f335
# good: [d72f049087d4f973f6332b599c92177e718107de] drm/panthor: Allow
driver compilation
git bisect good d72f049087d4f973f6332b599c92177e718107de
# good: [e18aeeda0b6905c333df5a0566b99f5c84426098] drm/bridge: Fix
improper bridge init order with pre_enable_prev_first
git bisect good e18aeeda0b6905c333df5a0566b99f5c84426098
# bad: [f89632a9e5fa6c4787c14458cd42a9ef42025434] drm: Add CONFIG_DRM_WERROR
git bisect bad f89632a9e5fa6c4787c14458cd42a9ef42025434
# good: [460be1d527a8e296d85301e8b14923299508d4fc] drm/nouveau: move
more missing 

Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive

2024-04-08 Thread Simon Horman
On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
> 
> Compile tested, no functionality changes intended
> 
> [1]: 
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> 
> Signed-off-by: Easwar Hariharan 

Reviewed-by: Simon Horman 



Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive

2024-04-08 Thread Easwar Hariharan
On 4/2/2024 7:32 AM, Jani Nikula wrote:
> On Tue, 02 Apr 2024, Easwar Hariharan  wrote:
>> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>>> On Fri, 29 Mar 2024, Easwar Hariharan  wrote:
 I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
 with more appropriate terms. Inspired by and following on to Wolfram's
 series to fix drivers/i2c/[1], fix the terminology for users of
 I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
 in the specification.
>>>
>>> gma500 and i915 changes should be split. See MAINTAINERS.
>>>
>>> Might also split the i915 changes to smaller pieces, it's kind of
>>> random. And the changes here are not strictly related to I2C AFAICT, so
>>> the commit message should be updated.
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>
>> 
>>
>> I will split gma500 and i915 into their respective patches if possible in v2.
>>
>> Can you say more about the changes being "not strictly related to I2C"? My
>> heuristic was to grep for master/slave, and look in the surrounding context 
>> for
>> i2c-related terminology (i2c_pin, 7-bit address, struct i2c_adapter, 
>> i2c_bus, etc)
>> to confirm that they are i2c-related, then following the references around to
>> make the compiler happy. For e.g., I did not change the many references to 
>> bigjoiner
>> master and slave because I understood from context they were not i2c 
>> references.
>>
>> A couple examples would help me restrict the changes to I2C, since as 
>> mentioned in the
>> discussion on Wolfram's thread, there are places where migrating away from 
>> master/slave
>> terms in the code would conflict with the original technical manuals and 
>> reduce correlation
>> and understanding of the code.
> 
> I guess I was looking at the VBT changes in intel_bios.c. Granted, they
> do end up being used as i2c addresses. No big deal.
> 
> I think I'd expect the treewide i2c adapter changes to land first, via
> i2c, and subsequent cleanups to happen next, via individual driver
> trees. There's quite a bit of conflict potential merging this outside of
> drm-intel-next, and there's really no need for that.
> 
> BR,
> Jani.
> 

Great! Just so I'm clear, do you still want the i915 changes split up more, 
along with them being
split off from gma500?

Thanks,
Easwar


Re: [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Melissa Wen  wrote:
> On 04/08, Jani Nikula wrote:
>> On Mon, 08 Apr 2024, Melissa Wen  wrote:
>> > On 04/02, Jani Nikula wrote:
>> >> On Thu, 21 Mar 2024, Jani Nikula  wrote:
>> >> > Jani Nikula (4):
>> >> >   drm/edid: add drm_edid_get_product_id()
>> >> >   drm/edid: add drm_edid_print_product_id()
>> >> >   drm/i915/bios: switch to struct drm_edid and struct
>> >> > drm_edid_product_id
>> >> >   drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
>> >> 
>> >> Ping for reviews please? This should be helpful in eradicating one class
>> >> of drm_edid_raw() uses.
>> >
>> > Hi Jani,
>> >
>> > I took a look at the series. AFAIU your solution with
>> > `drm_edid_product_id` mostly fits AMD display driver needs, except that
>> > it needs the `product_code` split into two parts (like manufacturer
>> > name) because the driver handles prod_code parts to configure a register
>> > for audio, as in the path below:
>> >
>> > 1. 
>> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c#L113
>> > 2. 
>> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/core/dc_stream.c#L90
>> > 3. 
>> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c#L873
>> >
>> > What do you think on keeping `prod_code` split into two part in
>> > `drm_edid_product_id`?
>> 
>> I think having it as "__le16 product_code" is better and
>> self-documenting. This is what the spec says it is, so why split it to
>> two parts where you always need to wonder about the byte order?
>
> I have no strong opinion, I was only thinking that two parts would make
> this `edid_buf->prod_code[0] | edid_buf->prod_code[1] << 8` operation
> more intuitive.
>
> As you mentioned the currrent product_code format fits specs better, I
> understand we can get the same result on amd with:
> le16_to_cpu() --> split --> second part shift.

Wait, what? No. le16_to_cpu() directly gives you what you want. That's
the whole point. No splits, no shifts, no OR-ing. One macro that forces
the right byte order for you, as the member is defined __le16.

> Anyway, it's certainly not a blocker. The series LGTM.
>
> Acked-by: Melissa Wen 
>
>> 
>> This is how you'd use it:
>> 
>>  edid_caps->product_id = le16_to_cpu(id->product_code);

This is intended to be an example how to deal with your URL 1 above.

BR,
Jani.

>> 
>> BR,
>> Jani.
>> 
>> >
>> > (cc'ing some AMD devs that might have a better understanding of this use 
>> > case)
>> >
>> > Thanks a lot for addressing this pending issue!
>> >
>> > Melissa
>> >
>> >> 
>> >> BR,
>> >> Jani.
>> >> 
>> >> 
>> >> >
>> >> >  drivers/gpu/drm/drm_edid.c| 50 +++
>> >> >  drivers/gpu/drm/i915/display/intel_bios.c | 49 ++
>> >> >  include/drm/drm_edid.h| 28 ++---
>> >> >  3 files changed, 94 insertions(+), 33 deletions(-)
>> >> 
>> >> -- 
>> >> Jani Nikula, Intel
>> 
>> -- 
>> Jani Nikula, Intel

-- 
Jani Nikula, Intel


Re: [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements

2024-04-08 Thread Melissa Wen
On 04/08, Jani Nikula wrote:
> On Mon, 08 Apr 2024, Melissa Wen  wrote:
> > On 04/02, Jani Nikula wrote:
> >> On Thu, 21 Mar 2024, Jani Nikula  wrote:
> >> > Jani Nikula (4):
> >> >   drm/edid: add drm_edid_get_product_id()
> >> >   drm/edid: add drm_edid_print_product_id()
> >> >   drm/i915/bios: switch to struct drm_edid and struct
> >> > drm_edid_product_id
> >> >   drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
> >> 
> >> Ping for reviews please? This should be helpful in eradicating one class
> >> of drm_edid_raw() uses.
> >
> > Hi Jani,
> >
> > I took a look at the series. AFAIU your solution with
> > `drm_edid_product_id` mostly fits AMD display driver needs, except that
> > it needs the `product_code` split into two parts (like manufacturer
> > name) because the driver handles prod_code parts to configure a register
> > for audio, as in the path below:
> >
> > 1. 
> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c#L113
> > 2. 
> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/core/dc_stream.c#L90
> > 3. 
> > https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c#L873
> >
> > What do you think on keeping `prod_code` split into two part in
> > `drm_edid_product_id`?
> 
> I think having it as "__le16 product_code" is better and
> self-documenting. This is what the spec says it is, so why split it to
> two parts where you always need to wonder about the byte order?

I have no strong opinion, I was only thinking that two parts would make
this `edid_buf->prod_code[0] | edid_buf->prod_code[1] << 8` operation
more intuitive.

As you mentioned the currrent product_code format fits specs better, I
understand we can get the same result on amd with:
le16_to_cpu() --> split --> second part shift.

Anyway, it's certainly not a blocker. The series LGTM.

Acked-by: Melissa Wen 

> 
> This is how you'd use it:
> 
>   edid_caps->product_id = le16_to_cpu(id->product_code);
> 
> BR,
> Jani.
> 
> >
> > (cc'ing some AMD devs that might have a better understanding of this use 
> > case)
> >
> > Thanks a lot for addressing this pending issue!
> >
> > Melissa
> >
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> >
> >> >  drivers/gpu/drm/drm_edid.c| 50 +++
> >> >  drivers/gpu/drm/i915/display/intel_bios.c | 49 ++
> >> >  include/drm/drm_edid.h| 28 ++---
> >> >  3 files changed, 94 insertions(+), 33 deletions(-)
> >> 
> >> -- 
> >> Jani Nikula, Intel
> 
> -- 
> Jani Nikula, Intel


[PATCH v2 3/3] drm/915/lspcon: Reduce dmesg errors during lspcon_init failure

2024-04-08 Thread Ankit Nautiyal
Currently lspcon_resume calls lspcon_init and in case of failure we get
error messages from lspcon_init and then again from lspcon_resume.

Just have a single error message in lspcon_init.

v2: Add the relavant info with each error, and avoid mix of dbg and
error messages. (Jani)

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 16ee0dc179f7..84d953496098 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -680,23 +680,27 @@ bool lspcon_init(struct intel_digital_port *dig_port)
return false;
 
if (!lspcon_set_pcon_mode(lspcon)) {
-   drm_err(>drm, "LSPCON mode change to PCON failed\n");
+   drm_err(>drm, "Failure: LSPCON init on port %c, mode 
change to PCON failed\n",
+   port_name(dig_port->base.port));
return false;
}
 
if (drm_dp_read_dpcd_caps(_dp->aux, intel_dp->dpcd) != 0) {
-   drm_err(>drm, "LSPCON DPCD read failed\n");
+   drm_err(>drm, "Failure: LSPCON init on port %c, DPCD caps 
read failed\n",
+   port_name(dig_port->base.port));
return false;
}
 
if (!lspcon_detect_vendor(lspcon)) {
-   drm_err(>drm, "LSPCON vendor detection failed\n");
+   drm_err(>drm, "Failure: LSPCON init on port %c, vendor 
detection failed\n",
+   port_name(dig_port->base.port));
return false;
}
 
connector->ycbcr_420_allowed = true;
lspcon->active = true;
drm_dbg_kms(>drm, "Success: LSPCON init\n");
+
return true;
 }
 
@@ -718,13 +722,8 @@ void lspcon_resume(struct intel_digital_port *dig_port)
if (!intel_bios_encoder_is_lspcon(dig_port->base.devdata))
return;
 
-   if (!lspcon->active) {
-   if (!lspcon_init(dig_port)) {
-   drm_err(>drm, "LSPCON init failed on port %c\n",
-   port_name(dig_port->base.port));
-   return;
-   }
-   }
+   if (!lspcon->active && !lspcon_init(dig_port))
+   return;
 
expected_mode = lspcon_get_expected_mode(lspcon);
if (expected_mode == DRM_LSPCON_MODE_PCON)
-- 
2.40.1



Re: [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Melissa Wen  wrote:
> On 04/02, Jani Nikula wrote:
>> On Thu, 21 Mar 2024, Jani Nikula  wrote:
>> > Jani Nikula (4):
>> >   drm/edid: add drm_edid_get_product_id()
>> >   drm/edid: add drm_edid_print_product_id()
>> >   drm/i915/bios: switch to struct drm_edid and struct
>> > drm_edid_product_id
>> >   drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
>> 
>> Ping for reviews please? This should be helpful in eradicating one class
>> of drm_edid_raw() uses.
>
> Hi Jani,
>
> I took a look at the series. AFAIU your solution with
> `drm_edid_product_id` mostly fits AMD display driver needs, except that
> it needs the `product_code` split into two parts (like manufacturer
> name) because the driver handles prod_code parts to configure a register
> for audio, as in the path below:
>
> 1. 
> https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c#L113
> 2. 
> https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/core/dc_stream.c#L90
> 3. 
> https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c#L873
>
> What do you think on keeping `prod_code` split into two part in
> `drm_edid_product_id`?

I think having it as "__le16 product_code" is better and
self-documenting. This is what the spec says it is, so why split it to
two parts where you always need to wonder about the byte order?

This is how you'd use it:

edid_caps->product_id = le16_to_cpu(id->product_code);

BR,
Jani.

>
> (cc'ing some AMD devs that might have a better understanding of this use case)
>
> Thanks a lot for addressing this pending issue!
>
> Melissa
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> >
>> >  drivers/gpu/drm/drm_edid.c| 50 +++
>> >  drivers/gpu/drm/i915/display/intel_bios.c | 49 ++
>> >  include/drm/drm_edid.h| 28 ++---
>> >  3 files changed, 94 insertions(+), 33 deletions(-)
>> 
>> -- 
>> Jani Nikula, Intel

-- 
Jani Nikula, Intel


RE: [PATCH v2 20/25] drm/i915/bmg: BMG should re-use MTL's south display logic

2024-04-08 Thread Bhadane, Dnyaneshwar



> -Original Message-
> From: Intel-gfx  On Behalf Of
> Balasubramani Vivekanandan
> Sent: Wednesday, April 3, 2024 4:53 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Roper, Matthew D ; De Marchi, Lucas
> ; Vivekanandan, Balasubramani
> 
> Subject: [PATCH v2 20/25] drm/i915/bmg: BMG should re-use MTL's south
> display logic
> 
> From: Matt Roper 
> 
> Battlemage's south display is the same as Meteor Lake's, including the need to

  ^^^
Hi Bala,
We might want to rephrase this description a bit to fit in sentence.
> invert the HPD pins, which Lunar Lake does not need.
> 
> Signed-off-by: Matt Roper 
> Signed-off-by: Balasubramani Vivekanandan
> 
> ---

With this change LGTM.
Reviewed-by: Dnyaneshwar Bhadane 

Dnyaneshwar Bhadane

>  drivers/gpu/drm/i915/soc/intel_pch.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/soc/intel_pch.c
> b/drivers/gpu/drm/i915/soc/intel_pch.c
> index 3cad6dac06b0..542eea50093c 100644
> --- a/drivers/gpu/drm/i915/soc/intel_pch.c
> +++ b/drivers/gpu/drm/i915/soc/intel_pch.c
> @@ -218,10 +218,10 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
>   if (DISPLAY_VER(dev_priv) >= 20) {
>   dev_priv->pch_type = PCH_LNL;
>   return;
> - } else if (IS_METEORLAKE(dev_priv)) {
> + } else if (IS_BATTLEMAGE(dev_priv) || IS_METEORLAKE(dev_priv)) {
>   /*
>* Both north display and south display are on the SoC die.
> -  * The real PCH is uninvolved in display.
> +  * The real PCH (if it even exists) is uninvolved in display.
>*/
>   dev_priv->pch_type = PCH_MTL;
>   return;
> --
> 2.25.1



Re: [PATCH] drm/i915: use check_add_overflow() and drop local variants

2024-04-08 Thread Rodrigo Vivi
On Fri, Apr 05, 2024 at 11:26:25PM +0300, Jani Nikula wrote:
> Prefer common check_add_overflow() from overflow.h over the locally
> rolled versions of it. While check_add_overflow() does require a
> variable to assign to, unlike add_overflows_t(), it's still better than
> having multiple versions around.
> 
> Cc: Kees Cook 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_fb.c |  6 +++---
>  drivers/gpu/drm/i915/i915_utils.h   | 14 --
>  2 files changed, 3 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 3ea6470d6d92..86b443433e8b 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1106,7 +1106,7 @@ static int intel_fb_offset_to_xy(int *x, int *y,
>  {
>   struct drm_i915_private *i915 = to_i915(fb->dev);
>   unsigned int height;
> - u32 alignment;
> + u32 alignment, unused;
>  
>   if (DISPLAY_VER(i915) >= 12 &&
>   !intel_fb_needs_pot_stride_remap(to_intel_framebuffer(fb)) &&
> @@ -1128,8 +1128,8 @@ static int intel_fb_offset_to_xy(int *x, int *y,
>   height = ALIGN(height, intel_tile_height(fb, color_plane));
>  
>   /* Catch potential overflows early */
> - if (add_overflows_t(u32, mul_u32_u32(height, fb->pitches[color_plane]),
> - fb->offsets[color_plane])) {
> + if (check_add_overflow(mul_u32_u32(height, fb->pitches[color_plane]),
> +fb->offsets[color_plane], )) {
>   drm_dbg_kms(>drm,
>   "Bad offset 0x%08x or pitch %d for color plane 
> %d\n",
>   fb->offsets[color_plane], fb->pitches[color_plane],
> diff --git a/drivers/gpu/drm/i915/i915_utils.h 
> b/drivers/gpu/drm/i915/i915_utils.h
> index b45ef0560611..06ec6ceb61d5 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -73,20 +73,6 @@ bool i915_error_injected(void);
>   __i915_printk(i915, i915_error_injected() ? KERN_DEBUG : KERN_ERR, \
> fmt, ##__VA_ARGS__)
>  
> -#if defined(GCC_VERSION) && GCC_VERSION >= 7
> -#define add_overflows_t(T, A, B) \
> - __builtin_add_overflow_p((A), (B), (T)0)
> -#else
> -#define add_overflows_t(T, A, B) ({ \
> - typeof(A) a = (A); \
> - typeof(B) b = (B); \
> - (T)(a + b) < a; \
> -})
> -#endif
> -
> -#define add_overflows(A, B) \
> - add_overflows_t(typeof((A) + (B)), (A), (B))
> -
>  #define range_overflows(start, size, max) ({ \
>   typeof(start) start__ = (start); \
>   typeof(size) size__ = (size); \
> -- 
> 2.39.2
> 


[PATCH 2/2] drm/xe/display: remove compat raw reg read/write support

2024-04-08 Thread Jani Nikula
The i915 display code no longer uses these interfaces. Remove them.

Signed-off-by: Jani Nikula 
---
 .../drm/xe/compat-i915-headers/intel_uncore.h | 24 ---
 1 file changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h 
b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
index ef79793caa72..a672165ececf 100644
--- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
+++ b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
@@ -148,28 +148,4 @@ static inline void intel_uncore_write_notrace(struct 
intel_uncore *uncore,
xe_mmio_write32(__compat_uncore_to_gt(uncore), reg, val);
 }
 
-static inline void __iomem *intel_uncore_regs(struct intel_uncore *uncore)
-{
-   struct xe_device *xe = container_of(uncore, struct xe_device, uncore);
-
-   return xe_device_get_root_tile(xe)->mmio.regs;
-}
-
-/*
- * The raw_reg_{read,write} macros are intended as a micro-optimization for
- * interrupt handlers so that the pointer indirection on uncore->regs can
- * be computed once (and presumably cached in a register) instead of generating
- * extra load instructions for each MMIO access.
- *
- * Given that these macros are only intended for non-GSI interrupt registers
- * (and the goal is to avoid extra instructions generated by the compiler),
- * these macros do not account for uncore->gsi_offset.  Any caller that needs
- * to use these macros on a GSI register is responsible for adding the
- * appropriate GSI offset to the 'base' parameter.
- */
-#define raw_reg_read(base, reg) \
-   readl(base + i915_mmio_reg_offset(reg))
-#define raw_reg_write(base, reg, value) \
-   writel(value, base + i915_mmio_reg_offset(reg))
-
 #endif /* __INTEL_UNCORE_H__ */
-- 
2.39.2



[PATCH 1/2] drm/i915/display: remove small micro-optimizations in irq handling

2024-04-08 Thread Jani Nikula
The raw register reads/writes are there as micro-optimizations to avoid
multiple pointer indirections on uncore->regs. Presumably this is useful
when there are plenty of register reads/writes in the same
function. However, the display irq handling only has a few raw
reads/writes. Remove them for simplification.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_irq.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c 
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index f846c5b108b5..d4ae9139be39 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -1148,15 +1148,14 @@ void gen8_de_irq_handler(struct drm_i915_private 
*dev_priv, u32 master_ctl)
 
 u32 gen11_gu_misc_irq_ack(struct drm_i915_private *i915, const u32 master_ctl)
 {
-   void __iomem * const regs = intel_uncore_regs(>uncore);
u32 iir;
 
if (!(master_ctl & GEN11_GU_MISC_IRQ))
return 0;
 
-   iir = raw_reg_read(regs, GEN11_GU_MISC_IIR);
+   iir = intel_de_read(i915, GEN11_GU_MISC_IIR);
if (likely(iir))
-   raw_reg_write(regs, GEN11_GU_MISC_IIR, iir);
+   intel_de_write(i915, GEN11_GU_MISC_IIR, iir);
 
return iir;
 }
@@ -1169,18 +1168,18 @@ void gen11_gu_misc_irq_handler(struct drm_i915_private 
*i915, const u32 iir)
 
 void gen11_display_irq_handler(struct drm_i915_private *i915)
 {
-   void __iomem * const regs = intel_uncore_regs(>uncore);
-   const u32 disp_ctl = raw_reg_read(regs, GEN11_DISPLAY_INT_CTL);
+   u32 disp_ctl;
 
disable_rpm_wakeref_asserts(>runtime_pm);
/*
 * GEN11_DISPLAY_INT_CTL has same format as GEN8_MASTER_IRQ
 * for the display related bits.
 */
-   raw_reg_write(regs, GEN11_DISPLAY_INT_CTL, 0x0);
+   disp_ctl = intel_de_read(i915, GEN11_DISPLAY_INT_CTL);
+
+   intel_de_write(i915, GEN11_DISPLAY_INT_CTL, 0);
gen8_de_irq_handler(i915, disp_ctl);
-   raw_reg_write(regs, GEN11_DISPLAY_INT_CTL,
- GEN11_DISPLAY_IRQ_ENABLE);
+   intel_de_write(i915, GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
 
enable_rpm_wakeref_asserts(>runtime_pm);
 }
-- 
2.39.2



Re: [PATCH v2 7/7] drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 12:24:02PM +0300, Jani Nikula wrote:
> We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug
> printing of modes in any printk-formatted logging. Prefer them over
> drm_mode_debug_printmodeline().
> 
> This allows drm device specific logging of modes, in the right drm debug
> category, and inline with the rest of the logging instead of split to
> multiple lines.
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c  |  6 +++---
>  drivers/gpu/drm/drm_crtc.c |  6 +++---
>  drivers/gpu/drm/drm_crtc_helper.c  |  9 -
>  drivers/gpu/drm/drm_modes.c| 13 +
>  drivers/gpu/drm/drm_probe_helper.c |  3 ++-
>  5 files changed, 17 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d4..fc16fddee5c5 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -145,10 +145,10 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>>mode, blob->data);
>   if (ret) {
>   drm_dbg_atomic(crtc->dev,
> -"[CRTC:%d:%s] invalid mode (ret=%d, 
> status=%s):\n",
> +"[CRTC:%d:%s] invalid mode (%s, %pe): " 
> DRM_MODE_FMT "\n",
>  crtc->base.id, crtc->name,
> -ret, 
> drm_get_mode_status_name(state->mode.status));
> - drm_mode_debug_printmodeline(>mode);
> +
> drm_get_mode_status_name(state->mode.status),
> +ERR_PTR(ret), 
> DRM_MODE_ARG(>mode));
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b0a0e27e83eb..483969b84a30 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -775,9 +775,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>  
>   ret = drm_mode_convert_umode(dev, mode, _req->mode);
>   if (ret) {
> - drm_dbg_kms(dev, "Invalid mode (ret=%d, status=%s)\n",
> - ret, 
> drm_get_mode_status_name(mode->status));
> - drm_mode_debug_printmodeline(mode);
> + drm_dbg_kms(dev, "Invalid mode (%s, %pe): " 
> DRM_MODE_FMT "\n",
> + drm_get_mode_status_name(mode->status),
> + ERR_PTR(ret), DRM_MODE_ARG(mode));
>   goto out;
>   }
>  
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index af7ac9d9192a..0955f1c385dd 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -657,8 +657,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>   if (!drm_mode_equal(set->mode, >crtc->mode)) {
>   drm_dbg_kms(dev, "[CRTC:%d:%s] modes are different, full mode 
> set:\n",
>   set->crtc->base.id, set->crtc->name);
> - drm_mode_debug_printmodeline(>crtc->mode);
> - drm_mode_debug_printmodeline(set->mode);
> + drm_dbg_kms(dev, DRM_MODE_FMT "\n", 
> DRM_MODE_ARG(>crtc->mode));
> + drm_dbg_kms(dev, DRM_MODE_FMT "\n", DRM_MODE_ARG(set->mode));
>   mode_changed = true;
>   }
>  
> @@ -766,9 +766,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>  
>   if (mode_changed) {
>   if (drm_helper_crtc_in_use(set->crtc)) {
> - drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode 
> from userspace\n",
> - set->crtc->base.id, set->crtc->name);
> - drm_mode_debug_printmodeline(set->mode);
> + drm_dbg_kms(dev, "[CRTC:%d:%s] attempting to set mode 
> from userspace: " DRM_MODE_FMT "\n",
> + set->crtc->base.id, set->crtc->name, 
> DRM_MODE_ARG(set->mode));
>   set->crtc->primary->fb = set->fb;
>   if (!drm_crtc_helper_set_mode(set->crtc, set->mode,
> set->x, set->y,
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 408ee1b5e44d..2d8b0371619d 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1201,9 +1201,8 @@ int of_get_drm_display_mode(struct device_node *np,
>   if (bus_flags)
>   drm_bus_flags_from_videomode(, bus_flags);
>  
> - pr_debug("%pOF: got %dx%d display mode\n",
> - np, vm.hactive, vm.vactive);
> - drm_mode_debug_printmodeline(dmode);
> + pr_debug("%pOF: got %dx%d display mode: " 

Re: [PATCH v2 01/17] drm/i915: Update pipes in reverse order for bigjoiner

2024-04-08 Thread Ville Syrjälä
On Fri, Apr 05, 2024 at 12:56:52PM +, Murthy, Arun R wrote:
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of Ville
> > Syrjala
> > Sent: Friday, April 5, 2024 3:04 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH v2 01/17] drm/i915: Update pipes in reverse order for 
> > bigjoiner
> > 
> > From: Ville Syrjälä 
> > 
> > With bigjoiner the master crtc is the one that will send out the uapi 
> > event/etc.
> > We want that to happen after all the slaves are done, so let's try to do the
> > commits in reverse order so that the master comes last.
> > 
> > Even worse, the modeset helper will simply complete the commit on the slave
> > pipe immediately as it consider the crtc to be inactive (it can't see our
> > crtc_state->hw.active/etc.).
> > 
> > With regular sync updates this generally doesn't matter all that much as the
> > slave pipe should typically finish its work during the same frame as the 
> > master
> > pipe. However in case the slave pipe's commit slips into the next frame we 
> > end
> > up in a bit of trouble. This is most visible with either async flips 
> > (currently
> > disabled with bigjoiner exactly for this reason), and DSB gamma updates. 
> > With
> > DSB the problem happens because the DSB itself will wait until the next 
> > start
> > vblank before starting to execute. So if the master pipe already finished 
> > its
> > commit and the DSB on the slave pipe is still waiting for the next vblank 
> > we will
> > assume the DSB as gotten stuck and terminate it.
> > 
> > Reversing the commit order should ameliarate this for the most part as the
> > master pipe is guaranteed to start its commit after the slave pipe started. 
> > The
> > one thing that can still screw us over is the fact that we aren't 
> > necessarily going
> > to commit the pipes in the reverse order as the actual order is dictated by 
> > the
> > DDB overlap avoidance.
> > But that can only happen while other pipes are being enabled/disabled, and 
> > so
> > in the normal steady state we should be safe.
> > 
> > The full fix will involve making the commit machinery aware of the slave 
> > pipes
> > and not finish their commits prematurely. But that will involve a bit more 
> > work
> > than this. And this commit order reversal will still be beneficial to avoid
> > userspace getting an -EBUSY from the following page flip if the second 
> > pipe's
> > commit does stretch into the next frame.
> Can there be a possibility of seeing a flicker/corruption in that case?
> Also should this be added a TODO in the driver so that it will not be missed 
> out?

I have something typed up for this already. Just waiting for better
testing coverage to actually exercise it properly.

> 
> Above comment is for clarification and if a TODO is required, can be taken up 
> while merging the patch. Remaining logic looks good to me.
> Reviewed-by: Arun R Murthy 

Thanks. I've pushed patches 1-6.

> 
> Thanks and Regards,
> Arun R Murthy
> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
> > drivers/gpu/drm/i915/display/intel_display.h |  8 
> >  2 files changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a481c9218138..0086a7422e86 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6956,8 +6956,12 @@ static void skl_commit_modeset_enables(struct
> > intel_atomic_state *state)
> > intel_dbuf_mbus_pre_ddb_update(state);
> > 
> > while (update_pipes) {
> > -   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> > -   new_crtc_state, i) {
> > +   /*
> > +* Commit in reverse order to make bigjoiner master
> > +* send the uapi events after slaves are done.
> > +*/
> > +   for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> > old_crtc_state,
> > +   new_crtc_state, i) {
> > enum pipe pipe = crtc->pipe;
> > 
> > if ((update_pipes & BIT(pipe)) == 0) @@ -7036,7
> > +7040,11 @@ static void skl_commit_modeset_enables(struct
> > intel_atomic_state *state)
> > intel_pre_update_crtc(state, crtc);
> > }
> > 
> > -   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > +   /*
> > +* Commit in reverse order to make bigjoiner master
> > +* send the uapi events after slaves are done.
> > +*/
> > +   for_each_new_intel_crtc_in_state_reverse(state, crtc, new_crtc_state,
> > +i) {
> > enum pipe pipe = crtc->pipe;
> > 
> > if ((update_pipes & BIT(pipe)) == 0)
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> > 

Re: [PATCH v2 6/7] drm/crtc-helper: switch to drm device based logging and warns

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 12:24:01PM +0300, Jani Nikula wrote:
> Prefer drm device based drm_dbg_kms(), drm_err(), drm_WARN_ON() over
> DRM_DEBUG_KMS(), DRM_ERROR(), and WARN_ON(). Also update encoder,
> connector, and crtc logging to include the object id and name, where
> possible.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 95 +--
>  1 file changed, 52 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 2dafc39a27cb..af7ac9d9192a 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -110,15 +110,15 @@ bool drm_helper_encoder_in_use(struct drm_encoder 
> *encoder)
>   struct drm_connector_list_iter conn_iter;
>   struct drm_device *dev = encoder->dev;
>  
> - WARN_ON(drm_drv_uses_atomic_modeset(dev));
> + drm_WARN_ON(dev, drm_drv_uses_atomic_modeset(dev));
>  
>   /*
>* We can expect this mutex to be locked if we are not panicking.
>* Locking is currently fubar in the panic handler.
>*/
>   if (!oops_in_progress) {
> - WARN_ON(!mutex_is_locked(>mode_config.mutex));
> - 
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> + drm_WARN_ON(dev, !mutex_is_locked(>mode_config.mutex));
> + drm_WARN_ON(dev, 
> !drm_modeset_is_locked(>mode_config.connection_mutex));

Someone could do a followup to convert this stuff over to
lockdep_assert_held().

>   }
>  
>  
> @@ -150,14 +150,14 @@ bool drm_helper_crtc_in_use(struct drm_crtc *crtc)
>   struct drm_encoder *encoder;
>   struct drm_device *dev = crtc->dev;
>  
> - WARN_ON(drm_drv_uses_atomic_modeset(dev));
> + drm_WARN_ON(dev, drm_drv_uses_atomic_modeset(dev));
>  
>   /*
>* We can expect this mutex to be locked if we are not panicking.
>* Locking is currently fubar in the panic handler.
>*/
>   if (!oops_in_progress)
> - WARN_ON(!mutex_is_locked(>mode_config.mutex));
> + drm_WARN_ON(dev, !mutex_is_locked(>mode_config.mutex));
>  
>   drm_for_each_encoder(encoder, dev)
>   if (encoder->crtc == crtc && drm_helper_encoder_in_use(encoder))
> @@ -230,7 +230,7 @@ static void __drm_helper_disable_unused_functions(struct 
> drm_device *dev)
>   */
>  void drm_helper_disable_unused_functions(struct drm_device *dev)
>  {
> - WARN_ON(drm_drv_uses_atomic_modeset(dev));
> + drm_WARN_ON(dev, drm_drv_uses_atomic_modeset(dev));
>  
>   drm_modeset_lock_all(dev);
>   __drm_helper_disable_unused_functions(dev);
> @@ -294,7 +294,7 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   struct drm_encoder *encoder;
>   bool ret = true;
>  
> - WARN_ON(drm_drv_uses_atomic_modeset(dev));
> + drm_WARN_ON(dev, drm_drv_uses_atomic_modeset(dev));
>  
>   drm_warn_on_modeset_not_all_locked(dev);
>  
> @@ -338,7 +338,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (encoder_funcs->mode_fixup) {
>   if (!(ret = encoder_funcs->mode_fixup(encoder, mode,
> adjusted_mode))) {
> - DRM_DEBUG_KMS("Encoder fixup failed\n");
> + drm_dbg_kms(dev, "[ENCODER:%d:%s] mode fixup 
> failed\n",
> + encoder->base.id, encoder->name);
>   goto done;
>   }
>   }
> @@ -347,11 +348,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (crtc_funcs->mode_fixup) {
>   if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
>   adjusted_mode))) {
> - DRM_DEBUG_KMS("CRTC fixup failed\n");
> + drm_dbg_kms(dev, "[CRTC:%d:%s] mode fixup failed\n",
> + crtc->base.id, crtc->name);
>   goto done;
>   }
>   }
> - DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
> + drm_dbg_kms(dev, "[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>  
>   drm_mode_copy(>hwmode, adjusted_mode);
>  
> @@ -390,8 +392,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   if (!encoder_funcs)
>   continue;
>  
> - DRM_DEBUG_KMS("[ENCODER:%d:%s] set [MODE:%s]\n",
> - encoder->base.id, encoder->name, mode->name);
> + drm_dbg_kms(dev, "[ENCODER:%d:%s] set [MODE:%s]\n",
> + encoder->base.id, encoder->name, mode->name);
>   if (encoder_funcs->mode_set)
>   encoder_funcs->mode_set(encoder, mode, adjusted_mode);
>   }
> @@ -503,7 +505,7 @@ drm_connector_get_single_encoder(struct drm_connector 
> *connector)
>  {
>   struct drm_encoder *encoder;
>  

Re: [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements

2024-04-08 Thread Melissa Wen
On 04/02, Jani Nikula wrote:
> On Thu, 21 Mar 2024, Jani Nikula  wrote:
> > Jani Nikula (4):
> >   drm/edid: add drm_edid_get_product_id()
> >   drm/edid: add drm_edid_print_product_id()
> >   drm/i915/bios: switch to struct drm_edid and struct
> > drm_edid_product_id
> >   drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
> 
> Ping for reviews please? This should be helpful in eradicating one class
> of drm_edid_raw() uses.

Hi Jani,

I took a look at the series. AFAIU your solution with
`drm_edid_product_id` mostly fits AMD display driver needs, except that
it needs the `product_code` split into two parts (like manufacturer
name) because the driver handles prod_code parts to configure a register
for audio, as in the path below:

1. 
https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c#L113
2. 
https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/core/dc_stream.c#L90
3. 
https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c#L873

What do you think on keeping `prod_code` split into two part in
`drm_edid_product_id`?

(cc'ing some AMD devs that might have a better understanding of this use case)

Thanks a lot for addressing this pending issue!

Melissa

> 
> BR,
> Jani.
> 
> 
> >
> >  drivers/gpu/drm/drm_edid.c| 50 +++
> >  drivers/gpu/drm/i915/display/intel_bios.c | 49 ++
> >  include/drm/drm_edid.h| 28 ++---
> >  3 files changed, 94 insertions(+), 33 deletions(-)
> 
> -- 
> Jani Nikula, Intel


Re: [PATCH v7 6/6] drm/i915: Implement fbdev emulation as in-kernel client

2024-04-08 Thread Thomas Zimmermann

Hi

Am 05.04.24 um 10:34 schrieb Hogander, Jouni:
[...]
  
diff --git a/drivers/gpu/drm/i915/i915_driver.c

b/drivers/gpu/drm/i915/i915_driver.c
index e0f13c62a1832..69178b73845e1 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -816,6 +816,8 @@ int i915_driver_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
  
 i915->do_release = true;
  
+   intel_fbdev_setup(i915);

+

This doesn't work for Xe. I propose you move it to
drivers/gpu/drm/i915/display/intel_display_dirver.c:intel_display_drive
r_probe? Otherwise patch looks ok to me.


The client setup needs to run after the DRM device has been registered, 
so _probe is too early. intel_display_driver_register() looks like a 
possible place to put this. That would be symmetric to unregistering in 
intel_display_driver_unregister().


Best regards
Thomas



BR,

Jouni Högander



 return 0;
  
  out_cleanup_gem:

diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index cdbc3f04c80a7..ca5cbe1d8a03b 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -214,9 +214,7 @@ void xe_display_fini(struct xe_device *xe)
 if (!xe->info.enable_display)
 return;
  
-   /* poll work can call into fbdev, hence clean that up

afterwards */
 intel_hpd_poll_fini(xe);
-   intel_fbdev_fini(xe);
  
 intel_hdcp_component_fini(xe);

 intel_audio_deinit(xe);


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



Re: [PATCH] drm/i915/pps: move pps debugfs file to intel_pps.c

2024-04-08 Thread Ville Syrjälä
On Mon, Apr 08, 2024 at 12:43:57PM +0300, Jani Nikula wrote:
> Continue with placing debugfs next to the implementation.
> 
> Signed-off-by: Jani Nikula 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 27 ++--
>  drivers/gpu/drm/i915/display/intel_pps.c  | 32 +++
>  drivers/gpu/drm/i915/display/intel_pps.h  |  2 ++
>  3 files changed, 36 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 5235f8758ef1..0feffe8d4e45 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -31,6 +31,7 @@
>  #include "intel_hdmi.h"
>  #include "intel_hotplug.h"
>  #include "intel_panel.h"
> +#include "intel_pps.h"
>  #include "intel_psr.h"
>  #include "intel_psr_regs.h"
>  #include "intel_wm.h"
> @@ -1095,27 +1096,6 @@ void intel_display_debugfs_register(struct 
> drm_i915_private *i915)
>   intel_display_debugfs_params(i915);
>  }
>  
> -static int i915_panel_show(struct seq_file *m, void *data)
> -{
> - struct intel_connector *connector = m->private;
> - struct intel_dp *intel_dp = intel_attached_dp(connector);
> -
> - if (connector->base.status != connector_status_connected)
> - return -ENODEV;
> -
> - seq_printf(m, "Panel power up delay: %d\n",
> -intel_dp->pps.panel_power_up_delay);
> - seq_printf(m, "Panel power down delay: %d\n",
> -intel_dp->pps.panel_power_down_delay);
> - seq_printf(m, "Backlight on delay: %d\n",
> -intel_dp->pps.backlight_on_delay);
> - seq_printf(m, "Backlight off delay: %d\n",
> -intel_dp->pps.backlight_off_delay);
> -
> - return 0;
> -}
> -DEFINE_SHOW_ATTRIBUTE(i915_panel);
> -
>  static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
>  {
>   struct intel_connector *connector = m->private;
> @@ -1560,12 +1540,9 @@ void intel_connector_debugfs_add(struct 
> intel_connector *connector)
>   return;
>  
>   intel_drrs_connector_debugfs_add(connector);
> + intel_pps_connector_debugfs_add(connector);
>   intel_psr_connector_debugfs_add(connector);
>  
> - if (connector_type == DRM_MODE_CONNECTOR_eDP)
> - debugfs_create_file("i915_panel_timings", 0444, root,
> - connector, _panel_fops);
> -
>   if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>   connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>   connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index b5d9920f8341..88a44d93f82b 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1670,6 +1670,38 @@ void intel_pps_setup(struct drm_i915_private *i915)
>   i915->display.pps.mmio_base = PPS_BASE;
>  }
>  
> +static int intel_pps_show(struct seq_file *m, void *data)
> +{
> + struct intel_connector *connector = m->private;
> + struct intel_dp *intel_dp = intel_attached_dp(connector);
> +
> + if (connector->base.status != connector_status_connected)
> + return -ENODEV;

That check seems completely pointless. Could be removed as a
followup.

Hmm. The other question that comes to mind is whether anyone has
ever used this file? I for sure have not. So I'm wondering if we
could just nuke the whole thing?

Anyways
Reviewed-by: Ville Syrjälä 

> +
> + seq_printf(m, "Panel power up delay: %d\n",
> +intel_dp->pps.panel_power_up_delay);
> + seq_printf(m, "Panel power down delay: %d\n",
> +intel_dp->pps.panel_power_down_delay);
> + seq_printf(m, "Backlight on delay: %d\n",
> +intel_dp->pps.backlight_on_delay);
> + seq_printf(m, "Backlight off delay: %d\n",
> +intel_dp->pps.backlight_off_delay);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(intel_pps);
> +
> +void intel_pps_connector_debugfs_add(struct intel_connector *connector)
> +{
> + struct dentry *root = connector->base.debugfs_entry;
> + int connector_type = connector->base.connector_type;
> +
> + if (connector_type == DRM_MODE_CONNECTOR_eDP)
> + debugfs_create_file("i915_panel_timings", 0444, root,
> + connector, _pps_fops);
> +
> +}
> +
>  void assert_pps_unlocked(struct drm_i915_private *dev_priv, enum pipe pipe)
>  {
>   i915_reg_t pp_reg;
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.h 
> b/drivers/gpu/drm/i915/display/intel_pps.h
> index a2c2467e3c22..07ef96ca8da2 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.h
> +++ b/drivers/gpu/drm/i915/display/intel_pps.h
> @@ -51,6 +51,8 @@ void vlv_pps_init(struct intel_encoder *encoder,
>  void intel_pps_unlock_regs_wa(struct drm_i915_private *i915);
>  

Re: [PATCH v7 1/6] drm/client: Export drm_client_dev_unregister()

2024-04-08 Thread Thomas Zimmermann

Hi

Am 08.03.24 um 16:49 schrieb Rodrigo Vivi:

On Fri, Mar 01, 2024 at 02:42:54PM +0100, Thomas Zimmermann wrote:

Export drm_client_dev_unregister() for use by the i915 driver. The
driver does not use drm_dev_unregister(),

Perhaps we should make i915 to call for the drm_dev_unregister since it calls
for drm_dev_register?


Not that I disagree, but this appears to be a separate change unrelated 
to fbdev support.


Best regards
Thomas




so it has to clean up the
in-kernel DRM clients by itself.

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/drm_client.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9403b3f576f7b..3d4f8b77d0789 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -172,6 +172,18 @@ void drm_client_release(struct drm_client_dev *client)
  }
  EXPORT_SYMBOL(drm_client_release);
  
+/**

+ * drm_client_dev_unregister - Unregister clients
+ * @dev: DRM device
+ *
+ * This function releases all clients by calling each client's
+ * _client_funcs.unregister callback. The callback function
+ * is responsibe for releaseing all resources including the client
+ * itself.
+ *
+ * The helper drm_dev_unregister() calls this function. Drivers
+ * that use it don't need to call this function themselves.
+ */
  void drm_client_dev_unregister(struct drm_device *dev)
  {
struct drm_client_dev *client, *tmp;
@@ -191,6 +203,7 @@ void drm_client_dev_unregister(struct drm_device *dev)
}
mutex_unlock(>clientlist_mutex);
  }
+EXPORT_SYMBOL(drm_client_dev_unregister);
  
  /**

   * drm_client_dev_hotplug - Send hotplug event to clients
--
2.43.2



--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



Re: [PATCH v2 0/7] drm: debug logging improvements

2024-04-08 Thread Thomas Zimmermann

Hi

Reviewed-by: Thomas Zimmermann 

for patches 5 to 7.

Best regards
Thomas

Am 08.04.24 um 11:23 schrieb Jani Nikula:

v2 of [1], dropping drm_mode_print() stuff altogether, and switching to
DRM_MODE_FMT/DRM_MODE_ARG() in a separate patch. Also add a few more drm
device based logging conversion patches, so the last patch makes more sense.

BR,
Jani.

[1] https://patchwork.freedesktop.org/series/130881/

Jani Nikula (7):
   drm/probe-helper: switch to drm device based logging
   drm/modes: switch to drm device based error logging
   drm/sysfs: switch to drm device based logging
   drm/client: switch to drm device based logging, and more
   drm/crtc: switch to drm device based logging
   drm/crtc-helper: switch to drm device based logging and warns
   drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()

  drivers/gpu/drm/drm_atomic_uapi.c|   6 +-
  drivers/gpu/drm/drm_client_modeset.c | 129 +++
  drivers/gpu/drm/drm_crtc.c   |  38 
  drivers/gpu/drm/drm_crtc_helper.c| 100 +++--
  drivers/gpu/drm/drm_modes.c  |  40 -
  drivers/gpu/drm/drm_probe_helper.c   |  39 
  drivers/gpu/drm/drm_sysfs.c  |  20 ++---
  7 files changed, 193 insertions(+), 179 deletions(-)



--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



Re: [PATCH v10 2/6] drm/i915/display: Extract code required to calculate max qgv/psf gv point

2024-04-08 Thread Govindapillai, Vinod
On Mon, 2024-04-08 at 11:32 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Apr 05, 2024 at 02:35:29PM +0300, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy 
> > 
> > We need that in order to force disable SAGV in next patch.
> > Also it is beneficial to separate that code, as in majority cases,
> > when SAGV is enabled, we don't even need those calculations.
> > Also we probably need to determine max PSF GV point as well, however
> > currently we don't do that when we disable SAGV, which might be
> > actually causing some issues in that case.
> > 
> > v2: - Introduce helper adl_qgv_bw(counterpart to adl_psf_bw)
> >   (Ville Syrjälä)
> >     - Don't restrict psf gv points for SAGV disable case
> >   (Ville Syrjälä)
> > v3: - Update icl_max_bw_qgv_point_mask to return max qgv point
> >   mask (Vinod)
> > v4: - Minor changes in icl_find_qgv_points (Vinod)
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > Signed-off-by: Vinod Govindapillai 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bw.c | 80 +++--
> >  1 file changed, 50 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 77886cc21211..c00094e5f11c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -661,6 +661,22 @@ static unsigned int adl_psf_bw(struct drm_i915_private 
> > *dev_priv,
> > return bi->psf_bw[psf_gv_point];
> >  }
> >  
> > +static unsigned int icl_qgv_bw(struct drm_i915_private *i915,
> > +  int num_active_planes, int qgv_point)
> > +{
> > +   unsigned int idx;
> > +
> > +   if (DISPLAY_VER(i915) >= 12)
> > +   idx = tgl_max_bw_index(i915, num_active_planes, qgv_point);
> > +   else
> > +   idx = icl_max_bw_index(i915, num_active_planes, qgv_point);
> > +
> > +   if (idx >= ARRAY_SIZE(i915->display.bw.max))
> > +   return 0;
> > +
> > +   return i915->display.bw.max[idx].deratedbw[qgv_point];
> > +}
> > +
> >  void intel_bw_init_hw(struct drm_i915_private *dev_priv)
> >  {
> > if (!HAS_DISPLAY(dev_priv))
> > @@ -806,6 +822,35 @@ intel_atomic_get_bw_state(struct intel_atomic_state 
> > *state)
> > return to_intel_bw_state(bw_state);
> >  }
> >  
> > +static unsigned int icl_max_bw_qgv_point_mask(struct drm_i915_private 
> > *i915,
> > + int num_active_planes)
> > +{
> > +   unsigned int num_qgv_points = 
> > i915->display.bw.max[0].num_qgv_points;
> > +   unsigned int max_bw_point_mask = 0;
> > +   unsigned int max_bw = 0;
> > +   int i;
> > +
> > +   for (i = 0; i < num_qgv_points; i++) {
> > +   unsigned int max_data_rate =
> > +   icl_qgv_bw(i915, num_active_planes, i);
> > +
> > +   /*
> > +    * We need to know which qgv point gives us
> > +    * maximum bandwidth in order to disable SAGV
> > +    * if we find that we exceed SAGV block time
> > +    * with watermarks. By that moment we already
> > +    * have those, as it is calculated earlier in
> > +    * intel_atomic_check,
> > +    */
> > +   if (max_data_rate > max_bw) {
> > +   max_bw_point_mask = BIT(i);
> > +   max_bw = max_data_rate;
> > +   }
> > +   }
> > +
> > +   return max_bw_point_mask;
> > +}
> > +
> 
> Wondering, why we just don't call it "max_bw_point", of course "mask"
> could be applied to single point as well, however in most cases it still
> kind of implies that there are few of those, however we always find
> a single one here.

Okay.. For QGV max point, indeed we are finding point with max bw. So the name 
can be changed. I
think it can be changed before merging instead of floating another version - 
well if we these
patches can be RB-ed 

Vinod

> 
> Stan
> 
> >  static int mtl_find_qgv_points(struct drm_i915_private *i915,
> >    unsigned int data_rate,
> >    unsigned int num_active_planes,
> > @@ -883,8 +928,6 @@ static int icl_find_qgv_points(struct drm_i915_private 
> > *i915,
> >    const struct intel_bw_state *old_bw_state,
> >    struct intel_bw_state *new_bw_state)
> >  {
> > -   unsigned int max_bw_point = 0;
> > -   unsigned int max_bw = 0;
> > unsigned int num_psf_gv_points = 
> > i915->display.bw.max[0].num_psf_gv_points;
> > unsigned int num_qgv_points = 
> > i915->display.bw.max[0].num_qgv_points;
> > u16 psf_points = 0;
> > @@ -897,31 +940,8 @@ static int icl_find_qgv_points(struct drm_i915_private 
> > *i915,
> > return ret;
> >  
> > for (i = 0; i < num_qgv_points; i++) {
> > -   unsigned int idx;
> > -  

Re: [PATCH v10 5/6] drm/i915/display: handle systems with duplicate psf gv points

2024-04-08 Thread Govindapillai, Vinod
On Mon, 2024-04-08 at 11:29 +0300, Lisovskiy, Stanislav wrote:
> On Fri, Apr 05, 2024 at 02:35:32PM +0300, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy 
> > 
> > There could be multiple qgv and psf gv points with similar values.
> > Apparently pcode's handling og psf and qgv points are different. For
> > qgv case, pcode sets whatever is asked by the driver. But in case
> > of psf gv points, it compares the bw from points before setting the
> > mask. This can cause problems in scenarios where we have to disable
> > sagv by setting the highest bw point and there could be multiple
> > points with highest bw. So to set the maximum psf gv point, find
> > out all the points with the highest bw and set all together.
> > 
> > v1: - use the same treatment to qgv points as well (Vinod)
> > 
> > v2: - pcode confirms that for qgv points, it sets whatever the
> >   driver sets (Vinod)
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > Signed-off-by: Vinod Govindapillai 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bw.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 5f4f93524bef..6fb228a1a28f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -874,6 +874,8 @@ static unsigned int icl_max_bw_psf_gv_point_mask(struct 
> > drm_i915_private
> > *i915)
> > if (max_data_rate > max_bw) {
> > max_bw_point_mask = BIT(i);
> > max_bw = max_data_rate;
> > +   } else if (max_data_rate == max_bw) {
> > +   max_bw_point_mask |= BIT(i);
> 
> So we just came back to where we started. Wondering still, why it even 
> bothers to expose
> two equal PSF GV points. Not only having duplicate points doesn't make much 
> sense for 
> the driver(since the BW they provide is the same), but also requires some 
> additional
> logic on top to handle those.

Yes. Unfortunately this is what pcode expects for psf gv points. (Please have a 
look at the email
thread with the pcode team/Art etc.)

For qgv, it sets whatever the driver sets!

BR
Vinod
> 
> Stan
> 
> > }
> > }
> >  
> > -- 
> > 2.34.1
> > 



Re: [PATCH 3/3] drm/915/lspcon: Reduce dmesg errors during lspcon_init failure

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Ankit Nautiyal  wrote:
> Currently lspcon_resume calls lspcon_init and in case of failure we get
> error messages from lspcon_init and then again from lspcon_resume.
>
> Just have a single error message in lspcon_init and convert all other
> errors as dbg messages.
>
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 27 +++--
>  1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 16ee0dc179f7..3c3bc80e32f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -680,24 +680,30 @@ bool lspcon_init(struct intel_digital_port *dig_port)
>   return false;
>  
>   if (!lspcon_set_pcon_mode(lspcon)) {
> - drm_err(>drm, "LSPCON mode change to PCON failed\n");
> - return false;
> + drm_dbg_kms(>drm, "LSPCON mode change to PCON failed\n");
> + goto lspcon_init_failed;
>   }
>  
>   if (drm_dp_read_dpcd_caps(_dp->aux, intel_dp->dpcd) != 0) {
> - drm_err(>drm, "LSPCON DPCD read failed\n");
> - return false;
> + drm_dbg_kms(>drm, "LSPCON DPCD read failed\n");
> + goto lspcon_init_failed;
>   }
>  
>   if (!lspcon_detect_vendor(lspcon)) {
> - drm_err(>drm, "LSPCON vendor detection failed\n");
> - return false;
> + drm_dbg_kms(>drm, "LSPCON vendor detection failed\n");
> + goto lspcon_init_failed;

Why not just keep all of the above as drm_err(), adding all the relevant
info there...

>   }
>  
>   connector->ycbcr_420_allowed = true;
>   lspcon->active = true;
>   drm_dbg_kms(>drm, "Success: LSPCON init\n");
>   return true;
> +
> +lspcon_init_failed:
> + drm_err(>drm, "LSPCON init failed on port %c\n",
> + port_name(dig_port->base.port));
> +
> + return false;

And dropping this change altogheter? Why would we need both the debug
message and the error? Just have one error message?

With that change,

Reviewed-by: Jani Nikula 


>  }
>  
>  u32 intel_lspcon_infoframes_enabled(struct intel_encoder *encoder,
> @@ -718,13 +724,8 @@ void lspcon_resume(struct intel_digital_port *dig_port)
>   if (!intel_bios_encoder_is_lspcon(dig_port->base.devdata))
>   return;
>  
> - if (!lspcon->active) {
> - if (!lspcon_init(dig_port)) {
> - drm_err(>drm, "LSPCON init failed on port %c\n",
> - port_name(dig_port->base.port));
> - return;
> - }
> - }
> + if (!lspcon->active && !lspcon_init(dig_port))
> + return;
>  
>   expected_mode = lspcon_get_expected_mode(lspcon);
>   if (expected_mode == DRM_LSPCON_MODE_PCON)

-- 
Jani Nikula, Intel


Re: [PATCH 2/3] drm/i915/lspcon: Separate out function to set pcon mode

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Ankit Nautiyal  wrote:
> Currently lspcon_probe tries to probe for LSPCON and also set the
> PCON mode on the LSPCON. If any of these fails, it returns fail
> resulting in error message. So even if there is nothing connected to
> LSPCON port we get error messages for probe failure.
>
> Separate out the function to set pcon mode from the lspcon_probe
> function, and show the error message only when the set pcon mode fails.
> Do not show error message if no LSPCON is detected.
>
> Signed-off-by: Ankit Nautiyal 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 24 ++---
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 36e8d9fb2bbb..16ee0dc179f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -277,17 +277,22 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
>   drm_dbg_kms(>drm, "LSPCON detected\n");
>   lspcon->mode = lspcon_wait_mode(lspcon, expected_mode);
>  
> + return true;
> +}
> +
> +static bool lspcon_set_pcon_mode(struct intel_lspcon *lspcon)
> +{
>   /*
>* In the SW state machine, lets Put LSPCON in PCON mode only.
>* In this way, it will work with both HDMI 1.4 sinks as well as HDMI
>* 2.0 sinks.
>*/
> - if (lspcon->mode != DRM_LSPCON_MODE_PCON) {
> - if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
> - drm_err(>drm, "LSPCON mode change to PCON 
> failed\n");
> - return false;
> - }
> - }
> + if (lspcon->mode == DRM_LSPCON_MODE_PCON)
> + return true;
> +
> + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0)
> + return false;
> +
>   return true;
>  }
>  
> @@ -671,8 +676,11 @@ bool lspcon_init(struct intel_digital_port *dig_port)
>   lspcon->active = false;
>   lspcon->mode = DRM_LSPCON_MODE_INVALID;
>  
> - if (!lspcon_probe(lspcon)) {
> - drm_err(>drm, "Failed to probe lspcon\n");
> + if (!lspcon_probe(lspcon))
> + return false;
> +
> + if (!lspcon_set_pcon_mode(lspcon)) {
> + drm_err(>drm, "LSPCON mode change to PCON failed\n");
>   return false;
>   }

-- 
Jani Nikula, Intel


Re: [PATCH 1/3] drm/i915/lspcon: Separate out function to get expected mode

2024-04-08 Thread Jani Nikula
On Mon, 08 Apr 2024, Ankit Nautiyal  wrote:
> Reuse code to wake native aux channel and get the expected lspcon
> mode.
>
> Signed-off-by: Ankit Nautiyal 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 1d048fa98561..36e8d9fb2bbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -240,6 +240,13 @@ static bool lspcon_wake_native_aux_ch(struct 
> intel_lspcon *lspcon)
>   return true;
>  }
>  
> +static
> +enum drm_lspcon_mode lspcon_get_expected_mode(struct intel_lspcon *lspcon)
> +{
> + return lspcon_wake_native_aux_ch(lspcon) ?
> + DRM_LSPCON_MODE_PCON : DRM_LSPCON_MODE_LS;
> +}
> +
>  static bool lspcon_probe(struct intel_lspcon *lspcon)
>  {
>   int retry;
> @@ -249,9 +256,7 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
>   struct i2c_adapter *ddc = _dp->aux.ddc;
>   enum drm_lspcon_mode expected_mode;
>  
> - expected_mode = lspcon_wake_native_aux_ch(lspcon) ?
> - DRM_LSPCON_MODE_PCON : DRM_LSPCON_MODE_LS;
> -
> + expected_mode = lspcon_get_expected_mode(lspcon);
>   /* Lets probe the adaptor and check its type */
>   for (retry = 0; retry < 6; retry++) {
>   if (retry)
> @@ -713,12 +718,9 @@ void lspcon_resume(struct intel_digital_port *dig_port)
>   }
>   }
>  
> - if (lspcon_wake_native_aux_ch(lspcon)) {
> - expected_mode = DRM_LSPCON_MODE_PCON;
> + expected_mode = lspcon_get_expected_mode(lspcon);
> + if (expected_mode == DRM_LSPCON_MODE_PCON)
>   lspcon_resume_in_pcon_wa(lspcon);
> - } else {
> - expected_mode = DRM_LSPCON_MODE_LS;
> - }
>  
>   if (lspcon_wait_mode(lspcon, expected_mode) == DRM_LSPCON_MODE_PCON)
>   return;

-- 
Jani Nikula, Intel


[PATCH] drm/i915/pps: move pps debugfs file to intel_pps.c

2024-04-08 Thread Jani Nikula
Continue with placing debugfs next to the implementation.

Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_display_debugfs.c  | 27 ++--
 drivers/gpu/drm/i915/display/intel_pps.c  | 32 +++
 drivers/gpu/drm/i915/display/intel_pps.h  |  2 ++
 3 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 5235f8758ef1..0feffe8d4e45 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -31,6 +31,7 @@
 #include "intel_hdmi.h"
 #include "intel_hotplug.h"
 #include "intel_panel.h"
+#include "intel_pps.h"
 #include "intel_psr.h"
 #include "intel_psr_regs.h"
 #include "intel_wm.h"
@@ -1095,27 +1096,6 @@ void intel_display_debugfs_register(struct 
drm_i915_private *i915)
intel_display_debugfs_params(i915);
 }
 
-static int i915_panel_show(struct seq_file *m, void *data)
-{
-   struct intel_connector *connector = m->private;
-   struct intel_dp *intel_dp = intel_attached_dp(connector);
-
-   if (connector->base.status != connector_status_connected)
-   return -ENODEV;
-
-   seq_printf(m, "Panel power up delay: %d\n",
-  intel_dp->pps.panel_power_up_delay);
-   seq_printf(m, "Panel power down delay: %d\n",
-  intel_dp->pps.panel_power_down_delay);
-   seq_printf(m, "Backlight on delay: %d\n",
-  intel_dp->pps.backlight_on_delay);
-   seq_printf(m, "Backlight off delay: %d\n",
-  intel_dp->pps.backlight_off_delay);
-
-   return 0;
-}
-DEFINE_SHOW_ATTRIBUTE(i915_panel);
-
 static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
 {
struct intel_connector *connector = m->private;
@@ -1560,12 +1540,9 @@ void intel_connector_debugfs_add(struct intel_connector 
*connector)
return;
 
intel_drrs_connector_debugfs_add(connector);
+   intel_pps_connector_debugfs_add(connector);
intel_psr_connector_debugfs_add(connector);
 
-   if (connector_type == DRM_MODE_CONNECTOR_eDP)
-   debugfs_create_file("i915_panel_timings", 0444, root,
-   connector, _panel_fops);
-
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_HDMIB) {
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index b5d9920f8341..88a44d93f82b 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1670,6 +1670,38 @@ void intel_pps_setup(struct drm_i915_private *i915)
i915->display.pps.mmio_base = PPS_BASE;
 }
 
+static int intel_pps_show(struct seq_file *m, void *data)
+{
+   struct intel_connector *connector = m->private;
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+
+   if (connector->base.status != connector_status_connected)
+   return -ENODEV;
+
+   seq_printf(m, "Panel power up delay: %d\n",
+  intel_dp->pps.panel_power_up_delay);
+   seq_printf(m, "Panel power down delay: %d\n",
+  intel_dp->pps.panel_power_down_delay);
+   seq_printf(m, "Backlight on delay: %d\n",
+  intel_dp->pps.backlight_on_delay);
+   seq_printf(m, "Backlight off delay: %d\n",
+  intel_dp->pps.backlight_off_delay);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(intel_pps);
+
+void intel_pps_connector_debugfs_add(struct intel_connector *connector)
+{
+   struct dentry *root = connector->base.debugfs_entry;
+   int connector_type = connector->base.connector_type;
+
+   if (connector_type == DRM_MODE_CONNECTOR_eDP)
+   debugfs_create_file("i915_panel_timings", 0444, root,
+   connector, _pps_fops);
+
+}
+
 void assert_pps_unlocked(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
i915_reg_t pp_reg;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.h 
b/drivers/gpu/drm/i915/display/intel_pps.h
index a2c2467e3c22..07ef96ca8da2 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.h
+++ b/drivers/gpu/drm/i915/display/intel_pps.h
@@ -51,6 +51,8 @@ void vlv_pps_init(struct intel_encoder *encoder,
 void intel_pps_unlock_regs_wa(struct drm_i915_private *i915);
 void intel_pps_setup(struct drm_i915_private *i915);
 
+void intel_pps_connector_debugfs_add(struct intel_connector *connector);
+
 void assert_pps_unlocked(struct drm_i915_private *i915, enum pipe pipe);
 
 #endif /* __INTEL_PPS_H__ */
-- 
2.39.2



  1   2   >