Re: [Intel-gfx] [PULL] drm-intel-next

[Ville Syrjälä]

On Tue, Nov 01, 2022 at 10:29:24PM +, Vivi, Rodrigo wrote:
> On Sat, 2022-10-29 at 02:41 +0300, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 02:22:33PM -0400, Rodrigo Vivi wrote:
> > > Hi Dave and Daniel,
> > > 
> > > Here goes the first chunk of drm-intel-next targeting 6.2
> > > 
> > > The highlight goes to Ville with many display related clean-up
> > > and improvement, some other MTL enabling work and many other
> > > fixes and small clean-ups.
> > > 
> > > drm-intel-next-2022-10-28:
> > ...
> > > - ELD precompute and readout (Ville)
> > 
> > A slight clarification seems to be in order. The ELD
> > precompute+readout is in fact not in yet. This was just a pile
> > of cleanups and minor fixes. The real ELD stuff will come later,
> > once we figure out how we actually want to do it.
> 
> Sorry for the confusion. I have just used the subject of your series
> as summary: 
> [Intel-gfx] [PATCH 00/22] drm/i915: ELD precompute and readout

Only part of the series went in.

> 
> Should I change that to ELD precompute and readout

Just "audio cleanups" or something like that would be the
approximate truth.

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: Introduce Wa_18017747507 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Introduce Wa_18017747507 (rev2)
URL   : https://patchwork.freedesktop.org/series/110323/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110323v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-skl:  ([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]) ([i915#5032])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl3/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl3/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl10/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl10/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl7/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl6/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl5/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl4/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl4/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl4/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl3/boot.html

  

### IGT changes ###

 Issues hit 

[Intel-gfx] [PATCH] drm/i915: Do not set cache_dirty for DGFX

[Niranjana Vishwanathapura]

Currently on DG1, which do not have LLC, we hit the below
warning while rebinding an userptr invalidated object.

WARNING: CPU: 4 PID: 13008 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 
__i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
Call Trace:
 
 i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
 i915_gem_object_get_pages+0x32/0xb0 [i915]
 i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
 eb_lookup_vmas+0x2ff/0xcf0 [i915]
 ? __intel_wakeref_get_first+0x55/0xb0 [i915]
 i915_gem_do_execbuffer+0x785/0x21d0 [i915]
 i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]

We shouldn't be setting the obj->cache_dirty for DGFX,
fix it.

Suggested-by: Matthew Auld 
Reported-by: Niranjana Vishwanathapura 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11125c32dd35..2f7804492cd5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -369,14 +369,14 @@ __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
 
__start_cpu_write(obj);
/*
-* On non-LLC platforms, force the flush-on-acquire if this is ever
+* On non-LLC igfx platforms, force the flush-on-acquire if this is ever
 * swapped-in. Our async flush path is not trust worthy enough yet(and
 * happens in the wrong order), and with some tricks it's conceivable
 * for userspace to change the cache-level to I915_CACHE_NONE after the
 * pages are swapped-in, and since execbuf binds the object before doing
 * the async flush, we have a race window.
 */
-   if (!HAS_LLC(i915))
+   if (!HAS_LLC(i915) && !IS_DGFX(i915))
obj->cache_dirty = true;
 }
 
-- 
2.21.0.rc0.32.g243a4c7e27

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: allow running mock selftests via Kunit

[Patchwork]

== Series Details ==

Series: drm/i915: allow running mock selftests via Kunit
URL   : https://patchwork.freedesktop.org/series/110383/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12328_full -> Patchwork_110383v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110383v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110383v1_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_110383v1_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_schedule@deep@vcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/shard-skl4/igt@gem_exec_schedule@d...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl4/igt@gem_exec_schedule@d...@vcs0.html

  * igt@i915_pm_rpm@gem-evict-pwrite:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/shard-iclb8/igt@i915_pm_...@gem-evict-pwrite.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-iclb5/igt@i915_pm_...@gem-evict-pwrite.html

  * igt@kms_cursor_crc@cursor-onscreen-256x85@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/shard-glk9/igt@kms_cursor_crc@cursor-onscreen-256...@pipe-b-hdmi-a-1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-glk2/igt@kms_cursor_crc@cursor-onscreen-256...@pipe-b-hdmi-a-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_persistence@hang:
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271]) +87 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl9/igt@gem_ctx_persiste...@hang.html

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

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][11] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-apl6/igt@gem_exec_f...@basic-deadline.html

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

  * igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl9/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html

  * igt@gem_userptr_blits@input-checking:
- shard-apl:  NOTRUN -> [DMESG-WARN][14] ([i915#4991])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-apl6/igt@gem_userptr_bl...@input-checking.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl9/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#454])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl3/igt@i915_pm...@dc6-dpms.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-c-edp-1:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#2521])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-skl10/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-edp-1.html

  * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/shard-apl6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html

  * 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't wait forever in drop_caches

[Patchwork]

== Series Details ==

Series: drm/i915: Don't wait forever in drop_caches
URL   : https://patchwork.freedesktop.org/series/110395/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12329 -> Patchwork_110395v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 26)
--

  Missing(14): bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 bat-adlp-6 
bat-adlp-4 fi-hsw-4770 bat-adln-1 fi-pnv-d510 bat-rplp-1 bat-rpls-1 bat-rpls-2 
bat-dg2-11 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110395v1/fi-bsw-nick/igt@run...@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6972]: https://gitlab.freedesktop.org/drm/intel/issues/6972


Build changes
-

  * Linux: CI_DRM_12329 -> Patchwork_110395v1

  CI-20190529: 20190529
  CI_DRM_12329: aeb0d740b4011006d27dc0ac4d5c2ae7c6da4066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7037: 6a25c53624502fc85cec3cf0a0bf244a2346e30f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110395v1: aeb0d740b4011006d27dc0ac4d5c2ae7c6da4066 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f43794f44a06 drm/i915: Don't wait forever in drop_caches

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Don't wait forever in drop_caches

[Patchwork]

== Series Details ==

Series: drm/i915: Don't wait forever in drop_caches
URL   : https://patchwork.freedesktop.org/series/110395/
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] [PATCH] drm/i915: Don't wait forever in drop_caches

[John . C . Harrison]

From: John Harrison 

