date:20220408

Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

2022-04-08 Thread Abhinav Kumar





On 4/7/2022 4:12 PM, Rob Clark wrote:

On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar  wrote:


Hi Rob and Daniel

On 4/7/2022 3:51 PM, Rob Clark wrote:

On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang  wrote:




On 3/31/2022 8:20 AM, Daniel Vetter wrote:

The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.

For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.

For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.

Inspired by an amdgpu bug report.

v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in

commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas 
Date:   Wed Dec 5 14:59:07 2018 -0500

   drm/amd/display: Add fast path for cursor plane updates

we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.

v3: Paper over msm and i915 regression. The complete_all is the only
thing missing afaict.

v4: Fixup i915 fixup ...

References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
References: 
https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Cc: Maxime Ripard 
Tested-by: Maxime Ripard 
Cc: mikita.lip...@amd.com
Cc: Michel Dänzer 
Cc: harry.wentl...@amd.com
Cc: Rob Clark 


Hey Rob,

I saw your tested-by and reviewed-by tags on Patchwork. Just curious,
what device did you test on?


I was testing on strongbad.. v5.18-rc1 + patches (notably, revert
80253168dbfd ("drm: of: Lookup if child node has panel or bridge")

I think the display setup shouldn't be significantly different than
limozeen (ie. it's an eDP panel).  But I didn't do much start/stop
ui.. I was mostly looking to make sure cursor movements weren't
causing fps drops ;-)

BR,
-R


start ui/ stop ui is a basic operation for us to use IGT on msm-next.
So we cannot let that break.

I think we need to check whats causing this splat.

Can we hold back this change till then?


Can you reproduce on v5.18-rc1 (plus 80253168dbfd)?  I'm running a
loop of stop ui / start ui and hasn't triggered a splat yet.

  Otherwise maybe you can addr2line to figure out where it crashed?

BR,
-R


So this is not a crash. Its a warning splat coming from

https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785

Looks like the complete_commit() which should signal the event has not 
happened before the next cursor commit.


Somehow this change is affecting the flow to miss the event signaling 
that the event is done.


We tried a couple of approaches but couldnt still fix the warning.

Will continue to check further next week.




Thanks

Abhinav



I'm hitting several instances of this error when doing a start/stop ui
on Lazor Chromebook with this patch:

[ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: GW
5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155
e5912cd286513b064a82a38938b3fdef86b079aa
[ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen
(rev4) (DT)
[ 3092.630492] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144
[ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144
[ 3092.647379] sp : ffc00c1e3760
[ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27:
0425
[ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24:
ffdf8ae3b6f0
[ 3092.665522] x23:  x22:  x21:
ff809b82da00
[ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18:
1000
[ 3092.680255] x17: 0400 x16: 0100 x15:
003b
[ 3092.687622] x14:  x13: 0002 x12:
0003
[ 3092.694979] x11: ff8084009000 x10: 0040 x9 :
0040
[ 3092.702340] x8 : 0300 x7 : 000c x6 :
0004
[ 3092.709698] x5 : 0320 x4 : 0018 x3 :

[ 3092.717056] x2 :  x1 : 7bfb38b2a3a89800 x0 :
ff809a1eb300
[ 3092.724424] Call trace:
[ 3092.726958]  dpu_crtc_atomic_flush+0x9c/0x144
[ 3092.731463]  drm_atomic_helper_commit_planes+0x1bc/0x1c4
[ 3092.736944]  msm_atomic_commit_tail+0x23c/0x3e0
[ 3092.741627]  commit_tail+0x7c/0xfc
[ 3092.745145]  drm_atomic_helper_commit+0x158/0x15c
[ 3092.749998]

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address (rev2)
URL   : https://patchwork.freedesktop.org/series/102428/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11479_full -> Patchwork_22833_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@sysfs-reader:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/shard-skl1/igt@i915_susp...@sysfs-reader.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/shard-skl6/igt@i915_susp...@sysfs-reader.html

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/shard-iclb6/igt@kms_fbcon_...@fbc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/shard-iclb8/igt@kms_fbcon_...@fbc.html

  
 Warnings 

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [DMESG-WARN][5] ([i915#5566]) -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/shard-skl4/igt@gen9_exec_pa...@allowed-single.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/shard-skl10/igt@gen9_exec_pa...@allowed-single.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Update to GuC v70

2022-04-08 Thread Patchwork

== Series Details ==

Series: Update to GuC v70
URL   : https://patchwork.freedesktop.org/series/102430/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11479_full -> Patchwork_22832_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address (rev2)
URL   : https://patchwork.freedesktop.org/series/102428/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11479 -> Patchwork_22833


Summary
---

  **WARNING**

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

Participating hosts (48 -> 45)
--

  Additional (2): bat-rpls-1 fi-kbl-8809g 
  Missing(5): shard-tglu fi-tgl-u2 fi-bsw-cyan fi-pnv-d510 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-7567u:   [DMESG-WARN][1] ([i915#5437]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][3] ([i915#5557])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-kbl-8809g/igt@fb...@eof.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-11600:   [PASS][6] -> [INCOMPLETE][7] ([i915#5127])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][14] ([i915#2867]) -> [PASS][15] +17 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-soraka:  [FAIL][16] ([i915#4312] / [i915#5257]) -> [FAIL][17] 
([i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-kbl-soraka/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22833/fi-kbl-soraka/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3555]:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uncore: Warn only if unclaimed access remains flagged

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/uncore: Warn only if unclaimed access remains flagged
URL   : https://patchwork.freedesktop.org/series/102424/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11479_full -> Patchwork_22830_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address (rev2)
URL   : https://patchwork.freedesktop.org/series/102428/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address (rev2)
URL   : https://patchwork.freedesktop.org/series/102428/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
29958f7974ac drm/dp: Factor out a function to probe a DPCD address
f43a845c0116 drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on 
LTTPR links
-:76: WARNING:LONG_LINE: line length of 107 exceeds 100 columns
#76: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:200:
+   if (drm_dp_dpcd_probe(_dp->aux, 
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))

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

Re: [Intel-gfx] [v2, 1/2] drm/dp: Factor out a function to probe a DPCD address

2022-04-08 Thread Imre Deak

On Sat, Apr 09, 2022 at 01:47:21AM +0300, Almahallawy, Khaled wrote:
> On Fri, 2022-04-08 at 20:21 +0300, Imre Deak wrote:
> > Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
> > with a 1-byte read access. This will be needed by the next patch
> > doing a
> > read from an LTTPR address, which must happen without the preceding
> > wake-up read in drm_dp_dpcd_read().
> >
> > v2: Add a probe function instead of exporting drm_dp_dpcd_access().
> > (Jani)
> >
> > Cc: Jani Nikula 
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/dp/drm_dp.c| 28 +---
> >  include/drm/dp/drm_dp_helper.h |  1 +
> >  2 files changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/dp/drm_dp.c
> > b/drivers/gpu/drm/dp/drm_dp.c
> > index 580016a1b9eb7..b58e30132768d 100644
> > --- a/drivers/gpu/drm/dp/drm_dp.c
> > +++ b/drivers/gpu/drm/dp/drm_dp.c
> > @@ -527,6 +527,29 @@ static int drm_dp_dpcd_access(struct drm_dp_aux
> > *aux, u8 request,
> >   return ret;
> >  }
> >
> > +/**
> > + * drm_dp_dpcd_probe() - probe a given DPCD address with a 1-byte read 
> > access
> > + * @aux: DisplayPort AUX channel (SST)
> > + * @offset: address of the register to probe
> > + *
> > + * Probe the provided DPCD address by reading 1 byte from it. The function 
> > can
> > + * be used to trigger some side-effect the read access has, like waking up 
> > the
> > + * sink, without the need for the read-out value.
> > + *
> > + * Returns 0 if the read access suceeded, or a negative error code on 
> > failure.
> > + */
> > +int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset)
> > +{
> > + u8 buffer;
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, , 1);
> > + WARN_ON(ret == 0);
> > +
> 
> Could you add "drm_dp_dump_access" similar to drm_dp_dpcd_read/write
> in order for this aux tranaction appears in the log?

I considered that, however I'd find the log before each actual read
transfer too verbose.

However logging in case of a failure could be moved here.

> 
> Thanks
> Khaled
> > + return ret < 0 ? ret : 0;
> > +}
> > +EXPORT_SYMBOL(drm_dp_dpcd_probe);
> > +
> >  /**
> >   * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> >   * @aux: DisplayPort AUX channel (SST or MST)
> > @@ -559,9 +582,8 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> > unsigned int offset,
> >* monitor doesn't power down exactly after the throw away
> > read.
> >*/
> >   if (!aux->is_remote) {
> > - ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ,
> > DP_DPCD_REV,
> > -  buffer, 1);
> > - if (ret != 1)
> > + ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
> > + if (ret < 0)
> >   goto out;
> >   }
> >
> > diff --git a/include/drm/dp/drm_dp_helper.h
> > b/include/drm/dp/drm_dp_helper.h
> > index 1eccd97419436..91af98e6617c6 100644
> > --- a/include/drm/dp/drm_dp_helper.h
> > +++ b/include/drm/dp/drm_dp_helper.h
> > @@ -2053,6 +2053,7 @@ struct drm_dp_aux {
> >   bool is_remote;
> >  };
> >
> > +int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset);
> >  ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int
> > offset,
> >void *buffer, size_t size);
> >  ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int
> > offset,

[Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

2022-04-08 Thread Imre Deak

Some ADLP DP link configuration at least with multiple LTTPRs expects
the first DPCD access during the LTTPR/DPCD detection after hotplug to
be a read from the LTTPR range starting with
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
this read is to put each LTTPR into the LTTPR transparent or LTTPR
non-transparent mode.

The lack of the above read may leave some of the LTTPRs in non-LTTPR
mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
mode (for instance LTTPRs after system suspend/resume that kept their
mode from before suspend). Due to the different AUX timeouts the
different modes imply, the DPCD access from a non-LTTPR range will
timeout and lead to an LTTPR generated hotplug towards the source (which
the LTTPR firmware uses to account for buggy TypeC adapters with a long
wake-up delay).

To avoid the above AUX timeout and subsequent hotplug interrupt, make
sure that the first DPCD access during detection is a read from an
LTTPR register.

VLK: SYSCROS-72939

v2: Keep DPCD read-out working on non-LTTPR platforms.

Signed-off-by: Imre Deak 
---
 .../drm/i915/display/intel_dp_link_training.c | 33 ++-
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 26f9e2b748e40..9feaf1a589f38 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp 
*intel_dp,
const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
-   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int ret;
 
-   if (intel_dp_is_edp(intel_dp))
-   return false;
-
-   /*
-* Detecting LTTPRs must be avoided on platforms with an AUX timeout
-* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
-*/
-   if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
-   return false;
-
ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
intel_dp->lttpr_common_caps);
if (ret < 0)
@@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp, 
const u8 dpcd[DP_RECEI
  */
 int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
 {
-   u8 dpcd[DP_RECEIVER_CAP_SIZE];
-   int lttpr_count;
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   int lttpr_count = 0;
 
-   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
-   return -EIO;
+   /*
+* Detecting LTTPRs must be avoided on platforms with an AUX timeout
+* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
+*/
+   if (!intel_dp_is_edp(intel_dp) &&
+   (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
+   u8 dpcd[DP_RECEIVER_CAP_SIZE];
 
-   lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
+   if (drm_dp_dpcd_probe(_dp->aux, 
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
+   return -EIO;
+
+   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
+   return -EIO;
+
+   lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
+   }
 
/*
 * The DPTX shall read the DPRX caps after LTTPR detection, so re-read
-- 
2.30.2

Re: [Intel-gfx] [v2, 1/2] drm/dp: Factor out a function to probe a DPCD address

2022-04-08 Thread Almahallawy, Khaled

On Fri, 2022-04-08 at 20:21 +0300, Imre Deak wrote:
> Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
> with a 1-byte read access. This will be needed by the next patch
> doing a
> read from an LTTPR address, which must happen without the preceding
> wake-up read in drm_dp_dpcd_read().
> 
> v2: Add a probe function instead of exporting drm_dp_dpcd_access().
> (Jani)
> 
> Cc: Jani Nikula 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/dp/drm_dp.c| 28 +---
>  include/drm/dp/drm_dp_helper.h |  1 +
>  2 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/dp/drm_dp.c
> b/drivers/gpu/drm/dp/drm_dp.c
> index 580016a1b9eb7..b58e30132768d 100644
> --- a/drivers/gpu/drm/dp/drm_dp.c
> +++ b/drivers/gpu/drm/dp/drm_dp.c
> @@ -527,6 +527,29 @@ static int drm_dp_dpcd_access(struct drm_dp_aux
> *aux, u8 request,
>   return ret;
>  }
>  
> +/**
> + * drm_dp_dpcd_probe() - probe a given DPCD address with a 1-byte
> read access
> + * @aux: DisplayPort AUX channel (SST)
> + * @offset: address of the register to probe
> + *
> + * Probe the provided DPCD address by reading 1 byte from it. The
> function can
> + * be used to trigger some side-effect the read access has, like
> waking up the
> + * sink, without the need for the read-out value.
> + *
> + * Returns 0 if the read access suceeded, or a negative error code
> on failure.
> + */
> +int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset)
> +{
> + u8 buffer;
> + int ret;
> +
> + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset,
> , 1);
> + WARN_ON(ret == 0);
> +

Could you add "drm_dp_dump_access" similar to drm_dp_dpcd_read/write
in order for this aux tranaction appears in the log?

Thanks
Khaled
> + return ret < 0 ? ret : 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dpcd_probe);
> +
>  /**
>   * drm_dp_dpcd_read() - read a series of bytes from the DPCD
>   * @aux: DisplayPort AUX channel (SST or MST)
> @@ -559,9 +582,8 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> unsigned int offset,
>* monitor doesn't power down exactly after the throw away
> read.
>*/
>   if (!aux->is_remote) {
> - ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ,
> DP_DPCD_REV,
> -  buffer, 1);
> - if (ret != 1)
> + ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
> + if (ret < 0)
>   goto out;
>   }
>  
> diff --git a/include/drm/dp/drm_dp_helper.h
> b/include/drm/dp/drm_dp_helper.h
> index 1eccd97419436..91af98e6617c6 100644
> --- a/include/drm/dp/drm_dp_helper.h
> +++ b/include/drm/dp/drm_dp_helper.h
> @@ -2053,6 +2053,7 @@ struct drm_dp_aux {
>   bool is_remote;
>  };
>  
> +int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset);
>  ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int
> offset,
>void *buffer, size_t size);
>  ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int
> offset,

[Intel-gfx] ✓ Fi.CI.BAT: success for Update to GuC v70

2022-04-08 Thread Patchwork

== Series Details ==

Series: Update to GuC v70
URL   : https://patchwork.freedesktop.org/series/102430/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11479 -> Patchwork_22832


Summary
---

  **WARNING**

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

Participating hosts (47 -> 45)
--

  Additional (1): fi-kbl-8809g 
  Missing(3): fi-bsw-cyan fi-icl-u2 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-7567u:   [DMESG-WARN][1] ([i915#5437]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-kbl-7567u/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][3] ([i915#5557])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-kbl-8809g/igt@fb...@eof.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   [PASS][4] -> [INCOMPLETE][5] ([i915#5127])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][6] -> [DMESG-WARN][7] ([i915#62]) +11 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [PASS][8] -> [DMESG-WARN][9] ([i915#5341] / [i915#62])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@runner@aborted:
- fi-kbl-8809g:   NOTRUN -> [FAIL][10] ([i915#2722])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-kbl-8809g/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][11] ([i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][12] ([i915#2867]) -> [PASS][13] +17 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22832/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

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

  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
  [i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
  [i915#5437]: https://gitlab.freedesktop.org/drm/intel/issues/5437
  [i915#5557]: https://gitlab.freedesktop.org/drm/intel/issues/5557
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Build changes
-

  * Linux: CI_DRM_11479 -> Patchwork_22832

  CI-20190529: 20190529
  CI_DRM_11479: 4dcdb745569d8eef8db09e24e8ff2e5dffc0664c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6415: c3b690bd5f7fb1fb7ed786ab0f3b815930a6a55f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22832: 634d8272f0e73c4e3a803750d6e90b0ab30e4d58 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

634d8272f0e7 drm/i915/guc: Update to GuC version 70.1.1
04be6eae2735 drm/i915/guc: Update scheduling policies to new GuC API
ca0a801b1dda drm/i915/guc: Update context registration to new GuC API

== Logs ==

For more details see:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update to GuC v70

2022-04-08 Thread Patchwork

== Series Details ==

Series: Update to GuC v70
URL   : https://patchwork.freedesktop.org/series/102430/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update to GuC v70

2022-04-08 Thread Patchwork

== Series Details ==

Series: Update to GuC v70
URL   : https://patchwork.freedesktop.org/series/102430/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ca0a801b1dda drm/i915/guc: Update context registration to new GuC API
-:418: WARNING:IF_0: Consider removing the code enclosed by this #if 0 and its 
#endif
#418: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2194:
+#if 0

total: 0 errors, 1 warnings, 0 checks, 492 lines checked
04be6eae2735 drm/i915/guc: Update scheduling policies to new GuC API
634d8272f0e7 drm/i915/guc: Update to GuC version 70.1.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address
URL   : https://patchwork.freedesktop.org/series/102428/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11479 -> Patchwork_22831


Summary
---

  **FAILURE**

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

Participating hosts (47 -> 48)
--

  Additional (3): bat-rpls-1 bat-adlm-1 fi-kbl-8809g 
  Missing(2): fi-bsw-cyan fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6700k2:  [PASS][1] -> [DMESG-WARN][2] +75 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gtt:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html

  * igt@kms_addfb_basic@unused-offsets:
- fi-skl-guc: [PASS][4] -> [DMESG-WARN][5] +74 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-skl-guc/igt@kms_addfb_ba...@unused-offsets.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-skl-guc/igt@kms_addfb_ba...@unused-offsets.html

  * igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-cfl-8109u:   [PASS][6] -> [DMESG-FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html

  * igt@kms_flip@basic-flip-vs-modeset@a-dp2:
- fi-kbl-x1275:   NOTRUN -> [DMESG-WARN][8] +9 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp2.html

  * igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109u:   [PASS][9] -> [FAIL][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html

  * igt@kms_flip@basic-flip-vs-modeset@c-dp2:
- fi-cfl-8109u:   [PASS][11] -> [DMESG-WARN][12] +59 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [PASS][13] -> [DMESG-WARN][14] +69 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-ilk-650: [PASS][15] -> [DMESG-WARN][16] +63 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-ilk-650/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-ilk-650/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html

  
 Suppressed 

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

  * igt@gem_lmem_swapping@random-engines:
- {bat-adlm-1}:   NOTRUN -> [INCOMPLETE][17]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/bat-adlm-1/igt@gem_lmem_swapp...@random-engines.html

  * {igt@i915_suspend@system-suspend-without-i915}:
- fi-ilk-650: [PASS][18] -> [DMESG-WARN][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-ilk-650/igt@i915_susp...@system-suspend-without-i915.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22831/fi-ilk-650/igt@i915_susp...@system-suspend-without-i915.html
- fi-kbl-x1275:   [PASS][20] -> [DMESG-WARN][21]
   [20]:

Re: [Intel-gfx] [PATCH 3/4] drm/fourcc: Introduce format modifier for DG2 clear color

2022-04-08 Thread Maarten Lankhorst

Op 07-04-2022 om 15:37 schreef Juha-Pekka Heikkila:
> Reviewed-by: Juha-Pekka Heikkila 
>
> On 4.4.2022 16.38, Imre Deak wrote:
>> From: Mika Kahola 
>>
>> DG2 clear color render compression uses Tile4 layout. Therefore, we need
>> to define a new format modifier for uAPI to support clear color rendering.
>>
>> v2:
>>    Display version is fixed. [Imre]
>>    KDoc is enhanced for cc modifier. [Nanley & Lionel]
>> v3:
>>    Split out the modifier addition to a separate patch.
>>    Clarify the modifier layout description.
>>
>> Cc: dri-de...@lists.freedesktop.org
>> Signed-off-by: Mika Kahola 
>> cc: Anshuman Gupta 
>> Signed-off-by: Juha-Pekka Heikkilä 
>> Signed-off-by: Ramalingam C 
>> Signed-off-by: Imre Deak 
>> Acked-by: Nanley Chery 
>> ---
>>   include/uapi/drm/drm_fourcc.h | 14 ++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 4a5117715db3c..e5074162bcdd4 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -605,6 +605,20 @@ extern "C" {
>>    */
>>   #define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
>>   +/*
>> + * Intel Color Control Surface with Clear Color (CCS) for DG2 render 
>> compression.
>> + *
>> + * The main surface is Tile 4 and at plane index 0. The CCS data is stored
>> + * outside of the GEM object in a reserved memory area dedicated for the
>> + * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The
>> + * main surface pitch is required to be a multiple of four Tile 4 widths. 
>> The
>> + * clear color is stored at plane index 1 and the pitch should be ignored. 
>> The
>> + * format of the 256 bits of clear color data matches the one used for the
>> + * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC modifier, see its description
>> + * for details.
>> + */
>> +#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
>> +
>>   /*
>>    * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>>    *
>
I personally think it's not required since it's a i915 only format), but for 
merging series through drm-intel:

Acked-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address

2022-04-08 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/2] drm/dp: Factor out a function to probe a 
DPCD address
URL   : https://patchwork.freedesktop.org/series/102428/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uncore: Warn only if unclaimed access remains flagged

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/uncore: Warn only if unclaimed access remains flagged
URL   : https://patchwork.freedesktop.org/series/102424/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11479 -> Patchwork_22830


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (47 -> 44)
--

  Additional (2): bat-rpls-1 fi-kbl-8809g 
  Missing(5): fi-skl-guc fi-bsw-cyan fi-icl-u2 fi-pnv-d510 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- {bat-adlp-6}:   NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/bat-adlp-6/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][2] ([i915#5557])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-kbl-8809g/igt@fb...@eof.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   [PASS][3] -> [INCOMPLETE][4] ([i915#5127])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@runner@aborted:
- fi-kbl-8809g:   NOTRUN -> [FAIL][5] ([i915#2722])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-kbl-8809g/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][6] ([i915#4312])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@perf:
- {fi-tgl-dsi}:   [DMESG-WARN][7] ([i915#2867]) -> [PASS][8] +17 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-tgl-dsi/igt@i915_selftest@l...@perf.html

  * igt@kms_flip@basic-flip-vs-dpms@b-edp1:
- {bat-adlp-6}:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/bat-adlp-6/igt@kms_flip@basic-flip-vs-d...@b-edp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/bat-adlp-6/igt@kms_flip@basic-flip-vs-d...@b-edp1.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][11] ([i915#4269]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11479/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22830/fi-cml-u2/igt@kms_frontbuffer_track...@basic.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
  [i915#5557]: https://gitlab.freedesktop.org/drm/intel/issues/5557


Build changes
-

  * Linux: CI_DRM_11479 -> Patchwork_22830

  CI-20190529: 20190529
  CI_DRM_11479: 4dcdb745569d8eef8db09e24e8ff2e5dffc0664c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6415: c3b690bd5f7fb1fb7ed786ab0f3b815930a6a55f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22830: 8f5512756b31dd254cd49c3dcd54f3f4e25afe34 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (rev2)

2022-04-08 Thread Vudum, Lakshminarayana

Issues are related to following (just filed #5614)
https://gitlab.freedesktop.org/drm/intel/-/issues/636
[CI][DRMTIP]igt@kms_flip@2x-flip-vs-suspend - dmesg-warn - WARNING: CPU: \d 
PID: \d+ at drivers/misc/mei/hbm.c:\d+ mei_hbm_dispatch\+.*

https://gitlab.freedesktop.org/drm/intel/-/issues/5614
igt@gem_exec_balancer@.* - dmesg-warn/dmesg-fail - WARNING: .* at 
drivers/dma-buf/dma-resv.c:\d+ dma_resv_add_fence

Lakshmi.
-Original Message-
From: Roper, Matthew D  
Sent: Friday, April 8, 2022 12:00 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Sunset igpu legacy mmap support 
based on GRAPHICS_VER_FULL (rev2)

On Fri, Apr 08, 2022 at 06:47:48PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL 
> (rev2)
> URL   : https://patchwork.freedesktop.org/series/102352/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22829_full 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_22829_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_22829_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 -> 10)
> --
> 
>   Missing(1): shard-tglu 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22829_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_flip@flip-vs-suspend@c-dp1:
> - shard-kbl:  [PASS][1] -> [DMESG-WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl1/ig
> t@kms_flip@flip-vs-susp...@c-dp1.html

Non-graphics error.  Appears to be the same one reported in
https://gitlab.freedesktop.org/drm/intel/-/issues/636

Not caused by this patch.


Matt

> 
>   
>  Warnings 
> 
>   * igt@gem_exec_balancer@parallel-bb-first:
> - shard-iclb: [SKIP][3] ([i915#4525]) -> [DMESG-WARN][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb2/i
> gt@gem_exec_balan...@parallel-bb-first.html
> 
>   * igt@gem_exec_balancer@parallel-ordering:
> - shard-iclb: [SKIP][5] ([i915#4525]) -> [DMESG-FAIL][6]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb4/i
> gt@gem_exec_balan...@parallel-ordering.html
> 
>   
> New tests
> -
> 
>   New tests have been introduced between CI_DRM_11477_full and 
> Patchwork_22829_full:
> 
> ### New Piglit tests (1) ###
> 
>   * spec@arb_copy_image@arb_copy_image-formats --samples=8:
> - Statuses : 1 fail(s)
> - Exec time: [2.36] s
> 
>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22829_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@preservation-s3@rcs0:
> - shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 
> similar issues
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-apl4/ig
> t@gem_ctx_isolation@preservation...@rcs0.html
> 
>   * igt@gem_exec_capture@pi@bcs0:
> - shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#4547])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/ig
> t@gem_exec_capture@p...@bcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl7/ig
> t@gem_exec_fair@basic-n...@vcs1.html
> 
>   * igt@gem_exec_fair@basic-pace@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
> - shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
> issue
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl4/ig
> t@gem_exec_fair@basic-p...@vcs1.html
> 
>   *

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL 
(rev2)
URL   : https://patchwork.freedesktop.org/series/102352/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22829_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_11477_full and 
Patchwork_22829_full:

### New Piglit tests (1) ###

  * spec@arb_copy_image@arb_copy_image-formats --samples=8:
- Statuses : 1 fail(s)
- Exec time: [2.36] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][3] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_exec_capture@p...@bcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb:  [PASS][8] -> [SKIP][9] ([fdo#109271]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html

  * igt@gem_lmem_swapping@random:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_lmem_swapp...@random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-iclb: NOTRUN -> [SKIP][11] ([i915#4613])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb8/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#644])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#4270])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb8/igt@gem_...@create-regular-context-1.html

  * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#768])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.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_22829/shard-skl4/igt@i915_pm...@dc6-dpms.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: NOTRUN -> [WARN][17] ([i915#1804] / [i915#2684])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb7/igt@i915_pm_rc6_reside...@rc6-idle.html

  * igt@i915_pm_rpm@pc8-residency:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109293] / [fdo#109506])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb7/igt@i915_pm_...@pc8-residency.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#5286])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb8/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-0.html

  * igt@kms_big_fb@linear-64bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#110725] / [fdo#111614])
   [20]:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (rev2)

2022-04-08 Thread Matt Roper

On Fri, Apr 08, 2022 at 06:47:48PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL 
> (rev2)
> URL   : https://patchwork.freedesktop.org/series/102352/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22829_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_22829_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_22829_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 -> 10)
> --
> 
>   Missing(1): shard-tglu 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22829_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_flip@flip-vs-suspend@c-dp1:
> - shard-kbl:  [PASS][1] -> [DMESG-WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html

Non-graphics error.  Appears to be the same one reported in
https://gitlab.freedesktop.org/drm/intel/-/issues/636

Not caused by this patch.


Matt

> 
>   
>  Warnings 
> 
>   * igt@gem_exec_balancer@parallel-bb-first:
> - shard-iclb: [SKIP][3] ([i915#4525]) -> [DMESG-WARN][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
> 
>   * igt@gem_exec_balancer@parallel-ordering:
> - shard-iclb: [SKIP][5] ([i915#4525]) -> [DMESG-FAIL][6]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb4/igt@gem_exec_balan...@parallel-ordering.html
> 
>   
> New tests
> -
> 
>   New tests have been introduced between CI_DRM_11477_full and 
> Patchwork_22829_full:
> 
> ### New Piglit tests (1) ###
> 
>   * spec@arb_copy_image@arb_copy_image-formats --samples=8:
> - Statuses : 1 fail(s)
> - Exec time: [2.36] s
> 
>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22829_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@preservation-s3@rcs0:
> - shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 
> similar issues
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
> 
>   * igt@gem_exec_capture@pi@bcs0:
> - shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#4547])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_exec_capture@p...@bcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html
> 
>   * igt@gem_exec_fair@basic-pace@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
> - shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
> issue
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
> 
>   * igt@gem_exec_flush@basic-batch-kernel-default-uc:
> - shard-snb:  [PASS][14] -> [SKIP][15] ([fdo#109271]) +1 similar 
> issue
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
> 
>   * igt@gem_lmem_swapping@random:
> - shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) 
> +2 similar issues
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_lmem_swapp...@random.html
> 
>   * igt@gem_lmem_swapping@random-engines:
> - shard-iclb:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL 
(rev2)
URL   : https://patchwork.freedesktop.org/series/102352/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22829_full


Summary
---

  **FAILURE**

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

  Missing(1): shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html

  
 Warnings 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [SKIP][3] ([i915#4525]) -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb3/igt@gem_exec_balan...@parallel-bb-first.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [SKIP][5] ([i915#4525]) -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb4/igt@gem_exec_balan...@parallel-ordering.html

  
New tests
-

  New tests have been introduced between CI_DRM_11477_full and 
Patchwork_22829_full:

### New Piglit tests (1) ###

  * spec@arb_copy_image@arb_copy_image-formats --samples=8:
- Statuses : 1 fail(s)
- Exec time: [2.36] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-apl4/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#4547])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_exec_capture@p...@bcs0.html

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

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb:  [PASS][14] -> [SKIP][15] ([fdo#109271]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html

  * igt@gem_lmem_swapping@random:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-skl8/igt@gem_lmem_swapp...@random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/shard-iclb8/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#644])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html
   [19]:

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Update to GuC version 70.1.1

2022-04-08 Thread John . C . Harrison

From: John Harrison 

Update to the latest GuC firmware release.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index bb864655c495..cb5dd16421d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -53,22 +53,22 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  * firmware as TGL.
  */
 #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
-   fw_def(DG2,  0, guc_def(dg2,  69, 0, 3)) \
-   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 69, 0, 3)) \
-   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  69, 0, 3)) \
-   fw_def(DG1,  0, guc_def(dg1,  69, 0, 3)) \
-   fw_def(ROCKETLAKE,   0, guc_def(tgl,  69, 0, 3)) \
-   fw_def(TIGERLAKE,0, guc_def(tgl,  69, 0, 3)) \
-   fw_def(JASPERLAKE,   0, guc_def(ehl,  69, 0, 3)) \
-   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  69, 0, 3)) \
-   fw_def(ICELAKE,  0, guc_def(icl,  69, 0, 3)) \
-   fw_def(COMETLAKE,5, guc_def(cml,  69, 0, 3)) \
-   fw_def(COMETLAKE,0, guc_def(kbl,  69, 0, 3)) \
-   fw_def(COFFEELAKE,   0, guc_def(kbl,  69, 0, 3)) \
-   fw_def(GEMINILAKE,   0, guc_def(glk,  69, 0, 3)) \
-   fw_def(KABYLAKE, 0, guc_def(kbl,  69, 0, 3)) \
-   fw_def(BROXTON,  0, guc_def(bxt,  69, 0, 3)) \
-   fw_def(SKYLAKE,  0, guc_def(skl,  69, 0, 3))
+   fw_def(DG2,  0, guc_def(dg2,  70, 1, 1)) \
+   fw_def(ALDERLAKE_P,  0, guc_def(adlp, 70, 1, 1)) \
+   fw_def(ALDERLAKE_S,  0, guc_def(tgl,  70, 1, 1)) \
+   fw_def(DG1,  0, guc_def(dg1,  70, 1, 1)) \
+   fw_def(ROCKETLAKE,   0, guc_def(tgl,  70, 1, 1)) \
+   fw_def(TIGERLAKE,0, guc_def(tgl,  70, 1, 1)) \
+   fw_def(JASPERLAKE,   0, guc_def(ehl,  70, 1, 1)) \
+   fw_def(ELKHARTLAKE,  0, guc_def(ehl,  70, 1, 1)) \
+   fw_def(ICELAKE,  0, guc_def(icl,  70, 1, 1)) \
+   fw_def(COMETLAKE,5, guc_def(cml,  70, 1, 1)) \
+   fw_def(COMETLAKE,0, guc_def(kbl,  70, 1, 1)) \
+   fw_def(COFFEELAKE,   0, guc_def(kbl,  70, 1, 1)) \
+   fw_def(GEMINILAKE,   0, guc_def(glk,  70, 1, 1)) \
+   fw_def(KABYLAKE, 0, guc_def(kbl,  70, 1, 1)) \
+   fw_def(BROXTON,  0, guc_def(bxt,  70, 1, 1)) \
+   fw_def(SKYLAKE,  0, guc_def(skl,  70, 1, 1))
 
 #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
-- 
2.25.1

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Update scheduling policies to new GuC API

2022-04-08 Thread John . C . Harrison

From: John Harrison 

The latest GuC firmware drops the individual scheduling policy update
H2G commands in favour of a single KLV based H2G. So, change the
update wrappers accordingly.

Unfortunately, the API changes also mean losing the ability to set any
scheduling policy values during context registration. Instead the same
KLV based H2G must be sent after the registration. Of course, that
second H2G per registration might fail due to being backed up. The
registration code has a complicated state machine to cope with the
actual registration call failing. However, if that works then there is
no support for unwinding if a further call should fail. Unwinding
would require sending a H2G to de-register - but that can't be done
because the CTB is already backed up.

So instead, add a new flag to say whether the context has a pending
policy update. This is set if the policy H2G fails at registration
time. The submission code checks for this flag and retries the policy
update if set. If that call fails, the submission path early exists
with a retry error. This is something that is already supported for
other reasons.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   4 +-
 drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h |  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  19 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 176 ++
 4 files changed, 175 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 9ad6df1b6fbc..be9ac47fa9d0 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,11 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
-   INTEL_GUC_ACTION_SET_CONTEXT_PRIORITY = 0x1005,
-   INTEL_GUC_ACTION_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
-   INTEL_GUC_ACTION_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
+   INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
index f0814a57c191..4a59478c3b5c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
@@ -6,6 +6,8 @@
 #ifndef _ABI_GUC_KLVS_ABI_H
 #define _ABI_GUC_KLVS_ABI_H
 
+#include 
+
 /**
  * DOC: GuC KLV
  *
@@ -79,4 +81,17 @@
 #define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_KEY  0x0907
 #define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_LEN  1u
 
+/*
+ * Per context scheduling policy update keys.
+ */
+enum  {
+   GUC_CONTEXT_POLICIES_KLV_ID_EXECUTION_QUANTUM   = 
0x2001,
+   GUC_CONTEXT_POLICIES_KLV_ID_PREEMPTION_TIMEOUT  = 
0x2002,
+   GUC_CONTEXT_POLICIES_KLV_ID_SCHEDULING_PRIORITY = 
0x2003,
+   GUC_CONTEXT_POLICIES_KLV_ID_PREEMPT_TO_IDLE_ON_QUANTUM_EXPIRY   = 
0x2004,
+   GUC_CONTEXT_POLICIES_KLV_ID_SLPM_GT_FREQUENCY   = 
0x2005,
+
+   GUC_CONTEXT_POLICIES_KLV_NUM_IDS = 5,
+};
+
 #endif /* _ABI_GUC_KLVS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 0e1e8d0079b5..c154b5efccde 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -221,11 +221,22 @@ struct guc_ctxt_registration_info {
 };
 #define CONTEXT_REGISTRATION_FLAG_KMD  BIT(0)
 
-#define CONTEXT_POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
-#define CONTEXT_POLICY_DEFAULT_PREEMPTION_TIME_US 50
+/* 32-bit KLV structure as used by policy updates and others */
+struct guc_klv_generic_dw_t {
+   u32 kl;
+   u32 value;
+} __packed;
 
-/* Preempt to idle on quantum expiry */
-#define CONTEXT_POLICY_FLAG_PREEMPT_TO_IDLEBIT(0)
+/* Format of the UPDATE_CONTEXT_POLICIES H2G data packet */
+struct guc_update_context_policy_header {
+   u32 action;
+   u32 ctx_id;
+} __packed;
+
+struct guc_update_context_policy {
+   struct guc_update_context_policy_header header;
+   struct guc_klv_generic_dw_t klv[GUC_CONTEXT_POLICIES_KLV_NUM_IDS];
+} __packed;
 
 #define GUC_POWER_UNSPECIFIED  0
 #define GUC_POWER_D0   1
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index bd0584d7d489..2bd680064942 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -162,7 +162,8 @@ guc_create_parallel(struct

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Update context registration to new GuC API

2022-04-08 Thread John . C . Harrison

From: John Harrison 

The latest GuC firmware drops the context descriptor pool in favour of
passing all creation data in the create H2G. It also greatly simplifies
the work queue and removes the process descriptor used for multi-LRC
submission. So, remove all mention of LRC and process descriptors and
update the registration code accordingly.

Unfortunately, the new API also removes the ability to set default
values for the scheduling policies at context registration time.
Instead, a follow up H2G must be sent. This will be addressed in the
next patch.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|   5 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  52 ++---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 221 --
 3 files changed, 116 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 4e431c14b118..3f3373f68123 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,11 +170,6 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
 
-   /** @lrc_desc_pool: object allocated to hold the GuC LRC descriptor 
pool */
-   struct i915_vma *lrc_desc_pool;
-   /** @lrc_desc_pool_vaddr: contents of the GuC LRC descriptor pool */
-   void *lrc_desc_pool_vaddr;
-
/**
 * @context_lookup: used to resolve intel_context from guc_id, if a
 * context is present in this structure it is registered with the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index f21b6de46a99..0e1e8d0079b5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -197,20 +197,28 @@ struct guc_wq_item {
u32 fence_id;
 } __packed;
 
-struct guc_process_desc {
-   u32 stage_id;
-   u64 db_base_addr;
+struct guc_sched_wq_desc {
u32 head;
u32 tail;
u32 error_offset;
-   u64 wq_base_addr;
-   u32 wq_size_bytes;
u32 wq_status;
-   u32 engine_presence;
-   u32 priority;
-   u32 reserved[36];
+   u32 reserved[28];
 } __packed;
 
+/* Helper for context registration H2G */
+struct guc_ctxt_registration_info {
+   u32 flags;
+   u32 context_idx;
+   u32 engine_class;
+   u32 engine_submit_mask;
+   u32 wq_desc_lo;
+   u32 wq_desc_hi;
+   u32 wq_base_lo;
+   u32 wq_base_hi;
+   u32 wq_size;
+   u32 hwlrca_lo;
+   u32 hwlrca_hi;
+};
 #define CONTEXT_REGISTRATION_FLAG_KMD  BIT(0)
 
 #define CONTEXT_POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
@@ -219,34 +227,6 @@ struct guc_process_desc {
 /* Preempt to idle on quantum expiry */
 #define CONTEXT_POLICY_FLAG_PREEMPT_TO_IDLEBIT(0)
 
-/*
- * GuC Context registration descriptor.
- * FIXME: This is only required to exist during context registration.
- * The current 1:1 between guc_lrc_desc and LRCs for the lifetime of the LRC
- * is not required.
- */
-struct guc_lrc_desc {
-   u32 hw_context_desc;
-   u32 slpm_perf_mode_hint;/* SPLC v1 only */
-   u32 slpm_freq_hint;
-   u32 engine_submit_mask; /* In logical space */
-   u8 engine_class;
-   u8 reserved0[3];
-   u32 priority;
-   u32 process_desc;
-   u32 wq_addr;
-   u32 wq_size;
-   u32 context_flags;  /* CONTEXT_REGISTRATION_* */
-   /* Time for one workload to execute. (in micro seconds) */
-   u32 execution_quantum;
-   /* Time to wait for a preemption request to complete before issuing a
-* reset. (in micro seconds).
-*/
-   u32 preemption_timeout;
-   u32 policy_flags;   /* CONTEXT_POLICY_* */
-   u32 reserved1[19];
-} __packed;
-
 #define GUC_POWER_UNSPECIFIED  0
 #define GUC_POWER_D0   1
 #define GUC_POWER_D1   2
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e1612c393781..bd0584d7d489 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -396,12 +396,12 @@ struct sync_semaphore {
 };
 
 struct parent_scratch {
-   struct guc_process_desc pdesc;
+   struct guc_sched_wq_desc wq_desc;
 
struct sync_semaphore go;
struct sync_semaphore join[MAX_ENGINE_INSTANCE + 1];
 
-   u8 unused[WQ_OFFSET - sizeof(struct guc_process_desc) -
+   u8 unused[WQ_OFFSET - sizeof(struct guc_sched_wq_desc) -
sizeof(struct sync_semaphore) * (MAX_ENGINE_INSTANCE + 2)];
 
u32 wq[WQ_SIZE / sizeof(u32)];
@@ -438,15 +438,15 @@ __get_parent_scratch(struct intel_context *ce)
   LRC_STATE_OFFSET) / sizeof(u32)));
 }
 
-static struct guc_process_desc *
-__get_process_desc(struct intel_context *ce)
+static struct

[Intel-gfx] [PATCH 0/3] Update to GuC v70

2022-04-08 Thread John . C . Harrison

From: John Harrison 

Update to the latest GuC firmware release.

Note that this includes some significant backwards breaking API
changes. One is about context registration - the descriptor pool is
gone, all parameters are passed via the CTB instead. The second is
about scheduling policy updates - they are now done via a single KLV
based H2G instead of multiple direct H2Gs. The patches to implement
these two changes are being sent split initially for ease of review.
However, for final merge, they will need to be squashed into a single
atomic commit.

Signed-off-by: John Harrison 


John Harrison (3):
  drm/i915/guc: Update context registration to new GuC API
  drm/i915/guc: Update scheduling policies to new GuC API
  drm/i915/guc: Update to GuC version 70.1.1

 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   4 +-
 drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h |  15 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|   5 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  67 ++--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 375 +++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  32 +-
 6 files changed, 294 insertions(+), 204 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function

2022-04-08 Thread Lisovskiy, Stanislav

On Fri, Apr 08, 2022 at 06:59:07PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 08, 2022 at 06:46:00PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 08, 2022 at 03:51:59PM +0300, Stanislav Lisovskiy wrote:
> > > Currently skl_pcode_try_request function doesn't
> > > properly handle return value it gets from
> > > snb_pcode_rw, but treats status != 0 as success,
> > > returning true, which basically doesn't allow
> > > to use retry/timeout mechanisms if PCode happens
> > > to be busy and returns EGAIN or some other status
> > > code not equal to 0.
> > > 
> > > We saw this on real hw and also tried simulating this
> > > by always returning -EAGAIN from snb_pcode_rw for 6 times, which
> > > currently will just result in false success, while it should
> > > have tried until timeout is reached:
> > > 
> > > [   22.357729] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > > Changing CDCLK to
> > > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage 
> > > level 0
> > > [   22.357831] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 1
> > > [   22.357892] i915 :00:02.0: [drm:skl_pcode_request [i915]] Success, 
> > > exiting
> > > [   22.357936] i915 :00:02.0: [drm] ERROR Failed to inform PCU about 
> > > cdclk change (err -11, freq 307200)
> > > 
> > > We see en error because higher level api, still notices that status was 
> > > wrong,
> > > however we still did try only once.
> > > 
> > > We fix it by requiring _both_ the status to be 0 and
> > > request/reply match for success(true) and function
> > > should return failure(false) if either status turns
> > > out to be EAGAIN, EBUSY or whatever or reply/request
> > > masks do not match.
> > > 
> > > So now we see this in the logs:
> > > 
> > > [   22.318667] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > > Changing CDCLK to
> > > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage 
> > > level 0
> > > [   22.318782] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 1
> 
> Hmm. That is weird. The timestamp difference is only ~100 usec even
> though we are supposed to use that 500 usec timeout. So did some
> previous pcode access already timeout and leave the mailbox busy 
> before we even do this request, or what is going on?

Ah that is not the real example. 
What I did to check how it works is just added something like this:

+ static int retries = 0;

+  if (++retry < 6)
+  return -EAGAIN

to _snb_pcode_rw.

So before the patch, skl_pcode_try_request returned True when getting -EAGAIN 
and 
immediately bailed out, assigning ret = 0 and goto out, as if it succeeded 
while it obvously not.

> 
> > > [   22.318849] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 2
> > > [   22.319006] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 3
> > > [   22.319091] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 4
> > > [   22.319158] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 5
> > > [   22.319224] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > > EAGAIN retry 6

That is how it behaves with this patch, i.e status != 0 makes 
skl_pcode_try_request
return False(as it should) which then enables skl_pcode_request retry machinery.

In real case we have something similar to this but can't really reproduce it 
that easily,
so was kinda simulating that issue to check.

Stan

> > > 
> > > Reviewed-by: Vinod Govindapillai 
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
> > > b/drivers/gpu/drm/i915/intel_pcode.c
> > > index 391a37492ce5..fb6c43e8a02f 100644
> > > --- a/drivers/gpu/drm/i915/intel_pcode.c
> > > +++ b/drivers/gpu/drm/i915/intel_pcode.c
> > > @@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct 
> > > drm_i915_private *i915, u32 mbox,
> > >  {
> > >   *status = __snb_pcode_rw(i915, mbox, , NULL, 500, 0, true);
> > >  
> > > - return *status || ((request & reply_mask) == reply);
> > > + return (*status == 0) && ((request & reply_mask) == reply);
> > 
> > The problem with this is that now we'll keep pointlessly banging it
> > even if it returns a real error.
> > 
> > We should never really see that -EAGAIN since it indicates that our
> > timeout is too short. So the real fix should be to increase that
> > timeout. But I guess we could do a belt-and-suspenders approach
> > where we also keep repeating on -EGAIN. But I'm thinking -EAGAIN
> > should WARN as well to make sure we notice that our timeout is wrong.
> > 
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.24.1.485.gad05a3d8e5
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Swap ret and status returned from skl_pcode_request

2022-04-08 Thread Govindapillai, Vinod

On Fri, 2022-04-08 at 15:52 +0300, Stanislav Lisovskiy wrote:
> If ret isn't zero, it is almost for sure ETIMEDOUT, because
> we use it in wait_for macro which does continuous retries
> until timeout is reached. If we still ran out of time and
> retries, we most likely would be interested in getting status,
> to understand what was the actual error propagated from PCode,
> rather than to find out that we had a time out, which is anyway
> quite obvious, if the function fails.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
> b/drivers/gpu/drm/i915/intel_pcode.c
> index fb6c43e8a02f..a68eaf510784 100644
> --- a/drivers/gpu/drm/i915/intel_pcode.c
> +++ b/drivers/gpu/drm/i915/intel_pcode.c
> @@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 
> mbox, u32 request,
>  
>  out:
>   mutex_unlock(>sb_lock);
> - return ret ? ret : status;
> + return ret ? status : ret;

Isnt this equivalent to "return status" 
When we were discussing this, I felt this is good. 
But on further check with the functions gen7_check_mailbox_status(), is there a 
possibility that
status = 0 but "request & reply_mask) != reply" for the "default" case handling?

In that cast _wait_for() will be timedout with ret = ETimedOut but "status" = 0

Is that real scenario? 


>  #undef COND
>  }
>

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function

2022-04-08 Thread Lisovskiy, Stanislav

On Fri, Apr 08, 2022 at 06:46:00PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 08, 2022 at 03:51:59PM +0300, Stanislav Lisovskiy wrote:
> > Currently skl_pcode_try_request function doesn't
> > properly handle return value it gets from
> > snb_pcode_rw, but treats status != 0 as success,
> > returning true, which basically doesn't allow
> > to use retry/timeout mechanisms if PCode happens
> > to be busy and returns EGAIN or some other status
> > code not equal to 0.
> > 
> > We saw this on real hw and also tried simulating this
> > by always returning -EAGAIN from snb_pcode_rw for 6 times, which
> > currently will just result in false success, while it should
> > have tried until timeout is reached:
> > 
> > [   22.357729] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > Changing CDCLK to
> > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> > [   22.357831] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 1
> > [   22.357892] i915 :00:02.0: [drm:skl_pcode_request [i915]] Success, 
> > exiting
> > [   22.357936] i915 :00:02.0: [drm] ERROR Failed to inform PCU about 
> > cdclk change (err -11, freq 307200)
> > 
> > We see en error because higher level api, still notices that status was 
> > wrong,
> > however we still did try only once.
> > 
> > We fix it by requiring _both_ the status to be 0 and
> > request/reply match for success(true) and function
> > should return failure(false) if either status turns
> > out to be EAGAIN, EBUSY or whatever or reply/request
> > masks do not match.
> > 
> > So now we see this in the logs:
> > 
> > [   22.318667] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > Changing CDCLK to
> > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> > [   22.318782] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 1
> > [   22.318849] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 2
> > [   22.319006] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 3
> > [   22.319091] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 4
> > [   22.319158] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 5
> > [   22.319224] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 6
> > 
> > Reviewed-by: Vinod Govindapillai 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
> > b/drivers/gpu/drm/i915/intel_pcode.c
> > index 391a37492ce5..fb6c43e8a02f 100644
> > --- a/drivers/gpu/drm/i915/intel_pcode.c
> > +++ b/drivers/gpu/drm/i915/intel_pcode.c
> > @@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct 
> > drm_i915_private *i915, u32 mbox,
> >  {
> > *status = __snb_pcode_rw(i915, mbox, , NULL, 500, 0, true);
> >  
> > -   return *status || ((request & reply_mask) == reply);
> > +   return (*status == 0) && ((request & reply_mask) == reply);
> 
> The problem with this is that now we'll keep pointlessly banging it
> even if it returns a real error.

Question is that we should then define when it is pointless and when
its not. 
Not sure, if we should retry on any status - maybe only if its EBUSY
or smth. But even if at some point we get some issue with PCode
which is resolved after retry as currently should we may be still retry?

Anyway I guess this isn't how this is supposed to work - i.e if we
get status != 0, we should fail, but not succeed, also I guess
request not matching the reply mask should make it fail.

Stan

> 
> We should never really see that -EAGAIN since it indicates that our
> timeout is too short. So the real fix should be to increase that
> timeout. But I guess we could do a belt-and-suspenders approach
> where we also keep repeating on -EGAIN. But I'm thinking -EAGAIN
> should WARN as well to make sure we notice that our timeout is wrong.
> 
> >  }
> >  
> >  /**
> > -- 
> > 2.24.1.485.gad05a3d8e5
> 
> -- 
> Ville Syrjälä
> Intel

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

2022-04-08 Thread Imre Deak

Some ADLP DP link configuration at least with multiple LTTPRs expects
the first DPCD access during the LTTPR/DPCD detection after hotplug to
be a read from the LTTPR range starting with
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
this read is to put each LTTPR into the LTTPR transparent or LTTPR
non-transparent mode.

The lack of the above read may leave some of the LTTPRs in non-LTTPR
mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
mode (for instance LTTPRs after system suspend/resume that kept their
mode from before suspend). Due to the different AUX timeouts the
different modes imply, the DPCD access from a non-LTTPR range will
timeout and lead to an LTTPR generated hotplug towards the source (which
the LTTPR firmware uses to account for buggy TypeC adapters with a long
wake-up delay).

To avoid the above AUX timeout and subsequent hotplug interrupt, make
sure that the first DPCD access during detection is a read from an
LTTPR register.

VLK: SYSCROS-72939

Signed-off-by: Imre Deak 
---
 .../drm/i915/display/intel_dp_link_training.c | 25 +++
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 26f9e2b748e40..8f4f3b6637c81 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp 
*intel_dp,
const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
-   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int ret;
 
-   if (intel_dp_is_edp(intel_dp))
-   return false;
-
-   /*
-* Detecting LTTPRs must be avoided on platforms with an AUX timeout
-* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
-*/
-   if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
-   return false;
-
ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
intel_dp->lttpr_common_caps);
if (ret < 0)
@@ -197,12 +186,26 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp, 
const u8 dpcd[DP_RECEI
  */
 int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
 {
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   /*
+* Detecting LTTPRs must be avoided on platforms with an AUX timeout
+* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
+*/
+   bool init_lttpr = !intel_dp_is_edp(intel_dp) &&
+ (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915));
u8 dpcd[DP_RECEIVER_CAP_SIZE];
int lttpr_count;
 
+   if (init_lttpr &&
+   drm_dp_dpcd_probe(_dp->aux, 
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
+   return -EIO;
+
if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
return -EIO;
 
+   if (!init_lttpr)
+   return 0;
+
lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
 
/*
-- 
2.30.2

[Intel-gfx] [PATCH v2 1/2] drm/dp: Factor out a function to probe a DPCD address

2022-04-08 Thread Imre Deak

Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
with a 1-byte read access. This will be needed by the next patch doing a
read from an LTTPR address, which must happen without the preceding
wake-up read in drm_dp_dpcd_read().

v2: Add a probe function instead of exporting drm_dp_dpcd_access(). (Jani)

Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/dp/drm_dp.c| 28 +---
 include/drm/dp/drm_dp_helper.h |  1 +
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c
index 580016a1b9eb7..b58e30132768d 100644
--- a/drivers/gpu/drm/dp/drm_dp.c
+++ b/drivers/gpu/drm/dp/drm_dp.c
@@ -527,6 +527,29 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
return ret;
 }
 
+/**
+ * drm_dp_dpcd_probe() - probe a given DPCD address with a 1-byte read access
+ * @aux: DisplayPort AUX channel (SST)
+ * @offset: address of the register to probe
+ *
+ * Probe the provided DPCD address by reading 1 byte from it. The function can
+ * be used to trigger some side-effect the read access has, like waking up the
+ * sink, without the need for the read-out value.
+ *
+ * Returns 0 if the read access suceeded, or a negative error code on failure.
+ */
+int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset)
+{
+   u8 buffer;
+   int ret;
+
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, , 1);
+   WARN_ON(ret == 0);
+
+   return ret < 0 ? ret : 0;
+}
+EXPORT_SYMBOL(drm_dp_dpcd_probe);
+
 /**
  * drm_dp_dpcd_read() - read a series of bytes from the DPCD
  * @aux: DisplayPort AUX channel (SST or MST)
@@ -559,9 +582,8 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned 
int offset,
 * monitor doesn't power down exactly after the throw away read.
 */
if (!aux->is_remote) {
-   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV,
-buffer, 1);
-   if (ret != 1)
+   ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV);
+   if (ret < 0)
goto out;
}
 
diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h
index 1eccd97419436..91af98e6617c6 100644
--- a/include/drm/dp/drm_dp_helper.h
+++ b/include/drm/dp/drm_dp_helper.h
@@ -2053,6 +2053,7 @@ struct drm_dp_aux {
bool is_remote;
 };
 
+int drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset);
 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
 void *buffer, size_t size);
 ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int offset,
-- 
2.30.2

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix warnings about PSR lock not held (rev4)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Fix warnings about PSR lock not held (rev4)
URL   : https://patchwork.freedesktop.org/series/102298/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22828_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_22828_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22828_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 -> 10)
--

  Missing(1): shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [SKIP][1] ([i915#4525]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb4/igt@gem_exec_balan...@parallel-ordering.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][3] ([i915#4547])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-skl6/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_schedule@semaphore-user:
- shard-skl:  [PASS][10] -> [DMESG-WARN][11] ([i915#1982])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-skl8/igt@gem_exec_sched...@semaphore-user.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-skl6/igt@gem_exec_sched...@semaphore-user.html

  * igt@gem_lmem_swapping@random:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-skl6/igt@gem_lmem_swapp...@random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb5/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#4270]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb5/igt@gem_...@create-regular-context-1.html

  * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#768])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb5/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.html

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb7/igt@gem_soft...@evict-snoop-interruptible.html

  * igt@gen7_exec_parse@basic-rejected:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109289]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb7/igt@gen7_exec_pa...@basic-rejected.html

  * igt@gen9_exec_parse@bb-start-cmd:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#2856])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/shard-iclb7/igt@gen9_exec_pa...@bb-start-cmd.html

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

Re: [Intel-gfx] [PATCH] drm/i915/uncore: Warn only if unclaimed access remains flagged

2022-04-08 Thread Matt Roper

On Fri, Apr 08, 2022 at 09:48:37AM -0700, Lucas De Marchi wrote:
> Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed
> accesses") tried to improve our report of unclaimed register access,
> however it unveiled cases that were not previously causing any harm.
> 
> Downgrade the first message to debug so we can still see them and
> eventually fix, but don't warn.
> 
> Fixes: 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses")
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

> ---
> 
> Tested on top of intel/CI_DRM_11471 as drm-tip is currently broken by
> other things.
> 
>  drivers/gpu/drm/i915/intel_uncore.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index df59ec88459e..83517a703eb6 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1518,13 +1518,11 @@ __unclaimed_previous_reg_debug(struct intel_uncore 
> *uncore,
>  const i915_reg_t reg,
>  const bool read)
>  {
> - if (drm_WARN(>i915->drm,
> -  check_for_unclaimed_mmio(uncore),
> -  "Unclaimed access detected before %s register 0x%x\n",
> -  read ? "read from" : "write to",
> -  i915_mmio_reg_offset(reg)))
> - /* Only report the first N failures */
> - uncore->i915->params.mmio_debug--;
> + if (check_for_unclaimed_mmio(uncore))
> + drm_dbg(>i915->drm,
> + "Unclaimed access detected before %s register 0x%x\n",
> + read ? "read from" : "write to",
> + i915_mmio_reg_offset(reg));
>  }
>  
>  static inline void
> -- 
> 2.35.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

[Intel-gfx] [PATCH] drm/i915/uncore: Warn only if unclaimed access remains flagged

2022-04-08 Thread Lucas De Marchi

Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed
accesses") tried to improve our report of unclaimed register access,
however it unveiled cases that were not previously causing any harm.

Downgrade the first message to debug so we can still see them and
eventually fix, but don't warn.

Fixes: 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses")
Signed-off-by: Lucas De Marchi 
---

Tested on top of intel/CI_DRM_11471 as drm-tip is currently broken by
other things.

 drivers/gpu/drm/i915/intel_uncore.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index df59ec88459e..83517a703eb6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1518,13 +1518,11 @@ __unclaimed_previous_reg_debug(struct intel_uncore 
*uncore,
   const i915_reg_t reg,
   const bool read)
 {
-   if (drm_WARN(>i915->drm,
-check_for_unclaimed_mmio(uncore),
-"Unclaimed access detected before %s register 0x%x\n",
-read ? "read from" : "write to",
-i915_mmio_reg_offset(reg)))
-   /* Only report the first N failures */
-   uncore->i915->params.mmio_debug--;
+   if (check_for_unclaimed_mmio(uncore))
+   drm_dbg(>i915->drm,
+   "Unclaimed access detected before %s register 0x%x\n",
+   read ? "read from" : "write to",
+   i915_mmio_reg_offset(reg));
 }
 
 static inline void
-- 
2.35.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (rev2)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL 
(rev2)
URL   : https://patchwork.freedesktop.org/series/102352/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477 -> Patchwork_22829


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (47 -> 37)
--

  Additional (1): fi-bxt-dsi 
  Missing(11): fi-bdw-samus shard-tglu bat-dg1-6 bat-dg2-8 bat-dg2-9 
fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-hsw-4770 bat-rpls-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: NOTRUN -> [DMESG-WARN][1] ([i915#5437])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][2] ([i915#5437])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][9] ([fdo#109278]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +13 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
- fi-cml-u2:  NOTRUN -> [SKIP][11] ([fdo#109285])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][12] ([fdo#109278] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-bxt-dsi: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-cml-u2:  NOTRUN -> [SKIP][14] ([i915#3555])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([i915#3301])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-cml-u2:  NOTRUN -> [FAIL][16] ([i915#4312] / [i915#5257])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-cml-u2/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][17] ([i915#4312] / [i915#5257])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22829/fi-bxt-dsi/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-cml-u2:  [INCOMPLETE][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/fi-cml-u2/igt@gem_exec_suspend@basic...@smem.html
   [19]:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function

2022-04-08 Thread Ville Syrjälä

On Fri, Apr 08, 2022 at 06:46:00PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 08, 2022 at 03:51:59PM +0300, Stanislav Lisovskiy wrote:
> > Currently skl_pcode_try_request function doesn't
> > properly handle return value it gets from
> > snb_pcode_rw, but treats status != 0 as success,
> > returning true, which basically doesn't allow
> > to use retry/timeout mechanisms if PCode happens
> > to be busy and returns EGAIN or some other status
> > code not equal to 0.
> > 
> > We saw this on real hw and also tried simulating this
> > by always returning -EAGAIN from snb_pcode_rw for 6 times, which
> > currently will just result in false success, while it should
> > have tried until timeout is reached:
> > 
> > [   22.357729] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > Changing CDCLK to
> > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> > [   22.357831] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 1
> > [   22.357892] i915 :00:02.0: [drm:skl_pcode_request [i915]] Success, 
> > exiting
> > [   22.357936] i915 :00:02.0: [drm] ERROR Failed to inform PCU about 
> > cdclk change (err -11, freq 307200)
> > 
> > We see en error because higher level api, still notices that status was 
> > wrong,
> > however we still did try only once.
> > 
> > We fix it by requiring _both_ the status to be 0 and
> > request/reply match for success(true) and function
> > should return failure(false) if either status turns
> > out to be EAGAIN, EBUSY or whatever or reply/request
> > masks do not match.
> > 
> > So now we see this in the logs:
> > 
> > [   22.318667] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> > Changing CDCLK to
> > 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> > [   22.318782] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 1

Hmm. That is weird. The timestamp difference is only ~100 usec even
though we are supposed to use that 500 usec timeout. So did some
previous pcode access already timeout and leave the mailbox busy 
before we even do this request, or what is going on?

> > [   22.318849] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 2
> > [   22.319006] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 3
> > [   22.319091] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 4
> > [   22.319158] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 5
> > [   22.319224] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> > EAGAIN retry 6
> > 
> > Reviewed-by: Vinod Govindapillai 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
> > b/drivers/gpu/drm/i915/intel_pcode.c
> > index 391a37492ce5..fb6c43e8a02f 100644
> > --- a/drivers/gpu/drm/i915/intel_pcode.c
> > +++ b/drivers/gpu/drm/i915/intel_pcode.c
> > @@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct 
> > drm_i915_private *i915, u32 mbox,
> >  {
> > *status = __snb_pcode_rw(i915, mbox, , NULL, 500, 0, true);
> >  
> > -   return *status || ((request & reply_mask) == reply);
> > +   return (*status == 0) && ((request & reply_mask) == reply);
> 
> The problem with this is that now we'll keep pointlessly banging it
> even if it returns a real error.
> 
> We should never really see that -EAGAIN since it indicates that our
> timeout is too short. So the real fix should be to increase that
> timeout. But I guess we could do a belt-and-suspenders approach
> where we also keep repeating on -EGAIN. But I'm thinking -EAGAIN
> should WARN as well to make sure we notice that our timeout is wrong.
> 
> >  }
> >  
> >  /**
> > -- 
> > 2.24.1.485.gad05a3d8e5
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix warnings about PSR lock not held (rev4)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Fix warnings about PSR lock not held (rev4)
URL   : https://patchwork.freedesktop.org/series/102298/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477 -> Patchwork_22828


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (47 -> 45)
--

  Additional (4): bat-jsl-2 bat-hsw-1 fi-bxt-dsi fi-icl-u2 
  Missing(6): shard-tglu fi-bsw-n3050 bat-dg2-8 fi-bsw-cyan fi-pnv-d510 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: NOTRUN -> [DMESG-WARN][1] ([i915#5437])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][2] ([i915#5437])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@core_hotunp...@unbind-rebind.html
- fi-icl-u2:  NOTRUN -> [DMESG-WARN][3] ([i915#5437])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109278]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][17] ([fdo#109271]) +13 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
- fi-cml-u2:  NOTRUN -> [SKIP][18] ([fdo#109285])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][19] ([fdo#109285])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html

  *

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function

2022-04-08 Thread Ville Syrjälä

On Fri, Apr 08, 2022 at 03:51:59PM +0300, Stanislav Lisovskiy wrote:
> Currently skl_pcode_try_request function doesn't
> properly handle return value it gets from
> snb_pcode_rw, but treats status != 0 as success,
> returning true, which basically doesn't allow
> to use retry/timeout mechanisms if PCode happens
> to be busy and returns EGAIN or some other status
> code not equal to 0.
> 
> We saw this on real hw and also tried simulating this
> by always returning -EAGAIN from snb_pcode_rw for 6 times, which
> currently will just result in false success, while it should
> have tried until timeout is reached:
> 
> [   22.357729] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> Changing CDCLK to
> 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> [   22.357831] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 1
> [   22.357892] i915 :00:02.0: [drm:skl_pcode_request [i915]] Success, 
> exiting
> [   22.357936] i915 :00:02.0: [drm] ERROR Failed to inform PCU about 
> cdclk change (err -11, freq 307200)
> 
> We see en error because higher level api, still notices that status was wrong,
> however we still did try only once.
> 
> We fix it by requiring _both_ the status to be 0 and
> request/reply match for success(true) and function
> should return failure(false) if either status turns
> out to be EAGAIN, EBUSY or whatever or reply/request
> masks do not match.
> 
> So now we see this in the logs:
> 
> [   22.318667] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] 
> Changing CDCLK to
> 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
> [   22.318782] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 1
> [   22.318849] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 2
> [   22.319006] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 3
> [   22.319091] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 4
> [   22.319158] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 5
> [   22.319224] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning 
> EAGAIN retry 6
> 
> Reviewed-by: Vinod Govindapillai 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/intel_pcode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
> b/drivers/gpu/drm/i915/intel_pcode.c
> index 391a37492ce5..fb6c43e8a02f 100644
> --- a/drivers/gpu/drm/i915/intel_pcode.c
> +++ b/drivers/gpu/drm/i915/intel_pcode.c
> @@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct drm_i915_private 
> *i915, u32 mbox,
>  {
>   *status = __snb_pcode_rw(i915, mbox, , NULL, 500, 0, true);
>  
> - return *status || ((request & reply_mask) == reply);
> + return (*status == 0) && ((request & reply_mask) == reply);

The problem with this is that now we'll keep pointlessly banging it
even if it returns a real error.

We should never really see that -EAGAIN since it indicates that our
timeout is too short. So the real fix should be to increase that
timeout. But I guess we could do a belt-and-suspenders approach
where we also keep repeating on -EGAIN. But I'm thinking -EAGAIN
should WARN as well to make sure we notice that our timeout is wrong.

>  }
>  
>  /**
> -- 
> 2.24.1.485.gad05a3d8e5

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/3] drm/debug: Expose connector's max supported bpc via debugfs

2022-04-08 Thread Modem, Bhanuprakash


On Fri-08-04-2022 08:32 pm, Harry Wentland wrote:



On 2022-04-08 02:53, Bhanuprakash Modem wrote:

It's useful to know the connector's max supported bpc for IGT
testing. Expose it via a debugfs file on the connector "output_bpc".

Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Signed-off-by: Bhanuprakash Modem 
---
  drivers/gpu/drm/drm_debugfs.c | 21 +
  1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 7f1b82dbaebb..33e5345c6f3e 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -395,6 +395,23 @@ static int vrr_range_show(struct seq_file *m, void *data)
  }
  DEFINE_SHOW_ATTRIBUTE(vrr_range);
  
+/*

+ * Returns Connector's max supported bpc through debugfs file.
+ * Example usage: cat /sys/kernel/debug/dri/0/DP-1/max_bpc


/s/max_bpc/output_bpc

Btw, in amdgpu we have both max_bpc and output_bpc.


I'll float a new rev, Thanks.

- Bhanu



Harry


+ */
+static int output_bpc_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+
+   if (connector->status != connector_status_connected)
+   return -ENODEV;
+
+   seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(output_bpc);
+
  static const struct file_operations drm_edid_fops = {
.owner = THIS_MODULE,
.open = edid_open,
@@ -437,6 +454,10 @@ void drm_debugfs_connector_add(struct drm_connector 
*connector)
debugfs_create_file("vrr_range", S_IRUGO, root, connector,
_range_fops);
  
+	/* max bpc */

+   debugfs_create_file("output_bpc", 0444, root, connector,
+   _bpc_fops);
+
if (connector->funcs->debugfs_init)
connector->funcs->debugfs_init(connector, root);
  }

Re: [Intel-gfx] [PATCH 3/3] drm/amd/display: Move connector debugfs to drm

2022-04-08 Thread Modem, Bhanuprakash


On Fri-08-04-2022 08:33 pm, Harry Wentland wrote:



On 2022-04-08 02:53, Bhanuprakash Modem wrote:

As drm_connector already have the display_info, instead of creating
"output_bpc" debugfs in vendor specific driver, move the logic to
the drm layer.

This patch will also move "Current" bpc to the crtc debugfs from
connector debugfs, since we are getting this info from crtc_state.



Does the amd_max_bpc test pass after this change?


We need IGT fix along with this change. And I have made the required 
changes in IGT: https://patchwork.freedesktop.org/series/102387/


- Bhanu



Harry


Cc: Harry Wentland 
Cc: Rodrigo Siqueira 
Signed-off-by: Bhanuprakash Modem 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  4 --
  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 38 +++
  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.h |  2 -
  3 files changed, 13 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 73423b805b54..f89651c71ec7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6615,14 +6615,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
  }
  
-#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY

  static int amdgpu_dm_crtc_late_register(struct drm_crtc *crtc)
  {
crtc_debugfs_init(crtc);
  
  	return 0;

  }
-#endif
  
  static inline int dm_set_vupdate_irq(struct drm_crtc *crtc, bool enable)

  {
@@ -6720,9 +6718,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = 
{
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
.get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
-#if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
.late_register = amdgpu_dm_crtc_late_register,
-#endif
  };
  
  static enum drm_connector_status

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index da17ece1a2c5..3ee26083920b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -873,28 +873,18 @@ static int psr_capability_show(struct seq_file *m, void 
*data)
  }
  
  /*

- * Returns the current and maximum output bpc for the connector.
- * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ * Returns the current bpc for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_bpc
   */
-static int output_bpc_show(struct seq_file *m, void *data)
+static int amdgpu_current_bpc_show(struct seq_file *m, void *data)
  {
-   struct drm_connector *connector = m->private;
-   struct drm_device *dev = connector->dev;
-   struct drm_crtc *crtc = NULL;
+   struct drm_crtc *crtc = m->private;
+   struct drm_device *dev = crtc->dev;
struct dm_crtc_state *dm_crtc_state = NULL;
int res = -ENODEV;
unsigned int bpc;
  
  	mutex_lock(>mode_config.mutex);

-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
-
-   if (connector->state == NULL)
-   goto unlock;
-
-   crtc = connector->state->crtc;
-   if (crtc == NULL)
-   goto unlock;
-
drm_modeset_lock(>mutex, NULL);
if (crtc->state == NULL)
goto unlock;
@@ -924,18 +914,15 @@ static int output_bpc_show(struct seq_file *m, void *data)
}
  
  	seq_printf(m, "Current: %u\n", bpc);

-   seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
res = 0;
  
  unlock:

-   if (crtc)
-   drm_modeset_unlock(>mutex);
-
-   drm_modeset_unlock(>mode_config.connection_mutex);
+   drm_modeset_unlock(>mutex);
mutex_unlock(>mode_config.mutex);
  
  	return res;

  }
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
  
  /*

   * Example usage:
@@ -2541,7 +2528,6 @@ static int target_backlight_show(struct seq_file *m, void 
*unused)
  DEFINE_SHOW_ATTRIBUTE(dp_dsc_fec_support);
  DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
  DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
-DEFINE_SHOW_ATTRIBUTE(output_bpc);
  DEFINE_SHOW_ATTRIBUTE(dp_lttpr_status);
  #ifdef CONFIG_DRM_AMD_DC_HDCP
  DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
@@ -2788,7 +2774,6 @@ static const struct {
const struct file_operations *fops;
  } connector_debugfs_entries[] = {
{"force_yuv420_output", _yuv420_output_fops},
-   {"output_bpc", _bpc_fops},
{"trigger_hotplug", _hotplug_debugfs_fops},
{"internal_display", _display_fops}
  };
@@ -3172,9 +3157,10 @@ static int crc_win_update_get(void *data, u64 *val)
  
  DEFINE_DEBUGFS_ATTRIBUTE(crc_win_update_fops, crc_win_update_get,

 crc_win_update_set, "%llu\n");
-
+#endif
  void crtc_debugfs_init(struct drm_crtc *crtc)
  {
+#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
struct dentry

[Intel-gfx] ✓ Fi.CI.IGT: success for Fix issues in skl_pcode_request

2022-04-08 Thread Patchwork

== Series Details ==

Series: Fix issues in skl_pcode_request
URL   : https://patchwork.freedesktop.org/series/102410/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477_full -> Patchwork_22827_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_22827_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22827_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 -> 10)
--

  Missing(1): shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [SKIP][1] ([i915#4525]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb4/igt@gem_exec_balan...@parallel-ordering.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][3] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
- shard-apl:  NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-apl4/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_suspend@basic-s0@smem:
- shard-snb:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-snb5/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-snb6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-iclb: [PASS][12] -> [DMESG-WARN][13] ([i915#4391]) +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/shard-iclb3/igt@gem_exec_suspend@basic-s4-devi...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb7/igt@gem_exec_suspend@basic-s4-devi...@smem.html

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

  * igt@gem_lmem_swapping@random-engines:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb3/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4270])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb3/igt@gem_...@create-regular-context-1.html

  * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb3/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: NOTRUN -> [WARN][18] ([i915#2684])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb8/igt@i915_pm_rc6_reside...@rc6-idle.html

  * igt@i915_pm_rpm@pc8-residency:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109293] / [fdo#109506])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/shard-iclb8/igt@i915_pm_...@pc8-residency.html

  * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#5286])
   [20]:

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-08 Thread Daniel Vetter

On Fri, 8 Apr 2022 at 12:29, Tvrtko Ursulin
 wrote:
>
>
> On 08/04/2022 10:50, Dave Airlie wrote:
> > On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 08/04/2022 08:58, Daniel Vetter wrote:
> >>> On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
>  From: Tvrtko Ursulin 
> 
>  Inherit submitter nice at point of request submission to account for long
>  running processes getting either externally or self re-niced.
> 
>  This accounts for the current processing landscape where computational
>  pipelines are composed of CPU and GPU parts working in tandem.
> 
>  Nice value will only apply to requests which originate from user contexts
>  and have default context priority. This is to avoid disturbing any
>  application made choices of low and high (batch processing and latency
>  sensitive compositing). In this case nice value adjusts the effective
>  priority in the narrow band of -19 to +20 around
>  I915_CONTEXT_DEFAULT_PRIORITY.
> 
>  This means that userspace using the context priority uapi directly has a
>  wider range of possible adjustments (in practice that only applies to
>  execlists platforms - with GuC there are only three priority buckets), 
>  but
>  in all cases nice adjustment has the expected effect: positive nice
>  lowering the scheduling priority and negative nice raising it.
> 
>  Signed-off-by: Tvrtko Ursulin 
> >>>
> >>> I don't think adding any more fancy features to i915-scheduler makes
> >>> sense, at least not before we've cut over to drm/sched.
> >>
> >> Why do you think so?
> >>
> >> Drm/sched has at least low/normal/high priority and surely we will keep
> >> the i915 context priority ABI.
> >>
> >> Then this patch is not touching the i915 scheduler at all, neither it is
> >> fancy.
> >>
> >> The cover letter explains how it implements the same approach as the IO
> >> scheduler. And it explains the reasoning and benefits. Provides an user
> >> experience benefit today, which can easily be preserved.
> >
> > won't this cause uAPI divergence between execlists and GuC, like if
> > something nices to -15 or -18 with execlists and the same with GuC it
> > won't get the same sort of result will it?
>
> Not sure what you consider new ABI divergence but the general problem
> space of execlists vs GuC priority handling is not related to this patch.

It 100% is.

Mesa only uses 3 priority levels, which means the 1k execlist levels
(or whatever it was) nonsense has not left the barn and we can get it
back in.

This here bakes it in forever as implicit uapi.

> Existing GEM context ABI has -1023 - +1023 for user priorities while GuC
> maps that to low/normal/high only. I915_CONTEXT_DEFAULT_PRIORITY is zero
> which maps to GuC normal. Negatives map to GuC low and positives to
> high. Drm/sched is I understand similar or the same.
>
> So any userspace using the existing uapi can already observe differences
> between GuC and execlists. With your example of -15 vs -18 I mean.
>
> I don't think anyone considered that a problem because execution order
> based on priority is not a hard guarantee. Neither is proportionality of
> timeslicing. Otherwise GuC would already be breaking the ABI.
>
> With this patch it simply allows external control - whereas before only
> applications could change their priorities, now users can influence the
> priority of the ones which did not bother to set a non-default priority.
>
> In the case of GuC if user says "nice 10 churn-my-dataset-on-gpu &&
> run-my-game", former part get low prio, latter gets normal. I don't see
> any issues there. Same as if the "churn-my-dataset-on-gpu" command
> implemented a command line switch which passed context priority to i915
> via the existing GEM context param ioctl.
>
> I've described the exact experiments in both modes in the cover letter
> which shows it works. (Ignoring the GuC scheduling quirk where
> apparently low-vs-normal timeslices worse than normal-vs-high).

Guc is not breaking anything because the _real_ uapi only has 3 levels
(plus one for kernel stuff on top).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH] drm/i915/uncore: Warn on previous unclaimed accesses

2022-04-08 Thread Lucas De Marchi


On Fri, Apr 08, 2022 at 01:44:44PM +0100, Tvrtko Ursulin wrote:


On 05/04/2022 01:11, Lucas De Marchi wrote:

Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers.
This register is in the display engine IP and can only ever detect
unclaimed accesses to registers in this area. However sometimes there
are reports of this triggering for registers in other areas, which
should not be possible.

Right now we always warn after the read/write of registers going through
unclaimed_reg_debug(). However places using __raw_uncore_* may be
triggering the unclaimed access and those being later accounted to a
different register. Let's warn both before and after the read/write
with a slightly different message, so it's clear if the register
reported in the warning is actually the culprit.

Signed-off-by: Lucas De Marchi 


I see this triggering a lot on drm-tip today (TGL), is that expected?

[3.994907] i915 :00:02.0: [drm:intel_uncore_init_mmio [i915]] unclaimed 
mmio detected on uncore init, clearing
[4.392525] i915 :00:02.0: Unclaimed access detected before read from 
register 0x44408
[5.669929] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[6.652808] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[   13.015978] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[   16.876802] i915 :00:02.0: Unclaimed access detected before write to 
register 0x44404
[   45.174395] i915 :00:02.0: Unclaimed access detected before write to 
register 0x44404

It continues at runtime as well:

[10265.010902] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10329.093078] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10354.060331] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10385.486480] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10408.910533] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10433.398443] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10444.110593] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10468.302627] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10493.398727] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10515.366845] i915 :00:02.0: Unclaimed access detected before read from 
register 0x44408
[10518.674046] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10529.934735] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10553.398808] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10599.684455] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc4008
[10602.898167] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10613.398909] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10686.006783] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10711.906813] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10745.860538] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10771.812277] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10805.903058] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10831.927073] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10853.398958] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10866.007084] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10879.378435] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10891.727120] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10913.395161] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10939.026480] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10964.626494] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204

It don't think this machine had a problem with this before, or perhaps it was 
going undetected?


it was going undetected. However I have a patch to downgrade the first
message to debug, because we are clear not ready to enable the stricter
check. I will send it in a bit.

Lucas De Marchi



Regards,

Tvrtko


---
 drivers/gpu/drm/i915/intel_uncore.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8b9ccc21..df59ec88459e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++

Re: [Intel-gfx] [PATCH v2 22/22] drm/i915/bios: Dump PNPID and panel name

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 09:07:19PM +0300, Jani Nikula wrote:
> On Tue, 05 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Dump the panel PNPID and name from the VBT.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 24 +++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index d561551d6324..953526a7dc5d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -25,6 +25,7 @@
> >   *
> >   */
> >  
> > +#include 
> >  #include 
> >  
> >  #include "display/intel_display.h"
> > @@ -597,6 +598,19 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
> > return NULL;
> >  }
> >  
> > +static void dump_pnp_id(struct drm_i915_private *i915,
> > +   const struct lvds_pnp_id *pnp_id,
> > +   const char *name)
> > +{
> > +   u16 mfg_name = be16_to_cpu((__force __be16)pnp_id->mfg_name);
> 
> Might just add the __be16 in the struct member?

Do we want that there since we copy the header to igt as well?

> 
> Reviewed-by: Jani Nikula 
> 
> > +   char vend[4];
> > +
> > +   drm_dbg_kms(>drm, "%s PNPID mfg: %s (0x%x), prod: %u, serial: %u, 
> > week: %d, year: %d\n",
> > +   name, drm_edid_decode_mfg_id(mfg_name, vend),
> > +   pnp_id->mfg_name, pnp_id->product_code, pnp_id->serial,
> > +   pnp_id->mfg_week, pnp_id->mfg_year + 1990);
> > +}
> > +
> >  static int pnp_id_panel_type(struct drm_i915_private *i915,
> >  const struct edid *edid)
> >  {
> > @@ -615,6 +629,8 @@ static int pnp_id_panel_type(struct drm_i915_private 
> > *i915,
> > edid_id_nodate.mfg_week = 0;
> > edid_id_nodate.mfg_year = 0;
> >  
> > +   dump_pnp_id(i915, edid_id, "EDID");
> > +
> > ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > if (!ptrs)
> > return -1;
> > @@ -802,6 +818,7 @@ parse_lfp_data(struct drm_i915_private *i915)
> > const struct bdb_lvds_lfp_data *data;
> > const struct bdb_lvds_lfp_data_tail *tail;
> > const struct bdb_lvds_lfp_data_ptrs *ptrs;
> > +   const struct lvds_pnp_id *pnp_id;
> > int panel_type = i915->vbt.panel_type;
> >  
> > ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > @@ -815,10 +832,17 @@ parse_lfp_data(struct drm_i915_private *i915)
> > if (!i915->vbt.lfp_lvds_vbt_mode)
> > parse_lfp_panel_dtd(i915, data, ptrs);
> >  
> > +   pnp_id = get_lvds_pnp_id(data, ptrs, panel_type);
> > +   dump_pnp_id(i915, pnp_id, "Panel");
> > +
> > tail = get_lfp_data_tail(data, ptrs);
> > if (!tail)
> > return;
> >  
> > +   drm_dbg_kms(>drm, "Panel name: %.*s\n",
> > +   (int)sizeof(tail->panel_name[0].name),
> > +   tail->panel_name[panel_type].name);
> > +
> > if (i915->vbt.version >= 188) {
> > i915->vbt.seamless_drrs_min_refresh_rate =
> > tail->seamless_drrs_min_refresh_rate[panel_type];
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v4 18/22] drm/i915/bios: Determine panel type via PNPID match

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 08:55:29PM +0300, Jani Nikula wrote:
> On Wed, 06 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Apparently when the VBT panel_type==0xff we should trawl through
> > the PNPID table and check for a match against the EDID. If a
> > match is found the index gives us the panel_type.
> >
> > Tried to match the Windows behaviour here with first looking
> > for an exact match, and if one isn't found we fall back to
> > looking for a match w/o the mfg year/week.
> 
> Does Windows also probe the EDID first, or does it use some side channel
> to use the GOP probed EDID? ISTR there's something in the EFI interface
> for this, but never looked deeper.

Lost some hair while trawling through it, but it does look it tries
the OpRegion mailbox first, then falls back to standard i2c stuff.

In a totally different codepath there's also an implementation of
APCI _DDC, but that doesn't seem get called from the eDP init path
that I was looking at so dunno what that is for.

> 
> >
> > v2: Rebase due to vlv_dsi changes
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5545
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Jani Nikula 
> 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
> >  drivers/gpu/drm/i915/display/intel_bios.c | 82 ---
> >  drivers/gpu/drm/i915/display/intel_bios.h |  4 +-
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
> >  drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
> >  drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
> >  drivers/gpu/drm/i915/display/vlv_dsi.c|  2 +-
> >  7 files changed, 82 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 688176d4a54a..49715485a3a6 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -2048,7 +2048,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> > /* attach connector to encoder */
> > intel_connector_attach_encoder(intel_connector, encoder);
> >  
> > -   intel_bios_init_panel(dev_priv);
> > +   intel_bios_init_panel(dev_priv, NULL);
> >  
> > mutex_lock(>mode_config.mutex);
> > intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 0e76c554581a..4c0680356134 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -582,6 +582,14 @@ get_lvds_fp_timing(const struct bdb_lvds_lfp_data 
> > *data,
> > return (const void *)data + ptrs->ptr[index].fp_timing.offset;
> >  }
> >  
> > +static const struct lvds_pnp_id *
> > +get_lvds_pnp_id(const struct bdb_lvds_lfp_data *data,
> > +   const struct bdb_lvds_lfp_data_ptrs *ptrs,
> > +   int index)
> > +{
> > +   return (const void *)data + ptrs->ptr[index].panel_pnp_id.offset;
> > +}
> > +
> >  static const struct bdb_lvds_lfp_data_tail *
> >  get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
> >   const struct bdb_lvds_lfp_data_ptrs *ptrs)
> > @@ -592,6 +600,52 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
> > return NULL;
> >  }
> >  
> > +static int pnp_id_panel_type(struct drm_i915_private *i915,
> > +const struct edid *edid)
> > +{
> > +   const struct bdb_lvds_lfp_data *data;
> > +   const struct bdb_lvds_lfp_data_ptrs *ptrs;
> > +   const struct lvds_pnp_id *edid_id;
> > +   struct lvds_pnp_id edid_id_nodate;
> > +   int i, best = -1;
> > +
> > +   if (!edid)
> > +   return -1;
> > +
> > +   edid_id = (const void *)>mfg_id[0];
> > +
> > +   edid_id_nodate = *edid_id;
> > +   edid_id_nodate.mfg_week = 0;
> > +   edid_id_nodate.mfg_year = 0;
> > +
> > +   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > +   if (!ptrs)
> > +   return -1;
> > +
> > +   data = find_section(i915, BDB_LVDS_LFP_DATA);
> > +   if (!data)
> > +   return -1;
> > +
> > +   for (i = 0; i < 16; i++) {
> > +   const struct lvds_pnp_id *vbt_id =
> > +   get_lvds_pnp_id(data, ptrs, i);
> > +
> > +   /* full match? */
> > +   if (!memcmp(vbt_id, edid_id, sizeof(*vbt_id)))
> > +   return i;
> > +
> > +   /*
> > +* Accept a match w/o date if no full match is found,
> > +* and the VBT entry does not specify a date.
> > +*/
> > +   if (best < 0 &&
> > +   !memcmp(vbt_id, _id_nodate, sizeof(*vbt_id)))
> > +   best = i;
> > +   }
> > +
> > +   return best;
> > +}
> > +
> >  static int vbt_panel_type(struct drm_i915_private *i915)
> >  {
> > const struct bdb_lvds_options *lvds_options;
> > @@ -600,7 +654,8 @@ static int vbt_panel_type(struct drm_i915_private *i915)
> > if (!lvds_options)
> > return -1;
> >  
> > -   if

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts

2022-04-08 Thread Thomas Hellström




On 3/14/22 19:20, Ramalingam C wrote:

From: Chris Wilson 

Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.

Testcase: igt/i915_selftests/gt_lrc

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Ramalingam C 


Reviewed-by: Thomas Hellström 




---
  drivers/gpu/drm/i915/gt/intel_engine_regs.h |  1 +
  drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +
  drivers/gpu/drm/i915/gt/selftest_lrc.c  |  5 +
  3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 0bf8b45c9319..d6da3bbf66f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -109,6 +109,7 @@
  #define RING_SBBSTATE(base)   _MMIO((base) + 0x118) /* hsw+ */
  #define RING_SBBADDR_UDW(base)_MMIO((base) + 0x11c) 
/* gen8+ */
  #define RING_BBADDR(base) _MMIO((base) + 0x140)
+#define RING_BB_OFFSET(base)   _MMIO((base) + 0x158)
  #define RING_BBADDR_UDW(base) _MMIO((base) + 0x168) /* gen8+ 
*/
  #define CCID(base)_MMIO((base) + 0x180)
  #define   CCID_EN BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 07bef7128fdb..f673bae97a03 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -662,6 +662,18 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs 
*engine)
return -1;
  }
  
+static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)

+{
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
+   return 0x80;
+   else if (GRAPHICS_VER(engine->i915) >= 12)
+   return 0x70;
+   else if (GRAPHICS_VER(engine->i915) >= 9)
+   return 0x64;
+   else
+   return -1;
+}
+
  static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
  {
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
@@ -768,6 +780,7 @@ static void init_common_regs(u32 * const regs,
 bool inhibit)
  {
u32 ctl;
+   int loc;
  
  	ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);

ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -779,6 +792,10 @@ static void init_common_regs(u32 * const regs,
regs[CTX_CONTEXT_CONTROL] = ctl;
  
  	regs[CTX_TIMESTAMP] = ce->runtime.last;

+
+   loc = lrc_ring_bb_offset(engine);
+   if  (loc != -1)
+   regs[loc + 1] = 0;
  }
  
  static void init_wa_bb_regs(u32 * const regs,

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 21c29d315cc0..13f57c7c4224 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -323,6 +323,11 @@ static int live_lrc_fixed(void *arg)
lrc_ring_cmd_buf_cctl(engine),
"RING_CMD_BUF_CCTL"
},
+   {
+   
i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
+   lrc_ring_bb_offset(engine),
+   "RING_BB_OFFSET"
+   },
{ },
}, *t;
u32 *hw;

Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Always cancel semaphore on error

2022-04-08 Thread Thomas Hellström




On 3/14/22 19:20, Ramalingam C wrote:

From: Chris Wilson 

Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.

Reported-by: CQ Tang 
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
cc: Joonas Lahtinen 
Signed-off-by: Ramalingam C 


Reviewed-by: Thomas Hellström 



---
  drivers/gpu/drm/i915/gt/selftest_lrc.c | 17 -
  1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index b9cc89de01bf..ae16668dd9d4 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1435,18 +1435,17 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
}
  
  	err = poison_registers(B, poison, sema);

-   if (err) {
-   WRITE_ONCE(*sema, -1);
-   i915_request_put(rq);
-   goto err_result1;
-   }
-
-   if (i915_request_wait(rq, 0, HZ / 2) < 0) {
-   i915_request_put(rq);
+   if (err == 0 && i915_request_wait(rq, 0, HZ / 2) < 0) {
+   pr_err("%s(%s): wait for results timed out\n",
+  __func__, engine->name);
err = -ETIME;
-   goto err_result1;
}
+
+   /* Always cancel the semaphore wait, just in case the GPU gets stuck */
+   WRITE_ONCE(*sema, -1);
i915_request_put(rq);
+   if (err)
+   goto err_result1;
  
  	err = compare_isolation(engine, ref, result, A, poison);

Re: [Intel-gfx] [PATCH 3/4] drm/i915/selftest: Clear the output buffers before GPU writes

2022-04-08 Thread Thomas Hellström




On 3/14/22 19:20, Ramalingam C wrote:

From: Chris Wilson 

When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a)
so that is both non-zero and distinct from the poison values used during
the test.

Reported-by: CQ Tang 
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
cc: Joonas Lahtinen 
Signed-off-by: Ramalingam C 


Reviewed-by: Thomas Hellström 




---
  drivers/gpu/drm/i915/gt/selftest_lrc.c | 32 ++
  1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 0a8ed4246082..b9cc89de01bf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1346,6 +1346,30 @@ static int compare_isolation(struct intel_engine_cs 
*engine,
return err;
  }
  
+static struct i915_vma *

+create_result_vma(struct i915_address_space *vm, unsigned long sz)
+{
+   struct i915_vma *vma;
+   void *ptr;
+
+   vma = create_user_vma(vm, sz);
+   if (IS_ERR(vma))
+   return vma;
+
+   /* Set the results to a known value distinct from the poison */
+   ptr = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+   if (IS_ERR(ptr)) {
+   i915_vma_put(vma);
+   return ERR_CAST(ptr);
+   }
+
+   memset(ptr, POISON_INUSE, vma->size);
+   i915_gem_object_flush_map(vma->obj);
+   i915_gem_object_unpin_map(vma->obj);
+
+   return vma;
+}
+
  static int __lrc_isolation(struct intel_engine_cs *engine, u32 poison)
  {
u32 *sema = memset32(engine->status_page.addr + 1000, 0, 1);
@@ -1364,13 +1388,13 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
goto err_A;
}
  
-	ref[0] = create_user_vma(A->vm, SZ_64K);

+   ref[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[0])) {
err = PTR_ERR(ref[0]);
goto err_B;
}
  
-	ref[1] = create_user_vma(A->vm, SZ_64K);

+   ref[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[1])) {
err = PTR_ERR(ref[1]);
goto err_ref0;
@@ -1392,13 +1416,13 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
}
i915_request_put(rq);
  
-	result[0] = create_user_vma(A->vm, SZ_64K);

+   result[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[0])) {
err = PTR_ERR(result[0]);
goto err_ref1;
}
  
-	result[1] = create_user_vma(A->vm, SZ_64K);

+   result[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[1])) {
err = PTR_ERR(result[1]);
goto err_result0;

Re: [Intel-gfx] [PATCH 2/4] drm/i915/selftests: Check for incomplete LRI from the context image

2022-04-08 Thread Intel




On 3/14/22 19:20, Ramalingam C wrote:

From: Chris Wilson 

In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
interpretting context data as instructions. Eventually, as Daniele


interpreting



discovered, this would lead us to find addition LRI as part of the data
and mistakenly add invalid LRI commands to the context probes.

Stop parsing after we see the first !MI command, as we know we will have
seen all the context registers by that point. (Mostly true for all gen so far,
though the render context does have LRI after the first page that we
have been ignoring so far. It would be useful to extract those as well
so that we have the full list of user accesisble registers.)

accessible


Similarly, emit a warning if we do try to emit an invalid zero-length
LRI.

Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Ramalingam C 


Acked-by: Thomas Hellström 





---
  drivers/gpu/drm/i915/gt/selftest_lrc.c | 61 +++---
  1 file changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 13f57c7c4224..0a8ed4246082 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,6 +27,9 @@
  #define NUM_GPR 16
  #define NUM_GPR_DW (NUM_GPR * 2) /* each GPR is 2 dwords */
  
+#define LRI_HEADER MI_INSTR(0x22, 0)

+#define LRI_LENGTH_MASK GENMASK(7, 0)
+
  static struct i915_vma *create_scratch(struct intel_gt *gt)
  {
return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
@@ -180,7 +183,7 @@ static int live_lrc_layout(void *arg)
continue;
}
  
-			if ((lri & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {

+   if ((lri & GENMASK(31, 23)) != LRI_HEADER) {
pr_err("%s: Expected LRI command at dword %d, found 
%08x\n",
   engine->name, dw, lri);
err = -EINVAL;
@@ -945,18 +948,40 @@ store_context(struct intel_context *ce, struct i915_vma 
*scratch)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
-   u32 len = hw[dw] & 0x7f;
+   u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+   /*
+* Keep it simple, skip parsing complex commands
+*
+* At present, there are no more MI_LOAD_REGISTER_IMM
+* commands after the first 3D state command. Rather
+* than include a table (see i915_cmd_parser.c) of all
+* the possible commands and their instruction lengths
+* (or mask for variable length instructions), assume
+* we have gathered the complete list of registers and
+* bail out.
+*/
+   if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+   break;
  
  		if (hw[dw] == 0) {

dw++;
continue;
}
  
-		if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {

+   if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
+   /* Assume all other MI commands match LRI length mask */
dw += len + 2;
continue;
}
  
+		if (!len) {

+   pr_err("%s: invalid LRI found in context image\n",
+  ce->engine->name);
+   igt_hexdump(defaults, PAGE_SIZE);
+   break;
+   }
+
dw++;
len = (len + 1) / 2;
while (len--) {
@@ -1108,18 +1133,29 @@ static struct i915_vma *load_context(struct 
intel_context *ce, u32 poison)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
-   u32 len = hw[dw] & 0x7f;
+   u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+   /* For simplicity, break parsing at the first complex command */
+   if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+   break;
  
  		if (hw[dw] == 0) {

dw++;
continue;
}
  
-		if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {

+   if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
dw += len + 2;
continue;
}
  
+		if (!len) {

+   pr_err("%s: invalid LRI found in context image\n",
+  ce->engine->name);
+   igt_hexdump(defaults, PAGE_SIZE);
+

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Fix warnings about PSR lock not held (rev4)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Fix warnings about PSR lock not held (rev4)
URL   : https://patchwork.freedesktop.org/series/102298/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11477 -> Patchwork_22828


Summary
---

  **FAILURE**

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

Participating hosts (47 -> 37)
--

  Additional (2): fi-bxt-dsi fi-icl-u2 
  Missing(12): fi-bdw-samus shard-tglu bat-dg1-6 fi-bsw-n3050 bat-dg2-8 
bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-pnv-d510 bat-rpls-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-icl-u2:  NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: NOTRUN -> [DMESG-WARN][2] ([i915#5437])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][3] ([i915#5437])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109278]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22828/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][17] ([fdo#109271]) +13 similar issues

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Fix warnings about PSR lock not held (rev3)

2022-04-08 Thread Vudum, Lakshminarayana

Issue is related to
https://gitlab.freedesktop.org/drm/intel/-/issues/5602
All tests - *ERROR* Scratch setup failed, DEBUG_LOCKS_WARN_ON(lock->magic != 
lock)

Lakshmi.

From: Souza, Jose 
Sent: Thursday, April 7, 2022 2:05 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/display: Fix warnings about PSR 
lock not held (rev3)

On Thu, 2022-04-07 at 21:01 +, Patchwork wrote:
Patch Details
Series:

drm/i915/display: Fix warnings about PSR lock not held (rev3)

URL:

https://patchwork.freedesktop.org/series/102298/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/index.html

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22818
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22818, 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_22818/index.html

Participating hosts (48 -> 46)

Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4
Missing (6): shard-tglu shard-rkl fi-bsw-cyan bat-rpls-1 fi-blb-e6850 
fi-bdw-samus

Possible new issues

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

CI changes
Possible regressions

  *   boot:

 *   fi-bwr-2160: NOTRUN -> 
FAIL

Hi Lakshmi

Can you please take a look at this?
There is other series with the same failure: 
https://patchwork.freedesktop.org/series/102333/

IGT changes
Possible regressions

  *   igt@gem_lmem_swapping@basic:

 *   bat-dg1-5: NOTRUN -> 
SKIP
 +2 similar issues
 *   fi-cfl-8109u: NOTRUN -> 
FAIL

Warnings

  *   igt@runner@aborted:

 *   fi-rkl-11600: 
FAIL
 (i915#4312) -> 
FAIL
 *   fi-kbl-guc: 
FAIL
 (i915#4312 / 
i915#5257) -> 
FAIL

Suppressed

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

  *   igt@runner@aborted:

 *   {bat-hsw-1}: NOTRUN -> 
FAIL

Known issues

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

IGT changes
Issues hit

  *   igt@core_auth@basic-auth:

 *   fi-kbl-8809g: NOTRUN -> 
SKIP
 (fdo#109271) +1 similar 
issue

  *   igt@fbdev@eof:

 *   fi-kbl-8809g: NOTRUN -> 
INCOMPLETE
 (i915#5557)

  *   igt@fbdev@write:

 *   bat-dg1-5: NOTRUN -> 
SKIP
 (i915#2582) +4 similar 
issues

  *   igt@gem_close_race@basic-process:

 *   fi-ivb-3770: NOTRUN -> 
SKIP
 (fdo#109271) +146 similar 
issues

  *   igt@kms_flip@basic-flip-vs-dpms:

 *   fi-kbl-soraka: NOTRUN -> 
SKIP
 (fdo#109271) +146 similar 
issues

  *   igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:

 *   fi-cfl-8109u: NOTRUN -> 
SKIP
 (fdo#109271) +145 similar 
issues

  *   igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:

 *   bat-dg1-5: NOTRUN ->

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL

2022-04-08 Thread Vudum, Lakshminarayana

Regression is related to https://gitlab.freedesktop.org/drm/intel/-/issues/5602
All tests - *ERROR* Scratch setup failed, DEBUG_LOCKS_WARN_ON(lock->magic != 
lock)

Lakshmi.

-Original Message-
From: Roper, Matthew D  
Sent: Thursday, April 7, 2022 4:15 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915: Sunset igpu legacy mmap support 
based on GRAPHICS_VER_FULL

On Thu, Apr 07, 2022 at 10:23:34PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
> URL   : https://patchwork.freedesktop.org/series/102352/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22819 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_22819 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_22819, 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_22819/index.html
> 
> Participating hosts (49 -> 35)
> --
> 
>   Additional (1): fi-bwr-2160 
>   Missing(15): fi-bdw-samus shard-tglu bat-adls-5 bat-dg1-6 bat-dg1-5 
> bat-dg2-8 shard-rkl bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-rpls-1 fi-blb-e6850 
> shard-dg1 bat-jsl-2 bat-jsl-1 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22819:
> 
> ### CI changes ###
> 
>  Possible regressions 
> 
>   * boot:
> - fi-bwr-2160:NOTRUN -> [FAIL][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-bwr-2160/b
> oot.html
> 

It looks like something failed during the initial driver probe (not sure what; 
there don't seem to be any obvious warnings/errors) and then driver cleanup 
started triggering more warnings and an eventual panic since not everything 
being cleaned up had been fully setup at that point.

Not related to this patch (which shouldn't have any functional impact on any 
currently-existing platform).


Matt

>   
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_lmem_swapping@basic:
> - fi-cfl-8109u:   NOTRUN -> [FAIL][2]
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-cfl-8109u/
> igt@gem_lmem_swapp...@basic.html
> 
>   
>  Warnings 
> 
>   * igt@runner@aborted:
> - fi-kbl-x1275:   [FAIL][3] ([i915#4312]) -> [FAIL][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-x1275/igt@run...@aborted.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-x1275/igt@run...@aborted.html
> - fi-kbl-guc: [FAIL][5] ([i915#4312] / [i915#5257]) -> [FAIL][6]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-guc/igt@run...@aborted.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-guc/igt@run...@aborted.html
> - fi-kbl-7567u:   [FAIL][7] ([i915#4312]) -> [FAIL][8]
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-7567u/igt@run...@aborted.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-7567u/
> igt@run...@aborted.html
> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@runner@aborted:
> - {fi-jsl-1}: [FAIL][9] ([i915#4312]) -> [FAIL][10]
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-jsl-1/igt@run...@aborted.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-jsl-1/igt@
> run...@aborted.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22819 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@core_auth@basic-auth:
> - fi-kbl-8809g:   NOTRUN -> [SKIP][11] ([fdo#109271]) +1 similar issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-8809g/
> igt@core_a...@basic-auth.html
> 
>   * igt@fbdev@eof:
> - fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][12] ([i915#5557])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-8809g/
> igt@fb...@eof.html
> 
>   * igt@gem_close_race@basic-process:
> - fi-ivb-3770:NOTRUN -> [SKIP][13] ([fdo#109271]) +146 similar 
> issues
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-ivb-3770/i
> gt@gem_close_r...@basic-process.html
> 
>   * igt@kms_flip@basic-flip-vs-dpms:
> - fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271]) +146 similar 
> issues
>[14]: 
>

Re: [Intel-gfx] [PATCH v2 17/22] drm/i915/bios: Refactor panel_type code

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 08:49:00PM +0300, Jani Nikula wrote:
> On Tue, 05 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Make the panel type code a bit more abstract along the
> > lines of the source of the panel type. For the moment
> > we have three classes: OpRegion, VBT, fallback.
> > Well introduce another one shortly.
> >
> > We can now also print out all the different panel types,
> > and indicate which one we ultimately selected. Could help
> > with debugging.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 47 ---
> >  1 file changed, 34 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 26839263abf0..feef5aa97398 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -606,25 +606,46 @@ static int vbt_panel_type(struct drm_i915_private 
> > *i915)
> > return lvds_options->panel_type;
> >  }
> >  
> > +enum panel_type {
> > +   PANEL_TYPE_OPREGION,
> > +   PANEL_TYPE_VBT,
> > +   PANEL_TYPE_FALLBACK,
> > +};
> > +
> >  static int get_panel_type(struct drm_i915_private *i915)
> >  {
> > -   int ret;
> > +   struct {
> > +   const char *name;
> > +   int panel_type;
> > +   } panel_types[] = {
> > +   [PANEL_TYPE_OPREGION] = { .name = "OpRegion", .panel_type = -1, 
> > },
> > +   [PANEL_TYPE_VBT] = { .name = "VBT", .panel_type = -1, },
> > +   [PANEL_TYPE_FALLBACK] = { .name = "fallback", .panel_type = 0, 
> > },
> > +   };
> > +   int i;
> >  
> > -   ret = intel_opregion_get_panel_type(i915);
> > -   if (ret >= 0) {
> > -   drm_WARN_ON(>drm, ret > 0xf);
> > -   drm_dbg_kms(>drm, "Panel type: %d (OpRegion)\n", ret);
> > -   return ret;
> > -   }
> > +   panel_types[PANEL_TYPE_OPREGION].panel_type = 
> > intel_opregion_get_panel_type(i915);
> > +   panel_types[PANEL_TYPE_VBT].panel_type = vbt_panel_type(i915);
> 
> I'd probably add a function pointer in the array, to be able to call
> these nicely in the loop. Needs a static wrapper function for
> intel_opregion_get_panel_type() in the follow-up to eat the edid
> parameter, but I think it's worth it.

Sure.

> 
> > +
> > +   for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
> > +   drm_WARN_ON(>drm, panel_types[i].panel_type > 0xf);
> 
> I know that's loud, but it's kind of annoying that the out of bounds
> value still goes through here.
> 
> >  
> > -   ret = vbt_panel_type(i915);
> > -   if (ret >= 0) {
> > -   drm_WARN_ON(>drm, ret > 0xf);
> > -   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n", ret);
> > -   return ret;
> > +   if (panel_types[i].panel_type >= 0)
> > +   drm_dbg_kms(>drm, "Panel type (%s): %d\n",
> > +   panel_types[i].name, 
> > panel_types[i].panel_type);
> > }
> >  
> > -   return 0; /* fallback */
> > +   if (panel_types[PANEL_TYPE_OPREGION].panel_type >= 0)
> > +   i = PANEL_TYPE_OPREGION;
> > +   else if (panel_types[PANEL_TYPE_VBT].panel_type >= 0)
> > +   i = PANEL_TYPE_VBT;
> > +   else
> > +   i = PANEL_TYPE_FALLBACK;
> 
> At this stage, we could set this in the loop too, but dunno how
> complicated that gets with the pnpid match rules.

I don't think the PNPID stuff really lends itself well to a loop
since it needs to consider both the VBT and PNPID pane types at
the same time.

> 
> Reviewed-by: Jani Nikula 
> 
> > +
> > +   drm_dbg_kms(>drm, "Selected panel type (%s): %d\n",
> > +   panel_types[i].name, panel_types[i].panel_type);
> > +
> > +   return panel_types[i].panel_type;
> >  }
> >  
> >  /* Parse general panel options */
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2 12/22] drm/i915/bios: Split VBT parsing to global vs. panel specific parts

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 08:23:03PM +0300, Jani Nikula wrote:
> On Tue, 05 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Parsing the panel specific data from VBT is currently happening
> > too early. Split the whole thing into global vs. panel specific
> > parts so that we can start doing the panel specific parsing at
> > a later time.
> 
> Might want to mention panel_type here somewhere, that's basically the
> split, right?

Yep. I'll try to clarify the commit msg a bit.

> 
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c| 50 +---
> >  drivers/gpu/drm/i915/display/intel_bios.h|  1 +
> >  drivers/gpu/drm/i915/display/intel_display.c |  1 +
> >  3 files changed, 35 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 1a7f1aa79827..da2b1932e10d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -723,6 +723,9 @@ parse_generic_dtd(struct drm_i915_private *i915)
> > struct drm_display_mode *panel_fixed_mode;
> > int num_dtd;
> >  
> > +   if (i915->vbt.lfp_lvds_vbt_mode)
> > +   return;
> > +
> > generic_dtd = find_section(i915, BDB_GENERIC_DTD);
> > if (!generic_dtd)
> > return;
> > @@ -891,6 +894,9 @@ parse_sdvo_panel_data(struct drm_i915_private *i915)
> > struct drm_display_mode *panel_fixed_mode;
> > int index;
> >  
> > +   if (i915->vbt.sdvo_lvds_vbt_mode)
> > +   return;
> > +
> > index = i915->params.vbt_sdvo_panel_type;
> > if (index == -2) {
> > drm_dbg_kms(>drm,
> > @@ -1419,6 +1425,9 @@ parse_mipi_config(struct drm_i915_private *i915)
> > int panel_type = i915->vbt.panel_type;
> > enum port port;
> >  
> > +   if (i915->vbt.dsi.config)
> > +   return;
> > +
> > /* parse MIPI blocks only if LFP type is MIPI */
> > if (!intel_bios_is_dsi_present(i915, ))
> > return;
> > @@ -1739,6 +1748,9 @@ parse_mipi_sequence(struct drm_i915_private *i915)
> > u8 *data;
> > int index = 0;
> >  
> > +   if (i915->vbt.dsi.data)
> > +   return;
> > +
> 
> All of the above checks to (presumably) allow calling
> intel_bios_init_panel() multiple times feel a bit out of place here. At
> the very least need a mention in the commit message.

I can split that out for clarity. I didn't have these originally but
given the current reliance on the i915->vbt singleton I got a bit
scared what would happen on some weird machines with multiple panels.
IIRC some kind of native LVDS + SDVO LVDS machines may have existed
at some point.

Plenty of refactoring left here to split the parsed data to proper
per-panel things...

> 
> Regardless,
> 
> Reviewed-by: Jani Nikula 
> 
> 
> > /* Only our generic panel driver uses the sequence block. */
> > if (i915->vbt.dsi.panel_id != MIPI_DSI_GENERIC_PANEL_ID)
> > return;
> > @@ -2878,6 +2890,27 @@ void intel_bios_init(struct drm_i915_private *i915)
> > /* Grab useful general definitions */
> > parse_general_features(i915);
> > parse_general_definitions(i915);
> > +   parse_driver_features(i915);
> > +
> > +   /* Depends on child device list */
> > +   parse_compression_parameters(i915);
> > +
> > +out:
> > +   if (!vbt) {
> > +   drm_info(>drm,
> > +"Failed to find VBIOS tables (VBT)\n");
> > +   init_vbt_missing_defaults(i915);
> > +   }
> > +
> > +   /* Further processing on pre-parsed or generated child device data */
> > +   parse_sdvo_device_mapping(i915);
> > +   parse_ddi_ports(i915);
> > +
> > +   kfree(oprom_vbt);
> > +}
> > +
> > +void intel_bios_init_panel(struct drm_i915_private *i915)
> > +{
> > parse_panel_options(i915);
> > /*
> >  * Older VBTs provided DTD information for internal displays through
> > @@ -2892,29 +2925,12 @@ void intel_bios_init(struct drm_i915_private *i915)
> > parse_lfp_data(i915);
> > parse_lfp_backlight(i915);
> > parse_sdvo_panel_data(i915);
> > -   parse_driver_features(i915);
> > parse_panel_driver_features(i915);
> > parse_power_conservation_features(i915);
> > parse_edp(i915);
> > parse_psr(i915);
> > parse_mipi_config(i915);
> > parse_mipi_sequence(i915);
> > -
> > -   /* Depends on child device list */
> > -   parse_compression_parameters(i915);
> > -
> > -out:
> > -   if (!vbt) {
> > -   drm_info(>drm,
> > -"Failed to find VBIOS tables (VBT)\n");
> > -   init_vbt_missing_defaults(i915);
> > -   }
> > -
> > -   /* Further processing on pre-parsed or generated child device data */
> > -   parse_sdvo_device_mapping(i915);
> > -   parse_ddi_ports(i915);
> > -
> > -   kfree(oprom_vbt);
> >  }
> >  
> >  /**
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
> > b/drivers/gpu/drm/i915/display/intel_bios.h
> > index

Re: [Intel-gfx] [PATCH v9 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g

2022-04-08 Thread Wang, Zhi A

Hi Jani:

Thanks so much for the help. Can you generate a new tag on drm-intel-next? I 
noticed that there was one patch moving the DMC related registers into 
display/intel_dmc_regs.h, which is not included in the latest tag on 
drm-intel-next.

Guess it would be better that I can change this patch according to it when 
checking in. This would prevent a conflict in future.

Thanks,
Zhi.

On 4/7/22 3:03 PM, Jani Nikula wrote:
> On Thu, 07 Apr 2022, Zhi Wang  wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_gvt.h 
>> b/drivers/gpu/drm/i915/intel_gvt.h
>> index d7d3fb6186fd..7665d7cf0bdd 100644
>> --- a/drivers/gpu/drm/i915/intel_gvt.h
>> +++ b/drivers/gpu/drm/i915/intel_gvt.h
>> @@ -26,7 +26,17 @@
>>  
>>  struct drm_i915_private;
>>  
>> +#include 
> 
> You only need . Please add it before the forward
> declaration above.
> 
>> +
>>  #ifdef CONFIG_DRM_I915_GVT
>> +
>> +struct intel_gvt_mmio_table_iter {
>> +struct drm_i915_private *i915;
>> +void *data;
>> +int (*handle_mmio_cb)(struct intel_gvt_mmio_table_iter *iter,
>> +  u32 offset, u32 size);
>> +};
>> +
>>  int intel_gvt_init(struct drm_i915_private *dev_priv);
>>  void intel_gvt_driver_remove(struct drm_i915_private *dev_priv);
>>  int intel_gvt_init_device(struct drm_i915_private *dev_priv);
>> @@ -34,6 +44,7 @@ void intel_gvt_clean_device(struct drm_i915_private 
>> *dev_priv);
>>  int intel_gvt_init_host(void);
>>  void intel_gvt_sanitize_options(struct drm_i915_private *dev_priv);
>>  void intel_gvt_resume(struct drm_i915_private *dev_priv);
>> +int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter);
>>  #else
>>  static inline int intel_gvt_init(struct drm_i915_private *dev_priv)
>>  {
>> @@ -51,6 +62,16 @@ static inline void intel_gvt_sanitize_options(struct 
>> drm_i915_private *dev_priv)
>>  static inline void intel_gvt_resume(struct drm_i915_private *dev_priv)
>>  {
>>  }
>> +
>> +unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915)
>> +{
>> +return 0;
>> +}
> 
> The CONFIG_DRM_I915_GVT=y counterpart for this is in mmio.h. Should be
> both in the same header.
> 
>> +
>> +int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter)
>> +{
>> +return 0;
>> +}
>>  #endif
>>  
>>  #endif /* _INTEL_GVT_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c 
>> b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>> new file mode 100644
>> index ..d29491a6d209
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>> @@ -0,0 +1,1290 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2020 Intel Corporation
>> + */
>> +
>> +#include "i915_drv.h"
>> +#include "i915_reg.h"
>> +#include "display/vlv_dsi_pll_regs.h"
>> +#include "gt/intel_gt_regs.h"
>> +#include "intel_mchbar_regs.h"
>> +#include "i915_pvinfo.h"
>> +#include "intel_gvt.h"
>> +#include "gvt/gvt.h"
> 
> Generally we have the include lists sorted.
> 
> Other than the nitpicks above, the series is
> 
> Acked-by: Jani Nikula 
> 
> 
> BR,
> Jani.
> 
>

Re: [Intel-gfx] [PATCH v3 09/22] drm/i915/bios: Get access to the tail end of the LFP data block

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 08:07:24PM +0300, Jani Nikula wrote:
> On Wed, 06 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > We need to start parsing stuff from the tail end of the LFP data block.
> > This is made awkward by the fact that the fp_timing table has variable
> > size. So we must use a bit more finesse to get the tail end, and to
> > make sure we allocate enough memory for it to make sure our struct
> > representation fits.
> >
> > v2: Rebase due to the preallocation of BDB blocks
> > v3: Rebase due to min_size WARN relocation
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 39 ++-
> >  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 17 
> >  2 files changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index d32091dad1b0..9a14d55b636c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -188,7 +188,7 @@ static const struct {
> > { .section_id = BDB_LVDS_LFP_DATA_PTRS,
> >   .min_size = sizeof(struct bdb_lvds_lfp_data_ptrs), },
> > { .section_id = BDB_LVDS_LFP_DATA,
> > - .min_size = sizeof(struct bdb_lvds_lfp_data), },
> > + .min_size = 0, /* special case */ },
> > { .section_id = BDB_LVDS_BACKLIGHT,
> >   .min_size = sizeof(struct bdb_lfp_backlight_data), },
> > { .section_id = BDB_LFP_POWER,
> > @@ -203,6 +203,23 @@ static const struct {
> >   .min_size = sizeof(struct bdb_generic_dtd), },
> >  };
> >  
> > +static size_t lfp_data_min_size(struct drm_i915_private *i915)
> > +{
> > +   const struct bdb_lvds_lfp_data_ptrs *ptrs;
> > +   size_t size;
> > +
> > +   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> 
> This depends on that block having been initialized before. Maybe the
> ordering requirement deserves a comment in bdb_blocks[].

Sure.

> 
> > +   if (!ptrs)
> > +   return 0;
> > +
> > +   size = sizeof(struct bdb_lvds_lfp_data);
> 
> Basically that and the struct definition are bogus, though? They assume
> a rigid structure. It might be true for some specific platforms, but
> generally likely not.
> 
> Or we could of course just add a comment about that in intel_vbt_defs.h.

I think I had that at some point. But I guess I lost it during
one of the many rewrites I did to this stuff.

> 
> > +   if (ptrs->panel_name.table_size)
> > +   size = max(size, ptrs->panel_name.offset +
> > +  sizeof(struct bdb_lvds_lfp_data_tail));
> > +
> > +   return size;
> > +}
> > +
> >  static bool validate_lfp_data_ptrs(const void *bdb,
> >const struct bdb_lvds_lfp_data_ptrs *ptrs)
> >  {
> > @@ -492,6 +509,9 @@ static void init_bdb_blocks(struct drm_i915_private 
> > *i915,
> > enum bdb_block_id section_id = bdb_blocks[i].section_id;
> > size_t min_size = bdb_blocks[i].min_size;
> >  
> > +   if (section_id == BDB_LVDS_LFP_DATA)
> > +   min_size = lfp_data_min_size(i915);
> 
> Nitpick, could also leave the "default" min size in bdb_blocks[], have
> lfp_data_min_size() return the other value or 0, and have the max()
> here. *shrug*

Could work. I was also pondering making .min_size a vfunc, but that
would lead to excessive boilerplate for all the other blocks. If only
we had lambdas...

> 
> > +
> > init_bdb_block(i915, bdb, section_id, min_size);
> > }
> >  }
> > @@ -562,6 +582,16 @@ get_lvds_fp_timing(const struct bdb_lvds_lfp_data 
> > *data,
> > return (const void *)data + ptrs->ptr[index].fp_timing.offset;
> >  }
> >  
> > +static const struct bdb_lvds_lfp_data_tail *
> > +get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
> > + const struct bdb_lvds_lfp_data_ptrs *ptrs)
> > +{
> > +   if (ptrs->panel_name.table_size)
> > +   return (const void *)data + ptrs->panel_name.offset;
> > +   else
> > +   return NULL;
> > +}
> > +
> >  /* Parse general panel options */
> >  static void
> >  parse_panel_options(struct drm_i915_private *i915)
> > @@ -666,6 +696,7 @@ static void
> >  parse_lfp_data(struct drm_i915_private *i915)
> >  {
> > const struct bdb_lvds_lfp_data *data;
> > +   const struct bdb_lvds_lfp_data_tail *tail;
> > const struct bdb_lvds_lfp_data_ptrs *ptrs;
> >  
> > ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > @@ -678,6 +709,12 @@ parse_lfp_data(struct drm_i915_private *i915)
> >  
> > if (!i915->vbt.lfp_lvds_vbt_mode)
> > parse_lfp_panel_dtd(i915, data, ptrs);
> > +
> > +   tail = get_lfp_data_tail(data, ptrs);
> > +   if (!tail)
> > +   return;
> > +
> > +   (void)tail;
> 
> Mmmkay.
> 
> Reviewed-by: Jani Nikula 
> 
> >  }
> >  
> >  static void
> > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
> > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > index

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix issues in skl_pcode_request

2022-04-08 Thread Patchwork

== Series Details ==

Series: Fix issues in skl_pcode_request
URL   : https://patchwork.freedesktop.org/series/102410/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11477 -> Patchwork_22827


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (47 -> 37)
--

  Additional (1): fi-bxt-dsi 
  Missing(11): fi-bdw-samus fi-bdw-5557u shard-tglu bat-dg1-6 bat-dg2-8 
bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-rpls-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: NOTRUN -> [DMESG-WARN][1] ([i915#5437])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][2] ([i915#5437])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][7] -> [DMESG-FAIL][8] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][11] ([fdo#109278]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-tgl-u2:  [PASS][12] -> [DMESG-WARN][13] ([i915#402])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11477/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][14] ([fdo#109271]) +13 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-kbl-guc: NOTRUN -> [SKIP][16] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-kbl-guc/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][17] ([fdo#109278] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-bxt-dsi: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-cml-u2:  NOTRUN -> [SKIP][19] ([i915#3555])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22827/fi-cml-u2/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
-

Re: [Intel-gfx] [PATCH v2 07/22] drm/i915/bios: Reorder panel DTD parsing

2022-04-08 Thread Ville Syrjälä

On Thu, Apr 07, 2022 at 07:21:44PM +0300, Jani Nikula wrote:
> On Tue, 05 Apr 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Reorder things so that we can parse the entier LFP data block
> 
> *entire
> 
> > in one go. For now we just stick to parsing the DTD from it.
> >
> > Also fix the misleading comment about block 42 being deprecated.
> > Only the DTD part is deprecated, the rest is still very much needed.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 62 ---
> >  1 file changed, 32 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 799c1fe36b23..f90991cac438 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -488,25 +488,16 @@ parse_panel_options(struct drm_i915_private *i915)
> > }
> >  }
> >  
> > -/* Try to find integrated panel timing data */
> >  static void
> > -parse_lfp_panel_dtd(struct drm_i915_private *i915)
> > +parse_lfp_panel_dtd(struct drm_i915_private *i915,
> > +   const struct bdb_lvds_lfp_data *lvds_lfp_data,
> > +   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs)
> >  {
> > -   const struct bdb_lvds_lfp_data *lvds_lfp_data;
> > -   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
> > const struct lvds_dvo_timing *panel_dvo_timing;
> > const struct lvds_fp_timing *fp_timing;
> > struct drm_display_mode *panel_fixed_mode;
> > int panel_type = i915->vbt.panel_type;
> >  
> > -   lvds_lfp_data = find_section(i915, BDB_LVDS_LFP_DATA);
> > -   if (!lvds_lfp_data)
> > -   return;
> > -
> > -   lvds_lfp_data_ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > -   if (!lvds_lfp_data_ptrs)
> > -   return;
> > -
> > panel_dvo_timing = get_lvds_dvo_timing(lvds_lfp_data,
> >lvds_lfp_data_ptrs,
> >panel_type);
> > @@ -537,6 +528,24 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915)
> > }
> >  }
> >  
> > +static void
> > +parse_lfp_data(struct drm_i915_private *i915)
> > +{
> > +   const struct bdb_lvds_lfp_data *data;
> > +   const struct bdb_lvds_lfp_data_ptrs *ptrs;
> > +
> > +   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
> > +   if (!ptrs)
> > +   return;
> > +
> > +   data = find_section(i915, BDB_LVDS_LFP_DATA);
> > +   if (!data)
> > +   return;
> > +
> > +   if (!i915->vbt.lfp_lvds_vbt_mode)
> > +   parse_lfp_panel_dtd(i915, data, ptrs);
> 
> Could do an early return on i915->vbt.lfp_lvds_vbt_mode.

I'm adding more stuff that we don't want to skip to the end of
the function in later patches.

> 
> > +}
> > +
> >  static void
> >  parse_generic_dtd(struct drm_i915_private *i915)
> >  {
> > @@ -615,23 +624,6 @@ parse_generic_dtd(struct drm_i915_private *i915)
> > i915->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
> >  }
> >  
> > -static void
> > -parse_panel_dtd(struct drm_i915_private *i915)
> > -{
> > -   /*
> > -* Older VBTs provided provided DTD information for internal displays
> > -* through the "LFP panel DTD" block (42).  As of VBT revision 229,
> > -* that block is now deprecated and DTD information should be provided
> > -* via a newer "generic DTD" block (58).  Just to be safe, we'll
> > -* try the new generic DTD block first on VBT >= 229, but still fall
> > -* back to trying the old LFP block if that fails.
> > -*/
> > -   if (i915->vbt.version >= 229)
> > -   parse_generic_dtd(i915);
> > -   if (!i915->vbt.lfp_lvds_vbt_mode)
> > -   parse_lfp_panel_dtd(i915);
> > -}
> > -
> >  static void
> >  parse_lfp_backlight(struct drm_i915_private *i915)
> >  {
> > @@ -2708,7 +2700,17 @@ void intel_bios_init(struct drm_i915_private *i915)
> > parse_general_features(i915);
> > parse_general_definitions(i915);
> > parse_panel_options(i915);
> > -   parse_panel_dtd(i915);
> > +   /*
> > +* Older VBTs provided DTD information for internal displays through
> > +* the "LFP panel tables" block (42).  As of VBT revision 229 the
> > +* DTD information should be provided via a newer "generic DTD"
> > +* block (58).  Just to be safe, we'll try the new generic DTD block
> > +* first on VBT >= 229, but still fall back to trying the old LFP
> > +* block if that fails.
> > +*/
> > +   if (i915->vbt.version >= 229)
> 
> I'd probably stick the vbt version check and the comment in
> parse_generic_dtd() instead of polluting the top level.

I suppose. Although that does make the ordering requirement between
parse_generic_dtd() vs. parse_lfp_data() a bit less clear. But maybe
this will all be rather temporary and we'll start transitioning
to a more on-demand based parsing of each thing.

> 
> Up to you if you want to do anything about the nitpicks,
> 
> Reviewed-by:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix issues in skl_pcode_request

2022-04-08 Thread Patchwork

== Series Details ==

Series: Fix issues in skl_pcode_request
URL   : https://patchwork.freedesktop.org/series/102410/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6934e112b8f9 drm/i915: Fix skl_pcode_try_request function
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#25: 
We see en error because higher level api, still notices that status was wrong,

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
96be4bb1275c drm/i915: Swap ret and status returned from skl_pcode_request

[Intel-gfx] ✗ Fi.CI.BAT: failure for Expose max and current bpc via debugfs

2022-04-08 Thread Patchwork

== Series Details ==

Series: Expose max and current bpc via debugfs
URL   : https://patchwork.freedesktop.org/series/102390/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11477 -> Patchwork_22825


Summary
---

  **FAILURE**

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

Participating hosts (46 -> 38)
--

  Additional (2): fi-bxt-dsi fi-icl-u2 
  Missing(10): fi-bdw-samus bat-dg1-6 bat-dg2-8 bat-dg2-9 fi-bsw-cyan 
bat-adlp-6 bat-adlp-4 fi-pnv-d510 bat-rpls-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-icl-u2:  NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bxt-dsi: NOTRUN -> [DMESG-WARN][2] ([i915#5437])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-bxt-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][3] ([i915#5437])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-cml-u2/igt@core_hotunp...@unbind-rebind.html

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

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

  * igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][12] ([fdo#111827]) +8 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][13] ([fdo#109278]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([fdo#109278]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][15] ([fdo#109271]) +13 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
- fi-cml-u2:  NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22825/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html
- fi-icl-u2:  NOTRUN -> [SKIP][17] ([fdo#109285])
   [17]:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: fix i915_gem_object_wait_moving_fence
URL   : https://patchwork.freedesktop.org/series/102396/
State : failure

== Summary ==

Applying: drm/i915: fix i915_gem_object_wait_moving_fence
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/i915_gem_object.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

Re: [Intel-gfx] [PATCH 3/3] drm/amd/display: Move connector debugfs to drm

2022-04-08 Thread kernel test robot

Hi Bhanuprakash,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20220408]
[cannot apply to drm/drm-next v5.18-rc1]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Bhanuprakash-Modem/Expose-max-and-current-bpc-via-debugfs/20220408-145638
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: s390-randconfig-r022-20220408 
(https://download.01.org/0day-ci/archive/20220408/202204082024.sjwgnute-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 11.2.0
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/25c70426c3d3454fc0c82bc71b101bf7b8bdf11f
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Bhanuprakash-Modem/Expose-max-and-current-bpc-via-debugfs/20220408-145638
git checkout 25c70426c3d3454fc0c82bc71b101bf7b8bdf11f
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=s390 SHELL=/bin/bash drivers/gpu/drm/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dmub/dmub_srv.h:67,
from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:35:
   drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h: In function 
'dmub_rb_flush_pending':
   drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:2961:26: warning: 
variable 'temp' set but not used [-Wunused-but-set-variable]
2961 | uint64_t temp;
 |  ^~~~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 
'amdgpu_dm_crtc_late_register':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6614:9: error: 
>> implicit declaration of function 'crtc_debugfs_init'; did you mean 
>> 'amdgpu_debugfs_init'? [-Werror=implicit-function-declaration]
6614 | crtc_debugfs_init(crtc);
 | ^
 | amdgpu_debugfs_init
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/core_types.h:32,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/link_enc_cfg.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:32:
   At top level:
   drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:128:22: 
warning: 'SYNAPTICS_DEVICE_ID' defined but not used [-Wunused-const-variable=]
 128 | static const uint8_t SYNAPTICS_DEVICE_ID[] = "SYNA";
 |  ^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:125:22: 
warning: 'DP_SINK_DEVICE_STR_ID_2' defined but not used 
[-Wunused-const-variable=]
 125 | static const uint8_t DP_SINK_DEVICE_STR_ID_2[] = {7, 1, 8, 7, 5, 0};
 |  ^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:124:22: 
warning: 'DP_SINK_DEVICE_STR_ID_1' defined but not used 
[-Wunused-const-variable=]
 124 | static const uint8_t DP_SINK_DEVICE_STR_ID_1[] = {7, 1, 8, 7, 3, 0};
 |  ^~~
   cc1: some warnings being treated as errors


vim +6614 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c

e7b07ceef2a650 Harry Wentland 2017-08-10  6611  
e69231c4451ae0 Wayne Lin  2021-03-08  6612  static int 
amdgpu_dm_crtc_late_register(struct drm_crtc *crtc)
86bc221918925a Wayne Lin  2021-03-02  6613  {
86bc221918925a Wayne Lin  2021-03-02 @6614  crtc_debugfs_init(crtc);
86bc221918925a Wayne Lin  2021-03-02  6615  
86bc221918925a Wayne Lin  2021-03-02  6616  return 0;
86bc221918925a Wayne Lin  2021-03-02  6617  }
86bc221918925a Wayne Lin  2021-03-02  6618  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Expose max and current bpc via debugfs

2022-04-08 Thread Patchwork

== Series Details ==

Series: Expose max and current bpc via debugfs
URL   : https://patchwork.freedesktop.org/series/102390/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: 0.5.1 (Ubuntu: 0.5.1-2)
Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH 2/2] drm/i915: Swap ret and status returned from skl_pcode_request

2022-04-08 Thread Stanislav Lisovskiy

If ret isn't zero, it is almost for sure ETIMEDOUT, because
we use it in wait_for macro which does continuous retries
until timeout is reached. If we still ran out of time and
retries, we most likely would be interested in getting status,
to understand what was the actual error propagated from PCode,
rather than to find out that we had a time out, which is anyway
quite obvious, if the function fails.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_pcode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
b/drivers/gpu/drm/i915/intel_pcode.c
index fb6c43e8a02f..a68eaf510784 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 
mbox, u32 request,
 
 out:
mutex_unlock(>sb_lock);
-   return ret ? ret : status;
+   return ret ? status : ret;
 #undef COND
 }
 
-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function

2022-04-08 Thread Stanislav Lisovskiy

Currently skl_pcode_try_request function doesn't
properly handle return value it gets from
snb_pcode_rw, but treats status != 0 as success,
returning true, which basically doesn't allow
to use retry/timeout mechanisms if PCode happens
to be busy and returns EGAIN or some other status
code not equal to 0.

We saw this on real hw and also tried simulating this
by always returning -EAGAIN from snb_pcode_rw for 6 times, which
currently will just result in false success, while it should
have tried until timeout is reached:

[   22.357729] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing 
CDCLK to
307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
[   22.357831] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 1
[   22.357892] i915 :00:02.0: [drm:skl_pcode_request [i915]] Success, 
exiting
[   22.357936] i915 :00:02.0: [drm] ERROR Failed to inform PCU about cdclk 
change (err -11, freq 307200)

We see en error because higher level api, still notices that status was wrong,
however we still did try only once.

We fix it by requiring _both_ the status to be 0 and
request/reply match for success(true) and function
should return failure(false) if either status turns
out to be EAGAIN, EBUSY or whatever or reply/request
masks do not match.

So now we see this in the logs:

[   22.318667] i915 :00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing 
CDCLK to
307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
[   22.318782] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 1
[   22.318849] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 2
[   22.319006] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 3
[   22.319091] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 4
[   22.319158] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 5
[   22.319224] i915 :00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN 
retry 6

Reviewed-by: Vinod Govindapillai 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_pcode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pcode.c 
b/drivers/gpu/drm/i915/intel_pcode.c
index 391a37492ce5..fb6c43e8a02f 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct drm_i915_private 
*i915, u32 mbox,
 {
*status = __snb_pcode_rw(i915, mbox, , NULL, 500, 0, true);
 
-   return *status || ((request & reply_mask) == reply);
+   return (*status == 0) && ((request & reply_mask) == reply);
 }
 
 /**
-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH 0/2] Fix issues in skl_pcode_request

2022-04-08 Thread Stanislav Lisovskiy

Couple of crucial fixes for skl_pcode_request function.
1) Correctly handle the error and do retires until timeout
2) Return PCode request status, when failure happens

Stanislav Lisovskiy (2):
  drm/i915: Fix skl_pcode_try_request function
  drm/i915: Swap ret and status returned from skl_pcode_request

 drivers/gpu/drm/i915/intel_pcode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.24.1.485.gad05a3d8e5

Re: [Intel-gfx] [PATCH] drm/i915/uncore: Warn on previous unclaimed accesses

2022-04-08 Thread Tvrtko Ursulin




On 05/04/2022 01:11, Lucas De Marchi wrote:

Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers.
This register is in the display engine IP and can only ever detect
unclaimed accesses to registers in this area. However sometimes there
are reports of this triggering for registers in other areas, which
should not be possible.

Right now we always warn after the read/write of registers going through
unclaimed_reg_debug(). However places using __raw_uncore_* may be
triggering the unclaimed access and those being later accounted to a
different register. Let's warn both before and after the read/write
with a slightly different message, so it's clear if the register
reported in the warning is actually the culprit.

Signed-off-by: Lucas De Marchi 


I see this triggering a lot on drm-tip today (TGL), is that expected?

[3.994907] i915 :00:02.0: [drm:intel_uncore_init_mmio [i915]] unclaimed 
mmio detected on uncore init, clearing
[4.392525] i915 :00:02.0: Unclaimed access detected before read from 
register 0x44408
[5.669929] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[6.652808] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[   13.015978] i915 :00:02.0: Unclaimed access detected before write to 
register 0x50380
[   16.876802] i915 :00:02.0: Unclaimed access detected before write to 
register 0x44404
[   45.174395] i915 :00:02.0: Unclaimed access detected before write to 
register 0x44404

It continues at runtime as well:

[10265.010902] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10329.093078] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10354.060331] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10385.486480] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10408.910533] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10433.398443] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10444.110593] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10468.302627] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10493.398727] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10515.366845] i915 :00:02.0: Unclaimed access detected before read from 
register 0x44408
[10518.674046] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10529.934735] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10553.398808] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10599.684455] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc4008
[10602.898167] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10613.398909] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10686.006783] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10711.906813] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10745.860538] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10771.812277] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10805.903058] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10831.927073] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10853.398958] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10866.007084] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10879.378435] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10891.727120] i915 :00:02.0: Unclaimed access detected before write to 
register 0x190030
[10913.395161] i915 :00:02.0: Unclaimed access detected before write to 
register 0x1900ec
[10939.026480] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204
[10964.626494] i915 :00:02.0: Unclaimed access detected before read from 
register 0xc7204

It don't think this machine had a problem with this before, or perhaps it was 
going undetected?

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/intel_uncore.c | 29 +
  1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8b9ccc21..df59ec88459e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1502,11 +1502,10 @@ ilk_dummy_write(struct intel_uncore *uncore)
  static void
  __unclaimed_reg_debug(struct intel_uncore *uncore,
  const i915_reg_t reg,
- const bool read,

Re: [Intel-gfx] [PATCH v11 01/13] drm/i915/guc: Update GuC ADS size for error capture lists

2022-04-08 Thread Tvrtko Ursulin




On 17/03/2022 18:56, Alan Previn wrote:

Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.

Then, populate GuC ADS with the lists of registers we want
GuC to report back to host on engine reset events. This list
should include global, engine-class and engine-instance
registers for every engine-class type on the current hardware.

Ensure we allocate a persistent store for the register lists
that are populated into ADS so that we don't need to allocate
memory during GT resets when GuC is reloaded and ADS population
happens again.

NOTE: Start with a sample static table of register lists to
layout the framework before adding real registers in subsequent
patch. This static register tables are a different format from
the ADS populated list.

Signed-off-by: Alan Previn 
Reviewed-by: Matthew Brost 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h |  91 +
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  13 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|   9 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 127 +-
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 374 ++
  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|  22 ++
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   8 +
  8 files changed, 628 insertions(+), 17 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h



[snip]


+
+static int
+guc_capture_list_init(struct intel_guc *guc, u32 owner, u32 type, u32 classid,
+ struct guc_mmio_reg *ptr, u16 num_entries)
+{
+   u32 i = 0;
+   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+   const struct __guc_mmio_reg_descr_group *reglists = 
guc->capture->reglists;
+   const struct __guc_mmio_reg_descr_group *match;
+
+   if (!reglists)
+   return -ENODEV;
+
+   match = guc_capture_get_one_list(reglists, owner, type, classid);
+   if (match) {
+   for (i = 0; i < num_entries && i < match->num_regs; ++i) {
+   ptr[i].offset = match->list[i].reg.reg;
+   ptr[i].value = 0xDEADF00D;
+   ptr[i].flags = match->list[i].flags;
+   ptr[i].mask = match->list[i].mask;
+   }
+   return 0;
+   }
+
+   guc_capture_warn_with_list_info(i915, "Missing register list init", 
owner, type,
+   classid);


I got a lot of these when booting on DG1 today (drm-tip):

[4.396554] i915 :03:00.0: [drm:intel_wopcm_init [i915]] Calculated GuC 
WOPCM [592K, 1420K)
[4.396681] i915 :03:00.0: [drm:i915_init_ggtt [i915]] clearing unused 
GTT space: [0, fee0]
[4.412408] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device
[4.505766] MCR Steering: Default steering: sliceid=0x0, subsliceid=0x0
[4.505771] [drm:wa_init_finish [i915]] Initialized 6 GT workarounds on 
global
[4.506300] [drm:wa_init_finish [i915]] Initialized 6 engine workarounds on 
rcs'0
[4.506413] [drm:wa_init_finish [i915]] Initialized 3 whitelist workarounds 
on rcs'0
[4.506490] [drm:wa_init_finish [i915]] Initialized 6 context workarounds on 
rcs'0
[4.506712] [drm:wa_init_finish [i915]] Initialized 1 engine workarounds on 
bcs'0
[4.506787] [drm:wa_init_finish [i915]] Initialized 1 whitelist workarounds 
on bcs'0
[4.506845] [drm:wa_init_finish [i915]] Initialized 1 context workarounds on 
bcs'0
[4.506972] [drm:wa_init_finish [i915]] Initialized 1 engine workarounds on 
vcs'0
[4.507026] [drm:wa_init_finish [i915]] Initialized 1 whitelist workarounds 
on vcs'0
[4.507160] [drm:wa_init_finish [i915]] Initialized 1 engine workarounds on 
vcs'2
[4.507217] [drm:wa_init_finish [i915]] Initialized 1 whitelist workarounds 
on vcs'2
[4.507330] [drm:wa_init_finish [i915]] Initialized 1 engine workarounds on 
vecs'0
[4.507385] [drm:wa_init_finish [i915]] Initialized 1 whitelist workarounds 
on vecs'0
[4.508752] [drm:intel_guc_log_create [i915]] guc_log_level=5 (enabled, 
verbose:yes, verbosity:3)
[4.508999] i915 :03:00.0: [drm:intel_guc_ads_create [i915]] Used 4 KB 
for temporary ADS regset
[4.509082] i915 :03:00.0: [drm:guc_capture_warn_with_list_info [i915]] 
GuC-capture: Missing register list size for PF Class-Registers on Video-Engine
[4.509152] i915 :03:00.0: [drm:guc_capture_warn_with_list_info [i915]] 
GuC-capture: Missing register list size for PF Class-Registers on Blitter-Engine
[4.509219] i915 :03:00.0: [drm:guc_capture_warn_with_list_info [i915]] 
GuC-capture: Missing register list size for VF Class-Registers on Render-Engine
[4.509283] i915 :03:00.0: [drm:guc_capture_warn_with_list_info [i915]] 
GuC-capture: Missing

Re: [Intel-gfx] [PATCH v2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Matthew Auld


On 08/04/2022 10:48, Matthew Auld wrote:

On 08/04/2022 09:59, Christian König wrote:

Am 08.04.22 um 10:42 schrieb Matthew Auld:

All of CI is just failing with the following, which prevents loading of
the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

v2(Lucas): handle ret == 0

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")
Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Lucas De Marchi 
Cc: Daniel Vetter 
Reviewed-by: Christian König  #v1


Reviewed-by: Christian König 

Should I push it to drm-misc-next?


I guess we need to wait for at least BAT result to come back. I will 
ping here, assuming that comes back green. Thanks.


Ok, please go ahead with merging.






---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..747ac65e060f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,16 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
    bool intr)
  {
+    long ret;
+
  assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, 
DMA_RESV_USAGE_KERNEL,

- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+    intr, MAX_SCHEDULE_TIMEOUT);
+    if (!ret)
+    ret = -ETIME;
+
+    return ret < 0 ? ret : 0;
  }
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH 20/20] drm/i915/gsc: allocate extended operational memory in LMEM

2022-04-08 Thread Matthew Auld

On Thu, 7 Apr 2022 at 14:00, Alexander Usyskin
 wrote:
>
> From: Tomas Winkler 
>
> GSC requires more operational memory than available on chip.
> Reserve 4M of LMEM for GSC operation. The memory is provided to the
> GSC as struct resource to the auxiliary data of the child device.
>
> Signed-off-by: Tomas Winkler 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> ---
>  drivers/gpu/drm/i915/gt/intel_gsc.c | 92 ++---
>  drivers/gpu/drm/i915/gt/intel_gsc.h |  3 +
>  2 files changed, 88 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
> b/drivers/gpu/drm/i915/gt/intel_gsc.c
> index bfc307e49bf9..4d87519d5773 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gsc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include "i915_drv.h"
>  #include "i915_reg.h"
> +#include "gem/i915_gem_region.h"
>  #include "gt/intel_gsc.h"
>  #include "gt/intel_gt.h"
>
> @@ -36,12 +37,68 @@ static int gsc_irq_init(int irq)
> return irq_set_chip_data(irq, NULL);
>  }
>
> +static int
> +gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t 
> size)
> +{
> +   struct intel_gt *gt = gsc_to_gt(gsc);
> +   struct drm_i915_gem_object *obj;
> +   void *vaddr;
> +   int err;
> +
> +   obj = i915_gem_object_create_lmem(gt->i915, size, 
> I915_BO_ALLOC_CONTIGUOUS);
> +   if (IS_ERR(obj)) {
> +   drm_err(>i915->drm, "Failed to allocate gsc memory\n");
> +   return PTR_ERR(obj);
> +   }
> +
> +   err = i915_gem_object_pin_pages_unlocked(obj);
> +   if (err) {
> +   drm_err(>i915->drm, "Failed to pin pages for gsc 
> memory\n");
> +   goto out_put;
> +   }
> +
> +   vaddr = i915_gem_object_pin_map_unlocked(obj, 
> i915_coherent_map_type(gt->i915, obj, true));
> +   if (IS_ERR(vaddr)) {
> +   err = PTR_ERR(vaddr);
> +   drm_err(>i915->drm, "Failed to map gsc memory\n");
> +   goto out_unpin;
> +   }
> +
> +   memset(vaddr, 0, obj->base.size);

We should be able to pass I915_BO_ALLOC_CPU_CLEAR to create_lmem,
which should do something like this for us, when later calling
pin_pages or similar.

> +
> +   i915_gem_object_unpin_map(obj);
> +
> +   intf->gem_obj = obj;
> +
> +   return 0;
> +
> +out_unpin:
> +   i915_gem_object_unpin_pages(obj);
> +out_put:
> +   i915_gem_object_put(obj);
> +   return err;
> +}
> +
> +static void gsc_ext_om_destroy(struct intel_gsc_intf *intf)
> +{
> +   struct drm_i915_gem_object *obj = fetch_and_zero(>gem_obj);
> +
> +   if (!obj)
> +   return;
> +
> +   if (i915_gem_object_has_pinned_pages(obj))
> +   i915_gem_object_unpin_pages(obj);
> +
> +   i915_gem_object_put(obj);
> +}
> +
>  struct gsc_def {
> const char *name;
> unsigned long bar;
> size_t bar_size;
> bool use_polling;
> bool slow_fw;
> +   size_t lmem_size;
>  };
>
>  /* gsc resources and definitions (HECI1 and HECI2) */
> @@ -74,6 +131,7 @@ static const struct gsc_def gsc_def_dg2[] = {
> .name = "mei-gsc",
> .bar = DG2_GSC_HECI1_BASE,
> .bar_size = GSC_BAR_LENGTH,
> +   .lmem_size = SZ_4M,
> },
> {
> .name = "mei-gscfi",
> @@ -90,26 +148,33 @@ static void gsc_release_dev(struct device *dev)
> kfree(adev);
>  }
>
> -static void gsc_destroy_one(struct intel_gsc_intf *intf)
> +static void gsc_destroy_one(struct drm_i915_private *i915,
> + struct intel_gsc *gsc, unsigned int intf_id)
>  {
> +   struct intel_gsc_intf *intf = >intf[intf_id];
> +
> if (intf->adev) {
> auxiliary_device_delete(>adev->aux_dev);
> auxiliary_device_uninit(>adev->aux_dev);
> intf->adev = NULL;
> }
> +
> if (intf->irq >= 0)
> irq_free_desc(intf->irq);
> intf->irq = -1;
> +
> +   gsc_ext_om_destroy(intf);
>  }
>
>  static void gsc_init_one(struct drm_i915_private *i915,
> -struct intel_gsc_intf *intf,
> -unsigned int intf_id)
> +  struct intel_gsc *gsc,
> +  unsigned int intf_id)
>  {
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct mei_aux_device *adev;
> struct auxiliary_device *aux_dev;
> const struct gsc_def *def;
> +   struct intel_gsc_intf *intf = >intf[intf_id];
> int ret;
>
> intf->irq = -1;
> @@ -141,7 +206,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
> intf->irq = irq_alloc_desc(0);
> if (intf->irq < 0) {
> drm_err(>drm, "gsc irq error %d\n", intf->irq);
> -   return;
> +   goto fail;
> }
>
> ret = gsc_irq_init(intf->irq);

Re: [Intel-gfx] [PATCH] drm/i915/display/debugfs: Add connector debugfs for "output_bpc"

2022-04-08 Thread Modem, Bhanuprakash


On Mon-04-04-2022 09:11 pm, Daniel Vetter wrote:

On Mon, Apr 04, 2022 at 01:46:23PM +0300, Jani Nikula wrote:

On Mon, 04 Apr 2022, "Modem, Bhanuprakash"  wrote:

On Fri-01-04-2022 06:10 pm, Jani Nikula wrote:

On Tue, 29 Mar 2022, Bhanuprakash Modem  wrote:

This new debugfs will expose the connector's max supported bpc
and the bpc currently using. It is very useful for verifying
whether we enter the correct output color depth from IGT.

Example:
cat /sys/kernel/debug/dri/0/DP-1/output_bpc
Current: 8
Maximum: 10

V2: Add connector's max bpc to i915_display_info

Cc: Ville Syrjälä 
Cc: Uma Shankar 
Cc: Swati Sharma 
Signed-off-by: Bhanuprakash Modem 
---
   .../drm/i915/display/intel_display_debugfs.c  | 46 +++
   1 file changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index c1e74a13a0828..694d27f3b109c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -663,6 +663,8 @@ static void intel_connector_info(struct seq_file *m,
seq_puts(m, "\tHDCP version: ");
intel_hdcp_info(m, intel_connector);
   
+	seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc);

+
intel_panel_info(m, intel_connector);
   
   	seq_printf(m, "\tmodes:\n");

@@ -2275,6 +2277,47 @@ static const struct file_operations i915_dsc_bpp_fops = {
.write = i915_dsc_bpp_write
   };
   
+/*

+ * Returns the maximum output bpc for the connector.
+ * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
+ */
+static int output_bpc_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   int res;
+
+   if (!encoder)
+   return -ENODEV;
+
+   res = 
drm_modeset_lock_single_interruptible(>mode_config.connection_mutex);
+   if (res)
+   return res;
+
+   crtc = connector->state->crtc;
+   if (connector->status != connector_status_connected || !crtc) {
+   res = -ENODEV;
+   goto unlock;
+   }
+
+   crtc_state = to_intel_crtc_state(crtc->state);
+   if (!crtc_state->hw.active)
+   goto unlock;
+
+   seq_printf(m, "Current: %u\n", crtc_state->pipe_bpp / 3);
+   seq_printf(m, "Maximum: %u\n", connector->display_info.bpc);
+   res = 0;
+
+unlock:
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   return res;
+}
+DEFINE_SHOW_ATTRIBUTE(output_bpc);


Looks like an excessive amount of code for a single value.


Yeah, but these values are very helpful in many IGT tests like
kms_color, kms_hdr, kms_dither, kms_dsc etc..

Otherwise IGT needs to request the kernel to get the EDID, and parse
that EDID to get the "Maximum" value which is redundant (Kernel is
already doing the same) and not recommended in IGT.

And there is no way to get the "Current" value except reading it from
i915_display_info which is again not recommended in IGT (As
i915_display_info is Intel specific).


Note how we have intel_connector_debugfs_add() for connector debugfs and
intel_crtc_debugfs_add() for crtc debugfs, and how this patch just mixes
up the two by looking up crtc and state from the connector debugfs.


This debugfs is already introduced & using by AMD:
https://patchwork.freedesktop.org/patch/308586


Wait, what?

Both amd and i915 adding the name "output_bpc" is *not* the way to
roll. We only add i915_ prefixed debugfs files from i915.ko.


Yeah vendor prefix would be nice, but it's debugfs so we can always fix
it.

Also would be really good to pull that output_bpc into drm core if it's
something standard that igts need in general, so ideally we don't just
standardize the drm side, but also the testcases that need this and make
them generic to run on any kms driver.


I made the required changes in both IGT & Kernel and floated to ML, 
please help to review.


IGT: https://patchwork.freedesktop.org/series/102387/
Kernel: https://patchwork.freedesktop.org/series/102390/

- Bhanu


-Daniel



If you need this to be a standard interface across drivers, IMO it
should be added in common drm code, not sprinkled around in drivers.

I see that amd is already using this in what is basically drm core
debugfs namespace, and there's amd specific IGT built on top.

Adding a bunch of Cc's to get some clarity on drm debugfs naming and
usage.


BR,
Jani.




- Bhanu



BR,
Jani.


+
   /**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2330,6 +2373,9 @@ void intel_connector_debugfs_add(struct intel_connector 
*intel_connector)
connector->connector_type ==

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-08 Thread Tvrtko Ursulin




On 08/04/2022 10:50, Dave Airlie wrote:

On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
 wrote:



On 08/04/2022 08:58, Daniel Vetter wrote:

On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.

This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem.

Nice value will only apply to requests which originate from user contexts
and have default context priority. This is to avoid disturbing any
application made choices of low and high (batch processing and latency
sensitive compositing). In this case nice value adjusts the effective
priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.

This means that userspace using the context priority uapi directly has a
wider range of possible adjustments (in practice that only applies to
execlists platforms - with GuC there are only three priority buckets), but
in all cases nice adjustment has the expected effect: positive nice
lowering the scheduling priority and negative nice raising it.

Signed-off-by: Tvrtko Ursulin 


I don't think adding any more fancy features to i915-scheduler makes
sense, at least not before we've cut over to drm/sched.


Why do you think so?

Drm/sched has at least low/normal/high priority and surely we will keep
the i915 context priority ABI.

Then this patch is not touching the i915 scheduler at all, neither it is
fancy.

The cover letter explains how it implements the same approach as the IO
scheduler. And it explains the reasoning and benefits. Provides an user
experience benefit today, which can easily be preserved.


won't this cause uAPI divergence between execlists and GuC, like if
something nices to -15 or -18 with execlists and the same with GuC it
won't get the same sort of result will it?


Not sure what you consider new ABI divergence but the general problem 
space of execlists vs GuC priority handling is not related to this patch.


Existing GEM context ABI has -1023 - +1023 for user priorities while GuC 
maps that to low/normal/high only. I915_CONTEXT_DEFAULT_PRIORITY is zero 
which maps to GuC normal. Negatives map to GuC low and positives to 
high. Drm/sched is I understand similar or the same.


So any userspace using the existing uapi can already observe differences 
between GuC and execlists. With your example of -15 vs -18 I mean.


I don't think anyone considered that a problem because execution order 
based on priority is not a hard guarantee. Neither is proportionality of 
timeslicing. Otherwise GuC would already be breaking the ABI.


With this patch it simply allows external control - whereas before only 
applications could change their priorities, now users can influence the 
priority of the ones which did not bother to set a non-default priority.


In the case of GuC if user says "nice 10 churn-my-dataset-on-gpu && 
run-my-game", former part get low prio, latter gets normal. I don't see 
any issues there. Same as if the "churn-my-dataset-on-gpu" command 
implemented a command line switch which passed context priority to i915 
via the existing GEM context param ioctl.


I've described the exact experiments in both modes in the cover letter 
which shows it works. (Ignoring the GuC scheduling quirk where 
apparently low-vs-normal timeslices worse than normal-vs-high).


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drivers: Fix spelling mistake "writting" -> "writing"

2022-04-08 Thread Jani Nikula

On Fri, 08 Apr 2022, cgel@gmail.com wrote:
> From: Lv Ruyi 
>
> There are some spelling mistakes in the comments. Fix it.

Please prefer splitting by driver. This isn't even split by subsystem. I
presume there are very few maintainers willing to pick this up as it is.

BR,
Jani.

>
> Reported-by: Zeal Robot 
> Signed-off-by: Lv Ruyi 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  | 2 +-
>  drivers/gpu/drm/i915/i915_request.c | 2 +-
>  drivers/net/ethernet/sfc/mcdi_pcol.h| 4 ++--
>  drivers/net/ethernet/toshiba/tc35815.c  | 2 +-
>  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 ++--
>  drivers/platform/x86/hp_accel.c | 2 +-
>  drivers/rtc/rtc-sa1100.c| 2 +-
>  drivers/scsi/pmcraid.c  | 4 ++--
>  8 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 9426e252d8aa..ce361fce7155 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -7304,7 +7304,7 @@ static void gfx_v10_0_setup_grbm_cam_remapping(struct 
> amdgpu_device *adev)
>   return;
>  
>   /* initialize cam_index to 0
> -  * index will auto-inc after each data writting */
> +  * index will auto-inc after each data writing */
>   WREG32_SOC15(GC, 0, mmGRBM_CAM_INDEX, 0);
>  
>   switch (adev->ip_versions[GC_HWIP][0]) {
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 582770360ad1..cf79a25cd98a 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -451,7 +451,7 @@ static bool __request_in_flight(const struct i915_request 
> *signal)
>* to avoid tearing.]
>*
>* Note that the read of *execlists->active may race with the promotion
> -  * of execlists->pending[] to execlists->inflight[], overwritting
> +  * of execlists->pending[] to execlists->inflight[], overwriting
>* the value at *execlists->active. This is fine. The promotion implies
>* that we received an ACK from the HW, and so the context is not
>* stuck -- if we do not see ourselves in *active, the inflight status
> diff --git a/drivers/net/ethernet/sfc/mcdi_pcol.h 
> b/drivers/net/ethernet/sfc/mcdi_pcol.h
> index d3fcbf930dba..ff617b1b38d3 100644
> --- a/drivers/net/ethernet/sfc/mcdi_pcol.h
> +++ b/drivers/net/ethernet/sfc/mcdi_pcol.h
> @@ -73,8 +73,8 @@
>   *   \-- Resync (always set)
>   *
>   * The client writes it's request into MC shared memory, and rings the
> - * doorbell. Each request is completed by either by the MC writting
> - * back into shared memory, or by writting out an event.
> + * doorbell. Each request is completed by either by the MC writing
> + * back into shared memory, or by writing out an event.
>   *
>   * All MCDI commands support completion by shared memory response. Each
>   * request may also contain additional data (accounted for by HEADER.LEN),
> diff --git a/drivers/net/ethernet/toshiba/tc35815.c 
> b/drivers/net/ethernet/toshiba/tc35815.c
> index ce38f7515225..1b4c207afb66 100644
> --- a/drivers/net/ethernet/toshiba/tc35815.c
> +++ b/drivers/net/ethernet/toshiba/tc35815.c
> @@ -157,7 +157,7 @@ struct tc35815_regs {
>  #define PROM_Read   0x4000 /*10:Read operation*/
>  #define PROM_Write  0x2000 /*01:Write operation   */
>  #define PROM_Erase  0x6000 /*11:Erase operation   */
> -   /*00:Enable or Disable Writting,   */
> +   /*00:Enable or Disable Writing,*/
> /*  as specified in PROM_Addr. */
>  #define PROM_Addr_Ena   0x0030 /*11:PROM Write enable
>  */
> /*00:   disable*/
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> index eaba66113328..fbb4941d0da8 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
> @@ -520,7 +520,7 @@ static void _rtl92cu_init_queue_reserved_page(struct 
> ieee80211_hw *hw,
>* 2 out-ep. Remainder pages have assigned to High queue */
>   if (outepnum > 1 && txqremaininpage)
>   numhq += txqremaininpage;
> - /* NOTE: This step done before writting REG_RQPN. */
> + /* NOTE: This step done before writing REG_RQPN. */
>   if (ischipn) {
>   if (queue_sel & TX_SELE_NQ)
>   numnq = txqpageunit;
> @@ -539,7 +539,7 @@ static void _rtl92cu_init_queue_reserved_page(struct 
>

Re: [Intel-gfx] [PATCH 12/15] drm/i915: drop bo->moving dependency

2022-04-08 Thread Jani Nikula

On Fri, 08 Apr 2022, Christian König  wrote:
> Am 08.04.22 um 11:05 schrieb Jani Nikula:
>> On Thu, 07 Apr 2022, "Christian König"  
>> wrote:
>>> That should now be handled by the common dma_resv framework.
>>>
>>> Signed-off-by: Christian König 
>>> Reviewed-by: Daniel Vetter 
>>> Cc: intel-gfx@lists.freedesktop.org
>> So, where are the i915 maintainer acks for merging this (and the other
>> patches in the series touching i915) via drm-misc-next?
>>
>> Daniel's Reviewed-by is not an ack to merge outside drm-intel-next.
>
> I had the impression that it would be sufficient.

Please don't assume. Please always ask for explicit acks from the
maintainers before merging, and record the acks in the commit
message. This has been standard policy for as long as I remember.

Contrast with us merging non-trivial dma-buf changes via drm-intel-next
with a Reviewed-by from someone who isn't a dma-buf maintainer, and not
even bothering to Cc the maintainers.

>> We don't merge i915 stuff without passing CI results. Apparently this
>> one failed enough machines that the CI had to be stopped entirely.
>
> That was unfortunately partially expected and pointed out by Matthew and 
> Daniel before the push.
>
> i915 for some reason extended the usage of the bo->moving fence despite 
> the fact we had patches on the mailing list to entirely remove this feature.
>
> I couldn't get any sane CI results for weeks because of this and at some 
> point we just had to go ahead and fix the clash in drm-tip.

Did you talk to the maintainers about it?


BR,
Jani.

>
> Sorry for any inconvenience cause by that. I hoped that we fixed all 
> cases, but looks like we still missed some.
>
> Regards,
> Christian.
>
>>
>>
>> BR,
>> Jani.
>>
>>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_object.c| 41 ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_object.h|  8 +---
>>>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 15 +--
>>>   .../drm/i915/gem/selftests/i915_gem_migrate.c |  3 +-
>>>   .../drm/i915/gem/selftests/i915_gem_mman.c|  3 +-
>>>   drivers/gpu/drm/i915/i915_vma.c   |  9 +++-
>>>   6 files changed, 21 insertions(+), 58 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> index 372bc220faeb..ffde7bc0a95d 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> @@ -741,30 +741,19 @@ static const struct drm_gem_object_funcs 
>>> i915_gem_object_funcs = {
>>>   /**
>>>* i915_gem_object_get_moving_fence - Get the object's moving fence if any
>>>* @obj: The object whose moving fence to get.
>>> + * @fence: The resulting fence
>>>*
>>>* A non-signaled moving fence means that there is an async operation
>>>* pending on the object that needs to be waited on before setting up
>>>* any GPU- or CPU PTEs to the object's pages.
>>>*
>>> - * Return: A refcounted pointer to the object's moving fence if any,
>>> - * NULL otherwise.
>>> + * Return: Negative error code or 0 for success.
>>>*/
>>> -struct dma_fence *
>>> -i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj)
>>> +int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
>>> +struct dma_fence **fence)
>>>   {
>>> -   return dma_fence_get(i915_gem_to_ttm(obj)->moving);
>>> -}
>>> -
>>> -void i915_gem_object_set_moving_fence(struct drm_i915_gem_object *obj,
>>> - struct dma_fence *fence)
>>> -{
>>> -   struct dma_fence **moving = _gem_to_ttm(obj)->moving;
>>> -
>>> -   if (*moving == fence)
>>> -   return;
>>> -
>>> -   dma_fence_put(*moving);
>>> -   *moving = dma_fence_get(fence);
>>> +   return dma_resv_get_singleton(obj->base.resv, DMA_RESV_USAGE_KERNEL,
>>> + fence);
>>>   }
>>>   
>>>   /**
>>> @@ -782,23 +771,9 @@ void i915_gem_object_set_moving_fence(struct 
>>> drm_i915_gem_object *obj,
>>>   int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
>>>   bool intr)
>>>   {
>>> -   struct dma_fence *fence = i915_gem_to_ttm(obj)->moving;
>>> -   int ret;
>>> -
>>> assert_object_held(obj);
>>> -   if (!fence)
>>> -   return 0;
>>> -
>>> -   ret = dma_fence_wait(fence, intr);
>>> -   if (ret)
>>> -   return ret;
>>> -
>>> -   if (fence->error)
>>> -   return fence->error;
>>> -
>>> -   i915_gem_to_ttm(obj)->moving = NULL;
>>> -   dma_fence_put(fence);
>>> -   return 0;
>>> +   return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
>>> +intr, MAX_SCHEDULE_TIMEOUT);
>>>   }
>>>   
>>>   #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
>>> index 02c37fe4a535..e11d82a9f7c3 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-08 Thread Dave Airlie

On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
 wrote:
>
>
> On 08/04/2022 08:58, Daniel Vetter wrote:
> > On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin 
> >>
> >> Inherit submitter nice at point of request submission to account for long
> >> running processes getting either externally or self re-niced.
> >>
> >> This accounts for the current processing landscape where computational
> >> pipelines are composed of CPU and GPU parts working in tandem.
> >>
> >> Nice value will only apply to requests which originate from user contexts
> >> and have default context priority. This is to avoid disturbing any
> >> application made choices of low and high (batch processing and latency
> >> sensitive compositing). In this case nice value adjusts the effective
> >> priority in the narrow band of -19 to +20 around
> >> I915_CONTEXT_DEFAULT_PRIORITY.
> >>
> >> This means that userspace using the context priority uapi directly has a
> >> wider range of possible adjustments (in practice that only applies to
> >> execlists platforms - with GuC there are only three priority buckets), but
> >> in all cases nice adjustment has the expected effect: positive nice
> >> lowering the scheduling priority and negative nice raising it.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >
> > I don't think adding any more fancy features to i915-scheduler makes
> > sense, at least not before we've cut over to drm/sched.
>
> Why do you think so?
>
> Drm/sched has at least low/normal/high priority and surely we will keep
> the i915 context priority ABI.
>
> Then this patch is not touching the i915 scheduler at all, neither it is
> fancy.
>
> The cover letter explains how it implements the same approach as the IO
> scheduler. And it explains the reasoning and benefits. Provides an user
> experience benefit today, which can easily be preserved.

won't this cause uAPI divergence between execlists and GuC, like if
something nices to -15 or -18 with execlists and the same with GuC it
won't get the same sort of result will it?

Dave.

Re: [Intel-gfx] [PATCH v2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Matthew Auld


On 08/04/2022 09:59, Christian König wrote:

Am 08.04.22 um 10:42 schrieb Matthew Auld:

All of CI is just failing with the following, which prevents loading of
the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

v2(Lucas): handle ret == 0

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")
Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Lucas De Marchi 
Cc: Daniel Vetter 
Reviewed-by: Christian König  #v1


Reviewed-by: Christian König 

Should I push it to drm-misc-next?


I guess we need to wait for at least BAT result to come back. I will 
ping here, assuming that comes back green. Thanks.





---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..747ac65e060f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,16 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
    bool intr)
  {
+    long ret;
+
  assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+    intr, MAX_SCHEDULE_TIMEOUT);
+    if (!ret)
+    ret = -ETIME;
+
+    return ret < 0 ? ret : 0;
  }
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH 1/1] drm/i915/uc: Use platform specific defaults for GuC/HuC enabling

2022-04-08 Thread Tvrtko Ursulin




On 07/04/2022 21:49, John Harrison wrote:

On 4/7/2022 08:49, Tvrtko Ursulin wrote:

On 03/06/2021 17:48, Matthew Brost wrote:

From: John Harrison 

The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right now, the default is for everything to be off
anyway. So this is not a change for current platforms.

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
Reviewed-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_params.c | 2 +-
  drivers/gpu/drm/i915/i915_params.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

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

index 0320878d96b0..e07f4cfea63a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -160,7 +160,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
  i915_param_named_unsafe(enable_guc, int, 0400,
  "Enable GuC load for GuC submission and/or HuC load. "
  "Required functionality can be selected using bitmask values. "
-    "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+    "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
    i915_param_named(guc_log_level, int, 0400,
  "GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h

index 4a114a5ad000..f27eceb82c0f 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,7 +59,7 @@ struct drm_printer;
  param(int, disable_power_well, -1, 0400) \
  param(int, enable_ips, 1, 0600) \
  param(int, invert_brightness, 0, 0600) \
-    param(int, enable_guc, 0, 0400) \
+    param(int, enable_guc, -1, 0400) \
  param(int, guc_log_level, -1, 0400) \
  param(char *, guc_firmware_path, NULL, 0400) \
  param(char *, huc_firmware_path, NULL, 0400) \


What is the BKM to use this with multi-GPU setups? Specifically I have 
a TGL+DG1 laptop (off the shelf) and want to have GuC with DG1 only. 
If I pass i915.enable_guc=3 it seems it wants to enable it for TGL as 
well and wedges the GPU if it can't?



I don't think there is one.

Module parameters are driver global and therefore apply to all cards in 
the system, both discrete and integrated. The '-1' default can and does 
have different meanings for each card. So in the TGL+DG1 case, TGL 
should default to execlist and DG1 should already be defaulting to GuC. 
So the -1 setting should do what you want. But if you did need to 
override for one specific card only then I think you would need to do 
that with a code change and rebuild.


You are right, I was on a kernel where DG1 wasn't yet defaulting to GuC 
hence the confusion when I tried to pass enable_guc=3 that broke TGL as 
well, but because I had no up to date firmware for it.


We really need per device modparams, as long as we have modparams..

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 12/15] drm/i915: drop bo->moving dependency

2022-04-08 Thread Daniel Vetter

On Fri, 8 Apr 2022 at 11:27, Christian König  wrote:
>
> Am 08.04.22 um 11:05 schrieb Jani Nikula:
> > On Thu, 07 Apr 2022, "Christian König"  
> > wrote:
> >> That should now be handled by the common dma_resv framework.
> >>
> >> Signed-off-by: Christian König 
> >> Reviewed-by: Daniel Vetter 
> >> Cc: intel-gfx@lists.freedesktop.org
> > So, where are the i915 maintainer acks for merging this (and the other
> > patches in the series touching i915) via drm-misc-next?
> >
> > Daniel's Reviewed-by is not an ack to merge outside drm-intel-next.
>
> I had the impression that it would be sufficient.
>
> > We don't merge i915 stuff without passing CI results. Apparently this
> > one failed enough machines that the CI had to be stopped entirely.
>
> That was unfortunately partially expected and pointed out by Matthew and
> Daniel before the push.

Uh I didn't realize that CI never tested this. Usually the way then is
to rebase onto drm-tip and figure out the merge story. Doing subsystem
wide changes while not on linux-next or drm-tip or another integration
tree is just fraught with surprises due to conflicts.

Also "doesn't even compile" is really below the bar, and not the first
time this happened at all. And i915 isn't really an obscure driver
which is hard to compile test :-)
-Daniel

> i915 for some reason extended the usage of the bo->moving fence despite
> the fact we had patches on the mailing list to entirely remove this feature.
>
> I couldn't get any sane CI results for weeks because of this and at some
> point we just had to go ahead and fix the clash in drm-tip.
>
> Sorry for any inconvenience cause by that. I hoped that we fixed all
> cases, but looks like we still missed some.
>
> Regards,
> Christian.
>
> >
> >
> > BR,
> > Jani.
> >
> >
> >> ---
> >>   drivers/gpu/drm/i915/gem/i915_gem_object.c| 41 ---
> >>   drivers/gpu/drm/i915/gem/i915_gem_object.h|  8 +---
> >>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 15 +--
> >>   .../drm/i915/gem/selftests/i915_gem_migrate.c |  3 +-
> >>   .../drm/i915/gem/selftests/i915_gem_mman.c|  3 +-
> >>   drivers/gpu/drm/i915/i915_vma.c   |  9 +++-
> >>   6 files changed, 21 insertions(+), 58 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> >> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> >> index 372bc220faeb..ffde7bc0a95d 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> >> @@ -741,30 +741,19 @@ static const struct drm_gem_object_funcs 
> >> i915_gem_object_funcs = {
> >>   /**
> >>* i915_gem_object_get_moving_fence - Get the object's moving fence if 
> >> any
> >>* @obj: The object whose moving fence to get.
> >> + * @fence: The resulting fence
> >>*
> >>* A non-signaled moving fence means that there is an async operation
> >>* pending on the object that needs to be waited on before setting up
> >>* any GPU- or CPU PTEs to the object's pages.
> >>*
> >> - * Return: A refcounted pointer to the object's moving fence if any,
> >> - * NULL otherwise.
> >> + * Return: Negative error code or 0 for success.
> >>*/
> >> -struct dma_fence *
> >> -i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj)
> >> +int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
> >> + struct dma_fence **fence)
> >>   {
> >> -return dma_fence_get(i915_gem_to_ttm(obj)->moving);
> >> -}
> >> -
> >> -void i915_gem_object_set_moving_fence(struct drm_i915_gem_object *obj,
> >> -  struct dma_fence *fence)
> >> -{
> >> -struct dma_fence **moving = _gem_to_ttm(obj)->moving;
> >> -
> >> -if (*moving == fence)
> >> -return;
> >> -
> >> -dma_fence_put(*moving);
> >> -*moving = dma_fence_get(fence);
> >> +return dma_resv_get_singleton(obj->base.resv, DMA_RESV_USAGE_KERNEL,
> >> +  fence);
> >>   }
> >>
> >>   /**
> >> @@ -782,23 +771,9 @@ void i915_gem_object_set_moving_fence(struct 
> >> drm_i915_gem_object *obj,
> >>   int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
> >>bool intr)
> >>   {
> >> -struct dma_fence *fence = i915_gem_to_ttm(obj)->moving;
> >> -int ret;
> >> -
> >>  assert_object_held(obj);
> >> -if (!fence)
> >> -return 0;
> >> -
> >> -ret = dma_fence_wait(fence, intr);
> >> -if (ret)
> >> -return ret;
> >> -
> >> -if (fence->error)
> >> -return fence->error;
> >> -
> >> -i915_gem_to_ttm(obj)->moving = NULL;
> >> -dma_fence_put(fence);
> >> -return 0;
> >> +return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
> >> + intr, MAX_SCHEDULE_TIMEOUT);
> >>   }
> >>
> >>   #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
>

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Christian König


Am 08.04.22 um 11:23 schrieb Tvrtko Ursulin:


On 08/04/2022 10:12, Christian König wrote:

Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:


On 07/04/2022 17:45, Matthew Auld wrote:
All of CI is just failing with the following, which prevents 
loading of

the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")


Has this one went in bypassing i915 CI and merged via drm-misc-next? 
If so I think it's the 2nd large disruption to i915 CI flows 
recently so the lesson here is try not to bypass i915 CI when 
merging i915 patches.


In this particular example, unless there were merge conflicts 
causing the series not to apply against drm-tip, it should have been 
doable to copy intel-gfx on all patches and so get the CI results. 
(Even if just with --subject-prefix=CI && --suppress-cc=all before 
merging.)


Exactly that was the problem. I didn't got any usable CI results for 
this set because it always caused merge conflicts between i915 and 
drm-misc-next in drm-tip.


Then a staged approach should be used. First merge the core stuff and 
when we backmerge to drm-intel(-gt)-next send the i915 parts out.


Because knock on effect of such large of a CI fire too many many 
people on our side is very significant.


Sorry for that. I thought we had everything covered in drm-tip, but 
looks like it still broke.


BTW: Why is the CI system failing?

Regards,
Christian.



Regards,

Tvrtko



Regards,
Christian.



The second question is which branch to merge through, on which I 
think i915 maintainers would have liked to be consulted.


Regards,

Tvrtko


Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..1c88d4121658 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,14 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object 
*obj,

    bool intr)
  {
+    long ret;
+
  assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, 
DMA_RESV_USAGE_KERNEL,

- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, 
DMA_RESV_USAGE_KERNEL,

+    intr, MAX_SCHEDULE_TIMEOUT);
+
+    return ret < 0 ? ret : 0;
  }
    #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH v2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Petri Latvala

On Fri, Apr 08, 2022 at 09:42:05AM +0100, Matthew Auld wrote:
> All of CI is just failing with the following, which prevents loading of
> the module:
> 
> i915 :03:00.0: [drm] *ERROR* Scratch setup failed
> 
> Best guess is that this comes from the pin_map() for the scratch page,
> which does an i915_gem_object_wait_moving_fence() somewhere. It looks
> like this now calls into dma_resv_wait_timeout() which can return the
> remaining timeout, leading to the caller thinking this is an error.
> 
> v2(Lucas): handle ret == 0
> 
> Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")
> Signed-off-by: Matthew Auld 
> Cc: Christian König 
> Cc: Lucas De Marchi 
> Cc: Daniel Vetter 
> Reviewed-by: Christian König  #v1


For the record, patchwork is disabled at this time. Trybot is still up
if you want CI to verify this.



-- 
Petri Latvala


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 2998d895a6b3..747ac65e060f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -772,9 +772,16 @@ int i915_gem_object_get_moving_fence(struct 
> drm_i915_gem_object *obj,
>  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
> bool intr)
>  {
> + long ret;
> +
>   assert_object_held(obj);
> - return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
> -  intr, MAX_SCHEDULE_TIMEOUT);
> +
> + ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
> + intr, MAX_SCHEDULE_TIMEOUT);
> + if (!ret)
> + ret = -ETIME;
> +
> + return ret < 0 ? ret : 0;
>  }
>  
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> -- 
> 2.34.1
>

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Tvrtko Ursulin




On 08/04/2022 10:12, Christian König wrote:

Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:


On 07/04/2022 17:45, Matthew Auld wrote:

All of CI is just failing with the following, which prevents loading of
the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")


Has this one went in bypassing i915 CI and merged via drm-misc-next? 
If so I think it's the 2nd large disruption to i915 CI flows recently 
so the lesson here is try not to bypass i915 CI when merging i915 
patches.


In this particular example, unless there were merge conflicts causing 
the series not to apply against drm-tip, it should have been doable to 
copy intel-gfx on all patches and so get the CI results. (Even if just 
with --subject-prefix=CI && --suppress-cc=all before merging.)


Exactly that was the problem. I didn't got any usable CI results for 
this set because it always caused merge conflicts between i915 and 
drm-misc-next in drm-tip.


Then a staged approach should be used. First merge the core stuff and 
when we backmerge to drm-intel(-gt)-next send the i915 parts out.


Because knock on effect of such large of a CI fire too many many people 
on our side is very significant.


Regards,

Tvrtko



Regards,
Christian.



The second question is which branch to merge through, on which I think 
i915 maintainers would have liked to be consulted.


Regards,

Tvrtko


Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..1c88d4121658 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,14 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
    bool intr)
  {
+    long ret;
+
  assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, 
DMA_RESV_USAGE_KERNEL,

- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+    intr, MAX_SCHEDULE_TIMEOUT);
+
+    return ret < 0 ? ret : 0;
  }
    #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Christian König


Am 08.04.22 um 11:08 schrieb Tvrtko Ursulin:


On 07/04/2022 17:45, Matthew Auld wrote:

All of CI is just failing with the following, which prevents loading of
the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")


Has this one went in bypassing i915 CI and merged via drm-misc-next? 
If so I think it's the 2nd large disruption to i915 CI flows recently 
so the lesson here is try not to bypass i915 CI when merging i915 
patches.


In this particular example, unless there were merge conflicts causing 
the series not to apply against drm-tip, it should have been doable to 
copy intel-gfx on all patches and so get the CI results. (Even if just 
with --subject-prefix=CI && --suppress-cc=all before merging.)


Exactly that was the problem. I didn't got any usable CI results for 
this set because it always caused merge conflicts between i915 and 
drm-misc-next in drm-tip.


Regards,
Christian.



The second question is which branch to merge through, on which I think 
i915 maintainers would have liked to be consulted.


Regards,

Tvrtko


Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..1c88d4121658 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,14 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
    bool intr)
  {
+    long ret;
+
  assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, 
DMA_RESV_USAGE_KERNEL,

- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+    intr, MAX_SCHEDULE_TIMEOUT);
+
+    return ret < 0 ? ret : 0;
  }
    #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Export drm_dp_dpcd_access()

2022-04-08 Thread Imre Deak

On Thu, Apr 07, 2022 at 10:32:11PM +0300, Jani Nikula wrote:
> On Thu, 07 Apr 2022, Imre Deak  wrote:
> > The next patch needs a way to read a DPCD register without the preceding
> > wake-up read in drm_dp_dpcd_read(). Export drm_dp_dpcd_access() to allow
> > this.
> 
> I think I'd rather you added a special "probe" function for this
> specific purpose. I think drm_dp_dpcd_access() is a too generic low
> level function to export, and runs the risk of complicating any
> potential future refactoring of the DP AUX code.
> 
> Something like this:
> 
> ssize_t drm_dp_dpcd_probe(struct drm_dp_aux *aux, unsigned int offset);
> 
> And you could reuse that for the wakeup in drm_dp_dpcd_read() too.

Ok, makes sense, I'll change that.

> BR,
> Jani.
> 
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/dp/drm_dp.c| 19 +--
> >  include/drm/dp/drm_dp_helper.h |  2 ++
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c
> > index 580016a1b9eb7..8b181314edcbe 100644
> > --- a/drivers/gpu/drm/dp/drm_dp.c
> > +++ b/drivers/gpu/drm/dp/drm_dp.c
> > @@ -470,8 +470,22 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
> >   * Both native and I2C-over-AUX transactions are supported.
> >   */
> >  
> > -static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> > - unsigned int offset, void *buffer, size_t size)
> > +/**
> > + * drm_dp_dpcd_access() - read or write a series of bytes from/to the DPCD
> > + * @aux: DisplayPort AUX channel (SST)
> > + * @request: DP_AUX_NATIVE_READ or DP_AUX_NATIVE_WRITE
> > + * @offset: address of the (first) register to read or write
> > + * @buffer: buffer with the register values to write or the register 
> > values read
> > + * @size: number of bytes in @buffer
> > + *
> > + * Returns the number of bytes transferred on success, or a negative error
> > + * code on failure. This is a low-level function only for SST sinks and 
> > cases
> > + * where calling drm_dp_dpcd_read()/write() is not possible (for instance 
> > due
> > + * to the wake-up register read in drm_dp_dpcd_read()). For all other cases
> > + * the latter functions should be used.
> > + */
> > +int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> > +  unsigned int offset, void *buffer, size_t size)
> >  {
> > struct drm_dp_aux_msg msg;
> > unsigned int retry, native_reply;
> > @@ -526,6 +540,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> > u8 request,
> > mutex_unlock(>hw_mutex);
> > return ret;
> >  }
> > +EXPORT_SYMBOL(drm_dp_dpcd_access);
> >  
> >  /**
> >   * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> > diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h
> > index 1eccd97419436..7cf6e83434a8c 100644
> > --- a/include/drm/dp/drm_dp_helper.h
> > +++ b/include/drm/dp/drm_dp_helper.h
> > @@ -2053,6 +2053,8 @@ struct drm_dp_aux {
> > bool is_remote;
> >  };
> >  
> > +int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> > +  unsigned int offset, void *buffer, size_t size);
> >  ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> >  void *buffer, size_t size);
> >  ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int offset,
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Tvrtko Ursulin




On 07/04/2022 17:45, Matthew Auld wrote:

All of CI is just failing with the following, which prevents loading of
the module:

 i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")


Has this one went in bypassing i915 CI and merged via drm-misc-next? If 
so I think it's the 2nd large disruption to i915 CI flows recently so 
the lesson here is try not to bypass i915 CI when merging i915 patches.


In this particular example, unless there were merge conflicts causing 
the series not to apply against drm-tip, it should have been doable to 
copy intel-gfx on all patches and so get the CI results. (Even if just 
with --subject-prefix=CI && --suppress-cc=all before merging.)


The second question is which branch to merge through, on which I think 
i915 maintainers would have liked to be consulted.


Regards,

Tvrtko


Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2998d895a6b3..1c88d4121658 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,14 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr)
  {
+   long ret;
+
assert_object_held(obj);
-   return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
-intr, MAX_SCHEDULE_TIMEOUT);
+
+   ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+   intr, MAX_SCHEDULE_TIMEOUT);
+
+   return ret < 0 ? ret : 0;
  }
  
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)

Re: [Intel-gfx] [PATCH 12/15] drm/i915: drop bo->moving dependency

2022-04-08 Thread Jani Nikula

On Thu, 07 Apr 2022, "Christian König"  wrote:
> That should now be handled by the common dma_resv framework.
>
> Signed-off-by: Christian König 
> Reviewed-by: Daniel Vetter 
> Cc: intel-gfx@lists.freedesktop.org

So, where are the i915 maintainer acks for merging this (and the other
patches in the series touching i915) via drm-misc-next?

Daniel's Reviewed-by is not an ack to merge outside drm-intel-next.

We don't merge i915 stuff without passing CI results. Apparently this
one failed enough machines that the CI had to be stopped entirely.


BR,
Jani.


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c| 41 ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  8 +---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 15 +--
>  .../drm/i915/gem/selftests/i915_gem_migrate.c |  3 +-
>  .../drm/i915/gem/selftests/i915_gem_mman.c|  3 +-
>  drivers/gpu/drm/i915/i915_vma.c   |  9 +++-
>  6 files changed, 21 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 372bc220faeb..ffde7bc0a95d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -741,30 +741,19 @@ static const struct drm_gem_object_funcs 
> i915_gem_object_funcs = {
>  /**
>   * i915_gem_object_get_moving_fence - Get the object's moving fence if any
>   * @obj: The object whose moving fence to get.
> + * @fence: The resulting fence
>   *
>   * A non-signaled moving fence means that there is an async operation
>   * pending on the object that needs to be waited on before setting up
>   * any GPU- or CPU PTEs to the object's pages.
>   *
> - * Return: A refcounted pointer to the object's moving fence if any,
> - * NULL otherwise.
> + * Return: Negative error code or 0 for success.
>   */
> -struct dma_fence *
> -i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj)
> +int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
> +  struct dma_fence **fence)
>  {
> - return dma_fence_get(i915_gem_to_ttm(obj)->moving);
> -}
> -
> -void i915_gem_object_set_moving_fence(struct drm_i915_gem_object *obj,
> -   struct dma_fence *fence)
> -{
> - struct dma_fence **moving = _gem_to_ttm(obj)->moving;
> -
> - if (*moving == fence)
> - return;
> -
> - dma_fence_put(*moving);
> - *moving = dma_fence_get(fence);
> + return dma_resv_get_singleton(obj->base.resv, DMA_RESV_USAGE_KERNEL,
> +   fence);
>  }
>  
>  /**
> @@ -782,23 +771,9 @@ void i915_gem_object_set_moving_fence(struct 
> drm_i915_gem_object *obj,
>  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
> bool intr)
>  {
> - struct dma_fence *fence = i915_gem_to_ttm(obj)->moving;
> - int ret;
> -
>   assert_object_held(obj);
> - if (!fence)
> - return 0;
> -
> - ret = dma_fence_wait(fence, intr);
> - if (ret)
> - return ret;
> -
> - if (fence->error)
> - return fence->error;
> -
> - i915_gem_to_ttm(obj)->moving = NULL;
> - dma_fence_put(fence);
> - return 0;
> + return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
> +  intr, MAX_SCHEDULE_TIMEOUT);
>  }
>  
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 02c37fe4a535..e11d82a9f7c3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -520,12 +520,8 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
> *obj)
>   i915_gem_object_unpin_pages(obj);
>  }
>  
> -struct dma_fence *
> -i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj);
> -
> -void i915_gem_object_set_moving_fence(struct drm_i915_gem_object *obj,
> -   struct dma_fence *fence);
> -
> +int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj,
> +  struct dma_fence **fence);
>  int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
> bool intr);
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index 438b8a95b3d1..a10716f4e717 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -467,19 +467,6 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
>   return fence;
>  }
>  
> -static int
> -prev_deps(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
> -   struct i915_deps *deps)
> -{
> - int ret;
> -
> - ret = i915_deps_add_dependency(deps, bo->moving, ctx);
> - if (!ret)
> - ret =

Re: [Intel-gfx] [PATCH v9 4/9] drm/i915/gt: Pass the -EINVAL when emit_pte doesn't update any PTE

2022-04-08 Thread Intel




On 4/5/22 17:08, Ramalingam C wrote:

When emit_pte doesn't update any PTE with return value as 0, interpret
it as -EINVAL.

v2:
   Add missing goto [Thomas]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/gt/intel_migrate.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index e0f1c727662e..6378d4450e1a 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -577,7 +577,11 @@ intel_context_migrate_copy(struct intel_context *ce,
  
  		len = emit_pte(rq, _src, src_cache_level, src_is_lmem,

   src_offset, CHUNK_SZ);


    if (len <= 0) {

        err = len ? len : -EINVAL;

        goto out_rq;

} ?

Up to you.

Reviewed-by: Thomas Hellström 




-   if (len <= 0) {
+   if (!len) {
+   err = -EINVAL;
+   goto out_rq;
+   }
+   if (len < 0) {
err = len;
goto out_rq;
}

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v3] tests/gem_lmem_swapping: limit lmem to 4G

2022-04-08 Thread Tvrtko Ursulin




On 28/03/2022 12:18, Petri Latvala wrote:

On Mon, Mar 28, 2022 at 11:08:59AM +0100, Matthew Auld wrote:

From: CQ Tang 

On some systems lmem can be as large as 16G, which seems to trigger
various CI timeouts, and in the best case just takes a long time. For
the purposes of the test we should be able to limit to 4G, without any
big loss in coverage.

v2:
  - No need to try again without the modparam; if it's not supported it
will still load the driver just fine.
v3(Petri):
  - Add a helpful debug print in case the kernel is missing support for
the lmem_size modparam.

Signed-off-by: CQ Tang 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
Cc: Petri Latvala 
Reviewed-by: Thomas Hellström 
Reviewed-by: Nirmoy Das 
---
  tests/i915/gem_lmem_swapping.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tests/i915/gem_lmem_swapping.c b/tests/i915/gem_lmem_swapping.c
index 31644bcd..6cf1acec 100644
--- a/tests/i915/gem_lmem_swapping.c
+++ b/tests/i915/gem_lmem_swapping.c
@@ -526,11 +526,20 @@ igt_main_args("", long_options, help_str, opt_handler, 
NULL)
  
  	igt_fixture {

struct intel_execution_engine2 *e;
+   char *tmp;
  
-		i915 = drm_open_driver(DRIVER_INTEL);

+   igt_i915_driver_unload();
+   igt_assert_eq(igt_i915_driver_load("lmem_size=4096"), 0);
+
+   i915 = __drm_open_driver(DRIVER_INTEL);
igt_require_gem(i915);
igt_require(gem_has_lmem(i915));
  
+		tmp = __igt_params_get(i915, "lmem_size");

+   if (!tmp)
+   igt_info("lmem_size modparam not supported on this kernel. 
Continuing with full lmem size. This may result in CI timeouts.");
+   free(tmp);


Newline at the end missing. With that added,
Reviewed-by: Petri Latvala 


+
regions = gem_get_query_memory_regions(i915);
igt_require(regions);
  
@@ -556,6 +565,7 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)

intel_ctx_destroy(i915, ctx);
free(regions);
close(i915);
+   igt_i915_driver_unload();


If this causes an extra module unload on legacy platforms just after 
tests skips due not having local memory, is it a good idea? Would it 
make sense to move the skip to before unload and reload with lmem_size 
param and only unload if that condition was passed?


Regards,

Tvrtko


}
  
  	igt_exit();

--
2.34.1

[Intel-gfx] [PATCH v2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Matthew Auld

All of CI is just failing with the following, which prevents loading of
the module:

i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

v2(Lucas): handle ret == 0

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")
Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Lucas De Marchi 
Cc: Daniel Vetter 
Reviewed-by: Christian König  #v1
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2998d895a6b3..747ac65e060f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,16 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,
 int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr)
 {
+   long ret;
+
assert_object_held(obj);
-   return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
-intr, MAX_SCHEDULE_TIMEOUT);
+
+   ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+   intr, MAX_SCHEDULE_TIMEOUT);
+   if (!ret)
+   ret = -ETIME;
+
+   return ret < 0 ? ret : 0;
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
-- 
2.34.1

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix broken build

2022-04-08 Thread Matthew Auld


On 07/04/2022 17:49, Christian König wrote:

Am 07.04.22 um 18:45 schrieb Matthew Auld:

I guess this was missed in the conversion or something.

Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 


My best guess is that this is a rebase/merge conflict. I'm 100% sure 
i915 was compiling fine before I pushed the patch.


Anyway Reviewed-by: Christian König  for the 
series.


Christian, could you merge the first patch? I need to re-spin the second 
patch it seems.




Thanks,
Christian.


---
  drivers/gpu/drm/i915/i915_deps.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

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

index 999210b37325..297b8e4e42ee 100644
--- a/drivers/gpu/drm/i915/i915_deps.c
+++ b/drivers/gpu/drm/i915/i915_deps.c
@@ -226,7 +226,7 @@ int i915_deps_add_resv(struct i915_deps *deps, 
struct dma_resv *resv,

  struct dma_fence *fence;
  dma_resv_assert_held(resv);
-    dma_resv_for_each_fence(, resv, true, fence) {
+    dma_resv_for_each_fence(, resv, dma_resv_usage_rw(true), 
fence) {

  int ret = i915_deps_add_dependency(deps, fence, ctx);
  if (ret)

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-08 Thread Tvrtko Ursulin




On 08/04/2022 08:58, Daniel Vetter wrote:

On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.

This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem.

Nice value will only apply to requests which originate from user contexts
and have default context priority. This is to avoid disturbing any
application made choices of low and high (batch processing and latency
sensitive compositing). In this case nice value adjusts the effective
priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.

This means that userspace using the context priority uapi directly has a
wider range of possible adjustments (in practice that only applies to
execlists platforms - with GuC there are only three priority buckets), but
in all cases nice adjustment has the expected effect: positive nice
lowering the scheduling priority and negative nice raising it.

Signed-off-by: Tvrtko Ursulin 


I don't think adding any more fancy features to i915-scheduler makes
sense, at least not before we've cut over to drm/sched.


Why do you think so?

Drm/sched has at least low/normal/high priority and surely we will keep 
the i915 context priority ABI.


Then this patch is not touching the i915 scheduler at all, neither it is 
fancy.


The cover letter explains how it implements the same approach as the IO 
scheduler. And it explains the reasoning and benefits. Provides an user 
experience benefit today, which can easily be preserved.


Regards,

Tvrtko


-Daniel


---
  drivers/gpu/drm/i915/i915_request.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 582770360ad1..e5cfa073d8f0 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1811,8 +1811,17 @@ void i915_request_add(struct i915_request *rq)
/* XXX placeholder for selftests */
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
-   if (ctx)
+   if (ctx) {
attr = ctx->sched;
+   /*
+* Inherit process nice when scheduling user contexts but only
+* if context has the default priority to avoid touching
+* contexts where GEM uapi has been used to explicitly lower
+* or elevate it.
+*/
+   if (attr.priority == I915_CONTEXT_DEFAULT_PRIORITY)
+   attr.priority = -task_nice(current);
+   }
rcu_read_unlock();
  
  	__i915_request_queue(rq, );

--
2.32.0

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix i915_gem_object_wait_moving_fence

2022-04-08 Thread Matthew Auld


On 08/04/2022 06:00, Lucas De Marchi wrote:

On Thu, Apr 07, 2022 at 05:45:32PM +0100, Matthew Auld wrote:

All of CI is just failing with the following, which prevents loading of
the module:

   i915 :03:00.0: [drm] *ERROR* Scratch setup failed

Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now calls into dma_resv_wait_timeout() which can return the
remaining timeout, leading to the caller thinking this is an error.

Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency")
Signed-off-by: Matthew Auld 
Cc: Christian König 
Cc: Daniel Vetter 
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)

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

index 2998d895a6b3..1c88d4121658 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -772,9 +772,14 @@ int i915_gem_object_get_moving_fence(struct 
drm_i915_gem_object *obj,

int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
  bool intr)
{
+    long ret;
+
assert_object_held(obj);
-    return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
- intr, MAX_SCHEDULE_TIMEOUT);
+
+    ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL,
+    intr, MAX_SCHEDULE_TIMEOUT);
+
+    return ret < 0 ? ret : 0;


shouldn't == 0 also be an error since it would be a timeout?


Hmm, I guess so...



Lucas De Marchi

Re: [Intel-gfx] [PATCH 0/4] drm/i915/dg2: Add support for render/media decompression

2022-04-08 Thread Jani Nikula

On Fri, 08 Apr 2022, Jani Nikula  wrote:
> On Mon, 04 Apr 2022, Imre Deak  wrote:
>> This is a rebased version of patches 15-17 of [1], adding DG2 display
>> engine support for decompressing render and media compressed
>> framebuffers.
>>
>> The dependency patches from [1] should be merged already to drm-tip.
>>
>> It addresses the review comments on the modifier layout description from
>> Nanley, updates the commit logs vs. flat CCS and Tile4 and splits out
>> the changes adding the modifiers to drm_fourcc.h to separate patches.
>
> Cc'd a bunch more people; ack on merging patches 2 & 4 via drm-intel?

Both off by one, I mean 1 & 3.

>
> BR,
> Jani.
>
>
>>
>> [1] https://patchwork.freedesktop.org/series/95686/
>>
>> Cc: Anshuman Gupta 
>> Cc: Ramalingam C 
>> Cc: Radhakrishna Sripada 
>> Cc: Matt Roper 
>> Cc: Mika Kahola 
>> Cc: Juha-Pekka Heikkilä 
>> Cc: Nanley Chery 
>>
>> Anshuman Gupta (1):
>>   drm/i915/dg2: Add support for DG2 clear color compression
>>
>> Matt Roper (2):
>>   drm/fourcc: Introduce format modifiers for DG2 render and media
>> compression
>>   drm/i915/dg2: Add support for DG2 render and media compression
>>
>> Mika Kahola (1):
>>   drm/fourcc: Introduce format modifier for DG2 clear color
>>
>>  drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
>>  drivers/gpu/drm/i915/display/intel_fb.c   | 53 +++
>>  .../drm/i915/display/skl_universal_plane.c| 49 +
>>  include/uapi/drm/drm_fourcc.h | 36 +
>>  4 files changed, 122 insertions(+), 20 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-08 Thread Daniel Vetter

On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Inherit submitter nice at point of request submission to account for long
> running processes getting either externally or self re-niced.
> 
> This accounts for the current processing landscape where computational
> pipelines are composed of CPU and GPU parts working in tandem.
> 
> Nice value will only apply to requests which originate from user contexts
> and have default context priority. This is to avoid disturbing any
> application made choices of low and high (batch processing and latency
> sensitive compositing). In this case nice value adjusts the effective
> priority in the narrow band of -19 to +20 around
> I915_CONTEXT_DEFAULT_PRIORITY.
> 
> This means that userspace using the context priority uapi directly has a
> wider range of possible adjustments (in practice that only applies to
> execlists platforms - with GuC there are only three priority buckets), but
> in all cases nice adjustment has the expected effect: positive nice
> lowering the scheduling priority and negative nice raising it.
> 
> Signed-off-by: Tvrtko Ursulin 

I don't think adding any more fancy features to i915-scheduler makes
sense, at least not before we've cut over to drm/sched.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_request.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 582770360ad1..e5cfa073d8f0 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1811,8 +1811,17 @@ void i915_request_add(struct i915_request *rq)
>   /* XXX placeholder for selftests */
>   rcu_read_lock();
>   ctx = rcu_dereference(rq->context->gem_context);
> - if (ctx)
> + if (ctx) {
>   attr = ctx->sched;
> + /*
> +  * Inherit process nice when scheduling user contexts but only
> +  * if context has the default priority to avoid touching
> +  * contexts where GEM uapi has been used to explicitly lower
> +  * or elevate it.
> +  */
> + if (attr.priority == I915_CONTEXT_DEFAULT_PRIORITY)
> + attr.priority = -task_nice(current);
> + }
>   rcu_read_unlock();
>  
>   __i915_request_queue(rq, );
> -- 
> 2.32.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 0/4] drm/i915/dg2: Add support for render/media decompression

2022-04-08 Thread Jani Nikula

On Mon, 04 Apr 2022, Imre Deak  wrote:
> This is a rebased version of patches 15-17 of [1], adding DG2 display
> engine support for decompressing render and media compressed
> framebuffers.
>
> The dependency patches from [1] should be merged already to drm-tip.
>
> It addresses the review comments on the modifier layout description from
> Nanley, updates the commit logs vs. flat CCS and Tile4 and splits out
> the changes adding the modifiers to drm_fourcc.h to separate patches.

Cc'd a bunch more people; ack on merging patches 2 & 4 via drm-intel?

BR,
Jani.


>
> [1] https://patchwork.freedesktop.org/series/95686/
>
> Cc: Anshuman Gupta 
> Cc: Ramalingam C 
> Cc: Radhakrishna Sripada 
> Cc: Matt Roper 
> Cc: Mika Kahola 
> Cc: Juha-Pekka Heikkilä 
> Cc: Nanley Chery 
>
> Anshuman Gupta (1):
>   drm/i915/dg2: Add support for DG2 clear color compression
>
> Matt Roper (2):
>   drm/fourcc: Introduce format modifiers for DG2 render and media
> compression
>   drm/i915/dg2: Add support for DG2 render and media compression
>
> Mika Kahola (1):
>   drm/fourcc: Introduce format modifier for DG2 clear color
>
>  drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_fb.c   | 53 +++
>  .../drm/i915/display/skl_universal_plane.c| 49 +
>  include/uapi/drm/drm_fourcc.h | 36 +
>  4 files changed, 122 insertions(+), 20 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp: Don't rewrite link config when setting phy CTS test pattern with LTTPR

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/dp: Don't rewrite link config when setting phy CTS test pattern 
with LTTPR
URL   : https://patchwork.freedesktop.org/series/102385/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11474 -> Patchwork_22824


Summary
---

  **FAILURE**

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

Participating hosts (50 -> 36)
--

  Missing(14): fi-bdw-samus bat-adls-5 bat-dg1-6 bat-adlm-1 bat-dg2-9 
fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-hsw-1 fi-elk-e7500 bat-rpls-1 bat-rpls-2 
bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@basic:
- fi-snb-2600:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-snb-2600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-bsw-kefka:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-bsw-kefka/igt@gem_lmem_swapp...@parallel-random-engines.html

  
 Warnings 

  * igt@gem_lmem_swapping@basic:
- fi-bdw-5557u:   [FAIL][4] ([i915#5602]) -> [FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11474/fi-bdw-5557u/igt@gem_lmem_swapp...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-bdw-5557u/igt@gem_lmem_swapp...@basic.html

  
 Suppressed 

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

  * igt@gem_lmem_swapping@basic:
- {fi-jsl-1}: [FAIL][6] ([i915#5602]) -> [FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11474/fi-jsl-1/igt@gem_lmem_swapp...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-jsl-1/igt@gem_lmem_swapp...@basic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-process:
- fi-ivb-3770:NOTRUN -> [SKIP][8] ([fdo#109271]) +146 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-ivb-3770/igt@gem_close_r...@basic-process.html

  * igt@gem_exec_fence@basic-await:
- fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271]) +151 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-bsw-nick/igt@gem_exec_fe...@basic-await.html

  * igt@i915_getparams_basic@basic-eu-total:
- fi-snb-2600:NOTRUN -> [SKIP][10] ([fdo#109271]) +150 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-snb-2600/igt@i915_getparams_ba...@basic-eu-total.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-bsw-nick:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#5341])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-bsw-nick/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2600:NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#5341])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-snb-2600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-ivb-3770:NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#5341])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-ivb-3770/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
 Warnings 

  * igt@gem_lmem_swapping@basic:
- fi-skl-guc: [FAIL][14] ([i915#4547]) -> [FAIL][15] ([i915#5602])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11474/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
- fi-hsw-g3258:   [FAIL][16] -> [FAIL][17] ([i915#5602])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11474/fi-hsw-g3258/igt@gem_lmem_swapp...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22824/fi-hsw-g3258/igt@gem_lmem_swapp...@basic.html
- fi-cfl-8109u:   [FAIL][18] -> [FAIL][19] ([i915#5602])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11474/fi-cfl-8109u/igt@gem_lmem_swapp...@basic.html
   [19]:

Re: [Intel-gfx] [PATCH v3 00/17] fbcon cleanups

2022-04-08 Thread Daniel Vetter

On Tue, Apr 05, 2022 at 11:03:18PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> Finally got around to respin this. Changes:
> - Bunch more acks and r-b, still not yet all patches.
> - one tiny fix for a bisect issue, end result was all fine
> - I dropped the last to patches to make registered_fb private, that needs
>   more work around how we handle the unregister vs driver load races
>   around fw fbdev drivers.
> 
> Review and acks on the remaining patches very much welcome, I'd like to
> push this pile.

I realized I got reviews/acks on all of them already, so pushed the lot.

Thanks everyone who helped.
-Daniel

> 
> Thanks, Daniel
> 
> Daniel Vetter (17):
>   fbcon: delete a few unneeded forward decl
>   fbcon: Move fbcon_bmove(_rec) functions
>   fbcon: Introduce wrapper for console->fb_info lookup
>   fbcon: delete delayed loading code
>   fbdev/sysfs: Fix locking
>   fbcon: Use delayed work for cursor
>   fbcon: Replace FBCON_FLAGS_INIT with a boolean
>   fb: Delete fb_info->queue
>   fbcon: Extract fbcon_open/release helpers
>   fbcon: Ditch error handling for con2fb_release_oldinfo
>   fbcon: move more common code into fb_open()
>   fbcon: use lock_fb_info in fbcon_open/release
>   fbcon: Consistently protect deferred_takeover with console_lock()
>   fbcon: Move console_lock for register/unlink/unregister
>   fbcon: Move more code into fbcon_release
>   fbcon: untangle fbcon_exit
>   fbcon: Maintain a private array of fb_info
> 
>  drivers/video/fbdev/core/fbcon.c   | 692 ++---
>  drivers/video/fbdev/core/fbcon.h   |   8 +-
>  drivers/video/fbdev/core/fbmem.c   |  27 +-
>  drivers/video/fbdev/core/fbsysfs.c |   2 +
>  include/linux/fb.h |   1 -
>  5 files changed, 333 insertions(+), 397 deletions(-)
> 
> -- 
> 2.34.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Fix warnings about PSR lock not held (rev3)

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Fix warnings about PSR lock not held (rev3)
URL   : https://patchwork.freedesktop.org/series/102298/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22818


Summary
---

  **FAILURE**

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

Participating hosts (49 -> 49)
--

  Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4 
  Missing(4): bat-rpls-1 fi-blb-e6850 fi-bsw-cyan fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@basic:
- fi-cfl-8109u:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-cfl-8109u/igt@gem_lmem_swapp...@basic.html

  
 Warnings 

  * igt@gem_lmem_swapping@basic:
- fi-kbl-7567u:   [FAIL][2] ([i915#5602]) -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-7567u/igt@gem_lmem_swapp...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-kbl-7567u/igt@gem_lmem_swapp...@basic.html

  
 Suppressed 

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

  * igt@perf_pmu@busy-start:
- {shard-dg1}:NOTRUN -> [SKIP][4] +16 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/shard-dg1-15/igt@perf_...@busy-start.html

  * igt@runner@aborted:
- {bat-hsw-1}:NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/bat-hsw-1/igt@run...@aborted.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bwr-2160:NOTRUN -> [FAIL][6] ([i915#5605])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-bwr-2160/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-kbl-8809g/igt@core_a...@basic-auth.html

  * igt@fbdev@eof:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#2582]) +4 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/bat-dg1-5/igt@fb...@eof.html
- fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][9] ([i915#5557])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-kbl-8809g/igt@fb...@eof.html

  * igt@gem_basic@create-close:
- fi-ivb-3770:NOTRUN -> [SKIP][10] ([fdo#109271]) +146 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-ivb-3770/igt@gem_ba...@create-close.html

  * igt@gem_lmem_swapping@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][11] ([i915#5602])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/bat-dg1-5/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#5174]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/bat-dg1-5/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][13] ([fdo#109271]) +146 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-ivb-3770:NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#5341])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-ivb-3770/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#2575] / [i915#5341])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/bat-dg1-5/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#5341])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#5341])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22818/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
URL   : https://patchwork.freedesktop.org/series/102352/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22819


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 49)
--

  Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4 
  Missing(4): fi-blb-e6850 shard-dg1 fi-bsw-cyan fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][1], [SKIP][2]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- {bat-jsl-2}:NOTRUN -> ([SKIP][3], [SKIP][4]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html

  * igt@prime_self_import@basic-llseek-size:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][5], [SKIP][6]) ([i915#2575]) +66 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html

  * igt@prime_vgem@basic-fence-read:
- {bat-jsl-2}:NOTRUN -> ([SKIP][7], [SKIP][8]) ([i915#2575]) +66 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html

  * igt@runner@aborted:
- {bat-adls-5}:   [FAIL][9] ([i915#4312]) -> ([FAIL][10], [FAIL][11])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/bat-adls-5/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
- {bat-hsw-1}:NOTRUN -> ([FAIL][12], [FAIL][13])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
- {fi-jsl-1}: [FAIL][14] ([i915#4312]) -> [FAIL][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-jsl-1/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-jsl-1/igt@run...@aborted.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bwr-2160:NOTRUN -> [FAIL][16] ([i915#5605])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-bwr-2160/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- fi-kbl-8809g:   NOTRUN -> [SKIP][17] ([fdo#109271]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-8809g/igt@core_a...@basic-auth.html

  * igt@fbdev@eof:
- fi-kbl-8809g:   NOTRUN -> [INCOMPLETE][18] ([i915#5557])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-8809g/igt@fb...@eof.html

  * igt@gem_basic@create-close:
- bat-dg1-6:  NOTRUN -> ([SKIP][19], [SKIP][20]) ([i915#2575]) +143 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@gem_ba...@create-close.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@gem_ba...@create-close.html

  * igt@gem_close_race@basic-process:
- fi-ivb-3770:NOTRUN -> [SKIP][21] ([fdo#109271]) +146 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-ivb-3770/igt@gem_close_r...@basic-process.html

  * igt@gem_lmem_swapping@basic:
- fi-cfl-8109u:   NOTRUN -> [FAIL][22] ([i915#5602])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-cfl-8109u/igt@gem_lmem_swapp...@basic.html
- bat-dg1-6:  NOTRUN -> ([SKIP][23], [SKIP][24]) ([i915#5602])
   [23]:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
URL   : https://patchwork.freedesktop.org/series/102352/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22819


Summary
---

  **FAILURE**

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

Participating hosts (49 -> 48)
--

  Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4 
  Missing(5): fi-blb-e6850 fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-rte:
- bat-dg1-6:  NOTRUN -> ([SKIP][1], [SKIP][2]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-x1275:   [FAIL][3] ([i915#4312]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-x1275/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-x1275/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][5] ([i915#4312] / [i915#5257]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-guc/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][7] ([i915#4312]) -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-7567u/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-7567u/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][9], [SKIP][10]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- {bat-jsl-2}:NOTRUN -> ([SKIP][11], [SKIP][12]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html

  * igt@prime_self_import@basic-llseek-size:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][13], [SKIP][14]) ([i915#2575]) +66 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html

  * igt@prime_vgem@basic-fence-read:
- {bat-jsl-2}:NOTRUN -> ([SKIP][15], [SKIP][16]) ([i915#2575]) +66 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html

  * igt@runner@aborted:
- {bat-adls-5}:   [FAIL][17] ([i915#4312]) -> ([FAIL][18], [FAIL][19])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/bat-adls-5/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
- {bat-hsw-1}:NOTRUN -> ([FAIL][20], [FAIL][21])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
- {fi-jsl-1}: [FAIL][22] ([i915#4312]) -> [FAIL][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-jsl-1/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-jsl-1/igt@run...@aborted.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bwr-2160:NOTRUN ->

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
URL   : https://patchwork.freedesktop.org/series/102352/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22819


Summary
---

  **FAILURE**

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

Participating hosts (49 -> 48)
--

  Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4 
  Missing(5): fi-blb-e6850 fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-rte:
- bat-dg1-6:  NOTRUN -> ([SKIP][1], [SKIP][2]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-x1275:   [FAIL][3] ([i915#4312]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-x1275/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-x1275/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][5] ([i915#4312] / [i915#5257]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-guc/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][7] ([i915#4312]) -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-7567u/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-7567u/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][9], [SKIP][10]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- {bat-jsl-2}:NOTRUN -> ([SKIP][11], [SKIP][12]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html

  * igt@prime_self_import@basic-llseek-size:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][13], [SKIP][14]) ([i915#2575]) +66 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html

  * igt@prime_vgem@basic-fence-read:
- {bat-jsl-2}:NOTRUN -> ([SKIP][15], [SKIP][16]) ([i915#2575]) +66 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html

  * igt@runner@aborted:
- {bat-adls-5}:   [FAIL][17] ([i915#4312]) -> ([FAIL][18], [FAIL][19])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/bat-adls-5/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
- {bat-hsw-1}:NOTRUN -> ([FAIL][20], [FAIL][21])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
- {fi-jsl-1}: [FAIL][22] ([i915#4312]) -> [FAIL][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-jsl-1/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-jsl-1/igt@run...@aborted.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bwr-2160:NOTRUN ->

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL

2022-04-08 Thread Patchwork

== Series Details ==

Series: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
URL   : https://patchwork.freedesktop.org/series/102352/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11472 -> Patchwork_22819


Summary
---

  **FAILURE**

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

Participating hosts (49 -> 48)
--

  Additional (4): bat-hsw-1 bat-rpls-2 fi-bwr-2160 bat-adlp-4 
  Missing(5): fi-blb-e6850 fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-rte:
- bat-dg1-6:  NOTRUN -> ([SKIP][1], [SKIP][2]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-dg1-6/igt@i915_pm_...@basic-rte.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-x1275:   [FAIL][3] ([i915#4312]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-x1275/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-x1275/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][5] ([i915#4312] / [i915#5257]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-guc/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][7] ([i915#4312]) -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-kbl-7567u/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-kbl-7567u/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][9], [SKIP][10]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- {bat-jsl-2}:NOTRUN -> ([SKIP][11], [SKIP][12]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@i915_pm_...@basic-rte.html

  * igt@prime_self_import@basic-llseek-size:
- {bat-rpls-2}:   NOTRUN -> ([SKIP][13], [SKIP][14]) ([i915#2575]) +66 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-rpls-2/igt@prime_self_imp...@basic-llseek-size.html

  * igt@prime_vgem@basic-fence-read:
- {bat-jsl-2}:NOTRUN -> ([SKIP][15], [SKIP][16]) ([i915#2575]) +66 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-jsl-2/igt@prime_v...@basic-fence-read.html

  * igt@runner@aborted:
- {bat-adls-5}:   [FAIL][17] ([i915#4312]) -> ([FAIL][18], [FAIL][19])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/bat-adls-5/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-adls-5/igt@run...@aborted.html
- {bat-hsw-1}:NOTRUN -> ([FAIL][20], [FAIL][21])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/bat-hsw-1/igt@run...@aborted.html
- {fi-jsl-1}: [FAIL][22] ([i915#4312]) -> [FAIL][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11472/fi-jsl-1/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22819/fi-jsl-1/igt@run...@aborted.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bwr-2160:NOTRUN ->

1 2 >

1 - 100 of 106 matches

Mail list logo