[PATCH v2 0/2] Add support for querying hw info that UMDs need

[PATCH v2 0/2] Add support for querying hw info that UMDs need

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.

v2: Add a kerneldoc comment.

Test-with: 20210915215558.2473428-2-John.C.Harrison@Intel.com
UMD: https://github.com/intel/compute-runtime/pull/432/files
UMD: https://github.com/intel/media-driver/pull/1239/files

CC: Katarzyna Cencelewska <katarzyna.cencelewska@intel.com>
CC: Tony Ye <tony.ye@intel.com>
CC: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>


John Harrison (1):
  drm/i915/guc: Add fetch of hwconfig table

Rodrigo Vivi (1):
  drm/i915/uapi: Add query for hwconfig table

 drivers/gpu/drm/i915/Makefile                 |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c        |   3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   3 +
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c   | 156 ++++++++++++++++++
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h   |  19 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c         |   6 +
 drivers/gpu/drm/i915/i915_query.c             |  23 +++
 include/uapi/drm/i915_drm.h                   |   1 +
 10 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h

-- 
2.25.1

[Intel-gfx] [PATCH v2 0/2] Add support for querying hw info that UMDs need

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.

v2: Add a kerneldoc comment.

Test-with: 20210915215558.2473428-2-John.C.Harrison@Intel.com
UMD: https://github.com/intel/compute-runtime/pull/432/files
UMD: https://github.com/intel/media-driver/pull/1239/files

CC: Katarzyna Cencelewska <katarzyna.cencelewska@intel.com>
CC: Tony Ye <tony.ye@intel.com>
CC: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>


John Harrison (1):
  drm/i915/guc: Add fetch of hwconfig table

Rodrigo Vivi (1):
  drm/i915/uapi: Add query for hwconfig table

 drivers/gpu/drm/i915/Makefile                 |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c        |   3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   3 +
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c   | 156 ++++++++++++++++++
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h   |  19 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c         |   6 +
 drivers/gpu/drm/i915/i915_query.c             |  23 +++
 include/uapi/drm/i915_drm.h                   |   1 +
 10 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h

-- 
2.25.1

[PATCH v2 1/2] drm/i915/guc: Add fetch of hwconfig table

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.

Note that the table is only available on ADL-P and later platforms.

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/Makefile                 |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c        |   3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   3 +
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c   | 156 ++++++++++++++++++
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h   |  19 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c         |   6 +
 8 files changed, 192 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c1e9f7369fb5..3789f03a1021 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -190,6 +190,7 @@ i915-y += gt/uc/intel_uc.o \
 	  gt/uc/intel_guc_rc.o \
 	  gt/uc/intel_guc_slpc.o \
 	  gt/uc/intel_guc_submission.o \
+	  gt/uc/intel_guc_hwconfig.o \
 	  gt/uc/intel_huc.o \
 	  gt/uc/intel_huc_debugfs.o \
 	  gt/uc/intel_huc_fw.o
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 8ff582222aff..72fd492b726a 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -137,6 +137,7 @@ enum intel_guc_action {
 	INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
 	INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
 	INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+	INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
 	INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
 	INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
 	INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index 488b6061ee89..f9e2a6aaef4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -8,6 +8,10 @@
 
 enum intel_guc_response_status {
 	INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
+	INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
+	INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
+	INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
+	INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
 	INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
 };
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index fbfcae727d7f..82c0ce0090c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -422,13 +422,14 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
 	/*
 	 * No GuC command should ever take longer than 10ms.
 	 * Fast commands should still complete in 10us.
+	 * Except for the hwconfig table query, which takes ~50ms.
 	 */
 	ret = __intel_wait_for_register_fw(uncore,
 					   guc_send_reg(guc, 0),
 					   GUC_HXG_MSG_0_ORIGIN,
 					   FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
 						      GUC_HXG_ORIGIN_GUC),
-					   10, 10, &header);
+					   10, 100, &header);
 	if (unlikely(ret)) {
 timeout:
 		drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5dd174babf7a..6bc20774007d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -13,6 +13,7 @@
 #include "intel_guc_fw.h"
 #include "intel_guc_fwif.h"
 #include "intel_guc_ct.h"
+#include "intel_guc_hwconfig.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
 #include "intel_guc_slpc_types.h"
@@ -37,6 +38,8 @@ struct intel_guc {
 	struct intel_guc_ct ct;
 	/** @slpc: sub-structure containing SLPC related data and objects */
 	struct intel_guc_slpc slpc;
+	/** @hwconfig: hardware configuration KLV table */
+	struct intel_guc_hwconfig hwconfig;
 
 	/** @sched_engine: Global engine used to submit requests to GuC */
 	struct i915_sched_engine *sched_engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
new file mode 100644
index 000000000000..af4fc9fdbaaf
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "gt/intel_gt.h"
+#include "i915_drv.h"
+#include "i915_memcpy.h"
+#include "intel_guc_hwconfig.h"
+
+static inline struct intel_guc *hwconfig_to_guc(struct intel_guc_hwconfig *hwconfig)
+{
+	return container_of(hwconfig, struct intel_guc, hwconfig);
+}
+
+/*
+ * GuC has a blob containing hardware configuration information (HWConfig).
+ * This is formatted as a simple and flexible KLV (Key/Length/Value) table.
+ *
+ * For example, a minimal version could be:
+ *   enum device_attr {
+ *     ATTR_SOME_VALUE = 0,
+ *     ATTR_SOME_MASK  = 1,
+ *   };
+ *
+ *   static const u32 hwconfig[] = {
+ *     ATTR_SOME_VALUE,
+ *     1,		// Value Length in DWords
+ *     8,		// Value
+ *
+ *     ATTR_SOME_MASK,
+ *     3,
+ *     0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
+ *   };
+ *
+ * The attribute ids are defined in a hardware spec.
+ */
+
+static int __guc_action_get_hwconfig(struct intel_guc_hwconfig *hwconfig,
+				     u32 ggtt_offset, u32 ggtt_size)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+	u32 action[] = {
+		INTEL_GUC_ACTION_GET_HWCONFIG,
+		ggtt_offset,
+		ggtt_size,
+		(INTEL_DEVID(i915) << 16) | INTEL_REVID(i915),
+	};
+	int ret;
+
+	ret = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+	if (ret == -ENXIO)
+		return -ENOENT;
+
+	if (!ggtt_size && !ret)
+		ret = -EINVAL;
+
+	return ret;
+}
+
+static int guc_hwconfig_discover_size(struct intel_guc_hwconfig *hwconfig)
+{
+	int ret;
+
+	/* Sending a query with too small a table will return the size of the table */
+	ret = __guc_action_get_hwconfig(hwconfig, 0, 0);
+	if (ret < 0)
+		return ret;
+
+	hwconfig->size = ret;
+	return 0;
+}
+
+static int guc_hwconfig_fill_buffer(struct intel_guc_hwconfig *hwconfig)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct i915_vma *vma;
+	u32 ggtt_offset;
+	void *vaddr;
+	int ret;
+
+	GEM_BUG_ON(!hwconfig->size);
+
+	ret = intel_guc_allocate_and_map_vma(guc, hwconfig->size, &vma, &vaddr);
+	if (ret)
+		return ret;
+
+	ggtt_offset = intel_guc_ggtt_offset(guc, vma);
+
+	ret = __guc_action_get_hwconfig(hwconfig, ggtt_offset, hwconfig->size);
+	if (ret >= 0)
+		memcpy(hwconfig->ptr, vaddr, hwconfig->size);
+
+	i915_vma_unpin_and_release(&vma, I915_VMA_RELEASE_MAP);
+
+	return ret;
+}
+
+static bool has_table(struct drm_i915_private *i915)
+{
+	if (IS_ALDERLAKE_P(i915)) {
+		if (IS_ADLP_GT_STEP(i915, STEP_A0, STEP_A0))
+			return false;
+
+		return true;
+	}
+
+	return false;
+}
+
+/**
+ * intel_guc_hwconfig_fini - Finalize the HWConfig
+ *
+ * Free up the memory allocation holding the table.
+ */
+void intel_guc_hwconfig_fini(struct intel_guc_hwconfig *hwconfig)
+{
+	kfree(hwconfig->ptr);
+	hwconfig->size = 0;
+	hwconfig->ptr = NULL;
+}
+
+/**
+ * intel_guc_hwconfig_init - Initialize the HWConfig
+ *
+ * Retrieve the HWConfig table from the GuC and save it away in a local memory
+ * allocation. It can then be queried on demand by other users later on.
+ */
+int intel_guc_hwconfig_init(struct intel_guc_hwconfig *hwconfig)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+	int ret;
+
+	if (!has_table(i915))
+		return 0;
+
+	ret = guc_hwconfig_discover_size(hwconfig);
+	if (ret)
+		return ret;
+
+	hwconfig->ptr = kmalloc(hwconfig->size, GFP_KERNEL);
+	if (!hwconfig->ptr) {
+		hwconfig->size = 0;
+		return -ENOMEM;
+	}
+
+	ret = guc_hwconfig_fill_buffer(hwconfig);
+	if (ret < 0) {
+		intel_guc_hwconfig_fini(hwconfig);
+		return ret;
+	}
+
+	return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
new file mode 100644
index 000000000000..fdd7f0d6e938
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_HWCONFIG_H_
+#define _INTEL_GUC_HWCONFIG_H_
+
+#include <linux/types.h>
+
+struct intel_guc_hwconfig {
+	u32 size;
+	void *ptr;
+};
+
+int intel_guc_hwconfig_init(struct intel_guc_hwconfig *hwconfig);
+void intel_guc_hwconfig_fini(struct intel_guc_hwconfig *hwconfig);
+
+#endif /* _INTEL_GUC_HWCONFIG_H_ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 86c318516e14..44c4adf58609 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -486,6 +486,10 @@ static int __uc_init_hw(struct intel_uc *uc)
 	if (ret)
 		goto err_log_capture;
 
+	ret = intel_guc_hwconfig_init(&guc->hwconfig);
+	if (ret)
+		drm_err(&i915->drm, "Failed to retrieve hwconfig table: %d\n", ret);
+
 	ret = guc_enable_communication(guc);
 	if (ret)
 		goto err_log_capture;
@@ -553,6 +557,8 @@ static void __uc_fini_hw(struct intel_uc *uc)
 	if (intel_uc_uses_guc_submission(uc))
 		intel_guc_submission_disable(guc);
 
+	intel_guc_hwconfig_fini(&guc->hwconfig);
+
 	__uc_sanitize(uc);
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Add fetch of hwconfig table

[John.C.Harrison]

From: John Harrison <John.C.Harrison@Intel.com>

Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.

Note that the table is only available on ADL-P and later platforms.

Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/Makefile                 |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   1 +
 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c        |   3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   3 +
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c   | 156 ++++++++++++++++++
 .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h   |  19 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c         |   6 +
 8 files changed, 192 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c1e9f7369fb5..3789f03a1021 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -190,6 +190,7 @@ i915-y += gt/uc/intel_uc.o \
 	  gt/uc/intel_guc_rc.o \
 	  gt/uc/intel_guc_slpc.o \
 	  gt/uc/intel_guc_submission.o \
+	  gt/uc/intel_guc_hwconfig.o \
 	  gt/uc/intel_huc.o \
 	  gt/uc/intel_huc_debugfs.o \
 	  gt/uc/intel_huc_fw.o
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 8ff582222aff..72fd492b726a 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -137,6 +137,7 @@ enum intel_guc_action {
 	INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
 	INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
 	INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+	INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
 	INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
 	INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
 	INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index 488b6061ee89..f9e2a6aaef4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -8,6 +8,10 @@
 
 enum intel_guc_response_status {
 	INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
+	INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
+	INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
+	INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
+	INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
 	INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
 };
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index fbfcae727d7f..82c0ce0090c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -422,13 +422,14 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
 	/*
 	 * No GuC command should ever take longer than 10ms.
 	 * Fast commands should still complete in 10us.
+	 * Except for the hwconfig table query, which takes ~50ms.
 	 */
 	ret = __intel_wait_for_register_fw(uncore,
 					   guc_send_reg(guc, 0),
 					   GUC_HXG_MSG_0_ORIGIN,
 					   FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
 						      GUC_HXG_ORIGIN_GUC),
-					   10, 10, &header);
+					   10, 100, &header);
 	if (unlikely(ret)) {
 timeout:
 		drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5dd174babf7a..6bc20774007d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -13,6 +13,7 @@
 #include "intel_guc_fw.h"
 #include "intel_guc_fwif.h"
 #include "intel_guc_ct.h"
+#include "intel_guc_hwconfig.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
 #include "intel_guc_slpc_types.h"
@@ -37,6 +38,8 @@ struct intel_guc {
 	struct intel_guc_ct ct;
 	/** @slpc: sub-structure containing SLPC related data and objects */
 	struct intel_guc_slpc slpc;
+	/** @hwconfig: hardware configuration KLV table */
+	struct intel_guc_hwconfig hwconfig;
 
 	/** @sched_engine: Global engine used to submit requests to GuC */
 	struct i915_sched_engine *sched_engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
new file mode 100644
index 000000000000..af4fc9fdbaaf
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "gt/intel_gt.h"
+#include "i915_drv.h"
+#include "i915_memcpy.h"
+#include "intel_guc_hwconfig.h"
+
+static inline struct intel_guc *hwconfig_to_guc(struct intel_guc_hwconfig *hwconfig)
+{
+	return container_of(hwconfig, struct intel_guc, hwconfig);
+}
+
+/*
+ * GuC has a blob containing hardware configuration information (HWConfig).
+ * This is formatted as a simple and flexible KLV (Key/Length/Value) table.
+ *
+ * For example, a minimal version could be:
+ *   enum device_attr {
+ *     ATTR_SOME_VALUE = 0,
+ *     ATTR_SOME_MASK  = 1,
+ *   };
+ *
+ *   static const u32 hwconfig[] = {
+ *     ATTR_SOME_VALUE,
+ *     1,		// Value Length in DWords
+ *     8,		// Value
+ *
+ *     ATTR_SOME_MASK,
+ *     3,
+ *     0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
+ *   };
+ *
+ * The attribute ids are defined in a hardware spec.
+ */
+
+static int __guc_action_get_hwconfig(struct intel_guc_hwconfig *hwconfig,
+				     u32 ggtt_offset, u32 ggtt_size)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+	u32 action[] = {
+		INTEL_GUC_ACTION_GET_HWCONFIG,
+		ggtt_offset,
+		ggtt_size,
+		(INTEL_DEVID(i915) << 16) | INTEL_REVID(i915),
+	};
+	int ret;
+
+	ret = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+	if (ret == -ENXIO)
+		return -ENOENT;
+
+	if (!ggtt_size && !ret)
+		ret = -EINVAL;
+
+	return ret;
+}
+
+static int guc_hwconfig_discover_size(struct intel_guc_hwconfig *hwconfig)
+{
+	int ret;
+
+	/* Sending a query with too small a table will return the size of the table */
+	ret = __guc_action_get_hwconfig(hwconfig, 0, 0);
+	if (ret < 0)
+		return ret;
+
+	hwconfig->size = ret;
+	return 0;
+}
+
+static int guc_hwconfig_fill_buffer(struct intel_guc_hwconfig *hwconfig)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct i915_vma *vma;
+	u32 ggtt_offset;
+	void *vaddr;
+	int ret;
+
+	GEM_BUG_ON(!hwconfig->size);
+
+	ret = intel_guc_allocate_and_map_vma(guc, hwconfig->size, &vma, &vaddr);
+	if (ret)
+		return ret;
+
+	ggtt_offset = intel_guc_ggtt_offset(guc, vma);
+
+	ret = __guc_action_get_hwconfig(hwconfig, ggtt_offset, hwconfig->size);
+	if (ret >= 0)
+		memcpy(hwconfig->ptr, vaddr, hwconfig->size);
+
+	i915_vma_unpin_and_release(&vma, I915_VMA_RELEASE_MAP);
+
+	return ret;
+}
+
+static bool has_table(struct drm_i915_private *i915)
+{
+	if (IS_ALDERLAKE_P(i915)) {
+		if (IS_ADLP_GT_STEP(i915, STEP_A0, STEP_A0))
+			return false;
+
+		return true;
+	}
+
+	return false;
+}
+
+/**
+ * intel_guc_hwconfig_fini - Finalize the HWConfig
+ *
+ * Free up the memory allocation holding the table.
+ */
+void intel_guc_hwconfig_fini(struct intel_guc_hwconfig *hwconfig)
+{
+	kfree(hwconfig->ptr);
+	hwconfig->size = 0;
+	hwconfig->ptr = NULL;
+}
+
+/**
+ * intel_guc_hwconfig_init - Initialize the HWConfig
+ *
+ * Retrieve the HWConfig table from the GuC and save it away in a local memory
+ * allocation. It can then be queried on demand by other users later on.
+ */
+int intel_guc_hwconfig_init(struct intel_guc_hwconfig *hwconfig)
+{
+	struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+	struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+	int ret;
+
+	if (!has_table(i915))
+		return 0;
+
+	ret = guc_hwconfig_discover_size(hwconfig);
+	if (ret)
+		return ret;
+
+	hwconfig->ptr = kmalloc(hwconfig->size, GFP_KERNEL);
+	if (!hwconfig->ptr) {
+		hwconfig->size = 0;
+		return -ENOMEM;
+	}
+
+	ret = guc_hwconfig_fill_buffer(hwconfig);
+	if (ret < 0) {
+		intel_guc_hwconfig_fini(hwconfig);
+		return ret;
+	}
+
+	return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
new file mode 100644
index 000000000000..fdd7f0d6e938
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_HWCONFIG_H_
+#define _INTEL_GUC_HWCONFIG_H_
+
+#include <linux/types.h>
+
+struct intel_guc_hwconfig {
+	u32 size;
+	void *ptr;
+};
+
+int intel_guc_hwconfig_init(struct intel_guc_hwconfig *hwconfig);
+void intel_guc_hwconfig_fini(struct intel_guc_hwconfig *hwconfig);
+
+#endif /* _INTEL_GUC_HWCONFIG_H_ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 86c318516e14..44c4adf58609 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -486,6 +486,10 @@ static int __uc_init_hw(struct intel_uc *uc)
 	if (ret)
 		goto err_log_capture;
 
+	ret = intel_guc_hwconfig_init(&guc->hwconfig);
+	if (ret)
+		drm_err(&i915->drm, "Failed to retrieve hwconfig table: %d\n", ret);
+
 	ret = guc_enable_communication(guc);
 	if (ret)
 		goto err_log_capture;
@@ -553,6 +557,8 @@ static void __uc_fini_hw(struct intel_uc *uc)
 	if (intel_uc_uses_guc_submission(uc))
 		intel_guc_submission_disable(guc);
 
+	intel_guc_hwconfig_fini(&guc->hwconfig);
+
 	__uc_sanitize(uc);
 }
 
-- 
2.25.1

[PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John.C.Harrison]

From: Rodrigo Vivi <rodrigo.vivi@intel.com>

GuC contains a consolidated table with a bunch of information about the
current device.

Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interested components can grab the
very latest and synchronized information using a simple query.

As per most of the other queries, this one can be called twice.
Once with item.length=0 to determine the exact buffer size, then
allocate the user memory and call it again for to retrieve the
table data. For example:
  struct drm_i915_query_item item = {
    .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
  };
  query.items_ptr = (int64_t) &item;
  query.num_items = 1;

  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  if (item.length <= 0)
    return -ENOENT;

  data = malloc(item.length);
  item.data_ptr = (int64_t) &data;
  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  // Parse the data as appropriate...

The returned array is a simple and flexible KLV (Key/Length/Value)
formatted table. For example, it could be just:
  enum device_attr {
     ATTR_SOME_VALUE = 0,
     ATTR_SOME_MASK  = 1,
  };

  static const u32 hwconfig[] = {
      ATTR_SOME_VALUE,
      1,             // Value Length in DWords
      8,             // Value

      ATTR_SOME_MASK,
      3,
      0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
  };

The attribute ids are defined in a hardware spec.

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
 include/uapi/drm/i915_drm.h       |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
index 5e2b909827f4..96989a37453c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -477,12 +477,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
 	return total_length;
 }
 
+static int query_hwconfig_table(struct drm_i915_private *i915,
+				struct drm_i915_query_item *query_item)
+{
+	struct intel_gt *gt = &i915->gt;
+	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
+
+	if (!hwconfig->size || !hwconfig->ptr)
+		return -ENODEV;
+
+	if (query_item->length == 0)
+		return hwconfig->size;
+
+	if (query_item->length < hwconfig->size)
+		return -EINVAL;
+
+	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+			 hwconfig->ptr, hwconfig->size))
+		return -EFAULT;
+
+	return hwconfig->size;
+}
+
 static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
 					struct drm_i915_query_item *query_item) = {
 	query_topology_info,
 	query_engine_info,
 	query_perf_config,
 	query_memregion_info,
+	query_hwconfig_table,
 };
 
 int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bde5860b3686..a1281f35b190 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2499,6 +2499,7 @@ struct drm_i915_query_item {
 #define DRM_I915_QUERY_ENGINE_INFO	2
 #define DRM_I915_QUERY_PERF_CONFIG      3
 #define DRM_I915_QUERY_MEMORY_REGIONS   4
+#define DRM_I915_QUERY_HWCONFIG_TABLE   5
 /* Must be kept compact -- no holes and well documented */
 
 	/**
-- 
2.25.1

[Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John.C.Harrison]

From: Rodrigo Vivi <rodrigo.vivi@intel.com>

GuC contains a consolidated table with a bunch of information about the
current device.

Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interested components can grab the
very latest and synchronized information using a simple query.

As per most of the other queries, this one can be called twice.
Once with item.length=0 to determine the exact buffer size, then
allocate the user memory and call it again for to retrieve the
table data. For example:
  struct drm_i915_query_item item = {
    .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
  };
  query.items_ptr = (int64_t) &item;
  query.num_items = 1;

  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  if (item.length <= 0)
    return -ENOENT;

  data = malloc(item.length);
  item.data_ptr = (int64_t) &data;
  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  // Parse the data as appropriate...

The returned array is a simple and flexible KLV (Key/Length/Value)
formatted table. For example, it could be just:
  enum device_attr {
     ATTR_SOME_VALUE = 0,
     ATTR_SOME_MASK  = 1,
  };

  static const u32 hwconfig[] = {
      ATTR_SOME_VALUE,
      1,             // Value Length in DWords
      8,             // Value

      ATTR_SOME_MASK,
      3,
      0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
  };

The attribute ids are defined in a hardware spec.

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
 include/uapi/drm/i915_drm.h       |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
index 5e2b909827f4..96989a37453c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -477,12 +477,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
 	return total_length;
 }
 
+static int query_hwconfig_table(struct drm_i915_private *i915,
+				struct drm_i915_query_item *query_item)
+{
+	struct intel_gt *gt = &i915->gt;
+	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
+
+	if (!hwconfig->size || !hwconfig->ptr)
+		return -ENODEV;
+
+	if (query_item->length == 0)
+		return hwconfig->size;
+
+	if (query_item->length < hwconfig->size)
+		return -EINVAL;
+
+	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+			 hwconfig->ptr, hwconfig->size))
+		return -EFAULT;
+
+	return hwconfig->size;
+}
+
 static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
 					struct drm_i915_query_item *query_item) = {
 	query_topology_info,
 	query_engine_info,
 	query_perf_config,
 	query_memregion_info,
+	query_hwconfig_table,
 };
 
 int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bde5860b3686..a1281f35b190 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2499,6 +2499,7 @@ struct drm_i915_query_item {
 #define DRM_I915_QUERY_ENGINE_INFO	2
 #define DRM_I915_QUERY_PERF_CONFIG      3
 #define DRM_I915_QUERY_MEMORY_REGIONS   4
+#define DRM_I915_QUERY_HWCONFIG_TABLE   5
 /* Must be kept compact -- no holes and well documented */
 
 	/**
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for querying hw info that UMDs need

[Patchwork]

== Series Details ==

Series: Add support for querying hw info that UMDs need
URL   : https://patchwork.freedesktop.org/series/94780/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2e34f570f67b drm/i915/guc: Add fetch of hwconfig table
-:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#98: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 247 lines checked
c7fa0fd27d07 drm/i915/uapi: Add query for hwconfig table

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for querying hw info that UMDs need

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 9829 bytes --]

== Series Details ==

Series: Add support for querying hw info that UMDs need
URL   : https://patchwork.freedesktop.org/series/94780/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10600 -> Patchwork_21080
====================================================

Summary
-------

  **WARNING**

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

Possible new issues
-------------------

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

### IGT changes ###

#### Warnings ####

  * igt@i915_module_load@reload:
    - fi-kbl-8809g:       [INCOMPLETE][1] ([i915#3910] / [i915#4136]) -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-kbl-8809g/igt@i915_module_load@reload.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-8809g/igt@i915_module_load@reload.html

  
#### Suppressed ####

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

  * igt@i915_module_load@reload:
    - {fi-ehl-2}:         [INCOMPLETE][3] ([i915#4136]) -> [INCOMPLETE][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-ehl-2/igt@i915_module_load@reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-ehl-2/igt@i915_module_load@reload.html

  * igt@i915_pm_rpm@module-reload:
    - {fi-jsl-1}:         NOTRUN -> [INCOMPLETE][5]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-jsl-1/igt@i915_pm_rpm@module-reload.html

  * igt@runner@aborted:
    - {fi-jsl-1}:         NOTRUN -> [FAIL][6]
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-jsl-1/igt@runner@aborted.html
    - {fi-ehl-2}:         NOTRUN -> [FAIL][7]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-ehl-2/igt@runner@aborted.html

  
Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@cs-sdma:
    - fi-kbl-7500u:       NOTRUN -> [SKIP][8] ([fdo#109271]) +17 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-7500u/igt@amdgpu/amd_basic@cs-sdma.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
    - fi-rkl-11600:       NOTRUN -> [SKIP][9] ([fdo#109315]) +17 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-rkl-11600/igt@amdgpu/amd_cs_nop@sync-gfx0.html

  * igt@core_hotunplug@unbind-rebind:
    - fi-cfl-8700k:       [PASS][10] -> [INCOMPLETE][11] ([i915#4130])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-cfl-8700k/igt@core_hotunplug@unbind-rebind.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-cfl-8700k/igt@core_hotunplug@unbind-rebind.html
    - fi-cfl-8109u:       [PASS][12] -> [INCOMPLETE][13] ([i915#4130])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-cfl-8109u/igt@core_hotunplug@unbind-rebind.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-cfl-8109u/igt@core_hotunplug@unbind-rebind.html
    - fi-kbl-7567u:       [PASS][14] -> [INCOMPLETE][15] ([i915#4130])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-kbl-7567u/igt@core_hotunplug@unbind-rebind.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-7567u/igt@core_hotunplug@unbind-rebind.html

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

  * igt@gem_tiled_blits@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][17] ([fdo#109271]) +5 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-soraka/igt@gem_tiled_blits@basic.html

  * igt@i915_module_load@reload:
    - fi-kbl-soraka:      NOTRUN -> [INCOMPLETE][18] ([i915#4130])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-soraka/igt@i915_module_load@reload.html
    - fi-rkl-guc:         [PASS][19] -> [INCOMPLETE][20] ([i915#4130])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-rkl-guc/igt@i915_module_load@reload.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-rkl-guc/igt@i915_module_load@reload.html
    - fi-skl-6700k2:      NOTRUN -> [INCOMPLETE][21] ([i915#4130])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-skl-6700k2/igt@i915_module_load@reload.html

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

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

  * igt@runner@aborted:
    - fi-kbl-soraka:      NOTRUN -> [FAIL][24] ([i915#2426] / [i915#3363])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-soraka/igt@runner@aborted.html
    - fi-rkl-guc:         NOTRUN -> [FAIL][25] ([i915#2426])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-rkl-guc/igt@runner@aborted.html
    - fi-skl-6700k2:      NOTRUN -> [FAIL][26] ([i915#2426] / [i915#3363])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-skl-6700k2/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@core_hotunplug@unbind-rebind:
    - fi-skl-6700k2:      [INCOMPLETE][27] ([i915#4130]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-skl-6700k2/igt@core_hotunplug@unbind-rebind.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-skl-6700k2/igt@core_hotunplug@unbind-rebind.html
    - fi-kbl-7500u:       [INCOMPLETE][29] ([i915#4130]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-kbl-7500u/igt@core_hotunplug@unbind-rebind.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-7500u/igt@core_hotunplug@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0:
    - fi-kbl-soraka:      [INCOMPLETE][31] ([i915#155]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html

  * igt@i915_module_load@reload:
    - fi-rkl-11600:       [INCOMPLETE][33] ([i915#4136]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-rkl-11600/igt@i915_module_load@reload.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-rkl-11600/igt@i915_module_load@reload.html
    - fi-kbl-guc:         [INCOMPLETE][35] ([i915#4130] / [i915#4139]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-kbl-guc/igt@i915_module_load@reload.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-kbl-guc/igt@i915_module_load@reload.html

  
#### Warnings ####

  * igt@i915_module_load@reload:
    - fi-cml-u2:          [INCOMPLETE][37] ([i915#4130] / [i915#4136]) -> [INCOMPLETE][38] ([i915#4136])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/fi-cml-u2/igt@i915_module_load@reload.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/fi-cml-u2/igt@i915_module_load@reload.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3910]: https://gitlab.freedesktop.org/drm/intel/issues/3910
  [i915#4130]: https://gitlab.freedesktop.org/drm/intel/issues/4130
  [i915#4136]: https://gitlab.freedesktop.org/drm/intel/issues/4136
  [i915#4139]: https://gitlab.freedesktop.org/drm/intel/issues/4139
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (38 -> 34)
------------------------------

  Missing    (4): fi-tgl-1115g4 fi-bsw-cyan fi-bsw-nick fi-bdw-samus 


Build changes
-------------

  * IGT: IGT_6211 -> IGTPW_6222
  * Linux: CI_DRM_10600 -> Patchwork_21080

  CI-20190529: 20190529
  CI_DRM_10600: 6d030d2f188222b72833db764662393e8d492325 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_6222: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6222/index.html
  IGT_6211: 7b275b3eb17ddf6e7c5b7b9ba359b7f5345a5311 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21080: c7fa0fd27d07ef18aca724effedb971d782b61e4 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c7fa0fd27d07 drm/i915/uapi: Add query for hwconfig table
2e34f570f67b drm/i915/guc: Add fetch of hwconfig table

== Logs ==

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

[-- Attachment #2: Type: text/html, Size: 12397 bytes --]

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for querying hw info that UMDs need

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 30270 bytes --]

== Series Details ==

Series: Add support for querying hw info that UMDs need
URL   : https://patchwork.freedesktop.org/series/94780/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10600_full -> Patchwork_21080_full
====================================================

Summary
-------

  **FAILURE**

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

  

Possible new issues
-------------------

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

### IGT changes ###

#### Possible regressions ####

  * igt@i915_pm_rpm@debugfs-forcewake-user:
    - shard-iclb:         [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-iclb7/igt@i915_pm_rpm@debugfs-forcewake-user.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb1/igt@i915_pm_rpm@debugfs-forcewake-user.html

  * igt@kms_cursor_crc@pipe-d-cursor-suspend:
    - shard-tglb:         [PASS][3] -> [INCOMPLETE][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb3/igt@kms_cursor_crc@pipe-d-cursor-suspend.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb7/igt@kms_cursor_crc@pipe-d-cursor-suspend.html

  * igt@testdisplay:
    - shard-kbl:          [PASS][5] -> [TIMEOUT][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl1/igt@testdisplay.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl4/igt@testdisplay.html

  

### Piglit changes ###

#### Possible regressions ####

  * spec@glsl-1.30@execution@tex-miplevel-selection textureprojlod 2d (NEW):
    - pig-snb-2600:       NOTRUN -> [FAIL][7]
   [7]: None

  
New tests
---------

  New tests have been introduced between CI_DRM_10600_full and Patchwork_21080_full:

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

  * igt@i915_query@hwconfig_table:
    - Statuses :
    - Exec time: [None] s

  


### New Piglit tests (1) ###

  * spec@glsl-1.30@execution@tex-miplevel-selection textureprojlod 2d:
    - Statuses : 1 fail(s)
    - Exec time: [7.20] s

  

Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@core_hotunplug@unbind-rebind:
    - shard-kbl:          [PASS][8] -> [INCOMPLETE][9] ([i915#4130])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl7/igt@core_hotunplug@unbind-rebind.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl6/igt@core_hotunplug@unbind-rebind.html

  * igt@drm_import_export@prime:
    - shard-kbl:          [PASS][10] -> [INCOMPLETE][11] ([i915#2895] / [i915#2944])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl6/igt@drm_import_export@prime.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@drm_import_export@prime.html

  * igt@gem_ctx_sseu@engines:
    - shard-tglb:         NOTRUN -> [SKIP][12] ([i915#280])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb7/igt@gem_ctx_sseu@engines.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-iclb:         NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb3/igt@gem_exec_fair@basic-pace-solo@rcs0.html
    - shard-tglb:         NOTRUN -> [FAIL][14] ([i915#2842])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb6/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@gem_exec_fair@basic-sync@rcs0:
    - shard-kbl:          [PASS][15] -> [SKIP][16] ([fdo#109271])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl3/igt@gem_exec_fair@basic-sync@rcs0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl4/igt@gem_exec_fair@basic-sync@rcs0.html

  * igt@gem_pread@exhaustion:
    - shard-tglb:         NOTRUN -> [WARN][17] ([i915#2658])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb7/igt@gem_pread@exhaustion.html
    - shard-kbl:          NOTRUN -> [WARN][18] ([i915#2658])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@gem_pread@exhaustion.html

  * igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs:
    - shard-iclb:         NOTRUN -> [SKIP][19] ([i915#768]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb3/igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs.html

  * igt@gem_softpin@evict-snoop-interruptible:
    - shard-tglb:         NOTRUN -> [SKIP][20] ([fdo#109312])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb6/igt@gem_softpin@evict-snoop-interruptible.html

  * igt@gem_userptr_blits@create-destroy-unsync:
    - shard-tglb:         NOTRUN -> [SKIP][21] ([i915#3297])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@gem_userptr_blits@create-destroy-unsync.html
    - shard-iclb:         NOTRUN -> [SKIP][22] ([i915#3297])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb6/igt@gem_userptr_blits@create-destroy-unsync.html

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

  * igt@gen3_render_mixed_blits:
    - shard-tglb:         NOTRUN -> [SKIP][24] ([fdo#109289]) +2 similar issues
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@gen3_render_mixed_blits.html

  * igt@gen3_render_tiledx_blits:
    - shard-iclb:         NOTRUN -> [SKIP][25] ([fdo#109289]) +4 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb6/igt@gen3_render_tiledx_blits.html

  * igt@gen9_exec_parse@bb-start-cmd:
    - shard-tglb:         NOTRUN -> [SKIP][26] ([i915#2856]) +4 similar issues
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@gen9_exec_parse@bb-start-cmd.html

  * igt@gen9_exec_parse@unaligned-access:
    - shard-iclb:         NOTRUN -> [SKIP][27] ([i915#2856]) +2 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb8/igt@gen9_exec_parse@unaligned-access.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [PASS][28] -> [FAIL][29] ([i915#454])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-iclb2/igt@i915_pm_dc@dc6-dpms.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_pm_rc6_residency@media-rc6-accuracy:
    - shard-tglb:         NOTRUN -> [SKIP][30] ([fdo#109289] / [fdo#111719])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb3/igt@i915_pm_rc6_residency@media-rc6-accuracy.html

  * igt@i915_pm_rc6_residency@rc6-fence:
    - shard-tglb:         NOTRUN -> [WARN][31] ([i915#2681])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb7/igt@i915_pm_rc6_residency@rc6-fence.html

  * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
    - shard-tglb:         NOTRUN -> [SKIP][32] ([fdo#111644] / [i915#1397] / [i915#2411])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
    - shard-iclb:         NOTRUN -> [SKIP][33] ([fdo#110892])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb8/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
    - shard-tglb:         NOTRUN -> [SKIP][34] ([fdo#109506] / [i915#2411])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@i915_pm_rpm@modeset-pc8-residency-stress.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-tglb:         [PASS][35] -> [INCOMPLETE][36] ([i915#456]) +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb1/igt@i915_suspend@fence-restore-tiled2untiled.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb2/igt@i915_suspend@fence-restore-tiled2untiled.html
    - shard-skl:          [PASS][37] -> [INCOMPLETE][38] ([i915#198])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl5/igt@i915_suspend@fence-restore-tiled2untiled.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl3/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@i915_suspend@sysfs-reader:
    - shard-kbl:          [PASS][39] -> [DMESG-WARN][40] ([i915#180])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl7/igt@i915_suspend@sysfs-reader.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl4/igt@i915_suspend@sysfs-reader.html

  * igt@kms_big_fb@x-tiled-16bpp-rotate-90:
    - shard-tglb:         NOTRUN -> [SKIP][41] ([fdo#111614])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@kms_big_fb@x-tiled-16bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-90:
    - shard-iclb:         NOTRUN -> [SKIP][42] ([fdo#110725] / [fdo#111614])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb7/igt@kms_big_fb@x-tiled-64bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
    - shard-kbl:          NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#3777]) +1 similar issue
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl6/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
    - shard-skl:          NOTRUN -> [SKIP][44] ([fdo#109271] / [i915#3777]) +1 similar issue
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl10/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
    - shard-skl:          NOTRUN -> [FAIL][45] ([i915#3763])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl10/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-180:
    - shard-iclb:         NOTRUN -> [SKIP][46] ([fdo#110723]) +1 similar issue
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb2/igt@kms_big_fb@yf-tiled-64bpp-rotate-180.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip:
    - shard-tglb:         NOTRUN -> [SKIP][47] ([fdo#111615]) +4 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][48] ([i915#3689]) +8 similar issues
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_ccs.html

  * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
    - shard-skl:          NOTRUN -> [SKIP][49] ([fdo#109271] / [i915#3886]) +6 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl9/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
    - shard-iclb:         NOTRUN -> [SKIP][50] ([fdo#109278] / [i915#3886]) +3 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb2/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
    - shard-kbl:          NOTRUN -> [SKIP][51] ([fdo#109271] / [i915#3886]) +12 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl4/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][52] ([i915#3689] / [i915#3886]) +3 similar issues
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-d-crc-primary-rotation-180-yf_tiled_ccs:
    - shard-iclb:         NOTRUN -> [SKIP][53] ([fdo#109278]) +8 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb1/igt@kms_ccs@pipe-d-crc-primary-rotation-180-yf_tiled_ccs.html

  * igt@kms_color@pipe-c-ctm-0-25:
    - shard-skl:          [PASS][54] -> [SKIP][55] ([fdo#109271]) +6 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl7/igt@kms_color@pipe-c-ctm-0-25.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl5/igt@kms_color@pipe-c-ctm-0-25.html

  * igt@kms_color@pipe-d-ctm-max:
    - shard-skl:          NOTRUN -> [SKIP][56] ([fdo#109271]) +81 similar issues
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl7/igt@kms_color@pipe-d-ctm-max.html
    - shard-iclb:         NOTRUN -> [SKIP][57] ([fdo#109278] / [i915#1149]) +1 similar issue
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb4/igt@kms_color@pipe-d-ctm-max.html

  * igt@kms_color_chamelium@pipe-a-ctm-blue-to-red:
    - shard-kbl:          NOTRUN -> [SKIP][58] ([fdo#109271] / [fdo#111827]) +27 similar issues
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@kms_color_chamelium@pipe-a-ctm-blue-to-red.html

  * igt@kms_color_chamelium@pipe-d-ctm-negative:
    - shard-iclb:         NOTRUN -> [SKIP][59] ([fdo#109278] / [fdo#109284] / [fdo#111827]) +1 similar issue
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb3/igt@kms_color_chamelium@pipe-d-ctm-negative.html

  * igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes:
    - shard-skl:          NOTRUN -> [SKIP][60] ([fdo#109271] / [fdo#111827]) +7 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl1/igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes.html

  * igt@kms_color_chamelium@pipe-invalid-degamma-lut-sizes:
    - shard-tglb:         NOTRUN -> [SKIP][61] ([fdo#109284] / [fdo#111827]) +12 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@kms_color_chamelium@pipe-invalid-degamma-lut-sizes.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
    - shard-iclb:         NOTRUN -> [SKIP][62] ([fdo#109284] / [fdo#111827]) +6 similar issues
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb2/igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_content_protection@legacy:
    - shard-kbl:          NOTRUN -> [TIMEOUT][63] ([i915#1319]) +1 similar issue
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@kms_content_protection@legacy.html

  * igt@kms_content_protection@type1:
    - shard-iclb:         NOTRUN -> [SKIP][64] ([fdo#109300] / [fdo#111066])
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb7/igt@kms_content_protection@type1.html

  * igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen:
    - shard-tglb:         NOTRUN -> [SKIP][65] ([fdo#109279] / [i915#3359]) +5 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-32x10-random:
    - shard-tglb:         NOTRUN -> [SKIP][66] ([i915#3359]) +3 similar issues
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb2/igt@kms_cursor_crc@pipe-b-cursor-32x10-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-512x512-random:
    - shard-iclb:         NOTRUN -> [SKIP][67] ([fdo#109278] / [fdo#109279])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb6/igt@kms_cursor_crc@pipe-c-cursor-512x512-random.html

  * igt@kms_cursor_crc@pipe-d-cursor-suspend:
    - shard-kbl:          NOTRUN -> [SKIP][68] ([fdo#109271]) +242 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@kms_cursor_crc@pipe-d-cursor-suspend.html

  * igt@kms_cursor_legacy@cursora-vs-flipb-atomic:
    - shard-tglb:         NOTRUN -> [SKIP][69] ([fdo#111825]) +30 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb2/igt@kms_cursor_legacy@cursora-vs-flipb-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
    - shard-skl:          [PASS][70] -> [FAIL][71] ([i915#2346] / [i915#533])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
    - shard-skl:          [PASS][72] -> [FAIL][73] ([i915#2346])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl4/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html

  * igt@kms_cursor_legacy@pipe-d-single-bo:
    - shard-kbl:          NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#533]) +1 similar issue
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@kms_cursor_legacy@pipe-d-single-bo.html

  * igt@kms_cursor_legacy@pipe-d-torture-bo:
    - shard-skl:          NOTRUN -> [SKIP][75] ([fdo#109271] / [i915#533])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl9/igt@kms_cursor_legacy@pipe-d-torture-bo.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          NOTRUN -> [INCOMPLETE][76] ([i915#155] / [i915#180] / [i915#636])
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@2x-flip-vs-rmfb-interruptible:
    - shard-iclb:         NOTRUN -> [SKIP][77] ([fdo#109274]) +2 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb2/igt@kms_flip@2x-flip-vs-rmfb-interruptible.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
    - shard-skl:          [PASS][78] -> [FAIL][79] ([i915#2122]) +1 similar issue
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl1/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl7/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
    - shard-skl:          NOTRUN -> [FAIL][80] ([i915#2122]) +1 similar issue
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl1/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-tglb:         [PASS][81] -> [INCOMPLETE][82] ([i915#2411] / [i915#456]) +1 similar issue
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb7/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-pwrite:
    - shard-iclb:         NOTRUN -> [SKIP][83] ([fdo#109280]) +12 similar issues
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-pwrite.html

  * igt@kms_hdr@bpc-switch-dpms:
    - shard-skl:          [PASS][84] -> [FAIL][85] ([i915#1188])
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl1/igt@kms_hdr@bpc-switch-dpms.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][86] ([i915#180]) +4 similar issues
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl4/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
    - shard-skl:          NOTRUN -> [FAIL][87] ([fdo#108145] / [i915#265]) +1 similar issue
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl2/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
    - shard-skl:          NOTRUN -> [FAIL][88] ([i915#265]) +1 similar issue
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [PASS][89] -> [FAIL][90] ([fdo#108145] / [i915#265]) +1 similar issue
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl5/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
    - shard-kbl:          NOTRUN -> [FAIL][91] ([fdo#108145] / [i915#265]) +2 similar issues
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb.html

  * igt@kms_plane_lowres@pipe-c-tiling-x:
    - shard-tglb:         NOTRUN -> [SKIP][92] ([i915#3536])
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_plane_lowres@pipe-c-tiling-x.html

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
    - shard-tglb:         NOTRUN -> [SKIP][93] ([fdo#112054])
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_plane_multiple@atomic-pipe-b-tiling-yf.html

  * igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
    - shard-kbl:          NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#2733])
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3:
    - shard-kbl:          NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#658]) +5 similar issues
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl6/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3.html
    - shard-tglb:         NOTRUN -> [SKIP][96] ([i915#2920])
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
    - shard-iclb:         NOTRUN -> [SKIP][97] ([i915#658])
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb5/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html

  * igt@kms_psr2_su@page_flip:
    - shard-tglb:         NOTRUN -> [SKIP][98] ([i915#1911])
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb2/igt@kms_psr2_su@page_flip.html
    - shard-skl:          NOTRUN -> [SKIP][99] ([fdo#109271] / [i915#658]) +1 similar issue
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl3/igt@kms_psr2_su@page_flip.html
    - shard-iclb:         NOTRUN -> [SKIP][100] ([fdo#109642] / [fdo#111068] / [i915#658])
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb4/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_basic:
    - shard-tglb:         NOTRUN -> [FAIL][101] ([i915#132] / [i915#3467])
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@kms_psr@psr2_basic.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [PASS][102] -> [SKIP][103] ([fdo#109441])
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb6/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_psr@psr2_sprite_blt:
    - shard-iclb:         NOTRUN -> [SKIP][104] ([fdo#109441])
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb8/igt@kms_psr@psr2_sprite_blt.html

  * igt@kms_sysfs_edid_timing:
    - shard-kbl:          NOTRUN -> [FAIL][105] ([IGT#2])
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl7/igt@kms_sysfs_edid_timing.html

  * igt@kms_vrr@flip-suspend:
    - shard-iclb:         NOTRUN -> [SKIP][106] ([fdo#109502])
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb8/igt@kms_vrr@flip-suspend.html

  * igt@kms_writeback@writeback-fb-id:
    - shard-kbl:          NOTRUN -> [SKIP][107] ([fdo#109271] / [i915#2437])
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl6/igt@kms_writeback@writeback-fb-id.html

  * igt@nouveau_crc@pipe-d-ctx-flip-detection:
    - shard-tglb:         NOTRUN -> [SKIP][108] ([i915#2530]) +2 similar issues
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb3/igt@nouveau_crc@pipe-d-ctx-flip-detection.html

  * igt@prime_nv_api@i915_nv_import_vs_close:
    - shard-tglb:         NOTRUN -> [SKIP][109] ([fdo#109291])
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@prime_nv_api@i915_nv_import_vs_close.html

  * igt@sysfs_clients@sema-25:
    - shard-iclb:         NOTRUN -> [SKIP][110] ([i915#2994])
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb6/igt@sysfs_clients@sema-25.html
    - shard-tglb:         NOTRUN -> [SKIP][111] ([i915#2994]) +1 similar issue
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@sysfs_clients@sema-25.html

  * igt@sysfs_clients@sema-50:
    - shard-kbl:          NOTRUN -> [SKIP][112] ([fdo#109271] / [i915#2994]) +4 similar issues
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl3/igt@sysfs_clients@sema-50.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@many-contexts:
    - shard-tglb:         [FAIL][113] ([i915#2410]) -> [PASS][114]
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb3/igt@gem_ctx_persistence@many-contexts.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@gem_ctx_persistence@many-contexts.html

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         [TIMEOUT][115] ([i915#2369] / [i915#3063] / [i915#3648]) -> [PASS][116]
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb8/igt@gem_eio@unwedge-stress.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb8/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace@vcs1:
    - shard-kbl:          [SKIP][117] ([fdo#109271]) -> [PASS][118]
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl3/igt@gem_exec_fair@basic-pace@vcs1.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
    - shard-kbl:          [FAIL][119] ([i915#2842]) -> [PASS][120]
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl3/igt@gem_exec_fair@basic-pace@vecs0.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-iclb:         [FAIL][121] ([i915#2849]) -> [PASS][122]
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-skl:          [DMESG-WARN][123] ([i915#1436] / [i915#716]) -> [PASS][124]
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl9/igt@gen9_exec_parse@allowed-single.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl9/igt@gen9_exec_parse@allowed-single.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
    - shard-tglb:         [INCOMPLETE][125] ([i915#2411] / [i915#456] / [i915#750]) -> [PASS][126]
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb7/igt@i915_pm_rpm@system-suspend-execbuf.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb1/igt@i915_pm_rpm@system-suspend-execbuf.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
    - shard-skl:          [FAIL][127] ([i915#79]) -> [PASS][128]
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl6/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-skl1/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][129] ([i915#180]) -> [PASS][130] +1 similar issue
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-tglb:         [INCOMPLETE][131] ([i915#2828] / [i915#456]) -> [PASS][132]
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-tglb7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21080/shard-tglb5/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][133] ([fdo#108145] / [i915#265]) -> [PASS][134]
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10600/shard-skl3/igt@kms_plane_alpha_blend@p

== Logs ==

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

[-- Attachment #2: Type: text/html, Size: 33774 bytes --]

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

<John.C.Harrison@Intel.com> writes:

> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.
>
> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
>   struct drm_i915_query_item item = {
>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>   };
>   query.items_ptr = (int64_t) &item;
>   query.num_items = 1;
>
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   if (item.length <= 0)
>     return -ENOENT;
>
>   data = malloc(item.length);
>   item.data_ptr = (int64_t) &data;
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
>   enum device_attr {
>      ATTR_SOME_VALUE = 0,
>      ATTR_SOME_MASK  = 1,
>   };
>
>   static const u32 hwconfig[] = {
>       ATTR_SOME_VALUE,
>       1,             // Value Length in DWords
>       8,             // Value
>
>       ATTR_SOME_MASK,
>       3,
>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>   };

Seems simple enough, so why doesn't i915 define the format of the
returned hwconfig blob in i915_drm.h?

struct drm_i915_hwconfig {
	uint32_t key;
	uint32_t length;
	uint32_t values[];
};

It sounds like the kernel depends on the closed source guc being loaded
to return this information. Is that right? Will i915 also become
dependent on some of this data such that it won't be able to initialize
without the firmware being loaded?

> The attribute ids are defined in a hardware spec.

Which spec?

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

<John.C.Harrison@Intel.com> writes:

> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.
>
> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
>   struct drm_i915_query_item item = {
>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>   };
>   query.items_ptr = (int64_t) &item;
>   query.num_items = 1;
>
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   if (item.length <= 0)
>     return -ENOENT;
>
>   data = malloc(item.length);
>   item.data_ptr = (int64_t) &data;
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
>   enum device_attr {
>      ATTR_SOME_VALUE = 0,
>      ATTR_SOME_MASK  = 1,
>   };
>
>   static const u32 hwconfig[] = {
>       ATTR_SOME_VALUE,
>       1,             // Value Length in DWords
>       8,             // Value
>
>       ATTR_SOME_MASK,
>       3,
>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>   };

Seems simple enough, so why doesn't i915 define the format of the
returned hwconfig blob in i915_drm.h?

struct drm_i915_hwconfig {
	uint32_t key;
	uint32_t length;
	uint32_t values[];
};

It sounds like the kernel depends on the closed source guc being loaded
to return this information. Is that right? Will i915 also become
dependent on some of this data such that it won't be able to initialize
without the firmware being loaded?

> The attribute ids are defined in a hardware spec.

Which spec?

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John Harrison]

On 11/1/2021 08:39, Jordan Justen wrote:
> <John.C.Harrison@Intel.com> writes:
>
>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>>    struct drm_i915_query_item item = {
>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>    };
>>    query.items_ptr = (int64_t) &item;
>>    query.num_items = 1;
>>
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    if (item.length <= 0)
>>      return -ENOENT;
>>
>>    data = malloc(item.length);
>>    item.data_ptr = (int64_t) &data;
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>>    enum device_attr {
>>       ATTR_SOME_VALUE = 0,
>>       ATTR_SOME_MASK  = 1,
>>    };
>>
>>    static const u32 hwconfig[] = {
>>        ATTR_SOME_VALUE,
>>        1,             // Value Length in DWords
>>        8,             // Value
>>
>>        ATTR_SOME_MASK,
>>        3,
>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>    };
> Seems simple enough, so why doesn't i915 define the format of the
> returned hwconfig blob in i915_drm.h?
Because the definition is nothing to do with i915. This table comes from 
the hardware spec. It is not defined by the KMD and it is not currently 
used by the KMD. So there is no reason for the KMD to be creating 
structures for it in the same way that the KMD does not document, 
define, struct, etc. every other feature of the hardware that the UMDs 
might use.

>
> struct drm_i915_hwconfig {
> 	uint32_t key;
> 	uint32_t length;
> 	uint32_t values[];
> };
>
> It sounds like the kernel depends on the closed source guc being loaded
> to return this information. Is that right? Will i915 also become
> dependent on some of this data such that it won't be able to initialize
> without the firmware being loaded?
At the moment, the KMD does not use the table at all. We merely provide 
a mechanism for the UMDs to retrieve it from the hardware.

In terms of future direction, that is something you need to take up with 
the hardware architects.


>> The attribute ids are defined in a hardware spec.
> Which spec?

Unfortunately, it is not one that is currently public. We are pushing 
the relevant people to get it included in the public bspec / HRM. It is 
a slow process :(.

John.


>
> -Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John Harrison]

On 11/1/2021 08:39, Jordan Justen wrote:
> <John.C.Harrison@Intel.com> writes:
>
>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>>    struct drm_i915_query_item item = {
>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>    };
>>    query.items_ptr = (int64_t) &item;
>>    query.num_items = 1;
>>
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    if (item.length <= 0)
>>      return -ENOENT;
>>
>>    data = malloc(item.length);
>>    item.data_ptr = (int64_t) &data;
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>>    enum device_attr {
>>       ATTR_SOME_VALUE = 0,
>>       ATTR_SOME_MASK  = 1,
>>    };
>>
>>    static const u32 hwconfig[] = {
>>        ATTR_SOME_VALUE,
>>        1,             // Value Length in DWords
>>        8,             // Value
>>
>>        ATTR_SOME_MASK,
>>        3,
>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>    };
> Seems simple enough, so why doesn't i915 define the format of the
> returned hwconfig blob in i915_drm.h?
Because the definition is nothing to do with i915. This table comes from 
the hardware spec. It is not defined by the KMD and it is not currently 
used by the KMD. So there is no reason for the KMD to be creating 
structures for it in the same way that the KMD does not document, 
define, struct, etc. every other feature of the hardware that the UMDs 
might use.

>
> struct drm_i915_hwconfig {
> 	uint32_t key;
> 	uint32_t length;
> 	uint32_t values[];
> };
>
> It sounds like the kernel depends on the closed source guc being loaded
> to return this information. Is that right? Will i915 also become
> dependent on some of this data such that it won't be able to initialize
> without the firmware being loaded?
At the moment, the KMD does not use the table at all. We merely provide 
a mechanism for the UMDs to retrieve it from the hardware.

In terms of future direction, that is something you need to take up with 
the hardware architects.


>> The attribute ids are defined in a hardware spec.
> Which spec?

Unfortunately, it is not one that is currently public. We are pushing 
the relevant people to get it included in the public bspec / HRM. It is 
a slow process :(.

John.


>
> -Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

John Harrison <john.c.harrison@intel.com> writes:

> On 11/1/2021 08:39, Jordan Justen wrote:
>> <John.C.Harrison@Intel.com> writes:
>>
>>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>
>>> GuC contains a consolidated table with a bunch of information about the
>>> current device.
>>>
>>> Previously, this information was spread and hardcoded to all the components
>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>> the data into GuC in a way that all interested components can grab the
>>> very latest and synchronized information using a simple query.
>>>
>>> As per most of the other queries, this one can be called twice.
>>> Once with item.length=0 to determine the exact buffer size, then
>>> allocate the user memory and call it again for to retrieve the
>>> table data. For example:
>>>    struct drm_i915_query_item item = {
>>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>    };
>>>    query.items_ptr = (int64_t) &item;
>>>    query.num_items = 1;
>>>
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    if (item.length <= 0)
>>>      return -ENOENT;
>>>
>>>    data = malloc(item.length);
>>>    item.data_ptr = (int64_t) &data;
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    // Parse the data as appropriate...
>>>
>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>> formatted table. For example, it could be just:
>>>    enum device_attr {
>>>       ATTR_SOME_VALUE = 0,
>>>       ATTR_SOME_MASK  = 1,
>>>    };
>>>
>>>    static const u32 hwconfig[] = {
>>>        ATTR_SOME_VALUE,
>>>        1,             // Value Length in DWords
>>>        8,             // Value
>>>
>>>        ATTR_SOME_MASK,
>>>        3,
>>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>    };
>> Seems simple enough, so why doesn't i915 define the format of the
>> returned hwconfig blob in i915_drm.h?
> Because the definition is nothing to do with i915. This table comes from 
> the hardware spec. It is not defined by the KMD and it is not currently 
> used by the KMD. So there is no reason for the KMD to be creating 
> structures for it in the same way that the KMD does not document, 
> define, struct, etc. every other feature of the hardware that the UMDs 
> might use.

So, i915 wants to wash it's hands completely of the format? There is
obviously a difference between hardware features and a blob coming from
closed source software. (Which i915 just happens to be passing along.)
The hardware is a lot more difficult to change...

It seems like these details should be dropped from the i915 patch commit
message since i915 wants nothing to do with it.

I would think it'd be preferable for i915 to stand behind the basic blob
format as is (even if the keys/values can't be defined), and make a new
query item if the closed source software changes the format.

Of course, it'd be even better if i915 could define some keys/values as
well. (Or if a spec could be released to help document / tie down the
format.)

>>
>> struct drm_i915_hwconfig {
>> 	uint32_t key;
>> 	uint32_t length;
>> 	uint32_t values[];
>> };
>>
>> It sounds like the kernel depends on the closed source guc being loaded
>> to return this information. Is that right? Will i915 also become
>> dependent on some of this data such that it won't be able to initialize
>> without the firmware being loaded?
> At the moment, the KMD does not use the table at all. We merely provide 
> a mechanism for the UMDs to retrieve it from the hardware.
>
> In terms of future direction, that is something you need to take up with 
> the hardware architects.
>

Why do you keep saying hardware, when only software is involved?

>
>>> The attribute ids are defined in a hardware spec.
>> Which spec?
>
> Unfortunately, it is not one that is currently public. We are pushing 
> the relevant people to get it included in the public bspec / HRM. It is 
> a slow process :(.
>

Right. I take it no progress has been made in the 1.5 months since you
posted this, so it'll probably finally be documented 6~12 months after
hardware is available? :)

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

John Harrison <john.c.harrison@intel.com> writes:

> On 11/1/2021 08:39, Jordan Justen wrote:
>> <John.C.Harrison@Intel.com> writes:
>>
>>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>
>>> GuC contains a consolidated table with a bunch of information about the
>>> current device.
>>>
>>> Previously, this information was spread and hardcoded to all the components
>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>> the data into GuC in a way that all interested components can grab the
>>> very latest and synchronized information using a simple query.
>>>
>>> As per most of the other queries, this one can be called twice.
>>> Once with item.length=0 to determine the exact buffer size, then
>>> allocate the user memory and call it again for to retrieve the
>>> table data. For example:
>>>    struct drm_i915_query_item item = {
>>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>    };
>>>    query.items_ptr = (int64_t) &item;
>>>    query.num_items = 1;
>>>
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    if (item.length <= 0)
>>>      return -ENOENT;
>>>
>>>    data = malloc(item.length);
>>>    item.data_ptr = (int64_t) &data;
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    // Parse the data as appropriate...
>>>
>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>> formatted table. For example, it could be just:
>>>    enum device_attr {
>>>       ATTR_SOME_VALUE = 0,
>>>       ATTR_SOME_MASK  = 1,
>>>    };
>>>
>>>    static const u32 hwconfig[] = {
>>>        ATTR_SOME_VALUE,
>>>        1,             // Value Length in DWords
>>>        8,             // Value
>>>
>>>        ATTR_SOME_MASK,
>>>        3,
>>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>    };
>> Seems simple enough, so why doesn't i915 define the format of the
>> returned hwconfig blob in i915_drm.h?
> Because the definition is nothing to do with i915. This table comes from 
> the hardware spec. It is not defined by the KMD and it is not currently 
> used by the KMD. So there is no reason for the KMD to be creating 
> structures for it in the same way that the KMD does not document, 
> define, struct, etc. every other feature of the hardware that the UMDs 
> might use.

So, i915 wants to wash it's hands completely of the format? There is
obviously a difference between hardware features and a blob coming from
closed source software. (Which i915 just happens to be passing along.)
The hardware is a lot more difficult to change...

It seems like these details should be dropped from the i915 patch commit
message since i915 wants nothing to do with it.

I would think it'd be preferable for i915 to stand behind the basic blob
format as is (even if the keys/values can't be defined), and make a new
query item if the closed source software changes the format.

Of course, it'd be even better if i915 could define some keys/values as
well. (Or if a spec could be released to help document / tie down the
format.)

>>
>> struct drm_i915_hwconfig {
>> 	uint32_t key;
>> 	uint32_t length;
>> 	uint32_t values[];
>> };
>>
>> It sounds like the kernel depends on the closed source guc being loaded
>> to return this information. Is that right? Will i915 also become
>> dependent on some of this data such that it won't be able to initialize
>> without the firmware being loaded?
> At the moment, the KMD does not use the table at all. We merely provide 
> a mechanism for the UMDs to retrieve it from the hardware.
>
> In terms of future direction, that is something you need to take up with 
> the hardware architects.
>

Why do you keep saying hardware, when only software is involved?

>
>>> The attribute ids are defined in a hardware spec.
>> Which spec?
>
> Unfortunately, it is not one that is currently public. We are pushing 
> the relevant people to get it included in the public bspec / HRM. It is 
> a slow process :(.
>

Right. I take it no progress has been made in the 1.5 months since you
posted this, so it'll probably finally be documented 6~12 months after
hardware is available? :)

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John Harrison]

On 11/3/2021 14:38, Jordan Justen wrote:
> John Harrison <john.c.harrison@intel.com> writes:
>
>> On 11/1/2021 08:39, Jordan Justen wrote:
>>> <John.C.Harrison@Intel.com> writes:
>>>
>>>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>
>>>> GuC contains a consolidated table with a bunch of information about the
>>>> current device.
>>>>
>>>> Previously, this information was spread and hardcoded to all the components
>>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>>> the data into GuC in a way that all interested components can grab the
>>>> very latest and synchronized information using a simple query.
>>>>
>>>> As per most of the other queries, this one can be called twice.
>>>> Once with item.length=0 to determine the exact buffer size, then
>>>> allocate the user memory and call it again for to retrieve the
>>>> table data. For example:
>>>>     struct drm_i915_query_item item = {
>>>>       .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>>     };
>>>>     query.items_ptr = (int64_t) &item;
>>>>     query.num_items = 1;
>>>>
>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>
>>>>     if (item.length <= 0)
>>>>       return -ENOENT;
>>>>
>>>>     data = malloc(item.length);
>>>>     item.data_ptr = (int64_t) &data;
>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>
>>>>     // Parse the data as appropriate...
>>>>
>>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>>> formatted table. For example, it could be just:
>>>>     enum device_attr {
>>>>        ATTR_SOME_VALUE = 0,
>>>>        ATTR_SOME_MASK  = 1,
>>>>     };
>>>>
>>>>     static const u32 hwconfig[] = {
>>>>         ATTR_SOME_VALUE,
>>>>         1,             // Value Length in DWords
>>>>         8,             // Value
>>>>
>>>>         ATTR_SOME_MASK,
>>>>         3,
>>>>         0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>>     };
>>> Seems simple enough, so why doesn't i915 define the format of the
>>> returned hwconfig blob in i915_drm.h?
>> Because the definition is nothing to do with i915. This table comes from
>> the hardware spec. It is not defined by the KMD and it is not currently
>> used by the KMD. So there is no reason for the KMD to be creating
>> structures for it in the same way that the KMD does not document,
>> define, struct, etc. every other feature of the hardware that the UMDs
>> might use.
> So, i915 wants to wash it's hands completely of the format? There is
> obviously a difference between hardware features and a blob coming from
> closed source software. (Which i915 just happens to be passing along.)
> The hardware is a lot more difficult to change...
Actually, no. The table is not "coming from closed source software". The 
table is defined by hardware specs. It is a table of hardware specific 
values. It is not being invented by the GuC just for fun or as a way to 
subvert the universe into the realms of closed source software. As per 
KMD, GuC is merely passing the table through. The table is only 
supported on newer hardware platforms and all GuC does is provide a 
mechanism for the KMD to retrieve it because the KMD cannot access it 
directly. The table contents are defined by hardware architects same as 
all the other aspects of the hardware.

>
> It seems like these details should be dropped from the i915 patch commit
> message since i915 wants nothing to do with it.
Sure. Can remove comments.

>
> I would think it'd be preferable for i915 to stand behind the basic blob
> format as is (even if the keys/values can't be defined), and make a new
> query item if the closed source software changes the format.
Close source software is not allowed to change the format because closed 
source software has no say in defining the format. The format is 
officially defined as being fixed in the spec. New key values can be 
added to the key enumeration but existing values cannot be deprecated 
and re-purposed. The table must be stable across all OSs and all 
platforms. No software can arbitrarily decide to change it.

>
> Of course, it'd be even better if i915 could define some keys/values as
> well. (Or if a spec could be released to help document / tie down the
> format.)
See the corresponding IGT test that details all the currently defined keys.


>
>>> struct drm_i915_hwconfig {
>>> 	uint32_t key;
>>> 	uint32_t length;
>>> 	uint32_t values[];
>>> };
>>>
>>> It sounds like the kernel depends on the closed source guc being loaded
>>> to return this information. Is that right? Will i915 also become
>>> dependent on some of this data such that it won't be able to initialize
>>> without the firmware being loaded?
>> At the moment, the KMD does not use the table at all. We merely provide
>> a mechanism for the UMDs to retrieve it from the hardware.
>>
>> In terms of future direction, that is something you need to take up with
>> the hardware architects.
>>
> Why do you keep saying hardware, when only software is involved?
See above - because the table is defined by hardware. No software, 
closed or open, has any say in the specification of the table.

John.


>
>>>> The attribute ids are defined in a hardware spec.
>>> Which spec?
>> Unfortunately, it is not one that is currently public. We are pushing
>> the relevant people to get it included in the public bspec / HRM. It is
>> a slow process :(.
>>
> Right. I take it no progress has been made in the 1.5 months since you
> posted this, so it'll probably finally be documented 6~12 months after
> hardware is available? :)
>
> -Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[John Harrison]

On 11/3/2021 14:38, Jordan Justen wrote:
> John Harrison <john.c.harrison@intel.com> writes:
>
>> On 11/1/2021 08:39, Jordan Justen wrote:
>>> <John.C.Harrison@Intel.com> writes:
>>>
>>>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>
>>>> GuC contains a consolidated table with a bunch of information about the
>>>> current device.
>>>>
>>>> Previously, this information was spread and hardcoded to all the components
>>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>>> the data into GuC in a way that all interested components can grab the
>>>> very latest and synchronized information using a simple query.
>>>>
>>>> As per most of the other queries, this one can be called twice.
>>>> Once with item.length=0 to determine the exact buffer size, then
>>>> allocate the user memory and call it again for to retrieve the
>>>> table data. For example:
>>>>     struct drm_i915_query_item item = {
>>>>       .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>>     };
>>>>     query.items_ptr = (int64_t) &item;
>>>>     query.num_items = 1;
>>>>
>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>
>>>>     if (item.length <= 0)
>>>>       return -ENOENT;
>>>>
>>>>     data = malloc(item.length);
>>>>     item.data_ptr = (int64_t) &data;
>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>
>>>>     // Parse the data as appropriate...
>>>>
>>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>>> formatted table. For example, it could be just:
>>>>     enum device_attr {
>>>>        ATTR_SOME_VALUE = 0,
>>>>        ATTR_SOME_MASK  = 1,
>>>>     };
>>>>
>>>>     static const u32 hwconfig[] = {
>>>>         ATTR_SOME_VALUE,
>>>>         1,             // Value Length in DWords
>>>>         8,             // Value
>>>>
>>>>         ATTR_SOME_MASK,
>>>>         3,
>>>>         0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>>     };
>>> Seems simple enough, so why doesn't i915 define the format of the
>>> returned hwconfig blob in i915_drm.h?
>> Because the definition is nothing to do with i915. This table comes from
>> the hardware spec. It is not defined by the KMD and it is not currently
>> used by the KMD. So there is no reason for the KMD to be creating
>> structures for it in the same way that the KMD does not document,
>> define, struct, etc. every other feature of the hardware that the UMDs
>> might use.
> So, i915 wants to wash it's hands completely of the format? There is
> obviously a difference between hardware features and a blob coming from
> closed source software. (Which i915 just happens to be passing along.)
> The hardware is a lot more difficult to change...
Actually, no. The table is not "coming from closed source software". The 
table is defined by hardware specs. It is a table of hardware specific 
values. It is not being invented by the GuC just for fun or as a way to 
subvert the universe into the realms of closed source software. As per 
KMD, GuC is merely passing the table through. The table is only 
supported on newer hardware platforms and all GuC does is provide a 
mechanism for the KMD to retrieve it because the KMD cannot access it 
directly. The table contents are defined by hardware architects same as 
all the other aspects of the hardware.

>
> It seems like these details should be dropped from the i915 patch commit
> message since i915 wants nothing to do with it.
Sure. Can remove comments.

>
> I would think it'd be preferable for i915 to stand behind the basic blob
> format as is (even if the keys/values can't be defined), and make a new
> query item if the closed source software changes the format.
Close source software is not allowed to change the format because closed 
source software has no say in defining the format. The format is 
officially defined as being fixed in the spec. New key values can be 
added to the key enumeration but existing values cannot be deprecated 
and re-purposed. The table must be stable across all OSs and all 
platforms. No software can arbitrarily decide to change it.

>
> Of course, it'd be even better if i915 could define some keys/values as
> well. (Or if a spec could be released to help document / tie down the
> format.)
See the corresponding IGT test that details all the currently defined keys.


>
>>> struct drm_i915_hwconfig {
>>> 	uint32_t key;
>>> 	uint32_t length;
>>> 	uint32_t values[];
>>> };
>>>
>>> It sounds like the kernel depends on the closed source guc being loaded
>>> to return this information. Is that right? Will i915 also become
>>> dependent on some of this data such that it won't be able to initialize
>>> without the firmware being loaded?
>> At the moment, the KMD does not use the table at all. We merely provide
>> a mechanism for the UMDs to retrieve it from the hardware.
>>
>> In terms of future direction, that is something you need to take up with
>> the hardware architects.
>>
> Why do you keep saying hardware, when only software is involved?
See above - because the table is defined by hardware. No software, 
closed or open, has any say in the specification of the table.

John.


>
>>>> The attribute ids are defined in a hardware spec.
>>> Which spec?
>> Unfortunately, it is not one that is currently public. We are pushing
>> the relevant people to get it included in the public bspec / HRM. It is
>> a slow process :(.
>>
> Right. I take it no progress has been made in the 1.5 months since you
> posted this, so it'll probably finally be documented 6~12 months after
> hardware is available? :)
>
> -Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

John Harrison <john.c.harrison@intel.com> writes:

> On 11/3/2021 14:38, Jordan Justen wrote:
>> So, i915 wants to wash it's hands completely of the format? There is
>> obviously a difference between hardware features and a blob coming from
>> closed source software. (Which i915 just happens to be passing along.)
>> The hardware is a lot more difficult to change...
> Actually, no. The table is not "coming from closed source software". The 
> table is defined by hardware specs. It is a table of hardware specific 
> values.

So, guc literally reads this info from the hardware verbatim? Then gives
it to i915 so i915 can give it to UMDs? Otherwise, it seems like a table
in software. Anyway...

>> It seems like these details should be dropped from the i915 patch commit
>> message since i915 wants nothing to do with it.
> Sure. Can remove comments.

Obviously not what should be done, but apparently all i915 is willing to
do.

>> I would think it'd be preferable for i915 to stand behind the basic blob
>> format as is (even if the keys/values can't be defined), and make a new
>> query item if the closed source software changes the format.
> Close source software is not allowed to change the format because closed 
> source software has no say in defining the format.

So, why can't i915 define this extremely simple (apparently
unchangeable) blob format, and thereby guarantee that it will have to
insulate UMDs if the format changes by making a different query item? It
ought to be made painful for everyone if this blob format changes.
Hopefully the format will basically never change. (Even if new
keys/values might be added.)

Further, it seems there is an implication that the keys will always be
backward compatible. Is that true, and if so, how can there be harm in
i915 enumerating the "known" ones?

>> Of course, it'd be even better if i915 could define some keys/values as
>> well. (Or if a spec could be released to help document / tie down the
>> format.)
> See the corresponding IGT test that details all the currently defined keys.

i915 can't/won't say anything about it, but look at this unmerged IGT
test? In the next sentence you'll say, but don't count on that because
IGT really has no control over it. :)

>>>>> The attribute ids are defined in a hardware spec.
>>>> Which spec?
>>> Unfortunately, it is not one that is currently public. We are pushing
>>> the relevant people to get it included in the public bspec / HRM. It is
>>> a slow process :(.
>>>
>> Right. I take it no progress has been made in the 1.5 months since you
>> posted this, so it'll probably finally be documented 6~12 months after
>> hardware is available? :)

Apparently all the data for this spec is "available" (in an unmerged IGT
patch), but am I correct in assuming that no actual spec timeframe is
defined?

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Jordan Justen]

John Harrison <john.c.harrison@intel.com> writes:

> On 11/3/2021 14:38, Jordan Justen wrote:
>> So, i915 wants to wash it's hands completely of the format? There is
>> obviously a difference between hardware features and a blob coming from
>> closed source software. (Which i915 just happens to be passing along.)
>> The hardware is a lot more difficult to change...
> Actually, no. The table is not "coming from closed source software". The 
> table is defined by hardware specs. It is a table of hardware specific 
> values.

So, guc literally reads this info from the hardware verbatim? Then gives
it to i915 so i915 can give it to UMDs? Otherwise, it seems like a table
in software. Anyway...

>> It seems like these details should be dropped from the i915 patch commit
>> message since i915 wants nothing to do with it.
> Sure. Can remove comments.

Obviously not what should be done, but apparently all i915 is willing to
do.

>> I would think it'd be preferable for i915 to stand behind the basic blob
>> format as is (even if the keys/values can't be defined), and make a new
>> query item if the closed source software changes the format.
> Close source software is not allowed to change the format because closed 
> source software has no say in defining the format.

So, why can't i915 define this extremely simple (apparently
unchangeable) blob format, and thereby guarantee that it will have to
insulate UMDs if the format changes by making a different query item? It
ought to be made painful for everyone if this blob format changes.
Hopefully the format will basically never change. (Even if new
keys/values might be added.)

Further, it seems there is an implication that the keys will always be
backward compatible. Is that true, and if so, how can there be harm in
i915 enumerating the "known" ones?

>> Of course, it'd be even better if i915 could define some keys/values as
>> well. (Or if a spec could be released to help document / tie down the
>> format.)
> See the corresponding IGT test that details all the currently defined keys.

i915 can't/won't say anything about it, but look at this unmerged IGT
test? In the next sentence you'll say, but don't count on that because
IGT really has no control over it. :)

>>>>> The attribute ids are defined in a hardware spec.
>>>> Which spec?
>>> Unfortunately, it is not one that is currently public. We are pushing
>>> the relevant people to get it included in the public bspec / HRM. It is
>>> a slow process :(.
>>>
>> Right. I take it no progress has been made in the 1.5 months since you
>> posted this, so it'll probably finally be documented 6~12 months after
>> hardware is available? :)

Apparently all the data for this spec is "available" (in an unmerged IGT
patch), but am I correct in assuming that no actual spec timeframe is
defined?

-Jordan

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table

[Lionel Landwerlin]

On 04/11/2021 01:49, John Harrison wrote:
> On 11/3/2021 14:38, Jordan Justen wrote:
>> John Harrison <john.c.harrison@intel.com> writes:
>>
>>> On 11/1/2021 08:39, Jordan Justen wrote:
>>>> <John.C.Harrison@Intel.com> writes:
>>>>
>>>>> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>>
>>>>> GuC contains a consolidated table with a bunch of information 
>>>>> about the
>>>>> current device.
>>>>>
>>>>> Previously, this information was spread and hardcoded to all the 
>>>>> components
>>>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>>>> the data into GuC in a way that all interested components can grab 
>>>>> the
>>>>> very latest and synchronized information using a simple query.
>>>>>
>>>>> As per most of the other queries, this one can be called twice.
>>>>> Once with item.length=0 to determine the exact buffer size, then
>>>>> allocate the user memory and call it again for to retrieve the
>>>>> table data. For example:
>>>>>     struct drm_i915_query_item item = {
>>>>>       .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>>>     };
>>>>>     query.items_ptr = (int64_t) &item;
>>>>>     query.num_items = 1;
>>>>>
>>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>>
>>>>>     if (item.length <= 0)
>>>>>       return -ENOENT;
>>>>>
>>>>>     data = malloc(item.length);
>>>>>     item.data_ptr = (int64_t) &data;
>>>>>     ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>>>
>>>>>     // Parse the data as appropriate...
>>>>>
>>>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>>>> formatted table. For example, it could be just:
>>>>>     enum device_attr {
>>>>>        ATTR_SOME_VALUE = 0,
>>>>>        ATTR_SOME_MASK  = 1,
>>>>>     };
>>>>>
>>>>>     static const u32 hwconfig[] = {
>>>>>         ATTR_SOME_VALUE,
>>>>>         1,             // Value Length in DWords
>>>>>         8,             // Value
>>>>>
>>>>>         ATTR_SOME_MASK,
>>>>>         3,
>>>>>         0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>>>     };
>>>> Seems simple enough, so why doesn't i915 define the format of the
>>>> returned hwconfig blob in i915_drm.h?
>>> Because the definition is nothing to do with i915. This table comes 
>>> from
>>> the hardware spec. It is not defined by the KMD and it is not currently
>>> used by the KMD. So there is no reason for the KMD to be creating
>>> structures for it in the same way that the KMD does not document,
>>> define, struct, etc. every other feature of the hardware that the UMDs
>>> might use.
>> So, i915 wants to wash it's hands completely of the format? There is
>> obviously a difference between hardware features and a blob coming from
>> closed source software. (Which i915 just happens to be passing along.)
>> The hardware is a lot more difficult to change...
> Actually, no. The table is not "coming from closed source software". 
> The table is defined by hardware specs. It is a table of hardware 
> specific values. It is not being invented by the GuC just for fun or 
> as a way to subvert the universe into the realms of closed source 
> software. As per KMD, GuC is merely passing the table through. The 
> table is only supported on newer hardware platforms and all GuC does 
> is provide a mechanism for the KMD to retrieve it because the KMD 
> cannot access it directly. The table contents are defined by hardware 
> architects same as all the other aspects of the hardware.
>
>>
>> It seems like these details should be dropped from the i915 patch commit
>> message since i915 wants nothing to do with it.
> Sure. Can remove comments.
>
>>
>> I would think it'd be preferable for i915 to stand behind the basic blob
>> format as is (even if the keys/values can't be defined), and make a new
>> query item if the closed source software changes the format.
> Close source software is not allowed to change the format because 
> closed source software has no say in defining the format. The format 
> is officially defined as being fixed in the spec. New key values can 
> be added to the key enumeration but existing values cannot be 
> deprecated and re-purposed. The table must be stable across all OSs 
> and all platforms. No software can arbitrarily decide to change it.
>
>>
>> Of course, it'd be even better if i915 could define some keys/values as
>> well. (Or if a spec could be released to help document / tie down the
>> format.)
> See the corresponding IGT test that details all the currently defined 
> keys.
>
>
>>
>>>> struct drm_i915_hwconfig {
>>>>     uint32_t key;
>>>>     uint32_t length;
>>>>     uint32_t values[];
>>>> };
>>>>
>>>> It sounds like the kernel depends on the closed source guc being 
>>>> loaded
>>>> to return this information. Is that right? Will i915 also become
>>>> dependent on some of this data such that it won't be able to 
>>>> initialize
>>>> without the firmware being loaded?
>>> At the moment, the KMD does not use the table at all. We merely provide
>>> a mechanism for the UMDs to retrieve it from the hardware.
>>>
>>> In terms of future direction, that is something you need to take up 
>>> with
>>> the hardware architects.
>>>
>> Why do you keep saying hardware, when only software is involved?
> See above - because the table is defined by hardware. No software, 
> closed or open, has any say in the specification of the table.


The values in the table might be defined by hardware, but the table 
itself definitely isn't.

Like Jordan tried to explain, because this is a software interface, it 
changes more often than HW.

Now testing doesn't just involve the number of different HW, it's the 
number of different HW times the number of different GuC firmwares.


As a UMD using this table, what guarantees do I get regarding the values 
I can find in the table?

Looking at the IGT test, it seems an empty table is a perfectly valid 
blob to get from GuC.

For instance, can I get a INTEL_HWCONFIG_TOTAL_VS_THREADS value and all 
the other threads count being missing from the table?

If any of the values I need to use is not there, what should I do? Just 
assert and refuse to run? Carry some default values to try keep going?

At least with the device info file we have now in UMD, we can fix any 
issue related to the in UMD without having to update the KMD/GuC.

This table looks like it effectively ties the UMDs to a particular GuC 
version.


There are also products for which the HW spec just doesn't provide 
values that are workable :

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3173

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8550

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8731


-Lionel


>
> John.
>
>
>>
>>>>> The attribute ids are defined in a hardware spec.
>>>> Which spec?
>>> Unfortunately, it is not one that is currently public. We are pushing
>>> the relevant people to get it included in the public bspec / HRM. It is
>>> a slow process :(.
>>>
>> Right. I take it no progress has been made in the 1.5 months since you
>> posted this, so it'll probably finally be documented 6~12 months after
>> hardware is available? :)
>>
>> -Jordan
>