At the end of each test, IGT does a drop caches call via sysfs with
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)
+
 static int
 i915_drop_caches_get(void *data, u64 *val)
 {
@@ -661,7 +664,9 @@ gt_drop_caches(struct intel_gt *gt, u64 val)
intel_gt_retire_requests(gt);
 
if (val & (DROP_IDLE | DROP_ACTIVE)) {
-   ret = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
+   ret = intel_gt_wait_for_idle(gt, DROP_IDLE_TIMEOUT);
+   if (ret == -ETIME)
+   intel_gt_set_wedged(gt);
if (ret)
return ret;
}
-- 
2.37.3

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/display: Do both crawl and squash 
when changing cdclk (rev2)
URL   : https://patchwork.freedesktop.org/series/110347/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12329 -> Patchwork_110347v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 29)
--

  Missing(11): bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 bat-adlp-4 
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_110347v2 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_12329/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v2/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12329/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v2/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- {fi-tgl-mst}:   [DMESG-WARN][5] ([i915#6434]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12329/fi-tgl-mst/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110347v2/fi-tgl-mst/igt@debugfs_test@read_all_entries.html

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

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

  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#7073]: https://gitlab.freedesktop.org/drm/intel/issues/7073
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12329 -> Patchwork_110347v2

  CI-20190529: 20190529
  CI_DRM_12329: aeb0d740b4011006d27dc0ac4d5c2ae7c6da4066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7037: 6a25c53624502fc85cec3cf0a0bf244a2346e30f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110347v2: aeb0d740b4011006d27dc0ac4d5c2ae7c6da4066 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

db8ade4d8794 drm/i915/display: Add CDCLK Support for MTL
7d65fabe426b drm/i915/display: Do both crawl and squash when changing cdclk

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Replace kmap() with kmap_local_page() (rev2)

[Fabio M. De Francesco]

On lunedì 17 ottobre 2022 22:23:30 CET Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Replace kmap() with kmap_local_page() (rev2)
> URL   : https://patchwork.freedesktop.org/series/107277/
> State : warning
> 
> == Summary ==
> 
> Error: dim sparse failed
> Sparse version: v0.6.2
> Fast mode used, each commit won't be checked separately.

I received this and other messages with regards to the same series, however, 
after due inspection of my patches, I haven't yet been able to understand what 
these reports may mean or even if they are reporting bugs.

Can anyone please provide any help?

Thanks,

Fabio

P.S.: Similar requests for the other messages will follow ASAP.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43

[Ceraolo Spurio, Daniele]

On 10/24/2022 11:40 AM, Alan Previn wrote:

Previously, we only used PXP FW interface version-42 structures for
PXP arbitration session on ADL/TGL products and version-43 for HuC
authentication on DG2. That worked fine despite not differentiating such
versioning of the PXP firmware interaction structures. This was okay
back then because the only commands used via version 42 was not
used via version 43 and vice versa.

With MTL, we'll need both these versions side by side for the same
commands (PXP-session) with the older platform feature support. That
said, let's create separate files to define the structures and definitions
for both version-42 and 43 of PXP FW interfaces.

Signed-off-by: Alan Previn 
---
  .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 39 +
  .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 45 +++
  .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 27 +
  drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 20 +++
  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 12 ++--
  .../drm/i915/pxp/intel_pxp_tee_interface.h| 57 ---
  6 files changed, 127 insertions(+), 73 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
  delete mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
new file mode 100644
index ..501012d3084d
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_FW_INTERFACE_42_H__
+#define __INTEL_PXP_FW_INTERFACE_42_H__
+
+#include 
+#include "intel_pxp_cmd_interface_cmn.h"
+
+/* PXP API Version 42 Core Definitions */
+#define PXP42_APIVER 0x00040002


Is it worth having a unified macro for this instead of 2 separate 
defines for 42 and 43? e.g


#define PXP_APIVER(x, y) (x << 16 | y)

And then use PXP_APIVER(4, 2) or PXP_APIVER(4, 3). Just a suggestion, 
not a blocker.



+
+/* PXP-Cmd-Op definitions */
+#define PXP42_CMDID_INIT_SESSION 0x1e


This might be better off closer to the matching structure. Not a blocker.


+
+/* PXP-In/Out-Cmd-Header */
+struct pxp42_cmd_header {
+   struct pxpcmn_cmd_header header;
+   u32 status;
+   /* Length of the message (excluding the header) */
+   u32 buffer_len;
+} __packed;


The PXP specs indicate that the header is common between v42 and v43, 
with one field being considered a union, so we can just define it as 
fully shared in the common file. Something like:


struct pxp_cmd_header {
        u32 api_version;
        u32 command_id;
        union {
                u32 status;        /* out */
                u32 stream id;  /* in */
        }
        u32 buffer_len;
}




+
+/* PXP-Input-Packet: Create-Arb-Session */
+#define PXP42_INIT_SESSION_PROTECTION_ARB 0x2


I was a bit confused by the comment above the define, took me a moment 
to understand that the define is not of the command ID matching the 
packed, but one of the possible values of one of the fields. Maybe move 
it inside the structure and below the matching variable like we usually do?



+struct pxp42_create_arb_in {
+   struct pxp42_cmd_header header;
+   u32 protection_mode;
+   u32 session_id;
+} __packed;
+
+/* PXP-Output-Packet: Create-Arb-Session */
+struct pxp42_create_arb_out {
+   struct pxp42_cmd_header header;
+} __packed;
+
+#endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
new file mode 100644
index ..d7d93876bbef
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2022, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_FW_INTERFACE_43_H__
+#define __INTEL_PXP_FW_INTERFACE_43_H__
+
+#include 
+#include "intel_pxp_cmd_interface_cmn.h"
+
+/* PXP API Version 43 Core Definitions */
+#define PXP43_APIVER 0x00040003
+#define PXP43_MAX_HECI_IN_SIZE (32 * 1024)
+#define PXP43_MAX_HECI_OUT_SIZE (32 * 1024)


Those MAX_HECI defines are unused

Daniele


+
+/* PXP-Cmd-Op definitions */
+#define PXP43_CMDID_START_HUC_AUTH 0x003A
+
+/* PXP-In/Out-Cmd-Header */
+struct pxp43_cmd_header {
+   struct pxpcmn_cmd_header header;
+   u32 in_out_data;
+   /* Length of the message (excluding the header) */
+   u32 buffer_len;
+} __packed;


This is unused (but anyway superseded by previous comment about the 
unified header)



+
+/* PXP-Input-Packet: HUC-Authentication */
+struct pxp43_start_huc_auth_in {
+   struct pxpcmn_cmd_header 

Re: [Intel-gfx] [PATCH v5] overflow: Introduce overflows_type() and castable_to_type()

[Kees Cook]

On Sat, Oct 29, 2022 at 11:01:38AM +0300, Gwan-gyeong Mun wrote:
> 
> 
> On 10/29/22 10:32 AM, Kees Cook wrote:
> > On Sat, Oct 29, 2022 at 08:55:43AM +0300, Gwan-gyeong Mun wrote:
> > > Hi Kees,
> > 
> > Hi! :)
> > 
> > > I've updated to v5 with the last comment of Nathan.
> > > Could you please kindly review what more is needed as we move forward with
> > > this patch?
> > 
> > It looks fine to me -- I assume it'll go via the drm tree? Would you
> > rather I carry the non-drm changes in my tree instead?
> > 
> Hi!
> Yes, I think it would be better to run this patch on your tree.
> this patch moves the macro of i915 to overflows.h and modifies one part of
> drm's driver code, but I think this part can be easily applied when merging
> into the drm tree.

I've rebased it to the hardening tree, and it should appear in -next
shortly:

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/hardening=5904fcb776d0b518be96bca43f258db90f26ba9a

-- 
Kees Cook

Re: [Intel-gfx] [PULL] drm-intel-next

[Vivi, Rodrigo]

On Sat, 2022-10-29 at 02:41 +0300, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 02:22:33PM -0400, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Here goes the first chunk of drm-intel-next targeting 6.2
> > 
> > The highlight goes to Ville with many display related clean-up
> > and improvement, some other MTL enabling work and many other
> > fixes and small clean-ups.
> > 
> > drm-intel-next-2022-10-28:
> ...
> > - ELD precompute and readout (Ville)
> 
> A slight clarification seems to be in order. The ELD
> precompute+readout is in fact not in yet. This was just a pile
> of cleanups and minor fixes. The real ELD stuff will come later,
> once we figure out how we actually want to do it.

Sorry for the confusion. I have just used the subject of your series
as summary: 
[Intel-gfx] [PATCH 00/22] drm/i915: ELD precompute and readout

Should I change that to ELD precompute and readout

> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set PROBE_PREFER_ASYNCHRONOUS

[Brian Norris]

On Fri, Oct 28, 2022 at 5:24 PM Patchwork
 wrote:
>
> Patch Details
> Series:drm/i915: Set PROBE_PREFER_ASYNCHRONOUS
> URL:https://patchwork.freedesktop.org/series/110277/
> State:failure
> Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110277v1/index.html
>
> CI Bug Log - changes from CI_DRM_12317 -> Patchwork_110277v1
>
> Summary
>
> FAILURE
>
> Serious unknown changes coming with Patchwork_110277v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_110277v1, 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_110277v1/index.html

For the record, I have almost zero idea what to do with this. From
what I can tell, most (all?) of these failures are flaky(?) already
and are probably not related to my change.

But if someone believes to actually be a blocking issue with my patch,
let me know, and I can see if I can figure out a better answer than
that.

Thanks,
Brian

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: allow running mock selftests via Kunit

[Patchwork]

== Series Details ==

Series: drm/i915: allow running mock selftests via Kunit
URL   : https://patchwork.freedesktop.org/series/110383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12328 -> Patchwork_110383v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 29)
--

  Additional (1): fi-tgl-dsi 
  Missing(11): bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 bat-adlp-6 
bat-adlp-4 bat-adln-1 bat-rplp-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_110383v1:

### IGT changes ###

 Suppressed 

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

  * igt@runner@aborted:
- {fi-tgl-dsi}:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/fi-tgl-dsi/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@gem_tiled_blits@basic:
- fi-pnv-d510:[SKIP][3] ([fdo#109271]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [INCOMPLETE][5] ([i915#3303] / [i915#4785]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@mman:
- fi-rkl-guc: [INCOMPLETE][7] ([i915#6794]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12328/fi-rkl-guc/igt@i915_selftest@l...@mman.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110383v1/fi-rkl-guc/igt@i915_selftest@l...@mman.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]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#6949]: https://gitlab.freedesktop.org/drm/intel/issues/6949
  [i915#7058]: https://gitlab.freedesktop.org/drm/intel/issues/7058


Build changes
-

  * Linux: CI_DRM_12328 -> Patchwork_110383v1

  CI-20190529: 20190529
  CI_DRM_12328: 8fe2bb19cad133f82e04b45f3e2ada6bb1179e48 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7037: 6a25c53624502fc85cec3cf0a0bf244a2346e30f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110383v1: 8fe2bb19cad133f82e04b45f3e2ada6bb1179e48 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

fbfc0f0a12e1 drm/i915: allow running mock selftests via Kunit

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Replace kmap() with kmap_local_page() (rev2)

[Fabio M. De Francesco]

On lunedì 17 ottobre 2022 22:23:30 CET Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Replace kmap() with kmap_local_page() (rev2)
> URL   : https://patchwork.freedesktop.org/series/107277/
> State : warning
> 
> == Summary ==
> 
> Error: dim sparse failed
> Sparse version: v0.6.2
> Fast mode used, each commit won't be checked separately.

I received this and other messages with regards to the same series, however, 
after due inspection of my patches, I haven't yet been able to understand what 
these reports may mean or even if they are reporting bugs.

Can anyone please provide any help?

Thanks,

Fabio

P.S.: Similar requests for the other messages will follow ASAP.

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace kmap() with kmap_local_page() (rev2)

[Fabio M. De Francesco]

On lunedì 17 ottobre 2022 22:34:44 CET Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Replace kmap() with kmap_local_page() (rev2)
> URL   : https://patchwork.freedesktop.org/series/107277/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12252 -> Patchwork_107277v2
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/
index.html
> 
> Participating hosts (46 -> 43)
> --
> 
>   Additional (1): fi-icl-u2
>   Missing(4): fi-bxt-dsi fi-cfl-8700k bat-atsm-1 fi-bdw-samus
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_107277v2 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_12252/fi-pnv-d510/
igt@gem_exec_gttfill@
> basic.html [2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-pnv-d510/
igt@gem_exec_gt
> tf...@basic.html
> 
>   * igt@gem_linear_blits@basic:
> - fi-pnv-d510:[PASS][3] -> [SKIP][4] ([fdo#109271])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12252/fi-pnv-d510/
igt@gem_linear_blits@
> basic.html [4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-pnv-d510/
igt@gem_linear_
> bl...@basic.html
> 
>   * igt@runner@aborted:
> - fi-icl-u2:  NOTRUN -> [FAIL][5] ([i915#7220])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/fi-icl-u2/
igt@runner@aborte
> d.html
> 
> 
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>   [i915#7220]: https://gitlab.freedesktop.org/drm/intel/issues/7220
>   [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
> 
> 
> Build changes
> -
> 
>   * Linux: CI_DRM_12252 -> Patchwork_107277v2
> 
>   CI-20190529: 20190529
>   CI_DRM_12252: 14867082ef288af10c90732e31b633af30e304c0 @
> git://anongit.freedesktop.org/gfx-ci/linux IGT_7017:
> 193c8bdd7df32556129482c52011e1b7a233b699 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107277v2:
> 14867082ef288af10c90732e31b633af30e304c0 @ git://anongit.freedesktop.org/
gfx-ci/linux
> 
> 
> ### Linux commits
> 
> 83c34dd3b2a2 drm/i915/gem: Replace kmap() with kmap_local_page()
> ade39e0c9963 drm/i915/gt: Replace kmap() with kmap_local_page()
> cd89efceb13c drm/i915: Replace kmap() with kmap_local_page()
> 
> == Logs ==
> 
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v2/index.html

This is the second of the three messages with regards to the same series.
My kind request is the same of the previous...

Can anyone please provide any help?

Thanks,

Fabio

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Introduce Wa_18017747507

[Matt Roper]

On Mon, Oct 31, 2022 at 06:15:09AM -0700, Wayne Boyer wrote:
> WA 18017747507 applies to all DG2 skus.
> 
> BSpec: 56035, 46121, 68173
> 
> Signed-off-by: Wayne Boyer 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index f4624262dc81..27b2641e1a53 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -501,6 +501,9 @@
>  #define VF_PREEMPTION_MMIO(0x83a4)
>  #define   PREEMPTION_VERTEX_COUNTREG_GENMASK(15, 0)
>  
> +#define VFG_PREEMPTION_CHICKEN   _MMIO(0x83b4)
> +#define  POLYGON_TRIFAN_LINELOOP_DISABLE REG_BIT(4)

We need one more space here between 'define' and the register name for
consistency with the rest of the file.  But I can fix that up while
applying.

Reviewed-by: Matt Roper 

Applied to drm-intel-gt-next.  Thanks for the patch.


Matt

> +
>  #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>  
>  #define XEHP_SQCMMCR_REG(0x8724)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 2a35e7e66625..3cdf5c24dbc5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2975,6 +2975,9 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>* Wa_22015475538:dg2
>*/
>   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
> +
> + /* Wa_18017747507:dg2 */
> + wa_masked_en(wal, VFG_PREEMPTION_CHICKEN, 
> POLYGON_TRIFAN_LINELOOP_DISABLE);
>   }
>  }
>  
> -- 
> 2.37.3
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: allow running mock selftests via Kunit

[Patchwork]

== Series Details ==

Series: drm/i915: allow running mock selftests via Kunit
URL   : https://patchwork.freedesktop.org/series/110383/
State : warning

== Summary ==

Error: dim checkpatch failed
a4f3a5c88a10 drm/i915: allow running mock selftests via Kunit
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#24: 
$ qemu-system-x86_64 -nodefaults -m 1024 -kernel 
.kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 
kunit_shutdown=reboot' -no-reboot -nographic -serial stdio

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

-:432: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
#432: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:13:
+#define selftest(x, __y) int __y(void);

-:438: ERROR:OPEN_BRACE: open brace '{' following function definitions go on 
the next line
#438: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:19:
+   static void mock_##__x(struct kunit *test) {\

-:467: WARNING:MODULE_LICENSE: Prefer "GPL" over "GPL v2" - see commit 
bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
#467: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:48:
+MODULE_LICENSE("GPL v2");

total: 1 errors, 4 warnings, 0 checks, 243 lines checked

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11

[Matt Roper]

On Tue, Nov 01, 2022 at 01:29:27PM +0530, Swati Sharma wrote:
> i915 driver supports DSC from DISPLAY_VER >= 11. Fix it.

Bspec 19713 indicates that GLK (i.e., our only display version 10
platform) does support DSC.  Are you saying that there's other GLK
enablement missing in the driver right now that prevents DSC from
working?


Matt

> 
> Signed-off-by: Swati Sharma 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..02e64f0284d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1012,7 +1012,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>* Output bpp is stored in 6.4 format so right shift by 4 to get the
>* integer value since we support only integer values of bpp.
>*/
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (DISPLAY_VER(dev_priv) >= 11 &&
>   drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
>   /*
>* TBD pass the connector BPC,
> @@ -2906,7 +2906,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   intel_dp_set_max_sink_lane_count(intel_dp);
>  
>   /* Read the eDP DSC DPCD registers */
> - if (DISPLAY_VER(dev_priv) >= 10)
> + if (DISPLAY_VER(dev_priv) >= 11)
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
>   /*
> -- 
> 2.25.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Souza, Jose]

On Tue, 2022-11-01 at 20:55 +, Hogander, Jouni wrote:
> On Tue, 2022-11-01 at 20:00 +, Souza, Jose wrote:
> > On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> > > Selective update area is now aligned with DSC slice height when
> > > DSC is enabled. Remove inappropriate warning about missing DSC
> > > alignment.
> > > 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > 
> > > Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> > > Signed-off-by: Jouni Högander 
> > > Signed-off-by: Anshuman Gupta 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 904a1049eff3..64e9e134fdca 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1678,9 +1678,6 @@ static void
> > > intel_psr2_sel_fetch_pipe_alignment(const struct intel_crtc_state
> > > *c
> > > pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
> > > if (pipe_clip->y2 % y_alignment)
> > > pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1)
> > > * y_alignment;
> > > -
> > > -   if (IS_ALDERLAKE_P(dev_priv) && crtc_state-
> > > > dsc.compression_enable)
> > > -   drm_warn(_priv->drm, "Missing PSR2 sel fetch
> > > alignment with DSC\n");
> > 
> > It is necessary check if DSC alignment and PSR2 alignment matches, if
> > not PSR2 can't be enabled.
> 
> This check is there at the begin of
> intel_psr2_sel_fetch_pipe_alignment:
> 
> /* ADLP aligns the SU region to vdsc slice height in case dsc is
> enabled */
> if (crtc_state->dsc.compression_enable &&
>   (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14))
>   y_alignment = vdsc_cfg->slice_height;

This is still wrong.
There is no guarantee that required PSR2 alignment matches 
vdsc_cfg->slice_height.

> 
> For some reason when this got merged warning was still left there. Now
> just removing the warning as well.
> 
> > 
> > >  }
> > >  
> > >  /*
> > 
> 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Hogander, Jouni]

On Tue, 2022-11-01 at 20:00 +, Souza, Jose wrote:
> On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> > Selective update area is now aligned with DSC slice height when
> > DSC is enabled. Remove inappropriate warning about missing DSC
> > alignment.
> > 
> > Cc: José Roberto de Souza 
> > Cc: Mika Kahola 
> > 
> > Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> > Signed-off-by: Jouni Högander 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 904a1049eff3..64e9e134fdca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1678,9 +1678,6 @@ static void
> > intel_psr2_sel_fetch_pipe_alignment(const struct intel_crtc_state
> > *c
> > pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
> > if (pipe_clip->y2 % y_alignment)
> > pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1)
> > * y_alignment;
> > -
> > -   if (IS_ALDERLAKE_P(dev_priv) && crtc_state-
> > >dsc.compression_enable)
> > -   drm_warn(_priv->drm, "Missing PSR2 sel fetch
> > alignment with DSC\n");
> 
> It is necessary check if DSC alignment and PSR2 alignment matches, if
> not PSR2 can't be enabled.

This check is there at the begin of
intel_psr2_sel_fetch_pipe_alignment:

/* ADLP aligns the SU region to vdsc slice height in case dsc is
enabled */
if (crtc_state->dsc.compression_enable &&
(IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14))
y_alignment = vdsc_cfg->slice_height;

For some reason when this got merged warning was still left there. Now
just removing the warning as well.

> 
> >  }
> >  
> >  /*
> 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Remove inappropriate DSC slice alignment warning

[Souza, Jose]

On Fri, 2022-10-21 at 08:49 +0300, Jouni Högander wrote:
> Selective update area is now aligned with DSC slice height when
> DSC is enabled. Remove inappropriate warning about missing DSC
> alignment.
> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> 
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7212
> Signed-off-by: Jouni Högander 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 904a1049eff3..64e9e134fdca 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1678,9 +1678,6 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
> struct intel_crtc_state *c
>   pipe_clip->y1 -= pipe_clip->y1 % y_alignment;
>   if (pipe_clip->y2 % y_alignment)
>   pipe_clip->y2 = ((pipe_clip->y2 / y_alignment) + 1) * 
> y_alignment;
> -
> - if (IS_ALDERLAKE_P(dev_priv) && crtc_state->dsc.compression_enable)
> - drm_warn(_priv->drm, "Missing PSR2 sel fetch alignment with 
> DSC\n");

It is necessary check if DSC alignment and PSR2 alignment matches, if not PSR2 
can't be enabled.

>  }
>  
>  /*

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Introduce Wa_18017747507

[Wayne Boyer]

On 10/31/22 3:44 PM, Patchwork wrote:
> *Patch Details*
> *Series:* drm/i915/dg2: Introduce Wa_18017747507
> *URL:*https://patchwork.freedesktop.org/series/110323/
> 
> *State:*  failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v1/index.html
> 
> 
> 
>   CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110323v1_full
> 
> 
> Summary
> 
> *FAILURE*
> 
> Serious unknown changes coming with Patchwork_110323v1_full absolutely
> need to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_110323v1_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_110323v1_full:
> 
> 
>   IGT changes
> 
> 
> Possible regressions
> 
>   * 
> igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
>   o shard-iclb: PASS
> 
> 
>  -> FAIL 
> 
>  +1 similar issue
> 

This failure is with a display test on an ICL shard.

The WA is specific to a GT issue on DG2 systems.

I don't see how the patch can be causing the failure.


> 
> Suppressed
> 
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
> 
>   *
> 
> igt@gem_exec_gttfill@all:
> 
>   o {shard-rkl}: NOTRUN -> INCOMPLETE
> 
> 
>  +1 similar issue
>   *
> 
> igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-3:
> 
>   o {shard-dg1}: NOTRUN -> INCOMPLETE
> 
> 
>   *
> 
> igt@perf_pmu@render-node-busy@vecs0:
> 
>   o {shard-dg1}: PASS
> 
> 
>  -> FAIL 
> 
>  +1 similar issue
> 
> 
> Known issues
> 
> Here are the changes found in Patchwork_110323v1_full that come from
> known issues:
> 
> 
>   CI changes
> 
> 
> Issues hit
> 
>   * boot:
>   o shard-snb: (PASS
> 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> , 
> PASS 
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Hogander, Jouni]

I checked possible new issues found by CI and I'm sure they are not related to 
my patch.

BR,

Jouni Högander

On Tue, 2022-11-01 at 18:34 +, Patchwork wrote:
Patch Details
Series: drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL
URL:https://patchwork.freedesktop.org/series/110375/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/index.html
CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110375v1_full
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110375v1_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 -> 9)

Missing (2): shard-rkl shard-dg1

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_whisper@basic-queues-forked:

 *   shard-iclb: 
PASS
 -> 
INCOMPLETE
  *   
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:

 *   shard-iclb: 
PASS
 -> 
FAIL

Known issues

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

CI changes
Issues hit

  *   boot:
 *   shard-glk: 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS)
 -> 
(PASS,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 
FAIL,
 
PASS,
 
PASS,
 
PASS,
 
PASS,
 

Re: [Intel-gfx] [PULL] drm-intel-gt-next

[Dave Airlie]

On Mon, 31 Oct 2022 at 21:07, Joonas Lahtinen
 wrote:
>
> Hi Dave & Daniel,
>
> Here goes first drm-intel-gt-next pull req towards 6.2.
>
> We have a fix for #6222 (kernel memory corruption issue) and fix for
> display regression after resume. A missing W/A for Gen12 iGPUs and
> extension of compute pre-emption timeout to 7.5 seconds to account for
> compute corner cases. Improvements to GuC compute error capture,
> scheduling hysteresis and SLPC. Fixes to EHL MOCS tables. Better docs
> for I915_PARAM_HUC_STATUS and pre-emption control policy. Extending the
> grace period for full GPU reset timeout to 60 seconds to better capture
> logs or recover, as opposed to just giving up on whole device in 5 seconds.
>
> We're starting to add HWMON metrics for recent devices. More MTL
> enabling, DG2 workarounds, DG2 HuC support, OA for DG2 is enabled. Small
> bar enabling, PS64 support added for DG2 page tables. ptrace support for
> local memory objects, local-memory migration for display surfaces.
>
> Note that there is drm/drm-next backmerge and then MEI subsystem patches
> around GSC/PXP which are intertwined with i915 change so merged here as
> agreed with Tomas and Greg.
>
> Additionally the usual amount of refactoring, cleanups, debugging
> improvements and static checker fixes.

Fails to build with clang here.
  CC [M]  drivers/gpu/drm/i915/i915_hwmon.o
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/i915_hwmon.c:115:16:
error: result of comparison of constant 18446744073709551615 with
expression of type 'typeof (_Generic((field_msk), char: (unsigned
char)0, unsigned char: (unsigned char)0, signed char: (unsigned
char)0, unsigned short: (unsigned short)0, short: (unsigned short)0,
unsigned int: (unsigned int)0, int: (unsigned int)0, unsigned long:
(unsigned long)0, long: (unsigned long)0, unsigned long long:
(unsigned long long)0, long long: (unsigned long long)0, default:
(field_msk)))' (aka 'unsigned int') is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
bits_to_set = FIELD_PREP(field_msk, nval);
  ^~~
/home/airlied/devel/kernel/dim/src/include/linux/bitfield.h:114:3:
note: expanded from macro 'FIELD_PREP'
__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");\
^~~
/home/airlied/devel/kernel/dim/src/include/linux/bitfield.h:71:53:
note: expanded from macro '__BF_FIELD_CHECK'
BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
~~^~~
/home/airlied/devel/kernel/dim/src/include/linux/build_bug.h:39:58:
note: expanded from macro 'BUILD_BUG_ON_MSG'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
~^~~
/home/airlied/devel/kernel/dim/src/include/linux/compiler_types.h:357:22:
note: expanded from macro 'compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
/home/airlied/devel/kernel/dim/src/include/linux/compiler_types.h:345:23:
note: expanded from macro '_compiletime_assert'
__compiletime_assert(condition, msg, prefix, suffix)
~^~~
/home/airlied/devel/kernel/dim/src/include/linux/compiler_types.h:337:9:
note: expanded from macro '__compiletime_assert'
if (!(condition))   \
  ^
1 error generated.

clang -v
clang version 14.0.5 (Fedora 14.0.5-1.fc36)

Dave.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL
URL   : https://patchwork.freedesktop.org/series/110375/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110375v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110375v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110375v1_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-queues-forked:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/shard-iclb7/igt@gem_exec_whis...@basic-queues-forked.html

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [FAIL][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]) ([i915#4392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk1/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk1/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk9/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk7/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk6/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk5/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/shard-glk9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/shard-glk9/boot.html
   [32]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Send update also on invalidate (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Send update also on invalidate (rev2)
URL   : https://patchwork.freedesktop.org/series/110037/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12311_full -> Patchwork_110037v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 10)
--

  Additional (2): shard-rkl shard-dg1 
  Missing(1): pig-glk-j5005 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_create@create-clear@smem0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-rkl-5/igt@gem_create@create-cl...@smem0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-iclb3/igt@gem_exec_balan...@parallel-keep-submit-fence.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-tglb: NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_exec_fair@basic-none-r...@rcs0.html

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

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-apl7/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-apl1/igt@gem_exec_suspend@basic...@smem.html
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#7299])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-skl1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-skl9/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-skl9/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html

  * igt@gem_lmem_swapping@verify:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-apl1/igt@gem_lmem_swapp...@verify.html

  * igt@gem_media_vme:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#284])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_media_vme.html

  * igt@gem_mmap_gtt@fault-concurrent-y:
- shard-snb:  [PASS][15] -> [INCOMPLETE][16] ([i915#5161])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-snb6/igt@gem_mmap_...@fault-concurrent-y.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-snb7/igt@gem_mmap_...@fault-concurrent-y.html

  * igt@gem_userptr_blits@input-checking:
- shard-tglb: NOTRUN -> [DMESG-WARN][17] ([i915#4991])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@unsync-unmap:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#3297])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_userptr_bl...@unsync-unmap.html

  * igt@gen3_render_tiledx_blits:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gen3_render_tiledx_blits.html

  * igt@gen9_exec_parse@bb-secure:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#2527] / [i915#2856])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gen9_exec_pa...@bb-secure.html

  * 

Re: [Intel-gfx] [PATCH 02/10] vfio: Move vfio_device_assign_container() into vfio_device_first_open()

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 10:37:14PM +0800, Yi Liu wrote:
> > @@ -784,12 +791,6 @@ static struct file *vfio_device_open(struct 
> > vfio_device *device)
> > struct file *filep;
> > int ret;
> > -   mutex_lock(>group->group_lock);
> > -   ret = vfio_device_assign_container(device);
> > -   mutex_unlock(>group->group_lock);
> > -   if (ret)
> > -   return ERR_PTR(ret);
> > -
> > mutex_lock(>dev_set->lock);
> > device->open_count++;
> > if (device->open_count == 1) {
> > @@ -833,7 +834,6 @@ static struct file *vfio_device_open(struct vfio_device 
> > *device)
> >   err_unassign_container:
> 
> should the err_unassign_container be renamed to be err_dec_count?

Yes, I went with err_unlock

Thanks,
Jason

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enable SDP split for DP2.0 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable SDP split for DP2.0 (rev2)
URL   : https://patchwork.freedesktop.org/series/109395/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_109395v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_109395v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_109395v2_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@basic:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/igt@gem_exec_parallel@engi...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-skl3/igt@gem_exec_parallel@engi...@basic.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/igt@gen9_exec_pa...@allowed-single.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-skl1/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_atomic_transition@modeset-transition-nonblocking@1x-outputs:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb5/igt@kms_atomic_transition@modeset-transition-nonblock...@1x-outputs.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-tglb8/igt@kms_atomic_transition@modeset-transition-nonblock...@1x-outputs.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-skl:  ([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], [FAIL][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51]) ([i915#5032])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-skl3/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-skl9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/shard-skl9/boot.html
   [32]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Send update also on invalidate (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Send update also on invalidate (rev2)
URL   : https://patchwork.freedesktop.org/series/110037/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12311_full -> Patchwork_110037v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 10)
--

  Additional (2): shard-rkl shard-dg1 
  Missing(1): pig-glk-j5005 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_create@create-clear@smem0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-rkl-5/igt@gem_create@create-cl...@smem0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-iclb3/igt@gem_exec_balan...@parallel-keep-submit-fence.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-tglb: NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_exec_fair@basic-none-r...@rcs0.html

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

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-apl7/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-apl1/igt@gem_exec_suspend@basic...@smem.html
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#7299])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-skl1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-skl9/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-skl9/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html

  * igt@gem_lmem_swapping@verify:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-apl1/igt@gem_lmem_swapp...@verify.html

  * igt@gem_media_vme:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#284])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_media_vme.html

  * igt@gem_mmap_gtt@fault-concurrent-y:
- shard-snb:  [PASS][15] -> [INCOMPLETE][16] ([i915#5161])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/shard-snb6/igt@gem_mmap_...@fault-concurrent-y.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-snb7/igt@gem_mmap_...@fault-concurrent-y.html

  * igt@gem_userptr_blits@input-checking:
- shard-tglb: NOTRUN -> [DMESG-WARN][17] ([i915#4991])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@unsync-unmap:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#3297])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gem_userptr_bl...@unsync-unmap.html

  * igt@gen3_render_tiledx_blits:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gen3_render_tiledx_blits.html

  * igt@gen9_exec_parse@bb-secure:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#2527] / [i915#2856])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/shard-tglb8/igt@gen9_exec_pa...@bb-secure.html

  * 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[John Harrison]

On 11/1/2022 02:58, Tvrtko Ursulin wrote:

On 31/10/2022 18:30, John Harrison wrote:

On 10/31/2022 05:51, Tvrtko Ursulin wrote:

On 31/10/2022 10:09, Tvrtko Ursulin wrote:

On 28/10/2022 20:46, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

Update the worker to abort if a reset is in progress rather than
waiting for it to complete. It will still acquire the reset lock in
the case where a reset was not already in progress. So the processing
is still safe from corruption, but the deadlock can no longer occur.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 15 
++-

  drivers/gpu/drm/i915/gt/intel_reset.h |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 --
  3 files changed, 19 insertions(+), 3 deletions(-)

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

index 3159df6cdd492..2f48c6e4420ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,7 +1407,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
-int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_trylock(struct intel_gt *gt, int 
*srcu, bool retry)

  {
  might_lock(>reset.backoff_srcu);
  might_sleep();
@@ -1416,6 +1416,9 @@ int intel_gt_reset_trylock(struct intel_gt 
*gt, int *srcu)

  while (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
  rcu_read_unlock();
+    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
>reset.flags)))


Would it be more obvious to rename the existing semantics to 
intel_gt_reset_interruptible(), while the flavour you add in this 
patch truly is trylock? I am not sure, since it's all a bit 
special, but trylock sure feels confusing if it can sleep forever...
To me, it would seem totally more obvious to have a function called 
'trylock' not wait forever until it can manage to acquire the lock. 
However, according to '2caffbf1176256 drm/i915: Revoke mmaps and 
prevent access to fence registers across reset', the current 
behaviour is exactly how the code was originally written and 
intended. It hasn't just mutated into some confused evolution a 
thousand patches later. So I figure there is some subtle but 
important reason why it was named how it is named and yet does what 
it does. Therefore it seemed safest to not change it unnecessarily.


Yeah I looked at that but honestly I don't see the trylock semantics 
anywhere. The only failure to lock path comes from 
wait_event_interruptible. It could have easily been just a naming mishap.


And I find adding a retry parameter to something called trylock makes 
this even more non-intuitive and would personally rather rename it 
all. Proof in the pudding is that the trylock naming did bite during 
development and review of the code this patch is now fixing.


I do however understand your point about a degree of uncertainty but 
my feeling is to rather err on the side of obvious naming. Shall we 
ask for a third opinion?
Umesh had commented (internally) that the naming seems wrong and would 
be good to change it. So we already have a third :).


To be clear, you are thinking to keep the wrappers but rename to 
intel_gt_reset_trylock() [retry = false] and 
intel_gt_reset_interruptible() [retry = true]? Which will obviously 
involve updating all but one existing user to use the interruptible name 
as the existing name will change behaviour in a backwards breaking manner.


John.



Oh and might_sleep() shouldn't be there with the trylock version - I 
mean any flavour of the real trylock.
You mean if the code is split into two completely separate functions? 
Or do you just mean to wrap the might_sleep() call with 'if(!retry)'?


And just to be totally clear, the unconditional call to 
rcu_read_lock() is not something that can sleep? One doesn't need a 
might_sleep() before doing that lock?


Corrrect, rcu_read_lock() can not sleep - it just disables preemption. 
So leaving the unconditional might_sleep() would have opportunity for 
false positives.


Regards,

Tvrtko

[Intel-gfx] [PATCH RFC] drm/i915: allow running mock selftests via Kunit

[Mauro Carvalho Chehab]

The mock selftests don't require any hardware to run. They can
easily run via kunit with qemu or bare metal.

Add support for it.

With this change, mock selftest can now run in qemu with:

$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/i915/selftests
[16:50:24] Configuring KUnit Kernel ...
[16:50:24] Building KUnit Kernel ...
Populating config with:
$ make ARCH=x86_64 O=.kunit olddefconfig
Building with:
$ make ARCH=x86_64 O=.kunit --jobs=8
[16:50:32] Starting KUnit Kernel (1/1)...
[16:50:32] 
Running tests with:
$ qemu-system-x86_64 -nodefaults -m 1024 -kernel 
.kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 
kunit_shutdown=reboot' -no-reboot -nographic -serial stdio
[16:50:33]  i915 mock selftests (18 subtests) =
[16:50:33] [PASSED] mock_sanitycheck
[16:50:33] [PASSED] mock_shmem
[16:50:37] [PASSED] mock_fence
[16:50:38] [PASSED] mock_scatterlist
[16:50:39] [PASSED] mock_syncmap
[16:50:39] [PASSED] mock_uncore
[16:50:39] [PASSED] mock_ring
[16:50:39] [PASSED] mock_engine
[16:50:43] [PASSED] mock_timelines
[16:50:45] [PASSED] mock_requests
[16:50:45] [PASSED] mock_objects
[16:50:45] [PASSED] mock_phys
[16:50:45] [PASSED] mock_dmabuf
[16:50:50] [PASSED] mock_vma
[16:50:51] [PASSED] mock_evict
[16:50:53] [PASSED] mock_gtt
[16:50:54] [PASSED] mock_hugepages
[16:50:55] [PASSED] mock_memory_region
[16:50:55] === [PASSED] i915 mock selftests ===
[16:50:55] 
[16:50:55] Testing complete. Ran 18 tests: passed: 18
[16:50:55] Elapsed time: 31.530s total, 0.003s configuring, 8.512s 
building, 22.974s running

It is also possible to run the tests on a bare metal machine,
and even collect code coverage data with:

$ sudo lcov -z && sudo modprobe test-i915 && sudo rmmod test-i915 &&
  sudo IGT_KERNEL_TREE=~/linux 
~/freedesktop-igt/scripts/code_cov_capture mock_selftest
Auto-detecting gcov kernel support.
Found upstream gcov kernel support at /sys/kernel/debug/gcov
Resetting kernel execution counters
Done.
[627.14] Code coverage wrote to mock_selftest.info

The KTAP and Kernel logs will be similar to:

[  596.382685] # Subtest: i915 mock selftests
[  596.382688] 1..18
[  596.387744] i915: i915_mock_sanitycheck() - ok!
[  596.395423] ok 1 - mock_sanitycheck
[  596.395495] i915: Running shmem_utils_mock_selftests/igt_shmem_basic
[  596.406650] ok 2 - mock_shmem
[  596.406737] i915: Running i915_sw_fence_mock_selftests/test_self
[  596.416868] i915: Running i915_sw_fence_mock_selftests/test_dag
[  596.423220] i915: Running i915_sw_fence_mock_selftests/test_AB
[  596.429585] i915: Running i915_sw_fence_mock_selftests/test_ABC
[  596.435921] i915: Running i915_sw_fence_mock_selftests/test_AB_C
[  596.442293] i915: Running i915_sw_fence_mock_selftests/test_C_AB
[  596.448671] i915: Running i915_sw_fence_mock_selftests/test_chain
[  596.485336] i915: Running i915_sw_fence_mock_selftests/test_ipc
[  596.492984] i915: Running i915_sw_fence_mock_selftests/test_timer
[  602.484395] i915: Running i915_sw_fence_mock_selftests/test_dma_fence
[  603.876315] Asynchronous wait on fence mock:mock:0 timed out 
(hint:fence_notify [i915])
[  603.886148] ok 3 - mock_fence
[  603.886377] i915: Running scatterlist_mock_selftests/igt_sg_alloc
[  604.398052] sg_alloc_table timed out
[  604.401979] i915: Running scatterlist_mock_selftests/igt_sg_trim
[  604.909003] i915_sg_trim timed out
[  604.912850] ok 4 - mock_scatterlist
[  604.912987] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_init
[  604.924092] i915: Running i915_syncmap_mock_selftests/igt_syncmap_one
[  605.430961] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_join_above
[  605.438458] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_join_below
[  605.446670] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_neighbours
[  606.736462] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_compact
[  606.744342] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_random
[  607.266569] ok 5 - mock_syncmap
[  607.266771] ok 6 - mock_uncore
[  607.271144] i915: Running 
intel_ring_mock_selftests/igt_ring_direction
[  607.281872] ok 7 - mock_ring
[  607.282142] i915: Running 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/sysfs: Update timeslice/preemption for new range limits

[Dixit, Ashutosh]

On Tue, 01 Nov 2022 09:22:11 -0700, John Harrison wrote:
>
> On 11/1/2022 08:27, Dixit, Ashutosh wrote:
> > On Mon, 31 Oct 2022 15:24:40 -0700, john.c.harri...@intel.com wrote:
> >> From: John Harrison 
> >>
> >> Guc submission imposes new range limits on certain scheduling
> >> parameters. The idempotent sections of the timeslice duration and
> >> pre-emption timeout tests was exceeding those limits and so would fail.
> >>
> >> Reduce the excessively large value (654s) to one which does not
> >> overflow (54s). Also add an assert that the write of the new value
> >> actually succeeds.
> >>
> >> Signed-off-by: John Harrison 
> >> ---
> >>   tests/i915/sysfs_preempt_timeout.c| 4 ++--
> >>   tests/i915/sysfs_timeslice_duration.c | 4 ++--
> >>   2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tests/i915/sysfs_preempt_timeout.c 
> >> b/tests/i915/sysfs_preempt_timeout.c
> >> index 515038281638..5e0a7d96299f 100644
> >> --- a/tests/i915/sysfs_preempt_timeout.c
> >> +++ b/tests/i915/sysfs_preempt_timeout.c
> >> @@ -68,7 +68,7 @@ static void set_preempt_timeout(int engine, unsigned int 
> >> value)
> >>   {
> >>unsigned int delay;
> >>
> >> -  igt_sysfs_printf(engine, ATTR, "%u", value);
> >> +  igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
> >>igt_sysfs_scanf(engine, ATTR, "%u", );
> >>igt_assert_eq(delay, value);
> >>   }
> >> @@ -82,7 +82,7 @@ static int wait_for_reset(int fence)
> >>
> >>   static void test_idempotent(int i915, int engine)
> >>   {
> >> -  unsigned int delays[] = { 0, 1, 1000, 1234, 654321 };
> >> +  unsigned int delays[] = { 0, 1, 1000, 1234, 54321 };
> > By way of documenting the difference between GuC and execlists, I think we
> > should use gem_using_guc_submission and define two different arrays, one
> > for execlists and the other for GuC?
> I really don't think it is worth the effort. Is execlist mode ever going to
> genuinely want an pre-emption timeout or execution quantum of 654s? And
> note that this test is not actually testing the behaviour with those
> values. It merely tests that it can set the value. There are other
> behavioural tests and they max out at 0.5s. So I don't see any benefit to
> adding in the extra complexity to verify that a certain range of values
> passes on execlist but fails on GuC.
>
> >
> > We could of course go the extra yard and check for errors with excessively
> > large values but I'm not sure if that's worth it so am ok if we skip that
> > at this point. Or that's a later patch.
> The 'invalid' test already puts in 'excessively large' values and checks
> that they are rejected.

Fair enough:

Reviewed-by: Ashutosh Dixit 

> >
> > Below too.
> >
> > Thanks.
> > --
> > Ashutosh
> >
> >
> >>unsigned int saved;
> >>
> >>/* Quick test that store/show reports the same values */
> >> diff --git a/tests/i915/sysfs_timeslice_duration.c 
> >> b/tests/i915/sysfs_timeslice_duration.c
> >> index 8a2f1c2f2ece..95dc377785a5 100644
> >> --- a/tests/i915/sysfs_timeslice_duration.c
> >> +++ b/tests/i915/sysfs_timeslice_duration.c
> >> @@ -79,7 +79,7 @@ static void set_timeslice(int engine, unsigned int value)
> >>   {
> >>unsigned int delay;
> >>
> >> -  igt_sysfs_printf(engine, ATTR, "%u", value);
> >> +  igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
> >>igt_sysfs_scanf(engine, ATTR, "%u", );
> >>igt_assert_eq(delay, value);
> >>   }
> >> @@ -93,7 +93,7 @@ static int wait_for_reset(int fence)
> >>
> >>   static void test_idempotent(int i915, int engine)
> >>   {
> >> -  const unsigned int delays[] = { 0, 1, 1234, 654321 };
> >> +  const unsigned int delays[] = { 0, 1, 1234, 54321 };
> >>unsigned int saved;
> >>
> >>/* Quick test to verify the kernel reports the same values as we write 
> >> */
> >> --
> >> 2.37.3
> >>
>

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add MC6 Wa_14017210380 for SAMedia

[Nilawar, Badal]

Hi Matt,

On 01-11-2022 20:47, Matt Roper wrote:

On Sat, Oct 29, 2022 at 12:59:35AM +0530, Badal Nilawar wrote:

This workaround is added for Media Tile of MTL A step. It is to help
pcode workaround which handles the hardware bug seen on CXL splitter
during package C2/C3 transitins due to MC6 entry/exit. As a part of
workaround pcode expect kmd to send mailbox message "media busy" when
components of Media tile is in use and "media not busy" when not in use.
As per workaround description gucrc need to be disabled so enabled
host based RC for Media tile.

HSD: 14017210380

Cc: Rodrigo Vivi 
Cc: Radhakrishna Sripada 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 33 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 -
  drivers/gpu/drm/i915/i915_drv.h   |  4 +++
  drivers/gpu/drm/i915/i915_reg.h   |  9 +++
  4 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index f553e2173bda..398dbeb298ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,10 +19,37 @@
  #include "intel_rc6.h"
  #include "intel_rps.h"
  #include "intel_wakeref.h"
+#include "intel_pcode.h"
  #include "pxp/intel_pxp_pm.h"
  
  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
  
+/*

+ * Wa_14017210380: mtl
+ */


This doesn't appear to be a valid workaround number; workaround numbers
are always supposed to be the "lineage" numbers from the workaround
database.  Wa_14017073508 seems to be related; is that the one you're
implementing?
Thanks for pointing out I will correct the workaround number in next 
revision.



+
+static bool mtl_needs_media_mc6_wa(struct intel_gt *gt)


Drive-by comment:  names like this aren't great since even though
there's only one "media MC6" workaround today, that may not be true in
the future.
I think its better to drop this function and replace its calls below 
with (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) && gt->type == 
GT_MEDIA)


Regards,
Badal



Matt


+{
+   return (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA);
+}
+
+static void mtl_mc6_wa_media_busy(struct intel_gt *gt)
+{
+   if (mtl_needs_media_mc6_wa(gt))
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
+static void mtl_mc6_wa_media_not_busy(struct intel_gt *gt)
+{
+   if (mtl_needs_media_mc6_wa(gt))
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
  static void user_forcewake(struct intel_gt *gt, bool suspend)
  {
int count = atomic_read(>user_wakeref);
@@ -70,6 +97,9 @@ static int __gt_unpark(struct intel_wakeref *wf)
  
  	GT_TRACE(gt, "\n");
  
+	/* Wa_14017210380: mtl */

+   mtl_mc6_wa_media_busy(gt);
+
/*
 * It seems that the DMC likes to transition between the DC states a lot
 * when there are no connected displays (no active power domains) during
@@ -119,6 +149,9 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_BUG_ON(!wakeref);
intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
  
+	/* Wa_14017210380: mtl */

+   mtl_mc6_wa_media_not_busy(gt);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c

index 8f8dd05835c5..cc6356ff84a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -11,9 +11,20 @@
  
  static bool __guc_rc_supported(struct intel_guc *guc)

  {
+   struct intel_gt *gt = guc_to_gt(guc);
+
+   /*
+* Wa_14017210380: mtl
+* Do not enable gucrc to avoid additional interrupts which
+* may disrupt pcode wa.
+*/
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA)
+   return false;
+
/* GuC RC is unavailable for pre-Gen12 */
return guc->submission_supported &&
-   GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+   GRAPHICS_VER(gt->i915) >= 12;
  }
  
  static bool __guc_rc_selected(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05b3300cc4ed..659b92382ff2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -740,6 +740,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
(IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
  
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/sysfs: Update timeslice/preemption for new range limits

[John Harrison]

On 11/1/2022 08:27, Dixit, Ashutosh wrote:

On Mon, 31 Oct 2022 15:24:40 -0700, john.c.harri...@intel.com wrote:

From: John Harrison 

Guc submission imposes new range limits on certain scheduling
parameters. The idempotent sections of the timeslice duration and
pre-emption timeout tests was exceeding those limits and so would fail.

Reduce the excessively large value (654s) to one which does not
overflow (54s). Also add an assert that the write of the new value
actually succeeds.

Signed-off-by: John Harrison 
---
  tests/i915/sysfs_preempt_timeout.c| 4 ++--
  tests/i915/sysfs_timeslice_duration.c | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/i915/sysfs_preempt_timeout.c 
b/tests/i915/sysfs_preempt_timeout.c
index 515038281638..5e0a7d96299f 100644
--- a/tests/i915/sysfs_preempt_timeout.c
+++ b/tests/i915/sysfs_preempt_timeout.c
@@ -68,7 +68,7 @@ static void set_preempt_timeout(int engine, unsigned int 
value)
  {
unsigned int delay;

-   igt_sysfs_printf(engine, ATTR, "%u", value);
+   igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
igt_sysfs_scanf(engine, ATTR, "%u", );
igt_assert_eq(delay, value);
  }
@@ -82,7 +82,7 @@ static int wait_for_reset(int fence)

  static void test_idempotent(int i915, int engine)
  {
-   unsigned int delays[] = { 0, 1, 1000, 1234, 654321 };
+   unsigned int delays[] = { 0, 1, 1000, 1234, 54321 };

By way of documenting the difference between GuC and execlists, I think we
should use gem_using_guc_submission and define two different arrays, one
for execlists and the other for GuC?
I really don't think it is worth the effort. Is execlist mode ever going 
to genuinely want an pre-emption timeout or execution quantum of 654s? 
And note that this test is not actually testing the behaviour with those 
values. It merely tests that it can set the value. There are other 
behavioural tests and they max out at 0.5s. So I don't see any benefit 
to adding in the extra complexity to verify that a certain range of 
values passes on execlist but fails on GuC.




We could of course go the extra yard and check for errors with excessively
large values but I'm not sure if that's worth it so am ok if we skip that
at this point. Or that's a later patch.
The 'invalid' test already puts in 'excessively large' values and checks 
that they are rejected.


John.



Below too.

Thanks.
--
Ashutosh



unsigned int saved;

/* Quick test that store/show reports the same values */
diff --git a/tests/i915/sysfs_timeslice_duration.c 
b/tests/i915/sysfs_timeslice_duration.c
index 8a2f1c2f2ece..95dc377785a5 100644
--- a/tests/i915/sysfs_timeslice_duration.c
+++ b/tests/i915/sysfs_timeslice_duration.c
@@ -79,7 +79,7 @@ static void set_timeslice(int engine, unsigned int value)
  {
unsigned int delay;

-   igt_sysfs_printf(engine, ATTR, "%u", value);
+   igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
igt_sysfs_scanf(engine, ATTR, "%u", );
igt_assert_eq(delay, value);
  }
@@ -93,7 +93,7 @@ static int wait_for_reset(int fence)

  static void test_idempotent(int i915, int engine)
  {
-   const unsigned int delays[] = { 0, 1, 1234, 654321 };
+   const unsigned int delays[] = { 0, 1, 1234, 54321 };
unsigned int saved;

/* Quick test to verify the kernel reports the same values as we write 
*/
--
2.37.3

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)
URL   : https://patchwork.freedesktop.org/series/110326/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110326v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110326v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110326v3_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html

  * igt@syncobj_wait@wait-all-for-submit-snapshot:
- shard-skl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/igt@syncobj_w...@wait-all-for-submit-snapshot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-skl1/igt@syncobj_w...@wait-all-for-submit-snapshot.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-iclb7/igt@gem_exec_balan...@parallel-contexts.html

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

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_lmem_swapping@massive:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-skl6/igt@gem_lmem_swapp...@massive.html

  * igt@gem_softpin@evict-single-offset:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#4171])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb2/igt@gem_soft...@evict-single-offset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-tglb7/igt@gem_soft...@evict-single-offset.html

  * igt@i915_module_load@reload:
- shard-skl:  NOTRUN -> [DMESG-WARN][14] ([i915#1982])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-skl6/igt@i915_module_l...@reload.html

  * igt@i915_pm_backlight@fade:
- shard-iclb: [PASS][15] -> [DMESG-WARN][16] ([i915#402])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@i915_pm_backli...@fade.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-iclb8/igt@i915_pm_backli...@fade.html

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

  * igt@i915_selftest@live@gt_pm:
- shard-skl:  NOTRUN -> [DMESG-FAIL][19] ([i915#1886])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/shard-skl6/igt@i915_selftest@live@gt_pm.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +2 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html
   [21]: 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/sysfs: Update timeslice/preemption for new range limits

[Dixit, Ashutosh]

On Mon, 31 Oct 2022 15:24:40 -0700, john.c.harri...@intel.com wrote:
>
> From: John Harrison 
>
> Guc submission imposes new range limits on certain scheduling
> parameters. The idempotent sections of the timeslice duration and
> pre-emption timeout tests was exceeding those limits and so would fail.
>
> Reduce the excessively large value (654s) to one which does not
> overflow (54s). Also add an assert that the write of the new value
> actually succeeds.
>
> Signed-off-by: John Harrison 
> ---
>  tests/i915/sysfs_preempt_timeout.c| 4 ++--
>  tests/i915/sysfs_timeslice_duration.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/i915/sysfs_preempt_timeout.c 
> b/tests/i915/sysfs_preempt_timeout.c
> index 515038281638..5e0a7d96299f 100644
> --- a/tests/i915/sysfs_preempt_timeout.c
> +++ b/tests/i915/sysfs_preempt_timeout.c
> @@ -68,7 +68,7 @@ static void set_preempt_timeout(int engine, unsigned int 
> value)
>  {
>   unsigned int delay;
>
> - igt_sysfs_printf(engine, ATTR, "%u", value);
> + igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
>   igt_sysfs_scanf(engine, ATTR, "%u", );
>   igt_assert_eq(delay, value);
>  }
> @@ -82,7 +82,7 @@ static int wait_for_reset(int fence)
>
>  static void test_idempotent(int i915, int engine)
>  {
> - unsigned int delays[] = { 0, 1, 1000, 1234, 654321 };
> + unsigned int delays[] = { 0, 1, 1000, 1234, 54321 };

By way of documenting the difference between GuC and execlists, I think we
should use gem_using_guc_submission and define two different arrays, one
for execlists and the other for GuC?

We could of course go the extra yard and check for errors with excessively
large values but I'm not sure if that's worth it so am ok if we skip that
at this point. Or that's a later patch.

Below too.

Thanks.
--
Ashutosh


>   unsigned int saved;
>
>   /* Quick test that store/show reports the same values */
> diff --git a/tests/i915/sysfs_timeslice_duration.c 
> b/tests/i915/sysfs_timeslice_duration.c
> index 8a2f1c2f2ece..95dc377785a5 100644
> --- a/tests/i915/sysfs_timeslice_duration.c
> +++ b/tests/i915/sysfs_timeslice_duration.c
> @@ -79,7 +79,7 @@ static void set_timeslice(int engine, unsigned int value)
>  {
>   unsigned int delay;
>
> - igt_sysfs_printf(engine, ATTR, "%u", value);
> + igt_assert_lte(0, igt_sysfs_printf(engine, ATTR, "%u", value));
>   igt_sysfs_scanf(engine, ATTR, "%u", );
>   igt_assert_eq(delay, value);
>  }
> @@ -93,7 +93,7 @@ static int wait_for_reset(int fence)
>
>  static void test_idempotent(int i915, int engine)
>  {
> - const unsigned int delays[] = { 0, 1, 1234, 654321 };
> + const unsigned int delays[] = { 0, 1, 1234, 54321 };
>   unsigned int saved;
>
>   /* Quick test to verify the kernel reports the same values as we write 
> */
> --
> 2.37.3
>

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add MC6 Wa_14017210380 for SAMedia

[Matt Roper]

On Sat, Oct 29, 2022 at 12:59:35AM +0530, Badal Nilawar wrote:
> This workaround is added for Media Tile of MTL A step. It is to help
> pcode workaround which handles the hardware bug seen on CXL splitter
> during package C2/C3 transitins due to MC6 entry/exit. As a part of
> workaround pcode expect kmd to send mailbox message "media busy" when
> components of Media tile is in use and "media not busy" when not in use.
> As per workaround description gucrc need to be disabled so enabled
> host based RC for Media tile.
> 
> HSD: 14017210380
> 
> Cc: Rodrigo Vivi 
> Cc: Radhakrishna Sripada 
> Cc: Vinay Belgaumkar 
> Cc: Chris Wilson 
> Signed-off-by: Badal Nilawar 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 33 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 -
>  drivers/gpu/drm/i915/i915_drv.h   |  4 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  9 +++
>  4 files changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index f553e2173bda..398dbeb298ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -19,10 +19,37 @@
>  #include "intel_rc6.h"
>  #include "intel_rps.h"
>  #include "intel_wakeref.h"
> +#include "intel_pcode.h"
>  #include "pxp/intel_pxp_pm.h"
>  
>  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
>  
> +/*
> + * Wa_14017210380: mtl
> + */

This doesn't appear to be a valid workaround number; workaround numbers
are always supposed to be the "lineage" numbers from the workaround
database.  Wa_14017073508 seems to be related; is that the one you're
implementing?

> +
> +static bool mtl_needs_media_mc6_wa(struct intel_gt *gt)

Drive-by comment:  names like this aren't great since even though
there's only one "media MC6" workaround today, that may not be true in
the future.


Matt

> +{
> + return (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
> + gt->type == GT_MEDIA);
> +}
> +
> +static void mtl_mc6_wa_media_busy(struct intel_gt *gt)
> +{
> + if (mtl_needs_media_mc6_wa(gt))
> + snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
> +   PCODE_MBOX_GT_STATE_MEDIA_BUSY,
> +   PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
> +}
> +
> +static void mtl_mc6_wa_media_not_busy(struct intel_gt *gt)
> +{
> + if (mtl_needs_media_mc6_wa(gt))
> + snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
> +   PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
> +   PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
> +}
> +
>  static void user_forcewake(struct intel_gt *gt, bool suspend)
>  {
>   int count = atomic_read(>user_wakeref);
> @@ -70,6 +97,9 @@ static int __gt_unpark(struct intel_wakeref *wf)
>  
>   GT_TRACE(gt, "\n");
>  
> + /* Wa_14017210380: mtl */
> + mtl_mc6_wa_media_busy(gt);
> +
>   /*
>* It seems that the DMC likes to transition between the DC states a lot
>* when there are no connected displays (no active power domains) during
> @@ -119,6 +149,9 @@ static int __gt_park(struct intel_wakeref *wf)
>   GEM_BUG_ON(!wakeref);
>   intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
>  
> + /* Wa_14017210380: mtl */
> + mtl_mc6_wa_media_not_busy(gt);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> index 8f8dd05835c5..cc6356ff84a5 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> @@ -11,9 +11,20 @@
>  
>  static bool __guc_rc_supported(struct intel_guc *guc)
>  {
> + struct intel_gt *gt = guc_to_gt(guc);
> +
> + /*
> +  * Wa_14017210380: mtl
> +  * Do not enable gucrc to avoid additional interrupts which
> +  * may disrupt pcode wa.
> +  */
> + if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
> + gt->type == GT_MEDIA)
> + return false;
> +
>   /* GuC RC is unavailable for pre-Gen12 */
>   return guc->submission_supported &&
> - GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
> + GRAPHICS_VER(gt->i915) >= 12;
>  }
>  
>  static bool __guc_rc_selected(struct intel_guc *guc)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 05b3300cc4ed..659b92382ff2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -740,6 +740,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
>   (IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
>  
> +#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
> + (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
> && \
> +  IS_GRAPHICS_STEP(__i915, since, until))
> +
>  /*
>   

Re: [Intel-gfx] [v2] drm/i915/pps: improve eDP power on flow

[Lee, Shawn C]

On Tue, Nov. 1, 2022, 1:43 p.m, Jani Nikula  wrote:
>On Tue, 01 Nov 2022, "Lee, Shawn C"  wrote:
>> On Tuesday, November 1, 2022 5:53 PM, Jani Nikula 
>>  wrote:
>>>On Mon, 24 Oct 2022, Lee Shawn C  wrote:
 A panel power off cycle delay always append before turn eDP on.
 Driver should check last_power_on and last_backlight_off before 
 insert this delay. If these values are the same, it means eDP was 
 off until now and driver can bypass power off cycle delay to save 
 some times to speed up eDP power on sequence.

 v2: fix commit messages
>>>
>>>There are more changes here than what the changelog says, but the previous 
>>>review comments were not answered [1].
>>>
>>
>> I'm sorry that lose the question in [1]. 
>>
>> "But someone else may have turned it off just before we were handed control, 
>> we have no idea."
>> This is the situation from Ville's comment. Agree that we don't know when 
>> panel will be powered off.
>> In my opinion, eDP panel should not be turned off before i915 take it over. 
>> If it was turned on or off by standard contorl (ex: modeset).
>> last_power_on and last_backlight_off would not be the same. So this change 
>> should be safe.
>
>I think it's pretty much a hard requirement we respect the panel delays 
>at i915 probe. If we don't know, we don't know, and we can't make 
>assumptions.
>
>If the goal is to speed up boot, you should ensure 1) the pre-os 
>enables the display, and 2) i915 can take over the display without a 
>modeset and a panel power cycle.
>

After boot into kernel. It seems there are two cases we will see. 
1) If eDP display did not enable at pre-os stage, this patch can save power 
cycle time. 
2) If eDP display was enabled at pre-os, because of cdclk was setting to max 
freq always.
   i915 driver will trigger modeset to reduce cdclk freq and run power off/on 
cycle.
   At this case power cycle delay will not be ignored.

So this patch can only benefit at case #1 (eDP did not enable at pre-os stage). 
And it is what we need. :)

Best regards,
Shawn

>
>BR,
>Jani.
>
>
>>
>> Best regards,
>> Shawn
>>
>>>
>>>BR,
>>>Jani.
>>>
>>>
>>>[1] https://lore.kernel.org/r/y1afudawfvtac...@intel.com
>>>

 Cc: Shankar Uma 
 Cc: Jani Nikula 
 Cc: Ville Syrjälä 
 Signed-off-by: Lee Shawn C 
 ---
  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 21944f5bf3a8..290473ec70d5 100644
 --- a/drivers/gpu/drm/i915/display/intel_pps.c
 +++ b/drivers/gpu/drm/i915/display/intel_pps.c
 @@ -509,6 +509,13 @@ static void wait_panel_power_cycle(struct intel_dp 
 *intel_dp)
ktime_t panel_power_on_time;
s64 panel_power_off_duration;
  
 +  /* When last_power_on equal to last_backlight_off, it means driver did 
 not
 +   * turn on or off eDP panel so far. So we can bypass power cycle delay 
 to
 +   * save some times here.
 +   */
 +  if (intel_dp->pps.last_power_on == intel_dp->pps.last_backlight_off)
 +  return;
 +
drm_dbg_kms(>drm, "Wait for panel power cycle\n");
  
/* take the difference of current time and panel power off time 
 @@
 -1100,7 +1107,7 @@ static void pps_init_timestamps(struct intel_dp
 *intel_dp)  {
intel_dp->pps.panel_power_off_time = ktime_get_boottime();
intel_dp->pps.last_power_on = jiffies;
 -  intel_dp->pps.last_backlight_off = jiffies;
 +  intel_dp->pps.last_backlight_off = intel_dp->pps.last_power_on;
  }
  
  static void
>>>
>>>--
>>>Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [v2] drm/i915/pps: improve eDP power on flow

[Lee, Shawn C]

On Tue, Nov. 1, 2022, 1:43 p.m, Jani Nikula  wrote:
>On Tue, 01 Nov 2022, "Lee, Shawn C"  wrote:
>> On Tuesday, November 1, 2022 5:53 PM, Jani Nikula 
>>  wrote:
>>>On Mon, 24 Oct 2022, Lee Shawn C  wrote:
 A panel power off cycle delay always append before turn eDP on.
 Driver should check last_power_on and last_backlight_off before insert 
 this delay. If these values are the same, it means eDP was off until 
 now and driver can bypass power off cycle delay to save some times to 
 speed up eDP power on sequence.

 v2: fix commit messages
>>>
>>>There are more changes here than what the changelog says, but the previous 
>>>review comments were not answered [1].
>>>
>>
>> I'm sorry that lose the question in [1]. 
>>
>> "But someone else may have turned it off just before we were handed control, 
>> we have no idea."
>> This is the situation from Ville's comment. Agree that we don't know when 
>> panel will be powered off.
>> In my opinion, eDP panel should not be turned off before i915 take it over. 
>> If it was turned on or off by standard contorl (ex: modeset).
>> last_power_on and last_backlight_off would not be the same. So this change 
>> should be safe.
>
>I think it's pretty much a hard requirement we respect the panel delays
>at i915 probe. If we don't know, we don't know, and we can't make
>assumptions.
>
>If the goal is to speed up boot, you should ensure 1) the pre-os enables
>the display, and 2) i915 can take over the display without a modeset and
>a panel power cycle.
>

After boot into kernel. It seems there are two cases we will see. 
1) If eDP display did not enable at pre-os stage, this patch can save power 
cycle time. 
2) If eDP display was enabled at pre-os, because of cdclk was setting to max 
freq always.
   i915 driver will trigger modeset to reduce cdclk freq and run power off/on 
cycle.
   At this case power cycle delay will not be ignored.

So this patch can only benefit at case #1 (eDP did not enable at pre-os stage). 
And it is what we need. :)

Best regards,
Shawn

>
>BR,
>Jani.
>
>
>>
>> Best regards,
>> Shawn
>>
>>>
>>>BR,
>>>Jani.
>>>
>>>
>>>[1] https://lore.kernel.org/r/y1afudawfvtac...@intel.com
>>>

 Cc: Shankar Uma 
 Cc: Jani Nikula 
 Cc: Ville Syrjälä 
 Signed-off-by: Lee Shawn C 
 ---
  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 21944f5bf3a8..290473ec70d5 100644
 --- a/drivers/gpu/drm/i915/display/intel_pps.c
 +++ b/drivers/gpu/drm/i915/display/intel_pps.c
 @@ -509,6 +509,13 @@ static void wait_panel_power_cycle(struct intel_dp 
 *intel_dp)
ktime_t panel_power_on_time;
s64 panel_power_off_duration;
  
 +  /* When last_power_on equal to last_backlight_off, it means driver did 
 not
 +   * turn on or off eDP panel so far. So we can bypass power cycle delay 
 to
 +   * save some times here.
 +   */
 +  if (intel_dp->pps.last_power_on == intel_dp->pps.last_backlight_off)
 +  return;
 +
drm_dbg_kms(>drm, "Wait for panel power cycle\n");
  
/* take the difference of current time and panel power off time @@ 
 -1100,7 +1107,7 @@ static void pps_init_timestamps(struct intel_dp 
 *intel_dp)  {
intel_dp->pps.panel_power_off_time = ktime_get_boottime();
intel_dp->pps.last_power_on = jiffies;
 -  intel_dp->pps.last_backlight_off = jiffies;
 +  intel_dp->pps.last_backlight_off = intel_dp->pps.last_power_on;
  }
  
  static void
>>>
>>>--
>>>Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 03/10] vfio: Rename vfio_device_assign/unassign_container()

[Yi Liu]

On 2022/10/26 02:17, Jason Gunthorpe wrote:

These functions don't really assign anything anymore, they just increment
some refcounts and do a sanity check. Call them
vfio_group_[un]use_container()

Signed-off-by: Jason Gunthorpe 
---
  drivers/vfio/container.c | 14 ++
  drivers/vfio/vfio.h  |  4 ++--
  drivers/vfio/vfio_main.c |  6 +++---
  3 files changed, 11 insertions(+), 13 deletions(-)


Reviewed-by: Yi Liu 


diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index dd79a66ec62cad..499777930b08fa 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -511,10 +511,8 @@ void vfio_group_detach_container(struct vfio_group *group)
vfio_container_put(container);
  }
  
-int vfio_device_assign_container(struct vfio_device *device)

+int vfio_group_use_container(struct vfio_group *group)
  {
-   struct vfio_group *group = device->group;
-
lockdep_assert_held(>group_lock);
  
  	if (!group->container || !group->container->iommu_driver ||

@@ -529,13 +527,13 @@ int vfio_device_assign_container(struct vfio_device 
*device)
return 0;
  }
  
-void vfio_device_unassign_container(struct vfio_device *device)

+void vfio_group_unuse_container(struct vfio_group *group)
  {
-   lockdep_assert_held_write(>group->group_lock);
+   lockdep_assert_held(>group_lock);
  
-	WARN_ON(device->group->container_users <= 1);

-   device->group->container_users--;
-   fput(device->group->opened_file);
+   WARN_ON(group->container_users <= 1);
+   group->container_users--;
+   fput(group->opened_file);
  }
  
  /*

diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index bcad54bbab08c4..f95f4925b83bbd 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -112,8 +112,8 @@ void vfio_unregister_iommu_driver(const struct 
vfio_iommu_driver_ops *ops);
  bool vfio_assert_device_open(struct vfio_device *device);
  
  struct vfio_container *vfio_container_from_file(struct file *filep);

-int vfio_device_assign_container(struct vfio_device *device);
-void vfio_device_unassign_container(struct vfio_device *device);
+int vfio_group_use_container(struct vfio_group *group);
+void vfio_group_unuse_container(struct vfio_group *group);
  int vfio_container_attach_group(struct vfio_container *container,
struct vfio_group *group);
  void vfio_group_detach_container(struct vfio_group *group);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 204443ba3b3cd9..8d809ecd982b39 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,7 +749,7 @@ static int vfio_device_first_open(struct vfio_device 
*device)
 * it during close_device.
 */
mutex_lock(>group->group_lock);
-   ret = vfio_device_assign_container(device);
+   ret = vfio_group_use_container(device->group);
if (ret)
goto err_module_put;
  
@@ -764,7 +764,7 @@ static int vfio_device_first_open(struct vfio_device *device)

return 0;
  
  err_container:

-   vfio_device_unassign_container(device);
+   vfio_group_unuse_container(device->group);
  err_module_put:
device->kvm = NULL;
mutex_unlock(>group->group_lock);
@@ -781,7 +781,7 @@ static void vfio_device_last_close(struct vfio_device 
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
-   vfio_device_unassign_container(device);
+   vfio_group_unuse_container(device->group);
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);
  }


--
Regards,
Yi Liu

Re: [Intel-gfx] [PATCH 02/10] vfio: Move vfio_device_assign_container() into vfio_device_first_open()

[Yi Liu]

On 2022/10/26 02:17, Jason Gunthorpe wrote:

The only thing this function does is assert the group has an assigned
container and incrs refcounts.

The overall model we have is that once a conatiner_users refcount is


typo.

s/conatiner_users/container_users


incremented it cannot be de-assigned from the group -
vfio_group_ioctl_unset_container() will fail and the group FD cannot be
closed.

Thus we do not need to check this on evey device FD open, just the


s/evey/every


first. Reorganize the code so that only the first open and last close
manages the container.

Signed-off-by: Jason Gunthorpe 
---
  drivers/vfio/container.c |  4 ++--
  drivers/vfio/vfio_main.c | 18 --
  2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index d74164abbf401d..dd79a66ec62cad 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -531,11 +531,11 @@ int vfio_device_assign_container(struct vfio_device 
*device)
  
  void vfio_device_unassign_container(struct vfio_device *device)

  {
-   mutex_lock(>group->group_lock);
+   lockdep_assert_held_write(>group->group_lock);
+
WARN_ON(device->group->container_users <= 1);
device->group->container_users--;
fput(device->group->opened_file);
-   mutex_unlock(>group->group_lock);
  }
  
  /*

diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index d043383fc3ba2b..204443ba3b3cd9 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,16 +749,22 @@ static int vfio_device_first_open(struct vfio_device 
*device)
 * it during close_device.
 */
mutex_lock(>group->group_lock);
+   ret = vfio_device_assign_container(device);
+   if (ret)
+   goto err_module_put;
+
device->kvm = device->group->kvm;
if (device->ops->open_device) {
ret = device->ops->open_device(device);
if (ret)
-   goto err_module_put;
+   goto err_container;
}
vfio_device_container_register(device);
mutex_unlock(>group->group_lock);
return 0;
  
+err_container:

+   vfio_device_unassign_container(device);
  err_module_put:
device->kvm = NULL;
mutex_unlock(>group->group_lock);
@@ -775,6 +781,7 @@ static void vfio_device_last_close(struct vfio_device 
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
+   vfio_device_unassign_container(device);
mutex_unlock(>group->group_lock);
module_put(device->dev->driver->owner);
  }
@@ -784,12 +791,6 @@ static struct file *vfio_device_open(struct vfio_device 
*device)
struct file *filep;
int ret;
  
-	mutex_lock(>group->group_lock);

-   ret = vfio_device_assign_container(device);
-   mutex_unlock(>group->group_lock);
-   if (ret)
-   return ERR_PTR(ret);
-
mutex_lock(>dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
@@ -833,7 +834,6 @@ static struct file *vfio_device_open(struct vfio_device 
*device)
  err_unassign_container:


should the err_unassign_container be renamed to be err_dec_count?

other parts look good to me.

Reviewed-by: Yi Liu 


device->open_count--;
mutex_unlock(>dev_set->lock);
-   vfio_device_unassign_container(device);
return ERR_PTR(ret);
  }
  
@@ -1040,8 +1040,6 @@ static int vfio_device_fops_release(struct inode *inode, struct file *filep)

device->open_count--;
mutex_unlock(>dev_set->lock);
  
-	vfio_device_unassign_container(device);

-
vfio_device_put_registration(device);
  
  	return 0;


--
Regards,
Yi Liu

Re: [Intel-gfx] [PATCH 01/10] vfio: Move vfio_device driver open/close code to a function

[Yi Liu]

On 2022/10/26 02:17, Jason Gunthorpe wrote:

This error unwind is getting complicated. Move all the code into two
pair'd function. The functions should be called when the open_count == 1
after incrementing/before decrementing.

Signed-off-by: Jason Gunthorpe 
---
  drivers/vfio/vfio_main.c | 95 ++--
  1 file changed, 53 insertions(+), 42 deletions(-)


Reviewed-by: Yi Liu 


diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2d168793d4e1ce..d043383fc3ba2b 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -734,6 +734,51 @@ bool vfio_assert_device_open(struct vfio_device *device)
return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
  }
  
+static int vfio_device_first_open(struct vfio_device *device)

+{
+   int ret;
+
+   lockdep_assert_held(>dev_set->lock);
+
+   if (!try_module_get(device->dev->driver->owner))
+   return -ENODEV;
+
+   /*
+* Here we pass the KVM pointer with the group under the read lock.  If
+* the device driver will use it, it must obtain a reference and release
+* it during close_device.
+*/
+   mutex_lock(>group->group_lock);
+   device->kvm = device->group->kvm;
+   if (device->ops->open_device) {
+   ret = device->ops->open_device(device);
+   if (ret)
+   goto err_module_put;
+   }
+   vfio_device_container_register(device);
+   mutex_unlock(>group->group_lock);
+   return 0;
+
+err_module_put:
+   device->kvm = NULL;
+   mutex_unlock(>group->group_lock);
+   module_put(device->dev->driver->owner);
+   return ret;
+}
+
+static void vfio_device_last_close(struct vfio_device *device)
+{
+   lockdep_assert_held(>dev_set->lock);
+
+   mutex_lock(>group->group_lock);
+   vfio_device_container_unregister(device);
+   if (device->ops->close_device)
+   device->ops->close_device(device);
+   device->kvm = NULL;
+   mutex_unlock(>group->group_lock);
+   module_put(device->dev->driver->owner);
+}
+
  static struct file *vfio_device_open(struct vfio_device *device)
  {
struct file *filep;
@@ -745,29 +790,12 @@ static struct file *vfio_device_open(struct vfio_device 
*device)
if (ret)
return ERR_PTR(ret);
  
-	if (!try_module_get(device->dev->driver->owner)) {

-   ret = -ENODEV;
-   goto err_unassign_container;
-   }
-
mutex_lock(>dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
-   /*
-* Here we pass the KVM pointer with the group under the read
-* lock.  If the device driver will use it, it must obtain a
-* reference and release it during close_device.
-*/
-   mutex_lock(>group->group_lock);
-   device->kvm = device->group->kvm;
-
-   if (device->ops->open_device) {
-   ret = device->ops->open_device(device);
-   if (ret)
-   goto err_undo_count;
-   }
-   vfio_device_container_register(device);
-   mutex_unlock(>group->group_lock);
+   ret = vfio_device_first_open(device);
+   if (ret)
+   goto err_unassign_container;
}
mutex_unlock(>dev_set->lock);
  
@@ -800,20 +828,11 @@ static struct file *vfio_device_open(struct vfio_device *device)
  
  err_close_device:

mutex_lock(>dev_set->lock);
-   mutex_lock(>group->group_lock);
-   if (device->open_count == 1 && device->ops->close_device) {
-   device->ops->close_device(device);
-
-   vfio_device_container_unregister(device);
-   }
-err_undo_count:
-   mutex_unlock(>group->group_lock);
+   if (device->open_count == 1)
+   vfio_device_last_close(device);
+err_unassign_container:
device->open_count--;
-   if (device->open_count == 0 && device->kvm)
-   device->kvm = NULL;
mutex_unlock(>dev_set->lock);
-   module_put(device->dev->driver->owner);
-err_unassign_container:
vfio_device_unassign_container(device);
return ERR_PTR(ret);
  }
@@ -1016,19 +1035,11 @@ static int vfio_device_fops_release(struct inode 
*inode, struct file *filep)
  
  	mutex_lock(>dev_set->lock);

vfio_assert_device_open(device);
-   mutex_lock(>group->group_lock);
-   if (device->open_count == 1 && device->ops->close_device)
-   device->ops->close_device(device);
-
-   vfio_device_container_unregister(device);
-   mutex_unlock(>group->group_lock);
+   if (device->open_count == 1)
+   vfio_device_last_close(device);
device->open_count--;
-   if (device->open_count == 0)
-   device->kvm = NULL;
mutex_unlock(>dev_set->lock);
  
-	

Re: [Intel-gfx] [PATCH v1 4/7] vfio/ccw: move private to mdev lifecycle

[Eric Farman]

On Tue, 2022-11-01 at 09:08 +, Tian, Kevin wrote:
> > From: Eric Farman 
> > Sent: Thursday, October 20, 2022 12:22 AM
> > 
> > @@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct
> > mdev_device *mdev)
> >  {
> > struct subchannel *sch = to_subchannel(mdev->dev.parent);
> > struct vfio_ccw_parent *parent = dev_get_drvdata(
> > >dev);
> > -   struct vfio_ccw_private *private = dev_get_drvdata(
> > >dev);
> > +   struct vfio_ccw_private *private;
> > int ret;
> > 
> > -   if (private->state == VFIO_CCW_STATE_NOT_OPER)
> > -   return -ENODEV;
> 
> Not familiar with ccw but just want to double confirm this removal
> is intentional w/o side-effect?

Right, it's intentional and fine. The concern previously was re-probing
the mdev when a device had gone into a non-recoverable state and the
private data was left hanging around. With the private now being
cleaned up in mdev_remove instead of the subchannel side, that's no
longer an issue.

> 
> > +   private = vfio_ccw_alloc_private(sch);
> > +   if (!private)
> > +   return -ENOMEM;
> > 
> > ret = vfio_init_device(>vdev, >dev,
> > _ccw_dev_ops);
> > -   if (ret)
> > +   if (ret) {
> > +   kfree(private);
> > return ret;
> > +   }
> > +
> > +   dev_set_drvdata(>dev, private);
> > 
> > VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
> >    sch->schid.cssid,
> > @@ -123,6 +128,7 @@ static int vfio_ccw_mdev_probe(struct
> > mdev_device
> > *mdev)
> > return 0;
> > 
> >  err_put_vdev:
> > +   dev_set_drvdata(>dev, NULL);
> 
> No need to set drvdata to NULL, iiuc

Fair.

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

[kernel test robot]

Hi Stanislav,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm/drm-next linus/master v6.1-rc3 next-20221101]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Stanislav-Lisovskiy/Add-DP-MST-DSC-support-to-i915/20221101-174550
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20221101094222.22091-7-stanislav.lisovskiy%40intel.com
patch subject: [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST 
DSC
config: i386-randconfig-a004
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/effdb0df885df736ad89da1a602dc43f82598408
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Stanislav-Lisovskiy/Add-DP-MST-DSC-support-to-i915/20221101-174550
git checkout effdb0df885df736ad89da1a602dc43f82598408
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/display/intel_dp.c:1543:7: warning: variable 
>> 'dsc_max_output_bpp' is used uninitialized whenever 'if' condition is false 
>> [-Wsometimes-uninitialized]
   if (compute_pipe_bpp) {
   ^~~~
   drivers/gpu/drm/i915/display/intel_dp.c:1559:9: note: uninitialized use 
occurs here
   if ((!dsc_max_output_bpp && compute_pipe_bpp) || 
!dsc_dp_slice_count) {
 ^~
   drivers/gpu/drm/i915/display/intel_dp.c:1543:3: note: remove the 'if' if its 
condition is always true
   if (compute_pipe_bpp) {
   ^~
   drivers/gpu/drm/i915/display/intel_dp.c:1540:25: note: initialize the 
variable 'dsc_max_output_bpp' to silence this warning
   u16 dsc_max_output_bpp;
 ^
  = 0
   1 warning generated.


vim +1543 drivers/gpu/drm/i915/display/intel_dp.c

  1485  
  1486  int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
  1487  struct intel_crtc_state *pipe_config,
  1488  struct drm_connector_state *conn_state,
  1489  struct link_config_limits *limits,
  1490  int timeslots,
  1491  bool compute_pipe_bpp)
  1492  {
  1493  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
  1494  struct drm_i915_private *dev_priv = 
to_i915(dig_port->base.base.dev);
  1495  const struct drm_display_mode *adjusted_mode =
  1496  _config->hw.adjusted_mode;
  1497  int pipe_bpp;
  1498  int ret;
  1499  
  1500  pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
  1501  intel_dp_supports_fec(intel_dp, pipe_config);
  1502  
  1503  if (!intel_dp_supports_dsc(intel_dp, pipe_config))
  1504  return -EINVAL;
  1505  
  1506  if (compute_pipe_bpp)
  1507  pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
  1508  else
  1509  pipe_bpp = pipe_config->pipe_bpp;
  1510  
  1511  if (intel_dp->force_dsc_bpc) {
  1512  pipe_bpp = intel_dp->force_dsc_bpc * 3;
  1513  drm_dbg_kms(_priv->drm, "Input DSC BPP forced to 
%d", pipe_bpp);
  1514  }
  1515  
  1516  /* Min Input BPC for ICL+ is 8 */
  1517  if (pipe_bpp < 8 * 3) {
  1518  drm_dbg_kms(_priv->drm,
  1519  "No DSC support for less than 8bpc\n");
  1520  return -EINVAL;
  1521  }
  1522  
  1523  /*
  1524   * For now enable DSC for max bpp, max link rate, max lane 
count.
  1525   * Optimize this later for the minimum possible link rate/lane 
count
  1526   * with DSC enabled for the requested mode.
  1527   */

Re: [Intel-gfx] [v2] drm/i915/pps: improve eDP power on flow

[Jani Nikula]

On Tue, 01 Nov 2022, "Lee, Shawn C"  wrote:
> On Tuesday, November 1, 2022 5:53 PM, Jani Nikula 
>  wrote:
>>On Mon, 24 Oct 2022, Lee Shawn C  wrote:
>>> A panel power off cycle delay always append before turn eDP on.
>>> Driver should check last_power_on and last_backlight_off before insert 
>>> this delay. If these values are the same, it means eDP was off until 
>>> now and driver can bypass power off cycle delay to save some times to 
>>> speed up eDP power on sequence.
>>>
>>> v2: fix commit messages
>>
>>There are more changes here than what the changelog says, but the previous 
>>review comments were not answered [1].
>>
>
> I'm sorry that lose the question in [1]. 
>
> "But someone else may have turned it off just before we were handed control, 
> we have no idea."
> This is the situation from Ville's comment. Agree that we don't know when 
> panel will be powered off.
> In my opinion, eDP panel should not be turned off before i915 take it over. 
> If it was turned on or off by standard contorl (ex: modeset).
> last_power_on and last_backlight_off would not be the same. So this change 
> should be safe.

I think it's pretty much a hard requirement we respect the panel delays
at i915 probe. If we don't know, we don't know, and we can't make
assumptions.

If the goal is to speed up boot, you should ensure 1) the pre-os enables
the display, and 2) i915 can take over the display without a modeset and
a panel power cycle.


BR,
Jani.


>
> Best regards,
> Shawn
>
>>
>>BR,
>>Jani.
>>
>>
>>[1] https://lore.kernel.org/r/y1afudawfvtac...@intel.com
>>
>>>
>>> Cc: Shankar Uma 
>>> Cc: Jani Nikula 
>>> Cc: Ville Syrjälä 
>>> Signed-off-by: Lee Shawn C 
>>> ---
>>>  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 21944f5bf3a8..290473ec70d5 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_pps.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
>>> @@ -509,6 +509,13 @@ static void wait_panel_power_cycle(struct intel_dp 
>>> *intel_dp)
>>> ktime_t panel_power_on_time;
>>> s64 panel_power_off_duration;
>>>  
>>> +   /* When last_power_on equal to last_backlight_off, it means driver did 
>>> not
>>> +* turn on or off eDP panel so far. So we can bypass power cycle delay 
>>> to
>>> +* save some times here.
>>> +*/
>>> +   if (intel_dp->pps.last_power_on == intel_dp->pps.last_backlight_off)
>>> +   return;
>>> +
>>> drm_dbg_kms(>drm, "Wait for panel power cycle\n");
>>>  
>>> /* take the difference of current time and panel power off time @@ 
>>> -1100,7 +1107,7 @@ static void pps_init_timestamps(struct intel_dp 
>>> *intel_dp)  {
>>> intel_dp->pps.panel_power_off_time = ktime_get_boottime();
>>> intel_dp->pps.last_power_on = jiffies;
>>> -   intel_dp->pps.last_backlight_off = jiffies;
>>> +   intel_dp->pps.last_backlight_off = intel_dp->pps.last_power_on;
>>>  }
>>>  
>>>  static void
>>
>>--
>>Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL
URL   : https://patchwork.freedesktop.org/series/110375/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110375v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 28)
--

  Additional (1): fi-tgl-mst 
  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 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_110375v1:

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-mst}:   NOTRUN -> [WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110375v1/fi-tgl-mst/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

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

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_110375v1

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110375v1: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b62b4181b82d drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Send update also on invalidate (rev2)

[Hogander, Jouni]

I checked possible regressions informed by CI and can't see them being related 
to my patch.

BR,

Jouni Högander

On Sat, 2022-10-29 at 08:37 +, Patchwork wrote:
Patch Details
Series: drm/i915/psr: Send update also on invalidate (rev2)
URL:https://patchwork.freedesktop.org/series/110037/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/index.html
CI Bug Log - changes from CI_DRM_12311_full -> Patchwork_110037v2_full
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110037v2_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 -> 10)

Additional (2): shard-rkl shard-dg1
Missing (1): pig-glk-j5005

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-render:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
  *   igt@kms_vblank@pipe-a-ts-continuation-suspend:

 *   shard-skl: 
PASS
 -> 
INCOMPLETE

Warnings

  *   igt@runner@aborted:
 *   shard-skl: 
(FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL)
 (i915#3002 / 
i915#4312 / 
i915#6949) -> 
(FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL,
 
FAIL)
 (i915#3002 / 
i915#4312)

Suppressed

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

  *   igt@gem_create@create-clear@smem0:
 *   {shard-rkl}: NOTRUN -> 
INCOMPLETE
 +1 similar issue

Known issues

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

IGT changes
Issues hit

  *   igt@gem_exec_balancer@parallel-keep-submit-fence:

 *   shard-iclb: 
PASS
 -> 
SKIP
 (i915#4525)
  *   igt@gem_exec_fair@basic-none-rrul@rcs0:

 *   shard-tglb: NOTRUN -> 
FAIL
 (i915#2842)
  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-tglb: 
PASS
 -> 

Re: [Intel-gfx] [PATCH] drm/i915: update DSC feature flag handling during device init

[Lisovskiy, Stanislav]

On Tue, Oct 11, 2022 at 12:30:48PM +0300, Vinod Govindapillai wrote:
> DSC feature information is no longer part of the DFSM register in
> some display generations.

Reviewed-by: Stanislav Lisovskiy 

> 
> Bspec:50075
> Signed-off-by: Vinod Govindapillai 
> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 908ec241fe71..17d2e3293892 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -480,7 +480,7 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>   if (DISPLAY_VER(dev_priv) >= 11 && (dfsm & 
> ICL_DFSM_DMC_DISABLE))
>   runtime->has_dmc = 0;
>  
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (IS_DISPLAY_VER(dev_priv, 10, 12) &&
>   (dfsm & GLK_DFSM_DISPLAY_DSC_DISABLE))
>   runtime->has_dsc = 0;
>   }
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation

[jim . cromie]

On Tue, Nov 1, 2022 at 2:52 AM Ville Syrjälä
 wrote:
>
> On Mon, Oct 31, 2022 at 08:20:54PM -0400, Jason Baron wrote:
> >
> >
> > On 10/31/22 6:11 PM, jim.cro...@gmail.com wrote:
> > > On Mon, Oct 31, 2022 at 7:07 AM Ville Syrjälä
> > >  wrote:
> > >> On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> > >>> On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
> > >>>  wrote:
> >  On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> > >  wrote:
> > >> On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > >>> On Thu, Oct 27, 2022 at 9:08 AM Jason Baron  
> > >>> wrote:
> > 
> > 
> >  On 10/21/22 05:18, Jani Nikula wrote:
> > > On Thu, 20 Oct 2022, Ville Syrjälä 
> > >  wrote:
> > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> >  hi Greg, Dan, Jason, DRM-folk,
> > 
> >  heres follow-up to V6:
> > rebased on driver-core/driver-core-next for -v6 applied 
> >  bits (thanks)
> > rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> > 
> >  It excludes:
> > nouveau parts (immature)
> > tracefs parts (I missed --to=Steve on v6)
> > split _ddebug_site and de-duplicate experiment (way unready)
> > 
> >  IOW, its the remaining commits of V6 on which Dan gave his 
> >  Reviewed-by.
> > 
> >  If these are good to apply, I'll rebase and repost the rest 
> >  separately.
> > >>> All now queued up, thanks.
> > >> This stuff broke i915 debugs. When I first load i915 no debug 
> > >> prints are
> > >> produced. If I then go fiddle around in 
> > >> /sys/module/drm/parameters/debug
> > >> the debug prints start to suddenly work.
> > > Wait what? I always assumed the default behaviour would stay the 
> > > same,
> > > which is usually how we roll. It's a regression in my books. 
> > > We've got a
> > > CI farm that's not very helpful in terms of dmesg logging right 
> > > now
> > > because of this.
> > >
> > > BR,
> > > Jani.
> > >
> > >
> >  That doesn't sound good - so you are saying that prior to this 
> >  change some
> >  of the drm debugs were default enabled. But now you have to 
> >  manually enable
> >  them?
> > 
> >  Thanks,
> > 
> >  -Jason
> > >>>
> > >>> Im just seeing this now.
> > >>> Any new details ?
> > >> No. We just disabled it as BROKEN for now. I was just today thinking
> > >> about sending that patch out if no solutin is forthcoming soon since
> > >> we need this working before 6.1 is released.
> > >>
> > >> Pretty sure you should see the problem immediately with any driver
> > >> (at least if it's built as a module, didn't try builtin). Or at least
> > >> can't think what would make i915 any more special.
> > >>
> > > So, I should note -
> > > 99% of my time & energy on this dyndbg + drm patchset
> > > has been done using virtme,
> > > so my world-view (and dev-hack-test env) has been smaller, simpler
> > > maybe its been fatally simplistic.
> > >
> > > ive just rebuilt v6.0  (before the trouble)
> > > and run it thru my virtual home box,
> > > I didnt see any unfamiliar drm-debug output
> > > that I might have inadvertently altered somehow
> > >
> > > I have some real HW I can put a reference kernel on,0
> > > to look for the missing output, but its all gonna take some time,
> > > esp to tighten up my dev-test-env
> > >
> > > in the meantime, there is:
> > >
> > > config DRM_USE_DYNAMIC_DEBUG
> > > bool "use dynamic debug to implement drm.debug"
> > > default y
> > > depends on DRM
> > > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> > > depends on JUMP_LABEL
> > > help
> > >Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
> > >Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
> > >bytes per callsite, the .data costs can be substantial, and
> > >are therefore configurable.
> > >
> > > Does changing the default fix things for i915 dmesg ?
> >  I think we want to mark it BROKEN in addition to make sure no one
> > >>> Ok, I get the distinction now.
> > >>> youre spelling that
> > >>>depends on BROKEN
> > >>>
> > >>> I have a notional explanation, and a conflating commit:
> > >>>
> > >>> can you eliminate
> > >>> git log -p ccc2b496324c13e917ef05f563626f4e7826bef1
> > >>>
> > >>> as the cause 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable SDP split for DP2.0 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable SDP split for DP2.0 (rev2)
URL   : https://patchwork.freedesktop.org/series/109395/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_109395v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 30)
--

  Additional (2): fi-tgl-dsi fi-tgl-mst 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 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_109395v2:

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-mst}:   NOTRUN -> [WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/fi-tgl-mst/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109395v2/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html

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

  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6856]: https://gitlab.freedesktop.org/drm/intel/issues/6856
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_109395v2

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 

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

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 08:41:56AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe 
> > Sent: Wednesday, October 26, 2022 2:51 AM
> > 
> >  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
> > + mappings. If N is selected here then IOMMUFD must be used the
> 
> establishing IOMMU mappings.
> 
> s/used the manage/used to manage/

Done

> > +if VFIO_CONTAINER
> >  config VFIO_IOMMU_TYPE1
> > tristate
> > -   default n
> > +   default MMU && (X86 || S390 || ARM || ARM64)
> 
> there are already same conditions for selecting TYPE1 from
> VFIO_CONTAINER. what does duplicating conditions here
> bring to us?

Yah, we can leave this out - this is just the more normal way to
approach this kconfig trick, AFAICT

Thanks,
Jason

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

[Yi Liu]

On 2022/11/1 19:41, Jason Gunthorpe wrote:

On Tue, Nov 01, 2022 at 11:04:38AM +0800, Yi Liu wrote:

On 2022/11/1 07:24, Jason Gunthorpe wrote:

On Mon, Oct 31, 2022 at 08:25:39PM +0800, Yi Liu wrote:

There is something wrong with the test suite that it isn't covering
the above, I'm going to look into that today.


sounds to be the cause. I didn't see any significant change in vfio_main.c
that may fail gvt. So should the iommufd changes. Then we will re-run the
test after your update.:-)


I updated the github with all the changes made so far, it is worth
trying again!


gvt is still failing with below call trace in host side. vfio_unpin_pages()
is still in problem. Any idea on it?


Oh, this is my mistake, I rushed a bit getting updated branches:

diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 40eb6931ab2321..29e7b1fdd0cd4a 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -118,6 +118,7 @@ static void vfio_emulated_unmap(void *data, unsigned long 
iova,
  }
  
  static const struct iommufd_access_ops vfio_user_ops = {

+   .needs_pin_pages = 1,
.unmap = vfio_emulated_unmap,
  };


yes, it is. The call trace goes away. my colleague is running gvt full test 
now.


--
Regards,
Yi Liu

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

[Yi Liu]

On 2022/11/1 12:21, Nicolin Chen wrote:

On Tue, Nov 01, 2022 at 11:04:38AM +0800, Yi Liu wrote:

On 2022/11/1 07:24, Jason Gunthorpe wrote:

On Mon, Oct 31, 2022 at 08:25:39PM +0800, Yi Liu wrote:

There is something wrong with the test suite that it isn't covering
the above, I'm going to look into that today.


sounds to be the cause. I didn't see any significant change in vfio_main.c
that may fail gvt. So should the iommufd changes. Then we will re-run the
test after your update.:-)


I updated the github with all the changes made so far, it is worth
trying again!


gvt is still failing with below call trace in host side. vfio_unpin_pages()
is still in problem. Any idea on it?



[  206.464318] WARNING: CPU: 9 PID: 3362 at
drivers/iommu/iommufd/device.c:591 iommufd_access_pin_pages+0x337/0x360


Judging from this WARNING, and since gvt (mdev) needs pin_pages(),
I assume this might be a fix, though Jason's latest change for the
iova_alignment seems to be added for CONFIG_IOMMUFD_TEST only.

--
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 72a289c5f8c9..185075528d5e 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -120,6 +120,7 @@ static void vfio_emulated_unmap(void *data, unsigned long 
iova,
  }
  
  static const struct iommufd_access_ops vfio_user_ops = {

+   .needs_pin_pages = 1,
.unmap = vfio_emulated_unmap,
  };
  
--


Perhaps you can try it first to see if we can test the rest part of
the routine for now, till Jason acks tomorrow.


fyi. it works so far. :-)

--
Regards,
Yi Liu

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Souza, Jose]

On Tue, 2022-11-01 at 13:53 +0200, Jouni Högander wrote:
> MTL shares PSR2_MAN_TRK_CTL bits with ADL. Currently some bit
> getter functions are incorrect for MTL. This patch fixes those.
> 
> Bspec: 49274

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Radhakrishna Sripada 
> 
> Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 904a1049eff3..4bfb8313738e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1470,7 +1470,8 @@ void intel_psr_resume(struct intel_dp *intel_dp)
>  
>  static u32 man_trk_ctl_enable_bit_get(struct drm_i915_private *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ? 0 : PSR2_MAN_TRK_CTL_ENABLE;
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ? 0 :
> + PSR2_MAN_TRK_CTL_ENABLE;
>  }
>  
>  static u32 man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private 
> *dev_priv)
> @@ -1482,14 +1483,14 @@ static u32 
> man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private *dev_pr
>  
>  static u32 man_trk_ctl_partial_frame_bit_get(struct drm_i915_private 
> *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ?
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
>  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
>  PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
>  }
>  
>  static u32 man_trk_ctl_continuos_full_frame(struct drm_i915_private 
> *dev_priv)
>  {
> - return IS_ALDERLAKE_P(dev_priv) ?
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
>  ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME :
>  PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
>  }

Re: [Intel-gfx] [PATCH 08/10] vfio-iommufd: Support iommufd for emulated VFIO devices

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 08:37:39AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe 
> > Sent: Wednesday, October 26, 2022 2:51 AM
> > 
> > Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> > consist of all the mdev drivers.
> > 
> > Like the physical drivers, support for iommufd is provided by the driver
> > supplying the correct correct standard ops. Provide ops from the core that
> > duplicate what vfio_register_emulated_iommu_dev() does.
> > 
> > Emulated drivers are where it is more likely to see variation in the
> > iommfd support ops. For instance IDXD will probably need to setup both a
> > iommfd_device context linked to a PASID and an iommufd_access context to
> > support all their mdev operations.
> > 
> > Signed-off-by: Jason Gunthorpe 
> > ---
> >  drivers/gpu/drm/i915/gvt/kvmgt.c  |   3 +
> >  drivers/s390/cio/vfio_ccw_ops.c   |   3 +
> >  drivers/s390/crypto/vfio_ap_ops.c |   3 +
> >  drivers/vfio/container.c  | 108 ++---
> >  drivers/vfio/iommufd.c|  57 
> >  drivers/vfio/vfio.h   |  10 ++-
> >  drivers/vfio/vfio_main.c  | 110 +-
> >  include/linux/vfio.h  |  14 
> >  8 files changed, 217 insertions(+), 91 deletions(-)
> 
> mtty, mdpy and mbochs?

They don't call rw or pin_pages, so they don't need to do
anything:


/*
 * If the driver doesn't provide this op then it means the device does
 * not do DMA at all. So nothing to do.
 */
if (!vdev->ops->bind_iommufd)
return 0;

> > +int vfio_container_pin_pages(struct vfio_container *container,
> > +struct iommu_group *iommu_group, dma_addr_t
> > iova,
> > +int npage, int prot, struct page **pages)
> >  {
> > -   struct vfio_container *container;
> > -   struct vfio_group *group = device->group;
> > -   struct vfio_iommu_driver *driver;
> > -   int ret;
> > -
> > -   if (!pages || !npage || !vfio_assert_device_open(device))
> > -   return -EINVAL;
> > +   /* group->container cannot change while a vfio device is open */
> > +   struct vfio_iommu_driver *driver = container->iommu_driver;
> > 
> > if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
> > return -E2BIG;
> > 
> > /* group->container cannot change while a vfio device is open */
> > -   container = group->container;
> > driver = container->iommu_driver;
> 
> duplicated comment and assignment.
> 
> Actually, I'm not sure whether the comment should be put within this
> container helper and other two. There is no group reference in these
> helpers then it sounds like the comment makes more sense to be in the
> caller side?

Yeah, that is better

> > +void vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova, int
> > npage)
> > +{
> > +   if (WARN_ON(!vfio_assert_device_open(device)))
> > +   return;
> > +
> > +   if (device->group->container) {
> > +   vfio_container_unpin_pages(device->group->container, iova,
> > +  npage);
> > +   } else if (device->iommufd_access) {
> 
> be consistent with other two helpers i.e. if-if instead of if-else

Done

> > +   if (WARN_ON(iova > ULONG_MAX))
> > +   return;
> 
> Is there a reason why this is a WARN_ON only in unpin but not in pin?

This is how it has always been. I suppose someone once thought it
would be OK for the driver to do racy stuff during pin - but clearly
that is not the case. Lets fix it while we are here.

> > +int vfio_dma_rw(struct vfio_device *device, dma_addr_t iova, void *data,
> > +   size_t len, bool write)
> > +{
> > +   if (!data || len <= 0 || !vfio_assert_device_open(device))
> > +   return -EINVAL;
> > +
> > +   if (device->group->container)
> > +   return vfio_container_dma_rw(device->group->container,
> > iova,
> > +data, len, write);
> > +
> > +   if (device->iommufd_access) {
> > +   unsigned int flags = 0;
> > +
> > +   if (iova > ULONG_MAX)
> > +   return -EINVAL;
> > +
> > +   /* VFIO historically tries to auto-detect a kthread */
> > +   if (!current->mm)
> > +   flags |= IOMMUFD_ACCESS_RW_KTHREAD;
> 
> Can you elaborate why this cannot be put in iommufd as the default
> policy similar to what vfio container does?

Snooping in kernel structs to try to guess the calling execution
context is bad design. The caller should know its own context and it
should declare positively what it is. Someday this should be lifted
out of VFIO as well and into the drivers.

Jason

Re: [Intel-gfx] [PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe 
> > Sent: Wednesday, October 26, 2022 2:51 AM
> >
> >  menuconfig VFIO
> > tristate "VFIO Non-Privileged userspace driver framework"
> > select IOMMU_API
> > +   depends on IOMMUFD || !IOMMUFD
> 
> Out of curiosity. What is the meaning of this dependency claim?
> 
> > @@ -717,12 +735,23 @@ static int vfio_group_ioctl_set_container(struct
> > vfio_group *group,
> > }
> > 
> > container = vfio_container_from_file(f.file);
> > -   ret = -EINVAL;
> 
> this changes the errno from -EINVAL to -EBADF for the original container
> path. Is it desired?

Yes, EBADFD is the right error code (it is a typo it was EBADF)

> > if (container) {
> > ret = vfio_container_attach_group(container, group);
> > goto out_unlock;
> > }
> > 
> > +   iommufd = iommufd_ctx_from_file(f.file);
> > +   if (!IS_ERR(iommufd)) {
> 
> The only errno which iommufd_ctx_from_file() may return is -EBADFD
> which duplicates with -EBADF assignment in following line.

The concept is that other places using iommufd_ctx_from_file() should
forward the return code directly. vfio is probably the only thing that
is going to be multiplexing like this.

> > +   u32 ioas_id;
> > +
> > +   group->iommufd = iommufd;
> > +   ret = iommufd_vfio_compat_ioas_id(iommufd, _id);
> 
> exchange the order of above two lines and only assign group->iommufd
> when the compat call succeeds.

Yeah, that is probably a small bug:

-   group->iommufd = iommufd;
ret = iommufd_vfio_compat_ioas_id(iommufd, _id);
+   if (ret) {
+   iommufd_ctx_put(group->iommufd);
+   goto out_unlock;
+   }
+
+   group->iommufd = iommufd;
goto out_unlock;


> > @@ -900,7 +940,7 @@ static int vfio_group_ioctl_get_status(struct
> > vfio_group *group,
> > return -ENODEV;
> > }
> > 
> > -   if (group->container)
> > +   if (group->container || group->iommufd)
> > status.flags |= VFIO_GROUP_FLAGS_CONTAINER_SET |
> > VFIO_GROUP_FLAGS_VIABLE;
> 
> Copy some explanation from commit msg to explain the subtle difference
> between container and iommufd.

/*
 * With the container FD the iommu_group_claim_dma_owner() is done
 * during SET_CONTAINER but for IOMMFD this is done during
 * VFIO_GROUP_GET_DEVICE_FD. Meaning that with iommufd
 * VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due
 * to viability.
 */

Thanks,
Jason

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add DP MST DSC support to i915 (rev14)

[Patchwork]

== Series Details ==

Series: Add DP MST DSC support to i915 (rev14)
URL   : https://patchwork.freedesktop.org/series/101492/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_101492v14


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 29)
--

  Additional (1): fi-tgl-mst 
  Missing(12): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 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_101492v14:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@dmabuf:
- fi-bxt-dsi: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bxt-dsi/igt@i915_selftest@l...@dmabuf.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v14/fi-bxt-dsi/igt@i915_selftest@l...@dmabuf.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-mst}:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v14/fi-tgl-mst/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v14/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1245]: https://gitlab.freedesktop.org/drm/intel/issues/1245
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_101492v14

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  

Re: [Intel-gfx] [PATCH 05/10] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 07:52:23AM +, Tian, Kevin wrote:
> > IOMMU_CAP_ENFORCE_CACHE_COHERENCY we know what the
> > iommu_domain will be
> > capable of without having to create it. Use this to compute
> 
> it's worth noting that the prerequisite is that vfio always enforces
> cache coherency on a domain according to the iommu capability
> of the devices attached to that domain. There is no mix of attaching
> a device supporting the cap to a domain which doesn't enforce
> coherency. With that we know what the domain will be w/o having
> to create it.

OK, I added this:

VFIO always tries to upgrade domains to enforce cache coherency, it never
attaches a device that supports enforce cache coherency to a less capable
domain, so the cap test is a sufficient proxy for the ultimate
outcome. iommufd also ensures that devices that set the cap will be
connected to enforcing domains.

> > +   /*
> > +* If the device does not have
> > IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
> > +* any domain later attached to it will also not support it.
> > +*/
> 
> also add the other part i.e. if the device does have the cap then any domain
> later attached to it will have the cap enabled. Only with both clarified
> we can safely use the device cap here.

And this:

/*
 * If the device does not have IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
 * any domain later attached to it will also not support it. If the cap
 * is set then the iommu_domain eventually attached to the device/group
 * must must use a domain with enforce_cache_coherency().
 */

Jason

Re: [Intel-gfx] [PATCH 02/10] vfio: Move vfio_device_assign_container() into vfio_device_first_open()

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 07:38:47AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe 
> > Sent: Wednesday, October 26, 2022 2:17 AM
> > 
> > +err_container:
> > +   vfio_device_unassign_container(device);
> >  err_module_put:
> > device->kvm = NULL;
> 
> err_module_put should be moved after nullifying device->kvm.
> 
> otherwise it looks good to me:
> 
> Reviewed-by: Kevin Tian 

Done, thanks

Jason

Re: [Intel-gfx] [PATCH 01/10] vfio: Move vfio_device driver open/close code to a function

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 07:33:30AM +, Tian, Kevin wrote:

> > +   /*
> > +* Here we pass the KVM pointer with the group under the read lock.
> 
> Now the read lock is replaced by mutex. Let's correct it when moving this
> piece of code.

Done, thanks

Jason

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add DP MST DSC support to i915 (rev14)

[Patchwork]

== Series Details ==

Series: Add DP MST DSC support to i915 (rev14)
URL   : https://patchwork.freedesktop.org/series/101492/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add DP MST DSC support to i915 (rev14)

[Patchwork]

== Series Details ==

Series: Add DP MST DSC support to i915 (rev14)
URL   : https://patchwork.freedesktop.org/series/101492/
State : warning

== Summary ==

Error: dim checkpatch failed
a682457fad34 drm: Add missing DP DSC extended capability definitions.
b9b9c7187c42 drm/i915: Fix intel_dp_mst_compute_link_config
c44bb8185012 drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate 
function
-:79: CHECK:LINE_SPACING: Please don't use multiple blank lines
#79: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:116:
+
+

total: 0 errors, 0 warnings, 1 checks, 75 lines checked
eca8be230991 drm/i915: Add DSC support to MST path
387fa6bcef93 drm/i915: Extract VESA DSC bpp alignment to separate function
-:52: CHECK:LINE_SPACING: Please don't use multiple blank lines
#52: FILE: drivers/gpu/drm/i915/display/intel_dp.c:704:
+
+

total: 0 errors, 0 warnings, 1 checks, 76 lines checked
4370dddb8d16 drm/i915: Bpp/timeslot calculation fixes for DP MST DSC
-:166: ERROR:CODE_INDENT: code indent should use tabs where possible
#166: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:113:
+else {$

-:166: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#166: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:113:
+else {$

-:166: CHECK:BRACES: Unbalanced braces around else statement
#166: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:113:
+else {

-:167: ERROR:CODE_INDENT: code indent should use tabs where possible
#167: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:114:
+if (!dsc)$

-:167: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#167: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:114:
+if (!dsc)$

-:200: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#200: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:187:
+   sink_min_bpp = sink_max_bpp = dsc_bpc[0] * 3;

total: 2 errors, 2 warnings, 2 checks, 220 lines checked

[Intel-gfx] [PATCH] drm/i915/mtl: Fix PSR2_MAN_TRK_CTL bit getter functions for MTL

[Jouni Högander]

MTL shares PSR2_MAN_TRK_CTL bits with ADL. Currently some bit
getter functions are incorrect for MTL. This patch fixes those.

Bspec: 49274

Cc: José Roberto de Souza 
Cc: Mika Kahola 
Cc: Radhakrishna Sripada 

Fixes: 47d4ae2192cb ("drm/i915/mtl: Extend PSR support")
Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 904a1049eff3..4bfb8313738e 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1470,7 +1470,8 @@ void intel_psr_resume(struct intel_dp *intel_dp)
 
 static u32 man_trk_ctl_enable_bit_get(struct drm_i915_private *dev_priv)
 {
-   return IS_ALDERLAKE_P(dev_priv) ? 0 : PSR2_MAN_TRK_CTL_ENABLE;
+   return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ? 0 :
+   PSR2_MAN_TRK_CTL_ENABLE;
 }
 
 static u32 man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private 
*dev_priv)
@@ -1482,14 +1483,14 @@ static u32 man_trk_ctl_single_full_frame_bit_get(struct 
drm_i915_private *dev_pr
 
 static u32 man_trk_ctl_partial_frame_bit_get(struct drm_i915_private *dev_priv)
 {
-   return IS_ALDERLAKE_P(dev_priv) ?
+   return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
   ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
   PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
 }
 
 static u32 man_trk_ctl_continuos_full_frame(struct drm_i915_private *dev_priv)
 {
-   return IS_ALDERLAKE_P(dev_priv) ?
+   return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
   ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME :
   PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
 }
-- 
2.34.1

Re: [Intel-gfx] [PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 02:19:04AM -0700, Nicolin Chen wrote:
> On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:
> 
> > > From: Jason Gunthorpe 
> > > Sent: Wednesday, October 26, 2022 2:51 AM
> > >
> > >  menuconfig VFIO
> > >   tristate "VFIO Non-Privileged userspace driver framework"
> > >   select IOMMU_API
> > > + depends on IOMMUFD || !IOMMUFD
> > 
> > Out of curiosity. What is the meaning of this dependency claim?
> 
> "is it a module or not" -- from https://lwn.net/Articles/683476/

Yes, it is the kconfig pattern for "This symbol optionally uses the
other symbol, and if the other symbol is turned on then it has to be
the right y/m value"

ie rejects vfio being built-in but iommufd being a module

Jason

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

[Jason Gunthorpe]

On Tue, Nov 01, 2022 at 11:04:38AM +0800, Yi Liu wrote:
> On 2022/11/1 07:24, Jason Gunthorpe wrote:
> > On Mon, Oct 31, 2022 at 08:25:39PM +0800, Yi Liu wrote:
> > > > There is something wrong with the test suite that it isn't covering
> > > > the above, I'm going to look into that today.
> > > 
> > > sounds to be the cause. I didn't see any significant change in vfio_main.c
> > > that may fail gvt. So should the iommufd changes. Then we will re-run the
> > > test after your update.:-)
> > 
> > I updated the github with all the changes made so far, it is worth
> > trying again!
> 
> gvt is still failing with below call trace in host side. vfio_unpin_pages()
> is still in problem. Any idea on it?

Oh, this is my mistake, I rushed a bit getting updated branches:

diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 40eb6931ab2321..29e7b1fdd0cd4a 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -118,6 +118,7 @@ static void vfio_emulated_unmap(void *data, unsigned long 
iova,
 }
 
 static const struct iommufd_access_ops vfio_user_ops = {
+   .needs_pin_pages = 1,
.unmap = vfio_emulated_unmap,
 };

Thanks, 
Jason

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: use surface size for bios fb size check (rev2)

[Patchwork]

== Series Details ==

Series: i915: use surface size for bios fb size check (rev2)
URL   : https://patchwork.freedesktop.org/series/109114/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_109114v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_109114v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_109114v2_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-valid-mode:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb1/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-valid-mode.html

  * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-skl9/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][6] -> [DMESG-WARN][7] ([i915#180])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-apl3/igt@gem_ctx_isolation@preservation...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb7/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_lmem_swapping@massive:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-skl4/igt@gem_lmem_swapp...@massive.html

  * igt@i915_pm_backlight@fade:
- shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#402])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb7/igt@i915_pm_backli...@fade.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb1/igt@i915_pm_backli...@fade.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#3989] / [i915#454])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-iclb2/igt@i915_pm...@dc6-psr.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb7/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@live@gt_pm:
- shard-skl:  NOTRUN -> [DMESG-FAIL][17] ([i915#1886])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-skl4/igt@i915_selftest@live@gt_pm.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#5286])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb2/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#110725] / [fdo#111614])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/shard-iclb2/igt@kms_big...@x-tiled-64bpp-rotate-90.html

  * 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)
URL   : https://patchwork.freedesktop.org/series/110326/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110326v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 28)
--

  Additional (1): fi-tgl-mst 
  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adlp-6 
bat-adlp-4 fi-hsw-4770 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_110326v3:

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-mst}:   NOTRUN -> [WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/fi-tgl-mst/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-2:
- fi-icl-u2:  [DMESG-WARN][4] ([i915#2867]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110326v3/fi-icl-u2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-2.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_110326v3

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110326v3: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

d0c15ceecb71 drm/i915/selftests: Run the perf MI_BB tests on gen4/5
51915c6b622a drm/i915/selftests: Test RING_TIMESTAMP on gen4/5
3b2d1ac48d95 drm/i915/selftests: Run MI_BB perf selftests on SNB
a82ff38edfda drm/i915: Fix cs timestamp frequency for cl/bw
2a7e71fe6a2f drm/i915: Stop claiming cs timestamp frquency on gen2/3
150c3764f31b drm/i915: Fix cs timestamp frequency for ctg/elk/ilk

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Enable SDP split for DP2.0

[Vinod Govindapillai]

Enable the SDP split configuration for DP2.0.

v2: Move the register handling out of compute config function (JaniN)

v3: Patch styling and register access based on platform support (JaniN)

v4: Rebased

Bspec: 67768
Signed-off-by: Vinod Govindapillai 
---
 drivers/gpu/drm/i915/display/intel_audio.c| 12 
 drivers/gpu/drm/i915/display/intel_audio.h|  2 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +++
 .../drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 19 +++
 5 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index c3176c9c89a6..415ac3960272 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -798,6 +798,18 @@ static void ilk_audio_codec_enable(struct intel_encoder 
*encoder,
mutex_unlock(>display.audio.mutex);
 }
 
+void intel_audio_sdp_split_update(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum transcoder trans = crtc_state->cpu_transcoder;
+   u32 clear = crtc_state->sdp_split_enable ? 0 : AUD_ENABLE_SDP_SPLIT;
+   u32 set = crtc_state->sdp_split_enable ? AUD_ENABLE_SDP_SPLIT : 0;
+
+   if (HAS_DP20(i915))
+   intel_de_rmw(i915, AUD_DP_2DOT0_CTRL(trans), clear, set);
+}
+
 /**
  * intel_audio_codec_enable - Enable the audio codec for HD audio
  * @encoder: encoder on which to enable audio
diff --git a/drivers/gpu/drm/i915/display/intel_audio.h 
b/drivers/gpu/drm/i915/display/intel_audio.h
index 63b22131dc45..1b87257c6a17 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.h
+++ b/drivers/gpu/drm/i915/display/intel_audio.h
@@ -22,5 +22,7 @@ void intel_audio_cdclk_change_pre(struct drm_i915_private 
*dev_priv);
 void intel_audio_cdclk_change_post(struct drm_i915_private *dev_priv);
 void intel_audio_init(struct drm_i915_private *dev_priv);
 void intel_audio_deinit(struct drm_i915_private *dev_priv);
+void intel_audio_sdp_split_update(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state);
 
 #endif /* __INTEL_AUDIO_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e95bde5cf060..c84b7b0e4c19 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2917,6 +2917,9 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
 
intel_vrr_enable(encoder, crtc_state);
 
+   /* Enable/Disable DP2.0 SDP split config before transcoder */
+   intel_audio_sdp_split_update(encoder, crtc_state);
+
intel_enable_transcoder(crtc_state);
 
intel_crtc_vblank_on(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7f18c052ec16..07eab71d3fc2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1286,6 +1286,8 @@ struct intel_crtc_state {
/* Forward Error correction State */
bool fec_enable;
 
+   bool sdp_split_enable;
+
/* Pointer to master transcoder in case of tiled displays */
enum transcoder master_transcoder;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7400d6b4c587..8a1af1294c6a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2008,6 +2008,23 @@ intel_dp_compute_output_format(struct intel_encoder 
*encoder,
return ret;
 }
 
+static void
+intel_dp_audio_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct drm_connector *connector = conn_state->connector;
+
+   pipe_config->sdp_split_enable =
+   intel_dp_has_audio(encoder, pipe_config, conn_state) &&
+   intel_dp_is_uhbr(pipe_config);
+
+   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] SDP split enable: %s\n",
+   connector->base.id, connector->name,
+   str_yes_no(pipe_config->sdp_split_enable));
+}
+
 int
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -2091,6 +2108,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
adjusted_mode->crtc_clock /= n;
}
 
+   intel_dp_audio_compute_config(encoder, pipe_config, conn_state);
+
intel_link_compute_m_n(output_bpp,
   pipe_config->lane_count,
   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix up and test RING_TIMESTAMP on gen4-6 (rev3)
URL   : https://patchwork.freedesktop.org/series/110326/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Don't use FIELD_PREP

[Jani Nikula]

On Mon, 31 Oct 2022, Ashutosh Dixit  wrote:
> FIELD_PREP and REG_FIELD_PREP have checks requiring a compile time constant
> mask. When the mask comes in as the argument of a function these checks can
> can fail depending on the compiler (gcc vs clang), optimization level,
> etc. Use a simpler version of FIELD_PREP which skips these checks. The
> checks are not needed because the mask is formed using REG_GENMASK (so is
> actually a compile time constant).
>
> v2: Split REG_FIELD_PREP into a macro with checks and one without and use
> the one without checks in i915_hwmon.c (Gwan-gyeong Mun)

I frankly think you're solving the wrong problem here. See [1].

BR,
Jani.

[1] https://lore.kernel.org/r/87leov7yix@intel.com

>
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7354
> Signed-off-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c|  2 +-
>  drivers/gpu/drm/i915/i915_reg_defs.h | 17 +++--
>  2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e97814930254..ae435b035229a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -112,7 +112,7 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat, 
> i915_reg_t rgadr,
>   nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>  
>   bits_to_clear = field_msk;
> - bits_to_set = FIELD_PREP(field_msk, nval);
> + bits_to_set = __REG_FIELD_PREP(field_msk, nval);
>  
>   hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>   bits_to_clear, bits_to_set);
> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h 
> b/drivers/gpu/drm/i915/i915_reg_defs.h
> index f1859046a9c48..dddacc8d48928 100644
> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
> @@ -67,12 +67,17 @@
>   *
>   * @return: @__val masked and shifted into the field defined by @__mask.
>   */
> -#define REG_FIELD_PREP(__mask, __val)
> \
> - ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) + 
> \
> -BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
> -BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + 
> \
> -BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
> __bf_shf(__mask + \
> -BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
> (~((__mask) >> __bf_shf(__mask)) & (__val)), 0
> +#define __REG_FIELD_PREP_CHK(__mask, __val) \
> + (BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
> +  BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) + \
> +  BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL << 
> __bf_shf(__mask + \
> +  BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val), 
> (~((__mask) >> __bf_shf(__mask)) & (__val)), 0)))
> +
> +#define __REG_FIELD_PREP(__mask, __val) \
> + ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask
> +
> +#define REG_FIELD_PREP(__mask, __val) \
> + (__REG_FIELD_PREP(__mask, __val) + __REG_FIELD_PREP_CHK(__mask, __val))
>  
>  /**
>   * REG_FIELD_GET() - Extract a u32 bitfield value

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Switch intel_connector_needs_modeset() to drm types

[Jani Nikula]

On Mon, 31 Oct 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> intel_connector_needs_modeset() currently uses a mix of drm_
> and intel_ types. But it doesn't actually need anything from
> the intel_ stuff, so seems better to switch the whole thing
> over to the drm_ types. Should help anyone who wants to steal
> it as well :)

I kind of get the point, but it goes against what we tell everyone to
do. :(

OTOH if this were drm_connector_needs_modeset() somewhere in drm, it
would be a whole different matter.


BR,
Jani.



>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c  | 11 +--
>  drivers/gpu/drm/i915/display/intel_atomic.h  |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c |  4 ++--
>  drivers/gpu/drm/i915/display/intel_dp.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  2 +-
>  5 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 6621aa245caf..f3fe2889bde3 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -175,18 +175,17 @@ intel_digital_connector_duplicate_state(struct 
> drm_connector *connector)
>   * @connector: the connector
>   */
>  bool
> -intel_connector_needs_modeset(struct intel_atomic_state *state,
> +intel_connector_needs_modeset(struct drm_atomic_state *state,
> struct drm_connector *connector)
>  {
>   const struct drm_connector_state *old_conn_state, *new_conn_state;
>  
> - old_conn_state = drm_atomic_get_old_connector_state(>base, 
> connector);
> - new_conn_state = drm_atomic_get_new_connector_state(>base, 
> connector);
> + old_conn_state = drm_atomic_get_old_connector_state(state, connector);
> + new_conn_state = drm_atomic_get_new_connector_state(state, connector);
>  
>   return old_conn_state->crtc != new_conn_state->crtc ||
> -(new_conn_state->crtc &&
> - 
> drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_state(>base,
> - 
> new_conn_state->crtc)));
> + (new_conn_state->crtc &&
> +  
> drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_state(state, 
> new_conn_state->crtc)));
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h 
> b/drivers/gpu/drm/i915/display/intel_atomic.h
> index 1dc439983dd9..8829b6f58aee 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -33,7 +33,7 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>struct drm_atomic_state *state);
>  struct drm_connector_state *
>  intel_digital_connector_duplicate_state(struct drm_connector *connector);
> -bool intel_connector_needs_modeset(struct intel_atomic_state *state,
> +bool intel_connector_needs_modeset(struct drm_atomic_state *state,
>  struct drm_connector *connector);
>  bool intel_any_crtc_needs_modeset(struct intel_atomic_state *state);
>  struct intel_digital_connector_state *
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2d91c59a827d..1a16625ce058 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1517,7 +1517,7 @@ static void intel_encoders_update_prepare(struct 
> intel_atomic_state *state)
>   struct intel_encoder *encoder;
>   struct intel_crtc *crtc;
>  
> - if (!intel_connector_needs_modeset(state, connector))
> + if (!intel_connector_needs_modeset(>base, connector))
>   continue;
>  
>   intel_connector = to_intel_connector(connector);
> @@ -1546,7 +1546,7 @@ static void intel_encoders_update_complete(struct 
> intel_atomic_state *state)
>   struct intel_encoder *encoder;
>   struct intel_crtc *crtc;
>  
> - if (!intel_connector_needs_modeset(state, connector))
> + if (!intel_connector_needs_modeset(>base, connector))
>   continue;
>  
>   intel_connector = to_intel_connector(connector);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..7c740463e9b6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5028,7 +5028,7 @@ static int intel_dp_connector_atomic_check(struct 
> drm_connector *conn,
>   if (DISPLAY_VER(dev_priv) < 9)
>   return 0;
>  
> - if (!intel_connector_needs_modeset(state, conn))
> + if (!intel_connector_needs_modeset(>base, conn))
>   return 0;
>  
>   if (conn->has_tile) {
> diff --git 

Re: [Intel-gfx] [v2] drm/i915/pps: improve eDP power on flow

[Lee, Shawn C]

On Tuesday, November 1, 2022 5:53 PM, Jani Nikula  
wrote:
>On Mon, 24 Oct 2022, Lee Shawn C  wrote:
>> A panel power off cycle delay always append before turn eDP on.
>> Driver should check last_power_on and last_backlight_off before insert 
>> this delay. If these values are the same, it means eDP was off until 
>> now and driver can bypass power off cycle delay to save some times to 
>> speed up eDP power on sequence.
>>
>> v2: fix commit messages
>
>There are more changes here than what the changelog says, but the previous 
>review comments were not answered [1].
>

I'm sorry that lose the question in [1]. 

"But someone else may have turned it off just before we were handed control, we 
have no idea."
This is the situation from Ville's comment. Agree that we don't know when panel 
will be powered off.
In my opinion, eDP panel should not be turned off before i915 take it over. If 
it was turned on or off by standard contorl (ex: modeset).
last_power_on and last_backlight_off would not be the same. So this change 
should be safe.

Best regards,
Shawn

>
>BR,
>Jani.
>
>
>[1] https://lore.kernel.org/r/y1afudawfvtac...@intel.com
>
>>
>> Cc: Shankar Uma 
>> Cc: Jani Nikula 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Lee Shawn C 
>> ---
>>  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 21944f5bf3a8..290473ec70d5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_pps.c
>> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
>> @@ -509,6 +509,13 @@ static void wait_panel_power_cycle(struct intel_dp 
>> *intel_dp)
>>  ktime_t panel_power_on_time;
>>  s64 panel_power_off_duration;
>>  
>> +/* When last_power_on equal to last_backlight_off, it means driver did 
>> not
>> + * turn on or off eDP panel so far. So we can bypass power cycle delay 
>> to
>> + * save some times here.
>> + */
>> +if (intel_dp->pps.last_power_on == intel_dp->pps.last_backlight_off)
>> +return;
>> +
>>  drm_dbg_kms(>drm, "Wait for panel power cycle\n");
>>  
>>  /* take the difference of current time and panel power off time @@ 
>> -1100,7 +1107,7 @@ static void pps_init_timestamps(struct intel_dp 
>> *intel_dp)  {
>>  intel_dp->pps.panel_power_off_time = ktime_get_boottime();
>>  intel_dp->pps.last_power_on = jiffies;
>> -intel_dp->pps.last_backlight_off = jiffies;
>> +intel_dp->pps.last_backlight_off = intel_dp->pps.last_power_on;
>>  }
>>  
>>  static void
>
>--
>Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Fix a build error used with clang compiler

[Jani Nikula]

On Mon, 31 Oct 2022, "Dixit, Ashutosh"  wrote:
> On Sun, 30 Oct 2022 23:37:59 -0700, Gwan-gyeong Mun wrote:
>>
>
> Hi GG,
>
>> On 10/31/22 7:19 AM, Dixit, Ashutosh wrote:
>> > On Fri, 28 Oct 2022 21:42:30 -0700, Gwan-gyeong Mun wrote:
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
>> >> b/drivers/gpu/drm/i915/i915_hwmon.c
>> >> index 9e9781493025..c588a17f97e9 100644
>> >> --- a/drivers/gpu/drm/i915/i915_hwmon.c
>> >> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
>> >> @@ -101,21 +101,16 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat, 
>> >> i915_reg_t rgadr,
>> >>
>> >>   static void
>> >>   hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
>> >> -   u32 field_msk, int nshift,
>> >> -   unsigned int scale_factor, long lval)
>> >> +   int nshift, unsigned int scale_factor, long lval)
>> >>   {
>> >>   u32 nval;
>> >> - u32 bits_to_clear;
>> >> - u32 bits_to_set;
>> >>
>> >>   /* Computation in 64-bits to avoid overflow. Round to nearest. */
>> >>   nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>> >>
>> >> - bits_to_clear = field_msk;
>> >> - bits_to_set = FIELD_PREP(field_msk, nval);
>> >> -
>> >>   hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>> >> - bits_to_clear, bits_to_set);
>> >> + PKG_PWR_LIM_1,
>> >> + REG_FIELD_PREP(PKG_PWR_LIM_1, 
>> >> nval));
>> >
>> > I registered my objection to this patch already here:
>> >
>> > https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.di...@intel.com/
>> >
>> > the crux of which is "hwm_field_scale_and_write() pairs with
>> > hwm_field_read_and_scale() (they are basically a set/get pair) so it is
>> > desirable they have identical arguments. This patch breaks that symmetry".
>> >
>> > We can merge this patch now but the moment a second caller of
>> > hwm_field_scale_and_write arrives this patch will need to be reverted.
>> >
>> > I have also posted my preferred way (as I previously indiecated) of fixing
>> > this issue here (if this needs to be fixed in i915):
>> >
>> > https://patchwork.freedesktop.org/series/110301/
>> >
>> The given link (https://patchwork.freedesktop.org/series/110301/) is an
>> inline function that reduces the checks of REG_FIELD_PREP() and pursues the
>> same functionality.
>> It's not a good idea to add and use duplicate new inline functions with
>> reduced functionality under different names.
>
> See if you like v2 better :-)
>
>> +/* FIELD_PREP and REG_FIELD_PREP require a compile time constant mask */
>> +static u32 hwm_field_prep(u32 mask, u32 val)
>> +{
>> +return (val << __bf_shf(mask)) & mask;
>> +}
>> +
>>  static void
>>  hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
>>  i915_reg_t reg, u32 clear, u32 set)
>> @@ -112,7 +118,7 @@  hwm_field_scale_and_write(struct hwm_drvdata *ddat,
>> i915_reg_t rgadr,
>>  nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>>
>>  bits_to_clear = field_msk;
>> -bits_to_set = FIELD_PREP(field_msk, nval);
>> +bits_to_set = hwm_field_prep(field_msk, nval);
>>
>>  hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
>>  bits_to_clear, bits_to_set);
>>
>>
>> The patch
>> (https://patchwork.freedesktop.org/patch/509248/?series=110094=5) that
>> fixed the build error in a simplified form was added as there is only one
>> place that calls the hwm_field_scale_and_write() function at this time.
>>
>> If more places that use the hwm_field_scale_and_write() function are added
>> in the future, how about changing the interface that calls this function as
>> Jani previously suggested?
>
> Sorry, which interface change which Jani suggested are you referring to? I
> don't recall seeing anything but maybe I am mistaken.

Maybe it was in another context, but this looks like the interfaces are
built a bit too much on the registers. There are chains of single-use
functions that scale and lock and read/write register fields. And it's
all based on the assumption that any given value maps to a single
bitfield in a single register and can be handled with a single read or
rmw, and it falls part otherwise.

I think the registers should be abstracted at the lowest level,
completely, not brought in top down as register addresses and masks. For
inspiration, maybe look at intel_backlight.c.

So here, you'd have hwm_read/hwm_write levels completely agnostic about
all the details, just muxing to different items.

The hwm_*_read/hwm_*_write would operate in a domain that handles all
generic i915 stuff, but still would not know anything about registers or
scaling. And then you'd have the lowest, platform specific level that
you'd call via platform specific function pointers. They would be passed
and return values in the right scale (maybe using common helpers).

You would *not* have or initialize 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11
URL   : https://patchwork.freedesktop.org/series/110353/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110353v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110353v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110353v1_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@drm_import_export@flink:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-tglb1/igt@drm_import_exp...@flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-tglb2/igt@drm_import_exp...@flink.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-skl6/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([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], [FAIL][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]) ([i915#4338])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb5/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb4/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-snb2/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-snb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-snb7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-snb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/shard-snb6/boot.html
   [34]: 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use intel_crtc_needs_modeset() more

[Jani Nikula]

On Mon, 31 Oct 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Prefer our own intel_crtc_needs_modeset() wrapper to
> drm_atomic_crtc_needs_modeset() whenever we are dealing
> with the intel_ types instead of drm_ types. Makes things
> a bit neater in general.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_color.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_fbc.c |  2 +-
>  drivers/gpu/drm/i915/display/skl_watermark.c |  2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 11 +--
>  6 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index eada931cb1c8..8a9031012d74 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2755,7 +2755,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state 
> *state)
>   if (IS_ERR(crtc_state))
>   return PTR_ERR(crtc_state);
>  
> - if (drm_atomic_crtc_needs_modeset(_state->uapi))
> + if (intel_crtc_needs_modeset(crtc_state))
>   pipe = INVALID_PIPE;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 4bb113c39f4b..1bd074431d89 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1240,7 +1240,7 @@ intel_color_add_affected_planes(struct intel_crtc_state 
> *new_crtc_state)
>   struct intel_plane *plane;
>  
>   if (!new_crtc_state->hw.active ||
> - drm_atomic_crtc_needs_modeset(_crtc_state->uapi))
> + intel_crtc_needs_modeset(new_crtc_state))
>   return 0;
>  
>   if (new_crtc_state->gamma_enable == old_crtc_state->gamma_enable &&
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b9393f9fc764..2d91c59a827d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5930,7 +5930,7 @@ int intel_modeset_all_pipes(struct intel_atomic_state 
> *state,
>   return PTR_ERR(crtc_state);
>  
>   if (!crtc_state->hw.active ||
> - drm_atomic_crtc_needs_modeset(_state->uapi))
> + intel_crtc_needs_modeset(crtc_state))
>   continue;
>  
>   drm_dbg_kms(_priv->drm, "[CRTC:%d:%s] Full modeset due to 
> %s\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 3f24f326b989..b5ee5ea0d010 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1183,7 +1183,7 @@ static bool intel_fbc_can_flip_nuke(struct 
> intel_atomic_state *state,
>   const struct drm_framebuffer *old_fb = old_plane_state->hw.fb;
>   const struct drm_framebuffer *new_fb = new_plane_state->hw.fb;
>  
> - if (drm_atomic_crtc_needs_modeset(_crtc_state->uapi))
> + if (intel_crtc_needs_modeset(new_crtc_state))
>   return false;
>  
>   if (!intel_fbc_is_ok(old_plane_state) ||
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index d58e667016e4..e0766d1be966 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -2744,7 +2744,7 @@ static int skl_wm_add_affected_planes(struct 
> intel_atomic_state *state,
>* power well the hardware state will go out of sync
>* with the software state.
>*/
> - if (!drm_atomic_crtc_needs_modeset(_crtc_state->uapi) &&
> + if (!intel_crtc_needs_modeset(new_crtc_state) &&
>   skl_plane_selected_wm_equals(plane,
>
> _crtc_state->wm.skl.optimal,
>
> _crtc_state->wm.skl.optimal))
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ee34e2785636..73c88b1c9545 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1426,7 +1426,7 @@ static int g4x_compute_intermediate_wm(struct 
> intel_atomic_state *state,
>   enum plane_id plane_id;
>  
>   if (!new_crtc_state->hw.active ||
> - drm_atomic_crtc_needs_modeset(_crtc_state->uapi)) {
> + intel_crtc_needs_modeset(new_crtc_state)) {
>   *intermediate = *optimal;
>  
>   intermediate->cxsr = false;
> @@ -1914,7 +1914,6 @@ static int vlv_compute_pipe_wm(struct 
> intel_atomic_state *state,
>  {
>   struct intel_crtc_state *crtc_state =
>   

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[Tvrtko Ursulin]

On 31/10/2022 18:30, John Harrison wrote:

On 10/31/2022 05:51, Tvrtko Ursulin wrote:

On 31/10/2022 10:09, Tvrtko Ursulin wrote:

On 28/10/2022 20:46, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

Update the worker to abort if a reset is in progress rather than
waiting for it to complete. It will still acquire the reset lock in
the case where a reset was not already in progress. So the processing
is still safe from corruption, but the deadlock can no longer occur.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 15 
++-

  drivers/gpu/drm/i915/gt/intel_reset.h |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 --
  3 files changed, 19 insertions(+), 3 deletions(-)

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

index 3159df6cdd492..2f48c6e4420ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,7 +1407,7 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
-int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_trylock(struct intel_gt *gt, int *srcu, 
bool retry)

  {
  might_lock(>reset.backoff_srcu);
  might_sleep();
@@ -1416,6 +1416,9 @@ int intel_gt_reset_trylock(struct intel_gt 
*gt, int *srcu)

  while (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
  rcu_read_unlock();
+    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
 >reset.flags)))


Would it be more obvious to rename the existing semantics to 
intel_gt_reset_interruptible(), while the flavour you add in this 
patch truly is trylock? I am not sure, since it's all a bit special, 
but trylock sure feels confusing if it can sleep forever...
To me, it would seem totally more obvious to have a function called 
'trylock' not wait forever until it can manage to acquire the lock. 
However, according to '2caffbf1176256 drm/i915: Revoke mmaps and prevent 
access to fence registers across reset', the current behaviour is 
exactly how the code was originally written and intended. It hasn't just 
mutated into some confused evolution a thousand patches later. So I 
figure there is some subtle but important reason why it was named how it 
is named and yet does what it does. Therefore it seemed safest to not 
change it unnecessarily.


Yeah I looked at that but honestly I don't see the trylock semantics 
anywhere. The only failure to lock path comes from 
wait_event_interruptible. It could have easily been just a naming mishap.


And I find adding a retry parameter to something called trylock makes 
this even more non-intuitive and would personally rather rename it all. 
Proof in the pudding is that the trylock naming did bite during 
development and review of the code this patch is now fixing.


I do however understand your point about a degree of uncertainty but my 
feeling is to rather err on the side of obvious naming. Shall we ask for 
a third opinion?


Oh and might_sleep() shouldn't be there with the trylock version - I 
mean any flavour of the real trylock.
You mean if the code is split into two completely separate functions? Or 
do you just mean to wrap the might_sleep() call with 'if(!retry)'?


And just to be totally clear, the unconditional call to rcu_read_lock() 
is not something that can sleep? One doesn't need a might_sleep() before 
doing that lock?


Corrrect, rcu_read_lock() can not sleep - it just disables preemption. 
So leaving the unconditional might_sleep() would have opportunity for 
false positives.


Regards,

Tvrtko

Re: [Intel-gfx] [v2] drm/i915/pps: improve eDP power on flow

[Jani Nikula]

On Mon, 24 Oct 2022, Lee Shawn C  wrote:
> A panel power off cycle delay always append before turn eDP on.
> Driver should check last_power_on and last_backlight_off before
> insert this delay. If these values are the same, it means eDP
> was off until now and driver can bypass power off cycle delay
> to save some times to speed up eDP power on sequence.
>
> v2: fix commit messages

There are more changes here than what the changelog says, but the
previous review comments were not answered [1].


BR,
Jani.


[1] https://lore.kernel.org/r/y1afudawfvtac...@intel.com

>
> Cc: Shankar Uma 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Lee Shawn C 
> ---
>  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 21944f5bf3a8..290473ec70d5 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -509,6 +509,13 @@ static void wait_panel_power_cycle(struct intel_dp 
> *intel_dp)
>   ktime_t panel_power_on_time;
>   s64 panel_power_off_duration;
>  
> + /* When last_power_on equal to last_backlight_off, it means driver did 
> not
> +  * turn on or off eDP panel so far. So we can bypass power cycle delay 
> to
> +  * save some times here.
> +  */
> + if (intel_dp->pps.last_power_on == intel_dp->pps.last_backlight_off)
> + return;
> +
>   drm_dbg_kms(>drm, "Wait for panel power cycle\n");
>  
>   /* take the difference of current time and panel power off time
> @@ -1100,7 +1107,7 @@ static void pps_init_timestamps(struct intel_dp 
> *intel_dp)
>  {
>   intel_dp->pps.panel_power_off_time = ktime_get_boottime();
>   intel_dp->pps.last_power_on = jiffies;
> - intel_dp->pps.last_backlight_off = jiffies;
> + intel_dp->pps.last_backlight_off = intel_dp->pps.last_power_on;
>  }
>  
>  static void

-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Stanislav Lisovskiy]

We might to use that function separately from intel_dp_dsc_compute_config
for DP DSC over MST case, because allocating bandwidth in that
case can be a bit more tricky. So in order to avoid code copy-pasta
lets extract this to separate function and reuse it for both SST
and MST cases.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 51 -
 drivers/gpu/drm/i915/display/intel_dp.h |  1 +
 2 files changed, 33 insertions(+), 19 deletions(-)

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

[Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

[Stanislav Lisovskiy]

Fix intel_dp_dsc_compute_config, previously timeslots parameter
was used in fact not as a timeslots, but more like a ratio
timeslots/64, which of course didn't have any effect for SST DSC,
but causes now issues for MST DSC.
Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp
only for SST DSC case, while for MST case it has been calculated
earlier already with intel_dp_dsc_mst_compute_link_config.
Third we also were wrongly determining sink min bpp/max bpp, those
limites should be intersected with our limits to find common
acceptable bpp's, plus on top of that we should align those with
VESA bpps and only then calculate required timeslots amount.
Some MST hubs started to work only after third change was made.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 52 ++---
 drivers/gpu/drm/i915/display/intel_dp.h |  3 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 65 +
 3 files changed, 88 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 71e08e665065..706fa4f7ea62 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -717,9 +717,14 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
*i915,
 * for SST -> TimeSlotsPerMTP is 1,
 * for MST -> TimeSlotsPerMTP has to be calculated
 */
-   bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
-intel_dp_mode_to_fec_clock(mode_clock);
-   drm_dbg_kms(>drm, "Max link bpp: %u\n", bits_per_pixel);
+   bits_per_pixel = DIV_ROUND_UP((link_clock * lane_count) * timeslots,
+ intel_dp_mode_to_fec_clock(mode_clock) * 
8);
+
+   drm_dbg_kms(>drm, "Max link bpp is %u for %u timeslots "
+   "total bw %u pixel clock %u\n",
+   bits_per_pixel, timeslots,
+   (link_clock * lane_count * 8),
+   intel_dp_mode_to_fec_clock(mode_clock));
 
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
@@ -1048,7 +1053,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
target_clock,
mode->hdisplay,
bigjoiner,
-   pipe_bpp, 1) >> 4;
+   pipe_bpp, 64) >> 4;
dsc_slice_count =
intel_dp_dsc_get_slice_count(intel_dp,
 target_clock,
@@ -1482,7 +1487,8 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
struct link_config_limits *limits,
-   int timeslots)
+   int timeslots,
+   bool compute_pipe_bpp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
@@ -1497,7 +1503,10 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
-   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
+   if (compute_pipe_bpp)
+   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
+   else
+   pipe_bpp = pipe_config->pipe_bpp;
 
if (intel_dp->force_dsc_bpc) {
pipe_bpp = intel_dp->force_dsc_bpc * 3;
@@ -1531,28 +1540,31 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
u16 dsc_max_output_bpp;
u8 dsc_dp_slice_count;
 
-   dsc_max_output_bpp =
-   intel_dp_dsc_get_output_bpp(dev_priv,
-   pipe_config->port_clock,
-   pipe_config->lane_count,
-   adjusted_mode->crtc_clock,
-   
adjusted_mode->crtc_hdisplay,
-   
pipe_config->bigjoiner_pipes,
-   pipe_bpp,
-   timeslots);
+   if (compute_pipe_bpp) {
+   dsc_max_output_bpp =
+   

[Intel-gfx] [PATCH 4/6] drm/i915: Add DSC support to MST path

[Stanislav Lisovskiy]

Whenever we are not able to get enough timeslots
for required PBN, let's try to allocate those
using DSC, just same way as we do for SST.

v2: Removed intel_dp_mst_dsc_compute_config and refactored
intel_dp_dsc_compute_config to support timeslots as a
parameter(Ville Syrjälä)

v3: - Rebased
- Added a debug to see that we at least try reserving
  VCPI slots using DSC, because currently its not visible
  from the logs, thus making debugging more tricky.
- Moved timeslots to numerator, where it should be.

v4: - Call drm_dp_mst_atomic_check already during link
  config computation, because we need to know already
  by this moment if uncompressed amount of VCPI slots
  needed can fit, otherwise we need to use DSC.
  (thanks to Vinod Govindapillai for pointing this out)

v5: - Put pipe_config->bigjoiner_pipes back to original
  condition in intel_dp_dsc_compute_config
  (don't remember when I lost it)

v6: - Removed unnecessary drm_dp_mst_atomic_check as it is
  now always called in a newly introduced
  intel_dp_mst_find_vcpi_slots_for_bpp function
  (Vinod Govindapillai)

Reviewed-by: Vinod Govindapillai 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp.c |  57 +
 drivers/gpu/drm/i915/display/intel_dp.h |  17 +++
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 125 
 3 files changed, 173 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 70b06806ec0d..70f4d6422795 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
 }
 
 static void intel_dp_unset_edid(struct intel_dp *intel_dp);
-static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc);
 
 /* Is link rate UHBR and thus 128b/132b? */
 bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
@@ -672,11 +671,12 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
return 6144 * 8;
 }
 
-static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
-  u32 link_clock, u32 lane_count,
-  u32 mode_clock, u32 mode_hdisplay,
-  bool bigjoiner,
-  u32 pipe_bpp)
+u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
+   u32 link_clock, u32 lane_count,
+   u32 mode_clock, u32 mode_hdisplay,
+   bool bigjoiner,
+   u32 pipe_bpp,
+   u32 timeslots)
 {
u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
@@ -687,8 +687,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct 
drm_i915_private *i915,
 * for SST -> TimeSlotsPerMTP is 1,
 * for MST -> TimeSlotsPerMTP has to be calculated
 */
-   bits_per_pixel = (link_clock * lane_count * 8) /
+   bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
 intel_dp_mode_to_fec_clock(mode_clock);
+   drm_dbg_kms(>drm, "Max link bpp: %u\n", bits_per_pixel);
 
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
@@ -737,9 +738,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct 
drm_i915_private *i915,
return bits_per_pixel << 4;
 }
 
-static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
-  int mode_clock, int mode_hdisplay,
-  bool bigjoiner)
+u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
+   int mode_clock, int mode_hdisplay,
+   bool bigjoiner)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 min_slice_count, i;
@@ -946,8 +947,8 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
return MODE_OK;
 }
 
-static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
-   int hdisplay, int clock)
+bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
+int hdisplay, int clock)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
@@ -1034,7 +1035,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
target_clock,
mode->hdisplay,
bigjoiner,
-   pipe_bpp) >> 4;
+   pipe_bpp, 1) >> 4;
dsc_slice_count =
 

[Intel-gfx] [PATCH 3/6] drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function

[Stanislav Lisovskiy]

We would be using almost same code to loop through bpps while calling
drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp

v2: Fix pbn_div calculation - shouldn't matter if its DSC or not.
v3: FIx rebase conflict, constant_n no longer needed.

Reviewed-by: Vinod Govindapillai 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 48 +++--
 1 file changed, 36 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 421bbcaed664..bdbb599cd48b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -44,10 +44,14 @@
 #include "intel_hotplug.h"
 #include "skl_scaler.h"
 
-static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
-   struct intel_crtc_state *crtc_state,
-   struct drm_connector_state 
*conn_state,
-   struct link_config_limits *limits)
+static int intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder *encoder,
+   struct intel_crtc_state 
*crtc_state,
+   int max_bpp,
+   int min_bpp,
+   struct link_config_limits 
*limits,
+   struct drm_connector_state 
*conn_state,
+   int step,
+   bool dsc)
 {
struct drm_atomic_state *state = crtc_state->uapi.state;
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
@@ -71,18 +75,20 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
// TODO: Handle pbn_div changes by adding a new MST helper
if (!mst_state->pbn_div) {
mst_state->pbn_div = 
drm_dp_get_vc_payload_bw(_dp->mst_mgr,
- limits->max_rate,
- 
limits->max_lane_count);
+ 
crtc_state->port_clock,
+ 
crtc_state->lane_count);
}
 
-   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+   for (bpp = max_bpp; bpp >= min_bpp; bpp -= step) {
crtc_state->pipe_bpp = bpp;
 
crtc_state->pbn = 
drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
-  crtc_state->pipe_bpp,
-  false);
+  dsc ? bpp << 4 : 
crtc_state->pipe_bpp,
+  dsc);
+
slots = drm_dp_atomic_find_time_slots(state, _dp->mst_mgr,
- connector->port, 
crtc_state->pbn);
+ connector->port,
+ crtc_state->pbn);
if (slots == -EDEADLK)
return slots;
if (slots >= 0) {
@@ -100,11 +106,29 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
if (ret && slots >= 0)
slots = ret;
 
-   if (slots < 0) {
+   if (slots < 0)
drm_dbg_kms(>drm, "failed finding vcpi slots:%d\n",
slots);
+
+   return slots;
+}
+
+
+static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
+   struct intel_crtc_state *crtc_state,
+   struct drm_connector_state 
*conn_state,
+   struct link_config_limits *limits)
+{
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+   int slots = -EINVAL;
+
+   slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state, 
limits->max_bpp,
+limits->min_bpp, limits,
+conn_state, 2 * 3, false);
+
+   if (slots < 0)
return slots;
-   }
 
intel_link_compute_m_n(crtc_state->pipe_bpp,
   crtc_state->lane_count,
-- 
2.37.3

[Intel-gfx] [PATCH 2/6] drm/i915: Fix intel_dp_mst_compute_link_config

[Stanislav Lisovskiy]

We currently always exit that bpp loop because
drm_dp_atomic_find_vcpi_slots doesn't care if we actually
can fit those or not.
I think that wasn't the initial intention here, especially when
we keep trying with lower bpps, we are supposed to keep trying
until we actually find some _working_ configuration, which isn't the
case here.
So added that drm_dp_mst_check here, so that we can make sure
that try all the bpps before we fail.

Reviewed-by: Vinod Govindapillai 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cd4e61026d98..421bbcaed664 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -59,6 +59,7 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
int bpp, slots = -EINVAL;
+   int ret = 0;
 
mst_state = drm_atomic_get_mst_topology_state(state, 
_dp->mst_mgr);
if (IS_ERR(mst_state))
@@ -84,10 +85,21 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
  connector->port, 
crtc_state->pbn);
if (slots == -EDEADLK)
return slots;
-   if (slots >= 0)
-   break;
+   if (slots >= 0) {
+   ret = drm_dp_mst_atomic_check(state);
+   /*
+* If we got slots >= 0 and we can fit those based on 
check
+* then we can exit the loop. Otherwise keep trying.
+*/
+   if (!ret)
+   break;
+   }
}
 
+   /* Despite slots are non-zero, we still failed the atomic check */
+   if (ret && slots >= 0)
+   slots = ret;
+
if (slots < 0) {
drm_dbg_kms(>drm, "failed finding vcpi slots:%d\n",
slots);
-- 
2.37.3

[Intel-gfx] [PATCH 0/6] Add DP MST DSC support to i915

[Stanislav Lisovskiy]

Currently we have only DSC support for DP SST.

Stanislav Lisovskiy (6):
  drm: Add missing DP DSC extended capability definitions.
  drm/i915: Fix intel_dp_mst_compute_link_config
  drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate
function
  drm/i915: Add DSC support to MST path
  drm/i915: Extract VESA DSC bpp alignment to separate function
  drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

 drivers/gpu/drm/i915/display/intel_dp.c | 142 +++-
 drivers/gpu/drm/i915/display/intel_dp.h |  19 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 236 ++--
 include/drm/display/drm_dp.h|   9 +-
 4 files changed, 333 insertions(+), 73 deletions(-)

-- 
2.37.3

[Intel-gfx] [PATCH 1/6] drm: Add missing DP DSC extended capability definitions.

[Stanislav Lisovskiy]

Adding DP DSC register definitions, we might need for further
DSC implementation, supporting MST and DP branch pass-through mode.

v2: - Fixed checkpatch comment warning
v3: - Removed function which is not yet used(Jani Nikula)

Reviewed-by: Vinod Govindapillai 

Signed-off-by: Stanislav Lisovskiy 
---
 include/drm/display/drm_dp.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index e934aab357be..9bc22a02874d 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -240,6 +240,8 @@
 #define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
 # define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
 # define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
+# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2)
+# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP  (1 << 3)
 
 #define DP_DSC_REV  0x061
 # define DP_DSC_MAJOR_MASK  (0xf << 0)
@@ -278,12 +280,15 @@
 
 #define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
 # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
+# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1)
 
 #define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
 
 #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
 # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
 # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8
+# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  0x06
+# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  0x08
 
 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
 # define DP_DSC_RGB (1 << 0)
@@ -345,11 +350,13 @@
 # define DP_DSC_24_PER_DP_DSC_SINK  (1 << 2)
 
 #define DP_DSC_BITS_PER_PIXEL_INC   0x06F
+# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f
+# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0
 # define DP_DSC_BITS_PER_PIXEL_1_16 0x0
 # define DP_DSC_BITS_PER_PIXEL_1_8  0x1
 # define DP_DSC_BITS_PER_PIXEL_1_4  0x2
 # define DP_DSC_BITS_PER_PIXEL_1_2  0x3
-# define DP_DSC_BITS_PER_PIXEL_10x4
+# define DP_DSC_BITS_PER_PIXEL_1_1  0x4
 
 #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
 # define DP_PSR_IS_SUPPORTED1
-- 
2.37.3

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: use surface size for bios fb size check (rev2)

[Patchwork]

== Series Details ==

Series: i915: use surface size for bios fb size check (rev2)
URL   : https://patchwork.freedesktop.org/series/109114/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_109114v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 28)
--

  Additional (1): fi-tgl-mst 
  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 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_109114v2:

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-mst}:   NOTRUN -> [WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/fi-tgl-mst/igt@i915_pm_...@module-reload.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  
 Possible fixes 

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [FAIL][5] ([i915#6298]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109114v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.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#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
  [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6596]: https://gitlab.freedesktop.org/drm/intel/issues/6596
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_109114v2

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109114v2: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

d1bf90e8dc69 i915: use surface size for bios fb size check

== Logs ==

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

Re: [Intel-gfx] [PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd

[Nicolin Chen]

On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:

> > From: Jason Gunthorpe 
> > Sent: Wednesday, October 26, 2022 2:51 AM
> >
> >  menuconfig VFIO
> >   tristate "VFIO Non-Privileged userspace driver framework"
> >   select IOMMU_API
> > + depends on IOMMUFD || !IOMMUFD
> 
> Out of curiosity. What is the meaning of this dependency claim?

"is it a module or not" -- from https://lwn.net/Articles/683476/

Re: [Intel-gfx] [PATCH v1 7/7] vfio: Remove vfio_free_device

[Tian, Kevin]

> From: Eric Farman 
> Sent: Thursday, October 20, 2022 12:22 AM
> 
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
> 
> Signed-off-by: Eric Farman 

Reviewed-by: Kevin Tian 

Re: [Intel-gfx] [PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_

[Tian, Kevin]

> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
> 
> Now that we have a reasonable separation of structs that follow
> the subchannel and mdev lifecycles, there's no reason we can't
> call the official vfio_alloc_device routine for our private data,
> and behave like everyone else.
> 
> Signed-off-by: Eric Farman 

This looks good to me. With Jason's suggestion handled,

Reviewed-by: Kevin Tian 

Re: [Intel-gfx] [PATCH v1 5/7] vfio/ccw: remove release completion

[Tian, Kevin]

> From: Eric Farman 
> Sent: Thursday, October 20, 2022 12:22 AM
> 
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
> 
> Signed-off-by: Eric Farman 

Reviewed-by: Kevin Tian 

Re: [Intel-gfx] [PATCH v1 4/7] vfio/ccw: move private to mdev lifecycle

[Tian, Kevin]

> From: Eric Farman 
> Sent: Thursday, October 20, 2022 12:22 AM
> 
> @@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct
> mdev_device *mdev)
>  {
>   struct subchannel *sch = to_subchannel(mdev->dev.parent);
>   struct vfio_ccw_parent *parent = dev_get_drvdata(>dev);
> - struct vfio_ccw_private *private = dev_get_drvdata(>dev);
> + struct vfio_ccw_private *private;
>   int ret;
> 
> - if (private->state == VFIO_CCW_STATE_NOT_OPER)
> - return -ENODEV;

Not familiar with ccw but just want to double confirm this removal
is intentional w/o side-effect?

> + private = vfio_ccw_alloc_private(sch);
> + if (!private)
> + return -ENOMEM;
> 
>   ret = vfio_init_device(>vdev, >dev,
> _ccw_dev_ops);
> - if (ret)
> + if (ret) {
> + kfree(private);
>   return ret;
> + }
> +
> + dev_set_drvdata(>dev, private);
> 
>   VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
>  sch->schid.cssid,
> @@ -123,6 +128,7 @@ static int vfio_ccw_mdev_probe(struct mdev_device
> *mdev)
>   return 0;
> 
>  err_put_vdev:
> + dev_set_drvdata(>dev, NULL);

No need to set drvdata to NULL, iiuc

[Intel-gfx] ✗ Fi.CI.DOCS: warning for i915: use surface size for bios fb size check (rev2)

[Patchwork]

== Series Details ==

Series: i915: use surface size for bios fb size check (rev2)
URL   : https://patchwork.freedesktop.org/series/109114/
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'

Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation

[Ville Syrjälä]

On Mon, Oct 31, 2022 at 08:20:54PM -0400, Jason Baron wrote:
> 
> 
> On 10/31/22 6:11 PM, jim.cro...@gmail.com wrote:
> > On Mon, Oct 31, 2022 at 7:07 AM Ville Syrjälä
> >  wrote:
> >> On Sun, Oct 30, 2022 at 08:42:52AM -0600, jim.cro...@gmail.com wrote:
> >>> On Thu, Oct 27, 2022 at 2:10 PM Ville Syrjälä
> >>>  wrote:
>  On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> > On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> >  wrote:
> >> On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> >>> On Thu, Oct 27, 2022 at 9:08 AM Jason Baron  wrote:
> 
> 
>  On 10/21/22 05:18, Jani Nikula wrote:
> > On Thu, 20 Oct 2022, Ville Syrjälä  
> > wrote:
> >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
>  hi Greg, Dan, Jason, DRM-folk,
> 
>  heres follow-up to V6:
> rebased on driver-core/driver-core-next for -v6 applied bits 
>  (thanks)
> rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> 
>  It excludes:
> nouveau parts (immature)
> tracefs parts (I missed --to=Steve on v6)
> split _ddebug_site and de-duplicate experiment (way unready)
> 
>  IOW, its the remaining commits of V6 on which Dan gave his 
>  Reviewed-by.
> 
>  If these are good to apply, I'll rebase and repost the rest 
>  separately.
> >>> All now queued up, thanks.
> >> This stuff broke i915 debugs. When I first load i915 no debug 
> >> prints are
> >> produced. If I then go fiddle around in 
> >> /sys/module/drm/parameters/debug
> >> the debug prints start to suddenly work.
> > Wait what? I always assumed the default behaviour would stay the 
> > same,
> > which is usually how we roll. It's a regression in my books. We've 
> > got a
> > CI farm that's not very helpful in terms of dmesg logging right now
> > because of this.
> >
> > BR,
> > Jani.
> >
> >
>  That doesn't sound good - so you are saying that prior to this 
>  change some
>  of the drm debugs were default enabled. But now you have to manually 
>  enable
>  them?
> 
>  Thanks,
> 
>  -Jason
> >>>
> >>> Im just seeing this now.
> >>> Any new details ?
> >> No. We just disabled it as BROKEN for now. I was just today thinking
> >> about sending that patch out if no solutin is forthcoming soon since
> >> we need this working before 6.1 is released.
> >>
> >> Pretty sure you should see the problem immediately with any driver
> >> (at least if it's built as a module, didn't try builtin). Or at least
> >> can't think what would make i915 any more special.
> >>
> > So, I should note -
> > 99% of my time & energy on this dyndbg + drm patchset
> > has been done using virtme,
> > so my world-view (and dev-hack-test env) has been smaller, simpler
> > maybe its been fatally simplistic.
> >
> > ive just rebuilt v6.0  (before the trouble)
> > and run it thru my virtual home box,
> > I didnt see any unfamiliar drm-debug output
> > that I might have inadvertently altered somehow
> >
> > I have some real HW I can put a reference kernel on,0
> > to look for the missing output, but its all gonna take some time,
> > esp to tighten up my dev-test-env
> >
> > in the meantime, there is:
> >
> > config DRM_USE_DYNAMIC_DEBUG
> > bool "use dynamic debug to implement drm.debug"
> > default y
> > depends on DRM
> > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> > depends on JUMP_LABEL
> > help
> >Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
> >Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
> >bytes per callsite, the .data costs can be substantial, and
> >are therefore configurable.
> >
> > Does changing the default fix things for i915 dmesg ?
>  I think we want to mark it BROKEN in addition to make sure no one
> >>> Ok, I get the distinction now.
> >>> youre spelling that
> >>>depends on BROKEN
> >>>
> >>> I have a notional explanation, and a conflating commit:
> >>>
> >>> can you eliminate
> >>> git log -p ccc2b496324c13e917ef05f563626f4e7826bef1
> >>>
> >>> as the cause ?
> >> Reverting that doesn't help.
> >>
> > thanks for eliminating it.
> >
> >>> I do need to clarify, I dont know exactly what debug/logging output
> >>> is missing such that CI is failing
> >> CI isn't failing. But any logs it produces are 100% useless,
> >> as are any user reported logs.
> >>
> >> The debugs 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11
URL   : https://patchwork.freedesktop.org/series/110353/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12325 -> Patchwork_110353v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 27)
--

  Missing(13): fi-cml-u2 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 
bat-adlp-6 bat-adlp-4 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_110353v1 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_12325/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110353v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  
 Possible fixes 

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

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

  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12325 -> Patchwork_110353v1

  CI-20190529: 20190529
  CI_DRM_12325: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7032: 372c56225e12578a7a4a6bcc5b79eb40b643fcde @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110353v1: 1a90222aa5e5bb86ffcbde5ba9611659a23f0df6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f8de86345655 drm/i915/dsc: Source supports DSC from DISPLAY_VER >= 11

== Logs ==

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

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

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Wednesday, October 26, 2022 2:51 AM
> 
>  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
> +   mappings. If N is selected here then IOMMUFD must be used the

establishing IOMMU mappings.

s/used the manage/used to manage/

> manage
> +   the mappings.
> +
> +   Unless testing IOMMUFD say Y here.
> +
> +if VFIO_CONTAINER
>  config VFIO_IOMMU_TYPE1
>   tristate
> - default n
> + default MMU && (X86 || S390 || ARM || ARM64)

there are already same conditions for selecting TYPE1 from
VFIO_CONTAINER. what does duplicating conditions here
bring to us?

Re: [Intel-gfx] [PATCH 08/10] vfio-iommufd: Support iommufd for emulated VFIO devices

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Wednesday, October 26, 2022 2:51 AM
> 
> Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> consist of all the mdev drivers.
> 
> Like the physical drivers, support for iommufd is provided by the driver
> supplying the correct correct standard ops. Provide ops from the core that
> duplicate what vfio_register_emulated_iommu_dev() does.
> 
> Emulated drivers are where it is more likely to see variation in the
> iommfd support ops. For instance IDXD will probably need to setup both a
> iommfd_device context linked to a PASID and an iommufd_access context to
> support all their mdev operations.
> 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c  |   3 +
>  drivers/s390/cio/vfio_ccw_ops.c   |   3 +
>  drivers/s390/crypto/vfio_ap_ops.c |   3 +
>  drivers/vfio/container.c  | 108 ++---
>  drivers/vfio/iommufd.c|  57 
>  drivers/vfio/vfio.h   |  10 ++-
>  drivers/vfio/vfio_main.c  | 110 +-
>  include/linux/vfio.h  |  14 
>  8 files changed, 217 insertions(+), 91 deletions(-)

mtty, mdpy and mbochs?

> diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
> index 8772dad6808539..0388f2e33447eb 100644
> --- a/drivers/vfio/container.c
> +++ b/drivers/vfio/container.c
> @@ -540,113 +540,45 @@ void vfio_group_unuse_container(struct
> vfio_group *group)
>   fput(group->opened_file);
>  }
> 
> -/*
> - * Pin contiguous user pages and return their associated host pages for local
> - * domain only.
> - * @device [in]  : device
> - * @iova [in]: starting IOVA of user pages to be pinned.
> - * @npage [in]   : count of pages to be pinned.  This count should not
> - *  be greater than VFIO_PIN_PAGES_MAX_ENTRIES.
> - * @prot [in]: protection flags
> - * @pages[out]   : array of host pages
> - * Return error or number of pages pinned.
> - *
> - * A driver may only call this function if the vfio_device was created
> - * by vfio_register_emulated_iommu_dev().
> - */
> -int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
> -int npage, int prot, struct page **pages)
> +int vfio_container_pin_pages(struct vfio_container *container,
> +  struct iommu_group *iommu_group, dma_addr_t
> iova,
> +  int npage, int prot, struct page **pages)
>  {
> - struct vfio_container *container;
> - struct vfio_group *group = device->group;
> - struct vfio_iommu_driver *driver;
> - int ret;
> -
> - if (!pages || !npage || !vfio_assert_device_open(device))
> - return -EINVAL;
> + /* group->container cannot change while a vfio device is open */
> + struct vfio_iommu_driver *driver = container->iommu_driver;
> 
>   if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
>   return -E2BIG;
> 
>   /* group->container cannot change while a vfio device is open */
> - container = group->container;
>   driver = container->iommu_driver;

duplicated comment and assignment.

Actually, I'm not sure whether the comment should be put within this
container helper and other two. There is no group reference in these
helpers then it sounds like the comment makes more sense to be in the
caller side?

> +void vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova, int
> npage)
> +{
> + if (WARN_ON(!vfio_assert_device_open(device)))
> + return;
> +
> + if (device->group->container) {
> + vfio_container_unpin_pages(device->group->container, iova,
> +npage);
> + } else if (device->iommufd_access) {

be consistent with other two helpers i.e. if-if instead of if-else

> + if (WARN_ON(iova > ULONG_MAX))
> + return;

Is there a reason why this is a WARN_ON only in unpin but not in pin?

> +int vfio_dma_rw(struct vfio_device *device, dma_addr_t iova, void *data,
> + size_t len, bool write)
> +{
> + if (!data || len <= 0 || !vfio_assert_device_open(device))
> + return -EINVAL;
> +
> + if (device->group->container)
> + return vfio_container_dma_rw(device->group->container,
> iova,
> +  data, len, write);
> +
> + if (device->iommufd_access) {
> + unsigned int flags = 0;
> +
> + if (iova > ULONG_MAX)
> + return -EINVAL;
> +
> + /* VFIO historically tries to auto-detect a kthread */
> + if (!current->mm)
> + flags |= IOMMUFD_ACCESS_RW_KTHREAD;

Can you elaborate why this cannot be put in iommufd as the default
policy similar to what vfio container does?

[Intel-gfx] [PATCH v2] i915: use surface size for bios fb size check

[Timo Teräs]

Lenovo laptop BIOS (possibly other vendors too) provide a framebuffer with
the size of the primary display. The BIOS selects the primary display to
be the internal display (lid open) or external display (lid closed).

Thus, if the external display supports higher resolution than the internal
one, and the lid is open during boot, the BIOS frame buffer size is not
large enough for the preferred resolution of the external display.

This causes the framebuffer to select non-preferred mode for the external
display. And this causes resolution change (and screen flicker) when
switching between framebuffer mode and drm mode (X11/Plymouth).

The fix is to make sure that the frame buffer is large enough to hold
data for the maximum surface size.

Signed-off-by: Timo Teräs 
---
v2: reword commit message, add signed-off-by

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

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 112aa0447a0d..287b58a732e0 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -217,13 +217,13 @@ static int intelfb_create(struct drm_fb_helper *helper,
return ret;
 
if (intel_fb &&
-   (sizes->fb_width > intel_fb->base.width ||
-sizes->fb_height > intel_fb->base.height)) {
+   (sizes->surface_width > intel_fb->base.width ||
+sizes->surface_height > intel_fb->base.height)) {
drm_dbg_kms(_priv->drm,
"BIOS fb too small (%dx%d), we require (%dx%d),"
" releasing it\n",
intel_fb->base.width, intel_fb->base.height,
-   sizes->fb_width, sizes->fb_height);
+   sizes->surface_width, sizes->surface_height);
drm_framebuffer_put(_fb->base);
intel_fb = ifbdev->fb = NULL;
}
-- 
2.38.1

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

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Wednesday, October 26, 2022 2:51 AM
> 
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(>dev_set->lock);
> +
> + /*
> +  * If the driver doesn't provide this op then it means the device does
> +  * not do DMA at all. So nothing to do.
> +  */
> + if (!vdev->ops->bind_iommufd)
> + return 0;

Nothing to do or return -EOPNOTSUPP?

> +
> + ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
> + if (ret)
> + return ret;
> +
> + if (vdev->ops->attach_ioas) {

__vfio_register_dev() already verifies that all three callbacks must
co-exist. Then no need to check it again here and later.

> +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...

Re: [Intel-gfx] [PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Wednesday, October 26, 2022 2:51 AM
>
>  menuconfig VFIO
>   tristate "VFIO Non-Privileged userspace driver framework"
>   select IOMMU_API
> + depends on IOMMUFD || !IOMMUFD

Out of curiosity. What is the meaning of this dependency claim?

> @@ -717,12 +735,23 @@ static int vfio_group_ioctl_set_container(struct
> vfio_group *group,
>   }
> 
>   container = vfio_container_from_file(f.file);
> - ret = -EINVAL;

this changes the errno from -EINVAL to -EBADF for the original container
path. Is it desired?

>   if (container) {
>   ret = vfio_container_attach_group(container, group);
>   goto out_unlock;
>   }
> 
> + iommufd = iommufd_ctx_from_file(f.file);
> + if (!IS_ERR(iommufd)) {

The only errno which iommufd_ctx_from_file() may return is -EBADFD
which duplicates with -EBADF assignment in following line.

What about having it return NULL pointer similar as the container
helper does?

> + u32 ioas_id;
> +
> + group->iommufd = iommufd;
> + ret = iommufd_vfio_compat_ioas_id(iommufd, _id);

exchange the order of above two lines and only assign group->iommufd
when the compat call succeeds.

> @@ -900,7 +940,7 @@ static int vfio_group_ioctl_get_status(struct
> vfio_group *group,
>   return -ENODEV;
>   }
> 
> - if (group->container)
> + if (group->container || group->iommufd)
>   status.flags |= VFIO_GROUP_FLAGS_CONTAINER_SET |
>   VFIO_GROUP_FLAGS_VIABLE;

Copy some explanation from commit msg to explain the subtle difference
between container and iommufd.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Introduce Wa_18017747507 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Introduce Wa_18017747507 (rev2)
URL   : https://patchwork.freedesktop.org/series/110323/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12325_full -> Patchwork_110323v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110323v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110323v2_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 -> 9)
--

  Missing(2): shard-rkl shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * 
igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-default-mode:
- shard-iclb: NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-iclb3/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscal...@pipe-a-default-mode.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-skl:  ([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], [FAIL][44]) ([i915#5032])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12325/shard-skl10/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl3/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl10/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl10/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl9/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110323v2/shard-skl7/boot.html
   [36]: