date:20221108

== Series Details ==

Series: drm/i915/display: mode clock check related to max dotclk frequency
URL   : https://patchwork.freedesktop.org/series/110686/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12358 -> Patchwork_110686v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 38)
--

  Additional (1): fi-hsw-4770 
  Missing(4): fi-ctg-p8600 bat-dg2-8 fi-ilk-m540 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 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-adlm-1}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-adlm-1/igt@i915_selftest@live@gt_mocs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/bat-adlm-1/igt@i915_selftest@live@gt_mocs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3012])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [PASS][6] -> [DMESG-WARN][7] ([i915#7077])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][8] ([i915#4785])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

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

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][14] ([i915#7073]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2:  [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110686v1/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][20] ([i915#5278]) -> [PASS][21]
   [20]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: mode clock check related to max dotclk frequency

== Series Details ==

Series: drm/i915/display: mode clock check related to max dotclk frequency
URL   : https://patchwork.freedesktop.org/series/110686/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup

== Series Details ==

Series: series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part 
of pps_get_register() cleanup
URL   : https://patchwork.freedesktop.org/series/110678/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12356_full -> Patchwork_110678v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] [PATCH] drm/i915/display: mode clock check related to max dotclk frequency

2022-11-08 Thread Nischal Varide

A check on mode->clock to see if is greater than i915->max_dotclk_freq
or greater than 2 * (i915_max_dotclk_freq) in case of big-joiner and
return an -EINVAL in both the cases

Signed-off-by: Nischal Varide 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7400d6b4c587..813f4c369dda 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -995,6 +995,10 @@ intel_dp_mode_valid(struct drm_connector *_connector,
bigjoiner = true;
max_dotclk *= 2;
}
+
+   if (mode->clock > max_dotclk)
+   return -EINVAL;
+
if (target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
 
-- 
2.36.0

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rps: Query min/max freq from FW when displaying in sysfs

== Series Details ==

Series: drm/i915/rps: Query min/max freq from FW when displaying in sysfs
URL   : https://patchwork.freedesktop.org/series/110685/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12358 -> Patchwork_110685v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Additional (2): fi-hsw-4770 bat-adls-5 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@basic-rte:
- {bat-adln-1}:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-adln-1/igt@i915_pm_...@basic-rte.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/bat-adln-1/igt@i915_pm_...@basic-rte.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3012])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@perf_pmu@frequency:
- fi-ilk-650: NOTRUN -> [SKIP][9] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-ilk-650/igt@perf_...@frequency.html
- fi-blb-e6850:   NOTRUN -> [SKIP][10] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-blb-e6850/igt@perf_...@frequency.html
- fi-bsw-nick:NOTRUN -> [SKIP][11] ([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-bsw-nick/igt@perf_...@frequency.html
- fi-bsw-kefka:   NOTRUN -> [SKIP][12] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-bsw-kefka/igt@perf_...@frequency.html
- fi-elk-e7500:   NOTRUN -> [SKIP][13] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-elk-e7500/igt@perf_...@frequency.html
- fi-pnv-d510:NOTRUN -> [SKIP][14] ([fdo#109271])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-pnv-d510/igt@perf_...@frequency.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][15] ([i915#7073]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

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

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [WARN][19] ([i915#7346]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2:  [DMESG-FAIL][21] ([i915#5334]) ->

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines (rev2)

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that 
have VCS engines (rev2)
URL   : https://patchwork.freedesktop.org/series/110646/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12356_full -> Patchwork_110646v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@debugfs-reader:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12356/shard-tglb7/igt@i915_susp...@debugfs-reader.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/shard-tglb3/igt@i915_susp...@debugfs-reader.html

  * igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12356/shard-iclb3/igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/shard-iclb6/igt@kms_ccs@pipe-c-crc-primary-rotation-180-yf_tiled_ccs.html

  * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1:
- shard-skl:  NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/shard-skl9/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

2022-11-08 Thread Tian, Kevin

> From: Jason Gunthorpe 
> Sent: Wednesday, November 9, 2022 9:05 AM
> 
> On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote:
> 
> > > > So why exactly isn't this an issue for VDPA?  Are we just burying our
> > > > head in the sand that such platforms exists and can still be useful
> > > > given the appropriate risk vs reward trade-off?
> > >
> > > Simply that nobody has asked for it, and might never ask for it. This
> > > is all support for old platforms, and there just doesn't seem to be a
> > > "real" use case for very new (and actually rare) NIC hardware stuck
> > > into ancient platforms with this security problem.
> >
> > vIOMMU support for interrupt remapping is relatively new, the nesting
> > case is important as well.
> 
> This is where we got hit. In the end we fixed the qemu..

but the point is that old qemu could have a much longer lifespan than
old platforms then when running newer kernel which supports vdpa
on old qemu the same tradeoff consideration is then not vfio specific...

> > It's certainly not acceptable in the latest proposal, iommufd consumes
> > an option set by another module and when that module goes away, so
> does
> > any claim of compatibility.  The code becomes dead and the feature not
> > present.  The option doesn't belong on the vfio module.  Do we need a
> > vfio-iommufd module to host it?  Thanks,
> 
> I don't know, as I said in the other email, these little things need
> work and discussion to resolve. We need to recheck the security stuff
> against the 2022 kernel where things have changed. We don't need to do
> it all right now.
> 
> People who want allow_unsafe_interrupts to work will simply not set
> VFIO_CONTAINER=n at this time. Same with P2P, vfio-no-iommu and any
> other gaps we haven't discovered.
> 

If all agree that VFIO_CONTAINER=n is a process to evolve, does it make
more sense to remove this patch from this series i.e. let it buried in
VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if
no consensus can be made quickly at this point.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/rps: Query min/max freq from FW when displaying in sysfs

== Series Details ==

Series: drm/i915/rps: Query min/max freq from FW when displaying in sysfs
URL   : https://patchwork.freedesktop.org/series/110685/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Drop force_probe requirement

== Series Details ==

Series: drm/i915/dg2: Drop force_probe requirement
URL   : https://patchwork.freedesktop.org/series/110683/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12358 -> Patchwork_110683v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Additional (2): fi-hsw-4770 bat-dg1-7 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271]) +9 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3012])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334] / 
[i915#7433])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [INCOMPLETE][9] ([i915#7073]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2:  [DMESG-FAIL][11] ([i915#5334]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   [DMESG-WARN][13] ([i915#5278]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [DMESG-FAIL][15] ([i915#6997]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/bat-adln-1/igt@i915_selftest@l...@slpc.html

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

  * igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}:   [SKIP][19] ([i915#1849]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12358/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110683v1/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-flip:
- {bat-rpls-2}:   [SKIP][21] ([fdo#109295] / [i915#1845] / [i915#3708]) 
-> [PASS][22]
   [21]:

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/dg2: Drop force_probe requirement

== Series Details ==

Series: drm/i915/dg2: Drop force_probe requirement
URL   : https://patchwork.freedesktop.org/series/110683/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: Drop force_probe requirement

== Series Details ==

Series: drm/i915/dg2: Drop force_probe requirement
URL   : https://patchwork.freedesktop.org/series/110683/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2

[Intel-gfx] [CI 0/1] drm/i915/rps: Query min/max freq from FW when displaying in sysfs

2022-11-08 Thread Ashutosh Dixit

CI ONLY, PLEASE DON'T REVIEW

Test-with: 20221108215457.2494061-1-ashutosh.di...@intel.com

Ashutosh Dixit (1):
  drm/i915/rps: Query min/max freq from FW when displaying in sysfs

 drivers/gpu/drm/i915/gt/intel_rps.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

-- 
2.38.0

[Intel-gfx] [CI 1/1] drm/i915/rps: Query min/max freq from FW when displaying in sysfs

2022-11-08 Thread Ashutosh Dixit

CI ONLY, PLEASE DON'T REVIEW

Instead of displaying i915 cached values, query min/max freq from FW when
displaying in sysfs.

FIXME: "show" functions don't allow you to return error!!!

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6c34a83c24b34..12609714055d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2162,10 +2162,15 @@ u32 intel_rps_get_max_frequency(struct intel_rps *rps)
 {
struct intel_guc_slpc *slpc = rps_to_slpc(rps);
 
-   if (rps_uses_slpc(rps))
-   return slpc->max_freq_softlimit;
-   else
+   if (rps_uses_slpc(rps)) {
+   u32 val;
+
+   intel_guc_slpc_get_max_freq(slpc, );
+
+   return val;
+   } else {
return intel_gpu_freq(rps, rps->max_freq_softlimit);
+   }
 }
 
 /**
@@ -2482,10 +2487,15 @@ u32 intel_rps_get_min_frequency(struct intel_rps *rps)
 {
struct intel_guc_slpc *slpc = rps_to_slpc(rps);
 
-   if (rps_uses_slpc(rps))
-   return slpc->min_freq_softlimit;
-   else
+   if (rps_uses_slpc(rps)) {
+   u32 val;
+
+   intel_guc_slpc_get_min_freq(slpc, );
+
+   return val;
+   } else {
return intel_gpu_freq(rps, rps->min_freq_softlimit);
+   }
 }
 
 /**
-- 
2.38.0

Re: [Intel-gfx] [PATCH v7 22/23] drm/vc4: vec: Add support for more analog TV standards

Hi Maxime,

I ran your v7 patchset on my Pi with Xorg, and the mode switching, as well as
the preferred mode handling, all work really well now!

I just noted that the downstream version of the vc4 driver still has inaccurate
field delays in vc4_crtc.c, which causes vertical lines to appear jagged (like
here: 
https://user-images.githubusercontent.com/4499762/112738569-385c3280-8f64-11eb-83c4-d671537af209.png).
This has been fixed downstream in
https://github.com/raspberrypi/linux/pull/4241/commits/bc093f27bf2613ec93524fdc19e922dd7dd3d800,
but I guess that should be upstreamed separately...?

Anyway, it's unrelated to the changes made in this patchset, so... I'm not sure
if I'm qualified or allowed to do these, but just in case:

Tested-by: Mateusz Kwiatkowski 

(that pretty much applies to parts 19-22 in general, I can respond to those
messages as well if you wish)

Best regards,
Mateusz Kwiatkowski

W dniu 7.11.2022 o 15:16, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski 
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>   4.43361875 MHz (the PAL subcarrier frequency). Never used for
>   broadcasting, but sometimes used as a hack to play NTSC content in PAL
>   regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
>   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>   frequency. Another non-standard, non-broadcast mode, used in similar
>   contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
>   been broadcast in Eastern Europe and various parts of Africa and Asia.
>   Uses the same 576i50 timings as PAL.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Acked-by: Noralf Trønnes 
> Signed-off-by: Mateusz Kwiatkowski 
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v6:
> - Support PAL60 again
> ---
>  drivers/gpu/drm/vc4/vc4_vec.c | 111 
> --
>  1 file changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a828fc6fb776..d23dbad3cbf6 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
>  #define VEC_CONFIG0_YDEL(x)  ((x) << 26)
>  #define VEC_CONFIG0_CDEL_MASKGENMASK(25, 24)
>  #define VEC_CONFIG0_CDEL(x)  ((x) << 24)
> +#define VEC_CONFIG0_SECAM_STDBIT(21)
>  #define VEC_CONFIG0_PBPR_FIL BIT(18)
>  #define VEC_CONFIG0_CHROMA_GAIN_MASK GENMASK(17, 16)
>  #define VEC_CONFIG0_CHROMA_GAIN_UNITY(0 << 16)
> @@ -76,6 +77,27 @@
>  #define VEC_SOFT_RESET   0x10c
>  #define VEC_CLMP0_START  0x144
>  #define VEC_CLMP0_END0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit half-word,
> + * VEC_FREQ3_2 contains the least significant 16-bit half-word.
> + * 0x8000 seems to be equivalent to the pixel clock
> + * (which itself is the VEC clock divided by 8).
> + *
> + * Reference values (with the default pixel clock of 13.5 MHz):
> + *
> + * NTSC  (3579545.[45] Hz) - 0x21F07C1F
> + * PAL   (4433618.75 Hz)   - 0x2A098ACB
> + * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
> + * PAL-N (3582056.25 Hz)   - 0x21F69446
> + *
> + * NOTE: For SECAM, it is used as the Dr center frequency,
> + * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
> + * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
> + */
>  #define VEC_FREQ3_2  0x180
>  #define VEC_FREQ1_0  0x184
>  
> @@ -118,6 +140,14 @@
>  
>  #define VEC_INTERRUPT_CONTROL0x190
>  #define VEC_INTERRUPT_STATUS 0x194
> +
> +/*
> + * Db center frequency for SECAM; the clock for this is the same as for
> + * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
> + *
> + * This is specified as 425 Hz, which corresponds to 0x284BDA13.
> + * That is also the default value, so no need to set it explicitly.
> + */
>  #define VEC_FCW_SECAM_B  0x198
>  #define VEC_SECAM_GAIN_VAL   0x19c
>  
> @@ -197,10 +227,15 @@ enum vc4_vec_tv_mode_id {
>   VC4_VEC_TV_MODE_NTSC_J,
>   VC4_VEC_TV_MODE_PAL,
>   VC4_VEC_TV_MODE_PAL_M,
> + VC4_VEC_TV_MODE_NTSC_443,
> + VC4_VEC_TV_MODE_PAL_60,
> + VC4_VEC_TV_MODE_PAL_N,
> + VC4_VEC_TV_MODE_SECAM,
>  };
>  
>  struct vc4_vec_tv_mode {
>   unsigned int mode;
> + u16 expected_htotal;
>   u32 config0;
>

Re: [Intel-gfx] [PATCH v1] drm/i915/gt: Add sysfs RAPL PL1 interface

2022-11-08 Thread Dixit, Ashutosh

On Thu, 03 Nov 2022 05:37:23 -0700, Sujaritha Sundaresan wrote:
>

Hi Suja,

> Adding the rapl_pl1_freq_mhz sysfs attribute.
>
> Signed-off-by: Sujaritha Sundaresan 
> Cc: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 20 ++
>  drivers/gpu/drm/i915/gt/intel_rps.c | 44 +
>  drivers/gpu/drm/i915/gt/intel_rps.h |  3 ++
>  drivers/gpu/drm/i915/i915_reg.h |  4 ++
>  4 files changed, 71 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 904160952369..e7f00ec252f8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -496,6 +496,17 @@ static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
>  static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
>  static const struct attribute * const gen6_gt_attrs[]  = GEN6_GT_ATTR;
>
> +static ssize_t rapl_pl1_freq_mhz_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + u32 rapl_pl1 = intel_rps_read_rapl_pl1_frequency(>rps);
> +
> + return sysfs_emit(buff, "%u\n", rapl_pl1);
> +}
> +
> +
>  static ssize_t punit_req_freq_mhz_show(struct device *dev,
>  struct device_attribute *attr,
>  char *buff)
> @@ -534,6 +545,7 @@ struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = 
> { \
>   .mask = mask__, \
>  }
>
> +static DEVICE_ATTR_RO(rapl_pl1_freq_mhz);
>  static DEVICE_ATTR_RO(punit_req_freq_mhz);

Is this patch against old code? Since this is now INTEL_GT_ATTR_RO. Yes the
build failed. So rapl_pl1_freq_mhz will need to follow punit_req_freq_mhz.

>  static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status, 
> GT0_PERF_LIMIT_REASONS_MASK);
>  static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
> @@ -790,12 +802,20 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct 
> kobject *kobj)
>   if (!is_object_gt(kobj))
>   return;
>
> + ret = sysfs_create_file(kobj, _attr_rapl_pl1_freq_mhz.attr);

The convention here is to create sysfs files only for platforms on which a
feature (in this case RAPL PL1 freq) is supported.

Also are we sure this is only available on MTL and XEHPSDV and not on DG2?
Since generally a feature appears first on a platform and then is available
for all successive products. If it's available on DG2 too then we can use
something like:

if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))

See GRAPHICS_VER_FULL for various platforms in i915_pci.c.

> + if (ret)
> + drm_warn(>i915->drm,
> + "failed to create gt%u rapl_pl1_freq_mhz sysfs(%pe)",
> + gt->info.id, ERR_PTR(ret));
> +
> +
>   ret = sysfs_create_file(kobj, _attr_punit_req_freq_mhz.attr);
>   if (ret)
>   drm_warn(>i915->drm,
>"failed to create gt%u punit_req_freq_mhz sysfs (%pe)",
>gt->info.id, ERR_PTR(ret));
>
> +

Remove empty line.

>   if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
>   ret = sysfs_create_files(kobj, throttle_reason_attrs);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 17b40b625e31..0e89b941e3be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -9,6 +9,7 @@
>
>  #include "i915_drv.h"
>  #include "i915_irq.h"
> +#include "i915_reg.h"

Not needed, see below.

>  #include "intel_breadcrumbs.h"
>  #include "intel_gt.h"
>  #include "intel_gt_clock_utils.h"
> @@ -2422,6 +2423,49 @@ bool rps_read_mask_mmio(struct intel_rps *rps,
>   return rps_read_mmio(rps, reg32) & mask;
>  }
>
> +u32 intel_rps_read_rapl_pl1(struct intel_rps *rps)
> +{
> + struct drm_i915_private *i915 = rps_to_i915(rps);
> + i915_reg_t rgadr;
> + u32 rapl_pl1;
> +
> + if (IS_METEORLAKE(i915)) {
> + rgadr = MTL_RAPL_PL1_FREQ_LIMIT;
> + } else if (IS_XEHPSDV(i915)) {
> + rgadr = XEHPSDV_RAPL_PL1_FREQ_LIMIT;
> + } else {
> + MISSING_CASE(GRAPHICS_VER(i915));
> + rgadr = INVALID_MMIO_REG;

No need for this, the sysfs file will only be visible for platforms on
which this is supported so this will never be hit.

> + }
> +
> + if (!i915_mmio_reg_valid(rgadr))
> + rapl_pl1 = 0;

No need for this either.

> + else
> + rapl_pl1 = rps_read_mmio(rps, rgadr);
> +
> + return rapl_pl1;
> +}
> +
> +u32 intel_rps_get_rapl(struct intel_rps *rps, u32 rapl_pl1)
> +{
> + struct drm_i915_private *i915 = rps_to_i915(rps);
> + u32 rapl = 0;
> +
> + if (IS_METEORLAKE(i915) || IS_XEHPSDV(i915))
> +

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote:

> > > So why exactly isn't this an issue for VDPA?  Are we just burying our
> > > head in the sand that such platforms exists and can still be useful
> > > given the appropriate risk vs reward trade-off?  
> > 
> > Simply that nobody has asked for it, and might never ask for it. This
> > is all support for old platforms, and there just doesn't seem to be a
> > "real" use case for very new (and actually rare) NIC hardware stuck
> > into ancient platforms with this security problem.
> 
> vIOMMU support for interrupt remapping is relatively new, the nesting
> case is important as well.

This is where we got hit. In the end we fixed the qemu..

> > I'd be much more comfortable with this as a system wide iommufd flag
> > if we also tied it to do some demonstration of privilege - eg a
> > requirement to open iommufd with CAP_SYS_RAWIO for instance.
> 
> Which is not compatible to existing use cases, which is also why we
> can't invent some way to allow some applications to run without CPU
> mitigations, while requiring it for others as a baseline.

Isn't it? Didn't we learn that libvirt runs as root and will open and
pass the iommufd as root?

> > That is the usual protocol for these kinds of insecurities..
> 
> Hmm, is it?

I think so. At least you should have something to shut down an
insecure feature in kernel lockdown modes. CAP_SYS_RAWIO is a simple
way to do it.

> > I think right now we can leave this as-is and we can wait for some
> > more information to decide how best to proceed.
> 
> It's certainly not acceptable in the latest proposal, iommufd consumes
> an option set by another module and when that module goes away, so does
> any claim of compatibility.  The code becomes dead and the feature not
> present.  The option doesn't belong on the vfio module.  Do we need a
> vfio-iommufd module to host it?  Thanks,

I don't know, as I said in the other email, these little things need
work and discussion to resolve. We need to recheck the security stuff
against the 2022 kernel where things have changed. We don't need to do
it all right now.

People who want allow_unsafe_interrupts to work will simply not set
VFIO_CONTAINER=n at this time. Same with P2P, vfio-no-iommu and any
other gaps we haven't discovered.

vfio-iommufd seems like overkill, I think your first suggestion to put
in vfio.ko was more practical.

My only doubt is if we should make it system wide for everything - and
I'm just a bit uncomfortable with that from a security POV. But maybe
I don't quite know exactly what the risks are.

Jason

Re: [Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled

On Tue, Nov 08, 2022 at 03:28:31PM -0700, Alex Williamson wrote:

> Perhaps this should have been obvious, but I'm realizing that
> vfio-noiommu mode is completely missing without VFIO_CONTAINER, which
> seems a barrier to deprecating VFIO_CONTAINER and perhaps makes it a

Yes, it is the same as the allow_unsafe_interrupts - it is something
that currently goes missing if you turn off VFIO_CONTAINER.

This seems straightforward enough to resolve in a followup, we mostly
just need someone with an existing no-iommu application to test
compatability against. Keeping it working with the device cdev will
also be a bit interesting. If you have or know about some application
I can try to make a patch.

> question whether IOMMUFD should really be taking over /dev/vfio/vfio.
> No-iommu mode has users.  

I view VFIO_CONTAINER=n as a process. An aspiration we can work
toward.

At this point there are few places that might want to use it. Android
perhaps, for example. It is also useful for testing. One of the main
values is you can switch the options and feed the kernel into an
existing test environment and see what happens. This is how we are
able to quickly get s390 mdev testing, for instance.

We are not going to get to a widely useful VFIO_CONTAINER=n if we
don't have a target that people can test against and evaluate what
compatability gaps may exist.

So, everytime we find something like this - let's think about how can
we make iommufd compatibility handle it and not jump straight to
giving up :)

I'm kind of thinking v6.4 might be a reasonable kernel target when we
might have closed off enough things.

Jason

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk

2022-11-08 Thread Matt Roper

On Tue, Nov 08, 2022 at 03:56:23PM -0800, Srivatsa, Anusha wrote:
> 
> 
> > -Original Message-
> > From: Roper, Matthew D 
> > Sent: Tuesday, November 8, 2022 3:43 PM
> > To: Srivatsa, Anusha 
> > Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
> > 
> > Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> > squash when changing cdclk
> > 
> > On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> > > From: Ville Syrjälä 
> > >
> > > For MTL, changing cdclk from between certain frequencies has both
> > > squash and crawl. Use the current cdclk config and the new(desired)
> > > cdclk config to construtc a mid cdclk config.
> > > Set the cdclk twice:
> > > - Current cdclk -> mid cdclk
> > > - mid cdclk -> desired cdclk
> > >
> > > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > > modeset for platforms that support squash_crawl sequences(Ville)
> > >
> > > v3: Add checks for:
> > > - scenario where only slow clock is used and cdclk is actually 0
> > > (bringing up display).
> > > - PLLs are on before looking up the waveform.
> > > - Squash and crawl capability checks.(Ville)
> > >
> > > v4: Rebase
> > > - Move checks to be more consistent (Ville)
> > > - Add comments (Bala)
> > > v5:
> > > - Further small changes. Move checks around.
> > > - Make if-else better looking (Ville)
> > >
> > > v6: MTl should not follow PUnit mailbox communication as the rest of
> > > gen11+ platforms.(Anusha)
> > >
> > > Cc: Clint Taylor 
> > > Cc: Balasubramani Vivekanandan
> > 
> > > Signed-off-by: Anusha Srivatsa 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 161
> > > +
> > >  1 file changed, 133 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index eada931cb1c8..d1e0763513be 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct
> > drm_i915_private *i915,
> > >   intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);  }
> > >
> > > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > -   const struct intel_cdclk_config *cdclk_config,
> > > -   enum pipe pipe)
> > > +static int cdclk_squash_divider(u16 waveform) {
> > > + return hweight16(waveform ?: 0x); }
> > > +
> > > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> > 
> > Bikeshed:  maybe name this "cdclk_compute_crawl_squash_midpoint" to
> > help clarify that we're just computing stuff here and not actually
> > programming the hardware in this function?
> > 
> > That naming would also help clarify why we're returning false if we crawl 
> > but
> > don't squash or vice versa (i.e., there's no midpoint in those cases).
> 
> Makes sense.
> 
> > > +const struct intel_cdclk_config
> > *old_cdclk_config,
> > > +const struct intel_cdclk_config
> > *new_cdclk_config,
> > > +struct intel_cdclk_config *mid_cdclk_config)
> > {
> > > + u16 old_waveform, new_waveform, mid_waveform;
> > > + int size = 16;
> > > + int div = 2;
> > > +
> > > + /* Return if both Squash and Crawl are not present */
> > > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > > + return false;
> > > +
> > > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> > >cdclk);
> > > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> > >cdclk);
> > > +
> > > + /* Return if Squash only or Crawl only is the desired action */
> > > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> > 
> > Isn't vco unsigned?  "== 0" should be fine here I think.
> 
> You mean the new_cdclk_config->vco right?

Both of them I think.  The vco field of intel_cdclk_config can't take on
negative values because it's defined as unsigned:

struct intel_cdclk_config {
unsigned int cdclk, vco, ref, bypass;
u8 voltage_level;
};
 
> > > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > > + old_waveform == new_waveform)
> > > + return false;
> > > +
> > > + *mid_cdclk_config = *new_cdclk_config;
> > > +
> > > + /* Populate the mid_cdclk_config accordingly.
> > > +  * - If moving to a higher cdclk, the desired action is squashing.
> > > +  * The mid cdclk config should have the new (squash) waveform.
> > > +  * - If moving to a lower cdclk, the desired action is crawling.
> > > +  * The mid cdclk config should have the new vco.
> > > +  */
> > > +
> > > + if (cdclk_squash_divider(new_waveform) >
> > cdclk_squash_divider(old_waveform)) {
> > > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > > + mid_waveform = new_waveform;
> > > + } else {
> > > +

[Intel-gfx] [PATCH] drm/i915/dg2: Drop force_probe requirement

2022-11-08 Thread Matt Roper

DG2 has been very usable for a while now, and all of the uapi changes
related to fundamental platform usage have been finalized.  Recent CI
results have also been healthy, so we're ready to drop the force_probe
requirement and enable the platform by default.

Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Signed-off-by: Matt Roper 
---

There was some recent offline discussion questioning whether we'd fully
identified the root cause of some historic CI failures, or whether it
was possible we might still have a bug lurking somewhere causing
sporadic failures.  Let's use this patch to centralize discussion about
any remaining concerns and make sure they're addressed before we apply
this.

 drivers/gpu/drm/i915/i915_pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 211913be40ce..0866300243aa 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1078,7 +1078,6 @@ static const struct intel_device_info dg2_info = {
XE_LPD_FEATURES,
.__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
-   .require_force_probe = 1,
 };

 static const struct intel_device_info ats_m_info = {
-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: ELD precompute and readout (rev3)

== Series Details ==

Series: drm/i915: ELD precompute and readout (rev3)
URL   : https://patchwork.freedesktop.org/series/109592/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12355_full -> Patchwork_109592v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl9/igt@i915_susp...@fence-restore-tiled2untiled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-skl6/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_flip@flip-vs-rmfb@c-edp1:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl4/igt@kms_flip@flip-vs-r...@c-edp1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-skl3/igt@kms_flip@flip-vs-r...@c-edp1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-iclb5/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-apl8/igt@gem_huc_c...@huc-copy.html

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

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

  * igt@gem_pxp@create-valid-protected-context:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +56 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-skl9/igt@gem_...@create-valid-protected-context.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-apl2/igt@gem_workarou...@suspend-resume-context.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-apl8/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_pm_dc@dc5-psr:
- shard-skl:  [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl3/igt@i915_pm...@dc5-psr.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-skl9/igt@i915_pm...@dc5-psr.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#3989] / [i915#454])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-iclb5/igt@i915_pm...@dc6-dpms.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-iclb3/igt@i915_pm...@dc6-dpms.html

  * igt@i915_pm_dc@dc6-psr:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#3989] / [i915#454])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl7/igt@i915_pm...@dc6-psr.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/shard-skl1/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- shard-tglb: NOTRUN -> [WARN][20] ([i915#2681]) +3 similar issues
   [20]:

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk

2022-11-08 Thread Srivatsa, Anusha




> -Original Message-
> From: Roper, Matthew D 
> Sent: Tuesday, November 8, 2022 3:43 PM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
> 
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
> 
> On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> > From: Ville Syrjälä 
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > Cc: Clint Taylor 
> > Cc: Balasubramani Vivekanandan
> 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 161
> > +
> >  1 file changed, 133 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index eada931cb1c8..d1e0763513be 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct
> drm_i915_private *i915,
> > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);  }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > +   return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> 
> Bikeshed:  maybe name this "cdclk_compute_crawl_squash_midpoint" to
> help clarify that we're just computing stuff here and not actually
> programming the hardware in this function?
> 
> That naming would also help clarify why we're returning false if we crawl but
> don't squash or vice versa (i.e., there's no midpoint in those cases).

Makes sense.

> > +  const struct intel_cdclk_config
> *old_cdclk_config,
> > +  const struct intel_cdclk_config
> *new_cdclk_config,
> > +  struct intel_cdclk_config *mid_cdclk_config)
> {
> > +   u16 old_waveform, new_waveform, mid_waveform;
> > +   int size = 16;
> > +   int div = 2;
> > +
> > +   /* Return if both Squash and Crawl are not present */
> > +   if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > +   return false;
> > +
> > +   old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > +   new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > +   /* Return if Squash only or Crawl only is the desired action */
> > +   if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> 
> Isn't vco unsigned?  "== 0" should be fine here I think.

You mean the new_cdclk_config->vco right?
 
> > +   old_cdclk_config->vco == new_cdclk_config->vco ||
> > +   old_waveform == new_waveform)
> > +   return false;
> > +
> > +   *mid_cdclk_config = *new_cdclk_config;
> > +
> > +   /* Populate the mid_cdclk_config accordingly.
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > +   if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > +   mid_cdclk_config->vco = old_cdclk_config->vco;
> > +   mid_waveform = new_waveform;
> > +   } else {
> > +   mid_cdclk_config->vco = new_cdclk_config->vco;
> > +   mid_waveform = old_waveform;
> > +   }
> > +
> > +   mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> > +   mid_cdclk_config->vco, size
> * div);
> > +
> > +   /* make sure the mid clock came out sane */
> > +
> > +   drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
> > +   min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> > +   drm_WARN_ON(>drm,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk

2022-11-08 Thread Matt Roper

On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> From: Ville Syrjälä 
> 
> For MTL, changing cdclk from between certain frequencies has
> both squash and crawl. Use the current cdclk config and
> the new(desired) cdclk config to construtc a mid cdclk config.
> Set the cdclk twice:
> - Current cdclk -> mid cdclk
> - mid cdclk -> desired cdclk
> 
> v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> change via modeset for platforms that support squash_crawl sequences(Ville)
> 
> v3: Add checks for:
> - scenario where only slow clock is used and
> cdclk is actually 0 (bringing up display).
> - PLLs are on before looking up the waveform.
> - Squash and crawl capability checks.(Ville)
> 
> v4: Rebase
> - Move checks to be more consistent (Ville)
> - Add comments (Bala)
> v5:
> - Further small changes. Move checks around.
> - Make if-else better looking (Ville)
> 
> v6: MTl should not follow PUnit mailbox communication as the rest of
> gen11+ platforms.(Anusha)
> 
> Cc: Clint Taylor 
> Cc: Balasubramani Vivekanandan 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 161 +
>  1 file changed, 133 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index eada931cb1c8..d1e0763513be 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct 
> drm_i915_private *i915,
>   intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
>  }
>  
> -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> -   const struct intel_cdclk_config *cdclk_config,
> -   enum pipe pipe)
> +static int cdclk_squash_divider(u16 waveform)
> +{
> + return hweight16(waveform ?: 0x);
> +}
> +
> +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,

Bikeshed:  maybe name this "cdclk_compute_crawl_squash_midpoint" to help
clarify that we're just computing stuff here and not actually
programming the hardware in this function?

That naming would also help clarify why we're returning false if we
crawl but don't squash or vice versa (i.e., there's no midpoint in those
cases).

> +const struct intel_cdclk_config 
> *old_cdclk_config,
> +const struct intel_cdclk_config 
> *new_cdclk_config,
> +struct intel_cdclk_config *mid_cdclk_config)
> +{
> + u16 old_waveform, new_waveform, mid_waveform;
> + int size = 16;
> + int div = 2;
> +
> + /* Return if both Squash and Crawl are not present */
> + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> + return false;
> +
> + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
> + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
> +
> + /* Return if Squash only or Crawl only is the desired action */
> + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||

Isn't vco unsigned?  "== 0" should be fine here I think.

> + old_cdclk_config->vco == new_cdclk_config->vco ||
> + old_waveform == new_waveform)
> + return false;
> +
> + *mid_cdclk_config = *new_cdclk_config;
> +
> + /* Populate the mid_cdclk_config accordingly.
> +  * - If moving to a higher cdclk, the desired action is squashing.
> +  * The mid cdclk config should have the new (squash) waveform.
> +  * - If moving to a lower cdclk, the desired action is crawling.
> +  * The mid cdclk config should have the new vco.
> +  */
> +
> + if (cdclk_squash_divider(new_waveform) > 
> cdclk_squash_divider(old_waveform)) {
> + mid_cdclk_config->vco = old_cdclk_config->vco;
> + mid_waveform = new_waveform;
> + } else {
> + mid_cdclk_config->vco = new_cdclk_config->vco;
> + mid_waveform = old_waveform;
> + }
> +
> + mid_cdclk_config->cdclk = 
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> + mid_cdclk_config->vco, size 
> * div);
> +
> + /* make sure the mid clock came out sane */
> +
> + drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
> + min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> + drm_WARN_ON(>drm, mid_cdclk_config->cdclk >
> + i915->display.cdclk.max_cdclk_freq);
> + drm_WARN_ON(>drm, cdclk_squash_waveform(i915, 
> mid_cdclk_config->cdclk) !=
> + mid_waveform);
> +
> + return true;
> +}
> +
> +static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> +const struct intel_cdclk_config *cdclk_config,
> +enum pipe pipe)
>  {
>   int cdclk = cdclk_config->cdclk;
>   int vco =

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

2022-11-08 Thread Alex Williamson

On Mon, 7 Nov 2022 14:45:59 -0400
Jason Gunthorpe  wrote:

> On Mon, Nov 07, 2022 at 11:05:08AM -0700, Alex Williamson wrote:
> 
> > After further consideration... I don't think the option on vfio-main
> > makes sense, basically for the same reason that the original option
> > existed on the IOMMU backend rather than vfio-core.  The option
> > describes a means to relax a specific aspect of IOMMU isolation, which
> > makes more sense to expose via the IOMMU provider, imo.  For example,
> > vfio-main cannot generate an equivalent error message as provided in
> > type1 today, it's too far removed from the IOMMU feature support.  
> 
> vfio-main can do it, we just have to be strict that the EPERM code is
> always going to be this case.

This doesn't seem very practical.

> > > > If vdpa doesn't allow full device access such that it can guarantee
> > > > that a device cannot generate a DMA that can spoof MSI, then it
> > > > sounds like the flag we pass when attaching a device to iommfd
> > > > should to reflect this difference in usage.
> > > 
> > > VDPA allows arbitary DMA just like VFIO. At most VDPA limits the MMIO
> > > touches.  
> >
> > So why exactly isn't this an issue for VDPA?  Are we just burying our
> > head in the sand that such platforms exists and can still be useful
> > given the appropriate risk vs reward trade-off?  
> 
> Simply that nobody has asked for it, and might never ask for it. This
> is all support for old platforms, and there just doesn't seem to be a
> "real" use case for very new (and actually rare) NIC hardware stuck
> into ancient platforms with this security problem.

vIOMMU support for interrupt remapping is relatively new, the nesting
case is important as well.

> So I'd rather leave this in the past than carry forward a security
> exception as some ongoing 1st class thing.
> 
> > > and IMHO we don't actually want to enable this more
> > > widely. So I don't want to see a global kernel wide flag at this point
> > > until we get reason to make more than just VFIO insecure.  
> > 
> > But this brings into question the entire existence of the opt-in.  Do
> > we agree that there are valid use cases for such an option?  
> 
> I think it is something VFIO has historically allowed and I think we
> can continue to allow it, but I don't think we should encourage its
> use or encourage it to propogate to wider areas given that the
> legitimate use cases are focused on fairly old hardware at this point.
> 
> So, I'd rather wait for someone to ask for it, and explain why they
> need to use a combination of stuff where we need to have a true global
> option.
> 
> > Unlike things like ACS overrides, lack of interrupt isolation really
> > requires a malicious actor.  We're not going to inadvertently overlap
> > DMA to interrupt addresses like we might to a non-isolated MMIO ranges.
> > Therefore an admin can make a reasonable determination relative to the
> > extent to which the userspace is trusted.  This is not unlike opt-outs
> > to CPU vulnerability mitigation imo, there are use cases where the
> > performance or functionality is more important than the isolation.
> > Hand waving this away as a vfio-unique insecurity is a bad precedent
> > for iommufd.  
> 
> I agree with this, which is why I think it should come from the actual
> user facing subsystem not be a system wide flag. The "is userspace
> trusted" for VFIO may be quite different than from VDPA or whatever
> else comes next.
> 
> I'd be much more comfortable with this as a system wide iommufd flag
> if we also tied it to do some demonstration of privilege - eg a
> requirement to open iommufd with CAP_SYS_RAWIO for instance.

Which is not compatible to existing use cases, which is also why we
can't invent some way to allow some applications to run without CPU
mitigations, while requiring it for others as a baseline.

> That is the usual protocol for these kinds of insecurities..

Hmm, is it?

> I think right now we can leave this as-is and we can wait for some
> more information to decide how best to proceed.

It's certainly not acceptable in the latest proposal, iommufd consumes
an option set by another module and when that module goes away, so does
any claim of compatibility.  The code becomes dead and the feature not
present.  The option doesn't belong on the vfio module.  Do we need a
vfio-iommufd module to host it?  Thanks,

Alex

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)

== Series Details ==

Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)
URL   : https://patchwork.freedesktop.org/series/110433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12355_full -> Patchwork_110433v8_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-apl2/igt@gem_ctx_isolation@preservation...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-apl2/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_eio@hibernate:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-glk7/igt@gem_...@hibernate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-glk1/igt@gem_...@hibernate.html

  * igt@gem_eio@kms:
