[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup

[Patchwork]

== Series Details ==

Series: drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() 
cleanup
URL   : https://patchwork.freedesktop.org/series/106922/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11964 -> Patchwork_106922v1


Summary
---

  **FAILURE**

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

Participating hosts (45 -> 43)
--

  Additional (1): fi-kbl-soraka 
  Missing(3): fi-ctg-p8600 fi-bdw-samus fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-kbl-7567u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-kbl-7567u/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-kbl-7567u/igt@i915_module_l...@load.html
- fi-kbl-8809g:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-kbl-8809g/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-kbl-8809g/igt@i915_module_l...@load.html
- fi-kbl-x1275:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-kbl-x1275/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-kbl-x1275/igt@i915_module_l...@load.html
- fi-skl-6600u:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-skl-6600u/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-kbl-soraka/igt@i915_module_l...@load.html

  
 Suppressed 

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

  * igt@i915_module_load@load:
- {bat-jsl-1}:[PASS][10] -> [INCOMPLETE][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/bat-jsl-1/igt@i915_module_l...@load.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/bat-jsl-1/igt@i915_module_l...@load.html
- {fi-jsl-1}: [PASS][12] -> [INCOMPLETE][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-jsl-1/igt@i915_module_l...@load.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-jsl-1/igt@i915_module_l...@load.html
- {fi-ehl-2}: [PASS][14] -> [INCOMPLETE][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/fi-ehl-2/igt@i915_module_l...@load.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-ehl-2/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][16] -> [DMESG-FAIL][17] ([i915#4494] / 
[i915#4957])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- bat-adlp-4: [PASS][18] -> [DMESG-WARN][19] ([i915#1888])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11964/bat-adlp-4/igt@i915_selftest@l...@hugepages.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/bat-adlp-4/igt@i915_selftest@l...@hugepages.html

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

  * igt@runner@aborted:
- fi-kbl-7567u:   NOTRUN -> [FAIL][22] ([i915#4312] / [i915#6219])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106922v1/fi-kbl-7567u/igt@run...@aborted.html
- fi-kbl-x1275:   NOTRUN -> [FAIL][23] ([i915#4312] / 

[Intel-gfx] [PATCH] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup

[Animesh Manna]

To support dual LFP two instances of pps added from display gen12 onwards.
Few older platform like VLV also has dual pps support but handling is
different. So added separate hook get_pps_idx() to formulate which pps
instance to used for a soecific LFP on a specific platform.

Simplified pps_get_register() which use get_pps_idx() hook to derive the
pps instance and get_pps_idx() will be initialized at pps_init().

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_bios.c |  5 
 drivers/gpu/drm/i915/display/intel_bios.h |  1 +
 .../drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_pps.c  | 25 ++-
 4 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 51dde5bfd956..42315615a728 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -611,6 +611,11 @@ static int opregion_get_panel_type(struct drm_i915_private 
*i915,
return intel_opregion_get_panel_type(i915);
 }
 
+bool intel_bios_is_lfp2(struct intel_encoder *encoder)
+{
+   return encoder->devdata && encoder->devdata->child.handle == 
DEVICE_HANDLE_LFP2;
+}
+
 static int vbt_get_panel_type(struct drm_i915_private *i915,
  const struct intel_bios_encoder_data *devdata,
  const struct edid *edid)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index e47582b0de0a..aea72a87ea2c 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -251,6 +251,7 @@ bool intel_bios_is_lspcon_present(const struct 
drm_i915_private *i915,
  enum port port);
 bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
enum port port);
+bool intel_bios_is_lfp2(struct intel_encoder *encoder);
 enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum 
port port);
 bool intel_bios_get_dsc_params(struct intel_encoder *encoder,
   struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..95f71a572b07 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1723,6 +1723,8 @@ struct intel_dp {
 
/* When we last wrote the OUI for eDP */
unsigned long last_oui_write;
+
+   int (*get_pps_idx)(struct intel_dp *intel_dp);
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 1b21a341962f..c9cdb302d318 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -231,6 +231,17 @@ bxt_power_sequencer_idx(struct intel_dp *intel_dp)
return backlight_controller;
 }
 
+static int
+gen12_power_sequencer_idx(struct intel_dp *intel_dp)
+{
+   struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+
+   if (intel_bios_is_lfp2(encoder))
+   return 1;
+
+   return 0;
+}
+
 typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
   enum pipe pipe);
 
@@ -361,15 +372,10 @@ static void intel_pps_get_registers(struct intel_dp 
*intel_dp,
struct pps_registers *regs)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   int pps_idx = 0;
+   int pps_idx = intel_dp->get_pps_idx(intel_dp);
 
memset(regs, 0, sizeof(*regs));
 
-   if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
-   pps_idx = bxt_power_sequencer_idx(intel_dp);
-   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-   pps_idx = vlv_power_sequencer_pipe(intel_dp);
-
regs->pp_ctrl = PP_CONTROL(pps_idx);
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
@@ -1431,6 +1437,13 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
 
+   if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+   intel_dp->get_pps_idx = bxt_power_sequencer_idx;
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
+   else if (DISPLAY_VER(i915) >= 12)
+   intel_dp->get_pps_idx = gen12_power_sequencer_idx;
+
pps_init_timestamps(intel_dp);
 
with_intel_pps_lock(intel_dp, wakeref) {
-- 
2.29.0

Re: [Intel-gfx] [PATCH 1/7] drm/i915/guc: Add a helper for log buffer size

[John Harrison]

On 8/2/2022 10:37, Teres Alexis, Alan Previn wrote:

Something minor in comments, so conditional R-B (please fix on the way in or 
reply to correct me):

Reviewed-by: Alan Previn 

On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:

From: Alan Previn 

Add a helper to get GuC log buffer size.

Signed-off-by: Alan Previn 
Signed-off-by: John Harrison 
Reviewed-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
  1 file changed, 27 insertions(+), 22 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 25b2d7ce6640d..492bbf419d4df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -15,6 +15,32 @@
  
  static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
  
+static u32 intel_guc_log_size(struct intel_guc_log *log)

+{
+   /*
+*  GuC Log buffer Layout:
+*
+*  NB: Ordering must follow "enum guc_log_buffer_type".
+*
+*  +===+ 00B
+*  |  Debug state header   |
+*  +---+ 32B


Something we might have missed in prior updates but i think the bufer state is 
now 36 bytes long no? (9 dwords).

Good catch. Yes, an extra word was added some while back.

John.





+*  |Crash dump state header|
+*  +---+ 64B
+*  | Capture state header  |
+*  +---+ 96B
+*  |   |
+*  +===+ PAGE_SIZE (4KB)
+*  |  Debug logs   |
+*  +===+ + DEBUG_SIZE
+*  |Crash Dump logs|
+*  +===+ + CRASH_SIZE
+*  | Capture logs  |
+*  +===+ + CAPTURE_SIZE
+*/
+   return PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE + 
CAPTURE_BUFFER_SIZE;
+}
+
  /**
   * DOC: GuC firmware log
   *
@@ -461,32 +487,11 @@ int intel_guc_log_create(struct intel_guc_log *log)
  
  	GEM_BUG_ON(log->vma);
  
-	/*

-*  GuC Log buffer Layout
-* (this ordering must follow "enum guc_log_buffer_type" definition)
-*
-*  +===+ 00B
-*  |  Debug state header   |
-*  +---+ 32B
-*  |Crash dump state header|
-*  +---+ 64B
-*  | Capture state header  |
-*  +---+ 96B
-*  |   |
-*  +===+ PAGE_SIZE (4KB)
-*  |  Debug logs   |
-*  +===+ + DEBUG_SIZE
-*  |Crash Dump logs|
-*  +===+ + CRASH_SIZE
-*  | Capture logs  |
-*  +===+ + CAPTURE_SIZE
-*/
if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
DRM_WARN("GuC log buffer for state_capture maybe too small. %d < 
%d\n",
 CAPTURE_BUFFER_SIZE, 
intel_guc_capture_output_min_size_est(guc));
  
-	guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +

-  CAPTURE_BUFFER_SIZE;
+   guc_log_size = intel_guc_log_size(log);
  
  	vma = intel_guc_allocate_vma(guc, guc_log_size);

if (IS_ERR(vma)) {
--
2.37.1

Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Record CTB info in error logs

[John Harrison]

On 8/2/2022 11:27, Teres Alexis, Alan Previn wrote:

One minor NIT (though i hope it could be fixed otw in as it adds a bit of 
ease-of-log-readibility).
That said, everything else looks good.

Reviewed-by: Alan Previn 
  
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:

From: John Harrison 

When debugging GuC communication issues, it is useful to have the CTB
info available. So add the state and buffer contents to the error
capture log.

Also, add a sub-structure for the GuC specific error capture info as
it is now becoming numerous.

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 59 +++
  drivers/gpu/drm/i915/i915_gpu_error.h | 20 +++--
  2 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index addba75252343..543ba63f958ea 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -671,6 +671,18 @@ static void err_print_pciid(struct 
drm_i915_error_state_buf *m,
   pdev->subsystem_device);
  }
  
+static void err_print_guc_ctb(struct drm_i915_error_state_buf *m,

+ const char *name,
+ const struct intel_ctb_coredump *ctb)
+{
+   if (!ctb->size)
+   return;
+
+   err_printf(m, "GuC %s CTB: raw: 0x%08X, 0x%08X/%08X, cached: 0x%08X/%08X, 
desc = 0x%08X, buf = 0x%08X x 0x%08X\n",
+  name, ctb->raw_status, ctb->raw_head, ctb->raw_tail,
+  ctb->head, ctb->tail, ctb->desc_offset, ctb->cmds_offset, 
ctb->size);


NIT: to make it more readible on first glance, would be nice to add more descriptive 
text like "raw: Sts:0x%08X,
Hd:0x%08X,Tl:0x@08X..." also, the not sure why cmds_offset is presented with a "x 
size" as opposed to just "desc-off =
foo1, cmd-off = foo2, size = foo3"?
The line is long enough as it is. I'd rather not make it even longer. 
Same for ':  x ' rather than ' _addr = 
, _size = '. It's useful for readability to keep a 
single CTB channel on a single line but not if that line is excessively 
long.


John.


+}
+
  static void err_print_uc(struct drm_i915_error_state_buf *m,
 const struct intel_uc_coredump *error_uc)
  {
@@ -678,8 +690,12 @@ static void err_print_uc(struct drm_i915_error_state_buf 
*m,
  
  	intel_uc_fw_dump(&error_uc->guc_fw, &p);

intel_uc_fw_dump(&error_uc->huc_fw, &p);
-   err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->timestamp);
-   intel_gpu_error_print_vma(m, NULL, error_uc->guc_log);
+   err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->guc.timestamp);
+   intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_log);
+   err_printf(m, "GuC CTB fence: %d\n", error_uc->guc.last_fence);
+   err_print_guc_ctb(m, "Send", error_uc->guc.ctb + 0);
+   err_print_guc_ctb(m, "Recv", error_uc->guc.ctb + 1);
+   intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_ctb);
  }
  
  static void err_free_sgl(struct scatterlist *sgl)

@@ -854,7 +870,7 @@ static void __err_print_to_sgl(struct 
drm_i915_error_state_buf *m,
if (error->gt) {
bool print_guc_capture = false;
  
-		if (error->gt->uc && error->gt->uc->is_guc_capture)

+   if (error->gt->uc && error->gt->uc->guc.is_guc_capture)
print_guc_capture = true;
  
  		err_print_gt_display(m, error->gt);

@@ -1009,7 +1025,8 @@ static void cleanup_uc(struct intel_uc_coredump *uc)
  {
kfree(uc->guc_fw.path);
kfree(uc->huc_fw.path);
-   i915_vma_coredump_free(uc->guc_log);
+   i915_vma_coredump_free(uc->guc.vma_log);
+   i915_vma_coredump_free(uc->guc.vma_ctb);
  
  	kfree(uc);

  }
@@ -1658,6 +1675,23 @@ gt_record_engines(struct intel_gt_coredump *gt,
}
  }
  
+static void gt_record_guc_ctb(struct intel_ctb_coredump *saved,

+ const struct intel_guc_ct_buffer *ctb,
+ const void *blob_ptr, struct intel_guc *guc)
+{
+   if (!ctb || !ctb->desc)
+   return;
+
+   saved->raw_status = ctb->desc->status;
+   saved->raw_head = ctb->desc->head;
+   saved->raw_tail = ctb->desc->tail;
+   saved->head = ctb->head;
+   saved->tail = ctb->tail;
+   saved->size = ctb->size;
+   saved->desc_offset = ((void *)ctb->desc) - blob_ptr;
+   saved->cmds_offset = ((void *)ctb->cmds) - blob_ptr;
+}
+
  static struct intel_uc_coredump *
  gt_record_uc(struct intel_gt_coredump *gt,
 struct i915_vma_compress *compress)
@@ -1684,9 +1718,16 @@ gt_record_uc(struct intel_gt_coredump *gt,
 * log times to system times (in conjunction with the error->boottime 
and
 * gt->clock_frequency fields saved elsewhere).
 */
-   error_uc->timestamp = intel_uncore_read(gt->_gt->uncore, 
GUCPMTIMESTAMP);
-   error_uc->guc_log = create_vma_coredump(gt->_gt

Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Use streaming loads to speed up dumping the guc log

[John Harrison]

On 8/2/2022 11:48, Teres Alexis, Alan Previn wrote:

One concern below. Else, nice, simple yet good optimization here. :)

In the interest of quicker progression, I will provide a conditional R-B if you 
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:
Not an issue, but code changes like that can't be 'fixed on the way in'. 
Tweaking a commit message can potentially happen when merging patches 
but not code changes. For that you have to repost for CI.


John.



Reviewed-by: Alan Previn 

On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:

From: Chris Wilson 

Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.

Signed-off-by: Chris Wilson 
Signed-off-by: John Harrison 
Reviewed-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
  1 file changed, 18 insertions(+), 6 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 07d31ae32f765..4722d4b18ed19 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -750,8 +750,9 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct 
drm_printer *p,
struct intel_guc *guc = log_to_guc(log);
struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct drm_i915_gem_object *obj = NULL;
-   u32 *map;
-   int i = 0;
+   void *map;
+   u32 *page;
+   int i, j;
  
  	if (!intel_guc_is_supported(guc))

return -ENODEV;
@@ -764,23 +765,34 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct 
drm_printer *p,
if (!obj)
return 0;
  
+	page = (u32 *)__get_free_page(GFP_KERNEL);

+   if (!page)
+   return -ENOMEM;

Alan: although unlikely, its possible that user could trigger debugfs mid of a 
gt reset - not sure if we need to use the
"uc->reset_in_progress" before calling this allocation and return a different 
error in that case like EAGAIN or EBUSY or
ECONNRESET.

Doesn't matter.

The issue of thou shalt not allocate memory during a reset is only 
relevant to code that can be called from within the reset path. As in, 
you must not do something that could block the reset from completing. 
This is only debugfs code. It is not called from within the reset path. 
So if it gets blocked waiting for memory to be released, no-one cares.


John.





+
intel_guc_dump_time_info(guc, p);
  
  	map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);

if (IS_ERR(map)) {
DRM_DEBUG("Failed to pin object\n");
drm_puts(p, "(log data unaccessible)\n");
+   free_page((unsigned long)page);
return PTR_ERR(map);
}
  
-	for (i = 0; i < obj->base.size / sizeof(u32); i += 4)

-   drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(map + i), *(map + i + 1),
-  *(map + i + 2), *(map + i + 3));
+   for (i = 0; i < obj->base.size; i += PAGE_SIZE) {
+   if (!i915_memcpy_from_wc(page, map + i, PAGE_SIZE))
+   memcpy(page, map + i, PAGE_SIZE);
+
+   for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4)
+   drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(page + j + 0), *(page + j + 1),
+  *(page + j + 2), *(page + j + 3));
+   }
  
  	drm_puts(p, "\n");
  
  	i915_gem_object_unpin_map(obj);

+   free_page((unsigned long)page);
  
  	return 0;

  }
--
2.37.1

Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness

[Umesh Nerlige Ramappa]

On Tue, Aug 02, 2022 at 09:41:38AM +0100, Tvrtko Ursulin wrote:


On 01/08/2022 20:02, Umesh Nerlige Ramappa wrote:

On Wed, Jul 27, 2022 at 09:48:18AM +0100, Tvrtko Ursulin wrote:


On 27/07/2022 07:01, Umesh Nerlige Ramappa wrote:

On Fri, Jun 17, 2022 at 09:00:06AM +0100, Tvrtko Ursulin wrote:


On 16/06/2022 23:13, Nerlige Ramappa, Umesh wrote:

From: John Harrison 

GuC provides engine_id and last_switch_in ticks for an 
active context in
the pphwsp. The context image provides a 32 bit total ticks 
which is the

accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information is used to calculate the context busyness as follows:

If the engine_id is valid, then busyness is the sum of 
accumulated total
ticks and active ticks. Active ticks is calculated with 
current gt time

as reference.

If engine_id is invalid, busyness is equal to accumulated total ticks.

Since KMD (CPU) retrieves busyness data from 2 sources - GPU 
and GuC, a

potential race was highlighted in an earlier review that can lead to
double accounting of busyness. While the solution to this is a wip,
busyness is still usable for platforms running GuC submission.

v2: (Tvrtko)
- Use COPS_RUNTIME_ACTIVE_TOTAL
- Add code comment for the race
- Undo local variables initializations

v3:
- Add support for virtual engines based on
  https://patchwork.freedesktop.org/series/105227/

Signed-off-by: John Harrison 
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 12 +++-
 drivers/gpu/drm/i915/gt/intel_context.h   |  6 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  6 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  5 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 65 
++-

 drivers/gpu/drm/i915/i915_drm_client.c    |  6 +-
 6 files changed, 89 insertions(+), 11 deletions(-)

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

index 4070cb5711d8..4a84146710e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,24 @@ void 
intel_context_bind_parent_child(struct intel_context 
*parent,

 child->parallel.parent = parent;
 }
-u64 intel_context_get_total_runtime_ns(const struct 
intel_context *ce)

+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
 {
 u64 total, active;
+    if (ce->ops->update_stats)
+    ce->ops->update_stats(ce);
+
 total = ce->stats.runtime.total;
 if (ce->ops->flags & COPS_RUNTIME_CYCLES)
 total *= ce->engine->gt->clock_period_ns;
 active = READ_ONCE(ce->stats.active);
-    if (active)
+    /*
+ * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, 
the backend
+ * already provides the total active time of the 
context, so skip this

+ * calculation when this flag is set.
+ */
+    if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
 active = intel_context_clock() - active;
 return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h

index b7d3214d2cdd..5fc7c19ab29b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -56,7 +56,7 @@ static inline bool 
intel_context_is_parent(struct intel_context *ce)

 return !!ce->parallel.number_children;
 }
-static inline bool intel_context_is_pinned(struct intel_context *ce);
+static inline bool intel_context_is_pinned(const struct 
intel_context *ce);

 static inline struct intel_context *
 intel_context_to_parent(struct intel_context *ce)
@@ -116,7 +116,7 @@ static inline int 
intel_context_lock_pinned(struct intel_context *ce)
  * Returns: true if the context is currently pinned for use 
by the GPU.

  */
 static inline bool
-intel_context_is_pinned(struct intel_context *ce)
+intel_context_is_pinned(const struct intel_context *ce)
 {
 return atomic_read(&ce->pin_count);
 }
@@ -351,7 +351,7 @@ intel_context_clear_nopreempt(struct 
intel_context *ce)

 clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
 }
-u64 intel_context_get_total_runtime_ns(const struct 
intel_context *ce);

+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
 u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
 static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h

index 09f82545789f..797bb4242c18 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
 #define COPS_RUNTIME_CYCLES_BIT 1
 #define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
 int (*alloc)(struct intel_context *ce);
 void (*ban)(struct intel_context *ce, struct i915_request *rq);
@@ -55,6 +58,8 @@ struct intel_context_ops 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gt: document TLB cache invalidation functions

[Niranjana Vishwanathapura]

On Fri, Jul 29, 2022 at 09:03:55AM +0200, Mauro Carvalho Chehab wrote:

Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v2 0/2] at: 
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/

Documentation/gpu/i915.rst  |   7 ++
drivers/gpu/drm/i915/gt/intel_tlb.c |  25 +++
drivers/gpu/drm/i915/gt/intel_tlb.h | 101 
3 files changed, 133 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..46911fdd79e8 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
   :internal:

+TLB cache invalidation
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
+
Workarounds
---

diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..4873b7ecc015 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
}

+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
+ */
void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
{
intel_wakeref_t wakeref;
@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
}
}

+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
void intel_gt_init_tlb(struct intel_gt *gt)
{
mutex_init(>->tlb.invalidate_lock);
seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
}

+/**
+ * intel_gt_fini_tlb - initialize TLB-specific vars


Free TLB-specific vars


+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
void intel_gt_fini_tlb(struct intel_gt *gt)
{
mutex_destroy(>->tlb.invalidate_lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h 
b/drivers/gpu/drm/i915/gt/intel_tlb.h
index 46ce25bf5afe..dca70c33bd61 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
@@ -11,16 +11,117 @@

#include "intel_gt_types.h"

+/**
+ * DOC: TLB cache invalidation logic
+ *
+ * The way the current algorithm works is that a struct drm_i915_gem_object can
+ * be created on any order. At unbind/evict time, the object is warranted that
+ * it won't be used anymore. So, a sequence number provided by
+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen either
+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - for
+ * VMA async VMA bind.
+ *
+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is 
called,
+ * where it checks if the sequence number of the object was already invalidated
+ * or not. If not, it flushes the TLB and increments the sequence number::
+ *
+ *   void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
+ *   {
+ *   ...
+ * with_intel_gt_pm_if_awake(gt, wakeref) {
+ * mutex_lock(>->tlb.invalidate_lock);
+ * if (tlb_seqno_passed(gt, seqno))
+ * goto unlock;
+ *
+ * // Some code to do TLB invalidation
+ *   ...
+ *
+ * write_seqcount_invalidate(>->tlb.seqno); // increment seqno
+ * mutex_lock(>->tlb.invalidate_lock);
+ *  }
+ *
+ * So, let's say the current seqno is 2 and 3 new objects were created,
+ * on this order::
+ *
+ * obj1
+ * obj2
+ * obj3
+ *
+ * They can be unbind/evict on a different order. At unbind/evict time,
+ * the mm.tlb will be stamped with the sequence number, using the number
+ * from the last TLB flush, plus 1.


I am trying to get my head around the below function.

void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)
{
   WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
}

Though we pass obj->mm.tlb for 'tlb' while calling this function,
aren't we writing to local 'tlb' variable here instead of obj->mm.tlb?


+ *
+ * Different threads may be used on unbind/evict and/or unset pages.
+ * As the logic at void intel_gt_invalidate_tlb_full() is protected by a mutex,


May be 

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Move TLB invalidation to its own file

[Niranjana Vishwanathapura]

On Fri, Jul 29, 2022 at 09:03:54AM +0200, Mauro Carvalho Chehab wrote:

From: Chris Wilson 

Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.


And looks like,
1. Rename intel_gt_invalidate_tlb() to intel_gt_invalidate_tlb_full()
2. Add intel_gt_init_tlb() and intel_gt_fini_tlb() abstracts.

Reviewed-by: Niranjana Vishwanathapura 



Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v2 0/2] at: 
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/

drivers/gpu/drm/i915/Makefile |   1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
drivers/gpu/drm/i915/gt/intel_tlb.c   | 183 ++
drivers/gpu/drm/i915/gt/intel_tlb.h   |  29 
drivers/gpu/drm/i915/i915_vma.c   |   1 +
7 files changed, 219 insertions(+), 179 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+   gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
#include 

#include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"

#include "i915_drv.h"
#include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object 
*obj)
if (!obj->mm.tlb)
return;

-   intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
}

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
#include "pxp/intel_pxp.h"

#include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
#include "intel_context.h"
-#include "intel_engine_pm.h"
#include "intel_engine_regs.h"
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
@@ -31,6 +29,7 @@
#include "intel_renderstate.h"
#include "intel_rps.h"
#include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
#include "intel_uncore.h"
#include "shmem_utils.h"

@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
-   mutex_init(>->tlb.invalidate_lock);
-   seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
+   intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);

intel_uc_init_early(>->uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
-   mutex_destroy(>->tlb.invalidate_lock);
+   intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
}
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,

intel_sseu_dump(&info->sseu, p);
}
-
-struct reg_and_bit {
-   i915_reg_t reg;
-   u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
-   const i915_reg_t *regs, const unsigned int num)
-{
-   const unsigned int class = engine->class;
-   struct reg_and_bit rb = { };
-
-   if (drm_WARN_ON_ONCE(&engine->i915->drm,
-class >= num || !regs[class].reg))
-   return rb;
-
-   rb.reg = regs[class];
-   if (gen8 && class == VIDEO_DECODE_CLASS)
-   rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
-   else
-   rb.bit = engine->instance;
-
-   rb.bit = BIT(rb.bit);
-
-   return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
-   static const i915_reg_t gen8_regs[] = {
-   [RENDER_CLASS]  = GEN8_RTCR,
-   [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN8_VTCR,
-   [COPY_ENGINE_CLASS] = GEN8_BTCR,
-   };
-   static const i915_reg_t gen12_regs[] = {
-

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Remove shared locking on freeing objects (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Remove shared locking on freeing objects (rev2)
URL   : https://patchwork.freedesktop.org/series/106720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11962_full -> Patchwork_106720v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rps@fence-order:
- {shard-rkl}:NOTRUN -> [TIMEOUT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-rkl-1/igt@i915_pm_...@fence-order.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-apl:  ([PASS][2], [PASS][3], [PASS][4], [PASS][5], 
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], 
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[FAIL][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51]) ([i915#4386])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl2/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl2/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl8/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl8/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl8/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl7/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl7/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl7/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/shard-apl6/boot.html
   [39]

Re: [Intel-gfx] [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots

[Lyude Paul]

On Wed, 2022-06-15 at 04:28 +, Lin, Wayne wrote:
> [Public]
> 
> Thank you Lyude for addressing this!
> 
> VCPI is also a confusing naming to me at first glance since it stands for 
> Virtual Channel Payload Identification which is just an ID number ( we can 
>  look up these payload IDs In DPCD 0x2C1 ~0x2FF).
> 
> I also look up left VCPI terms in rest of the code. Seems like we still can
> modify 
> some parts here? Like:
> 
> /**
>  * struct drm_dp_vcpi - Virtual Channel Payload Identifier
>  * @vcpi: Virtual channel ID.
>  * @pbn: Payload Bandwidth Number for this channel
>  * @aligned_pbn: PBN aligned with slot size
>  * @num_slots: number of slots for this PBN
>  */
> struct drm_dp_vcpi {
> int vcpi;
> int pbn;
> int aligned_pbn;
> int num_slots;
> };
> 
> Would like to change the structure name to  "struct drm_dp_mst_vcp {}" to
> represent
> the virtual channel payload. Not specific to the ID.
> Would like to know your thoughts : )

JFYI - I didn't rename this structure because we actually remove it entirely
in later patches

> 
> > -Original Message-
> > From: Lyude Paul 
> > Sent: Wednesday, June 8, 2022 3:29 AM
> > To: dri-de...@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Ville Syrjälä
> > ; Zuo, Jerry ; Jani
> > Nikula
> > ; Imre Deak ; Daniel Vetter
> > ; Sean Paul ; Wentland, Harry
> > ; Li, Sun peng (Leo) ;
> > Siqueira, Rodrigo ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Jani Nikula
> > ; Joonas Lahtinen
> > ; Rodrigo Vivi ;
> > Tvrtko Ursulin ; Ben Skeggs
> > ; Karol Herbst ; Kazlauskas,
> > Nicholas ; Li, Roman
> > ; Shih, Jude ; Simon Ser
> > ; Wu, Hersen ; Thomas
> > Zimmermann ; Lakha, Bhawanpreet
> > ; José Roberto de Souza
> > ; He Ying ; Matt Roper
> > ; Sean Paul ; Hans
> > Verkuil ; Fernando Ramos ;
> > Javier Martinez Canillas ; open list  > ker...@vger.kernel.org>; open list:INTEL DRM DRIVERS  > g...@lists.freedesktop.org>
> > Subject: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not
> > VCPI slots
> > 
> > VCPI is only sort of the correct term here, originally the majority of
> > this code
> > simply referred to timeslots vaguely as "slots" - and since I started
> > working
> > on it and adding atomic functionality, the name "VCPI slots" has been used
> > to
> > represent time slots.
> > 
> > Now that we actually have consistent access to the DisplayPort spec thanks
> > to
> > VESA, I now know this isn't actually the proper term - as the
> > specification
> > refers to these as time slots.
> > 
> > Since we're trying to make this code as easy to figure out as possible,
> > let's
> > take this opportunity to correct this nomenclature and call them by their
> > proper name - timeslots. Likewise, we rename various functions
> > appropriately, along with replacing references in the kernel documentation
> > and various debugging messages.
> > 
> > It's important to note that this patch series leaves the legacy MST code
> > untouched for the most part, which is fine since we'll be removing it soon
> > anyhow. There should be no functional changes in this series.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Wayne Lin 
> > Cc: Ville Syrjälä 
> > Cc: Fangzhi Zuo 
> > Cc: Jani Nikula 
> > Cc: Imre Deak 
> > Cc: Daniel Vetter 
> > Cc: Sean Paul 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  28 ++---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   5 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   |   4 +-
> >  include/drm/display/drm_dp_mst_helper.h   |   6 +-
> >  6 files changed, 75 insertions(+), 76 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index ad4571190a90..f84a4ad736d8 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct
> > drm_encoder *encoder,
> > clock = adjusted_mode->clock;
> > dm_new_connector_state->pbn =
> > drm_dp_calc_pbn_mode(clock, bpp, false);
> > }
> > -   dm_new_connector_state->vcpi_slots =
> > drm_dp_atomic_find_vcpi_slots(state,
> > +   dm_new_connector_state->vcpi_slots =
> > +drm_dp_atomic_find_time_slots(state,
> > 
> > mst_mgr,
> > 
> > mst_port,
> > 
> > dm_new_connector_state->pbn, diff --git
> > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 9221b6690a4a..e40ff51e7be0 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -378,7 +378

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: Add support for DC5 state (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Add support for DC5 state (rev3)
URL   : https://patchwork.freedesktop.org/series/106816/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11962_full -> Patchwork_106816v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rps@fence-order:
- {shard-rkl}:NOTRUN -> [TIMEOUT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/shard-rkl-6/igt@i915_pm_...@fence-order.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

  

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-tglb: [PASS][38] -> [FAIL][39] ([i915#5784])
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/shard-tglb7/igt@gem_...@kms.html
   [39]: 
https://i

Re: [Intel-gfx] [PATCH 7/7] drm/i915/guc: Reduce spam from error capture

[Teres Alexis, Alan Previn]

Reviewed-by: Alan Previn 

On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> Some debug code got left in when the GuC based register save for error
> capture was added. Remove that.
> 
> Signed-off-by: John Harrison 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 67 ---
>  1 file changed, 28 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index d2ac53d4f3b6e..8f11651460131 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -1383,33 +1383,22 @@ guc_capture_reg_to_str(const struct intel_guc *guc, 
> u32 owner, u32 type,
>   return NULL;
>  }
>  
> -#ifdef CONFIG_DRM_I915_DEBUG_GUC
> -#define __out(a, ...) \
> - do { \
> - drm_warn((&(a)->i915->drm), __VA_ARGS__); \
> - i915_error_printf((a), __VA_ARGS__); \
> - } while (0)
> -#else
> -#define __out(a, ...) \
> - i915_error_printf(a, __VA_ARGS__)
> -#endif
> -
>  #define GCAP_PRINT_INTEL_ENG_INFO(ebuf, eng) \
>   do { \
> - __out(ebuf, "i915-Eng-Name: %s command stream\n", \
> -   (eng)->name); \
> - __out(ebuf, "i915-Eng-Inst-Class: 0x%02x\n", (eng)->class); 
> \
> - __out(ebuf, "i915-Eng-Inst-Id: 0x%02x\n", (eng)->instance); 
> \
> - __out(ebuf, "i915-Eng-LogicalMask: 0x%08x\n", \
> -   (eng)->logical_mask); \
> + i915_error_printf(ebuf, "i915-Eng-Name: %s command 
> stream\n", \
> +   (eng)->name); \
> + i915_error_printf(ebuf, "i915-Eng-Inst-Class: 0x%02x\n", 
> (eng)->class); \
> + i915_error_printf(ebuf, "i915-Eng-Inst-Id: 0x%02x\n", 
> (eng)->instance); \
> + i915_error_printf(ebuf, "i915-Eng-LogicalMask: 0x%08x\n", \
> +   (eng)->logical_mask); \
>   } while (0)
>  
>  #define GCAP_PRINT_GUC_INST_INFO(ebuf, node) \
>   do { \
> - __out(ebuf, "GuC-Engine-Inst-Id: 0x%08x\n", \
> -   (node)->eng_inst); \
> - __out(ebuf, "GuC-Context-Id: 0x%08x\n", (node)->guc_id); \
> - __out(ebuf, "LRCA: 0x%08x\n", (node)->lrca); \
> + i915_error_printf(ebuf, "GuC-Engine-Inst-Id: 0x%08x\n", \
> +   (node)->eng_inst); \
> + i915_error_printf(ebuf, "GuC-Context-Id: 0x%08x\n", 
> (node)->guc_id); \
> + i915_error_printf(ebuf, "LRCA: 0x%08x\n", (node)->lrca); \
>   } while (0)
>  
>  int intel_guc_capture_print_engine_node(struct drm_i915_error_state_buf 
> *ebuf,
> @@ -1441,57 +1430,57 @@ int intel_guc_capture_print_engine_node(struct 
> drm_i915_error_state_buf *ebuf,
>  
>   guc = &ee->engine->gt->uc.guc;
>  
> - __out(ebuf, "global --- GuC Error Capture on %s command stream:\n",
> -   ee->engine->name);
> + i915_error_printf(ebuf, "global --- GuC Error Capture on %s command 
> stream:\n",
> +   ee->engine->name);
>  
>   node = ee->guc_capture_node;
>   if (!node) {
> - __out(ebuf, "  No matching ee-node\n");
> + i915_error_printf(ebuf, "  No matching ee-node\n");
>   return 0;
>   }
>  
> - __out(ebuf, "Coverage:  %s\n", grptype[node->is_partial]);
> + i915_error_printf(ebuf, "Coverage:  %s\n", grptype[node->is_partial]);
>  
>   for (i = GUC_CAPTURE_LIST_TYPE_GLOBAL; i < GUC_CAPTURE_LIST_TYPE_MAX; 
> ++i) {
> - __out(ebuf, "  RegListType: %s\n",
> -   datatype[i % GUC_CAPTURE_LIST_TYPE_MAX]);
> - __out(ebuf, "Owner-Id: %d\n", node->reginfo[i].vfid);
> + i915_error_printf(ebuf, "  RegListType: %s\n",
> +   datatype[i % GUC_CAPTURE_LIST_TYPE_MAX]);
> + i915_error_printf(ebuf, "Owner-Id: %d\n", 
> node->reginfo[i].vfid);
>  
>   switch (i) {
>   case GUC_CAPTURE_LIST_TYPE_GLOBAL:
>   default:
>   break;
>   case GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS:
> - __out(ebuf, "GuC-Eng-Class: %d\n", node->eng_class);
> - __out(ebuf, "i915-Eng-Class: %d\n",
> -   guc_class_to_engine_class(node->eng_class));
> + i915_error_printf(ebuf, "GuC-Eng-Class: %d\n", 
> node->eng_class);
> + i915_error_printf(ebuf, "i915-Eng-Class: %d\n",
> +   
> guc_class_to_engine_class(node->eng_class));
>   break;
>   case GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE:
>   eng = intel_guc_lookup_engine(guc, node->eng_class, 
> node->eng_inst);
>   if (eng)
>  

Re: [Intel-gfx] [v5, 13/14] drm/i915/gsc: allocate extended operational memory in LMEM

[Winkler, Tomas]

> 
> Looks good, just a minor nit.
> 
> Reviewed-by: Alan Previn 
> 
> 
> On Wed, 2022-07-06 at 14:43 +0300, Alexander Usyskin wrote:
> > From: Tomas Winkler 
> >
> > GSC requires more operational memory than available on chip.
> > Reserve 4M of LMEM for GSC operation. The memory is provided to the
> > GSC as struct resource to the auxiliary data of the child device.
> >
> > Cc: Alan Previn 
> > Signed-off-by: Tomas Winkler 
> > Signed-off-by: Daniele Ceraolo Spurio
> > 
> > Signed-off-by: Alexander Usyskin 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gsc.c | 92
> > ++---  drivers/gpu/drm/i915/gt/intel_gsc.h
> |
> > 3 +
> >  2 files changed, 88 insertions(+), 7 deletions(-)
> >
> > +   if (def->lmem_size) {
> > +   dev_dbg(&pdev->dev, "setting up GSC lmem\n");

> >
> NIT: Any reason we are not being consistent and using drm_err / drm_debug
> (same below)? either way, ensuring we get PCI device id info in the dmesg
> output we are good.

Thanks, will fix.

> > +
> > +   if (gsc_ext_om_alloc(gsc, intf, def->lmem_size)) {
> > +   dev_err(&pdev->dev, "setting up gsc extended
> operational memory failed\n");
> > +   kfree(adev);
> > +   goto fail;
> > +   }
> > +
> > +   adev->ext_op_mem.start =
> i915_gem_object_get_dma_address(intf->gem_obj, 0);
> > +   adev->ext_op_mem.end = adev->ext_op_mem.start + def-
> >lmem_size;
> > +   }
> > +

Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Use streaming loads to speed up dumping the guc log

[Teres Alexis, Alan Previn]

One concern below. Else, nice, simple yet good optimization here. :)

In the interest of quicker progression, I will provide a conditional R-B if you 
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:

Reviewed-by: Alan Previn 

On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: Chris Wilson 
> 
> Use a temporary page and mempy_from_wc to reduce the time it takes to
> dump the guc log to debugfs.
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: John Harrison 
> Reviewed-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
>  1 file changed, 18 insertions(+), 6 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 07d31ae32f765..4722d4b18ed19 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -750,8 +750,9 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct 
> drm_printer *p,
>   struct intel_guc *guc = log_to_guc(log);
>   struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
>   struct drm_i915_gem_object *obj = NULL;
> - u32 *map;
> - int i = 0;
> + void *map;
> + u32 *page;
> + int i, j;
>  
>   if (!intel_guc_is_supported(guc))
>   return -ENODEV;
> @@ -764,23 +765,34 @@ int intel_guc_log_dump(struct intel_guc_log *log, 
> struct drm_printer *p,
>   if (!obj)
>   return 0;
>  
> + page = (u32 *)__get_free_page(GFP_KERNEL);
> + if (!page)
> + return -ENOMEM;

Alan: although unlikely, its possible that user could trigger debugfs mid of a 
gt reset - not sure if we need to use the
"uc->reset_in_progress" before calling this allocation and return a different 
error in that case like EAGAIN or EBUSY or
ECONNRESET.

> +
>   intel_guc_dump_time_info(guc, p);
>  
>   map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
>   if (IS_ERR(map)) {
>   DRM_DEBUG("Failed to pin object\n");
>   drm_puts(p, "(log data unaccessible)\n");
> + free_page((unsigned long)page);
>   return PTR_ERR(map);
>   }
>  
> - for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
> - drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> -*(map + i), *(map + i + 1),
> -*(map + i + 2), *(map + i + 3));
> + for (i = 0; i < obj->base.size; i += PAGE_SIZE) {
> + if (!i915_memcpy_from_wc(page, map + i, PAGE_SIZE))
> + memcpy(page, map + i, PAGE_SIZE);
> +
> + for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4)
> + drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> +*(page + j + 0), *(page + j + 1),
> +*(page + j + 2), *(page + j + 3));
> + }
>  
>   drm_puts(p, "\n");
>  
>   i915_gem_object_unpin_map(obj);
> + free_page((unsigned long)page);
>  
>   return 0;
>  }
> -- 
> 2.37.1
> 

Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Record CTB info in error logs

[Teres Alexis, Alan Previn]

One minor NIT (though i hope it could be fixed otw in as it adds a bit of 
ease-of-log-readibility).
That said, everything else looks good.

Reviewed-by: Alan Previn 
 
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> When debugging GuC communication issues, it is useful to have the CTB
> info available. So add the state and buffer contents to the error
> capture log.
> 
> Also, add a sub-structure for the GuC specific error capture info as
> it is now becoming numerous.
> 
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gpu_error.c | 59 +++
>  drivers/gpu/drm/i915/i915_gpu_error.h | 20 +++--
>  2 files changed, 67 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index addba75252343..543ba63f958ea 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -671,6 +671,18 @@ static void err_print_pciid(struct 
> drm_i915_error_state_buf *m,
>  pdev->subsystem_device);
>  }
>  
> +static void err_print_guc_ctb(struct drm_i915_error_state_buf *m,
> +   const char *name,
> +   const struct intel_ctb_coredump *ctb)
> +{
> + if (!ctb->size)
> + return;
> +
> + err_printf(m, "GuC %s CTB: raw: 0x%08X, 0x%08X/%08X, cached: 
> 0x%08X/%08X, desc = 0x%08X, buf = 0x%08X x 0x%08X\n",
> +name, ctb->raw_status, ctb->raw_head, ctb->raw_tail,
> +ctb->head, ctb->tail, ctb->desc_offset, ctb->cmds_offset, 
> ctb->size);
> 
NIT: to make it more readible on first glance, would be nice to add more 
descriptive text like "raw: Sts:0x%08X,
Hd:0x%08X,Tl:0x@08X..." also, the not sure why cmds_offset is presented with a 
"x size" as opposed to just "desc-off =
foo1, cmd-off = foo2, size = foo3"?
> +}
> +
>  static void err_print_uc(struct drm_i915_error_state_buf *m,
>const struct intel_uc_coredump *error_uc)
>  {
> @@ -678,8 +690,12 @@ static void err_print_uc(struct drm_i915_error_state_buf 
> *m,
>  
>   intel_uc_fw_dump(&error_uc->guc_fw, &p);
>   intel_uc_fw_dump(&error_uc->huc_fw, &p);
> - err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->timestamp);
> - intel_gpu_error_print_vma(m, NULL, error_uc->guc_log);
> + err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->guc.timestamp);
> + intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_log);
> + err_printf(m, "GuC CTB fence: %d\n", error_uc->guc.last_fence);
> + err_print_guc_ctb(m, "Send", error_uc->guc.ctb + 0);
> + err_print_guc_ctb(m, "Recv", error_uc->guc.ctb + 1);
> + intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_ctb);
>  }
>  
>  static void err_free_sgl(struct scatterlist *sgl)
> @@ -854,7 +870,7 @@ static void __err_print_to_sgl(struct 
> drm_i915_error_state_buf *m,
>   if (error->gt) {
>   bool print_guc_capture = false;
>  
> - if (error->gt->uc && error->gt->uc->is_guc_capture)
> + if (error->gt->uc && error->gt->uc->guc.is_guc_capture)
>   print_guc_capture = true;
>  
>   err_print_gt_display(m, error->gt);
> @@ -1009,7 +1025,8 @@ static void cleanup_uc(struct intel_uc_coredump *uc)
>  {
>   kfree(uc->guc_fw.path);
>   kfree(uc->huc_fw.path);
> - i915_vma_coredump_free(uc->guc_log);
> + i915_vma_coredump_free(uc->guc.vma_log);
> + i915_vma_coredump_free(uc->guc.vma_ctb);
>  
>   kfree(uc);
>  }
> @@ -1658,6 +1675,23 @@ gt_record_engines(struct intel_gt_coredump *gt,
>   }
>  }
>  
> +static void gt_record_guc_ctb(struct intel_ctb_coredump *saved,
> +   const struct intel_guc_ct_buffer *ctb,
> +   const void *blob_ptr, struct intel_guc *guc)
> +{
> + if (!ctb || !ctb->desc)
> + return;
> +
> + saved->raw_status = ctb->desc->status;
> + saved->raw_head = ctb->desc->head;
> + saved->raw_tail = ctb->desc->tail;
> + saved->head = ctb->head;
> + saved->tail = ctb->tail;
> + saved->size = ctb->size;
> + saved->desc_offset = ((void *)ctb->desc) - blob_ptr;
> + saved->cmds_offset = ((void *)ctb->cmds) - blob_ptr;
> +}
> +
>  static struct intel_uc_coredump *
>  gt_record_uc(struct intel_gt_coredump *gt,
>struct i915_vma_compress *compress)
> @@ -1684,9 +1718,16 @@ gt_record_uc(struct intel_gt_coredump *gt,
>* log times to system times (in conjunction with the error->boottime 
> and
>* gt->clock_frequency fields saved elsewhere).
>*/
> - error_uc->timestamp = intel_uncore_read(gt->_gt->uncore, 
> GUCPMTIMESTAMP);
> - error_uc->guc_log = create_vma_coredump(gt->_gt, uc->guc.log.vma,
> - "GuC log buffer", compress);
> + error_uc->guc.timestamp = intel_uncore_read(gt->_gt->uncore, 
> GUCPMTIMEST

Re: [Intel-gfx] [PATCH 21/23] drm/i915/dmc: MTL DMC debugfs entries

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:18PM -0700, Radhakrishna Sripada wrote:
> From: Anusha Srivatsa 
> 
> MTL needs both Pipe A and Pipe B DMC to be loaded
> along with Main DMC. Patch also adds

That's true, but it's unrelated to this patch.  intel_dmc_load_program()
always loads all of the pipe firmwares (including pipe C and pipe D)
assuming it found them in the firmware file.

> DMC debug register for MTL.
> 
> BSpec: 49788
> Cc: Matt Roper 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 9c4f442fa407..2fabb2760474 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -1005,7 +1005,7 @@ static int intel_dmc_debugfs_status_show(struct 
> seq_file *m, void *unused)
>   seq_printf(m, "Pipe A fw loaded: %s\n",
>  str_yes_no(dmc->dmc_info[DMC_FW_PIPEA].payload));
>   seq_printf(m, "Pipe B fw support: %s\n",
> -str_yes_no(IS_ALDERLAKE_P(i915)));
> +str_yes_no(DISPLAY_VER(i915) >= 13));

What is this debugfs trying to tell us?  Pipe DMC fw for all four pipes
has been supported since TGL.  So the output here is misleading (and
incomplete since it doesn't include C/D).

The thing that changed in DG2 was that we were required to upload the
pipe A firmware along with the main firmware (other pipes optional).
The thing that further changed in ADL-P was that we were required to
upload *both* pipe A and pipe B along with the main firmware (other two
pipes still optional).

Even if the output here was trying to indicate which pipe firmware(s)
need to be uploaded at the same time as the main firmware (rather than
being uploaded later), the change here wouldn't be correct since as
noted above, DG2 (which has display version 13) only required pipe A and
not B.

I think we probably need to decide what the purpose of this debugfs is
supposed to be and then rework it accordingly.


Matt

>   seq_printf(m, "Pipe B fw loaded: %s\n",
>  str_yes_no(dmc->dmc_info[DMC_FW_PIPEB].payload));
>  
> @@ -1029,9 +1029,9 @@ static int intel_dmc_debugfs_status_show(struct 
> seq_file *m, void *unused)
>* reg for DC3CO debugging and validation,
>* but TGL DMC f/w is using DMC_DEBUG3 reg for DC3CO counter.
>*/
> - seq_printf(m, "DC3CO count: %d\n",
> -intel_de_read(i915, IS_DGFX(i915) ?
> -  DG1_DMC_DEBUG3 : TGL_DMC_DEBUG3));
> + seq_printf(m, "DC3CO count: %d\n", intel_de_read(i915,
> +(IS_DGFX(i915) || DISPLAY_VER(i915) >= 14) ?
> + DG1_DMC_DEBUG3 : TGL_DMC_DEBUG3));
>   } else {
>   dc5_reg = IS_BROXTON(i915) ? BXT_DMC_DC3_DC5_COUNT :
>   SKL_DMC_DC3_DC5_COUNT;
> -- 
> 2.25.1
> 

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

Re: [Intel-gfx] [PATCH 20/23] drm/i915/dmc: Load DMC on MTL

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:17PM -0700, Radhakrishna Sripada wrote:
> From: Madhumitha Tolakanahalli Pradeep 
> 
> 
> Adding support to load DMC v2.08 on MTL.
> 
> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index fa9ef591b885..9c4f442fa407 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -52,6 +52,11 @@
>  
>  #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>  
> +#define MTL_DMC_PATH DMC_PATH(mtl, 2, 08)
> +#define MTL_DMC_VERSION_REQUIRED DMC_VERSION(2, 8)
> +#define MTL_DMC_MAX_FW_SIZE  0x1

Is it correct that Xe_LPD+ has a smaller payload than Xe_LPD platforms?

Actually, looking closer I'm wondering if the
DISPLAY_VER13_DMC_MAX_FW_SIZE we were using on Xe_LPD was correct.  I
think the value here is supposed to be a per-payload maximum (i.e.,
checked separately for the main DMC and the pipe DMC), right?  And the
MMIO ranges the payloads can be loaded into both appear to be sized
0x1, so it's not clear to me whether we needed the 0x2 value on
ADL-P and DG2.


Matt

> +MODULE_FIRMWARE(MTL_DMC_PATH);
> +
>  #define DG2_DMC_PATH DMC_PATH(dg2, 2, 06)
>  #define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 06)
>  MODULE_FIRMWARE(DG2_DMC_PATH);
> @@ -827,7 +832,11 @@ void intel_dmc_ucode_init(struct drm_i915_private 
> *dev_priv)
>*/
>   intel_dmc_runtime_pm_get(dev_priv);
>  
> - if (IS_DG2(dev_priv)) {
> + if (IS_METEORLAKE(dev_priv)) {
> + dmc->fw_path = MTL_DMC_PATH;
> + dmc->required_version = MTL_DMC_VERSION_REQUIRED;
> + dmc->max_fw_size = MTL_DMC_MAX_FW_SIZE;
> + } else if (IS_DG2(dev_priv)) {
>   dmc->fw_path = DG2_DMC_PATH;
>   dmc->required_version = DG2_DMC_VERSION_REQUIRED;
>   dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> -- 
> 2.25.1
> 

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable TTM for integrated GFX objects in sysmem

[Patchwork]

== Series Details ==

Series: Enable TTM for integrated GFX objects in sysmem
URL   : https://patchwork.freedesktop.org/series/106913/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11963 -> Patchwork_106913v1


Summary
---

  **FAILURE**

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

Participating hosts (47 -> 44)
--

  Missing(3): fi-ctg-p8600 fi-icl-u2 fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-dg1-5:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg1-5/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg1-5/igt@i915_module_l...@load.html
- bat-dg1-6:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg1-6/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg1-6/igt@i915_module_l...@load.html

  
 Suppressed 

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

  * igt@i915_module_load@load:
- {bat-dg2-9}:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg2-9/igt@i915_module_l...@load.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg2-9/igt@i915_module_l...@load.html
- {bat-dg2-8}:[PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg2-8/igt@i915_module_l...@load.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg2-8/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [PASS][9] -> [INCOMPLETE][10] ([i915#5982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][12] ([i915#2867]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@hugepages:
- fi-rkl-guc: [DMESG-WARN][14] -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-rkl-guc/igt@i915_selftest@l...@hugepages.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/fi-rkl-guc/igt@i915_selftest@l...@hugepages.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [INCOMPLETE][16] ([i915#146]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  
 Warnings 

  * igt@runner@aborted:
- bat-dg1-5:  [FAIL][18] ([i915#4312] / [i915#5257]) -> [FAIL][19] 
([i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg1-5/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg1-5/igt@run...@aborted.html
- bat-dg1-6:  [FAIL][20] ([i915#4312] / [i915#5257]) -> [FAIL][21] 
([i915#4312])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg1-6/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106913v1/bat-dg1-6/igt@run...@aborted.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_

Re: [Intel-gfx] [PATCH 2/7] drm/i915/guc: Fix capture size warning and bump the size

[Teres Alexis, Alan Previn]

Straight forward change - LGTM.

Reviewed-by: Alan Previn 


On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> There was a size check to warn if the GuC error state capture buffer
> allocation would be too small to fit a reasonable amount of capture
> data for the current platform. Unfortunately, the test was done too
> early in the boot sequence and was actually testing 'if(-ENODEV >
> size)'.
> 
> Move the check to be later. The check is only used to print a warning
> message, so it doesn't really matter how early or late it is done.
> Note that it is not possible to dynamically size the buffer because
> the allocation needs to be done before the engine information is
> available (at least, it would be in the intended two-phase GuC init
> process).
> 
> Now that the check works, it is reporting size too small for newer
> platforms. The check includes a 3x oversample multiplier to allow for
> multiple error captures to be bufferd by GuC before i915 has a chance
> to read them out. This is less important than simply being big enough
> to fit the first capture.
> 
> So a) bump the default size to be large enough for one capture minimum
> and b) make the warning only if one capture won't fit, instead use a
> notice for the 3x size.
> 
> Note that the size estimate is a worst case scenario. Actual captures
> will likely be smaller.
> 
> Lastly, use drm_warn istead of DRM_WARN as the former provides more
> infmration and the latter is deprecated.
> 
> Signed-off-by: John Harrison 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 40 ++-
>  .../gpu/drm/i915/gt/uc/intel_guc_capture.h|  1 -
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  4 --
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|  4 +-
>  4 files changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 75257bd20ff01..b54b7883320b1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -600,10 +600,8 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
>   return 0;
>  }
>  
> -#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
> -
> -int
> -intel_guc_capture_output_min_size_est(struct intel_guc *guc)
> +static int
> +guc_capture_output_min_size_est(struct intel_guc *guc)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
>   struct intel_engine_cs *engine;
> @@ -623,13 +621,8 @@ intel_guc_capture_output_min_size_est(struct intel_guc 
> *guc)
>* For each engine instance, there would be 1 x 
> guc_state_capture_group_t output
>* followed by 3 x guc_state_capture_t lists. The latter is how the 
> register
>* dumps are split across different register types (where the '3' are 
> global vs class
> -  * vs instance). Finally, let's multiply the whole thing by 3x (just so 
> we are
> -  * not limited to just 1 round of data in a worst case full register 
> dump log)
> -  *
> -  * NOTE: intel_guc_log that allocates the log buffer would round this 
> size up to
> -  * a power of two.
> +  * vs instance).
>*/
> -
>   for_each_engine(engine, gt, id) {
>   worst_min_size += sizeof(struct 
> guc_state_capture_group_header_t) +
>(3 * sizeof(struct 
> guc_state_capture_header_t));
> @@ -649,7 +642,30 @@ intel_guc_capture_output_min_size_est(struct intel_guc 
> *guc)
>  
>   worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
>  
> - return (worst_min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER);
> + return worst_min_size;
> +}
> +
> +/*
> + * Add on a 3x multiplier to allow for multiple back-to-back captures 
> occurring
> + * before the i915 can read the data out and process it
> + */
> +#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
> +
> +static void check_guc_capture_size(struct intel_guc *guc)
> +{
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> + int min_size = guc_capture_output_min_size_est(guc);
> + int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
> +
> + if (min_size < 0)
> + drm_warn(&i915->drm, "Failed to calculate GuC error state 
> capture buffer minimum size: %d!\n",
> +  min_size);
> + else if (min_size > CAPTURE_BUFFER_SIZE)
> + drm_warn(&i915->drm, "GuC error state capture buffer is too 
> small: %d < %d\n",
> +  CAPTURE_BUFFER_SIZE, min_size);
> + else if (spare_size > CAPTURE_BUFFER_SIZE)
> + drm_notice(&i915->drm, "GuC error state capture buffer maybe 
> too small: %d < %d (min = %d)\n",
> +CAPTURE_BUFFER_SIZE, spare_size, min_size);
>  }
>  
>  /*
> @@ -1580,5 +1596,7 @@ int intel_guc_capture_init(struct intel_guc *guc)
>   INIT_LIST_HEAD(&guc->capture->outlist);
>   INIT_LIST_HEAD(&guc->capture->cachelist);

Re: [Intel-gfx] [PATCH 19/23] drm/i915/display/mtl: Extend MBUS programming

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:16PM -0700, Radhakrishna Sripada wrote:
> From: José Roberto de Souza 
> 
> Display version 14 also supports MBUS joining just like ADL-P
> and also it don't need MBUS initialization, so extending ADL-P

s/don't/doesn't/

Otherwise,

Reviewed-by: Matt Roper 

> code paths to display version 14 and higher.
> 
> Bspec: 49213
> 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>  drivers/gpu/drm/i915/i915_drv.h| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index ccc3f78b1607..c0bc5c30cef3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1101,7 +1101,7 @@ static void icl_mbus_init(struct drm_i915_private 
> *dev_priv)
>   unsigned long abox_regs = INTEL_INFO(dev_priv)->display.abox_mask;
>   u32 mask, val, i;
>  
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
>   return;
>  
>   mask = MBUS_ABOX_BT_CREDIT_POOL1_MASK |
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5767bbba2260..6a876cd53228 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1360,7 +1360,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
> IS_ALDERLAKE_S(dev_priv))
>  
> -#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
> +#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 
> 14)
>  
>  #define HAS_3D_PIPELINE(i915)(INTEL_INFO(i915)->has_3d_pipeline)
>  
> -- 
> 2.25.1
> 

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

Re: [Intel-gfx] [PATCH 1/7] drm/i915/guc: Add a helper for log buffer size

[Teres Alexis, Alan Previn]

Something minor in comments, so conditional R-B (please fix on the way in or 
reply to correct me):

Reviewed-by: Alan Previn 

On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
> From: Alan Previn 
> 
> Add a helper to get GuC log buffer size.
> 
> Signed-off-by: Alan Previn 
> Signed-off-by: John Harrison 
> Reviewed-by: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
>  1 file changed, 27 insertions(+), 22 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 25b2d7ce6640d..492bbf419d4df 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -15,6 +15,32 @@
>  
>  static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
>  
> +static u32 intel_guc_log_size(struct intel_guc_log *log)
> +{
> + /*
> +  *  GuC Log buffer Layout:
> +  *
> +  *  NB: Ordering must follow "enum guc_log_buffer_type".
> +  *
> +  *  +===+ 00B
> +  *  |  Debug state header   |
> +  *  +---+ 32B
> 
Something we might have missed in prior updates but i think the bufer state is 
now 36 bytes long no? (9 dwords).


> +  *  |Crash dump state header|
> +  *  +---+ 64B
> +  *  | Capture state header  |
> +  *  +---+ 96B
> +  *  |   |
> +  *  +===+ PAGE_SIZE (4KB)
> +  *  |  Debug logs   |
> +  *  +===+ + DEBUG_SIZE
> +  *  |Crash Dump logs|
> +  *  +===+ + CRASH_SIZE
> +  *  | Capture logs  |
> +  *  +===+ + CAPTURE_SIZE
> +  */
> + return PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE + 
> CAPTURE_BUFFER_SIZE;
> +}
> +
>  /**
>   * DOC: GuC firmware log
>   *
> @@ -461,32 +487,11 @@ int intel_guc_log_create(struct intel_guc_log *log)
>  
>   GEM_BUG_ON(log->vma);
>  
> - /*
> -  *  GuC Log buffer Layout
> -  * (this ordering must follow "enum guc_log_buffer_type" definition)
> -  *
> -  *  +===+ 00B
> -  *  |  Debug state header   |
> -  *  +---+ 32B
> -  *  |Crash dump state header|
> -  *  +---+ 64B
> -  *  | Capture state header  |
> -  *  +---+ 96B
> -  *  |   |
> -  *  +===+ PAGE_SIZE (4KB)
> -  *  |  Debug logs   |
> -  *  +===+ + DEBUG_SIZE
> -  *  |Crash Dump logs|
> -  *  +===+ + CRASH_SIZE
> -  *  | Capture logs  |
> -  *  +===+ + CAPTURE_SIZE
> -  */
>   if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
>   DRM_WARN("GuC log buffer for state_capture maybe too small. %d 
> < %d\n",
>CAPTURE_BUFFER_SIZE, 
> intel_guc_capture_output_min_size_est(guc));
>  
> - guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
> -CAPTURE_BUFFER_SIZE;
> + guc_log_size = intel_guc_log_size(log);
>  
>   vma = intel_guc_allocate_vma(guc, guc_log_size);
>   if (IS_ERR(vma)) {
> -- 
> 2.37.1
> 

Re: [Intel-gfx] [PATCH 18/23] drm/i915/mtl: DBUF handling is same as adlp

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:15PM -0700, Radhakrishna Sripada wrote:
> Meteorlake uses a similar DBUF programming as ADL-P.
> Reuse the call flow for meteorlake.

Although the patch below is correct, the commit message and subject line
here are extremely misleading.  MTL uses _very_ different
handling/programming of DBUF (via the new PM demand mechanism).  The
only thing that's actually the same is the computation of which dbufs
will be enabled (which is all this patch deals with).

> 
> Bspec: 49255
> 
> Cc: Matt Roper 
> Original Author: Caz Yokoyama
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 58a3c72418a7..d73be4bbaaa3 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4934,7 +4934,7 @@ static u8 skl_compute_dbuf_slices(struct intel_crtc 
> *crtc, u8 active_pipes, bool
>  
>   if (IS_DG2(dev_priv))
>   return dg2_compute_dbuf_slices(pipe, active_pipes, join_mbus);
> - else if (IS_ALDERLAKE_P(dev_priv))
> + else if (DISPLAY_VER(dev_priv) >= 14 || IS_ALDERLAKE_P(dev_priv))

An alternative would be to just do

else if (DISPLAY_VER(dev_priv) >= 13)

here since DG2 is already broken out into its own case above.

But either way,

Reviewed-by: Matt Roper 

with an updated commit message/subject change.

>   return adlp_compute_dbuf_slices(pipe, active_pipes, join_mbus);
>   else if (DISPLAY_VER(dev_priv) == 12)
>   return tgl_compute_dbuf_slices(pipe, active_pipes, join_mbus);
> -- 
> 2.25.1
> 

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

Re: [Intel-gfx] [v5, 13/14] drm/i915/gsc: allocate extended operational memory in LMEM

[Teres Alexis, Alan Previn]

Looks good, just a minor nit.

Reviewed-by: Alan Previn 


On Wed, 2022-07-06 at 14:43 +0300, Alexander Usyskin wrote:
> From: Tomas Winkler 
> 
> GSC requires more operational memory than available on chip.
> Reserve 4M of LMEM for GSC operation. The memory is provided to the
> GSC as struct resource to the auxiliary data of the child device.
> 
> Cc: Alan Previn 
> Signed-off-by: Tomas Winkler 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Alexander Usyskin 
> ---
>  drivers/gpu/drm/i915/gt/intel_gsc.c | 92 ++---
>  drivers/gpu/drm/i915/gt/intel_gsc.h |  3 +
>  2 files changed, 88 insertions(+), 7 deletions(-)
> 
> + if (def->lmem_size) {
> + dev_dbg(&pdev->dev, "setting up GSC lmem\n");
> 
NIT: Any reason we are not being consistent and using drm_err / drm_debug (same 
below)? either way, ensuring we get PCI
device id info in the dmesg output we are good.

> +
> + if (gsc_ext_om_alloc(gsc, intf, def->lmem_size)) {
> + dev_err(&pdev->dev, "setting up gsc extended 
> operational memory failed\n");
> + kfree(adev);
> + goto fail;
> + }
> +
> + adev->ext_op_mem.start = 
> i915_gem_object_get_dma_address(intf->gem_obj, 0);
> + adev->ext_op_mem.end = adev->ext_op_mem.start + def->lmem_size;
> + }
> +

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable TTM for integrated GFX objects in sysmem

[Patchwork]

== Series Details ==

Series: Enable TTM for integrated GFX objects in sysmem
URL   : https://patchwork.freedesktop.org/series/106913/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable TTM for integrated GFX objects in sysmem

[Patchwork]

== Series Details ==

Series: Enable TTM for integrated GFX objects in sysmem
URL   : https://patchwork.freedesktop.org/series/106913/
State : warning

== Summary ==

Error: dim checkpatch failed
30b2640e4185 drm/i915/ttm: dont trample cache_level overrides during ttm move
b283b8a7d71e drm/i915: limit ttm to dma32 for i965G[M]
ae22ccdeda30 drm/i915/ttm: only trust snooping for dgfx when deciding default 
cache_level
8399f78186f7 drm/i915/ttm: don't overwrite cache_dirty after setting coherency
-:14: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id 'b6f17c183a3e', maybe 
rebased or not pulled?
#14: 
placement of the framebuffer. However, commit b6f17c183a3e ("drm/i915/ttm:

total: 0 errors, 1 warnings, 0 checks, 16 lines checked
b08c8f9acefb drm/i915: Pick the right memory allocation flags for older devices
68bee3ccdca5 drm/i915: Add module param for enabling TTM in sysmem region
-:25: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#25: FILE: drivers/gpu/drm/i915/i915_params.c:211:
+i915_param_named_unsafe(use_pool_alloc, bool, 0600,
+   "Force the driver to use TTM's pool allocator API for smem objects. "

-:29: CHECK:LINE_SPACING: Please don't use multiple blank lines
#29: FILE: drivers/gpu/drm/i915/i915_params.c:215:
+
+

total: 0 errors, 0 warnings, 2 checks, 21 lines checked
085d8ed8fa28 drm/i915: Optionally manage system memory with TTM and poolalloc
-:76: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#76: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:78:
+void __i915_gem_object_release_smem(struct drm_i915_gem_object *obj,
 struct sg_table *pages,

-:282: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#282: FILE: drivers/gpu/drm/i915/gem/i915_gem_shmem.c:355:
+__i915_gem_object_release_smem(struct drm_i915_gem_object *obj,
struct sg_table *pages,

-:423: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#423: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1177:
+ttm_pwrite(struct drm_i915_gem_object *obj,
+const struct drm_i915_gem_pwrite *arg)

-:425: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#425: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1179:
+{
+

-:434: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#434: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1188:
+ttm_pread(struct drm_i915_gem_object *obj,
+   const struct drm_i915_gem_pread *arg)

-:519: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#519: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1387:
+i915_gem_object_create_ttm_from_data(struct drm_i915_private *dev_priv,
+  const void *data, resource_size_t size)

total: 0 errors, 0 warnings, 6 checks, 567 lines checked

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: avoid abnormal pixel output when turn eDP display off

[Patchwork]

== Series Details ==

Series: drm/i915/display: avoid abnormal pixel output when turn eDP display off
URL   : https://patchwork.freedesktop.org/series/106910/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11963 -> Patchwork_106910v1


Summary
---

  **FAILURE**

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

Participating hosts (47 -> 43)
--

  Missing(4): fi-ctg-p8600 fi-icl-u2 bat-jsl-1 fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@basic-flip-after-cursor@atomic-transitions:
- fi-adl-ddr5:[PASS][1] -> [DMESG-WARN][2] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-adl-ddr5/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-adl-ddr5/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
- fi-kbl-x1275:   [PASS][3] -> [DMESG-WARN][4] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
- fi-cfl-8109u:   [PASS][5] -> [DMESG-WARN][6] +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-cfl-8109u/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-cfl-8109u/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-apl-guc/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-apl-guc/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
- fi-rkl-guc: [PASS][9] -> [DMESG-WARN][10] +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-rkl-guc/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-rkl-guc/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
- fi-cfl-8700k:   [PASS][11] -> [DMESG-WARN][12] +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-cfl-8700k/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-cfl-8700k/igt@kms_cursor_legacy@basic-flip-after-cur...@atomic-transitions.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions:
- fi-rkl-11600:   [PASS][13] -> [DMESG-WARN][14] +4 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-rkl-11600/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-rkl-11600/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html
- fi-cfl-guc: [PASS][15] -> [DMESG-WARN][16] +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/fi-cfl-guc/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/fi-cfl-guc/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions.html

  * igt@kms_flip@basic-plain-flip@c-hdmi-a2:
- bat-dg1-6:  [PASS][17] -> [DMESG-WARN][18] +55 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg1-6/igt@kms_flip@basic-plain-f...@c-hdmi-a2.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/bat-dg1-6/igt@kms_flip@basic-plain-f...@c-hdmi-a2.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {bat-dg2-9}:[WARN][19] ([i915#6498]) -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11963/bat-dg2-9/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106910v1/bat-dg2-9/igt@i915_pm_..

Re: [Intel-gfx] [PATCH 17/23] drm/i915/mtl: Update MBUS_DBOX credits

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:14PM -0700, Radhakrishna Sripada wrote:
> Display version 14 platforms has different credits values compared to ADL-P.

s/has/have/

> Update the credits based on pipe usage.
> 
> Bspec: 49213
> 
> Cc: Jose Roberto de Souza 
> Cc: Matt Roper 
> Original Author: Caz Yokoyama
> Signed-off-by: José Roberto de Souza 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  4 +++
>  drivers/gpu/drm/i915/intel_pm.c | 47 ++---
>  2 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d37607109398..2f9cbdd068e8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1125,8 +1125,12 @@
>  #define MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN   REG_BIT(16) /* tgl+ */
>  #define MBUS_DBOX_BW_CREDIT_MASK REG_GENMASK(15, 14)
>  #define MBUS_DBOX_BW_CREDIT(x)   
> REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, x)
> +#define MBUS_DBOX_BW_4CREDITS_MTL0x2
> +#define MBUS_DBOX_BW_8CREDITS_MTL0x3

It might be better to move the REG_FIELD_PREP into the definition here

   #define MBUS_DBOX_BW_4CREDITS_MTL REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 
0x2)
   #define MBUS_DBOX_BW_8CREDITS_MTL REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 
0x3)

and then...

>  #define MBUS_DBOX_B_CREDIT_MASK  REG_GENMASK(12, 8)
>  #define MBUS_DBOX_B_CREDIT(x)
> REG_FIELD_PREP(MBUS_DBOX_B_CREDIT_MASK, x)
> +#define MBUS_DBOX_I_CREDIT_MASK  REG_GENMASK(7, 5)
> +#define MBUS_DBOX_I_CREDIT(x)
> REG_FIELD_PREP(MBUS_DBOX_I_CREDIT_MASK, x)
>  #define MBUS_DBOX_A_CREDIT_MASK  REG_GENMASK(3, 0)
>  #define MBUS_DBOX_A_CREDIT(x)
> REG_FIELD_PREP(MBUS_DBOX_A_CREDIT_MASK, x)
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f71b3b8b590c..58a3c72418a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8443,6 +8443,27 @@ void intel_dbuf_post_plane_update(struct 
> intel_atomic_state *state)
>   new_dbuf_state->enabled_slices);
>  }
>  
> +static bool xelpdp_is_one_pipe_per_dbuf_bank(enum pipe pipe, u8 active_pipes)
> +{
> + switch (pipe) {
> + case PIPE_A:
> + case PIPE_D:
> + if (is_power_of_2(active_pipes & (BIT(PIPE_A) | BIT(PIPE_D
> + return true;
> + break;
> + case PIPE_B:
> + case PIPE_C:
> + if (is_power_of_2(active_pipes & (BIT(PIPE_B) | BIT(PIPE_C
> + return true;
> + break;
> + default: /* to suppress compiler warning */
> + MISSING_CASE(pipe);
> + break;
> + }
> +
> + return false;
> +}
> +
>  void intel_mbus_dbox_update(struct intel_atomic_state *state)
>  {
>   struct drm_i915_private *i915 = to_i915(state->base.dev);
> @@ -8462,20 +8483,28 @@ void intel_mbus_dbox_update(struct intel_atomic_state 
> *state)
>new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
>   return;
>  
> + if (DISPLAY_VER(i915) >= 14)
> + val |= MBUS_DBOX_I_CREDIT(2);
> +
>   if (DISPLAY_VER(i915) >= 12) {
>   val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
>   val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
>   val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
>   }
>  
> - /* Wa_22010947358:adl-p */
> - if (IS_ALDERLAKE_P(i915))
> + if (DISPLAY_VER(i915) >= 14)
> + val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(12) :
> +  MBUS_DBOX_A_CREDIT(8);
> + else if (IS_ALDERLAKE_P(i915))
> + /* Wa_22010947358:adl-p */
>   val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
>MBUS_DBOX_A_CREDIT(4);
>   else
>   val |= MBUS_DBOX_A_CREDIT(2);
>  
> - if (IS_ALDERLAKE_P(i915)) {
> + if (DISPLAY_VER(i915) >= 14) {
> + val |= MBUS_DBOX_B_CREDIT(0xA);
> + } else if (IS_ALDERLAKE_P(i915)) {
>   val |= MBUS_DBOX_BW_CREDIT(2);
>   val |= MBUS_DBOX_B_CREDIT(8);
>   } else if (DISPLAY_VER(i915) >= 12) {
> @@ -8487,10 +8516,20 @@ void intel_mbus_dbox_update(struct intel_atomic_state 
> *state)
>   }
>  
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + u32 pipe_val = val;
> +
>   if (!new_crtc_state->hw.active ||
>   !intel_crtc_needs_modeset(new_crtc_state))
>   continue;
>  
> - intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe), val);
> + if (DISPLAY_VER(i915) >= 14) {
> + if (xelpdp_is_one_pipe_per_dbuf

[Intel-gfx] [PATCH 5/7] drm/i915: Pick the right memory allocation flags for older devices

[Adrian Larumbe]

i965gm devices cannot relocate objects above 4GiB. This situation was
already being handled in the older shmem GEM object backend, but not in TTM
for BO's that are allocated in system memory.

Borrow the code from shmem so that TTM handles them in the same way.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0332d5214aab..b232aed4927e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -207,6 +207,11 @@ static int i915_ttm_tt_shmem_populate(struct ttm_device 
*bdev,
return PTR_ERR(filp);
 
mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
+   if (IS_I965GM(i915) || IS_I965G(i915)) {
+   /* 965gm cannot relocate objects above 4GiB. */
+   mask &= ~__GFP_HIGHMEM;
+   mask |= __GFP_DMA32;
+   }
 
mapping = filp->f_mapping;
mapping_set_gfp_mask(mapping, mask);
-- 
2.37.0

Re: [Intel-gfx] [PATCH 16/23] drm/i915/mtl: Update memory bandwidth parameters

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:13PM -0700, Radhakrishna Sripada wrote:
> Like ADL_P, Meteorlake has different memory characteristics from
> past platforms. Update the values used by our memory bandwidth
> calculations accordingly.
> 
> Bspec: 64631
> 
> Cc: Matt Roper 
> Cc: Caz Yokoyama 
> Signed-off-by: Radhakrishna Sripada 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 42 ++---
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 8bbf47da1716..447a15f2c18a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -178,7 +178,32 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>   qi->num_points = dram_info->num_qgv_points;
>   qi->num_psf_points = dram_info->num_psf_gv_points;
>  
> - if (DISPLAY_VER(dev_priv) >= 12)
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + switch (dram_info->type) {
> + case INTEL_DRAM_DDR4:
> + qi->t_bl = 4;
> + qi->max_numchannels = 2;
> + qi->channel_width = 64;
> + qi->deinterleave = 2;
> + break;
> + case INTEL_DRAM_DDR5:
> + qi->t_bl = 8;
> + qi->max_numchannels = 4;
> + qi->channel_width = 32;
> + qi->deinterleave = 2;
> + break;
> + case INTEL_DRAM_LPDDR4:
> + case INTEL_DRAM_LPDDR5:
> + qi->t_bl = 16;
> + qi->max_numchannels = 8;
> + qi->channel_width = 16;
> + qi->deinterleave = 4;
> + break;
> + default:
> + MISSING_CASE(dram_info->type);
> + return -EINVAL;
> + }
> + } else if (DISPLAY_VER(dev_priv) >= 12) {
>   switch (dram_info->type) {
>   case INTEL_DRAM_DDR4:
>   qi->t_bl = is_y_tile ? 8 : 4;
> @@ -212,7 +237,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>   qi->max_numchannels = 1;
>   break;
>   }
> - else if (DISPLAY_VER(dev_priv) == 11) {
> + } else if (DISPLAY_VER(dev_priv) == 11) {
>   qi->t_bl = dev_priv->dram_info.type == INTEL_DRAM_DDR4 ? 4 : 8;
>   qi->max_numchannels = 1;
>   }
> @@ -311,6 +336,13 @@ static const struct intel_sa_info adlp_sa_info = {
>   .derating = 20,
>  };
>  
> +static const struct intel_sa_info mtl_sa_info = {
> + .deburst = 32,
> + .deprogbwlimit = 38, /* GB/s */
> + .displayrtids = 256,
> + .derating = 20,
> +};
> +
>  static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
> intel_sa_info *sa)
>  {
>   struct intel_qgv_info qi = {};
> @@ -585,9 +617,11 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
>   if (!HAS_DISPLAY(dev_priv))
>   return;
>  
> - if (IS_DG2(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 14)
> + tgl_get_bw_info(dev_priv, &mtl_sa_info);
> + else if (IS_DG2(dev_priv))
>   dg2_get_bw_info(dev_priv);
> - else if (DISPLAY_VER(dev_priv) >= 13 || IS_ALDERLAKE_P(dev_priv))
> + else if (IS_ALDERLAKE_P(dev_priv))

Here you're undoing the change from the previous patch.  If you drop the
unwanted change from the previous patch and rebase the real changes here
accordingly,

Reviewed-by: Matt Roper 

>   tgl_get_bw_info(dev_priv, &adlp_sa_info);
>   else if (IS_ALDERLAKE_S(dev_priv))
>   tgl_get_bw_info(dev_priv, &adls_sa_info);
> -- 
> 2.25.1
> 

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

[Intel-gfx] [PATCH 3/7] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

[Adrian Larumbe]

From: Robert Beckett 

By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 042c2237e287..a949594237d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -52,7 +52,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.37.0

[Intel-gfx] [PATCH 7/7] drm/i915: Optionally manage system memory with TTM and poolalloc

[Adrian Larumbe]

Allow system memory to be managed by TTM on integrated graphics platforms.
We replace using the shmem objects with similar use of TTM objects and can
then benefit from using alloc_page() pages instead of shmem pages.

This commit has no effect on DGFX hardware.

Because it manages objects allocated on system memory, support for the
legacy mmap ioctl was introduced. The change also affects how the original
object is accessed when constructing a phys gem object, which means it must
be mapped and accessed in its entirety rather than traversing the list of
shmem pages.

A new set of integrated TTM GEM object operations are needed, which do not
hold pointers to memory mapping functions, because mmap'ing of TTM-managed
BO's in system memory should still be handled by the GEM subsystem. This
new set of operations also handles pwrite and pread, which are forbidden on
platforms having LMEM.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c|  21 ++-
 drivers/gpu/drm/i915/gem/i915_gem_object.h  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c| 127 -
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c   |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 187 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h |  14 ++
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|   6 +-
 drivers/gpu/drm/i915/intel_memory_region.c  |   2 +-
 9 files changed, 298 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 0c5c43852e24..112de5c0a23f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -83,6 +83,22 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
if (!obj)
return -ENOENT;
 
+   if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
+   addr = -EINVAL;
+   goto err;
+   }
+
+   if (i915_gem_object_is_ttm(obj)) {
+   GEM_WARN_ON(!i915->params.use_pool_alloc);
+
+   addr = i915_gem_ttm_mmap_ioctl(obj, args);
+   if (IS_ERR_VALUE(addr))
+   goto err;
+
+   args->addr_ptr = (u64)addr;
+   return 0;
+   }
+
/* prime objects have no backing filp to GEM mmap
 * pages from.
 */
@@ -91,11 +107,6 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
goto err;
}
 
-   if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
-   addr = -EINVAL;
-   goto err;
-   }
-
addr = vm_mmap(obj->base.filp, 0, args->size,
   PROT_READ | PROT_WRITE, MAP_SHARED,
   args->offset);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 6f0a3ce35567..c130db4d757f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -74,7 +74,7 @@ __i915_gem_object_create_user(struct drm_i915_private *i915, 
u64 size,
 
 extern const struct drm_i915_gem_object_ops i915_gem_shmem_ops;
 
-void __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
+void __i915_gem_object_release_smem(struct drm_i915_gem_object *obj,
 struct sg_table *pages,
 bool needs_clflush);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c 
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 0d0e46dae559..4efedd3fdf7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -16,16 +16,15 @@
 #include "i915_gem_region.h"
 #include "i915_gem_tiling.h"
 #include "i915_scatterlist.h"
+#include "i915_gem_ttm.h"
 
 static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
 {
-   struct address_space *mapping = obj->base.filp->f_mapping;
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct scatterlist *sg;
struct sg_table *st;
dma_addr_t dma;
void *vaddr;
-   void *dst;
int i;
 
if (GEM_WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
@@ -57,22 +56,40 @@ static int i915_gem_object_get_pages_phys(struct 
drm_i915_gem_object *obj)
sg_dma_address(sg) = dma;
sg_dma_len(sg) = obj->base.size;
 
-   dst = vaddr;
-   for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
-   struct page *page;
-   void *src;
+   if (i915_gem_object_is_ttm(obj)) {
+   void *objaddr;
 
-   page = shmem_read_mapping_page(mapping, i);
-   if (IS_ERR(page))
-   goto err_st;
+   objaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(objaddr))
+   return PTR_ERR(objaddr);
 
-   src = kmap_atomic

[Intel-gfx] [PATCH 6/7] drm/i915: Add module param for enabling TTM in sysmem region

[Adrian Larumbe]

Introduces a new module parameter, 'use_pool_alloc', which defaults to
'false'. Its goal is to make the driver fall back on TTM for setting up
the system memory region, so that object allocation will be done through
the TTM subsystem rather than shmem objects.

This commit only brings in the new kernel module param, which will be
used by successive commits.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/i915_params.c | 6 ++
 drivers/gpu/drm/i915/i915_params.h | 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 6fc475a5db61..1af11f030ab1 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -207,6 +207,12 @@ i915_param_named_unsafe(lmem_size, uint, 0400,
 i915_param_named_unsafe(lmem_bar_size, uint, 0400,
"Set the lmem bar size(in MiB).");
 
+i915_param_named_unsafe(use_pool_alloc, bool, 0600,
+   "Force the driver to use TTM's pool allocator API for smem objects. "
+   "This will cause TTM to take over BO allocation even in integrated 
platforms. "
+   "(default: false)");
+
+
 static __always_inline void _print_param(struct drm_printer *p,
 const char *name,
 const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 2733cb6cfe09..992ee2a4947d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -84,7 +84,8 @@ struct drm_printer;
param(bool, verbose_state_checks, true, 0) \
param(bool, nuclear_pageflip, false, 0400) \
param(bool, enable_dp_mst, true, 0600) \
-   param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ? 0400 : 
0)
+   param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ? 0400 : 
0) \
+   param(bool, use_pool_alloc, false, 0600)
 
 #define MEMBER(T, member, ...) T member;
 struct i915_params {
-- 
2.37.0

[Intel-gfx] [PATCH 2/7] drm/i915: limit ttm to dma32 for i965G[M]

[Adrian Larumbe]

From: Robert Beckett 

i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..88b525f9bb2d 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = &dev_priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.37.0

[Intel-gfx] [PATCH 4/7] drm/i915/ttm: don't overwrite cache_dirty after setting coherency

[Adrian Larumbe]

When i915_gem_object_set_cache_level sets the GEM object's cache_dirty to
true, in the case of TTM that will sometimes be overwritten when getting
the object's pages, more specifically for shmem-placed objects for which
its ttm structure has just been populated.

This wasn't an issue so far, even though intel_dpt_create was setting the
object's cache level to 'none', regardless of the platform and memory
placement of the framebuffer. However, commit b6f17c183a3e ("drm/i915/ttm:
dont trample cache_level overrides during ttm move") makes sure the cache
level set by older backends soon to be managed by TTM isn't altered after
their TTM bo ttm structure is populated.

However this led to the 'obj->cache_dirty = true' set in
i915_gem_object_set_cache_level and flush_write_domain to stick around
rather than being reset inside i915_ttm_adjust_gem_after_move after calling
ttm_tt_populate in __i915_ttm_get_pages, which eventually led to a warning
in DGFX platforms.

Make sure it's not set in DGFX platforms.

Signed-off-by: Adrian Larumbe 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 1674b0c5802b..341b60432a12 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -77,7 +77,7 @@ flush_write_domain(struct drm_i915_gem_object *obj, unsigned 
int flush_domains)
 
case I915_GEM_DOMAIN_RENDER:
if (gpu_write_needs_clflush(obj))
-   obj->cache_dirty = true;
+   obj->cache_dirty = !IS_DGFX(to_i915(obj->base.dev));
break;
}
 
@@ -275,7 +275,7 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
/* Always invalidate stale cachelines */
if (obj->cache_level != cache_level) {
i915_gem_object_set_cache_coherency(obj, cache_level);
-   obj->cache_dirty = true;
+   obj->cache_dirty = !IS_DGFX(to_i915(obj->base.dev));
}
 
/* The cache-level will be applied when each vma is rebound. */
-- 
2.37.0

[Intel-gfx] [PATCH 1/7] drm/i915/ttm: dont trample cache_level overrides during ttm move

[Adrian Larumbe]

From: Robert Beckett 

Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index ccec4055fde3..966ac2d778d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5cf36a130061..14937cf1daaa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -623,6 +623,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5a5cf332d8a5..0332d5214aab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1253,6 +1253,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84..042c2237e287 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -129,9 +129,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.37.0

[Intel-gfx] [PATCH 0/6] Enable TTM for integrated GFX objects in sysmem

[Adrian Larumbe]

This patch series aims at enabling TTM support for system memory objects in
integrated graphics platforms. Whether one wishes to use TTM for sysmem
objects depends on a user-enabled kernel module parameter, so that the
former behaviour of using shmem objects for the system memory region is
kept by default.

The rationale for this change is the benefits in having TTM allocate BO
memory pages for us with alloc_page() rather than shmem.

The first three patches in the series, which the latter three depend on,
are being worked on in parallel by Bob, and handle TTM object cache level
and coherence for sysmem-allocated objects too.

Adrian Larumbe (4):
  drm/i915/ttm: don't overwrite cache_dirty after setting coherency
  drm/i915: Pick the right memory allocation flags for older devices
  drm/i915: Add module param for enabling TTM in sysmem region
  drm/i915: Optionally manage system memory with TTM and poolalloc

Robert Beckett (3):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level

 drivers/gpu/drm/i915/gem/i915_gem_domain.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   2 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  | 127 +++-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 193 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |  14 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   6 +-
 drivers/gpu/drm/i915/i915_params.c|   6 +
 drivers/gpu/drm/i915/i915_params.h|   3 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   2 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |   7 +-
 16 files changed, 331 insertions(+), 75 deletions(-)

-- 
2.37.0

Re: [Intel-gfx] [PATCH 15/23] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:12PM -0700, Radhakrishna Sripada wrote:
> From Meteorlake, Latency Level, SAGV bloack time are read from
> LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
> and QGV information are also tob read from Mem SS registers.

There seems to be a typo here.  I'm not sure what it's trying to say.

> 
> Bspec: 49324, 64636

49324 doesn't look correct.  Did you mean 64608?

> 
> Cc: Matt Roper 
> Original Author: Caz Yokoyama
> Signed-off-by: José Roberto de Souza 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 49 +++--
>  drivers/gpu/drm/i915/display/intel_bw.h |  9 +
>  drivers/gpu/drm/i915/i915_reg.h | 16 
>  drivers/gpu/drm/i915/intel_dram.c   | 41 -
>  drivers/gpu/drm/i915/intel_pm.c |  8 +++-
>  5 files changed, 110 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 79269d2c476b..8bbf47da1716 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -15,11 +15,6 @@
>  #include "intel_pcode.h"
>  #include "intel_pm.h"
>  
> -/* Parameters for Qclk Geyserville (QGV) */
> -struct intel_qgv_point {
> - u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> -};
> -
>  struct intel_psf_gv_point {
>   u8 clk; /* clock in multiples of 16. MHz */
>  };
> @@ -137,6 +132,42 @@ int icl_pcode_restrict_qgv_points(struct 
> drm_i915_private *dev_priv,
>   return 0;
>  }
>  
> +static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
> +struct intel_qgv_point *sp, int point)
> +{
> + u32 val, val2;
> + u16 dclk;
> +
> + val = intel_uncore_read(&dev_priv->uncore,
> + MTL_MEM_SS_INFO_QGV_POINT(point, 0));
> + val2 = intel_uncore_read(&dev_priv->uncore,
> +  MTL_MEM_SS_INFO_QGV_POINT(point, 1));
> + dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
> + sp->dclk = DIV_ROUND_UP((16667 * dclk) +  500, 1000);

What is the "+ 500" for here?  You're already doing a DIV_ROUND_UP, so
this doesn't seem right.


> + sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
> + sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
> +
> + sp->t_rdpre = REG_FIELD_GET(MTL_TRDPRE_MASK, val2);
> + sp->t_ras = REG_FIELD_GET(MTL_TRAS_MASK, val2);
> +
> + sp->t_rc = sp->t_rp + sp->t_ras;
> +
> + return 0;
> +}
> +
> +int
> +intel_read_qgv_point_info(struct drm_i915_private *dev_priv,
> +   struct intel_qgv_point *sp,
> +   int point)
> +{
> + if (DISPLAY_VER(dev_priv) >= 14)
> + return mtl_read_qgv_point_info(dev_priv, sp, point);
> + else if (IS_DG1(dev_priv))
> + return dg1_mchbar_read_qgv_point_info(dev_priv, sp, point);
> + else
> + return icl_pcode_read_qgv_point_info(dev_priv, sp, point);
> +}
> +
>  static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
> struct intel_qgv_info *qi,
> bool is_y_tile)
> @@ -193,11 +224,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>   for (i = 0; i < qi->num_points; i++) {
>   struct intel_qgv_point *sp = &qi->points[i];
>  
> - if (IS_DG1(dev_priv))
> - ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp, i);
> - else
> - ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
> -
> + ret = intel_read_qgv_point_info(dev_priv, sp, i);
>   if (ret)
>   return ret;
>  
> @@ -560,7 +587,7 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
>  
>   if (IS_DG2(dev_priv))
>   dg2_get_bw_info(dev_priv);
> - else if (IS_ALDERLAKE_P(dev_priv))
> + else if (DISPLAY_VER(dev_priv) >= 13 || IS_ALDERLAKE_P(dev_priv))

ADL-P is display version 13, so it's already covered by the first half
of the condition here.

But this doesn't look right in general.  At the very least MTL has a
deburst value of 32, so we don't want to re-use ADL-P's 16.  I didn't
check all the others, but there may or may not be other differences.

>   tgl_get_bw_info(dev_priv, &adlp_sa_info);
>   else if (IS_ALDERLAKE_S(dev_priv))
>   tgl_get_bw_info(dev_priv, &adls_sa_info);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index cb7ee3a24a58..b4c6665b0cf0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -46,6 +46,11 @@ struct intel_bw_state {
>   u8 num_active_planes[I915_MAX_PIPES];
>  };
>  
> +/* Parameters for Qclk Geyserville (QGV) */
> +struct intel_qgv_point {
> + u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> +};
> +
>  #define to_intel_bw_stat

Re: [Intel-gfx] [PATCH 13/23] drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:10PM -0700, Radhakrishna Sripada wrote:
> Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
> instead of GT driver mailbox.
> 
> Bspec: 64608
> 
> Cc: Matt Roper 
> Original Author: Caz Yokoyama
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |   7 +++
>  drivers/gpu/drm/i915/intel_pm.c | 105 +++-
>  2 files changed, 71 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6087d40eed70..23b50d671550 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8754,4 +8754,11 @@ enum skl_power_gate {
>  #define GEN12_STATE_ACK_DEBUG_MMIO(0x20BC)
>  
>  #define MTL_MEDIA_GSI_BASE   0x38
> +
> +#define MTL_LATENCY_LP0_LP1  _MMIO(0x45780)
> +#define MTL_LATENCY_LP2_LP3  _MMIO(0x45784)
> +#define MTL_LATENCY_LP4_LP5  _MMIO(0x45788)
> +#define  MTL_LATENCY_LEVEL0_2_4_MASK REG_GENMASK(12, 0)
> +#define  MTL_LATENCY_LEVEL1_3_5_MASK REG_GENMASK(28, 16)
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ef7553b494ea..fac565d23d57 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2861,16 +2861,75 @@ static void ilk_compute_wm_level(const struct 
> drm_i915_private *dev_priv,
>   result->enable = true;
>  }
>  
> +static void
> +adjust_wm_latency(u16 wm[], int max_level, int read_latency,
> +   bool wm_lv_0_adjust_needed)

The refactoring to separate the adjustment from the readout should
probably be a separate patch before you add the MTL-specific changes on
top.


Matt

> +{
> + int i, level;
> +
> + /*
> +  * If a level n (n > 1) has a 0us latency, all levels m (m >= n)
> +  * need to be disabled. We make sure to sanitize the values out
> +  * of the punit to satisfy this requirement.
> +  */
> + for (level = 1; level <= max_level; level++) {
> + if (wm[level] == 0) {
> + for (i = level + 1; i <= max_level; i++)
> + wm[i] = 0;
> +
> + max_level = level - 1;
> + break;
> + }
> + }
> +
> + /*
> +  * WaWmMemoryReadLatency
> +  *
> +  * punit doesn't take into account the read latency so we need
> +  * to add proper adjustement to each valid level we retrieve
> +  * from the punit when level 0 response data is 0us.
> +  */
> + if (wm[0] == 0) {
> + for (level = 0; level <= max_level; level++)
> + wm[level] += read_latency;
> + }
> +
> + /*
> +  * WA Level-0 adjustment for 16GB DIMMs: SKL+
> +  * If we could not get dimm info enable this WA to prevent from
> +  * any underrun. If not able to get Dimm info assume 16GB dimm
> +  * to avoid any underrun.
> +  */
> + if (wm_lv_0_adjust_needed)
> + wm[0] += 1;
> +}
> +
>  static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
> u16 wm[])
>  {
>   struct intel_uncore *uncore = &dev_priv->uncore;
> + int max_level = ilk_wm_max_level(dev_priv);
>  
> - if (DISPLAY_VER(dev_priv) >= 9) {
> + if (DISPLAY_VER(dev_priv) >= 14) {
>   u32 val;
> - int ret, i;
> - int level, max_level = ilk_wm_max_level(dev_priv);
> +
> + val = intel_uncore_read(uncore, MTL_LATENCY_LP0_LP1);
> + wm[0] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
> + wm[1] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
> + val = intel_uncore_read(uncore, MTL_LATENCY_LP2_LP3);
> + wm[2] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
> + wm[3] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
> + val = intel_uncore_read(uncore, MTL_LATENCY_LP4_LP5);
> + wm[4] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
> + wm[5] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
> +
> + adjust_wm_latency(wm, max_level, 6,
> +   dev_priv->dram_info.wm_lv_0_adjust_needed);
> + } else if (DISPLAY_VER(dev_priv) >= 9) {
> + int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
>   int mult = IS_DG2(dev_priv) ? 2 : 1;
> + u32 val;
> + int ret;
>  
>   /* read the first set of memory latencies[0:3] */
>   val = 0; /* data0 to be programmed to 0 for first set */
> @@ -2909,44 +2968,8 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>   wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
>   GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
>  
> - /*
> -  * If a level n (n > 1) has a 0us latency, all

Re: [Intel-gfx] [PATCH 11/23] drm/i915/mtl: Add DP AUX support on TypeC ports

[Matt Roper]

On Wed, Jul 27, 2022 at 06:34:08PM -0700, Radhakrishna Sripada wrote:
> From: Imre Deak 
> 
> On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
> changed wrt. previous platforms, adjust the code accordingly.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 40c4bdd9cb26..10616e18dc18 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -637,6 +637,46 @@ static i915_reg_t tgl_aux_data_reg(struct intel_dp 
> *intel_dp, int index)
>   }
>  }
>  
> +static i915_reg_t xelpdp_aux_ctl_reg(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum aux_ch aux_ch = dig_port->aux_ch;
> +
> + switch (aux_ch) {
> + case AUX_CH_A:
> + case AUX_CH_B:
> + case AUX_CH_USBC1:
> + case AUX_CH_USBC2:
> + case AUX_CH_USBC3:
> + case AUX_CH_USBC4:
> + return XELPDP_DP_AUX_CH_CTL(aux_ch);
> + default:
> + MISSING_CASE(aux_ch);
> + return XELPDP_DP_AUX_CH_CTL(AUX_CH_A);
> + }
> +}
> +
> +static i915_reg_t xelpdp_aux_data_reg(struct intel_dp *intel_dp, int index)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum aux_ch aux_ch = dig_port->aux_ch;
> +
> + switch (aux_ch) {
> + case AUX_CH_A:
> + case AUX_CH_B:
> + case AUX_CH_USBC1:
> + case AUX_CH_USBC2:
> + case AUX_CH_USBC3:
> + case AUX_CH_USBC4:
> + return XELPDP_DP_AUX_CH_DATA(aux_ch, index);

The definition of XELPDP_DP_AUX_CH_DATA was in the previous patch but
wasn't actually used there; it should probably be moved to this one.


Matt

> + default:
> + MISSING_CASE(aux_ch);
> + return XELPDP_DP_AUX_CH_DATA(AUX_CH_A, index);
> + }
> +}
> +
>  void intel_dp_aux_fini(struct intel_dp *intel_dp)
>  {
>   if (cpu_latency_qos_request_active(&intel_dp->pm_qos))
> @@ -652,7 +692,10 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
>   struct intel_encoder *encoder = &dig_port->base;
>   enum aux_ch aux_ch = dig_port->aux_ch;
>  
> - if (DISPLAY_VER(dev_priv) >= 12) {
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
> + intel_dp->aux_ch_data_reg = xelpdp_aux_data_reg;
> + } else if (DISPLAY_VER(dev_priv) >= 12) {
>   intel_dp->aux_ch_ctl_reg = tgl_aux_ctl_reg;
>   intel_dp->aux_ch_data_reg = tgl_aux_data_reg;
>   } else if (DISPLAY_VER(dev_priv) >= 9) {
> -- 
> 2.25.1
> 

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

Re: [Intel-gfx] [PATCH 10/23] drm/i915/mtl: Add display power wells

[Matt Roper]

On Mon, Aug 01, 2022 at 06:23:39PM -0700, Matt Roper wrote:
> On Wed, Jul 27, 2022 at 06:34:07PM -0700, Radhakrishna Sripada wrote:
> > From: Imre Deak 
> > 
> > Add support for display power wells on MTL. The differences from D13:

Also, this should be "...from Xe_LPD"


Matt

> > - The AUX HW block is moved to the PICA block, where the registers are on
> >   an always-on power well and the functionality needs to be powered on/off
> >   via the AUX_CH_CTL register: [1], [2]
> > - The DDI IO power on/off programming sequence is moved to the PHY PLL
> >   enable/disable sequence. [3], [4], [5]
> > 
> > Bspec: [1] 49233, [2] 65247, [3] 64568, [4] 65451, [5] 65450
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  .../i915/display/intel_display_power_map.c| 115 +-
> >  .../i915/display/intel_display_power_well.c   |  43 +++
> >  .../i915/display/intel_display_power_well.h   |   4 +
> >  drivers/gpu/drm/i915/display/intel_dp_aux.c   |   8 ++
> >  drivers/gpu/drm/i915/i915_reg.h   |  30 +
> >  5 files changed, 199 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c 
> > b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > index 97b367f39f35..cd28976f8076 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > @@ -1350,6 +1350,117 @@ static const struct i915_power_well_desc_list 
> > xelpd_power_wells[] = {
> > I915_PW_DESCRIPTORS(xelpd_power_wells_main),
> >  };
> >  
> > +/*
> > + * MTL is based on XELPD power domains with the exception of power gating 
> > for:
> > + * - DDI_IO (moved to PLL logic)
> > + * - AUX and AUX_IO functionality and register access for USBC1-4 (PICA 
> > always-on)
> > + */
> > +#define XELPDP_PW_2_POWER_DOMAINS \
> > +   XELPD_PW_B_POWER_DOMAINS, \
> > +   XELPD_PW_C_POWER_DOMAINS, \
> > +   XELPD_PW_D_POWER_DOMAINS, \
> > +   POWER_DOMAIN_AUDIO_PLAYBACK, \
> > +   POWER_DOMAIN_VGA, \
> > +   POWER_DOMAIN_PORT_DDI_LANES_TC1, \
> > +   POWER_DOMAIN_PORT_DDI_LANES_TC2, \
> > +   POWER_DOMAIN_PORT_DDI_LANES_TC3, \
> > +   POWER_DOMAIN_PORT_DDI_LANES_TC4
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_pw_2,
> > +   XELPDP_PW_2_POWER_DOMAINS,
> > +   POWER_DOMAIN_INIT);
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_dc_off,
> > +   XELPDP_PW_2_POWER_DOMAINS,
> > +   POWER_DOMAIN_AUDIO_MMIO,
> > +   POWER_DOMAIN_MODESET,
> > +   POWER_DOMAIN_AUX_A,
> > +   POWER_DOMAIN_AUX_B,
> > +   POWER_DOMAIN_INIT);
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc1,
> > +   POWER_DOMAIN_AUX_USBC1,
> > +   POWER_DOMAIN_AUX_TBT1);
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc2,
> > +   POWER_DOMAIN_AUX_USBC2,
> > +   POWER_DOMAIN_AUX_TBT2);
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc3,
> > +   POWER_DOMAIN_AUX_USBC3,
> > +   POWER_DOMAIN_AUX_TBT3);
> > +
> > +I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc4,
> > +   POWER_DOMAIN_AUX_USBC4,
> > +   POWER_DOMAIN_AUX_TBT4);
> > +
> > +static const struct i915_power_well_desc xelpdp_power_wells_main[] = {
> > +   {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("DC_off", &xelpdp_pwdoms_dc_off,
> > +   .id = SKL_DISP_DC_OFF),
> > +   ),
> > +   .ops = &gen9_dc_off_power_well_ops,
> > +   }, {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("PW_2", &xelpdp_pwdoms_pw_2,
> > +   .hsw.idx = ICL_PW_CTL_IDX_PW_2,
> > +   .id = SKL_DISP_PW_2),
> > +   ),
> > +   .ops = &hsw_power_well_ops,
> > +   .has_vga = true,
> > +   .has_fuses = true,
> > +   }, {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("PW_A", &xelpd_pwdoms_pw_a,
> > +   .hsw.idx = XELPD_PW_CTL_IDX_PW_A),
> > +   ),
> > +   .ops = &hsw_power_well_ops,
> > +   .irq_pipe_mask = BIT(PIPE_A),
> > +   .has_fuses = true,
> > +   }, {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("PW_B", &xelpd_pwdoms_pw_b,
> > +   .hsw.idx = XELPD_PW_CTL_IDX_PW_B),
> > +   ),
> > +   .ops = &hsw_power_well_ops,
> > +   .irq_pipe_mask = BIT(PIPE_B),
> > +   .has_fuses = true,
> > +   }, {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("PW_C", &xelpd_pwdoms_pw_c,
> > +   .hsw.idx = XELPD_PW_CTL_IDX_PW_C),
> > +   ),
> > +   .ops = &hsw_power_well_ops,
> > +   .irq_pipe_mask = BIT(PIPE_C),
> > +   .has_fuses = true,
> > +   }, {
> > +   .instances = &I915_PW_INSTANCES(
> > +   I915_PW("PW_D", &xelpd_pwdoms_pw_d,
> > +   .hsw.idx = XELPD_PW_CTL_IDX_PW_D),
> > +   ),
> > +   .ops = &hsw_power_well_ops,
> > +   .irq

Re: [Intel-gfx] [PATCH] drm/i915/display: Audio keep alive timestamp cdclk divisors

[Jani Nikula]

On Fri, 22 Jul 2022, "Taylor, Clinton A"  wrote:
> Use BSPEC values for the Audio Keep alive M and N values as included in
> the cdclk BSPEC pages for display > 13
>
> BSPEC: 54034, 55409
> Cc: Kai Vehmanen 
> Cc: Uma Shankar 
> Cc: Ville Syrjälä 
> Signed-off-by: Taylor, Clinton A 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 23 +--
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 79 ++
>  drivers/gpu/drm/i915/display/intel_cdclk.h |  1 +
>  3 files changed, 51 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 6c9ee905f132..cb45be5edfec 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -945,37 +945,16 @@ void intel_audio_hooks_init(struct drm_i915_private 
> *dev_priv)
>   }
>  }
>  
> -struct aud_ts_cdclk_m_n {
> - u8 m;
> - u16 n;
> -};
> -
>  void intel_audio_cdclk_change_pre(struct drm_i915_private *i915)
>  {
>   if (DISPLAY_VER(i915) >= 13)
>   intel_de_rmw(i915, AUD_TS_CDCLK_M, AUD_TS_CDCLK_M_EN, 0);
>  }
>  
> -static void get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct 
> aud_ts_cdclk_m_n *aud_ts)
> -{
> - if (refclk == 24000)
> - aud_ts->m = 12;
> - else
> - aud_ts->m = 15;
> -
> - aud_ts->n = cdclk * aud_ts->m / 24000;
> -}
> -
>  void intel_audio_cdclk_change_post(struct drm_i915_private *i915)
>  {
> - struct aud_ts_cdclk_m_n aud_ts;
> -
>   if (DISPLAY_VER(i915) >= 13) {
> - get_aud_ts_cdclk_m_n(i915->cdclk.hw.ref, i915->cdclk.hw.cdclk, 
> &aud_ts);
> -
> - intel_de_write(i915, AUD_TS_CDCLK_N, aud_ts.n);
> - intel_de_write(i915, AUD_TS_CDCLK_M, aud_ts.m | 
> AUD_TS_CDCLK_M_EN);
> - drm_dbg_kms(&i915->drm, "aud_ts_cdclk set to M=%u, N=%u\n", 
> aud_ts.m, aud_ts.n);
> + intel_update_audio_keep_alive(i915);
>   }
>  }

The organization of the functions is now a bit silly to be honest.

intel_set_cdclk() in intel_cdclk.c -> intel_audio_cdclk_change_post() in
intel_audio.c -> intel_update_audio_keep_alive() in intel_cdclk.c.

Just drop the round trip to intel_audio.c? Or maybe add a function to
set the M/N and limit the audio register access to intel_audio.c like it
should be.

> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 86a22c3766e5..57021ecad509 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -37,6 +37,7 @@
>  #include "intel_pcode.h"
>  #include "intel_psr.h"
>  #include "vlv_sideband.h"
> +#include "intel_audio_regs.h"

Alphabetical order please.

BR,
Jani.

>  
>  /**
>   * DOC: CDCLK / RAWCLK
> @@ -1231,6 +1232,8 @@ struct intel_cdclk_vals {
>   u16 waveform;
>   u8 divider; /* CD2X divider * 2 */
>   u8 ratio;
> + u16 aud_m;
> + u16 aud_n;
>  };
>  
>  static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> @@ -1313,40 +1316,40 @@ static const struct intel_cdclk_vals 
> adlp_a_step_cdclk_table[] = {
>  };
>  
>  static const struct intel_cdclk_vals adlp_cdclk_table[] = {
> - { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27 },
> - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> -
> - { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22 },
> - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> - { .refclk = 24400, .cdclk = 648000, .divider = 2, .ratio = 54 },
> -
> - { .refclk = 38400, .cdclk = 179200, .divider = 3, .ratio = 14 },
> - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> - { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> - { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> - { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> + { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27, .aud_m = 
> 0x3C, .aud_n = 0x140 },
> + { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20, .aud_m = 
> 0x3C, .aud_n = 0x1E0 },
> + { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32, .aud_m = 
> 0x3C, .aud_n = 0x300 },
> + { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58, .aud_m = 
> 0x3C, .aud_n = 0x570 },
> + { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68, .aud_m = 
> 0x3C, .aud_n = 0x660 },
> +
> + { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22, .aud_m = 
> 0x3C, .aud_n = 0x1B8 },
> + { .refcl

[Intel-gfx] [PATCH] drm/i915/display: avoid abnormal pixel output when turn eDP display off

[Lee Shawn C]

Customer report abnormal display output while switch eDP off sometimes.
In current display disable flow, plane will be off at first. Then turn
eDP off and disable HW pipe line. Try to turn PLANE_SURF off before
disable PLANE_CTL. No more abnormal pixel appear on eDP with this changes.

Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 4d6a27757065..7e7d265131b2 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -618,8 +618,8 @@ skl_plane_disable_arm(struct intel_plane *plane,
 
skl_write_plane_wm(plane, crtc_state);
 
-   intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0);
+   intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
 }
 
 static void
@@ -636,8 +636,8 @@ icl_plane_disable_arm(struct intel_plane *plane,
skl_write_plane_wm(plane, crtc_state);
 
intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
-   intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 0);
+   intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
 }
 
 static bool
-- 
2.17.1

Re: [Intel-gfx] [PATCH v2] drm/i915/dg2: Add Wa_1509727124

[Matt Roper]

On Mon, Aug 01, 2022 at 02:38:39PM -0700, Harish Chegondi wrote:
> Bspec: 46052
> Reviewed-by: Matt Roper 
> Signed-off-by: Harish Chegondi 

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


Matt

> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 60d6eb5f245b..b3b49f6d6d1c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1078,6 +1078,7 @@
>  
>  #define GEN10_SAMPLER_MODE   _MMIO(0xe18c)
>  #define   ENABLE_SMALLPL REG_BIT(15)
> +#define   SC_DISABLE_POWER_OPTIMIZATION_EBB  REG_BIT(9)
>  #define   GEN11_SAMPLER_ENABLE_HEADLESS_MSG  REG_BIT(5)
>  
>  #define GEN9_HALF_SLICE_CHICKEN7 _MMIO(0xe194)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index e8111fce56d0..59cf28baa472 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2119,6 +2119,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>   wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
>   }
>  
> + if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
> + IS_DG2_G11(i915) || IS_DG2_G12(i915)) {
> + /* Wa_1509727124:dg2 */
> + wa_masked_en(wal, GEN10_SAMPLER_MODE,
> +  SC_DISABLE_POWER_OPTIMIZATION_EBB);
> + }
> +
>   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0) ||
>   IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
>   /* Wa_14012419201:dg2 */
> -- 
> 2.37.1
> 

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Remove shared locking on freeing objects

[Das, Nirmoy]

On 7/26/2022 9:15 PM, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   drm/i915/gem: Remove shared locking on freeing objects
*URL:*  https://patchwork.freedesktop.org/series/106720/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v1/index.html



  CI Bug Log - changes from CI_DRM_11943_full -> Patchwork_106720v1_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_106720v1_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106720v1_full, please notify your bug team to 
allow them
to document this new failure mode, which will reduce false positives 
in CI.



Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

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



  IGT changes


Possible regressions

  * igt@device_reset@unbind-reset-rebind:
  o shard-tglb: PASS


-> INCOMPLETE





Tested this on my local TGL NUC with success, seems spurious.


Nirmoy


 *


New tests

New tests have been introduced between CI_DRM_11943_full and 
Patchwork_106720v1_full:



  New IGT tests (4)

 *

igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-a-hdmi-a-4:

  o Statuses : 1 pass(s)
  o Exec time: [0.40] s
 *

igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-b-hdmi-a-4:

  o Statuses : 1 pass(s)
  o Exec time: [0.41] s
 *

igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-c-hdmi-a-4:

  o Statuses : 1 pass(s)
  o Exec time: [0.41] s
 *

igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-d-hdmi-a-4:

  o Statuses : 1 pass(s)
  o Exec time: [0.41] s


Known issues

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



  IGT changes


Issues hit

 *

igt@feature_discovery@display-4x:

  o shard-tglb: NOTRUN -> SKIP


(i915#1839 )
 *

igt@gem_ctx_isolation@preservation-s3@vcs0:

  o shard-kbl: PASS


-> DMESG-WARN


(i915#180
) +1
similar issue
 *

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

  o shard-iclb: PASS


-> SKIP


(i915#4525
) +1
similar issue
 *

igt@gem_exec_fair@basic-none-solo@rcs0:

 o

shard-apl: PASS


-> FAIL


(i915#2842 )

 o

shard-kbl: PASS


-> FAIL


(i915#2842 )

 *

igt@gem_exec_fair@basic-pace-share@rcs0:

  o shard-glk: PASS


-> FAIL


(i915#2842
) +2
similar issues
 *

igt@gem_exec_fair@basic-pace@bcs0:

  o shard-tglb: NOTRUN -> SKIP


(i915#2848
) +4
similar issues

Re: [Intel-gfx] [PATCHv2] drm/i915/display: add support for dual panel backlight

[Jani Nikula]

On Wed, 13 Jul 2022, Arun R Murthy  wrote:
> The patch with commit 20f85ef89d94 ("drm/i915/backlight: use unique
> backlight device names") already adds support for dual panel backlight
> but with error prints. Since the patch tried to create the backlight
> device with the same name and upon failure will try with a different
> name it leads to failure logs in dmesg inturn getting caught by CI.
>
> This patch alternately will check if the backlight class of same name
> exists, will use a different name.
>
> v2: reworked on top of the patch 20f85ef89d94 ("drm/i915/backlight: use
> unique backlight device names")
>
> Signed-off-by: Arun R Murthy 
> ---
>  .../gpu/drm/i915/display/intel_backlight.c| 24 ---
>  1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 110fc98ec280..1e550d048e86 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -971,26 +971,22 @@ int intel_backlight_device_register(struct 
> intel_connector *connector)
>   if (!name)
>   return -ENOMEM;
>  
> - bd = backlight_device_register(name, connector->base.kdev, connector,
> -&intel_backlight_device_ops, &props);
> -
> - /*
> -  * Using the same name independent of the drm device or connector
> -  * prevents registration of multiple backlight devices in the
> -  * driver. However, we need to use the default name for backward
> -  * compatibility. Use unique names for subsequent backlight devices as a
> -  * fallback when the default name already exists.
> -  */
> - if (IS_ERR(bd) && PTR_ERR(bd) == -EEXIST) {
> + if (backlight_device_get_by_name(name)) {

This leaks a reference count to the backlight device. It needs to be
something like:

bd = backlight_device_get_by_name(name);
if (bd) {
put_device(&bd->dev);

/* ... */
}

BR,
Jani.

> + /*
> +  * Using the same name independent of the drm device or 
> connector
> +  * prevents registration of multiple backlight devices in the
> +  * driver. However, we need to use the default name for backward
> +  * compatibility. Use unique names for subsequent backlight 
> devices as a
> +  * fallback when the default name already exists.
> +  */
>   kfree(name);
>   name = kasprintf(GFP_KERNEL, "card%d-%s-backlight",
>i915->drm.primary->index, 
> connector->base.name);
>   if (!name)
>   return -ENOMEM;
> -
> - bd = backlight_device_register(name, connector->base.kdev, 
> connector,
> -&intel_backlight_device_ops, 
> &props);
>   }
> + bd = backlight_device_register(name, connector->base.kdev, connector,
> +&intel_backlight_device_ops, &props);
>  
>   if (IS_ERR(bd)) {
>   drm_err(&i915->drm,

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/drm_edid: Refactor HFVSDB parsing for DSC1.2

[Jani Nikula]

On Fri, 22 Jul 2022, Ankit Nautiyal  wrote:
> DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
> SCDS). Since minimum length of Data block is 7, all bytes greater than 7
> must be read only after checking the length of the data block.
>
> This patch adds check for data block length before reading relavant DSC
> bytes. It also corrects min DSC BPC to 8, and minor refactoring for
> better readability, and proper log messages.

I think this patch tries to do too much at once. Please split it up. One
thing per patch.

I think the logging is excessive, and what logging remains should use
drm_dbg_kms() instead of DRM_DEBUG_KMS().

Further comments inline.

>
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_edid.c | 124 +++--
>  1 file changed, 77 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bbc25e3b7220..f683a8d5fd31 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5703,12 +5703,58 @@ static void drm_parse_ycbcr420_deep_color_info(struct 
> drm_connector *connector,
>   hdmi->y420_dc_modes = dc_mask;
>  }
>  
> +static void drm_parse_dsc_slice_info(u8 dsc_max_slices,
> +  struct drm_hdmi_dsc_cap *hdmi_dsc)

Arguments should always be in the order: context, destination, source.

> +{
> + switch (dsc_max_slices) {
> + case 1:
> + hdmi_dsc->max_slices = 1;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 2:
> + hdmi_dsc->max_slices = 2;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 3:
> + hdmi_dsc->max_slices = 4;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 4:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 5:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 6:
> + hdmi_dsc->max_slices = 12;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 7:
> + hdmi_dsc->max_slices = 16;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 0:
> + default:
> + hdmi_dsc->max_slices = 0;
> + hdmi_dsc->clk_per_slice = 0;
> + }
> +}
> +
>  /* Sink Capability Data Structure */
>  static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
> const u8 *hf_scds)
>  {
>   struct drm_display_info *display = &connector->display_info;
>   struct drm_hdmi_info *hdmi = &display->hdmi;
> + u8 db_length = hf_scds[0] & 0x1F;

There's cea_db_payload_len() for this, and you can use that directly
instead of caching the value to a local variable.

> + u8 dsc_max_frl_rate;
> + u8 dsc_max_slices;

These two are local to a tiny if block and should be declared there.

> + struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
> +
> + if (db_length < 7 || db_length > 31)
> + return;

Both cea_db_is_hdmi_forum_vsdb() and cea_db_is_hdmi_forum_scdb() check
the payload is >= 7 bytes before this one even gets called.

There's no reason to not parse the first 31 bytes if the length is > 31
bytes. That condition just breaks future compatibility for no reason.

>  
>   display->has_hdmi_infoframe = true;
>  
> @@ -5749,17 +5795,25 @@ static void drm_parse_hdmi_forum_scds(struct 
> drm_connector *connector,
>  
>   if (hf_scds[7]) {
>   u8 max_frl_rate;
> - u8 dsc_max_frl_rate;
> - u8 dsc_max_slices;
> - struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
>  
> - DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
>   max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
> + if (max_frl_rate)
> + DRM_DEBUG_KMS("HDMI2.1 FRL support detected\n");
> +
>   drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
>&hdmi->max_frl_rate_per_lane);
> +
> + drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
> + }
> +
> + if (db_length < 11)
> + return;
> +
> + if (hf_scds[11]) {

Matter of taste, but I'd probably make these

if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])

and drop the early returns, and add a single (or very few) debug logging
call at the end.

>   hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
>  
>   if (hdmi_dsc->v_1p2) {
> + DRM_DEBUG_KMS("HDMI DSC1.2 support detected\n");
>   hdmi_dsc->native_420 = hf_scds[11] & 
> DRM_EDID_DSC_NATIVE_420;
>   hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
>  
> @@ -5770,52 +5824,28 @@ static void drm_par

Re: [Intel-gfx] [CI] drm/i915/dg2: Add support for DC5 state

[Imre Deak]

On Thu, Jul 28, 2022 at 11:36:41AM -0700, Anusha Srivatsa wrote:
> With the latest DMC in place, enabling DC5 on DG2.
> 
> Cc: Imre Deak 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Imre Deak 

Thanks for the patch, pushed to drm-intel-next.

The failures in the IGT CI result are unrelated, since there are no
shard-DG2 machines.

> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 13aaa3247a5a..3f84af6beff3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -908,7 +908,7 @@ static u32 get_allowed_dc_mask(const struct 
> drm_i915_private *dev_priv,
>   return 0;
>  
>   if (IS_DG2(dev_priv))
> - max_dc = 0;
> + max_dc = 1;
>   else if (IS_DG1(dev_priv))
>   max_dc = 3;
>   else if (DISPLAY_VER(dev_priv) >= 12)
> -- 
> 2.25.1
> 

Re: [Intel-gfx] [PATCH v6 0/4] drm/i915/display: stop HPD workers before display driver unregister

[Gwan-gyeong Mun]

Hi Jani, Ville and Imre,

If there are no problems after reviewing this patch series, could you 
please merge it?


Many thanks,
G.G.

On 7/22/22 3:51 PM, Andrzej Hajda wrote:

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
   - reword of commit message (Arun)
   - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
   - new patch adding suspended flag, to handle
 https://gitlab.freedesktop.org/drm/intel/-/issues/5950
v4:
   - check suspend flag also in i915_digport_work_func
v5:
   - added patch blocking FB creation in case HPD is supended,
   - added R-B from Arun to patch 3, thx
v6:
   - finally, after getting direct access to bat-rpls-2, I have found the 
source of last WARN,
 intel_fbdev_hpd_set_suspend was not called in case of deferred setup, 
fixed in patch 2.

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (4):
   drm/i915/hpd: postpone HPD cancel work after last user suspension
   drm/i915/fbdev: suspend HPD before fbdev unregistration
   drm/i915/display: add hotplug.suspended flag
   drm/i915/fbdev: do not create fbdev if HPD is suspended

  drivers/gpu/drm/i915/display/intel_display.c |  3 +++
  drivers/gpu/drm/i915/display/intel_fbdev.c   | 12 ++--
  drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
  drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
  drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
  drivers/gpu/drm/i915/i915_irq.c  |  1 -
  7 files changed, 28 insertions(+), 7 deletions(-)

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add additional HDMI pixel clock frequencies (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Add additional HDMI pixel clock frequencies (rev2)
URL   : https://patchwork.freedesktop.org/series/106891/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11961_full -> Patchwork_106891v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@syncobj_timeline@signal-point-0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-iclb3/igt@syncobj_timel...@signal-point-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-iclb4/igt@syncobj_timel...@signal-point-0.html

  
 Suppressed 

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

  * igt@i915_pm_rps@fence-order:
- {shard-rkl}:[PASS][3] -> [TIMEOUT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-rkl-5/igt@i915_pm_...@fence-order.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-rkl-6/igt@i915_pm_...@fence-order.html

  
New tests
-

  New tests have been introduced between CI_DRM_11961_full and 
Patchwork_106891v2_full:

### New IGT tests (4) ###

  * igt@kms_cursor_crc@cursor-dpms@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.89] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.75] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.73] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.74] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-iclb6/igt@gem_exec_balan...@parallel-keep-submit-fence.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-glk3/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-glk2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-glk2/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-glk:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-glk1/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-kbl4/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106891v2/shard-skl10/igt@gem_lmem_swapp...@parallel-random-ve

Re: [Intel-gfx] [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper

[Hans de Goede]

Hi Daniel,

On 7/21/22 23:30, Daniel Dadap wrote:
> 
> On 7/21/22 16:24, Daniel Dadap wrote:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> ATM on x86 laptops where we want userspace to use the acpi_video backlight
>>> device we often register both the GPU's native backlight device and
>>> acpi_video's firmware acpi_video# backlight device. This relies on
>>> userspace preferring firmware type backlight devices over native ones, but
>>> registering 2 backlight devices for a single display really is undesirable.
>>>
>>> On x86 laptops where the native GPU backlight device should be used,
>>> the registering of other backlight devices is avoided by their drivers
>>> using acpi_video_get_backlight_type() and only registering their backlight
>>> if the return value matches their type.
>>>
>>> acpi_video_get_backlight_type() uses
>>> backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
>>> driver is available and will never return native if this returns
>>> false. This means that the GPU's native backlight registering code
>>> cannot just call acpi_video_get_backlight_type() to determine if it
>>> should register its backlight, since acpi_video_get_backlight_type() will
>>> never return native until the native backlight has already registered.
>>>
>>> To fix this add a new internal native function parameter to
>>> acpi_video_get_backlight_type(), which when set to true will make
>>> acpi_video_get_backlight_type() behave as if a native backlight has
>>> already been registered.
>>>
>>> And add a new acpi_video_backlight_use_native() helper, which sets this
>>> to true, for use in native GPU backlight code.
>>>
>>> Changes in v2:
>>> - Replace adding a native parameter to acpi_video_get_backlight_type() with
>>>    adding a new acpi_video_backlight_use_native() helper.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>   drivers/acpi/video_detect.c | 24 
>>>   include/acpi/video.h    |  5 +
>>>   2 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index becc198e4c22..4346c990022d 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -17,8 +17,9 @@
>>>    * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>>    * sony_acpi,... can take care about backlight brightness.
>>>    *
>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>> - * which driver should handle the backlight.
>>> + * Backlight drivers can use acpi_video_get_backlight_type() to determine 
>>> which
>>> + * driver should handle the backlight. RAW/GPU-driver backlight drivers 
>>> must
>>> + * use the acpi_video_backlight_use_native() helper for this.
>>>    *
>>>    * If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a 
>>> module (m)
>>>    * this file will not be compiled and acpi_video_get_backlight_type() will
>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct 
>>> notifier_block *nb,
>>>    * Arguably the native on win8 check should be done first, but that would
>>>    * be a behavior change, which may causes issues.
>>>    */
>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool 
>>> native)
>>>   {
>>>   static DEFINE_MUTEX(init_mutex);
>>> +    static bool native_available;
>>>   static bool init_done;
>>>   static long video_caps;
>>>   @@ -570,6 +572,8 @@ enum acpi_backlight_type 
>>> acpi_video_get_backlight_type(void)
>>>   backlight_notifier_registered = true;
>>>   init_done = true;
>>>   }
>>> +    if (native)
>>> +    native_available = true;
>>>   mutex_unlock(&init_mutex);
>>>     if (acpi_backlight_cmdline != acpi_backlight_undef)
>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type 
>>> acpi_video_get_backlight_type(void)
>>>   if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>>   return acpi_backlight_vendor;
>>>   -    if (acpi_osi_is_win8() && 
>>> backlight_device_get_by_type(BACKLIGHT_RAW))
>>> +    if (acpi_osi_is_win8() &&
>>> +    (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>>   return acpi_backlight_native;
>>>     return acpi_backlight_video;
>>
>>
>> So I ran into a minor problem when testing the NVIDIA proprietary driver 
>> against this change set, after checking acpi_video_backlight_use_native() 
>> before registering the NVIDIA proprietary driver's backlight handler. 
>> Namely, for the case where a user installs the NVIDIA proprietary driver 
>> after the video.ko has already registered its backlight handler, we end up 
>> with both the firmware and native handlers registered simultaneously, since 
>> the ACPI video driver no longer unregisters its backlight handler. In this 
>> state, desktop environments end up preferring the registered but 
>> non-functional firmware handler from video.ko. (Ma

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Enabling Pipewriteback

[Patchwork]

== Series Details ==

Series: Enabling Pipewriteback
URL   : https://patchwork.freedesktop.org/series/106902/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/display/intel_wd.o
drivers/gpu/drm/i915/display/intel_wd.c:352:6: error: no previous prototype for 
‘intel_wd_connector_init’ [-Werror=missing-prototypes]
 void intel_wd_connector_init(struct intel_wd *intel_wd)
  ^~~
drivers/gpu/drm/i915/display/intel_wd.c:426:6: error: no previous prototype for 
‘intel_wd_writeback_complete’ [-Werror=missing-prototypes]
 void intel_wd_writeback_complete(struct intel_wd *intel_wd,
  ^~~
drivers/gpu/drm/i915/display/intel_wd.c:434:5: error: no previous prototype for 
‘intel_wd_setup_transcoder’ [-Werror=missing-prototypes]
 int intel_wd_setup_transcoder(struct intel_wd *intel_wd,
 ^
drivers/gpu/drm/i915/display/intel_wd.c:590:5: error: no previous prototype for 
‘intel_wd_capture’ [-Werror=missing-prototypes]
 int intel_wd_capture(struct intel_wd *intel_wd,
 ^~~~
cc1: all warnings being treated as errors
scripts/Makefile.build:249: recipe for target 
'drivers/gpu/drm/i915/display/intel_wd.o' failed
make[4]: *** [drivers/gpu/drm/i915/display/intel_wd.o] Error 1
scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:466: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1843: recipe for target 'drivers' failed
make: *** [drivers] Error 2

[Intel-gfx] [PATCH 2/2] drm/i915: Enabling WD Transcoder

[Suraj Kandpal]

Adding support for writeback transcoder to start capturing frames using
interrupt mechanism

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_crtc.c |   3 +
 .../drm/i915/display/intel_crtc_state_dump.c  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  63 +-
 drivers/gpu/drm/i915/display/intel_display.h  |  19 +-
 .../drm/i915/display/intel_display_debugfs.c  |  14 +-
 .../drm/i915/display/intel_display_types.h|  36 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   6 +
 .../drm/i915/display/intel_modeset_setup.c|  67 +-
 .../drm/i915/display/intel_modeset_verify.c   |  18 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 .../gpu/drm/i915/display/intel_wb_connector.h |  20 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 726 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  76 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 18 files changed, 1044 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..ec63ed16c250 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -302,6 +302,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+   display/intel_wd.o \
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..ae08db164f73 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector 
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 4442aa355f86..f9fa612ac991 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -512,6 +512,9 @@ void intel_pipe_update_start(struct intel_crtc_state 
*new_crtc_state)
if (min <= 0 || max <= 0)
goto irq_disable;
 
+   if (new_crtc_state->output_types & BIT(INTEL_OUTPUT_WD))
+   goto irq_disable;
+
if (drm_WARN_ON(&dev_priv->drm, drm_crtc_vblank_get(&crtc->base)))
goto irq_disable;
 
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index e9212f69c360..f49630d95d6a 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -71,6 +71,7 @@ static const char * const output_type_str[] = {
OUTPUT_TYPE(DSI),
OUTPUT_TYPE(DDI),
OUTPUT_TYPE(DP_MST),
+   OUTPUT_TYPE(WD)
 };
 
 #undef OUTPUT_TYPE
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index a0f84cbe974f..90b41b49e1d7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -116,6 +116,7 @@
 #include "intel_sprite.h"
 #include "intel_tc.h"
 #include "intel_vga.h"
+#include "intel_wd.h"
 #include "i9xx_plane.h"
 #include "skl_scaler.h"
 #include "skl_universal_plane.h"
@@ -1507,6 +1508,9 @@ static void intel_encoders_update_prepare(struct 
intel_atomic_state *state)
struct intel_encoder *encoder;
struct intel_crtc *crtc;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+   continue;
+
if (!intel_connector_needs_modeset(state, connector))
continue;
 
@@ -1536,6 +1540,9 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
struct intel_encoder *encoder;
struct intel_crtc *crtc;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+   continue;
+
if (!intel_connector_needs_modeset(state, connector))
continue;
 
@@ -1550,6 +1557,39 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
}
 }
 
+static void intel_queue_writeback_job(struct intel_atomic_state *state,
+   struct intel_crtc *intel_crtc, struct intel_c

[Intel-gfx] [PATCH 1/2] drm/i915: Define WD trancoder for i915

[Suraj Kandpal]

Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
Adding i915 register definitions related to WD transcoder

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_display.h  |   6 +
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/i915_reg.h   | 139 ++
 3 files changed, 146 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index fa5371036239..4e9f22954a41 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -120,6 +120,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+   TRANSCODER_WD_0,
+   TRANSCODER_WD_1,
 
I915_MAX_TRANSCODERS
 };
@@ -141,6 +143,10 @@ static inline const char *transcoder_name(enum transcoder 
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+   case TRANSCODER_WD_0:
+   return "WD 0";
+   case TRANSCODER_WD_1:
+   return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..0e94bd430bcb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -79,6 +79,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+   INTEL_OUTPUT_WD = 12,
 };
 
 enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3168d7007e10..273f5c7cbd89 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2052,6 +2052,8 @@
 #define TRANSCODER_EDP_OFFSET 0x6f000
 #define TRANSCODER_DSI0_OFFSET 0x6b000
 #define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET  0x6e000
+#define TRANSCODER_WD1_OFFSET  0x6e800
 
 #define HTOTAL(trans)  _MMIO_TRANS2(trans, _HTOTAL_A)
 #define HBLANK(trans)  _MMIO_TRANS2(trans, _HBLANK_A)
@@ -3824,6 +3826,11 @@
 #define PIPE_DSI0_OFFSET   0x7b000
 #define PIPE_DSI1_OFFSET   0x7b800
 
+/* WD 0 and 1 */
+#define PIPE_WD0_OFFSET0x7e000
+#define PIPE_WD1_OFFSET0x7d000
+
+
 #define PIPECONF(pipe) _MMIO_PIPE2(pipe, _PIPEACONF)
 #define PIPEDSL(pipe)  _MMIO_PIPE2(pipe, _PIPEADSL)
 #define PIPEFRAME(pipe)_MMIO_PIPE2(pipe, _PIPEAFRAMEHIGH)
@@ -4488,6 +4495,10 @@
 #define _PIPEDSI0CONF  0x7b008
 #define _PIPEDSI1CONF  0x7b808
 
+/* WD 0 and 1 */
+#define _PIPEWD0CONF   0x7e008
+#define _PIPEWD1CONF   0x7d008
+
 /* Sprite A control */
 #define _DVSACNTR  0x72180
 #define   DVS_ENABLE   REG_BIT(31)
@@ -5713,6 +5724,7 @@
 #define GEN8_DE_MISC_IER _MMIO(0x4446c)
 #define  GEN8_DE_MISC_GSE  (1 << 27)
 #define  GEN8_DE_EDP_PSR   (1 << 19)
+#define  GEN8_DE_MISC_WD0  (1 << 23)
 
 #define GEN8_PCU_ISR _MMIO(0x444e0)
 #define GEN8_PCU_IMR _MMIO(0x444e4)
@@ -8707,6 +8719,133 @@ enum skl_power_gate {
 #define   DSB_ENABLE   (1 << 31)
 #define   DSB_STATUS   (1 << 0)
 
+#define TGL_ROOT_DEVICE_ID 0x9A00
+#define TGL_ROOT_DEVICE_MASK   0xFF00
+#define TGL_ROOT_DEVICE_SKU_MASK   0xF
+#define TGL_ROOT_DEVICE_SKU_ULX0x2
+#define TGL_ROOT_DEVICE_SKU_ULT0x4
+
+/* Gen12 WD */
+#define _MMIO_WD(tc, wd0, wd1) _MMIO_TRANS((tc) - TRANSCODER_WD_0, \
+   wd0, wd1)
+
+#define WD_TRANS_ENABLE(1 << 31)
+#define WD_TRANS_DISABLE   0
+#define WD_TRANS_ACTIVE(1 << 30)
+
+/* WD transcoder control */
+#define _WD_TRANS_FUNC_CTL_0   0x6e400
+#define _WD_TRANS_FUNC_CTL_1   0x6ec00
+#define WD_TRANS_FUNC_CTL(tc)  _MMIO_WD(tc,\
+   _WD_TRANS_FUNC_CTL_0,\
+   _WD_TRANS_FUNC_CTL_1)
+
+#define TRANS_WD_FUNC_ENABLE   (1 << 31)
+#define WD_TRIGGERED_CAP_MODE_ENABLE   (1 << 30)
+#define START_TRIGGER_FRAME(1 << 29)
+#define STOP_TRIGGER_FRAME (1 << 28)
+#define WD_CTL_POINTER_ETEH(0 << 18)
+#define WD_CTL_POINTER_ETDH(1 << 18)
+#define WD_CTL_POINTER_DTDH(2 << 18)
+#define WD_INPUT_SELECT_MASK   (7 << 12)
+#define WD_INPUT_PIPE_A(0 << 12)
+#define WD_INPUT_PIPE_B(5 << 12)
+#define WD_INPUT_PIPE_C(6 << 12)
+#define WD_INPUT_PIPE_D(7 << 12)
+
+#define WD_PIX_FMT_MASK   

[Intel-gfx] [PATCH 0/2] Enabling Pipewriteback

[Suraj Kandpal]

A patch series was floated in the drm mailing list which aimed to change
the drm_connector and drm_encoder fields to pointer in the
drm_connector_writeback structure, this received a huge pushback from
the community but since i915 expects each connector present in the
drm_device list to be a intel_connector but drm_writeback framework
makes us have a connector which cannot be embedded in an intel_connector
structure.
[1] 
https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/
[2] 
https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/
Since no one had an issue with encoder field being changed into a
pointer it was decided to break the connector and encoder pointer
changes into two different series.The encoder field changes is
currently being worked upon by Abhinav Kumar and the changes have been
merged.
[3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565
Going forward we use a drm_connector which is not embedded in
intel_connector. 
We also create a intel_encoder to avoid changes to many
iterators but no intel_connector. We also changed all iterators that
go through connectors and add a check to only cast connectors which are
not writeback connectors.

Suraj Kandpal (2):
  drm/i915: Define WD trancoder for i915
  drm/i915: Enabling WD Transcoder

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_crtc.c |   3 +
 .../drm/i915/display/intel_crtc_state_dump.c  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  63 +-
 drivers/gpu/drm/i915/display/intel_display.h  |  25 +-
 .../drm/i915/display/intel_display_debugfs.c  |  14 +-
 .../drm/i915/display/intel_display_types.h|  37 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   6 +
 .../drm/i915/display/intel_modeset_setup.c|  67 +-
 .../drm/i915/display/intel_modeset_verify.c   |  18 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 .../gpu/drm/i915/display/intel_wb_connector.h |  20 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 726 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  76 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 drivers/gpu/drm/i915/i915_reg.h   | 139 
 19 files changed, 1190 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

-- 
2.37.0

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Remove shared locking on freeing objects (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Remove shared locking on freeing objects (rev2)
URL   : https://patchwork.freedesktop.org/series/106720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11962 -> Patchwork_106720v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 41)
--

  Additional (2): fi-icl-u2 bat-dg1-5 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@fb...@nullptr.html

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

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

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][4] ([i915#4083])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#1155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#4785])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][10] ([i915#4494] / [i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][11] -> [DMESG-FAIL][12] ([i915#4494] / 
[i915#4957])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11962/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][13] ([i915#6011])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([i915#5903])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#4212]) +7 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([i915#4215])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_busy@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#1845] / [i915#4303])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@kms_b...@basic.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([fdo#111827]) +7 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106720v2/bat-dg1-5/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Remove shared locking on freeing objects (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Remove shared locking on freeing objects (rev2)
URL   : https://patchwork.freedesktop.org/series/106720/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

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

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Add Wa_1509727124 (rev2)
URL   : https://patchwork.freedesktop.org/series/106822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11961_full -> Patchwork_106822v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_pm_rps@fence-order:
- {shard-rkl}:[PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-rkl-5/igt@i915_pm_...@fence-order.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-rkl-6/igt@i915_pm_...@fence-order.html

  
New tests
-

  New tests have been introduced between CI_DRM_11961_full and 
Patchwork_106822v2_full:

### New IGT tests (4) ###

  * igt@kms_cursor_crc@cursor-dpms@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.88] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.75] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.74] s

  * igt@kms_cursor_crc@cursor-dpms@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.74] s

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_endless@dispatch@vcs0:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#3778])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-tglb6/igt@gem_exec_endless@dispa...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-tglb1/igt@gem_exec_endless@dispa...@vcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-glk3/igt@gem_exec_f...@basic-deadline.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-glk5/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-tglb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842]) +4 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-glk3/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_lmem_swapping@heavy-multi:
- shard-glk:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-glk8/igt@gem_lmem_swapp...@heavy-multi.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-kbl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-kbl1/igt@gem_lmem_swapp...@heavy-verify-random.html

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

  * igt@gen9_exec_parse@allowed-all:
- shard-skl:  [PASS][16] -> [DMESG-WARN][17] ([i915#5566] / 
[i915#716])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-skl5/igt@gen9_exec_pa...@allowed-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106822v2/shard-skl10/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11961/shard-apl8/igt@i915_susp...@debugfs-reader.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add support for DC5 state (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dg2: Add support for DC5 state (rev3)
URL   : https://patchwork.freedesktop.org/series/106816/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11962 -> Patchwork_106816v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 41)
--

  Additional (3): fi-kbl-soraka bat-jsl-3 bat-dg1-5 
  Missing(1): bat-rpls-1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gem_contexts:
- {bat-dg2-8}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- bat-dg1-5:  NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@fb...@nullptr.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

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

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

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][6] ([i915#4083])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@gem_m...@basic.html

  * igt@gem_tiled_blits@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@gem_tiled_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_module_load@load:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][9] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/fi-kbl-soraka/igt@i915_module_l...@load.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#1155])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

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

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

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

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][15] ([i915#6011])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([i915#4212]) +7 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#4215])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_busy@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#1845] / [i915#4303])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106816v3/bat-dg1-5/igt@kms_b...@basic.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([

Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness

[Tvrtko Ursulin]

On 01/08/2022 20:02, Umesh Nerlige Ramappa wrote:

On Wed, Jul 27, 2022 at 09:48:18AM +0100, Tvrtko Ursulin wrote:


On 27/07/2022 07:01, Umesh Nerlige Ramappa wrote:

On Fri, Jun 17, 2022 at 09:00:06AM +0100, Tvrtko Ursulin wrote:


On 16/06/2022 23:13, Nerlige Ramappa, Umesh wrote:

From: John Harrison 

GuC provides engine_id and last_switch_in ticks for an active 
context in
the pphwsp. The context image provides a 32 bit total ticks which 
is the

accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information is used to calculate the context busyness as follows:

If the engine_id is valid, then busyness is the sum of accumulated 
total
ticks and active ticks. Active ticks is calculated with current gt 
time

as reference.

If engine_id is invalid, busyness is equal to accumulated total ticks.

Since KMD (CPU) retrieves busyness data from 2 sources - GPU and 
GuC, a

potential race was highlighted in an earlier review that can lead to
double accounting of busyness. While the solution to this is a wip,
busyness is still usable for platforms running GuC submission.

v2: (Tvrtko)
- Use COPS_RUNTIME_ACTIVE_TOTAL
- Add code comment for the race
- Undo local variables initializations

v3:
- Add support for virtual engines based on
  https://patchwork.freedesktop.org/series/105227/

Signed-off-by: John Harrison 
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 12 +++-
 drivers/gpu/drm/i915/gt/intel_context.h   |  6 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  6 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  5 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 65 
++-

 drivers/gpu/drm/i915/i915_drm_client.c    |  6 +-
 6 files changed, 89 insertions(+), 11 deletions(-)

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

index 4070cb5711d8..4a84146710e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct 
intel_context *parent,

 child->parallel.parent = parent;
 }
-u64 intel_context_get_total_runtime_ns(const struct intel_context 
*ce)

+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
 {
 u64 total, active;
+    if (ce->ops->update_stats)
+    ce->ops->update_stats(ce);
+
 total = ce->stats.runtime.total;
 if (ce->ops->flags & COPS_RUNTIME_CYCLES)
 total *= ce->engine->gt->clock_period_ns;
 active = READ_ONCE(ce->stats.active);
-    if (active)
+    /*
+ * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the 
backend
+ * already provides the total active time of the context, so 
skip this

+ * calculation when this flag is set.
+ */
+    if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
 active = intel_context_clock() - active;
 return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h

index b7d3214d2cdd..5fc7c19ab29b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -56,7 +56,7 @@ static inline bool intel_context_is_parent(struct 
intel_context *ce)

 return !!ce->parallel.number_children;
 }
-static inline bool intel_context_is_pinned(struct intel_context *ce);
+static inline bool intel_context_is_pinned(const struct 
intel_context *ce);

 static inline struct intel_context *
 intel_context_to_parent(struct intel_context *ce)
@@ -116,7 +116,7 @@ static inline int 
intel_context_lock_pinned(struct intel_context *ce)
  * Returns: true if the context is currently pinned for use by the 
GPU.

  */
 static inline bool
-intel_context_is_pinned(struct intel_context *ce)
+intel_context_is_pinned(const struct intel_context *ce)
 {
 return atomic_read(&ce->pin_count);
 }
@@ -351,7 +351,7 @@ intel_context_clear_nopreempt(struct 
intel_context *ce)

 clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
 }
-u64 intel_context_get_total_runtime_ns(const struct intel_context 
*ce);

+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
 u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
 static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h

index 09f82545789f..797bb4242c18 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
 #define COPS_RUNTIME_CYCLES_BIT 1
 #define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
 int (*alloc)(struct intel_context *ce);
 void (*ban)(struct intel_context *ce, struct i915_request *rq);
@@ -55,6 +58,8 @@ struct intel_context_ops {
 void (*sched_disable)(struct intel_context *ce);
+    void

Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/guc: Define CTB based TLB invalidation routines

[Mauro Carvalho Chehab]

On Thu, 14 Jul 2022 16:06:28 +0200
Michal Wajdeczko  wrote:

> On 14.07.2022 14:06, Mauro Carvalho Chehab wrote:
> > From: Prathap Kumar Valsan 
> > 
> > Add routines to interface with GuC firmware for TLB invalidation.
> > 
> > Signed-off-by: Prathap Kumar Valsan 
> > Cc: Bruce Chang 
> > Cc: Michal Wajdeczko 
> > Cc: Matthew Brost 
> > Cc: Chris Wilson 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> > To avoid mailbombing on a large number of people, only mailing lists were 
> > C/C on the cover.
> > See [PATCH v2 00/21] at: 
> > https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
> > 
> >  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 35 +++
> >  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 90 ++
> >  drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 -
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  6 ++
> >  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
> >  6 files changed, 253 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > index 4ef9990ed7f8..2e39d8df4c82 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > @@ -134,6 +134,10 @@ enum intel_guc_action {
> > INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
> > INTEL_GUC_ACTION_CLIENT_SOFT_RESET = 0x5507,
> > INTEL_GUC_ACTION_SET_ENG_UTIL_BUFF = 0x550A,
> > +   INTEL_GUC_ACTION_NOTIFY_MEMORY_CAT_ERROR = 0x6000,  
> 
> should this be part of this patch ?

No, I'll drop...
> 
> > +   INTEL_GUC_ACTION_PAGE_FAULT_NOTIFICATION = 0x6001,

... and also drop this one.

> > +   INTEL_GUC_ACTION_TLB_INVALIDATION = 0x7000,
> > +   INTEL_GUC_ACTION_TLB_INVALIDATION_DONE = 0x7001,  
> 
> can we document layout of these actions ?

Where should we document it? At intel_guc_invalidate_tlb_guc()
function & friends, or are you thinking on something else, at this
header file?

> 
> > INTEL_GUC_ACTION_STATE_CAPTURE_NOTIFICATION = 0x8002,
> > INTEL_GUC_ACTION_NOTIFY_FLUSH_LOG_BUFFER_TO_FILE = 0x8003,
> > INTEL_GUC_ACTION_NOTIFY_CRASH_DUMP_POSTED = 0x8004,
> > @@ -177,4 +181,35 @@ enum intel_guc_state_capture_event_status {
> >  
> >  #define INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_MASK  0x00FF
> >  
> > +#define INTEL_GUC_TLB_INVAL_TYPE_SHIFT 0
> > +#define INTEL_GUC_TLB_INVAL_MODE_SHIFT 8  
> 
> can we stop using SHIFT-based definitions and start using MASK-based
> instead ? then we will be able to use FIELD_PREP/GET like we do for i915_reg

Ok.

> 
> > +/* Flush PPC or SMRO caches along with TLB invalidation request */
> > +#define INTEL_GUC_TLB_INVAL_FLUSH_CACHE (1 << 31)
> > +
> > +enum intel_guc_tlb_invalidation_type {
> > +   INTEL_GUC_TLB_INVAL_GUC = 0x3,
> > +};
> > +
> > +/*
> > + * 0: Heavy mode of Invalidation:
> > + * The pipeline of the engine(s) for which the invalidation is targeted to 
> > is
> > + * blocked, and all the in-flight transactions are guaranteed to be 
> > Globally
> > + * Observed before completing the TLB invalidation
> > + * 1: Lite mode of Invalidation:
> > + * TLBs of the targeted engine(s) are immediately invalidated.
> > + * In-flight transactions are NOT guaranteed to be Globally Observed before
> > + * completing TLB invalidation.
> > + * Light Invalidation Mode is to be used only when
> > + * it can be guaranteed (by SW) that the address translations remain 
> > invariant
> > + * for the in-flight transactions across the TLB invalidation. In other 
> > words,
> > + * this mode can be used when the TLB invalidation is intended to clear 
> > out the
> > + * stale cached translations that are no longer in use. Light Invalidation 
> > Mode
> > + * is much faster than the Heavy Invalidation Mode, as it does not wait 
> > for the
> > + * in-flight transactions to be GOd.
> > + */  
> 
> either drop this comment or squash with patch 10/21 to fix it

Ok.

> 
> > +enum intel_guc_tlb_inval_mode {
> > +   INTEL_GUC_TLB_INVAL_MODE_HEAVY = 0x0,
> > +   INTEL_GUC_TLB_INVAL_MODE_LITE = 0x1,
> > +};
> > +
> >  #endif /* _ABI_GUC_ACTIONS_ABI_H */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index 2706a8c65090..5c59f9b144a3 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -855,6 +855,96 @@ int intel_guc_self_cfg64(struct intel_guc *guc, u16 
> > key, u64 value)
> > return __guc_self_cfg(guc, key, 2, value);
> >  }
> >  
> > +static int guc_send_invalidate_tlb(struct intel_guc *guc, u32 *action, u32 
> > size)  
> 
> nit: maybe since MMIO TLB has moved to dedicated file, we can do the
> same with GUC TLB code like "intel_guc_tlb.c" ?

I'll add a patch at the end of this series moving the code.

> > +{
> > +   struct intel_guc_tlb_wait _wq, *wq = &_wq;
> > +   DEFIN