[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/ttm: Async migration (rev11)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Async migration (rev11)
URL   : https://patchwork.freedesktop.org/series/96798/
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.IGT: failure for Enable pipe color support on D13 platform

[Patchwork]

== Series Details ==

Series: Enable pipe color support on D13 platform
URL   : https://patchwork.freedesktop.org/series/97219/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10919_full -> Patchwork_21670_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-kbl4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-kbl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_eio@unwedge-stress:
- shard-tglb: NOTRUN -> [TIMEOUT][4] ([i915#3063] / [i915#3648])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-tglb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#4525]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-tglb2/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-apl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-apl4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-glk9/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_lmem_swapping@parallel-multi:
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-kbl4/igt@gem_lmem_swapp...@parallel-multi.html

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

  * igt@gem_lmem_swapping@verify:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/shard-tglb6/igt@gem_lmem_swapp...@verify.html

  * 

[Intel-gfx] linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel-gt tree got a conflict in:

  drivers/gpu/drm/i915/i915_pci.c

between commit:

  3c542cfa8266 ("drm/i915/dg2: Tile 4 plane format support")

from the drm-intel tree and commit:

  a5b7ef27da60 ("drm/i915: Add struct to hold IP version")

from the drm-intel-gt tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_pci.c
index 69b8029da6b6,5e6795853dc3..
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@@ -1042,9 -1030,8 +1042,9 @@@ static const struct intel_device_info d
XE_HPM_FEATURES,
XE_LPD_FEATURES,
DGFX_FEATURES,
-   .graphics_rel = 55,
-   .media_rel = 55,
+   .graphics.rel = 55,
+   .media.rel = 55,
 +  .has_4tile = 1,
PLATFORM(INTEL_DG2),
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |


pgpnur9XDp7LF.pgp
Description: OpenPGP digital signature

[Intel-gfx] ✗ Fi.CI.BUILD: failure for sysctl: second set of kernel/sysctl cleanups

[Patchwork]

== Series Details ==

Series: sysctl: second set of kernel/sysctl cleanups
URL   : https://patchwork.freedesktop.org/series/97221/
State : failure

== Summary ==

Applying: hpet: simplify subdirectory registration with register_sysctl()
Applying: i915: simplify subdirectory registration with register_sysctl()
Applying: macintosh/mac_hid.c: simplify subdirectory registration with 
register_sysctl()
Applying: ocfs2: simplify subdirectory registration with register_sysctl()
Applying: test_sysctl: simplify subdirectory registration with register_sysctl()
Applying: inotify: simplify subdirectory registration with register_sysctl()
error: sha1 information is lacking or useless (kernel/sysctl.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0006 inotify: simplify subdirectory registration with 
register_sysctl()
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [RFC 3/7] drm/i915/guc: Populate XE_LP register lists for GuC error state capture.

[Michal Wajdeczko]

On 23.11.2021 00:03, Alan Previn wrote:
> Add device specific tables and register lists to cover different engines
> class types for GuC error state capture.
> 
> Also, add runtime allocation and freeing of extended register lists
> for registers that need steering identifiers that depend on
> the detected HW config.
> 
> Signed-off-by: Alan Previn 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 260 +-
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|   2 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   2 +
>  3 files changed, 197 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index c741c77b7fc8..eec1d193ac26 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -9,120 +9,245 @@
>  #include "i915_drv.h"
>  #include "i915_memcpy.h"
>  #include "gt/intel_gt.h"
> +#include "gt/intel_lrc_reg.h"
>  
>  #include "intel_guc_fwif.h"
>  #include "intel_guc_capture.h"
>  
> -/* Define all device tables of GuC error capture register lists */
> +/*
> + * Define all device tables of GuC error capture register lists
> + * NOTE: For engine-registers, GuC only needs the register offsets
> + *   from the engine-mmio-base
> + */
> +#define COMMON_GEN12BASE_GLOBAL() \
> + {GEN12_FAULT_TLB_DATA0,0,  0, "GEN12_FAULT_TLB_DATA0"}, \
> + {GEN12_FAULT_TLB_DATA1,0,  0, "GEN12_FAULT_TLB_DATA1"}, \
> + {FORCEWAKE_MT, 0,  0, "FORCEWAKE_MT"}, \
> + {DERRMR,   0,  0, "DERRMR"}, \
> + {GEN12_AUX_ERR_DBG,0,  0, "GEN12_AUX_ERR_DBG"}, \
> + {GEN12_GAM_DONE,   0,  0, "GEN12_GAM_DONE"}, \
> + {GEN11_GUC_SG_INTR_ENABLE, 0,  0, "GEN11_GUC_SG_INTR_ENABLE"}, \
> + {GEN11_CRYPTO_RSVD_INTR_ENABLE, 0, 0, "GEN11_CRYPTO_RSVD_INTR_ENABLE"}, 
> \
> + {GEN11_GUNIT_CSME_INTR_ENABLE, 0,  0, "GEN11_GUNIT_CSME_INTR_ENABLE"}, \
> + {GEN12_RING_FAULT_REG, 0,  0, "GEN12_RING_FAULT_REG"}
> +
> +#define COMMON_GEN12BASE_ENGINE_INSTANCE() \
> + {RING_PSMI_CTL(0), 0,  0, "RING_PSMI_CTL"}, \
> + {RING_ESR(0),  0,  0, "RING_ESR"}, \
> + {RING_ESR(0),  0,  0, "RING_ESR"}, \
> + {RING_DMA_FADD(0), 0,  0, "RING_DMA_FADD_LOW32"}, \
> + {RING_DMA_FADD_UDW(0), 0,  0, "RING_DMA_FADD_UP32"}, \
> + {RING_IPEIR(0),0,  0, "RING_IPEIR"}, \
> + {RING_IPEHR(0),0,  0, "RING_IPEHR"}, \
> + {RING_INSTPS(0),   0,  0, "RING_INSTPS"}, \
> + {RING_BBADDR(0),   0,  0, "RING_BBADDR_LOW32"}, \
> + {RING_BBADDR_UDW(0),   0,  0, "RING_BBADDR_UP32"}, \
> + {RING_BBSTATE(0),  0,  0, "RING_BBSTATE"}, \
> + {CCID(0),  0,  0, "CCID"}, \
> + {RING_ACTHD(0),0,  0, "RING_ACTHD_LOW32"}, \
> + {RING_ACTHD_UDW(0),0,  0, "RING_ACTHD_UP32"}, \
> + {RING_INSTPM(0),   0,  0, "RING_INSTPM"}, \
> + {RING_NOPID(0),0,  0, "RING_NOPID"}, \
> + {RING_START(0),0,  0, "RING_START"}, \
> + {RING_HEAD(0), 0,  0, "RING_HEAD"}, \
> + {RING_TAIL(0), 0,  0, "RING_TAIL"}, \
> + {RING_CTL(0),  0,  0, "RING_CTL"}, \
> + {RING_MI_MODE(0),  0,  0, "RING_MI_MODE"}, \
> + {RING_CONTEXT_CONTROL(0),  0,  0, "RING_CONTEXT_CONTROL"}, \
> + {RING_INSTDONE(0), 0,  0, "RING_INSTDONE"}, \
> + {RING_HWS_PGA(0),  0,  0, "RING_HWS_PGA"}, \
> + {RING_MODE_GEN7(0),0,  0, "RING_MODE_GEN7"}, \
> + {GEN8_RING_PDP_LDW(0, 0),  0,  0, "GEN8_RING_PDP0_LDW"}, \
> + {GEN8_RING_PDP_UDW(0, 0),  0,  0, "GEN8_RING_PDP0_UDW"}, \
> + {GEN8_RING_PDP_LDW(0, 1),  0,  0, "GEN8_RING_PDP1_LDW"}, \
> + {GEN8_RING_PDP_UDW(0, 1),  0,  0, "GEN8_RING_PDP1_UDW"}, \
> + {GEN8_RING_PDP_LDW(0, 2),  0,  0, "GEN8_RING_PDP2_LDW"}, \
> + {GEN8_RING_PDP_UDW(0, 2),  0,  0, "GEN8_RING_PDP2_UDW"}, \
> + {GEN8_RING_PDP_LDW(0, 3),  0,  0, "GEN8_RING_PDP3_LDW"}, \
> + {GEN8_RING_PDP_UDW(0, 3),  0,  0, "GEN8_RING_PDP3_UDW"}
> +
> +#define COMMON_GEN12BASE_HAS_EU() \
> + {EIR,  0,  0, "EIR"}
> +
> +#define COMMON_GEN12BASE_RENDER() \
> + {GEN7_SC_INSTDONE, 0,  0, "GEN7_SC_INSTDONE"}, \
> + {GEN12_SC_INSTDONE_EXTRA,  0,  0, "GEN12_SC_INSTDONE_EXTRA"}, \
> + {GEN12_SC_INSTDONE_EXTRA2, 0,  0, "GEN12_SC_INSTDONE_EXTRA2"}
> +
> +#define COMMON_GEN12BASE_VEC() \
> + {GEN11_VCS_VECS_INTR_ENABLE, 0,0, "GEN11_VCS_VECS_INTR_ENABLE"}, \
> + {GEN12_SFC_DONE(0),0,  0, "GEN12_SFC_DONE0"}, \
> + {GEN12_SFC_DONE(1),0,  0, "GEN12_SFC_DONE1"}, \
> + {GEN12_SFC_DONE(2),0,  

Re: [Intel-gfx] [RFC 2/7] drm/i915/guc: Update GuC ADS size for error capture lists

[Michal Wajdeczko]

Hi,

just few random nits below

-Michal


On 23.11.2021 00:03, Alan Previn wrote:
> Update GuC ADS size allocation to include space for
> the lists of error state capture register descriptors.
> 
> Also, populate the lists of registers we want GuC to report back to
> Host on engine reset events. This list should include global,
> engine-class and engine-instance registers for every engine-class
> type on the current hardware.
> 
> NOTE: Start with a fake table of register lists to layout the
> framework before adding real registers in subsequent patch.
> 
> Signed-off-by: Alan Previn 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  10 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc.h|   5 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 176 -
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 232 ++
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|  47 
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  19 +-
>  7 files changed, 476 insertions(+), 14 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
>  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 074d6b8edd23..e3c4d5cea4c3 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -190,6 +190,7 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_guc_rc.o \
> gt/uc/intel_guc_slpc.o \
> gt/uc/intel_guc_submission.o \
> +   gt/uc/intel_guc_capture.o \

use alphabetical order

> gt/uc/intel_huc.o \
> gt/uc/intel_huc_debugfs.o \
> gt/uc/intel_huc_fw.o
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 5cf9ebd2ee55..458f0d248a5a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -335,9 +335,14 @@ int intel_guc_init(struct intel_guc *guc)
>   if (ret)
>   goto err_fw;
>  
> - ret = intel_guc_ads_create(guc);
> + ret = intel_guc_capture_init(guc);
>   if (ret)
>   goto err_log;
> +
> + ret = intel_guc_ads_create(guc);
> + if (ret)
> + goto err_capture;
> +
>   GEM_BUG_ON(!guc->ads_vma);
>  
>   ret = intel_guc_ct_init(>ct);
> @@ -376,6 +381,8 @@ int intel_guc_init(struct intel_guc *guc)
>   intel_guc_ct_fini(>ct);
>  err_ads:
>   intel_guc_ads_destroy(guc);
> +err_capture:
> + intel_guc_capture_destroy(guc);
>  err_log:
>   intel_guc_log_destroy(>log);
>  err_fw:
> @@ -403,6 +410,7 @@ void intel_guc_fini(struct intel_guc *guc)
>   intel_guc_ct_fini(>ct);
>  
>   intel_guc_ads_destroy(guc);
> + intel_guc_capture_destroy(guc);
>   intel_guc_log_destroy(>log);
>   intel_uc_fw_fini(>fw);
>  }
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 9de99772f916..d136c69abe12 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -16,6 +16,7 @@
>  #include "intel_guc_log.h"
>  #include "intel_guc_reg.h"
>  #include "intel_guc_slpc_types.h"
> +#include "intel_guc_capture.h"

use alphabetical order

>  #include "intel_uc_fw.h"
>  #include "i915_utils.h"
>  #include "i915_vma.h"
> @@ -37,6 +38,8 @@ struct intel_guc {
>   struct intel_guc_ct ct;
>   /** @slpc: sub-structure containing SLPC related data and objects */
>   struct intel_guc_slpc slpc;
> + /** @capture: the error-state-capture module's data and objects */
> + struct intel_guc_state_capture capture;
>  
>   /** @sched_engine: Global engine used to submit requests to GuC */
>   struct i915_sched_engine *sched_engine;
> @@ -138,6 +141,8 @@ struct intel_guc {
>   u32 ads_regset_size;
>   /** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
>   u32 ads_golden_ctxt_size;
> + /** @ads_capture_size: size of register lists in the ADS used for error 
> capture */
> + u32 ads_capture_size;
>   /** @ads_engine_usage_size: size of engine usage in the ADS */
>   u32 ads_engine_usage_size;
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 6c81ddd303d3..2780c0fadd01 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -10,6 +10,7 @@
>  #include "gt/shmem_utils.h"
>  #include "intel_guc_ads.h"
>  #include "intel_guc_fwif.h"
> +#include "intel_guc_capture.h"

wrong order

>  #include "intel_uc.h"
>  #include "i915_drv.h"
>  
> @@ -71,8 +72,7 @@ static u32 guc_ads_golden_ctxt_size(struct intel_guc *guc)
>  
>  static u32 guc_ads_capture_size(struct intel_guc *guc)
>  {
> - /* Basic support to init ADS without a proper GuC error capture list */
> - return PAGE_ALIGN(PAGE_SIZE);
> + return 

Re: [Intel-gfx] [PATCH V4] drm/i915/gt: Hold RPM wakelock during PXP suspend

[Daniele Ceraolo Spurio]

On 11/22/2021 8:56 AM, Daniele Ceraolo Spurio wrote:



On 11/18/2021 11:35 AM, Daniele Ceraolo Spurio wrote:



On 11/16/2021 10:03 PM, Tejas Upadhyay wrote:

selftest --r live shows failure in suspend tests when
RPM wakelock is not acquired during suspend.

This changes addresses below error :
<4> [154.177535] RPM wakelock ref not held during HW access
<4> [154.177575] WARNING: CPU: 4 PID: 5772 at
drivers/gpu/drm/i915/intel_runtime_pm.h:113
fwtable_write32+0x240/0x320 [i915]
<4> [154.177974] Modules linked in: i915(+) vgem drm_shmem_helper
fuse snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio mei_hdcp mei_pxp x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_intel_dspcfg
snd_hda_codec snd_hwdep igc snd_hda_core ttm mei_me ptp
snd_pcm prime_numbers mei i2c_i801 pps_core i2c_smbus intel_lpss_pci
btusb btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: 
i915]

<4> [154.178143] CPU: 4 PID: 5772 Comm: i915_selftest Tainted: G
U    5.15.0-rc6-CI-Patchwork_21432+ #1
<4> [154.178154] Hardware name: ASUS System Product Name/TUF GAMING
Z590-PLUS WIFI, BIOS 0811 04/06/2021
<4> [154.178160] RIP: 0010:fwtable_write32+0x240/0x320 [i915]
<4> [154.178604] Code: 15 7b e1 0f 0b e9 34 fe ff ff 80 3d a9 89 31
00 00 0f 85 31 fe ff ff 48 c7 c7 88 9e 4f a0 c6 05 95 89 31 00 01 e8
c0 15 7b e1 <0f> 0b e9 17 fe ff ff 8b 05 0f 83 58 e2 85 c0 0f 85 8d
00 00 00 48
<4> [154.178614] RSP: 0018:c900016279f0 EFLAGS: 00010286
<4> [154.178626] RAX:  RBX: 888204fe0ee0
RCX: 0001
<4> [154.178634] RDX: 8001 RSI: 823142b5
RDI: 
<4> [154.178641] RBP: 000320f0 R08: 
R09: c000cd5a
<4> [154.178647] R10: 000f8c90 R11: c90001627808
R12: 
<4> [154.178654] R13: 4000 R14: a04d12e0
R15: 
<4> [154.178660] FS:  7f7390aa4c00() GS:88844f00()
knlGS:
<4> [154.178669] CS:  0010 DS:  ES:  CR0: 80050033
<4> [154.178675] CR2: 55bc40595028 CR3: 000204474005
CR4: 00770ee0
<4> [154.178682] PKRU: 5554
<4> [154.178687] Call Trace:
<4> [154.178706]  intel_pxp_fini_hw+0x23/0x30 [i915]
<4> [154.179284]  intel_pxp_suspend+0x1f/0x30 [i915]
<4> [154.179807]  live_gt_resume+0x5b/0x90 [i915]

Changes since V2 :
- Remove boolean in intel_pxp_runtime_preapre for
  non-pxp configs. Solves build error
Changes since V2 :
- Open-code intel_pxp_runtime_suspend - Daniele
- Remove boolean in intel_pxp_runtime_preapre - Daniele
Changes since V1 :
- split the HW access parts in gt_suspend_late - Daniele
- Remove default PXP configs



Just realized this is also missing a fixes tag:

Fixes: 0cfab4cb3c4e ("drm/i915/pxp: Enable PXP power management")

Daniele

Signed-off-by: Tejas Upadhyay 



Reviewed-by: Daniele Ceraolo Spurio 

Can you send a trybot with the PXP config enabled before we merge 
this, just to make sure the issue is gone?




Trybot came back ok for this change, so pushed to gt-next (fixes tag 
included).


Thanks,
Daniele


Thanks,
Daniele


---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c   |  7 +++--
  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 37 
+

  drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 19 +++--
  3 files changed, 46 insertions(+), 17 deletions(-)

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

index b4a8594bc46c..c0fa41e4c803 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -303,7 +303,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
  user_forcewake(gt, true);
  wait_for_suspend(gt);
  -    intel_pxp_suspend(>pxp, false);
+    intel_pxp_suspend_prepare(>pxp);
  }
    static suspend_state_t pm_suspend_target(void)
@@ -328,6 +328,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
  GEM_BUG_ON(gt->awake);
    intel_uc_suspend(>uc);
+    intel_pxp_suspend(>pxp);
    /*
   * On disabling the device, we want to turn off HW access to 
memory

@@ -355,7 +356,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
    void intel_gt_runtime_suspend(struct intel_gt *gt)
  {
-    intel_pxp_suspend(>pxp, true);
+    intel_pxp_runtime_suspend(>pxp);
  intel_uc_runtime_suspend(>uc);
    GT_TRACE(gt, "\n");
@@ -373,7 +374,7 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
  if (ret)
  return ret;
  -    intel_pxp_resume(>pxp);
+    intel_pxp_runtime_resume(>pxp);
    return 0;
  }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c

index 23fd86de5a24..6a7d4e2ee138 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -7,26 +7,29 @@
  #include "intel_pxp_irq.h"
  #include "intel_pxp_pm.h"
  #include "intel_pxp_session.h"
+#include "i915_drv.h"
  -void 

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable pipe color support on D13 platform

[Patchwork]

== Series Details ==

Series: Enable pipe color support on D13 platform
URL   : https://patchwork.freedesktop.org/series/97219/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10919 -> Patchwork_21670


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 35)
--

  Additional (1): fi-tgl-u2 
  Missing(5): bat-dg1-6 fi-bsw-cyan bat-adlp-4 bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][4] -> [INCOMPLETE][5] ([i915#4432])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2:  NOTRUN -> [SKIP][6] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/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][7] ([i915#4103]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/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][8] ([fdo#109285])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][10] ([i915#3928] / [i915#4312])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/fi-rkl-guc/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [FAIL][11] ([i915#4547]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10919/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21670/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4432]: https://gitlab.freedesktop.org/drm/intel/issues/4432
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613


Build changes
-

  * Linux: CI_DRM_10919 -> Patchwork_21670

  CI-20190529: 20190529
  CI_DRM_10919: c57375a8a23e1a8caf9b01dfbe3927e8d18420c1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6287: 99f085f3a48d4df6eb971b48fff3023d960eb47d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21670: bd28649475400f791f10c3d5d6edda43a14c0ee7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bd2864947540 drm/i915/xelpd: Add Pipe Color Lut caps to platform config
6d05a136562d drm/i915/xelpd: Enable Pipe Degamma
858ca7f937c7 drm/i915/xelpd: Enable Pipe color support 

Re: [Intel-gfx] [RFC 1/7] drm/i915/guc: Add basic support for error capture lists

[Michal Wajdeczko]

On 23.11.2021 00:03, Alan Previn wrote:
> From: John Harrison 
...

> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 77fbcd8730ee..0bfc92b1b982 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -4003,6 +4003,24 @@ int intel_guc_context_reset_process_msg(struct 
> intel_guc *guc,
>   return 0;
>  }
>  
> +int intel_guc_error_capture_process_msg(struct intel_guc *guc,
> +  const u32 *msg, u32 len)
> +{
> + int status;

likely it should be "u32" as few lines below you're using msg[0];

> +
> + if (unlikely(len != 1)) {
> + drm_dbg(_to_gt(guc)->i915->drm, "Invalid length %u", len);

any error returned by the CTB message handler will trigger full dump of
unexpected message - do we really need this unlikely dbg message here ?

> + return -EPROTO;
> + }
> +
> + status = msg[0];
> + drm_info(_to_gt(guc)->i915->drm, "Got error capture: status = %d", 
> status);

IIRC all notification status are defined in GuC spec in hex, so maybe we
should also print it as %#x ?

-Michal

> +
> + /* Add extraction of error capture dump */
> +
> + return 0;
> +}
> +
>  static struct intel_engine_cs *
>  guc_lookup_engine(struct intel_guc *guc, u8 guc_class, u8 instance)
>  {
> 

[Intel-gfx] [PATCH v2 2/8] i915: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 drivers/gpu/drm/i915/i915_perf.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2f01b8c0284c..5979e3258647 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4273,26 +4273,6 @@ static struct ctl_table oa_table[] = {
{}
 };
 
-static struct ctl_table i915_root[] = {
-   {
-.procname = "i915",
-.maxlen = 0,
-.mode = 0555,
-.child = oa_table,
-},
-   {}
-};
-
-static struct ctl_table dev_root[] = {
-   {
-.procname = "dev",
-.maxlen = 0,
-.mode = 0555,
-.child = i915_root,
-},
-   {}
-};
-
 static void oa_init_supported_formats(struct i915_perf *perf)
 {
struct drm_i915_private *i915 = perf->i915;
@@ -4488,7 +4468,7 @@ static int destroy_config(int id, void *p, void *data)
 
 int i915_perf_sysctl_register(void)
 {
-   sysctl_header = register_sysctl_table(dev_root);
+   sysctl_header = register_sysctl("dev/i915", oa_table);
return 0;
 }
 
-- 
2.33.0

[Intel-gfx] [PATCH v2 3/8] macintosh/mac_hid.c: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 drivers/macintosh/mac_hid.c | 24 +---
 1 file changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
index 28b8581b44dd..d8c4d5664145 100644
--- a/drivers/macintosh/mac_hid.c
+++ b/drivers/macintosh/mac_hid.c
@@ -239,33 +239,11 @@ static struct ctl_table mac_hid_files[] = {
{ }
 };
 
-/* dir in /proc/sys/dev */
-static struct ctl_table mac_hid_dir[] = {
-   {
-   .procname   = "mac_hid",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = mac_hid_files,
-   },
-   { }
-};
-
-/* /proc/sys/dev itself, in case that is not there yet */
-static struct ctl_table mac_hid_root_dir[] = {
-   {
-   .procname   = "dev",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = mac_hid_dir,
-   },
-   { }
-};
-
 static struct ctl_table_header *mac_hid_sysctl_header;
 
 static int __init mac_hid_init(void)
 {
-   mac_hid_sysctl_header = register_sysctl_table(mac_hid_root_dir);
+   mac_hid_sysctl_header = register_sysctl("dev/mac_hid", mac_hid_files);
if (!mac_hid_sysctl_header)
return -ENOMEM;
 
-- 
2.33.0

[Intel-gfx] [PATCH v2 1/8] hpet: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci drivers/char/hpet.c

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 drivers/char/hpet.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 4e5431f01450..563dfae3b8da 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -746,26 +746,6 @@ static struct ctl_table hpet_table[] = {
{}
 };
 
-static struct ctl_table hpet_root[] = {
-   {
-.procname = "hpet",
-.maxlen = 0,
-.mode = 0555,
-.child = hpet_table,
-},
-   {}
-};
-
-static struct ctl_table dev_root[] = {
-   {
-.procname = "dev",
-.maxlen = 0,
-.mode = 0555,
-.child = hpet_root,
-},
-   {}
-};
-
 static struct ctl_table_header *sysctl_header;
 
 /*
@@ -1061,7 +1041,7 @@ static int __init hpet_init(void)
if (result < 0)
return -ENODEV;
 
-   sysctl_header = register_sysctl_table(dev_root);
+   sysctl_header = register_sysctl("dev/hpet", hpet_table);
 
result = acpi_bus_register_driver(_acpi_driver);
if (result < 0) {
-- 
2.33.0

[Intel-gfx] [PATCH v2 4/8] ocfs2: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 fs/ocfs2/stackglue.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 16f1bfc407f2..731558a6f27d 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -672,31 +672,8 @@ static struct ctl_table ocfs2_mod_table[] = {
{ }
 };
 
-static struct ctl_table ocfs2_kern_table[] = {
-   {
-   .procname   = "ocfs2",
-   .data   = NULL,
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = ocfs2_mod_table
-   },
-   { }
-};
-
-static struct ctl_table ocfs2_root_table[] = {
-   {
-   .procname   = "fs",
-   .data   = NULL,
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = ocfs2_kern_table
-   },
-   { }
-};
-
 static struct ctl_table_header *ocfs2_table_header;
 
-
 /*
  * Initialization
  */
@@ -705,7 +682,7 @@ static int __init ocfs2_stack_glue_init(void)
 {
strcpy(cluster_stack_name, OCFS2_STACK_PLUGIN_O2CB);
 
-   ocfs2_table_header = register_sysctl_table(ocfs2_root_table);
+   ocfs2_table_header = register_sysctl("fs/ocfs2", ocfs2_mod_table);
if (!ocfs2_table_header) {
printk(KERN_ERR
   "ocfs2 stack glue: unable to register sysctl\n");
-- 
2.33.0

[Intel-gfx] [PATCH v2 6/8] inotify: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

From: Xiaoming Ni 

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

Move inotify_user sysctl to inotify_user.c while at it to remove clutter
from kernel/sysctl.c.

Signed-off-by: Xiaoming Ni 
[mcgrof: update commit log to reflect new path we decided to take]
Signed-off-by: Luis Chamberlain 
---
 fs/notify/inotify/inotify_user.c | 11 ++-
 include/linux/inotify.h  |  3 ---
 kernel/sysctl.c  | 21 -
 3 files changed, 10 insertions(+), 25 deletions(-)

diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 29fca3284bb5..54583f62dc44 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -58,7 +58,7 @@ struct kmem_cache *inotify_inode_mark_cachep __read_mostly;
 static long it_zero = 0;
 static long it_int_max = INT_MAX;
 
-struct ctl_table inotify_table[] = {
+static struct ctl_table inotify_table[] = {
{
.procname   = "max_user_instances",
.data   = 
_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES],
@@ -87,6 +87,14 @@ struct ctl_table inotify_table[] = {
},
{ }
 };
+
+static void __init inotify_sysctls_init(void)
+{
+   register_sysctl("fs/inotify", inotify_table);
+}
+
+#else
+#define inotify_sysctls_init() do { } while (0)
 #endif /* CONFIG_SYSCTL */
 
 static inline __u32 inotify_arg_to_mask(struct inode *inode, u32 arg)
@@ -849,6 +857,7 @@ static int __init inotify_user_setup(void)
inotify_max_queued_events = 16384;
init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES] = 128;
init_user_ns.ucount_max[UCOUNT_INOTIFY_WATCHES] = watches_max;
+   inotify_sysctls_init();
 
return 0;
 }
diff --git a/include/linux/inotify.h b/include/linux/inotify.h
index 6a24905f6e1e..8d20caa1b268 100644
--- a/include/linux/inotify.h
+++ b/include/linux/inotify.h
@@ -7,11 +7,8 @@
 #ifndef _LINUX_INOTIFY_H
 #define _LINUX_INOTIFY_H
 
-#include 
 #include 
 
-extern struct ctl_table inotify_table[]; /* for sysctl */
-
 #define ALL_INOTIFY_BITS (IN_ACCESS | IN_MODIFY | IN_ATTRIB | IN_CLOSE_WRITE | 
\
  IN_CLOSE_NOWRITE | IN_OPEN | IN_MOVED_FROM | \
  IN_MOVED_TO | IN_CREATE | IN_DELETE | \
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 7a90a12b9ea4..6aa67c737e4e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -125,13 +125,6 @@ static const int maxolduid = 65535;
 static const int ngroups_max = NGROUPS_MAX;
 static const int cap_last_cap = CAP_LAST_CAP;
 
-#ifdef CONFIG_INOTIFY_USER
-#include 
-#endif
-#ifdef CONFIG_FANOTIFY
-#include 
-#endif
-
 #ifdef CONFIG_PROC_SYSCTL
 
 /**
@@ -3099,20 +3092,6 @@ static struct ctl_table fs_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
-#ifdef CONFIG_INOTIFY_USER
-   {
-   .procname   = "inotify",
-   .mode   = 0555,
-   .child  = inotify_table,
-   },
-#endif
-#ifdef CONFIG_FANOTIFY
-   {
-   .procname   = "fanotify",
-   .mode   = 0555,
-   .child  = fanotify_table,
-   },
-#endif
 #ifdef CONFIG_EPOLL
{
.procname   = "epoll",
-- 
2.33.0

[Intel-gfx] [PATCH v2 8/8] eventpoll: simplify sysctl declaration with register_sysctl()

[Luis Chamberlain]

From: Xiaoming Ni 

The kernel/sysctl.c is a kitchen sink where everyone leaves
their dirty dishes, this makes it very difficult to maintain.

To help with this maintenance let's start by moving sysctls to
places where they actually belong. The proc sysctl maintainers
do not want to know what sysctl knobs you wish to add for your own
piece of code, we just care about the core logic.

So move the epoll_table sysctl to fs/eventpoll.c and use
use register_sysctl().

Signed-off-by: Xiaoming Ni 
Signed-off-by: Luis Chamberlain 
---
 fs/eventpoll.c | 10 +-
 include/linux/poll.h   |  2 --
 include/linux/sysctl.h |  1 -
 kernel/sysctl.c|  7 ---
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 06f4c5ae1451..e2daa940ebce 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -307,7 +307,7 @@ static void unlist_file(struct epitems_head *head)
 static long long_zero;
 static long long_max = LONG_MAX;
 
-struct ctl_table epoll_table[] = {
+static struct ctl_table epoll_table[] = {
{
.procname   = "max_user_watches",
.data   = _user_watches,
@@ -319,6 +319,13 @@ struct ctl_table epoll_table[] = {
},
{ }
 };
+
+static void __init epoll_sysctls_init(void)
+{
+   register_sysctl("fs/epoll", epoll_table);
+}
+#else
+#define epoll_sysctls_init() do { } while (0)
 #endif /* CONFIG_SYSCTL */
 
 static const struct file_operations eventpoll_fops;
@@ -2378,6 +2385,7 @@ static int __init eventpoll_init(void)
/* Allocates slab cache used to allocate "struct eppoll_entry" */
pwq_cache = kmem_cache_create("eventpoll_pwq",
sizeof(struct eppoll_entry), 0, SLAB_PANIC|SLAB_ACCOUNT, NULL);
+   epoll_sysctls_init();
 
ephead_cache = kmem_cache_create("ep_head",
sizeof(struct epitems_head), 0, SLAB_PANIC|SLAB_ACCOUNT, NULL);
diff --git a/include/linux/poll.h b/include/linux/poll.h
index 1cdc32b1f1b0..a9e0e1c2d1f2 100644
--- a/include/linux/poll.h
+++ b/include/linux/poll.h
@@ -8,12 +8,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 
-extern struct ctl_table epoll_table[]; /* for sysctl */
 /* ~832 bytes of stack space used max in sys_select/sys_poll before allocating
additional memory. */
 #ifdef __clang__
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 718492057c70..5e0428a71899 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -218,7 +218,6 @@ extern int no_unaligned_warning;
 extern struct ctl_table sysctl_mount_point[];
 extern struct ctl_table random_table[];
 extern struct ctl_table firmware_config_table[];
-extern struct ctl_table epoll_table[];
 
 #else /* CONFIG_SYSCTL */
 static inline struct ctl_table_header *register_sysctl_table(struct ctl_table 
* table)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6aa67c737e4e..b09ff41720e3 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -3092,13 +3092,6 @@ static struct ctl_table fs_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
-#ifdef CONFIG_EPOLL
-   {
-   .procname   = "epoll",
-   .mode   = 0555,
-   .child  = epoll_table,
-   },
-#endif
 #endif
{
.procname   = "protected_symlinks",
-- 
2.33.0

[Intel-gfx] [PATCH v2 5/8] test_sysctl: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci lib/test_sysctl.c

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 lib/test_sysctl.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c
index 3750323973f4..a5a3d6c27e1f 100644
--- a/lib/test_sysctl.c
+++ b/lib/test_sysctl.c
@@ -128,26 +128,6 @@ static struct ctl_table test_table[] = {
{ }
 };
 
-static struct ctl_table test_sysctl_table[] = {
-   {
-   .procname   = "test_sysctl",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = test_table,
-   },
-   { }
-};
-
-static struct ctl_table test_sysctl_root_table[] = {
-   {
-   .procname   = "debug",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = test_sysctl_table,
-   },
-   { }
-};
-
 static struct ctl_table_header *test_sysctl_header;
 
 static int __init test_sysctl_init(void)
@@ -155,7 +135,7 @@ static int __init test_sysctl_init(void)
test_data.bitmap_0001 = kzalloc(SYSCTL_TEST_BITMAP_SIZE/8, GFP_KERNEL);
if (!test_data.bitmap_0001)
return -ENOMEM;
-   test_sysctl_header = register_sysctl_table(test_sysctl_root_table);
+   test_sysctl_header = register_sysctl("debug/test_sysctl", test_table);
if (!test_sysctl_header) {
kfree(test_data.bitmap_0001);
return -ENOMEM;
-- 
2.33.0

[Intel-gfx] [PATCH v2 7/8] cdrom: simplify subdirectory registration with register_sysctl()

[Luis Chamberlain]

There is no need to user boiler plate code to specify a set of base
directories we're going to stuff sysctls under. Simplify this by using
register_sysctl() and specifying the directory path directly.

// pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH

@c1@
expression E1;
identifier subdir, sysctls;
@@

static struct ctl_table subdir[] = {
{
.procname = E1,
.maxlen = 0,
.mode = 0555,
.child = sysctls,
},
{ }
};

@c2@
identifier c1.subdir;

expression E2;
identifier base;
@@

static struct ctl_table base[] = {
{
.procname = E2,
.maxlen = 0,
.mode = 0555,
.child = subdir,
},
{ }
};

@c3@
identifier c2.base;
identifier header;
@@

header = register_sysctl_table(base);

@r1 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.subdir, c1.sysctls;
@@

-static struct ctl_table subdir[] = {
-   {
-   .procname = E1,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = sysctls,
-   },
-   { }
-};

@r2 depends on c1 && c2 && c3@
identifier c1.subdir;

expression c2.E2;
identifier c2.base;
@@
-static struct ctl_table base[] = {
-   {
-   .procname = E2,
-   .maxlen = 0,
-   .mode = 0555,
-   .child = subdir,
-   },
-   { }
-};

@initialize:python@
@@

def make_my_fresh_expression(s1, s2):
  return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'

@r3 depends on c1 && c2 && c3@
expression c1.E1;
identifier c1.sysctls;
expression c2.E2;
identifier c2.base;
identifier c3.header;
fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) 
};
@@

header =
-register_sysctl_table(base);
+register_sysctl(E3, sysctls);

Generated-by: Coccinelle SmPL
Signed-off-by: Luis Chamberlain 
---
 drivers/cdrom/cdrom.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 9877e413fce3..1b57d4666e43 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -3691,27 +3691,6 @@ static struct ctl_table cdrom_table[] = {
},
{ }
 };
-
-static struct ctl_table cdrom_cdrom_table[] = {
-   {
-   .procname   = "cdrom",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = cdrom_table,
-   },
-   { }
-};
-
-/* Make sure that /proc/sys/dev is there */
-static struct ctl_table cdrom_root_table[] = {
-   {
-   .procname   = "dev",
-   .maxlen = 0,
-   .mode   = 0555,
-   .child  = cdrom_cdrom_table,
-   },
-   { }
-};
 static struct ctl_table_header *cdrom_sysctl_header;
 
 static void cdrom_sysctl_register(void)
@@ -3721,7 +3700,7 @@ static void cdrom_sysctl_register(void)
if (!atomic_add_unless(, 1, 1))
return;
 
-   cdrom_sysctl_header = register_sysctl_table(cdrom_root_table);
+   cdrom_sysctl_header = register_sysctl("dev/cdrom", cdrom_table);
 
/* set the defaults */
cdrom_sysctl_settings.autoclose = autoclose;
-- 
2.33.0

[Intel-gfx] [PATCH v2 0/8] sysctl: second set of kernel/sysctl cleanups

[Luis Chamberlain]

This is the 2nd set of kernel/sysctl.c cleanups. The diff stat should
reflect how this is a much better way to deal with theses. Fortunately
coccinelle can be used to ensure correctness for most of these and/or
future merge conflicts.

Note that since this is part of a larger effort to cleanup
kernel/sysctl.c I think we have no other option but to go with
merging these patches in either Andrew's tree or keep them staged
in a separate tree and send a merge request later. Otherwise
kernel/sysctl.c will end up becoming a sore spot for the next
merge window.

Changes in this v2:

 * As suggested by Eric W. Biederman I dropped the subdir new call
   and just used the register_sysctl() by specifying the parent
   directory.
 * 0-day cleanups, commit log enhancements
 * Updated the coccinelle patch with register_sysctl()

Luis Chamberlain (6):
  hpet: simplify subdirectory registration with register_sysctl()
  i915: simplify subdirectory registration with register_sysctl()
  macintosh/mac_hid.c: simplify subdirectory registration with
register_sysctl()
  ocfs2: simplify subdirectory registration with register_sysctl()
  test_sysctl: simplify subdirectory registration with register_sysctl()
  cdrom: simplify subdirectory registration with register_sysctl()

Xiaoming Ni (2):
  inotify: simplify subdirectory registration with register_sysctl()
  eventpoll: simplify sysctl declaration with register_sysctl()

 drivers/cdrom/cdrom.c| 23 +--
 drivers/char/hpet.c  | 22 +-
 drivers/gpu/drm/i915/i915_perf.c | 22 +-
 drivers/macintosh/mac_hid.c  | 24 +---
 fs/eventpoll.c   | 10 +-
 fs/notify/inotify/inotify_user.c | 11 ++-
 fs/ocfs2/stackglue.c | 25 +
 include/linux/inotify.h  |  3 ---
 include/linux/poll.h |  2 --
 include/linux/sysctl.h   |  1 -
 kernel/sysctl.c  | 28 
 lib/test_sysctl.c| 22 +-
 12 files changed, 25 insertions(+), 168 deletions(-)

-- 
2.33.0

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

[Rodrigo Vivi]

On Tue, Nov 23, 2021 at 09:39:25AM +, Tvrtko Ursulin wrote:
> 
> On 17/11/2021 22:49, Vinay Belgaumkar wrote:
> > 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.
> 
> This partially brings back, from a different angle, the more dynamic
> scheduling behavior which has been lost since bugfix 90a987205c6c
> ("drm/i915/gt: Only swap to a random sibling once upon creation").

Shouldn't we use the Fixes tag here since this is targeting to fix one
of the performance regressions of this patch?

> 
> One day we could experiment with using engine busyness as criteria (instead
> of random). Back in the day busyness was kind of the best strategy, although
> sampled at submit, not at the trailing edge like here, but it still may be
> able to settle down to engine configuration better in some scenarios. Only
> testing could say.
> 
> Still, from memory random also wasn't that bad so this should be okay for
> now.
> 
> Reviewed-by: Tvrtko Ursulin 

Since you reviewed and it looks to be a middle ground point in terms
of when to balancing (always like in the initial implementation vs
only once like the in 90a987205c6c).

If this one is really fixing the regression by itself:
Acked-by: Rodrigo Vivi 
on this patch here.

But I still don't want to take the risk with touching the freq with
race to idle, until not convinced that it is absolutely needed and
that we are not breaking the world out there.

> 
> Regards,
> 
> Tvrtko
> 
> > 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(>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,
> > +

Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay

[Souza, Jose]

On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
> 
> v1: RFC version.
> v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
> v3:
> - code comments improved. [Jani]
> - dpcd_readb used instead of dpcd_read. [Jani]
> - panel-repaplay init/compute functions moved inside respective psr
> function. [Jani]
> 
> Signed-off-by: Animesh Manna 
> ---
>  .../drm/i915/display/intel_display_types.h|  2 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 43 +
>  drivers/gpu/drm/i915/display/intel_psr.c  | 48 +++
>  drivers/gpu/drm/i915/display/intel_psr.h  |  3 ++
>  4 files changed, 87 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 39e11eaec1a3..48f7d676ed2c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1070,6 +1070,7 @@ struct intel_crtc_state {
>   bool req_psr2_sdp_prior_scanline;
>   u32 dc3co_exitline;
>   u16 su_y_granularity;
> + bool has_panel_replay;

We can drop this and reuse current ones ones, see bellow.

>   struct drm_dp_vsc_sdp psr_vsc;
>  
>   /*
> @@ -1531,6 +1532,7 @@ struct intel_psr {
>   bool irq_aux_error;
>   u16 su_w_granularity;
>   u16 su_y_granularity;
> + bool sink_panel_replay_support;

move this closer to has_psr and set both when it is panel replay.
otherwise psr functions will not be executed for panel replay, see CAN_PSR().

>   u32 dc3co_exitline;
>   u32 dc3co_exit_delay;
>   struct delayed_work dc3co_work;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 10fda20a5bd8..f58a7b72be14 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1587,12 +1587,22 @@ static void intel_dp_compute_vsc_colorimetry(const 
> struct intel_crtc_state *crtc
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  
> - /*
> -  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> -  * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> -  * Colorimetry Format indication.
> -  */
> - vsc->revision = 0x5;
> + if (crtc_state->has_panel_replay) {
> + /*
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> +  * VSC SDP supporting 3D stereo, Panel Replay, and Pixel
> +  * Encoding/Colorimetry Format indication.
> +  */
> + vsc->revision = 0x7;
> + } else {
> + /*
> +  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> +  * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> +  * Colorimetry Format indication.
> +  */
> + vsc->revision = 0x5;
> + }
> +
>   vsc->length = 0x13;
>  
>   /* DP 1.4a spec, Table 2-120 */
> @@ -1701,6 +1711,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp 
> *intel_dp,
>   vsc->revision = 0x4;
>   vsc->length = 0xe;
>   }
> + } else if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
> + if (intel_dp->psr.colorimetry_support &&
> + intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> + /* [Panel Replay with colorimetry info] */
> + intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> +  vsc);
> + } else {
> + /*
> +  * [Panel Replay without colorimetry info]
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 
> 2-223
> +  * VSC SDP supporting 3D stereo + Panel Replay.
> +  */
> + vsc->revision = 0x6;
> + vsc->length = 0x10;
> + }
>   } else {
>   /*
>* [PSR1]
> @@ -2749,10 +2774,10 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct 
> drm_dp_vsc_sdp *vsc,
>   sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
>  
>   /*
> -  * Only revision 0x5 supports Pixel Encoding/Colorimetry Format as
> -  * per DP 1.4a spec.
> +  * Revision 0x5 and 0x7 supports Pixel Encoding/Colorimetry Format as
> +  * per DP 1.4a spec and DP 2.0 spec respectively.
>*/
> - if (vsc->revision != 0x5)
> + if (vsc->revision != 0x5 || vsc->revision != 0x7)
>   goto out;
>  
>   /* VSC SDP Payload for DB16 through DB18 */
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> 

[Intel-gfx] [PATCH 3/3] drm/i915/xelpd: Add Pipe Color Lut caps to platform config

[Uma Shankar]

XE_LPD has 128 Lut entries for Degamma, with additional 3 entries for
extended range. It has 511 entries for gamma with additional 2 entries
for extended range.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f01cba4ec283..40d21a8c50ff 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -938,7 +938,7 @@ static const struct intel_device_info adl_s_info = {
 
 #define XE_LPD_FEATURES \
.abox_mask = GENMASK(1, 0), 
\
-   .color = { .degamma_lut_size = 0, .gamma_lut_size = 0 },
\
+   .color = { .degamma_lut_size = 128, .gamma_lut_size = 513 },
\
.dbuf.size = 4096,  
\
.dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
\
BIT(DBUF_S4),   
\
-- 
2.25.1

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/panelreplay: dpcd register definition for panelreplay

[Souza, Jose]

On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> DPCD register definition added to check and enable panel replay
> capability of the sink.
> 
> Signed-off-by: Animesh Manna 
> ---
>  include/drm/drm_dp_helper.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index b52df4db3e8f..8a2b929c3f88 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -541,6 +541,9 @@ struct drm_panel;
>  /* DFP Capability Extension */
>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0a3   /* 2.0 */
>  
> +#define DP_PANEL_REPLAY_CAP 0x0b0
> +# define PANEL_REPLAY_SUPPORT   (1 << 0)

Missing bit 1, that is very important when panel do not support selective 
update panel replay needs to act like PSR1 when it is sets it needs to act
like PSR2.

> +
>  /* Link Configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -709,6 +712,9 @@ struct drm_panel;
>  #define DP_BRANCH_DEVICE_CTRL0x1a1
>  # define DP_BRANCH_DEVICE_IRQ_HPD(1 << 0)
>  
> +#define PANEL_REPLAY_CONFIG 0x1b0
> +# define PANEL_REPLAY_ENABLE(1 << 0)

All other bits are also important, for the errors ones we have PSR counter 
parts and your are missing the error status register.

> +
>  #define DP_PAYLOAD_ALLOCATE_SET  0x1c0
>  #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
>  #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2

[Intel-gfx] [PATCH 2/3] drm/i915/xelpd: Enable Pipe Degamma

[Uma Shankar]

Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
to incorparate the extended lut size for XE_LPD.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index e529dbeee525..81046d5ab509 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -815,6 +815,12 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
int i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
const struct drm_color_lut *lut = crtc_state->hw.degamma_lut->data;
+   u32 extended_lut_size;
+
+   if (DISPLAY_VER(dev_priv) >= 13)
+   extended_lut_size = 131;
+   else
+   extended_lut_size = 35;
 
/*
 * When setting the auto-increment bit, the hardware seems to
@@ -827,8 +833,8 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state)
 
for (i = 0; i < lut_size; i++) {
/*
-* First 33 entries represent range from 0 to 1.0
-* 34th and 35th entry will represent extended range
+* First lut_size entries represent range from 0 to 1.0
+* 3 additional lut entries will represent extended range
 * inputs 3.0 and 7.0 respectively, currently clamped
 * at 1.0. Since the precision is 16bit, the user
 * value can be directly filled to register.
@@ -844,7 +850,7 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state)
}
 
/* Clamp values > 1.0. */
-   while (i++ < 35)
+   while (i++ < extended_lut_size)
intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
 
intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
-- 
2.25.1

[Intel-gfx] [PATCH 1/3] drm/i915/xelpd: Enable Pipe color support for D13 platform

[Uma Shankar]

Enable pipe color support for Display 13 platforms. Currently
limit to just 10bit gamma and later extend it for logarithmic
gamma, once the new UAPI is agreed by community and implemented
by a userspace consumer.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_color.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index c870a0e50cb1..e529dbeee525 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1574,6 +1574,8 @@ static int glk_color_check(struct intel_crtc_state 
*crtc_state)
 
 static u32 icl_gamma_mode(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);
u32 gamma_mode = 0;
 
if (crtc_state->hw.degamma_lut)
@@ -1586,6 +1588,13 @@ static u32 icl_gamma_mode(const struct intel_crtc_state 
*crtc_state)
if (!crtc_state->hw.gamma_lut ||
crtc_state_is_legacy_gamma(crtc_state))
gamma_mode |= GAMMA_MODE_MODE_8BIT;
+   /*
+* Enable 10bit gamma for D13
+* ToDo: Extend to Logarithmic Gamma once the new UAPI
+* is acccepted and implemented by a userspace consumer
+*/
+   else if (DISPLAY_VER(dev_priv) >= 13)
+   gamma_mode |= GAMMA_MODE_MODE_10BIT;
else
gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
 
-- 
2.25.1

[Intel-gfx] [PATCH 0/3] Enable pipe color support on D13 platform

[Uma Shankar]

Enable pipe color support for Display 13 platform. This series
enables just the 10bit gamma mode. More advanced logarithmic
gamma mode will be enable with the new enhanced UAPI. It will
be extended once the UAPI is agreed in community. This series
just adds the basic support in the interim.

Uma Shankar (3):
  drm/i915/xelpd: Enable Pipe color support for D13 platform
  drm/i915/xelpd: Enable Pipe Degamma
  drm/i915/xelpd: Add Pipe Color Lut caps to platform config

 drivers/gpu/drm/i915/display/intel_color.c | 21 ++---
 drivers/gpu/drm/i915/i915_pci.c|  2 +-
 2 files changed, 19 insertions(+), 4 deletions(-)

-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: placate scripts/kernel-doc

[Patchwork]

== Series Details ==

Series: drm/i915/gem: placate scripts/kernel-doc
URL   : https://patchwork.freedesktop.org/series/97190/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10917_full -> Patchwork_21664_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl6/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-kbl7/igt@gem_b...@close-race.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-skl2/igt@gem_exec_capture@p...@rcs0.html

  * igt@kms_cursor_legacy@cursora-vs-flipa-atomic:
- shard-skl:  NOTRUN -> [DMESG-WARN][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-skl2/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html

  * igt@kms_flip@busy-flip@b-edp1:
- shard-skl:  [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-skl8/igt@kms_flip@busy-f...@b-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-skl3/igt@kms_flip@busy-f...@b-edp1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_capture@pi@vecs0:
- shard-iclb: NOTRUN -> [INCOMPLETE][7] ([i915#3371])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-iclb8/igt@gem_exec_capture@p...@vecs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-iclb6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_params@no-vebox:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109283])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-tglb1/igt@gem_exec_par...@no-vebox.html

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

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/shard-apl6/igt@gem_pr...@exhaustion.html

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

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][21] -> [DMESG-WARN][22] ([i915#1436] / 
[i915#716])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-skl6/igt@gen9_exec_pa...@allowed-single.html
   [22]: 

Re: [Intel-gfx] [PATCH] drm/i915/ttm: fixup build failure

[Tvrtko Ursulin]

On 23/11/2021 12:58, Matthew Auld wrote:

drm-intel-gt-next fails to build with:

drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘vm_fault_ttm’:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:862:23: error: too many arguments to 
function ‘ttm_bo_vm_fault_reserved’
   862 | ret = ttm_bo_vm_fault_reserved(vmf, 
vmf->vma->vm_page_prot,
   |   ^~~

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
---
  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 753f0f5458b6..02918b990b25 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, )) {

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);



Pushed thanks!

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 02/17] Use memberof(T, m) instead of explicit NULL dereference

[Rafael J. Wysocki]

On Fri, Nov 19, 2021 at 12:37 PM Alejandro Colomar
 wrote:
>
> Signed-off-by: Alejandro Colomar 
> Cc: Ajit Khaparde 
> Cc: Andrew Morton 
> Cc: Andy Shevchenko 
> Cc: Arnd Bergmann 
> Cc: Bjorn Andersson 
> Cc: Borislav Petkov 
> Cc: Corey Minyard 
> Cc: Chris Mason 
> Cc: Christian Brauner 
> Cc: David Sterba 
> Cc: Jani Nikula 
> Cc: Jason Wang 
> Cc: Jitendra Bhivare 
> Cc: John Hubbard 
> Cc: John S. Gruber 
> Cc: Jonathan Cameron 
> Cc: Joonas Lahtinen 
> Cc: Josef Bacik 
> Cc: Kees Cook 
> Cc: Ketan Mukadam 
> Cc: Len Brown 
> Cc: "Michael S. Tsirkin" 
> Cc: Miguel Ojeda 
> Cc: Mike Rapoport 
> Cc: Nick Desaulniers 
> Cc: "Rafael J. Wysocki" 
> Cc: Rasmus Villemoes 
> Cc: Rodrigo Vivi 
> Cc: Russell King 
> Cc: Somnath Kotur 
> Cc: Sriharsha Basavapatna 
> Cc: Subbu Seetharaman 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> ---
>  arch/x86/include/asm/bootparam_utils.h  |  3 ++-
>  arch/x86/kernel/signal_compat.c |  5 +++--
>  drivers/gpu/drm/i915/i915_utils.h   |  5 ++---
>  drivers/gpu/drm/i915/intel_runtime_pm.h |  2 +-
>  drivers/net/ethernet/emulex/benet/be.h  |  7 ---
>  drivers/net/ethernet/i825xx/ether1.c|  7 +--
>  drivers/scsi/be2iscsi/be.h  |  7 ---
>  drivers/scsi/be2iscsi/be_cmds.h |  5 -
>  fs/btrfs/ctree.h|  5 +++--
>  include/acpi/actypes.h  |  4 +++-

The change in actypes.h would need to be submitted to the upstream
ACPICA project via https://github.com/acpica/acpica/

Thanks!

>  include/linux/container_of.h|  6 +++---
>  include/linux/virtio_config.h   | 14 +++---
>  12 files changed, 41 insertions(+), 29 deletions(-)

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

[Belgaumkar, Vinay]

On 11/17/2021 2:49 PM, Vinay Belgaumkar wrote:

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 


Data collected does show some power savings.

Reviewed-by: Vinay Belgaumkar 

---
  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(>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(>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(>work);

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

[Belgaumkar, Vinay]

On 11/17/2021 2:49 PM, Vinay Belgaumkar wrote:

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 


Reviewed-by: Vinay Belgaumkar 


---
  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, );

-   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, );
+   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;
  

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: placate scripts/kernel-doc

[Vudum, Lakshminarayana]

This failure is related to 
https://gitlab.freedesktop.org/drm/intel/-/issues/4547
Few tests - fail - This test was killed due to a kernel taint, INFO: task 
kworker/.* blocked for more than 30 seconds.

Re-reproted.

Thanks,
Lakshmi.
From: Matthew Auld 
Sent: Tuesday, November 23, 2021 1:45 AM
To: Intel Graphics Development ; Vudum, 
Lakshminarayana 
Cc: Randy Dunlap 
Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: placate 
scripts/kernel-doc

On Tue, 23 Nov 2021 at 05:56, Patchwork 
mailto:patchw...@emeril.freedesktop.org>> 
wrote:
Patch Details
Series:

drm/i915/gem: placate scripts/kernel-doc

URL:

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

State:

failure

Details:

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

CI Bug Log - changes from CI_DRM_10917 -> Patchwork_21664
Summary

FAILURE

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

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

Participating hosts (40 -> 34)

Additional (1): fi-kbl-soraka
Missing (7): bat-dg1-6 fi-tgl-u2 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-jsl-2 
bat-jsl-1

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_suspend@basic-s3:

 *   fi-skl-6600u: 
PASS
 -> 
FAIL

Lakshmi, another false positive it seems. The patch in question is only fixing 
kernel-doc. Pushed to drm-intel-gt-next. Thanks.


  *

Known issues

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

IGT changes
Issues hit

  *   igt@amdgpu/amd_basic@semaphore:

 *   fi-bdw-5557u: NOTRUN -> 
SKIP
 (fdo#109271) +31 similar 
issues

  *   igt@gem_exec_fence@basic-busy@bcs0:

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

  *   igt@gem_exec_suspend@basic-s0:

 *   fi-kbl-soraka: NOTRUN -> 
INCOMPLETE
 (i915#4221)

  *   igt@gem_huc_copy@huc-copy:

 *   fi-kbl-8809g: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#2190)

  *   igt@i915_selftest@live@hangcheck:

 *   fi-snb-2600: 
PASS
 -> 
INCOMPLETE
 (i915#3921)

  *   igt@kms_chamelium@dp-crc-fast:

 *   fi-bdw-5557u: NOTRUN -> 
SKIP
 (fdo#109271 / 
fdo#111827) +8 similar 
issues

  *   igt@kms_chamelium@hdmi-edid-read:

 *   fi-kbl-8809g: NOTRUN -> 
SKIP
 (fdo#109271 / 
fdo#111827) +8 similar 
issues

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

 *   fi-kbl-8809g: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#533)

  *   igt@kms_psr@cursor_plane_move:

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

Possible fixes

  *   igt@core_auth@basic-auth:

 *   fi-kbl-8809g: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: placate scripts/kernel-doc

[Patchwork]

== Series Details ==

Series: drm/i915/gem: placate scripts/kernel-doc
URL   : https://patchwork.freedesktop.org/series/97190/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10917 -> Patchwork_21664


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 34)
--

  Additional (1): fi-kbl-soraka 
  Missing(7): bat-dg1-6 fi-tgl-u2 fi-bsw-cyan bat-adlp-6 bat-adlp-4 
bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   [PASS][4] -> [FAIL][5] ([i915#4547])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

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

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

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

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

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-8809g:   NOTRUN -> [SKIP][12] ([fdo#109271]) +41 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/fi-kbl-8809g/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@core_auth@basic-auth:
- fi-kbl-8809g:   [FAIL][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-kbl-8809g/igt@core_a...@basic-auth.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/fi-kbl-8809g/igt@core_a...@basic-auth.html

  
 Warnings 

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

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4221]: https://gitlab.freedesktop.org/drm/intel/issues/4221
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-

  * Linux: CI_DRM_10917 -> Patchwork_21664

  CI-20190529: 20190529
  CI_DRM_10917: de9a03c2007f3c69c5fa86ef007841a4a9194aac @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6286: cdcbf81f734fdb1d102e84490e49e9fec23760cd @ 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
URL   : https://patchwork.freedesktop.org/series/97208/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10917_full -> Patchwork_21669_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-skl9/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_whisper@basic-sync-all:
- shard-kbl:  [PASS][2] -> [INCOMPLETE][3] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl4/igt@gem_exec_whis...@basic-sync-all.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-kbl7/igt@gem_exec_whis...@basic-sync-all.html

  
 Suppressed 

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

  * igt@gem_mmap@basic-small-bo:
- {shard-rkl}:NOTRUN -> [DMESG-WARN][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-rkl-2/igt@gem_m...@basic-small-bo.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-tglb1/igt@gem_exec_balan...@parallel-out-fence.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-iclb6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2849])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-vebox:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-tglb8/igt@gem_exec_par...@no-vebox.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#456])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-tglb6/igt@gem_exec_susp...@basic-s0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_whisper@basic-contexts:
- shard-kbl:  [PASS][18] -> [INCOMPLETE][19] ([i915#794])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl1/igt@gem_exec_whis...@basic-contexts.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/shard-kbl7/igt@gem_exec_whis...@basic-contexts.html

  * igt@gem_mmap_offset@clear:
- shard-kbl:  [PASS][20] -> [INCOMPLETE][21] ([fdo#109052] / 
[i915#794])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl4/igt@gem_mmap_off...@clear.html
   [21]: 

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

[Vivi, Rodrigo]

On Tue, 2021-11-23 at 09:17 +, Tvrtko Ursulin wrote:
> 
> On 22/11/2021 18:44, Rodrigo Vivi wrote:
> > On Wed, Nov 17, 2021 at 02:49:55PM -0800, Vinay Belgaumkar wrote:
> > > 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 
> > 
> > Please let's not increase the complexity here, unless we have a
> > very good
> > and documented reason.
> > 
> > Before trying to implement anything smart like this in the driver
> > I'd like
> > to see data, power and performance results in different platforms
> > and with
> > different workloads.
> 
> Who has such test suite and test farm which isn't focused to
> workloads 
> from a single customer? ;(

Okay, maybe we don't need to cover the world here. But without seen any
data at all it is hard to make this call.

> 
> Regards,
> 
> Tvrtko

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

[Imre Deak]

On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> Hi Stanislav,
> 
> Are there IGT tests for this modifier?
> 
> On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > - Check specifically for DG2, but not the Display13(Imre)
> >
> > v6: - Moved Tile4 assocating struct for modifier/display to
> >   the beginning(Imre Deak)
> > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> >   checks(Imre Deak)
> > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> >   (Imre Deak)
> >
> > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > - Removed redundant newline(Imre Deak)
> >
> > Reviewed-by: Imre Deak 
> > 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   |  9 +
> >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> >  .../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, 37 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f3c9208a30b1..7429965d3682 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7766,6 +7766,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(>drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index c4a743d0913f..b7f1ef62072c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -139,6 +139,9 @@ struct intel_modifier_desc {
> >
> >  static const struct intel_modifier_desc intel_modifiers[] = {
> > {
> > +   .modifier = I915_FORMAT_MOD_4_TILED,
> > +   .display_ver = { 13, 13 },
> 
> I see that every other modifier has the plane_cap field set. Why is it
> okay for it to be zero here?

Yes, missed this. The INTEL_PLANE_CAP_TILING_4 flag needs to be added
and returned from skl_get_plane_caps() for HAS_4TILE() platforms and
here we need to set this flag.

> > +   }, {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > .display_ver = { 12, 13 },
> > .plane_caps = INTEL_PLANE_CAP_TILING_Y | 
> > INTEL_PLANE_CAP_CCS_MC,
> > @@ -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;
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index d0c34bc3af6c..0ceabe40d8c9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -898,6 +898,7 @@ static bool tiling_is_valid(struct drm_i915_private 
> > *i915,
> > case I915_FORMAT_MOD_Y_TILED:
> > 

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

[Chery, Nanley G]

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, November 23, 2021 10:23 AM
> To: Chery, Nanley G 
> Cc: intel-gfx@lists.freedesktop.org; Deak, Imre 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support
> 
> On Tue, Nov 23, 2021 at 05:06:22PM +0200, Chery, Nanley G wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav 
> > > Sent: Tuesday, November 23, 2021 8:37 AM
> > > To: Chery, Nanley G 
> > > Cc: Nanley Chery ;
> > > intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format
> > > support
> > >
> > > On Tue, Nov 23, 2021 at 02:41:20PM +0200, Chery, Nanley G wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Lisovskiy, Stanislav 
> > > > > Sent: Tuesday, November 23, 2021 3:14 AM
> > > > > To: Nanley Chery 
> > > > > Cc: intel-gfx@lists.freedesktop.org; Chery, Nanley G
> > > > > 
> > > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane
> > > > > format support
> > > > >
> > > > > On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> > > > > > Hi Stanislav,
> > > > > >
> > > > > > Are there IGT tests for this modifier?
> > > > >
> > > > > Hi Nanley
> > > > >
> > > > > Yes, there should be plenty of those, not sure they are all sent
> > > > > to upstream though.
> > > > > We have a separate team doing this.
> > > > > That modifier should be added to kms_plane_multiple and many
> > > > > others
> > > > >
> > > >
> > > > Okay, I'll be on the lookout for them.
> > > >
> > > > > Stan
> > > > >
> > > >
> > > > Looks like you missed the other review comments I left in my prior 
> > > > email.
> > >
> > > Oh, sorry just saw those. I pushed this already, I will check those
> > > anyway and sent additional patch, if needed.
> > >
> >
> > Where has this been pushed to? We're still requiring an Ack from
> userspace/mesa to get new modifiers upstream, right?
> 
> It was pushed to drm-intel-next. To be honest, I was not aware that this 
> requires
> userspace/mesa ack.
> 

Yeah, I don't think much of the process has been documented. Might be good for 
us
to discuss and/or put something together. The ack was something we did in the 
last
cycle and it seemed like something we were going to do for this one as well.

> How do we proceed then? Should I revert and push the fixed version or do we
> wait until IGT part gets merged?
> 

Reverting and waiting for IGT tests to at least be on the list seems like a 
reasonable
plan to me. I also think it's a good idea to continue waiting on an ack from 
mesa as
well. I'll be OOO this week for holidays, but I'm happy to discuss the latter 
bit when
I get back.

-Nanley

> Stan
> 
> >
> > -Nanley
> >
> > > Stan
> > >
> > > >
> > > > -Nanley
> > > >
> > > > > >
> > > > > > On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > > > > > > - Check specifically for DG2, but not the
> > > > > > > Display13(Imre)
> > > > > > >
> > > > > > > v6: - Moved Tile4 assocating struct for modifier/display to
> > > > > > >   the beginning(Imre Deak)
> > > > > > > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > > > > > >   checks(Imre Deak)
> > > > > > > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > > > > > >   (Imre Deak)
> > > > > > >
> > > > > > > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > > > > > > - Removed redundant newline(Imre Deak)
> > > > > > >
> > > > > > > Reviewed-by: Imre Deak 
> > > > > > > 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   |  9 +
> > > > > > >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> > > > > > >  .../drm/i915/display/intel_plane_initial.c|  1 +
> > > > 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
URL   : https://patchwork.freedesktop.org/series/97208/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10917 -> Patchwork_21669


Summary
---

  **WARNING**

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

Participating hosts (40 -> 37)
--

  Additional (3): fi-kbl-soraka fi-icl-u2 fi-icl-y 
  Missing(6): bat-dg1-6 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-jsl-2 
bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [INCOMPLETE][1] ([i915#4547]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  
 Suppressed 

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

  * igt@i915_selftest@live@objects:
- {fi-tgl-dsi}:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-tgl-dsi/igt@i915_selftest@l...@objects.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-tgl-dsi/igt@i915_selftest@l...@objects.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][5] ([fdo#109315]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271]) +31 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

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

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][13] ([i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-icl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-icl-y:   NOTRUN -> [SKIP][15] ([i915#4555]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21669/fi-icl-y/igt@gem_lmem_swapp...@basic.html

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

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

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

  * 

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

[Lisovskiy, Stanislav]

On Tue, Nov 23, 2021 at 05:06:22PM +0200, Chery, Nanley G wrote:
> 
> 
> > -Original Message-
> > From: Lisovskiy, Stanislav 
> > Sent: Tuesday, November 23, 2021 8:37 AM
> > To: Chery, Nanley G 
> > Cc: Nanley Chery ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support
> > 
> > On Tue, Nov 23, 2021 at 02:41:20PM +0200, Chery, Nanley G wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Lisovskiy, Stanislav 
> > > > Sent: Tuesday, November 23, 2021 3:14 AM
> > > > To: Nanley Chery 
> > > > Cc: intel-gfx@lists.freedesktop.org; Chery, Nanley G
> > > > 
> > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format
> > > > support
> > > >
> > > > On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> > > > > Hi Stanislav,
> > > > >
> > > > > Are there IGT tests for this modifier?
> > > >
> > > > Hi Nanley
> > > >
> > > > Yes, there should be plenty of those, not sure they are all sent to
> > > > upstream though.
> > > > We have a separate team doing this.
> > > > That modifier should be added to kms_plane_multiple and many others
> > > >
> > >
> > > Okay, I'll be on the lookout for them.
> > >
> > > > Stan
> > > >
> > >
> > > Looks like you missed the other review comments I left in my prior email.
> > 
> > Oh, sorry just saw those. I pushed this already, I will check those anyway
> > and sent additional patch, if needed.
> > 
> 
> Where has this been pushed to? We're still requiring an Ack from 
> userspace/mesa to get new modifiers upstream, right?

It was pushed to drm-intel-next. To be honest, I was not aware that this 
requires userspace/mesa ack.

How do we proceed then? Should I revert and push the fixed version or do we 
wait until IGT
part gets merged?

Stan

> 
> -Nanley
> 
> > Stan
> > 
> > >
> > > -Nanley
> > >
> > > > >
> > > > > On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > > > > > - Check specifically for DG2, but not the Display13(Imre)
> > > > > >
> > > > > > v6: - Moved Tile4 assocating struct for modifier/display to
> > > > > >   the beginning(Imre Deak)
> > > > > > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > > > > >   checks(Imre Deak)
> > > > > > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > > > > >   (Imre Deak)
> > > > > >
> > > > > > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > > > > > - Removed redundant newline(Imre Deak)
> > > > > >
> > > > > > Reviewed-by: Imre Deak 
> > > > > > 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   |  9 +
> > > > > >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> > > > > >  .../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, 37 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index f3c9208a30b1..7429965d3682 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -7766,6 +7766,7 @@ static int intel_atomic_check_async(struct
> > > > intel_atomic_state *state, struct int
> > > > > > case I915_FORMAT_MOD_X_TILED:
> > > > > > case 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
URL   : https://patchwork.freedesktop.org/series/97208/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8a0b3247925b drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
-:23: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#23: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:1236:
+   wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
+   PSDUNIT_CLKGATE_DIS);

-:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#27: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:1240:
+   wa_write_or(wal,
+   SUBSLICE_UNIT_LEVEL_CLKGATE,

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

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

[Chery, Nanley G]

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, November 23, 2021 8:37 AM
> To: Chery, Nanley G 
> Cc: Nanley Chery ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support
> 
> On Tue, Nov 23, 2021 at 02:41:20PM +0200, Chery, Nanley G wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav 
> > > Sent: Tuesday, November 23, 2021 3:14 AM
> > > To: Nanley Chery 
> > > Cc: intel-gfx@lists.freedesktop.org; Chery, Nanley G
> > > 
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format
> > > support
> > >
> > > On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> > > > Hi Stanislav,
> > > >
> > > > Are there IGT tests for this modifier?
> > >
> > > Hi Nanley
> > >
> > > Yes, there should be plenty of those, not sure they are all sent to
> > > upstream though.
> > > We have a separate team doing this.
> > > That modifier should be added to kms_plane_multiple and many others
> > >
> >
> > Okay, I'll be on the lookout for them.
> >
> > > Stan
> > >
> >
> > Looks like you missed the other review comments I left in my prior email.
> 
> Oh, sorry just saw those. I pushed this already, I will check those anyway
> and sent additional patch, if needed.
> 

Where has this been pushed to? We're still requiring an Ack from userspace/mesa 
to get new modifiers upstream, right?

-Nanley

> Stan
> 
> >
> > -Nanley
> >
> > > >
> > > > On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > > > > - Check specifically for DG2, but not the Display13(Imre)
> > > > >
> > > > > v6: - Moved Tile4 assocating struct for modifier/display to
> > > > >   the beginning(Imre Deak)
> > > > > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > > > >   checks(Imre Deak)
> > > > > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > > > >   (Imre Deak)
> > > > >
> > > > > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > > > > - Removed redundant newline(Imre Deak)
> > > > >
> > > > > Reviewed-by: Imre Deak 
> > > > > 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   |  9 +
> > > > >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> > > > >  .../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, 37 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index f3c9208a30b1..7429965d3682 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -7766,6 +7766,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(>drm,
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > > b/drivers/gpu/drm/i915/display/intel_fb.c
> > > > > index c4a743d0913f..b7f1ef62072c 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > > > +++ 

[Intel-gfx] [PATCH] drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()

[ravitejax . goud . talla]

From: raviteja goud talla 

Bspec page says "Reset: BUS", Accordingly moving w/a's:
Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
Which will resolve guc enabling error

Cc: John Harrison 
Signed-off-by: raviteja goud talla 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a9727447c037..4f7b598d21b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1231,6 +1231,15 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
GAMT_CHKN_BIT_REG,
GAMT_CHKN_DISABLE_L3_COH_PIPE);
 
+   /* Wa_1407352427:icl,ehl */
+   wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
+   PSDUNIT_CLKGATE_DIS);
+
+   /* Wa_1406680159:icl,ehl */
+   wa_write_or(wal,
+   SUBSLICE_UNIT_LEVEL_CLKGATE,
+   GWUNIT_CLKGATE_DIS);
+
/* Wa_1607087056:icl,ehl,jsl */
if (IS_ICELAKE(i915) ||
IS_JSL_EHL_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
@@ -2272,15 +2281,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
 
-   /* Wa_1407352427:icl,ehl */
-   wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
-   PSDUNIT_CLKGATE_DIS);
-
-   /* Wa_1406680159:icl,ehl */
-   wa_write_or(wal,
-   SUBSLICE_UNIT_LEVEL_CLKGATE,
-   GWUNIT_CLKGATE_DIS);
-
/*
 * Wa_1408767742:icl[a2..forever],ehl[all]
 * Wa_1605460711:icl[a0..c0]
-- 
2.30.2

Re: [Intel-gfx] [PATCH bpf] treewide: add missing includes masked by cgroup -> bpf dependency

[Peter Chen]

On 21-11-20 07:26:02, Jakub Kicinski wrote:
> On Sat, 20 Nov 2021 15:30:11 +0800 Peter Chen wrote:
> > > diff --git a/drivers/usb/cdns3/host.c b/drivers/usb/cdns3/host.c
> > > index 84dadfa726aa..9643b905e2d8 100644
> > > --- a/drivers/usb/cdns3/host.c
> > > +++ b/drivers/usb/cdns3/host.c
> > > @@ -10,6 +10,7 @@
> > >   */
> > >  
> > >  #include 
> > > +#include   
> > 
> > Should be "#include "?
> 
> Why? Different files are missing different includes, this one needs
> slab.h:
> 
> ../drivers/usb/cdns3/host.c: In function ‘__cdns_host_init’:
> ../drivers/usb/cdns3/host.c:86:2: error: implicit declaration of function 
> ‘kfree’; did you mean ‘vfree’? [-Werror=implicit-function-declaration]
>   kfree(cdns->xhci_plat_data);
>   ^
>   vfree

Oh, my fault.

Acked-by: Peter Chen 

-- 

Thanks,
Peter Chen

Re: [Intel-gfx] RPM raw-wakeref not held in intel_pxp_fini_hw

[Jason A. Donenfeld]

Hi Daniele,

I'll give it a whirl on my laptop. Thanks.

Jason

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

[Lisovskiy, Stanislav]

On Tue, Nov 23, 2021 at 02:41:20PM +0200, Chery, Nanley G wrote:
> 
> 
> > -Original Message-
> > From: Lisovskiy, Stanislav 
> > Sent: Tuesday, November 23, 2021 3:14 AM
> > To: Nanley Chery 
> > Cc: intel-gfx@lists.freedesktop.org; Chery, Nanley G
> > 
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support
> > 
> > On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> > > Hi Stanislav,
> > >
> > > Are there IGT tests for this modifier?
> > 
> > Hi Nanley
> > 
> > Yes, there should be plenty of those, not sure they
> > are all sent to upstream though.
> > We have a separate team doing this.
> > That modifier should be added to kms_plane_multiple
> > and many others
> > 
> 
> Okay, I'll be on the lookout for them.
> 
> > Stan
> > 
> 
> Looks like you missed the other review comments I left in my prior email.

Oh, sorry just saw those. I pushed this already, I will check those anyway
and sent additional patch, if needed.

Stan

> 
> -Nanley
> 
> > >
> > > On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > > > - Check specifically for DG2, but not the Display13(Imre)
> > > >
> > > > v6: - Moved Tile4 assocating struct for modifier/display to
> > > >   the beginning(Imre Deak)
> > > > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > > >   checks(Imre Deak)
> > > > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > > >   (Imre Deak)
> > > >
> > > > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > > > - Removed redundant newline(Imre Deak)
> > > >
> > > > Reviewed-by: Imre Deak 
> > > > 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   |  9 +
> > > >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> > > >  .../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, 37 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index f3c9208a30b1..7429965d3682 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -7766,6 +7766,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(>drm,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > > > index c4a743d0913f..b7f1ef62072c 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > > > @@ -139,6 +139,9 @@ struct intel_modifier_desc {
> > > >
> > > >  static const struct intel_modifier_desc intel_modifiers[] = {
> > > > {
> > > > +   .modifier = I915_FORMAT_MOD_4_TILED,
> > > > +   .display_ver = { 13, 13 },
> > >
> > > I see that every other modifier has the plane_cap field set. Why is it
> > > okay for it to be zero here?
> > >
> > > > +   }, {
> > > > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > > > .display_ver = { 12, 13 },
> > > > .plane_caps = INTEL_PLANE_CAP_TILING_Y |
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: fixup build failure

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: fixup build failure
URL   : https://patchwork.freedesktop.org/series/97205/
State : failure

== Summary ==

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

[Intel-gfx] [PATCH] drm/i915/ttm: fixup build failure

[Matthew Auld]

drm-intel-gt-next fails to build with:

drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘vm_fault_ttm’:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:862:23: error: too many arguments to 
function ‘ttm_bo_vm_fault_reserved’
  862 | ret = ttm_bo_vm_fault_reserved(vmf, 
vmf->vma->vm_page_prot,
  |   ^~~

Signed-off-by: Matthew Auld 
Cc: Tvrtko Ursulin 
---
 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 753f0f5458b6..02918b990b25 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, )) {
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.31.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pxp: Trybot - run CI with PXP and MEI_PXP enabled (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: Trybot - run CI with PXP and MEI_PXP enabled (rev2)
URL   : https://patchwork.freedesktop.org/series/97145/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10917_full -> Patchwork_21667_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_capture@pi@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-skl1/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_whisper@basic-sync-all:
- shard-kbl:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl4/igt@gem_exec_whis...@basic-sync-all.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-kbl7/igt@gem_exec_whis...@basic-sync-all.html

  * igt@gem_pxp@hw-rejects-pxp-context:
- shard-tglb: [PASS][4] -> [SKIP][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-tglb5/igt@gem_...@hw-rejects-pxp-context.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-tglb1/igt@gem_...@hw-rejects-pxp-context.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +3 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-apl7/igt@gem_...@in-flight-suspend.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-apl8/igt@gem_...@in-flight-suspend.html

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][9] -> [SKIP][10] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-apl8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-iclb5/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_suspend@basic-s3:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20] ([i915#198])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-skl9/igt@gem_exec_susp...@basic-s3.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-skl7/igt@gem_exec_susp...@basic-s3.html

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

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][22] ([i915#2658])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/shard-apl6/igt@gem_pr...@exhaustion.html

  * 

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

[Chery, Nanley G]

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: Tuesday, November 23, 2021 3:14 AM
> To: Nanley Chery 
> Cc: intel-gfx@lists.freedesktop.org; Chery, Nanley G
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Tile 4 plane format support
> 
> On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> > Hi Stanislav,
> >
> > Are there IGT tests for this modifier?
> 
> Hi Nanley
> 
> Yes, there should be plenty of those, not sure they
> are all sent to upstream though.
> We have a separate team doing this.
> That modifier should be added to kms_plane_multiple
> and many others
> 

Okay, I'll be on the lookout for them.

> Stan
> 

Looks like you missed the other review comments I left in my prior email.

-Nanley

> >
> > On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > > - Check specifically for DG2, but not the Display13(Imre)
> > >
> > > v6: - Moved Tile4 assocating struct for modifier/display to
> > >   the beginning(Imre Deak)
> > > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > >   checks(Imre Deak)
> > > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > >   (Imre Deak)
> > >
> > > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > > - Removed redundant newline(Imre Deak)
> > >
> > > Reviewed-by: Imre Deak 
> > > 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   |  9 +
> > >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> > >  .../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, 37 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > > index f3c9208a30b1..7429965d3682 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -7766,6 +7766,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(>drm,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> > > index c4a743d0913f..b7f1ef62072c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > > @@ -139,6 +139,9 @@ struct intel_modifier_desc {
> > >
> > >  static const struct intel_modifier_desc intel_modifiers[] = {
> > > {
> > > +   .modifier = I915_FORMAT_MOD_4_TILED,
> > > +   .display_ver = { 13, 13 },
> >
> > I see that every other modifier has the plane_cap field set. Why is it
> > okay for it to be zero here?
> >
> > > +   }, {
> > > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > > .display_ver = { 12, 13 },
> > > .plane_caps = INTEL_PLANE_CAP_TILING_Y |
> INTEL_PLANE_CAP_CCS_MC,
> > > @@ -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 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Trybot - run CI with PXP and MEI_PXP enabled (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pxp: Trybot - run CI with PXP and MEI_PXP enabled (rev2)
URL   : https://patchwork.freedesktop.org/series/97145/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10917 -> Patchwork_21667


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 35)
--

  Additional (2): fi-kbl-soraka fi-icl-y 
  Missing(7): bat-dg1-6 fi-bsw-cyan fi-apl-guc bat-adlp-6 bat-adlp-4 
bat-jsl-2 bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html

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

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-icl-y:   NOTRUN -> [SKIP][9] ([i915#4555]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-icl-y/igt@gem_lmem_swapp...@basic.html

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

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

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

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

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21667/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#533])
   [20]: 

Re: [Intel-gfx] [PATCH 0/1] Ensure zero alignment on gens < 4

[Tvrtko Ursulin]

On 22/11/2021 19:13, Zbigniew Kempczyński wrote:

In short - we want to enforce alignment == 0 for gen4+ GEM object
settings.

Before we merge this we need to inspect all UMD we expect can use
this. My investigation was narrowed to UMD code:

1. IGT
2. Mesa
3. Media-Driver
4. NEO
5. libdrm
6. xf86-intel-video

I would like to ask subsystem developers / maintainers to confirm
my analysis.

1. IGT:
We've already removed / fixed most of the code where alignment != 0.
What left was few multi-card subtests I'm not able to rewrite due
to lack of such hw (nv + intel on the board).

2. Mesa:
gallium/drivers/iris/iris_batch.c,iris_bufmgr.c - it uses softpinning
only with alignment handled by allocator, so drm_i915_gem_exec_object2
alignment field == 0.

drivers/dri/i965/brw_batch.c,brw_screen.c - it uses relocations but
it is supported by allocator, there're no direct alignment settings
to value != 0.

vulcan/anv_batch_chain.c: drm_i915_gem_exec_object2 objects are
initialized within anv_execbuf_add_bo() and .alignment field
is set to 0 there. There's no other place where I've found vulcan
driver touches it both for softpinning / relocations.

3. Media-Driver:
It contains modified libdrm code and three functions which do
allocations, all of them uses mos_gem_bo_alloc_internal():
- mos_gem_bo_alloc() - internally uses alignment == 0, that's ok
- mos_gem_bo_alloc_tiled() - same as mos_gem_bo_alloc()
- mos_gem_bo_alloc_for_render() - this one passes alignment from
  the caller and it may be != 0. But I haven't found practical
  usage of this function externally (using mos_bo_alloc_for_render()
  wrapper).
There's another userptr allocation function: mos_bo_alloc_userptr()
but it doesn't use alignment.

4. NEO:
Uses softpinning only with alignment == 0:
source/os_interface/linux/drm_buffer_object.cpp:
void BufferObject::fillExecObject() has execObject.alignment = 0;

5. libdrm:
Corresponding functions to Media-Driver:
drm_intel_bo_alloc(), drm_intel_bo_alloc_for_render(),
drm_intel_bo_alloc_userptr() and drm_intel_bo_alloc_tiled().
Alignment field is used in drm_intel_bo_alloc_for_render()
so couple not rewritten IGTs may encounter issue here (alignment
passed in IGTs which still uses libdrm == 4096).

6. xf86-intel-video:
src/sna/kgem.c: _kgem_submit() - alignment is set to 0 so this
shouldn't be a problem.


You also need to figure out not only what codebase currently uses this, 
but what maybe has an older version in the field which used to, right? 
Otherwise kernel upgrade can break someones old userspace which is not 
allowed. Just raising this for consideration if it isn't already on your 
radar.


Regards,

Tvrtko




Cc: Petri Latvala 
Cc: Jason Ekstrand 
Cc: Dmitry Rogozhkin 
Cc: Michal Mrozek 
Cc: José Roberto de Souza 
Cc: Chris Wilson 
Cc: Daniel Vetter 

Zbigniew Kempczyński (1):
   i915/gem/i915_gem_execbuffer: Disallow passing alignment

  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 +++
  1 file changed, 11 insertions(+)

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: placate scripts/kernel-doc

[Matthew Auld]

On Tue, 23 Nov 2021 at 05:56, Patchwork 
wrote:

> *Patch Details*
> *Series:* drm/i915/gem: placate scripts/kernel-doc
> *URL:* https://patchwork.freedesktop.org/series/97190/
> *State:* failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21664/index.html CI
> Bug Log - changes from CI_DRM_10917 -> Patchwork_21664 Summary
>
> *FAILURE*
>
> Serious unknown changes coming with Patchwork_21664 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21664, 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_21664/index.html
> Participating hosts (40 -> 34)
>
> Additional (1): fi-kbl-soraka
> Missing (7): bat-dg1-6 fi-tgl-u2 fi-bsw-cyan bat-adlp-6 bat-adlp-4
> bat-jsl-2 bat-jsl-1
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_21664:
> IGT changes Possible regressions
>
>- igt@gem_exec_suspend@basic-s3:
>   - fi-skl-6600u: PASS
>   
> 
>   -> FAIL
>   
> 
>
>
Lakshmi, another false positive it seems. The patch in question is only
fixing kernel-doc. Pushed to drm-intel-gt-next. Thanks.


>-
>
> Known issues
>
> Here are the changes found in Patchwork_21664 that come from known issues:
> IGT changes Issues hit
>
>-
>
>igt@amdgpu/amd_basic@semaphore:
>- fi-bdw-5557u: NOTRUN -> SKIP
>   
> 
>   (fdo#109271 )
>   +31 similar issues
>-
>
>igt@gem_exec_fence@basic-busy@bcs0:
>- fi-kbl-soraka: NOTRUN -> SKIP
>   
> 
>   (fdo#109271 )
>   +2 similar issues
>-
>
>igt@gem_exec_suspend@basic-s0:
>- fi-kbl-soraka: NOTRUN -> INCOMPLETE
>   
> 
>   (i915#4221 )
>-
>
>igt@gem_huc_copy@huc-copy:
>- fi-kbl-8809g: NOTRUN -> SKIP
>   
> 
>   (fdo#109271  /
>   i915#2190 )
>-
>
>igt@i915_selftest@live@hangcheck:
>- fi-snb-2600: PASS
>   
> 
>   -> INCOMPLETE
>   
> 
>   (i915#3921 )
>-
>
>igt@kms_chamelium@dp-crc-fast:
>- fi-bdw-5557u: NOTRUN -> SKIP
>   
> 
>   (fdo#109271  /
>   fdo#111827 )
>   +8 similar issues
>-
>
>igt@kms_chamelium@hdmi-edid-read:
>- fi-kbl-8809g: NOTRUN -> SKIP
>   
> 
>   (fdo#109271  /
>   fdo#111827 )
>   +8 similar issues
>-
>
>igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
>- fi-kbl-8809g: NOTRUN -> SKIP
>   
> 
>   (fdo#109271  /
>   i915#533 )
>-
>
>igt@kms_psr@cursor_plane_move:
>- fi-kbl-8809g: NOTRUN -> SKIP
>   
> 
>   (fdo#109271 )
>   +41 similar issues
>
> Possible fixes
>
>- igt@core_auth@basic-auth:
>   - fi-kbl-8809g: FAIL
>   
> 
>   -> PASS
>   
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: Async migration (rev10)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Async migration (rev10)
URL   : https://patchwork.freedesktop.org/series/96798/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10917_full -> Patchwork_21666_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_schedule@submit-golden-slice@rcs0:
- shard-kbl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-kbl7/igt@gem_exec_schedule@submit-golden-sl...@rcs0.html

  * igt@kms_vblank@pipe-c-wait-forked-busy-hang:
- shard-kbl:  [PASS][2] -> [INCOMPLETE][3] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl6/igt@kms_vbl...@pipe-c-wait-forked-busy-hang.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-kbl7/igt@kms_vbl...@pipe-c-wait-forked-busy-hang.html

  
 Warnings 

  * igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-kbl:  [SKIP][4] ([fdo#109271]) -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl6/igt@gem_...@verify-pxp-stale-buf-optout-execution.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-kbl7/igt@gem_...@verify-pxp-stale-buf-optout-execution.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-vebox:
- shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109283])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-tglb8/igt@gem_exec_par...@no-vebox.html

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

  * igt@gem_pxp@reject-modify-context-protection-off-2:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4270])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-iclb2/igt@gem_...@reject-modify-context-protection-off-2.html

  * igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-iclb2/igt@gem_render_c...@y-tiled-ccs-to-y-tiled-mc-ccs.html

  * igt@gem_workarounds@suspend-resume:
- shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([i915#456])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/shard-tglb1/igt@gem_workarou...@suspend-resume.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/shard-tglb7/igt@gem_workarou...@suspend-resume.html

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

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

[Tvrtko Ursulin]

On 17/11/2021 22:49, Vinay Belgaumkar wrote:

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.


This partially brings back, from a different angle, the more dynamic 
scheduling behavior which has been lost since bugfix 90a987205c6c 
("drm/i915/gt: Only swap to a random sibling once upon creation").


One day we could experiment with using engine busyness as criteria 
(instead of random). Back in the day busyness was kind of the best 
strategy, although sampled at submit, not at the trailing edge like 
here, but it still may be able to settle down to engine configuration 
better in some scenarios. Only testing could say.


Still, from memory random also wasn't that bad so this should be okay 
for now.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


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(>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(>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(>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 

Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

[Simon Ser]

First off, let me reiterate that this feature would be invaluable as user-space
developers. It's often pretty difficult to figure out the cause of an EINVAL,
we have to ask users to follow complicated instructions [1] to grab DRM logs.
Then have to skim through several megabytes of logs to find the error.

I have a hack [2] which just calls system("sudo dmesg") after a failed atomic
commit, it's been pretty handy. But it's really just a hack, a proper solution
would be awesome.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/DRM-Debugging
[2]: https://gitlab.freedesktop.org/emersion/libliftoff/-/merge_requests/61

> > > > Having a subsystem specific trace buffer would allow subsystem specific
> > > > trace log permissions depending on the sensitivity of the data. But
> > > > doesn't drm output today go to the system log which is typically world
> > > > readable today?

dmesg isn't world-readable these days, it's been changed recently-ish (last
year?) at least on my distribution (Arch). I need root to grab dmesg.

(Maybe we can we just let the DRM master process grab the logs?)

> > > Yes, and that is exactly the problem. The DRM debug output is so high
> > > traffic it would make the system log both unusable due to cruft and
> > > slow down the whole machine. The debug output is only useful when
> > > something went wrong, and at that point it is too late to enable
> > > debugging. That's why a flight recorder with an over-written circular
> > > in-memory buffer is needed.
> >
> > Seans patch reuses enum drm_debug_category to split the tracing
> > stream into 10 sub-streams
> > - how much traffic from each ?
> > - are some sub-streams more valuable for post-mortem ?
> > - any value from further refinement of categories ?
> > - drop irrelevant callsites individually to reduce clutter, extend
> > buffer time/space ?
>
> I think it's hard to predict which sub-streams you are going to need
> before you have a bug to debug. Hence I would err on the side of
> enabling too much. This also means that better or more refined
> categorisation might not be that much of help - or if it is, then are
> the excluded debug messages worth having in the kernel to begin with.
> Well, we're probably not that interested in GPU debugs but just
> everything related to the KMS side, which on the existing categories
> is... everything except half of CORE and DRIVER, maybe? Not sure.

We've been recommending drm.debug=0x19F so far (see wiki linked above).
KMS + PRIME + ATOMIC + LEASE is definitely something we want in, and
CORE + DRIVER contains other useful info. We definitely don't want VBL.

> My feeling is that that could mean in the order of hundreds of log
> events at framerate (e.g. 60 times per second) per each enabled output
> individually. And per DRM device, of course. This is with the
> uninteresting GPU debugs already excluded.

Indeed, successful KMS atomic commits already generate a lot of noise. On my
machine, setting drm.debug=0x19F and running the following command:

sudo dmesg -w | pv >/dev/null

I get 400KiB/s when idling, and 850KiB/s when wiggling the cursor.

> Still, I don't think the flight recorder buffer would need to be
> massive. I suspect it would be enough to hold a few frames' worth which
> is just a split second under active operation. When something happens,
> the userspace stack is likely going to stop on its tracks immediately
> to collect the debug information, which means the flooding should pause
> and the relevant messages don't get overwritten before we get them. In
> a multi-seat system where each device is controlled by a separate
> display server instance, per-device logs would help with this. OTOH,
> multi-seat is not a very common use case I suppose.

There's also the case of multi-GPU where GPU B's logs could clutter GPU A's,
making it harder to understand the cause of an atomic commit failure on GPU A.
So per-device logs would be useful, but not a hard requirement for me, having
*anything* at all would already be a big win.

In my experiments linked above [2], system("sudo dmesg") after atomic commit
failure worked pretty well, and the bottom of the log contained the cause of
the failure. It was pretty useful to system("sudo dmesg -C") before performing
an atomic commit, to be able to only collect the extract of the log relevant to
the atomic commit.

Having some kind of "marker" mechanism could be pretty cool. "Mark" the log
stream before performing an atomic commit (ideally that'd just return e.g. an
uint64 offset), then on failure request the logs collected after that mark.

Re: [Intel-gfx] [PATCH] drm/i915/gem: placate scripts/kernel-doc

[Matthew Auld]

On 23/11/2021 05:09, Randy Dunlap wrote:

Correct kernel-doc warnings in i915_drm_object.c:

i915_gem_object.c:103: warning: expecting prototype for i915_gem_object_fini(). 
Prototype was for __i915_gem_object_fini() instead
i915_gem_object.c:110: warning: This comment starts with '/**', but isn't a 
kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
  * Mark up the object's coherency levels for a given cache_level
i915_gem_object.c:110: warning: missing initial short description on line:
  * Mark up the object's coherency levels for a given cache_level
i915_gem_object.c:457: warning: No description found for return value of 
'i915_gem_object_read_from_page'

Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Thomas Hellström 
Cc: Matthew Auld 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org

Reviewed-by: Matthew Auld 

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

[Tvrtko Ursulin]

On 22/11/2021 18:44, Rodrigo Vivi wrote:

On Wed, Nov 17, 2021 at 02:49:55PM -0800, Vinay Belgaumkar wrote:

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 


Please let's not increase the complexity here, unless we have a very good
and documented reason.

Before trying to implement anything smart like this in the driver I'd like
to see data, power and performance results in different platforms and with
different workloads.


Who has such test suite and test farm which isn't focused to workloads 
from a single customer? ;(


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Fix synchronization of PMU callback with reset

[Tvrtko Ursulin]

On 22/11/2021 23:39, Umesh Nerlige Ramappa wrote:

On Mon, Nov 22, 2021 at 03:44:29PM +, Tvrtko Ursulin wrote:


On 11/11/2021 16:48, Umesh Nerlige Ramappa wrote:

On Thu, Nov 11, 2021 at 02:37:43PM +, Tvrtko Ursulin wrote:


On 04/11/2021 22:04, Umesh Nerlige Ramappa wrote:

On Thu, Nov 04, 2021 at 05:37:37PM +, Tvrtko Ursulin wrote:


On 03/11/2021 22:47, Umesh Nerlige Ramappa wrote:

Since the PMU callback runs in irq context, it synchronizes with gt
reset using the reset count. We could run into a case where the PMU
callback could read the reset count before it is updated. This has a
potential of corrupting the busyness stats.

In addition to the reset count, check if the reset bit is set before
capturing busyness.

In addition save the previous stats only if you intend to update 
them.


Signed-off-by: Umesh Nerlige Ramappa 


---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

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

index 5cc49c0b3889..d83ade77ca07 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1183,6 +1183,7 @@ static ktime_t guc_engine_busyness(struct 
intel_engine_cs *engine, ktime_t *now)

 u64 total, gt_stamp_saved;
 unsigned long flags;
 u32 reset_count;
+    bool in_reset;
 spin_lock_irqsave(>timestamp.lock, flags);
@@ -1191,7 +1192,9 @@ static ktime_t guc_engine_busyness(struct 
intel_engine_cs *engine, ktime_t *now)

  * engine busyness from GuC, so we just use the driver stored
  * copy of busyness. Synchronize with gt reset using 
reset_count.

  */
-    reset_count = i915_reset_count(gpu_error);
+    rcu_read_lock();
+    in_reset = test_bit(I915_RESET_BACKOFF, >reset.flags);
+    rcu_read_unlock();


I don't really understand the point of rcu_read_lock over test_bit 
but I guess you copied it from the trylock loop.


Yes, I don't see other parts of code using the lock though. I can 
drop it.





 *now = ktime_get();
@@ -1201,9 +1204,10 @@ static ktime_t guc_engine_busyness(struct 
intel_engine_cs *engine, ktime_t *now)

  * start_gt_clk is derived from GuC state. To get a consistent
  * view of activity, we query the GuC state only if gt is 
awake.

  */
-    stats_saved = *stats;
-    gt_stamp_saved = guc->timestamp.gt_stamp;
-    if (intel_gt_pm_get_if_awake(gt)) {
+    if (intel_gt_pm_get_if_awake(gt) && !in_reset) {


What is the point of looking at the old value of in_reset here? 
Gut feeling says if there is a race this does not fix it.


I did not figure out from the commit message what does "could read 
the reset count before it is updated" mean?

I thought the point of reading


the reset count twice was that you are sure there was no reset 
while in here, in which case it is safe to update the software 
copy. I don't easily see what test_bit does on top.


This is what I see in the reset flow
---

R1) test_and_set_bit(I915_RESET_BACKOFF, >reset.flags)
R2) atomic_inc(>i915->gpu_error.reset_count)
R3) reset prepare
R4) do the HW reset

The reset count is updated only once above and that's before an 
actual HW reset happens.


PMU callback flow before this patch
---

P1) read reset count
P2) update stats
P3) read reset count
P4) if reset count changed, use old stats. if not use updated stats.

I am concerned that the PMU flow could run after step (R2). Then we 
wrongly conclude that the count stayed the same and no HW reset 
happened.


Here is the problematic sequence: Threads R and P.

R1) test_and_set_bit(I915_RESET_BACKOFF, >reset.flags)
R2) atomic_inc(>i915->gpu_error.reset_count)
P1) read reset count
P2) update stats
P3) read reset count
P4) if reset count changed, use old stats. if not use updated stats.
R3) reset prepare
R4) do the HW reset

Do you agree that this is racy? In thread P we don't know in if the 
reset flag was set or not when we captured the reset count in P1?




PMU callback flow with this patch
---
This would rely on the reset_count only if a reset is not in progress.

P0) test_bit for I915_RESET_BACKOFF
P1) read reset count if not in reset. if in reset, use old stats
P2) update stats
P3) read reset count
P4) if reset count changed, use old stats. if not use updated stats.

Now that I think about it more, I do see one sequence that still 
needs fixing though - P0, R1, R2, P1 - P4. For that, I think I need 
to re-read the BACKOFF bit after reading the reset_count for the 
first time.

Modified PMU callback sequence would be:
--

M0) test_bit for I915_RESET_BACKOFF
M1) read reset count if not in reset, if in reset, use old stats

M1.1) test_bit for I915_RESET_BACKOFF. if set, use old stats. if 
not, use reset_count to synchronize


M2) update stats
M3) read reset count
M4) if reset count changed, use old 

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

[Lisovskiy, Stanislav]

On Fri, Nov 19, 2021 at 03:13:47PM +0200, Mika Kahola wrote:
> 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()]
>

Reviewed-by: Stanislav Lisovskiy 
 
> 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 560383e8c5b6..5fcb393079f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1466,6 +1466,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;
>  
> @@ -1503,7 +1504,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
> 

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

[Lisovskiy, Stanislav]

On Fri, Nov 19, 2021 at 03:13:46PM +0200, Mika Kahola wrote:
> 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()]
>

Reviewed-by: Stanislav Lisovskiy 
 
> 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 3a61d52bdc0e..560383e8c5b6 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1638,6 +1638,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(_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)
> @@ -1645,6 +1665,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. */
> @@ -1688,7 +1710,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 3450818802c2..36f14f243190 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10654,6 +10654,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_MASK  REG_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
> 

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/display/dg2: Sanitize CD clock

[Lisovskiy, Stanislav]

On Fri, Nov 19, 2021 at 03:13:45PM +0200, Mika Kahola wrote:
> 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(-)
> 

Reviewed-by: Stanislav Lisovskiy 

> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 7af4cb965060..3a61d52bdc0e 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, _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 },
> @@ -1735,7 +1740,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(_priv->cdclk.hw, "Current CDCLK");
> @@ -1771,8 +1776,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
> 

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

[Lisovskiy, Stanislav]

On Fri, Nov 19, 2021 at 03:13:44PM +0200, Mika Kahola wrote:
> 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.
> 

Reviewed-by: Stanislav Lisovskiy 

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

Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

[Pekka Paalanen]

On Mon, 22 Nov 2021 15:42:38 -0700
jim.cro...@gmail.com wrote:

> On Mon, Nov 22, 2021 at 2:02 AM Pekka Paalanen  wrote:
> >
> > On Fri, 19 Nov 2021 11:21:36 -0500
> > Jason Baron  wrote:
> >  
> > > On 11/18/21 10:24 AM, Pekka Paalanen wrote:  
> > > > On Thu, 18 Nov 2021 09:29:27 -0500
> > > > Jason Baron  wrote:
> > > >  
> > > >> On 11/16/21 3:46 AM, Pekka Paalanen wrote:  
> > > >>> On Fri, 12 Nov 2021 10:08:41 -0500
> > > >>> Jason Baron  wrote:
> > > >>>  
> > >  On 11/12/21 6:49 AM, Vincent Whitchurch wrote:  
> > > > On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:  
> > > >> Sean Paul proposed, in:
> > > >> https://urldefense.com/v3/__https://patchwork.freedesktop.org/series/78133/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRA8Dki4A$
> > > >> drm/trace: Mirror DRM debug logs to tracefs
> > > >>
> > > >> His patchset's objective is to be able to independently steer some 
> > > >> of
> > > >> the drm.debug stream to an alternate tracing destination, by 
> > > >> splitting
> > > >> drm_debug_enabled() into syslog & trace flavors, and enabling them
> > > >> separately.  2 advantages were identified:
> > > >>
> > > >> 1- syslog is heavyweight, tracefs is much lighter
> > > >> 2- separate selection of enabled categories means less traffic
> > > >>
> > > >> Dynamic-Debug can do 2nd exceedingly well:
> > > >>
> > > >> A- all work is behind jump-label's NOOP, zero off cost.
> > > >> B- exact site selectivity, precisely the useful traffic.
> > > >>can tailor enabled set interactively, at shell.
> > > >>
> > > >> Since the tracefs interface is effective for drm (the threads 
> > > >> suggest
> > > >> so), adding that interface to dynamic-debug has real potential for
> > > >> everyone including drm.
> > > >>
> > > >> if CONFIG_TRACING:
> > > >>
> > > >> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> > > >> available by default to all pr_debugs.  This will likely need some
> > > >> further per-module treatment; perhaps something reflecting 
> > > >> hierarchy
> > > >> of module,file,function,line, maybe with a tuned flattening.
> > > >>
> > > >> endif CONFIG_TRACING
> > > >>
> > > >> Add a new +T flag to enable tracing, independent of +p, and add and
> > > >> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to 
> > > >> encapsulate
> > > >> the flag checks.  Existing code treats T like other flags.  
> > > >
> > > > I posted a patchset a while ago to do something very similar, but 
> > > > that
> > > > got stalled for some reason and I unfortunately didn't follow it up:
> > > >
> > > >  
> > > > https://urldefense.com/v3/__https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchu...@axis.com/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRGytKHPg$
> > > >
> > > > A key difference between that patchset and this patch (besides that
> > > > small fact that I used +x instead of +T) was that my patchset 
> > > > allowed
> > > > the dyndbg trace to be emitted to the main buffer and did not force 
> > > > them
> > > > to be in an instance-specific buffer.  
> > > 
> > >  Yes, I agree I'd prefer that we print here to the 'main' buffer - it
> > >  seems to keep things simpler and easier to combine the output from
> > >  different sources as you mentioned.  
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> I'm not quite sure I understand this discussion, but I would like to
> > > >>> remind you all of what Sean's original work is about:
> > > >>>
> > > >>> Userspace configures DRM tracing into a flight recorder buffer (I 
> > > >>> guess
> > > >>> this is what you refer to "instance-specific buffer").
> > > >>>
> > > >>> Userspace runs happily for months, and then hits a problem: a failure
> > > >>> in the DRM sub-system most likely, e.g. an ioctl that should never
> > > >>> fail, failed. Userspace handles that failure by dumping the flight
> > > >>> recorder buffer into a file and saving or sending a bug report. The
> > > >>> flight recorder contents give a log of all relevant DRM in-kernel
> > > >>> actions leading to the unexpected failure to help developers debug it.
> > > >>>
> > > >>> I don't mind if one can additionally send the flight recorder stream 
> > > >>> to
> > > >>> the main buffer, but I do want the separate flight recorder buffer to
> > > >>> be an option so that a) unrelated things cannot flood the interesting
> > > >>> bits out of it, and b) the scope of collected information is relevant.
> > > >>>
> > > >>> The very reason for this work is problems that are very difficult to
> > > >>> reproduce in practice, either because the problem itself is triggered
> > > >>> very rarely and randomly, or because the end users of the system have
> > > >>> either no knowledge or no access to 

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

[Lisovskiy, Stanislav]

On Mon, Nov 22, 2021 at 05:08:31PM -0500, Nanley Chery wrote:
> Hi Stanislav,
> 
> Are there IGT tests for this modifier?

Hi Nanley

Yes, there should be plenty of those, not sure they
are all sent to upstream though.
We have a separate team doing this.
That modifier should be added to kms_plane_multiple
and many others

Stan

> 
> On Mon, Nov 22, 2021 at 4:14 PM 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 C)
> > - Check specifically for DG2, but not the Display13(Imre)
> >
> > v6: - Moved Tile4 assocating struct for modifier/display to
> >   the beginning(Imre Deak)
> > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> >   checks(Imre Deak)
> > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> >   (Imre Deak)
> >
> > v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
> > - Removed redundant newline(Imre Deak)
> >
> > Reviewed-by: Imre Deak 
> > 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   |  9 +
> >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> >  .../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, 37 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f3c9208a30b1..7429965d3682 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7766,6 +7766,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(>drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index c4a743d0913f..b7f1ef62072c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -139,6 +139,9 @@ struct intel_modifier_desc {
> >
> >  static const struct intel_modifier_desc intel_modifiers[] = {
> > {
> > +   .modifier = I915_FORMAT_MOD_4_TILED,
> > +   .display_ver = { 13, 13 },
> 
> I see that every other modifier has the plane_cap field set. Why is it
> okay for it to be zero here?
> 
> > +   }, {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > .display_ver = { 12, 13 },
> > .plane_caps = INTEL_PLANE_CAP_TILING_Y | 
> > INTEL_PLANE_CAP_CCS_MC,
> > @@ -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;
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index d0c34bc3af6c..0ceabe40d8c9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -898,6 +898,7 @@ static bool tiling_is_valid(struct drm_i915_private 
> > *i915,
> > 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: Async migration (rev10)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Async migration (rev10)
URL   : https://patchwork.freedesktop.org/series/96798/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10917 -> Patchwork_21666


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 35)
--

  Additional (1): fi-kbl-soraka 
  Missing(6): bat-dg1-6 fi-bsw-cyan bat-adlp-6 bat-adlp-4 bat-jsl-2 
bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-kbl-8809g/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_21666/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_21666/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-kbl-8809g/igt@kms_chamel...@hdmi-edid-read.html

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

  * igt@kms_psr@cursor_plane_move:
- fi-kbl-8809g:   NOTRUN -> [SKIP][11] ([fdo#109271]) +41 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-kbl-8809g/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@core_auth@basic-auth:
- fi-kbl-8809g:   [FAIL][12] -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-kbl-8809g/igt@core_a...@basic-auth.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-kbl-8809g/igt@core_a...@basic-auth.html

  
 Warnings 

  * igt@kms_psr@primary_page_flip:
- fi-skl-6600u:   [INCOMPLETE][14] ([i915#4547]) -> [FAIL][15] 
([i915#4547])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10917/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21666/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

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

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

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