date:20220614

[Intel-gfx] [PATCH 2/2] drm/i915: Add lmem_bar_size modparam

2022-06-14 Thread priyanka . dandamudi

From: Priyanka Dandamudi 

lmem_bar_size is used to resize lmem bar.
It sets to only one of the supported sizes.
Setting this param will be in MB unit.

Cc: Matthew Auld 
Signed-off-by: Priyanka Dandamudi 
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |  3 +++
 drivers/gpu/drm/i915/i915_driver.c  | 25 -
 drivers/gpu/drm/i915/i915_params.c  |  2 ++
 drivers/gpu/drm/i915/i915_params.h  |  1 +
 4 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 119e53f5d9b1..d73d8b2adfa2 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -132,6 +132,9 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
  mul_u32_u32(i915->params.lmem_size, SZ_1M));
}
 
+   if (i915->params.lmem_bar_size > 0)
+   lmem_size = pci_resource_len(pdev, 2);
+
io_start = pci_resource_start(pdev, 2);
io_size = min(pci_resource_len(pdev, 2), lmem_size);
if (!io_size)
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 8d33a6a31675..2f5d7a1f1a7b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -371,7 +371,30 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915)
u32 pci_cmd;
int i;
 
-   if (!rebar_size)
+   if (i915->params.lmem_bar_size > 0) {
+   u32 lmem_bar_size;
+   u32 set_bit;
+   u32 rebar;
+   u32 msb;
+   int k;
+
+   lmem_bar_size = i915->params.lmem_bar_size;
+   rebar = pci_rebar_get_possible_sizes(pdev, LMEM_BAR_NUM);
+   msb = __fls(rebar);
+
+   for (k = msb; k >= 0; k--) {
+   set_bit = (1 << k);
+
+   if (set_bit & rebar)
+   if (set_bit == lmem_bar_size) {
+   rebar_size = 1ULL << 
(__fls(lmem_bar_size) + BAR_SIZE_SHIFT);
+
+   if (rebar_size == 
pci_resource_len(pdev, LMEM_BAR_NUM))
+   return;
+   break;
+   }
+   }
+   } else if (!rebar_size)
return;
 
/* Find out if root bus contains 64bit memory addressing */
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 701fbc98afa0..6fc475a5db61 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -204,6 +204,8 @@ i915_param_named_unsafe(request_timeout_ms, uint, 0600,
 
 i915_param_named_unsafe(lmem_size, uint, 0400,
"Set the lmem size(in MiB) for each region. (default: 
0, all memory)");
+i915_param_named_unsafe(lmem_bar_size, uint, 0400,
+   "Set the lmem bar size(in MiB).");
 
 static __always_inline void _print_param(struct drm_printer *p,
 const char *name,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index b5e7ea45d191..2733cb6cfe09 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -74,6 +74,7 @@ struct drm_printer;
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
param(unsigned int, request_timeout_ms, 
CONFIG_DRM_I915_REQUEST_TIMEOUT, CONFIG_DRM_I915_REQUEST_TIMEOUT ? 0600 : 0) \
param(unsigned int, lmem_size, 0, 0400) \
+   param(unsigned int, lmem_bar_size, 0, 0400) \
/* leave bools at the end to not create holes */ \
param(bool, enable_hangcheck, true, 0600) \
param(bool, load_detect_test, false, 0600) \
-- 
2.27.0

[Intel-gfx] [PATCH 1/2] drm/i915: Add support for LMEM PCIe resizable bar

2022-06-14 Thread priyanka . dandamudi

From: Akeem G Abodunrin 

This patch adds support for the local memory PICe resizable bar, so that
local memory can be resized to the maximum size supported by the device,
and mapped correctly to the PCIe memory bar. It is usual that GPU
devices expose only 256MB BARs primarily to be compatible with 32-bit
systems. So, those devices cannot claim larger memory BAR windows size due
to the system BIOS limitation. With this change, it would be possible to
reprogram the windows of the bridge directly above the requesting device
on the same BAR type.

Signed-off-by: Akeem G Abodunrin 
Signed-off-by: Michał Winiarski 
Cc: Stuart Summers 
Cc: Michael J Ruhl 
Cc: Prathap Kumar Valsan 
Signed-off-by: Priyanka Dandamudi 
---
 drivers/gpu/drm/i915/i915_driver.c | 103 +
 1 file changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index b47746152d97..8d33a6a31675 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -303,6 +303,106 @@ static void sanitize_gpu(struct drm_i915_private *i915)
__intel_gt_reset(to_gt(i915), ALL_ENGINES);
 }
 
+static void __release_bars(struct pci_dev *pdev)
+{
+   int resno;
+
+   for (resno = PCI_STD_RESOURCES; resno < PCI_STD_RESOURCE_END; resno++) {
+   if (pci_resource_len(pdev, resno))
+   pci_release_resource(pdev, resno);
+   }
+}
+
+static void
+__resize_bar(struct drm_i915_private *i915, int resno, resource_size_t size)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   int bar_size = pci_rebar_bytes_to_size(size);
+   int ret;
+
+   __release_bars(pdev);
+
+   ret = pci_resize_resource(pdev, resno, bar_size);
+   if (ret) {
+   drm_info(>drm, "Failed to resize BAR%d to %dM (%pe)\n",
+resno, 1 << bar_size, ERR_PTR(ret));
+   return;
+   }
+
+   drm_info(>drm, "BAR%d resized to %dM\n", resno, 1 << bar_size);
+}
+
+/* BAR size starts from 1MB - 2^20 */
+#define BAR_SIZE_SHIFT 20
+static resource_size_t
+__lmem_rebar_size(struct drm_i915_private *i915, int resno)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   u32 rebar = pci_rebar_get_possible_sizes(pdev, resno);
+   resource_size_t size;
+
+   if (!rebar)
+   return 0;
+
+   size = 1ULL << (__fls(rebar) + BAR_SIZE_SHIFT);
+
+   if (size <= pci_resource_len(pdev, resno))
+   return 0;
+
+   return size;
+}
+
+/**
+ * i915_resize_lmem_bar - resize local memory BAR
+ * @i915: device private
+ *
+ * This function will attempt to resize LMEM bar to make all memory accessible.
+ * Whether it will be successful depends on both device and platform
+ * capabilities. Any errors are non-critical, even if resize fails, we go back
+ * to the previous configuration.
+ */
+#define LMEM_BAR_NUM 2
+static void i915_resize_lmem_bar(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   struct pci_bus *root = pdev->bus;
+   struct resource *root_res;
+   resource_size_t rebar_size = __lmem_rebar_size(i915, LMEM_BAR_NUM);
+   u32 pci_cmd;
+   int i;
+
+   if (!rebar_size)
+   return;
+
+   /* Find out if root bus contains 64bit memory addressing */
+   while (root->parent)
+   root = root->parent;
+
+   pci_bus_for_each_resource(root, root_res, i) {
+   if (root_res &&
+   root_res->flags & (IORESOURCE_MEM | 
IORESOURCE_MEM_64) &&
+   root_res->start > 0x1ull)
+   break;
+   }
+
+   /* pci_resize_resource will fail anyways */
+   if (!root_res) {
+   drm_info(>drm,
+   "Can't resize LMEM BAR - platform support is 
missing\n");
+   return;
+   }
+
+   /* First disable PCI memory decoding references */
+   pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
+   pci_write_config_dword(pdev, PCI_COMMAND,
+  pci_cmd & ~PCI_COMMAND_MEMORY);
+
+   __resize_bar(i915, LMEM_BAR_NUM, rebar_size);
+
+   pci_assign_unassigned_bus_resources(pdev->bus);
+   pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+}
+
 /**
  * i915_driver_early_probe - setup state not requiring device access
  * @dev_priv: device private
@@ -836,6 +936,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
disable_rpm_wakeref_asserts(>runtime_pm);
 
+   if (HAS_LMEM(i915))
+   i915_resize_lmem_bar(i915);
+
intel_vgpu_detect(i915);
 
ret = intel_gt_probe_all(i915);
-- 
2.27.0

[Intel-gfx] [PATCH 0/2] Add support for LMEM PCIe resizable bar

2022-06-14 Thread priyanka . dandamudi

From: Priyanka Dandamudi 

Added support to resize the bar to maximum supported,
only when bar is not set to maximum by default.
Also, added new modparam lmem_bar_size which can resize the bar
provided if it is among the supported sizes.

Akeem G Abodunrin (1):
  drm/i915: Add support for LMEM PCIe resizable bar

Priyanka Dandamudi (1):
  drm/i915: Add lmem_bar_size modparam

 drivers/gpu/drm/i915/gt/intel_region_lmem.c |   3 +
 drivers/gpu/drm/i915/i915_driver.c  | 126 
 drivers/gpu/drm/i915/i915_params.c  |   2 +
 drivers/gpu/drm/i915/i915_params.h  |   1 +
 4 files changed, 132 insertions(+)

-- 
2.27.0

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: split out hdcp registers to a separate file

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/hdcp: split out hdcp registers to a separate file
URL   : https://patchwork.freedesktop.org/series/105119/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757_full -> Patchwork_105119v1_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_105119v1_full:

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- {shard-dg1}:NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/shard-dg1-16/igt@kms_cd...@mode-transition-all-outputs.html
- {shard-tglu}:   NOTRUN -> [SKIP][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/shard-tglu-4/igt@kms_cd...@mode-transition-all-outputs.html

  * {igt@kms_plane_lowres@tiling-none@pipe-a-edp-1}:
- {shard-rkl}:NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/shard-rkl-6/igt@kms_plane_lowres@tiling-n...@pipe-a-edp-1.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/display: Add smem fallback allocation for dpt (rev3)

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Add smem fallback 
allocation for dpt (rev3)
URL   : https://patchwork.freedesktop.org/series/104983/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11757_full -> Patchwork_104983v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload:
- shard-kbl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/shard-kbl4/igt@i915_module_l...@reload.html

  
 Suppressed 

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

  * {igt@api_intel_bb@crc32}:
- {shard-rkl}:NOTRUN -> [SKIP][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/shard-rkl-1/igt@api_intel...@crc32.html

  * igt@gem_eio@kms:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/shard-dg1-18/igt@gem_...@kms.html

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- {shard-dg1}:NOTRUN -> [SKIP][4] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/shard-dg1-17/igt@kms_cd...@mode-transition-all-outputs.html
- {shard-tglu}:   NOTRUN -> [SKIP][5] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/shard-tglu-2/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Clean up drm_crtc.h (rev5)

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm: Clean up drm_crtc.h (rev5)
URL   : https://patchwork.freedesktop.org/series/105073/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757_full -> Patchwork_105073v5_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_105073v5_full:

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- {shard-dg1}:NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/shard-dg1-16/igt@kms_cd...@mode-transition-all-outputs.html
- {shard-tglu}:   NOTRUN -> [SKIP][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/shard-tglu-3/igt@kms_cd...@mode-transition-all-outputs.html
- {shard-rkl}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/shard-rkl-1/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/dp/mst: Read the extended DPCD capabilities during system resume
URL   : https://patchwork.freedesktop.org/series/105102/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11756_full -> Patchwork_105102v1_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-snb7/igt@gem_...@reset-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-snb2/igt@gem_...@reset-stress.html

  
New tests
-

  New tests have been introduced between CI_DRM_11756_full and 
Patchwork_105102v1_full:

### New IGT tests (5) ###

  * igt@kms_atomic_interruptible@legacy-setmode@hdmi-a-3-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [6.14] s

  * igt@kms_plane_lowres@tiling-none@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [8.02] s

  * igt@kms_plane_lowres@tiling-none@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.91] s

  * igt@kms_plane_lowres@tiling-none@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.93] s

  * igt@kms_plane_lowres@tiling-none@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.94] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-1us:
- shard-apl:  [PASS][3] -> [TIMEOUT][4] ([i915#3063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-apl2/igt@gem_...@in-flight-contexts-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-apl2/igt@gem_...@in-flight-contexts-1us.html

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

  * igt@gem_exec_capture@pi@vcs0:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#3371])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-iclb7/igt@gem_exec_capture@p...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-iclb1/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_endless@dispatch@bcs0:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#3778])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-tglb2/igt@gem_exec_endless@dispa...@bcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-tglb1/igt@gem_exec_endless@dispa...@bcs0.html

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

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-iclb3/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-iclb6/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar 
issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109283])
   [18]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: add payload receiving code

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsi: add payload receiving code
URL   : https://patchwork.freedesktop.org/series/105096/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11756_full -> Patchwork_105096v1_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_softpin@safe-alignment:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/shard-apl6/igt@gem_soft...@safe-alignment.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/shard-apl1/igt@gem_soft...@safe-alignment.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Extract, polish, and document multicast handling

2022-06-14 Thread Patchwork

== Series Details ==

Series: i915: Extract, polish, and document multicast handling
URL   : https://patchwork.freedesktop.org/series/105134/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11758 -> Patchwork_105134v1


Summary
---

  **FAILURE**

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

Participating hosts (43 -> 43)
--

  Additional (2): fi-hsw-4770 bat-dg2-9 
  Missing(2): bat-atsm-1 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-hsw-4770:NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-hsw-4770/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][2] ([i915#4528])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html

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

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-n3050:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-bsw-n3050/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-n3050:   NOTRUN -> [SKIP][8] ([fdo#109271])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-bsw-n3050/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][9] ([i915#4312] / [i915#5594])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [DMESG-WARN][10] ([i915#3576]) -> [PASS][11] +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11758/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

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

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [INCOMPLETE][14] ([i915#4418]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11758/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][16] ([i915#4528]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11758/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
- fi-blb-e6850:   [DMESG-FAIL][18] ([i915#4528]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11758/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105134v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +1 
similar issue
   [20]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for remove shmem backend and region and unify them with TTM

2022-06-14 Thread Patchwork

== Series Details ==

Series: remove shmem backend and region and unify them with TTM
URL   : https://patchwork.freedesktop.org/series/105087/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105087v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_tiling@flip-change-tiling@dp-1-pipe-a-yf-ccs-to-y-ccs:
- shard-kbl:  [PASS][1] -> [FAIL][2] +36 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-kbl7/igt@kms_flip_tiling@flip-change-til...@dp-1-pipe-a-yf-ccs-to-y-ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-kbl6/igt@kms_flip_tiling@flip-change-til...@dp-1-pipe-a-yf-ccs-to-y-ccs.html

  
 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-iclb7/igt@kms_cd...@mode-transition-all-outputs.html

  

### Piglit changes ###

 Possible regressions 

  * spec@!opengl 1.1@max-texture-size:
- pig-kbl-iris:   NOTRUN -> [CRASH][4]
   [4]: None

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], 
[PASS][15], [PASS][16], [FAIL][17], [PASS][18], [PASS][19], [PASS][20], 
[PASS][21], [PASS][22], [PASS][23]) ([i915#5032]) -> ([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], [PASS][43], 
[PASS][44])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl10/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl10/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl9/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl7/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl6/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105087v1/shard-skl6/boot.html
   [32]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Extract, polish, and document multicast handling

2022-06-14 Thread Patchwork

== Series Details ==

Series: i915: Extract, polish, and document multicast handling
URL   : https://patchwork.freedesktop.org/series/105134/
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 i915/pmu: Wire GuC backend to per-client busyness

2022-06-14 Thread Patchwork

== Series Details ==

Series: i915/pmu: Wire GuC backend to per-client busyness
URL   : https://patchwork.freedesktop.org/series/105085/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105085v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@device_reset@unbind-reset-rebind:
- {shard-dg1}:[PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-dg1-16/igt@device_re...@unbind-reset-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-dg1-15/igt@device_re...@unbind-reset-rebind.html

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-iclb5/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([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], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl10/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-skl10/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl9/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl9/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl7/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl7/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl6/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl4/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl4/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl4/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v1/shard-skl3/boot.html
   [37]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement w/a 22010492432 for adl-s

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915: Implement w/a 22010492432 for adl-s
URL   : https://patchwork.freedesktop.org/series/105074/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105074v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * 
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-c-edp-1:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-tglb6/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-c-edp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105074v1/shard-tglb8/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-...@pipe-c-edp-1.html

  
 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105074v1/shard-iclb8/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

[Intel-gfx] [PATCH v2 0/2] i915: Extract, polish, and document multicast handling

2022-06-14 Thread Matt Roper

Multicast/replicated (MCR) registers on Intel hardware are a purely
GT-specific concept.  Rather than leaving MCR register handling spread
across several places throughout the driver (intel_uncore.c, intel_gt.c,
etc.) with confusing combinations of handler functions living in
different namespaces, let's consolidate it all into a single place
(intel_gt_mcr.c) and provide a more consistent and clearly-documented
interface for the rest of the driver to access such registers:

 * intel_gt_mcr_read -- unicast read from specific instance
 * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
   instance
 * intel_gt_mcr_unicast_write -- unicast write to specific instance
 * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances


v2:
 - Reference the new kerneldoc from i915.rst.  (Jani)
 - Tweak the wording of the documentation for a couple functions to
   clarify the difference between "_fw" and non-"_fw" forms.

Matt Roper (2):
  drm/i915/gt: Move multicast register handling to a dedicated file
  drm/i915/gt: Cleanup interface for MCR operations

 Documentation/gpu/i915.rst  |  12 +
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |   3 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  36 +-
 drivers/gpu/drm/i915/gt/intel_gt.c  | 297 +---
 drivers/gpu/drm/i915/gt/intel_gt.h  |  15 -
 drivers/gpu/drm/i915/gt/intel_gt_debugfs.c  |   3 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 497 
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  34 ++
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |   5 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c |   9 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h |   2 -
 drivers/gpu/drm/i915/intel_uncore.c | 112 -
 drivers/gpu/drm/i915/intel_uncore.h |   8 -
 15 files changed, 577 insertions(+), 460 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.h

-- 
2.35.3

[Intel-gfx] [PATCH v2 2/2] drm/i915/gt: Cleanup interface for MCR operations

2022-06-14 Thread Matt Roper

Let's replace the assortment of intel_gt_* and intel_uncore_* functions
that operate on MCR registers with a cleaner set of interfaces:

  * intel_gt_mcr_read -- unicast read from specific instance
  * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
instance
  * intel_gt_mcr_unicast_write -- unicast write to specific instance
  * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances

We'll also replace the historic "slice" and "subslice" terminology with
"group" and "instance" to match the documentation for more recent
platforms; these days MCR steering applies to more types of replication
than just slice/subslice.

v2:
 - Reference the new kerneldoc from i915.rst.  (Jani)
 - Tweak the wording of the documentation for a couple functions to
   clarify the difference between "_fw" and non-"_fw" forms.

Signed-off-by: Matt Roper 
Acked-by: Jani Nikula 
---
 Documentation/gpu/i915.rst  |  12 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |   2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  33 ++-
 drivers/gpu/drm/i915/gt/intel_gt_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 239 
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  43 ++--
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c |   8 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |   2 +-
 9 files changed, 200 insertions(+), 145 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 54060cd6c419..4e59db1cfb00 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -246,6 +246,18 @@ Display State Buffer
 .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
:internal:
 
+GT Programming
+==
+
+Multicast/Replicated (MCR) Registers
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+   :doc: GT Multicast/Replicated (MCR) Register Support
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+   :internal:
+
 Memory Management and Command Submission
 
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index da30503d3ca2..fa54823d1219 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -835,7 +835,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
} else {
resource_size_t lmem_range;
 
-   lmem_range = intel_gt_read_register(>gt0, 
XEHPSDV_TILE0_ADDR_RANGE) & 0x;
+   lmem_range = intel_gt_mcr_read_any(>gt0, 
XEHPSDV_TILE0_ADDR_RANGE) & 0x;
lmem_size = lmem_range >> XEHPSDV_TILE_LMEM_RANGE_SHIFT;
lmem_size *= SZ_1G;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 244af1bdb7db..136cc44c3deb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1428,14 +1428,6 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs 
*engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
 }
 
-static u32
-read_subslice_reg(const struct intel_engine_cs *engine,
- int slice, int subslice, i915_reg_t reg)
-{
-   return intel_uncore_read_with_mcr_steering(engine->uncore, reg,
-  slice, subslice);
-}
-
 /* NB: please notice the memset */
 void intel_engine_get_instdone(const struct intel_engine_cs *engine,
   struct intel_instdone *instdone)
@@ -1469,28 +1461,33 @@ void intel_engine_get_instdone(const struct 
intel_engine_cs *engine,
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
for_each_instdone_gslice_dss_xehp(i915, sseu, iter, 
slice, subslice) {
instdone->sampler[slice][subslice] =
-   read_subslice_reg(engine, slice, 
subslice,
- 
GEN7_SAMPLER_INSTDONE);
+   intel_gt_mcr_read(engine->gt,
+ GEN7_SAMPLER_INSTDONE,
+ slice, subslice);
instdone->row[slice][subslice] =
-   read_subslice_reg(engine, slice, 
subslice,
- GEN7_ROW_INSTDONE);
+   intel_gt_mcr_read(engine->gt,
+ GEN7_ROW_INSTDONE,
+ slice, subslice);
}
} else {
for_each_instdone_slice_subslice(i915, sseu, slice,

[Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Move multicast register handling to a dedicated file

2022-06-14 Thread Matt Roper

Handling of multicast/replicated registers is spread across intel_gt.c
and intel_uncore.c today.  As multicast handling and the related
steering logic gets more complicated with the addition of new platforms
and new rules it makes sense to centralize it all in one place.

For now the existing functions have been moved to the new .c/.h as-is.
Function renames and updates to operate in a more consistent manner will
be done in subsequent patches.

Signed-off-by: Matt Roper 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_gt.c  | 297 +
 drivers/gpu/drm/i915/gt/intel_gt.h  |  15 -
 drivers/gpu/drm/i915/gt/intel_gt_debugfs.c  |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 448 
 drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  37 ++
 drivers/gpu/drm/i915/gt/intel_region_lmem.c |   1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   2 -
 drivers/gpu/drm/i915/intel_uncore.c | 112 -
 drivers/gpu/drm/i915/intel_uncore.h |   8 -
 14 files changed, 495 insertions(+), 433 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_mcr.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..08f5d0d6e83a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -103,6 +103,7 @@ gt-y += \
gt/intel_gt_debugfs.o \
gt/intel_gt_engines_debugfs.o \
gt/intel_gt_irq.o \
+   gt/intel_gt_mcr.o \
gt/intel_gt_pm.o \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 47b5e0e342ab..da30503d3ca2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -13,6 +13,7 @@
 #include "gem/i915_gem_lmem.h"
 #include "gem/i915_gem_region.h"
 #include "gt/intel_gt.h"
+#include "gt/intel_gt_mcr.h"
 #include "gt/intel_region_lmem.h"
 #include "i915_drv.h"
 #include "i915_gem_stolen.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f0acf8518a51..244af1bdb7db 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -21,8 +21,9 @@
 #include "intel_engine_user.h"
 #include "intel_execlists_submission.h"
 #include "intel_gt.h"
-#include "intel_gt_requests.h"
+#include "intel_gt_mcr.h"
 #include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
 #include "intel_lrc.h"
 #include "intel_lrc_reg.h"
 #include "intel_reset.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f33290358c51..be9877c4b496 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -17,6 +17,7 @@
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_debugfs.h"
 #include "intel_gt_gmch.h"
+#include "intel_gt_mcr.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_regs.h"
 #include "intel_gt_requests.h"
@@ -102,107 +103,13 @@ int intel_gt_assign_ggtt(struct intel_gt *gt)
return gt->ggtt ? 0 : -ENOMEM;
 }
 
-static const char * const intel_steering_types[] = {
-   "L3BANK",
-   "MSLICE",
-   "LNCF",
-   "INSTANCE 0",
-};
-
-static const struct intel_mmio_range icl_l3bank_steering_table[] = {
-   { 0x00B100, 0x00B3FF },
-   {},
-};
-
-static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
-   { 0x004000, 0x004AFF },
-   { 0x00C800, 0x00CFFF },
-   { 0x00DD00, 0x00DDFF },
-   { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
-   {},
-};
-
-static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
-   { 0x00B000, 0x00B0FF },
-   { 0x00D800, 0x00D8FF },
-   {},
-};
-
-static const struct intel_mmio_range dg2_lncf_steering_table[] = {
-   { 0x00B000, 0x00B0FF },
-   { 0x00D880, 0x00D8FF },
-   {},
-};
-
-/*
- * We have several types of MCR registers on PVC where steering to (0,0)
- * will always provide us with a non-terminated value.  We'll stick them
- * all in the same table for simplicity.
- */
-static const struct intel_mmio_range pvc_instance0_steering_table[] = {
-   { 0x004000, 0x004AFF }, /* HALF-BSLICE */
-   { 0x008800, 0x00887F }, /* CC */
-   { 0x008A80, 0x008AFF }, /* TILEPSMI */
-   { 0x00B000, 0x00B0FF }, /* HALF-BSLICE */
-   { 0x00B100, 0x00B3FF }, /* L3BANK */
-   { 0x00C800, 0x00CFFF }, /* HALF-BSLICE */
-   { 0x00D800, 0x00D8FF }, /* HALF-BSLICE */
-   { 0x00DD00, 0x00DDFF }, /* BSLICE */
-   { 0x00E900,

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display: Add smem fallback allocation for dpt (rev2)

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Add smem fallback 
allocation for dpt (rev2)
URL   : https://patchwork.freedesktop.org/series/104983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_104983v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-iclb7/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#5327])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-iclb6/igt@gem_...@block-copy-compressed.html

  * igt@gem_ctx_persistence@smoketest:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-snb5/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#3070])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-iclb7/igt@gem_...@in-flight-contexts-1us.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-iclb4/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-iclb7/igt@gem_exec_balan...@parallel-bb-first.html

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

  * igt@gem_exec_capture@pi@vcs1:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([i915#3371])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-iclb2/igt@gem_exec_capture@p...@vcs1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-iclb4/igt@gem_exec_capture@p...@vcs1.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +3 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html

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

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11755/shard-tglb8/igt@gem_huc_c...@huc-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v2/shard-apl8/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html

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

  * igt@gem_softpin@evict-single-offset:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#4171])
   [21]:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pvc: Add recommended MMIO setting

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/pvc: Add recommended MMIO setting
URL   : https://patchwork.freedesktop.org/series/105063/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105063v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105063v1/shard-iclb7/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Re-add check for low voltage sku for max dp source rate

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Re-add check for low voltage sku for max dp source 
rate
URL   : https://patchwork.freedesktop.org/series/105048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105048v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105048v1/shard-skl5/igt@gem_exec_fair@basic-n...@vcs0.html

  
 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105048v1/shard-iclb2/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: minor cleanups (rev2)

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/bios: minor cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/104988/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_104988v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104988v2/shard-iclb5/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Extract, polish, and document multicast handling

2022-06-14 Thread Patchwork

== Series Details ==

Series: i915: Extract, polish, and document multicast handling
URL   : https://patchwork.freedesktop.org/series/105015/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105015v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105015v1/shard-iclb2/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2

2022-06-14 Thread Ye, Tony




On 6/14/2022 8:30 AM, Ceraolo Spurio, Daniele wrote:



On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:


On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:

On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:

On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:


On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 1:16 AM, Tvrtko Ursulin wrote:


On 10/06/2022 00:19, Daniele Ceraolo Spurio wrote:
On DG2, HuC loading is performed by the GSC, via a PXP 
command. The load
operation itself is relatively simple (just send a message 
to the GSC
with the physical address of the HuC in LMEM), but there are 
timing
changes that requires special attention. In particular, to 
send a PXP
command we need to first export the GSC driver and then wait 
for the
mei-gsc and mei-pxp modules to start, which means that HuC 
load will
complete after i915 load is complete. This means that there 
is a small
window of time after i915 is registered and before HuC is 
loaded
during which userspace could submit and/or checking the HuC 
load status,
although this is quite unlikely to happen (HuC is usually 
loaded before

kernel init/resume completes).
We've consulted with the media team in regards to how to 
handle this and

they've asked us to do the following:

1) Report HuC as loaded in the getparam IOCTL even if load 
is still in
progress. The media driver uses the IOCTL as a way to check 
if HuC is
enabled and then includes a secondary check in the batches 
to get the
actual status, so doing it this way allows userspace to keep 
working

without changes.

2) Stall all userspace VCS submission until HuC is loaded. 
Stalls are
expected to be very rare (if any), due to the fact that HuC 
is usually

loaded before kernel init/resume is completed.


Motivation to add these complications into i915 are not clear 
to me here. I mean there is no HuC on DG2 _yet_ is the 
premise of the series, right? So no backwards compatibility 
concerns. In this case why jump through the hoops and not let 
userspace handle all of this by just leaving the getparam 
return the true status?


The main areas impacted by the fact that we can't guarantee 
that HuC load is complete when i915 starts accepting 
submissions are boot and suspend/resume, with the latter being 
the main problem; GT reset is not a concern because HuC now 
survives it. A suspend/resume can be transparent to userspace 
and therefore the HuC status can temporarily flip from loaded 
to not without userspace knowledge, especially if we start 
going into deeper suspend states and start causing HuC resets 
when we go into runtime suspend. Note that this is different 
from what happens during GT reset for older platforms, because 
in that scenario we guarantee that HuC reload is complete 
before we restart the submission back-end, so userspace 
doesn't notice that the HuC status change. We had an internal 
discussion about this problem with both media and i915 archs 
and the conclusion was that the best option is for i915 to 
stall media submission while HuC (re-)load is in progress.


Resume is potentialy a good reason - I did not pick up on that 
from the cover letter. I read the statement about the unlikely 
and small window where HuC is not loaded during kernel 
init/resume and I guess did not pick up on the resume part.


Waiting for GSC to load HuC from i915 resume is not an option?


GSC is an aux device exported by i915, so AFAIU GSC resume can't 
start until i915 resume completes.


I'll dig into this in the next few days since I want to 
understand how exactly it works. Or someone can help explain.


If in the end conclusion will be that i915 resume indeed cannot 
wait for GSC, then I think auto-blocking of queued up contexts on 
media engines indeed sounds unavoidable. Otherwise, as you 
explained, user experience post resume wouldn't be good.


Even if we could implement a wait, I'm not sure we should. GSC 
resume and HuC reload takes ~300ms in most cases, I don't think we 
want to block within the i915 resume path for that long.


Yeah maybe not. But entertaining the idea that it is technically 
possible to block - we could perhaps add uapi for userspace to mark 
contexts which want HuC access. Then track if there are any such 
contexts with outstanding submissions and only wait in resume if 
there are. If that would end up significantly less code on the i915 
side to maintain is an open.


What would be the end result from users point of view in case where 
it suspended during video playback? The proposed solution from this 
series sees the video stuck after resume. Maybe compositor blocks 
as well since I am not sure how well they handle one window not 
providing new data. Probably depends on the compositor.


And then with a simpler solution definitely the whole resume would 
be delayed by 300ms.


With my ChromeOS hat the

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc/slpc: Add a new SLPC selftest (rev2)

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/guc/slpc: Add a new SLPC selftest (rev2)
URL   : https://patchwork.freedesktop.org/series/105005/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11755_full -> Patchwork_105005v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_cdclk@mode-transition-all-outputs}:
- shard-iclb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105005v2/shard-iclb8/igt@kms_cd...@mode-transition-all-outputs.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-14 Thread Zeng, Oak



Thanks,
Oak

> -Original Message-
> From: dri-devel  On Behalf Of
> Zeng, Oak
> Sent: June 14, 2022 5:13 PM
> To: Vishwanathapura, Niranjana ;
> Landwerlin, Lionel G 
> Cc: Intel GFX ; Wilson, Chris P
> ; Hellstrom, Thomas
> ; Maling list - DRI developers  de...@lists.freedesktop.org>; Vetter, Daniel ;
> Christian König 
> Subject: RE: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design
> document
> 
> 
> 
> Thanks,
> Oak
> 
> > -Original Message-
> > From: Vishwanathapura, Niranjana 
> > Sent: June 14, 2022 1:02 PM
> > To: Landwerlin, Lionel G 
> > Cc: Zeng, Oak ; Intel GFX  > g...@lists.freedesktop.org>; Maling list - DRI developers  > de...@lists.freedesktop.org>; Hellstrom, Thomas
> > ; Wilson, Chris P
> ;
> > Vetter, Daniel ; Christian König
> > 
> > Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design
> > document
> >
> > On Tue, Jun 14, 2022 at 10:04:00AM +0300, Lionel Landwerlin wrote:
> > >On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:
> > >>On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:
> > >>>
> > >>>
> > >>>Regards,
> > >>>Oak
> > >>>
> > -Original Message-
> > From: Intel-gfx  On
> > Behalf Of Niranjana
> > Vishwanathapura
> > Sent: June 10, 2022 1:43 PM
> > To: Landwerlin, Lionel G 
> > Cc: Intel GFX ; Maling list -
> > DRI developers  > de...@lists.freedesktop.org>; Hellstrom, Thomas
> > ;
> > Wilson, Chris P ; Vetter, Daniel
> > ; Christian König
> > 
> > Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND
> > feature design
> > document
> > 
> > On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:
> > >On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
> > >>On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
> > >>>On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
> > On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin
> wrote:
> > >  On 09/06/2022 00:55, Jason Ekstrand wrote:
> > >
> > >    On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
> > >  wrote:
> > >
> > >  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko
> > Ursulin wrote:
> > >  >
> > >  >
> > >  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
> > >  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
> > >Vishwanathapura
> > >  wrote:
> > >  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason
> > >Ekstrand wrote:
> > >   On Fri, Jun 3, 2022 at 6:52 PM Niranjana
> > Vishwanathapura
> > >    wrote:
> > >  
> > >     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel
> > >Landwerlin
> > >  wrote:
> > >     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
> > >     >
> > >     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana
> > >Vishwanathapura
> > >     >  wrote:
> > >     >
> > >     >   On Wed, Jun 01, 2022 at 01:28:36PM
> > -0700, Matthew
> > >  Brost wrote:
> > >     >   >On Wed, Jun 01, 2022 at 05:25:49PM
> > +0300, Lionel
> > >  Landwerlin
> > >     wrote:
> > >     > >> On 17/05/2022 21:32, Niranjana
> Vishwanathapura
> > >  wrote:
> > >     > >> > +VM_BIND/UNBIND ioctl will immediately start
> > >     binding/unbinding
> > >     >   the mapping in an
> > >     > >> > +async worker. The binding and
> > >unbinding will
> > >  work like a
> > >     special
> > >     >   GPU engine.
> > >     > >> > +The binding and unbinding operations are
> > >  serialized and
> > >     will
> > >     >   wait on specified
> > >     > >> > +input fences before the operation
> > >and will signal
> > >  the
> > >     output
> > >     >   fences upon the
> > >     > >> > +completion of the operation. Due to
> > >  serialization,
> > >     completion of
> > >     >   an operation
> > >     > >> > +will also indicate that all
> > >previous operations
> > >  are also
> > >     > complete.
> > >     > >>
> > >     > >> I guess we should avoid saying "will
> > >immediately
> > >  start
> > >     > binding/unbinding" if
> > >     > >> there are fences involved.
> > >     > >>
> > >     > >> And the fact

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()

2022-06-14 Thread Matt Roper

Looks like the logs links finally work (there was probably a big backlog
to upload them after the gitlab downtime).  The module_reload log shows
and ext4 filesystem panic (not graphics-related).  The syncobj_basic
failure is an unexpected incomplete; no graphics errors in the log that
I can see, although logs of periodic non-graphics warnings from
xhci_hcd.


Matt

On Tue, Jun 14, 2022 at 01:21:49PM -0700, Vudum, Lakshminarayana wrote:
> I am unable to load both the failures? Is there any other way to get these 
> failures?
> 
> -Original Message-
> From: Roper, Matthew D 
> Sent: Tuesday, June 14, 2022 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vudum, Lakshminarayana 
> Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS 
> according to HAS_ONE_EU_PER_FUSE_BIT()
> 
> On Tue, Jun 14, 2022 at 07:20:48PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/pvc: Adjust EU per SS according to 
> > HAS_ONE_EU_PER_FUSE_BIT()
> > URL   : https://patchwork.freedesktop.org/series/105010/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_105010v1_full
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_105010v1_full absolutely 
> > need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_105010v1_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_105010v1_full:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@i915_module_load@reload-with-fault-injection:
> > - shard-snb:  [PASS][1] -> [DMESG-WARN][2]
> >[1]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
> >[2]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
> >
> >   * igt@syncobj_basic@bad-create-flags:
> > - shard-skl:  NOTRUN -> [INCOMPLETE][3]
> >[3]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-skl3/igt@syncobj_ba...@bad-create-flags.html
> 
> The failure logs for the two hits above don't seem to have been uploaded
> to the server so I can't see exactly what went wrong.  However this
> patch is modifying xehp_sseu_info_init() which only gets executed on
> Xe_HP-based platforms, so it would not change the behavior of SNB or
> SKL.
> 
> 
> Matt
> 
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_105010v1_full that come from 
> > known issues:
> >
> > ### CI changes ###
> >
> >  Issues hit 
> >
> >   * boot:
> > - shard-apl:  ([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], [FAIL][31], 
> > [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
> > [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
> > [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
> > [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4386])
> >[4]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
> >[5]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
> >[6]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
> >[7]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
> >[8]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
> >[9]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
> >[10]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
> >[11]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
> >[12]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
> >[13]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
> >[14]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
> >[15]: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
> >[16]: 
> >

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-14 Thread Zeng, Oak



Thanks,
Oak

> -Original Message-
> From: Vishwanathapura, Niranjana 
> Sent: June 14, 2022 1:02 PM
> To: Landwerlin, Lionel G 
> Cc: Zeng, Oak ; Intel GFX  g...@lists.freedesktop.org>; Maling list - DRI developers  de...@lists.freedesktop.org>; Hellstrom, Thomas
> ; Wilson, Chris P ;
> Vetter, Daniel ; Christian König
> 
> Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design
> document
> 
> On Tue, Jun 14, 2022 at 10:04:00AM +0300, Lionel Landwerlin wrote:
> >On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:
> >>On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:
> >>>
> >>>
> >>>Regards,
> >>>Oak
> >>>
> -Original Message-
> From: Intel-gfx  On
> Behalf Of Niranjana
> Vishwanathapura
> Sent: June 10, 2022 1:43 PM
> To: Landwerlin, Lionel G 
> Cc: Intel GFX ; Maling list -
> DRI developers  de...@lists.freedesktop.org>; Hellstrom, Thomas
> ;
> Wilson, Chris P ; Vetter, Daniel
> ; Christian König
> 
> Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND
> feature design
> document
> 
> On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:
> >On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
> >>On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
> >>>On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
> On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
> >  On 09/06/2022 00:55, Jason Ekstrand wrote:
> >
> >    On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
> >  wrote:
> >
> >  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko
> Ursulin wrote:
> >  >
> >  >
> >  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
> >  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
> >Vishwanathapura
> >  wrote:
> >  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason
> >Ekstrand wrote:
> >   On Fri, Jun 3, 2022 at 6:52 PM Niranjana
> Vishwanathapura
> >    wrote:
> >  
> >     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel
> >Landwerlin
> >  wrote:
> >     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
> >     >
> >     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana
> >Vishwanathapura
> >     >  wrote:
> >     >
> >     >   On Wed, Jun 01, 2022 at 01:28:36PM
> -0700, Matthew
> >  Brost wrote:
> >     >   >On Wed, Jun 01, 2022 at 05:25:49PM
> +0300, Lionel
> >  Landwerlin
> >     wrote:
> >     > >> On 17/05/2022 21:32, Niranjana Vishwanathapura
> >  wrote:
> >     > >> > +VM_BIND/UNBIND ioctl will immediately start
> >     binding/unbinding
> >     >   the mapping in an
> >     > >> > +async worker. The binding and
> >unbinding will
> >  work like a
> >     special
> >     >   GPU engine.
> >     > >> > +The binding and unbinding operations are
> >  serialized and
> >     will
> >     >   wait on specified
> >     > >> > +input fences before the operation
> >and will signal
> >  the
> >     output
> >     >   fences upon the
> >     > >> > +completion of the operation. Due to
> >  serialization,
> >     completion of
> >     >   an operation
> >     > >> > +will also indicate that all
> >previous operations
> >  are also
> >     > complete.
> >     > >>
> >     > >> I guess we should avoid saying "will
> >immediately
> >  start
> >     > binding/unbinding" if
> >     > >> there are fences involved.
> >     > >>
> >     > >> And the fact that it's happening in an async
> >  worker seem to
> >     imply
> >     >   it's not
> >     > >> immediate.
> >     > >>
> >     >
> >     >   Ok, will fix.
> >     >   This was added because in earlier design
> >binding was
> >  deferred
> >     until
> >     >   next execbuff.
> >     >   But now it is non-deferred (immediate in
> >that sense).
> >  But yah,
> >     this is
> >     >

Re: [Intel-gfx] [PATCH] drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()

2022-06-14 Thread Srivatsa, Anusha




> -Original Message-
> From: Intel-gfx  On Behalf Of Matt
> Roper
> Sent: Friday, June 10, 2022 4:08 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/pvc: Adjust EU per SS according to
> HAS_ONE_EU_PER_FUSE_BIT()
> 
> If we're treating each bit in the EU fuse register as a single EU instead of a
> pair of EUs, then that also cuts the number of potential EUs per subslice in
> half.
> 
> Fixes: 5ac342ef84d7 ("drm/i915/pvc: Add SSEU changes")
> Signed-off-by: Matt Roper 

Reviewed-by: Anusha Srivatsa

> ---
>  drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
> b/drivers/gpu/drm/i915/gt/intel_sseu.c
> index 7ef75f0d9c9e..c6d3050604c8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
> @@ -229,7 +229,7 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
>*/
>   intel_sseu_set_info(sseu, 1,
>   32 * max(num_geometry_regs,
> num_compute_regs),
> - 16);
> + HAS_ONE_EU_PER_FUSE_BIT(gt->i915) ? 8 : 16);
>   sseu->has_xehp_dss = 1;
> 
>   xehp_load_dss_mask(uncore, >geometry_subslice_mask,
> --
> 2.35.3

[Intel-gfx] ✓ Fi.CI.BAT: success for Break VM to rq reference loop

2022-06-14 Thread Patchwork

== Series Details ==

Series: Break VM to rq reference loop
URL   : https://patchwork.freedesktop.org/series/105122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_105122v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (2): fi-rkl-11600 bat-jsl-2 
  Missing(3): fi-ctg-p8600 fi-bdw-samus fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#3576]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][9] ([i915#4528])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][10] -> [DMESG-FAIL][11] ([i915#4494] / 
[i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][12] -> [DMESG-FAIL][13] ([i915#4494] / 
[i915#4957])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_busy@basic@modeset:
- fi-tgl-u2:  [PASS][15] -> [DMESG-WARN][16] ([i915#402])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-tgl-u2/igt@kms_busy@ba...@modeset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-tgl-u2/igt@kms_busy@ba...@modeset.html

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#111827]) +7 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([i915#4103]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][20] ([fdo#109285] / [i915#4098])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][21] ([i915#533])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105122v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  *

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()

2022-06-14 Thread Vudum, Lakshminarayana

I am unable to load both the failures? Is there any other way to get these 
failures?

-Original Message-
From: Roper, Matthew D  
Sent: Tuesday, June 14, 2022 1:07 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS according 
to HAS_ONE_EU_PER_FUSE_BIT()

On Tue, Jun 14, 2022 at 07:20:48PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()
> URL   : https://patchwork.freedesktop.org/series/105010/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_105010v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_105010v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_105010v1_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_105010v1_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_module_load@reload-with-fault-injection:
> - shard-snb:  [PASS][1] -> [DMESG-WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
> 
>   * igt@syncobj_basic@bad-create-flags:
> - shard-skl:  NOTRUN -> [INCOMPLETE][3]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-skl3/igt@syncobj_ba...@bad-create-flags.html

The failure logs for the two hits above don't seem to have been uploaded
to the server so I can't see exactly what went wrong.  However this
patch is modifying xehp_sseu_info_init() which only gets executed on
Xe_HP-based platforms, so it would not change the behavior of SNB or
SKL.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_105010v1_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Issues hit 
> 
>   * boot:
> - shard-apl:  ([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], [FAIL][31], 
> [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
> [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
> [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
> [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4386])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl7/boot.html
>[23]: 
>

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()

2022-06-14 Thread Matt Roper

On Tue, Jun 14, 2022 at 07:20:48PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()
> URL   : https://patchwork.freedesktop.org/series/105010/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_105010v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_105010v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_105010v1_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_105010v1_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_module_load@reload-with-fault-injection:
> - shard-snb:  [PASS][1] -> [DMESG-WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
> 
>   * igt@syncobj_basic@bad-create-flags:
> - shard-skl:  NOTRUN -> [INCOMPLETE][3]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-skl3/igt@syncobj_ba...@bad-create-flags.html

The failure logs for the two hits above don't seem to have been uploaded
to the server so I can't see exactly what went wrong.  However this
patch is modifying xehp_sseu_info_init() which only gets executed on
Xe_HP-based platforms, so it would not change the behavior of SNB or
SKL.


Matt

> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_105010v1_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Issues hit 
> 
>   * boot:
> - shard-apl:  ([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], [FAIL][31], 
> [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], 
> [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], 
> [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
> [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4386])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl2/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl3/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl4/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl6/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl7/boot.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl7/boot.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl7/boot.html
>[25]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl7/boot.html
>[26]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl8/boot.html
>[27]: 
>

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Dixit, Ashutosh

On Tue, 14 Jun 2022 09:28:14 -0700, Dixit, Ashutosh wrote:
> On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>
> > @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct 
> > ct_request *req, u32 *status)
> >  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
> >  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
> >  #define done \
> > -   (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> > +   (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> > READ_ONCE(req->status)) == \
> >  GUC_HXG_ORIGIN_GUC)
> > err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
> > if (err)
> > err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
> >  #undef done
> > +   if (!intel_guc_ct_enabled(ct))
> > +   err = -ECANCELED;
>
> Also, I really don't like intel_guc_ct_enabled() being called in two
> places. Is there a possibility that intel_guc_ct_enabled() can return false
> in the first place (causing the wait to exit) and then return true in the
> second place (so we don't return -ECANCELED)?
>
> Is it possible to change the status of the request to something else from
> intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather
> than introducing intel_guc_ct_enabled() checks here. Changing the status of
> the request when CT goes down would cause the wait's to exit here. And then
> we can check that special request status signifying CT went down?

I think there are free bits in the request status fields which can be
used. But setting the request status say from intel_guc_ct_enabled() might
not be straightforward since you have to locate waiting requests and also
there may be multiple such requests (waiting in different threads).

Maybe an easier way might be to do something like:

bool foo(ct, req)
{
if (!intel_guc_ct_enabled(ct)) {
req->status = CT_WENT_AWAY;
return true;
}
return false;
}

Now in your patch we can substitute foo() instead of
!intel_guc_ct_enabled(ct) so that we have:

 #define done \
(foo() || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
 GUC_HXG_ORIGIN_GUC)

And then check for req->status == CT_WENT_AWAY (most likely in ct_send()).

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Break VM to rq reference loop

2022-06-14 Thread Patchwork

== Series Details ==

Series: Break VM to rq reference loop
URL   : https://patchwork.freedesktop.org/series/105122/
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 series starting with [1/3] iosys-map: Add per-word read

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] iosys-map: Add per-word read
URL   : https://patchwork.freedesktop.org/series/105011/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_105011v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()
URL   : https://patchwork.freedesktop.org/series/105010/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_105010v1_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- shard-snb:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@syncobj_basic@bad-create-flags:
- shard-skl:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105010v1/shard-skl3/igt@syncobj_ba...@bad-create-flags.html

  
Known issues


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

### CI changes ###

 Issues hit 

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: disable HPD workers before display driver unregister (rev9)

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: disable HPD workers before display driver unregister 
(rev9)
URL   : https://patchwork.freedesktop.org/series/103811/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_103811v9_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-tglb7/igt@kms_cursor_leg...@all-pipes-torture-move.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-tglb1/igt@kms_cursor_leg...@all-pipes-torture-move.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_buddy@all@buddy_alloc_smoke:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#5800])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-skl6/igt@drm_buddy@all@buddy_alloc_smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-skl9/igt@drm_buddy@all@buddy_alloc_smoke.html

  * igt@gem_ccs@ctrl-surf-copy:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#3555] / [i915#5325])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-tglb3/igt@gem_...@ctrl-surf-copy.html

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

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-iclb7/igt@gem_exec_balan...@parallel-contexts.html

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

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

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-apl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-iclb8/igt@gem_exec_fair@basic-p...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-iclb6/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v9/shard-apl7/igt@gem_lmem_swapp...@basic.html

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

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

  * igt@gem_pxp@reject-modify-context-protection-on:
- shard-tglb: NOTRUN ->

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/display: Add smem fallback allocation for dpt

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Add smem fallback 
allocation for dpt
URL   : https://patchwork.freedesktop.org/series/104983/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_104983v1_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- shard-snb:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11753/shard-snb5/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v1/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html

  
Known issues


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

### CI changes ###

 Possible fixes 

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel-gpu-top: Optimise the scanning loop a bit

2022-06-14 Thread Umesh Nerlige Ramappa


On Mon, Jun 06, 2022 at 02:27:19PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin 

Opendir(3) and fdopendir(3) are quite expensive system calls when ran in
a loop which iterates all processes in a system times all open files in
each.

Replace some of them (easy ones) with simpler open(2)/read(2) combo to
avoid hammering on the malloc/free.

This brings the default CPU usage of the tool on my desktop from ~3% to
~2%.

Signed-off-by: Tvrtko Ursulin 
---
tools/intel_gpu_top.c | 66 +++
1 file changed, 29 insertions(+), 37 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 997aff582ff7..6de8a164fcff 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1022,12 +1022,12 @@ static void free_clients(struct clients *clients)
free(clients);
}

-static bool is_drm_fd(DIR *fd_dir, const char *name)
+static bool is_drm_fd(int fd_dir, const char *name)
{
struct stat stat;
int ret;

-   ret = fstatat(dirfd(fd_dir), name, , 0);
+   ret = fstatat(fd_dir, name, , 0);

return ret == 0 &&
   (stat.st_mode & S_IFMT) == S_IFCHR &&
@@ -1054,12 +1054,12 @@ static bool get_task_name(const char *buffer, char 
*out, unsigned long sz)
return true;
}

-static DIR *opendirat(DIR *at, const char *name)
+static DIR *opendirat(int at, const char *name)
{
DIR *dir;
int fd;

-   fd = openat(dirfd(at), name, O_DIRECTORY);
+   fd = openat(at, name, O_DIRECTORY);
if (fd < 0)
return NULL;

@@ -1070,37 +1070,27 @@ static DIR *opendirat(DIR *at, const char *name)
return dir;
}

-static FILE *fropenat(DIR *at, const char *name)
+static size_t readat2buf(int at, const char *name, char *buf, const size_t sz)
{
-   FILE *f;
+   ssize_t count;
int fd;

-   fd = openat(dirfd(at), name, O_RDONLY);
-   if (fd < 0)
-   return NULL;
+   fd = openat(at, name, O_RDONLY);
+   if (fd <= 0)
+   return 0;

-   f = fdopen(fd, "r");
-   if (!f)
-   close(fd);
+   count = read(fd, buf, sz - 1);
+   close(fd);

-   return f;
-}
+   if (count > 0) {
+   buf[count] = 0;

-static size_t freadat2buf(char *buf, const size_t sz, DIR *at, const char 
*name)
-{
-   size_t count;
-   FILE *f;
+   return count;
+   } else {
+   buf[0] = 0;

-   f = fropenat(at, name);
-   if (!f)
return 0;
-
-   buf[sz - 1] = 0;
-   count = fread(buf, 1, sz, f);
-   buf[count - 1] = 0;
-   fclose(f);
-
-   return count;
+   }
}

static struct clients *scan_clients(struct clients *clients, bool display)
@@ -1126,10 +1116,11 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
return clients;

while ((proc_dent = readdir(proc_dir)) != NULL) {
-   DIR *pid_dir = NULL, *fd_dir = NULL, *fdinfo_dir = NULL;
+   int pid_dir = -1, fd_dir = -1;

nit: openat takes care of this initialization ^ on error.

struct dirent *fdinfo_dent;
char client_name[64] = { };
unsigned int client_pid;
+   DIR *fdinfo_dir = NULL;
char buf[4096];
size_t count;

@@ -1138,11 +1129,12 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
if (!isdigit(proc_dent->d_name[0]))
continue;

-   pid_dir = opendirat(proc_dir, proc_dent->d_name);
-   if (!pid_dir)
+   pid_dir = openat(dirfd(proc_dir), proc_dent->d_name,
+O_DIRECTORY | O_RDONLY);
+   if (pid_dir < 0)
continue;

-   count = freadat2buf(buf, sizeof(buf), pid_dir, "stat");
+   count = readat2buf(pid_dir, "stat", buf, sizeof(buf));
if (!count)
goto next;

@@ -1153,8 +1145,8 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
if (!get_task_name(buf, client_name, sizeof(client_name)))
goto next;

-   fd_dir = opendirat(pid_dir, "fd");
-   if (!fd_dir)
+   fd_dir = openat(pid_dir, "fd", O_DIRECTORY | O_RDONLY);
+   if (fd_dir < 0)
goto next;

fdinfo_dir = opendirat(pid_dir, "fdinfo");
@@ -1196,10 +1188,10 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
next:
if (fdinfo_dir)
closedir(fdinfo_dir);
-   if (fd_dir)
-   closedir(fd_dir);
-   if (pid_dir)
-   closedir(pid_dir);
+   if (fd_dir >= 0)
+   close(fd_dir);
+   if (pid_dir >= 0)
+   close(pid_dir);

[Intel-gfx] [PATCH 3/3] drm/i915: Do not use reserved requests for virtual engines

2022-06-14 Thread Ramalingam C

Do not use reserved requests for virtual engines as this is only
needed for kernel contexts.

Signed-off-by: Ramalingam C 
Suggested-by: Matthew Brost 
---
 drivers/gpu/drm/i915/i915_request.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c71905d8e154..f0392b053bca 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -135,6 +135,8 @@ static void i915_fence_release(struct dma_fence *fence)
 
/*
 * Keep one request on each engine for reserved use under mempressure
+* do not use with virtual engines as this really is only needed for
+* kernel contexts.
 *
 * We do not hold a reference to the engine here and so have to be
 * very careful in what rq->engine we poke. The virtual engine is
@@ -164,7 +166,8 @@ static void i915_fence_release(struct dma_fence *fence)
 * know that if the rq->execution_mask is a single bit, rq->engine
 * can be a physical engine with the exact corresponding mask.
 */
-   if (is_power_of_2(rq->execution_mask) &&
+   if (!intel_engine_is_virtual(rq->engine) &&
+   is_power_of_2(rq->execution_mask) &&
!cmpxchg(>engine->request_pool, NULL, rq))
return;
 
-- 
2.20.1

[Intel-gfx] [PATCH 2/3] Revert "drm/i915: Hold reference to intel_context over life of i915_request"

2022-06-14 Thread Ramalingam C

From: Niranjana Vishwanathapura 

This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.

The problem with this patch is that it makes i915_request to hold a
reference to intel_context, which in turn holds a reference on the VM.
This strong back referencing can lead to reference loops which leads
to resource leak.

An example is the upcoming VM_BIND work which requires VM to hold
a reference to some shared VM specific BO. But this BO's dma-resv
fences holds reference to the i915_request thus leading to reference
loop.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Ramalingam C 
Suggested-by: Matthew Brost 
---
 drivers/gpu/drm/i915/i915_request.c | 55 +
 1 file changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 7f6998bf390c..c71905d8e154 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -134,17 +134,39 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>semaphore);
 
/*
-* Keep one request on each engine for reserved use under mempressure,
-* do not use with virtual engines as this really is only needed for
-* kernel contexts.
+* Keep one request on each engine for reserved use under mempressure
+*
+* We do not hold a reference to the engine here and so have to be
+* very careful in what rq->engine we poke. The virtual engine is
+* referenced via the rq->context and we released that ref during
+* i915_request_retire(), ergo we must not dereference a virtual
+* engine here. Not that we would want to, as the only consumer of
+* the reserved engine->request_pool is the power management parking,
+* which must-not-fail, and that is only run on the physical engines.
+*
+* Since the request must have been executed to be have completed,
+* we know that it will have been processed by the HW and will
+* not be unsubmitted again, so rq->engine and rq->execution_mask
+* at this point is stable. rq->execution_mask will be a single
+* bit if the last and _only_ engine it could execution on was a
+* physical engine, if it's multiple bits then it started on and
+* could still be on a virtual engine. Thus if the mask is not a
+* power-of-two we assume that rq->engine may still be a virtual
+* engine and so a dangling invalid pointer that we cannot dereference
+*
+* For example, consider the flow of a bonded request through a virtual
+* engine. The request is created with a wide engine mask (all engines
+* that we might execute on). On processing the bond, the request mask
+* is reduced to one or more engines. If the request is subsequently
+* bound to a single engine, it will then be constrained to only
+* execute on that engine and never returned to the virtual engine
+* after timeslicing away, see __unwind_incomplete_requests(). Thus we
+* know that if the rq->execution_mask is a single bit, rq->engine
+* can be a physical engine with the exact corresponding mask.
 */
-   if (!intel_engine_is_virtual(rq->engine) &&
-   !cmpxchg(>engine->request_pool, NULL, rq)) {
-   intel_context_put(rq->context);
+   if (is_power_of_2(rq->execution_mask) &&
+   !cmpxchg(>engine->request_pool, NULL, rq))
return;
-   }
-
-   intel_context_put(rq->context);
 
kmem_cache_free(slab_requests, rq);
 }
@@ -921,19 +943,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
}
}
 
-   /*
-* Hold a reference to the intel_context over life of an i915_request.
-* Without this an i915_request can exist after the context has been
-* destroyed (e.g. request retired, context closed, but user space holds
-* a reference to the request from an out fence). In the case of GuC
-* submission + virtual engine, the engine that the request references
-* is also destroyed which can trigger bad pointer dref in fence ops
-* (e.g. i915_fence_get_driver_name). We could likely change these
-* functions to avoid touching the engine but let's just be safe and
-* hold the intel_context reference. In execlist mode the request always
-* eventually points to a physical engine so this isn't an issue.
-*/
-   rq->context = intel_context_get(ce);
+   rq->context = ce;
rq->engine = ce->engine;
rq->ring = ce->ring;
rq->execution_mask = ce->engine->mask;
@@ -1009,7 +1019,6 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
GEM_BUG_ON(!list_empty(>sched.waiters_list));
 
 err_free:
-   intel_context_put(ce);
kmem_cache_free(slab_requests, rq);

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Dong, Zhanjun

Thanks for all comments, I will update code and prepare for next version.

Regards,
Zhanjun

-Original Message-
From: Dixit, Ashutosh  
Sent: June 14, 2022 12:28 PM
To: Dong, Zhanjun 
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Teres 
Alexis, Alan Previn ; Wajdeczko, Michal 

Subject: Re: [PATCH] drm/i915/guc: Check ctx while waiting for response

On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>

Hi Zhanjun,

> We are seeing error message of "No response for request". Some cases 
> happened while waiting for response and reset/suspend action was 
> triggered. In this case, no response is not an error, active requests will be 
> cancelled.
>
> This patch will handle this condition and change the error message 
> into debug message.

IMO the patch title should be changed: which ctx are we checking while waiting 
for response? Something like "check for ct enabled while waiting for response"?

> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct 
> ct_request *req, u32 *status)  #define 
> GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10  #define 
> GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> +READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;

Also, I really don't like intel_guc_ct_enabled() being called in two places. Is 
there a possibility that intel_guc_ct_enabled() can return false in the first 
place (causing the wait to exit) and then return true in the second place (so 
we don't return -ECANCELED)?

Is it possible to change the status of the request to something else from
intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather than 
introducing intel_guc_ct_enabled() checks here. Changing the status of the 
request when CT goes down would cause the wait's to exit here. And then we can 
check that special request status signifying CT went down?

Thanks.
--
Ashutosh

[Intel-gfx] [PATCH 1/3] drm/i915: Do not access rq->engine without a reference

2022-06-14 Thread Ramalingam C

From: Niranjana Vishwanathapura 

In i915_fence_get_driver_name(), user may not hold a
reference to rq->engine. Hence do not access it. Instead,
store required device private pointer in 'rq->i915' and use it.

Signed-off-by: Niranjana Vishwanathapura 
Suggested-by: Matthew Brost 
---
 drivers/gpu/drm/i915/i915_request.c | 3 ++-
 drivers/gpu/drm/i915/i915_request.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 73d5195146b0..7f6998bf390c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -60,7 +60,7 @@ static struct kmem_cache *slab_execute_cbs;
 
 static const char *i915_fence_get_driver_name(struct dma_fence *fence)
 {
-   return dev_name(to_request(fence)->engine->i915->drm.dev);
+   return dev_name(to_request(fence)->i915->drm.dev);
 }
 
 static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
@@ -937,6 +937,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->engine = ce->engine;
rq->ring = ce->ring;
rq->execution_mask = ce->engine->mask;
+   rq->i915 = ce->engine->i915;
 
ret = intel_timeline_get_seqno(tl, rq, );
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 28b1f9db5487..47041ec68df8 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -196,6 +196,8 @@ struct i915_request {
struct dma_fence fence;
spinlock_t lock;
 
+   struct drm_i915_private *i915;
+
/**
 * Context and ring buffer related to this request
 * Contexts are refcounted, so when this request is associated with a
-- 
2.20.1

[Intel-gfx] [PATCH 0/3] Break VM to rq reference loop

2022-06-14 Thread Ramalingam C

The i915_request holds a reference to intel_context, which in
turn holds a reference on the VM. But the dma-resv update for
VM_BIND feature would require VM hold a reference to the
i915_request through dma-resv fences of VM_PRIVATE objects
(which share a per VM dma-resv object).

Thus, we have a circular reference pattern causing the VM
reference to never reach 0, hence VM is not destroyed.

Break this by reverting the below patch which is making the
i915_request to hold a reference on intel_context.
"drm/i915: Hold reference to intel_context over life of i915_request"

This means we can't access rq->engine in i915_fence_get_driver_name()
as user do not hold a reference on rq->engine here. So, instead
store required device private pointer in 'rq->i915' and use it.

Niranjana Vishwanathapura (2):
  drm/i915: Do not access rq->engine without a reference
  Revert "drm/i915: Hold reference to intel_context over life of
i915_request"

Ramalingam C (1):
  drm/i915: Do not use reserved requests for virtual engines

 drivers/gpu/drm/i915/i915_request.c | 55 ++---
 drivers/gpu/drm/i915/i915_request.h |  2 ++
 2 files changed, 36 insertions(+), 21 deletions(-)

-- 
2.20.1

[Intel-gfx] ✓ Fi.CI.IGT: success for Disable connector polling for a headless sku (rev3)

2022-06-14 Thread Patchwork

== Series Details ==

Series: Disable connector polling for a headless sku (rev3)
URL   : https://patchwork.freedesktop.org/series/104711/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11753_full -> Patchwork_104711v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Known issues


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

### CI changes ###

 Possible fixes 

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/ttm: don't overwrite cache_dirty after setting coherency

2022-06-14 Thread Matthew Auld

On Tue, 14 Jun 2022 at 02:14, Adrian Larumbe
 wrote:
>
> 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 2f0ec95ed20c ("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 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.
>
> There also seems to be no need for this statement to be kept in
> i915_gem_object_set_cache_level, since i915_gem_object_set_cache_coherency
> is already taking care of it, and also considering whether it's a discrete
> platform.
>
> Remove statement altogether.
>
> Signed-off-by: Adrian Larumbe 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 3e5d6057b3ef..b2c9e16bfa55 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -273,10 +273,8 @@ int i915_gem_object_set_cache_level(struct 
> drm_i915_gem_object *obj,
> return ret;
>
> /* Always invalidate stale cachelines */
> -   if (obj->cache_level != cache_level) {
> +   if (obj->cache_level != cache_level)
> i915_gem_object_set_cache_coherency(obj, cache_level);
> -   obj->cache_dirty = true;

Maybe ban calling this on dgpu or have it fail silently? At the ioctl
level this should already be banned.

Ignoring dgpu, the cache_dirty handling is quite thorny on non-LLC
platforms. I'm not sure if there are other historical reasons for
having this here, but one big issue is that we are not allowed to
freely set cache_dirty = false, unless we are certain that the pages
underneath have been populated and the potential flush-on-acquire
completed. See the kernel-doc for @cache_dirty for more details.

> -   }
>
> /* The cache-level will be applied when each vma is rebound. */
> return i915_gem_object_unbind(obj,
> --
> 2.36.1
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: split out hdcp registers to a separate file

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/hdcp: split out hdcp registers to a separate file
URL   : https://patchwork.freedesktop.org/series/105119/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_105119v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 45)
--

  Additional (3): bat-adlm-1 fi-rkl-11600 bat-jsl-2 
  Missing(4): fi-ctg-p8600 fi-bdw-samus fi-apl-guc fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#3576]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-adlp-4/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][7] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][8] -> [DMESG-FAIL][9] ([i915#4494] / 
[i915#4957])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][10] ([i915#4817])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

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

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105119v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [19]:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hdcp: split out hdcp registers to a separate file

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/hdcp: split out hdcp registers to a separate file
URL   : https://patchwork.freedesktop.org/series/105119/
State : warning

== Summary ==

Error: dim checkpatch failed
60447ec4cacf drm/i915/hdcp: split out hdcp registers to a separate file
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:35: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#35: 
new file mode 100644

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Bump up CDCLK for DG2

2022-06-14 Thread Patchwork

== Series Details ==

Series: Bump up CDCLK for DG2
URL   : https://patchwork.freedesktop.org/series/105110/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_105110v1


Summary
---

  **FAILURE**

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

Participating hosts (46 -> 44)
--

  Additional (2): fi-rkl-11600 bat-jsl-2 
  Missing(4): fi-ctg-p8600 bat-dg2-8 fi-bdw-samus fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@basic-api:
- fi-kbl-soraka:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-kbl-soraka/igt@i915_pm_...@basic-api.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-kbl-soraka/igt@i915_pm_...@basic-api.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@i915_selftest@live@gtt:
- fi-bdw-5557u:   [PASS][8] -> [DMESG-FAIL][9] ([i915#3674])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [PASS][10] -> [DMESG-FAIL][11] ([i915#4494] / 
[i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][12] ([i915#4817])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][14] -> [DMESG-WARN][15] ([i915#3576]) +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#111827]) +7 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4103]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105110v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-14 Thread Niranjana Vishwanathapura


On Tue, Jun 14, 2022 at 10:04:00AM +0300, Lionel Landwerlin wrote:

On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:



Regards,
Oak


-Original Message-
From: Intel-gfx  On 
Behalf Of Niranjana

Vishwanathapura
Sent: June 10, 2022 1:43 PM
To: Landwerlin, Lionel G 
Cc: Intel GFX ; Maling list - 
DRI developers de...@lists.freedesktop.org>; Hellstrom, Thomas 
;

Wilson, Chris P ; Vetter, Daniel
; Christian König 
Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND 
feature design

document

On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:

On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:

On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:

On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:

  On 09/06/2022 00:55, Jason Ekstrand wrote:

    On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
 wrote:

  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko 

Ursulin wrote:

  >
  >
  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
Vishwanathapura
  wrote:
  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason
Ekstrand wrote:
   On Fri, Jun 3, 2022 at 6:52 PM Niranjana 

Vishwanathapura

    wrote:
  
     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel
Landwerlin
  wrote:
     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
     >
     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana
Vishwanathapura
     >  wrote:
     >
     >   On Wed, Jun 01, 2022 at 01:28:36PM 

-0700, Matthew

  Brost wrote:
     >   >On Wed, Jun 01, 2022 at 05:25:49PM 

+0300, Lionel

  Landwerlin
     wrote:
     > >> On 17/05/2022 21:32, Niranjana Vishwanathapura
  wrote:
     > >> > +VM_BIND/UNBIND ioctl will immediately start
     binding/unbinding
     >   the mapping in an
     > >> > +async worker. The binding and
unbinding will
  work like a
     special
     >   GPU engine.
     > >> > +The binding and unbinding operations are
  serialized and
     will
     >   wait on specified
     > >> > +input fences before the operation
and will signal
  the
     output
     >   fences upon the
     > >> > +completion of the operation. Due to
  serialization,
     completion of
     >   an operation
     > >> > +will also indicate that all
previous operations
  are also
     > complete.
     > >>
     > >> I guess we should avoid saying "will
immediately
  start
     > binding/unbinding" if
     > >> there are fences involved.
     > >>
     > >> And the fact that it's happening in an async
  worker seem to
     imply
     >   it's not
     > >> immediate.
     > >>
     >
     >   Ok, will fix.
     >   This was added because in earlier design
binding was
  deferred
     until
     >   next execbuff.
     >   But now it is non-deferred (immediate in
that sense).
  But yah,
     this is
     > confusing
     >   and will fix it.
     >
     > >>
     > >> I have a question on the behavior of the bind
  operation when
     no
     >   input fence
     > >> is provided. Let say I do :
     > >>
     > >> VM_BIND (out_fence=fence1)
     > >>
     > >> VM_BIND (out_fence=fence2)
     > >>
     > >> VM_BIND (out_fence=fence3)
     > >>
     > >>
     > >> In what order are the fences going to
be signaled?
     > >>
     > >> In the order of VM_BIND ioctls? Or out
of order?
     > >>
     > >> Because you wrote "serialized I assume
it's : in
  order
     > >>
     >
     >   Yes, in the order of VM_BIND/UNBIND
ioctls. Note that
  bind and
     unbind
     >   will use
     >   the same queue and hence are ordered.
     >
     > >>
     > >> One thing I didn't realize is that
because we only
  get one
     > "VM_BIND" engine,
     > >> there is a disconnect from the Vulkan
specification.
     > >>
     > >> In Vulkan VM_BIND operations are
serialized but
  per engine.
     > >>
     > >> So you could have something like this :
     > >>
     > >> VM_BIND (engine=rcs0, in_fence=fence1,
  out_fence=fence2)
     > >>

[Intel-gfx] [PATCH] drm/i915/hdcp: split out hdcp registers to a separate file

2022-06-14 Thread Jani Nikula

Reduce the bloat of i915_reg.h.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp.c |   1 +
 .../gpu/drm/i915/display/intel_hdcp_regs.h| 270 ++
 drivers/gpu/drm/i915/display/intel_hdmi.c |   1 +
 drivers/gpu/drm/i915/i915_reg.h   | 259 -
 5 files changed, 273 insertions(+), 259 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_regs.h

diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index a7640dbcf00e..88689124c013 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -17,6 +17,7 @@
 #include "intel_dp.h"
 #include "intel_dp_hdcp.h"
 #include "intel_hdcp.h"
+#include "intel_hdcp_regs.h"
 
 static unsigned int transcoder_to_stream_enc_status(enum transcoder 
cpu_transcoder)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 8ea66a2e1b09..c5e9e86bb4cb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,6 +23,7 @@
 #include "intel_display_power_well.h"
 #include "intel_display_types.h"
 #include "intel_hdcp.h"
+#include "intel_hdcp_regs.h"
 #include "intel_pcode.h"
 
 #define KEY_LOAD_TRIES 5
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_regs.h 
b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h
new file mode 100644
index ..cbeab64e69d2
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h
@@ -0,0 +1,270 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __INTEL_HDCP_REGS_H__
+#define __INTEL_HDCP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* HDCP Key Registers */
+#define HDCP_KEY_CONF  _MMIO(0x66c00)
+#define  HDCP_AKSV_SEND_TRIGGERBIT(31)
+#define  HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define  HDCP_KEY_LOAD_TRIGGER BIT(8)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  HDCP_FUSE_ERROR   BIT(6)
+#define  HDCP_FUSE_DONEBIT(5)
+#define  HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  HDCP_KEY_LOAD_DONEBIT(0)
+#define HDCP_AKSV_LO   _MMIO(0x66c10)
+#define HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define HDCP_REP_CTL   _MMIO(0x66d00)
+#define  HDCP_TRANSA_REP_PRESENT   BIT(31)
+#define  HDCP_TRANSB_REP_PRESENT   BIT(30)
+#define  HDCP_TRANSC_REP_PRESENT   BIT(29)
+#define  HDCP_TRANSD_REP_PRESENT   BIT(28)
+#define  HDCP_DDIB_REP_PRESENT BIT(30)
+#define  HDCP_DDIA_REP_PRESENT BIT(29)
+#define  HDCP_DDIC_REP_PRESENT BIT(28)
+#define  HDCP_DDID_REP_PRESENT BIT(27)
+#define  HDCP_DDIF_REP_PRESENT BIT(26)
+#define  HDCP_DDIE_REP_PRESENT BIT(25)
+#define  HDCP_TRANSA_SHA1_M0   (1 << 20)
+#define  HDCP_TRANSB_SHA1_M0   (2 << 20)
+#define  HDCP_TRANSC_SHA1_M0   (3 << 20)
+#define  HDCP_TRANSD_SHA1_M0   (4 << 20)
+#define  HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  HDCP_DDID_SHA1_M0 (4 << 20)
+#define  HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  HDCP_SHA1_BUSYBIT(16)
+#define  HDCP_SHA1_READY   BIT(17)
+#define  HDCP_SHA1_COMPLETEBIT(18)
+#define  HDCP_SHA1_V_MATCH BIT(19)
+#define  HDCP_SHA1_TEXT_32 (1 << 1)
+#define  HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  HDCP_SHA1_TEXT_24 (4 << 1)
+#define  HDCP_SHA1_TEXT_16 (5 << 1)
+#define  HDCP_SHA1_TEXT_8  (6 << 1)
+#define  HDCP_SHA1_TEXT_0  (7 << 1)
+#define HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + (h) * 4))
+#define HDCP_SHA_TEXT  _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _PORTA_HDCP_AUTHENC0x66800
+#define _PORTB_HDCP_AUTHENC0x66500
+#define _PORTC_HDCP_AUTHENC0x66600
+#define _PORTD_HDCP_AUTHENC0x66700
+#define _PORTE_HDCP_AUTHENC0x66A00
+#define _PORTF_HDCP_AUTHENC0x66900
+#define _PORT_HDCP_AUTHENC(port, x)_MMIO(_PICK(port, \
+ _PORTA_HDCP_AUTHENC, \
+ _PORTB_HDCP_AUTHENC, \
+

[Intel-gfx] ✗ Fi.CI.BAT: failure for Do not enable PSR2 if no active planes

2022-06-14 Thread Patchwork

== Series Details ==

Series: Do not enable PSR2 if no active planes
URL   : https://patchwork.freedesktop.org/series/105109/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_105109v1


Summary
---

  **FAILURE**

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

Participating hosts (46 -> 45)
--

  Additional (2): fi-rkl-11600 bat-jsl-2 
  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_105109v1:

### IGT changes ###

 Possible regressions 

  * igt@debugfs_test@read_all_entries:
- fi-kbl-guc: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-kbl-guc/igt@debugfs_test@read_all_entries.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-8809g:   [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-kbl-8809g/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-kbl-8809g/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@i915_selftest@live@reset:
- fi-bdw-5557u:   [PASS][12] -> [INCOMPLETE][13] ([i915#6000])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/fi-bdw-5557u/igt@i915_selftest@l...@reset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-bdw-5557u/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][14] ([i915#4817])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#111827]) +7 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4103]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109285] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105109v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  *

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Niranjana Vishwanathapura


On Tue, Jun 14, 2022 at 05:07:37PM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 17:02, Tvrtko Ursulin wrote:


On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel 
Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of 
binding during VM creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support 
output fences. Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to 
object mapping to bind.

+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the 
specified address space (VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in 
the order of submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+

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

2022-06-14 Thread Umesh Nerlige Ramappa


On Tue, Jun 14, 2022 at 02:30:42PM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 01:46, 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.

Signed-off-by: John Harrison 
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 11 +++-
 drivers/gpu/drm/i915/gt/intel_context.h   |  6 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  5 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 55 ++-
 drivers/gpu/drm/i915/i915_drm_client.c|  6 +-
 6 files changed, 75 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..a49f313db911 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,23 @@ 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)
+   /*
+* GuC backend returns the actual time the context was active, so skip
+* the calculation here for GuC.
+*/
+   if (active && !intel_engine_uses_guc(ce->engine))


What is the point of looking at ce->stats.active in GuC mode? I see 
that guc_context_update_stats/__guc_context_update_clks touches it, 
but I can't spot that there is a purpose to it. This is the only 
conditional reading it but it is short-circuited in GuC case.


Also, since a GuC only vfunc (update_stats) has been added, I wonder 
why not just fork the whole runtime query (ce->get_total_runtime_ns). 
I think that would end up cleaner.



active = intel_context_clock() - active;
return total + active;


In case of GuC the active is used directly here since the active updated 
in update_stats is equal to the active time of the context already. I 
will look into separate vfunc.



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


snip


+static void __guc_context_update_clks(struct intel_context *ce)
+{
+   struct intel_guc *guc = ce_to_guc(ce);
+   struct intel_gt *gt = ce->engine->gt;
+   u32 *pphwsp, last_switch, engine_id;
+   u64 start_gt_clk = 0, active = 0;


No need to init these two.


+   unsigned long flags;
+   ktime_t unused;
+
+   spin_lock_irqsave(>timestamp.lock, flags);
+
+   pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
+   last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
+   engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
+
+   guc_update_pm_timestamp(guc, );
+
+   if (engine_id != 0x && last_switch) {
+   start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
+   __extend_last_switch(guc, _gt_clk, last_switch);
+   active = intel_gt_clock_interval_to_ns(gt, 
guc->timestamp.gt_stamp - start_gt_clk);
+   WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
+   WRITE_ONCE(ce->stats.active, active);
+   } else {
+   lrc_update_runtime(ce);


Why is this called from here? Presumably it was called already from 
guc_context_unpin if here code things context is not active. Or will 
be called shortly, once context save is done.


guc_context_unpin is only called in the path of ce->sched_disable. The 
sched_disable is implemented in GuC (H2G message). Once the 
corresponding G2H response is

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Dixit, Ashutosh

On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>

Hi Zhanjun,

> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will handle this condition and change the error message into
> debug message.

IMO the patch title should be changed: which ctx are we checking while
waiting for response? Something like "check for ct enabled while waiting
for response"?

> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;

Also, I really don't like intel_guc_ct_enabled() being called in two
places. Is there a possibility that intel_guc_ct_enabled() can return false
in the first place (causing the wait to exit) and then return true in the
second place (so we don't return -ECANCELED)?

Is it possible to change the status of the request to something else from
intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather
than introducing intel_guc_ct_enabled() checks here. Changing the status of
the request when CT goes down would cause the wait's to exit here. And then
we can check that special request status signifying CT went down?

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Jani Nikula

On Thu, 02 Jun 2022, Zhanjun Dong  wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will handle this condition and change the error message into
> debug message.
>
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)
>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(, status);
> + err = wait_for_ct_request_update(, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))

I think you mean -ECANCELED, not ECANCELED.

Please drop the unlikely(). I no longer want to see a single unlikely()
or likely() added anywhere without proper performance
justification. They make the code harder to read, for no real benefit,
and people just cargo cult copy paste them everywhere. Moreover, nested
unlikely/likely is just silly.

> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> );
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))

Ditto for -ECANCELED and likely().

BR,
Jani.

> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Niranjana Vishwanathapura


On Tue, Jun 14, 2022 at 09:27:05AM +0300, Lionel Landwerlin wrote:

On 10/06/2022 11:53, Matthew Brost wrote:

On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
 1 file changed, 490 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND   (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See _i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND   0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3   0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE   0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+   /** @vm_id: VM (address space) id to bind */
+   __u32 vm_id;
+
+   /** @queue_idx: Index of queue for binding */
+   __u32 queue_idx;
+
+   /** @rsvd: Reserved, MBZ */
+   __u32 rsvd;
+
+   /** @handle: Object handle */
+   __u32 handle;
+
+   /** @start: Virtual Address start to bind */
+   __u64 start;
+
+   /** @offset: Offset in object to bind */
+   __u64 offset;
+
+   /** @length: Length of mapping to bind */
+   __u64 length;

This probably isn't needed. We are never going to unbind a subset of a
VMA are we? That

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/display: Add smem fallback allocation for dpt (rev3)

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Add smem fallback 
allocation for dpt (rev3)
URL   : https://patchwork.freedesktop.org/series/104983/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_104983v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Additional (2): fi-rkl-11600 bat-jsl-2 
  Missing(4): fi-ctg-p8600 bat-dg2-8 fi-bdw-samus fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][5] ([i915#4528])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-blb-e6850/igt@i915_selftest@l...@gem.html

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

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][8] ([i915#4817])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][10] -> [DMESG-WARN][11] ([i915#3576]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

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

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104983v3/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [19]:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Michal Wajdeczko




On 02.06.2022 19:21, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
> 
> This patch will handle this condition and change the error message into
> debug message.
> 
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)

if you need to add "intel_guc_ct *ct" param then make it the first one

>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(, status);
> + err = wait_for_ct_request_update(, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))

you are looking for -ECANCELED
and I guess you can safely drop "unlikely" hint here

> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> );
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))

ditto

,Michal

> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Tvrtko Ursulin




On 14/06/2022 17:02, Tvrtko Ursulin wrote:


On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:
On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin 
wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM 
creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. 
Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to 
bind.

+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space 
(VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of 
submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Tvrtko Ursulin




On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:

On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM 
creation.

+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. 
Hence,

+ * I915_EXEC_FENCE_SIGNAL (See
_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space 
(VM).

+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of 
submission.

+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for binding

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/display: Add smem fallback allocation for dpt (rev3)

2022-06-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Add smem fallback 
allocation for dpt (rev3)
URL   : https://patchwork.freedesktop.org/series/104983/
State : warning

== Summary ==

Error: dim checkpatch failed
53835e6eed08 drm/i915/display: Add smem fallback allocation for dpt
97462dcde577 drm/i915: Fix i915_vma_pin_iomap()
-:48: CHECK:BRACES: Unbalanced braces around else statement
#48: FILE: drivers/gpu/drm/i915/i915_vma.c:573:
+   else {

total: 0 errors, 0 warnings, 1 checks, 72 lines checked
a24cd5f929e5 drm/i915: don't leak lmem mapping in vma_evict

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Niranjana Vishwanathapura


On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:


On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
  Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See
_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for binding */
+    __u32 queue_idx;


I have a question here to which I did

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Clean up drm_crtc.h (rev5)

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm: Clean up drm_crtc.h (rev5)
URL   : https://patchwork.freedesktop.org/series/105073/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11757 -> Patchwork_105073v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 43)
--

  Additional (1): fi-rkl-11600 
  Missing(4): fi-ctg-p8600 bat-dg2-8 fi-bdw-samus fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [PASS][5] -> [INCOMPLETE][6] ([i915#4418])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11757/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][7] ([i915#4817])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([fdo#111827]) +7 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

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

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

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#533])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105073v5/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm:  [INCOMPLETE][19] ([i915#2940]) -> [PASS][20]
   [19]:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response

2022-06-14 Thread Teres Alexis, Alan Previn

Can't see anything wrong with this.
I consider this only a NIT, so feel : not sure if -ECANCELLED is reflective of 
the "ct service being temporarily down"
as opposed to the "requester cancelling". Perhaps a -EPIPE or -EAGAIN (if we 
got this far, we know we are probably mid-
reset) ?? (if not already used elsewhere along this callstack). Else :

Reviewed-by: Alan Previn 

...alan


On Thu, 2022-06-02 at 10:21 -0700, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
> 
> This patch will handle this condition and change the error message into
> debug message.
> 
> Signed-off-by: Zhanjun Dong 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index f01325cd1b62..a30a388877e2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * * 0 response received (status is valid)
>   * * -ETIMEDOUT no response within hardcoded timeout
>   */
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct ct_request *req, u32 *status, 
> struct intel_guc_ct *ct)
>  {
>   int err;
>  
> @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request 
> *req, u32 *status)
>  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
>  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
>  #define done \
> - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, 
> READ_ONCE(req->status)) == \
>GUC_HXG_ORIGIN_GUC)
>   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
>   if (err)
>   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
>  #undef done
> + if (!intel_guc_ct_enabled(ct))
> + err = -ECANCELED;
>  
>   *status = req->status;
>   return err;
> @@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
>  
>   intel_guc_notify(ct_to_guc(ct));
>  
> - err = wait_for_ct_request_update(, status);
> + err = wait_for_ct_request_update(, status, ct);
>   g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
>   if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> -  action[0], request.fence);
> + if (unlikely(err == ECANCELED))
> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB 
> is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
>   goto unlink;
>   }
>  
> @@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
> *action, u32 len,
>  
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
> );
>   if (unlikely(ret < 0)) {
> - CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> -  action[0], ERR_PTR(ret), status);
> + if (likely(ret != ECANCELED))
> + CT_ERROR(ct, "Sending action %#x failed (%pe) 
> status=%#X\n",
> + action[0], ERR_PTR(ret), status);
>   } else if (unlikely(ret)) {
>   CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
>action[0], ret, ret);
> -- 
> 2.36.0
>

Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2

2022-06-14 Thread Ceraolo Spurio, Daniele





On 6/14/2022 12:44 AM, Tvrtko Ursulin wrote:


On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:

On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:

On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:


On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 1:16 AM, Tvrtko Ursulin wrote:


On 10/06/2022 00:19, Daniele Ceraolo Spurio wrote:
On DG2, HuC loading is performed by the GSC, via a PXP 
command. The load
operation itself is relatively simple (just send a message to 
the GSC
with the physical address of the HuC in LMEM), but there are 
timing
changes that requires special attention. In particular, to 
send a PXP
command we need to first export the GSC driver and then wait 
for the
mei-gsc and mei-pxp modules to start, which means that HuC 
load will
complete after i915 load is complete. This means that there 
is a small

window of time after i915 is registered and before HuC is loaded
during which userspace could submit and/or checking the HuC 
load status,
although this is quite unlikely to happen (HuC is usually 
loaded before

kernel init/resume completes).
We've consulted with the media team in regards to how to 
handle this and

they've asked us to do the following:

1) Report HuC as loaded in the getparam IOCTL even if load is 
still in
progress. The media driver uses the IOCTL as a way to check 
if HuC is
enabled and then includes a secondary check in the batches to 
get the
actual status, so doing it this way allows userspace to keep 
working

without changes.

2) Stall all userspace VCS submission until HuC is loaded. 
Stalls are
expected to be very rare (if any), due to the fact that HuC 
is usually

loaded before kernel init/resume is completed.


Motivation to add these complications into i915 are not clear 
to me here. I mean there is no HuC on DG2 _yet_ is the premise 
of the series, right? So no backwards compatibility concerns. 
In this case why jump through the hoops and not let userspace 
handle all of this by just leaving the getparam return the 
true status?


The main areas impacted by the fact that we can't guarantee 
that HuC load is complete when i915 starts accepting 
submissions are boot and suspend/resume, with the latter being 
the main problem; GT reset is not a concern because HuC now 
survives it. A suspend/resume can be transparent to userspace 
and therefore the HuC status can temporarily flip from loaded 
to not without userspace knowledge, especially if we start 
going into deeper suspend states and start causing HuC resets 
when we go into runtime suspend. Note that this is different 
from what happens during GT reset for older platforms, because 
in that scenario we guarantee that HuC reload is complete 
before we restart the submission back-end, so userspace doesn't 
notice that the HuC status change. We had an internal 
discussion about this problem with both media and i915 archs 
and the conclusion was that the best option is for i915 to 
stall media submission while HuC (re-)load is in progress.


Resume is potentialy a good reason - I did not pick up on that 
from the cover letter. I read the statement about the unlikely 
and small window where HuC is not loaded during kernel 
init/resume and I guess did not pick up on the resume part.


Waiting for GSC to load HuC from i915 resume is not an option?


GSC is an aux device exported by i915, so AFAIU GSC resume can't 
start until i915 resume completes.


I'll dig into this in the next few days since I want to understand 
how exactly it works. Or someone can help explain.


If in the end conclusion will be that i915 resume indeed cannot 
wait for GSC, then I think auto-blocking of queued up contexts on 
media engines indeed sounds unavoidable. Otherwise, as you 
explained, user experience post resume wouldn't be good.


Even if we could implement a wait, I'm not sure we should. GSC 
resume and HuC reload takes ~300ms in most cases, I don't think we 
want to block within the i915 resume path for that long.


Yeah maybe not. But entertaining the idea that it is technically 
possible to block - we could perhaps add uapi for userspace to mark 
contexts which want HuC access. Then track if there are any such 
contexts with outstanding submissions and only wait in resume if 
there are. If that would end up significantly less code on the i915 
side to maintain is an open.


What would be the end result from users point of view in case where 
it suspended during video playback? The proposed solution from this 
series sees the video stuck after resume. Maybe compositor blocks as 
well since I am not sure how well they handle one window not 
providing new data. Probably depends on the compositor.


And then with a simpler solution definitely the whole resume would 
be delayed by 300ms.


With my ChromeOS hat the stalled media engines does sound like a 
better

Re: [Intel-gfx] [PATCH v7] drm/i915/display: disable HPD workers before display driver unregister

2022-06-14 Thread Andrzej Hajda


On 10.06.2022 20:37, Ville Syrjälä wrote:

On Fri, Jun 10, 2022 at 06:00:24PM +0200, Andrzej Hajda wrote:

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

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

I am not sure about changes in shutdown path, any comments welcome.
I suspect suspend path have also some common bits, but I am little
bit afraid of touching it.

Changes:
v1 - v6:
 - chasing the bug appearing only on public CI.
v7:
 - shutdown path adjusted (suggested by Jani)

Regards
Andrzej
---
  drivers/gpu/drm/i915/display/intel_display.c | 11 ---
  drivers/gpu/drm/i915/i915_driver.c   |  5 ++---
  2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 186b37925d23f2..f9952ee8289fb2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10490,13 +10490,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
  
-	/*

-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
  
@@ -10588,6 +10581,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915)

if (!HAS_DISPLAY(i915))
return;
  
+	intel_dp_mst_suspend(i915);

+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(>drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
  
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c

index d26dcca7e654aa..82cdccf072e2bc 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1070,15 +1070,14 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
i915_gem_suspend(i915);
  
  	if (HAS_DISPLAY(i915)) {

+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
drm_kms_helper_poll_disable(>drm);
  
  		drm_atomic_helper_shutdown(>drm);


You can't suspend MST before this since this is what actually turns the
displays off.

The real chicken and egg sitaation is due to MST sideband depending
on HPD_IRQs to work, but we want to stop the rest of hotplug processing
before we shut down the displays to make sure fbdev/etc. doesn't light
them back up.

If we didn't have MST sidband we could just turn off hotplug interrupts
ahead of time and flush the works, but with MST we need to keep the
interrupts alive. So I suspect we need some kind of flag to indicate
that at least full hotplug handling should not happen even though the
hotplug interrupts are still enabled.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/dp/mst: Read the extended DPCD capabilities during system resume
URL   : https://patchwork.freedesktop.org/series/105102/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11756 -> Patchwork_105102v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 45)
--

  Additional (3): bat-dg2-8 fi-kbl-x1275 bat-adlp-4 
  Missing(2): bat-adlm-1 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html

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

  * igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_module_load@load:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#6227])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@i915_module_l...@load.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#5903])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#4093]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][15] ([i915#3576]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

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

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlp-4: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4579])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105102v1/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-kbl-x1275:   NOTRUN -> [SKIP][18] ([fdo#109271]) +12 similar issues
   [18]:

Re: [Intel-gfx] [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Jani Nikula

On Tue, 14 Jun 2022, Imre Deak  wrote:
> On Tue, Jun 14, 2022 at 03:32:59PM +0300, Jani Nikula wrote:
>> On Tue, 14 Jun 2022, Imre Deak  wrote:
>> > The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
>> > from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
>> > registers are not read subsequently also as required.
>> 
>> Does it actually change the behaviour depending on whether the dpcd is
>> read or not, or is this just about the resume path overwriting mgr->dpcd
>> with stuff from DP_DPCD_REV?
>
> Yes, the reading out DP_DP13_DPCD_REV has a side-effect, see
> https://gitlab.freedesktop.org/drm/intel/-/issues/5292#note_1343399

:o

Okay, the commit message is fine as-is.

>
>> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
>> reading the caps, which would normally set mgr->dpcd from
>> DP_DP13_DPCD_REV.
>
> Right, but at that point DP_DP13_DPCD_REV returns HBR2 w/o this change.
>
>> BR,
>> Jani.
>> 
>> >
>> > Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
>> > done during connector detection. While at it also fix up the same call
>> > in drm_dp_mst_dump_topology().
>> >
>> > Cc: Lyude Paul 
>> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
>> > Signed-off-by: Imre Deak 
>> > ---
>> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>> >  1 file changed, 2 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
>> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > index 67b3b9697da7f..18f2b6075b780 100644
>> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
>> > drm_dp_mst_topology_mgr *mgr,
>> >if (!mgr->mst_primary)
>> >goto out_fail;
>> >  
>> > -  ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
>> > - DP_RECEIVER_CAP_SIZE);
>> > -  if (ret != DP_RECEIVER_CAP_SIZE) {
>> > +  if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>> >drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
>> > suspend?\n");
>> >goto out_fail;
>> >}
>> > @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>> >u8 buf[DP_PAYLOAD_TABLE_SIZE];
>> >int ret;
>> >  
>> > -  ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
>> > DP_RECEIVER_CAP_SIZE);
>> > -  if (ret) {
>> > +  if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>> >seq_printf(m, "dpcd read failed\n");
>> >goto out;
>> >}
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: add payload receiving code

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsi: add payload receiving code
URL   : https://patchwork.freedesktop.org/series/105096/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11756 -> Patchwork_105096v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (44 -> 44)
--

  Additional (2): fi-kbl-x1275 bat-adlp-4 
  Missing(2): bat-adlm-1 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html

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

  * igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_module_load@load:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#6227])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@i915_module_l...@load.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][6] ([i915#3576]) +1 similar 
issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][7] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u:   [PASS][8] -> [INCOMPLETE][9] ([i915#5502])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][10] -> [INCOMPLETE][11] ([i915#4785])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11756/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5:  NOTRUN -> [DMESG-FAIL][12] ([i915#4494] / [i915#4957])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-dg1-5/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_105096v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_busy@basic@flip:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][15] ([i915#1982] / [i915#3576])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][19] ([i915#4103]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-4:

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

2022-06-14 Thread Tvrtko Ursulin




On 14/06/2022 01:46, 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.

Signed-off-by: John Harrison 
Signed-off-by: Umesh Nerlige Ramappa 
---
  drivers/gpu/drm/i915/gt/intel_context.c   | 11 +++-
  drivers/gpu/drm/i915/gt/intel_context.h   |  6 +-
  drivers/gpu/drm/i915/gt/intel_context_types.h |  3 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  5 ++
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 55 ++-
  drivers/gpu/drm/i915/i915_drm_client.c|  6 +-
  6 files changed, 75 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..a49f313db911 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,23 @@ 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)
+   /*
+* GuC backend returns the actual time the context was active, so skip
+* the calculation here for GuC.
+*/
+   if (active && !intel_engine_uses_guc(ce->engine))


What is the point of looking at ce->stats.active in GuC mode? I see that 
guc_context_update_stats/__guc_context_update_clks touches it, but I 
can't spot that there is a purpose to it. This is the only conditional 
reading it but it is short-circuited in GuC case.


Also, since a GuC only vfunc (update_stats) has been added, I wonder why 
not just fork the whole runtime query (ce->get_total_runtime_ns). I 
think that would end up cleaner.



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(>pin_count);
  }
@@ -351,7 +351,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >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..0a3290c99a31 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -55,6 +55,8 @@ struct intel_context_ops {
  
  	void (*sched_disable)(struct intel_context *ce);
  
+	void (*update_stats)(struct intel_context *ce);

+
void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
  
@@ -146,6 +148,7 @@ struct intel_context {

struct ewma_runtime avg;
u64 total;
u32 last;
+   u64 start_gt_clk;

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsi: add payload receiving code

2022-06-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsi: add payload receiving code
URL   : https://patchwork.freedesktop.org/series/105096/
State : warning

== Summary ==

Error: dim checkpatch failed
c041108e8df4 drm/i915/dsi: add payload receiving code
-:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#27: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:205:
+static int dsi_read_pkt_payld(struct intel_dsi_host *host,
+   u8 *rx_buf, size_t rx_len)

-:75: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#75: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:253:
+   payld_read = min(rx_len, (size_t)4*payld_dw);
  ^

-:78: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#78: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:256:
+   for (i = 0; i < payld_read; i++) {
+

-:82: CHECK:SPACING: spaces preferred around that '%' (ctx:VxV)
#82: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:260:
+   *(rx_buf + i) = (payld_data >> (8 * (i%4))) & 0xff;
  ^

total: 0 errors, 0 warnings, 4 checks, 111 lines checked

Re: [Intel-gfx] [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Imre Deak

On Tue, Jun 14, 2022 at 03:32:59PM +0300, Jani Nikula wrote:
> On Tue, 14 Jun 2022, Imre Deak  wrote:
> > The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
> > from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
> > registers are not read subsequently also as required.
> 
> Does it actually change the behaviour depending on whether the dpcd is
> read or not, or is this just about the resume path overwriting mgr->dpcd
> with stuff from DP_DPCD_REV?

Yes, the reading out DP_DP13_DPCD_REV has a side-effect, see
https://gitlab.freedesktop.org/drm/intel/-/issues/5292#note_1343399

> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
> reading the caps, which would normally set mgr->dpcd from
> DP_DP13_DPCD_REV.

Right, but at that point DP_DP13_DPCD_REV returns HBR2 w/o this change.

> BR,
> Jani.
> 
> >
> > Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
> > done during connector detection. While at it also fix up the same call
> > in drm_dp_mst_dump_topology().
> >
> > Cc: Lyude Paul 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 67b3b9697da7f..18f2b6075b780 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > if (!mgr->mst_primary)
> > goto out_fail;
> >  
> > -   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> > -  DP_RECEIVER_CAP_SIZE);
> > -   if (ret != DP_RECEIVER_CAP_SIZE) {
> > +   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
> > drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
> > suspend?\n");
> > goto out_fail;
> > }
> > @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> > u8 buf[DP_PAYLOAD_TABLE_SIZE];
> > int ret;
> >  
> > -   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
> > DP_RECEIVER_CAP_SIZE);
> > -   if (ret) {
> > +   if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
> > seq_printf(m, "dpcd read failed\n");
> > goto out;
> > }
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Do not enable PSR2/selective fetch if there are no planes

2022-06-14 Thread Hogander, Jouni

On Tue, 2022-06-14 at 15:22 +0300, Stanislav Lisovskiy wrote:
> We seem to enable PSR2 and selective fetch even if there are no
> active
> planes. That seems to causes FIFO underruns at least for ADLP.
> Those are gone if we don't do that. Just adding simple check
> in intel_psr2_sel_fetch_config_valid seems to do the trick.

We are already disabling PSR intel_psr_pre_plane_update if
active_planes is 0.

We are also checking active_planes in _intel_psr_post_plane_update and
not enabling PSR if it's 0.

So I'm now wondering what sequence this patch is actually changing?
I.e. where PSR is currently enabled/not disabled if active_planes == 0?

> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7d61c55184e5..03add69cfdca 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -747,6 +747,12 @@ static bool
> intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
>   return false;
>   }
>  
> + if (hweight32(crtc_state->active_planes) == 0) {
> + drm_dbg_kms(_priv->drm,
> + "PSR2 sel fetch not enabled, no
> active_planes\n");
> + return false;
> + }
> +
>   /* Wa_14010254185 Wa_14010103792 */
>   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
>   drm_dbg_kms(_priv->drm,

Re: [Intel-gfx] [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Jani Nikula

On Tue, 14 Jun 2022, Jani Nikula  wrote:
> On Tue, 14 Jun 2022, Imre Deak  wrote:
>> The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
>> from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
>> registers are not read subsequently also as required.
>
> Does it actually change the behaviour depending on whether the dpcd is
> read or not, or is this just about the resume path overwriting mgr->dpcd
> with stuff from DP_DPCD_REV?
>
> drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
> reading the caps, which would normally set mgr->dpcd from
> DP_DP13_DPCD_REV.

Oh,

Reviewed-by: Jani Nikula 

on the changes, I'm just wondering about the statement in the commit
message.



>
> BR,
> Jani.
>
>>
>> Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
>> done during connector detection. While at it also fix up the same call
>> in drm_dp_mst_dump_topology().
>>
>> Cc: Lyude Paul 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
>> Signed-off-by: Imre Deak 
>> ---
>>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> index 67b3b9697da7f..18f2b6075b780 100644
>> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
>> drm_dp_mst_topology_mgr *mgr,
>>  if (!mgr->mst_primary)
>>  goto out_fail;
>>  
>> -ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
>> -   DP_RECEIVER_CAP_SIZE);
>> -if (ret != DP_RECEIVER_CAP_SIZE) {
>> +if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>>  drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
>> suspend?\n");
>>  goto out_fail;
>>  }
>> @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>>  u8 buf[DP_PAYLOAD_TABLE_SIZE];
>>  int ret;
>>  
>> -ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
>> DP_RECEIVER_CAP_SIZE);
>> -if (ret) {
>> +if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>>  seq_printf(m, "dpcd read failed\n");
>>  goto out;
>>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Jani Nikula

On Tue, 14 Jun 2022, Imre Deak  wrote:
> The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
> from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
> registers are not read subsequently also as required.

Does it actually change the behaviour depending on whether the dpcd is
read or not, or is this just about the resume path overwriting mgr->dpcd
with stuff from DP_DPCD_REV?

drm_dp_mst_topology_mgr_set_mst() does use drm_dp_read_dpcd_caps() for
reading the caps, which would normally set mgr->dpcd from
DP_DP13_DPCD_REV.

BR,
Jani.

>
> Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
> done during connector detection. While at it also fix up the same call
> in drm_dp_mst_dump_topology().
>
> Cc: Lyude Paul 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 67b3b9697da7f..18f2b6075b780 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
> drm_dp_mst_topology_mgr *mgr,
>   if (!mgr->mst_primary)
>   goto out_fail;
>  
> - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> -DP_RECEIVER_CAP_SIZE);
> - if (ret != DP_RECEIVER_CAP_SIZE) {
> + if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
>   drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
> suspend?\n");
>   goto out_fail;
>   }
> @@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   u8 buf[DP_PAYLOAD_TABLE_SIZE];
>   int ret;
>  
> - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
> DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
>   seq_printf(m, "dpcd read failed\n");
>   goto out;
>   }

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH 1/1] drm/i915/dg2: Bump up CDCLK for DG2

2022-06-14 Thread Stanislav Lisovskiy

We seem to need this W/A same way as for TGL, in order
to fix some of the underruns, which we currently have and
those not related to PSR.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 6e80162632dd..86a22c3766e5 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2300,7 +2300,7 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
 
/*
-* HACK. Currently for TGL platforms we calculate
+* HACK. Currently for TGL/DG2 platforms we calculate
 * min_cdclk initially based on pixel_rate divided
 * by 2, accounting for also plane requirements,
 * however in some cases the lowest possible CDCLK
@@ -2308,7 +2308,7 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
 * Explicitly stating here that this seems to be currently
 * rather a Hack, than final solution.
 */
-   if (IS_TIGERLAKE(dev_priv)) {
+   if (IS_TIGERLAKE(dev_priv) || IS_DG2(dev_priv)) {
/*
 * Clamp to max_cdclk_freq in case pixel rate is higher,
 * in order not to break an 8K, but still leave W/A at place.
-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH 0/1] Bump up CDCLK for DG2

2022-06-14 Thread Stanislav Lisovskiy

We set it to be equal to pixel rate here, just same as
we have already for TGL, as that seems to be currently
the only solution to fix underruns, not related to PSR.

Stanislav Lisovskiy (1):
  drm/i915/dg2: Bump up CDCLK for DG2

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

-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH 1/1] drm/i915: Do not enable PSR2/selective fetch if there are no planes

2022-06-14 Thread Stanislav Lisovskiy

We seem to enable PSR2 and selective fetch even if there are no active
planes. That seems to causes FIFO underruns at least for ADLP.
Those are gone if we don't do that. Just adding simple check
in intel_psr2_sel_fetch_config_valid seems to do the trick.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7d61c55184e5..03add69cfdca 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -747,6 +747,12 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
 
+   if (hweight32(crtc_state->active_planes) == 0) {
+   drm_dbg_kms(_priv->drm,
+   "PSR2 sel fetch not enabled, no active_planes\n");
+   return false;
+   }
+
/* Wa_14010254185 Wa_14010103792 */
if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
drm_dbg_kms(_priv->drm,
-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH 0/1] Do not enable PSR2 if no active planes

2022-06-14 Thread Stanislav Lisovskiy

We seem to cause FIFO underruns by doing that.
Also it doesn't make sense. 

Stanislav Lisovskiy (1):
  drm/i915: Do not enable PSR2/selective fetch if there are no planes

 drivers/gpu/drm/i915/display/intel_psr.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.24.1.485.gad05a3d8e5

[Intel-gfx] [PATCH v3 7/8] drm: Remove linux/media-bus-format.h from drm_crtc.h

2022-06-14 Thread Ville Syrjala

From: Ville Syrjälä 

drm_crtc.h has no need for linux/media-bus-format.h, so don't
include it. Avoids useless rebuilds of the entire universe when
touching linux/media-bus-format.h.

Quite a few placs do currently depend on linux/media-bus-format.h
without actually including it directly. All of those need to be
fixed up.

v2: Deal with ingenic as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 1 +
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c   | 1 +
 drivers/gpu/drm/bridge/chipone-icn6211.c  | 1 +
 drivers/gpu/drm/bridge/display-connector.c| 1 +
 drivers/gpu/drm/bridge/fsl-ldb.c  | 1 +
 drivers/gpu/drm/bridge/ite-it66121.c  | 1 +
 drivers/gpu/drm/bridge/lontium-lt8912b.c  | 1 +
 drivers/gpu/drm/bridge/lontium-lt9211.c   | 1 +
 drivers/gpu/drm/bridge/lontium-lt9611.c   | 1 +
 drivers/gpu/drm/bridge/nwl-dsi.c  | 1 +
 drivers/gpu/drm/bridge/sii902x.c  | 1 +
 drivers/gpu/drm/bridge/tc358767.c | 1 +
 drivers/gpu/drm/bridge/tc358775.c | 1 +
 drivers/gpu/drm/bridge/ti-dlpc3433.c  | 1 +
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
 drivers/gpu/drm/bridge/ti-tfp410.c| 1 +
 drivers/gpu/drm/drm_bridge.c  | 1 +
 drivers/gpu/drm/drm_of.c  | 1 +
 drivers/gpu/drm/imx/imx-ldb.c | 1 +
 drivers/gpu/drm/imx/parallel-display.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
 drivers/gpu/drm/mediatek/mtk_dpi.c| 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 1 +
 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 +
 drivers/gpu/drm/panel/panel-raydium-rm67191.c | 1 +
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c   | 1 +
 drivers/gpu/drm/panel/panel-simple.c  | 1 +
 drivers/gpu/drm/pl111/pl111_display.c | 1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c   | 1 +
 drivers/gpu/drm/stm/ltdc.c| 1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 1 +
 drivers/gpu/drm/vc4/vc4_dpi.c | 1 +
 include/drm/drm_crtc.h| 1 -
 36 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cfe4fc69277e..58184cd6ab0b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index ba5f695703dc..ab63e7b11944 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index d25bc62bfebd..481c86b2406e 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/display-connector.c 
b/drivers/gpu/drm/bridge/display-connector.c
index e4d52a7e31b7..9a12449ad7b8 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index b2675c769a55..8d091521ccba 100644
--- a/drivers/gpu/drm/bridge/fsl-ldb.c
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
index 448c58e60c11..44278d54d35d 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -7,6 +7,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c 
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 6a7a6983e796..28bad30dc4e5 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c 
b/drivers/gpu/drm/bridge/lontium-lt9211.c
index

[Intel-gfx] [PATCH v3 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h

2022-06-14 Thread Ville Syrjala

From: Ville Syrjälä 

drm_crtc.h has no need for drm_frambuffer.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_framebuffer.h.

Quite a few placs do currently depend on drm_framebuffer.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up msm some more
v2: Deal with ingenic and shmobile as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h  | 1 +
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c | 1 +
 drivers/gpu/drm/arm/malidp_crtc.c| 1 +
 drivers/gpu/drm/arm/malidp_mw.c  | 1 +
 drivers/gpu/drm/arm/malidp_planes.c  | 1 +
 drivers/gpu/drm/armada/armada_fb.h   | 2 ++
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 1 +
 drivers/gpu/drm/drm_atomic.c | 1 +
 drivers/gpu/drm/drm_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_atomic_state_helper.c| 1 +
 drivers/gpu/drm/drm_atomic_uapi.c| 1 +
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_crtc_helper.c| 1 +
 drivers/gpu/drm/drm_damage_helper.c  | 1 +
 drivers/gpu/drm/drm_fb_helper.c  | 1 +
 drivers/gpu/drm/drm_gem_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_mipi_dbi.c   | 1 +
 drivers/gpu/drm/drm_mode_config.c| 1 +
 drivers/gpu/drm/drm_modeset_helper.c | 1 +
 drivers/gpu/drm/drm_writeback.c  | 1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c| 1 +
 drivers/gpu/drm/exynos/exynos7_drm_decon.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c  | 1 +
 drivers/gpu/drm/gma500/framebuffer.c | 1 +
 drivers/gpu/drm/gma500/gma_display.c | 1 +
 drivers/gpu/drm/gma500/oaktrail_crtc.c   | 1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 1 +
 drivers/gpu/drm/i915/display/intel_display_types.h   | 1 +
 drivers/gpu/drm/imx/dcss/dcss-plane.c| 1 +
 drivers/gpu/drm/imx/ipuv3-plane.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 1 +
 drivers/gpu/drm/ingenic/ingenic-ipu.c| 1 +
 drivers/gpu/drm/kmb/kmb_plane.c  | 1 +
 drivers/gpu/drm/logicvc/logicvc_layer.c  | 1 +
 drivers/gpu/drm/mcde/mcde_display.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
 drivers/gpu/drm/meson/meson_overlay.c| 1 +
 drivers/gpu/drm/meson/meson_plane.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c   | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 1 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp_format.c| 2 ++
 drivers/gpu/drm/msm/msm_debugfs.c| 1 +
 drivers/gpu/drm/msm/msm_fb.c | 1 +
 drivers/gpu/drm/msm/msm_fbdev.c  | 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c| 1 +
 drivers/gpu/drm/omapdrm/omap_debugfs.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 1 +
 drivers/gpu/drm/pl111/pl111_display.c| 1 +
 drivers/gpu/drm/pl111/pl111_drv.c| 1 +
 drivers/gpu/drm/pl111/pl111_versatile.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_display.c| 1 +
 drivers/gpu/drm/qxl/qxl_draw.c   | 1 +
 drivers/gpu/drm/radeon/atombios_crtc.c

[Intel-gfx] [PATCH] drm/dp/mst: Read the extended DPCD capabilities during system resume

2022-06-14 Thread Imre Deak

The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
registers are not read subsequently also as required.

Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
done during connector detection. While at it also fix up the same call
in drm_dp_mst_dump_topology().

Cc: Lyude Paul 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 67b3b9697da7f..18f2b6075b780 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3860,9 +3860,7 @@ int drm_dp_mst_topology_mgr_resume(struct 
drm_dp_mst_topology_mgr *mgr,
if (!mgr->mst_primary)
goto out_fail;
 
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
-  DP_RECEIVER_CAP_SIZE);
-   if (ret != DP_RECEIVER_CAP_SIZE) {
+   if (drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd) < 0) {
drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during 
suspend?\n");
goto out_fail;
}
@@ -4911,8 +4909,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
u8 buf[DP_PAYLOAD_TABLE_SIZE];
int ret;
 
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
DP_RECEIVER_CAP_SIZE);
-   if (ret) {
+   if (drm_dp_read_dpcd_caps(mgr->aux, buf) < 0) {
seq_printf(m, "dpcd read failed\n");
goto out;
}
-- 
2.30.2

Re: [Intel-gfx] [PATCH v2] drm/i915: Support Async Flip on Linear buffers

2022-06-14 Thread Murthy, Arun R

Any comments?

Thanks and Regards,
Arun R Murthy


> -Original Message-
> From: Murthy, Arun R 
> Sent: Wednesday, June 1, 2022 9:54 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; B S, Karthik ;
> Murthy, Arun R 
> Subject: [PATCH v2] drm/i915: Support Async Flip on Linear buffers
> 
> Starting from Gen12 Async Flip is supported on linear buffers.
> This patch enables support for async on linear buffer.
> 
> UseCase: In Hybrid graphics, for harware unsupported pixel formats it will be
> converted to linear memory and then composed.
> 
> v2: Added use case
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e71b69425309..da2df7239353 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7524,6 +7524,13 @@ static int intel_async_flip_check_hw(struct
> intel_atomic_state *state, struct in
>* this selectively if required.
>*/
>   switch (new_plane_state->hw.fb->modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + if (DISPLAY_VER(i915) < 12) {
> + drm_dbg_kms(>drm,
> + "[PLANE:%d:%s] Modifier does not
> support async flips\n",
> + plane->base.base.id, plane-
> >base.name);
> + return -EINVAL;
> + }
>   case I915_FORMAT_MOD_X_TILED:
>   case I915_FORMAT_MOD_Y_TILED:
>   case I915_FORMAT_MOD_Yf_TILED:
> --
> 2.25.1

[Intel-gfx] [PATCH v2 2/8] drm: Drop drm_framebuffer.h from drm_crtc.h

2022-06-14 Thread Ville Syrjala

From: Ville Syrjälä 

drm_crtc.h has no need for drm_frambuffer.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_framebuffer.h.

Quite a few placs do currently depend on drm_framebuffer.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up msm some more

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h  | 1 +
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c | 1 +
 drivers/gpu/drm/arm/malidp_crtc.c| 1 +
 drivers/gpu/drm/arm/malidp_mw.c  | 1 +
 drivers/gpu/drm/arm/malidp_planes.c  | 1 +
 drivers/gpu/drm/armada/armada_fb.h   | 2 ++
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 1 +
 drivers/gpu/drm/drm_atomic.c | 1 +
 drivers/gpu/drm/drm_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_atomic_state_helper.c| 1 +
 drivers/gpu/drm/drm_atomic_uapi.c| 1 +
 drivers/gpu/drm/drm_crtc.c   | 1 +
 drivers/gpu/drm/drm_crtc_helper.c| 1 +
 drivers/gpu/drm/drm_damage_helper.c  | 1 +
 drivers/gpu/drm/drm_fb_helper.c  | 1 +
 drivers/gpu/drm/drm_gem_atomic_helper.c  | 1 +
 drivers/gpu/drm/drm_mipi_dbi.c   | 1 +
 drivers/gpu/drm/drm_mode_config.c| 1 +
 drivers/gpu/drm/drm_modeset_helper.c | 1 +
 drivers/gpu/drm/drm_writeback.c  | 1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c| 1 +
 drivers/gpu/drm/exynos/exynos7_drm_decon.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c  | 1 +
 drivers/gpu/drm/gma500/framebuffer.c | 1 +
 drivers/gpu/drm/gma500/gma_display.c | 1 +
 drivers/gpu/drm/gma500/oaktrail_crtc.c   | 1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 1 +
 drivers/gpu/drm/i915/display/intel_display_types.h   | 1 +
 drivers/gpu/drm/imx/dcss/dcss-plane.c| 1 +
 drivers/gpu/drm/imx/ipuv3-plane.c| 1 +
 drivers/gpu/drm/kmb/kmb_plane.c  | 1 +
 drivers/gpu/drm/logicvc/logicvc_layer.c  | 1 +
 drivers/gpu/drm/mcde/mcde_display.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
 drivers/gpu/drm/meson/meson_overlay.c| 1 +
 drivers/gpu/drm/meson/meson_plane.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c   | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 1 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c   | 1 +
 drivers/gpu/drm/msm/disp/mdp_format.c| 2 ++
 drivers/gpu/drm/msm/msm_debugfs.c| 1 +
 drivers/gpu/drm/msm/msm_fb.c | 1 +
 drivers/gpu/drm/msm/msm_fbdev.c  | 1 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c| 1 +
 drivers/gpu/drm/omapdrm/omap_debugfs.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 1 +
 drivers/gpu/drm/pl111/pl111_display.c| 1 +
 drivers/gpu/drm/pl111/pl111_drv.c| 1 +
 drivers/gpu/drm/pl111/pl111_versatile.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_display.c| 1 +
 drivers/gpu/drm/qxl/qxl_draw.c   | 1 +
 drivers/gpu/drm/radeon/atombios_crtc.c   | 1 +
 drivers/gpu/drm/radeon/evergreen.c   | 1 +
 drivers/gpu/drm/radeon/r100.c| 1 +

[Intel-gfx] [PATCH v2 1/8] drm: Drop drm_edid.h from drm_crtc.h

2022-06-14 Thread Ville Syrjala

From: Ville Syrjälä 

drm_crtc.h has no need for drm_edid.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_edid.h.

Quite a few placs do currently depend on drm_edid.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up i915 and msm some more

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/malidp_mw.c | 1 +
 drivers/gpu/drm/aspeed/aspeed_gfx_out.c | 1 +
 drivers/gpu/drm/ast/ast_mode.c  | 1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c  | 1 +
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 +
 drivers/gpu/drm/bridge/lontium-lt8912b.c| 1 +
 drivers/gpu/drm/bridge/parade-ps8640.c  | 1 +
 drivers/gpu/drm/bridge/simple-bridge.c  | 1 +
 drivers/gpu/drm/bridge/ti-tfp410.c  | 1 +
 drivers/gpu/drm/display/drm_dp_helper.c | 1 +
 drivers/gpu/drm/display/drm_dp_mst_topology.c   | 1 +
 drivers/gpu/drm/drm_client_modeset.c| 1 +
 drivers/gpu/drm/drm_kms_helper_common.c | 1 +
 drivers/gpu/drm/drm_modes.c | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c   | 1 +
 drivers/gpu/drm/gma500/cdv_intel_dp.c   | 1 +
 drivers/gpu/drm/gma500/oaktrail_hdmi.c  | 1 +
 drivers/gpu/drm/gma500/oaktrail_lvds.c  | 1 +
 drivers/gpu/drm/gma500/psb_intel_modes.c| 2 ++
 drivers/gpu/drm/gud/gud_connector.c | 1 +
 drivers/gpu/drm/i915/display/intel_bios.c   | 1 +
 drivers/gpu/drm/i915/display/intel_dp.c | 1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c | 1 +
 drivers/gpu/drm/i915/display/intel_opregion.c   | 2 ++
 drivers/gpu/drm/imx/imx-ldb.c   | 1 +
 drivers/gpu/drm/imx/imx-tve.c   | 1 +
 drivers/gpu/drm/imx/parallel-display.c  | 1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c   | 2 ++
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c  | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 +
 drivers/gpu/drm/panel/panel-edp.c   | 1 +
 drivers/gpu/drm/panel/panel-simple.c| 1 +
 drivers/gpu/drm/qxl/qxl_display.c   | 1 +
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 1 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c  | 1 +
 drivers/gpu/drm/solomon/ssd130x.c   | 1 +
 drivers/gpu/drm/stm/ltdc.c  | 1 +
 drivers/gpu/drm/tiny/arcpgu.c   | 1 +
 drivers/gpu/drm/tiny/bochs.c| 1 +
 drivers/gpu/drm/tiny/cirrus.c   | 1 +
 drivers/gpu/drm/tiny/gm12u320.c | 1 +
 drivers/gpu/drm/udl/udl_connector.c | 1 +
 drivers/gpu/drm/vboxvideo/vbox_mode.c   | 1 +
 drivers/gpu/drm/virtio/virtgpu_display.c| 1 +
 drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
 drivers/gpu/drm/vkms/vkms_output.c  | 1 +
 drivers/gpu/drm/vkms/vkms_writeback.c   | 1 +
 include/drm/drm_crtc.h  | 1 -
 49 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 204c869d9fe2..43de2ac8f27e 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
index 6759cb88415a..4f2187025a21 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "aspeed_gfx.h"
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index db2010a55674..3eb9afecd9d4 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 01c8b80e34ec..8aadcc0aa90b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 67f0f444b4e8..ba5f695703dc 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c

Re: [Intel-gfx] [PATCH 0/6] Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-06-14 Thread Gwan-gyeong Mun





On 6/3/22 4:19 PM, Jani Nikula wrote:

On Fri, 03 Jun 2022, Gwan-gyeong Mun  wrote:

This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead of a more suitable long.


So when are we going to start moving the helpers, both existing and the
ones being added here, from i915_utils.h to proper kernel headers? We
just keep adding more and more. This needs to stop.

BR,
Jani.



Thanks for your comments.

The following two macros have been added to i915_utils.h in this patch 
series.


#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
The reason this macro was added is that there was a possibility that an 
overflow could occur in the code that is passed as a function parameter 
in the form of "offset >> PAGE_SHIFT" for the offset variable of 
unsigned int type in the code. Therefore this macro added so that we can 
check this part at the code level.
After checking all of this type of overflow problem in the i915 driver 
code, it is thought that it will be possible to remove it through 
refactoring in the future.


So, in my opinion, there is no need to move this macro to 
include/linux/types.h or other header files.



#define safe_conversion(ptr, value) ({ \
typeof(value) __v = (value); \
typeof(ptr) __ptr = (ptr); \
overflows_type(__v, *__ptr) ? 0 : (*__ptr = (typeof(*__ptr))__v), 1; \
})
The above macro depends on overflows_type(), and overflows_type() is 
defined in i915_utils.h in the same way.
To move the safe_conversion() macro to a commonly available header, the 
overflows_type() macro must also be moved, and if the name or type of 
this macro is changed, all other code using overflows_type() will be 
affected. In this patch, safe_conversion() is added to i915_utils.h, and 
it seems to be prepared and moved to the next patch.


If you absolutely need to move the safe_conversion() macro to a common 
header in this patch series, please let me know and I will update this 
patch series.


Br,

G.G.

[Intel-gfx] [PATCH] drm/i915/dsi: add payload receiving code

2022-06-14 Thread William Tseng

To support Host to read data from Peripheral after
a DCS read command is sent over DSI.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Vandita Kulkarni 
Cc: Lee Shawn C 
Signed-off-by: William Tseng 
---
 drivers/gpu/drm/i915/display/icl_dsi.c  | 68 -
 drivers/gpu/drm/i915/display/icl_dsi_regs.h | 13 
 2 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 19bf717fd4cb..a9a152ffcaef 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -201,6 +201,68 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
return 0;
 }
 
+static int dsi_read_pkt_payld(struct intel_dsi_host *host,
+   u8 *rx_buf, size_t rx_len)
+{
+   struct intel_dsi *intel_dsi = host->intel_dsi;
+   struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
+   enum transcoder dsi_trans = dsi_port_to_transcoder(host->port);
+   u32 tmp, /*hdr_data, */payld_data;
+   u32 payld_dw;
+   size_t payld_read;
+   u8 i;
+
+   /* step2: place a BTA reque */
+   /* check if header credit available */
+   if (!wait_for_header_credits(dev_priv, dsi_trans, 1))
+   return -EBUSY;
+
+   /* place BTA request */
+   tmp = intel_de_read(dev_priv, DSI_LP_MSG(dsi_trans));
+   tmp |= LINK_BTA;
+   intel_de_write(dev_priv, DSI_LP_MSG(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_LP_MSG(dsi_trans));
+
+   /* step2a:  */
+   /* step2ai: set Turn-Around Timeout */
+   tmp = intel_de_read(dev_priv, DSI_TA_TO(dsi_trans));
+   tmp &= ~TA_TIMEOUT_VALUE_MASK;
+   tmp |= TA_TIMEOUT_VALUE(intel_dsi->turn_arnd_val);
+   intel_de_write(dev_priv, DSI_TA_TO(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_TA_TO(dsi_trans));
+
+   /* step2aii: set maximum allowed time */
+   tmp = intel_de_read(dev_priv, DSI_LPRX_HOST_TO(dsi_trans));
+   tmp &= ~LPRX_TIMEOUT_VALUE_MASK;
+   tmp |= LPRX_TIMEOUT_VALUE(intel_dsi->lp_rx_timeout);
+   intel_de_write(dev_priv, DSI_LPRX_HOST_TO(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_LPRX_HOST_TO(dsi_trans));
+
+   /* step4a: wait and read payload */
+   if (wait_for_us(((intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans)) &
+   NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT) > 0, 
10)) {
+   drm_err(_priv->drm, "DSI fails to receive payload\n");
+   return -EBUSY;
+   }
+
+   tmp = intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans));
+   payld_dw = (tmp & NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT;
+   payld_read = min(rx_len, (size_t)4*payld_dw);
+
+   for (i = 0; i < payld_read; i++) {
+
+   if ((i % 4) == 0)
+   payld_data = intel_de_read(dev_priv, 
DSI_CMD_RXPYLD(dsi_trans));
+
+   *(rx_buf + i) = (payld_data >> (8 * (i%4))) & 0xff;
+   }
+
+   return 0;
+}
+
 void icl_dsi_frame_update(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1078,8 +1140,8 @@ static void gen11_dsi_setup_timeouts(struct intel_encoder 
*encoder,
mul = 8 * 100;
hs_tx_timeout = DIV_ROUND_UP(intel_dsi->hs_tx_timeout * mul,
 divisor);
-   lp_rx_timeout = DIV_ROUND_UP(intel_dsi->lp_rx_timeout * mul, divisor);
-   ta_timeout = DIV_ROUND_UP(intel_dsi->turn_arnd_val * mul, divisor);
+   lp_rx_timeout = intel_dsi->lp_rx_timeout;
+   ta_timeout = intel_dsi->turn_arnd_val;
 
for_each_dsi_port(port, intel_dsi->ports) {
dsi_trans = dsi_port_to_transcoder(port);
@@ -1838,6 +1900,8 @@ static ssize_t gen11_dsi_host_transfer(struct 
mipi_dsi_host *host,
return ret;
 
//TODO: add payload receive code if needed
+   if (msg->rx_buf && msg->rx_len > 0)
+   dsi_read_pkt_payld(intel_dsi_host, msg->rx_buf, msg->rx_len);
 
ret = sizeof(dsi_pkt.header) + dsi_pkt.payload_length;
 
diff --git a/drivers/gpu/drm/i915/display/icl_dsi_regs.h 
b/drivers/gpu/drm/i915/display/icl_dsi_regs.h
index f78f28b8dd94..a77a49b42d60 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi_regs.h
+++ b/drivers/gpu/drm/i915/display/icl_dsi_regs.h
@@ -251,6 +251,18 @@
 #define  NUMBER_RX_PLOAD_DW_MASK   (0xff << 0)
 #define  NUMBER_RX_PLOAD_DW_SHIFT  0
 
+#define _DSI_CMD_RXHDR_0   0x6b0e0
+#define _DSI_CMD_RXHDR_1   0x6b8e0
+#define DSI_CMD_RXHDR(tc)  _MMIO_DSI(tc,   \
+ _DSI_CMD_RXHDR_0,\
+ _DSI_CMD_RXHDR_1)
+
+#define _DSI_CMD_RXPYLD_0  0x6b0e4
+#define _DSI_CMD_RXPYLD_1  0x6b8e4
+#define DSI_CMD_RXPYLD(tc) _MMIO_DSI(tc,   \
+

Re: [Intel-gfx] [PATCH 0/8] drm: Clean up drm_crtc.h

2022-06-14 Thread Jani Nikula

On Mon, 13 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Eliminate unnecessary includes from drm_crtc.h to avoid
> pointless rebuilds of the entire universe when touching
> some random header.
>
> I didn't really feel like splitting this up per-driver since
> that would have ended up being metric ton of one liners.
> I'm thinking the conflicts (if any) should be trivial enough
> to deal with even with bigger patches.
>
> Also the cc list would have been massive so didn't do it.
> Hopefully enough people actually read dri-devel...

Seems like a good idea to me. FWIW,

Acked-by: Jani Nikula 

Both the CI and the kernel bot found some issues, obviously those need
to be addressed, but otherwise I'd just rely on build results for
merging.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915: Improve user experience and driver robustness under SIGINT or similar

2022-06-14 Thread Tvrtko Ursulin




Final call to raise objections.

Regards,

Tvrtko

On 07/06/2022 09:36, Tvrtko Ursulin wrote:


On 27/05/2022 13:07, Andrzej Hajda wrote:

On 27.05.2022 09:24, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

We have long standing customer complaints that pressing Ctrl-C (or to 
the

effect of) causes engine resets with otherwise well behaving programs.

Not only is logging engine resets during normal operation not desirable
since it creates support incidents, but more fundamentally we should 
avoid
going the engine reset path when we can since any engine reset 
introduces

a chance of harming an innocent context.

Reason for this undesirable behaviour is that the driver currently does
not distinguish between banned contexts and non-persistent contexts 
which

have been closed.

To fix this we add the distinction between the two reasons for revoking
contexts, which then allows the strict timeout only be applied to 
banned,

while innocent contexts (well behaving) can preempt cleanly and exit
without triggering the engine reset path.

Note that the added context exiting category applies both to closed non-
persistent context, and any exiting context when hangcheck has been
disabled by the user.

At the same time we rename the backend operation from 'ban' to 'revoke'
which more accurately describes the actual semantics. (There is no 
ban at

the backend level since banning is a concept driven by the scheduling
frontend. Backends are simply able to revoke a running context so that
is the more appropriate name chosen.)

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 23 +++--
  drivers/gpu/drm/i915/gt/intel_context.c   | 24 ++
  drivers/gpu/drm/i915/gt/intel_context.h   | 25 +--
  drivers/gpu/drm/i915/gt/intel_context_types.h |  4 ++-
  .../drm/i915/gt/intel_execlists_submission.c  |  6 ++---
  .../gpu/drm/i915/gt/intel_ring_submission.c   |  7 +++---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
  drivers/gpu/drm/i915/i915_request.c   |  2 +-
  8 files changed, 77 insertions(+), 29 deletions(-)

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

index ab4c5ab28e4d..6b171c89b1b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1367,7 +1367,8 @@ static struct intel_engine_cs 
*active_engine(struct intel_context *ce)

  return engine;
  }
-static void kill_engines(struct i915_gem_engines *engines, bool ban)
+static void
+kill_engines(struct i915_gem_engines *engines, bool exit, bool 
persistent)

  {
  struct i915_gem_engines_iter it;
  struct intel_context *ce;
@@ -1381,9 +1382,15 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

   */
  for_each_gem_engine(ce, engines, it) {
  struct intel_engine_cs *engine;
+    bool skip = false;
-    if (ban && intel_context_ban(ce, NULL))
-    continue;
+    if (exit)
+    skip = intel_context_set_exiting(ce);
+    else if (!persistent)
+    skip = intel_context_exit_nonpersistent(ce, NULL);
+
+    if (skip)
+    continue; /* Already marked. */


why not:
 if (exit && intel_context_set_exiting(ce))
 continue;
 else if (!persistent && intel_context_exit_nonpersistent(ce, NULL)
 continue;


Just so I can put the "already marked" comment on single line.



Anyway:
Reviewed-by: Andrzej Hajda 


Thanks!

John, Daniel - you had reservations against the older version of this 
patch AFAIR. This time round I believe I conceptually simplified it by 
doing a clean separation of contexts which should not be scheduled any 
more becuase they want it so, versus the ones we banned. That is, the 
patch stops abusing the banned status for contexts which haven't been 
(banned). This allows to only apply the strict preempt timeout to 
banned, while there is no reason to add any new timeout values for the 
rest.


Any objections to this version?

Regards,

Tvrtko



Regards
Andrzej


  /*
   * Check the current active state of this context; if we
@@ -1395,7 +1402,7 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

  engine = active_engine(ce);
  /* First attempt to gracefully cancel the context */
-    if (engine && !__cancel_engine(engine) && ban)
+    if (engine && !__cancel_engine(engine) && (exit || 
!persistent))

  /*
   * If we are unable to send a preemptive pulse to bump
   * the context from the GPU, we have to resort to a full
@@ -1407,8 +1414,6 @@ static void kill_engines(struct 
i915_gem_engines *engines, bool ban)

  static void kill_context(struct i915_gem_context *ctx)
  {
-    bool ban = (!i915_gem_context_is_persistent(ctx) ||
-    !ctx->i915->params.enable_hangcheck);
  struct i915_gem_engines *pos, *next;

Re: [Intel-gfx] [PATCH 00/15] HuC loading for DG2

2022-06-14 Thread Tvrtko Ursulin




On 13/06/2022 19:13, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 10:39 AM, Tvrtko Ursulin wrote:

On 13/06/2022 18:06, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:56 AM, Tvrtko Ursulin wrote:

On 13/06/2022 17:41, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 9:31 AM, Tvrtko Ursulin wrote:


On 13/06/2022 16:39, Ceraolo Spurio, Daniele wrote:

On 6/13/2022 1:16 AM, Tvrtko Ursulin wrote:


On 10/06/2022 00:19, Daniele Ceraolo Spurio wrote:
On DG2, HuC loading is performed by the GSC, via a PXP command. 
The load
operation itself is relatively simple (just send a message to 
the GSC
with the physical address of the HuC in LMEM), but there are 
timing
changes that requires special attention. In particular, to send 
a PXP
command we need to first export the GSC driver and then wait 
for the
mei-gsc and mei-pxp modules to start, which means that HuC load 
will
complete after i915 load is complete. This means that there is 
a small

window of time after i915 is registered and before HuC is loaded
during which userspace could submit and/or checking the HuC 
load status,
although this is quite unlikely to happen (HuC is usually 
loaded before

kernel init/resume completes).
We've consulted with the media team in regards to how to handle 
this and

they've asked us to do the following:

1) Report HuC as loaded in the getparam IOCTL even if load is 
still in
progress. The media driver uses the IOCTL as a way to check if 
HuC is
enabled and then includes a secondary check in the batches to 
get the
actual status, so doing it this way allows userspace to keep 
working

without changes.

2) Stall all userspace VCS submission until HuC is loaded. 
Stalls are
expected to be very rare (if any), due to the fact that HuC is 
usually

loaded before kernel init/resume is completed.


Motivation to add these complications into i915 are not clear to 
me here. I mean there is no HuC on DG2 _yet_ is the premise of 
the series, right? So no backwards compatibility concerns. In 
this case why jump through the hoops and not let userspace 
handle all of this by just leaving the getparam return the true 
status?


The main areas impacted by the fact that we can't guarantee that 
HuC load is complete when i915 starts accepting submissions are 
boot and suspend/resume, with the latter being the main problem; 
GT reset is not a concern because HuC now survives it. A 
suspend/resume can be transparent to userspace and therefore the 
HuC status can temporarily flip from loaded to not without 
userspace knowledge, especially if we start going into deeper 
suspend states and start causing HuC resets when we go into 
runtime suspend. Note that this is different from what happens 
during GT reset for older platforms, because in that scenario we 
guarantee that HuC reload is complete before we restart the 
submission back-end, so userspace doesn't notice that the HuC 
status change. We had an internal discussion about this problem 
with both media and i915 archs and the conclusion was that the 
best option is for i915 to stall media submission while HuC 
(re-)load is in progress.


Resume is potentialy a good reason - I did not pick up on that 
from the cover letter. I read the statement about the unlikely and 
small window where HuC is not loaded during kernel init/resume and 
I guess did not pick up on the resume part.


Waiting for GSC to load HuC from i915 resume is not an option?


GSC is an aux device exported by i915, so AFAIU GSC resume can't 
start until i915 resume completes.


I'll dig into this in the next few days since I want to understand 
how exactly it works. Or someone can help explain.


If in the end conclusion will be that i915 resume indeed cannot wait 
for GSC, then I think auto-blocking of queued up contexts on media 
engines indeed sounds unavoidable. Otherwise, as you explained, user 
experience post resume wouldn't be good.


Even if we could implement a wait, I'm not sure we should. GSC resume 
and HuC reload takes ~300ms in most cases, I don't think we want to 
block within the i915 resume path for that long.


Yeah maybe not. But entertaining the idea that it is technically 
possible to block - we could perhaps add uapi for userspace to mark 
contexts which want HuC access. Then track if there are any such 
contexts with outstanding submissions and only wait in resume if there 
are. If that would end up significantly less code on the i915 side to 
maintain is an open.


What would be the end result from users point of view in case where it 
suspended during video playback? The proposed solution from this 
series sees the video stuck after resume. Maybe compositor blocks as 
well since I am not sure how well they handle one window not providing 
new data. Probably depends on the compositor.


And then with a simpler solution definitely the whole resume would be 
delayed by 300ms.


With my ChromeOS hat the stalled media engines does sound like a 
better solution. But with the maintainer hat I'd like all

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel-gpu-top: Optimise the scanning loop a bit

2022-06-14 Thread Tvrtko Ursulin




+ Umesh

If you have time this is an easy improvement extracted from the "vendor 
agnostic gputop" series.


Regards,

Tvrtko

On 06/06/2022 14:27, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Opendir(3) and fdopendir(3) are quite expensive system calls when ran in
a loop which iterates all processes in a system times all open files in
each.

Replace some of them (easy ones) with simpler open(2)/read(2) combo to
avoid hammering on the malloc/free.

This brings the default CPU usage of the tool on my desktop from ~3% to
~2%.

Signed-off-by: Tvrtko Ursulin 
---
  tools/intel_gpu_top.c | 66 +++
  1 file changed, 29 insertions(+), 37 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 997aff582ff7..6de8a164fcff 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1022,12 +1022,12 @@ static void free_clients(struct clients *clients)
free(clients);
  }
  
-static bool is_drm_fd(DIR *fd_dir, const char *name)

+static bool is_drm_fd(int fd_dir, const char *name)
  {
struct stat stat;
int ret;
  
-	ret = fstatat(dirfd(fd_dir), name, , 0);

+   ret = fstatat(fd_dir, name, , 0);
  
  	return ret == 0 &&

   (stat.st_mode & S_IFMT) == S_IFCHR &&
@@ -1054,12 +1054,12 @@ static bool get_task_name(const char *buffer, char 
*out, unsigned long sz)
return true;
  }
  
-static DIR *opendirat(DIR *at, const char *name)

+static DIR *opendirat(int at, const char *name)
  {
DIR *dir;
int fd;
  
-	fd = openat(dirfd(at), name, O_DIRECTORY);

+   fd = openat(at, name, O_DIRECTORY);
if (fd < 0)
return NULL;
  
@@ -1070,37 +1070,27 @@ static DIR *opendirat(DIR *at, const char *name)

return dir;
  }
  
-static FILE *fropenat(DIR *at, const char *name)

+static size_t readat2buf(int at, const char *name, char *buf, const size_t sz)
  {
-   FILE *f;
+   ssize_t count;
int fd;
  
-	fd = openat(dirfd(at), name, O_RDONLY);

-   if (fd < 0)
-   return NULL;
+   fd = openat(at, name, O_RDONLY);
+   if (fd <= 0)
+   return 0;
  
-	f = fdopen(fd, "r");

-   if (!f)
-   close(fd);
+   count = read(fd, buf, sz - 1);
+   close(fd);
  
-	return f;

-}
+   if (count > 0) {
+   buf[count] = 0;
  
-static size_t freadat2buf(char *buf, const size_t sz, DIR *at, const char *name)

-{
-   size_t count;
-   FILE *f;
+   return count;
+   } else {
+   buf[0] = 0;
  
-	f = fropenat(at, name);

-   if (!f)
return 0;
-
-   buf[sz - 1] = 0;
-   count = fread(buf, 1, sz, f);
-   buf[count - 1] = 0;
-   fclose(f);
-
-   return count;
+   }
  }
  
  static struct clients *scan_clients(struct clients *clients, bool display)

@@ -1126,10 +1116,11 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
return clients;
  
  	while ((proc_dent = readdir(proc_dir)) != NULL) {

-   DIR *pid_dir = NULL, *fd_dir = NULL, *fdinfo_dir = NULL;
+   int pid_dir = -1, fd_dir = -1;
struct dirent *fdinfo_dent;
char client_name[64] = { };
unsigned int client_pid;
+   DIR *fdinfo_dir = NULL;
char buf[4096];
size_t count;
  
@@ -1138,11 +1129,12 @@ static struct clients *scan_clients(struct clients *clients, bool display)

if (!isdigit(proc_dent->d_name[0]))
continue;
  
-		pid_dir = opendirat(proc_dir, proc_dent->d_name);

-   if (!pid_dir)
+   pid_dir = openat(dirfd(proc_dir), proc_dent->d_name,
+O_DIRECTORY | O_RDONLY);
+   if (pid_dir < 0)
continue;
  
-		count = freadat2buf(buf, sizeof(buf), pid_dir, "stat");

+   count = readat2buf(pid_dir, "stat", buf, sizeof(buf));
if (!count)
goto next;
  
@@ -1153,8 +1145,8 @@ static struct clients *scan_clients(struct clients *clients, bool display)

if (!get_task_name(buf, client_name, sizeof(client_name)))
goto next;
  
-		fd_dir = opendirat(pid_dir, "fd");

-   if (!fd_dir)
+   fd_dir = openat(pid_dir, "fd", O_DIRECTORY | O_RDONLY);
+   if (fd_dir < 0)
goto next;
  
  		fdinfo_dir = opendirat(pid_dir, "fdinfo");

@@ -1196,10 +1188,10 @@ static struct clients *scan_clients(struct clients 
*clients, bool display)
  next:
if (fdinfo_dir)
closedir(fdinfo_dir);
-   if (fd_dir)
-   closedir(fd_dir);
-   if (pid_dir)
-   closedir(pid_dir);
+   if (fd_dir >= 0)
+   close(fd_dir);
+   if (pid_dir >= 0)
+

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Tvrtko Ursulin




On 14/06/2022 00:39, Matthew Brost wrote:

On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:


On 13/06/2022 16:05, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 09:24:18AM +0100, Tvrtko Ursulin wrote:


On 10/06/2022 17:14, Niranjana Vishwanathapura wrote:

On Fri, Jun 10, 2022 at 05:48:39PM +0300, Lionel Landwerlin wrote:

On 10/06/2022 13:37, Tvrtko Ursulin wrote:


On 10/06/2022 08:07, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura

---
   Documentation/gpu/rfc/i915_vm_bind.h | 490
+++
   1 file changed, 490 insertions(+)
   create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git
a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND
timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND    57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not
support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3
ioctl which will not accept any
+ * execlist (See struct
drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND    (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they
complete in reasonable amount of time.
+ * Compute on the other hand can be long
running. Hence it is not appropriate
+ * for compute contexts to export request
completion dma-fence to user.
+ * The dma-fence usage will be limited to
in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See
_i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl
call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND    0x3d
+#define DRM_I915_GEM_VM_UNBIND    0x3e
+#define DRM_I915_GEM_EXECBUFFER3    0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE    0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct
drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND
ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the
section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique
(ie., not currently bound) and can
+ * be mapped to whole object or a section
of the object (partial binding).
+ * Multiple VA mappings can be created to
the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to
use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND
calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should
be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device
local-memory and has compact page
+ * table. On those platforms, for binding
device local-memory objects, the
+ * @start should be 2M aligned, @offset and
@length should be 64K aligned.
+ * Also, on those platforms, it is not
allowed to bind an device local-memory
+ * object and a system memory object in a
single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+    /** @vm_id: VM (address space) id to bind */
+    __u32 vm_id;
+
+    /** @queue_idx: Index of queue for binding */
+    __u32 queue_idx;


I have a question here to which I did not find
an answer by browsing the old threads.

Queue index

Re: [Intel-gfx] [Intel-gfx 1/1] drm/i915/guc: Don't update engine busyness stats too frequently

2022-06-14 Thread Tvrtko Ursulin




On 14/06/2022 02:10, Umesh Nerlige Ramappa wrote:

On Sat, Jun 11, 2022 at 10:27:11AM -0700, Alan Previn wrote:

Using igt's gem-create and with additional patches to track object
creation time, it was measured that guc_update_engine_gt_clks was
getting called over 188 thousand times in the span of 15 seconds
(running the test three times).

Get a jiffies sample on every trigger and ensure we skip sampling
if we are being called too soon. Use half of the ping_delay as a
safe threshold.

NOTE: with this change, the number of calls went down to just 14
over the same span of time (matching the original intent of running
about once every 24 seconds, at 19.2Mhz GT freq, per engine).

Signed-off-by: Alan Previn 
---
drivers/gpu/drm/i915/gt/intel_engine_types.h  | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  9 +
2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h

index 2286f96f5f87..63f4ecdf1606 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -323,6 +323,16 @@ struct intel_engine_guc_stats {
 * @start_gt_clk: GT clock time of last idle to active transition.
 */
u64 start_gt_clk;
+
+    /**
+ * @last_jiffies: Jiffies at last actual stats collection time
+ *
+ * We use this timestamp to ensure we don't oversample the
+ * stats because runtime power management events can trigger
+ * stats collection at much higher rates than required.
+ */
+    u64 last_jiffies;
+
};

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

index 5a1dfacf24ea..8f8bf6e40ccb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1167,6 +1167,15 @@ static void guc_update_engine_gt_clks(struct 
intel_engine_cs *engine)


A user query will end up in guc_engine_busyness which will call 
guc_update_engine_gt_clks. Adding this logic here will affect accuracy.
The other place where guc_update_engine_gt_clks is called is in the ping 
worker, but that worker runs at 1/8th the wrap around time for the gt 
clocks (32 bit). The last I checked the wrap around was at 22 seconds.


That leaves only the gt_park path. fwiu, this path runs too frequently 
and here we are updating the busyness stats. That is causing the 
enormous PCI traffic (lmem accesses). Only this path needs to be fixed, 
as in just use the same logic in the intel_guc_busyness_park() to decide 
whether to call __update_guc_busyness_stats or not.


Not updating the driver state in park will not negatively impact 
accuracy in some scenarios? That needs to balanced against the questions 
whether or not there are real world scenarios impacted by the update 
cost or it is just for IGT.


Regards,

Tvrtko



Of course, if you are running the user query too frequently, then IMO we 
should not fix that in i915.
If you haven't already, please make sure the igt@perf_pmu@ tests are all 
passing with any of these changes. There's also a selftest - 
live_engine_busy_stats that you need to make sure passes.



struct intel_engine_guc_stats *stats = >stats.guc;
struct intel_guc *guc = >gt->uc.guc;
u32 last_switch, ctx_id, total;
+    u64 newjiffs;
+
+    /* Don't worry about jiffies wrap-around, a rare additional 
sample won't have any impact */

+    newjiffs = get_jiffies_64();
+    if (stats->last_jiffies && (newjiffs - stats->last_jiffies <
+   (guc->timestamp.ping_delay << 1)))


You want to right shift by 1 for half the ping delay here.

Thanks,
Umesh


+    return;
+
+    stats->last_jiffies = newjiffs;

lockdep_assert_held(>timestamp.lock);

--
2.25.1

Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-14 Thread Lionel Landwerlin


On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:

On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:



Regards,
Oak


-Original Message-
From: Intel-gfx  On Behalf 
Of Niranjana

Vishwanathapura
Sent: June 10, 2022 1:43 PM
To: Landwerlin, Lionel G 
Cc: Intel GFX ; Maling list - DRI 
developers de...@lists.freedesktop.org>; Hellstrom, Thomas 
;

Wilson, Chris P ; Vetter, Daniel
; Christian König 
Subject: Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature 
design

document

On Fri, Jun 10, 2022 at 11:18:14AM +0300, Lionel Landwerlin wrote:
>On 10/06/2022 10:54, Niranjana Vishwanathapura wrote:
>>On Fri, Jun 10, 2022 at 09:53:24AM +0300, Lionel Landwerlin wrote:
>>>On 09/06/2022 22:31, Niranjana Vishwanathapura wrote:
On Thu, Jun 09, 2022 at 05:49:09PM +0300, Lionel Landwerlin wrote:
>  On 09/06/2022 00:55, Jason Ekstrand wrote:
>
>    On Wed, Jun 8, 2022 at 4:44 PM Niranjana Vishwanathapura
>  wrote:
>
>  On Wed, Jun 08, 2022 at 08:33:25AM +0100, Tvrtko Ursulin 
wrote:

>  >
>  >
>  >On 07/06/2022 22:32, Niranjana Vishwanathapura wrote:
>  >>On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana
>Vishwanathapura
>  wrote:
>  >>>On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason
>Ekstrand wrote:
>   On Fri, Jun 3, 2022 at 6:52 PM Niranjana 
Vishwanathapura

>    wrote:
>  
>     On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel
>Landwerlin
>  wrote:
>     >   On 02/06/2022 23:35, Jason Ekstrand wrote:
>     >
>     > On Thu, Jun 2, 2022 at 3:11 PM Niranjana
>Vishwanathapura
>     >  wrote:
>     >
>     >   On Wed, Jun 01, 2022 at 01:28:36PM -0700, 
Matthew

>  Brost wrote:
>     >   >On Wed, Jun 01, 2022 at 05:25:49PM +0300, 
Lionel

>  Landwerlin
>     wrote:
>     > >> On 17/05/2022 21:32, Niranjana Vishwanathapura
>  wrote:
>     > >> > +VM_BIND/UNBIND ioctl will immediately start
>     binding/unbinding
>     >   the mapping in an
>     > >> > +async worker. The binding and
>unbinding will
>  work like a
>     special
>     >   GPU engine.
>     > >> > +The binding and unbinding operations are
>  serialized and
>     will
>     >   wait on specified
>     > >> > +input fences before the operation
>and will signal
>  the
>     output
>     >   fences upon the
>     > >> > +completion of the operation. Due to
>  serialization,
>     completion of
>     >   an operation
>     > >> > +will also indicate that all
>previous operations
>  are also
>     > complete.
>     > >>
>     > >> I guess we should avoid saying "will
>immediately
>  start
>     > binding/unbinding" if
>     > >> there are fences involved.
>     > >>
>     > >> And the fact that it's happening in an async
>  worker seem to
>     imply
>     >   it's not
>     > >> immediate.
>     > >>
>     >
>     >   Ok, will fix.
>     >   This was added because in earlier design
>binding was
>  deferred
>     until
>     >   next execbuff.
>     >   But now it is non-deferred (immediate in
>that sense).
>  But yah,
>     this is
>     > confusing
>     >   and will fix it.
>     >
>     > >>
>     > >> I have a question on the behavior of the bind
>  operation when
>     no
>     >   input fence
>     > >> is provided. Let say I do :
>     > >>
>     > >> VM_BIND (out_fence=fence1)
>     > >>
>     > >> VM_BIND (out_fence=fence2)
>     > >>
>     > >> VM_BIND (out_fence=fence3)
>     > >>
>     > >>
>     > >> In what order are the fences going to
>be signaled?
>     > >>
>     > >> In the order of VM_BIND ioctls? Or out
>of order?
>     > >>
>     > >> Because you wrote "serialized I assume
>it's : in
>  order
>     > >>
>     >
>     >   Yes, in the order of VM_BIND/UNBIND
>ioctls. Note that
>  bind and
>     unbind
>     >   will use
>     >   the same queue and hence are ordered.
>

Re: [Intel-gfx] [PATCH 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-14 Thread Lionel Landwerlin


On 10/06/2022 11:53, Matthew Brost wrote:

On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:

VM_BIND and related uapi definitions

Signed-off-by: Niranjana Vishwanathapura 
---
  Documentation/gpu/rfc/i915_vm_bind.h | 490 +++
  1 file changed, 490 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..9fc854969cfb
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,490 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ * bit[0]: If set, VM_BIND is supported, otherwise not.
+ * bits[8-15]: VM_BIND implementation version.
+ * version 0 will not have VM_BIND/UNBIND timeline fence array support.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND   (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_SIGNAL (See _i915_gem_exec_fence.flags) is expected
+ * to be not used. DRM_I915_GEM_WAIT ioctl call is also not supported for
+ * objects mapped to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING   (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND   0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3   0x3f
+#define DRM_I915_GEM_WAIT_USER_FENCE   0x40
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @queue_idx specifies the queue to use for binding. Same queue can be
+ * used for both VM_BIND and VM_UNBIND calls. All submitted bind and unbind
+ * operations in a queue are performed in the order of submission.
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+   /** @vm_id: VM (address space) id to bind */
+   __u32 vm_id;
+
+   /** @queue_idx: Index of queue for binding */
+   __u32 queue_idx;
+
+   /** @rsvd: Reserved, MBZ */
+   __u32 rsvd;
+
+   /** @handle: Object handle */
+   __u32 handle;
+
+   /** @start: Virtual Address start to bind */
+   __u64 start;
+
+   /** @offset: Offset in object to bind */
+   __u64 offset;
+
+   /** @length: Length of mapping to bind */
+   __u64 length;

This probably isn't needed. We are never going to unbind a subset of a
VMA are we? That being said it can't hurt as a sanity check (e.g.
internal

94 matches

Mail list logo