- shard-tglb: NOTRUN -> [FAIL][5] ([i915#5784])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-tglb2/igt@gem_...@kms.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-iclb3/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-glk9/igt@gem_exec_fair@basic-n...@vecs0.html

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

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

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#5566] / 
[i915#716])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl10/igt@gen9_exec_pa...@allowed-single.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-skl6/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_dc@dc6-psr:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#3989] / [i915#454])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl7/igt@i915_pm...@dc6-psr.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-skl10/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- shard-tglb: NOTRUN -> [WARN][19] ([i915#2681]) +3 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-tglb2/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-edp-1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2521])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-skl1/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-edp-1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-skl10/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-edp-1.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-c-hdmi-a-1:
- shard-glk:  [PASS][22] -> [FAIL][23] ([i915#2521])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/shard-glk7/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-hdmi-a-1.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/shard-glk1/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-hdmi-a-1.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-apl:  NOTRUN ->

Re: [Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled

2022-11-08 Thread Alex Williamson

On Mon,  7 Nov 2022 20:52:54 -0400
Jason Gunthorpe  wrote:

> Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container
> code. If 'n' then only iommufd will provide the container service. All the
> support for vfio iommu drivers, including type1, will not be built.
> 
> This allows a compilation check that no inappropriate dependencies between
> the device/group and container have been created.
> 
> Tested-by: Nicolin Chen 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/vfio/Kconfig  | 35 +++
>  drivers/vfio/Makefile |  4 +--
>  drivers/vfio/vfio.h   | 65 +++
>  3 files changed, 91 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 1118d322eec97d..286c1663bd7564 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -3,8 +3,8 @@ menuconfig VFIO
>   tristate "VFIO Non-Privileged userspace driver framework"
>   select IOMMU_API
>   depends on IOMMUFD || !IOMMUFD
> - select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
>   select INTERVAL_TREE
> + select VFIO_CONTAINER if IOMMUFD=n
>   help
> VFIO provides a framework for secure userspace device drivers.
> See Documentation/driver-api/vfio.rst for more details.
> @@ -12,6 +12,18 @@ menuconfig VFIO
> If you don't know what to do here, say N.
>  
>  if VFIO
> +config VFIO_CONTAINER
> + bool "Support for the VFIO container /dev/vfio/vfio"
> + select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
> + default y
> + help
> +   The VFIO container is the classic interface to VFIO for establishing
> +   IOMMU mappings. If N is selected here then IOMMUFD must be used to
> +   manage the mappings.
> +
> +   Unless testing IOMMUFD say Y here.
> +
> +if VFIO_CONTAINER
>  config VFIO_IOMMU_TYPE1
>   tristate
>   default n
> @@ -21,16 +33,6 @@ config VFIO_IOMMU_SPAPR_TCE
>   depends on SPAPR_TCE_IOMMU
>   default VFIO
>  
> -config VFIO_SPAPR_EEH
> - tristate
> - depends on EEH && VFIO_IOMMU_SPAPR_TCE
> - default VFIO
> -
> -config VFIO_VIRQFD
> - tristate
> - select EVENTFD
> - default n
> -
>  config VFIO_NOIOMMU
>   bool "VFIO No-IOMMU support"
>   help


Perhaps this should have been obvious, but I'm realizing that
vfio-noiommu mode is completely missing without VFIO_CONTAINER, which
seems a barrier to deprecating VFIO_CONTAINER and perhaps makes it a
question whether IOMMUFD should really be taking over /dev/vfio/vfio.
No-iommu mode has users.  Thanks,

Alex

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Analog TV Improvements (rev8)

== Series Details ==

Series: drm: Analog TV Improvements (rev8)
URL   : https://patchwork.freedesktop.org/series/107892/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/8/mbox/ not 
applied
Applying: drm/tests: Add Kunit Helpers
Applying: drm/connector: Rename legacy TV property
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/drm_connector.c
M   drivers/gpu/drm/i915/display/intel_tv.c
M   include/drm/drm_connector.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_connector.h
Auto-merging drivers/gpu/drm/i915/display/intel_tv.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_tv.c
Auto-merging drivers/gpu/drm/drm_connector.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/connector: Rename legacy TV property
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [Nouveau] [PATCH v7 22/23] drm/vc4: vec: Add support for more analog TV standards

Hi Lukas, Maxime and everyone,

W dniu 8.11.2022 o 14:17, Lukas Satin pisze:
> They are important for retrogaming and connecting TV out to CRT TV or using
> emulator.
>
> I have PS1 that is using PAL-60 for example.
>
> Can you add 240p and 288p non-interlaced modes for NTSC and PAL, please?

To add progressive mode support, at least for the VC4/VEC device that's used
on the Raspberry Pi, all that's necessary is a patch like:

--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -623,7 +623,9 @@ static void vc4_vec_encoder_enable(struct drm_encoder 
*encoder,
VEC_WRITE(VEC_CLMP0_START, 0xac);
VEC_WRITE(VEC_CLMP0_END, 0xec);
VEC_WRITE(VEC_CONFIG2,
- VEC_CONFIG2_UV_DIG_DIS | VEC_CONFIG2_RGB_DIG_DIS);
+ VEC_CONFIG2_UV_DIG_DIS |
+ VEC_CONFIG2_RGB_DIG_DIS |
+ ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ? 0 : 
VEC_CONFIG2_PROG_SCAN));
VEC_WRITE(VEC_CONFIG3, VEC_CONFIG3_HORIZ_LEN_STD);
VEC_WRITE(VEC_DAC_CONFIG, vec->variant->dac_config);
 

and then you can just add custom modes, for example within Xorg:

xrandr --newmode 720x240 13.5 720 736 800 858 240 243 246 262
xrandr --newmode 720x288 13.5 720 740 804 864 288 290 293 312

Note that the pixel aspect ratio will be all over the place - unfortunately this
is necessary at the driver level, because VC4's VEC does not support pixel
clocks other than 13.5 MHz. However, you can fix it by running something like
"xrandr --scale-from 320x240" or "xrandr --scale-from 384x288". Other (non-X)
applications would need to be adapted to similarly configure DRM scaling.

I'm not sure if Maxime wants to introduce any more code like the patch above to
facilitate progressive scan support, though (@Maxime: feel free to grab the code
from above or anything else from https://github.com/raspberrypi/linux/pull/4406
if you do, however!). We talked recently that the priority is to finally merge
existing functionality first, see this message:
https://lore.kernel.org/dri-devel/20221027115822.5vd3fqlcpy4gfq5v@houat/

I'm willing to post a couple of follow-up patches to improve things like
support for progressive modes or exotic TV norms (such as PAL-M-50 or PAL-N-60)
within the VC4 driver once this patchset lands - but I agree with Maxime's point
to focus on merging existing functionality first.

> Lukas

Best regards,
Mateusz Kwiatkowski

> On Mon, Nov 7, 2022 at 3:19 PM Maxime Ripard  wrote:
>
> From: Mateusz Kwiatkowski 
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>   4.43361875 MHz (the PAL subcarrier frequency). Never used for
>   broadcasting, but sometimes used as a hack to play NTSC content in PAL
>   regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
>   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>   frequency. Another non-standard, non-broadcast mode, used in similar
>   contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
>   been broadcast in Eastern Europe and various parts of Africa and Asia.
>   Uses the same 576i50 timings as PAL.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Acked-by: Noralf Trønnes 
> Signed-off-by: Mateusz Kwiatkowski 
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v6:
> - Support PAL60 again
> ---
>  drivers/gpu/drm/vc4/vc4_vec.c | 111 
> --
>  1 file changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a828fc6fb776..d23dbad3cbf6 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
>  #define VEC_CONFIG0_YDEL(x)((x) << 26)
>  #define VEC_CONFIG0_CDEL_MASK  GENMASK(25, 24)
>  #define VEC_CONFIG0_CDEL(x)((x) << 24)
> +#define VEC_CONFIG0_SECAM_STD  BIT(21)
>  #define VEC_CONFIG0_PBPR_FIL   BIT(18)
>  #define VEC_CONFIG0_CHROMA_GAIN_MASK   GENMASK(17, 16)
>  #define VEC_CONFIG0_CHROMA_GAIN_UNITY  (0 << 16)
> @@ -76,6 +77,27 @@
>  #define VEC_SOFT_RESET 0x10c
>  #define VEC_CLMP0_START0x144
>  #define VEC_CLMP0_END  0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup

== Series Details ==

Series: series starting with [1/3] drm/i915/pps: Add get_pps_idx() hook as part 
of pps_get_register() cleanup
URL   : https://patchwork.freedesktop.org/series/110678/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12356 -> Patchwork_110678v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 39)
--

  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110678v1/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

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

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

  * igt@i915_selftest@live@hugepages:
- fi-bsw-nick:[DMESG-FAIL][10] ([i915#6217]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12356/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110678v1/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
  [i915#7467]: https://gitlab.freedesktop.org/drm/intel/issues/7467


Build changes
-

  * Linux: CI_DRM_12356 -> Patchwork_110678v1

  CI-20190529: 20190529
  CI_DRM_12356: 1278975de8debde9eb1f5d86fd2fbe533361e456 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7048: 5edd5c539f1fdf1c02157bf43fa1fd22d4ad2c75 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110678v1: 1278975de8debde9eb1f5d86fd2fbe533361e456 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

13138199a94b drm/i915/edp: Fix warning as vdd went down without driver knowledge
11d417b24708 drm/i915/pps: Enable 2nd pps for dual EDP scenario
adf3cd59520d drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() 
cleanup

== Logs ==

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

Re: [Intel-gfx] [Nouveau] [PATCH v7 06/23] drm/modes: Add a function to generate analog display modes

Hi Lukas,

W dniu 8.11.2022 o 14:28, Lukas Satin pisze:
> Hi, your statement:
>
> "However, analog display usually have fairly loose timings requirements,
> the only discrete parameters being the total number of lines and pixel
> clock frequency."
>
> Please do not make it as a rule. You said yourself: "usually". Arcade CRT
> have more loose timings, but professional broadcast TV's such as Sony PVM,
> Sony BVM, JVC. These cost tens of thousand dollars back in the day. Now they
> are affordable for gamers. I just solved issue in Retroarch, CRT Switchres
> library here: https://github.com/antonioginer/switchres/issues/96

I think I'm partially to blame for this wording.
See this message and the surrounding thread:
https://lore.kernel.org/dri-devel/6d1dfaad-7310-a596-34dd-4a6d9aa95...@gmail.com/

A lot of composite video equipment routinely violated the reference spec.
For example, CGA and Apple II output singal that had 15699.76 Hz horizontal
sync and 59.92 Hz vertical sync instead of the regular 15734.26 Hz / 59.94 Hz.
Values for Famicom/NES are 15745.98 Hz / 60.10 Hz (and the last line is slightly
shorter than all other ones at that). And I'm pretty sure these will display
just fine on a PVM.

Of course you can't just output 14 kHz / 70 Hz and expect it to work, there are
constraints of display capabilities. But the point of that discussion, which
culminated in the wording you see in the code, was that it does not need to be
precise down to every clock cycle as you would normally expect in the digital
world.

> This model is quite common among retrogamers and on Reddit.
>
> Some developers do not test it properly.
>
> This model requires exact number of lines.
>
> For Switchres we came up with these ranges:
> crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 
> 0.192, 1.024, 1, 1, 192, 288, 0, 0
> crt_range1 15625.00-15625.00, 50.00-50.00, 1.500, 4.700, 5.800, 
> 0.064, 0.160, 1.056, 1, 1, 0, 0, 448, 576
> crt_range2 15734.26-15734.26, 59.94-59.94, 1.500, 4.700, 4.700, 
> 0.191, 0.191, 0.953, 1, 1, 0, 0, 448, 480
> crt_range0 is default, more loose definition for MAME emulators. crt_range1 
> is PAL and crt_range2 is NTSC.
>
> Yes, this model does support both NTSC and PAL.
>
> Does your driver or library support that?
>
> For example old driver in Windows 7 with NVIDIA 2007 driver on Geforce 7600
> can support both NTSC and PAL and these are being switched automatically by
> the resolution you choose. So in desktop properties, you change to 640x480
> and it will switch TV chipset to NTSC 480i. Then you change to 720x576 and it
> will switch TV chipset to PAL 576i.
>
> It would be preferred if advanced users could set up these numbers from a
> commandline during a runtime, so it would depend on the app being used.

As far as I understand the patch, this is exactly how it works right now. The
function you're commenting on is only used for generating the "default" modes.

> Lukas

Best regards,
Mateusz Kwiatkowski

> On Mon, Nov 7, 2022 at 3:17 PM Maxime Ripard  wrote:
>
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 625-lines modes in their drivers.
>
> Since those modes are fairly standard, and that we'll need to use them
> in more places in the future, it makes sense to move their definition
> into the core framework.
>
> However, analog display usually have fairly loose timings requirements,
> the only discrete parameters being the total number of lines and pixel
> clock frequency. Thus, we created a function that will create a display
> mode from the standard, the pixel frequency and the active area.
>
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v6:
> - Fix typo
>
> Changes in v4:
> - Reworded the line length check comment
> - Switch to HZ_PER_KHZ in tests
> - Use previous timing to fill our mode
> - Move the number of lines check earlier
> ---
>  drivers/gpu/drm/drm_modes.c| 474 
> +
>  drivers/gpu/drm/tests/Makefile |   1 +
>  drivers/gpu/drm/tests/drm_modes_test.c | 144 ++
>  include/drm/drm_modes.h|  17 ++
>  4 files changed, 636 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5d4ac79381c4..71c050c3ee6b 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector 
> *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_probed_add);
>
> +enum drm_mode_analog {
> +   DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
> +   DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
> +};
> +
> +/*
> + * The timings come from:
> + * - 
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> + * - 
>

Re: [Intel-gfx] [PATCH v7 15/23] drm/modes: Introduce more named modes

Hi Noralf,

W dniu 8.11.2022 o 10:38, Noralf Trønnes pisze:
>
> Den 07.11.2022 19.03, skrev Noralf Trønnes:
>>
>> Den 07.11.2022 15.16, skrev Maxime Ripard:
>>> Now that we can easily extend the named modes list, let's add a few more
>>> analog TV modes that were used in the wild, and some unit tests to make
>>> sure it works as intended.
>>>
>>> Signed-off-by: Maxime Ripard 
>>>
>>> ---
>>> Changes in v6:
>>> - Renamed the tests to follow DRM test naming convention
>>>
>>> Changes in v5:
>>> - Switched to KUNIT_ASSERT_NOT_NULL
>>> ---
>>>  drivers/gpu/drm/drm_modes.c |  2 +
>>>  drivers/gpu/drm/tests/drm_client_modeset_test.c | 54 
>>> +
>>>  2 files changed, 56 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>>> index 49441cabdd9d..17c5b6108103 100644
>>> --- a/drivers/gpu/drm/drm_modes.c
>>> +++ b/drivers/gpu/drm/drm_modes.c
>>> @@ -2272,7 +2272,9 @@ struct drm_named_mode {
>>>  
>>>  static const struct drm_named_mode drm_named_modes[] = {
>>> NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
>>> DRM_MODE_TV_MODE_NTSC),
>>> +   NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
>>> DRM_MODE_TV_MODE_NTSC_J),
>>> NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE, 
>>> DRM_MODE_TV_MODE_PAL),
>>> +   NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
>>> DRM_MODE_TV_MODE_PAL_M),
>>>  };
>> I'm now having second thoughts about the tv_mode commandline option. Can
>> we just add all the variants to this table and drop the tv_mode option?
>> IMO this will be more user friendly and less confusing.
>>
> One downside of this is that it's not possible to force connector status
> when using named modes, but I think it would be better to have a force
> option than a tv_mode option. A lot of userspace treats unknown status
> as disconnected.
>
> Anyone know if it's possible to set the connector status sysfs file
> using a udev rule?
>
> Noralf.

I think that leaving named modes only would be a bit limiting. There are use
cases for custom modes, e.g. we might want progressive 240p "NTSC" (like 80s/90s
home computers and video game consoles) or the modes with non-13.5MHz pixel
clock that Geert requested with Amiga in mind.

I'm not sure if the current cmdline-to-drm_mode conversion is flexible enough
to meaningfully facilitate those, but we're at least getting the syntax down.

Best regards,
Mateusz Kwiatkowski

[Intel-gfx] [PATCH 3/3] drm/i915/edp: Fix warning as vdd went down without driver knowledge

2022-11-08 Thread Animesh Manna

Kernel warning triggered as vdd went down after certain time during
aux transfer in connector init sequence. To solve the kernel
warning adjust power domain and vdd wakeref count.
Currently issue seen on ADL so add the above adjustment part of
ADL platform check, if needed will extend for future platform.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Uma Shankar 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_pps.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 0975e49f8d03..1857bbcc6fd4 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -587,8 +587,15 @@ bool intel_pps_vdd_on_unlocked(struct intel_dp *intel_dp)
cancel_delayed_work(_dp->pps.panel_vdd_work);
intel_dp->pps.want_panel_vdd = true;
 
-   if (edp_have_panel_vdd(intel_dp))
+   if (edp_have_panel_vdd(intel_dp)) {
return need_to_disable;
+   } else {
+   if ((IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv)) &&
+   intel_dp->pps.vdd_wakeref)
+   intel_display_power_put(dev_priv,
+   
intel_aux_power_domain(dig_port),
+   
fetch_and_zero(_dp->pps.vdd_wakeref));
+   }
 
drm_WARN_ON(_priv->drm, intel_dp->pps.vdd_wakeref);
intel_dp->pps.vdd_wakeref = intel_display_power_get(dev_priv,
-- 
2.29.0

[Intel-gfx] [PATCH 2/3] drm/i915/pps: Enable 2nd pps for dual EDP scenario

2022-11-08 Thread Animesh Manna

>From display gen12 onwards to support dual EDP two instances of pps added.
Currently backlight controller and pps instance can be mapped together
for a specific panel. Extended support for gen12 for dual EDP usage.

v1: Iniital revision
v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init. [Jani]

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Uma Shankar 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
 drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 9 ++---
 drivers/gpu/drm/i915/display/intel_pps.c  | 2 +-
 4 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index c2987f2c2b2e..fca44be9bab8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct drm_i915_private 
*i915,
return 0;
 }
 
-enum panel_type {
-   PANEL_TYPE_OPREGION,
-   PANEL_TYPE_VBT,
-   PANEL_TYPE_PNPID,
-   PANEL_TYPE_FALLBACK,
-};
-
 static int get_panel_type(struct drm_i915_private *i915,
  const struct intel_bios_encoder_data *devdata,
  const struct edid *edid)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index e375405a7828..da01b13260ae 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -231,6 +231,13 @@ struct mipi_pps_data {
u16 panel_power_cycle_delay;
 } __packed;
 
+enum panel_type {
+   PANEL_TYPE_OPREGION,
+   PANEL_TYPE_VBT,
+   PANEL_TYPE_PNPID,
+   PANEL_TYPE_FALLBACK,
+};
+
 void intel_bios_init(struct drm_i915_private *dev_priv);
 void intel_bios_init_panel(struct drm_i915_private *dev_priv,
   struct intel_panel *panel,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7400d6b4c587..08ece347f7cb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5254,6 +5254,9 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
return false;
}
 
+   intel_bios_init_panel(dev_priv, _connector->panel,
+ encoder->devdata, NULL);
+
intel_pps_init(intel_dp);
 
/* Cache DPCD and EDID for edp. */
@@ -5288,9 +5291,9 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
edid = ERR_PTR(-ENOENT);
}
intel_connector->edid = edid;
-
-   intel_bios_init_panel(dev_priv, _connector->panel,
- encoder->devdata, IS_ERR(edid) ? NULL : edid);
+   if (intel_connector->panel.vbt.panel_type == PANEL_TYPE_FALLBACK)
+   intel_bios_init_panel(dev_priv, _connector->panel,
+ encoder->devdata, IS_ERR(edid) ? NULL : 
edid);
 
intel_panel_add_edid_fixed_modes(intel_connector, true);
 
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 3949fb449353..0975e49f8d03 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1430,7 +1430,7 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(_dp->pps.panel_vdd_work, edp_panel_vdd_work);
 
-   if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+   if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >= 12)
intel_dp->get_pps_idx = bxt_power_sequencer_idx;
else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
-- 
2.29.0

[Intel-gfx] [PATCH 1/3] drm/i915/pps: Add get_pps_idx() hook as part of pps_get_register() cleanup

2022-11-08 Thread Animesh Manna

Simplified pps_get_register() which use get_pps_idx() hook to derive the
pps instance and get_pps_idx() will be initialized at pps_init().

v1: Initial version. Got r-b from Jani.
v2: Corrected unintentional change around memset() call. [Jani]

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Uma Shankar 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_display_types.h |  1 +
 drivers/gpu/drm/i915/display/intel_pps.c   | 14 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c6abaaa46e17..87163ef32983 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1698,6 +1698,7 @@ struct intel_dp {
u8 (*preemph_max)(struct intel_dp *intel_dp);
u8 (*voltage_max)(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state);
+   int (*get_pps_idx)(struct intel_dp *intel_dp);
 
/* Displayport compliance testing */
struct intel_dp_compliance compliance;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 22f5e08d396b..3949fb449353 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -366,11 +366,8 @@ static void intel_pps_get_registers(struct intel_dp 
*intel_dp,
int pps_idx = 0;
 
memset(regs, 0, sizeof(*regs));
-
-   if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
-   pps_idx = bxt_power_sequencer_idx(intel_dp);
-   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-   pps_idx = vlv_power_sequencer_pipe(intel_dp);
+   if (intel_dp->get_pps_idx)
+   pps_idx = intel_dp->get_pps_idx(intel_dp);
 
regs->pp_ctrl = PP_CONTROL(pps_idx);
regs->pp_stat = PP_STATUS(pps_idx);
@@ -1433,6 +1430,13 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(_dp->pps.panel_vdd_work, edp_panel_vdd_work);
 
+   if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+   intel_dp->get_pps_idx = bxt_power_sequencer_idx;
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
+   else
+   intel_dp->get_pps_idx = NULL;
+
pps_init_timestamps(intel_dp);
 
with_intel_pps_lock(intel_dp, wakeref) {
-- 
2.29.0

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output

2022-11-08 Thread John Harrison


On 11/8/2022 01:01, Tvrtko Ursulin wrote:

On 07/11/2022 19:14, John Harrison wrote:

On 11/7/2022 08:17, Tvrtko Ursulin wrote:

On 07/11/2022 09:33, Tvrtko Ursulin wrote:

On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:

On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:

From: John Harrison 

When trying to analyse bug reports from CI, customers, etc. it 
can be

difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but 
with

a GT# prefix on it.

Signed-off-by: John Harrison 


The only downside to this is that we'll print "GT0: " even on 
single-GT devices. We could introduce a gt->info.name and print 
that, so we could have it different per-platform, but IMO it's not 
worth the effort.


Reviewed-by: Daniele Ceraolo Spurio 

I think it might be worth getting an ack from one of the 
maintainers to make sure we're all aligned on transitioning to 
these new logging macro for gt code.


Idea is I think a very good one. First I would suggest 
standardising to lowercase GT in logs because:


$ grep "GT%" i915/ -r
$ grep "gt%" i915/ -r
i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
i915/gt/intel_gt_sysfs.c:    "failed to initialize gt%d 
sysfs root\n", gt->info.id);
i915/gt/intel_gt_sysfs_pm.c: "failed to create 
gt%u RC6 sysfs files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs 
files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create 
gt%u RPS sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create 
gt%u punit_req_freq_mhz sysfs (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle sysfs 
files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u 
media_perf_power_attrs sysfs (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to add 
gt%u rps defaults (%pe)\n",
i915/i915_driver.c: drm_err(>i915->drm, "gt%d: intel_pcode_init 
failed %d\n", id, ret);
i915/i915_hwmon.c:  snprintf(ddat_gt->name, 
sizeof(ddat_gt->name), "i915_gt%u", i);




Just because there are 11 existing instances of one form doesn't mean 
that the 275 instances that are waiting to be converted should be 
done incorrectly. GT is an acronym and should be capitalised.


Okay just make it consistent then.


Besides:
grep -r "GT " i915 | grep '"'
i915/vlv_suspend.c: drm_err(>drm, "timeout 
disabling GT waking\n");
i915/vlv_suspend.c: "timeout waiting for GT wells 
to go %s\n",
i915/vlv_suspend.c: drm_dbg(>drm, "GT register access while 
GT waking disabled\n");
i915/i915_gpu_error.c:  err_printf(m, "GT awake: %s\n", 
str_yes_no(gt->awake));

i915/i915_debugfs.c:    seq_printf(m, "GT awake? %s [%d], %llums\n",
i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on %s)", 
engine->name);
i915/intel_uncore.c:  "GT thread status wait timed 
out\n");
i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>i915->drm, "GT 
failed to idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to 
idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to 
idle: %d\n", ret);
i915/gt/intel_gt_mcr.c: * Some GT registers are designed as 
"multicast" or "replicated" registers:
i915/gt/selftest_rps.c: pr_info("%s: rps counted %d 
C0 cycles [%lldns] in %lldns [%d cycles], using GT clock frequency of 
%uKHz\n",
i915/gt/selftest_hangcheck.c:   pr_err("[%s] GT is 
wedged!\n", engine->name);

i915/gt/selftest_hangcheck.c:   pr_err("GT is wedged!\n");
i915/gt/intel_gt_clock_utils.c: "GT clock frequency 
changed, was %uHz, now %uHz!\n",
i915/gt/selftest_engine_pm.c:   pr_err("Unable to flush GT pm 
before test\n");

i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
i915/i915_sysfs.c:   "failed to register GT sysfs 
directory\n");
i915/intel_uncore.h: * of the basic non-engine GT registers 
(referred to as "GSI" on
i915/intel_uncore.h: * newer platforms, or "GT block" on older 
platforms)?  If so, we'll




Then there is a question of naming. Are we okay with GT_XXX or, do 
we want intel_gt_, or something completely different. I don't have 
a strong opinion at the moment so I'll add some more folks to Cc.


You mean GT_ERR("msg") vs intel_gt_err("msg")? Personally, I would 
prefer just gt_err("msg") to keep it as close to the official drm_* 
versions as possible. Print lines tend to be excessively long 
already. Taking a 'gt' parameter instead of a '>i915->drm' 
parameter does help with that but it seems like calling the wrapper 
intel_gt_* is shooting ourselves in the foot on that one. And GT_ERR 
vs gt_err just comes down to the fact that it is a macro wrapper and 
therefore is required to be in upper case.


There was a maintainer level

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines (rev2)

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that 
have VCS engines (rev2)
URL   : https://patchwork.freedesktop.org/series/110646/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12356 -> Patchwork_110646v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 38)
--

  Additional (1): bat-atsm-1 
  Missing(5): fi-ilk-m540 fi-ctg-p8600 fi-hsw-4770 fi-pnv-d510 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@migrate:
- {bat-atsm-1}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_selftest@live@hugepages:
- fi-bsw-nick:[DMESG-FAIL][4] ([i915#6217]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12356/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110646v2/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
  [i915#6077]: https://gitlab.freedesktop.org/drm/intel/issues/6077
  [i915#6078]: https://gitlab.freedesktop.org/drm/intel/issues/6078
  [i915#6093]: https://gitlab.freedesktop.org/drm/intel/issues/6093
  [i915#6094]: https://gitlab.freedesktop.org/drm/intel/issues/6094
  [i915#6166]: https://gitlab.freedesktop.org/drm/intel/issues/6166
  [i915#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
  [i915#7357]: https://gitlab.freedesktop.org/drm/intel/issues/7357
  [i915#7358]: https://gitlab.freedesktop.org/drm/intel/issues/7358


Build changes
-

  * Linux: CI_DRM_12356 -> Patchwork_110646v2

  CI-20190529: 20190529
  CI_DRM_12356: 1278975de8debde9eb1f5d86fd2fbe533361e456 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7048: 5edd5c539f1fdf1c02157bf43fa1fd22d4ad2c75 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110646v2: 1278975de8debde9eb1f5d86fd2fbe533361e456 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

5c2053064b1d drm/i915/guc: handle interrupts from media GuC
ffee3ba6f389 drm/i915/guc: define media GT GuC send regs
efeb8e6b1fbc drm/i915/mtl: Handle wopcm per-GT and limit calculations.
caed9b0a0c56 drm/i915/guc: Add GuC deprivilege feature to MTL
0da74eda6f16 drm/i915/uc: use different ggtt pin offsets for uc loads
9897b6259b28 drm/i915/uc: fetch uc firmwares for each GT
b5743d73560a drm/i915/huc: only load HuC on GTs that have VCS engines

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Partial abandonment of legacy DRM logging macros

2022-11-08 Thread John Harrison


On 11/8/2022 04:26, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.

v2:
  * Don't have struct drm_device as local. (Jani, Ville)

Signed-off-by: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: John Harrison 
Cc: Ville Syrjälä 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 26 +++
  .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
  drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
  drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
  .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
  .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
  drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
  drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
  drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
  drivers/gpu/drm/i915/i915_query.c | 12 +++---
  drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
  drivers/gpu/drm/i915/i915_vma.c   | 16 ---
  drivers/gpu/drm/i915/intel_uncore.c   | 21 +
  19 files changed, 119 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 01402f3c58f6..7f2831efc798 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
__user *base, void *data)
}
  
  	if (intel_engine_uses_guc(master)) {

-   DRM_DEBUG("bonding extension not supported with GuC 
submission");
+   drm_dbg(>drm, "bonding extension not supported with GuC 
submission");
return -ENODEV;
}
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 1160723c9d2d..f65fd03f7cf2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
return err;
  }
  
-static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)

+static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
+struct drm_i915_gem_execbuffer2 *exec)
  {
if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
return -EINVAL;
@@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
}
  
  	if (exec->DR4 == 0x) {

-   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
exec->DR4 = 0;
}
if (exec->DR1 || exec->DR4)
@@ -2799,7 +2800,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
  
  		syncobj = drm_syncobj_find(eb->file, user_fence.handle);

if (!syncobj) {
-   DRM_DEBUG("Invalid syncobj handle provided\n");
+   drm_dbg(>i915->drm,
+   "Invalid syncobj handle provided\n");
return -ENOENT;
}
  
@@ -2807,7 +2809,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
  
  		if (!fence && user_fence.flags &&

!(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
-   DRM_DEBUG("Syncobj handle has no fence\n");
+   drm_dbg(>i915->drm,
+   "Syncobj handle has no fence\n");
drm_syncobj_put(syncobj);
return -EINVAL;
}
@@ -2816,7 +2819,9 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
err = dma_fence_chain_find_seqno(, point);
  
  		if (err && !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {

-   DRM_DEBUG("Syncobj handle missing requested point 
%llu\n", point);
+   drm_dbg(>i915->drm,
+   "Syncobj handle missing requested point %llu\n",
+   point);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return err;
@@ -2842,7 +2847,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 * 0) would break the timeline.
 */
if (user_fence.flags & I915_EXEC_FENCE_WAIT) {
-   DRM_DEBUG("Trying to wait & signal the same timeline 
point.\n");
+

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches

2022-11-08 Thread John Harrison


On 11/8/2022 01:08, Tvrtko Ursulin wrote:

On 07/11/2022 19:45, John Harrison wrote:

On 11/7/2022 06:09, Tvrtko Ursulin wrote:

On 04/11/2022 17:45, John Harrison wrote:

On 11/4/2022 03:01, Tvrtko Ursulin wrote:

On 03/11/2022 19:16, John Harrison wrote:

On 11/3/2022 02:38, Tvrtko Ursulin wrote:

On 03/11/2022 09:18, Tvrtko Ursulin wrote:

On 03/11/2022 01:33, John Harrison wrote:

On 11/2/2022 07:20, Tvrtko Ursulin wrote:

On 02/11/2022 12:12, Jani Nikula wrote:

On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

At the end of each test, IGT does a drop caches call via 
sysfs with


sysfs?
Sorry, that was meant to say debugfs. I've also been working 
on some sysfs IGT issues and evidently got my wires crossed!




special flags set. One of the possible paths waits for idle 
with an
infinite timeout. That causes problems for debugging issues 
when CI
catches a "can't go idle" test failure. Best case, the CI 
system times
out (after 90s), attempts a bunch of state dump actions and 
then
reboots the system to recover it. Worst case, the CI system 
can't do
anything at all and then times out (after 1000s) and simply 
reboots.
Sometimes a serial port log of dmesg might be available, 
sometimes not.


So rather than making life hard for ourselves, change the 
timeout to

be 10s rather than infinite. Also, trigger the standard
wedge/reset/recover sequence so that testing can continue 
with a

working system (if possible).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

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

index ae987e92251dd..9d916fbbfc27c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -641,6 +641,9 @@ 
DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,

    DROP_RESET_ACTIVE | \
    DROP_RESET_SEQNO | \
    DROP_RCU)
+
+#define DROP_IDLE_TIMEOUT    (HZ * 10)


I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's 
also only used

here.


So move here, dropping i915 prefix, next to the newly 
proposed one?

Sure, can do that.



I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only 
used in

gt/intel_gt.c.


Move there and rename to GT_IDLE_TIMEOUT?

I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in 
intel_gt_pm.c.


No action needed, maybe drop i915 prefix if wanted.

These two are totally unrelated and in code not being touched 
by this change. I would rather not conflate changing random 
other things with fixing this specific issue.



I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies.


Add _MS suffix if wanted.


My head spins.


I follow and raise that the newly proposed DROP_IDLE_TIMEOUT 
applies to DROP_ACTIVE and not only DROP_IDLE.
My original intention for the name was that is the 'drop 
caches timeout for intel_gt_wait_for_idle'. Which is quite the 
mouthful and hence abbreviated to DROP_IDLE_TIMEOUT. But yes, 
I realised later that name can be conflated with the DROP_IDLE 
flag. Will rename.





Things get refactored, code moves around, bits get left 
behind, who knows. No reason to get too worked up. :) As long 
as people are taking a wider view when touching the code 
base, and are not afraid to send cleanups, things should be 
good.
On the other hand, if every patch gets blocked in code review 
because someone points out some completely unrelated piece of 
code could be a bit better then nothing ever gets fixed. If 
you spot something that you think should be improved, isn't 
the general idea that you should post a patch yourself to 
improve it?


There's two maintainers per branch and an order of magnitude or 
two more developers so it'd be nice if cleanups would just be 
incoming on self-initiative basis. ;)


For the actual functional change at hand - it would be nice 
if code paths in question could handle SIGINT and then we 
could punt the decision on how long someone wants to wait 
purely to userspace. But it's probably hard and it's only 
debugfs so whatever.


The code paths in question will already abort on a signal 
won't they? Both intel_gt_wait_for_idle() and 
intel_guc_wait_for_pending_msg(), which is where the 
uc_wait_for_idle eventually ends up, have an 
'if(signal_pending) return -EINTR;' check. Beyond that, it 
sounds like what you are asking for is a change in the IGT 
libraries and/or CI framework to start sending signals after 
some specific timeout. That seems like a significantly more 
complex change (in terms of the number of entities affected 
and number of groups involved) and unnecessary.


If you say so, I haven't looked at them all. But if the code 
path in question already aborts on signals then I am not sure 
what is the patch fixing? I assumed you are trying to avoid the 
write stuck in D forever, which then prevents driver unload and 
everything, requiring the test runner to eventually reboot. If 
you

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: never purge busy objects

== Series Details ==

Series: drm/i915/ttm: never purge busy objects
URL   : https://patchwork.freedesktop.org/series/110601/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12351_full -> Patchwork_110601v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@engine-order:
- shard-tglb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-tglb1/igt@i915_pm_...@engine-order.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/shard-tglb1/igt@i915_pm_...@engine-order.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines (rev2)

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that 
have VCS engines (rev2)
URL   : https://patchwork.freedesktop.org/series/110646/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines (rev2)

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that 
have VCS engines (rev2)
URL   : https://patchwork.freedesktop.org/series/110646/
State : warning

== Summary ==

Error: dim checkpatch failed
5d5b41d0c6b7 drm/i915/huc: only load HuC on GTs that have VCS engines
-:44: 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
#44: FILE: drivers/gpu/drm/i915/gt/uc/intel_huc.c:227:
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);

total: 0 errors, 1 warnings, 0 checks, 59 lines checked
65b14690dc70 drm/i915/uc: fetch uc firmwares for each GT
79a95783a7b8 drm/i915/uc: use different ggtt pin offsets for uc loads
-:66: 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
#66: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:704:
+   GEM_BUG_ON(gt->type == GT_MEDIA && gt->info.id > 1);

-:73: 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
#73: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:711:
+   GEM_BUG_ON(offset + uc_fw->obj->base.size > node->size);

-:74: 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
#74: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:712:
+   GEM_BUG_ON(uc_fw->obj->base.size > INTEL_UC_RSVD_GGTT_PER_FW);

total: 0 errors, 3 warnings, 0 checks, 82 lines checked
1f241d7bf14b drm/i915/guc: Add GuC deprivilege feature to MTL
8d4c91c06b88 drm/i915/mtl: Handle wopcm per-GT and limit calculations.
-:113: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#113: 
rename from drivers/gpu/drm/i915/intel_wopcm.c

-:278: 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
#278: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:567:
+   GEM_BUG_ON(!gt->wopcm.size);

total: 0 errors, 2 warnings, 0 checks, 240 lines checked
5e40143ea58d drm/i915/guc: define media GT GuC send regs
9724cc84a969 drm/i915/guc: handle interrupts from media GuC

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: ELD precompute and readout (rev3)

== Series Details ==

Series: drm/i915: ELD precompute and readout (rev3)
URL   : https://patchwork.freedesktop.org/series/109592/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12355 -> Patchwork_109592v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 38)
--

  Additional (1): fi-hsw-4770 
  Missing(5): fi-ilk-m540 fi-tgl-dsi fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#7073])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

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

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

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

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

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

  
 Possible fixes 

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [INCOMPLETE][13] ([i915#7308] / [i915#7348]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- {bat-rpls-1}:   [DMESG-FAIL][15] ([i915#6367]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-edp-1:
- fi-bsw-kefka:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/fi-bsw-kefka/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109592v3/fi-bsw-kefka/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3012]:

Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices

On Tue, Nov 08, 2022 at 03:41:25PM +0800, Yi Liu wrote:
> On 2022/11/8 14:10, Nicolin Chen wrote:
> > On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
> > 
> > > @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct vfio_device 
> > > *device)
> > >   ret = vfio_group_use_container(device->group);
> > >   if (ret)
> > >   goto err_module_put;
> > > + } else if (device->group->iommufd) {
> > > + ret = vfio_iommufd_bind(device, device->group->iommufd);
> > 
> > Here we check device->group->iommufd...
> > 
> > > + if (ret)
> > > + goto err_module_put;
> > >   }
> > >   device->kvm = device->group->kvm;
> > > @@ -812,6 +821,7 @@ static int vfio_device_first_open(struct vfio_device 
> > > *device)
> > >   device->kvm = NULL;
> > >   if (device->group->container)
> > >   vfio_group_unuse_container(device->group);
> > > + vfio_iommufd_unbind(device);
> > 
> > ...yet, missing here, which could result in kernel oops.
> > 
> > Should probably add something similar:
> > +   if (device->group->iommufd)
> > +   vfio_iommufd_unbind(device);
> > 
> > Or should check !vdev->iommufd_device inside the ->unbind.
> 
> this check was in prior version, but removed in this version. any
> special reason? Jason?

Oooh, this makes more sense - Kevin pointed out the check was wrong:

> > +void vfio_iommufd_unbind(struct vfio_device *vdev)
> > +{
> > +   lockdep_assert_held(>dev_set->lock);
> > +
> > +   if (!vdev->iommufd_device)
> > +   return;

> there is no iommufd_device in the emulated path...

And he is right, so I dropped it. But really the check was just
misspelled, it was supposed to be "device->group->iommufd" because the
caller assumed it.

Still, I think the right way to fix it is to lift the check as we
don't touch group->iommufd in iommufd.c

Thanks,
Jason

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Partial abandonment of legacy DRM logging macros (rev2)

== Series Details ==

Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev2)
URL   : https://patchwork.freedesktop.org/series/110660/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12354_full -> Patchwork_110660v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices

On Mon, Nov 07, 2022 at 10:10:59PM -0800, Nicolin Chen wrote:

> > @@ -812,6 +821,7 @@ static int vfio_device_first_open(struct vfio_device 
> > *device)
> > device->kvm = NULL;
> > if (device->group->container)
> > vfio_group_unuse_container(device->group);
> > +   vfio_iommufd_unbind(device);
> 
> ...yet, missing here, which could result in kernel oops.
> 
> Should probably add something similar:
> + if (device->group->iommufd)
> + vfio_iommufd_unbind(device);
> 
> Or should check !vdev->iommufd_device inside the ->unbind.

Lets keep it symmetric since the container is checked:

@@ -821,7 +821,8 @@ static int vfio_device_first_open(struct vfio_device 
*device)
device->kvm = NULL;
if (device->group->container)
vfio_group_unuse_container(device->group);
-   vfio_iommufd_unbind(device);
+   else if (device->group->iommufd)
+   vfio_iommufd_unbind(device);
 err_module_put:
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);
@@ -840,7 +841,8 @@ static void vfio_device_last_close(struct vfio_device 
*device)
device->kvm = NULL;
if (device->group->container)
vfio_group_unuse_container(device->group);
-   vfio_iommufd_unbind(device);
+   else if (device->group->iommufd)
+   vfio_iommufd_unbind(device);
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);

Thanks,
Jason

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: ELD precompute and readout (rev3)

== Series Details ==

Series: drm/i915: ELD precompute and readout (rev3)
URL   : https://patchwork.freedesktop.org/series/109592/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: ELD precompute and readout (rev3)

== Series Details ==

Series: drm/i915: ELD precompute and readout (rev3)
URL   : https://patchwork.freedesktop.org/series/109592/
State : warning

== Summary ==

Error: dim checkpatch failed
c4aa4dddc007 drm/i915/audio: Don't program the hardware ELD buffer on ilk+
c76e56062fbb drm/i915/audio: Don't program the hardware ELD buffer on hsw+
-:33: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#33: 
References: 
https://lore.kernel.org/intel-gfx/20221012104936.30911-1-ville.syrj...@linux.intel.com/

total: 0 errors, 1 warnings, 0 checks, 56 lines checked
8f2e43fd7ce9 drm/i915/audio: Unify get_saved_enc()
bb1c3179fbb5 drm/i915/audio: Realign some function arguments
443c4ced0b86 drm/i915/audio: Introduce a struct for the acomp audio state
-:248: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"audio_state->connector"
#248: FILE: drivers/gpu/drm/i915/display/intel_audio.c:1175:
+   *enabled = audio_state->connector != NULL;

total: 0 errors, 0 warnings, 1 checks, 253 lines checked
1a67a5edff2d drm/i915/audio: Precompute the ELD
-:133: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"audio_state->encoder"
#133: FILE: drivers/gpu/drm/i915/display/intel_audio.c:1187:
+   *enabled = audio_state->encoder != NULL;

total: 0 errors, 0 warnings, 1 checks, 164 lines checked
7c9d5d385179 drm/i915/audio: Don't enable audio with bogus ELD
0a0921ed2c75 drm/i915/audio: Hardware ELD readout
f1217d882f77 drm/i915/sdvo: Precompute the ELD
f5f865143008 drm/i915/sdvo: Only use "presence detect" for has_audio readout
36be705edf36 drm/i915/sdvo: Do ELD hardware readout
b9731e6e19f4 drm/i915/audio: Hook up ELD into the state checker
-:72: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible 
side-effects?
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:5710:
+#define PIPE_CONF_CHECK_BUFFER(name, len) do { \
+   BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
+   BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
+   if (!intel_compare_buffer(current_config->name, pipe_config->name, 
(len))) { \
+   pipe_config_buffer_mismatch(dev_priv, fastset, 
__stringify(name), \
+   current_config->name, \
+   pipe_config->name, \
+   (len)); \
+   ret = false; \
+   } \
+} while (0)

-:72: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as 
'(name)' to avoid precedence issues
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:5710:
+#define PIPE_CONF_CHECK_BUFFER(name, len) do { \
+   BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
+   BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
+   if (!intel_compare_buffer(current_config->name, pipe_config->name, 
(len))) { \
+   pipe_config_buffer_mismatch(dev_priv, fastset, 
__stringify(name), \
+   current_config->name, \
+   pipe_config->name, \
+   (len)); \
+   ret = false; \
+   } \
+} while (0)

-:72: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'len' - possible side-effects?
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:5710:
+#define PIPE_CONF_CHECK_BUFFER(name, len) do { \
+   BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
+   BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
+   if (!intel_compare_buffer(current_config->name, pipe_config->name, 
(len))) { \
+   pipe_config_buffer_mismatch(dev_priv, fastset, 
__stringify(name), \
+   current_config->name, \
+   pipe_config->name, \
+   (len)); \
+   ret = false; \
+   } \
+} while (0)

total: 0 errors, 0 warnings, 3 checks, 67 lines checked
dede93fe868f drm/i915/audio: Include ELD in the state dump
b3b99c69a060 drm/i915/audio: s/ilk/ibx/
387c2eaf84e7 drm/i915/audio: Clean up the PCH type checks

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)

== Series Details ==

Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)
URL   : https://patchwork.freedesktop.org/series/110433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12355 -> Patchwork_110433v8


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 39)
--

  Additional (1): fi-hsw-4770 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-tgl-dsi 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#7056])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

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

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

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

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

  
 Possible fixes 

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [INCOMPLETE][11] ([i915#7308] / [i915#7348]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][13] ([i915#4983]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [DMESG-FAIL][15] ([i915#6997]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/bat-adln-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-edp-1:
- fi-bsw-kefka:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12355/fi-bsw-kefka/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110433v8/fi-bsw-kefka/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#4312]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)

== Series Details ==

Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)
URL   : https://patchwork.freedesktop.org/series/110433/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)

== Series Details ==

Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev8)
URL   : https://patchwork.freedesktop.org/series/110433/
State : warning

== Summary ==

Error: dim checkpatch failed
f6043b9389ee drm/i915: Allocate power domain set wakerefs dynamically
-:112: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#112: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:876:
+
+}

total: 0 errors, 0 warnings, 1 checks, 191 lines checked
86c2dfc43e8b drm/i915: Move the POWER_DOMAIN_AUX_IO_A definition to its logical 
place
31dbe0fcb5c6 drm/i915: Use the AUX_IO power domain only for eDP/PSR port
6d2e3fc68ba2 drm/i915/tgl+: Enable display DC power states on all eDP ports
-:330: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#330: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:694:
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_b,
+   POWER_DOMAIN_AUX_IO_B,

-:333: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#333: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:697:
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_c,
+   POWER_DOMAIN_AUX_IO_C,

-:336: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#336: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:700:
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_d,
+   POWER_DOMAIN_AUX_IO_D,

-:339: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#339: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:703:
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_e,
+   POWER_DOMAIN_AUX_IO_E,

-:342: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#342: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:706:
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_f,
+   POWER_DOMAIN_AUX_IO_F,

total: 0 errors, 0 warnings, 5 checks, 285 lines checked
da361d14d8ef drm/i915: Add missing AUX_IO_A power domain->well mappings
8384e7066e8d drm/i915: Add missing DC_OFF power domain->well mappings
6237dc05ca11 drm/i915: Factor out function to get/put AUX_IO power for main link
4770b792f5fb drm/i915: Don't enable the AUX_IO power for combo-PHY external DP 
port main links
94f242b405f3 drm/i915/mtl+: Don't enable the AUX_IO power for non-eDP port main 
links

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: use i915_sg_dma_sizes() for all backends (rev2)

== Series Details ==

Series: drm/i915: use i915_sg_dma_sizes() for all backends (rev2)
URL   : https://patchwork.freedesktop.org/series/110620/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12354_full -> Patchwork_110620v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[FAIL][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50]) ([i915#4392])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk9/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk8/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk8/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk8/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk7/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk6/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk5/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk5/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/shard-glk3/boot.html
   [43]:

Re: [Intel-gfx] [PATCH v2 04/15] drm/i915/audio: Realign some function arguments

On Tue, 08 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Fix up some function argument alignment fails.
>
> Cc: Chaitanya Kumar Borah 
> Cc: Kai Vehmanen 
> Cc: Takashi Iwai 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 0ac28d28098f..6b0c2b0522fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -778,8 +778,8 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>  
>   if (i915->display.funcs.audio)
>   i915->display.funcs.audio->audio_codec_enable(encoder,
> -   crtc_state,
> -   conn_state);
> +   crtc_state,
> +   conn_state);
>  
>   mutex_lock(>display.audio.mutex);
>   encoder->audio_connector = connector;
> @@ -794,7 +794,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
>   pipe = -1;
>   
> acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
> -  (int) port, (int) pipe);
> +   (int)port, (int)pipe);
>   }
>  
>   intel_lpe_audio_notify(i915, pipe, port, connector->eld,
> @@ -831,8 +831,8 @@ void intel_audio_codec_disable(struct intel_encoder 
> *encoder,
>  
>   if (i915->display.funcs.audio)
>   i915->display.funcs.audio->audio_codec_disable(encoder,
> -
> old_crtc_state,
> -
> old_conn_state);
> +old_crtc_state,
> +old_conn_state);
>  
>   mutex_lock(>display.audio.mutex);
>   encoder->audio_connector = NULL;
> @@ -845,7 +845,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> *encoder,
>   if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
>   pipe = -1;
>   
> acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
> -  (int) port, (int) pipe);
> +   (int)port, (int)pipe);
>   }
>  
>   intel_lpe_audio_notify(i915, pipe, port, NULL, 0, false);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2 03/15] drm/i915/audio: Unify get_saved_enc()

On Tue, 08 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Make the two branches of get_saved_enc() look alike. Currently
> they look different even though they do exactly the same thing
> apart from == vs. != for the MST comparison.
>
> Cc: Chaitanya Kumar Borah 
> Cc: Kai Vehmanen 
> Cc: Takashi Iwai 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 0a53731a9272..0ac28d28098f 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -1069,10 +1069,10 @@ static int i915_audio_component_get_cdclk_freq(struct 
> device *kdev)
>  static struct intel_encoder *get_saved_enc(struct drm_i915_private *i915,
>  int port, int pipe)
>  {
> - struct intel_encoder *encoder;
> -
>   /* MST */
>   if (pipe >= 0) {
> + struct intel_encoder *encoder;
> +
>   if (drm_WARN_ON(>drm,
>   pipe >= 
> ARRAY_SIZE(i915->display.audio.encoder_map)))
>   return NULL;
> @@ -1083,7 +1083,7 @@ static struct intel_encoder *get_saved_enc(struct 
> drm_i915_private *i915,
>* MST or not. So it will poll all the port & pipe
>* combinations
>*/
> - if (encoder != NULL && encoder->port == port &&
> + if (encoder && encoder->port == port &&
>   encoder->type == INTEL_OUTPUT_DP_MST)
>   return encoder;
>   }
> @@ -1093,14 +1093,12 @@ static struct intel_encoder *get_saved_enc(struct 
> drm_i915_private *i915,
>   return NULL;
>  
>   for_each_pipe(i915, pipe) {
> + struct intel_encoder *encoder;
> +
>   encoder = i915->display.audio.encoder_map[pipe];
> - if (encoder == NULL)
> - continue;
>  
> - if (encoder->type == INTEL_OUTPUT_DP_MST)
> - continue;
> -
> - if (port == encoder->port)
> + if (encoder && encoder->port == port &&
> + encoder->type != INTEL_OUTPUT_DP_MST)
>   return encoder;
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support

2022-11-08 Thread Niranjana Vishwanathapura


On Mon, Nov 07, 2022 at 05:39:34PM -0800, Zanoni, Paulo R wrote:

On Mon, 2022-11-07 at 00:52 -0800, Niranjana Vishwanathapura wrote:

Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.

No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.


Can you please provide some more details on how this works from the
user space point of view? I want to be able to know with 100% certainty
if an unbind has already happened, so I can reuse that vma or whatever
else I may decide to do. I see the interface does not provide any sort
of drm_syncobjs for me to wait on the async unbind. So, when does the
unbind really happen? When can I be sure it's past so I can do stuff
with it? Why would you provide an async ioctl and provide no means for
user space to wait on it?



Paulo,
The async vm_unbind here is not transparent to user space. From user space
point of view, it is like synchronous and they can reuse the assigned virtual
address immediately after vm_unbind ioctl returns. The i915 driver will
ensure that the unbind completes before there is a rebind at that virtual
address. So, unless there is error from user programming where GPU tries to
access the buffer even after user doing the vm_unbind, it should be fine.

Regards,
Niranjana


Thanks,
Paulo



Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c | 51 ++---
 drivers/gpu/drm/i915/i915_vma.h |  1 +
 2 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 08218e3a2f12..03c966fad87b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
 #include "i915_vma.h"
 #include "i915_vma_resource.h"
 



+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
 static inline void assert_vma_held_evict(const struct i915_vma *vma)
 {
    /*
@@ -1711,7 +1713,7 @@ void i915_vma_reopen(struct i915_vma *vma)
    spin_unlock_irq(>closed_lock);
 }
 



-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
 {
    if (!drm_mm_node_allocated(>node))
    return;
@@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
    i915_vma_set_purged(vma);
 



    atomic_and(~I915_VMA_PIN_MASK, >flags);
-   WARN_ON(__i915_vma_unbind(vma));
+   if (async) {
+   struct dma_fence *fence;
+
+   fence = __i915_vma_unbind_async(vma);
+   if (IS_ERR_OR_NULL(fence)) {
+   async = false;
+   } else {
+   dma_resv_add_fence(vma->obj->base.resv, fence,
+  DMA_RESV_USAGE_READ);
+   dma_fence_put(fence);
+   }
+   }
+
+   if (!async)
+   WARN_ON(__i915_vma_unbind(vma));
    GEM_BUG_ON(drm_mm_node_allocated(>node));
 }
 



@@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
 {
    lockdep_assert_held(>vm->mutex);
 



-   force_unbind(vma);
+   force_unbind(vma, false);
    list_del_init(>vm_link);
    release_references(vma, vma->vm->gt, false);
 }
@@ -1796,7 +1812,34 @@ void i915_vma_destroy(struct i915_vma *vma)
    bool vm_ddestroy;
 



    mutex_lock(>vm->mutex);
-   force_unbind(vma);
+   force_unbind(vma, false);
+   list_del_init(>vm_link);
+   vm_ddestroy = vma->vm_ddestroy;
+   vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
+   mutex_unlock(>vm->mutex);
+   release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+   bool vm_ddestroy, async = vma->obj->mm.rsgt;
+   struct intel_gt *gt;
+
+   if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+   async = false;
+
+   mutex_lock(>vm->mutex);
+   /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+   if (async && i915_active_wait(>active))
+   async = false;
+
+   force_unbind(vma, async);
    list_del_init(>vm_link);
    vm_ddestroy = vma->vm_ddestroy;
    vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
 



 void i915_vma_destroy_locked(struct i915_vma *vma);
 void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
 



 #define

Re: [Intel-gfx] [PATCH] drm/edid/firmware: stop using throwaway platform device

2022-11-08 Thread Matthieu CHARETTE

I didn't test the patch yet. I will do. But even without testing I can
tell you that it will work (It will not crash).
Currently when the crash occurs, all screens remain black after resume.
I'm not able to login with ssh neither. And logs end before the
suspend. So the crash seems to be some kind of kernel panic.

Matthieu

On Tue, Nov 8 2022 at 01:27:33 PM +0200, Jani Nikula
wrote:
On Sun, 06 Nov 2022, Matthieu CHARETTE
wrote:

Hi,

Can you tell me what are we waiting for? Maybe I can help.

Have you tried the patch? Is it an improvement over the status quo?

The "crash" is still ambiguous to me. Do you observe it with the
patch?

Do you have logs? Etc.

BR,
Jani.

Thanks.

Matthieu

On Wed, Oct 12 2022 at 07:16:29 PM +0200, Matthieu CHARETTE
wrote:

By crash, I mean that an error is returned here:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/refs/heads/master/drivers/gpu/drm/drm_edid_load.c#195
I don't really know what happens next, but on my machine the
built-in

screen and the external remains dark. Also the kernel seems to
freeze. I suspect a kernel panic, but I'm not sure. Anyway, the
error

is definitely not well handled, and a fix would be great.
Also, request_firmware() will crash if called for the first time on
the resume path because the file system isn't reachable on the
resume
process. And no cache is available for this firmware. So I guess
that

in this case, request_firmware() returns an error.
Suspend-plug-resume case is not my priority nether as long as it
doesn't make the system crash (Which is currently the case).

On Wed, Oct 12 2022 at 11:25:59 AM +0300, Jani Nikula
wrote:
On Tue, 11 Oct 2022, Matthieu CHARETTE

wrote:
Currently the EDID is requested during the resume. But since
it's
requested too early, this means before the filesystem is
mounted,

the
firmware request fails. This make the DRM driver crash when
resuming.
This kind of issue should be prevented by the firmware caching
process
which cache every firmware requested for the next resume. But
since we
are using a temporary device, the firmware isn't cached on
suspend

since the device doesn't work anymore.
When using a non temporary device to get the EDID, the firmware
will
be cached on suspend for the next resume. So requesting the
firmware
during resume will succeed.
But if the firmware has never been requested since the boot,
this

means that the monitor isn't plugged since the boot. The kernel
will
not be caching the EDID. So if we plug the monitor while the
machine
is suspended. The resume will fail to load the firmware. And the
DRM
driver will crash.
So basically, your fix should solve the issue except for the
case

where the monitor hasn't been plugged since boot and is plugged
while
the machine is suspended.
I hope I was clear. Tell me if I wasn't. I'm not really good at
explaining.

That was a pretty good explanation. The only thing I'm missing is
what
the failure mode is exactly when you claim the driver will crash.
Why
would request_firmware() "crash" if called for the first time on
the

resume path?

I'm not sure I care much about not being able to load the firmware
EDID
in the suspend-plug-resume case (as this can be remedied with a
subsequent modeset), but obviously any errors need to be handled
gracefully, without crashing.

BR,
Jani.

--
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v2 15/15] drm/i915/audio: Clean up the PCH type checks

From: Ville Syrjälä 

Use explicit PCH type checks to make it more clear
which platforms use which codepaths.

Also reorder the branches in ibx_audio_regs_init()
a bit to be more in chronological order.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 4286f7a7cc76..847c7a9ddb06 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -666,21 +666,21 @@ static void ibx_audio_regs_init(struct drm_i915_private 
*i915,
enum pipe pipe,
struct ibx_audio_regs *regs)
 {
-   if (HAS_PCH_IBX(i915)) {
-   regs->hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
-   regs->aud_config = IBX_AUD_CFG(pipe);
-   regs->aud_cntl_st = IBX_AUD_CNTL_ST(pipe);
-   regs->aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
-   } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
+   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
regs->hdmiw_hdmiedid = VLV_HDMIW_HDMIEDID(pipe);
regs->aud_config = VLV_AUD_CFG(pipe);
regs->aud_cntl_st = VLV_AUD_CNTL_ST(pipe);
regs->aud_cntrl_st2 = VLV_AUD_CNTL_ST2;
-   } else {
+   } else if (HAS_PCH_CPT(i915)) {
regs->hdmiw_hdmiedid = CPT_HDMIW_HDMIEDID(pipe);
regs->aud_config = CPT_AUD_CFG(pipe);
regs->aud_cntl_st = CPT_AUD_CNTL_ST(pipe);
regs->aud_cntrl_st2 = CPT_AUD_CNTRL_ST2;
+   } else if (HAS_PCH_IBX(i915)) {
+   regs->hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
+   regs->aud_config = IBX_AUD_CFG(pipe);
+   regs->aud_cntl_st = IBX_AUD_CNTL_ST(pipe);
+   regs->aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
}
 }
 
@@ -954,12 +954,11 @@ void intel_audio_hooks_init(struct drm_i915_private *i915)
 {
if (IS_G4X(i915))
i915->display.funcs.audio = _audio_funcs;
-   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915) ||
+HAS_PCH_CPT(i915) || HAS_PCH_IBX(i915))
i915->display.funcs.audio = _audio_funcs;
else if (IS_HASWELL(i915) || DISPLAY_VER(i915) >= 8)
i915->display.funcs.audio = _audio_funcs;
-   else if (HAS_PCH_SPLIT(i915))
-   i915->display.funcs.audio = _audio_funcs;
 }
 
 struct aud_ts_cdclk_m_n {
-- 
2.37.4

Re: [Intel-gfx] [PATCH v2] drm/i915: Partial abandonment of legacy DRM logging macros

2022-11-08 Thread Andrzej Hajda


On 08.11.2022 13:26, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.

v2:
  * Don't have struct drm_device as local. (Jani, Ville)

Signed-off-by: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: John Harrison 
Cc: Ville Syrjälä 


Nice work.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 26 +++
  .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
  drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
  drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
  .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
  .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
  drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
  drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
  drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
  drivers/gpu/drm/i915/i915_query.c | 12 +++---
  drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
  drivers/gpu/drm/i915/i915_vma.c   | 16 ---
  drivers/gpu/drm/i915/intel_uncore.c   | 21 +
  19 files changed, 119 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 01402f3c58f6..7f2831efc798 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
__user *base, void *data)
}
  
  	if (intel_engine_uses_guc(master)) {

-   DRM_DEBUG("bonding extension not supported with GuC 
submission");
+   drm_dbg(>drm, "bonding extension not supported with GuC 
submission");
return -ENODEV;
}
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 1160723c9d2d..f65fd03f7cf2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
return err;
  }
  
-static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)

+static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
+struct drm_i915_gem_execbuffer2 *exec)
  {
if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
return -EINVAL;
@@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
}
  
  	if (exec->DR4 == 0x) {

-   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
exec->DR4 = 0;
}
if (exec->DR1 || exec->DR4)
@@ -2799,7 +2800,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
  
  		syncobj = drm_syncobj_find(eb->file, user_fence.handle);

if (!syncobj) {
-   DRM_DEBUG("Invalid syncobj handle provided\n");
+   drm_dbg(>i915->drm,
+   "Invalid syncobj handle provided\n");
return -ENOENT;
}
  
@@ -2807,7 +2809,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
  
  		if (!fence && user_fence.flags &&

!(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
-   DRM_DEBUG("Syncobj handle has no fence\n");
+   drm_dbg(>i915->drm,
+   "Syncobj handle has no fence\n");
drm_syncobj_put(syncobj);
return -EINVAL;
}
@@ -2816,7 +2819,9 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
err = dma_fence_chain_find_seqno(, point);
  
  		if (err && !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {

-   DRM_DEBUG("Syncobj handle missing requested point 
%llu\n", point);
+   drm_dbg(>i915->drm,
+   "Syncobj handle missing requested point %llu\n",
+   point);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return err;
@@ -2842,7 +2847,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 * 0) would break the timeline.
 */
if (user_fence.flags & I915_EXEC_FENCE_WAIT) {
-   DRM_DEBUG("Trying

[Intel-gfx] [PATCH v3 9/9] drm/i915/mtl+: Don't enable the AUX_IO power for non-eDP port main links

MTL+ requires the AUX_IO power for the main link only on eDP, so don't
enable it in other cases.

v2:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.

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

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cc4bc529a78a5..7a4b5a7d2ec66 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -866,7 +866,7 @@ intel_ddi_main_link_aux_domain(struct intel_digital_port 
*dig_port)
 */
if (intel_encoder_can_psr(_port->base))
return intel_display_power_aux_io_domain(i915, 
dig_port->aux_ch);
-   else if (intel_phy_is_tc(i915, phy))
+   else if (DISPLAY_VER(i915) < 14 && intel_phy_is_tc(i915, phy))
return intel_aux_power_domain(dig_port);
else
return POWER_DOMAIN_INVALID;
-- 
2.37.1

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling

2022-11-08 Thread Vudum, Lakshminarayana

Known issue. Re-reported.

-Original Message-
From: Auld, Matthew  
Sent: Tuesday, November 8, 2022 1:40 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/ttm: 
fix uaf with lmem_userfault_list handling

On 08/11/2022 00:09, Patchwork wrote:
> *Patch Details*
> *Series:* series starting with [1/2] drm/i915/ttm: fix uaf with 
> lmem_userfault_list handling
> *URL:*https://patchwork.freedesktop.org/series/110613/ 
> 
> *State:*  failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/index.html
>  l>
> 
> 
>   CI Bug Log - changes from CI_DRM_12351_full -> 
> Patchwork_110613v1_full
> 
> 
> Summary
> 
> *FAILURE*
> 
> Serious unknown changes coming with Patchwork_110613v1_full absolutely 
> need to be verified manually.
> 
> If you think the reported changes have nothing to do with the changes 
> introduced in Patchwork_110613v1_full, please notify your bug team to 
> allow them to document this new failure mode, which will reduce false 
> positives in CI.
> 
> 
> Participating hosts (9 -> 9)
> 
> No changes in participating hosts
> 
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_110613v1_full:
> 
> 
>   IGT changes
> 
> 
> Possible regressions
> 
>   *
> 
> igt@kms_plane_alpha_blend@constant-alpha-min@pipe-a-dp-1:
> 
>   o shard-apl: PASS
> 
> 
>  -> FAIL 
> 
>   *
> 
> igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
> 
>   o shard-skl: NOTRUN -> INCOMPLETE
> 
>  4/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html>


Unrelated. These platforms don't have lmem.

> 
> 
> Known issues
> 
> Here are the changes found in Patchwork_110613v1_full that come from 
> known issues:
> 
> 
>   CI changes
> 
> 
> Issues hit
> 
>   * boot:
>   o shard-glk: (PASS
> 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>, PASS 
>  .html>) -> (PASS 
>  1/boot.html>, PASS 
>  1/boot.html>, PASS 
>  1/boot.html>, PASS 
>

[Intel-gfx] [PATCH v2 10/15] drm/i915/sdvo: Only use "presence detect" for has_audio readout

From: Ville Syrjälä 

Align the SDVO audio code with the native HDMI/DP audio and
use just the "presence detect" bit for the has_audio readout.
The "ELD valid" bit will be used for ELD readout soon.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 55aa8f2ed7da..c269cd6ddb63 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -1731,9 +1731,7 @@ static void intel_sdvo_get_config(struct intel_encoder 
*encoder,
 
if (intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_AUDIO_STAT,
 , 1)) {
-   u8 mask = SDVO_AUDIO_ELD_VALID | SDVO_AUDIO_PRESENCE_DETECT;
-
-   if ((val & mask) == mask)
+   if (val & SDVO_AUDIO_PRESENCE_DETECT)
pipe_config->has_audio = true;
}
 
-- 
2.37.4

[Intel-gfx] [PATCH v2 12/15] drm/i915/audio: Hook up ELD into the state checker

From: Ville Syrjälä 

Have the state checker validate the ELD. For now we'll
just dump it out as a hex buffer on a mismatch, maybe
someone will get inspired to decode it properly at some
point...

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 43 
 1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0d3353c403af..01ddda65be0f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5428,6 +5428,12 @@ intel_compare_dp_vsc_sdp(const struct drm_dp_vsc_sdp *a,
return memcmp(a, b, sizeof(*a)) == 0;
 }
 
+static bool
+intel_compare_buffer(const u8 *a, const u8 *b, size_t len)
+{
+   return memcmp(a, b, len) == 0;
+}
+
 static void
 pipe_config_infoframe_mismatch(struct drm_i915_private *dev_priv,
   bool fastset, const char *name,
@@ -5478,6 +5484,30 @@ pipe_config_dp_vsc_sdp_mismatch(struct drm_i915_private 
*dev_priv,
}
 }
 
+static void
+pipe_config_buffer_mismatch(struct drm_i915_private *dev_priv,
+   bool fastset, const char *name,
+   const u8 *a, const u8 *b, size_t len)
+{
+   if (fastset) {
+   if (!drm_debug_enabled(DRM_UT_KMS))
+   return;
+
+   drm_dbg_kms(_priv->drm,
+   "fastset mismatch in %s buffer\n", name);
+   print_hex_dump(KERN_DEBUG, "expected: ", DUMP_PREFIX_NONE,
+  16, 0, a, len, false);
+   print_hex_dump(KERN_DEBUG, "found: ", DUMP_PREFIX_NONE,
+  16, 0, b, len, false);
+   } else {
+   drm_err(_priv->drm, "mismatch in %s buffer\n", name);
+   print_hex_dump(KERN_ERR, "expected: ", DUMP_PREFIX_NONE,
+  16, 0, a, len, false);
+   print_hex_dump(KERN_ERR, "found: ", DUMP_PREFIX_NONE,
+  16, 0, b, len, false);
+   }
+}
+
 static void __printf(4, 5)
 pipe_config_mismatch(bool fastset, const struct intel_crtc *crtc,
 const char *name, const char *format, ...)
@@ -5677,6 +5707,18 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
} \
 } while (0)
 
+#define PIPE_CONF_CHECK_BUFFER(name, len) do { \
+   BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
+   BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
+   if (!intel_compare_buffer(current_config->name, pipe_config->name, 
(len))) { \
+   pipe_config_buffer_mismatch(dev_priv, fastset, 
__stringify(name), \
+   current_config->name, \
+   pipe_config->name, \
+   (len)); \
+   ret = false; \
+   } \
+} while (0)
+
 #define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
if (current_config->name1 != pipe_config->name1) { \
pipe_config_mismatch(fastset, crtc, __stringify(name1), \
@@ -5755,6 +5797,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_BOOL(fec_enable);
 
PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_audio);
+   PIPE_CONF_CHECK_BUFFER(eld, MAX_ELD_BYTES);
 
PIPE_CONF_CHECK_X(gmch_pfit.control);
/* pfit ratios are autocomputed by the hw on gen4+ */
-- 
2.37.4

[Intel-gfx] [PATCH v2 03/15] drm/i915/audio: Unify get_saved_enc()

From: Ville Syrjälä 

Make the two branches of get_saved_enc() look alike. Currently
they look different even though they do exactly the same thing
apart from == vs. != for the MST comparison.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 0a53731a9272..0ac28d28098f 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1069,10 +1069,10 @@ static int i915_audio_component_get_cdclk_freq(struct 
device *kdev)
 static struct intel_encoder *get_saved_enc(struct drm_i915_private *i915,
   int port, int pipe)
 {
-   struct intel_encoder *encoder;
-
/* MST */
if (pipe >= 0) {
+   struct intel_encoder *encoder;
+
if (drm_WARN_ON(>drm,
pipe >= 
ARRAY_SIZE(i915->display.audio.encoder_map)))
return NULL;
@@ -1083,7 +1083,7 @@ static struct intel_encoder *get_saved_enc(struct 
drm_i915_private *i915,
 * MST or not. So it will poll all the port & pipe
 * combinations
 */
-   if (encoder != NULL && encoder->port == port &&
+   if (encoder && encoder->port == port &&
encoder->type == INTEL_OUTPUT_DP_MST)
return encoder;
}
@@ -1093,14 +1093,12 @@ static struct intel_encoder *get_saved_enc(struct 
drm_i915_private *i915,
return NULL;
 
for_each_pipe(i915, pipe) {
+   struct intel_encoder *encoder;
+
encoder = i915->display.audio.encoder_map[pipe];
-   if (encoder == NULL)
-   continue;
 
-   if (encoder->type == INTEL_OUTPUT_DP_MST)
-   continue;
-
-   if (port == encoder->port)
+   if (encoder && encoder->port == port &&
+   encoder->type != INTEL_OUTPUT_DP_MST)
return encoder;
}
 
-- 
2.37.4

Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD

2022-11-08 Thread Yi Liu


On 2022/11/8 17:19, Nicolin Chen wrote:

On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:


This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd

[...]

v2:
  - Rebase to v6.1-rc3, v4 iommufd series
  - Fixup comments and commit messages from list remarks
  - Fix leaking of the iommufd for mdevs
  - New patch to fix vfio modaliases when vfio container is disabled
  - Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened
to signal that iommufd is providing this


I've redone my previous sanity tests. Except those reported bugs,
things look fine. Once we fix those issues, GVT and other modules
can run some more stressful tests, I think.


our side is also starting test (gvt, nic passthrough) this version. need to
wait a while for the result.

--
Regards,
Yi Liu

[Intel-gfx] [PATCH v2 02/15] drm/i915/audio: Don't program the hardware ELD buffer on hsw+

From: Ville Syrjälä 

Since we use the audio component to transfer the ELD to the audio
driver on hsw+ platforms there is no point in even programming
the hardware ELD buffer. Stop doing so.

The one slight caveat here is that this is not strictly legal
according to the HDA spec. PD=1;ELD=0 is only documented as
an intermediate state during modeset. But if there is no hardware
that depends on that then I guess we're fine. Or we could
perhaps set ELD=1 without actually programming the buffer?

Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 ->
PD=1;ELD=1 is also not strictly correct according to the HDA
spec, as the only documented transition from PD=0;ELD=0 is
straight to PD=1;ELD=1.

Additionally on hsw/bdw the hardware buffer is tied in with the
dedicated display HDA controller's power state, so currently
we mostly fail at proramming the buffer anyway. When the HDA
side is not sufficiently powered up the ELD address bits get
stuck and the ELD data register accesses go nowhere.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
References: 
https://lore.kernel.org/intel-gfx/20221012104936.30911-1-ville.syrj...@linux.intel.com/
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 37 +++---
 1 file changed, 4 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index dbcb4d9ecde7..0a53731a9272 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -459,17 +459,6 @@ hsw_audio_config_update(struct intel_encoder *encoder,
hsw_hdmi_audio_config_update(encoder, crtc_state);
 }
 
-/* ELD buffer size in dwords */
-static int hsw_eld_buffer_size(struct drm_i915_private *i915,
-  enum transcoder cpu_transcoder)
-{
-   u32 tmp;
-
-   tmp = intel_de_read(i915, HSW_AUD_DIP_ELD_CTRL(cpu_transcoder));
-
-   return REG_FIELD_GET(IBX_ELD_BUFFER_SIZE_MASK, tmp);
-}
-
 static void hsw_audio_codec_disable(struct intel_encoder *encoder,
const struct intel_crtc_state 
*old_crtc_state,
const struct drm_connector_state 
*old_conn_state)
@@ -618,10 +607,7 @@ static void hsw_audio_codec_enable(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_connector *connector = conn_state->connector;
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
-   const u32 *eld = (const u32 *)connector->eld;
-   int eld_buffer_size, len, i;
 
mutex_lock(>display.audio.mutex);
 
@@ -639,25 +625,10 @@ static void hsw_audio_codec_enable(struct intel_encoder 
*encoder,
intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
 AUDIO_ELD_VALID(cpu_transcoder), 0);
 
-   /* Reset ELD address */
-   intel_de_rmw(i915, HSW_AUD_DIP_ELD_CTRL(cpu_transcoder),
-IBX_ELD_ADDRESS_MASK, 0);
-
-   eld_buffer_size = hsw_eld_buffer_size(i915, cpu_transcoder);
-   len = min(drm_eld_size(connector->eld) / 4, eld_buffer_size);
-
-   for (i = 0; i < len; i++)
-   intel_de_write(i915, HSW_AUD_EDID_DATA(cpu_transcoder), eld[i]);
-   for (; i < eld_buffer_size; i++)
-   intel_de_write(i915, HSW_AUD_EDID_DATA(cpu_transcoder), 0);
-
-   drm_WARN_ON(>drm,
-   (intel_de_read(i915, HSW_AUD_DIP_ELD_CTRL(cpu_transcoder)) &
-IBX_ELD_ADDRESS_MASK) != 0);
-
-   /* ELD valid */
-   intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD,
-0, AUDIO_ELD_VALID(cpu_transcoder));
+   /*
+* The audio componenent is used to convey the ELD
+* instead using of the hardware ELD buffer.
+*/
 
/* Enable timestamps */
hsw_audio_config_update(encoder, crtc_state);
-- 
2.37.4

[Intel-gfx] [PATCH v3 7/9] drm/i915: Factor out function to get/put AUX_IO power for main link

Factor out functions to get/put the AUX_IO power domain for the main
link on DDI ports.

While at it clarify the corresponding code comment.

No functional change.

v2:
- s/(get/put)_aux_power_for_main_link/main_link_aux_power_domain_(get/put)
  (Jani)
- Clarify in the code comment that AUX_IO is needed only by TypeC besides
  eDP/PSR.
v3:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 84 ++--
 1 file changed, 51 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a087609223c60..21f1a68a57598 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -846,26 +846,63 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
 }
 
 static enum intel_display_power_domain
-intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port)
+intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port,
+  const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
 
-   /* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
+   /*
+* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
 * DC states enabled at the same time, while for driver initiated AUX
 * transfers we need the same AUX IOs to be powered but with DC states
-* disabled. Accordingly use the AUX power domain here which leaves DC
-* states enabled.
-* However, for non-A AUX ports the corresponding non-EDP transcoders
-* would have already enabled power well 2 and DC_OFF. This means we can
-* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
-* specific AUX_IO reference without powering up any extra wells.
-* Note that PSR is enabled only on Port A even though this function
-* returns the correct domain for other ports too.
+* disabled. Accordingly use the AUX_IO_ power domain here which
+* leaves DC states enabled.
+*
+* Before MTL TypeC PHYs (in all TypeC modes and both DP/HDMI) also 
require
+* AUX IO to be enabled, but all these require DC_OFF to be enabled as
+* well, so we can acquire a wider AUX_ power domain reference
+* instead of a specific AUX_IO_ reference without powering up any
+* extra wells.
 */
if (intel_encoder_can_psr(_port->base))
return intel_display_power_aux_io_domain(i915, 
dig_port->aux_ch);
-   else
+   else if (intel_crtc_has_dp_encoder(crtc_state) ||
+intel_phy_is_tc(i915, phy))
return intel_aux_power_domain(dig_port);
+   else
+   return POWER_DOMAIN_INVALID;
+}
+
+static void
+main_link_aux_power_domain_get(struct intel_digital_port *dig_port,
+  const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   enum intel_display_power_domain domain =
+   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
+
+   drm_WARN_ON(>drm, dig_port->aux_wakeref);
+
+   if (domain == POWER_DOMAIN_INVALID)
+   return;
+
+   dig_port->aux_wakeref = intel_display_power_get(i915, domain);
+}
+
+static void
+main_link_aux_power_domain_put(struct intel_digital_port *dig_port,
+  const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   intel_wakeref_t wf = fetch_and_zero(_port->aux_wakeref);
+   enum intel_display_power_domain domain =
+   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
+
+   if (!wf)
+   return;
+
+   intel_display_power_put(i915, domain, wf);
 }
 
 static void intel_ddi_get_power_domains(struct intel_encoder *encoder,
@@ -873,7 +910,6 @@ static void intel_ddi_get_power_domains(struct 
intel_encoder *encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port;
-   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
 
/*
 * TODO: Add support for MST encoders. Atm, the following should never
@@ -892,17 +928,7 @@ static void intel_ddi_get_power_domains(struct 
intel_encoder *encoder,
   
dig_port->ddi_io_power_domain);
}
 
-   /*
-* AUX power is only needed for (e)DP mode, and for HDMI mode on TC
-* ports.
-*/
-   if (intel_crtc_has_dp_encoder(crtc_state) ||
-   intel_phy_is_tc(dev_priv, phy)) {
-

[Intel-gfx] [PATCH v2 08/15] drm/i915/audio: Hardware ELD readout

From: Ville Syrjälä 

Read out the ELD from the hardware buffer, or from our stashed
copy for the audio component, so that we can hook up the state
checker to validate it.

v2: Deal with the platforms using acomp

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/g4x_dp.c  |  2 +
 drivers/gpu/drm/i915/display/g4x_hdmi.c|  2 +
 drivers/gpu/drm/i915/display/intel_audio.c | 56 ++
 drivers/gpu/drm/i915/display/intel_audio.h |  2 +
 drivers/gpu/drm/i915/display/intel_ddi.c   |  2 +
 5 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
b/drivers/gpu/drm/i915/display/g4x_dp.c
index e3e3d27ffb53..4fc7153ad35a 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -397,6 +397,8 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
 
if (intel_dp_is_edp(intel_dp))
intel_edp_fixup_vbt_bpp(encoder, pipe_config->pipe_bpp);
+
+   intel_audio_codec_get_config(encoder, pipe_config);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c 
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 8aadf96fa5e9..478878abada6 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -142,6 +142,8 @@ static void intel_hdmi_get_config(struct intel_encoder 
*encoder,
intel_read_infoframe(encoder, pipe_config,
 HDMI_INFOFRAME_TYPE_VENDOR,
 _config->infoframes.hdmi);
+
+   intel_audio_codec_get_config(encoder, pipe_config);
 }
 
 static void g4x_enable_hdmi(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index ca7f8c3a6aae..524fa3f4ebc4 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -71,6 +71,8 @@ struct intel_audio_funcs {
void (*audio_codec_disable)(struct intel_encoder *encoder,
const struct intel_crtc_state 
*old_crtc_state,
const struct drm_connector_state 
*old_conn_state);
+   void (*audio_codec_get_config)(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state);
 };
 
 /* DP N/M table */
@@ -314,6 +316,27 @@ static int g4x_eld_buffer_size(struct drm_i915_private 
*i915)
return REG_FIELD_GET(G4X_ELD_BUFFER_SIZE_MASK, tmp);
 }
 
+static void g4x_audio_codec_get_config(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   u32 *eld = (u32 *)crtc_state->eld;
+   int eld_buffer_size, len, i;
+   u32 tmp;
+
+   tmp = intel_de_read(i915, G4X_AUD_CNTL_ST);
+   if ((tmp & G4X_ELD_VALID) == 0)
+   return;
+
+   intel_de_rmw(i915, G4X_AUD_CNTL_ST, G4X_ELD_ADDRESS_MASK, 0);
+
+   eld_buffer_size = g4x_eld_buffer_size(i915);
+   len = min_t(int, sizeof(crtc_state->eld) / 4, eld_buffer_size);
+
+   for (i = 0; i < len; i++)
+   eld[i] = intel_de_read(i915, G4X_HDMIW_HDMIEDID);
+}
+
 static void g4x_audio_codec_disable(struct intel_encoder *encoder,
const struct intel_crtc_state 
*old_crtc_state,
const struct drm_connector_state 
*old_conn_state)
@@ -875,19 +898,52 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
intel_lpe_audio_notify(i915, pipe, port, NULL, 0, false);
 }
 
+static void intel_acomp_get_config(struct intel_encoder *encoder,
+  struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct intel_audio_state *audio_state;
+   enum pipe pipe = crtc->pipe;
+
+   mutex_lock(>display.audio.mutex);
+
+   audio_state = >display.audio.state[pipe];
+
+   if (audio_state->encoder)
+   memcpy(crtc_state->eld, audio_state->eld, 
sizeof(audio_state->eld));
+
+   mutex_unlock(>display.audio.mutex);
+}
+
+void intel_audio_codec_get_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+   if (!crtc_state->has_audio)
+   return;
+
+   if (i915->display.funcs.audio)
+   i915->display.funcs.audio->audio_codec_get_config(encoder, 
crtc_state);
+}
+
 static const struct intel_audio_funcs g4x_audio_funcs = {
.audio_codec_enable = g4x_audio_codec_enable,
.audio_codec_disable = g4x_audio_codec_disable,
+   .audio_codec_get_config =

[Intel-gfx] [PATCH v2 14/15] drm/i915/audio: s/ilk/ibx/

From: Ville Syrjälä 

Rename the ilk stuff to ibx, as the audio logic lives
in the PCH. The only exception are VLV/CHV but their audio
hardware was stolen from ibx so the name still fits.

Also most of the register defines also use the IBX namespace.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 524fa3f4ebc4..4286f7a7cc76 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -658,13 +658,13 @@ static void hsw_audio_codec_enable(struct intel_encoder 
*encoder,
mutex_unlock(>display.audio.mutex);
 }
 
-struct ilk_audio_regs {
+struct ibx_audio_regs {
i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
 };
 
-static void ilk_audio_regs_init(struct drm_i915_private *i915,
+static void ibx_audio_regs_init(struct drm_i915_private *i915,
enum pipe pipe,
-   struct ilk_audio_regs *regs)
+   struct ibx_audio_regs *regs)
 {
if (HAS_PCH_IBX(i915)) {
regs->hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
@@ -684,7 +684,7 @@ static void ilk_audio_regs_init(struct drm_i915_private 
*i915,
}
 }
 
-static void ilk_audio_codec_disable(struct intel_encoder *encoder,
+static void ibx_audio_codec_disable(struct intel_encoder *encoder,
const struct intel_crtc_state 
*old_crtc_state,
const struct drm_connector_state 
*old_conn_state)
 {
@@ -692,12 +692,12 @@ static void ilk_audio_codec_disable(struct intel_encoder 
*encoder,
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
-   struct ilk_audio_regs regs;
+   struct ibx_audio_regs regs;
 
if (drm_WARN_ON(>drm, port == PORT_A))
return;
 
-   ilk_audio_regs_init(i915, pipe, );
+   ibx_audio_regs_init(i915, pipe, );
 
mutex_lock(>display.audio.mutex);
 
@@ -720,7 +720,7 @@ static void ilk_audio_codec_disable(struct intel_encoder 
*encoder,
intel_crtc_wait_for_next_vblank(crtc);
 }
 
-static void ilk_audio_codec_enable(struct intel_encoder *encoder,
+static void ibx_audio_codec_enable(struct intel_encoder *encoder,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
@@ -728,14 +728,14 @@ static void ilk_audio_codec_enable(struct intel_encoder 
*encoder,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
-   struct ilk_audio_regs regs;
+   struct ibx_audio_regs regs;
 
if (drm_WARN_ON(>drm, port == PORT_A))
return;
 
intel_crtc_wait_for_next_vblank(crtc);
 
-   ilk_audio_regs_init(i915, pipe, );
+   ibx_audio_regs_init(i915, pipe, );
 
mutex_lock(>display.audio.mutex);
 
@@ -934,9 +934,9 @@ static const struct intel_audio_funcs g4x_audio_funcs = {
.audio_codec_get_config = g4x_audio_codec_get_config,
 };
 
-static const struct intel_audio_funcs ilk_audio_funcs = {
-   .audio_codec_enable = ilk_audio_codec_enable,
-   .audio_codec_disable = ilk_audio_codec_disable,
+static const struct intel_audio_funcs ibx_audio_funcs = {
+   .audio_codec_enable = ibx_audio_codec_enable,
+   .audio_codec_disable = ibx_audio_codec_disable,
.audio_codec_get_config = intel_acomp_get_config,
 };
 
@@ -955,11 +955,11 @@ void intel_audio_hooks_init(struct drm_i915_private *i915)
if (IS_G4X(i915))
i915->display.funcs.audio = _audio_funcs;
else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
-   i915->display.funcs.audio = _audio_funcs;
+   i915->display.funcs.audio = _audio_funcs;
else if (IS_HASWELL(i915) || DISPLAY_VER(i915) >= 8)
i915->display.funcs.audio = _audio_funcs;
else if (HAS_PCH_SPLIT(i915))
-   i915->display.funcs.audio = _audio_funcs;
+   i915->display.funcs.audio = _audio_funcs;
 }
 
 struct aud_ts_cdclk_m_n {
-- 
2.37.4

[Intel-gfx] [PATCH v2 00/15] drm/i915: ELD precompute and readout

From: Ville Syrjälä 

Second attempt at ELD precompute + readout.

v2:
- get rid of the hw ELD buffer entirely on !g4x
- actually use the precomputed ELD in acomp .get_eld()
- more cleanups/etc. here and there

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 

Ville Syrjälä (15):
  drm/i915/audio: Don't program the hardware ELD buffer on ilk+
  drm/i915/audio: Don't program the hardware ELD buffer on hsw+
  drm/i915/audio: Unify get_saved_enc()
  drm/i915/audio: Realign some function arguments
  drm/i915/audio: Introduce a struct for the acomp audio state
  drm/i915/audio: Precompute the ELD
  drm/i915/audio: Don't enable audio with bogus ELD
  drm/i915/audio: Hardware ELD readout
  drm/i915/sdvo: Precompute the ELD
  drm/i915/sdvo: Only use "presence detect" for has_audio readout
  drm/i915/sdvo: Do ELD hardware readout
  drm/i915/audio: Hook up ELD into the state checker
  drm/i915/audio: Include ELD in the state dump
  drm/i915/audio: s/ilk/ibx/
  drm/i915/audio: Clean up the PCH type checks

 drivers/gpu/drm/i915/display/g4x_dp.c |   2 +
 drivers/gpu/drm/i915/display/g4x_hdmi.c   |   2 +
 drivers/gpu/drm/i915/display/intel_audio.c| 343 +-
 drivers/gpu/drm/i915/display/intel_audio.h|   7 +
 .../drm/i915/display/intel_crtc_state_dump.c  |  17 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   2 +
 drivers/gpu/drm/i915/display/intel_display.c  |  43 +++
 .../gpu/drm/i915/display/intel_display_core.h |   9 +-
 .../drm/i915/display/intel_display_types.h|   4 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   4 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |   4 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  40 +-
 12 files changed, 298 insertions(+), 179 deletions(-)

-- 
2.37.4

[Intel-gfx] [PATCH v2 06/15] drm/i915/audio: Precompute the ELD

From: Ville Syrjälä 

Stash the ELD into the crtc_state and precompute it. This gets
rid of the ugly ELD mutation during intel_audio_codec_enable(),
and opens the door for the state checker.

v2: Make another copy for the acomp hooks (Chaitanya)
Split out the bogus ELD handling change (Jani)

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c| 50 ---
 drivers/gpu/drm/i915/display/intel_audio.h|  5 ++
 .../gpu/drm/i915/display/intel_display_core.h |  2 +-
 .../drm/i915/display/intel_display_types.h|  2 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  4 +-
 6 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index dba9e25ae69d..1daf3591a824 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -335,8 +335,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_connector *connector = conn_state->connector;
-   const u32 *eld = (const u32 *)connector->eld;
+   const u32 *eld = (const u32 *)crtc_state->eld;
int eld_buffer_size, len, i;
 
intel_crtc_wait_for_next_vblank(crtc);
@@ -345,7 +344,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
 G4X_ELD_VALID | G4X_ELD_ADDRESS_MASK, 0);
 
eld_buffer_size = g4x_eld_buffer_size(i915);
-   len = min(drm_eld_size(connector->eld) / 4, eld_buffer_size);
+   len = min(drm_eld_size(crtc_state->eld) / 4, eld_buffer_size);
 
for (i = 0; i < len; i++)
intel_de_write(i915, G4X_HDMIW_HDMIEDID, eld[i]);
@@ -738,6 +737,28 @@ static void ilk_audio_codec_enable(struct intel_encoder 
*encoder,
mutex_unlock(>display.audio.mutex);
 }
 
+bool intel_audio_compute_config(struct intel_encoder *encoder,
+   struct intel_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct drm_connector *connector = conn_state->connector;
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+
+   if (!connector->eld[0])
+   drm_dbg_kms(>drm,
+   "Bogus ELD on [CONNECTOR:%d:%s]\n",
+   connector->base.id, connector->name);
+
+   BUILD_BUG_ON(sizeof(crtc_state->eld) != sizeof(connector->eld));
+   memcpy(crtc_state->eld, connector->eld, sizeof(crtc_state->eld));
+
+   crtc_state->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
+
+   return true;
+}
+
 /**
  * intel_audio_codec_enable - Enable the audio codec for HD audio
  * @encoder: encoder on which to enable audio
@@ -755,8 +776,6 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
struct i915_audio_component *acomp = i915->display.audio.component;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
-   const struct drm_display_mode *adjusted_mode =
-   _state->hw.adjusted_mode;
struct intel_audio_state *audio_state;
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
@@ -768,15 +787,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
connector->base.base.id, connector->base.name,
encoder->base.base.id, encoder->base.name,
crtc->base.base.id, crtc->base.name,
-   drm_eld_size(connector->base.eld));
-
-   /* FIXME precompute the ELD in .compute_config() */
-   if (!connector->base.eld[0])
-   drm_dbg_kms(>drm,
-   "Bogus ELD on [CONNECTOR:%d:%s]\n",
-   connector->base.base.id, connector->base.name);
-
-   connector->base.eld[6] = drm_av_sync_delay(>base, 
adjusted_mode) / 2;
+   drm_eld_size(crtc_state->eld));
 
if (i915->display.funcs.audio)
i915->display.funcs.audio->audio_codec_enable(encoder,
@@ -788,7 +799,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
audio_state = >display.audio.state[pipe];
 
audio_state->encoder = encoder;
-   audio_state->connector = connector;
+   BUILD_BUG_ON(sizeof(audio_state->eld) != sizeof(crtc_state->eld));
+   memcpy(audio_state->eld, crtc_state->eld, sizeof(audio_state->eld));
 
mutex_unlock(>display.audio.mutex);
 
@@ -801,7 +813,7 @@ void

[Intel-gfx] [PATCH v2 13/15] drm/i915/audio: Include ELD in the state dump

From: Ville Syrjälä 

Include the ELD has a hex blob in the crtc state dump.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_crtc_state_dump.c| 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index e3273fe8ddac..2422d6ef5777 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -3,6 +3,8 @@
  * Copyright © 2022 Intel Corporation
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "intel_crtc_state_dump.h"
 #include "intel_display_types.h"
@@ -56,6 +58,17 @@ intel_dump_dp_vsc_sdp(struct drm_i915_private *i915,
drm_dp_vsc_sdp_log(KERN_DEBUG, i915->drm.dev, vsc);
 }
 
+static void
+intel_dump_buffer(struct drm_i915_private *i915,
+ const char *prefix, const u8 *buf, size_t len)
+{
+   if (!drm_debug_enabled(DRM_UT_KMS))
+   return;
+
+   print_hex_dump(KERN_DEBUG, prefix, DUMP_PREFIX_NONE,
+  16, 0, buf, len, false);
+}
+
 #define OUTPUT_TYPE(x) [INTEL_OUTPUT_ ## x] = #x
 
 static const char * const output_type_str[] = {
@@ -236,6 +249,10 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
intel_hdmi_infoframe_enable(DP_SDP_VSC))
intel_dump_dp_vsc_sdp(i915, _config->infoframes.vsc);
 
+   if (pipe_config->has_audio)
+   intel_dump_buffer(i915, "ELD: ", pipe_config->eld,
+ drm_eld_size(pipe_config->eld));
+
drm_dbg_kms(>drm, "vrr: %s, vmin: %d, vmax: %d, pipeline full: 
%d, guardband: %d flipline: %d, vmin vblank: %d, vmax vblank: %d\n",
str_yes_no(pipe_config->vrr.enable),
pipe_config->vrr.vmin, pipe_config->vrr.vmax,
-- 
2.37.4

[Intel-gfx] [PATCH v2 07/15] drm/i915/audio: Don't enable audio with bogus ELD

From: Ville Syrjälä 

Currently we just print a debug message if the ELD is bogus.
Maybe we should just not enable audio at all in that case?

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 1daf3591a824..ca7f8c3a6aae 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -746,10 +746,12 @@ bool intel_audio_compute_config(struct intel_encoder 
*encoder,
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
 
-   if (!connector->eld[0])
+   if (!connector->eld[0]) {
drm_dbg_kms(>drm,
"Bogus ELD on [CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
+   return false;
+   }
 
BUILD_BUG_ON(sizeof(crtc_state->eld) != sizeof(connector->eld));
memcpy(crtc_state->eld, connector->eld, sizeof(crtc_state->eld));
-- 
2.37.4

[Intel-gfx] [PATCH v2 04/15] drm/i915/audio: Realign some function arguments

From: Ville Syrjälä 

Fix up some function argument alignment fails.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 0ac28d28098f..6b0c2b0522fd 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -778,8 +778,8 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
 
if (i915->display.funcs.audio)
i915->display.funcs.audio->audio_codec_enable(encoder,
- crtc_state,
- conn_state);
+ crtc_state,
+ conn_state);
 
mutex_lock(>display.audio.mutex);
encoder->audio_connector = connector;
@@ -794,7 +794,7 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
pipe = -1;

acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
-(int) port, (int) pipe);
+ (int)port, (int)pipe);
}
 
intel_lpe_audio_notify(i915, pipe, port, connector->eld,
@@ -831,8 +831,8 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
 
if (i915->display.funcs.audio)
i915->display.funcs.audio->audio_codec_disable(encoder,
-  
old_crtc_state,
-  
old_conn_state);
+  old_crtc_state,
+  old_conn_state);
 
mutex_lock(>display.audio.mutex);
encoder->audio_connector = NULL;
@@ -845,7 +845,7 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
pipe = -1;

acomp->base.audio_ops->pin_eld_notify(acomp->base.audio_ops->audio_ptr,
-(int) port, (int) pipe);
+ (int)port, (int)pipe);
}
 
intel_lpe_audio_notify(i915, pipe, port, NULL, 0, false);
-- 
2.37.4

[Intel-gfx] [PATCH v2 11/15] drm/i915/sdvo: Do ELD hardware readout

From: Ville Syrjälä 

Read out the ELD from the hw so the state checker can verify it.

v2: Check the "ELD valid" bit separately

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_sdvo.c | 24 +++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index c269cd6ddb63..5279eb5fd527 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -1185,6 +1185,28 @@ static void intel_sdvo_get_avi_infoframe(struct 
intel_sdvo *intel_sdvo,
  frame->any.type, HDMI_INFOFRAME_TYPE_AVI);
 }
 
+static void intel_sdvo_get_eld(struct intel_sdvo *intel_sdvo,
+  struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
+   ssize_t len;
+   u8 val;
+
+   if (!crtc_state->has_audio)
+   return;
+
+   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_AUDIO_STAT, , 1))
+   return;
+
+   if ((val & SDVO_AUDIO_ELD_VALID) == 0)
+   return;
+
+   len = intel_sdvo_read_infoframe(intel_sdvo, SDVO_HBUF_INDEX_ELD,
+   crtc_state->eld, 
sizeof(crtc_state->eld));
+   if (len < 0)
+   drm_dbg_kms(>drm, "failed to read ELD\n");
+}
+
 static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo,
 const struct drm_connector_state 
*conn_state)
 {
@@ -1742,6 +1764,8 @@ static void intel_sdvo_get_config(struct intel_encoder 
*encoder,
}
 
intel_sdvo_get_avi_infoframe(intel_sdvo, pipe_config);
+
+   intel_sdvo_get_eld(intel_sdvo, pipe_config);
 }
 
 static void intel_sdvo_disable_audio(struct intel_sdvo *intel_sdvo)
-- 
2.37.4

[Intel-gfx] [PATCH v2 09/15] drm/i915/sdvo: Precompute the ELD

From: Ville Syrjälä 

Use the precomputed crtc_state->eld for audio setup on SDVO
just like we do with native HDMI.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_sdvo.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index 48b7b1aa37b2..55aa8f2ed7da 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -38,6 +38,7 @@
 
 #include "i915_drv.h"
 #include "intel_atomic.h"
+#include "intel_audio.h"
 #include "intel_connector.h"
 #include "intel_crtc.h"
 #include "intel_de.h"
@@ -1377,7 +1378,9 @@ static int intel_sdvo_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_sdvo, 
conn_state);
 
-   pipe_config->has_audio = intel_sdvo_has_audio(encoder, pipe_config, 
conn_state);
+   pipe_config->has_audio =
+   intel_sdvo_has_audio(encoder, pipe_config, conn_state) &&
+   intel_audio_compute_config(encoder, pipe_config, conn_state);
 
pipe_config->limited_color_range =
intel_sdvo_limited_color_range(encoder, pipe_config,
@@ -1752,12 +1755,7 @@ static void intel_sdvo_enable_audio(struct intel_sdvo 
*intel_sdvo,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state 
*conn_state)
 {
-   const struct drm_display_mode *adjusted_mode =
-   _state->hw.adjusted_mode;
-   struct drm_connector *connector = conn_state->connector;
-   u8 *eld = connector->eld;
-
-   eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
+   const u8 *eld = crtc_state->eld;
 
intel_sdvo_set_audio_state(intel_sdvo, 0);
 
-- 
2.37.4

[Intel-gfx] [PATCH v2 05/15] drm/i915/audio: Introduce a struct for the acomp audio state

From: Ville Syrjälä 

Currently we're spreading the stashed state for use of the
audio component hooks all over the place. Start collecting
it up into a single spot.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c| 106 ++
 .../gpu/drm/i915/display/intel_display_core.h |   9 +-
 .../drm/i915/display/intel_display_types.h|   2 -
 3 files changed, 65 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 6b0c2b0522fd..dba9e25ae69d 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -754,27 +754,29 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct i915_audio_component *acomp = i915->display.audio.component;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_connector *connector = conn_state->connector;
+   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
+   struct intel_audio_state *audio_state;
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
 
if (!crtc_state->has_audio)
return;
 
-   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s][ENCODER:%d:%s] Enable audio 
codec on pipe %c, %u bytes ELD\n",
-   connector->base.id, connector->name,
+   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s][ENCODER:%d:%s] Enable audio 
codec on [CRTC:%d:%s], %u bytes ELD\n",
+   connector->base.base.id, connector->base.name,
encoder->base.base.id, encoder->base.name,
-   pipe_name(pipe), drm_eld_size(connector->eld));
+   crtc->base.base.id, crtc->base.name,
+   drm_eld_size(connector->base.eld));
 
/* FIXME precompute the ELD in .compute_config() */
-   if (!connector->eld[0])
+   if (!connector->base.eld[0])
drm_dbg_kms(>drm,
"Bogus ELD on [CONNECTOR:%d:%s]\n",
-   connector->base.id, connector->name);
+   connector->base.base.id, connector->base.name);
 
-   connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
+   connector->base.eld[6] = drm_av_sync_delay(>base, 
adjusted_mode) / 2;
 
if (i915->display.funcs.audio)
i915->display.funcs.audio->audio_codec_enable(encoder,
@@ -782,10 +784,12 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
  conn_state);
 
mutex_lock(>display.audio.mutex);
-   encoder->audio_connector = connector;
 
-   /* referred in audio callbacks */
-   i915->display.audio.encoder_map[pipe] = encoder;
+   audio_state = >display.audio.state[pipe];
+
+   audio_state->encoder = encoder;
+   audio_state->connector = connector;
+
mutex_unlock(>display.audio.mutex);
 
if (acomp && acomp->base.audio_ops &&
@@ -797,7 +801,7 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
  (int)port, (int)pipe);
}
 
-   intel_lpe_audio_notify(i915, pipe, port, connector->eld,
+   intel_lpe_audio_notify(i915, pipe, port, connector->base.eld,
   crtc_state->port_clock,
   intel_crtc_has_dp_encoder(crtc_state));
 }
@@ -818,16 +822,18 @@ void intel_audio_codec_disable(struct intel_encoder 
*encoder,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct i915_audio_component *acomp = i915->display.audio.component;
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
-   struct drm_connector *connector = old_conn_state->connector;
+   struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
+   struct intel_audio_state *audio_state;
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
 
if (!old_crtc_state->has_audio)
return;
 
-   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s][ENCODER:%d:%s] Disable audio 
codec on pipe %c\n",
-   connector->base.id, connector->name,
-   encoder->base.base.id, encoder->base.name, pipe_name(pipe));
+   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s][ENCODER:%d:%s] Disable audio 
codec on [CRTC:%d:%s]\n",
+   connector->base.base.id, connector->base.name,
+   encoder->base.base.id, encoder->base.name,
+   crtc->base.base.id, crtc->base.name);
 
if (i915->display.funcs.audio)

[Intel-gfx] [PATCH v3 8/9] drm/i915: Don't enable the AUX_IO power for combo-PHY external DP port main links

Combo PHY ports require the AUX_IO power only for eDP/PSR, so don't
enable it otherwise on these ports. So far the external DP and eDP case
was handled the same way due to unclarity when AUX_IO for the main link
is needed. However Bspec is clear in which cases it's required:

- eDP/PSR on all ports and platforms (presumably due to HW/FW initiated
  PSR transactions that won't enable AUX_IO)
  Bspec: 4301, 49296
- TypeC PHY ports on platforms before MTL in all TypeC modes (TBT,
  DP-alt, legacy) and for both HDMI and DP. The next patch will take
  into account the pre-MTL platform dependency.
  Bspec: 22243, 53339, 21750, 49190, 49191, 55424, 65448, 65750, 49294,
 55480, 65380

v2:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 21f1a68a57598..cc4bc529a78a5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -846,8 +846,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
 }
 
 static enum intel_display_power_domain
-intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port,
-  const struct intel_crtc_state *crtc_state)
+intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
@@ -867,20 +866,18 @@ intel_ddi_main_link_aux_domain(struct intel_digital_port 
*dig_port,
 */
if (intel_encoder_can_psr(_port->base))
return intel_display_power_aux_io_domain(i915, 
dig_port->aux_ch);
-   else if (intel_crtc_has_dp_encoder(crtc_state) ||
-intel_phy_is_tc(i915, phy))
+   else if (intel_phy_is_tc(i915, phy))
return intel_aux_power_domain(dig_port);
else
return POWER_DOMAIN_INVALID;
 }
 
 static void
-main_link_aux_power_domain_get(struct intel_digital_port *dig_port,
-  const struct intel_crtc_state *crtc_state)
+main_link_aux_power_domain_get(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
enum intel_display_power_domain domain =
-   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
+   intel_ddi_main_link_aux_domain(dig_port);
 
drm_WARN_ON(>drm, dig_port->aux_wakeref);
 
@@ -891,13 +888,12 @@ main_link_aux_power_domain_get(struct intel_digital_port 
*dig_port,
 }
 
 static void
-main_link_aux_power_domain_put(struct intel_digital_port *dig_port,
-  const struct intel_crtc_state *crtc_state)
+main_link_aux_power_domain_put(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
intel_wakeref_t wf = fetch_and_zero(_port->aux_wakeref);
enum intel_display_power_domain domain =
-   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
+   intel_ddi_main_link_aux_domain(dig_port);
 
if (!wf)
return;
@@ -928,7 +924,7 @@ static void intel_ddi_get_power_domains(struct 
intel_encoder *encoder,
   
dig_port->ddi_io_power_domain);
}
 
-   main_link_aux_power_domain_get(dig_port, crtc_state);
+   main_link_aux_power_domain_get(dig_port);
 }
 
 void intel_ddi_enable_pipe_clock(struct intel_encoder *encoder,
@@ -2767,7 +2763,7 @@ static void intel_ddi_post_disable(struct 
intel_atomic_state *state,
intel_ddi_post_disable_dp(state, encoder, old_crtc_state,
  old_conn_state);
 
-   main_link_aux_power_domain_put(dig_port, old_crtc_state);
+   main_link_aux_power_domain_put(dig_port);
 
if (is_tc_port)
intel_tc_port_put_link(dig_port);
@@ -3088,7 +3084,7 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state *state,
if (is_tc_port)
intel_tc_port_get_link(dig_port, crtc_state->lane_count);
 
-   main_link_aux_power_domain_get(dig_port, crtc_state);
+   main_link_aux_power_domain_get(dig_port);
 
if (is_tc_port && !intel_tc_port_in_tbt_alt_mode(dig_port))
/*
-- 
2.37.1

[Intel-gfx] [PATCH v3 4/9] drm/i915/tgl+: Enable display DC power states on all eDP ports

Starting with TGL eDP is supported on ports B+ (besides port A), so make
sure DC states are not blocked on any such ports. For this add an
AUX_IO_ power domain for each port with eDP support. These domains
similarly to AUX_IO_A enable only the AUX_IO_ power well for an
enabled port, whereas the existing AUX_ domains enable both the
AUX_IO_ and the DC_OFF power wells as required by DP AUX transfers.

v2: (Ville)
- Split the change using AUX vs. AUX_IO on port A to a separate patch.
- Select AUX_IO vs. AUX based on crtc_state->has_psr instead of
  is_edp().
v3:
- Rebased on checking intel_encoder_can_psr() instead of crtc->has_psr.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  6 ++-
 .../drm/i915/display/intel_display_power.c| 30 +++
 .../drm/i915/display/intel_display_power.h|  7 +++
 .../i915/display/intel_display_power_map.c| 53 +--
 4 files changed, 89 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca236cd7f9b76..a087609223c60 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -848,6 +848,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
 static enum intel_display_power_domain
 intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port)
 {
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
/* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
 * DC states enabled at the same time, while for driver initiated AUX
 * transfers we need the same AUX IOs to be powered but with DC states
@@ -860,8 +862,8 @@ intel_ddi_main_link_aux_domain(struct intel_digital_port 
*dig_port)
 * Note that PSR is enabled only on Port A even though this function
 * returns the correct domain for other ports too.
 */
-   if (dig_port->aux_ch == AUX_CH_A && 
intel_encoder_can_psr(_port->base))
-   return POWER_DOMAIN_AUX_IO_A;
+   if (intel_encoder_can_psr(_port->base))
+   return intel_display_power_aux_io_domain(i915, 
dig_port->aux_ch);
else
return intel_aux_power_domain(dig_port);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 78f1749397e1d..61c6a3616db08 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -131,6 +131,16 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "AUDIO_PLAYBACK";
case POWER_DOMAIN_AUX_IO_A:
return "AUX_IO_A";
+   case POWER_DOMAIN_AUX_IO_B:
+   return "AUX_IO_B";
+   case POWER_DOMAIN_AUX_IO_C:
+   return "AUX_IO_C";
+   case POWER_DOMAIN_AUX_IO_D:
+   return "AUX_IO_D";
+   case POWER_DOMAIN_AUX_IO_E:
+   return "AUX_IO_E";
+   case POWER_DOMAIN_AUX_IO_F:
+   return "AUX_IO_F";
case POWER_DOMAIN_AUX_A:
return "AUX_A";
case POWER_DOMAIN_AUX_B:
@@ -2356,6 +2366,7 @@ struct intel_ddi_port_domains {
 
enum intel_display_power_domain ddi_lanes;
enum intel_display_power_domain ddi_io;
+   enum intel_display_power_domain aux_io;
enum intel_display_power_domain aux_legacy_usbc;
enum intel_display_power_domain aux_tbt;
 };
@@ -2370,6 +2381,7 @@ i9xx_port_domains[] = {
 
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_A,
.ddi_io = POWER_DOMAIN_PORT_DDI_IO_A,
+   .aux_io = POWER_DOMAIN_AUX_IO_A,
.aux_legacy_usbc = POWER_DOMAIN_AUX_A,
.aux_tbt = POWER_DOMAIN_INVALID,
},
@@ -2385,6 +2397,7 @@ d11_port_domains[] = {
 
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_A,
.ddi_io = POWER_DOMAIN_PORT_DDI_IO_A,
+   .aux_io = POWER_DOMAIN_AUX_IO_A,
.aux_legacy_usbc = POWER_DOMAIN_AUX_A,
.aux_tbt = POWER_DOMAIN_INVALID,
}, {
@@ -2395,6 +2408,7 @@ d11_port_domains[] = {
 
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_C,
.ddi_io = POWER_DOMAIN_PORT_DDI_IO_C,
+   .aux_io = POWER_DOMAIN_AUX_IO_C,
.aux_legacy_usbc = POWER_DOMAIN_AUX_C,
.aux_tbt = POWER_DOMAIN_AUX_TBT1,
},
@@ -2410,6 +2424,7 @@ d12_port_domains[] = {
 
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_A,
.ddi_io = POWER_DOMAIN_PORT_DDI_IO_A,
+   .aux_io = POWER_DOMAIN_AUX_IO_A,
.aux_legacy_usbc = POWER_DOMAIN_AUX_A,
.aux_tbt = POWER_DOMAIN_INVALID,
}, {
@@ -2420,6 +2435,7 @@ d12_port_domains[] = {
 
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_TC1,
.ddi_io =

[Intel-gfx] [PATCH v2 01/15] drm/i915/audio: Don't program the hardware ELD buffer on ilk+

From: Ville Syrjälä 

Since we use the audio component to transfer the ELD to the audio
driver on ilk+ platforms there is no point in even programming
the hardware ELD buffer. Stop doing so.

The one slight caveat here is that this is not strictly legal
according to the HDA spec. PD=1;ELD=0 is only documented as
an intermediate state during modeset. But if there is no hardware
that depends on that then I guess we're fine. Or we could
perhaps set ELD=1 without actually programming the buffer?

Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 ->
PD=1;ELD=1 is also not strictly correct according to the HDA
spec, as the only documented transition from PD=0;ELD=0 is
straight to PD=1;ELD=1. But that is not even possible on
these platforms as the bits live in different registers.

Cc: Chaitanya Kumar Borah 
Cc: Kai Vehmanen 
Cc: Takashi Iwai 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 39 +++---
 1 file changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index c3176c9c89a6..dbcb4d9ecde7 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -691,20 +691,6 @@ static void ilk_audio_regs_init(struct drm_i915_private 
*i915,
}
 }
 
-/* ELD buffer size in dwords */
-static int ilk_eld_buffer_size(struct drm_i915_private *i915,
-  enum pipe pipe)
-{
-   struct ilk_audio_regs regs;
-   u32 tmp;
-
-   ilk_audio_regs_init(i915, pipe, );
-
-   tmp = intel_de_read(i915, regs.aud_cntl_st);
-
-   return REG_FIELD_GET(IBX_ELD_BUFFER_SIZE_MASK, tmp);
-}
-
 static void ilk_audio_codec_disable(struct intel_encoder *encoder,
const struct intel_crtc_state 
*old_crtc_state,
const struct drm_connector_state 
*old_conn_state)
@@ -747,11 +733,8 @@ static void ilk_audio_codec_enable(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_connector *connector = conn_state->connector;
-   const u32 *eld = (const u32 *)connector->eld;
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
-   int eld_buffer_size, len, i;
struct ilk_audio_regs regs;
 
if (drm_WARN_ON(>drm, port == PORT_A))
@@ -767,24 +750,10 @@ static void ilk_audio_codec_enable(struct intel_encoder 
*encoder,
intel_de_rmw(i915, regs.aud_cntrl_st2,
 IBX_ELD_VALID(port), 0);
 
-   /* Reset ELD address */
-   intel_de_rmw(i915, regs.aud_cntl_st,
-IBX_ELD_ADDRESS_MASK, 0);
-
-   eld_buffer_size = ilk_eld_buffer_size(i915, pipe);
-   len = min(drm_eld_size(connector->eld) / 4, eld_buffer_size);
-
-   for (i = 0; i < len; i++)
-   intel_de_write(i915, regs.hdmiw_hdmiedid, eld[i]);
-   for (; i < eld_buffer_size; i++)
-   intel_de_write(i915, regs.hdmiw_hdmiedid, 0);
-
-   drm_WARN_ON(>drm,
-   (intel_de_read(i915, regs.aud_cntl_st) & 
IBX_ELD_ADDRESS_MASK) != 0);
-
-   /* ELD valid */
-   intel_de_rmw(i915, regs.aud_cntrl_st2,
-0, IBX_ELD_VALID(port));
+   /*
+* The audio componenent is used to convey the ELD
+* instead using of the hardware ELD buffer.
+*/
 
/* Enable timestamps */
intel_de_rmw(i915, regs.aud_config,
-- 
2.37.4

[Intel-gfx] [PATCH v3 3/9] drm/i915: Use the AUX_IO power domain only for eDP/PSR port

Use the AUX_IO_A display power domain only for eDP on port A where PSR
is also supported. This is the case where DC states need to be enabled
while the output is enabled - ensured by AUX_IO_A domain not enabling
the DC_OFF power well. Otherwise port A can be treated the same way as
other ports with an external DP output: using the AUX_ domain
which disables the unrequired DC states.

This change prepares for the next patch enabling DC states on all ports
supporting eDP/PSR besides port A.

v2:
- Check the encoder PSR capability instead of PSR being enabled in the
  crtc_state, as the latter can be changed with a fastset.

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

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e95bde5cf060e..ca236cd7f9b76 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -860,8 +860,10 @@ intel_ddi_main_link_aux_domain(struct intel_digital_port 
*dig_port)
 * Note that PSR is enabled only on Port A even though this function
 * returns the correct domain for other ports too.
 */
-   return dig_port->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
- intel_aux_power_domain(dig_port);
+   if (dig_port->aux_ch == AUX_CH_A && 
intel_encoder_can_psr(_port->base))
+   return POWER_DOMAIN_AUX_IO_A;
+   else
+   return intel_aux_power_domain(dig_port);
 }
 
 static void intel_ddi_get_power_domains(struct intel_encoder *encoder,
-- 
2.37.1

[Intel-gfx] [PATCH v3 1/9] drm/i915: Allocate power domain set wakerefs dynamically

Since the intel_display_power_domain_set struct, currently its current
size close to 1kB, can be allocated on the stack, it's better to
allocate the per-domain wakeref pointer array - used for debugging -
within the struct dynamically, so do this.

The memory freeing is guaranteed by the fact that the acquired domain
references tracked by the struct can't be leaked either.

v2:
- Don't use fetch_and_zero() when freeing the wakerefs array. (Jani)
- Simplify intel_display_power_get/put_in_set(). (Jani)
- Check in intel_crtc_destroy() that the wakerefs array has been freed.
v3:
- Add intel_display_power_set_disabled() and a separate assert
  function instead of open coding these. (Jani)

Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_crtc.c |  11 ++
 .../drm/i915/display/intel_display_power.c| 109 ++
 .../drm/i915/display/intel_display_power.h|   6 +-
 3 files changed, 104 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 037fc140b585c..c18d98bfe1a7c 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -21,6 +21,7 @@
 #include "intel_crtc.h"
 #include "intel_cursor.h"
 #include "intel_display_debugfs.h"
+#include "intel_display_power.h"
 #include "intel_display_trace.h"
 #include "intel_display_types.h"
 #include "intel_drrs.h"
@@ -37,6 +38,14 @@ static void assert_vblank_disabled(struct drm_crtc *crtc)
drm_crtc_vblank_put(crtc);
 }
 
+static void assert_power_domains_disabled(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+   drm_WARN_ON(>drm,
+   !intel_display_power_set_disabled(i915, 
>enabled_power_domains));
+}
+
 struct intel_crtc *intel_first_crtc(struct drm_i915_private *i915)
 {
return to_intel_crtc(drm_crtc_from_index(>drm, 0));
@@ -204,6 +213,8 @@ static void intel_crtc_destroy(struct drm_crtc *_crtc)
 
cpu_latency_qos_remove_request(>vblank_pm_qos);
 
+   assert_power_domains_disabled(crtc);
+
drm_crtc_cleanup(>base);
kfree(crtc);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4c1de91e56ff9..ca63b4f1af41b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -830,20 +830,85 @@ void intel_display_power_put_unchecked(struct 
drm_i915_private *dev_priv,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
+static void
+add_domain_to_set(struct drm_i915_private *i915,
+ struct intel_display_power_domain_set *power_domain_set,
+ enum intel_display_power_domain domain,
+ intel_wakeref_t wf)
+{
+   drm_WARN_ON(>drm, test_bit(domain, power_domain_set->mask.bits));
+
+   if (!power_domain_set->wakerefs)
+   power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
+
sizeof(*power_domain_set->wakerefs),
+GFP_KERNEL);
+
+   if (power_domain_set->wakerefs)
+   power_domain_set->wakerefs[domain] = wf;
+
+   set_bit(domain, power_domain_set->mask.bits);
+}
+
+static intel_wakeref_t
+remove_domain_from_set(struct drm_i915_private *i915,
+  struct intel_display_power_domain_set *power_domain_set,
+  enum intel_display_power_domain domain)
+{
+   intel_wakeref_t wf;
+
+   drm_WARN_ON(>drm, !test_bit(domain, power_domain_set->mask.bits));
+
+   clear_bit(domain, power_domain_set->mask.bits);
+
+   if (!power_domain_set->wakerefs)
+   return -1;
+
+   wf = fetch_and_zero(_domain_set->wakerefs[domain]);
+
+   if (bitmap_empty(power_domain_set->mask.bits, POWER_DOMAIN_NUM)) {
+   kfree(power_domain_set->wakerefs);
+   power_domain_set->wakerefs = NULL;
+   }
+
+   return wf;
+
+}
+#else
+static void
+add_domain_to_set(struct drm_i915_private *i915,
+ struct intel_display_power_domain_set *power_domain_set,
+ enum intel_display_power_domain domain,
+ intel_wakeref_t wf)
+{
+   drm_WARN_ON(>drm, test_bit(domain, power_domain_set->mask.bits));
+
+   set_bit(domain, power_domain_set->mask.bits);
+}
+
+static intel_wakeref_t
+remove_domain_from_set(struct drm_i915_private *i915,
+  struct intel_display_power_domain_set *power_domain_set,
+  enum intel_display_power_domain domain)
+{
+   drm_WARN_ON(>drm, !test_bit(domain, power_domain_set->mask.bits));
+
+   clear_bit(domain, power_domain_set->mask.bits);
+
+   return -1;
+}
+#endif
+
 void
 intel_display_power_get_in_set(struct drm_i915_private *i915,
   struct

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: never purge busy objects

2022-11-08 Thread Vudum, Lakshminarayana

Issue is related to https://gitlab.freedesktop.org/drm/intel/-/issues/7379

Lakshmi.
-Original Message-
From: Auld, Matthew  
Sent: Tuesday, November 8, 2022 5:49 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/ttm: never purge busy objects

On 07/11/2022 17:57, Patchwork wrote:
> *Patch Details*
> *Series:* drm/i915/ttm: never purge busy objects
> *URL:*https://patchwork.freedesktop.org/series/110601/ 
> 
> *State:*  failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/index.html
>  l>
> 
> 
>   CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110601v1
> 
> 
> Summary
> 
> *FAILURE*
> 
> Serious unknown changes coming with Patchwork_110601v1 absolutely need 
> to be verified manually.
> 
> If you think the reported changes have nothing to do with the changes 
> introduced in Patchwork_110601v1, please notify your bug team to allow 
> them to document this new failure mode, which will reduce false positives in 
> CI.
> 
> External URL: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/index.html
> 
> 
> Participating hosts (42 -> 30)
> 
> Additional (2): fi-kbl-soraka fi-cml-u2 Missing (14): fi-ilk-m540 
> fi-bdw-samus fi-tgl-dsi fi-hsw-4200u bat-dg2-9
> bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1
> bat-rpls-2 bat-dg2-11 bat-jsl-1
> 
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_110601v1:
> 
> 
>   IGT changes
> 
> 
> Possible regressions
> 
>   * igt@i915_suspend@basic-s3-without-i915:
>   o fi-cml-u2: NOTRUN -> INCOMPLETE
> 
>  /igt@i915_susp...@basic-s3-without-i915.html>

Unrelated. Patch only affects discrete platforms.

> 
> 
> Known issues
> 
> Here are the changes found in Patchwork_110601v1 that come from known
> issues:
> 
> 
>   IGT changes
> 
> 
> Issues hit
> 
>   *
> 
> igt@gem_exec_fence@basic-busy@bcs0:
> 
>   o fi-cml-u2: NOTRUN -> SKIP
> 
> 
>  (i915#1208 ) +1 
> similar issue
>   *
> 
> igt@gem_exec_gttfill@basic:
> 
>   o
> 
> fi-kbl-soraka: NOTRUN -> SKIP
> 
>  raka/igt@gem_exec_gttf...@basic.html> (fdo#109271 
> ) +8 similar 
> issues
> 
>   o
> 
> fi-pnv-d510: PASS
> 
>  @gem_exec_gttf...@basic.html> -> FAIL 
>  10/igt@gem_exec_gttf...@basic.html> (i915#7229 
> )
> 
>   *
> 
> igt@gem_huc_copy@huc-copy:
> 
>   o
> 
> fi-cml-u2: NOTRUN -> SKIP
> 
>  /igt@gem_huc_c...@huc-copy.html> (i915#2190 
> )
> 
>   o
> 
> fi-kbl-soraka: NOTRUN -> SKIP
> 
>  raka/igt@gem_huc_c...@huc-copy.html> (fdo#109271 
>  / i915#2190 
> )
> 
>   *
> 
> igt@gem_lmem_swapping@basic:
> 
>   o fi-kbl-soraka: NOTRUN -> SKIP
> 
> 
>  (fdo#109271  / 
> i915#4613 ) +3 similar 
> issues
>   *
> 
> igt@gem_lmem_swapping@verify-random:
> 
>   o fi-cml-u2: NOTRUN -> SKIP
> 
> 
>  (i915#4613 ) +3 
> similar issues
>   *
> 
> igt@i915_selftest@live@gem_contexts:
> 
>   o fi-kbl-soraka: NOTRUN -> INCOMPLETE
> 
> 
>  (i915#7099 )
>   *
> 
> igt@i915_selftest@live@gt_pm:
> 
>   o fi-kbl-soraka: NOTRUN -> DMESG-FAIL
> 
> 
>  (i915#1886

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: never purge busy objects

== Series Details ==

Series: drm/i915/ttm: never purge busy objects
URL   : https://patchwork.freedesktop.org/series/110601/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110601v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 30)
--

  Additional (2): fi-kbl-soraka fi-cml-u2 
  Missing(14): fi-ilk-m540 fi-bdw-samus fi-tgl-dsi fi-hsw-4200u bat-dg2-9 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 
bat-dg2-11 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][1] ([i915#1208]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][3] -> [FAIL][4] ([i915#7229])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

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

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][9] ([i915#7099])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][10] ([i915#1886])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-cml-u2:  NOTRUN -> [INCOMPLETE][11] ([i915#7379])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-cml-u2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-ivb-3770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-ivb-3770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109284] / [fdo#111827]) +7 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v1/fi-cml-u2/igt@kms_chamel...@vga-hpd-fast.html

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

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

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

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-cml-u2:  NOTRUN -> [SKIP][19] ([i915#3555])
   [19]:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling

== Series Details ==

Series: series starting with [1/2] drm/i915/ttm: fix uaf with 
lmem_userfault_list handling
URL   : https://patchwork.freedesktop.org/series/110613/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12351_full -> Patchwork_110613v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[FAIL][48], [PASS][49]) ([i915#4392])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk7/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk3/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk3/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk5/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk7/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk8/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk3/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12351/shard-glk3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk2/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk2/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk2/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk3/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk3/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk3/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk6/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk6/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk7/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk7/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110613v1/shard-glk7/boot.html
   [43]:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: never purge busy objects

2022-11-08 Thread Matthew Auld


On 07/11/2022 17:57, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915/ttm: never purge busy objects
*URL:*	https://patchwork.freedesktop.org/series/110601/ 


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




  CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110601v1


Summary

*FAILURE*

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

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

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



Participating hosts (42 -> 30)

Additional (2): fi-kbl-soraka fi-cml-u2
Missing (14): fi-ilk-m540 fi-bdw-samus fi-tgl-dsi fi-hsw-4200u bat-dg2-9 
bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 
bat-rpls-2 bat-dg2-11 bat-jsl-1



Possible new issues

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



  IGT changes


Possible regressions

  * igt@i915_suspend@basic-s3-without-i915:
  o fi-cml-u2: NOTRUN -> INCOMPLETE




Unrelated. Patch only affects discrete platforms.




Known issues

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



  IGT changes


Issues hit

  *

igt@gem_exec_fence@basic-busy@bcs0:

  o fi-cml-u2: NOTRUN -> SKIP


 (i915#1208 ) +1 similar issue
  *

igt@gem_exec_gttfill@basic:

  o

fi-kbl-soraka: NOTRUN -> SKIP


 (fdo#109271 ) +8 similar issues

  o

fi-pnv-d510: PASS


 -> FAIL 

 (i915#7229 )

  *

igt@gem_huc_copy@huc-copy:

  o

fi-cml-u2: NOTRUN -> SKIP


 (i915#2190 )

  o

fi-kbl-soraka: NOTRUN -> SKIP


 (fdo#109271  / i915#2190 
)

  *

igt@gem_lmem_swapping@basic:

  o fi-kbl-soraka: NOTRUN -> SKIP


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

igt@gem_lmem_swapping@verify-random:

  o fi-cml-u2: NOTRUN -> SKIP


 (i915#4613 ) +3 similar issues
  *

igt@i915_selftest@live@gem_contexts:

  o fi-kbl-soraka: NOTRUN -> INCOMPLETE


 (i915#7099 )
  *

igt@i915_selftest@live@gt_pm:

  o fi-kbl-soraka: NOTRUN -> DMESG-FAIL


 (i915#1886 )
  *

igt@kms_chamelium@common-hpd-after-suspend:

  o

fi-ivb-3770: NOTRUN -> SKIP


 (fdo#109271  / fdo#111827 
)

  o

fi-hsw-4770: NOTRUN -> SKIP


 (fdo#109271  /

Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Allocate power domain set wakerefs dynamically

On Tue, Nov 08, 2022 at 10:54:21AM +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2022, Imre Deak  wrote:
> > Since the intel_display_power_domain_set struct, currently its current
> > size close 1kB, can be allocated on the stack, it's better to allocate
> > the per-domain wakeref pointer array - used for debugging - within the
> > struct dynamically, so do this.
> >
> > The memory freeing is guaranteed by the fact that the acquired domain
> > references tracked by struct can't be leaked either.
> >
> > v2:
> > - Don't use fetch_and_zero() when freeing the wakerefs array. (Jani)
> > - Simplify intel_display_power_get/put_in_set(). (Jani)
> > - Check in intel_crtc_destroy() that the wakerefs array has been freed.
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/intel_crtc.c |  4 +
> >  .../drm/i915/display/intel_display_power.c| 95 +++
> >  .../drm/i915/display/intel_display_power.h|  2 +-
> >  3 files changed, 79 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 037fc140b585c..2c8d564e73182 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -205,6 +205,10 @@ static void intel_crtc_destroy(struct drm_crtc *_crtc)
> > cpu_latency_qos_remove_request(>vblank_pm_qos);
> >  
> > drm_crtc_cleanup(>base);
> > +
> > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > +   drm_WARN_ON(crtc->base.dev, crtc->enabled_power_domains.wakerefs);
> > +#endif
> 
> Can we please not add this kind of asserts without abstractions? The
> #ifdef is ugly, looking at crtc->enabled_power_domains.wakerefs directly
> is ugly.
>
> Maybe add an assert_something_or_other(crtc) that does the right thing?
> Similar to the other assert_*() functions we have?

Yes, can add assert_power_domains_disabled(crtc) to this file.

> Does it even need to depend on the config? If it's worth having, maybe
> worth having unconditionally?

The wakerefs array exists only when the config is enabled, but the
non-debug crtc->enabled_power_domains.mask should be checked as well.

> BR,
> Jani.
> 
> > kfree(crtc);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 4c1de91e56ff9..db235b79c9629 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -830,20 +830,85 @@ void intel_display_power_put_unchecked(struct 
> > drm_i915_private *dev_priv,
> >  }
> >  #endif
> >  
> > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > +static void
> > +add_domain_to_set(struct drm_i915_private *i915,
> > + struct intel_display_power_domain_set *power_domain_set,
> > + enum intel_display_power_domain domain,
> > + intel_wakeref_t wf)
> > +{
> > +   drm_WARN_ON(>drm, test_bit(domain, power_domain_set->mask.bits));
> > +
> > +   if (!power_domain_set->wakerefs)
> > +   power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > +
> > sizeof(*power_domain_set->wakerefs),
> > +GFP_KERNEL);
> > +
> > +   if (power_domain_set->wakerefs)
> > +   power_domain_set->wakerefs[domain] = wf;
> > +
> > +   set_bit(domain, power_domain_set->mask.bits);
> > +}
> > +
> > +static intel_wakeref_t
> > +remove_domain_from_set(struct drm_i915_private *i915,
> > +  struct intel_display_power_domain_set *power_domain_set,
> > +  enum intel_display_power_domain domain)
> > +{
> > +   intel_wakeref_t wf;
> > +
> > +   drm_WARN_ON(>drm, !test_bit(domain, power_domain_set->mask.bits));
> > +
> > +   clear_bit(domain, power_domain_set->mask.bits);
> > +
> > +   if (!power_domain_set->wakerefs)
> > +   return -1;
> > +
> > +   wf = fetch_and_zero(_domain_set->wakerefs[domain]);
> > +
> > +   if (bitmap_empty(power_domain_set->mask.bits, POWER_DOMAIN_NUM)) {
> > +   kfree(power_domain_set->wakerefs);
> > +   power_domain_set->wakerefs = NULL;
> > +   }
> > +
> > +   return wf;
> > +
> > +}
> > +#else
> > +static void
> > +add_domain_to_set(struct drm_i915_private *i915,
> > + struct intel_display_power_domain_set *power_domain_set,
> > + enum intel_display_power_domain domain,
> > + intel_wakeref_t wf)
> > +{
> > +   drm_WARN_ON(>drm, test_bit(domain, power_domain_set->mask.bits));
> > +
> > +   set_bit(domain, power_domain_set->mask.bits);
> > +}
> > +
> > +static intel_wakeref_t
> > +remove_domain_from_set(struct drm_i915_private *i915,
> > +  struct intel_display_power_domain_set *power_domain_set,
> > +  enum intel_display_power_domain domain)
> > +{
> > +   drm_WARN_ON(>drm, !test_bit(domain,

Re: [Intel-gfx] [Nouveau] [PATCH v7 00/23] drm: Analog TV Improvements

2022-11-08 Thread Geert Uytterhoeven

Hi Lukas,

On Tue, Nov 8, 2022 at 2:20 PM Lukas Satin  wrote:
> One can switch from NTSC to PAL now using (on vc4)
>
> modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
>
> NTSC should be 640x480i, not 720. It will probably work on most TV's, but 
> NTSC by the spec is 640x480i.

The above are actually the digital ("DVD Video") variants, which have 720
horizontal pixels (incl. overscan).
The analog variants do not have a fixed horizontal resolution, except
for bandwidth limitations.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Separate PXP FW interface structures for

== Series Details ==

Series: drm/i915/pxp: Separate PXP FW interface structures for
URL   : https://patchwork.freedesktop.org/series/110652/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12353_full -> Patchwork_110652v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12353/shard-iclb2/igt@feature_discov...@psr2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-iclb1/igt@feature_discov...@psr2.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12353/shard-iclb2/igt@gem_exec_balan...@parallel-keep-in-fence.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-iclb6/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12353/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-glk8/igt@gem_lmem_swapp...@basic.html

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

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-glk:  NOTRUN -> [INCOMPLETE][10] ([i915#7248])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-glk6/igt@gem_pwr...@basic-exhaustion.html

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

  * igt@gem_userptr_blits@vma-merge:
- shard-skl:  NOTRUN -> [FAIL][12] ([i915#3318])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-skl7/igt@gem_userptr_bl...@vma-merge.html

  * igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +6 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-glk8/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-skl7/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-apl7/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@hdmi-hpd:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-apl7/igt@kms_chamel...@hdmi-hpd.html

  * igt@kms_color_chamelium@ctm-limited-range:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-skl7/igt@kms_color_chamel...@ctm-limited-range.html

  * igt@kms_color_chamelium@ctm-red-to-blue:
- shard-glk:  NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110652v1/shard-glk8/igt@kms_color_chamel...@ctm-red-to-blue.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-b-edp-1:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#2411])
   [19]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Partial abandonment of legacy DRM logging macros (rev2)

== Series Details ==

Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev2)
URL   : https://patchwork.freedesktop.org/series/110660/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12354 -> Patchwork_110660v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 38)
--

  Additional (1): fi-tgl-dsi 
  Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][1] ([fdo#109271]) +31 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-bdw-gvtdvm/igt@gem_lmem_swapp...@basic.html

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][2] -> [INCOMPLETE][3] ([i915#7056])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-4: [PASS][6] -> [INCOMPLETE][7] ([i915#7308] / 
[i915#7348])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/bat-adlp-4/igt@i915_selftest@l...@migrate.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/bat-adlp-4/igt@i915_selftest@l...@migrate.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][8] ([i915#146])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html

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

  
 Possible fixes 

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

  * igt@gem_exec_parallel@engines@contexts:
- fi-bdw-gvtdvm:  [INCOMPLETE][14] -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html

  * igt@gem_linear_blits@basic:
- fi-pnv-d510:[SKIP][16] ([fdo#109271]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-pnv-d510/igt@gem_linear_bl...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/fi-pnv-d510/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][18] ([i915#7348]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [DMESG-FAIL][20] ([i915#4983]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110660v2/bat-rpls-2/igt@i915_selftest@l...@reset.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Partial abandonment of legacy DRM logging macros (rev2)

== Series Details ==

Series: drm/i915: Partial abandonment of legacy DRM logging macros (rev2)
URL   : https://patchwork.freedesktop.org/series/110660/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Partial abandonment of legacy DRM logging macros

On Tue, 08 Nov 2022, Tvrtko Ursulin  wrote:
> From: Tvrtko Ursulin 
>
> Convert some usages of legacy DRM logging macros into versions which tell
> us on which device have the events occurred.

Acked-by: Jani Nikula 

>
> v2:
>  * Don't have struct drm_device as local. (Jani, Ville)
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: Jani Nikula 
> Cc: John Harrison 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 26 +++
>  .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
>  drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
>  .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
>  .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
>  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
>  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
>  drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
>  drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
>  drivers/gpu/drm/i915/i915_query.c | 12 +++---
>  drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
>  drivers/gpu/drm/i915/i915_vma.c   | 16 ---
>  drivers/gpu/drm/i915/intel_uncore.c   | 21 +
>  19 files changed, 119 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 01402f3c58f6..7f2831efc798 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
> __user *base, void *data)
>   }
>  
>   if (intel_engine_uses_guc(master)) {
> - DRM_DEBUG("bonding extension not supported with GuC 
> submission");
> + drm_dbg(>drm, "bonding extension not supported with GuC 
> submission");
>   return -ENODEV;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1160723c9d2d..f65fd03f7cf2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
>   return err;
>  }
>  
> -static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)
> +static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
> +  struct drm_i915_gem_execbuffer2 *exec)
>  {
>   if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
>   return -EINVAL;
> @@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
> drm_i915_gem_execbuffer2 *exec)
>   }
>  
>   if (exec->DR4 == 0x) {
> - DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> + drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
>   exec->DR4 = 0;
>   }
>   if (exec->DR1 || exec->DR4)
> @@ -2799,7 +2800,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>  
>   syncobj = drm_syncobj_find(eb->file, user_fence.handle);
>   if (!syncobj) {
> - DRM_DEBUG("Invalid syncobj handle provided\n");
> + drm_dbg(>i915->drm,
> + "Invalid syncobj handle provided\n");
>   return -ENOENT;
>   }
>  
> @@ -2807,7 +2809,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>  
>   if (!fence && user_fence.flags &&
>   !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
> - DRM_DEBUG("Syncobj handle has no fence\n");
> + drm_dbg(>i915->drm,
> + "Syncobj handle has no fence\n");
>   drm_syncobj_put(syncobj);
>   return -EINVAL;
>   }
> @@ -2816,7 +2819,9 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>   err = dma_fence_chain_find_seqno(, point);
>  
>   if (err && !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
> - DRM_DEBUG("Syncobj handle missing requested point 
> %llu\n", point);
> + drm_dbg(>i915->drm,
> + "Syncobj handle missing requested point %llu\n",
> + point);
>   dma_fence_put(fence);
>   drm_syncobj_put(syncobj);
>   return err;
> @@ -2842,7 +2847,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>* 0) would break the timeline.
>*/
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use i915_sg_dma_sizes() for all backends (rev2)

== Series Details ==

Series: drm/i915: use i915_sg_dma_sizes() for all backends (rev2)
URL   : https://patchwork.freedesktop.org/series/110620/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12354 -> Patchwork_110620v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 36)
--

  Missing(4): fi-ctg-p8600 fi-hsw-4770 fi-ilk-m540 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][1] ([i915#146])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([fdo#111827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_flip@basic-plain-flip:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][4] ([fdo#109271]) +31 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-bdw-gvtdvm/igt@kms_f...@basic-plain-flip.html

  
 Possible fixes 

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

  * igt@gem_exec_parallel@engines@contexts:
- fi-bdw-gvtdvm:  [INCOMPLETE][7] -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html

  * igt@gem_linear_blits@basic:
- fi-pnv-d510:[SKIP][9] ([fdo#109271]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-pnv-d510/igt@gem_linear_bl...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-pnv-d510/igt@gem_linear_bl...@basic.html

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

  * igt@i915_selftest@live@migrate:
- {bat-adlp-6}:   [INCOMPLETE][13] ([i915#7348]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  
 Warnings 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [INCOMPLETE][15] ([i915#4817]) -> [FAIL][16] 
([fdo#103375])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12354/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110620v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348
  [i915#7355]:

[Intel-gfx] [PATCH v2] drm/i915: Partial abandonment of legacy DRM logging macros

2022-11-08 Thread Tvrtko Ursulin

From: Tvrtko Ursulin 

Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.

v2:
 * Don't have struct drm_device as local. (Jani, Ville)

Signed-off-by: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: John Harrison 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 26 +++
 .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
 drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
 .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
 .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
 drivers/gpu/drm/i915/i915_gem.c   |  2 +-
 drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
 drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
 drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
 drivers/gpu/drm/i915/i915_query.c | 12 +++---
 drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
 drivers/gpu/drm/i915/i915_vma.c   | 16 ---
 drivers/gpu/drm/i915/intel_uncore.c   | 21 +
 19 files changed, 119 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 01402f3c58f6..7f2831efc798 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
__user *base, void *data)
}
 
if (intel_engine_uses_guc(master)) {
-   DRM_DEBUG("bonding extension not supported with GuC 
submission");
+   drm_dbg(>drm, "bonding extension not supported with GuC 
submission");
return -ENODEV;
}
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1160723c9d2d..f65fd03f7cf2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
return err;
 }
 
-static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)
+static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
+struct drm_i915_gem_execbuffer2 *exec)
 {
if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
return -EINVAL;
@@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
}
 
if (exec->DR4 == 0x) {
-   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
exec->DR4 = 0;
}
if (exec->DR1 || exec->DR4)
@@ -2799,7 +2800,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 
syncobj = drm_syncobj_find(eb->file, user_fence.handle);
if (!syncobj) {
-   DRM_DEBUG("Invalid syncobj handle provided\n");
+   drm_dbg(>i915->drm,
+   "Invalid syncobj handle provided\n");
return -ENOENT;
}
 
@@ -2807,7 +2809,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 
if (!fence && user_fence.flags &&
!(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
-   DRM_DEBUG("Syncobj handle has no fence\n");
+   drm_dbg(>i915->drm,
+   "Syncobj handle has no fence\n");
drm_syncobj_put(syncobj);
return -EINVAL;
}
@@ -2816,7 +2819,9 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
err = dma_fence_chain_find_seqno(, point);
 
if (err && !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
-   DRM_DEBUG("Syncobj handle missing requested point 
%llu\n", point);
+   drm_dbg(>i915->drm,
+   "Syncobj handle missing requested point %llu\n",
+   point);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return err;
@@ -2842,7 +2847,8 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 * 0) would break the timeline.
 */
if (user_fence.flags & I915_EXEC_FENCE_WAIT) {
-   DRM_DEBUG("Trying to wait & signal the same 
timeline point.\n");
+

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: use i915_sg_dma_sizes() for all backends (rev2)

== Series Details ==

Series: drm/i915: use i915_sg_dma_sizes() for all backends (rev2)
URL   : https://patchwork.freedesktop.org/series/110620/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: use i915_sg_dma_sizes() for all backends (rev2)

== Series Details ==

Series: drm/i915: use i915_sg_dma_sizes() for all backends (rev2)
URL   : https://patchwork.freedesktop.org/series/110620/
State : warning

== Summary ==

Error: dim checkpatch failed
681e3d6ac1e4 drm/i915: use i915_sg_dma_sizes() for all backends
-:121: 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
#121: FILE: drivers/gpu/drm/i915/gem/i915_gem_pages.c:48:
+   GEM_BUG_ON(!obj->mm.page_sizes.phys);

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Move has_hdmi_sink out from intel_hdmi_compute_config()

On Mon, 07 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> We'll be wanting to compute has_hdmi_sink a bit differently
> for some platforms. To that end compute it in the encoder
> .compute_config_hook() before we call intel_hdmi_compute_config().
> intel_hdmi_compute_has_hdmi_sink() will do the basic lifting
> beyond any platform specific stuff.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

But, uh, I don't want to dig into patch 5 right now, and this one
doesn't really make sense without that... in the mean time the first
three look like could be merged.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/display/g4x_hdmi.c   |  3 +++
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +++
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++
>  drivers/gpu/drm/i915/display/intel_hdmi.h |  3 +++
>  4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c 
> b/drivers/gpu/drm/i915/display/g4x_hdmi.c
> index 3d09359d7337..fd23aa03cdc4 100644
> --- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
> @@ -87,6 +87,9 @@ static int g4x_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   if (HAS_PCH_SPLIT(i915))
>   crtc_state->has_pch_encoder = true;
>  
> + crtc_state->has_hdmi_sink =
> + intel_hdmi_compute_has_hdmi_sink(encoder, crtc_state, 
> conn_state);
> +
>   return intel_hdmi_compute_config(encoder, crtc_state, conn_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index e95bde5cf060..5ebfbe7b81b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3638,6 +3638,9 @@ static int intel_ddi_compute_config(struct 
> intel_encoder *encoder,
>   pipe_config->cpu_transcoder = TRANSCODER_EDP;
>  
>   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI)) {
> + pipe_config->has_hdmi_sink =
> + intel_hdmi_compute_has_hdmi_sink(encoder, pipe_config, 
> conn_state);
> +
>   ret = intel_hdmi_compute_config(encoder, pipe_config, 
> conn_state);
>   } else {
>   ret = intel_dp_compute_config(encoder, pipe_config, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 31927f8238d1..2425a9f59b90 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2237,11 +2237,20 @@ static bool intel_hdmi_is_cloned(const struct 
> intel_crtc_state *crtc_state)
>   !is_power_of_2(crtc_state->uapi.encoder_mask);
>  }
>  
> +bool intel_hdmi_compute_has_hdmi_sink(struct intel_encoder *encoder,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct drm_connector_state 
> *conn_state)
> +{
> + struct intel_hdmi *hdmi = enc_to_intel_hdmi(encoder);
> +
> + return intel_has_hdmi_sink(hdmi, conn_state) &&
> + !intel_hdmi_is_cloned(crtc_state);
> +}
> +
>  int intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
>  {
> - struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
>   struct drm_connector *connector = conn_state->connector;
> @@ -2252,9 +2261,6 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   return -EINVAL;
>  
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - pipe_config->has_hdmi_sink =
> - intel_has_hdmi_sink(intel_hdmi, conn_state) &&
> - !intel_hdmi_is_cloned(pipe_config);
>  
>   if (pipe_config->has_hdmi_sink)
>   pipe_config->has_infoframe = true;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h 
> b/drivers/gpu/drm/i915/display/intel_hdmi.h
> index 774dda2376ed..dd08b4004c59 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
> @@ -23,6 +23,9 @@ union hdmi_infoframe;
>  
>  void intel_hdmi_init_connector(struct intel_digital_port *dig_port,
>  struct intel_connector *intel_connector);
> +bool intel_hdmi_compute_has_hdmi_sink(struct intel_encoder *encoder,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct drm_connector_state 
> *conn_state);
>  int intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state);

-- 
Jani Nikula, Intel Open

Re: [Intel-gfx] [PATCH] drm/i915: Partial abandonment of legacy DRM logging macros

2022-11-08 Thread Tvrtko Ursulin




On 08/11/2022 12:01, Jani Nikula wrote:

On Tue, 08 Nov 2022, Tvrtko Ursulin  wrote:

From: Tvrtko Ursulin 

Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.

Signed-off-by: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 23 ++
  .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
  drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
  drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
  .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
  .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
  drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
  drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
  drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
  drivers/gpu/drm/i915/i915_query.c | 12 +++---
  drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
  drivers/gpu/drm/i915/i915_vma.c   | 16 ---
  drivers/gpu/drm/i915/intel_uncore.c   | 21 +
  19 files changed, 116 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 01402f3c58f6..7f2831efc798 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
__user *base, void *data)
}
  
  	if (intel_engine_uses_guc(master)) {

-   DRM_DEBUG("bonding extension not supported with GuC 
submission");
+   drm_dbg(>drm, "bonding extension not supported with GuC 
submission");
return -ENODEV;
}
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index 1160723c9d2d..1eb7b66191b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
return err;
  }
  
-static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)

+static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
+struct drm_i915_gem_execbuffer2 *exec)
  {
if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
return -EINVAL;
@@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
}
  
  	if (exec->DR4 == 0x) {

-   DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
+   drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
exec->DR4 = 0;
}
if (exec->DR1 || exec->DR4)
@@ -2744,6 +2745,7 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
 const struct 
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences)
  {
struct drm_i915_gem_exec_fence __user *user_fences;
+   struct drm_device *drm = >i915->drm;


Elsewhere we've been pretty strict about not adding struct drm_device as
a local variable, just struct drm_i915_private *i915. We don't want to
have both, and in general it's more likely i915 is needed than
drm_device, if not now then in the future. Even if it means having to
use >drm here.


Yeah it smelled bad while I was typing it.. will change.

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915: Partial abandonment of legacy DRM logging macros

2022-11-08 Thread Ville Syrjälä

> @@ -2744,6 +2745,7 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>const struct 
> drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences)
>  {
>   struct drm_i915_gem_exec_fence __user *user_fences;
> + struct drm_device *drm = >i915->drm;

We've said a firm "no" to drm_device pointers in display code at 
least. If we want a local device pointer we always make it a 'i915'.
Otherwise you end up with annoying aliases all over the place.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915: Partial abandonment of legacy DRM logging macros

On Tue, 08 Nov 2022, Tvrtko Ursulin  wrote:
> From: Tvrtko Ursulin 
>
> Convert some usages of legacy DRM logging macros into versions which tell
> us on which device have the events occurred.
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: Jani Nikula 
> Cc: John Harrison 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 23 ++
>  .../drm/i915/gt/intel_execlists_submission.c  | 13 +++---
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |  4 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c|  4 +-
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  8 ++--
>  drivers/gpu/drm/i915/gt/intel_rps.c   |  6 ++-
>  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 43 +++
>  .../gpu/drm/i915/gt/intel_workarounds_types.h |  4 ++
>  .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
>  drivers/gpu/drm/i915/i915_debugfs.c   |  4 +-
>  drivers/gpu/drm/i915/i915_gem.c   |  2 +-
>  drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 12 +++---
>  drivers/gpu/drm/i915/i915_perf.c  | 14 +++---
>  drivers/gpu/drm/i915/i915_query.c | 12 +++---
>  drivers/gpu/drm/i915/i915_sysfs.c |  3 +-
>  drivers/gpu/drm/i915/i915_vma.c   | 16 ---
>  drivers/gpu/drm/i915/intel_uncore.c   | 21 +
>  19 files changed, 116 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 01402f3c58f6..7f2831efc798 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -546,7 +546,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension 
> __user *base, void *data)
>   }
>  
>   if (intel_engine_uses_guc(master)) {
> - DRM_DEBUG("bonding extension not supported with GuC 
> submission");
> + drm_dbg(>drm, "bonding extension not supported with GuC 
> submission");
>   return -ENODEV;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1160723c9d2d..1eb7b66191b2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2148,7 +2148,8 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
>   return err;
>  }
>  
> -static int i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec)
> +static int i915_gem_check_execbuffer(struct drm_i915_private *i915,
> +  struct drm_i915_gem_execbuffer2 *exec)
>  {
>   if (exec->flags & __I915_EXEC_ILLEGAL_FLAGS)
>   return -EINVAL;
> @@ -2161,7 +2162,7 @@ static int i915_gem_check_execbuffer(struct 
> drm_i915_gem_execbuffer2 *exec)
>   }
>  
>   if (exec->DR4 == 0x) {
> - DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> + drm_dbg(>drm, "UXA submitting garbage DR4, fixing up\n");
>   exec->DR4 = 0;
>   }
>   if (exec->DR1 || exec->DR4)
> @@ -2744,6 +2745,7 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>const struct 
> drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences)
>  {
>   struct drm_i915_gem_exec_fence __user *user_fences;
> + struct drm_device *drm = >i915->drm;

Elsewhere we've been pretty strict about not adding struct drm_device as
a local variable, just struct drm_i915_private *i915. We don't want to
have both, and in general it's more likely i915 is needed than
drm_device, if not now then in the future. Even if it means having to
use >drm here.

BR,
Jani.


>   u64 __user *user_values;
>   struct eb_fence *f;
>   u64 nfences;
> @@ -2799,7 +2801,7 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>  
>   syncobj = drm_syncobj_find(eb->file, user_fence.handle);
>   if (!syncobj) {
> - DRM_DEBUG("Invalid syncobj handle provided\n");
> + drm_dbg(drm, "Invalid syncobj handle provided\n");
>   return -ENOENT;
>   }
>  
> @@ -2807,7 +2809,7 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>  
>   if (!fence && user_fence.flags &&
>   !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
> - DRM_DEBUG("Syncobj handle has no fence\n");
> + drm_dbg(drm, "Syncobj handle has no fence\n");
>   drm_syncobj_put(syncobj);
>   return -EINVAL;
>   }
> @@ -2816,7 +2818,9 @@ add_timeline_fence_array(struct i915_execbuffer *eb,
>   err = dma_fence_chain_find_seqno(, point);
>  
>   if (err && !(user_fence.flags & I915_EXEC_FENCE_SIGNAL)) {
> - DRM_DEBUG("Syncobj handle missing requested point 
>

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Treat HDMI as DVI when cloning

On Mon, 07 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> When doing HDMI+non-HDMI cloing the other sink can't get

*cloning

> the inframes/etc. so stuff like limited range output is

*infoframes

> not a good idea.
>
> Similarly when doing HDMI+HDMI cloning on g4x (only platform
> where we allow it) only one of the ports can receive infoframes
> and so again using any fancy stuff is a bad idea. We also don't
> track the inforames/audio state per-port so we'd end up with
> some kind of random mismash state when multipled encoders try
> to compute the same stuff. And the hardware will in fact
> automagically disable audio/infoframe transmission if you try
> to enable it for multiple HDMI ports at the same time.
>
> Thus disable all HDMI specific features when cloning.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index d3692c9a1d80..31927f8238d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2057,13 +2057,6 @@ static bool hdmi_bpc_possible(const struct 
> intel_crtc_state *crtc_state, int bpc
>   if (!intel_hdmi_source_bpc_possible(dev_priv, bpc))
>   return false;
>  
> - /*
> -  * HDMI deep color affects the clocks, so it's only possible
> -  * when not cloning with other encoder types.
> -  */
> - if (bpc > 8 && crtc_state->output_types != BIT(INTEL_OUTPUT_HDMI))
> - return false;
> -
>   /* Display Wa_1405510057:icl,ehl */
>   if (intel_hdmi_is_ycbcr420(crtc_state) &&
>   bpc == 10 && DISPLAY_VER(dev_priv) == 11 &&
> @@ -2238,6 +2231,12 @@ static int intel_hdmi_compute_output_format(struct 
> intel_encoder *encoder,
>   return ret;
>  }
>  
> +static bool intel_hdmi_is_cloned(const struct intel_crtc_state *crtc_state)
> +{
> + return crtc_state->uapi.encoder_mask &&
> + !is_power_of_2(crtc_state->uapi.encoder_mask);
> +}
> +
>  int intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> @@ -2253,8 +2252,9 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   return -EINVAL;
>  
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> - pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
> -  conn_state);
> + pipe_config->has_hdmi_sink =
> + intel_has_hdmi_sink(intel_hdmi, conn_state) &&
> + !intel_hdmi_is_cloned(pipe_config);
>  
>   if (pipe_config->has_hdmi_sink)
>   pipe_config->has_infoframe = true;

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Force RGB output for DVI sink

On Mon, 07 Nov 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> YCbCr output requires infoframes and whatnot, so don't allow
> it when dealing with a DVI sink (or a HDMI sink we wishc to
> treat as DVI).

*wish

Reviewed-by: Jani Nikula 


>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index f2a4431a7fbf..d3692c9a1d80 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2190,9 +2190,13 @@ static bool intel_hdmi_has_audio(struct intel_encoder 
> *encoder,
>  }
>  
>  static enum intel_output_format
> -intel_hdmi_output_format(struct intel_connector *connector,
> +intel_hdmi_output_format(const struct intel_crtc_state *crtc_state,
> +  struct intel_connector *connector,
>bool ycbcr_420_output)
>  {
> + if (!crtc_state->has_hdmi_sink)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
>   if (connector->base.ycbcr_420_allowed && ycbcr_420_output)
>   return INTEL_OUTPUT_FORMAT_YCBCR420;
>   else
> @@ -2211,7 +2215,8 @@ static int intel_hdmi_compute_output_format(struct 
> intel_encoder *encoder,
>   bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
>   int ret;
>  
> - crtc_state->output_format = intel_hdmi_output_format(connector, 
> ycbcr_420_only);
> + crtc_state->output_format =
> + intel_hdmi_output_format(crtc_state, connector, ycbcr_420_only);
>  
>   if (ycbcr_420_only && !intel_hdmi_is_ycbcr420(crtc_state)) {
>   drm_dbg_kms(>drm,
> @@ -2226,7 +2231,7 @@ static int intel_hdmi_compute_output_format(struct 
> intel_encoder *encoder,
>   !drm_mode_is_420_also(info, adjusted_mode))
>   return ret;
>  
> - crtc_state->output_format = intel_hdmi_output_format(connector, 
> true);
> + crtc_state->output_format = 
> intel_hdmi_output_format(crtc_state, connector, true);
>   ret = intel_hdmi_compute_clock(encoder, crtc_state, 
> respect_downstream_limits);
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Introduce g4x_hdmi_compute_config()