[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/: Extend VRR platform support to Gen 11

[Patchwork]

== Series Details ==

Series: drm/i915/: Extend VRR platform support to Gen 11
URL   : https://patchwork.freedesktop.org/series/96998/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10888_full -> Patchwork_21609_full


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@busy-flip@a-hdmi-a2:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-glk7/igt@kms_flip@busy-f...@a-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-glk2/igt@kms_flip@busy-f...@a-hdmi-a2.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-apl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb5/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-tglb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#2369])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-iclb3/igt@gem_exec_capture@p...@bcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-iclb7/igt@gem_exec_capture@p...@bcs0.html
- shard-skl:  NOTRUN -> [INCOMPLETE][10] ([i915#2369])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-skl8/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb3/igt@gem_exec_f...@basic-deadline.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-tglb7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271]) +32 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-iclb7/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-iclb2/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][19] ([i915#2842]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html
- shard-kbl:  [PASS][20] -> [SKIP][21] ([fdo#109271])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21609/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][22] -> [FAIL][23] ([i915#2842])
   [22]:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/adl_p: Add adl-p ddc pin mapping

[Patchwork]

== Series Details ==

Series: drm/i915/adl_p: Add adl-p ddc pin mapping
URL   : https://patchwork.freedesktop.org/series/97009/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10889 -> Patchwork_21611


Summary
---

  **FAILURE**

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

Participating hosts (37 -> 35)
--

  Additional (2): fi-kbl-soraka fi-icl-u2 
  Missing(4): fi-ctg-p8600 fi-bsw-cyan bat-dg1-6 fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10889/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([fdo#109315]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +8 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10889/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-kbl-soraka/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_21611/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][9] -> [INCOMPLETE][10] ([i915#2940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10889/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

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

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.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_21611/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21611/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#1436] / 
[i915#2722] / [i915#3428] / [i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patc

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Hold RPM wakelock during PXP suspend (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Hold RPM wakelock during PXP suspend (rev3)
URL   : https://patchwork.freedesktop.org/series/96658/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10888_full -> Patchwork_21610_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 10)
--

  Missing(1): shard-rkl 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-apl:  [PASS][1] -> [TIMEOUT][2] ([i915#3063])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-apl2/igt@gem_...@in-flight-contexts-immediate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-apl6/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#2369] / 
[i915#3371] / [i915#3731])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb6/igt@gem_exec_capture@p...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-tglb3/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][5] ([i915#2369])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-skl7/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +30 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-skl7/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2852])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-iclb7/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-iclb8/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][12] -> [SKIP][13] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][14] -> [INCOMPLETE][15] ([i915#456])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb1/igt@gem_exec_susp...@basic-s0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10888/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-tglb7/igt@gem_huc_c...@huc-copy.html
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-kbl2/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-kbl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-kbl2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@verify-pxp-stale-ctx-execution:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#4270]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-tglb6/igt@gem_...@verify-pxp-stale-ctx-execution.html

  * igt@gem_userptr_blits@dmabuf-unsync:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-iclb5/igt@gem_userptr_bl...@dmabuf-unsync.html

  * igt@gem_userptr_blits@input-checking:
- shard-skl:  NOTRUN -> [DMESG-WARN][23] ([i915#3002])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/shard-skl7/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_w

Re: [Intel-gfx] [PATCH 1/3] drm/i915/driver: rename i915_drv.c to i915_driver.c

[Jani Nikula]

On Thu, 11 Nov 2021, Jani Nikula  wrote:
> This is more about trimming i915_drv.h than the renamed
> i915_driver.[ch]. Split out i915_driver.[ch] out of i915_drv.h as a
> feasible thing to do.

Pushed the series with Daniel's IRC ack.

BR,
Jani.


>
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/Makefile |  2 +-
>  .../drm/i915/{i915_drv.c => i915_driver.c}|  5 ++--
>  drivers/gpu/drm/i915/i915_driver.h| 24 +++
>  drivers/gpu/drm/i915/i915_drv.h   | 11 +
>  drivers/gpu/drm/i915/i915_pci.c   |  1 +
>  drivers/gpu/drm/i915/i915_switcheroo.c|  1 +
>  6 files changed, 31 insertions(+), 13 deletions(-)
>  rename drivers/gpu/drm/i915/{i915_drv.c => i915_driver.c} (99%)
>  create mode 100644 drivers/gpu/drm/i915/i915_driver.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7d0d0b814670..074d6b8edd23 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -30,7 +30,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
>  # Please keep these build lists sorted!
>  
>  # core driver code
> -i915-y += i915_drv.o \
> +i915-y += i915_driver.o \
> i915_config.o \
> i915_irq.o \
> i915_getparam.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> b/drivers/gpu/drm/i915/i915_driver.c
> similarity index 99%
> rename from drivers/gpu/drm/i915/i915_drv.c
> rename to drivers/gpu/drm/i915/i915_driver.c
> index 46bf3315f616..9111abafa44f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -29,8 +29,8 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -48,8 +48,8 @@
>  #include "display/intel_acpi.h"
>  #include "display/intel_bw.h"
>  #include "display/intel_cdclk.h"
> -#include "display/intel_dmc.h"
>  #include "display/intel_display_types.h"
> +#include "display/intel_dmc.h"
>  #include "display/intel_dp.h"
>  #include "display/intel_dpt.h"
>  #include "display/intel_fbdev.h"
> @@ -72,6 +72,7 @@
>  #include "pxp/intel_pxp_pm.h"
>  
>  #include "i915_debugfs.h"
> +#include "i915_driver.h"
>  #include "i915_drv.h"
>  #include "i915_ioc32.h"
>  #include "i915_irq.h"
> diff --git a/drivers/gpu/drm/i915/i915_driver.h 
> b/drivers/gpu/drm/i915/i915_driver.h
> new file mode 100644
> index ..e99c00fb6312
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_driver.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#ifndef __I915_DRIVER_H__
> +#define __I915_DRIVER_H__
> +
> +#include 
> +
> +struct pci_dev;
> +struct pci_device_id;
> +struct drm_i915_private;
> +
> +extern const struct dev_pm_ops i915_pm_ops;
> +
> +int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
> +void i915_driver_remove(struct drm_i915_private *i915);
> +void i915_driver_shutdown(struct drm_i915_private *i915);
> +
> +int i915_resume_switcheroo(struct drm_i915_private *i915);
> +int i915_suspend_switcheroo(struct drm_i915_private *i915, pm_message_t 
> state);
> +
> +#endif /* __I915_DRIVER_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 94840af45750..72619a030b0c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1785,16 +1785,7 @@ intel_vm_no_concurrent_access_wa(struct 
> drm_i915_private *i915)
>   return IS_CHERRYVIEW(i915) || intel_ggtt_update_needs_vtd_wa(i915);
>  }
>  
> -/* i915_drv.c */
> -extern const struct dev_pm_ops i915_pm_ops;
> -
> -int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
> -void i915_driver_remove(struct drm_i915_private *i915);
> -void i915_driver_shutdown(struct drm_i915_private *i915);
> -
> -int i915_resume_switcheroo(struct drm_i915_private *i915);
> -int i915_suspend_switcheroo(struct drm_i915_private *i915, pm_message_t 
> state);
> -
> +/* i915_getparam.c */
>  int i915_getparam_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 5e6795853dc3..d7548605aa08 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  
> +#include "i915_driver.h"
>  #include "i915_drv.h"
>  #include "i915_pci.h"
>  
> diff --git a/drivers/gpu/drm/i915/i915_switcheroo.c 
> b/drivers/gpu/drm/i915/i915_switcheroo.c
> index de0e224b56ce..7f06f5ad0749 100644
> --- a/drivers/gpu/drm/i915/i915_switcheroo.c
> +++ b/drivers/gpu/drm/i915/i915_switcheroo.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  
> +#include "i915_driver.h"
>  #include "i915_drv.h"
>  #include "i915_switcheroo.h"

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-gt tree

[Joonas Lahtinen]

+ intel-gfx mailing list (Stephen, can you include this going forward?)

Adding Thomas for this specific patch.

Regards, Joonas

Quoting Stephen Rothwell (2021-11-17 01:02:23)
> Hi all,
> 
> After merging the etnaviv tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'vm_fault_ttm':
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:862:9: error: too many arguments to 
> function 'ttm_bo_vm_fault_reserved'
>   862 |   ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
>   | ^~~~
> In file included from include/drm/ttm/ttm_bo_driver.h:42,
>  from drivers/gpu/drm/i915/gem/i915_gem_ttm.c:6:
> include/drm/ttm/ttm_bo_api.h:585:12: note: declared here
>   585 | vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
>   |^~~~
> 
> Caused by commit
> 
>   ebd4a8ec7799 ("drm/i915/ttm: move shrinker management into adjust_lru")
> 
> interacting with commit
> 
>   0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
> 
> from Linus' tree.
> 
> I applied the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Wed, 17 Nov 2021 09:57:09 +1100
> Subject: [PATCH] fix up for "drm/ttm: remove ttm_bo_vm_insert_huge()"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index d08a270b0921..68cfe6e9ceab 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -860,7 +860,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
>  
> if (drm_dev_enter(dev, &idx)) {
> ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> -  TTM_BO_VM_NUM_PREFAULT, 1);
> +  TTM_BO_VM_NUM_PREFAULT);
> drm_dev_exit(idx);
> } else {
> ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
> -- 
> 2.33.0
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-gt tree

[Stephen Rothwell]

Hi Joonas,

On Wed, 17 Nov 2021 12:35:50 +0200 Joonas Lahtinen 
 wrote:
>
> + intel-gfx mailing list (Stephen, can you include this going forward?)

I have added that to my contacts for this tree (so, yes :-)).

-- 
Cheers,
Stephen Rothwell


pgpu3TAyT8ZHT.pgp
Description: OpenPGP digital signature

[Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support

[Stanislav Lisovskiy]

TileF(Tile4 in bspec) format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.

v2: - Fixed wrong case condition(Jani Nikula)
- Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)

v3: - s/I915_TILING_F/TILING_4/g
- s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
- Removed unneeded fencing code

v4: - Rebased, fixed merge conflict with new table-oriented
  format modifier checking(Stan)
- Replaced the rest of "Tile F" mentions to "Tile 4"(Stan)

v5: - Still had to remove some Tile F mentionings
- Moved has_4tile from adlp to DG2(Ramalingam)
- Check specifically for DG2, but not the Display13(Imre)

Cc: Imre Deak 
Cc: Matt Roper 
Cc: Maarten Lankhorst 
Signed-off-by: Stanislav Lisovskiy 
Signed-off-by: Matt Roper 
Signed-off-by: Juha-Pekka Heikkilä 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  1 +
 drivers/gpu/drm/i915/display/intel_fb.c   | 10 ++
 drivers/gpu/drm/i915/display/intel_fbc.c  |  2 ++
 .../drm/i915/display/intel_plane_initial.c|  1 +
 .../drm/i915/display/skl_universal_plane.c| 20 +++
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_pci.c   |  1 +
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 drivers/gpu/drm/i915/intel_device_info.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   |  1 +
 include/uapi/drm/drm_fourcc.h |  8 
 11 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0ceee8ac6671..eaea986dff99 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7743,6 +7743,7 @@ static int intel_atomic_check_async(struct 
intel_atomic_state *state, struct int
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+   case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg_kms(&i915->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index c4a743d0913f..a3d465e111d8 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -184,6 +184,9 @@ static const struct intel_modifier_desc intel_modifiers[] = 
{
.modifier = I915_FORMAT_MOD_Yf_TILED,
.display_ver = { 9, 11 },
.plane_caps = INTEL_PLANE_CAP_TILING_Yf,
+   }, {
+   .modifier = I915_FORMAT_MOD_4_TILED,
+   .display_ver = { 12, 13 },
}, {
.modifier = I915_FORMAT_MOD_Y_TILED,
.display_ver = { 9, 13 },
@@ -544,6 +547,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_4_TILED:
+   /*
+* Each 4K tile consists of 64B(8*8) subtiles, with
+* same shape as Y Tile(i.e 4*16B OWords)
+*/
+   return 128;
case I915_FORMAT_MOD_Y_TILED_CCS:
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
@@ -726,6 +735,7 @@ unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index d0c34bc3af6c..5f2ad0f4bd81 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -898,6 +898,8 @@ static bool tiling_is_valid(struct drm_i915_private *i915,
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return DISPLAY_VER(i915) >= 9;
+   case I915_FORMAT_MOD_4_TILED:
+   return HAS_4TILE(i915);
case I915_FORMAT_MOD_X_TILED:
return true;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index dcd698a02da2..d80855ee9b96 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -125,6 +125,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg(&dev_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/skl_u

Re: [Intel-gfx] [PATCH 1/6] drm/i915: move the pre_pin earlier

[Thomas Hellström]

On Fri, 2021-11-12 at 15:32 +, Matthew Auld wrote:
> In intel_context_do_pin_ww, when calling into the pre_pin hook(which
> is
> passed the ww context) it could in theory return -EDEADLK(which is
> very
> likely with debug kernels), once we start adding more ww locking in
> there,
> like in the next patch. If so then we need to be mindful of having to
> restart the do_pin at this point.
> 
> If this is the kernel_context, or some other early in-kernel context
> where we have yet to setup the default_state, then we always inhibit
> the
> context restore, and instead rely on the delayed active_release to
> set
> the CONTEXT_VALID_BIT for us(if we even care), which should indicate
> that we have context switched away, and that our newly saved context
> state should now be valid. However, since we currently grab the
> active
> reference before the potential ww dance, we can end up setting the
> CONTEXT_VALID_BIT much too early, if we need to backoff, and then
> upon
> re-trying the do_pin, we could potentially cause the hardware to
> incorrectly load some garbage context state when later context
> switching
> to that context, but at the very least this will trigger the
> GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance
> stuff prior to arming the active reference.
> 
> For normal user contexts this shouldn't be a concern, since we should
> already have the default_state ready when initialising the lrc state,
> and so there should be no concern with active_release somehow
> prematurely setting the CONTEXT_VALID_BIT.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/gt/intel_context.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 5634d14052bc..ad44860faaf3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct
> intel_context *ce,
> if (err)
> return err;
>  
> -   err = i915_active_acquire(&ce->active);
> +   err = ce->ops->pre_pin(ce, ww, &vaddr);
> if (err)
> goto err_ctx_unpin;
>  
> -   err = ce->ops->pre_pin(ce, ww, &vaddr);
> +   err = i915_active_acquire(&ce->active);
> if (err)
> -   goto err_release;
> +   goto err_post_unpin;

Hmm, If i915_active_acquire() fails, wouldn't we end up calling
i915_active_release() here?

Thanks,
Thomas

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915: drop intel_display.h include from intel_ddi.h (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: drop intel_display.h include from 
intel_ddi.h (rev2)
URL   : https://patchwork.freedesktop.org/series/96981/
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.BAT: failure for series starting with [1/5] drm/i915: drop intel_display.h include from intel_ddi.h (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: drop intel_display.h include from 
intel_ddi.h (rev2)
URL   : https://patchwork.freedesktop.org/series/96981/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10891 -> Patchwork_21612


Summary
---

  **FAILURE**

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

Participating hosts (39 -> 32)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): fi-kbl-soraka bat-dg1-6 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  
 Suppressed 

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

  * {igt@gem_lmem_swapping@verify-random}:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [PASS][6] -> [INCOMPLETE][7] ([i915#146])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#1155])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21612/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [SKIP][17] ([fdo#109271]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-kbl-guc/igt@i

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: fix includes for headers in include/drm (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: fix includes for headers in include/drm (rev3)
URL   : https://patchwork.freedesktop.org/series/96974/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10891 -> Patchwork_21613


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 34)
--

  Additional (1): fi-tgl-1115g4 
  Missing(6): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 bat-jsl-2 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@gem_lmem_swapping@verify-random}:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([fdo#109315])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][5] ([fdo#109271]) +18 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#1155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- fi-icl-u2:  [PASS][8] -> [FAIL][9] ([i915#3049])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-icl-u2/igt@i915_pm_...@module-reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-icl-u2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@objects:
- fi-icl-u2:  [PASS][10] -> [DMESG-WARN][11] ([i915#2867]) +5 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-icl-u2/igt@i915_selftest@l...@objects.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-icl-u2/igt@i915_selftest@l...@objects.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [SKIP][17] ([fdo#109271]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bdw-5557u:   [INCOMPLET

[Intel-gfx] [PATCH 0/2] More preparation for multi gt patches

[Andi Shyti]

Hi,

the first of the two patches concludes the first stage of
refactoring which makes the use of intel_gt on the different
subsystem. It's taken from Matt's series and it has alread been
reviewed. The patch has just been replaced before any multitile
patches and I think it can be already pushed.

The second patch is on more step to prepare for the coming multi
tile. It's very invasive but it's an effort that can be paid once
and for all in order to have a cleaner way to refer to GTs.

Andi

Andi Shyti (1):
  drm/i915: Rename gt to gt0

Michał Winiarski (1):
  drm/i915: Store backpointer to GT in uncore

 .../gpu/drm/i915/display/intel_atomic_plane.c |  4 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 18 +++---
 drivers/gpu/drm/i915/display/intel_dpt.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  2 +-
 .../drm/i915/display/skl_universal_plane.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 22 
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_throttle.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 12 ++--
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  2 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  4 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
 .../drm/i915/gem/selftests/i915_gem_context.c | 10 ++--
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c| 20 +++
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++--
 drivers/gpu/drm/i915/gt/selftest_context.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  4 +-
 .../drm/i915/gt/selftest_engine_heartbeat.c   |  4 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  6 +-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c  |  8 +--
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  2 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  2 +-
 .../drm/i915/gt/selftest_ring_submission.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_slpc.c   |  6 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  2 +-
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c |  2 +-
 .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   |  2 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 38 ++---
 drivers/gpu/drm/i915/i915_debugfs_params.c|  4 +-
 drivers/gpu/drm/i915/i915_driver.c| 30 +-
 drivers/gpu/drm/i915/i915_drv.h   |  4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++---
 drivers/gpu/drm/i915/i915_getparam.c  | 10 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 +-
 drivers/gpu/drm/i915/i915_irq.c   | 56 +--
 drivers/gpu/drm/i915/i915_perf.c  |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c   | 14 ++---
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/i915_sysfs.c | 22 
 drivers/gpu/drm/i915/intel_gvt.c  |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   |  9 +--
 drivers/gpu/drm/i915/intel_uncore.h   |  3 +-
 drivers/gpu/drm/i915/intel_wopcm.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_active.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  6 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_request.c | 10 ++--
 .../gpu/drm/i915/selftests/i915_selftest.c|  4 +-
 .../gpu/drm/i915/selftests/igt_flush_test.c   |  2 +-
 .../gpu/drm/i915/selftests/igt_live_test.c|  4 +-
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  | 31 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  6 +-
 drivers/gpu/drm/i915/selftests/mock_uncore.c  |  2 +-
 75 files changed, 259 insertions(+), 258 deletions(-)

-- 
2.33.1

[Intel-gfx] [PATCH 1/2] drm/i915: Store backpointer to GT in uncore

[Andi Shyti]

From: Michał Winiarski 

We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon.  Let's store a backpointer for now.

Signed-off-by: Michał Winiarski 
Signed-off-by: Matt Roper 
Reviewed-by: Andi Shyti 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_driver.c   | 2 +-
 drivers/gpu/drm/i915/intel_uncore.c  | 9 +
 drivers/gpu/drm/i915/intel_uncore.h  | 3 ++-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 +--
 drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index a1327dad4..26e90e55d8ca9 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -316,7 +316,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
intel_step_init(dev_priv);
 
intel_uncore_mmio_debug_init_early(&dev_priv->mmio_debug);
-   intel_uncore_init_early(&dev_priv->uncore, dev_priv);
+   intel_uncore_init_early(&dev_priv->uncore, &dev_priv->gt);
 
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index abdac78d39766..fc25ebf1a593e 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2061,12 +2061,13 @@ void intel_uncore_cleanup_mmio(struct intel_uncore 
*uncore)
 }
 
 void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915)
+struct intel_gt *gt)
 {
spin_lock_init(&uncore->lock);
-   uncore->i915 = i915;
-   uncore->rpm = &i915->runtime_pm;
-   uncore->debug = &i915->mmio_debug;
+   uncore->i915 = gt->i915;
+   uncore->gt = gt;
+   uncore->rpm = >->i915->runtime_pm;
+   uncore->debug = >->i915->mmio_debug;
 }
 
 static void uncore_raw_init(struct intel_uncore *uncore)
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index d1d17b04e29fc..210fe2a716129 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -129,6 +129,7 @@ struct intel_uncore {
void __iomem *regs;
 
struct drm_i915_private *i915;
+   struct intel_gt *gt;
struct intel_runtime_pm *rpm;
 
spinlock_t lock; /** lock is also taken in irq contexts. */
@@ -217,7 +218,7 @@ u32 intel_uncore_read_with_mcr_steering(struct intel_uncore 
*uncore,
 void
 intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug);
 void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915);
+struct intel_gt *gt);
 int intel_uncore_setup_mmio(struct intel_uncore *uncore);
 int intel_uncore_init_mmio(struct intel_uncore *uncore);
 void intel_uncore_prune_engine_fw_domains(struct intel_uncore *uncore,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d0e2e61de8d41..cdbeac375240c 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -175,12 +175,11 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->memory_regions = REGION_SMEM;
intel_memory_regions_hw_probe(i915);
 
-   mock_uncore_init(&i915->uncore, i915);
-
spin_lock_init(&i915->gpu_error.lock);
 
i915_gem_init__mm(i915);
intel_gt_init_early(&i915->gt, i915);
+   mock_uncore_init(&i915->uncore, i915);
atomic_inc(&i915->gt.wakeref.count); /* disable; no hw support */
i915->gt.awake = -ENODEV;
 
diff --git a/drivers/gpu/drm/i915/selftests/mock_uncore.c 
b/drivers/gpu/drm/i915/selftests/mock_uncore.c
index ca57e4008701d..b3790ef137e41 100644
--- a/drivers/gpu/drm/i915/selftests/mock_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/mock_uncore.c
@@ -42,7 +42,7 @@ __nop_read(64)
 void mock_uncore_init(struct intel_uncore *uncore,
  struct drm_i915_private *i915)
 {
-   intel_uncore_init_early(uncore, i915);
+   intel_uncore_init_early(uncore, &i915->gt);
 
ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
-- 
2.33.1

[Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0

[Andi Shyti]

In preparation to the upcoming multitile commits, embed the gt
id in the GT 0 in the drm_i915_private structure.

Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Lucas De Marchi 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
---
 .../gpu/drm/i915/display/intel_atomic_plane.c |  4 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 18 +++---
 drivers/gpu/drm/i915/display/intel_dpt.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  2 +-
 .../drm/i915/display/skl_universal_plane.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 22 
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_throttle.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 12 ++--
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  2 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  4 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
 .../drm/i915/gem/selftests/i915_gem_context.c | 10 ++--
 .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c| 20 +++
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |  2 +-
 drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++--
 drivers/gpu/drm/i915/gt/selftest_context.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c  |  4 +-
 .../drm/i915/gt/selftest_engine_heartbeat.c   |  4 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  |  6 +-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c  |  8 +--
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  2 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c   |  2 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  2 +-
 .../drm/i915/gt/selftest_ring_submission.c|  4 +-
 drivers/gpu/drm/i915/gt/selftest_slpc.c   |  6 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  6 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  2 +-
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c |  2 +-
 .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   |  2 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 38 ++---
 drivers/gpu/drm/i915/i915_debugfs_params.c|  4 +-
 drivers/gpu/drm/i915/i915_driver.c| 30 +-
 drivers/gpu/drm/i915/i915_drv.h   |  4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 16 +++---
 drivers/gpu/drm/i915/i915_getparam.c  | 10 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 +-
 drivers/gpu/drm/i915/i915_irq.c   | 56 +--
 drivers/gpu/drm/i915/i915_perf.c  |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c   | 14 ++---
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/i915_sysfs.c | 22 
 drivers/gpu/drm/i915/intel_gvt.c  |  2 +-
 drivers/gpu/drm/i915/intel_wopcm.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_active.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |  6 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_request.c | 10 ++--
 .../gpu/drm/i915/selftests/i915_selftest.c|  4 +-
 .../gpu/drm/i915/selftests/igt_flush_test.c   |  2 +-
 .../gpu/drm/i915/selftests/igt_live_test.c|  4 +-
 .../drm/i915/selftests/intel_memory_region.c  |  4 +-
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  | 28 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  6 +-
 drivers/gpu/drm/i915/selftests/mock_uncore.c  |  2 +-
 73 files changed, 251 insertions(+), 251 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 089fb4658b216..0bbf8c0c42eac 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
 * maximum clocks following a vblank miss (see do_rps_boost()).
 */
if (!state->rps_interactive) {
-   intel_rps_mark_interactive(&dev_priv->gt.rps, true);
+   intel_rps_mark_interactive(&dev_priv->gt0.rps, true);

[Intel-gfx] [PATCH] drm/i915/dg2: Implement WM0 cursor WA for DG2

[Stanislav Lisovskiy]

Bug in the register unit which results in WM1 register
used when only WM0 is enabled on cursor.
Software workaround is when only WM0 enabled on cursor,
copy contents of CUR_WM_0[30:0] (exclude the enable bit)
into CUR_WM_1[30:0].

HSDES: 14012656716

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 89dc7f69baf3..4bc90196d0fb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5095,6 +5095,18 @@ skl_check_nv12_wm_level(struct skl_wm_level *wm, struct 
skl_wm_level *uv_wm,
}
 }
 
+static bool icl_need_wm1_wa(struct drm_i915_private *dev_priv,
+   enum plane_id plane_id)
+{
+   /*
+* Wa_1408961008:icl, ehl
+* Wa_14012656716:tgl, adl
+* Underruns with WM1+ disabled
+*/
+   return (DISPLAY_VER(dev_priv) == 11) ||
+  (IS_DISPLAY_VER(dev_priv, 12, 13) && (plane_id == PLANE_CURSOR));
+}
+
 static int
 skl_allocate_plane_ddb(struct intel_atomic_state *state,
   struct intel_crtc *crtc)
@@ -5265,11 +5277,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
skl_check_nv12_wm_level(&wm->wm[level], 
&wm->uv_wm[level],
total[plane_id], 
uv_total[plane_id]);
 
-   /*
-* Wa_1408961008:icl, ehl
-* Underruns with WM1+ disabled
-*/
-   if (DISPLAY_VER(dev_priv) == 11 &&
+   if (icl_need_wm1_wa(dev_priv, plane_id) &&
level == 1 && wm->wm[0].enable) {
wm->wm[level].blocks = wm->wm[0].blocks;
wm->wm[level].lines = wm->wm[0].lines;
-- 
2.24.1.485.gad05a3d8e5

Re: [Intel-gfx] [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm

[Christian König]

I've looked a bit more into this and I think we should just follow 
Thomas Zimmermann's idea to make this a separate module.


Otherwise we just have the code around all the time even if it is unused 
and implementing this should be trivial.


See how DRM_GEM_CMA_HELPER or DRM_VRAM_HELPER are done in 
drivers/gpu/drm/Kconfig and then have the desired effect in 
drivers/gpu/drm/Makefile


Should be something like ~15 lines of additional configuration which 
saves a bit of memory on embedded systems which just need a fbdev 
replacement.


Thanks,
Christian.

Am 16.11.21 um 21:18 schrieb Arunpravin:

Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
   will be moved to drm selftest folder

cleanup i915 buddy references in i915 driver module
and replace with drm buddy

v2:
   - include header file in alphabetical order (Thomas)
   - merged changes listed in the body section into a single patch
 to keep the build intact (Christian, Jani)

Signed-off-by: Arunpravin 
---
  drivers/gpu/drm/Makefile  |   2 +-
  drivers/gpu/drm/drm_buddy.c   | 521 ++
  drivers/gpu/drm/drm_drv.c |   3 +
  drivers/gpu/drm/i915/Makefile |   1 -
  drivers/gpu/drm/i915/i915_buddy.c | 466 
  drivers/gpu/drm/i915/i915_buddy.h | 143 -
  drivers/gpu/drm/i915/i915_module.c|   3 -
  drivers/gpu/drm/i915/i915_scatterlist.c   |  11 +-
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c |  33 +-
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |   4 +-
  include/drm/drm_buddy.h   | 153 +
  11 files changed, 702 insertions(+), 638 deletions(-)
  create mode 100644 drivers/gpu/drm/drm_buddy.c
  delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
  delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
  create mode 100644 include/drm/drm_buddy.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..dc61e91a3154 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_aperture.o drm_auth.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
-   drm_managed.o drm_vblank_work.o
+   drm_managed.o drm_vblank_work.o drm_buddy.o
  
  drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \

drm_legacy_misc.o drm_lock.o drm_memory.o 
drm_scatter.o \
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..39eb1d224bec
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,521 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+static struct kmem_cache *slab_blocks;
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy_mm *mm,
+  struct drm_buddy_block *parent,
+  unsigned int order,
+  u64 offset)
+{
+   struct drm_buddy_block *block;
+
+   BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+   block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
+   if (!block)
+   return NULL;
+
+   block->header = offset;
+   block->header |= order;
+   block->parent = parent;
+
+   BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
+   return block;
+}
+
+static void drm_block_free(struct drm_buddy_mm *mm,
+  struct drm_buddy_block *block)
+{
+   kmem_cache_free(slab_blocks, block);
+}
+
+static void mark_allocated(struct drm_buddy_block *block)
+{
+   block->header &= ~DRM_BUDDY_HEADER_STATE;
+   block->header |= DRM_BUDDY_ALLOCATED;
+
+   list_del(&block->link);
+}
+
+static void mark_free(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *block)
+{
+   block->header &= ~DRM_BUDDY_HEADER_STATE;
+   block->header |= DRM_BUDDY_FREE;
+
+   list_add(&block->link,
+&mm->free_list[drm_buddy_block_order(block)]);
+}
+
+static void mark_split(struct drm_buddy_block *block)
+{
+   block->header &= ~DRM_BUDDY_HEADER_STATE;
+   block->header |= DRM_BUDDY_SPLIT;
+
+   list_del(&block->link);
+}
+
+/**
+ * drm_buddy_init - init memory manager
+ *
+ * @mm: DRM buddy manager to initialize
+ 

[Intel-gfx] [PATCH v2 1/6] drm/i915: move the pre_pin earlier

[Matthew Auld]

In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart the do_pin at this point.

If this is the kernel_context, or some other early in-kernel context
where we have yet to setup the default_state, then we always inhibit the
context restore, and instead rely on the delayed active_release to set
the CONTEXT_VALID_BIT for us(if we even care), which should indicate
that we have context switched away, and that our newly saved context
state should now be valid. However, since we currently grab the active
reference before the potential ww dance, we can end up setting the
CONTEXT_VALID_BIT much too early, if we need to backoff, and then upon
re-trying the do_pin, we could potentially cause the hardware to
incorrectly load some garbage context state when later context switching
to that context, but at the very least this will trigger the
GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance
stuff prior to arming the active reference.

For normal user contexts this shouldn't be a concern, since we should
already have the default_state ready when initialising the lrc state,
and so there should be no concern with active_release somehow
prematurely setting the CONTEXT_VALID_BIT.

v2(Thomas):
  - Also re-order the union unwind

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5634d14052bc..4c296de1d67d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
if (err)
return err;
 
-   err = i915_active_acquire(&ce->active);
+   err = ce->ops->pre_pin(ce, ww, &vaddr);
if (err)
goto err_ctx_unpin;
 
-   err = ce->ops->pre_pin(ce, ww, &vaddr);
+   err = i915_active_acquire(&ce->active);
if (err)
-   goto err_release;
+   goto err_post_unpin;
 
err = mutex_lock_interruptible(&ce->pin_mutex);
if (err)
-   goto err_post_unpin;
+   goto err_release;
 
intel_engine_pm_might_get(ce->engine);
 
@@ -273,11 +273,11 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
 
 err_unlock:
mutex_unlock(&ce->pin_mutex);
+err_release:
+   i915_active_release(&ce->active);
 err_post_unpin:
if (!handoff)
ce->ops->post_unpin(ce);
-err_release:
-   i915_active_release(&ce->active);
 err_ctx_unpin:
intel_context_post_unpin(ce);
 
-- 
2.31.1

[Intel-gfx] [PATCH v2 2/6] drm/i915: Create a dummy object for gen6 ppgtt

[Matthew Auld]

From: Maarten Lankhorst 

We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created. It just has to look real enough.

Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.

v2:
  - Drop IS_SHRINKABLE and shorten overly long line
v3:
  - Checkpatch fix for alignment

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  44 ---
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 123 +++
 drivers/gpu/drm/i915/gt/gen6_ppgtt.h |   1 -
 drivers/gpu/drm/i915/i915_drv.h  |   4 +
 4 files changed, 100 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index a57a6b7013c2..c5150a1ee3d2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -145,24 +145,10 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_internal_ops = {
.put_pages = i915_gem_object_put_pages_internal,
 };
 
-/**
- * i915_gem_object_create_internal: create an object with volatile pages
- * @i915: the i915 device
- * @size: the size in bytes of backing storage to allocate for the object
- *
- * Creates a new object that wraps some internal memory for private use.
- * This object is not backed by swappable storage, and as such its contents
- * are volatile and only valid whilst pinned. If the object is reaped by the
- * shrinker, its pages and data will be discarded. Equally, it is not a full
- * GEM object and so not valid for access from userspace. This makes it useful
- * for hardware interfaces like ringbuffers (which are pinned from the time
- * the request is written to the time the hardware stops accessing it), but
- * not for contexts (which need to be preserved when not active for later
- * reuse). Note that it is not cleared upon allocation.
- */
 struct drm_i915_gem_object *
-i915_gem_object_create_internal(struct drm_i915_private *i915,
-   phys_addr_t size)
+__i915_gem_object_create_internal(struct drm_i915_private *i915,
+ const struct drm_i915_gem_object_ops *ops,
+ phys_addr_t size)
 {
static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
@@ -179,7 +165,7 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
return ERR_PTR(-ENOMEM);
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
-   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class, 
0);
+   i915_gem_object_init(obj, ops, &lock_class, 0);
obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
 
/*
@@ -199,3 +185,25 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
 
return obj;
 }
+
+/**
+ * i915_gem_object_create_internal: create an object with volatile pages
+ * @i915: the i915 device
+ * @size: the size in bytes of backing storage to allocate for the object
+ *
+ * Creates a new object that wraps some internal memory for private use.
+ * This object is not backed by swappable storage, and as such its contents
+ * are volatile and only valid whilst pinned. If the object is reaped by the
+ * shrinker, its pages and data will be discarded. Equally, it is not a full
+ * GEM object and so not valid for access from userspace. This makes it useful
+ * for hardware interfaces like ringbuffers (which are pinned from the time
+ * the request is written to the time the hardware stops accessing it), but
+ * not for contexts (which need to be preserved when not active for later
+ * reuse). Note that it is not cleared upon allocation.
+ */
+struct drm_i915_gem_object *
+i915_gem_object_create_internal(struct drm_i915_private *i915,
+   phys_addr_t size)
+{
+   return __i915_gem_object_create_internal(i915, 
&i915_gem_object_internal_ops, size);
+}
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index ae693bf88ef0..4a166d25fe60 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -261,13 +261,10 @@ static void gen6_ppgtt_cleanup(struct i915_address_space 
*vm)
 {
struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
 
-   __i915_vma_put(ppgtt->vma);
-
gen6_ppgtt_free_pd(ppgtt);
free_scratch(vm);
 
mutex_destroy(&ppgtt->flush);
-   mutex_destroy(&ppgtt->pin_mutex);
 
free_pd(&ppgtt->base.vm, ppgtt->base.pd);
 }
@@ -330,37 +327,6 @@ static const struct i915_vma_ops pd_vma_ops = {
.unbind_vma = pd_vma_unbind,
 };
 
-static struct i915_vma *pd_vma_create

[Intel-gfx] [PATCH v2 4/6] drm/i915: vma is always backed by an object.

[Matthew Auld]

From: Maarten Lankhorst 

vma->obj and vma->resv are now never NULL, and some checks can be removed.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_context.c   |  2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  2 +-
 drivers/gpu/drm/i915/i915_vma.c   | 48 ---
 drivers/gpu/drm/i915/i915_vma.h   |  3 --
 4 files changed, 22 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 4c296de1d67d..268c51f886b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -219,7 +219,7 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
 */
 
err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj, ww);
-   if (!err && ce->ring->vma->obj)
+   if (!err)
err = i915_gem_object_lock(ce->ring->vma->obj, ww);
if (!err && ce->state)
err = i915_gem_object_lock(ce->state->obj, ww);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 586dca1731ce..3e6fac0340ef 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1357,7 +1357,7 @@ int intel_ring_submission_setup(struct intel_engine_cs 
*engine)
err = i915_gem_object_lock(timeline->hwsp_ggtt->obj, &ww);
if (!err && gen7_wa_vma)
err = i915_gem_object_lock(gen7_wa_vma->obj, &ww);
-   if (!err && engine->legacy.ring->vma->obj)
+   if (!err)
err = i915_gem_object_lock(engine->legacy.ring->vma->obj, &ww);
if (!err)
err = intel_timeline_pin(timeline, &ww);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0896656896d0..502ae9c73b09 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -40,12 +40,12 @@
 
 static struct kmem_cache *slab_vmas;
 
-struct i915_vma *i915_vma_alloc(void)
+static struct i915_vma *i915_vma_alloc(void)
 {
return kmem_cache_zalloc(slab_vmas, GFP_KERNEL);
 }
 
-void i915_vma_free(struct i915_vma *vma)
+static void i915_vma_free(struct i915_vma *vma)
 {
return kmem_cache_free(slab_vmas, vma);
 }
@@ -423,10 +423,8 @@ int i915_vma_bind(struct i915_vma *vma,
 
work->base.dma.error = 0; /* enable the queue_work() */
 
-   if (vma->obj) {
-   __i915_gem_object_pin_pages(vma->obj);
-   work->pinned = i915_gem_object_get(vma->obj);
-   }
+   __i915_gem_object_pin_pages(vma->obj);
+   work->pinned = i915_gem_object_get(vma->obj);
} else {
vma->ops->bind_vma(vma->vm, NULL, vma, cache_level, bind_flags);
}
@@ -667,7 +665,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
}
 
color = 0;
-   if (vma->obj && i915_vm_has_cache_coloring(vma->vm))
+   if (i915_vm_has_cache_coloring(vma->vm))
color = vma->obj->cache_level;
 
if (flags & PIN_OFFSET_FIXED) {
@@ -792,17 +790,14 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned 
int flags)
 static int vma_get_pages(struct i915_vma *vma)
 {
int err = 0;
-   bool pinned_pages = false;
+   bool pinned_pages = true;
 
if (atomic_add_unless(&vma->pages_count, 1, 0))
return 0;
 
-   if (vma->obj) {
-   err = i915_gem_object_pin_pages(vma->obj);
-   if (err)
-   return err;
-   pinned_pages = true;
-   }
+   err = i915_gem_object_pin_pages(vma->obj);
+   if (err)
+   return err;
 
/* Allocations ahoy! */
if (mutex_lock_interruptible(&vma->pages_mutex)) {
@@ -835,8 +830,8 @@ static void __vma_put_pages(struct i915_vma *vma, unsigned 
int count)
if (atomic_sub_return(count, &vma->pages_count) == 0) {
vma->ops->clear_pages(vma);
GEM_BUG_ON(vma->pages);
-   if (vma->obj)
-   i915_gem_object_unpin_pages(vma->obj);
+
+   i915_gem_object_unpin_pages(vma->obj);
}
mutex_unlock(&vma->pages_mutex);
 }
@@ -872,7 +867,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
int err;
 
 #ifdef CONFIG_PROVE_LOCKING
-   if (debug_locks && !WARN_ON(!ww) && vma->resv)
+   if (debug_locks && !WARN_ON(!ww))
assert_vma_held(vma);
 #endif
 
@@ -980,7 +975,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
 
GEM_BUG_ON(!vma->pages);
err = i915_vma_bind(vma,
-   vma->obj ? vma->obj->cache_level : 0,
+   vma->obj->cache_level,
flags, work);
   

[Intel-gfx] [PATCH v2 3/6] drm/i915: Create a full object for mock_ring, v2.

[Matthew Auld]

From: Maarten Lankhorst 

This allows us to finally get rid of all the assumptions that vma->obj
is NULL.

Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/mock_engine.c | 38 ---
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c 
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 8b89215afe46..bb99fc03f503 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -35,9 +35,31 @@ static void mock_timeline_unpin(struct intel_timeline *tl)
atomic_dec(&tl->pin_count);
 }
 
+static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
+{
+   struct i915_address_space *vm = &ggtt->vm;
+   struct drm_i915_private *i915 = vm->i915;
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+
+   obj = i915_gem_object_create_internal(i915, size);
+   if (IS_ERR(obj))
+   return ERR_CAST(obj);
+
+   vma = i915_vma_instance(obj, vm, NULL);
+   if (IS_ERR(vma))
+   goto err;
+
+   return vma;
+
+err:
+   i915_gem_object_put(obj);
+   return vma;
+}
+
 static struct intel_ring *mock_ring(struct intel_engine_cs *engine)
 {
-   const unsigned long sz = PAGE_SIZE / 2;
+   const unsigned long sz = PAGE_SIZE;
struct intel_ring *ring;
 
ring = kzalloc(sizeof(*ring) + sz, GFP_KERNEL);
@@ -50,15 +72,11 @@ static struct intel_ring *mock_ring(struct intel_engine_cs 
*engine)
ring->vaddr = (void *)(ring + 1);
atomic_set(&ring->pin_count, 1);
 
-   ring->vma = i915_vma_alloc();
-   if (!ring->vma) {
+   ring->vma = create_ring_vma(engine->gt->ggtt, PAGE_SIZE);
+   if (IS_ERR(ring->vma)) {
kfree(ring);
return NULL;
}
-   i915_active_init(&ring->vma->active, NULL, NULL, 0);
-   __set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(ring->vma));
-   __set_bit(DRM_MM_NODE_ALLOCATED_BIT, &ring->vma->node.flags);
-   ring->vma->node.size = sz;
 
intel_ring_update_space(ring);
 
@@ -67,8 +85,7 @@ static struct intel_ring *mock_ring(struct intel_engine_cs 
*engine)
 
 static void mock_ring_free(struct intel_ring *ring)
 {
-   i915_active_fini(&ring->vma->active);
-   i915_vma_free(ring->vma);
+   i915_vma_put(ring->vma);
 
kfree(ring);
 }
@@ -125,6 +142,7 @@ static void mock_context_unpin(struct intel_context *ce)
 
 static void mock_context_post_unpin(struct intel_context *ce)
 {
+   i915_vma_unpin(ce->ring->vma);
 }
 
 static void mock_context_destroy(struct kref *ref)
@@ -169,7 +187,7 @@ static int mock_context_alloc(struct intel_context *ce)
 static int mock_context_pre_pin(struct intel_context *ce,
struct i915_gem_ww_ctx *ww, void **unused)
 {
-   return 0;
+   return i915_vma_pin_ww(ce->ring->vma, ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
 }
 
 static int mock_context_pin(struct intel_context *ce, void *unused)
-- 
2.31.1

[Intel-gfx] [PATCH v2 5/6] drm/i915: Remove resv from i915_vma

[Matthew Auld]

From: Maarten Lankhorst 

It's just an alias to vma->obj->base.resv, no need to duplicate it.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Niranjana Vishwanathapura 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
 drivers/gpu/drm/i915/i915_vma.c| 9 -
 drivers/gpu/drm/i915/i915_vma.h| 6 +++---
 drivers/gpu/drm/i915/i915_vma_types.h  | 1 -
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index ea5b7b2a4d70..9f7c6ecadb90 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1001,7 +1001,7 @@ static int eb_validate_vmas(struct i915_execbuffer *eb)
}
 
if (!(ev->flags & EXEC_OBJECT_WRITE)) {
-   err = dma_resv_reserve_shared(vma->resv, 1);
+   err = dma_resv_reserve_shared(vma->obj->base.resv, 1);
if (err)
return err;
}
@@ -2175,7 +2175,7 @@ static int eb_parse(struct i915_execbuffer *eb)
goto err_trampoline;
}
 
-   err = dma_resv_reserve_shared(shadow->resv, 1);
+   err = dma_resv_reserve_shared(shadow->obj->base.resv, 1);
if (err)
goto err_trampoline;
 
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 502ae9c73b09..e2f2c4c52009 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -113,7 +113,6 @@ vma_create(struct drm_i915_gem_object *obj,
vma->vm = i915_vm_get(vm);
vma->ops = &vm->vma_ops;
vma->obj = obj;
-   vma->resv = obj->base.resv;
vma->size = obj->base.size;
vma->display_alignment = I915_GTT_MIN_ALIGNMENT;
 
@@ -1029,7 +1028,7 @@ int i915_ggtt_pin(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
 
 #ifdef CONFIG_LOCKDEP
-   WARN_ON(!ww && dma_resv_held(vma->resv));
+   WARN_ON(!ww && dma_resv_held(vma->obj->base.resv));
 #endif
 
do {
@@ -1248,19 +1247,19 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
}
 
if (fence) {
-   dma_resv_add_excl_fence(vma->resv, fence);
+   dma_resv_add_excl_fence(vma->obj->base.resv, fence);
obj->write_domain = I915_GEM_DOMAIN_RENDER;
obj->read_domains = 0;
}
} else {
if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
-   err = dma_resv_reserve_shared(vma->resv, 1);
+   err = dma_resv_reserve_shared(vma->obj->base.resv, 1);
if (unlikely(err))
return err;
}
 
if (fence) {
-   dma_resv_add_shared_fence(vma->resv, fence);
+   dma_resv_add_shared_fence(vma->obj->base.resv, fence);
obj->write_domain = 0;
}
}
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 312933c06017..4033aa08d5e4 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -234,16 +234,16 @@ static inline void __i915_vma_put(struct i915_vma *vma)
kref_put(&vma->ref, i915_vma_release);
 }
 
-#define assert_vma_held(vma) dma_resv_assert_held((vma)->resv)
+#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
 
 static inline void i915_vma_lock(struct i915_vma *vma)
 {
-   dma_resv_lock(vma->resv, NULL);
+   dma_resv_lock(vma->obj->base.resv, NULL);
 }
 
 static inline void i915_vma_unlock(struct i915_vma *vma)
 {
-   dma_resv_unlock(vma->resv);
+   dma_resv_unlock(vma->obj->base.resv);
 }
 
 int __must_check
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h 
b/drivers/gpu/drm/i915/i915_vma_types.h
index 4ee6e54799f4..f03fa96a1701 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -187,7 +187,6 @@ struct i915_vma {
const struct i915_vma_ops *ops;
 
struct drm_i915_gem_object *obj;
-   struct dma_resv *resv; /** Alias of obj->resv */
 
struct sg_table *pages;
void __iomem *iomap;
-- 
2.31.1

[Intel-gfx] [PATCH v2 6/6] drm/i915: Drain the ttm delayed workqueue too

[Matthew Auld]

From: Maarten Lankhorst 

Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8eb6de5cae9..b02694ee6546 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1809,6 +1809,7 @@ static inline void i915_gem_drain_freed_objects(struct 
drm_i915_private *i915)
 */
while (atomic_read(&i915->mm.free_count)) {
flush_work(&i915->mm.free_work);
+   flush_delayed_work(&i915->bdev.wq);
rcu_barrier();
}
 }
-- 
2.31.1

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0

[Chris Wilson]

Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>  * maximum clocks following a vblank miss (see do_rps_boost()).
>  */
> if (!state->rps_interactive) {
> -   intel_rps_mark_interactive(&dev_priv->gt.rps, true);
> +   intel_rps_mark_interactive(&dev_priv->gt0.rps, true);

This should be across all gt, so probably wants a fresh interface that
takes i915 and does for_each_gt in a later patch. (Since we could be
rendering on a remote tile to present on a display.)

> state->rps_interactive = true;
> }
>  
> @@ -851,7 +851,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> return;
>  
> if (state->rps_interactive) {
> -   intel_rps_mark_interactive(&dev_priv->gt.rps, false);
> +   intel_rps_mark_interactive(&dev_priv->gt0.rps, false);
> state->rps_interactive = false;
> }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac66717..d4fcd8f236476 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -838,7 +838,7 @@ __intel_display_resume(struct drm_device *dev,
>  static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
>  {
> return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> -   intel_has_gpu_reset(&dev_priv->gt));
> +   intel_has_gpu_reset(&dev_priv->gt0));

All these display consumers probably want to use
dev_priv->ggtt->vm.gt, since the scanout capable GGTT would seem to be
the defining feature.

to_scanout_gt(i915) ?

>  static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ebd775cb1661c..c62253d0af044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct 
> drm_i915_private *i915,
>  * colateral damage, and we should not pretend we can by
>  * exposing the interface.
>  */
> -   if (!intel_has_reset_engine(&i915->gt))
> +   if (!intel_has_reset_engine(&i915->gt0))
> return -ENODEV;

Prep for all gt. A lot of these need an all-gt interface so we don't
have for_each_gt spread all other the place.

> 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 ef22d4ed66ad6..69ad407eb15f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -166,7 +166,7 @@ static struct dma_fence *i915_ttm_accel_move(struct 
> ttm_buffer_object *bo,
> enum i915_cache_level src_level, dst_level;
> int ret;
>  
> -   if (!i915->gt.migrate.context || intel_gt_is_wedged(&i915->gt))
> +   if (!i915->gt0.migrate.context || intel_gt_is_wedged(&i915->gt0))

This should already be looking at lmem->gt

> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 8f8bea08e734d..176ea5c7d422f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private 
> *i915)
> disabled |= (I915_SCHEDULER_CAP_ENABLED |
>  I915_SCHEDULER_CAP_PRIORITY);
>  
> -   if (intel_uc_uses_guc_submission(&i915->gt.uc))
> +   if (intel_uc_uses_guc_submission(&i915->gt0.uc))

This shouldn't be looking at gt at all, but if it must, that information
must be coming via engine->gt. Kind of renders the mapping moot
currently.
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 07ff7ba7b2b71..63089e671a242 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
> return 0;
>  
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> -   struct intel_ips *ips = &i915->gt.rps.ips;
> +   struct intel_ips *ips = &i915->gt0.rps.ips;

Make mchdev_get() return the gt or rps, at the slight cost of making the
drm_dev_put() more complicated (but can be pushed into a mchdev_put for
symmetry).

> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gp

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support

[Imre Deak]

On Wed, Nov 17, 2021 at 01:01:00PM +0200, Stanislav Lisovskiy wrote:
> TileF(Tile4 in bspec) format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
> 
> v2: - Fixed wrong case condition(Jani Nikula)
> - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)
> 
> v3: - s/I915_TILING_F/TILING_4/g
> - s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
> - Removed unneeded fencing code
> 
> v4: - Rebased, fixed merge conflict with new table-oriented
>   format modifier checking(Stan)
> - Replaced the rest of "Tile F" mentions to "Tile 4"(Stan)
> 
> v5: - Still had to remove some Tile F mentionings
> - Moved has_4tile from adlp to DG2(Ramalingam)
> - Check specifically for DG2, but not the Display13(Imre)
> 
> Cc: Imre Deak 
> Cc: Matt Roper 
> Cc: Maarten Lankhorst 
> Signed-off-by: Stanislav Lisovskiy 
> Signed-off-by: Matt Roper 
> Signed-off-by: Juha-Pekka Heikkilä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_fb.c   | 10 ++
>  drivers/gpu/drm/i915/display/intel_fbc.c  |  2 ++
>  .../drm/i915/display/intel_plane_initial.c|  1 +
>  .../drm/i915/display/skl_universal_plane.c| 20 +++
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/i915_pci.c   |  1 +
>  drivers/gpu/drm/i915/i915_reg.h   |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h  |  1 +
>  drivers/gpu/drm/i915/intel_pm.c   |  1 +
>  include/uapi/drm/drm_fourcc.h |  8 
>  11 files changed, 39 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac6671..eaea986dff99 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7743,6 +7743,7 @@ static int intel_atomic_check_async(struct 
> intel_atomic_state *state, struct int
>   case I915_FORMAT_MOD_X_TILED:
>   case I915_FORMAT_MOD_Y_TILED:
>   case I915_FORMAT_MOD_Yf_TILED:
> + case I915_FORMAT_MOD_4_TILED:
>   break;
>   default:
>   drm_dbg_kms(&i915->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index c4a743d0913f..a3d465e111d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -184,6 +184,9 @@ static const struct intel_modifier_desc intel_modifiers[] 
> = {
>   .modifier = I915_FORMAT_MOD_Yf_TILED,
>   .display_ver = { 9, 11 },
>   .plane_caps = INTEL_PLANE_CAP_TILING_Yf,
> + }, {
> + .modifier = I915_FORMAT_MOD_4_TILED,
> + .display_ver = { 12, 13 },

Starting from display version 13. The list is priority ordered so this
needs to be the first item.

>   }, {
>   .modifier = I915_FORMAT_MOD_Y_TILED,
>   .display_ver = { 9, 13 },
> @@ -544,6 +547,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
> int color_plane)
>   return 128;
>   else
>   return 512;
> + case I915_FORMAT_MOD_4_TILED:
> + /*
> +  * Each 4K tile consists of 64B(8*8) subtiles, with
> +  * same shape as Y Tile(i.e 4*16B OWords)
> +  */
> + return 128;
>   case I915_FORMAT_MOD_Y_TILED_CCS:
>   if (intel_fb_is_ccs_aux_plane(fb, color_plane))
>   return 128;
> @@ -726,6 +735,7 @@ unsigned int intel_surf_alignment(const struct 
> drm_framebuffer *fb,
>   case I915_FORMAT_MOD_Y_TILED_CCS:
>   case I915_FORMAT_MOD_Yf_TILED_CCS:
>   case I915_FORMAT_MOD_Y_TILED:
> + case I915_FORMAT_MOD_4_TILED:

The 4-tiled formats need to be mapped via DPT on all platforms, which is
handled earlier in the func, so handling it here shouldn't be needed.

>   case I915_FORMAT_MOD_Yf_TILED:
>   return 1 * 1024 * 1024;
>   default:
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index d0c34bc3af6c..5f2ad0f4bd81 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -898,6 +898,8 @@ static bool tiling_is_valid(struct drm_i915_private *i915,
>   case I915_FORMAT_MOD_Y_TILED:
>   case I915_FORMAT_MOD_Yf_TILED:
>   return DISPLAY_VER(i915) >= 9;
> + case I915_FORMAT_MOD_4_TILED:
> + return HAS_4TILE(i915);

Could return true always, since only HAS_4TILE() platforms will use/pass
to this func the modifier.

>   case I915_FORMAT_MOD_X_TILED:
>   return true;
>   default:
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
> b/drivers/gp

[Intel-gfx] [PATCH] drm/i915/display/dg2: Introduce CD clock squashing table

[Mika Kahola]

For CD clock squashing method, we need to define corresponding CD clock table 
for
reference clocks, dividers and ratios for all CD clock options.

BSpec: 54034

v2: Add CD squashing waveforms as part of CD clock table (Ville)
v3: Waveform is 16 bits wide (Ville)
[v4: vsyrjala: Nuke the non-squasher based table,
   Set .divider=2 for consistency,
   Pack intel_cdclk_vals a bit nicer]
v5: Fix error in waveform value (Swati)
v6 (Lucas): Rebase on upstream
v7 (MattR): Drop 40.8, 81.6, and 122.4 MHz frequencies to reflect new
bspec update.

Signed-off-by: Mika Kahola 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 19 +--
 drivers/gpu/drm/i915/display/intel_cdclk.h |  1 +
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 91c19e0a98d7..7af4cb965060 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1313,12 +1313,19 @@ static const struct intel_cdclk_vals adlp_cdclk_table[] 
= {
 };
 
 static const struct intel_cdclk_vals dg2_cdclk_table[] = {
-   { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio =  9 },
-   { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
-   { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
-   { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
-   { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
-   { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
+   { .refclk = 38400, .cdclk = 163200, .divider = 2, .ratio = 34, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 204000, .divider = 2, .ratio = 34, 
.waveform = 0x9248 },
+   { .refclk = 38400, .cdclk = 244800, .divider = 2, .ratio = 34, 
.waveform = 0xa4a4 },
+   { .refclk = 38400, .cdclk = 285600, .divider = 2, .ratio = 34, 
.waveform = 0xa54a },
+   { .refclk = 38400, .cdclk = 326400, .divider = 2, .ratio = 34, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 367200, .divider = 2, .ratio = 34, 
.waveform = 0xad5a },
+   { .refclk = 38400, .cdclk = 408000, .divider = 2, .ratio = 34, 
.waveform = 0xb6b6 },
+   { .refclk = 38400, .cdclk = 448800, .divider = 2, .ratio = 34, 
.waveform = 0xdbb6 },
+   { .refclk = 38400, .cdclk = 489600, .divider = 2, .ratio = 34, 
.waveform = 0x },
+   { .refclk = 38400, .cdclk = 530400, .divider = 2, .ratio = 34, 
.waveform = 0xf7de },
+   { .refclk = 38400, .cdclk = 571200, .divider = 2, .ratio = 34, 
.waveform = 0xfefe },
+   { .refclk = 38400, .cdclk = 612000, .divider = 2, .ratio = 34, 
.waveform = 0xfffe },
+   { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34, 
.waveform = 0x },
{}
 };
 
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h 
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index 309b3f394e24..89ca59c46102 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -19,6 +19,7 @@ struct intel_crtc_state;
 struct intel_cdclk_vals {
u32 cdclk;
u16 refclk;
+   u16 waveform;
u8 divider; /* CD2X divider * 2 */
u8 ratio;
 };
-- 
2.27.0

[Intel-gfx] [PATCH] drm/i915/display/dg2: Read CD clock from squasher table

[Mika Kahola]

To calculate CD clock with squasher unit, we set CD clock ratio to fixed value 
of 34.
The CD clock value is read from CD clock squasher table.

BSpec: 54034

v2: Read ratio from register (Ville)
Drop unnecessary local variable (Ville)
Get CD clock from the given table
v3: Calculate CD clock frequency based on waveform bit pattern (Ville)
[v4: vsyrjala: Actually do a proper blind readout from the hardware]
[v5: vsyrjala: Use has_cdclk_squasher()]

Signed-off-by: Mika Kahola 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 91c19e0a98d7..ee48a6b87184 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1454,6 +1454,7 @@ static void bxt_de_pll_readout(struct drm_i915_private 
*dev_priv,
 static void bxt_get_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_config *cdclk_config)
 {
+   u32 squash_ctl = 0;
u32 divider;
int div;
 
@@ -1491,7 +1492,21 @@ static void bxt_get_cdclk(struct drm_i915_private 
*dev_priv,
return;
}
 
-   cdclk_config->cdclk = DIV_ROUND_CLOSEST(cdclk_config->vco, div);
+   if (has_cdclk_squasher(dev_priv))
+   squash_ctl = intel_de_read(dev_priv, CDCLK_SQUASH_CTL);
+
+   if (squash_ctl & CDCLK_SQUASH_ENABLE) {
+   u16 waveform;
+   int size;
+
+   size = REG_FIELD_GET(CDCLK_SQUASH_WINDOW_SIZE_MASK, squash_ctl) 
+ 1;
+   waveform = REG_FIELD_GET(CDCLK_SQUASH_WAVEFORM_MASK, 
squash_ctl) >> (16 - size);
+
+   cdclk_config->cdclk = DIV_ROUND_CLOSEST(hweight16(waveform) *
+   cdclk_config->vco, size 
* div);
+   } else {
+   cdclk_config->cdclk = DIV_ROUND_CLOSEST(cdclk_config->vco, div);
+   }
 
  out:
/*
-- 
2.27.0

[Intel-gfx] [PATCH] drm/i915/display/dg2: Sanitize CD clock

[Mika Kahola]

In case of CD clock squashing the divider is always 1. We don't
need to calculate the divider in use so let's skip that for DG2.

v2: Drop unnecessary local variable (Ville)
v3: Avoid if-else structure (Ville)
[v4: vsyrjala: Fix cd2x divider calculation (Uma),
   Introduce has_cdclk_squasher()]

Signed-off-by: Mika Kahola 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 91c19e0a98d7..296dd1fc4289 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1212,6 +1212,11 @@ static void skl_cdclk_uninit_hw(struct drm_i915_private 
*dev_priv)
skl_set_cdclk(dev_priv, &cdclk_config, INVALID_PIPE);
 }
 
+static bool has_cdclk_squasher(struct drm_i915_private *i915)
+{
+   return IS_DG2(i915);
+}
+
 static const struct intel_cdclk_vals bxt_cdclk_table[] = {
{ .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
{ .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
@@ -1728,7 +1733,7 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
 static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
 {
u32 cdctl, expected;
-   int cdclk, vco;
+   int cdclk, clock, vco;
 
intel_update_cdclk(dev_priv);
intel_dump_cdclk_config(&dev_priv->cdclk.hw, "Current CDCLK");
@@ -1764,8 +1769,12 @@ static void bxt_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
expected = skl_cdclk_decimal(cdclk);
 
/* Figure out what CD2X divider we should be using for this cdclk */
-   expected |= bxt_cdclk_cd2x_div_sel(dev_priv,
-  dev_priv->cdclk.hw.cdclk,
+   if (has_cdclk_squasher(dev_priv))
+   clock = dev_priv->cdclk.hw.vco / 2;
+   else
+   clock = dev_priv->cdclk.hw.cdclk;
+
+   expected |= bxt_cdclk_cd2x_div_sel(dev_priv, clock,
   dev_priv->cdclk.hw.vco);
 
/*
-- 
2.27.0

[Intel-gfx] [PATCH] drm/i915/display/dg2: Set CD clock squashing registers

[Mika Kahola]

Set CD clock squashing registers based on selected CD clock.

v2: use slk_cdclk_decimal() to compute decimal values instead of a
specific table (Ville)
Set waveform based on CD clock table (Ville)
Drop unnecessary local variable (Ville)
v3: Correct function naming (Ville)
Correct if-else structure (Ville)
[v4: vsyrjala: Fix spaces vs. tabs]
[v5: vsyrjala: Fix cd2x divider calculation (Uma),
   Add warn to waveform lookup (Uma),
   Handle bypass freq in waveform lookup,
   Generalize waveform handling in bxt_set_cdclk()]

Signed-off-by: Mika Kahola 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 41 +-
 drivers/gpu/drm/i915/i915_reg.h|  8 +
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 91c19e0a98d7..69bdec6abf1e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1626,6 +1626,26 @@ static u32 bxt_cdclk_cd2x_div_sel(struct 
drm_i915_private *dev_priv,
}
 }
 
+static u32 cdclk_squash_waveform(struct drm_i915_private *dev_priv,
+int cdclk)
+{
+   const struct intel_cdclk_vals *table = dev_priv->cdclk.table;
+   int i;
+
+   if (cdclk == dev_priv->cdclk.hw.bypass)
+   return 0;
+
+   for (i = 0; table[i].refclk; i++)
+   if (table[i].refclk == dev_priv->cdclk.hw.ref &&
+   table[i].cdclk == cdclk)
+   return table[i].waveform;
+
+   drm_WARN(&dev_priv->drm, 1, "cdclk %d not valid for refclk %u\n",
+cdclk, dev_priv->cdclk.hw.ref);
+
+   return 0x;
+}
+
 static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_config *cdclk_config,
  enum pipe pipe)
@@ -1633,6 +1653,8 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
u32 val;
+   u16 waveform;
+   int clock;
int ret;
 
/* Inform power controller of upcoming frequency change. */
@@ -1676,7 +1698,24 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
bxt_de_pll_enable(dev_priv, vco);
}
 
-   val = bxt_cdclk_cd2x_div_sel(dev_priv, cdclk, vco) |
+   waveform = cdclk_squash_waveform(dev_priv, cdclk);
+
+   if (waveform)
+   clock = vco / 2;
+   else
+   clock = cdclk;
+
+   if (has_cdclk_squasher(dev_priv)) {
+   u32 squash_ctl = 0;
+
+   if (waveform)
+   squash_ctl = CDCLK_SQUASH_ENABLE |
+   CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
+
+   intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
+   }
+
+   val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
skl_cdclk_decimal(cdclk);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f15ffc53e858..cfedbca0b5d3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10649,6 +10649,14 @@ enum skl_power_gate {
 #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE(1 << 16)
 #define  CDCLK_FREQ_DECIMAL_MASK   (0x7ff)
 
+/* CDCLK_SQUASH_CTL */
+#define CDCLK_SQUASH_CTL   _MMIO(0x46008)
+#define  CDCLK_SQUASH_ENABLE   REG_BIT(31)
+#define  CDCLK_SQUASH_WINDOW_SIZE_MASK REG_GENMASK(27, 24)
+#define  CDCLK_SQUASH_WINDOW_SIZE(x)   
REG_FIELD_PREP(CDCLK_SQUASH_WINDOW_SIZE_MASK, (x))
+#define  CDCLK_SQUASH_WAVEFORM_MASKREG_GENMASK(15, 0)
+#define  CDCLK_SQUASH_WAVEFORM(x)  
REG_FIELD_PREP(CDCLK_SQUASH_WAVEFORM_MASK, (x))
+
 /* LCPLL_CTL */
 #define LCPLL1_CTL _MMIO(0x46010)
 #define LCPLL2_CTL _MMIO(0x46014)
-- 
2.27.0

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: Tile 4 plane format support (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Tile 4 plane format support (rev3)
URL   : https://patchwork.freedesktop.org/series/95715/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: split out display trace to a separate file

[Ville Syrjälä]

On Tue, Nov 16, 2021 at 05:42:34PM +0200, Jani Nikula wrote:
> Add display/intel_display_trace.[ch] for defining display
> tracepoints. The main goal is to reduce cross-includes between gem and
> display. It would be possible split up tracing even further, but that
> would lead to more boilerplate.
> 
> There should be no changes to tracepoints.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  .../gpu/drm/i915/display/intel_atomic_plane.c |   5 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c |   5 +-
>  .../drm/i915/display/intel_display_trace.c|   9 +
>  .../drm/i915/display/intel_display_trace.h| 588 ++
>  drivers/gpu/drm/i915/display/intel_fbc.c  |   2 +-
>  .../drm/i915/display/intel_fifo_underrun.c|   2 +-
>  .../gpu/drm/i915/display/intel_frontbuffer.c  |   7 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c   |   1 -
>  drivers/gpu/drm/i915/i915_debugfs.c   |   1 -
>  drivers/gpu/drm/i915/i915_drv.c   |   1 -
>  drivers/gpu/drm/i915/i915_irq.c   |   2 +-
>  drivers/gpu/drm/i915/i915_trace.h | 567 -
>  drivers/gpu/drm/i915/intel_pm.c   |   2 +-
>  14 files changed, 610 insertions(+), 583 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_display_trace.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_display_trace.h
> 

> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.c 
> b/drivers/gpu/drm/i915/display/intel_display_trace.c
> new file mode 100644
> index ..737979ada869
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.c
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#ifndef __CHECKER__
> +#define CREATE_TRACE_POINTS
> +#include "intel_display_trace.h"
> +#endif
> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h 
> b/drivers/gpu/drm/i915/display/intel_display_trace.h
> new file mode 100644
> index ..8608f5a6ff32
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
> @@ -0,0 +1,588 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM i915
> +
> +#if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ)
> +#define __INTEL_DISPLAY_TRACE_H__
> +
> +#include 
> +#include 
> +
> +#include "i915_drv.h"
> +#include "intel_crtc.h"
> +#include "intel_display_types.h"
> +
> +/* watermark/fifo updates */

That comment is a bit misplaced. I guess it already was like that in the
old file. Maybe just nuke all these comments? I don't think they really
serve any useful purpose.

Series is
Reviewed-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915/dg2: Implement WM0 cursor WA for DG2

[Ville Syrjälä]

On Wed, Nov 17, 2021 at 03:43:41PM +0200, Stanislav Lisovskiy wrote:
> Bug in the register unit which results in WM1 register
> used when only WM0 is enabled on cursor.
> Software workaround is when only WM0 enabled on cursor,
> copy contents of CUR_WM_0[30:0] (exclude the enable bit)
> into CUR_WM_1[30:0].
> 
> HSDES: 14012656716
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 89dc7f69baf3..4bc90196d0fb 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5095,6 +5095,18 @@ skl_check_nv12_wm_level(struct skl_wm_level *wm, 
> struct skl_wm_level *uv_wm,
>   }
>  }
>  
> +static bool icl_need_wm1_wa(struct drm_i915_private *dev_priv,

s/dev_priv/i915/

> + enum plane_id plane_id)
> +{
> + /*
> +  * Wa_1408961008:icl, ehl
> +  * Wa_14012656716:tgl, adl
> +  * Underruns with WM1+ disabled
> +  */
> + return (DISPLAY_VER(dev_priv) == 11) ||
> +(IS_DISPLAY_VER(dev_priv, 12, 13) && (plane_id == PLANE_CURSOR));

Unnecessary parens in a few places there. With those removed this is
Reviewed-by: Ville Syrjälä 

> +}
> +
>  static int
>  skl_allocate_plane_ddb(struct intel_atomic_state *state,
>  struct intel_crtc *crtc)
> @@ -5265,11 +5277,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state 
> *state,
>   skl_check_nv12_wm_level(&wm->wm[level], 
> &wm->uv_wm[level],
>   total[plane_id], 
> uv_total[plane_id]);
>  
> - /*
> -  * Wa_1408961008:icl, ehl
> -  * Underruns with WM1+ disabled
> -  */
> - if (DISPLAY_VER(dev_priv) == 11 &&
> + if (icl_need_wm1_wa(dev_priv, plane_id) &&
>   level == 1 && wm->wm[0].enable) {
>   wm->wm[level].blocks = wm->wm[0].blocks;
>   wm->wm[level].lines = wm->wm[0].lines;
> -- 
> 2.24.1.485.gad05a3d8e5

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Tile 4 plane format support (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Tile 4 plane format support (rev3)
URL   : https://patchwork.freedesktop.org/series/95715/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10893 -> Patchwork_21614


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 33)
--

  Additional (1): fi-kbl-soraka 
  Missing(7): bat-dg1-6 fi-tgl-u2 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][2] -> [FAIL][3] ([i915#1888])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

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

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][8] ([i915#3303]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_10893 -> Patchwork_21614

  CI-20190529: 20190529
  CI_DRM_10893: 7b3b824c33cc266381cc91979163f6c4b3f42426 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6283: a2cd90a7c24bb7a4c19ca74c75ed8c950820dee2 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21614: ee19f4b1985733bae4d40d9e7d7e3d04605f3fc0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ee19f4b19857 drm/i915/dg2: Tile 4 plane format support

== Logs ==

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

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Add privacy-screen support (v3)

[Hans de Goede]

Hi Rajat,

On 11/17/21 14:59, Rajat Jain wrote:
> Hello Hans,
> 
> I'm working on my platform's privacy-screen support based on your
> patches, and had some (I know late) questions. Would be great if you
> could please help answer. Please see inline.
> 
> On Tue, Oct 5, 2021 at 1:25 PM Hans de Goede  wrote:
>>
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> Changes in v3:
>> - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
>>
>> Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>>   intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
>>   for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
>> - Move the probe-deferral check to the intel_modeset_probe_defer() helper
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/intel_atomic.c  |  1 +
>>  drivers/gpu/drm/i915/display/intel_ddi.c | 16 
>>  drivers/gpu/drm/i915/display/intel_display.c | 10 ++
>>  3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
>> b/drivers/gpu/drm/i915/display/intel_atomic.c
>> index b4e7ac51aa31..a62550711e98 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
>> @@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct 
>> drm_connector *conn,
>> new_conn_state->base.picture_aspect_ratio != 
>> old_conn_state->base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != 
>> old_conn_state->base.content_type ||
>> new_conn_state->base.scaling_mode != 
>> old_conn_state->base.scaling_mode ||
>> +   new_conn_state->base.privacy_screen_sw_state != 
>> old_conn_state->base.privacy_screen_sw_state ||
>> !drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
>> crtc_state->mode_changed = true;
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index 0d4cf7fa8720..272714e07cc6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -25,6 +25,7 @@
>>   *
>>   */
>>
>> +#include 
>>  #include 
>>
>>  #include "i915_drv.h"
>> @@ -2946,6 +2947,7 @@ static void intel_enable_ddi_dp(struct 
>> intel_atomic_state *state,
>> if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
>> intel_dp_stop_link_train(intel_dp, crtc_state);
>>
>> +   drm_connector_update_privacy_screen(conn_state);
>> intel_edp_backlight_on(crtc_state, conn_state);
>>
>> if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
>> @@ -3161,6 +3163,7 @@ static void intel_ddi_update_pipe_dp(struct 
>> intel_atomic_state *state,
>> intel_drrs_update(intel_dp, crtc_state);
>>
>> intel_backlight_update(state, encoder, crtc_state, conn_state);
>> +   drm_connector_update_privacy_screen(conn_state);
>>  }
>>
>>  void intel_ddi_update_pipe(struct intel_atomic_state *state,
>> @@ -3979,6 +3982,19 @@ intel_ddi_init_dp_connector(struct intel_digital_port 
>> *dig_port)
>> return NULL;
>> }
>>
>> +   if (dig_port->base.type == INTEL_OUTPUT_EDP) {
>> +   struct drm_device *dev = dig_port->base.base.dev;
>> +   struct drm_privacy_screen *privacy_screen;
>> +
>> +   privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
> 
> Why pass NULL for con_id? Can we pass something more meaningful (e.g.
> "eDP-1") so that the non-KMS platform components that provide the
> privacy-screen can provide a more specific lookup? Or is that
> information (connector name) not available at the time this call is
> being made?

For the x86 ACPI case it does not matter because the static lookups
added by drivers/gpu/drm/drm_privacy_screen_x86.c do not set
a con_id in the lookup and if the lookup lack a con_id then
the value passed to drm_privacy_screen_get() is a no-op.

So, if it helps you to pass a connector-name then go for it.

As for the connecter_name already being set at this point,
I don't know, you need to check.

But also see below.

>> +   if (!IS_ERR(privacy_screen)) {
>> +   
>> drm_connector_attach_privacy_screen_provider(&connector->base,
>> +
>> privacy_screen);
>> +   } else if (PTR_ERR(privacy_screen) != -ENODEV) {
>> +   drm_warn(dev, "Error getting privacy-screen\n");
>> +   }
>> +   }
>> +
>> return connector;
>>  }
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 86dbe366a907..84715a779d9d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -42,6 +42,7 @@
>>  #include 
>>  

Re: [Intel-gfx] [PATCH 03/10] drm/privacy-screen: Add X86 specific arch init code

[Hans de Goede]

Hi Rajat,

On 11/17/21 15:13, Rajat Jain wrote:
> Hello Hans,
> 
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede  wrote:
>>
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
>> controlling the privacy-screen.
>>
>> This initial version only checks for the Lenovo Thinkpad specific ACPI
>> methods for privacy-screen control.
>>
>> Reviewed-by: Emil Velikov 
>> Reviewed-by: Lyude Paul 
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/Makefile |  2 +-
>>  drivers/gpu/drm/drm_privacy_screen_x86.c | 86 
>>  include/drm/drm_privacy_screen_machine.h |  5 ++
>>  3 files changed, 92 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 788fc37096f6..12997ca5670d 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>>  drm-$(CONFIG_PCI) += drm_pci.o
>>  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>>  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o 
>> drm_privacy_screen_x86.o
>>
>>  obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c 
>> b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> new file mode 100644
>> index ..a2cafb294ca6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> @@ -0,0 +1,86 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright (C) 2020 Red Hat, Inc.
>> + *
>> + * Authors:
>> + * Hans de Goede 
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +#ifdef CONFIG_X86
>> +static struct drm_privacy_screen_lookup arch_lookup;
>> +
>> +struct arch_init_data {
>> +   struct drm_privacy_screen_lookup lookup;
>> +   bool (*detect)(void);
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
>> + void *context, void **return_value)
>> +{
>> +   *(acpi_handle *)return_value = handle;
>> +   return AE_CTRL_TERMINATE;
>> +}
>> +
>> +static bool __init detect_thinkpad_privacy_screen(void)
>> +{
>> +   union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
>> +   struct acpi_object_list args = { .count = 1, .pointer = &obj, };
>> +   acpi_handle ec_handle = NULL;
>> +   unsigned long long output;
>> +   acpi_status status;
>> +
>> +   /* Get embedded-controller handle */
>> +   status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, 
>> &ec_handle);
>> +   if (ACPI_FAILURE(status) || !ec_handle)
>> +   return false;
>> +
>> +   /* And call the privacy-screen get-status method */
>> +   status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", &args, 
>> &output);
>> +   if (ACPI_FAILURE(status))
>> +   return false;
>> +
>> +   return (output & 0x1) ? true : false;
>> +}
>> +#endif
>> +
>> +static const struct arch_init_data arch_init_data[] __initconst = {
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +   {
>> +   .lookup = {
>> +   .dev_id = NULL,
>> +   .con_id = NULL,
>> +   .provider = "privacy_screen-thinkpad_acpi",
>> +   },
>> +   .detect = detect_thinkpad_privacy_screen,
>> +   },
>> +#endif
>> +};
> 
> As I'm trying to add privacy-screen support for my platform, I'm
> trying to understand if my platform needs to make an entry in this
> static list.
> 
> Do I understand it right that the reason you needed this static list
> (and this whole file really), instead of just doing a
> drm_privacy_screen_lookup_add() in the platform code in
> thinkpad_acpi.c, was because that code was executed AFTER the
> drm_connectors had already initialized> 
> In other words, the privacy-screen providers (platform code) need to
> register a privacy-screen and a lookup structure, BEFORE the drm
> connectors are initialized. If the platform code that provides a
> privacy-screen is executed AFTER the drm-connector initializes, then
> we need an entry in this static list, so that the drm probe (for i915
> atleast) is DEFERRED until the privacy-screen provider registers the
> privacy-screen?
> 
> OTOH, if the platform can register a privacy-screen and a lookup
> function (via drm_privacy_screen_lookup_add()) BEFORE drm probe, then
> I do not need an entry in this static list.
> 
> Is this correct understanding?

Yes, this is all here to deal with probe-ordering.

On a platform where the link between connectors and device-tree
is available in something like devicetree this all becomes
much easier.

The i915 code does a:

   privacy_screen = drm_privacy_screen_get(

Re: [Intel-gfx] [PATCH 02/10] drm: Add privacy-screen class (v4)

[Hans de Goede]

Hi Rajat,

On 11/17/21 15:28, Rajat Jain wrote:
> +Heikki Krogerus
> 
> Hello Hans, Heikki,
> 
> I have a question below, which isn't really a problem, but more of an
> attempt to understand the current code and its limitations.
> 
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede  wrote:
>>
>> On some new laptops the LCD panel has a builtin electronic privacy-screen.
>> We want to export this functionality as a property on the drm connector
>> object. But often this functionality is not exposed on the GPU but on some
>> other (ACPI) device.
>>
>> This commit adds a privacy-screen class allowing the driver for these
>> other devices to register themselves as a privacy-screen provider; and
>> allowing the drm/kms code to get a privacy-screen provider associated
>> with a specific GPU/connector combo.
>>
>> Changes in v2:
>> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
>>   code gets built as part of the main drm module rather then making it
>>   a tristate which builds its own module.
>> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
>>   drm_privacy_screen_consumer.h and define stubs when the check fails.
>>   Together these 2 changes fix several dependency issues.
>> - Remove module related code now that this is part of the main drm.ko
>> - Use drm_class as class for the privacy-screen devices instead of
>>   adding a separate class for this
>>
>> Changes in v3:
>> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
>>   and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
>>   variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>>
>> Changes in v4:
>> - Make drm_privacy_screen_set_sw_state() skip calling out to the hw if
>>   hw_state == new_sw_state
>>
>> Reviewed-by: Emil Velikov 
>> Reviewed-by: Lyude Paul 
>> Signed-off-by: Hans de Goede 
>> ---
>>  Documentation/gpu/drm-kms-helpers.rst |  15 +
>>  MAINTAINERS   |   8 +
>>  drivers/gpu/drm/Kconfig   |   4 +
>>  drivers/gpu/drm/Makefile  |   1 +
>>  drivers/gpu/drm/drm_drv.c |   4 +
>>  drivers/gpu/drm/drm_privacy_screen.c  | 403 ++
>>  include/drm/drm_privacy_screen_consumer.h |  50 +++
>>  include/drm/drm_privacy_screen_driver.h   |  80 +
>>  include/drm/drm_privacy_screen_machine.h  |  41 +++
>>  9 files changed, 606 insertions(+)
>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>>  create mode 100644 include/drm/drm_privacy_screen_consumer.h
>>  create mode 100644 include/drm/drm_privacy_screen_driver.h
>>  create mode 100644 include/drm/drm_privacy_screen_machine.h
>>
>> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
>> b/Documentation/gpu/drm-kms-helpers.rst
>> index ec2f65b31930..5bb55ec1b9b5 100644
>> --- a/Documentation/gpu/drm-kms-helpers.rst
>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>> @@ -435,3 +435,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>>
>>  .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
>> :export:
>> +
>> +Privacy-screen class
>> +
>> +
>> +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
>> +   :doc: overview
>> +
>> +.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
>> +   :internal:
>> +
>> +.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
>> +   :internal:
>> +
>> +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
>> +   :export:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 28e5f0ae1009..cb94bb3b8724 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6423,6 +6423,14 @@ F:   drivers/gpu/drm/drm_panel.c
>>  F: drivers/gpu/drm/panel/
>>  F: include/drm/drm_panel.h
>>
>> +DRM PRIVACY-SCREEN CLASS
>> +M: Hans de Goede 
>> +L: dri-de...@lists.freedesktop.org
>> +S: Maintained
>> +T: git git://anongit.freedesktop.org/drm/drm-misc
>> +F: drivers/gpu/drm/drm_privacy_screen*
>> +F: include/drm/drm_privacy_screen*
>> +
>>  DRM TTM SUBSYSTEM
>>  M: Christian Koenig 
>>  M: Huang Rui 
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 2a926d0de423..c686c08447ac 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
>>  config DRM_LIB_RANDOM
>> bool
>> default n
>> +
>> +config DRM_PRIVACY_SCREEN
>> +   bool
>> +   default n
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 0dff40bb863c..788fc37096f6 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>>  drm-$(CONFIG_PCI) += drm_pci.o
>>  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>>  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>>
>>  obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 

Re: [Intel-gfx] [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm

[Matthew Auld]

On 16/11/2021 20:18, Arunpravin wrote:

Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
   will be moved to drm selftest folder

cleanup i915 buddy references in i915 driver module
and replace with drm buddy

v2:
   - include header file in alphabetical order (Thomas)
   - merged changes listed in the body section into a single patch
 to keep the build intact (Christian, Jani)

Signed-off-by: Arunpravin 


Any ideas for what to do with the existing selftests? Currently this 
series doesn't build yet for i915 due to this, and prevents throwing the 
series at CI.

Re: [Intel-gfx] [PATCH] drm/i915/: Extend VRR platform support to Gen 11

[Ville Syrjälä]

On Tue, Nov 16, 2021 at 03:12:09PM -0800, Manasi Navare wrote:
> VRR is supported on Gen 11 HW , hence extend the support
> in the driver to enable this for Gen 11.

Yeah, based on my testing icl works as well (or as poorly)
as tgl.

Reviewed-by: Ville Syrjälä 

> 
> Cc: Ville Syrjälä 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 94840af45750..3b00a8edbb1d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1741,7 +1741,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  
>  #define HAS_DISPLAY(dev_priv) (INTEL_INFO(dev_priv)->pipe_mask != 0)
>  
> -#define HAS_VRR(i915)(GRAPHICS_VER(i915) >= 12)
> +#define HAS_VRR(i915)(GRAPHICS_VER(i915) >= 11)
>  
>  #define HAS_ASYNC_FLIPS(i915)(DISPLAY_VER(i915) >= 5)
>  
> -- 
> 2.19.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again

[Ville Syrjala]

From: Ville Syrjälä 

Moving the vrr push to happen before sampling the frame counter
was wrong. If we are already in vblank when the push is sent
the vblank exit will start immediately which causes the sampled
frame counter to correspond to the next frame instead of the current
frame.

So put things back into the original order (except we should
keep the vrr push within the irq disable section to avoid
pointless irq related delays here).

We'll just have to accept the tiny race that exists between
sampling the frame counter vs. vrr push. And let's at least
document said race properly in a comment.

I suppose we could try to minimize the race by sampling the frame
counter just before sending the push, but that would require
changing drm_crtc_arm_vblank_event() to accept a caller provided
vblank counter value, so leave it be for now. Another thing we
could do is change the vblank evasion to account for the case
where a push was already sent. That would anyway be required
for mailbox style updates. Currently mailbox updates are only
used by the legacy cursor, but we don't do a vrr push for those.

Cc: Manasi Navare 
Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame counter")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index f09df2cf052b..cf403be7736c 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -610,9 +610,6 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
 
trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
 
-   /* Send VRR Push to terminate Vblank */
-   intel_vrr_send_push(new_crtc_state);
-
/*
 * Incase of mipi dsi command mode, we need to set frame update
 * request for every commit.
@@ -641,6 +638,22 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->uapi.event = NULL;
}
 
+   /*
+* Send VRR Push to terminate Vblank. If we are already in vblank
+* this has to be done _after_ sampling the frame counter, as
+* otherwise the push would immediately terminate the vblank and
+* the sampled frame counter would correspond to the next frame
+* instead of the current frame.
+*
+* There is a tiny race here (iff vblank evasion failed us) where
+* we might sample the frame counter just before vmax vblank start
+* but the push would be sent just after it. That would cause the
+* push to affect the next frame instead of the current frame,
+* which would cause the next frame to terminate already at vmin
+* vblank start instead of vmax vblank start.
+*/
+   intel_vrr_send_push(new_crtc_state);
+
local_irq_enable();
 
if (intel_vgpu_active(dev_priv))
-- 
2.32.0

[Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Ville Syrjala]

From: Ville Syrjälä 

Let's adjust the vblank evasion to account for the case where
a push has already been sent. In that case the vblank exit will start
at vmin vblank start (as opposed to vmax vblank start when no push
has been sent).

This should minimize the effects of the tiny race between sampling
the frame counter vs. intel_vrr_send_push() during the previous frame.
This will also be required if we want to do mailbox style updates with
vrr since then we'd definitely do multiple commits per frame. Currently
mailbox updates are only used by the legacy cursor, but we don't do
vrr push for those.

Cc: Manasi Navare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
 drivers/gpu/drm/i915/display/intel_vrr.c  | 12 
 drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index cf403be7736c..eb5444f90e77 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state 
*new_crtc_state)
if (intel_crtc_needs_vblank_work(new_crtc_state))
intel_crtc_vblank_work_init(new_crtc_state);
 
-   if (new_crtc_state->vrr.enable)
-   vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
-   else
+   if (new_crtc_state->vrr.enable) {
+   if (intel_vrr_is_push_sent(new_crtc_state))
+   vblank_start = 
intel_vrr_vmin_vblank_start(new_crtc_state);
+   else
+   vblank_start = 
intel_vrr_vmax_vblank_start(new_crtc_state);
+   } else {
vblank_start = intel_mode_vblank_start(adjusted_mode);
+   }
 
/* FIXME needs to be calibrated sensibly */
min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index c335b1dbafcf..db1c3902fc2d 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state 
*crtc_state)
   TRANS_PUSH_EN | TRANS_PUSH_SEND);
 }
 
+bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+   if (!crtc_state->vrr.enable)
+   return false;
+
+   return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & 
TRANS_PUSH_SEND;
+}
+
 void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h 
b/drivers/gpu/drm/i915/display/intel_vrr.h
index 96f9c9c27ab9..1c2da572693d 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.h
+++ b/drivers/gpu/drm/i915/display/intel_vrr.h
@@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
 void intel_vrr_enable(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state);
 void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
+bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
 void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
 void intel_vrr_get_config(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state);
-- 
2.32.0

[Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code

[Ville Syrjala]

From: Ville Syrjälä 

Since I originally wrote these comments we decided to change our
definition of framestart_delay from 0-3 to 1-4. Adjust the comments
to match that new convention. The actual code was adjusted already.

Cc: Manasi Navare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index db1c3902fc2d..139e8936edc5 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -60,7 +60,7 @@ intel_vrr_check_modeset(struct intel_atomic_state *state)
  * Between those two points the vblank exit starts (and hence registers get
  * latched) ASAP after a push is sent.
  *
- * framestart_delay is programmable 0-3.
+ * framestart_delay is programmable 1-4.
  */
 static int intel_vrr_vblank_exit_length(const struct intel_crtc_state 
*crtc_state)
 {
@@ -138,13 +138,13 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
i915->window2_delay;
else
/*
-* FIXME: s/4/framestart_delay+1/ to get consistent
+* FIXME: s/4/framestart_delay/ to get consistent
 * earliest/latest points for register latching regardless
 * of the framestart_delay used?
 *
 * FIXME: this really needs the extra scanline to provide 
consistent
 * behaviour for all framestart_delay values. Otherwise with
-* framestart_delay==3 we will end up extending the min vblank 
by
+* framestart_delay==4 we will end up extending the min vblank 
by
 * one extra line.
 */
crtc_state->vrr.pipeline_full =
-- 
2.32.0

[Intel-gfx] ✗ Fi.CI.BUILD: failure for More preparation for multi gt patches

[Patchwork]

== Series Details ==

Series: More preparation for multi gt patches
URL   : https://patchwork.freedesktop.org/series/97020/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_mman.o
In file included from drivers/gpu/drm/i915/gem/i915_gem_mman.c:1010:
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c: In function 
‘check_partial_mapping’:
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:144:54: error: ‘struct 
drm_i915_private’ has no member named ‘gt’; did you mean ‘gvt’?
  intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt);
  ^~
  gvt
In file included from drivers/gpu/drm/i915/gem/i915_gem_mman.c:1010:
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c: In function 
‘check_partial_mappings’:
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:237:55: error: ‘struct 
drm_i915_private’ has no member named ‘gt’; did you mean ‘gvt’?
   intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt);
   ^~
   gvt
scripts/Makefile.build:287: recipe for target 
'drivers/gpu/drm/i915/gem/i915_gem_mman.o' failed
make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_mman.o] Error 1
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1846: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Re: [Intel-gfx] [PATCH v3 2/6] drm: improve drm_buddy_alloc function

[Matthew Auld]

On 16/11/2021 20:18, Arunpravin wrote:

- Make drm_buddy_alloc a single function to handle
   range allocation and non-range allocation demands

- Implemented a new function alloc_range() which allocates
   the requested power-of-two block comply with range limitations

- Moved order computation and memory alignment logic from
   i915 driver to drm buddy

v2:
   merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver

v3(Matthew Auld):
   - Fix alignment issues and remove unnecessary list_empty check
   - add more validation checks for input arguments
   - make alloc_range() block allocations as bottom-up
   - optimize order computation logic
   - replace uint64_t with u64, which is preferred in the kernel

Signed-off-by: Arunpravin 
---
  drivers/gpu/drm/drm_buddy.c   | 259 ++
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c |  69 ++---
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.h |   2 +
  include/drm/drm_buddy.h   |  22 +-
  4 files changed, 203 insertions(+), 149 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 39eb1d224bec..c9b18a29f8d1 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -274,63 +274,6 @@ void drm_buddy_free_list(struct drm_buddy_mm *mm, struct 
list_head *objects)
  }
  EXPORT_SYMBOL(drm_buddy_free_list);
  
-/**

- * drm_buddy_alloc - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the &drm_buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order)
-{
-   struct drm_buddy_block *block = NULL;
-   unsigned int i;
-   int err;
-
-   for (i = order; i <= mm->max_order; ++i) {
-   block = list_first_entry_or_null(&mm->free_list[i],
-struct drm_buddy_block,
-link);
-   if (block)
-   break;
-   }
-
-   if (!block)
-   return ERR_PTR(-ENOSPC);
-
-   BUG_ON(!drm_buddy_block_is_free(block));
-
-   while (i != order) {
-   err = split_block(mm, block);
-   if (unlikely(err))
-   goto out_free;
-
-   /* Go low */
-   block = block->left;
-   i--;
-   }
-
-   mark_allocated(block);
-   mm->avail -= drm_buddy_block_size(mm, block);
-   kmemleak_update_trace(block);
-   return block;
-
-out_free:
-   if (i != order)
-   __drm_buddy_free(mm, block);
-   return ERR_PTR(err);
-}
-EXPORT_SYMBOL(drm_buddy_alloc);
-
  static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2)
  {
return s1 <= e2 && e1 >= s2;
@@ -341,52 +284,22 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64 
e2)
return s1 <= s2 && e1 >= e2;
  }
  
-/**

- * drm_buddy_alloc_range - allocate range
- *
- * @mm: DRM buddy manager to allocate from
- * @blocks: output list head to add allocated blocks
- * @start: start of the allowed range for this block
- * @size: size of the allocation
- *
- * Intended for pre-allocating portions of the address space, for example to
- * reserve a block for the initial framebuffer or similar, hence the 
expectation
- * here is that drm_buddy_alloc() is still the main vehicle for
- * allocations, so if that's not the case then the drm_mm range allocator is
- * probably a much better fit, and so you should probably go use that instead.
- *
- * Note that it's safe to chain together multiple alloc_ranges
- * with the same blocks list
- *
- * Returns:
- * 0 on success, error code on failure.
- */
-int drm_buddy_alloc_range(struct drm_buddy_mm *mm,
- struct list_head *blocks,
- u64 start, u64 size)
+static struct drm_buddy_block *
+alloc_range(struct drm_buddy_mm *mm,
+   u64 start, u64 end,
+   unsigned int order)
  {
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
-   LIST_HEAD(allocated);
LIST_HEAD(dfs);
-   u64 end;
int err;
int i;
  
-	if (size < mm->chunk_size)

-   return -EINVAL;
-
-   if (!IS_ALIGNED(size | start, mm->chunk_size))
-   return -EINVAL;
-
-   if (range_overflows(start, size, mm->size))
-   return -EINVAL;
+   end = end - 1;
  
  	for (i = 0; i < mm->n_roots; ++i)

list_add_tail(&mm->roots[i]->tmp_link, &dfs);
  
-	end = start + size - 1;

-
do {
u64 block_s

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

[Ville Syrjälä]

On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> From: Matt Atwood 
> 
> Extend existing workaround 1409120013 to DG2.

I don't see this listed for DG2.

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Matt Atwood 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 89dc7f69baf3..e721c421cc58 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>  
>  static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
>  {
> - /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> + /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
>   if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> - IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> + IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
>   intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
>  DPFC_CHICKEN_COMP_DUMMY_PIXEL);
>  
> -- 
> 2.33.0

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move the pre_pin earlier

[Thomas Hellström]

On 11/17/21 15:20, Matthew Auld wrote:

In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart the do_pin at this point.

If this is the kernel_context, or some other early in-kernel context
where we have yet to setup the default_state, then we always inhibit the
context restore, and instead rely on the delayed active_release to set
the CONTEXT_VALID_BIT for us(if we even care), which should indicate
that we have context switched away, and that our newly saved context
state should now be valid. However, since we currently grab the active
reference before the potential ww dance, we can end up setting the
CONTEXT_VALID_BIT much too early, if we need to backoff, and then upon
re-trying the do_pin, we could potentially cause the hardware to
incorrectly load some garbage context state when later context switching
to that context, but at the very least this will trigger the
GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance
stuff prior to arming the active reference.

For normal user contexts this shouldn't be a concern, since we should
already have the default_state ready when initialising the lrc state,
and so there should be no concern with active_release somehow
prematurely setting the CONTEXT_VALID_BIT.

v2(Thomas):
   - Also re-order the union unwind

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 


Reviewed-by: Thomas Hellström 



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

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5634d14052bc..4c296de1d67d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
if (err)
return err;
  
-	err = i915_active_acquire(&ce->active);

+   err = ce->ops->pre_pin(ce, ww, &vaddr);
if (err)
goto err_ctx_unpin;
  
-	err = ce->ops->pre_pin(ce, ww, &vaddr);

+   err = i915_active_acquire(&ce->active);
if (err)
-   goto err_release;
+   goto err_post_unpin;
  
  	err = mutex_lock_interruptible(&ce->pin_mutex);

if (err)
-   goto err_post_unpin;
+   goto err_release;
  
  	intel_engine_pm_might_get(ce->engine);
  
@@ -273,11 +273,11 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
  
  err_unlock:

mutex_unlock(&ce->pin_mutex);
+err_release:
+   i915_active_release(&ce->active);
  err_post_unpin:
if (!handoff)
ce->ops->post_unpin(ce);
-err_release:
-   i915_active_release(&ce->active);
  err_ctx_unpin:
intel_context_post_unpin(ce);
  

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

[Matt Roper]

On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood 
> > 
> > Extend existing workaround 1409120013 to DG2.
> 
> I don't see this listed for DG2.

This seems to be problem with the DG2 query since for some reason they
marked this workaround as 'driver_change_required' rather than
'driver_permanent_wa' in the database and that prevents it from showing
up in some of the queries properly.  The DG2-specific ID number
to check is 140975.


Matt

> 
> > 
> > Cc: José Roberto de Souza 
> > Signed-off-by: Matt Atwood 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 89dc7f69baf3..e721c421cc58 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> >  
> >  static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> >  {
> > -   /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> > +   /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
> > if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> > -   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> > +   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
> > intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
> >DPFC_CHICKEN_COMP_DUMMY_PIXEL);
> >  
> > -- 
> > 2.33.0
> 
> -- 
> Ville Syrjälä
> Intel

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

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

[Ville Syrjälä]

On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood 
> > 
> > Extend existing workaround 1409120013 to DG2.
> 
> I don't see this listed for DG2.
> 
> > 
> > Cc: José Roberto de Souza 
> > Signed-off-by: Matt Atwood 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 89dc7f69baf3..e721c421cc58 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> >  
> >  static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> >  {
> > -   /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> > +   /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
> > if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> > -   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> > +   IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))

AFAIK we're not even calling this function on dg2, so this is just dead
code. And in fact without dg2 this seems to be the same as DISPLAY_VER==12
so we shuld stop calling it on adl-p as well. We could then rip out most
of the platform checks in here.

> > intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
> >DPFC_CHICKEN_COMP_DUMMY_PIXEL);
> >  
> > -- 
> > 2.33.0
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2

[Ville Syrjälä]

On Wed, Nov 17, 2021 at 10:51:39AM -0800, Matt Roper wrote:
> On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > > From: Matt Atwood 
> > > 
> > > Extend existing workaround 1409120013 to DG2.
> > 
> > I don't see this listed for DG2.
> 
> This seems to be problem with the DG2 query since for some reason they
> marked this workaround as 'driver_change_required' rather than
> 'driver_permanent_wa' in the database and that prevents it from showing
> up in some of the queries properly.  The DG2-specific ID number
> to check is 140975.

Bit of mes that one. I can't really figure out if dg2 is the only
d13 platform that needs this or might there be others?

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v3 4/6] drm: implement a method to free unused pages

[Matthew Auld]

On 16/11/2021 20:18, Arunpravin wrote:

On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.

v2(Matthew Auld):
   - replace function name 'drm_buddy_free_unused_pages' with
 drm_buddy_block_trim
   - replace input argument name 'actual_size' with 'new_size'
   - add more validation checks for input arguments
   - add overlaps check to avoid needless searching and splitting
   - merged the below patch to see the feature in action
 - add free unused pages support to i915 driver
   - lock drm_buddy_block_trim() function as it calls mark_free/mark_split
 are all globally visible

Signed-off-by: Arunpravin 
---
  drivers/gpu/drm/drm_buddy.c   | 108 ++
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c |  10 ++
  include/drm/drm_buddy.h   |   4 +
  3 files changed, 122 insertions(+)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 0a9db2981188..943fe2ad27bf 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -284,6 +284,114 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64 
e2)
return s1 <= s2 && e1 >= e2;
  }
  
+/**

+ * drm_buddy_block_trim - free unused pages
+ *
+ * @mm: DRM buddy manager
+ * @new_size: original size requested
+ * @blocks: output list head to add allocated blocks
+ *
+ * For contiguous allocation, we round up the size to the nearest
+ * power of two value, drivers consume *actual* size, so remaining
+ * portions are unused and it can be freed.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_block_trim(struct drm_buddy_mm *mm,
+u64 new_size,
+struct list_head *blocks)
+{
+   struct drm_buddy_block *block;
+   struct drm_buddy_block *buddy;
+   u64 new_start;
+   u64 new_end;
+   LIST_HEAD(dfs);
+   u64 count = 0;
+   int err;
+
+   if (!list_is_singular(blocks))
+   return -EINVAL;
+
+   block = list_first_entry(blocks,
+struct drm_buddy_block,
+link);
+
+   if (!drm_buddy_block_is_allocated(block))
+   return -EINVAL;
+
+   if (new_size > drm_buddy_block_size(mm, block))
+   return -EINVAL;
+
+   if (!new_size && !IS_ALIGNED(new_size, mm->chunk_size))
+   return -EINVAL;
+
+   if (new_size == drm_buddy_block_size(mm, block))
+   return 0;
+
+   list_del(&block->link);
+
+   new_start = drm_buddy_block_offset(block);
+   new_end = new_start + new_size - 1;
+
+   mark_free(mm, block);
+
+   list_add(&block->tmp_link, &dfs);
+
+   do {
+   u64 block_start;
+   u64 block_end;
+
+   block = list_first_entry_or_null(&dfs,
+struct drm_buddy_block,
+tmp_link);
+   if (!block)
+   break;
+
+   list_del(&block->tmp_link);
+
+   if (count == new_size)
+   return 0;
+
+   block_start = drm_buddy_block_offset(block);
+   block_end = block_start + drm_buddy_block_size(mm, block) - 1;
+
+   if (!overlaps(new_start, new_end, block_start, block_end))
+   continue;
+
+   if (contains(new_start, new_end, block_start, block_end)) {
+   BUG_ON(!drm_buddy_block_is_free(block));
+
+   /* Allocate only required blocks */
+   mark_allocated(block);
+   mm->avail -= drm_buddy_block_size(mm, block);
+   list_add_tail(&block->link, blocks);
+   count += drm_buddy_block_size(mm, block);
+   continue;
+   }
+
+   if (!drm_buddy_block_is_split(block)) {


Should always be true, right? But I guess depends if we want to re-use 
this for generic range allocation...



+   err = split_block(mm, block);
+   if (unlikely(err))
+   goto err_undo;
+   }
+
+   list_add(&block->right->tmp_link, &dfs);
+   list_add(&block->left->tmp_link, &dfs);
+   } while (1);
+
+   return -ENOSPC;
+
+err_undo:
+   buddy = get_buddy(block);
+   if (buddy &&
+   (drm_buddy_block_is_free(block) &&
+drm_buddy_block_is_free(buddy)))
+   __drm_buddy_free(mm, block);
+   return err;


Looking at the split_block failure path. The user allocated some block, 
and then tried to trim it, but this then marks it as free and removes it 
from their original list(potentially also freeing it), if we fail here. 
Would it be better to leave that decision to the user? If the trim(

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Implement WM0 cursor WA for DG2

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Implement WM0 cursor WA for DG2
URL   : https://patchwork.freedesktop.org/series/97022/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21616


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 33)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): bat-dg1-6 fi-tgl-u2 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([fdo#109315])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([i915#4103]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([fdo#109285])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#1072]) +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#3301])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][14] ([i915#3363] / [i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [DMESG-WARN][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [DMESG-FAIL][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21616/fi-rkl-guc/igt@i915_selftes

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915: move the pre_pin earlier

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: move the pre_pin earlier
URL   : https://patchwork.freedesktop.org/series/97026/
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.BAT: failure for series starting with [v2,1/6] drm/i915: move the pre_pin earlier

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/6] drm/i915: move the pre_pin earlier
URL   : https://patchwork.freedesktop.org/series/97026/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21617


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 35)
--

  Additional (1): fi-tgl-1115g4 
  Missing(6): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 bat-jsl-2 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_flink_basic@bad-flink:
- fi-skl-6600u:   [PASS][6] -> [FAIL][7] ([i915#4547])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#1155])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#3301])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][15] ([i915#3363] / [i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [DMESG-WARN][16] -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21617/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gt_engines:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dg2: Introduce CD clock squashing table

[Patchwork]

== Series Details ==

Series: drm/i915/display/dg2: Introduce CD clock squashing table
URL   : https://patchwork.freedesktop.org/series/97030/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b93af6229243 drm/i915/display/dg2: Introduce CD clock squashing table
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
For CD clock squashing method, we need to define corresponding CD clock table 
for

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

Re: [Intel-gfx] [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm

[kernel test robot]

Hi Arunpravin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next v5.16-rc1]
[cannot apply to drm-tip/drm-tip next-2027]
[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/0day-ci/linux/commits/Arunpravin/drm-move-the-buddy-allocator-from-i915-into-common-drm/2027-041920
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/47fb1aeae75661971f4526efddf4ae5b5738977f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Arunpravin/drm-move-the-buddy-allocator-from-i915-into-common-drm/2027-041920
git checkout 47fb1aeae75661971f4526efddf4ae5b5738977f
# save the attached .config to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

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/i915/intel_memory_region.c:242:
>> drivers/gpu/drm/i915/selftests/intel_memory_region.c:23:10: fatal error: 
>> i915_buddy.h: No such file or directory
  23 | #include "i915_buddy.h"
 |  ^~
   compilation terminated.


vim +23 drivers/gpu/drm/i915/selftests/intel_memory_region.c

232a6ebae419193 Matthew Auld 2019-10-08  14  
340be48f2c5a3c0 Matthew Auld 2019-10-25  15  #include 
"gem/i915_gem_context.h"
b908be543e44414 Matthew Auld 2019-10-25  16  #include "gem/i915_gem_lmem.h"
232a6ebae419193 Matthew Auld 2019-10-08  17  #include 
"gem/i915_gem_region.h"
340be48f2c5a3c0 Matthew Auld 2019-10-25  18  #include 
"gem/selftests/igt_gem_utils.h"
232a6ebae419193 Matthew Auld 2019-10-08  19  #include 
"gem/selftests/mock_context.h"
99919be74aa3753 Thomas Hellström 2021-06-17  20  #include "gt/intel_engine_pm.h"
6804da20bb549e3 Chris Wilson 2019-10-27  21  #include 
"gt/intel_engine_user.h"
b908be543e44414 Matthew Auld 2019-10-25  22  #include "gt/intel_gt.h"
d53ec322dc7de32 Matthew Auld 2021-06-16 @23  #include "i915_buddy.h"
99919be74aa3753 Thomas Hellström 2021-06-17  24  #include "gt/intel_migrate.h"
ba12993c5228015 Matthew Auld 2020-01-29  25  #include "i915_memcpy.h"
d53ec322dc7de32 Matthew Auld 2021-06-16  26  #include 
"i915_ttm_buddy_manager.h"
01377a0d7e6648b Abdiel Janulgue  2019-10-25  27  #include 
"selftests/igt_flush_test.h"
2f0b97ca0211863 Matthew Auld 2019-10-08  28  #include 
"selftests/i915_random.h"
232a6ebae419193 Matthew Auld 2019-10-08  29  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Moving the vrr push to happen before sampling the frame counter
> was wrong. If we are already in vblank when the push is sent
> the vblank exit will start immediately which causes the sampled
> frame counter to correspond to the next frame instead of the current
> frame.
> 
> So put things back into the original order (except we should
> keep the vrr push within the irq disable section to avoid
> pointless irq related delays here).
> 
> We'll just have to accept the tiny race that exists between
> sampling the frame counter vs. vrr push. And let's at least
> document said race properly in a comment.
> 
> I suppose we could try to minimize the race by sampling the frame
> counter just before sending the push, but that would require
> changing drm_crtc_arm_vblank_event() to accept a caller provided
> vblank counter value, so leave it be for now. Another thing we
> could do is change the vblank evasion to account for the case
> where a push was already sent. That would anyway be required
> for mailbox style updates. Currently mailbox updates are only
> used by the legacy cursor, but we don't do a vrr push for those.
> 
> Cc: Manasi Navare 
> Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame 
> counter")
> Signed-off-by: Ville Syrjälä 

The original order was to send push after enabling IRQs but I think it makes
sense to send push just before enabling IRQs so avoid the vblank
termination getting delayed due to IRQs

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index f09df2cf052b..cf403be7736c 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -610,9 +610,6 @@ void intel_pipe_update_end(struct intel_crtc_state 
> *new_crtc_state)
>  
>   trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
>  
> - /* Send VRR Push to terminate Vblank */
> - intel_vrr_send_push(new_crtc_state);
> -
>   /*
>* Incase of mipi dsi command mode, we need to set frame update
>* request for every commit.
> @@ -641,6 +638,22 @@ void intel_pipe_update_end(struct intel_crtc_state 
> *new_crtc_state)
>   new_crtc_state->uapi.event = NULL;
>   }
>  
> + /*
> +  * Send VRR Push to terminate Vblank. If we are already in vblank
> +  * this has to be done _after_ sampling the frame counter, as
> +  * otherwise the push would immediately terminate the vblank and
> +  * the sampled frame counter would correspond to the next frame
> +  * instead of the current frame.
> +  *
> +  * There is a tiny race here (iff vblank evasion failed us) where
> +  * we might sample the frame counter just before vmax vblank start
> +  * but the push would be sent just after it. That would cause the
> +  * push to affect the next frame instead of the current frame,
> +  * which would cause the next frame to terminate already at vmin
> +  * vblank start instead of vmax vblank start.
> +  */
> + intel_vrr_send_push(new_crtc_state);
> +
>   local_irq_enable();
>  
>   if (intel_vgpu_active(dev_priv))
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's adjust the vblank evasion to account for the case where
> a push has already been sent. In that case the vblank exit will start
> at vmin vblank start (as opposed to vmax vblank start when no push
> has been sent).
> 
> This should minimize the effects of the tiny race between sampling
> the frame counter vs. intel_vrr_send_push() during the previous frame.
> This will also be required if we want to do mailbox style updates with
> vrr since then we'd definitely do multiple commits per frame. Currently
> mailbox updates are only used by the legacy cursor, but we don't do
> vrr push for those.
> 
> Cc: Manasi Navare 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
>  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 
>  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index cf403be7736c..eb5444f90e77 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state 
> *new_crtc_state)
>   if (intel_crtc_needs_vblank_work(new_crtc_state))
>   intel_crtc_vblank_work_init(new_crtc_state);
>  
> - if (new_crtc_state->vrr.enable)
> - vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> - else
> + if (new_crtc_state->vrr.enable) {
> + if (intel_vrr_is_push_sent(new_crtc_state))
> + vblank_start = 
> intel_vrr_vmin_vblank_start(new_crtc_state);

Actually if Push is sent then the vblank gets terminated at that point which 
falls between vmin and vmax so
not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to 
calculate it based on vmin?

> + else
> + vblank_start = 
> intel_vrr_vmax_vblank_start(new_crtc_state);
> + } else {
>   vblank_start = intel_mode_vblank_start(adjusted_mode);
> + }
>  
>   /* FIXME needs to be calibrated sensibly */
>   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index c335b1dbafcf..db1c3902fc2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state 
> *crtc_state)
>  TRANS_PUSH_EN | TRANS_PUSH_SEND);
>  }
>  
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + if (!crtc_state->vrr.enable)
> + return false;
> +
> + return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & 
> TRANS_PUSH_SEND;

But HW clears this bit after double buffer update. Is this a good inidcation to 
check the PUSH_SEND bit?

Manasi

> +}
> +
>  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h 
> b/drivers/gpu/drm/i915/display/intel_vrr.h
> index 96f9c9c27ab9..1c2da572693d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>  void intel_vrr_enable(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state);
>  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
>  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
>  void intel_vrr_get_config(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state);
> -- 
> 2.32.0
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/dg2: Introduce CD clock squashing table

[Patchwork]

== Series Details ==

Series: drm/i915/display/dg2: Introduce CD clock squashing table
URL   : https://patchwork.freedesktop.org/series/97030/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21618


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 35)
--

  Additional (1): fi-tgl-1115g4 
  Missing(6): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 bat-jsl-2 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([fdo#109315])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  [PASS][7] -> [INCOMPLETE][8] ([i915#4006])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  NOTRUN -> [FAIL][9] ([i915#1888])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#1155])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][17] ([i915#3363] / [i915#4312])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21618/fi-skl-6600u/igt@run...@aborted.html
- fi-tgl-u2:  NOTRUN -> [FAIL][18] ([i915#1602] / [i915#2722] / 
[i915#4312])
   [18]: 
https://inte

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Since I originally wrote these comments we decided to change our
> definition of framestart_delay from 0-3 to 1-4. Adjust the comments
> to match that new convention. The actual code was adjusted already.
> 
> Cc: Manasi Navare 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index db1c3902fc2d..139e8936edc5 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -60,7 +60,7 @@ intel_vrr_check_modeset(struct intel_atomic_state *state)
>   * Between those two points the vblank exit starts (and hence registers get
>   * latched) ASAP after a push is sent.
>   *
> - * framestart_delay is programmable 0-3.
> + * framestart_delay is programmable 1-4.
>   */
>  static int intel_vrr_vblank_exit_length(const struct intel_crtc_state 
> *crtc_state)
>  {
> @@ -138,13 +138,13 @@ intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>   i915->window2_delay;
>   else
>   /*
> -  * FIXME: s/4/framestart_delay+1/ to get consistent
> +  * FIXME: s/4/framestart_delay/ to get consistent
>* earliest/latest points for register latching regardless
>* of the framestart_delay used?
>*
>* FIXME: this really needs the extra scanline to provide 
> consistent
>* behaviour for all framestart_delay values. Otherwise with
> -  * framestart_delay==3 we will end up extending the min vblank 
> by
> +  * framestart_delay==4 we will end up extending the min vblank 
> by
>* one extra line.
>*/
>   crtc_state->vrr.pipeline_full =
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Ville Syrjälä]

On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Let's adjust the vblank evasion to account for the case where
> > a push has already been sent. In that case the vblank exit will start
> > at vmin vblank start (as opposed to vmax vblank start when no push
> > has been sent).
> > 
> > This should minimize the effects of the tiny race between sampling
> > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > This will also be required if we want to do mailbox style updates with
> > vrr since then we'd definitely do multiple commits per frame. Currently
> > mailbox updates are only used by the legacy cursor, but we don't do
> > vrr push for those.
> > 
> > Cc: Manasi Navare 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
> >  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 
> >  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
> >  3 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index cf403be7736c..eb5444f90e77 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state 
> > *new_crtc_state)
> > if (intel_crtc_needs_vblank_work(new_crtc_state))
> > intel_crtc_vblank_work_init(new_crtc_state);
> >  
> > -   if (new_crtc_state->vrr.enable)
> > -   vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > -   else
> > +   if (new_crtc_state->vrr.enable) {
> > +   if (intel_vrr_is_push_sent(new_crtc_state))
> > +   vblank_start = 
> > intel_vrr_vmin_vblank_start(new_crtc_state);
> 
> Actually if Push is sent then the vblank gets terminated at that point which 
> falls between vmin and vmax so
> not necessarily at Vmin but at anytime between vmin and vmax. Is it correct 
> to calculate it based on vmin?

If you do a push between vmin and vmax then the vblank terminates
immediately and the PUSH_SEND bit gets cleared. The only way the bit
stays set is you set it after vmax/before vmin.

> 
> > +   else
> > +   vblank_start = 
> > intel_vrr_vmax_vblank_start(new_crtc_state);
> > +   } else {
> > vblank_start = intel_mode_vblank_start(adjusted_mode);
> > +   }
> >  
> > /* FIXME needs to be calibrated sensibly */
> > min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index c335b1dbafcf..db1c3902fc2d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state 
> > *crtc_state)
> >TRANS_PUSH_EN | TRANS_PUSH_SEND);
> >  }
> >  
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +
> > +   if (!crtc_state->vrr.enable)
> > +   return false;
> > +
> > +   return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & 
> > TRANS_PUSH_SEND;
> 
> But HW clears this bit after double buffer update. Is this a good inidcation 
> to check the PUSH_SEND bit?
> 
> Manasi
> 
> > +}
> > +
> >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> >  {
> > struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h 
> > b/drivers/gpu/drm/i915/display/intel_vrr.h
> > index 96f9c9c27ab9..1c2da572693d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state 
> > *crtc_state,
> >  void intel_vrr_enable(struct intel_encoder *encoder,
> >   const struct intel_crtc_state *crtc_state);
> >  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> >  void intel_vrr_get_config(struct intel_crtc *crtc,
> >   struct intel_crtc_state *crtc_state);
> > -- 
> > 2.32.0
> > 

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pxp: fix includes for headers in include/drm (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: fix includes for headers in include/drm (rev3)
URL   : https://patchwork.freedesktop.org/series/96974/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10891_full -> Patchwork_21613_full


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_atomic_transition@modeset-transition-nonblocking-fencing@1x-outputs:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-tglb7/igt@kms_atomic_transition@modeset-transition-nonblocking-fenc...@1x-outputs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb8/igt@kms_atomic_transition@modeset-transition-nonblocking-fenc...@1x-outputs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][4] -> [INCOMPLETE][5] ([i915#198])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-tglb7/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb8/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#4525])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb2/igt@gem_exec_balan...@parallel-keep-in-fence.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#2369])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-skl9/igt@gem_exec_capture@p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-skl4/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][11] -> [SKIP][12] ([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-apl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-apl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10891/shard-tglb5/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-tglb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb2/igt@gem_exec_fair@basic-throt...@rcs0.html

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

  * igt@gen7_exec_parse@basic-offset:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-tglb8/igt@gen7_exec_pa...@basic-offset.html
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109289])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21613/shard-iclb6/igt@gen7_exec_pa...@basic-offset.html

  * igt@gen9_exec_parse@allowed-all:
- shard-kbl:  [PASS][20] -> [DMESG-WARN][21] ([i915#1436] / 
[i915#716])
   [20]: 
https://

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display/dg2: Read CD clock from squasher table

[Patchwork]

== Series Details ==

Series: drm/i915/display/dg2: Read CD clock from squasher table
URL   : https://patchwork.freedesktop.org/series/97031/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/display/intel_cdclk.o
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘bxt_get_cdclk’:
drivers/gpu/drm/i915/display/intel_cdclk.c:1495:6: error: implicit declaration 
of function ‘has_cdclk_squasher’ [-Werror=implicit-function-declaration]
  if (has_cdclk_squasher(dev_priv))
  ^~
drivers/gpu/drm/i915/display/intel_cdclk.c:1496:40: error: ‘CDCLK_SQUASH_CTL’ 
undeclared (first use in this function); did you mean ‘CDCLK_CTL’?
   squash_ctl = intel_de_read(dev_priv, CDCLK_SQUASH_CTL);
^~~~
CDCLK_CTL
drivers/gpu/drm/i915/display/intel_cdclk.c:1496:40: note: each undeclared 
identifier is reported only once for each function it appears in
drivers/gpu/drm/i915/display/intel_cdclk.c:1498:19: error: 
‘CDCLK_SQUASH_ENABLE’ undeclared (first use in this function); did you mean 
‘ICL_CSC_ENABLE’?
  if (squash_ctl & CDCLK_SQUASH_ENABLE) {
   ^~~
   ICL_CSC_ENABLE
In file included from :
drivers/gpu/drm/i915/display/intel_cdclk.c:1502:24: error: 
‘CDCLK_SQUASH_WINDOW_SIZE_MASK’ undeclared (first use in this function); did 
you mean ‘ACPI_EBDA_WINDOW_SIZE’?
   size = REG_FIELD_GET(CDCLK_SQUASH_WINDOW_SIZE_MASK, squash_ctl) + 1;
^
././include/linux/compiler_types.h:315:9: note: in definition of macro 
‘__compiletime_assert’
   if (!(condition)) \
 ^
././include/linux/compiler_types.h:335:2: note: in expansion of macro 
‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  ^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^~
./include/linux/bitfield.h:46:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
   BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),  \
   ^~~~
./include/linux/bitfield.h:108:3: note: in expansion of macro ‘__BF_FIELD_CHECK’
   __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
   ^~~~
./drivers/gpu/drm/i915/i915_reg.h:179:44: note: in expansion of macro 
‘FIELD_GET’
 #define REG_FIELD_GET(__mask, __val) ((u32)FIELD_GET(__mask, __val))
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1502:10: note: in expansion of macro 
‘REG_FIELD_GET’
   size = REG_FIELD_GET(CDCLK_SQUASH_WINDOW_SIZE_MASK, squash_ctl) + 1;
  ^
drivers/gpu/drm/i915/display/intel_cdclk.c:1503:28: error: 
‘CDCLK_SQUASH_WAVEFORM_MASK’ undeclared (first use in this function); did you 
mean ‘CDCLK_FREQ_SEL_MASK’?
   waveform = REG_FIELD_GET(CDCLK_SQUASH_WAVEFORM_MASK, squash_ctl) >> (16 - 
size);
^~
././include/linux/compiler_types.h:315:9: note: in definition of macro 
‘__compiletime_assert’
   if (!(condition)) \
 ^
././include/linux/compiler_types.h:335:2: note: in expansion of macro 
‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  ^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^~
./include/linux/bitfield.h:46:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
   BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask),  \
   ^~~~
./include/linux/bitfield.h:108:3: note: in expansion of macro ‘__BF_FIELD_CHECK’
   __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
   ^~~~
./drivers/gpu/drm/i915/i915_reg.h:179:44: note: in expansion of macro 
‘FIELD_GET’
 #define REG_FIELD_GET(__mask, __val) ((u32)FIELD_GET(__mask, __val))
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1503:14: note: in expansion of macro 
‘REG_FIELD_GET’
   waveform = REG_FIELD_GET(CDCLK_SQUASH_WAVEFORM_MASK, squash_ctl) >> (16 - 
size);
  ^
cc1: all warnings being treated as errors
scripts/Makefile.build:287: recipe for target 
'drivers/gpu/drm/i915/display/intel_cdclk.o' failed
make[4]: *** [drivers/gpu/drm/i915/display/intel_cdclk.o] Error 1
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:549: recipe for target 'dr

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display/dg2: Set CD clock squashing registers

[Patchwork]

== Series Details ==

Series: drm/i915/display/dg2: Set CD clock squashing registers
URL   : https://patchwork.freedesktop.org/series/97033/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/display/intel_cdclk.o
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘cdclk_squash_waveform’:
drivers/gpu/drm/i915/display/intel_cdclk.c:1641:19: error: ‘const struct 
intel_cdclk_vals’ has no member named ‘waveform’
return table[i].waveform;
   ^
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘bxt_set_cdclk’:
drivers/gpu/drm/i915/display/intel_cdclk.c:1708:6: error: implicit declaration 
of function ‘has_cdclk_squasher’ [-Werror=implicit-function-declaration]
  if (has_cdclk_squasher(dev_priv)) {
  ^~
cc1: all warnings being treated as errors
scripts/Makefile.build:287: recipe for target 
'drivers/gpu/drm/i915/display/intel_cdclk.o' failed
make[4]: *** [drivers/gpu/drm/i915/display/intel_cdclk.o] Error 1
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:549: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1846: recipe for target 'drivers' failed
make: *** [drivers] Error 2

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/dg2: Sanitize CD clock

[Patchwork]

== Series Details ==

Series: drm/i915/display/dg2: Sanitize CD clock
URL   : https://patchwork.freedesktop.org/series/97032/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21620


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 33)
--

  Additional (1): fi-tgl-1115g4 
  Missing(8): bat-dg1-6 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan fi-snb-2520m 
fi-ctg-p8600 bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][6] -> [INCOMPLETE][7] ([i915#4221])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#1155])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u:   [PASS][10] -> [FAIL][11] ([i915#3239])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#3301])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21620/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [DMESG-FAIL][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
  

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915: Introduce new macros for i915 PTE

[Lucas De Marchi]

On Sat, Nov 13, 2021 at 08:22:20AM -0800, Lucas De Marchi wrote:

On Fri, Nov 12, 2021 at 05:47:27PM -0800, Matt Roper wrote:

On Fri, Nov 12, 2021 at 05:42:28PM -0800, Michael Cheng wrote:

Thanks for the feed back! I feel like using something name GEN6 or BYT for a
platform that's not GEN6 or BYT could be a bit confusing, that's why we
decided to go with something more generic. I do agree I need to cite the
bspec more. Ill wait for more feedback before I send a new revision out.


In general that's the pattern that i915 tries to use --- we name
functions, macros, etc. after the first platform or generation that they
apply to and then continue to use them on all subsequent platforms until
the hardware changes again and we need a new version.  E.g., we're still
calling "gen8_ppgtt_create" to create our PPGTTs on the latest
platforms, even though we're well past gen8 at this point.



I'd be totally ok with it if it was gen8 or gen6, but here the define is
BYT.  But if it's only me who find strange using the BYT_ define, I'm
fine with it.


let's ignore that and go with the GEN6 + BYT defines. Please also Cc
dri-devel since this touches gt/  code.

thanks
Lucas De Marchi

[Intel-gfx] [PATCH 0/3] drm/i915/gt: RPS tuning for light media playback

[Vinay Belgaumkar]

  Switch from tgl to adl, sees one particular media decode pipeline fit
into a single vcs engine on adl, whereas it took two on tgl. However, it
was observed that the power consumtpion for adl remained higher than for
tgl. One contibution is that each engine is treated individually for rps
evaluation, another is that it appears that we prefer to avoid low
frequencies (with no rc6) and use slightly higher frequencies (with lots
of rc6). So let's try tweaking the balancer to smear busy virtual
contexts across multiple engines (trying to make adl look more like
tgl), and tweak the rps evaluation to "race to idle" harder.

Cc: Tvrtko Ursulin 
Cc: Vinay Belgaumkar 
Signed-off-by: Chris Wilson 

Chris Wilson (3):
  drm/i915/gt: Spread virtual engines over idle engines
  drm/i915/gt: Compare average group occupancy for RPS evaluation
  drm/i915/gt: Improve "race-to-idle" at low frequencies

 .../drm/i915/gt/intel_execlists_submission.c  | 80 ---
 drivers/gpu/drm/i915/gt/intel_rps.c   | 79 +-
 2 files changed, 112 insertions(+), 47 deletions(-)

-- 
2.34.0

[Intel-gfx] [PATCH 1/3] drm/i915/gt: Spread virtual engines over idle engines

[Vinay Belgaumkar]

From: Chris Wilson 

Everytime we come to the end of a virtual engine's context, re-randomise
it's siblings[]. As we schedule the siblings' tasklets in the order they
are in the array, earlier entries are executed first (when idle) and so
will be preferred when scheduling the next virtual request. Currently,
we only update the array when switching onto a new idle engine, so we
prefer to stick on the last execute engine, keeping the work compact.
However, it can be beneficial to spread the work out across idle
engines, so choose another sibling as our preferred target at the end of
the context's execution.

Signed-off-by: Chris Wilson 
Cc: Vinay Belgaumkar 
Cc: Tvrtko Ursulin 
---
 .../drm/i915/gt/intel_execlists_submission.c  | 80 ---
 1 file changed, 52 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index ca03880fa7e4..b95bbc8fb91a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -539,6 +539,41 @@ static void execlists_schedule_in(struct i915_request *rq, 
int idx)
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
 }
 
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+   unsigned int n;
+
+   if (likely(engine == ve->siblings[0]))
+   return;
+
+   if (!intel_engine_has_relative_mmio(engine))
+   lrc_update_offsets(&ve->context, engine);
+
+   /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+   for (n = 1; n < ve->num_siblings; n++) {
+   if (ve->siblings[n] == engine) {
+   swap(ve->siblings[n], ve->siblings[0]);
+   break;
+   }
+   }
+}
+
+static int ve_random_sibling(struct virtual_engine *ve)
+{
+   return prandom_u32_max(ve->num_siblings);
+}
+
+static int ve_random_other_sibling(struct virtual_engine *ve)
+{
+   return 1 + prandom_u32_max(ve->num_siblings - 1);
+}
+
 static void
 resubmit_virtual_request(struct i915_request *rq, struct virtual_engine *ve)
 {
@@ -578,8 +613,23 @@ static void kick_siblings(struct i915_request *rq, struct 
intel_context *ce)
rq->execution_mask != engine->mask)
resubmit_virtual_request(rq, ve);
 
-   if (READ_ONCE(ve->request))
+   /*
+* Reschedule with a new "preferred" sibling.
+*
+* The tasklets are executed in the order of ve->siblings[], so
+* siblings[0] receives preferrential treatment of greedily checking
+* for execution of the virtual engine. At this point, the virtual
+* engine is no longer in the current GPU cache due to idleness or
+* contention, so it can be executed on any without penalty. We
+* re-randomise at this point in order to spread light loads across
+* the system, heavy overlapping loads will continue to be greedily
+* executed by the first available engine.
+*/
+   if (READ_ONCE(ve->request)) {
+   virtual_xfer_context(ve,
+ve->siblings[ve_random_other_sibling(ve)]);
tasklet_hi_schedule(&ve->base.sched_engine->tasklet);
+   }
 }
 
 static void __execlists_schedule_out(struct i915_request * const rq,
@@ -1030,32 +1080,6 @@ first_virtual_engine(struct intel_engine_cs *engine)
return NULL;
 }
 
-static void virtual_xfer_context(struct virtual_engine *ve,
-struct intel_engine_cs *engine)
-{
-   unsigned int n;
-
-   if (likely(engine == ve->siblings[0]))
-   return;
-
-   GEM_BUG_ON(READ_ONCE(ve->context.inflight));
-   if (!intel_engine_has_relative_mmio(engine))
-   lrc_update_offsets(&ve->context, engine);
-
-   /*
-* Move the bound engine to the top of the list for
-* future execution. We then kick this tasklet first
-* before checking others, so that we preferentially
-* reuse this set of bound registers.
-*/
-   for (n = 1; n < ve->num_siblings; n++) {
-   if (ve->siblings[n] == engine) {
-   swap(ve->siblings[n], ve->siblings[0]);
-   break;
-   }
-   }
-}
-
 static void defer_request(struct i915_request *rq, struct list_head * const pl)
 {
LIST_HEAD(list);
@@ -3590,7 +3614,7 @@ static void virtual_engine_initial_hint(struct 
virtual_engine *ve)
 * NB This does not force us to execute on this engine, it will just
 * typically be the first we inspect for submission.
 */
-   swp = prandom_u32_max(ve->num_siblings);
+   sw

[Intel-gfx] [PATCH 2/3] drm/i915/gt: Compare average group occupancy for RPS evaluation

[Vinay Belgaumkar]

From: Chris Wilson 

Currently, we inspect each engine individually and measure the occupancy
of that engine over the last evaluation interval. If that exceeds our
busyness thresholds, we decide to increase the GPU frequency. However,
under a load balancer, we should consider the occupancy of entire engine
groups, as work may be spread out across the group. In doing so, we
prefer wide over fast, power consumption is approximately proportional to
the square of the frequency. However, since the load balancer is greedy,
the first idle engine gets all the work, and preferrentially reuses the
last active engine, under light loads all work is assigned to one
engine, and so that engine appears very busy. But if the work happened
to overlap slightly, the workload would spread across multiple engines,
reducing each individual engine's runtime, and so reducing the rps
contribution, keeping the frequency low. Instead, when considering the
contribution, consider the contribution over the entire engine group
(capacity).

Signed-off-by: Chris Wilson 
Cc: Vinay Belgaumkar 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 48 -
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 07ff7ba7b2b7..3675ac93ded0 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -7,6 +7,7 @@
 
 #include "i915_drv.h"
 #include "intel_breadcrumbs.h"
+#include "intel_engine_pm.h"
 #include "intel_gt.h"
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_irq.h"
@@ -65,26 +66,45 @@ static void set(struct intel_uncore *uncore, i915_reg_t 
reg, u32 val)
 static void rps_timer(struct timer_list *t)
 {
struct intel_rps *rps = from_timer(rps, t, timer);
-   struct intel_engine_cs *engine;
-   ktime_t dt, last, timestamp;
-   enum intel_engine_id id;
+   struct intel_gt *gt = rps_to_gt(rps);
+   ktime_t dt, last, timestamp = 0;
s64 max_busy[3] = {};
+   int i, j;
 
-   timestamp = 0;
-   for_each_engine(engine, rps_to_gt(rps), id) {
-   s64 busy;
-   int i;
+   /* Compare average occupancy over each engine group */
+   for (i = 0; i < ARRAY_SIZE(gt->engine_class); i++) {
+   s64 busy = 0;
+   int count = 0;
+
+   for (j = 0; j < ARRAY_SIZE(gt->engine_class[i]); j++) {
+   struct intel_engine_cs *engine;
 
-   dt = intel_engine_get_busy_time(engine, ×tamp);
-   last = engine->stats.rps;
-   engine->stats.rps = dt;
+   engine = gt->engine_class[i][j];
+   if (!engine)
+   continue;
 
-   busy = ktime_to_ns(ktime_sub(dt, last));
-   for (i = 0; i < ARRAY_SIZE(max_busy); i++) {
-   if (busy > max_busy[i])
-   swap(busy, max_busy[i]);
+   dt = intel_engine_get_busy_time(engine, ×tamp);
+   last = engine->stats.rps;
+   engine->stats.rps = dt;
+
+   if (!intel_engine_pm_is_awake(engine))
+   continue;
+
+   busy += ktime_to_ns(ktime_sub(dt, last));
+   count++;
+   }
+
+   if (count > 1)
+   busy = div_u64(busy, count);
+   if (busy <= max_busy[ARRAY_SIZE(max_busy) - 1])
+   continue;
+
+   for (j = 0; j < ARRAY_SIZE(max_busy); j++) {
+   if (busy > max_busy[j])
+   swap(busy, max_busy[j]);
}
}
+
last = rps->pm_timestamp;
rps->pm_timestamp = timestamp;
 
-- 
2.34.0

[Intel-gfx] [PATCH 3/3] drm/i915/gt: Improve "race-to-idle" at low frequencies

[Vinay Belgaumkar]

From: Chris Wilson 

While the power consumption is proportional to the frequency, there is
also a static draw for active gates. The longer we are able to powergate
(rc6), the lower the static draw. Thus there is a sweetspot in the
frequency/power curve where we run at higher frequency in order to sleep
longer, aka race-to-idle. This is more evident at lower frequencies, so
let's look to bump the frequency if we think we will benefit by sleeping
longer at the higher frequency and so conserving power.

Signed-off-by: Chris Wilson 
Cc: Vinay Belgaumkar 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 31 -
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 3675ac93ded0..6af3231982af 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -63,6 +63,22 @@ static void set(struct intel_uncore *uncore, i915_reg_t reg, 
u32 val)
intel_uncore_write_fw(uncore, reg, val);
 }
 
+static bool race_to_idle(struct intel_rps *rps, u64 busy, u64 dt)
+{
+   unsigned int this = rps->cur_freq;
+   unsigned int next = rps->cur_freq + 1;
+   u64 next_dt = next * max(busy, dt);
+
+   /*
+* Compare estimated time spent in rc6 at the next power bin. If
+* we expect to sleep longer than the estimated increased power
+* cost of running at a higher frequency, it will be reduced power
+* consumption overall.
+*/
+   return (((next_dt - this * busy) >> 10) * this * this >
+   ((next_dt - next * busy) >> 10) * next * next);
+}
+
 static void rps_timer(struct timer_list *t)
 {
struct intel_rps *rps = from_timer(rps, t, timer);
@@ -133,7 +149,7 @@ static void rps_timer(struct timer_list *t)
if (!max_busy[i])
break;
 
-   busy += div_u64(max_busy[i], 1 << i);
+   busy += max_busy[i] >> i;
}
GT_TRACE(rps_to_gt(rps),
 "busy:%lld [%d%%], max:[%lld, %lld, %lld], 
interval:%d\n",
@@ -141,13 +157,18 @@ static void rps_timer(struct timer_list *t)
 max_busy[0], max_busy[1], max_busy[2],
 rps->pm_interval);
 
-   if (100 * busy > rps->power.up_threshold * dt &&
-   rps->cur_freq < rps->max_freq_softlimit) {
+   if (rps->cur_freq < rps->max_freq_softlimit &&
+   race_to_idle(rps, max_busy[0], dt)) {
+   rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
+   rps->pm_interval = 1;
+   schedule_work(&rps->work);
+   } else if (rps->cur_freq < rps->max_freq_softlimit &&
+  100 * busy > rps->power.up_threshold * dt) {
rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
rps->pm_interval = 1;
schedule_work(&rps->work);
-   } else if (100 * busy < rps->power.down_threshold * dt &&
-  rps->cur_freq > rps->min_freq_softlimit) {
+   } else if (rps->cur_freq > rps->min_freq_softlimit &&
+  100 * busy < rps->power.down_threshold * dt) {
rps->pm_iir |= GEN6_PM_RP_DOWN_THRESHOLD;
rps->pm_interval = 1;
schedule_work(&rps->work);
-- 
2.34.0

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Navare, Manasi]

On Wed, Nov 17, 2021 at 11:04:05PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> > On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Let's adjust the vblank evasion to account for the case where
> > > a push has already been sent. In that case the vblank exit will start
> > > at vmin vblank start (as opposed to vmax vblank start when no push
> > > has been sent).
> > > 
> > > This should minimize the effects of the tiny race between sampling
> > > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > > This will also be required if we want to do mailbox style updates with
> > > vrr since then we'd definitely do multiple commits per frame. Currently
> > > mailbox updates are only used by the legacy cursor, but we don't do
> > > vrr push for those.
> > > 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++---
> > >  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 
> > >  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
> > >  3 files changed, 20 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index cf403be7736c..eb5444f90e77 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct 
> > > intel_crtc_state *new_crtc_state)
> > >   if (intel_crtc_needs_vblank_work(new_crtc_state))
> > >   intel_crtc_vblank_work_init(new_crtc_state);
> > >  
> > > - if (new_crtc_state->vrr.enable)
> > > - vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > - else
> > > + if (new_crtc_state->vrr.enable) {
> > > + if (intel_vrr_is_push_sent(new_crtc_state))
> > > + vblank_start = 
> > > intel_vrr_vmin_vblank_start(new_crtc_state);
> > 
> > Actually if Push is sent then the vblank gets terminated at that point 
> > which falls between vmin and vmax so
> > not necessarily at Vmin but at anytime between vmin and vmax. Is it correct 
> > to calculate it based on vmin?
> 
> If you do a push between vmin and vmax then the vblank terminates
> immediately and the PUSH_SEND bit gets cleared. The only way the bit
> stays set is you set it after vmax/before vmin.
>

The scenario where PUSH comes in during the active so that its before Vmin, 
then it will stay on until we hit vmin to
terminate the vblank.
But when we reach Vmax, the HW will terminate the vblank anyways, should we 
actually alter the code to not
allow any PUSH after Vmax?

Manasi
 
> > 
> > > + else
> > > + vblank_start = 
> > > intel_vrr_vmax_vblank_start(new_crtc_state);
> > > + } else {
> > >   vblank_start = intel_mode_vblank_start(adjusted_mode);
> > > + }
> > >  
> > >   /* FIXME needs to be calibrated sensibly */
> > >   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> > > b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > index c335b1dbafcf..db1c3902fc2d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct 
> > > intel_crtc_state *crtc_state)
> > >  TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > >  }
> > >  
> > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > +
> > > + if (!crtc_state->vrr.enable)
> > > + return false;
> > > +
> > > + return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & 
> > > TRANS_PUSH_SEND;
> > 
> > But HW clears this bit after double buffer update. Is this a good 
> > inidcation to check the PUSH_SEND bit?
> > 
> > Manasi
> > 
> > > +}
> > > +
> > >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> > >  {
> > >   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h 
> > > b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > index 96f9c9c27ab9..1c2da572693d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state 
> > > *crtc_state,
> > >  void intel_vrr_enable(struct intel_encoder *encoder,
> > > const struct intel_crtc_state *crtc_state);
> > >  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> > >  void intel_vrr_disable(cons

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/rpm: Enable runtime pm autosuspend by default (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/rpm: Enable runtime pm autosuspend by default (rev4)
URL   : https://patchwork.freedesktop.org/series/96741/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21622


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 34)
--

  Additional (1): fi-tgl-1115g4 
  Missing(7): bat-dg1-6 fi-tgl-u2 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][2] -> [FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][9] -> [INCOMPLETE][10] ([i915#2940])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][11] -> [INCOMPLETE][12] ([i915#4433])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#4103]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][17] ([i915#3301])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21622/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][18] ([i915#3363] / [i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Move vrr push after the frame counter sampling again

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Move vrr push after the frame 
counter sampling again
URL   : https://patchwork.freedesktop.org/series/97037/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21623


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 34)
--

  Additional (1): fi-tgl-1115g4 
  Missing(7): bat-dg1-6 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 
bat-jsl-2 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [PASS][9] -> [DMESG-FAIL][10] ([i915#541])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [DMESG-WARN][16] -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [DMESG-FAIL][18] -> [PASS][19]
   [18]: 
https://

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: RPS tuning for light media playback

[Patchwork]

== Series Details ==

Series: drm/i915/gt: RPS tuning for light media playback
URL   : https://patchwork.freedesktop.org/series/97043/
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/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: RPS tuning for light media playback

[Patchwork]

== Series Details ==

Series: drm/i915/gt: RPS tuning for light media playback
URL   : https://patchwork.freedesktop.org/series/97043/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10897 -> Patchwork_21624


Summary
---

  **FAILURE**

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

Participating hosts (39 -> 35)
--

  Additional (1): fi-tgl-u2 
  Missing(5): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_lmem_swapping@verify-random:
- fi-tgl-u2:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-tgl-u2/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2:  NOTRUN -> [SKIP][6] ([i915#4103]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

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

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

  * igt@runner@aborted:
- fi-skl-6600u:   NOTRUN -> [FAIL][9] ([i915#2722] / [i915#3363] / 
[i915#4312])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-skl-6600u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][12] ([i915#541]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21624/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

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

  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Build changes
-

  * Linux: CI_DRM_10897 -> Patchwork_21624

  CI-20190529: 20190529
  CI_DRM_10897: 6afd200919ae894c775326ea99e607e5a8adf51b @ 
git://anongit.freed

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Tile 4 plane format support (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Tile 4 plane format support (rev3)
URL   : https://patchwork.freedesktop.org/series/95715/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10893_full -> Patchwork_21614_full


Summary
---

  **FAILURE**

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

  

Participating hosts (11 -> 11)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_persistence@many-contexts:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-iclb7/igt@gem_ctx_persiste...@many-contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-iclb6/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_lmem_swapping@random:
- shard-iclb: NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-iclb5/igt@gem_lmem_swapp...@random.html

  * igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-tglb7/igt@kms_cursor_edge_w...@pipe-a-128x128-right-edge.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-tglb7/igt@kms_cursor_edge_w...@pipe-a-128x128-right-edge.html

  * igt@kms_plane@pixel-format-source-clamping@pipe-a-planes:
- shard-tglb: [PASS][6] -> [FAIL][7] +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-tglb7/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-tglb5/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html

  
 Suppressed 

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

  * igt@gem_lmem_swapping@parallel-random-verify:
- {shard-rkl}:NOTRUN -> [SKIP][8] +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-rkl-1/igt@gem_lmem_swapp...@parallel-random-verify.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#3002])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-tglb3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +5 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#2369] / 
[i915#3063] / [i915#3648])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-tglb6/igt@gem_...@unwedge-stress.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-tglb6/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][14] -> [TIMEOUT][15] ([i915#2369] / 
[i915#2481] / [i915#3070])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-iclb6/igt@gem_...@unwedge-stress.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-iclb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#4525])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-tglb3/igt@gem_exec_balan...@parallel-keep-in-fence.html

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

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2846])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10893/shard-glk3/igt@gem_exec_f...@basic-deadline.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21614/shard-glk7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][20] -> [SKIP][21] ([fdo#109271])
   [20]: 
https://intel-gfx-ci.0

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Hold RPM wakelock during PXP suspend (rev3)

[Surendrakumar Upadhyay, TejaskumarX]

Hi Daniele,

Would you please ack and merge the patch if it looks good? 
https://patchwork.freedesktop.org/series/96658/#rev3

Thanks,
Tejas


From: Patchwork 
Sent: 17 November 2021 15:07
To: Surendrakumar Upadhyay, TejaskumarX 

Cc: intel-gfx@lists.freedesktop.org
Subject: ✓ Fi.CI.IGT: success for drm/i915/gt: Hold RPM wakelock during PXP 
suspend (rev3)

Patch Details
Series:
drm/i915/gt: Hold RPM wakelock during PXP suspend (rev3)
URL:
https://patchwork.freedesktop.org/series/96658/
State:
success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21610/index.html
CI Bug Log - changes from CI_DRM_10888_full -> Patchwork_21610_full
Summary

SUCCESS

No regressions found.

Participating hosts (11 -> 10)

Missing (1): shard-rkl

Known issues

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

IGT changes
Issues hit

  *   igt@gem_eio@in-flight-contexts-immediate:

 *   shard-apl: 
PASS
 -> 
TIMEOUT
 ([i915#3063])

  *   igt@gem_exec_capture@pi@bcs0:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
 ([i915#2369] / [i915#3371] / [i915#3731])

  *   igt@gem_exec_capture@pi@vcs0:

 *   shard-skl: NOTRUN -> 
INCOMPLETE
 ([i915#2369])

  *   igt@gem_exec_fair@basic-flow@rcs0:

 *   shard-skl: NOTRUN -> 
SKIP
 ([fdo#109271]) +30 similar issues

  *   igt@gem_exec_fair@basic-none-rrul@rcs0:

 *   shard-iclb: 
PASS
 -> 
FAIL
 ([i915#2852])

  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-tglb: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@vcs0:

 *   shard-iclb: NOTRUN -> 
FAIL
 ([i915#2842]) +3 similar issues

  *   igt@gem_exec_fair@basic-pace@vecs0:

 *   shard-kbl: 
PASS
 -> 
SKIP
 ([fdo#109271])

  *   igt@gem_exec_suspend@basic-s0:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE
 ([i915#456])

  *   igt@gem_huc_copy@huc-copy:

 *   shard-tglb: 
PASS
 -> 
SKIP
 ([i915#2190])
 *   shard-kbl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#2190])

  *   igt@gem_media_vme:

 *   shard-tglb: NOTRUN -> 
SKIP
 ([i915#284])

  *   igt@gem_pwrite@basic-exhaustion:

 *   shard-kbl: NOTRUN -> 
WARN
 ([i915#2658])

  *   igt@gem_pxp@verify-pxp-stale-ctx-execution:

 *   shard-tglb: NOTRUN -> 
SKIP
 ([i915#4270]) +1 similar issue

  *   igt@gem_userptr_blits@dmabuf-unsync:

 *   shard-iclb: NOTRUN -> 
SKIP
 ([i915#3297])

  *   igt@gem_userptr_blits@input-checking:

 *   shard-skl: NOTRUN -> 
DMESG-WARN
 ([i915#3002])

  *   igt@gem_workarounds@suspend-resume-context:

 *   shard-apl: 
PA

[Intel-gfx] [PATCH] drm/i915: Reject 5k on HDR planes for planar fb formats

[Vidya Srinivas]

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Reject 5k on HDR plane for planar formats like NV12
to let the user space know about it.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out. Issue is seen on both TGL and ADL platforms.

Signed-off-by: Vidya Srinivas 
Signed-off-by: Yashashvi Shantam 
---
 drivers/gpu/drm/i915/display/skl_scaler.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c 
b/drivers/gpu/drm/i915/display/skl_scaler.c
index 37eabeff8197..e2e52f5dca3b 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -86,6 +86,7 @@ static u16 skl_scaler_calc_phase(int sub, int scale, bool 
chroma_cosited)
 #define ICL_MAX_DST_H 4096
 #define SKL_MIN_YUV_420_SRC_W 16
 #define SKL_MIN_YUV_420_SRC_H 16
+#define MAX_CUSCTL_W 4096
 
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
@@ -221,6 +222,14 @@ int skl_update_scaler_plane(struct intel_crtc_state 
*crtc_state,
bool force_detach = !fb || !plane_state->uapi.visible;
bool need_scaler = false;
 
+   /* PLANE_CUS_CTL size max 4096 */
+   if (icl_is_hdr_plane(dev_priv, intel_plane->id) &&
+   fb && intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) 
&&
+   (drm_rect_width(&plane_state->uapi.src) >> 16) > MAX_CUSCTL_W) {
+   DRM_ERROR("HDR chroma upsampler size exceeds limits\n");
+   return -EINVAL;
+   }
+
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
fb && intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
-- 
2.33.0

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move the pre_pin earlier

[Thomas Hellström]

On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote:
> 
> On 11/17/21 15:20, Matthew Auld wrote:
> > In intel_context_do_pin_ww, when calling into the pre_pin
> > hook(which is
> > passed the ww context) it could in theory return -EDEADLK(which is
> > very
> > likely with debug kernels), once we start adding more ww locking in
> > there,
> > like in the next patch. If so then we need to be mindful of having
> > to
> > restart the do_pin at this point.
> > 
> > If this is the kernel_context, or some other early in-kernel
> > context
> > where we have yet to setup the default_state, then we always
> > inhibit the
> > context restore, and instead rely on the delayed active_release to
> > set
> > the CONTEXT_VALID_BIT for us(if we even care), which should
> > indicate
> > that we have context switched away, and that our newly saved
> > context
> > state should now be valid. However, since we currently grab the
> > active
> > reference before the potential ww dance, we can end up setting the
> > CONTEXT_VALID_BIT much too early, if we need to backoff, and then
> > upon
> > re-trying the do_pin, we could potentially cause the hardware to
> > incorrectly load some garbage context state when later context
> > switching
> > to that context, but at the very least this will trigger the
> > GEM_BUG_ON() in __engine_unpark. For now let's just move any ww
> > dance
> > stuff prior to arming the active reference.
> > 
> > For normal user contexts this shouldn't be a concern, since we
> > should
> > already have the default_state ready when initialising the lrc
> > state,
> > and so there should be no concern with active_release somehow
> > prematurely setting the CONTEXT_VALID_BIT.
> > 
> > v2(Thomas):
> >    - Also re-order the union unwind

Oh should this be 

s/union/onion/ ?


> > 
> > Signed-off-by: Matthew Auld 
> > Cc: Thomas Hellström 
> > Cc: Maarten Lankhorst 
> 
> Reviewed-by: Thomas Hellström 
> 
> 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_context.c | 12 ++--
> >   1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 5634d14052bc..4c296de1d67d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct
> > intel_context *ce,
> > if (err)
> > return err;
> >   
> > -   err = i915_active_acquire(&ce->active);
> > +   err = ce->ops->pre_pin(ce, ww, &vaddr);
> > if (err)
> > goto err_ctx_unpin;
> >   
> > -   err = ce->ops->pre_pin(ce, ww, &vaddr);
> > +   err = i915_active_acquire(&ce->active);
> > if (err)
> > -   goto err_release;
> > +   goto err_post_unpin;
> >   
> > err = mutex_lock_interruptible(&ce->pin_mutex);
> > if (err)
> > -   goto err_post_unpin;
> > +   goto err_release;
> >   
> > intel_engine_pm_might_get(ce->engine);
> >   
> > @@ -273,11 +273,11 @@ int __intel_context_do_pin_ww(struct
> > intel_context *ce,
> >   
> >   err_unlock:
> > mutex_unlock(&ce->pin_mutex);
> > +err_release:
> > +   i915_active_release(&ce->active);
> >   err_post_unpin:
> > if (!handoff)
> > ce->ops->post_unpin(ce);
> > -err_release:
> > -   i915_active_release(&ce->active);
> >   err_ctx_unpin:
> > intel_context_post_unpin(ce);
> >   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject 5k on HDR planes for planar fb formats

[Patchwork]

== Series Details ==

Series: drm/i915: Reject 5k on HDR planes for planar fb formats
URL   : https://patchwork.freedesktop.org/series/97053/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10897 -> Patchwork_21625


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 31)
--

  Missing(8): fi-kbl-soraka bat-dg1-6 fi-hsw-4200u fi-skl-guc fi-icl-u2 
fi-bsw-cyan fi-ctg-p8600 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21625/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

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

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

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u:   [FAIL][5] ([i915#3239]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21625/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}:   [DMESG-FAIL][7] ([i915#541]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21625/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][9] ([i915#3921]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10897/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21625/fi-snb-2600/igt@i915_selftest@l...@hangcheck.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
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3239]: https://gitlab.freedesktop.org/drm/intel/issues/3239
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4290]: https://gitlab.freedesktop.org/drm/intel/issues/4290
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Build changes
-

  * Linux: CI_DRM_10897 -> Patchwork_21625

  CI-20190529: 20190529
  CI_DRM_10897: 6afd200919ae894c775326ea99e607e5a8adf51b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6284: 2971051d07d02da90c20ccb842e76ee711b02ecb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21625: 1115e33cd27836f37a8840e9fe9940310466e059 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1115e33cd278 drm/i915: Reject 5k on HDR planes for planar fb formats

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/ttm: Implement asynchronous TTM moves

[Thomas Hellström]

Hi, Matthew

Finally got some time to look at this more in-depth, please see below.

On Mon, 2021-11-15 at 17:16 +, Matthew Auld wrote:
> On 14/11/2021 11:12, Thomas Hellström wrote:
> > Don't wait sync while migrating, but rather make the GPU blit await
> > the
> > dependencies and add a moving fence to the object.
> > 
> > This also enables asynchronous VRAM management in that on eviction,
> > rather than waiting for the moving fence to expire before freeing
> > VRAM,
> > it is freed immediately and the fence is stored with the VRAM
> > manager and
> > handed out to newly allocated objects to await before clears and
> > swapins,
> > or for kernel objects before setting up gpu vmas or mapping.
> > 
> > To collect dependencies before migrating, add a set of utilities
> > that
> > coalesce these to a single dma_fence.
> > 
> > What is still missing for fully asynchronous operation is
> > asynchronous vma
> > unbinding, which is still to be implemented.
> > 
> > This commit substantially reduces execution time in the
> > gem_lmem_swapping
> > test.
> > 
> > v2:
> > - Make a couple of functions static.
> > 
> > Signed-off-by: Thomas Hellström 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  10 +
> >   drivers/gpu/drm/i915/gem/i915_gem_ttm.h  |   2 +-
> >   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 329
> > +--
> >   drivers/gpu/drm/i915/gem/i915_gem_wait.c |   4 +-
> >   4 files changed, 318 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index a1df49378a0f..111a4282d779 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -326,6 +326,9 @@ static bool i915_ttm_eviction_valuable(struct
> > ttm_buffer_object *bo,
> >   {
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> >   
> > +   if (!obj)
> > +   return false;
> > +
> > /*
> >  * EXTERNAL objects should never be swapped out by TTM,
> > instead we need
> >  * to handle that ourselves. TTM will already skip such
> > objects for us,
> > @@ -448,6 +451,10 @@ static int
> > i915_ttm_shrinker_release_pages(struct drm_i915_gem_object *obj,
> > if (bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED)
> > return 0;
> >   
> > +   ret = ttm_bo_wait_ctx(bo, &ctx);
> > +   if (ret)
> > +   return ret;
> 
> 
> Why do we need this? Also not needed for the above purge case?

This is for bos with an on-going async move to system. The
intel_migrate code doesn't set up vmas, so unbinding doesn't
necessarily idle. The purge code currently idles in TTM, but in both
cases we should probably add another argument to
shrinker_release_pages() and move this wait before purge to return -
EBUSY unless we have SHRINK_ACTIVE.

> 
> > +
> > bo->ttm->page_flags |= TTM_TT_FLAG_SWAPPED;
> > ret = ttm_bo_validate(bo, &place, &ctx);
> > if (ret) {
> > @@ -549,6 +556,9 @@ static void i915_ttm_swap_notify(struct
> > ttm_buffer_object *bo)
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > int ret = i915_ttm_move_notify(bo);
> >   
> > +   if (!obj)
> > +   return;
> 
> It looks like the i915_ttm_move_notify(bo) already dereferenced the
> GEM 
> bo. Or did something in there maybe nuke it?
> 
> > +
> > GEM_WARN_ON(ret);
> > GEM_WARN_ON(obj->ttm.cached_io_rsgt);
> > if (!ret && obj->mm.madv != I915_MADV_WILLNEED)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > index 82cdabb542be..9d698ad00853 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > @@ -37,7 +37,7 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object
> > *bo);
> >   static inline struct drm_i915_gem_object *
> >   i915_ttm_to_gem(struct ttm_buffer_object *bo)
> >   {
> > -   if (GEM_WARN_ON(bo->destroy != i915_ttm_bo_destroy))
> > +   if (bo->destroy != i915_ttm_bo_destroy)
> > return NULL;
> 
> So this would indicate a "ghost" object, or is this something else?
> How 
> scared should we be with this, like with the above checking for NULL
> GEM 
> object state? In general do you know where we need the above
> checking?

Yeah, these are ghost objects and this is a major flaw in TTM in that
some callbacks are per device and not per object. Should have been
fixed long ago :/. For the ttm_tt callbacks, obj might be NULL but we
must still be able to cope with that. For other callbacks we should
ignore the ghost objects. I'll do a second audit here.

> 
> >   
> > return container_of(bo, struct drm_i915_gem_object,
> > __do_not_access);
> > 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 f35b386c56ca..ae2c49fc3500 100644
> > --- a/drivers/gpu/drm

[Intel-gfx] [PULL] drm-misc-fixes

[Maxime Ripard]

Hi Daniel, Dave,

Here's this week drm-misc-fixes PR

Maxime

drm-misc-fixes-2021-11-18:
A infoframe corruption fix for nouveau, a wrong free function usage fix
for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for
drm/scheduler refcounting and a probing fix for efifb.
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:

  Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-11-18

for you to fetch changes up to fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee:

  fbdev: Prevent probing generic drivers if a FB is already registered 
(2021-11-17 10:15:05 +0100)


A infoframe corruption fix for nouveau, a wrong free function usage fix
for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for
drm/scheduler refcounting and a probing fix for efifb.


Christian König (1):
  drm/scheduler: fix drm_sched_job_add_implicit_dependencies

Hans Verkuil (1):
  drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrame

Javier Martinez Canillas (1):
  fbdev: Prevent probing generic drivers if a FB is already registered

Julian Braha (1):
  drm/sun4i: fix unmet dependency on RESET_CONTROLLER for 
PHY_SUN6I_MIPI_DPHY

Maxime Ripard (1):
  Merge drm/drm-fixes into drm-misc-fixes

Rob Clark (1):
  drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder

Thomas Zimmermann (1):
  drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()

 drivers/gpu/drm/drm_gem_cma_helper.c |  9 +++--
 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c |  1 -
 drivers/gpu/drm/scheduler/sched_main.c   |  6 +-
 drivers/gpu/drm/sun4i/Kconfig|  1 +
 drivers/video/fbdev/efifb.c  | 11 +++
 drivers/video/fbdev/simplefb.c   | 11 +++
 6 files changed, 35 insertions(+), 4 deletions(-)


signature.asc
Description: PGP signature