[Intel-gfx] ✓ Fi.CI.IGT: success for Drop TGL/DG1 workarounds for pre-prod steppings

[Patchwork]

== Series Details ==

Series: Drop TGL/DG1 workarounds for pre-prod steppings
URL   : https://patchwork.freedesktop.org/series/113453/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12658_full -> Patchwork_113453v1_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s3-devices@smem:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-6/igt@gem_exec_suspend@basic-s3-devi...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-4/igt@gem_exec_suspend@basic-s3-devi...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@perf@stress-open-close:
- shard-glk:  [PASS][5] -> [ABORT][6] ([i915#5213])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-glk5/igt@p...@stress-open-close.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-glk9/igt@p...@stress-open-close.html

  
 Possible fixes 

  * igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-6/igt@drm_fdinfo@i...@rcs0.html

  * igt@drm_read@empty-block:
- {shard-rkl}:[SKIP][9] ([i915#4098]) -> [PASS][10] +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-3/igt@drm_r...@empty-block.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-6/igt@drm_r...@empty-block.html

  * igt@fbdev@unaligned-read:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-2/igt@fb...@unaligned-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-6/igt@fb...@unaligned-read.html

  * igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][13] ([fdo#103375]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-3/igt@gem_...@in-flight-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-6/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_capture@pi@vcs0:
- {shard-rkl}:[ABORT][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-6/igt@gem_exec_capture@p...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-5/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}:   [FAIL][17] ([i915#2842]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-tglu-5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-tglu-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-3/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html

  * igt@gem_mmap_wc@set-cache-level:
- {shard-rkl}:[SKIP][21] ([i915#1850]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-4/igt@gem_mmap...@set-cache-level.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/shard-rkl-6/igt@gem_mmap...@set-cache-level.html

  * igt@gem_pwrite@basic-self:
- {shard-rkl}:[SKIP][23] ([i915#3282]) -> [PASS][24] +4 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/shard-rkl-3/igt@gem_pwr...@basic-self.html
   [24]: 

Re: [Intel-gfx] [PATCH] drm/i915/pcode: Wait 10 seconds for pcode to settle

[Gwan-gyeong Mun]

On 1/27/23 11:00 AM, Andi Shyti wrote:

Hi Gwan-gyeong,

thanks for the review and the thorough explanation.

On Fri, Jan 27, 2023 at 08:50:26AM +0200, Gwan-gyeong Mun wrote:



On 1/11/23 5:36 PM, Andi Shyti wrote:

On Wed, Jan 11, 2023 at 03:18:38PM +0200, Jani Nikula wrote:

On Wed, 11 Jan 2023, Andi Shyti  wrote:

From: Aravind Iddamsetty 

During module load not all the punit transaction have completed
and we might end up timing out, as shown by the following
warning:


Root cause?


Hi Andi, looking at the log where this problem is reported,

https://gitlab.freedesktop.org/drm/intel/-/issues/7814

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1294/bat-atsm-1/igt@i915_module_l...@resize-bar.html#dmesg-warnings17324

<4> [268.276908] i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)

In the code above, the call stack is output, and the return value of
intel_pcode_init() returns -11 (-EAGAIN).

<3> [268.329058] i915 :4d:00.0: [drm] *ERROR* gt0: intel_pcode_init
failed -11


If you simplify the function call flow, you can see it as below. (The call
of _wait_for(COND, timeout_base_ms * 1000, 10, 10) in skl_pcode_request() is
omitted)

-
intel_pcode_init()
  |
  +-> skl_pcode_request(uncore, DG1_PCODE_STATUS,
DG1_UNCORE_GET_INIT_STATUS,
DG1_UNCORE_INIT_STATUS_COMPLETE,
DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
|
+-> skl_pcode_try_request()
  |
  +->  *status = __snb_pcode_rw(uncore, mbox, , NULL,
500, 0, true);

-
static int __snb_pcode_rw(struct intel_uncore *uncore, u32 mbox,
  u32 *val, u32 *val1,
  int fast_timeout_us, int slow_timeout_ms,
  bool is_read)
{
...

if (intel_uncore_read_fw(uncore, GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY)
return -EAGAIN;

intel_uncore_write_fw(uncore, GEN6_PCODE_DATA, *val);
intel_uncore_write_fw(uncore, GEN6_PCODE_DATA1, val1 ? *val1 : 0);
intel_uncore_write_fw(uncore,
  GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);

if (__intel_wait_for_register_fw(uncore,
 GEN6_PCODE_MAILBOX,
 GEN6_PCODE_READY, 0,
 fast_timeout_us,
 slow_timeout_ms,
 ))
return -ETIMEDOUT;

...
}
-

The case where skl_pcode_request() returns -EAGAIN can be considered as the
following scenario.
1. 1. When checking the GEN6_PCODE_MAILBOX register status before writing
the value to the GEN6_PCODE_DATA register in __snb_pcode_rw(), it is always
BUSY


correct! We fail with EAGAIN because we are not able to
communicate with the punit because the punit is busy.

Talking about this case we are in boot time and the gpu is
performing its boot routine, the punit as well. While the punit
is working we try communicate with it, but unfortunately, being
busy, we fail with -EAGAIN exactly where you pointed.

Adding an extra wait_for_register_fw, i.e. waiting until the
PCODE_READY register tells that the punit is ready, makes sure
that the read/write will succeed.

Thus Chris has added a 10 seconds wait before the very first read
and write. If the punit is not ready we don't fail with -EAGAIN
and give up the driver loading as it happens now. But we give it
another chance trying to probe it again later.


2. _wait_for(COND, timeout_base_ms * 1000, 10, 10) of skl_pcode_request()
returns -EAGAIN if the GEN6_PCODE_MAILBOX register indicates BUSY even after
waiting 500us after writing a value to the GEN6_PCODE_DATA register in
__snb_pcode_rw()


Isn't it the same as '1'?


(Even if skl_pcode_request() gives a timeout of 180 seconds, the time used
each time __snb_pcode_rw() is called is up to 500us. The rest of the time is
used for sleep.)


There is one big, massive, huge difference... the timeout in
skl_pcode_request() after the read/write, not before. So that at
the first communication we fail, return -EAGAIN and give up
probing without starting any timer.

Be aware of the fact that the timeout is not for the current
communication, but for the next one. De facto we start the
timeout after communicating, this makes sure that the next
communication will work.

But no one makes sure that the very first communication works
during probe. Thus the extra wait.


Hi Andi,
In the call flow invoked by intel_pcode_init(), I've added brief 
comments where further clarification is needed in this scenario, and a 
description of the suspicious scenario at the bottom.

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix missing ecodes

[John Harrison]

On 1/26/2023 11:17, Teres Alexis, Alan Previn wrote:

Firstly, thanks for catching this miss.
Since I only have one trivial nit and one non-blocker ask.
and the non-blocker ask will not impact the patch intent as it merely
tweaks an existing debug message, I believe we have an rb:

Reviewed-by: Alan Previn 

On Tue, 2023-01-24 at 16:49 -0800, Harrison, John C wrote:

From: John Harrison 

Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
in execlist mode. In GuC mode, the register state exists in a separate
list of arbitrary register address/value pairs rather than the named
entry structure. So, search through that list to find the two exciting
registers and copy them over to the structure's named members.

Signed-off-by: John Harrison 
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Cc: Alan Previn 
Cc: Umesh Nerlige Ramappa 
Cc: Lucas De Marchi 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Aravind Iddamsetty 
Cc: Michael Cheng 
Cc: Matthew Brost 
Cc: Bruce Chang 
Cc: Daniele Ceraolo Spurio 
Cc: Matthew Auld 
---
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 22 +++
  1 file changed, 22 insertions(+)

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 1c1b85073b4bd..4e0b06ceed96d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1571,6 +1571,27 @@ int intel_guc_capture_print_engine_node(struct 
drm_i915_error_state_buf *ebuf,
  
  #endif //CONFIG_DRM_I915_CAPTURE_ERROR
  
+static void guc_capture_find_ecode(struct intel_engine_coredump *ee)

+{
+   struct gcap_reg_list_info *reginfo;
+   struct guc_mmio_reg *regs;
+   i915_reg_t reg_ipehr = RING_IPEHR(0);
+   i915_reg_t reg_instdone = RING_INSTDONE(0);
+   int i;
+
+   if (!ee->guc_capture_node)
+   return;
+
+   reginfo = ee->guc_capture_node->reginfo + 
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE;
+   regs = reginfo->regs;
+   for (i = 0; i < reginfo->num_regs; i++) {
+   if (regs[i].offset == reg_ipehr.reg)
+   ee->ipehr = regs[i].value;
+   if (regs[i].offset == reg_instdone.reg)

nit: "else if"?

+   ee->instdone.instdone = regs[i].value;
+   }
+}
+
  void intel_guc_capture_free_node(struct intel_engine_coredump *ee)
  {
 if (!ee || !ee->guc_capture_node)
@@ -1612,6 +1633,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt 
*gt,
 list_del(>link);
 ee->guc_capture_node = n;
 ee->capture = guc->capture;
+   guc_capture_find_ecode(ee);
 return;
 }
 }

alan: only one non-blocker request:
while we are here, could we update the debug message when we can't find a 
matching captured node?
Current code:
drm_dbg(>drm, "GuC capture can't match ee to node\n");
New suggestion:
drm_dbg(>drm, "GuC capture can't find node for ee-ctx: lcra = 0x%08x | 
gucid = 0x%08x\n",
ce->lrc.lrca, ce->guc_id.id);
Regarding the search test, there seem to be some incorrect terms in 
there. The if itself is also not the easiest to read with some terms 
across multiple lines and other lines with multiple terms. Breaking it down:

    (n->eng_inst == GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id) &&
    n->eng_class == GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id) &&
    n->guc_id &&
Why does the GuC id have to be non zero? Zero is a valid id. And even if 
it isn't, comparing to ce->guc_id.id is sufficient to filter out 
anything bad.

    n->guc_id == ce->guc_id.id &&
    (n->lrca & CTX_GTT_ADDRESS_MASK) &&
Again, address zero is not invalid but the next test makes this one 
redundant anyway.
    (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca & 
CTX_GTT_ADDRESS_MASK)) {


Any objection to dropping the !zero tests and reformatting the whole thing?

John.

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/guc: Add GuC oriented print macros

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

While we do have GT oriented print macros, add few more GuC
specific to have common look and feel across all messages
related to the GuC and to avoid chasing the gt pointer.

We will use these macros shortly in upcoming patches.

Signed-off-by: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 48 
  1 file changed, 48 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_print.h

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
new file mode 100644
index ..e75989d4ba06
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef __INTEL_GUC_PRINT__
+#define __INTEL_GUC_PRINT__
+
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
+
+#define guc_printk(_guc, _level, _fmt, ...) \
+   gt_##_level(guc_to_gt(_guc), "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_err(_guc, _fmt, ...) \
+   guc_printk((_guc), err, _fmt, ##__VA_ARGS__)
+
+#define guc_warn(_guc, _fmt, ...) \
+   guc_printk((_guc), warn, _fmt, ##__VA_ARGS__)
+
+#define guc_notice(_guc, _fmt, ...) \
+   guc_printk((_guc), notice, _fmt, ##__VA_ARGS__)
+
+#define guc_info(_guc, _fmt, ...) \
+   guc_printk((_guc), info, _fmt, ##__VA_ARGS__)
+
+#define guc_dbg(_guc, _fmt, ...) \
+   guc_printk((_guc), dbg, _fmt, ##__VA_ARGS__)
+
+#define guc_err_ratelimited(_guc, _fmt, ...) \
+   guc_printk((_guc), err_ratelimited, _fmt, ##__VA_ARGS__)
+
+#define guc_probe_error(_guc, _fmt, ...) \
+   guc_printk((_guc), probe_error, _fmt, ##__VA_ARGS__)
+
+#define guc_WARN(_guc, _cond, _fmt, ...) \
+   gt_WARN(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_WARN_ONCE(_guc, _cond, _fmt, ...) \
+   gt_WARN_ONCE(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_WARN_ON(_guc, _cond) \
+   gt_WARN(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON", 
__stringify(_cond))
+
+#define guc_WARN_ON_ONCE(_guc, _cond) \
+   gt_WARN_ONCE(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON_ONCE", 
__stringify(_cond))
+
+#endif /* __INTEL_GUC_PRINT__ */

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/guc: Update GT/GuC messages in intel_uc.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: pass gt to print_fw_ver

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 80 +--
  1 file changed, 39 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 9a8a1abf71d7..a750966ddcab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -6,11 +6,13 @@
  #include 
  
  #include "gt/intel_gt.h"

+#include "gt/intel_gt_print.h"
  #include "gt/intel_reset.h"
  #include "intel_gsc_fw.h"
  #include "intel_gsc_uc.h"
  #include "intel_guc.h"
  #include "intel_guc_ads.h"
+#include "intel_guc_print.h"
  #include "intel_guc_submission.h"
  #include "gt/intel_rps.h"
  #include "intel_uc.h"
@@ -67,14 +69,14 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
  
  	ret = intel_reset_guc(gt);

if (ret) {
-   DRM_ERROR("Failed to reset GuC, ret = %d\n", ret);
+   gt_err(gt, "Failed to reset GuC, ret = %d\n", ret);
return ret;
}
  
  	guc_status = intel_uncore_read(gt->uncore, GUC_STATUS);

-   WARN(!(guc_status & GS_MIA_IN_RESET),
-"GuC status: 0x%x, MIA core expected to be in reset\n",
-guc_status);
+   gt_WARN(gt, !(guc_status & GS_MIA_IN_RESET),
+   "GuC status: 0x%x, MIA core expected to be in reset\n",
+   guc_status);
  
  	return ret;

  }
@@ -252,15 +254,13 @@ static int guc_enable_communication(struct intel_guc *guc)
intel_guc_ct_event_handler(>ct);
spin_unlock_irq(gt->irq_lock);
  
-	drm_dbg(>drm, "GuC communication enabled\n");

+   guc_dbg(guc, "communication enabled\n");
  
  	return 0;

  }
  
  static void guc_disable_communication(struct intel_guc *guc)

  {
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
-
/*
 * Events generated during or after CT disable are logged by guc in
 * via mmio. Make sure the register is clear before disabling CT since
@@ -280,11 +280,12 @@ static void guc_disable_communication(struct intel_guc 
*guc)
 */
guc_get_mmio_msg(guc);
  
-	drm_dbg(>drm, "GuC communication disabled\n");

+   guc_dbg(guc, "communication disabled\n");
  }
  
  static void __uc_fetch_firmwares(struct intel_uc *uc)

  {
+   struct intel_gt *gt = uc_to_gt(uc);
int err;
  
  	GEM_BUG_ON(!intel_uc_wants_guc(uc));

@@ -293,15 +294,13 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
if (err) {
/* Make sure we transition out of transient "SELECTED" state */
if (intel_uc_wants_huc(uc)) {
-   drm_dbg(_to_gt(uc)->i915->drm,
-   "Failed to fetch GuC: %d disabling HuC\n", err);
+   gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling 
HuC\n", ERR_PTR(err));
intel_uc_fw_change_status(>huc.fw,
  INTEL_UC_FIRMWARE_ERROR);
}
  
  		if (intel_uc_wants_gsc_uc(uc)) {

-   drm_dbg(_to_gt(uc)->i915->drm,
-   "Failed to fetch GuC: %d disabling GSC\n", err);
+   gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling 
GSC\n", ERR_PTR(err));
intel_uc_fw_change_status(>gsc.fw,
  INTEL_UC_FIRMWARE_ERROR);
}
@@ -382,7 +381,7 @@ static int uc_init_wopcm(struct intel_uc *uc)
int err;
  
  	if (unlikely(!base || !size)) {

-   i915_probe_error(gt->i915, "Unsuccessful WOPCM partitioning\n");
+   gt_probe_error(gt, "Unsuccessful WOPCM partitioning\n");
return -E2BIG;
}
  
@@ -413,13 +412,13 @@ static int uc_init_wopcm(struct intel_uc *uc)

return 0;
  
  err_out:

-   i915_probe_error(gt->i915, "Failed to init uC WOPCM registers!\n");
-   i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
-i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
-intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
-   i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
-i915_mmio_reg_offset(GUC_WOPCM_SIZE),
-intel_uncore_read(uncore, GUC_WOPCM_SIZE));
+   gt_probe_error(gt, "Failed to init uC WOPCM registers!\n");
+   gt_probe_error(gt, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
+  i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
+  intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+   gt_probe_error(gt, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
+  i915_mmio_reg_offset(GUC_WOPCM_SIZE),
+  intel_uncore_read(uncore, GUC_WOPCM_SIZE));
  
  	return err;

 

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/guc: Update GuC messages in intel_guc_submission.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: improve few existing messages

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ---
  1 file changed, 26 insertions(+), 35 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 b436dd7f12e4..b2250181f31b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -27,6 +27,7 @@
  
  #include "intel_guc_ads.h"

  #include "intel_guc_capture.h"
+#include "intel_guc_print.h"
  #include "intel_guc_submission.h"
  
  #include "i915_drv.h"

@@ -1443,8 +1444,7 @@ static void guc_init_engine_stats(struct intel_guc *guc)
int ret = guc_action_enable_usage_stats(guc);
  
  		if (ret)

-   drm_err(>i915->drm,
-   "Failed to enable usage stats: %d!\n", ret);
+   guc_err(guc, "Failed to enable usage stats: %pe\n", 
ERR_PTR(ret));
}
  }
  
@@ -3585,8 +3585,7 @@ static int guc_request_alloc(struct i915_request *rq)

intel_context_sched_disable_unpin(ce);
else if (intel_context_is_closed(ce))
if (wait_for(context_close_done(ce), 1500))
-   drm_warn(_to_gt(guc)->i915->drm,
-"timed out waiting on context sched close before 
realloc\n");
+   guc_warn(guc, "timed out waiting on context sched close 
before realloc\n");
/*
 * Call pin_guc_id here rather than in the pinning step as with
 * dma_resv, contexts can be repeatedly pinned / unpinned trashing the
@@ -4349,11 +4348,14 @@ static int __guc_action_set_scheduling_policies(struct 
intel_guc *guc,
  
  	ret = intel_guc_send(guc, (u32 *)>h2g,

 __guc_scheduling_policy_action_size(policy));
-   if (ret < 0)
+   if (ret < 0) {
+   guc_probe_error(guc, "Failed to configure global scheduling 
policies: %pe!\n",
+   ERR_PTR(ret));
return ret;
+   }
  
  	if (ret != policy->count) {

-   drm_warn(_to_gt(guc)->i915->drm, "GuC global scheduler policy 
processed %d of %d KLVs!",
+   guc_warn(guc, "global scheduler policy processed %d of %d 
KLVs!",
 ret, policy->count);
if (ret > policy->count)
return -EPROTO;
@@ -4367,7 +4369,7 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
struct scheduling_policy policy;
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
-   int ret = 0;
+   int ret;
  
  	if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 1, 0))

return 0;
@@ -4385,10 +4387,6 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
yield, ARRAY_SIZE(yield));
  
  		ret = __guc_action_set_scheduling_policies(guc, );

-   if (ret)
-   i915_probe_error(gt->i915,
-"Failed to configure global scheduling 
policies: %pe!\n",
-ERR_PTR(ret));
}
  
  	return ret;

@@ -4487,21 +4485,18 @@ g2h_context_lookup(struct intel_guc *guc, u32 ctx_id)
struct intel_context *ce;
  
  	if (unlikely(ctx_id >= GUC_MAX_CONTEXT_ID)) {

-   drm_err(_to_gt(guc)->i915->drm,
-   "Invalid ctx_id %u\n", ctx_id);
+   guc_err(guc, "Invalid ctx_id %u\n", ctx_id);
return NULL;
}
  
  	ce = __get_context(guc, ctx_id);

if (unlikely(!ce)) {
-   drm_err(_to_gt(guc)->i915->drm,
-   "Context is NULL, ctx_id %u\n", ctx_id);
+   guc_err(guc, "Context is NULL, ctx_id %u\n", ctx_id);
return NULL;
}
  
  	if (unlikely(intel_context_is_child(ce))) {

-   drm_err(_to_gt(guc)->i915->drm,
-   "Context is child, ctx_id %u\n", ctx_id);
+   guc_err(guc, "Context is child, ctx_id %u\n", ctx_id);
return NULL;
}
  
@@ -4516,7 +4511,7 @@ int intel_guc_deregister_done_process_msg(struct intel_guc *guc,

u32 ctx_id;
  
  	if (unlikely(len < 1)) {

-   drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+   guc_err(guc, "Invalid length %u\n", len);
return -EPROTO;
}
ctx_id = msg[0];
@@ -4568,7 +4563,7 @@ int intel_guc_sched_done_process_msg(struct intel_guc 
*guc,
u32 ctx_id;
  
  	if (unlikely(len < 2)) {

-   drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+   guc_err(guc, "Invalid length %u\n", 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/guc: Update GuC messages in intel_guc_log.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop redundant GuC strings, minor improvements

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 37 --
  1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 68331c538b0a..290bb996b667 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -12,6 +12,7 @@
  #include "i915_memcpy.h"
  #include "intel_guc_capture.h"
  #include "intel_guc_log.h"
+#include "intel_guc_print.h"
  
  #if defined(CONFIG_DRM_I915_DEBUG_GUC)

  #define GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE SZ_2M
@@ -39,7 +40,6 @@ struct guc_log_section {
  static void _guc_log_init_sizes(struct intel_guc_log *log)
  {
struct intel_guc *guc = log_to_guc(log);
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
static const struct guc_log_section sections[GUC_LOG_SECTIONS_LIMIT] = {
{
GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT,
@@ -82,12 +82,12 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
}
  
  		if (!IS_ALIGNED(log->sizes[i].bytes, log->sizes[i].units))

-   drm_err(>drm, "Mis-aligned GuC log %s size: 0x%X vs 
0x%X!",
+   guc_err(guc, "Mis-aligned log %s size: 0x%X vs 0x%X!\n",
sections[i].name, log->sizes[i].bytes, 
log->sizes[i].units);
log->sizes[i].count = log->sizes[i].bytes / log->sizes[i].units;
  
  		if (!log->sizes[i].count) {

-   drm_err(>drm, "Zero GuC log %s size!", 
sections[i].name);
+   guc_err(guc, "Zero log %s size!\n", sections[i].name);
} else {
/* Size is +1 unit */
log->sizes[i].count--;
@@ -95,15 +95,17 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
  
  		/* Clip to field size */

if (log->sizes[i].count > sections[i].max) {
-   drm_err(>drm, "GuC log %s size too large: %d vs 
%d!",
+   guc_err(guc, "log %s size too large: %d vs %d!\n",
sections[i].name, log->sizes[i].count + 1, 
sections[i].max + 1);
log->sizes[i].count = sections[i].max;
}
}
  
  	if (log->sizes[GUC_LOG_SECTIONS_CRASH].units != log->sizes[GUC_LOG_SECTIONS_DEBUG].units) {

-   drm_err(>drm, "Unit mis-match for GuC log crash and debug 
sections: %d vs %d!",
+   guc_err(guc, "Unit mis-match between log sections: %s = %d vs %s = 
%d!\n",
+   sections[GUC_LOG_SECTIONS_CRASH].name,
log->sizes[GUC_LOG_SECTIONS_CRASH].units,
+   sections[GUC_LOG_SECTIONS_DEBUG].name,
Sorry, didn't get to reply to your comment in time. This can only be a 
mis-match between crash and debug. And the 'name' field is just a string 
version of the array index enum. So I would have just gone with "Unit 
mismatch for crash and debug sections: %d vs %d".




log->sizes[GUC_LOG_SECTIONS_DEBUG].units);
log->sizes[GUC_LOG_SECTIONS_CRASH].units = 
log->sizes[GUC_LOG_SECTIONS_DEBUG].units;
log->sizes[GUC_LOG_SECTIONS_CRASH].count = 0;
@@ -374,6 +376,7 @@ size_t intel_guc_get_log_buffer_offset(struct intel_guc_log 
*log,
  
  static void _guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)

  {
+   struct intel_guc *guc = log_to_guc(log);
unsigned int buffer_size, read_offset, write_offset, bytes_to_copy, 
full_cnt;
struct guc_log_buffer_state *log_buf_state, *log_buf_snapshot_state;
struct guc_log_buffer_state log_buf_state_local;
@@ -383,7 +386,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
  
  	mutex_lock(>relay.lock);
  
-	if (WARN_ON(!intel_guc_log_relay_created(log)))

+   if (guc_WARN_ON(guc, !intel_guc_log_relay_created(log)))
goto out_unlock;
  
  	/* Get the pointer to shared GuC log buffer */

@@ -398,7 +401,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
 * Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
-   DRM_ERROR_RATELIMITED("no sub-buffer to copy general logs\n");
+   guc_err_ratelimited(guc, "no sub-buffer to copy general 
logs\n");
log->relay.full_count++;
  
  		goto out_unlock;

@@ -451,7 +454,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
write_offset = buffer_size;
} else if (unlikely((read_offset > buffer_size) ||

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/guc: Update GuC messages in intel_guc_ct.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop unused helpers

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 23 ---
  1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 2b22065e87bf..1803a633ed64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -11,38 +11,23 @@
  
  #include "i915_drv.h"

  #include "intel_guc_ct.h"
-#include "gt/intel_gt.h"
+#include "intel_guc_print.h"
  
  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)

  {
return container_of(ct, struct intel_guc, ct);
  }
  
-static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)

-{
-   return guc_to_gt(ct_to_guc(ct));
-}
-
-static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
-{
-   return ct_to_gt(ct)->i915;
-}
-
-static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
-{
-   return _to_i915(ct)->drm;
-}
-
  #define CT_ERROR(_ct, _fmt, ...) \
-   drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_err(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
  #ifdef CONFIG_DRM_I915_DEBUG_GUC
  #define CT_DEBUG(_ct, _fmt, ...) \
-   drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_dbg(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
  #else
  #define CT_DEBUG(...) do { } while (0)
  #endif
  #define CT_PROBE_ERROR(_ct, _fmt, ...) \
-   i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_probe_error(ct_to_guc(ct), "CT: " _fmt, ##__VA_ARGS__)
  
  /**

   * DOC: CTB Blob

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915/guc: Update GuC messages in intel_guc.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop now redundant "GuC" word from the message

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c | 31 +-
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 1bccc175f9e6..d76508fa3af7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -11,6 +11,7 @@
  #include "intel_guc.h"
  #include "intel_guc_ads.h"
  #include "intel_guc_capture.h"
+#include "intel_guc_print.h"
  #include "intel_guc_slpc.h"
  #include "intel_guc_submission.h"
  #include "i915_drv.h"
@@ -94,8 +95,8 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
  
  	spin_lock_irq(gt->irq_lock);

-   WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
+   guc_WARN_ON_ONCE(guc, intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(gt->irq_lock);
  
@@ -342,7 +343,7 @@ static void guc_init_params(struct intel_guc *guc)

params[GUC_CTL_DEVID] = guc_ctl_devid(guc);
  
  	for (i = 0; i < GUC_CTL_MAX_DWORDS; i++)

-   DRM_DEBUG_DRIVER("param[%2d] = %#x\n", i, params[i]);
+   guc_dbg(guc, "param[%2d] = %#x\n", i, params[i]);
  }
  
  /*

@@ -389,7 +390,6 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct 
drm_printer *p)
  
  int intel_guc_init(struct intel_guc *guc)

  {
-   struct intel_gt *gt = guc_to_gt(guc);
int ret;
  
  	ret = intel_uc_fw_init(>fw);

@@ -451,7 +451,7 @@ int intel_guc_init(struct intel_guc *guc)
intel_uc_fw_fini(>fw);
  out:
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
-   i915_probe_error(gt->i915, "failed with %d\n", ret);
+   guc_probe_error(guc, "failed with %pe\n", ERR_PTR(ret));
return ret;
  }
  
@@ -480,7 +480,6 @@ void intel_guc_fini(struct intel_guc *guc)

  int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
  {
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
u32 header;
int i;
@@ -515,7 +514,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
   10, 10, );
if (unlikely(ret)) {
  timeout:
-   drm_err(>drm, "mmio request %#x: no reply %x\n",
+   guc_err(guc, "mmio request %#x: no reply %x\n",
request[0], header);
goto out;
}
@@ -537,7 +536,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == 
GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
  
-		drm_dbg(>drm, "mmio request %#x: retrying, reason %u\n",

+   guc_dbg(guc, "mmio request %#x: retrying, reason %u\n",
request[0], reason);
goto retry;
}
@@ -546,7 +545,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
  
-		drm_err(>drm, "mmio request %#x: failure %x/%u\n",

+   guc_err(guc, "mmio request %#x: failure %x/%u\n",
request[0], error, hint);
ret = -ENXIO;
goto out;
@@ -554,7 +553,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
  
  	if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {

  proto:
-   drm_err(>drm, "mmio request %#x: unexpected reply %#x\n",
+   guc_err(guc, "mmio request %#x: unexpected reply %#x\n",
request[0], header);
ret = -EPROTO;
goto out;
@@ -597,9 +596,9 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc 
*guc,
msg = payload[0] & guc->msg_enabled_mask;
  
  	if (msg & INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)

-   drm_err(_to_gt(guc)->i915->drm, "Received early GuC crash dump 
notification!\n");
+   guc_err(guc, "Received early crash dump notification!\n");
if (msg & INTEL_GUC_RECV_MSG_EXCEPTION)
-   drm_err(_to_gt(guc)->i915->drm, "Received early GuC exception 
notification!\n");
+   guc_err(guc, "Received early exception notification!\n");
  
  	return 0;

  }
@@ -653,7 +652,8 

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tejun Heo]

On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote:
...
> + /*
> +  * 1st pass - reset working values and update hierarchical weights and
> +  * GPU utilisation.
> +  */
> + if (!__start_scanning(root, period_us))
> + goto out_retry; /*
> +  * Always come back later if scanner races with
> +  * core cgroup management. (Repeated pattern.)
> +  */
> +
> + css_for_each_descendant_pre(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> + struct cgroup_subsys_state *css;
> + unsigned int over_weights = 0;
> + u64 unused_us = 0;
> +
> + if (!css_tryget_online(node))
> + goto out_retry;
> +
> + /*
> +  * 2nd pass - calculate initial budgets, mark over budget
> +  * siblings and add up unused budget for the group.
> +  */
> + css_for_each_child(css, >css) {
> + struct drm_cgroup_state *sibling = css_to_drmcs(css);
> +
> + if (!css_tryget_online(css)) {
> + css_put(node);
> + goto out_retry;
> + }
> +
> + sibling->per_s_budget_us  =
> + DIV_ROUND_UP_ULL(drmcs->per_s_budget_us *
> +  sibling->weight,
> +  drmcs->sum_children_weights);
> +
> + sibling->over = sibling->active_us >
> + sibling->per_s_budget_us;
> + if (sibling->over)
> + over_weights += sibling->weight;
> + else
> + unused_us += sibling->per_s_budget_us -
> +  sibling->active_us;
> +
> + css_put(css);
> + }
> +
> + /*
> +  * 3rd pass - spread unused budget according to relative weights
> +  * of over budget siblings.
> +  */
> + css_for_each_child(css, >css) {
> + struct drm_cgroup_state *sibling = css_to_drmcs(css);
> +
> + if (!css_tryget_online(css)) {
> + css_put(node);
> + goto out_retry;
> + }
> +
> + if (sibling->over) {
> + u64 budget_us =
> + DIV_ROUND_UP_ULL(unused_us *
> +  sibling->weight,
> +  over_weights);
> + sibling->per_s_budget_us += budget_us;
> + sibling->over = sibling->active_us  >
> + sibling->per_s_budget_us;
> + }
> +
> + css_put(css);
> + }
> +
> + css_put(node);
> + }
> +
> + /*
> +  * 4th pass - send out over/under budget notifications.
> +  */
> + css_for_each_descendant_post(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> +
> + if (!css_tryget_online(node))
> + goto out_retry;
> +
> + if (drmcs->over || drmcs->over_budget)
> + signal_drm_budget(drmcs,
> +   drmcs->active_us,
> +   drmcs->per_s_budget_us);
> + drmcs->over_budget = drmcs->over;
> +
> + css_put(node);
> + }

It keeps bothering me that the distribution logic has no memory. Maybe this
is good enough for coarse control with long cycle durations but it likely
will get in trouble if pushed to finer grained control. State keeping
doesn't require a lot of complexity. The only state that needs tracking is
each cgroup's vtime and then the core should be able to tell specific
drivers how much each cgroup is over or under fairly accurately at any given
time.

That said, this isn't a blocker. What's implemented can work well enough
with coarse enough time grain and that might be enough for the time being
and we can get back to it later. I think Michal already mentioned it but it
might be a good idea to track active and inactive cgroups and build the
weight tree with only active ones. There are machines with a lot of mostly
idle cgroups (> tens of thousands) and tree wide scanning even at low
frequency can become a pretty bad bottleneck.

Thanks.

-- 
tejun

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3

[Teres Alexis, Alan Previn]

With the acceptance of the explicit-px-fw-cmd-termination series upstream
(https://patchwork.freedesktop.org/series/113307/), this patch #5 of this
series will need a rerev with the addition of MTL's version of the
explicit termination as well.

...alan

On Wed, 2023-01-25 at 00:06 -0800, Teres Alexis, Alan Previn wrote:
> Add MTL's function for ARB session creation using PXP firmware
> version 4.3 ABI structure format.
> 
> Before checking the return status, look at the GSC-CS-Mem-Header's
> pending-bit which means the GSC firmware is busy and we should
> resubmit.
> 
> Signed-off-by: Alan Previn 
> ---
alan:snip

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: vblank stuff (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: vblank stuff (rev2)
URL   : https://patchwork.freedesktop.org/series/112170/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12656_full -> Patchwork_112170v2_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s3@smem:
- {shard-tglu}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-tglu-4/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-tglu-6/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-glk5/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-glk7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271]) +10 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-glk7/igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs.html

  
 Possible fixes 

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}:   [FAIL][6] ([i915#6268]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-tglu-2/igt@gem_ctx_e...@basic-nohangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-tglu-4/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][8] ([i915#6259]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-rkl-3/igt@gem_exec_balan...@fairslice.html

  * igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][10] ([i915#2846]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-3/igt@gem_exec_f...@basic-deadline.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk:  [FAIL][12] ([i915#2842]) -> [PASS][13] +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-glk7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-glk3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15] +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-1/igt@gem_exec_fair@basic-n...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}:[SKIP][16] ([i915#3281]) -> [PASS][17] +9 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-3/igt@gem_exec_re...@basic-write-read-noreloc.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html

  * igt@gem_pwrite_snooped:
- {shard-rkl}:[SKIP][18] ([i915#3282]) -> [PASS][19] +6 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-3/igt@gem_pwrite_snooped.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-rkl-5/igt@gem_pwrite_snooped.html

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [ABORT][20] -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/shard-glk7/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@shadow-peek:
- {shard-rkl}:[SKIP][22] ([i915#2527]) -> [PASS][23] +2 similar 
issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-rkl-3/igt@gen9_exec_pa...@shadow-peek.html
   [23]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for Drop TGL/DG1 workarounds for pre-prod steppings

[Patchwork]

== Series Details ==

Series: Drop TGL/DG1 workarounds for pre-prod steppings
URL   : https://patchwork.freedesktop.org/series/113453/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12658 -> Patchwork_113453v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (24 -> 23)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@requests:
- {bat-rplp-1}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/bat-rplp-1/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/bat-rplp-1/igt@i915_selftest@l...@requests.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- {bat-dg2-11}:   [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/bat-dg2-11/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/bat-dg2-11/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}:   [ABORT][5] -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/bat-adlp-6/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/bat-adlp-6/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- {bat-dg2-11}:   [DMESG-WARN][7] -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/bat-dg2-11/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/bat-dg2-11/igt@i915_pm_...@module-reload.html

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

  * igt@i915_selftest@live@migrate:
- {bat-dg2-11}:   [DMESG-WARN][11] ([i915#2867]) -> [PASS][12] +5 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12658/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113453v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

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

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

  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4137]: https://gitlab.freedesktop.org/drm/intel/issues/4137
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828


Build changes
-

  * Linux: CI_DRM_12658 -> Patchwork_113453v1

  CI-20190529: 20190529
  CI_DRM_12658: a9e72f4e0baf2e3e306da0063f98099044d85285 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7141: a978df7912acda18eada1b1d2ae4b438ed3e940b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_113453v1: a9e72f4e0baf2e3e306da0063f98099044d85285 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

7fb70302790c 

[Intel-gfx] [PATCH 1/3] drm/i915/tgl: Drop support for pre-production steppings

[Matt Roper]

Several post-TGL platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.

Production TGL hardware always has display stepping C0 or later and GT
stepping B0 or later (this is true for both the original TGL and the U/Y
subplatform).

Bspec 44455
Signed-off-by: Matt Roper 
---
 .../drm/i915/display/intel_display_power.c|  5 +--
 drivers/gpu/drm/i915/display/intel_psr.c  | 26 ---
 .../drm/i915/display/skl_universal_plane.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 44 ++-
 drivers/gpu/drm/i915/i915_driver.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h   |  8 
 drivers/gpu/drm/i915/intel_pm.c   |  4 --
 7 files changed, 7 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 1a23ecd4623a..1dc31f0f5e0a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1581,9 +1581,8 @@ static void tgl_bw_buddy_init(struct drm_i915_private 
*dev_priv)
 
if (IS_ALDERLAKE_S(dev_priv) ||
IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
-   IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
-   IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0))
-   /* Wa_1409767108:tgl,dg1,adl-s */
+   IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   /* Wa_1409767108 */
table = wa_1409767108_buddy_page_masks;
else
table = tgl_buddy_page_masks;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7d4a15a283a0..5dca58dd97a9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -591,12 +591,6 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (intel_dp->psr.psr2_sel_fetch_enabled) {
u32 tmp;
 
-   /* Wa_1408330847 */
-   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
-   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
-DIS_RAM_BYPASS_PSR2_MAN_TRACK,
-DIS_RAM_BYPASS_PSR2_MAN_TRACK);
-
tmp = intel_de_read(dev_priv, 
PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder));
drm_WARN_ON(_priv->drm, !(tmp & PSR2_MAN_TRK_CTL_ENABLE));
} else if (HAS_PSR2_SEL_FETCH(dev_priv)) {
@@ -765,13 +759,6 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
 
-   /* Wa_14010254185 Wa_14010103792 */
-   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
-   drm_dbg_kms(_priv->drm,
-   "PSR2 sel fetch not enabled, missing the 
implementation of WAs\n");
-   return false;
-   }
-
return crtc_state->enable_psr2_sel_fetch = true;
 }
 
@@ -945,13 +932,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
}
}
 
-   /* Wa_2209313811 */
-   if (!crtc_state->enable_psr2_sel_fetch &&
-   IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
-   drm_dbg_kms(_priv->drm, "PSR2 HW tracking is not supported 
this Display stepping\n");
-   goto unsupported;
-   }
-
if (!psr2_granularity_check(intel_dp, crtc_state)) {
drm_dbg_kms(_priv->drm, "PSR2 not enabled, SU granularity 
not compatible\n");
goto unsupported;
@@ -1360,12 +1340,6 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
intel_psr_exit(intel_dp);
intel_psr_wait_exit_locked(intel_dp);
 
-   /* Wa_1408330847 */
-   if (intel_dp->psr.psr2_sel_fetch_enabled &&
-   IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
-   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
-DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
-
/*
 * Wa_16013835468
 * Wa_14015648006
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 9b172a1e90de..e956edb87398 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2180,7 +2180,7 @@ static bool gen12_plane_has_mc_ccs(struct 
drm_i915_private *i915,
if (DISPLAY_VER(i915) < 12)
return false;
 
-   /* Wa_14010477008:tgl[a0..c0],rkl[all],dg1[all] */
+   /* Wa_14010477008 */
if (IS_DG1(i915) || IS_ROCKETLAKE(i915) ||
IS_TGL_DISPLAY_STEP(i915, STEP_A0, STEP_D0))
return false;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 4efc1a532982..82a8f372bde6 100644
--- 

[Intel-gfx] [PATCH 0/3] Drop TGL/DG1 workarounds for pre-prod steppings

[Matt Roper]

As described in the comment on intel_detect_preproduction_hw(),

   Our policy for removing pre-production workarounds is to keep the
   current gen workarounds as a guide to the bring-up of the next gen
   (workarounds have a habit of persisting!). Anything older than that
   should be removed along with the complications they introduce.

TGL and DG1 are well past the point where we should move forward with
removing the hardware workarounds specific to internal/pre-production
hardware.

JSL/EHL appear to have productized A0 hardware, so all workarounds for
those platforms will stay in the driver forever.  We can probably remove
some pre-production workarounds for RKL and ADL at this point as well,
but the bspec doesn't have details about which steppings were only used
in pre-production, so we'll need to track down that information later.


Matt Roper (3):
  drm/i915/tgl: Drop support for pre-production steppings
  drm/i915/dg1: Drop support for pre-production steppings
  drm/i915/dg1: Drop final use of IS_DG1_GRAPHICS_STEP

 .../drm/i915/display/intel_display_power.c|  6 +-
 drivers/gpu/drm/i915/display/intel_psr.c  | 26 --
 .../drm/i915/display/skl_universal_plane.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 86 +--
 drivers/gpu/drm/i915/i915_driver.c|  2 +
 drivers/gpu/drm/i915/i915_drv.h   | 13 ---
 drivers/gpu/drm/i915/intel_pm.c   | 16 
 8 files changed, 10 insertions(+), 143 deletions(-)

-- 
2.39.1

[Intel-gfx] [PATCH 3/3] drm/i915/dg1: Drop final use of IS_DG1_GRAPHICS_STEP

[Matt Roper]

All production DG1 hardware has graphics stepping B0; there is no such
thing as C0.  As such, we can simplify

IS_DG1_GRAPHICS_STEP(uncore->i915, STEP_A0, STEP_C0)

to just match DG1 in general.

Bspec: 44463
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index f3ad93db0b21..89fdfc67f8d1 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -158,7 +158,7 @@ static const struct intel_memory_region_ops 
intel_region_lmem_ops = {
 static bool get_legacy_lowmem_region(struct intel_uncore *uncore,
 u64 *start, u32 *size)
 {
-   if (!IS_DG1_GRAPHICS_STEP(uncore->i915, STEP_A0, STEP_C0))
+   if (!IS_DG1(uncore->i915))
return false;
 
*start = 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 57b84dbca084..495788e18b77 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -656,9 +656,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_RKL_DISPLAY_STEP(p, since, until) \
(IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))
 
-#define IS_DG1_GRAPHICS_STEP(p, since, until) \
-   (IS_DG1(p) && IS_GRAPHICS_STEP(p, since, until))
-
 #define IS_ADLS_DISPLAY_STEP(__i915, since, until) \
(IS_ALDERLAKE_S(__i915) && \
 IS_DISPLAY_STEP(__i915, since, until))
-- 
2.39.1

[Intel-gfx] [PATCH 2/3] drm/i915/dg1: Drop support for pre-production steppings

[Matt Roper]

Several post-DG1 platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.

Production DG1 hardware always has a B0 stepping for both display and
GT.

Bspec: 44463
Signed-off-by: Matt Roper 
---
 .../drm/i915/display/intel_display_power.c|  1 -
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 48 ++-
 drivers/gpu/drm/i915/i915_driver.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h   |  2 -
 drivers/gpu/drm/i915/intel_pm.c   | 12 -
 5 files changed, 5 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 1dc31f0f5e0a..7222502a760c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1580,7 +1580,6 @@ static void tgl_bw_buddy_init(struct drm_i915_private 
*dev_priv)
return;
 
if (IS_ALDERLAKE_S(dev_priv) ||
-   IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
/* Wa_1409767108 */
table = wa_1409767108_buddy_page_masks;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 82a8f372bde6..648fceba5bb6 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1463,12 +1463,6 @@ dg1_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
 
gen12_gt_workarounds_init(gt, wal);
 
-   /* Wa_1607087056:dg1 */
-   if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
-   wa_write_or(wal,
-   GEN11_SLICE_UNIT_LEVEL_CLKGATE,
-   L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
-
/* Wa_1409420604:dg1 */
if (IS_DG1(i915))
wa_mcr_write_or(wal,
@@ -2103,20 +2097,6 @@ static void tgl_whitelist_build(struct intel_engine_cs 
*engine)
}
 }
 
-static void dg1_whitelist_build(struct intel_engine_cs *engine)
-{
-   struct i915_wa_list *w = >whitelist;
-
-   tgl_whitelist_build(engine);
-
-   /* GEN:BUG:1409280441:dg1 */
-   if (IS_DG1_GRAPHICS_STEP(engine->i915, STEP_A0, STEP_B0) &&
-   (engine->class == RENDER_CLASS ||
-engine->class == COPY_ENGINE_CLASS))
-   whitelist_reg_ext(w, RING_ID(engine->mmio_base),
- RING_FORCE_TO_NONPRIV_ACCESS_RD);
-}
-
 static void xehpsdv_whitelist_build(struct intel_engine_cs *engine)
 {
allow_read_ctx_timestamp(engine);
@@ -2196,8 +2176,6 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
dg2_whitelist_build(engine);
else if (IS_XEHPSDV(i915))
xehpsdv_whitelist_build(engine);
-   else if (IS_DG1(i915))
-   dg1_whitelist_build(engine);
else if (GRAPHICS_VER(i915) == 12)
tgl_whitelist_build(engine);
else if (GRAPHICS_VER(i915) == 11)
@@ -2410,16 +2388,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
   true);
}
 
-   if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) {
-   /*
-* Wa_1607138336
-* Wa_1607063988
-*/
-   wa_write_or(wal,
-   GEN9_CTX_PREEMPT_REG,
-   GEN12_DISABLE_POSH_BUSY_FF_DOP_CG);
-   }
-
if (IS_ALDERLAKE_P(i915) || IS_ALDERLAKE_S(i915) || IS_DG1(i915) ||
IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
/* Wa_1606931601:tgl,rkl,dg1,adl-s,adl-p */
@@ -2449,30 +2417,22 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
}
 
if (IS_ALDERLAKE_P(i915) || IS_ALDERLAKE_S(i915) ||
-   IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
-   /* Wa_1409804808:tgl,rkl,dg1[a0],adl-s,adl-p */
+   /* Wa_1409804808 */
wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN2,
 GEN12_PUSH_CONST_DEREF_HOLD_DIS);
 
-   /*
-* Wa_1409085225:tgl
-* Wa_14010229206:tgl,rkl,dg1[a0],adl-s,adl-p
-*/
+   /* Wa_14010229206 */
wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN4, 
GEN12_DISABLE_TDL_PUSH);
}
 
-   if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
-   IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) {
+   if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) {
/*
-* Wa_1607030317:tgl
-* Wa_1607186500:tgl
-* Wa_1607297627:tgl,rkl,dg1[a0],adlp
+* 

Re: [Intel-gfx] [PATCH v4] drm/i915: implement async_flip mode per plane tracking

[Ville Syrjälä]

On Fri, Jan 27, 2023 at 04:30:02PM +0100, Andrzej Hajda wrote:
> Current implementation of async flip w/a relies on assumption that
> previous atomic commit contains valid information if async_flip is still
> enabled on the plane. It is incorrect. If previous commit did not modify
> the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
> errors can be observed:
> i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
> i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
> DMAR: DRHD: handling fault status reg 2
> DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault 
> reason 0x06] PTE Read access is not set
> 
> v2: update async_flip_planes in more reliable places (Ville)
> v3: reset async_flip_planes and do_async_flip in more scenarios (Ville)
> v4: move all resets to plane loops (Ville)
> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Ville,
> 
> I am not sure about this change. I wonder if in case of
> for*plane loops code could be like:
> 
> new_crtc_state->async_flip_planes &= ~BIT(plane->id);
> if (!new_crtc_state->async_flip_planes)
>   new_crtc_state->do_async_flip = false;

The current code is all geared towards all planes doing the
same kind of update (async vs. sync). Maybe we could rework
things so that some planes could remain in async mode while
the rest (and the whole pipe) really does a sync update.
But that will involve some real work.

This one is 
Reviewed-by: Ville Syrjälä 

> 
> But let's see what CI says.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 5 -
>  drivers/gpu/drm/i915/display/intel_color.c | 3 +++
>  drivers/gpu/drm/i915/display/intel_display.c   | 9 ++---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
>  drivers/gpu/drm/i915/display/skl_watermark.c   | 4 
>  5 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 1409bcfb6fd3d9..3bd8f7eb75a60b 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -363,6 +363,7 @@ void intel_plane_set_invisible(struct intel_crtc_state 
> *crtc_state,
>   crtc_state->scaled_planes &= ~BIT(plane->id);
>   crtc_state->nv12_planes &= ~BIT(plane->id);
>   crtc_state->c8_planes &= ~BIT(plane->id);
> + crtc_state->async_flip_planes &= ~BIT(plane->id);
>   crtc_state->data_rate[plane->id] = 0;
>   crtc_state->data_rate_y[plane->id] = 0;
>   crtc_state->rel_data_rate[plane->id] = 0;
> @@ -582,8 +583,10 @@ static int intel_plane_atomic_calc_changes(const struct 
> intel_crtc_state *old_cr
>intel_plane_is_scaled(new_plane_state
>   new_crtc_state->disable_lp_wm = true;
>  
> - if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state))
> + if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state)) {
>   new_crtc_state->do_async_flip = true;
> + new_crtc_state->async_flip_planes |= BIT(plane->id);
> + }
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 8d97c299e6577b..2ca7a016a9d9d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1500,12 +1500,15 @@ intel_color_add_affected_planes(struct 
> intel_crtc_state *new_crtc_state)
>   return PTR_ERR(plane_state);
>  
>   new_crtc_state->update_planes |= BIT(plane->id);
> + new_crtc_state->async_flip_planes = 0;
> + new_crtc_state->do_async_flip = false;
>  
>   /* plane control register changes blocked by CxSR */
>   if (HAS_GMCH(i915))
>   new_crtc_state->disable_cxsr = true;
>   }
>  
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 717ca3d7890d34..fcd3f1c7af3291 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1252,7 +1252,8 @@ static void intel_crtc_async_flip_disable_wa(struct 
> intel_atomic_state *state,
>   intel_atomic_get_old_crtc_state(state, crtc);
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
> - u8 update_planes = new_crtc_state->update_planes;
> + u8 disable_async_flip_planes = old_crtc_state->async_flip_planes &
> +~new_crtc_state->async_flip_planes;
>   const struct intel_plane_state *old_plane_state;
>   struct intel_plane *plane;
>   bool need_vbl_wait = false;
> @@ -1261,7 +1262,7 @@ static void intel_crtc_async_flip_disable_wa(struct 
> intel_atomic_state 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix potential bit_17 double-free

[Patchwork]

== Series Details ==

Series: drm/i915: Fix potential bit_17 double-free
URL   : https://patchwork.freedesktop.org/series/113447/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12656 -> Patchwork_113447v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 25)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

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

  
Known issues


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

### IGT changes ###

 Issues hit 

  * 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_113447v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@dmabuf:
- fi-bsw-nick:[PASS][5] -> [DMESG-FAIL][6] ([i915#7562])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113447v1/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][7] ([i915#7156])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113447v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

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

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271]) +15 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113447v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][10] ([i915#7852]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113447v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-adlm-1}:   [ABORT][12] -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113447v1/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7562]: https://gitlab.freedesktop.org/drm/intel/issues/7562
  [i915#7677]: https://gitlab.freedesktop.org/drm/intel/issues/7677
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852


Build changes
-

  * Linux: CI_DRM_12656 -> Patchwork_113447v1

  CI-20190529: 20190529
  CI_DRM_12656: 5a9d8eeec978f2373afe9e049eaa42f67b42074a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7140: ec87a6a636b9337ac9c8fec57350812bcb48fc09 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_113447v1: 5a9d8eeec978f2373afe9e049eaa42f67b42074a @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b24f26e3eebf drm/i915: Fix potential bit_17 double-free

== Logs ==

For more details see: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: probe lmem before the stolen portion

[Patchwork]

== Series Details ==

Series: drm/i915: probe lmem before the stolen portion
URL   : https://patchwork.freedesktop.org/series/113435/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12655_full -> Patchwork_113435v1_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s4-devices@lmem0:
- {shard-dg1}:NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-dg1-14/igt@gem_exec_suspend@basic-s4-devi...@lmem0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][2] ([fdo#109271])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-glk1/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][3] ([i915#7742]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_ctx_persistence@many-contexts:
- {shard-dg1}:[ABORT][5] ([i915#4983]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-dg1-14/igt@gem_ctx_persiste...@many-contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-dg1-12/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][7] ([fdo#103375]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-4/igt@gem_...@in-flight-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-2/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][9] ([i915#5784]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-dg1-12/igt@gem_...@reset-stress.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-dg1-17/igt@gem_...@reset-stress.html

  * igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][11] ([i915#6247]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [FAIL][13] ([i915#2842]) -> [PASS][14] +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][15] ([fdo#109313]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-3/igt@gem_exec_re...@basic-wc-read-noreloc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html

  * igt@gem_userptr_blits@forbidden-operations:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-3/igt@gem_userptr_bl...@forbidden-operations.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/shard-rkl-5/igt@gem_userptr_bl...@forbidden-operations.html

  * igt@gen9_exec_parse@secure-batches:
- {shard-rkl}:[SKIP][21] ([i915#2527]) -> [PASS][22] +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-3/igt@gen9_exec_pa...@secure-batches.html
   [22]: 

Re: [Intel-gfx] [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Rodrigo Vivi]

On Fri, Jan 27, 2023 at 10:09:31AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
> > 
> > Greg, ack on getting these 3 mei patches merged through intel-gfx?
> 
> I only see 2 mei patches in this series, what am I missing?

right... 2 mei patches only... sorry for the noise and for the top posting.

thanks for the ack.

series pushed to drm-intel-next

> 
> thanks,
> 
> greg k-h

[Intel-gfx] [PATCH] drm/i915: Fix potential bit_17 double-free

[Rob Clark]

From: Rob Clark 

A userspace with multiple threads racing I915_GEM_SET_TILING to set the
tiling to I915_TILING_NONE could trigger a double free of the bit_17
bitmask.  (Or conversely leak memory on the transition to tiled.)  Move
allocation/free'ing of the bitmask within the section protected by the
obj lock.

Fixes: e9b73c67390a ("drm/i915: Reduce memory pressure during shrinker by 
preallocating swizzle pages")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index fd42b89b7162..bc21b1c2350a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -298,36 +298,37 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
*obj,
vma->fence_alignment =
i915_gem_fence_alignment(i915,
 vma->size, tiling, stride);
 
if (vma->fence)
vma->fence->dirty = true;
}
spin_unlock(>vma.lock);
 
obj->tiling_and_stride = tiling | stride;
-   i915_gem_object_unlock(obj);
-
-   /* Force the fence to be reacquired for GTT access */
-   i915_gem_object_release_mmap_gtt(obj);
 
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
if (!obj->bit_17) {
obj->bit_17 = bitmap_zalloc(obj->base.size >> 
PAGE_SHIFT,
GFP_KERNEL);
}
} else {
bitmap_free(obj->bit_17);
obj->bit_17 = NULL;
}
 
+   i915_gem_object_unlock(obj);
+
+   /* Force the fence to be reacquired for GTT access */
+   i915_gem_object_release_mmap_gtt(obj);
+
return 0;
 }
 
 /**
  * i915_gem_set_tiling_ioctl - IOCTL handler to set tiling mode
  * @dev: DRM device
  * @data: data pointer for the ioctl
  * @file: DRM file for the ioctl call
  *
  * Sets the tiling mode of an object, returning the required swizzling of
-- 
2.38.1

Re: [Intel-gfx] [PATCH 5/9] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()

[Imre Deak]

On Fri, Jan 27, 2023 at 09:42:39PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 25, 2023 at 01:48:48PM +0200, Imre Deak wrote:
> > Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
> > 
> > Cc: Lyude Paul 
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 81cc0c3b1e000..619f616d69e20 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4770,7 +4770,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> > list_for_each_entry(payload, >payloads, next) {
> > char name[14];
> >  
> > -   if (payload->vcpi != i || payload->delete)
> > +   if (payload->vcpi != i + 1 || payload->delete)
> 
> Why does this code even do that funny nested double loop?

The payload list is not ordered by VCPIs I think, but the printout wants
to list them in VCPI order.

> 
> > continue;
> >  
> > fetch_monitor_name(mgr, payload->port, name, 
> > sizeof(name));
> > -- 
> > 2.37.1
> 
> -- 
> Ville Syrjälä
> Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: vblank stuff (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: vblank stuff (rev2)
URL   : https://patchwork.freedesktop.org/series/112170/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12656 -> Patchwork_112170v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 25)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}:   NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@module-reload:
- {bat-rplp-1}:   [PASS][2] -> [DMESG-FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-rplp-1/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-rplp-1/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@dmabuf:
- {bat-rplp-1}:   [PASS][4] -> [DMESG-WARN][5] +13 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-rplp-1/igt@i915_selftest@l...@dmabuf.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-rplp-1/igt@i915_selftest@l...@dmabuf.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * 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_112170v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][8] ([i915#7156])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][9] ([i915#5334] / [i915#7872])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][11] -> [ABORT][12] ([i915#4983])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][13] ([fdo#109271]) +15 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][14] ([i915#4983] / [i915#7609]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][16] ([i915#7852]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [ABORT][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-adlm-1}:   [ABORT][20] -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112170v2/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html

  
  {name}: This element is suppressed. This means it is 

Re: [Intel-gfx] [PATCH 5/9] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()

[Ville Syrjälä]

On Wed, Jan 25, 2023 at 01:48:48PM +0200, Imre Deak wrote:
> Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
> 
> Cc: Lyude Paul 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 81cc0c3b1e000..619f616d69e20 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4770,7 +4770,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   list_for_each_entry(payload, >payloads, next) {
>   char name[14];
>  
> - if (payload->vcpi != i || payload->delete)
> + if (payload->vcpi != i + 1 || payload->delete)

Why does this code even do that funny nested double loop?

>   continue;
>  
>   fetch_monitor_name(mgr, payload->port, name, 
> sizeof(name));
> -- 
> 2.37.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Luca Coelho]

On Fri, 2023-01-27 at 11:33 -0800, Lucas De Marchi wrote:
> On Fri, Jan 27, 2023 at 07:12:29PM +0200, Luca Coelho wrote:
> > On Fri, 2023-01-27 at 16:37 +0200, Jani Nikula wrote:
> > > On Fri, 27 Jan 2023, Tvrtko Ursulin  
> > > wrote:
> > > > On 26/01/2023 16:05, Jani Nikula wrote:
> > > > > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > > > > On Thu, 2023-01-26 at 14:11 +0200, Luca Coelho wrote:
> > > > > > > On Thu, 2023-01-26 at 14:00 +0200, Jani Nikula wrote:
> > > > > > > > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > > > > > > > On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > > > index 7d4a15a283a0..63b79c611932 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > > > @@ -1559,7 +1559,26 @@ void 
> > > > > > > > > > > intel_psr2_disable_plane_sel_fetch(struct intel_plane 
> > > > > > > > > > > *plane,
> > > > > > > > > > >   intel_de_write_fw(dev_priv, 
> > > > > > > > > > > PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
> > > > > > > > > > >   }
> > > > > > > > > > > 
> > > > > > > > > > > -void intel_psr2_program_plane_sel_fetch(struct 
> > > > > > > > > > > intel_plane *plane,
> > > > > > > > > > > +void intel_psr2_program_plane_sel_fetch_arm(struct 
> > > > > > > > > > > intel_plane *plane,
> > > > > > > > > > > + const struct 
> > > > > > > > > > > intel_crtc_state *crtc_state,
> > > > > > > > > > > + const struct 
> > > > > > > > > > > intel_plane_state *plane_state,
> > > > > > > > > > > + int color_plane)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct drm_i915_private *dev_priv = 
> > > > > > > > > > > to_i915(plane->base.dev);
> > > > > > > > > 
> > > > > > > > > Should you use i915 instead of dev_priv? I've heard and read 
> > > > > > > > > elsewhere
> > > > > > > > > that this is generally a desired change.  Much easier to use 
> > > > > > > > > always the
> > > > > > > > > same local name for this kind of thing.  Though this file is 
> > > > > > > > > already
> > > > > > > > > interspersed with both versions...
> > > > > > > > 
> > > > > > > > Basically the only reason to use dev_priv for new code is to 
> > > > > > > > deal with
> > > > > > > > some register macros that still have implicit dev_priv in
> > > > > > > > them. Otherwise, i915 should be used, and when convenient, 
> > > > > > > > dev_priv
> > > > > > > > should be converted to i915 while touching the code anyway (in a
> > > > > > > > separate patch, but while you're there).
> > > > > > > 
> > > > > > > Thanks for the clarification! In this case we're not using any of 
> > > > > > > the
> > > > > > > macros, AFAICT, so I guess it's better to go with i915 already? 
> > > > > > > And I
> > > > > > > think it should even be in this same patch, since it's a new 
> > > > > > > function
> > > > > > > anyway.
> > > > > > > 
> > > > > > > 
> > > > > > > > The implicit dev_priv dependencies in the register macros are a 
> > > > > > > > bit
> > > > > > > > annoying to fix, and it's been going slow. In retrospect maybe 
> > > > > > > > the right
> > > > > > > > thing would have been to just sed the parameter to all of them
> > > > > > > > everywhere and be done with it for good. Not too late now, I 
> > > > > > > > guess, and
> > > > > > > > I'd take the patches in a heartbeat if someone were to step up 
> > > > > > > > and do
> > > > > > > > it.
> > > > > > > 
> > > > > > > I see that there is a boatload of register macros using it... I 
> > > > > > > won't
> > > > > > > promise, but I think it would be a good exercise for a n00b like 
> > > > > > > me to
> > > > > > > make this patch, though I already foresee another boatload of 
> > > > > > > conflicts
> > > > > > > with the internal trees and everything...
> > > > > > 
> > > > > > There were actually 10 boatloads of places to change:
> > > > > > 
> > > > > >   187 files changed, 12104 insertions(+), 12104 deletions(-)
> > > > > > 
> > > > > > ...but it _does_ compile. 
> > > > > > 
> > > > > > Do you think this is fine? Lots of shuffle, but if you think it's 
> > > > > > okay,
> > > > > > I can send the patch out now.
> > > > > 
> > > > > Heh, I said I'd take patchES, not everything together! ;)
> > > > > 
> > > > > Rodrigo, Tvrtko, Joonas, thoughts?
> > > > 
> > > > IMO if the elimination of implicit dev_priv is not included then I am
> > > > not sure the churn is worth the effort.
> > > > 
> > > > I think one trap is that it is easy to assume solving those conflicts is
> > > > easy because there is a script, somewhere, whatever, but one needs to be
> > > > careful with assuming a random person hitting a merge conflict will
> > > > realize there is a script, know where to find it, and know how to 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Lucas De Marchi]

On Fri, Jan 27, 2023 at 07:12:29PM +0200, Luca Coelho wrote:

On Fri, 2023-01-27 at 16:37 +0200, Jani Nikula wrote:

On Fri, 27 Jan 2023, Tvrtko Ursulin  wrote:
> On 26/01/2023 16:05, Jani Nikula wrote:
> > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > On Thu, 2023-01-26 at 14:11 +0200, Luca Coelho wrote:
> > > > On Thu, 2023-01-26 at 14:00 +0200, Jani Nikula wrote:
> > > > > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > > > > On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > index 7d4a15a283a0..63b79c611932 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > @@ -1559,7 +1559,26 @@ void 
intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
> > > > > > > > intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
plane->id), 0);
> > > > > > > >   }
> > > > > > > >
> > > > > > > > -void intel_psr2_program_plane_sel_fetch(struct intel_plane 
*plane,
> > > > > > > > +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane 
*plane,
> > > > > > > > +   const struct 
intel_crtc_state *crtc_state,
> > > > > > > > +   const struct 
intel_plane_state *plane_state,
> > > > > > > > +   int color_plane)
> > > > > > > > +{
> > > > > > > > +   struct drm_i915_private *dev_priv = 
to_i915(plane->base.dev);
> > > > > >
> > > > > > Should you use i915 instead of dev_priv? I've heard and read 
elsewhere
> > > > > > that this is generally a desired change.  Much easier to use always 
the
> > > > > > same local name for this kind of thing.  Though this file is already
> > > > > > interspersed with both versions...
> > > > >
> > > > > Basically the only reason to use dev_priv for new code is to deal with
> > > > > some register macros that still have implicit dev_priv in
> > > > > them. Otherwise, i915 should be used, and when convenient, dev_priv
> > > > > should be converted to i915 while touching the code anyway (in a
> > > > > separate patch, but while you're there).
> > > >
> > > > Thanks for the clarification! In this case we're not using any of the
> > > > macros, AFAICT, so I guess it's better to go with i915 already? And I
> > > > think it should even be in this same patch, since it's a new function
> > > > anyway.
> > > >
> > > >
> > > > > The implicit dev_priv dependencies in the register macros are a bit
> > > > > annoying to fix, and it's been going slow. In retrospect maybe the 
right
> > > > > thing would have been to just sed the parameter to all of them
> > > > > everywhere and be done with it for good. Not too late now, I guess, 
and
> > > > > I'd take the patches in a heartbeat if someone were to step up and do
> > > > > it.
> > > >
> > > > I see that there is a boatload of register macros using it... I won't
> > > > promise, but I think it would be a good exercise for a n00b like me to
> > > > make this patch, though I already foresee another boatload of conflicts
> > > > with the internal trees and everything...
> > >
> > > There were actually 10 boatloads of places to change:
> > >
> > >   187 files changed, 12104 insertions(+), 12104 deletions(-)
> > >
> > > ...but it _does_ compile. 
> > >
> > > Do you think this is fine? Lots of shuffle, but if you think it's okay,
> > > I can send the patch out now.
> >
> > Heh, I said I'd take patchES, not everything together! ;)
> >
> > Rodrigo, Tvrtko, Joonas, thoughts?
>
> IMO if the elimination of implicit dev_priv is not included then I am
> not sure the churn is worth the effort.
>
> I think one trap is that it is easy to assume solving those conflicts is
> easy because there is a script, somewhere, whatever, but one needs to be
> careful with assuming a random person hitting a merge conflict will
> realize there is a script, know where to find it, and know how to use it
> against a state where conflict markers are sitting in their local tree.
> That's a lot of assumed knowledge which my experience tells me is not
> universally there.
>
> Having said all that, I looked at the occurrence histogram for the
> proposed churn and gut feel says conflicts wouldn't even be that bad
> since they seem heavily localized in a handful of files plus the display
> subdir.
>
> Plus it is upstream.. so we are allowed not to care too much about
> backporting woes. I would still hope implicit dev_priv, albeit
> orthogonal, would be coming somewhat together with the rename. For that
> warm fuzzy feeling that the churn was really really worth it.

I was mostly talking about the implicit dev_priv removal. It's somewhat
easy, because you can always assume dev_priv is around when the macros
in question are used.

The above is a dependency to any renames. I don't think the renames are
as important as removing the implicit 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: implement async_flip mode per plane tracking (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: implement async_flip mode per plane tracking (rev5)
URL   : https://patchwork.freedesktop.org/series/108371/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12655_full -> Patchwork_108371v5_full


Summary
---

  **FAILURE**

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

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-glk1/igt@gen9_exec_pa...@allowed-single.html

  
 Suppressed 

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

  * igt@gem_ccs@suspend-resume:
- {shard-rkl}:[SKIP][3] ([i915#5325]) -> [SKIP][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-2/igt@gem_...@suspend-resume.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_...@suspend-resume.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-glk3/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  
 Possible fixes 

  * igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][6] ([i915#7742]) -> [PASS][7] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@drm_fdi...@virtual-idle.html

  * igt@gem_ctx_persistence@many-contexts:
- {shard-dg1}:[ABORT][8] ([i915#4983]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-dg1-14/igt@gem_ctx_persiste...@many-contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-dg1-12/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][10] ([fdo#103375]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-4/igt@gem_...@in-flight-suspend.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][12] ([i915#6247]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-4/igt@gem_exec_endless@dispa...@bcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15] +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-2/igt@gem_exec_fair@basic-n...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [FAIL][16] ([i915#2842]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +15 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-3/igt@gem_exec_re...@basic-wc-read-noreloc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html

  * igt@gem_pwrite_snooped:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +2 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/shard-rkl-3/igt@gem_pwrite_snooped.html
   [21]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Use unversioned blob path for ADLP DMC (rev2)

[Patchwork]

== Series Details ==

Series: Use unversioned blob path for ADLP DMC (rev2)
URL   : https://patchwork.freedesktop.org/series/113238/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/113238/revisions/2/mbox/ not 
applied
Applying: drm/i915/dmc: Prepare to use unversioned paths
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_dmc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_dmc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_dmc.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/dmc: Prepare to use unversioned paths
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] [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Teres Alexis, Alan Previn]

Hi Greg, appreciate your time on this, 

Patch #2 adds a device link between i915 and mei
(at bind time) specifically for the PXP interface
that is subject to the issue being fixed.

Change is on i915 but implication is mei suspend-resume
aligfnent with i915. Rodrigo has already reviewed it
but Alex and himself felt you might wanna take a look.

...alan


On Fri, 2023-01-27 at 10:09 +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
> > 
> > Greg, ack on getting these 3 mei patches merged through intel-gfx?
> 
> I only see 2 mei patches in this series, what am I missing?
> 
> thanks,
> 
> greg k-h

Re: [Intel-gfx] [RFC 1/2] drm/i915: Add RPL-U sub platform

[Matt Roper]

On Fri, Jan 27, 2023 at 01:34:31AM -0800, Borah, Chaitanya Kumar wrote:
> Hello Jani and Matt,
> 
> > -Original Message-
> > From: Jani Nikula 
> > Sent: Tuesday, January 24, 2023 8:02 PM
> > To: Borah, Chaitanya Kumar ; intel-
> > g...@lists.freedesktop.org
> > Cc: Shankar, Uma ; Syrjala, Ville
> > ; Srivatsa, Anusha ;
> > Roper, Matthew D ; Atwood, Matthew S
> > ; Borah, Chaitanya Kumar
> > 
> > Subject: Re: [RFC 1/2] drm/i915: Add RPL-U sub platform
> > 
> > On Tue, 17 Jan 2023, Chaitanya Kumar Borah
> >  wrote:
> > > Separate out RPLU device ids and add them to both RPL and newly
> > > created RPL-U subplatforms.
> > >
> > > v2: (Matt)
> > > - Sort PCI-IDs numerically
> > > - Name the sub-platform to accurately depict what it is for
> > > - Make RPL-U part of RPL subplatform
> > >
> > > v3: revert to RPL-U subplatform (Jani)
> > >
> > > Signed-off-by: Chaitanya Kumar Borah
> > 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
> > >  drivers/gpu/drm/i915/i915_pci.c  |  1 +
> > >  drivers/gpu/drm/i915/intel_device_info.c |  8 
> > > drivers/gpu/drm/i915/intel_device_info.h |  2 ++
> > >  include/drm/i915_pciids.h| 11 +++
> > >  5 files changed, 20 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h index 48fd82722f12..c88e514728a0
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -619,6 +619,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> > >   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> > INTEL_SUBPLATFORM_N)
> > > #define IS_ADLP_RPLP(dev_priv) \
> > >   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> > INTEL_SUBPLATFORM_RPL)
> > > +#define IS_ADLP_RPLU(dev_priv) \
> > > + IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> > INTEL_SUBPLATFORM_RPLU)
> > >  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > >   (INTEL_DEVID(dev_priv) & 0xFF00) ==
> > 0x0C00)  #define
> > > IS_BDW_ULT(dev_priv) \ diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > b/drivers/gpu/drm/i915/i915_pci.c index 6cc65079b18d..e9f3b99b3e00
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -1234,6 +1234,7 @@ static const struct pci_device_id pciidlist[] = {
> > >   INTEL_DG1_IDS(_info),
> > >   INTEL_RPLS_IDS(_s_info),
> > >   INTEL_RPLP_IDS(_p_info),
> > > + INTEL_RPLU_IDS(_p_info),
> > 
> > You may want to drop this change, see later comment on how and why.
> > 
> > >   INTEL_DG2_IDS(_info),
> > >   INTEL_ATS_M_IDS(_m_info),
> > >   INTEL_MTL_IDS(_info),
> > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > > b/drivers/gpu/drm/i915/intel_device_info.c
> > > index 849baf6c3b3c..fec8bd116436 100644
> > > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > > @@ -199,6 +199,11 @@ static const u16 subplatform_n_ids[] = {  static
> > > const u16 subplatform_rpl_ids[] = {
> > >   INTEL_RPLS_IDS(0),
> > >   INTEL_RPLP_IDS(0),
> > > + INTEL_RPLU_IDS(0)
> > 
> > Please always include the trailing , at the end to make future changes 
> > easier.
> > (However, you may want to drop this change altogether, see later
> > comment.)
> > 
> > > +};
> > > +
> > > +static const u16 subplatform_rplu_ids[] = {
> > > + INTEL_RPLU_IDS(0),
> > >  };
> > >
> > >  static const u16 subplatform_g10_ids[] = { @@ -268,6 +273,9 @@ static
> > > void intel_device_info_subplatform_init(struct drm_i915_private *i915)
> > >   } else if (find_devid(devid, subplatform_rpl_ids,
> > > ARRAY_SIZE(subplatform_rpl_ids))) {
> > >   mask = BIT(INTEL_SUBPLATFORM_RPL);
> > > + if (find_devid(devid, subplatform_rplu_ids,
> > > +ARRAY_SIZE(subplatform_rplu_ids)))
> > > + mask |= BIT(INTEL_SUBPLATFORM_RPLU);
> > >   } else if (find_devid(devid, subplatform_g10_ids,
> > > ARRAY_SIZE(subplatform_g10_ids))) {
> > >   mask = BIT(INTEL_SUBPLATFORM_G10);
> > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > > b/drivers/gpu/drm/i915/intel_device_info.h
> > > index d588e5fd2eea..4a5cd337e4b5 100644
> > > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > > @@ -127,6 +127,8 @@ enum intel_platform {
> > >   * bit set
> > >   */
> > >  #define INTEL_SUBPLATFORM_N1
> > > +/* Sub Platform for RPL-U */
> > 
> > This comment really adds nothing, it's exactly the same as the macro name.
> > 
> 
> Ack.
> 
> > > +#define INTEL_SUBPLATFORM_RPLU  2
> > >
> > >  /* MTL */
> > >  #define INTEL_SUBPLATFORM_M  0
> > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > > index 4a4c190f7698..758be5fb09a2 100644
> > > --- a/include/drm/i915_pciids.h
> > > +++ b/include/drm/i915_pciids.h
> > > @@ -684,14 +684,17 @@
> > >   

Re: [Intel-gfx] [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Simon Ser]

On Wednesday, January 25th, 2023 at 21:04, Thomas Zimmermann 
 wrote:

> Not having connectors indicates a driver bug.

Is it? What if all connectors are of the DP-MST type, ie. they are
created on-the-fly?

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: probe lmem before the stolen portion

[Patchwork]

== Series Details ==

Series: drm/i915: probe lmem before the stolen portion
URL   : https://patchwork.freedesktop.org/series/113435/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12655 -> Patchwork_113435v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 25)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-2}:   [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
- {bat-rpls-1}:   NOTRUN -> [ABORT][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * 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_113435v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][8] ([i915#7156])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

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

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271]) +15 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [DMESG-FAIL][11] ([i915#5334]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-1}:   [ABORT][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
- {bat-adlp-6}:   [ABORT][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-adlp-6/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-adlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@workarounds:
- {bat-rplp-1}:   [INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-rplp-1/igt@i915_selftest@l...@workarounds.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113435v1/bat-rplp-1/igt@i915_selftest@l...@workarounds.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7828]: 

Re: [Intel-gfx] [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

[Sam Ravnborg]

On Fri, Jan 27, 2023 at 03:21:30PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 25.01.23 um 22:03 schrieb Sam Ravnborg:
> > Hi Thomas,
> > 
> > On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> > > Initialize the fb-helper structure immediately after its allocation
> > > in drm_fbdev_generic_setup(). That will make it easier to fill it with
> > > driver-specific values, such as the preferred BPP.
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > Reviewed-by: Javier Martinez Canillas 
> > > ---
> > >   drivers/gpu/drm/drm_fbdev_generic.c | 13 +
> > >   1 file changed, 9 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
> > > b/drivers/gpu/drm/drm_fbdev_generic.c
> > > index 135d58b8007b..63f66325a8a5 100644
> > > --- a/drivers/gpu/drm/drm_fbdev_generic.c
> > > +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> > > @@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct 
> > > drm_client_dev *client)
> > >   if (dev->fb_helper)
> > >   return drm_fb_helper_hotplug_event(dev->fb_helper);
> > > - drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
> > > -
> > >   ret = drm_fb_helper_init(dev, fb_helper);
> > >   if (ret)
> > >   goto err;
> > 
> >  From the documentation:
> > The drm_fb_helper_prepare()
> > helper must be called first to initialize the minimum required to make
> > hotplug detection work.
> > ...
> > To finish up the fbdev helper initialization, the
> > drm_fb_helper_init() function is called.
> > 
> > So this change do not follow the documentation as drm_fb_helper_init()
> > is now called before drm_fb_helper_prepare()
> 
> No, we now call drm_fb_helper_prepare() from within
> drm_fbdev_generic_setup(), right after allocating the fb_helper.
> drm_fb_helper_init() will only be called after the client received a
> hot-plug event.
> 
> > 
> > I did not follow all the code - but my gut feeling is that the
> > documentation is right.
> 
> The docs are of low quality. The _prepare() helper is the actual init
> function and _init() only sets the fb_helper in the device instance.
OK, thanks for the follow-up.


Sam

Re: [Intel-gfx] [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Sam Ravnborg]

On Fri, Jan 27, 2023 at 03:13:50PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 25.01.23 um 21:52 schrieb Sam Ravnborg:
> > Hi Thomas,
> > 
> > On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> > > Test for connectors in the client code and remove a similar test
> > > from the generic fbdev emulation. Do nothing if the test fails.
> > > Not having connectors indicates a driver bug.
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > Reviewed-by: Javier Martinez Canillas 
> > > ---
> > >   drivers/gpu/drm/drm_client.c| 5 +
> > >   drivers/gpu/drm/drm_fbdev_generic.c | 5 -
> > >   2 files changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index 262ec64d4397..09ac191c202d 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> > >   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > >   return;
> > > + if (!dev->mode_config.num_connector) {
> > > + drm_dbg_kms(dev, "No connectors found, will not send hotplug 
> > > events!\n");
> > > + return;
> > This deserves a more visible logging - if a driver fails here it would
> > be good to spot it in the normal kernel log.
> > drm_info or drm_notice?
> 
> But is that really noteworthy? AFAIK, this situation can legally happen. So
> if it's expected, why should we print a message about it?
I was reading it as a driver error - as that's not the case current code
is fine.

Sam

[Intel-gfx] [PATCH v2 4/4] drm/i915: Reject wm levels that exceed vblank time

[Ville Syrjala]

From: Ville Syrjälä 

The pipe needs a certain amount of time during vblank to prefill
sufficiently. If the vblank is too short the relevant watermark
level must be disabled.

Start implementing the necessary calculations to check this.
Scaler and DSC prefill are left out for now as handling those
is not entirely trivial.

Also the PSR latency reporting override chicken bits would
need to be correctly configured based on the results of these
calculations. Just add some FIXMEs for now.

TODO: bspec isn't exactly crystal clear in its explanations
  so quite a few open questions remain...

v2: Skip inacive pipes
Handle SAGV latency

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/skl_watermark.c | 117 ++-
 1 file changed, 115 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
b/drivers/gpu/drm/i915/display/skl_watermark.c
index 65c746d018b5..715f389cd872 100644
--- a/drivers/gpu/drm/i915/display/skl_watermark.c
+++ b/drivers/gpu/drm/i915/display/skl_watermark.c
@@ -8,6 +8,7 @@
 #include "intel_atomic.h"
 #include "intel_atomic_plane.h"
 #include "intel_bw.h"
+#include "intel_crtc.h"
 #include "intel_de.h"
 #include "intel_display.h"
 #include "intel_display_power.h"
@@ -720,7 +721,7 @@ static unsigned int skl_wm_latency(struct drm_i915_private 
*i915, int level,
skl_watermark_ipc_enabled(i915))
latency += 4;
 
-   if (skl_needs_memory_bw_wa(i915) && wp->x_tiled)
+   if (skl_needs_memory_bw_wa(i915) && wp && wp->x_tiled)
latency += 15;
 
return latency;
@@ -2195,6 +2196,118 @@ static int icl_build_plane_wm(struct intel_crtc_state 
*crtc_state,
return 0;
 }
 
+static bool
+skl_is_vblank_too_short(const struct intel_crtc_state *crtc_state,
+   int wm0_lines, int latency)
+{
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+
+   /* FIXME missing scaler and DSC pre-fill time */
+   return crtc_state->framestart_delay +
+   intel_usecs_to_scanlines(adjusted_mode, latency) +
+   wm0_lines >
+   adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vblank_start;
+}
+
+static int skl_max_wm0_lines(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   enum plane_id plane_id;
+   int wm0_lines = 0;
+
+   for_each_plane_id_on_crtc(crtc, plane_id) {
+   const struct skl_plane_wm *wm = 
_state->wm.skl.optimal.planes[plane_id];
+
+   /* FIXME what about !skl_wm_has_lines() platforms? */
+   wm0_lines = max_t(int, wm0_lines, wm->wm[0].lines);
+   }
+
+   return wm0_lines;
+}
+
+static int skl_max_wm_level_for_vblank(struct intel_crtc_state *crtc_state,
+  int wm0_lines)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   int level;
+
+   for (level = ilk_wm_max_level(i915); level >= 0; level--) {
+   int latency;
+
+   /*
+* FIXME is it correct to use 0 latency for wm0 here?
+* FIXME should we care about the latency w/a's?
+* FIXME what if we don't have latency for all levels?
+*/
+   latency = level == 0 ?
+   0 : skl_wm_latency(i915, level, NULL);
+
+   if (!skl_is_vblank_too_short(crtc_state, wm0_lines, latency))
+   return level;
+   }
+
+   return -EINVAL;
+}
+
+static int skl_wm_check_vblank(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   int wm0_lines, level;
+
+   if (!crtc_state->hw.active)
+   return 0;
+
+   wm0_lines = skl_max_wm0_lines(crtc_state);
+
+   level = skl_max_wm_level_for_vblank(crtc_state, wm0_lines);
+   if (level < 0)
+   return level;
+
+   /*
+* FIXME PSR needs to toggle LATENCY_REPORTING_REMOVED_PIPE_*
+* based on whether we're limited by the vblank duration.
+*
+* FIXME also related to skl+ w/a 1136 (also unimplemented as of
+* now) perhaps?
+*/
+
+   for (level++; level <= ilk_wm_max_level(i915); level++) {
+   enum plane_id plane_id;
+
+   for_each_plane_id_on_crtc(crtc, plane_id) {
+   struct skl_plane_wm *wm =
+   _state->wm.skl.optimal.planes[plane_id];
+
+   /*
+* FIXME just clear enable or flag the entire
+* thing as bad via min_ddb_alloc=U16_MAX?
+*/
+   wm->wm[level].enable = false;
+   

[Intel-gfx] [PATCH v2 3/4] drm/i915: Extract skl_wm_latency()

[Ville Syrjala]

From: Ville Syrjälä 

Extract the skl+ wm latency determination into a small helper
so that everyone has the same idea what the latency should be.

This introduces a slight functional change in that
skl_cursor_allocation() will now start to account for the
extra 4 usec that the kbk/cfl/cml IPC w/a adds.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/skl_watermark.c | 40 +---
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c 
b/drivers/gpu/drm/i915/display/skl_watermark.c
index ae4e9e680c2e..65c746d018b5 100644
--- a/drivers/gpu/drm/i915/display/skl_watermark.c
+++ b/drivers/gpu/drm/i915/display/skl_watermark.c
@@ -704,6 +704,28 @@ static void skl_compute_plane_wm(const struct 
intel_crtc_state *crtc_state,
 const struct skl_wm_level *result_prev,
 struct skl_wm_level *result /* out */);
 
+static unsigned int skl_wm_latency(struct drm_i915_private *i915, int level,
+  const struct skl_wm_params *wp)
+{
+   unsigned int latency = i915->display.wm.skl_latency[level];
+
+   if (latency == 0)
+   return 0;
+
+   /*
+* WaIncreaseLatencyIPCEnabled: kbl,cfl
+* Display WA #1141: kbl,cfl
+*/
+   if ((IS_KABYLAKE(i915) || IS_COFFEELAKE(i915) || IS_COMETLAKE(i915)) &&
+   skl_watermark_ipc_enabled(i915))
+   latency += 4;
+
+   if (skl_needs_memory_bw_wa(i915) && wp->x_tiled)
+   latency += 15;
+
+   return latency;
+}
+
 static unsigned int
 skl_cursor_allocation(const struct intel_crtc_state *crtc_state,
  int num_active)
@@ -723,7 +745,7 @@ skl_cursor_allocation(const struct intel_crtc_state 
*crtc_state,
drm_WARN_ON(>drm, ret);
 
for (level = 0; level <= max_level; level++) {
-   unsigned int latency = i915->display.wm.skl_latency[level];
+   unsigned int latency = skl_wm_latency(i915, level, );
 
skl_compute_plane_wm(crtc_state, plane, level, latency, , 
, );
if (wm.min_ddb_alloc == U16_MAX)
@@ -1834,17 +1856,6 @@ static void skl_compute_plane_wm(const struct 
intel_crtc_state *crtc_state,
return;
}
 
-   /*
-* WaIncreaseLatencyIPCEnabled: kbl,cfl
-* Display WA #1141: kbl,cfl
-*/
-   if ((IS_KABYLAKE(i915) || IS_COFFEELAKE(i915) || IS_COMETLAKE(i915)) &&
-   skl_watermark_ipc_enabled(i915))
-   latency += 4;
-
-   if (skl_needs_memory_bw_wa(i915) && wp->x_tiled)
-   latency += 15;
-
method1 = skl_wm_method1(i915, wp->plane_pixel_rate,
 wp->cpp, latency, wp->dbuf_block_size);
method2 = skl_wm_method2(wp->plane_pixel_rate,
@@ -1971,7 +1982,7 @@ skl_compute_wm_levels(const struct intel_crtc_state 
*crtc_state,
 
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = [level];
-   unsigned int latency = i915->display.wm.skl_latency[level];
+   unsigned int latency = skl_wm_latency(i915, level, wm_params);
 
skl_compute_plane_wm(crtc_state, plane, level, latency,
 wm_params, result_prev, result);
@@ -1991,7 +2002,8 @@ static void tgl_compute_sagv_wm(const struct 
intel_crtc_state *crtc_state,
unsigned int latency = 0;
 
if (i915->display.sagv.block_time_us)
-   latency = i915->display.sagv.block_time_us + 
i915->display.wm.skl_latency[0];
+   latency = i915->display.sagv.block_time_us +
+   skl_wm_latency(i915, 0, wm_params);
 
skl_compute_plane_wm(crtc_state, plane, 0, latency,
 wm_params, [0],
-- 
2.39.1

[Intel-gfx] [PATCH v2 2/4] drm/i915/psr: Fix the delayed vblank w/a

[Ville Syrjala]

From: Ville Syrjälä 

Fix the code to correctly determine whether delayed vblank
is used or not.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7a72e15e6836..eb9a0cd18652 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1170,13 +1170,8 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 */
if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
IS_DISPLAY_VER(dev_priv, 12, 13)) {
-   u16 vtotal, vblank;
-
-   vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
-   crtc_state->uapi.adjusted_mode.crtc_vdisplay;
-   vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end -
-   crtc_state->uapi.adjusted_mode.crtc_vblank_start;
-   if (vblank > vtotal)
+   if (crtc_state->hw.adjusted_mode.crtc_vblank_start !=
+   crtc_state->hw.adjusted_mode.crtc_vdisplay)
intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
 wa_16013835468_bit_get(intel_dp));
}
-- 
2.39.1

[Intel-gfx] [PATCH v2 1/4] drm/i915/vrr: Fix "window2" handling

[Ville Syrjala]

From: Ville Syrjälä 

The "window2" delay is just the difference of vactive
(undelayed vblank) vs. vblank_start (delayed vblank).
Just use vblank_start during the VRR calculations so
that things work correctly regardless of whether delayed
vblank is used or not.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_vrr.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 5ff6aed9575e..4228f26b4c11 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -144,17 +144,11 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
 * is deprecated.
 */
if (DISPLAY_VER(i915) >= 13) {
-   /*
-* FIXME: Subtract Window2 delay from below value.
-*
-* Window2 specifies time required to program DSB (Window2) in
-* number of scan lines. Assuming 0 for no DSB.
-*/
crtc_state->vrr.guardband =
-   crtc_state->vrr.vmin + 1 - adjusted_mode->crtc_vdisplay;
+   crtc_state->vrr.vmin + 1 - 
adjusted_mode->crtc_vblank_start;
} else {
crtc_state->vrr.pipeline_full =
-   min(255, crtc_state->vrr.vmin - 
adjusted_mode->crtc_vdisplay -
+   min(255, crtc_state->vrr.vmin - 
adjusted_mode->crtc_vblank_start -
crtc_state->framestart_delay - 1);
}
 
-- 
2.39.1

[Intel-gfx] [PATCH v2 0/4] drm/i915: vblank stuff

[Ville Syrjala]

From: Ville Syrjälä 

A bunch of stuff related to vblank length/start.

v2: Fix inactive pipe handling
Fix SAGV handling
Fix some typos

Ville Syrjälä (4):
  drm/i915/vrr: Fix "window2" handling
  drm/i915/psr: Fix the delayed vblank w/a
  drm/i915: Extract skl_wm_latency()
  drm/i915: Reject wm levels that exceed vblank time

 drivers/gpu/drm/i915/display/intel_psr.c |   9 +-
 drivers/gpu/drm/i915/display/intel_vrr.c |  10 +-
 drivers/gpu/drm/i915/display/skl_watermark.c | 155 +--
 3 files changed, 144 insertions(+), 30 deletions(-)

-- 
2.39.1

Re: [Intel-gfx] [PATCH i-g-t 1/6] intel_gpu_top: Fix man page formatting

[Kamil Konieczny]

Hi Tvrtko,

On 2023-01-27 at 11:12:36 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> New lines are not respected when rst2man generates the page so try to work
> around that by followin advice from the Internet.
> 
> v2:
>  * Improve some wording.
>  * Tidy -o option description.
>  * Update dates.
>  * Convert the filter list to table.
> 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Kamil Konieczny  # v1
--- ^
Remove this addition at end,
s/ # v1//

Man page looks much better so you can keep my r-b,
thank you for your effort,

Regards,
Kamil

> ---
>  man/intel_gpu_top.rst | 55 ---
>  1 file changed, 25 insertions(+), 30 deletions(-)
> 
> diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
> index 748c7740c800..4417bcff0d5b 100644
> --- a/man/intel_gpu_top.rst
> +++ b/man/intel_gpu_top.rst
> @@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
>  -
>  .. include:: defs.rst
>  :Author: IGT Developers 
> -:Date: 2020-03-18
> +:Date: 2023-01-27
>  :Version: |PACKAGE_STRING|
> -:Copyright: 2009,2011,2012,2016,2018,2019,2020 Intel Corporation
> +:Copyright: 2009,2011,2012,2016,2018,2019,2020,2023 Intel Corporation
>  :Manual section: |MANUAL_SECTION|
>  :Manual group: |MANUAL_GROUP|
>  
> @@ -23,7 +23,7 @@ DESCRIPTION
>  
>  **intel_gpu_top** is a tool to display usage information on Intel GPU's.
>  
> -The tool gathers data using perf performance counters (PMU) exposed by i915 
> and other platform drivers like RAPL (power) and Uncore IMC (memory 
> bandwidth).
> +The tool presents data collected from performance counters (PMU), exposed by 
> i915 and other platform drivers like RAPL (power) and Uncore IMC (memory 
> bandwidth).
>  
>  OPTIONS
>  ===
> @@ -37,49 +37,44 @@ OPTIONS
>  -l
>  List plain text data.
>  
> --o 
> -Output to the specified file instead of standard output.
> -'-' can also be specified to explicitly select standard output.
> +-o , or -o -
> +Output to the specified file instead of standard output. '-' can also be 
> specified to explicitly select standard output.
>  
>  -s 
>  Refresh period in milliseconds.
> +
>  -L
> -List available GPUs on the platform.
> +List available GPUs on the system.
> +
>  -d
> -Select a specific GPU using supported filter.
> +Select a specific GPU using one of the supported filters.
>  
>  RUNTIME CONTROL
>  ===
>  
>  Supported keys:
>  
> -'q'Exit from the tool.
> -'h'Show interactive help.
> -'1'Toggle between aggregated engine class and physical engine mode.
> -'n'Toggle display of numeric client busyness overlay.
> -'s'Toggle between sort modes (runtime, total runtime, pid, client 
> id).
> -'i'Toggle display of clients which used no GPU time.
> -'H'Toggle between per PID aggregation and individual clients.
> +|
> +|'q'Exit from the tool.
> +|'h'Show interactive help.
> +|'1'Toggle between aggregated by engine class and physical engine 
> mode.
> +|'n'Toggle display of numeric client busyness overlay.
> +|'s'Toggle between sort modes (runtime, total runtime, pid, client 
> id).
> +|'i'Toggle display of clients which used no GPU time.
> +|'H'Toggle between per PID aggregation and individual clients.
>  
>  DEVICE SELECTION
>  
>  
> -User can select specific GPU for performance monitoring on platform where 
> multiple GPUs are available.
> -A GPU can be selected by sysfs path, drm node or using various PCI sub 
> filters.
> -
> -Filter types: ::
> -
> ----
> -filter   syntax
> ----
> -sys  sys:/sys/devices/pci:00/:00:02.0
> - find device by its sysfs path
> -
> -drm  drm:/dev/dri/* path
> - find drm device by /dev/dri/* node
> +On systems where multiple GPUs are present it is possible to select a 
> specific GPU to be monitored. A GPU can be selected by sysfs path, drm device 
> node or using various PCI sub filters.
>  
> -pci  pci:[vendor=%04x/name][,device=%04x][,card=%d]
> - vendor is hex number or vendor name
> +==  == 
> ==
> +**Filter**  **Syntax** **GPU 
> selection criteria**
> +==  == 
> ==
> +sys  | ``sys:/sys/devices/pci:00/:00:02.0``Select 
> using the sysfs path.
> +drm  | ``drm:/dev/dri/`` Select 
> using the /dev/dri/\* device node.
> +pci  | ``pci:[vendor=%04x/name][,device=%04x][,card=%d]``  Select 
> using the PCI addrress. Vendor is hexadecinal number or vendor name.
> +==  == 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Luca Coelho]

On Fri, 2023-01-27 at 16:37 +0200, Jani Nikula wrote:
> On Fri, 27 Jan 2023, Tvrtko Ursulin  wrote:
> > On 26/01/2023 16:05, Jani Nikula wrote:
> > > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > > On Thu, 2023-01-26 at 14:11 +0200, Luca Coelho wrote:
> > > > > On Thu, 2023-01-26 at 14:00 +0200, Jani Nikula wrote:
> > > > > > On Thu, 26 Jan 2023, Luca Coelho  wrote:
> > > > > > > On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > > > > > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > index 7d4a15a283a0..63b79c611932 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > > > > @@ -1559,7 +1559,26 @@ void 
> > > > > > > > > intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
> > > > > > > > >   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
> > > > > > > > > plane->id), 0);
> > > > > > > > >   }
> > > > > > > > >   
> > > > > > > > > -void intel_psr2_program_plane_sel_fetch(struct intel_plane 
> > > > > > > > > *plane,
> > > > > > > > > +void intel_psr2_program_plane_sel_fetch_arm(struct 
> > > > > > > > > intel_plane *plane,
> > > > > > > > > + const struct 
> > > > > > > > > intel_crtc_state *crtc_state,
> > > > > > > > > + const struct 
> > > > > > > > > intel_plane_state *plane_state,
> > > > > > > > > + int color_plane)
> > > > > > > > > +{
> > > > > > > > > + struct drm_i915_private *dev_priv = 
> > > > > > > > > to_i915(plane->base.dev);
> > > > > > > 
> > > > > > > Should you use i915 instead of dev_priv? I've heard and read 
> > > > > > > elsewhere
> > > > > > > that this is generally a desired change.  Much easier to use 
> > > > > > > always the
> > > > > > > same local name for this kind of thing.  Though this file is 
> > > > > > > already
> > > > > > > interspersed with both versions...
> > > > > > 
> > > > > > Basically the only reason to use dev_priv for new code is to deal 
> > > > > > with
> > > > > > some register macros that still have implicit dev_priv in
> > > > > > them. Otherwise, i915 should be used, and when convenient, dev_priv
> > > > > > should be converted to i915 while touching the code anyway (in a
> > > > > > separate patch, but while you're there).
> > > > > 
> > > > > Thanks for the clarification! In this case we're not using any of the
> > > > > macros, AFAICT, so I guess it's better to go with i915 already? And I
> > > > > think it should even be in this same patch, since it's a new function
> > > > > anyway.
> > > > > 
> > > > > 
> > > > > > The implicit dev_priv dependencies in the register macros are a bit
> > > > > > annoying to fix, and it's been going slow. In retrospect maybe the 
> > > > > > right
> > > > > > thing would have been to just sed the parameter to all of them
> > > > > > everywhere and be done with it for good. Not too late now, I guess, 
> > > > > > and
> > > > > > I'd take the patches in a heartbeat if someone were to step up and 
> > > > > > do
> > > > > > it.
> > > > > 
> > > > > I see that there is a boatload of register macros using it... I won't
> > > > > promise, but I think it would be a good exercise for a n00b like me to
> > > > > make this patch, though I already foresee another boatload of 
> > > > > conflicts
> > > > > with the internal trees and everything...
> > > > 
> > > > There were actually 10 boatloads of places to change:
> > > > 
> > > >   187 files changed, 12104 insertions(+), 12104 deletions(-)
> > > > 
> > > > ...but it _does_ compile. 
> > > > 
> > > > Do you think this is fine? Lots of shuffle, but if you think it's okay,
> > > > I can send the patch out now.
> > > 
> > > Heh, I said I'd take patchES, not everything together! ;)
> > > 
> > > Rodrigo, Tvrtko, Joonas, thoughts?
> > 
> > IMO if the elimination of implicit dev_priv is not included then I am 
> > not sure the churn is worth the effort.
> > 
> > I think one trap is that it is easy to assume solving those conflicts is 
> > easy because there is a script, somewhere, whatever, but one needs to be 
> > careful with assuming a random person hitting a merge conflict will 
> > realize there is a script, know where to find it, and know how to use it 
> > against a state where conflict markers are sitting in their local tree. 
> > That's a lot of assumed knowledge which my experience tells me is not 
> > universally there.
> > 
> > Having said all that, I looked at the occurrence histogram for the 
> > proposed churn and gut feel says conflicts wouldn't even be that bad 
> > since they seem heavily localized in a handful of files plus the display 
> > subdir.
> > 
> > Plus it is upstream.. so we are allowed not to care too much about 
> > backporting woes. I would still hope implicit dev_priv, albeit 
> > orthogonal, would be coming somewhat 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement async_flip mode per plane tracking (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: implement async_flip mode per plane tracking (rev5)
URL   : https://patchwork.freedesktop.org/series/108371/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12655 -> Patchwork_108371v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 24)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}:   NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [DMESG-FAIL][2] ([i915#5334]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-1}:   [ABORT][4] -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/bat-rpls-1/igt@i915_selftest@l...@requests.html
- {bat-adlp-6}:   [ABORT][6] -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-adlp-6/igt@i915_selftest@l...@requests.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/bat-adlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@workarounds:
- {bat-rplp-1}:   [INCOMPLETE][8] -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12655/bat-rplp-1/igt@i915_selftest@l...@workarounds.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/bat-rplp-1/igt@i915_selftest@l...@workarounds.html

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

  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852


Build changes
-

  * Linux: CI_DRM_12655 -> Patchwork_108371v5

  CI-20190529: 20190529
  CI_DRM_12655: d9b0bc4a0e9edfcbf171e09d3743b7186cd801f7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7139: 1e2fdea2a5547aba6d8595b7ac1c5e4543e90f2f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108371v5: d9b0bc4a0e9edfcbf171e09d3743b7186cd801f7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

367b64475e60 drm/i915: implement async_flip mode per plane tracking

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

[Kamil Konieczny]

Hi Tvrtko,

On 2023-01-27 at 11:12:41 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Now that DRM subsystem can contain PCI cards with the vendor set to Intel
> but they are not Intel GPUs, we need a better selection logic than looking
> at the vendor. Use the driver name instead.
> 
> Caveat that the driver key was on a blacklist so far, and although I can't
> imagine it can be slow to probe, this is something to double check.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Kamil Konieczny 
> Cc: Zbigniew Kempczyński 

Please send this as separate patch, not in this series.

> ---
>  lib/igt_device_scan.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index ed128d24dd10..8b767eed202d 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -237,6 +237,7 @@ struct igt_device {
>   char *vendor;
>   char *device;
>   char *pci_slot_name;
> + char *driver;
>   int gpu_index; /* For more than one GPU with same vendor and device. */
>  
>   char *codename; /* For grouping by codename */
> @@ -440,7 +441,6 @@ static bool is_on_blacklist(const char *what)
> "resource3", "resource4", "resource5",
> "resource0_wc", "resource1_wc", 
> "resource2_wc",
> "resource3_wc", "resource4_wc", 
> "resource5_wc",
> -   "driver",
> "uevent", NULL};
>   const char *key;
>   int i = 0;
> @@ -662,6 +662,8 @@ static struct igt_device *igt_device_new_from_udev(struct 
> udev_device *dev)
>   get_pci_vendor_device(idev, , );
>   idev->codename = __pci_codename(vendor, device);
>   idev->dev_type = __pci_devtype(vendor, device, 
> idev->pci_slot_name);
> + idev->driver = strdup_nullsafe(get_attr(idev, "driver"));
> + igt_assert(idev->driver);
>   }
>  
>   return idev;
> @@ -776,7 +778,7 @@ static bool __find_first_i915_card(struct igt_device_card 
> *card, bool discrete)
>  
>   igt_list_for_each_entry(dev, _devs.all, link) {
>  
> - if (!is_pci_subsystem(dev) || !is_vendor_matched(dev, "intel"))
> + if (!is_pci_subsystem(dev) || strcmp(dev->driver, "i915"))

Put the comment here why it can be problematic to relay on driver name.

Regards,
Kamil

>   continue;
>  
>   cmp = strncmp(dev->pci_slot_name, INTEGRATED_I915_GPU_PCI_ID,
> @@ -1023,6 +1025,7 @@ static void igt_device_free(struct igt_device *dev)
>   free(dev->drm_render);
>   free(dev->vendor);
>   free(dev->device);
> + free(dev->driver);
>   free(dev->pci_slot_name);
>   g_hash_table_destroy(dev->attrs_ht);
>   g_hash_table_destroy(dev->props_ht);
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH i-g-t 5/6] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU

[Kamil Konieczny]

Hi Tvrtko,

On 2023-01-27 at 11:12:40 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Avoid trying to dereference null engines on exit when there are either
> none which are supported, or kernel does not have i915 PMU support.
> 
> Also fix a memory leak on the same failure path just so Valgrind runs are
> quite.
> 
> v2:
>  * Fix a memory leak in the same failure mode too.

Please rebase, patch do not apply.

> 
> Signed-off-by: Tvrtko Ursulin 
> Acked-by: Nirmoy Das  # v1
 ^
Delete this.

Rest looks good,

Regards,
Kamil

> ---
>  tools/intel_gpu_top.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index 7aa233570463..0a1de41b3374 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -340,7 +340,7 @@ static struct engines *discover_engines(char *device)
>  
>   d = opendir(sysfs_root);
>   if (!d)
> - return NULL;
> + goto err;
>  
>   while ((dent = readdir(d)) != NULL) {
>   const char *endswith = "-busy";
> @@ -423,10 +423,8 @@ static struct engines *discover_engines(char *device)
>   }
>  
>   if (ret) {
> - free(engines);
>   errno = ret;
> -
> - return NULL;
> + goto err;
>   }
>  
>   qsort(engine_ptr(engines, 0), engines->num_engines,
> @@ -435,6 +433,11 @@ static struct engines *discover_engines(char *device)
>   engines->root = d;
>  
>   return engines;
> +
> +err:
> + free(engines);
> +
> + return NULL;
>  }
>  
>  static void free_engines(struct engines *engines)
> @@ -448,6 +451,9 @@ static void free_engines(struct engines *engines)
>   };
>   unsigned int i;
>  
> + if (!engines)
> + return;
> +
>   for (pmu = _list[0]; *pmu; pmu++) {
>   if ((*pmu)->present)
>   free((char *)(*pmu)->units);
> @@ -2568,7 +2574,7 @@ int main(int argc, char **argv)
>   "Failed to detect engines! (%s)\n(Kernel 4.16 or newer 
> is required for i915 PMU support.)\n",
>   strerror(errno));
>   ret = EXIT_FAILURE;
> - goto err;
> + goto err_engines;
>   }
>  
>   ret = pmu_init(engines);
> @@ -2585,7 +2591,7 @@ int main(int argc, char **argv)
>  "More information can be found at 'Perf events and tool security' 
> document:\n"
>  "https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n;);
>   ret = EXIT_FAILURE;
> - goto err;
> + goto err_pmu;
>   }
>  
>   ret = EXIT_SUCCESS;
> @@ -2699,8 +2705,9 @@ int main(int argc, char **argv)
>   free_clients(clients);
>  
>   free(codename);
> -err:
> +err_pmu:
>   free_engines(engines);
> +err_engines:
>   free(pmu_device);
>  exit:
>   igt_devices_free();
> -- 
> 2.34.1
> 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: implement async_flip mode per plane tracking (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: implement async_flip mode per plane tracking (rev5)
URL   : https://patchwork.freedesktop.org/series/108371/
State : warning

== Summary ==

Error: dim checkpatch failed
39da81540542 drm/i915: implement async_flip mode per plane tracking
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#14: 
DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 
0x06] PTE Read access is not set

-:62: CHECK:LINE_SPACING: Please don't use multiple blank lines
#62: FILE: drivers/gpu/drm/i915/display/intel_color.c:1511:
 
+

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

[Intel-gfx] [PATCH] drm/i915: probe lmem before the stolen portion

[Matthew Auld]

At the very least, we have some tests that force the BAR size for
testing purposes, which would result in different BAR size with
stolen-lmem vs normal lmem, since the BAR is only resized as part of the
normal lmem probing.

Signed-off-by: Matthew Auld 
Cc: Andrzej Hajda 
Cc: Nirmoy Das 
---
 drivers/gpu/drm/i915/i915_driver.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index cf1c0970ecb4..320a4f861659 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -489,13 +489,17 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
if (ret)
goto err_ggtt;
 
-   ret = intel_memory_regions_hw_probe(dev_priv);
+   /*
+* Make sure we probe lmem before we probe stolen-lmem. The BAR size
+* might be different due to bar resizing.
+*/
+   ret = intel_gt_tiles_init(dev_priv);
if (ret)
goto err_ggtt;
 
-   ret = intel_gt_tiles_init(dev_priv);
+   ret = intel_memory_regions_hw_probe(dev_priv);
if (ret)
-   goto err_mem_regions;
+   goto err_ggtt;
 
ret = i915_ggtt_enable_hw(dev_priv);
if (ret) {
-- 
2.39.1

[Intel-gfx] [PATCH v4] drm/i915: implement async_flip mode per plane tracking

[Andrzej Hajda]

Current implementation of async flip w/a relies on assumption that
previous atomic commit contains valid information if async_flip is still
enabled on the plane. It is incorrect. If previous commit did not modify
the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
errors can be observed:
i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 
0x06] PTE Read access is not set

v2: update async_flip_planes in more reliable places (Ville)
v3: reset async_flip_planes and do_async_flip in more scenarios (Ville)
v4: move all resets to plane loops (Ville)

Signed-off-by: Andrzej Hajda 
---
Hi Ville,

I am not sure about this change. I wonder if in case of
for*plane loops code could be like:

new_crtc_state->async_flip_planes &= ~BIT(plane->id);
if (!new_crtc_state->async_flip_planes)
new_crtc_state->do_async_flip = false;

But let's see what CI says.

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 5 -
 drivers/gpu/drm/i915/display/intel_color.c | 3 +++
 drivers/gpu/drm/i915/display/intel_display.c   | 9 ++---
 drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
 drivers/gpu/drm/i915/display/skl_watermark.c   | 4 
 5 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 1409bcfb6fd3d9..3bd8f7eb75a60b 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -363,6 +363,7 @@ void intel_plane_set_invisible(struct intel_crtc_state 
*crtc_state,
crtc_state->scaled_planes &= ~BIT(plane->id);
crtc_state->nv12_planes &= ~BIT(plane->id);
crtc_state->c8_planes &= ~BIT(plane->id);
+   crtc_state->async_flip_planes &= ~BIT(plane->id);
crtc_state->data_rate[plane->id] = 0;
crtc_state->data_rate_y[plane->id] = 0;
crtc_state->rel_data_rate[plane->id] = 0;
@@ -582,8 +583,10 @@ static int intel_plane_atomic_calc_changes(const struct 
intel_crtc_state *old_cr
 intel_plane_is_scaled(new_plane_state
new_crtc_state->disable_lp_wm = true;
 
-   if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state))
+   if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state)) {
new_crtc_state->do_async_flip = true;
+   new_crtc_state->async_flip_planes |= BIT(plane->id);
+   }
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 8d97c299e6577b..2ca7a016a9d9d1 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1500,12 +1500,15 @@ intel_color_add_affected_planes(struct intel_crtc_state 
*new_crtc_state)
return PTR_ERR(plane_state);
 
new_crtc_state->update_planes |= BIT(plane->id);
+   new_crtc_state->async_flip_planes = 0;
+   new_crtc_state->do_async_flip = false;
 
/* plane control register changes blocked by CxSR */
if (HAS_GMCH(i915))
new_crtc_state->disable_cxsr = true;
}
 
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 717ca3d7890d34..fcd3f1c7af3291 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1252,7 +1252,8 @@ static void intel_crtc_async_flip_disable_wa(struct 
intel_atomic_state *state,
intel_atomic_get_old_crtc_state(state, crtc);
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
-   u8 update_planes = new_crtc_state->update_planes;
+   u8 disable_async_flip_planes = old_crtc_state->async_flip_planes &
+  ~new_crtc_state->async_flip_planes;
const struct intel_plane_state *old_plane_state;
struct intel_plane *plane;
bool need_vbl_wait = false;
@@ -1261,7 +1262,7 @@ static void intel_crtc_async_flip_disable_wa(struct 
intel_atomic_state *state,
for_each_old_intel_plane_in_state(state, plane, old_plane_state, i) {
if (plane->need_async_flip_disable_wa &&
plane->pipe == crtc->pipe &&
-   update_planes & BIT(plane->id)) {
+   disable_async_flip_planes & BIT(plane->id)) {
/*
 * Apart from the async flip bit we want to
 * preserve the old state for the plane.
@@ -1378,7 +1379,7 @@ static void 

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tvrtko Ursulin]

On 27/01/2023 14:11, Michal Koutný wrote:

On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin 
 wrote:

I think you missed the finish_suspend_scanning() part:

if (root_drmcs.suspended_period_us)
cancel_delayed_work_sync(_drmcs.scan_work);

So if scanning was in progress migration will wait until it finishes.


Indeed, I've missed that. Thank you!


Not claiming I did not miss something because I was totally new with cgroup
internals when I started working on this. So it is definitely useful to have
more eyes looking.


The custom with (especially v2, especially horizontal) migrations
is that they're treated leniently to avoid performance costs.

I'm afraid waiting for scan in can_attach() can propagate globally (via
cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.


That something along those lines might be a concern was indeed worrying 
me when coming up with the scheme. Good inside knowledge hint, thank 
you. I will have a deeper look.



OTOH, unless I misunderstood, you need to cover explicit (not task but
resource, when sending client FD around) migration anyway?


Correct. So far that was handled outside the cgroup controller in the 
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating 
the struct pid based client tracking and so become relevant.



(I.e. my suggestion would be to mutualy exclude scanning and explicit
migration but not scanning and task migration in order to avoid possible
global propagation.)


Thanks, I will look into this all hopefully shortly. Perhaps what you 
suggest will come naturally with the removal of struct pid based tracking.


Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Add selftests for TLB invalidation (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add selftests for TLB invalidation (rev5)
URL   : https://patchwork.freedesktop.org/series/112894/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12654_full -> Patchwork_112894v5_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (10 -> 10)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_12654_full and 
Patchwork_112894v5_full:

### New IGT tests (1) ###

  * igt@i915_selftest@live@gt_tlb:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][1] -> [FAIL][2] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  
 Possible fixes 

  * igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][3] ([i915#658]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-2/igt@feature_discov...@psr1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-6/igt@feature_discov...@psr1.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [FAIL][5] ([i915#2846]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][7] ([i915#2842]) -> [PASS][8] +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [FAIL][9] ([i915#2842]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-glk2/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-glk8/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_reloc@basic-gtt:
- {shard-rkl}:[SKIP][11] ([i915#3281]) -> [PASS][12] +11 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-3/igt@gem_exec_re...@basic-gtt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gem_exec_re...@basic-gtt.html

  * igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:[SKIP][13] ([i915#7276]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-3/igt@gem_exec_sched...@semaphore-power.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gem_exec_sched...@semaphore-power.html

  * igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][15] ([fdo#111656]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-4/igt@gem_mmap_...@coherency.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gem_mmap_...@coherency.html

  * igt@gem_partial_pwrite_pread@reads-uncached:
- {shard-rkl}:[SKIP][17] ([i915#3282]) -> [PASS][18] +7 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-3/igt@gem_partial_pwrite_pr...@reads-uncached.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gem_partial_pwrite_pr...@reads-uncached.html

  * igt@gen9_exec_parse@shadow-peek:
- {shard-rkl}:[SKIP][19] ([i915#2527]) -> [PASS][20] +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-2/igt@gen9_exec_pa...@shadow-peek.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-5/igt@gen9_exec_pa...@shadow-peek.html

  * igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180:
- {shard-rkl}:[SKIP][21] ([i915#1845] / [i915#4098]) -> [PASS][22] 
+6 similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/shard-rkl-2/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/shard-rkl-6/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [FAIL][23] ([i915#2346]) -> [PASS][24]
   [23]: 

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Hogander, Jouni]

On Fri, 2023-01-27 at 14:00 +, Souza, Jose wrote:
> On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> > SEL_FETCH_CTL registers are armed immediately when plane is
> > disabled.
> > SEL_FETCH_* instances of plane configuration are used when doing
> > selective update and normal plane register instances for full
> > updates.
> > Currently all SEL_FETCH_* registers are written as a part of noarm
> > plane configuration. If noarm and arm plane configuration are not
> > happening within same vblank we may end up having plane as a part
> > of
> > selective update before it's PLANE_SURF register is written.
> > 
> > Fix this by splitting plane selective fetch configuration into arm
> > and
> > noarm versions and call them accordingly. Write SEL_FETCH_CTL in
> > arm
> > version.
> 
> Does this helps to revert the set of SFF and CFF at the same time?

No, this one is a separate issue.

> 
> > 
> > v2:
> >  - drop color_plane parameter from arm part
> >  - dev_priv -> i915 in arm part
> > 
> > Cc: Ville Syrjälä 
> > Cc: José Roberto de Souza 
> > Cc: Mika Kahola 
> > Cc: Vinod Govindapillai 
> > Cc: Stanislav Lisovskiy 
> > Cc: Luca Coelho 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
> >  drivers/gpu/drm/i915/display/intel_psr.c  | 28 +--
> > 
> >  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
> >  .../drm/i915/display/skl_universal_plane.c    |  4 ++-
> >  4 files changed, 30 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index d190fa0d393b..ae9f0b6c92db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -532,7 +532,8 @@ static void i9xx_cursor_update_arm(struct
> > intel_plane *plane,
> > skl_write_cursor_wm(plane, crtc_state);
> >  
> > if (plane_state)
> > -   intel_psr2_program_plane_sel_fetch(plane,
> > crtc_state, plane_state, 0);
> > +   intel_psr2_program_plane_sel_fetch_arm(plane,
> > crtc_state,
> > + 
> > plane_state);
> > else
> > intel_psr2_disable_plane_sel_fetch(plane,
> > crtc_state);
> 
> Missing rename intel_psr2_disable_plane_sel_fetch() to
> intel_psr2_disable_plane_sel_fetch_arm().

Yes, this makes sense. I will update the patch. Thank you for the
review.

> 
> With this LGTM.
> Reviewed-by: José Roberto de Souza 
> 
> 
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 7a72e15e6836..a3f4451eb66d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1559,7 +1559,25 @@ void
> > intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
> > intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe,
> > plane->id), 0);
> >  }
> >  
> > -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane
> > *plane,
> > +   const struct
> > intel_crtc_state *crtc_state,
> > +   const struct
> > intel_plane_state *plane_state)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(plane->base.dev);
> > +   enum pipe pipe = plane->pipe;
> > +
> > +   if (!crtc_state->enable_psr2_sel_fetch)
> > +   return;
> > +
> > +   if (plane->id == PLANE_CURSOR)
> > +   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe,
> > plane->id),
> > + plane_state->ctl);
> > +   else
> > +   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe,
> > plane->id),
> > + PLANE_SEL_FETCH_CTL_ENABLE);
> > +}
> > +
> > +void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane
> > *plane,
> > const struct
> > intel_crtc_state *crtc_state,
> > const struct
> > intel_plane_state *plane_state,
> > int color_plane)
> > @@ -1573,11 +1591,8 @@ void
> > intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > if (!crtc_state->enable_psr2_sel_fetch)
> > return;
> >  
> > -   if (plane->id == PLANE_CURSOR) {
> > -   intel_de_write_fw(dev_priv,
> > PLANE_SEL_FETCH_CTL(pipe, plane->id),
> > - plane_state->ctl);
> > +   if (plane->id == PLANE_CURSOR)
> > return;
> > -   }
> >  
> > clip = _state->psr2_sel_fetch_area;
> >  
> > @@ -1605,9 +1620,6 @@ void
> > intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > val = (drm_rect_height(clip) - 1) << 16;
> > val |= (drm_rect_width(_state->uapi.src) >> 16) 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Jani Nikula]

On Fri, 27 Jan 2023, Tvrtko Ursulin  wrote:
> On 26/01/2023 16:05, Jani Nikula wrote:
>> On Thu, 26 Jan 2023, Luca Coelho  wrote:
>>> On Thu, 2023-01-26 at 14:11 +0200, Luca Coelho wrote:
 On Thu, 2023-01-26 at 14:00 +0200, Jani Nikula wrote:
> On Thu, 26 Jan 2023, Luca Coelho  wrote:
>> On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
 diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
 b/drivers/gpu/drm/i915/display/intel_psr.c
 index 7d4a15a283a0..63b79c611932 100644
 --- a/drivers/gpu/drm/i915/display/intel_psr.c
 +++ b/drivers/gpu/drm/i915/display/intel_psr.c
 @@ -1559,7 +1559,26 @@ void intel_psr2_disable_plane_sel_fetch(struct 
 intel_plane *plane,
intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
 plane->id), 0);
   }
   
 -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
 +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
 +  const struct intel_crtc_state 
 *crtc_state,
 +  const struct intel_plane_state 
 *plane_state,
 +  int color_plane)
 +{
 +  struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
>>
>> Should you use i915 instead of dev_priv? I've heard and read elsewhere
>> that this is generally a desired change.  Much easier to use always the
>> same local name for this kind of thing.  Though this file is already
>> interspersed with both versions...
>
> Basically the only reason to use dev_priv for new code is to deal with
> some register macros that still have implicit dev_priv in
> them. Otherwise, i915 should be used, and when convenient, dev_priv
> should be converted to i915 while touching the code anyway (in a
> separate patch, but while you're there).

 Thanks for the clarification! In this case we're not using any of the
 macros, AFAICT, so I guess it's better to go with i915 already? And I
 think it should even be in this same patch, since it's a new function
 anyway.


> The implicit dev_priv dependencies in the register macros are a bit
> annoying to fix, and it's been going slow. In retrospect maybe the right
> thing would have been to just sed the parameter to all of them
> everywhere and be done with it for good. Not too late now, I guess, and
> I'd take the patches in a heartbeat if someone were to step up and do
> it.

 I see that there is a boatload of register macros using it... I won't
 promise, but I think it would be a good exercise for a n00b like me to
 make this patch, though I already foresee another boatload of conflicts
 with the internal trees and everything...
>>>
>>> There were actually 10 boatloads of places to change:
>>>
>>>   187 files changed, 12104 insertions(+), 12104 deletions(-)
>>>
>>> ...but it _does_ compile. 
>>>
>>> Do you think this is fine? Lots of shuffle, but if you think it's okay,
>>> I can send the patch out now.
>> 
>> Heh, I said I'd take patchES, not everything together! ;)
>> 
>> Rodrigo, Tvrtko, Joonas, thoughts?
>
> IMO if the elimination of implicit dev_priv is not included then I am 
> not sure the churn is worth the effort.
>
> I think one trap is that it is easy to assume solving those conflicts is 
> easy because there is a script, somewhere, whatever, but one needs to be 
> careful with assuming a random person hitting a merge conflict will 
> realize there is a script, know where to find it, and know how to use it 
> against a state where conflict markers are sitting in their local tree. 
> That's a lot of assumed knowledge which my experience tells me is not 
> universally there.
>
> Having said all that, I looked at the occurrence histogram for the 
> proposed churn and gut feel says conflicts wouldn't even be that bad 
> since they seem heavily localized in a handful of files plus the display 
> subdir.
>
> Plus it is upstream.. so we are allowed not to care too much about 
> backporting woes. I would still hope implicit dev_priv, albeit 
> orthogonal, would be coming somewhat together with the rename. For that 
> warm fuzzy feeling that the churn was really really worth it.

I was mostly talking about the implicit dev_priv removal. It's somewhat
easy, because you can always assume dev_priv is around when the macros
in question are used.

The above is a dependency to any renames. I don't think the renames are
as important as removing the implicit dev_priv, and the renames are
easier to handle piecemeal, say a file at a time or something.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v3] drm/i915: implement async_flip mode per plane tracking

[Ville Syrjälä]

On Fri, Jan 27, 2023 at 08:34:03AM +0100, Andrzej Hajda wrote:
> Current implementation of async flip w/a relies on assumption that
> previous atomic commit contains valid information if async_flip is still
> enabled on the plane. It is incorrect. If previous commit did not modify
> the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
> errors can be observed:
> i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
> i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
> DMAR: DRHD: handling fault status reg 2
> DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault 
> reason 0x06] PTE Read access is not set
> 
> v2: update async_flip_planes in more reliable places (Ville)
> v3: reset async_flip_planes and do_async_flip in more scenarios (Ville)
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 5 -
>  drivers/gpu/drm/i915/display/intel_color.c | 3 +++
>  drivers/gpu/drm/i915/display/intel_display.c   | 9 ++---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
>  drivers/gpu/drm/i915/display/skl_watermark.c   | 5 +
>  5 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 1409bcfb6fd3d9..3bd8f7eb75a60b 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -363,6 +363,7 @@ void intel_plane_set_invisible(struct intel_crtc_state 
> *crtc_state,
>   crtc_state->scaled_planes &= ~BIT(plane->id);
>   crtc_state->nv12_planes &= ~BIT(plane->id);
>   crtc_state->c8_planes &= ~BIT(plane->id);
> + crtc_state->async_flip_planes &= ~BIT(plane->id);
>   crtc_state->data_rate[plane->id] = 0;
>   crtc_state->data_rate_y[plane->id] = 0;
>   crtc_state->rel_data_rate[plane->id] = 0;
> @@ -582,8 +583,10 @@ static int intel_plane_atomic_calc_changes(const struct 
> intel_crtc_state *old_cr
>intel_plane_is_scaled(new_plane_state
>   new_crtc_state->disable_lp_wm = true;
>  
> - if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state))
> + if (intel_plane_do_async_flip(plane, old_crtc_state, new_crtc_state)) {
>   new_crtc_state->do_async_flip = true;
> + new_crtc_state->async_flip_planes |= BIT(plane->id);
> + }
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 8d97c299e6577b..5162b2b4ede080 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1506,6 +1506,9 @@ intel_color_add_affected_planes(struct intel_crtc_state 
> *new_crtc_state)
>   new_crtc_state->disable_cxsr = true;
>   }
>  
> + new_crtc_state->do_async_flip = false;
> + new_crtc_state->async_flip_planes = 0;

These should be next to the update_plane bitmask change.

> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 717ca3d7890d34..8581b32c9cf0eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1252,7 +1252,8 @@ static void intel_crtc_async_flip_disable_wa(struct 
> intel_atomic_state *state,
>   intel_atomic_get_old_crtc_state(state, crtc);
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
> - u8 update_planes = new_crtc_state->update_planes;
> + u8 disable_async_flip_planes = old_crtc_state->async_flip_planes &
> +~new_crtc_state->async_flip_planes;
>   const struct intel_plane_state *old_plane_state;
>   struct intel_plane *plane;
>   bool need_vbl_wait = false;
> @@ -1261,7 +1262,7 @@ static void intel_crtc_async_flip_disable_wa(struct 
> intel_atomic_state *state,
>   for_each_old_intel_plane_in_state(state, plane, old_plane_state, i) {
>   if (plane->need_async_flip_disable_wa &&
>   plane->pipe == crtc->pipe &&
> - update_planes & BIT(plane->id)) {
> + disable_async_flip_planes & BIT(plane->id)) {
>   /*
>* Apart from the async flip bit we want to
>* preserve the old state for the plane.
> @@ -1378,7 +1379,7 @@ static void intel_pre_plane_update(struct 
> intel_atomic_state *state,
>* WA for platforms where async address update enable bit
>* is double buffered and only latched at start of vblank.
>*/
> - if (old_crtc_state->uapi.async_flip && !new_crtc_state->uapi.async_flip)
> + if (old_crtc_state->async_flip_planes & 
> ~new_crtc_state->async_flip_planes)

Re: [Intel-gfx] [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

[Thomas Zimmermann]

Hi

Am 25.01.23 um 22:03 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:

Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 135d58b8007b..63f66325a8a5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
-	drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);

-
ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;


 From the documentation:
The drm_fb_helper_prepare()
helper must be called first to initialize the minimum required to make
hotplug detection work.
...
To finish up the fbdev helper initialization, the
drm_fb_helper_init() function is called.

So this change do not follow the documentation as drm_fb_helper_init()
is now called before drm_fb_helper_prepare()


No, we now call drm_fb_helper_prepare() from within 
drm_fbdev_generic_setup(), right after allocating the fb_helper. 
drm_fb_helper_init() will only be called after the client received a 
hot-plug event.




I did not follow all the code - but my gut feeling is that the
documentation is right.


The docs are of low quality. The _prepare() helper is the actual init 
function and _init() only sets the fb_helper in the device instance.


Best regards
Thomas



Sam



@@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper)
return;
+   drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
  
  	ret = drm_client_init(dev, _helper->client, "fbdev", _fbdev_client_funcs);

if (ret) {
-   kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
-   return;
+   goto err_drm_client_init;
}
  
  	/*

@@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
  
  	drm_client_register(_helper->client);

+
+   return;
+
+err_drm_client_init:
+   drm_fb_helper_unprepare(fb_helper);
+   kfree(fb_helper);
+   return;
  }
  EXPORT_SYMBOL(drm_fbdev_generic_setup);
--
2.39.0


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH v3 02/10] drm/client: Add hotplug_failed flag

[Thomas Zimmermann]

Hi

Am 25.01.23 um 21:57 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:

Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.

This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper,

I failed to find where we clear the pointers. What do I miss?


Those pointer fields, dev and funcs, where allocated with kzalloc(). The 
error path in drm_fbdev_client_hotplug() later reset them to NULL again 
if an error occured.


Best regards
Thomas


(I had assumed we would stop clearing the pointers after this change).

Sam

which prevents us from initializing these pointers

early after allocation.

The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_client.c| 5 +
  drivers/gpu/drm/drm_fbdev_generic.c | 4 
  include/drm/drm_client.h| 8 
  3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 09ac191c202d..009e7b10455c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!client->funcs || !client->funcs->hotplug)
continue;
  
+		if (client->hotplug_failed)

+   continue;
+
ret = client->funcs->hotplug(client);
drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
+   if (ret)
+   client->hotplug_failed = true;
}
mutex_unlock(>clientlist_mutex);
  }
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 3d455a2e3fb5..135d58b8007b 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
struct drm_device *dev = client->dev;
int ret;
  
-	/* Setup is not retried if it has failed */

-   if (!fb_helper->dev && fb_helper->funcs)
-   return 0;
-
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h

index 4fc8018eddda..39482527a775 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -106,6 +106,14 @@ struct drm_client_dev {
 * @modesets: CRTC configurations
 */
struct drm_mode_set *modesets;
+
+   /**
+* @hotplug failed:
+*
+* Set by client hotplug helpers if the hotplugging failed
+* before. It is usually not tried again.
+*/
+   bool hotplug_failed;
  };
  
  int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,

--
2.39.0


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Thomas Zimmermann]

Hi

Am 25.01.23 um 21:52 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:

Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_client.c| 5 +
  drivers/gpu/drm/drm_fbdev_generic.c | 5 -
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 262ec64d4397..09ac191c202d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
  
+	if (!dev->mode_config.num_connector) {

+   drm_dbg_kms(dev, "No connectors found, will not send hotplug 
events!\n");
+   return;

This deserves a more visible logging - if a driver fails here it would
be good to spot it in the normal kernel log.
drm_info or drm_notice?


But is that really noteworthy? AFAIK, this situation can legally happen. 
So if it's expected, why should we print a message about it?


Best regards
Thomas



The original code had this on the debug level, but when moving the log
level could also be updated.

Sam


+   }
+
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (!client->funcs || !client->funcs->hotplug)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 0a4c160e0e58..3d455a2e3fb5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
-	if (!dev->mode_config.num_connector) {

-   drm_dbg_kms(dev, "No connectors found, will not create 
framebuffer!\n");
-   return 0;
-   }
-
drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
  
  	ret = drm_fb_helper_init(dev, fb_helper);

--
2.39.0


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Tvrtko Ursulin]

On 26/01/2023 16:05, Jani Nikula wrote:

On Thu, 26 Jan 2023, Luca Coelho  wrote:

On Thu, 2023-01-26 at 14:11 +0200, Luca Coelho wrote:

On Thu, 2023-01-26 at 14:00 +0200, Jani Nikula wrote:

On Thu, 26 Jan 2023, Luca Coelho  wrote:

On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7d4a15a283a0..63b79c611932 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1559,7 +1559,26 @@ void intel_psr2_disable_plane_sel_fetch(struct 
intel_plane *plane,
intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
  }
  
-void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,

+void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
+   const struct intel_crtc_state 
*crtc_state,
+   const struct intel_plane_state 
*plane_state,
+   int color_plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);


Should you use i915 instead of dev_priv? I've heard and read elsewhere
that this is generally a desired change.  Much easier to use always the
same local name for this kind of thing.  Though this file is already
interspersed with both versions...


Basically the only reason to use dev_priv for new code is to deal with
some register macros that still have implicit dev_priv in
them. Otherwise, i915 should be used, and when convenient, dev_priv
should be converted to i915 while touching the code anyway (in a
separate patch, but while you're there).


Thanks for the clarification! In this case we're not using any of the
macros, AFAICT, so I guess it's better to go with i915 already? And I
think it should even be in this same patch, since it's a new function
anyway.



The implicit dev_priv dependencies in the register macros are a bit
annoying to fix, and it's been going slow. In retrospect maybe the right
thing would have been to just sed the parameter to all of them
everywhere and be done with it for good. Not too late now, I guess, and
I'd take the patches in a heartbeat if someone were to step up and do
it.


I see that there is a boatload of register macros using it... I won't
promise, but I think it would be a good exercise for a n00b like me to
make this patch, though I already foresee another boatload of conflicts
with the internal trees and everything...


There were actually 10 boatloads of places to change:

  187 files changed, 12104 insertions(+), 12104 deletions(-)

...but it _does_ compile. 

Do you think this is fine? Lots of shuffle, but if you think it's okay,
I can send the patch out now.


Heh, I said I'd take patchES, not everything together! ;)

Rodrigo, Tvrtko, Joonas, thoughts?


IMO if the elimination of implicit dev_priv is not included then I am 
not sure the churn is worth the effort.


I think one trap is that it is easy to assume solving those conflicts is 
easy because there is a script, somewhere, whatever, but one needs to be 
careful with assuming a random person hitting a merge conflict will 
realize there is a script, know where to find it, and know how to use it 
against a state where conflict markers are sitting in their local tree. 
That's a lot of assumed knowledge which my experience tells me is not 
universally there.


Having said all that, I looked at the occurrence histogram for the 
proposed churn and gut feel says conflicts wouldn't even be that bad 
since they seem heavily localized in a handful of files plus the display 
subdir.


Plus it is upstream.. so we are allowed not to care too much about 
backporting woes. I would still hope implicit dev_priv, albeit 
orthogonal, would be coming somewhat together with the rename. For that 
warm fuzzy feeling that the churn was really really worth it.


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Souza, Jose]

On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> SEL_FETCH_CTL registers are armed immediately when plane is disabled.
> SEL_FETCH_* instances of plane configuration are used when doing
> selective update and normal plane register instances for full updates.
> Currently all SEL_FETCH_* registers are written as a part of noarm
> plane configuration. If noarm and arm plane configuration are not
> happening within same vblank we may end up having plane as a part of
> selective update before it's PLANE_SURF register is written.
> 
> Fix this by splitting plane selective fetch configuration into arm and
> noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
> version.

Does this helps to revert the set of SFF and CFF at the same time?

> 
> v2:
>  - drop color_plane parameter from arm part
>  - dev_priv -> i915 in arm part
> 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Vinod Govindapillai 
> Cc: Stanislav Lisovskiy 
> Cc: Luca Coelho 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  | 28 +--
>  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
>  .../drm/i915/display/skl_universal_plane.c|  4 ++-
>  4 files changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index d190fa0d393b..ae9f0b6c92db 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -532,7 +532,8 @@ static void i9xx_cursor_update_arm(struct intel_plane 
> *plane,
>   skl_write_cursor_wm(plane, crtc_state);
>  
>   if (plane_state)
> - intel_psr2_program_plane_sel_fetch(plane, crtc_state, 
> plane_state, 0);
> + intel_psr2_program_plane_sel_fetch_arm(plane, crtc_state,
> +plane_state);
>   else
>   intel_psr2_disable_plane_sel_fetch(plane, crtc_state);

Missing rename intel_psr2_disable_plane_sel_fetch() to 
intel_psr2_disable_plane_sel_fetch_arm().

With this LGTM.
Reviewed-by: José Roberto de Souza 


>  
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7a72e15e6836..a3f4451eb66d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1559,7 +1559,25 @@ void intel_psr2_disable_plane_sel_fetch(struct 
> intel_plane *plane,
>   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
>  }
>  
> -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
> + const struct intel_crtc_state 
> *crtc_state,
> + const struct intel_plane_state 
> *plane_state)
> +{
> + struct drm_i915_private *i915 = to_i915(plane->base.dev);
> + enum pipe pipe = plane->pipe;
> +
> + if (!crtc_state->enable_psr2_sel_fetch)
> + return;
> +
> + if (plane->id == PLANE_CURSOR)
> + intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> +   plane_state->ctl);
> + else
> + intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> +   PLANE_SEL_FETCH_CTL_ENABLE);
> +}
> +
> +void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
>   const struct intel_crtc_state 
> *crtc_state,
>   const struct intel_plane_state 
> *plane_state,
>   int color_plane)
> @@ -1573,11 +1591,8 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
>   if (!crtc_state->enable_psr2_sel_fetch)
>   return;
>  
> - if (plane->id == PLANE_CURSOR) {
> - intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
> plane->id),
> -   plane_state->ctl);
> + if (plane->id == PLANE_CURSOR)
>   return;
> - }
>  
>   clip = _state->psr2_sel_fetch_area;
>  
> @@ -1605,9 +1620,6 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
>   val = (drm_rect_height(clip) - 1) << 16;
>   val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
>   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
> -
> - intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> -   PLANE_SEL_FETCH_CTL_ENABLE);
>  }
>  
>  void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
> *crtc_state)
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h 
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index 2ac3a465..c87ae2e6ee6c 100644
> --- 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid potential vm use-after-free

[Tvrtko Ursulin]

On 27/01/2023 13:10, Matthew Auld wrote:

On Mon, 23 Jan 2023 at 16:57, Tvrtko Ursulin
 wrote:



+ some more people based on e1a7ab4fca0c

On 19/01/2023 17:32, Rob Clark wrote:

From: Rob Clark 

Adding the vm to the vm_xa table makes it visible to userspace, which
could try to race with us to close the vm.  So we need to take our extra
reference before putting it in the table.

Signed-off-by: Rob Clark 
---
Note, you could list commit e1a7ab4fca0c ("drm/i915: Remove the vm open
count") as the "fixed" commit, but really the issue seems to go back
much further (with the fix needing some backporting in the process).


It would probably be rather essential to identify the correct Fixes: tag.

Since Thomas, Matt and Niranjana you were directly involved in the patch
which changed significantly how this works, perhaps there is something
still somewhat easily retrievable from your memory lanes to help with this?


Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld 

Looking at the git history, the fixes tag I think needs to be:

Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm")
Cc:  # v5.16+


As discussed offline this looks correct to me too. Thanks for looking 
into it!


Since the CI was green I have now merged the patch. Thanks for the fix Rob!

Regards,

Tvrtko

P.S. Backport to kernels which do not contain e1a7ab4fca0c ("drm/i915: 
Remove the vm open count"), so 5.16 to 5.18, will require a slightly 
different patch as Matt has also mentioned offline.






Regards,

Tvrtko



   drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
   1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6250de9b9196..e4b78ab4773b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private 
*file_priv,
   vm = ctx->vm;
   GEM_BUG_ON(!vm);

+ /*
+  * Get a reference for the allocated handle.  Once the handle is
+  * visible in the vm_xa table, userspace could try to close it
+  * from under our feet, so we need to hold the extra reference
+  * first.
+  */
+ i915_vm_get(vm);
+
   err = xa_alloc(_priv->vm_xa, , vm, xa_limit_32b, GFP_KERNEL);
- if (err)
+ if (err) {
+ i915_vm_put(vm);
   return err;
-
- i915_vm_get(vm);
+ }

   GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
   args->value = id;

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

[Petri Latvala]

On Fri, Jan 27, 2023 at 11:53:38AM +, Tvrtko Ursulin wrote:
> 
> On 27/01/2023 11:39, Petri Latvala wrote:
> > On Fri, Jan 27, 2023 at 11:12:41AM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > Now that DRM subsystem can contain PCI cards with the vendor set to Intel
> > > but they are not Intel GPUs, we need a better selection logic than looking
> > > at the vendor. Use the driver name instead.
> > > 
> > > Caveat that the driver key was on a blacklist so far, and although I can't
> > > imagine it can be slow to probe, this is something to double check.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Cc: Kamil Konieczny 
> > > Cc: Zbigniew Kempczyński 
> > > ---
> > >   lib/igt_device_scan.c | 7 +--
> > >   1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > > index ed128d24dd10..8b767eed202d 100644
> > > --- a/lib/igt_device_scan.c
> > > +++ b/lib/igt_device_scan.c
> > > @@ -237,6 +237,7 @@ struct igt_device {
> > >   char *vendor;
> > >   char *device;
> > >   char *pci_slot_name;
> > > + char *driver;
> > >   int gpu_index; /* For more than one GPU with same vendor and 
> > > device. */
> > >   char *codename; /* For grouping by codename */
> > > @@ -440,7 +441,6 @@ static bool is_on_blacklist(const char *what)
> > > "resource3", "resource4", 
> > > "resource5",
> > > "resource0_wc", "resource1_wc", 
> > > "resource2_wc",
> > > "resource3_wc", "resource4_wc", 
> > > "resource5_wc",
> > > -   "driver",
> > > "uevent", NULL};
> > >   const char *key;
> > >   int i = 0;
> > > @@ -662,6 +662,8 @@ static struct igt_device 
> > > *igt_device_new_from_udev(struct udev_device *dev)
> > >   get_pci_vendor_device(idev, , );
> > >   idev->codename = __pci_codename(vendor, device);
> > >   idev->dev_type = __pci_devtype(vendor, device, 
> > > idev->pci_slot_name);
> > > + idev->driver = strdup_nullsafe(get_attr(idev, "driver"));
> > > + igt_assert(idev->driver);
> > >   }
> > >   return idev;
> > > @@ -776,7 +778,7 @@ static bool __find_first_i915_card(struct 
> > > igt_device_card *card, bool discrete)
> > >   igt_list_for_each_entry(dev, _devs.all, link) {
> > > - if (!is_pci_subsystem(dev) || !is_vendor_matched(dev, "intel"))
> > > + if (!is_pci_subsystem(dev) || strcmp(dev->driver, "i915"))
> > 
> > Is this the time to prepare for that other driver as well?
> 
> Ha, didn't think of that TBH, but AFAICT this patch will work for that case
> too, no?

Ah, now that I read the surrounding code...

Indeed the function is for finding i915 devices in particular, used by
gem_wsim and intel_gpu_top. Having that function find devices driven
by xe might lead to incompatibilities that need to be resolved or at
least compatibility fully understood, which is not the case for either
at this time I assume. In other words, out of scope for this patch.


-- 
Petri Latvala

Re: [Intel-gfx] [PATCH v8 5/6] drm/i915/mtl: Add function to send command to GSC CS

[Teres Alexis, Alan Previn]

On Tue, 2023-01-24 at 15:12 +0530, Kandpal, Suraj wrote:
> Add function that takes care of sending command to gsc cs. We start
> of with allocation of memory for our command intel_hdcp_gsc_message that
> contains gsc cs memory header as directed in specs followed by the
> actual payload hdcp message that we want to send.
> Spec states that we need to poll pending bit of response header around
> 20 times each try being 50ms apart hence adding that to current
> gsc_msg_send function
> Also we use the same function to take care of both sending and receiving
> hence no separate function to get the response.
> 
> --v4
> -Create common function to fill in gsc_mtl_header [Alan]
> -define host session bitmask [Alan]
> 
> --v5
> -use i915 directly instead of gt->i915 [Alan]
> -No need to make fields NULL as we are already
> using kzalloc [Alan]
> 
> --v8
> -change mechanism to reuse the same memory for one hdcp session[Alan]
> -fix header ordering
> -add comments to explain flags and host session mask [Alan]
> 
> Cc: Ankit Nautiyal 
> Cc: Daniele Ceraolo Spurio 
> Cc: Alan Pervin Teres 
> Cc: Uma Shankar 
> Cc: Anshuman Gupta 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  .../gpu/drm/i915/display/intel_display_core.h |   5 +
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  20 ++
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 185 ++
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  27 +++
>  .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |  15 ++
>  .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  16 ++
>  7 files changed, 269 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 461d6b40656d..194aae92c354 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -254,6 +254,7 @@ i915-y += \
> display/intel_frontbuffer.o \
> display/intel_global_state.o \
> display/intel_hdcp.o \
> +   display/intel_hdcp_gsc.o \
> display/intel_hotplug.o \
> display/intel_hti.o \
> display/intel_lpe_audio.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index 132e9134ba05..7e9f3f87c767 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -372,6 +372,11 @@ struct intel_display {
> struct i915_hdcp_master *master;
> bool comp_added;
>  
> +   /*HDCP message struct for allocation of memory which can be 
> reused
> +    * when sending message to gsc cs
> +    * this is only populated post Meteorlake
> +    */
> +   struct intel_hdcp_gsc_message *hdcp_message;
> /* Mutex to protect the above hdcp component related values. 
> */
> struct mutex comp_mutex;
alan: apologies for these additional self-narration drizzled with questions 
after
an 8th rev - please bear with me:

1. Firstly thanks for changing the codes from allocating 'struct 
intel_hdcp_gsc_message'
   dynamically-as-we-need-send-a-msg it to an init-time allocation that we can 
continue
   to use over life of a hdcp-enabled-connector (so we dont have to keep 
allocating and
   freeing every few seconds).
2. With this new code i was lead to look at "intel_display->hdcp" usage. 
intel_display
   is a global context i.e. (not per crtc) and the hdcp substruct in 
intel_display is
   holding global structures too (with comp_mutex protecting master). However
   'struct intel_hdcp_gsc_message' is used at a per-connector level (but only 
for active
   connectors which cannot exist without an attached crtc).
3. That said, although we do use comp_mutex for all the connector level hdcp 
activity,
   those activities sit behind a global lock and component interface. To me 
this looks
   inefficient because we are forcing serialization of hdcp operations across 
all the
   connectors with active hdcp operatoin. Putting an instance of hdcp_message 
per connector
   will allow parallelism and reduce overall latencies. (perhaps attaching 
hdcp_message
   to crtc works better as we might have more logical connectors than active - 
capped
   strictly by no. of crtcs).
4. I am aware that in the past we wouldn't have gained anything by such 
paralellism since
   the hdcp interactions would have to be serialized behind the hdcp component 
interface
   anyway. Today, with the gsc engine, we could try to parallelize stuff a bit 
more?
   (but not completely since there is only one gsc firmware and I can't recall 
if the GSC fw
   can operate on hdcp requests in parallel and if they support different 
host-session-
   handles per display pipe). As such, I am not sure if this ask can gain any 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/8] Vendor agnostic gputop

[Tvrtko Ursulin]

On 26/01/2023 17:02, Kamil Konieczny wrote:

Hi,

please rebase and resend, also please change commit subject to start
with lib: or lib/[name of lib changed]: rest od commit description


Series should still apply as is so I don't think there is need to 
re-send. It will only conflict if I get to merge the "Assorted 
intel_gpu_top improvements" series first, in which case I can resend.



For example, in 3/8 instead of
libdrmclients: Record client drm minor
write:
lib/igt_drm_clients: Record client drm minor

If there are more lib changes, use "lib: " alone, for example
in your 2/8 patch,
libdrmfdinfo: Allow specifying custom engine map
write:
lib: Allow specifying custom engine map


Again, if you agree there is no need to spam the list with a re-send 
yet, review can continue against this version, and I will note to change 
the above patch prefixes while doing the other changes the review is 
bound to trigger.


Regards,

Tvrtko



+Cc Petri and Zbyszek

Regards,
Kamil

On 2022-11-11 at 15:58:36 +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This is a pile of patches which implements a rudimentary vendor agnostic gputop
tool based of the new DRM spec as documented in
Documentation/gpu/drm-usage-stats.rst.

First part of the series is code refactoring which should be reasonably stable.
I've tested it all while working on it both against intel_gpu_top and gputop.

Last patch is the actual tool itself. It works but it is rather rudimentary
which is hopefully good enough for a start.

Fundamental difference between intel_gpu_top and gputop is that the former is
centered around a single card and only shows processes belonging to it. Gputop
on the other hand has an idea to show all processes with DRM file descriptors
open and sort them into groups per card. It also makes no effort to provide
sorting modes, well any interactivity, or any pretty names for GPUs or engines.

It looks like this:

DRM minor 0
 PID   NAMErender   copy   video
 3816  kwin_x11 |███▎  ||  ||  ||  |
 3523  Xorg |▊ ||  ||  ||  |
  1120449   mpv |  ||  ||▋ ||  |
  1120529  glxgears |▋ ||  ||  ||  |
  1120449   mpv |▍ ||  ||  ||  |
 3860   plasmashell |▏ ||  ||  ||  |
 4764   krunner |  ||  ||  ||  |
   575206chrome |  ||  ||  ||  |
   833481   firefox |  ||  ||  ||  |
   892924   thunderbird |  ||  ||  ||  |


I did test it as well with two cards and confirmed that too works.

Rob Clark also tested it with a patch which exports the respective data from the
msm driver and confirmed it works fine. Christian König tested it with in
progress patches for amdgpu and that worked as well.

v2:
  * Fixed SPDX headers and added a bunch of code comments/docs throughout.

Tvrtko Ursulin (8):
   lib: Extract igt_drm_clients from intel_gpu_top
   libdrmfdinfo: Allow specifying custom engine map
   libdrmclients: Record client drm minor
   libdrmclient: Support multiple DRM cards
   libdrmfdinfo: Track largest engine index
   libdrmclient/intel_gpu_top: Decouple hardcoded engine assumptions
   libdrmclient: Enforce client status sort order in the library
   gputop: Basic vendor agnostic GPU top tool

  lib/igt_drm_clients.c   | 503 +
  lib/igt_drm_clients.h   |  87 ++
  lib/igt_drm_fdinfo.c|  50 ++-
  lib/igt_drm_fdinfo.h|  16 +-
  lib/meson.build |   8 +
  tests/i915/drm_fdinfo.c |  19 +-
  tools/gputop.c  | 260 +++
  tools/intel_gpu_top.c   | 677 +++-
  tools/meson.build   |   7 +-
  9 files changed, 1113 insertions(+), 514 deletions(-)
  create mode 100644 lib/igt_drm_clients.c
  create mode 100644 lib/igt_drm_clients.h
  create mode 100644 tools/gputop.c

--
2.34.1

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tvrtko Ursulin]

On 27/01/2023 13:01, Michal Koutný wrote:

On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin 
 wrote:

+static int drmcs_can_attach(struct cgroup_taskset *tset)
+{
+   int ret;
+
+   /*
+* As processes are getting moved between groups we need to ensure
+* both that the old group does not see a sudden downward jump in the
+* GPU utilisation, and that the new group does not see a sudden jump
+* up with all the GPU time clients belonging to the migrated process
+* have accumulated.
+*
+* To achieve that we suspend the scanner until the migration is
+* completed where the resume at the end ensures both groups start
+* observing GPU utilisation from a reset state.
+*/
+
+   ret = mutex_lock_interruptible(_mutex);
+   if (ret)
+   return ret;
+   start_suspend_scanning();
+   mutex_unlock(_mutex);
+
+   finish_suspend_scanning();


Here's scanning suspension, communicated via

root_drmcs.scanning_suspended = true;
root_drmcs.suspended_period_us = root_drmcs.period_us;
root_drmcs.period_us = 0;

but I don't see those used in scan_worker() and the scanning traversal
can apparently run concurrently with a task migration.


I think you missed the finish_suspend_scanning() part:

if (root_drmcs.suspended_period_us)
cancel_delayed_work_sync(_drmcs.scan_work);

So if scanning was in progress migration will wait until it finishes. 
And re-start only when migration is done (drmcs_attach), or it failed 
(drmcs_cancel_attach).


Not claiming I did not miss something because I was totally new with 
cgroup internals when I started working on this. So it is definitely 
useful to have more eyes looking.



[...]
+static bool
+__start_scanning(struct drm_cgroup_state *root, unsigned int period_us)
[...]
+   css_for_each_descendant_post(node, >css) {
[...]
+   active = drmcs_get_active_time_us(drmcs);
+   if (period_us && active > drmcs->prev_active_us)
+   drmcs->active_us += active - drmcs->prev_active_us;
+   drmcs->prev_active_us = active;


drmcs_get_active_time_us() could count a task's contribution here,
the task would migrate to a different drmcs,
and it'd be counted 2nd time.


Lets see.. __start_scanning() can be called from the worker, so max one 
instance at a time, no issue.


Then from resume scanning, so it is guaranteed worker is not running and 
can't restart since mutex guards the re-start.


Finally from drmcs_write_period_us() - yes there __start_scanning() can 
race with it being invoked by the worker - oops! However.. this is just 
a debugging aid as the cover letter explains. This file is not intended 
to be present in the final version, rather as per earlier discussion 
with Tejun the idea is to only have boot time option to control the 
functionality (enable/disable or period).


I will nevertheless try to fix this race up for the next posting to 
avoid further confusion!


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915: Avoid potential vm use-after-free

[Matthew Auld]

On Mon, 23 Jan 2023 at 16:57, Tvrtko Ursulin
 wrote:
>
>
> + some more people based on e1a7ab4fca0c
>
> On 19/01/2023 17:32, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Adding the vm to the vm_xa table makes it visible to userspace, which
> > could try to race with us to close the vm.  So we need to take our extra
> > reference before putting it in the table.
> >
> > Signed-off-by: Rob Clark 
> > ---
> > Note, you could list commit e1a7ab4fca0c ("drm/i915: Remove the vm open
> > count") as the "fixed" commit, but really the issue seems to go back
> > much further (with the fix needing some backporting in the process).
>
> It would probably be rather essential to identify the correct Fixes: tag.
>
> Since Thomas, Matt and Niranjana you were directly involved in the patch
> which changed significantly how this works, perhaps there is something
> still somewhat easily retrievable from your memory lanes to help with this?

Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld 

Looking at the git history, the fixes tag I think needs to be:

Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm")
Cc:  # v5.16+

>
> Regards,
>
> Tvrtko
>
> >
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
> >   1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 6250de9b9196..e4b78ab4773b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private 
> > *file_priv,
> >   vm = ctx->vm;
> >   GEM_BUG_ON(!vm);
> >
> > + /*
> > +  * Get a reference for the allocated handle.  Once the handle is
> > +  * visible in the vm_xa table, userspace could try to close it
> > +  * from under our feet, so we need to hold the extra reference
> > +  * first.
> > +  */
> > + i915_vm_get(vm);
> > +
> >   err = xa_alloc(_priv->vm_xa, , vm, xa_limit_32b, GFP_KERNEL);
> > - if (err)
> > + if (err) {
> > + i915_vm_put(vm);
> >   return err;
> > -
> > - i915_vm_get(vm);
> > + }
> >
> >   GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
> >   args->value = id;

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Add selftests for TLB invalidation (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add selftests for TLB invalidation (rev5)
URL   : https://patchwork.freedesktop.org/series/112894/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12654 -> Patchwork_112894v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (26 -> 25)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@i915_selftest@live@gt_tlb} (NEW):
- fi-bsw-nick:NOTRUN -> [DMESG-FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/fi-bsw-nick/igt@i915_selftest@live@gt_tlb.html
- fi-bsw-n3050:   NOTRUN -> [DMESG-FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/fi-bsw-n3050/igt@i915_selftest@live@gt_tlb.html

  
New tests
-

  New tests have been introduced between CI_DRM_12654 and Patchwork_112894v5:

### New IGT tests (1) ###

  * igt@i915_selftest@live@gt_tlb:
- Statuses : 2 dmesg-fail(s) 23 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][3] -> [INCOMPLETE][4] ([i915#6972] / 
[i915#7911])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
- fi-kbl-soraka:  [PASS][5] -> [INCOMPLETE][6] ([i915#7156])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6600u:   [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@gt_lrc:
- {bat-adlp-6}:   [INCOMPLETE][10] ([i915#4983] / [i915#7913]) -> 
[PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][12] ([i915#6257]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12654/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112894v5/bat-rpls-2/igt@i915_selftest@l...@requests.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6972]: https://gitlab.freedesktop.org/drm/intel/issues/6972
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913


Build changes
-

  * Linux: CI_DRM_12654 -> Patchwork_112894v5

  CI-20190529: 20190529
  CI_DRM_12654: a2c772f5e02e24678456b5e66384de742110e1a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7137: 5f7ea985ac0828bec5e1bbc101b7931bd7fb62e3 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112894v5: a2c772f5e02e24678456b5e66384de742110e1a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

32ae0050b663 drm/i915/gt: Add selftests for TLB invalidation

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Add selftests for TLB invalidation (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add selftests for TLB invalidation (rev5)
URL   : https://patchwork.freedesktop.org/series/112894/
State : warning

== Summary ==

Error: dim checkpatch failed
9ba7aae4 drm/i915/gt: Add selftests for TLB invalidation
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#39: 
new file mode 100644

-:67: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#67: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:24:
+   GEM_BUG_ON(addr < i915_vma_offset(vma));

-:68: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#68: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:25:
+   GEM_BUG_ON(addr >= i915_vma_offset(vma) + i915_vma_size(vma) + 
sizeof(val));

-:114: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#114: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:71:
+   GEM_BUG_ON(i915_vma_offset(va) != addr);

-:181: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#181: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:138:
+   msleep(10);

-:217: WARNING:MEMORY_BARRIER: memory barrier without comment
#217: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:174:
+   wmb();

-:262: WARNING:LINE_SPACING: Missing a blank line after declarations
#262: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:219:
+   enum intel_engine_id id;
+   I915_RND_STATE(prng);

-:296: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#296: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:253:
+   GEM_BUG_ON(A->base.size != B->base.size);

-:357: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#357: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:314:
+   err = pte_tlbinv(ce, va, vb,
+   BIT_ULL(bit),

total: 0 errors, 8 warnings, 1 checks, 407 lines checked

[Intel-gfx] [PATCH v4] drm/i915/gt: Add selftests for TLB invalidation

[Andrzej Hajda]

From: Chris Wilson 

Check that we invalidate the TLB cache, the updated physical addresses
are immediately visible to the HW, and there is no retention of the old
physical address for concurrent HW access.

Signed-off-by: Chris Wilson 
[ahajda: adjust to upstream driver, v2+]
Signed-off-by: Andrzej Hajda 
---
v2:
- addressed comments (Tvrtko),
- changed pin/sample address calculation,
- removed checks for platforms older than 8,
- use low ints in MI_DO_COMPARE to be more clear,
- continue test if physical addresses have the same uppper 32 bits,
- consolidate two calls to pte_tlbinv into one
v3:
- skip pages not supported by vm (CI reported EINVAL),
- fix dw size in MI_CONDITIONAL_BATCH_BUFFER_END for gen8 (CI reported EIO),
- remove aggressive allocation to get different upper halves of physical
  address (CI reported OOM).
v4:
- align address in MI_CONDITIONAL_BATCH_BUFFER_END to 8b,
- set QWORD pointed by addr in above cmd, as required by Gen8/VCS.
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |   1 +
 drivers/gpu/drm/i915/gt/intel_gt.c|   4 +
 drivers/gpu/drm/i915/gt/selftest_tlb.c| 386 ++
 .../drm/i915/selftests/i915_live_selftests.h  |   1 +
 4 files changed, 392 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gt/selftest_tlb.c

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 2af1ae3831df98..e10507fa71ce63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -394,6 +394,7 @@
 #define MI_LOAD_URB_MEM MI_INSTR(0x2C, 0)
 #define MI_STORE_URB_MEMMI_INSTR(0x2D, 0)
 #define MI_CONDITIONAL_BATCH_BUFFER_END MI_INSTR(0x36, 0)
+#define  MI_DO_COMPARE REG_BIT(21)
 
 #define STATE_BASE_ADDRESS \
((0x3 << 29) | (0x0 << 27) | (0x1 << 24) | (0x1 << 16))
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f0dbfc434e0773..001a7ec5b86182 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1205,3 +1205,7 @@ void intel_gt_invalidate_tlb(struct intel_gt *gt, u32 
seqno)
mutex_unlock(>tlb.invalidate_lock);
}
 }
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_tlb.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/selftest_tlb.c 
b/drivers/gpu/drm/i915/gt/selftest_tlb.c
new file mode 100644
index 00..fb25ef699a764d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_tlb.c
@@ -0,0 +1,386 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include "i915_selftest.h"
+
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
+
+#include "gen8_engine_cs.h"
+#include "i915_gem_ww.h"
+#include "intel_engine_regs.h"
+#include "intel_gpu_commands.h"
+#include "intel_context.h"
+#include "intel_gt.h"
+#include "intel_ring.h"
+
+#include "selftests/igt_flush_test.h"
+#include "selftests/i915_random.h"
+
+static void vma_set_qw(struct i915_vma *vma, u64 addr, u64 val)
+{
+   GEM_BUG_ON(addr < i915_vma_offset(vma));
+   GEM_BUG_ON(addr >= i915_vma_offset(vma) + i915_vma_size(vma) + 
sizeof(val));
+   memset64(page_mask_bits(vma->obj->mm.mapping) +
+(addr - i915_vma_offset(vma)), val, 1);
+}
+
+static int
+pte_tlbinv(struct intel_context *ce,
+  struct i915_vma *va,
+  struct i915_vma *vb,
+  u64 align,
+  void (*tlbinv)(struct i915_address_space *vm, u64 addr, u64 length),
+  u64 length,
+  struct rnd_state *prng)
+{
+   struct drm_i915_gem_object *batch;
+   struct i915_request *rq;
+   struct i915_vma *vma;
+   u32 dw_len;
+   u64 addr;
+   int err;
+   u32 *cs;
+
+   batch = i915_gem_object_create_internal(ce->vm->i915, 4096);
+   if (IS_ERR(batch))
+   return PTR_ERR(batch);
+
+   vma = i915_vma_instance(batch, ce->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto out;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_USER);
+   if (err)
+   goto out;
+
+   /* Pin va at random but aligned offset after vma */
+   addr = round_up(vma->node.start + vma->node.size, align);
+   /* MI_CONDITIONAL_BATCH_BUFFER_END limits address to 48b */
+   addr = igt_random_offset(prng, addr, min(ce->vm->total, BIT_ULL(48)),
+va->size, align);
+   err = i915_vma_pin(va,  0, 0, addr | PIN_OFFSET_FIXED | PIN_USER);
+   if (err) {
+   pr_err("Cannot pin at %llx+%llx\n", addr, va->size);
+   goto out;
+   }
+   GEM_BUG_ON(i915_vma_offset(va) != addr);
+   vb->node = va->node; /* overwrites the _same_ PTE  */
+
+   /*
+* Now choose random dword at the 1st pinned page.
+*
+* SZ_64K pages on dg1 require that the whole PT be 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

[Tvrtko Ursulin]

On 27/01/2023 11:39, Petri Latvala wrote:

On Fri, Jan 27, 2023 at 11:12:41AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Now that DRM subsystem can contain PCI cards with the vendor set to Intel
but they are not Intel GPUs, we need a better selection logic than looking
at the vendor. Use the driver name instead.

Caveat that the driver key was on a blacklist so far, and although I can't
imagine it can be slow to probe, this is something to double check.

Signed-off-by: Tvrtko Ursulin 
Cc: Kamil Konieczny 
Cc: Zbigniew Kempczyński 
---
  lib/igt_device_scan.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index ed128d24dd10..8b767eed202d 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -237,6 +237,7 @@ struct igt_device {
char *vendor;
char *device;
char *pci_slot_name;
+   char *driver;
int gpu_index; /* For more than one GPU with same vendor and device. */
  
  	char *codename; /* For grouping by codename */

@@ -440,7 +441,6 @@ static bool is_on_blacklist(const char *what)
  "resource3", "resource4", "resource5",
  "resource0_wc", "resource1_wc", 
"resource2_wc",
  "resource3_wc", "resource4_wc", 
"resource5_wc",
- "driver",
  "uevent", NULL};
const char *key;
int i = 0;
@@ -662,6 +662,8 @@ static struct igt_device *igt_device_new_from_udev(struct 
udev_device *dev)
get_pci_vendor_device(idev, , );
idev->codename = __pci_codename(vendor, device);
idev->dev_type = __pci_devtype(vendor, device, 
idev->pci_slot_name);
+   idev->driver = strdup_nullsafe(get_attr(idev, "driver"));
+   igt_assert(idev->driver);
}
  
  	return idev;

@@ -776,7 +778,7 @@ static bool __find_first_i915_card(struct igt_device_card 
*card, bool discrete)
  
  	igt_list_for_each_entry(dev, _devs.all, link) {
  
-		if (!is_pci_subsystem(dev) || !is_vendor_matched(dev, "intel"))

+   if (!is_pci_subsystem(dev) || strcmp(dev->driver, "i915"))


Is this the time to prepare for that other driver as well?


Ha, didn't think of that TBH, but AFAICT this patch will work for that 
case too, no?


Regards,

Tvrtko

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

[Petri Latvala]

On Fri, Jan 27, 2023 at 11:12:41AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Now that DRM subsystem can contain PCI cards with the vendor set to Intel
> but they are not Intel GPUs, we need a better selection logic than looking
> at the vendor. Use the driver name instead.
> 
> Caveat that the driver key was on a blacklist so far, and although I can't
> imagine it can be slow to probe, this is something to double check.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Kamil Konieczny 
> Cc: Zbigniew Kempczyński 
> ---
>  lib/igt_device_scan.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> index ed128d24dd10..8b767eed202d 100644
> --- a/lib/igt_device_scan.c
> +++ b/lib/igt_device_scan.c
> @@ -237,6 +237,7 @@ struct igt_device {
>   char *vendor;
>   char *device;
>   char *pci_slot_name;
> + char *driver;
>   int gpu_index; /* For more than one GPU with same vendor and device. */
>  
>   char *codename; /* For grouping by codename */
> @@ -440,7 +441,6 @@ static bool is_on_blacklist(const char *what)
> "resource3", "resource4", "resource5",
> "resource0_wc", "resource1_wc", 
> "resource2_wc",
> "resource3_wc", "resource4_wc", 
> "resource5_wc",
> -   "driver",
> "uevent", NULL};
>   const char *key;
>   int i = 0;
> @@ -662,6 +662,8 @@ static struct igt_device *igt_device_new_from_udev(struct 
> udev_device *dev)
>   get_pci_vendor_device(idev, , );
>   idev->codename = __pci_codename(vendor, device);
>   idev->dev_type = __pci_devtype(vendor, device, 
> idev->pci_slot_name);
> + idev->driver = strdup_nullsafe(get_attr(idev, "driver"));
> + igt_assert(idev->driver);
>   }
>  
>   return idev;
> @@ -776,7 +778,7 @@ static bool __find_first_i915_card(struct igt_device_card 
> *card, bool discrete)
>  
>   igt_list_for_each_entry(dev, _devs.all, link) {
>  
> - if (!is_pci_subsystem(dev) || !is_vendor_matched(dev, "intel"))
> + if (!is_pci_subsystem(dev) || strcmp(dev->driver, "i915"))

Is this the time to prepare for that other driver as well?


-- 
Petri Latvala


>   continue;
>  
>   cmp = strncmp(dev->pci_slot_name, INTEGRATED_I915_GPU_PCI_ID,
> @@ -1023,6 +1025,7 @@ static void igt_device_free(struct igt_device *dev)
>   free(dev->drm_render);
>   free(dev->vendor);
>   free(dev->device);
> + free(dev->driver);
>   free(dev->pci_slot_name);
>   g_hash_table_destroy(dev->attrs_ht);
>   g_hash_table_destroy(dev->props_ht);
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

[Tvrtko Ursulin]

On 27/01/2023 10:04, Michal Koutný wrote:

On Thu, Jan 26, 2023 at 05:57:24PM +, Tvrtko Ursulin 
 wrote:

So even if the RFC shows just a simple i915 implementation, the controller
itself shouldn't prevent a smarter approach (via exposed ABI).


scan/query + over budget notification is IMO limited in guarantees.


It is yes, I tried to stress out that it is not a hard guarantee in any 
shape and form and that the "quality" of adhering to the allocated 
budget will depend on individual hw and sw capabilities.


But it is what I believe is the best approach given a) how different in 
scheduling capability GPU drivers are and b) the very fact there isn't a 
central scheduling entity as opposed to the CPU side of things.


It is just no possible to do a hard guarantee system. GPUs do not 
preempt as nicely and easily as the CPUs do. And the frequency of 
context switches varies widely from too fast to "never", so again, 
charging would have several problems to overcome which would make the 
whole setup IMHO pointless.


And not only that some GPUs do not preempt nicely, but some even can't 
do any of this, period. Even if we stay within the lineage of hardware 
supported by only i915, we have three distinct categories: 1) can't do 
any of this, 2a) can do fine grained priority based scheduling with 
reasonable preemption capability, 2b) ditto but without reasonable 
preemption capability, and 3) like 2a) and 2b) but with the scheduler in 
the firmware and currently supporting coarse priority based scheduling.


Shall I also mention that a single cgroup can contain multiple GPU 
clients, all using different GPUs with a different mix of the above 
listed challenges?


The main point is, should someone prove me wrong and come up a smarter 
way at some point in the future, then "drm.weight" as an ABI remains 
compatible and the improvement can happen completely under the hood. In 
the mean time users get external control, and _some_ ability to improve 
the user experience with the scenarios such as I described yesterday.



[...]
Yes agreed, and to re-stress out, the ABI as proposed does not preclude
changing from scanning to charging or whatever. The idea was for it to be
compatible in concept with the CPU controller and also avoid baking in the
controlling method to individual drivers.
[...]


But I submit to your point of rather not exposing this via cgroup API
for possible future refinements.


Ack.


Secondly, doing this in userspace would require the ability to get some sort
of an atomic snapshot of the whole tree hierarchy to account for changes in
layout of the tree and task migrations. Or some retry logic with some added
ABI fields to enable it.


Note, that the proposed implementation is succeptible to miscount due to
concurrent tree modifications and task migrations too (scanning may not
converge under frequent cgroup layout modifications, and migrating tasks
may be summed 0 or >1 times). While in-kernel implementation may assure
the snapshot view, it'd come at cost. (Read: since the mechanism isn't
precise anyway, I don't suggest a fully synchronized scanning.)


The part that scanning may not converge in my _current implementation_ 
is true. For instance if clients would be constantly coming and going, 
for that I took a shortcut of not bothering to accumulate usage on 
process/client exit, and I just wait for a stable two periods to look at 
the current state. I reckon this is possibly okay for the real world.


Cgroup tree hierarchy modifications being the reason for not converging 
can also happen, but I thought I can hand wave that as not a realistic 
scenario. Perhaps I am not imaginative enough?


Under or over-accounting for migrating tasks I don't think can happen 
since I am explicitly handling that.


Regards,

Tvrtko

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Split sel fetch plane configuration into arm and noarm (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Split sel fetch plane configuration into arm and noarm 
(rev2)
URL   : https://patchwork.freedesktop.org/series/113321/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12652_full -> Patchwork_113321v2_full


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_eio@wait-wedge-immediate:
- {shard-rkl}:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-3/igt@gem_...@wait-wedge-immediate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-3/igt@gem_...@wait-wedge-immediate.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2346])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-5/igt@drm_fdinfo@most-busy-check-...@rcs0.html

  * igt@fbdev@read:
- {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-2/igt@fb...@read.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-6/igt@fb...@read.html

  * igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][9] ([i915#658]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-2/igt@feature_discov...@psr2.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-6/igt@feature_discov...@psr2.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- {shard-rkl}:[SKIP][11] ([i915#6252]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-4/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][15] ([i915#3281]) -> [PASS][16] +11 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-4/igt@gem_exec_re...@basic-gtt-read-noreloc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read-noreloc.html

  * igt@gem_mmap_wc@set-cache-level:
- {shard-rkl}:[SKIP][17] ([i915#1850]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-3/igt@gem_mmap...@set-cache-level.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-6/igt@gem_mmap...@set-cache-level.html

  * igt@gem_pwrite@basic-self:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +6 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-4/igt@gem_pwr...@basic-self.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-5/igt@gem_pwr...@basic-self.html

  * igt@gen9_exec_parse@bb-chained:
- {shard-rkl}:[SKIP][21] ([i915#2527]) -> [PASS][22] +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12652/shard-rkl-2/igt@gen9_exec_pa...@bb-chained.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/shard-rkl-5/igt@gen9_exec_pa...@bb-chained.html

  * igt@i915_pipe_stress@stress-xrgb-ytiled:
- {shard-rkl}:[SKIP][23] 

[Intel-gfx] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Now that DRM subsystem can contain PCI cards with the vendor set to Intel
but they are not Intel GPUs, we need a better selection logic than looking
at the vendor. Use the driver name instead.

Caveat that the driver key was on a blacklist so far, and although I can't
imagine it can be slow to probe, this is something to double check.

Signed-off-by: Tvrtko Ursulin 
Cc: Kamil Konieczny 
Cc: Zbigniew Kempczyński 
---
 lib/igt_device_scan.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index ed128d24dd10..8b767eed202d 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -237,6 +237,7 @@ struct igt_device {
char *vendor;
char *device;
char *pci_slot_name;
+   char *driver;
int gpu_index; /* For more than one GPU with same vendor and device. */
 
char *codename; /* For grouping by codename */
@@ -440,7 +441,6 @@ static bool is_on_blacklist(const char *what)
  "resource3", "resource4", "resource5",
  "resource0_wc", "resource1_wc", 
"resource2_wc",
  "resource3_wc", "resource4_wc", 
"resource5_wc",
- "driver",
  "uevent", NULL};
const char *key;
int i = 0;
@@ -662,6 +662,8 @@ static struct igt_device *igt_device_new_from_udev(struct 
udev_device *dev)
get_pci_vendor_device(idev, , );
idev->codename = __pci_codename(vendor, device);
idev->dev_type = __pci_devtype(vendor, device, 
idev->pci_slot_name);
+   idev->driver = strdup_nullsafe(get_attr(idev, "driver"));
+   igt_assert(idev->driver);
}
 
return idev;
@@ -776,7 +778,7 @@ static bool __find_first_i915_card(struct igt_device_card 
*card, bool discrete)
 
igt_list_for_each_entry(dev, _devs.all, link) {
 
-   if (!is_pci_subsystem(dev) || !is_vendor_matched(dev, "intel"))
+   if (!is_pci_subsystem(dev) || strcmp(dev->driver, "i915"))
continue;
 
cmp = strncmp(dev->pci_slot_name, INTEGRATED_I915_GPU_PCI_ID,
@@ -1023,6 +1025,7 @@ static void igt_device_free(struct igt_device *dev)
free(dev->drm_render);
free(dev->vendor);
free(dev->device);
+   free(dev->driver);
free(dev->pci_slot_name);
g_hash_table_destroy(dev->attrs_ht);
g_hash_table_destroy(dev->props_ht);
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 5/6] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.

Also fix a memory leak on the same failure path just so Valgrind runs are
quite.

v2:
 * Fix a memory leak in the same failure mode too.

Signed-off-by: Tvrtko Ursulin 
Acked-by: Nirmoy Das  # v1
---
 tools/intel_gpu_top.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..0a1de41b3374 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -340,7 +340,7 @@ static struct engines *discover_engines(char *device)
 
d = opendir(sysfs_root);
if (!d)
-   return NULL;
+   goto err;
 
while ((dent = readdir(d)) != NULL) {
const char *endswith = "-busy";
@@ -423,10 +423,8 @@ static struct engines *discover_engines(char *device)
}
 
if (ret) {
-   free(engines);
errno = ret;
-
-   return NULL;
+   goto err;
}
 
qsort(engine_ptr(engines, 0), engines->num_engines,
@@ -435,6 +433,11 @@ static struct engines *discover_engines(char *device)
engines->root = d;
 
return engines;
+
+err:
+   free(engines);
+
+   return NULL;
 }
 
 static void free_engines(struct engines *engines)
@@ -448,6 +451,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
 
+   if (!engines)
+   return;
+
for (pmu = _list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2574,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or newer 
is required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
-   goto err;
+   goto err_engines;
}
 
ret = pmu_init(engines);
@@ -2585,7 +2591,7 @@ int main(int argc, char **argv)
 "More information can be found at 'Perf events and tool security' document:\n"
 "https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n;);
ret = EXIT_FAILURE;
-   goto err;
+   goto err_pmu;
}
 
ret = EXIT_SUCCESS;
@@ -2699,8 +2705,9 @@ int main(int argc, char **argv)
free_clients(clients);
 
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
 exit:
igt_devices_free();
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 2/6] intel_gpu_top: Automatically enclose JSON output into brackets

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Parsers need the whole output enclosed into square brackets so every
period sample becomes an array element.

So far we have been suggesting this in the man page but we can trivially
make the tool output that itself.

Signed-off-by: Tvrtko Ursulin 
Cc: Eero Tamminen 
Reviewed-by: Kamil Konieczny 
---
 man/intel_gpu_top.rst | 2 +-
 tools/intel_gpu_top.c | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 4417bcff0d5b..caf0a9f9432c 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -79,7 +79,7 @@ pci  | 
``pci:[vendor=%04x/name][,device=%04x][,card=%d]``  Select using
 JSON OUTPUT
 ===
 
-To parse the JSON as output by the tool the consumer should wrap its entirety 
into square brackets ([ ]). This will make each sample point a JSON array 
element and will avoid "Multiple root elements" JSON validation error.
+JSON output will be correctly terminated when the tool cleanly exits, 
otherwise one square bracket needs to be added before parsing.
 
 LIMITATIONS
 ===
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 6de8a164fcff..c4d98de4fe31 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -2597,6 +2597,9 @@ int main(int argc, char **argv)
scan_clients(clients, false);
codename = igt_device_get_pretty_name(, false);
 
+   if (output_mode == JSON)
+   printf("[\n");
+
while (!stop_top) {
struct clients *disp_clients;
bool consumed = false;
@@ -2683,6 +2686,9 @@ int main(int argc, char **argv)
usleep(period_us);
}
 
+   if (output_mode == JSON)
+   printf("]\n");
+
if (clients)
free_clients(clients);
 
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 4/6] intel_gpu_top: Aggregate engine classes in all output modes

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Use the same default for stdout and JSON output modes as it is for
interactive.

Previously added command line switch can be used to go back to showing all
physical engines.

Signed-off-by: Tvrtko Ursulin 
Cc: Dmitry Rogozhkin 
Reviewed-by: Kamil Konieczny 
---
 tools/intel_gpu_top.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index e91b47baf72b..7aa233570463 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -2509,11 +2509,12 @@ int main(int argc, char **argv)
if (signal(SIGINT, sigint_handler) == SIG_ERR)
fprintf(stderr, "Failed to install signal handler!\n");
 
+   class_view = !physical_engines;
+
switch (output_mode) {
case INTERACTIVE:
pops = _pops;
interactive_stdin();
-   class_view = !physical_engines;
break;
case STDOUT:
pops = _pops;
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 3/6] intel_gpu_top: Add command line switch to start in physical engine mode

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Default mode is to aggreate engines per class but some users would prefer
to be able to start in physical engine mode too.

Signed-off-by: Tvrtko Ursulin 
Cc: Dmitry Rogozhkin 
Reviewed-by: Kamil Konieczny 
---
 man/intel_gpu_top.rst | 3 +++
 tools/intel_gpu_top.c | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index caf0a9f9432c..69834756b81e 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -49,6 +49,9 @@ OPTIONS
 -d
 Select a specific GPU using one of the supported filters.
 
+-p
+   Default to showing physical engines instead of aggregated classes.
+
 RUNTIME CONTROL
 ===
 
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index c4d98de4fe31..e91b47baf72b 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1268,6 +1268,7 @@ usage(const char *appname)
"\t[-s ]   Refresh period in milliseconds (default 
%ums).\n"
"\t[-L]List all cards.\n"
"\t[-d ]   Device filter, please check manual page for 
more details.\n"
+   "\t[-p]Default to showing physical engines instead 
of classes.\n"
"\n",
appname, DEFAULT_PERIOD_MS);
igt_device_print_filter_types();
@@ -2446,6 +2447,7 @@ int main(int argc, char **argv)
 {
unsigned int period_us = DEFAULT_PERIOD_MS * 1000;
struct clients *clients = NULL;
+   bool physical_engines = false;
int con_w = -1, con_h = -1;
char *output_path = NULL;
struct engines *engines;
@@ -2456,7 +2458,7 @@ int main(int argc, char **argv)
char *codename = NULL;
 
/* Parse options */
-   while ((ch = getopt(argc, argv, "o:s:d:JLlh")) != -1) {
+   while ((ch = getopt(argc, argv, "o:s:d:pJLlh")) != -1) {
switch (ch) {
case 'o':
output_path = optarg;
@@ -2467,6 +2469,9 @@ int main(int argc, char **argv)
case 'd':
opt_device = strdup(optarg);
break;
+   case 'p':
+   physical_engines = true;
+   break;
case 'J':
output_mode = JSON;
break;
@@ -2508,7 +2513,7 @@ int main(int argc, char **argv)
case INTERACTIVE:
pops = _pops;
interactive_stdin();
-   class_view = true;
+   class_view = !physical_engines;
break;
case STDOUT:
pops = _pops;
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 1/6] intel_gpu_top: Fix man page formatting

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

New lines are not respected when rst2man generates the page so try to work
around that by followin advice from the Internet.

v2:
 * Improve some wording.
 * Tidy -o option description.
 * Update dates.
 * Convert the filter list to table.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Kamil Konieczny  # v1
---
 man/intel_gpu_top.rst | 55 ---
 1 file changed, 25 insertions(+), 30 deletions(-)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 748c7740c800..4417bcff0d5b 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
 -
 .. include:: defs.rst
 :Author: IGT Developers 
-:Date: 2020-03-18
+:Date: 2023-01-27
 :Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016,2018,2019,2020 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018,2019,2020,2023 Intel Corporation
 :Manual section: |MANUAL_SECTION|
 :Manual group: |MANUAL_GROUP|
 
@@ -23,7 +23,7 @@ DESCRIPTION
 
 **intel_gpu_top** is a tool to display usage information on Intel GPU's.
 
-The tool gathers data using perf performance counters (PMU) exposed by i915 
and other platform drivers like RAPL (power) and Uncore IMC (memory bandwidth).
+The tool presents data collected from performance counters (PMU), exposed by 
i915 and other platform drivers like RAPL (power) and Uncore IMC (memory 
bandwidth).
 
 OPTIONS
 ===
@@ -37,49 +37,44 @@ OPTIONS
 -l
 List plain text data.
 
--o 
-Output to the specified file instead of standard output.
-'-' can also be specified to explicitly select standard output.
+-o , or -o -
+Output to the specified file instead of standard output. '-' can also be 
specified to explicitly select standard output.
 
 -s 
 Refresh period in milliseconds.
+
 -L
-List available GPUs on the platform.
+List available GPUs on the system.
+
 -d
-Select a specific GPU using supported filter.
+Select a specific GPU using one of the supported filters.
 
 RUNTIME CONTROL
 ===
 
 Supported keys:
 
-'q'Exit from the tool.
-'h'Show interactive help.
-'1'Toggle between aggregated engine class and physical engine mode.
-'n'Toggle display of numeric client busyness overlay.
-'s'Toggle between sort modes (runtime, total runtime, pid, client id).
-'i'Toggle display of clients which used no GPU time.
-'H'Toggle between per PID aggregation and individual clients.
+|
+|'q'Exit from the tool.
+|'h'Show interactive help.
+|'1'Toggle between aggregated by engine class and physical engine mode.
+|'n'Toggle display of numeric client busyness overlay.
+|'s'Toggle between sort modes (runtime, total runtime, pid, client id).
+|'i'Toggle display of clients which used no GPU time.
+|'H'Toggle between per PID aggregation and individual clients.
 
 DEVICE SELECTION
 
 
-User can select specific GPU for performance monitoring on platform where 
multiple GPUs are available.
-A GPU can be selected by sysfs path, drm node or using various PCI sub filters.
-
-Filter types: ::
-
----
-filter   syntax
----
-sys  sys:/sys/devices/pci:00/:00:02.0
- find device by its sysfs path
-
-drm  drm:/dev/dri/* path
- find drm device by /dev/dri/* node
+On systems where multiple GPUs are present it is possible to select a specific 
GPU to be monitored. A GPU can be selected by sysfs path, drm device node or 
using various PCI sub filters.
 
-pci  pci:[vendor=%04x/name][,device=%04x][,card=%d]
- vendor is hex number or vendor name
+==  == 
==
+**Filter**  **Syntax** **GPU 
selection criteria**
+==  == 
==
+sys  | ``sys:/sys/devices/pci:00/:00:02.0``Select 
using the sysfs path.
+drm  | ``drm:/dev/dri/`` Select 
using the /dev/dri/\* device node.
+pci  | ``pci:[vendor=%04x/name][,device=%04x][,card=%d]``  Select 
using the PCI addrress. Vendor is hexadecinal number or vendor name.
+==  == 
==
 
 JSON OUTPUT
 ===
-- 
2.34.1

[Intel-gfx] [PATCH i-g-t 0/6] Assorted intel_gpu_top improvements

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Mostly by popular demand from
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/109, although for
some of these changes I'd like some second opinions. For instance is it user
friendly to change the default aggregation mode for stdout and JSON output?

Plus a GPU selection fix to prepare for Intel VPU being a DRM device, making
intel_gpu_top not try to monitor it.

And finally some memory freeing fixes.

Tvrtko Ursulin (6):
  intel_gpu_top: Fix man page formatting
  intel_gpu_top: Automatically enclose JSON output into brackets
  intel_gpu_top: Add command line switch to start in physical engine
mode
  intel_gpu_top: Aggregate engine classes in all output modes
  intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
  lib/igt_device_scan: Improve Intel discrete GPU selection

 lib/igt_device_scan.c |  7 +++--
 man/intel_gpu_top.rst | 60 +--
 tools/intel_gpu_top.c | 37 +++---
 3 files changed, 62 insertions(+), 42 deletions(-)

-- 
2.34.1

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

[Jani Nikula]

Hi Dave & Daniel -

drm-intel-next-2023-01-27:
drm/i915 feature pull #2 v6.3:

Features and functionality:
- Enable HF-EEODB by switching HDMI, DP and LVDS to use struct drm_edid (Jani)
- Start using unversioned DMC firmware paths for new platforms (Gustavo)

Refactoring and cleanups:
- ELD refactor: Stop using hardware buffer, precompute ELD, and wire up ELD in
  the state checker (Ville)
- Use generics for debugfs device parameters (Jani)
- DSB refactoring and fixes (Ville)
- Header refactoring, add new intel_display_limits.h (Jani)
- Split out GMCH code to a new file (Jani)
- Split out vblank code to a new file (Jani)
- i915_drv.h and struct drm_i915_private cleanups (Jani)
- Simplify FBC and DRRS debug attributes (Deepak R Varma)
- Remove some single-use macros (Rodrigo)

Fixes:
- Fix scaler limits for display versions 12 and 13 (Luca)
- Fix plane source size check for zero height (Drew Davenport)
- Implement PSR2 selective fetch workaround (Jouni)
- Expand a PSR workaound to more platforms and pipes (Jouni)
- Expand an HDMI infoframe workaround to all MTL steppings (Jouni)
- Enable PIPEDMC whenever its corresponding pipe is enabled (Imre)

Merges:
- Backmerge drm-next (Jani)

BR,
Jani.

The following changes since commit 68de345e101ce9a24e5c8849e69dd0dba2e8c9b2:

  Merge tag 'drm-misc-next-2023-01-24' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-01-25 12:14:08 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-01-27

for you to fetch changes up to d3eb347da1148fdb1c2462ae83090a4553d3f46f:

  drm/i915/mtl: Apply Wa_14013475917 for all MTL steppings (2023-01-26 13:54:05 
+0200)


drm/i915 feature pull #2 v6.3:

Features and functionality:
- Enable HF-EEODB by switching HDMI, DP and LVDS to use struct drm_edid (Jani)
- Start using unversioned DMC firmware paths for new platforms (Gustavo)

Refactoring and cleanups:
- ELD refactor: Stop using hardware buffer, precompute ELD, and wire up ELD in
  the state checker (Ville)
- Use generics for debugfs device parameters (Jani)
- DSB refactoring and fixes (Ville)
- Header refactoring, add new intel_display_limits.h (Jani)
- Split out GMCH code to a new file (Jani)
- Split out vblank code to a new file (Jani)
- i915_drv.h and struct drm_i915_private cleanups (Jani)
- Simplify FBC and DRRS debug attributes (Deepak R Varma)
- Remove some single-use macros (Rodrigo)

Fixes:
- Fix scaler limits for display versions 12 and 13 (Luca)
- Fix plane source size check for zero height (Drew Davenport)
- Implement PSR2 selective fetch workaround (Jouni)
- Expand a PSR workaound to more platforms and pipes (Jouni)
- Expand an HDMI infoframe workaround to all MTL steppings (Jouni)
- Enable PIPEDMC whenever its corresponding pipe is enabled (Imre)

Merges:
- Backmerge drm-next (Jani)


Deepak R Varma (3):
  drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes
  drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
  drm/i915/display: Convert i9xx_pipe_crc_auto_source to void

Drew Davenport (1):
  drm/i915/display: Check source height is > 0

Gustavo Sousa (2):
  drm/i915/dmc: Prepare to use unversioned paths
  drm/i915/dmc: Use unversioned path for ADLP

Imre Deak (1):
  drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled

Jani Nikula (32):
  drm/i915/display: drop redundant display/ from #includes
  drm/i915/irq: split out vblank/scanline code to intel_vblank.[ch]
  drm/i915/display: move more scanline functions to intel_vblank.[ch]
  drm/i915/display: use common function for checking scanline is moving
  drm/i915/vblank: use intel_de_read()
  drm/i915/vblank: add and use intel_de_read64_2x32() to read vblank counter
  drm/i915: add struct i915_dsm to wrap dsm members together
  drm/i915: drop cast from DEFINE_RES_MEM() usage
  drm/i915: move snps_phy_failed_calibration to display sub-struct under 
snps
  drm/i915: move pch_ssc_use to display sub-struct under dpll
  drm/i915: move chv_dpll_md and bxt_phy_grc to display sub-struct under 
state
  drm/i915: add i915_config.h and move relevant declarations there
  drm/i915: move I915_IDLE_ENGINES_TIMEOUT next to its only user
  drm/i915: drop a number of unnecessary forward declarations
  drm/i915: move a few HAS_ macros closer to their place
  drm/i915: move I915_GEM_GPU_DOMAINS to i915_gem.h
  drm/i915: move I915_COLOR_UNEVICTABLE to i915_gem_gtt.h
  drm/i915: move GT_FREQUENCY_MULTIPLIER and GEN9_FREQ_SCALER to intel_rps.h
  Merge drm/drm-next into drm-intel-next
  drm/i915: add gmch substruct to struct drm_i915_private
  drm/i915/gmch: split out soc/intel_gmch
  drm/i915/gmch: mass rename dev_priv to i915
  drm/i915/gmch: move VGA set state to GMCH 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Add selftests for TLB invalidation (rev4)

[Andrzej Hajda]

On 26.01.2023 18:42, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915/gt: Add selftests for TLB invalidation (rev4)
*URL:*	https://patchwork.freedesktop.org/series/112894/ 


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




  CI Bug Log - changes from CI_DRM_12647 -> Patchwork_112894v4


Summary

*SUCCESS*

No regressions found.

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



Participating hosts (26 -> 22)

Missing (4): fi-kbl-soraka bat-rpls-2 bat-atsm-1 fi-snb-2520m


Possible new issues

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



  IGT changes


Possible regressions

  *

{igt@i915_selftest@live@gt_tlb} (NEW):

  o

fi-bsw-nick: NOTRUN -> DMESG-FAIL



  o

fi-bsw-n3050: NOTRUN -> DMESG-FAIL





It seems on Gen8/VCS MI_CONDITIONAL_BATCH_BUFFER_END has exceptional 
syntax[1]:

"Compare Address
Qword address to fetch compare Mask (DW0) and Data Dword(DW1) from
memory.
HW will do AND operation on Mask(DW0) with Data Dword(DW1) and then 
compare the

result against Semaphore Data Dword
"

Moreover address is aligned to qword on all platforms.
I will implement changes, I hope it will solve the issue.
Unfortunately I have no access to BSW/CHERRYVIEW platforms, so unless I 
find one I need to rely on CI.


[1]: https://gfxspecs.intel.com/Predator/Home/Index/6971

Regards
Andrzej




New tests

New tests have been introduced between CI_DRM_12647 and Patchwork_112894v4:


  New IGT tests (1)

  * igt@i915_selftest@live@gt_tlb:
  o Statuses : 2 dmesg-fail(s) 19 pass(s)
  o Exec time: [0.0] s


Known issues

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



  IGT changes


Issues hit

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
  o fi-bsw-n3050: PASS


 -> FAIL 

 (i915#6298 )


Possible fixes

  *

igt@i915_selftest@live@mman:

  o {bat-rpls-1}: TIMEOUT


 (i915#6794 ) -> PASS 

  *

igt@i915_selftest@live@workarounds:

  o {bat-adlm-1}: INCOMPLETE


 (i915#4983 ) -> PASS 

  *

igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-1:

  o {bat-adlp-9}: FAIL


 (i915#4137 ) -> PASS 

 +3 similar issues

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


Build changes

  * Linux: CI_DRM_12647 -> Patchwork_112894v4

CI-20190529: 20190529
CI_DRM_12647: ab288692acfb4c176e1411107686368c121462dc @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7137: 5f7ea985ac0828bec5e1bbc101b7931bd7fb62e3 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112894v4: ab288692acfb4c176e1411107686368c121462dc @ 
git://anongit.freedesktop.org/gfx-ci/linux



  Linux commits

1635ae6c0100 drm/i915/gt: Add selftests for TLB invalidation

[Intel-gfx] [PATCH i-g-t] i915/gem_ppgtt: Terminate batch for evict-vs-shrink*

[Matthew Auld]

From: Chris Wilson 

Terminate the first upload batch (with MI_BB_END) as otherwise we
trigger a sequence of $(nproc) GPU hangs, which take a long time to be
processed.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/7961
Fixes: 4f22b49ee353 ("tests/i915/gem_ppgtt: verify GTT eviction with contended 
locks")
Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
Signed-off-by: Matthew Auld 
---
 tests/i915/gem_ppgtt.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index ca09f089..c3102857 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@ -257,12 +257,12 @@ static void flink_and_close(void)
 
 #define PAGE_SIZE 4096
 
-static uint32_t batch_create_size(int fd, uint64_t size)
+static uint32_t batch_create(int fd)
 {
const uint32_t bbe = MI_BATCH_BUFFER_END;
uint32_t handle;
 
-   handle = gem_create(fd, size);
+   handle = gem_create(fd, sizeof(bbe));
gem_write(fd, handle, 0, , sizeof(bbe));
 
return handle;
@@ -307,8 +307,7 @@ static void shrink_vs_evict(unsigned int flags)
uint64_t ahnd = get_reloc_ahnd(fd, 0);
const intel_ctx_t *ctx_arr[nproc];
igt_spin_t *spinner;
-   uint32_t handle1;
-   int i;
+   uint32_t shared;
 
/*
 * Try to simulate some nasty object lock contention during GTT
@@ -327,7 +326,7 @@ static void shrink_vs_evict(unsigned int flags)
 
igt_drop_caches_set(fd, DROP_ALL);
 
-   handle1 = gem_create(fd, PAGE_SIZE);
+   shared = batch_create(fd);
 
spinner = igt_spin_new(fd,
   .ahnd = ahnd,
@@ -340,44 +339,43 @@ static void shrink_vs_evict(unsigned int flags)
 * somehow result in -ENOSPC from execbuf, if we need to trigger GTT
 * eviction.
 */
-   for (i = 0; i < nproc; i++) {
+   for (int i = 0; i < nproc; i++) {
ctx_arr[i] = intel_ctx_create(fd, NULL);
 
-   upload(fd, handle1, spinner->execbuf.rsvd2 >> 32,
+   upload(fd, shared, spinner->execbuf.rsvd2 >> 32,
   ctx_arr[i]->id, flags);
}
 
igt_fork(child, 1)
igt_drop_caches_set(fd, DROP_ALL);
 
-   sleep(2); /* Give the shrinker time to find handle1 */
+   sleep(2); /* Give the shrinker time to find shared */
 
igt_fork(child, nproc) {
-   uint32_t handle2;
+   uint32_t isolated;
 
/*
 * One of these forks will be stuck on the vm mutex, since the
 * shrinker is holding it (along with the object lock) while
 * trying to unbind the chosen vma, but is blocked by the
 * spinner. The rest should only block waiting to grab the
-* object lock for handle1, before then trying to GTT evict it
+* object lock for shared, before then trying to GTT evict it
 * from their respective vm. In either case the contention of
 * the vm->mutex or object lock should never result in -ENOSPC
 * or some other error.
 */
-   handle2 = batch_create_size(fd, PAGE_SIZE);
-
-   upload(fd, handle2, 0, ctx_arr[child]->id, flags);
-   gem_close(fd, handle2);
+   isolated = batch_create(fd);
+   upload(fd, isolated, 0, ctx_arr[child]->id, flags);
+   gem_close(fd, isolated);
}
 
igt_waitchildren();
igt_spin_free(fd, spinner);
 
-   for (i = 0; i < nproc; i++)
+   for (int i = 0; i < nproc; i++)
intel_ctx_destroy(fd, ctx_arr[i]);
 
-   gem_close(fd, handle1);
+   gem_close(fd, shared);
 }
 
 static bool has_contexts(void)
-- 
2.39.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: implement async_flip mode per plane tracking (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: implement async_flip mode per plane tracking (rev4)
URL   : https://patchwork.freedesktop.org/series/108371/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12651_full -> Patchwork_108371v4_full


Summary
---

  **FAILURE**

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

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@test-time-stamp@pipe-a-hdmi-a-1:
- shard-glk:  [PASS][1] -> [FAIL][2] +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-glk4/igt@kms_async_flips@test-time-st...@pipe-a-hdmi-a-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-glk3/igt@kms_async_flips@test-time-st...@pipe-a-hdmi-a-1.html

  
 Suppressed 

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

  * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-1:
- {shard-tglu-10}:[PASS][3] -> [FAIL][4] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-tglu-10/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-hdmi-a-1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-tglu-10/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-hdmi-a-1.html

  * igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-4:
- {shard-dg1}:[PASS][5] -> [FAIL][6] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-dg1-16/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-hdmi-a-4.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-dg1-16/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-hdmi-a-4.html

  * igt@kms_async_flips@test-time-stamp@pipe-a-hdmi-a-1:
- {shard-tglu}:   [PASS][7] -> [FAIL][8] +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-tglu-4/igt@kms_async_flips@test-time-st...@pipe-a-hdmi-a-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-tglu-1/igt@kms_async_flips@test-time-st...@pipe-a-hdmi-a-1.html

  * igt@kms_big_fb@linear-16bpp-rotate-0:
- {shard-dg1}:[PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-dg1-15/igt@kms_big...@linear-16bpp-rotate-0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-dg1-13/igt@kms_big...@linear-16bpp-rotate-0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2846])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-glk7/igt@gem_exec_f...@basic-deadline.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-glk8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-glk8/igt@gem_exec_fair@basic-p...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2521]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-glk7/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-glk7/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  * 
igt@kms_flip_scaled_crc@flip-64bpp-xtile-to-32bpp-xtile-upscaling@pipe-a-valid-mode:
 

Re: [Intel-gfx] [RFC 1/2] drm/i915: Add RPL-U sub platform

[Borah, Chaitanya Kumar]

Hello Jani and Matt,

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, January 24, 2023 8:02 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma ; Syrjala, Ville
> ; Srivatsa, Anusha ;
> Roper, Matthew D ; Atwood, Matthew S
> ; Borah, Chaitanya Kumar
> 
> Subject: Re: [RFC 1/2] drm/i915: Add RPL-U sub platform
> 
> On Tue, 17 Jan 2023, Chaitanya Kumar Borah
>  wrote:
> > Separate out RPLU device ids and add them to both RPL and newly
> > created RPL-U subplatforms.
> >
> > v2: (Matt)
> > - Sort PCI-IDs numerically
> > - Name the sub-platform to accurately depict what it is for
> > - Make RPL-U part of RPL subplatform
> >
> > v3: revert to RPL-U subplatform (Jani)
> >
> > Signed-off-by: Chaitanya Kumar Borah
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
> >  drivers/gpu/drm/i915/i915_pci.c  |  1 +
> >  drivers/gpu/drm/i915/intel_device_info.c |  8 
> > drivers/gpu/drm/i915/intel_device_info.h |  2 ++
> >  include/drm/i915_pciids.h| 11 +++
> >  5 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 48fd82722f12..c88e514728a0
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -619,6 +619,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> > IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N)
> > #define IS_ADLP_RPLP(dev_priv) \
> > IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPL)
> > +#define IS_ADLP_RPLU(dev_priv) \
> > +   IS_SUBPLATFORM(dev_priv, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPLU)
> >  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > (INTEL_DEVID(dev_priv) & 0xFF00) ==
> 0x0C00)  #define
> > IS_BDW_ULT(dev_priv) \ diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index 6cc65079b18d..e9f3b99b3e00
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -1234,6 +1234,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_DG1_IDS(_info),
> > INTEL_RPLS_IDS(_s_info),
> > INTEL_RPLP_IDS(_p_info),
> > +   INTEL_RPLU_IDS(_p_info),
> 
> You may want to drop this change, see later comment on how and why.
> 
> > INTEL_DG2_IDS(_info),
> > INTEL_ATS_M_IDS(_m_info),
> > INTEL_MTL_IDS(_info),
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 849baf6c3b3c..fec8bd116436 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -199,6 +199,11 @@ static const u16 subplatform_n_ids[] = {  static
> > const u16 subplatform_rpl_ids[] = {
> > INTEL_RPLS_IDS(0),
> > INTEL_RPLP_IDS(0),
> > +   INTEL_RPLU_IDS(0)
> 
> Please always include the trailing , at the end to make future changes easier.
> (However, you may want to drop this change altogether, see later
> comment.)
> 
> > +};
> > +
> > +static const u16 subplatform_rplu_ids[] = {
> > +   INTEL_RPLU_IDS(0),
> >  };
> >
> >  static const u16 subplatform_g10_ids[] = { @@ -268,6 +273,9 @@ static
> > void intel_device_info_subplatform_init(struct drm_i915_private *i915)
> > } else if (find_devid(devid, subplatform_rpl_ids,
> >   ARRAY_SIZE(subplatform_rpl_ids))) {
> > mask = BIT(INTEL_SUBPLATFORM_RPL);
> > +   if (find_devid(devid, subplatform_rplu_ids,
> > +  ARRAY_SIZE(subplatform_rplu_ids)))
> > +   mask |= BIT(INTEL_SUBPLATFORM_RPLU);
> > } else if (find_devid(devid, subplatform_g10_ids,
> >   ARRAY_SIZE(subplatform_g10_ids))) {
> > mask = BIT(INTEL_SUBPLATFORM_G10);
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index d588e5fd2eea..4a5cd337e4b5 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -127,6 +127,8 @@ enum intel_platform {
> >   * bit set
> >   */
> >  #define INTEL_SUBPLATFORM_N1
> > +/* Sub Platform for RPL-U */
> 
> This comment really adds nothing, it's exactly the same as the macro name.
> 

Ack.

> > +#define INTEL_SUBPLATFORM_RPLU  2
> >
> >  /* MTL */
> >  #define INTEL_SUBPLATFORM_M0
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 4a4c190f7698..758be5fb09a2 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -684,14 +684,17 @@
> > INTEL_VGA_DEVICE(0xA78A, info), \
> > INTEL_VGA_DEVICE(0xA78B, info)
> >
> > +/* RPL-U */
> > +#define INTEL_RPLU_IDS(info) \
> > +   INTEL_VGA_DEVICE(0xA721, info), \
> > +   INTEL_VGA_DEVICE(0xA7A1, info), \
> > +   INTEL_VGA_DEVICE(0xA7A9, info)
> > +
> >  /* RPL-P */
> >  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Split sel fetch plane configuration into arm and noarm (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Split sel fetch plane configuration into arm and noarm 
(rev2)
URL   : https://patchwork.freedesktop.org/series/113321/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12652 -> Patchwork_113321v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 25)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][3] ([i915#7156])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

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

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271]) +15 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113321v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

  * Linux: CI_DRM_12652 -> Patchwork_113321v2

  CI-20190529: 20190529
  CI_DRM_12652: 7a09b9c23a1e9b05a7a2e07abd1dc13b20070c9f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7137: 5f7ea985ac0828bec5e1bbc101b7931bd7fb62e3 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_113321v2: 7a09b9c23a1e9b05a7a2e07abd1dc13b20070c9f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4782af643a16 drm/i915/psr: Split sel fetch plane configuration into arm and 
noarm

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Coelho, Luciano]

On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> SEL_FETCH_CTL registers are armed immediately when plane is disabled.
> SEL_FETCH_* instances of plane configuration are used when doing
> selective update and normal plane register instances for full updates.
> Currently all SEL_FETCH_* registers are written as a part of noarm
> plane configuration. If noarm and arm plane configuration are not
> happening within same vblank we may end up having plane as a part of
> selective update before it's PLANE_SURF register is written.
> 
> Fix this by splitting plane selective fetch configuration into arm and
> noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
> version.
> 
> v2:
>  - drop color_plane parameter from arm part
>  - dev_priv -> i915 in arm part
> 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Vinod Govindapillai 
> Cc: Stanislav Lisovskiy 
> Cc: Luca Coelho 
> Signed-off-by: Jouni Högander 
> ---

Looks good to me:

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Greg Kroah-Hartman]

On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
> 
> Greg, ack on getting these 3 mei patches merged through intel-gfx?

I only see 2 mei patches in this series, what am I missing?

thanks,

greg k-h

Re: [Intel-gfx] [PATCH v7 1/6] mei: mei-me: resume device in prepare

[Greg Kroah-Hartman]

On Wed, Jan 25, 2023 at 12:26:32AM -0800, Alan Previn wrote:
> From: Alexander Usyskin 
> 
> Asynchronous runtime resume is not possible while the system
> is suspending.
> The power management subsystem resumes the device only in the
> suspend phase, not in the prepare phase.
> Force resume device in prepare to allow drivers on mei bus
> to communicate in their prepare callbacks.
> 
> Signed-off-by: Alexander Usyskin 
> Reviewed-by: Tomas Winkler 
> Signed-off-by: Alan Previn 
> ---
>  drivers/misc/mei/pci-me.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
> index 5bf0d50d55a0..676d566f38dd 100644
> --- a/drivers/misc/mei/pci-me.c
> +++ b/drivers/misc/mei/pci-me.c
> @@ -342,6 +342,12 @@ static void mei_me_remove(struct pci_dev *pdev)
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
> +static int mei_me_pci_prepare(struct device *device)
> +{
> + pm_runtime_resume(device);
> + return 0;
> +}
> +
>  static int mei_me_pci_suspend(struct device *device)
>  {
>   struct pci_dev *pdev = to_pci_dev(device);
> @@ -398,7 +404,17 @@ static int mei_me_pci_resume(struct device *device)
>  
>   return 0;
>  }
> -#endif /* CONFIG_PM_SLEEP */
> +
> +static void mei_me_pci_complete(struct device *device)
> +{
> + pm_runtime_suspend(device);
> +}
> +#else /* CONFIG_PM_SLEEP */
> +
> +#define mei_me_pci_prepare NULL
> +#define mei_me_pci_complete NULL
> +
> +#endif /* !CONFIG_PM_SLEEP */
>  
>  #ifdef CONFIG_PM
>  static int mei_me_pm_runtime_idle(struct device *device)
> @@ -501,6 +517,8 @@ static inline void mei_me_unset_pm_domain(struct 
> mei_device *dev)
>  }
>  
>  static const struct dev_pm_ops mei_me_pm_ops = {
> + .prepare = mei_me_pci_prepare,
> + .complete = mei_me_pci_complete,
>   SET_SYSTEM_SLEEP_PM_OPS(mei_me_pci_suspend,
>   mei_me_pci_resume)
>   SET_RUNTIME_PM_OPS(
> -- 
> 2.39.0
> 

Acked-by: Greg Kroah-Hartman 

Re: [Intel-gfx] [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Greg Kroah-Hartman]

On Wed, Jan 25, 2023 at 12:26:34AM -0800, Alan Previn wrote:
> From: Alexander Usyskin 
> 
> Client on bus have only one vtag map slot and should disregard the vtag
> value when cleaning pending read flag.
> Fixes read flow control message unexpectedly generated when
> clent on bus send messages with different vtags.
> 
> Signed-off-by: Alexander Usyskin 
> Reviewed-by: Tomas Winkler 
> Signed-off-by: Alan Previn 
> ---
>  drivers/misc/mei/client.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
> index 9ddb854b8155..5c19097266fe 100644
> --- a/drivers/misc/mei/client.c
> +++ b/drivers/misc/mei/client.c
> @@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct 
> mei_cl *cl, u8 vtag)
>   struct mei_cl_vtag *vtag_l;
>  
>   list_for_each_entry(vtag_l, >vtag_map, list) {
> - if (vtag_l->vtag == vtag) {
> + /* The client on bus has one fixed vtag map */
> + if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
> + vtag_l->vtag == vtag) {
>   vtag_l->pending_read = false;
>   break;
>   }
> -- 
> 2.39.0
> 

Acked-by: Greg Kroah-Hartman 

Re: [Intel-gfx] [PATCH] drm/i915/pcode: Wait 10 seconds for pcode to settle

[Andi Shyti]

Hi Gwan-gyeong,

thanks for the review and the thorough explanation.

On Fri, Jan 27, 2023 at 08:50:26AM +0200, Gwan-gyeong Mun wrote:
> 
> 
> On 1/11/23 5:36 PM, Andi Shyti wrote:
> > On Wed, Jan 11, 2023 at 03:18:38PM +0200, Jani Nikula wrote:
> > > On Wed, 11 Jan 2023, Andi Shyti  wrote:
> > > > From: Aravind Iddamsetty 
> > > > 
> > > > During module load not all the punit transaction have completed
> > > > and we might end up timing out, as shown by the following
> > > > warning:
> > > 
> > > Root cause?
> 
> Hi Andi, looking at the log where this problem is reported,
> 
> https://gitlab.freedesktop.org/drm/intel/-/issues/7814
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1294/bat-atsm-1/igt@i915_module_l...@resize-bar.html#dmesg-warnings17324
> 
> <4> [268.276908] i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)
> 
> In the code above, the call stack is output, and the return value of
> intel_pcode_init() returns -11 (-EAGAIN).
> 
> <3> [268.329058] i915 :4d:00.0: [drm] *ERROR* gt0: intel_pcode_init
> failed -11
> 
> 
> If you simplify the function call flow, you can see it as below. (The call
> of _wait_for(COND, timeout_base_ms * 1000, 10, 10) in skl_pcode_request() is
> omitted)
> 
> -
> intel_pcode_init()
>  |
>  +-> skl_pcode_request(uncore, DG1_PCODE_STATUS,
>DG1_UNCORE_GET_INIT_STATUS,
>DG1_UNCORE_INIT_STATUS_COMPLETE,
>DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
>|
>+-> skl_pcode_try_request()
>  |
>  +->  *status = __snb_pcode_rw(uncore, mbox, , NULL,
>500, 0, true);
> 
> -
> static int __snb_pcode_rw(struct intel_uncore *uncore, u32 mbox,
> u32 *val, u32 *val1,
> int fast_timeout_us, int slow_timeout_ms,
> bool is_read)
> {
> ...
> 
>   if (intel_uncore_read_fw(uncore, GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY)
>   return -EAGAIN;
> 
>   intel_uncore_write_fw(uncore, GEN6_PCODE_DATA, *val);
>   intel_uncore_write_fw(uncore, GEN6_PCODE_DATA1, val1 ? *val1 : 0);
>   intel_uncore_write_fw(uncore,
> GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
> 
>   if (__intel_wait_for_register_fw(uncore,
>GEN6_PCODE_MAILBOX,
>GEN6_PCODE_READY, 0,
>fast_timeout_us,
>slow_timeout_ms,
>))
>   return -ETIMEDOUT;
> 
> ...
> }
> -
> 
> The case where skl_pcode_request() returns -EAGAIN can be considered as the
> following scenario.
> 1. 1. When checking the GEN6_PCODE_MAILBOX register status before writing
> the value to the GEN6_PCODE_DATA register in __snb_pcode_rw(), it is always
> BUSY

correct! We fail with EAGAIN because we are not able to
communicate with the punit because the punit is busy.

Talking about this case we are in boot time and the gpu is
performing its boot routine, the punit as well. While the punit
is working we try communicate with it, but unfortunately, being
busy, we fail with -EAGAIN exactly where you pointed.

Adding an extra wait_for_register_fw, i.e. waiting until the
PCODE_READY register tells that the punit is ready, makes sure
that the read/write will succeed.

Thus Chris has added a 10 seconds wait before the very first read
and write. If the punit is not ready we don't fail with -EAGAIN
and give up the driver loading as it happens now. But we give it
another chance trying to probe it again later.

> 2. _wait_for(COND, timeout_base_ms * 1000, 10, 10) of skl_pcode_request()
> returns -EAGAIN if the GEN6_PCODE_MAILBOX register indicates BUSY even after
> waiting 500us after writing a value to the GEN6_PCODE_DATA register in
> __snb_pcode_rw()

Isn't it the same as '1'?

> (Even if skl_pcode_request() gives a timeout of 180 seconds, the time used
> each time __snb_pcode_rw() is called is up to 500us. The rest of the time is
> used for sleep.)

There is one big, massive, huge difference... the timeout in
skl_pcode_request() after the read/write, not before. So that at
the first communication we fail, return -EAGAIN and give up
probing without starting any timer.

Be aware of the fact that the timeout is not for the current
communication, but for the next one. De facto we start the
timeout after communicating, this makes sure that the next
communication will work.

But no one makes sure that the very first communication works
during probe. Thus the extra wait.

> In the situation where the problem is reported, it is not possible to
> confirm exactly which scenario code 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: Split sel fetch plane configuration into arm and noarm (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Split sel fetch plane configuration into arm and noarm 
(rev2)
URL   : https://patchwork.freedesktop.org/series/113321/
State : warning

== Summary ==

Error: dim checkpatch failed
df442db34504 drm/i915/psr: Split sel fetch plane configuration into arm and 
noarm
-:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#59: FILE: drivers/gpu/drm/i915/display/intel_psr.c:1563:
+void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
+   const struct intel_crtc_state 
*crtc_state,

-:77: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#77: FILE: drivers/gpu/drm/i915/display/intel_psr.c:1581:
+void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
const struct intel_crtc_state 
*crtc_state,

-:113: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#113: FILE: drivers/gpu/drm/i915/display/intel_psr.h:50:
+void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
const struct intel_crtc_state 
*crtc_state,

-:117: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#117: FILE: drivers/gpu/drm/i915/display/intel_psr.h:54:
+void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
+   const struct intel_crtc_state 
*crtc_state,

total: 0 errors, 0 warnings, 4 checks, 87 lines checked

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Govindapillai, Vinod]

Hi Jouni,

On Fri, 2023-01-27 at 10:27 +0200, Jouni Högander wrote:
> SEL_FETCH_CTL registers are armed immediately when plane is disabled.
> SEL_FETCH_* instances of plane configuration are used when doing
> selective update and normal plane register instances for full updates.
> Currently all SEL_FETCH_* registers are written as a part of noarm
> plane configuration. If noarm and arm plane configuration are not
> happening within same vblank we may end up having plane as a part of
> selective update before it's PLANE_SURF register is written.
> 
> Fix this by splitting plane selective fetch configuration into arm and
> noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
> version.
> 
> v2:
>  - drop color_plane parameter from arm part
>  - dev_priv -> i915 in arm part
> 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> Cc: Mika Kahola 
> Cc: Vinod Govindapillai 
> Cc: Stanislav Lisovskiy 
> Cc: Luca Coelho 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  | 28 +--
>  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
>  .../drm/i915/display/skl_universal_plane.c    |  4 ++-
>  4 files changed, 30 insertions(+), 11 deletions(-)

Reviewed-by: Vinod Govindapillai 

BR
Vinod
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index d190fa0d393b..ae9f0b6c92db 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -532,7 +532,8 @@ static void i9xx_cursor_update_arm(struct intel_plane 
> *plane,
> skl_write_cursor_wm(plane, crtc_state);
>  
> if (plane_state)
> -   intel_psr2_program_plane_sel_fetch(plane, crtc_state, 
> plane_state, 0);
> +   intel_psr2_program_plane_sel_fetch_arm(plane, crtc_state,
> +  plane_state);
> else
> intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7a72e15e6836..a3f4451eb66d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1559,7 +1559,25 @@ void intel_psr2_disable_plane_sel_fetch(struct 
> intel_plane *plane,
> intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
>  }
>  
> -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
> +   const struct intel_crtc_state 
> *crtc_state,
> +   const struct intel_plane_state 
> *plane_state)
> +{
> +   struct drm_i915_private *i915 = to_i915(plane->base.dev);
> +   enum pipe pipe = plane->pipe;
> +
> +   if (!crtc_state->enable_psr2_sel_fetch)
> +   return;
> +
> +   if (plane->id == PLANE_CURSOR)
> +   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> + plane_state->ctl);
> +   else
> +   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> + PLANE_SEL_FETCH_CTL_ENABLE);
> +}
> +
> +void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
> const struct intel_crtc_state 
> *crtc_state,
> const struct intel_plane_state 
> *plane_state,
> int color_plane)
> @@ -1573,11 +1591,8 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
> if (!crtc_state->enable_psr2_sel_fetch)
> return;
>  
> -   if (plane->id == PLANE_CURSOR) {
> -   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
> plane->id),
> - plane_state->ctl);
> +   if (plane->id == PLANE_CURSOR)
> return;
> -   }
>  
> clip = _state->psr2_sel_fetch_area;
>  
> @@ -1605,9 +1620,6 @@ void intel_psr2_program_plane_sel_fetch(struct 
> intel_plane *plane,
> val = (drm_rect_height(clip) - 1) << 16;
> val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
> intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), 
> val);
> -
> -   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> - PLANE_SEL_FETCH_CTL_ENABLE);
>  }
>  
>  void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
> *crtc_state)
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.h 
> b/drivers/gpu/drm/i915/display/intel_psr.h
> index 2ac3a465..c87ae2e6ee6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.h
> +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> @@ -46,10 +46,14 @@ bool 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Hogander, Jouni]

On Thu, 2023-01-26 at 13:01 +, Govindapillai, Vinod wrote:
> On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
> > SEL_FETCH_CTL registers are armed immediately when plane is
> > disabled.
> > SEL_FETCH_* instances of plane configuration are used when doing
> > selective update and normal plane register instances for full
> > updates.
> > Currently all SEL_FETCH_* registers are written as a part of noarm
> > plane configuration. If noarm and arm plane configuration are not
> > happening within same vblank we may end up having plane as a part
> > of
> > selective update before it's PLANE_SURF register is written.
> > 
> > Fix this by splitting plane selective fetch configuration into arm
> > and
> > noarm versions and call them accordingly. Write SEL_FETCH_CTL in
> > arm
> > version.
> > 
> > Cc: Ville Syrjälä 
> > Cc: José Roberto de Souza 
> > Cc: Mika Kahola 
> > Cc: Vinod Govindapillai 
> > Cc: Stanislav Lisovskiy 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cursor.c   |  2 +-
> >  drivers/gpu/drm/i915/display/intel_psr.c  | 29 ++-
> > 
> >  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
> >  .../drm/i915/display/skl_universal_plane.c    |  4 ++-
> >  4 files changed, 30 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index d190fa0d393b..50232cec48e0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -532,7 +532,7 @@ static void i9xx_cursor_update_arm(struct
> > intel_plane *plane,
> > skl_write_cursor_wm(plane, crtc_state);
> >  
> > if (plane_state)
> > -   intel_psr2_program_plane_sel_fetch(plane,
> > crtc_state, plane_state, 0);
> > +   intel_psr2_program_plane_sel_fetch_arm(plane,
> > crtc_state, plane_state, 0);
> 
> > else
> > intel_psr2_disable_plane_sel_fetch(plane,
> > crtc_state);
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 7d4a15a283a0..63b79c611932 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1559,7 +1559,26 @@ void
> > intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
> > intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe,
> > plane->id), 0);
> >  }
> >  
> > -void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane
> > *plane,
> > +   const struct
> > intel_crtc_state *crtc_state,
> > +   const struct
> > intel_plane_state *plane_state,
> > +   int color_plane)
> Looks like color_plane is redundant here.
> 
> Otherwise, looks good to me.

Thank you Vinod for checking my patch. There is a new version
addressing your comment.

> 
> Reviewed-by: Vinod Govindapillai 
> 
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(plane-
> > >base.dev);
> > +   enum pipe pipe = plane->pipe;
> > +
> > +   if (!crtc_state->enable_psr2_sel_fetch)
> > +   return;
> > +
> > +   if (plane->id == PLANE_CURSOR)
> > +   intel_de_write_fw(dev_priv,
> > PLANE_SEL_FETCH_CTL(pipe, plane->id),
> > + plane_state->ctl);
> > +   else
> > +   intel_de_write_fw(dev_priv,
> > PLANE_SEL_FETCH_CTL(pipe, plane->id),
> > + PLANE_SEL_FETCH_CTL_ENABLE);
> > +}
> > +
> > +void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane
> > *plane,
> > const struct
> > intel_crtc_state *crtc_state,
> > const struct
> > intel_plane_state *plane_state,
> > int color_plane)
> > @@ -1573,11 +1592,8 @@ void
> > intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > if (!crtc_state->enable_psr2_sel_fetch)
> > return;
> >  
> > -   if (plane->id == PLANE_CURSOR) {
> > -   intel_de_write_fw(dev_priv,
> > PLANE_SEL_FETCH_CTL(pipe, plane->id),
> > - plane_state->ctl);
> > +   if (plane->id == PLANE_CURSOR)
> > return;
> > -   }
> >  
> > clip = _state->psr2_sel_fetch_area;
> >  
> > @@ -1605,9 +1621,6 @@ void
> > intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > val = (drm_rect_height(clip) - 1) << 16;
> > val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
> > intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe,
> > plane->id), val);
> > -
> > -   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe,
> > plane->id),
> > - 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Hogander, Jouni]

On Thu, 2023-01-26 at 13:29 +0200, Luca Coelho wrote:
> On Wed, 2023-01-25 at 12:44 +0200, Jouni Högander wrote:
> > > SEL_FETCH_CTL registers are armed immediately when plane is
> > > disabled.
> > > SEL_FETCH_* instances of plane configuration are used when doing
> > > selective update and normal plane register instances for full
> > > updates.
> > > Currently all SEL_FETCH_* registers are written as a part of
> > > noarm
> > > plane configuration. If noarm and arm plane configuration are not
> > > happening within same vblank we may end up having plane as a part
> > > of
> > > selective update before it's PLANE_SURF register is written.
> > > 
> > > Fix this by splitting plane selective fetch configuration into
> > > arm and
> > > noarm versions and call them accordingly. Write SEL_FETCH_CTL in
> > > arm
> > > version.
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: José Roberto de Souza 
> > > Cc: Mika Kahola 
> > > Cc: Vinod Govindapillai 
> > > Cc: Stanislav Lisovskiy 
> > > Signed-off-by: Jouni Högander 
> > > ---
> 
> Looks fine to me. A couple of nitpicks.
> 
> 
> > >  drivers/gpu/drm/i915/display/intel_cursor.c   |  2 +-
> > >  drivers/gpu/drm/i915/display/intel_psr.c  | 29
> > > ++-
> > >  drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
> > >  .../drm/i915/display/skl_universal_plane.c    |  4 ++-
> > >  4 files changed, 30 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > index d190fa0d393b..50232cec48e0 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > > @@ -532,7 +532,7 @@ static void i9xx_cursor_update_arm(struct
> > > intel_plane *plane,
> > > skl_write_cursor_wm(plane, crtc_state);
> > >  
> > > if (plane_state)
> > > -   intel_psr2_program_plane_sel_fetch(plane,
> > > crtc_state, plane_state, 0);
> > > +   intel_psr2_program_plane_sel_fetch_arm(plane,
> > > crtc_state, plane_state, 0);
> 
> This goes well over 80 chars.  Even though it's accepted to go over
> that nowadays, I think it's still preferred to keep it shorter and
> this
> line is easily breakable.
> 
> 
> > > else
> > > intel_psr2_disable_plane_sel_fetch(plane,
> > > crtc_state);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 7d4a15a283a0..63b79c611932 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1559,7 +1559,26 @@ void
> > > intel_psr2_disable_plane_sel_fetch(struct intel_plane *plane,
> > > intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe,
> > > plane->id), 0);
> > >  }
> > >  
> > > -void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > *plane,
> > > +void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane
> > > *plane,
> > > +   const struct
> > > intel_crtc_state *crtc_state,
> > > +   const struct
> > > intel_plane_state *plane_state,
> > > +   int color_plane)
> > > +{
> > > +   struct drm_i915_private *dev_priv = to_i915(plane-
> > > >base.dev);
> 
> Should you use i915 instead of dev_priv? I've heard and read
> elsewhere
> that this is generally a desired change.  Much easier to use always
> the
> same local name for this kind of thing.  Though this file is already
> interspersed with both versions...
> 
> Regardless of these nitpicks (change them if you want):

Thank you Luca for checking my patch. Sent new version addressing your
comments.


> Reviewed-by: Luca Coelho 
> 
> --
> Cheers,
> Luca.

BR,

Jouni Högander

[Intel-gfx] [PATCH v2] drm/i915/psr: Split sel fetch plane configuration into arm and noarm

[Jouni Högander]

SEL_FETCH_CTL registers are armed immediately when plane is disabled.
SEL_FETCH_* instances of plane configuration are used when doing
selective update and normal plane register instances for full updates.
Currently all SEL_FETCH_* registers are written as a part of noarm
plane configuration. If noarm and arm plane configuration are not
happening within same vblank we may end up having plane as a part of
selective update before it's PLANE_SURF register is written.

Fix this by splitting plane selective fetch configuration into arm and
noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm
version.

v2:
 - drop color_plane parameter from arm part
 - dev_priv -> i915 in arm part

Cc: Ville Syrjälä 
Cc: José Roberto de Souza 
Cc: Mika Kahola 
Cc: Vinod Govindapillai 
Cc: Stanislav Lisovskiy 
Cc: Luca Coelho 
Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_cursor.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  | 28 +--
 drivers/gpu/drm/i915/display/intel_psr.h  |  6 +++-
 .../drm/i915/display/skl_universal_plane.c|  4 ++-
 4 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index d190fa0d393b..ae9f0b6c92db 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -532,7 +532,8 @@ static void i9xx_cursor_update_arm(struct intel_plane 
*plane,
skl_write_cursor_wm(plane, crtc_state);
 
if (plane_state)
-   intel_psr2_program_plane_sel_fetch(plane, crtc_state, 
plane_state, 0);
+   intel_psr2_program_plane_sel_fetch_arm(plane, crtc_state,
+  plane_state);
else
intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
 
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7a72e15e6836..a3f4451eb66d 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1559,7 +1559,25 @@ void intel_psr2_disable_plane_sel_fetch(struct 
intel_plane *plane,
intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id), 0);
 }
 
-void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
+void intel_psr2_program_plane_sel_fetch_arm(struct intel_plane *plane,
+   const struct intel_crtc_state 
*crtc_state,
+   const struct intel_plane_state 
*plane_state)
+{
+   struct drm_i915_private *i915 = to_i915(plane->base.dev);
+   enum pipe pipe = plane->pipe;
+
+   if (!crtc_state->enable_psr2_sel_fetch)
+   return;
+
+   if (plane->id == PLANE_CURSOR)
+   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
+ plane_state->ctl);
+   else
+   intel_de_write_fw(i915, PLANE_SEL_FETCH_CTL(pipe, plane->id),
+ PLANE_SEL_FETCH_CTL_ENABLE);
+}
+
+void intel_psr2_program_plane_sel_fetch_noarm(struct intel_plane *plane,
const struct intel_crtc_state 
*crtc_state,
const struct intel_plane_state 
*plane_state,
int color_plane)
@@ -1573,11 +1591,8 @@ void intel_psr2_program_plane_sel_fetch(struct 
intel_plane *plane,
if (!crtc_state->enable_psr2_sel_fetch)
return;
 
-   if (plane->id == PLANE_CURSOR) {
-   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, 
plane->id),
- plane_state->ctl);
+   if (plane->id == PLANE_CURSOR)
return;
-   }
 
clip = _state->psr2_sel_fetch_area;
 
@@ -1605,9 +1620,6 @@ void intel_psr2_program_plane_sel_fetch(struct 
intel_plane *plane,
val = (drm_rect_height(clip) - 1) << 16;
val |= (drm_rect_width(_state->uapi.src) >> 16) - 1;
intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id), val);
-
-   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
- PLANE_SEL_FETCH_CTL_ENABLE);
 }
 
 void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
*crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h 
b/drivers/gpu/drm/i915/display/intel_psr.h
index 2ac3a465..c87ae2e6ee6c 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -46,10 +46,14 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
 int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
struct intel_crtc *crtc);
 void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
*crtc_state);
-void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
+void 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement async_flip mode per plane tracking (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: implement async_flip mode per plane tracking (rev4)
URL   : https://patchwork.freedesktop.org/series/108371/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12651 -> Patchwork_108371v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (25 -> 24)
--

  Additional (1): bat-atsm-1 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@dmabuf:
- fi-bsw-nick:[PASS][1] -> [DMESG-FAIL][2] ([i915#7562])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6600u:   [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-apl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html

  
 Possible fixes 

  * igt@i915_selftest@live@migrate:
- {bat-dg2-11}:   [DMESG-WARN][7] ([i915#7699]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@workarounds:
- {bat-adlp-9}:   [INCOMPLETE][9] ([i915#4983] / [i915#7677]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12651/bat-adlp-9/igt@i915_selftest@l...@workarounds.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v4/bat-adlp-9/igt@i915_selftest@l...@workarounds.html

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

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6077]: https://gitlab.freedesktop.org/drm/intel/issues/6077
  [i915#6078]: https://gitlab.freedesktop.org/drm/intel/issues/6078
  [i915#6093]: https://gitlab.freedesktop.org/drm/intel/issues/6093
  [i915#6094]: https://gitlab.freedesktop.org/drm/intel/issues/6094
  [i915#6166]: https://gitlab.freedesktop.org/drm/intel/issues/6166
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7357]: https://gitlab.freedesktop.org/drm/intel/issues/7357
  [i915#7562]: https://gitlab.freedesktop.org/drm/intel/issues/7562
  [i915#7677]: https://gitlab.freedesktop.org/drm/intel/issues/7677
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932


Build changes
-

  * Linux: CI_DRM_12651 -> Patchwork_108371v4

  CI-20190529: 20190529
  CI_DRM_12651: fce901b03b34c10947c3dd53b338032f6d22812f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7137: 5f7ea985ac0828bec5e1bbc101b7931bd7fb62e3 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108371v4: fce901b03b34c10947c3dd53b338032f6d22812f @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux