[Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL

[Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL

[Ashutosh Dixit]

Since https://patchwork.freedesktop.org/series/107908/ is now merged,
rebase this series on latest drm-tip and post a clean series.

Ashutosh Dixit (2):
  drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL
  drm/i915/rps: Freq caps for MTL

Tilak Tangudu (1):
  drm/i915/debugfs: Add perf_limit_reasons in debugfs

 drivers/gpu/drm/i915/gt/intel_gt.c            |  6 +++
 drivers/gpu/drm/i915/gt/intel_gt.h            |  1 +
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   |  6 +--
 drivers/gpu/drm/i915/gt/intel_rps.c           | 46 +++++++++++++++----
 drivers/gpu/drm/i915/i915_reg.h               | 11 +++++
 6 files changed, 89 insertions(+), 12 deletions(-)

-- 
2.34.1

[Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Ashutosh Dixit]

From: Tilak Tangudu <tilak.tangudu@intel.com>

Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
bits are identical to the lower 16 RO "status" bits except that the "log"
bits remain set until cleared, thereby ensuring the throttling occurrence
is not missed. The clear fop clears the upper 16 "log" bits, the get fop
gets all 32 "log" and "status" bits.

v2: Expand commit message and clarify "log" and "status" bits in
    comment (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
 drivers/gpu/drm/i915/i915_reg.h               |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 108b9e76c32e..a009cf69103a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -655,6 +655,36 @@ static bool rps_eval(void *data)
 
 DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
 
+static int perf_limit_reasons_get(void *data, u64 *val)
+{
+	struct intel_gt *gt = data;
+	intel_wakeref_t wakeref;
+
+	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
+
+	return 0;
+}
+
+static int perf_limit_reasons_clear(void *data, u64 val)
+{
+	struct intel_gt *gt = data;
+	intel_wakeref_t wakeref;
+
+	/*
+	 * Clear the upper 16 "log" bits, the lower 16 "status" bits are
+	 * read-only. The upper 16 "log" bits are identical to the lower 16
+	 * "status" bits except that the "log" bits remain set until cleared.
+	 */
+	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
+				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
+
+	return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
+			perf_limit_reasons_clear, "%llu\n");
+
 void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
 {
 	static const struct intel_gt_debugfs_file files[] = {
@@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
 		{ "forcewake_user", &forcewake_user_fops, NULL},
 		{ "llc", &llc_fops, llc_eval },
 		{ "rps_boost", &rps_boost_fops, rps_eval },
+		{ "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
 	};
 
 	intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 52462cbfdc66..58b0ed9dddd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1802,6 +1802,7 @@
 #define   POWER_LIMIT_4_MASK		REG_BIT(8)
 #define   POWER_LIMIT_1_MASK		REG_BIT(10)
 #define   POWER_LIMIT_2_MASK		REG_BIT(11)
+#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
 
 #define CHV_CLK_CTL1			_MMIO(0x101100)
 #define VLV_CLK_CTL2			_MMIO(0x101104)
-- 
2.34.1

[Intel-gfx] [PATCH 2/3] drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL

[Ashutosh Dixit]

PERF_LIMIT_REASONS register for MTL media gt is different now.

v2: Avoid static inline for intel_gt_perf_limit_reasons_reg() (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_gt.c            | 6 ++++++
 drivers/gpu/drm/i915/gt/intel_gt.h            | 1 +
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 ++--
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 6 +++---
 drivers/gpu/drm/i915/i915_reg.h               | 1 +
 5 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c
index b59fb03ed274..46929afa18c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -229,6 +229,12 @@ static void gen6_clear_engine_error_register(struct intel_engine_cs *engine)
 	GEN6_RING_FAULT_REG_POSTING_READ(engine);
 }
 
+i915_reg_t intel_gt_perf_limit_reasons_reg(struct intel_gt *gt)
+{
+	return gt->type == GT_MEDIA ?
+		MTL_MEDIA_PERF_LIMIT_REASONS : GT0_PERF_LIMIT_REASONS;
+}
+
 void
 intel_gt_clear_error_registers(struct intel_gt *gt,
 			       intel_engine_mask_t engine_mask)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h b/drivers/gpu/drm/i915/gt/intel_gt.h
index 2ee582e287c8..e0365d556248 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -60,6 +60,7 @@ void intel_gt_driver_late_release_all(struct drm_i915_private *i915);
 int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
 
 void intel_gt_check_and_clear_faults(struct intel_gt *gt);
+i915_reg_t intel_gt_perf_limit_reasons_reg(struct intel_gt *gt);
 void intel_gt_clear_error_registers(struct intel_gt *gt,
 				    intel_engine_mask_t engine_mask);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index a009cf69103a..68310881a793 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -661,7 +661,7 @@ static int perf_limit_reasons_get(void *data, u64 *val)
 	intel_wakeref_t wakeref;
 
 	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
+		*val = intel_uncore_read(gt->uncore, intel_gt_perf_limit_reasons_reg(gt));
 
 	return 0;
 }
@@ -677,7 +677,7 @@ static int perf_limit_reasons_clear(void *data, u64 val)
 	 * "status" bits except that the "log" bits remain set until cleared.
 	 */
 	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
+		intel_uncore_rmw(gt->uncore, intel_gt_perf_limit_reasons_reg(gt),
 				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
 
 	return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index e066cc33d9f2..54deae45d81f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -510,7 +510,7 @@ struct intel_gt_bool_throttle_attr {
 	struct attribute attr;
 	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
 			char *buf);
-	i915_reg_t reg32;
+	i915_reg_t (*reg32)(struct intel_gt *gt);
 	u32 mask;
 };
 
@@ -521,7 +521,7 @@ static ssize_t throttle_reason_bool_show(struct device *dev,
 	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
 	struct intel_gt_bool_throttle_attr *t_attr =
 				(struct intel_gt_bool_throttle_attr *) attr;
-	bool val = rps_read_mask_mmio(&gt->rps, t_attr->reg32, t_attr->mask);
+	bool val = rps_read_mask_mmio(&gt->rps, t_attr->reg32(gt), t_attr->mask);
 
 	return sysfs_emit(buff, "%u\n", val);
 }
@@ -530,7 +530,7 @@ static ssize_t throttle_reason_bool_show(struct device *dev,
 struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
 	.attr = { .name = __stringify(sysfs_func__), .mode = 0444 }, \
 	.show = throttle_reason_bool_show, \
-	.reg32 = GT0_PERF_LIMIT_REASONS, \
+	.reg32 = intel_gt_perf_limit_reasons_reg, \
 	.mask = mask__, \
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 58b0ed9dddd5..38e895ad4b59 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1803,6 +1803,7 @@
 #define   POWER_LIMIT_1_MASK		REG_BIT(10)
 #define   POWER_LIMIT_2_MASK		REG_BIT(11)
 #define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
+#define MTL_MEDIA_PERF_LIMIT_REASONS	_MMIO(0x138030)
 
 #define CHV_CLK_CTL1			_MMIO(0x101100)
 #define VLV_CLK_CTL2			_MMIO(0x101104)
-- 
2.34.1

[Intel-gfx] [PATCH 3/3] drm/i915/rps: Freq caps for MTL

[Ashutosh Dixit]

For MTL, when reading from HW, RP0, RP1 (actuall RPe) and RPn freq use an
entirely different set of registers with different fields, bitwidths and
units.

v2: Move MTL check into a separate function (Jani)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++++++++++++++++++++++------
 drivers/gpu/drm/i915/i915_reg.h     |  9 ++++++
 2 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6b86250c31ab..17b40b625e31 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1085,15 +1085,25 @@ static u32 intel_rps_read_state_cap(struct intel_rps *rps)
 		return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
 }
 
-/**
- * gen6_rps_get_freq_caps - Get freq caps exposed by HW
- * @rps: the intel_rps structure
- * @caps: returned freq caps
- *
- * Returned "caps" frequencies should be converted to MHz using
- * intel_gpu_freq()
- */
-void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *caps)
+static void
+mtl_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *caps)
+{
+	struct intel_uncore *uncore = rps_to_uncore(rps);
+	u32 rp_state_cap = rps_to_gt(rps)->type == GT_MEDIA ?
+				intel_uncore_read(uncore, MTL_MEDIAP_STATE_CAP) :
+				intel_uncore_read(uncore, MTL_RP_STATE_CAP);
+	u32 rpe = rps_to_gt(rps)->type == GT_MEDIA ?
+			intel_uncore_read(uncore, MTL_MPE_FREQUENCY) :
+			intel_uncore_read(uncore, MTL_GT_RPE_FREQUENCY);
+
+	/* MTL values are in units of 16.67 MHz */
+	caps->rp0_freq = REG_FIELD_GET(MTL_RP0_CAP_MASK, rp_state_cap);
+	caps->min_freq = REG_FIELD_GET(MTL_RPN_CAP_MASK, rp_state_cap);
+	caps->rp1_freq = REG_FIELD_GET(MTL_RPE_MASK, rpe);
+}
+
+static void
+__gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *caps)
 {
 	struct drm_i915_private *i915 = rps_to_i915(rps);
 	u32 rp_state_cap;
@@ -1128,6 +1138,24 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *c
 	}
 }
 
+/**
+ * gen6_rps_get_freq_caps - Get freq caps exposed by HW
+ * @rps: the intel_rps structure
+ * @caps: returned freq caps
+ *
+ * Returned "caps" frequencies should be converted to MHz using
+ * intel_gpu_freq()
+ */
+void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *caps)
+{
+	struct drm_i915_private *i915 = rps_to_i915(rps);
+
+	if (IS_METEORLAKE(i915))
+		return mtl_get_freq_caps(rps, caps);
+	else
+		return __gen6_rps_get_freq_caps(rps, caps);
+}
+
 static void gen6_rps_init(struct intel_rps *rps)
 {
 	struct drm_i915_private *i915 = rps_to_i915(rps);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 38e895ad4b59..2101b6d6dae5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1792,6 +1792,15 @@
 #define XEHPSDV_RP_STATE_CAP	_MMIO(0x250014)
 #define PVC_RP_STATE_CAP	_MMIO(0x281014)
 
+#define MTL_RP_STATE_CAP	_MMIO(0x138000)
+#define MTL_MEDIAP_STATE_CAP	_MMIO(0x138020)
+#define   MTL_RP0_CAP_MASK	REG_GENMASK(8, 0)
+#define   MTL_RPN_CAP_MASK	REG_GENMASK(24, 16)
+
+#define MTL_GT_RPE_FREQUENCY	_MMIO(0x13800c)
+#define MTL_MPE_FREQUENCY	_MMIO(0x13802c)
+#define   MTL_RPE_MASK		REG_GENMASK(8, 0)
+
 #define GT0_PERF_LIMIT_REASONS		_MMIO(0x1381a8)
 #define   GT0_PERF_LIMIT_REASONS_MASK	0xde3
 #define   PROCHOT_MASK			REG_BIT(0)
-- 
2.34.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: freq caps and perf_limit_reasons changes for MTL (rev5)

[Patchwork]

== Series Details ==

Series: i915: freq caps and perf_limit_reasons changes for MTL (rev5)
URL   : https://patchwork.freedesktop.org/series/108091/
State : warning

== Summary ==

Error: dim checkpatch failed
d4fac19a8b7f drm/i915/debugfs: Add perf_limit_reasons in debugfs
-:34: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV)
#34: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c:664:
+		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
 		^

total: 0 errors, 0 warnings, 1 checks, 50 lines checked
3ade6583a69d drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL
-:53: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV)
#53: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c:664:
+		*val = intel_uncore_read(gt->uncore, intel_gt_perf_limit_reasons_reg(gt));
 		^

total: 0 errors, 0 warnings, 1 checks, 66 lines checked
5ea34d6dbf96 drm/i915/rps: Freq caps for MTL

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: freq caps and perf_limit_reasons changes for MTL (rev5)

[Patchwork]

== Series Details ==

Series: i915: freq caps and perf_limit_reasons changes for MTL (rev5)
URL   : https://patchwork.freedesktop.org/series/108091/
State : warning

== Summary ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: freq caps and perf_limit_reasons changes for MTL (rev5)

[Patchwork]

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

== Series Details ==

Series: i915: freq caps and perf_limit_reasons changes for MTL (rev5)
URL   : https://patchwork.freedesktop.org/series/108091/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12112 -> Patchwork_108091v5
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 37)
------------------------------

  Additional (2): fi-kbl-soraka fi-hsw-4770 
  Missing    (2): fi-bdw-samus fi-elk-e7500 

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s3@smem:
    - fi-rkl-11600:       NOTRUN -> [FAIL][1] ([fdo#103375])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-rkl-11600/igt@gem_exec_suspend@basic-s3@smem.html

  * igt@i915_pm_backlight@basic-brightness:
    - fi-hsw-4770:        NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#3012])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-hsw-4770/igt@i915_pm_backlight@basic-brightness.html

  * igt@i915_selftest@live@requests:
    - fi-pnv-d510:        [PASS][3] -> [DMESG-FAIL][4] ([i915#4528])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/fi-pnv-d510/igt@i915_selftest@live@requests.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-pnv-d510/igt@i915_selftest@live@requests.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
    - fi-hsw-4770:        NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-hsw-4770/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html

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

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

  * igt@kms_psr@sprite_plane_onoff:
    - fi-hsw-4770:        NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1072]) +3 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  * igt@runner@aborted:
    - fi-kbl-soraka:      NOTRUN -> [FAIL][9] ([i915#6219])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/fi-kbl-soraka/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@i915_pm_rpm@module-reload:
    - {bat-rpls-2}:       [DMESG-WARN][10] ([i915#5537]) -> [PASS][11]
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/bat-rpls-2/igt@i915_pm_rpm@module-reload.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/bat-rpls-2/igt@i915_pm_rpm@module-reload.html

  * igt@i915_selftest@live@gem_contexts:
    - {bat-dg2-8}:        [INCOMPLETE][12] ([i915#6523]) -> [PASS][13]
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html

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

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

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#5537]: https://gitlab.freedesktop.org/drm/intel/issues/5537
  [i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
  [i915#6219]: https://gitlab.freedesktop.org/drm/intel/issues/6219
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
  [i915#6523]: https://gitlab.freedesktop.org/drm/intel/issues/6523
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645


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

  * Linux: CI_DRM_12112 -> Patchwork_108091v5

  CI-20190529: 20190529
  CI_DRM_12112: ff8b32fbe64a79b380b1cca4232d30c0b29df069 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6650: f7aff600ab16d6405f0704b1743d2b7909715752 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108091v5: ff8b32fbe64a79b380b1cca4232d30c0b29df069 @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

12f81d5002bc drm/i915/rps: Freq caps for MTL
5c4fc500b63d drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL
0e4dfbc4bd2e drm/i915/debugfs: Add perf_limit_reasons in debugfs

== Logs ==

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

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

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: freq caps and perf_limit_reasons changes for MTL (rev5)

[Patchwork]

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

== Series Details ==

Series: i915: freq caps and perf_limit_reasons changes for MTL (rev5)
URL   : https://patchwork.freedesktop.org/series/108091/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12112_full -> Patchwork_108091v5_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_eio@in-flight-contexts-10ms:
    - shard-snb:          [PASS][1] -> [FAIL][2] ([i915#4409])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-snb6/igt@gem_eio@in-flight-contexts-10ms.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-snb5/igt@gem_eio@in-flight-contexts-10ms.html

  * igt@gem_exec_balancer@parallel-balancer:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([i915#4525])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb1/igt@gem_exec_balancer@parallel-balancer.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb6/igt@gem_exec_balancer@parallel-balancer.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
    - shard-apl:          [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-apl2/igt@gem_exec_fair@basic-none-solo@rcs0.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html

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

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk9/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
    - shard-apl:          [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +1 similar issue
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-apl4/igt@gem_exec_suspend@basic-s3@smem.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl8/igt@gem_exec_suspend@basic-s3@smem.html

  * igt@gem_lmem_swapping@heavy-random:
    - shard-apl:          NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@gem_lmem_swapping@heavy-random.html

  * igt@gem_userptr_blits@vma-merge:
    - shard-apl:          NOTRUN -> [FAIL][13] ([i915#3318])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@gem_userptr_blits@vma-merge.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-90:
    - shard-glk:          NOTRUN -> [SKIP][14] ([fdo#109271]) +29 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@kms_big_fb@x-tiled-64bpp-rotate-90.html

  * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
    - shard-apl:          NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl1/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
    - shard-glk:          NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +2 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - shard-apl:          NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-crc-single:
    - shard-glk:          NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@kms_chamelium@hdmi-crc-single.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
    - shard-glk:          [PASS][19] -> [FAIL][20] ([i915#2346])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
    - shard-iclb:         [PASS][21] -> [FAIL][22] ([i915#79])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb6/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb5/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-downscaling@pipe-a-valid-mode:
    - shard-iclb:         NOTRUN -> [SKIP][23] ([i915#2672]) +4 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-downscaling@pipe-a-valid-mode.html

  * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling@pipe-a-default-mode:
    - shard-iclb:         [PASS][24] -> [SKIP][25] ([i915#3555])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling@pipe-a-default-mode.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling@pipe-a-default-mode.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-snb:          [PASS][26] -> [DMESG-WARN][27] ([i915#5090])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-snb6/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-snb4/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-fullscreen:
    - shard-apl:          NOTRUN -> [SKIP][28] ([fdo#109271]) +54 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-fullscreen.html

  * igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1:
    - shard-iclb:         [PASS][29] -> [SKIP][30] ([i915#5235]) +2 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb3/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb2/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][31] -> [SKIP][32] ([fdo#109441])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb8/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_vblank@pipe-d-wait-idle:
    - shard-apl:          NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#533])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@kms_vblank@pipe-d-wait-idle.html

  * igt@sysfs_clients@sema-25:
    - shard-glk:          NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#2994])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@sysfs_clients@sema-25.html

  
#### Possible fixes ####

  * igt@gem_eio@in-flight-contexts-immediate:
    - shard-tglb:         [TIMEOUT][35] ([i915#3063]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-tglb3/igt@gem_eio@in-flight-contexts-immediate.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-tglb2/igt@gem_eio@in-flight-contexts-immediate.html

  * igt@gem_eio@kms:
    - shard-tglb:         [FAIL][37] ([i915#5784]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-tglb1/igt@gem_eio@kms.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-tglb6/igt@gem_eio@kms.html

  * igt@gem_exec_balancer@parallel-contexts:
    - shard-iclb:         [SKIP][39] ([i915#4525]) -> [PASS][40] +1 similar issue
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb3/igt@gem_exec_balancer@parallel-contexts.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb4/igt@gem_exec_balancer@parallel-contexts.html

  * igt@gem_exec_endless@dispatch@vcs1:
    - shard-tglb:         [INCOMPLETE][41] ([i915#3778]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-tglb7/igt@gem_exec_endless@dispatch@vcs1.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-tglb6/igt@gem_exec_endless@dispatch@vcs1.html

  * igt@gem_exec_fair@basic-flow@rcs0:
    - shard-tglb:         [FAIL][43] ([i915#2842]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-tglb3/igt@gem_exec_fair@basic-flow@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
    - shard-glk:          [FAIL][45] ([i915#2842]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-glk6/igt@gem_exec_fair@basic-none@vcs0.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk7/igt@gem_exec_fair@basic-none@vcs0.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-glk:          [DMESG-WARN][47] ([i915#5566] / [i915#716]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-glk7/igt@gen9_exec_parse@allowed-single.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-glk1/igt@gen9_exec_parse@allowed-single.html

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

  * igt@i915_pm_rps@engine-order:
    - shard-apl:          [FAIL][51] ([i915#6537]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-apl6/igt@i915_pm_rps@engine-order.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl3/igt@i915_pm_rps@engine-order.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
    - shard-apl:          [DMESG-WARN][53] ([i915#180]) -> [PASS][54] +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-apl8/igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-apl4/igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1.html

  * igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1:
    - shard-iclb:         [SKIP][55] ([i915#5235]) -> [PASS][56] +2 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb2/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb8/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][57] ([fdo#109441]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

  
#### Warnings ####

  * igt@gem_exec_balancer@parallel-ordering:
    - shard-iclb:         [FAIL][59] ([i915#6117]) -> [SKIP][60] ([i915#4525])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12112/shard-iclb4/igt@gem_exec_balancer@parallel-ordering.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108091v5/shard-iclb7/igt@gem_exec_balancer@parallel-ordering.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#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644
  [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
  [i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
  [i915#2410]: https://gitlab.freedesktop.org/drm/intel/issues/2410
  [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
  [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
  [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
  [i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3778]: https://gitlab.freedesktop.org/drm/intel/issues/3778
  [i915#3804]: https://gitlab.freedesktop.org/drm/intel/issues/3804
  [i915#3825]: https://gitlab.freedesktop.org/drm/intel/issues/3825
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
  [i915#4281]: https://gitlab.freedesktop.org/drm/intel/issues/4281
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4387]: https://gitlab.freedesktop.org/drm/intel/issues/4387
  [i915#4409]: https://gitlab.freedesktop.org/drm/intel/issues/4409
  [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
  [i915#5090]: https://gitlab.freedesktop.org/drm/intel/issues/5090
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
  [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
  [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
  [i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
  [i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
  [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
  [i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
  [i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
  [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
  [i915#6117]: https://gitlab.freedesktop.org/drm/intel/issues/6117
  [i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
  [i915#6433]: https://gitlab.freedesktop.org/drm/intel/issues/6433
  [i915#6537]: https://gitlab.freedesktop.org/drm/intel/issues/6537
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#6599]: https://gitlab.freedesktop.org/drm/intel/issues/6599
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79


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

  * Linux: CI_DRM_12112 -> Patchwork_108091v5

  CI-20190529: 20190529
  CI_DRM_12112: ff8b32fbe64a79b380b1cca4232d30c0b29df069 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6650: f7aff600ab16d6405f0704b1743d2b7909715752 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108091v5: ff8b32fbe64a79b380b1cca4232d30c0b29df069 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

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

Re: [Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL

[Rodrigo Vivi]

On Sat, Sep 10, 2022 at 07:38:41AM -0700, Ashutosh Dixit wrote:
> Since https://patchwork.freedesktop.org/series/107908/ is now merged,
> rebase this series on latest drm-tip and post a clean series.

pushed to drm-intel-gt-next

thansk for the patches

> 
> Ashutosh Dixit (2):
>   drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL
>   drm/i915/rps: Freq caps for MTL
> 
> Tilak Tangudu (1):
>   drm/i915/debugfs: Add perf_limit_reasons in debugfs
> 
>  drivers/gpu/drm/i915/gt/intel_gt.c            |  6 +++
>  drivers/gpu/drm/i915/gt/intel_gt.h            |  1 +
>  drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   |  6 +--
>  drivers/gpu/drm/i915/gt/intel_rps.c           | 46 +++++++++++++++----
>  drivers/gpu/drm/i915/i915_reg.h               | 11 +++++
>  6 files changed, 89 insertions(+), 12 deletions(-)
> 
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Tvrtko Ursulin]

On 10/09/2022 15:38, Ashutosh Dixit wrote:
> From: Tilak Tangudu <tilak.tangudu@intel.com>
> 
> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
> bits are identical to the lower 16 RO "status" bits except that the "log"
> bits remain set until cleared, thereby ensuring the throttling occurrence
> is not missed. The clear fop clears the upper 16 "log" bits, the get fop
> gets all 32 "log" and "status" bits.
> 
> v2: Expand commit message and clarify "log" and "status" bits in
>      comment (Rodrigo)
> 
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>   drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
>   drivers/gpu/drm/i915/i915_reg.h               |  1 +
>   2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 108b9e76c32e..a009cf69103a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
>   
>   DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>   
> +static int perf_limit_reasons_get(void *data, u64 *val)
> +{
> +	struct intel_gt *gt = data;
> +	intel_wakeref_t wakeref;
> +
> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> +		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);

I have a bunch of questions, given failure to apply this to 
drm-intel-next-fixes brought my attention to it.

Why is GT0_PERF_LIMIT_REASONS_MASK not applied here?

Why do we have sysfs expose some of this register, but not these high 
log bits? Which are more important to the user?

Who resets the low bits and when in normal operation? (I mean not via 
this debugfs clear.)

What is the use case for allowing clearing of the log bits from debugfs? 
Why do we want to carry that code? For IGT?

Regards,

Tvrtko

> +
> +	return 0;
> +}
> +
> +static int perf_limit_reasons_clear(void *data, u64 val)
> +{
> +	struct intel_gt *gt = data;
> +	intel_wakeref_t wakeref;
> +
> +	/*
> +	 * Clear the upper 16 "log" bits, the lower 16 "status" bits are
> +	 * read-only. The upper 16 "log" bits are identical to the lower 16
> +	 * "status" bits except that the "log" bits remain set until cleared.
> +	 */
> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> +		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> +				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> +
> +	return 0;
> +}
> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> +			perf_limit_reasons_clear, "%llu\n");
> +
>   void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
>   {
>   	static const struct intel_gt_debugfs_file files[] = {
> @@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
>   		{ "forcewake_user", &forcewake_user_fops, NULL},
>   		{ "llc", &llc_fops, llc_eval },
>   		{ "rps_boost", &rps_boost_fops, rps_eval },
> +		{ "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
>   	};
>   
>   	intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 52462cbfdc66..58b0ed9dddd5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1802,6 +1802,7 @@
>   #define   POWER_LIMIT_4_MASK		REG_BIT(8)
>   #define   POWER_LIMIT_1_MASK		REG_BIT(10)
>   #define   POWER_LIMIT_2_MASK		REG_BIT(11)
> +#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
>   
>   #define CHV_CLK_CTL1			_MMIO(0x101100)
>   #define VLV_CLK_CTL2			_MMIO(0x101104)

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Dixit, Ashutosh]

On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
>

Hi Tvrtko,

I am adding some people who may have more background/history into this.

> On 10/09/2022 15:38, Ashutosh Dixit wrote:
> > From: Tilak Tangudu <tilak.tangudu@intel.com>
> >
> > Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
> > bits are identical to the lower 16 RO "status" bits except that the "log"
> > bits remain set until cleared, thereby ensuring the throttling occurrence
> > is not missed. The clear fop clears the upper 16 "log" bits, the get fop
> > gets all 32 "log" and "status" bits.
> >
> > v2: Expand commit message and clarify "log" and "status" bits in
> >      comment (Rodrigo)
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
> >   drivers/gpu/drm/i915/i915_reg.h               |  1 +
> >   2 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > index 108b9e76c32e..a009cf69103a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
> >     DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
> >   +static int perf_limit_reasons_get(void *data, u64 *val)
> > +{
> > +	struct intel_gt *gt = data;
> > +	intel_wakeref_t wakeref;
> > +
> > +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> > +		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
>
> I have a bunch of questions, given failure to apply this to
> drm-intel-next-fixes brought my attention to it.
>
> Why is GT0_PERF_LIMIT_REASONS_MASK not applied here?

To expose all 32 "log" and "status" bits, since no log bits and only a few
status bits are available in sysfs.

> Who resets the low bits and when in normal operation? (I mean not via this
> debugfs clear.)

HW would reset the low status bits after the condition causing the
throttling goes away. That condition would persist in the the upper log
bits till cleared via debugfs.

> Why do we have sysfs expose some of this register, but not these high log
> bits? Which are more important to the user?

The low status bits should be sampled while the throttling condition is
"current" (still happening). The upper log bits can be looked at later to
see if a particular condition happened.

I would say as long user land can sample (say every 5 ms) the low status
bits while a workload is running they can get a complete picture of what
throttling happened when (the app could sample the actual_freq sysfs and
correlate those values with the perf_limit_reasons sysfs e.g.).

> What is the use case for allowing clearing of the log bits from debugfs?
> Why do we want to carry that code? For IGT?

I guess the reason for exposing/clearing the log bits is that they can be
useful in cases where userspace does not want to sample the status bits
continuously while a workload is running. They can just come afterwards and
say, ah, these are the reasons limiting freq while the workload was
running.

Also the log bits could be used in conjunction with the low status bits to
infer if any limiting event got missed during sampling the status bits.

I believe IGT's correlating the actual_freq with perf_limit_reasons are
planned. But yes, whether the upper log bits should also be exposed in
sysfs is a valid one and should be discussed.

Thanks.
--
Ashutosh

> > +
> > +	return 0;
> > +}
> > +
> > +static int perf_limit_reasons_clear(void *data, u64 val)
> > +{
> > +	struct intel_gt *gt = data;
> > +	intel_wakeref_t wakeref;
> > +
> > +	/*
> > +	 * Clear the upper 16 "log" bits, the lower 16 "status" bits are
> > +	 * read-only. The upper 16 "log" bits are identical to the lower 16
> > +	 * "status" bits except that the "log" bits remain set until cleared.
> > +	 */
> > +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> > +		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> > +				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> > +
> > +	return 0;
> > +}
> > +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> > +			perf_limit_reasons_clear, "%llu\n");
> > +
> >   void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> >   {
> >	static const struct intel_gt_debugfs_file files[] = {
> > @@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> >		{ "forcewake_user", &forcewake_user_fops, NULL},
> >		{ "llc", &llc_fops, llc_eval },
> >		{ "rps_boost", &rps_boost_fops, rps_eval },
> > +		{ "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
> >	};
> >		intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files),
> > gt);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 52462cbfdc66..58b0ed9dddd5 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1802,6 +1802,7 @@
> >   #define   POWER_LIMIT_4_MASK		REG_BIT(8)
> >   #define   POWER_LIMIT_1_MASK		REG_BIT(10)
> >   #define   POWER_LIMIT_2_MASK		REG_BIT(11)
> > +#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
> >     #define CHV_CLK_CTL1			_MMIO(0x101100)
> >   #define VLV_CLK_CTL2			_MMIO(0x101104)

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Tvrtko Ursulin]

On 03/10/2022 06:34, Dixit, Ashutosh wrote:
> On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
>>
> 
> Hi Tvrtko,
> 
> I am adding some people who may have more background/history into this.
> 
>> On 10/09/2022 15:38, Ashutosh Dixit wrote:
>>> From: Tilak Tangudu <tilak.tangudu@intel.com>
>>>
>>> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
>>> bits are identical to the lower 16 RO "status" bits except that the "log"
>>> bits remain set until cleared, thereby ensuring the throttling occurrence
>>> is not missed. The clear fop clears the upper 16 "log" bits, the get fop
>>> gets all 32 "log" and "status" bits.
>>>
>>> v2: Expand commit message and clarify "log" and "status" bits in
>>>       comment (Rodrigo)
>>>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>>> Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
>>>    drivers/gpu/drm/i915/i915_reg.h               |  1 +
>>>    2 files changed, 32 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>> index 108b9e76c32e..a009cf69103a 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>> @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
>>>      DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>>>    +static int perf_limit_reasons_get(void *data, u64 *val)
>>> +{
>>> +	struct intel_gt *gt = data;
>>> +	intel_wakeref_t wakeref;
>>> +
>>> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
>>> +		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
>>
>> I have a bunch of questions, given failure to apply this to
>> drm-intel-next-fixes brought my attention to it.
>>
>> Why is GT0_PERF_LIMIT_REASONS_MASK not applied here?
> 
> To expose all 32 "log" and "status" bits, since no log bits and only a few
> status bits are available in sysfs.
> 
>> Who resets the low bits and when in normal operation? (I mean not via this
>> debugfs clear.)
> 
> HW would reset the low status bits after the condition causing the
> throttling goes away. That condition would persist in the the upper log
> bits till cleared via debugfs.
> 
>> Why do we have sysfs expose some of this register, but not these high log
>> bits? Which are more important to the user?
> 
> The low status bits should be sampled while the throttling condition is
> "current" (still happening). The upper log bits can be looked at later to
> see if a particular condition happened.
> 
> I would say as long user land can sample (say every 5 ms) the low status
> bits while a workload is running they can get a complete picture of what
> throttling happened when (the app could sample the actual_freq sysfs and
> correlate those values with the perf_limit_reasons sysfs e.g.).
> 
>> What is the use case for allowing clearing of the log bits from debugfs?
>> Why do we want to carry that code? For IGT?
> 
> I guess the reason for exposing/clearing the log bits is that they can be
> useful in cases where userspace does not want to sample the status bits
> continuously while a workload is running. They can just come afterwards and
> say, ah, these are the reasons limiting freq while the workload was
> running.

But as you say hardware clears them, then it is questionable it would 
show anything at that point?

Do we have interrupts associated with throttling and associated log 
message or uevents?

> Also the log bits could be used in conjunction with the low status bits to
> infer if any limiting event got missed during sampling the status bits.
> 
> I believe IGT's correlating the actual_freq with perf_limit_reasons are
> planned. But yes, whether the upper log bits should also be exposed in
> sysfs is a valid one and should be discussed.

Thanks for the clarifications!

Yes, it sounds like some discussion is needed as to intended use cases 
for exposing and clearing the log.

TBH I am not sure how urgent it is - will there be further conflicts 
caused by divergence of 7738be973fc4e2ba22154fafd3a5d7b9666f9abf vs 
0d2d201095e9f141d6a9fb44320afce761f8b5c2. If there would be it would 
probably be good to close on this question within the current 
development cycle.

Regards,

Tvrtko

> 
> Thanks.
> --
> Ashutosh
> 
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int perf_limit_reasons_clear(void *data, u64 val)
>>> +{
>>> +	struct intel_gt *gt = data;
>>> +	intel_wakeref_t wakeref;
>>> +
>>> +	/*
>>> +	 * Clear the upper 16 "log" bits, the lower 16 "status" bits are
>>> +	 * read-only. The upper 16 "log" bits are identical to the lower 16
>>> +	 * "status" bits except that the "log" bits remain set until cleared.
>>> +	 */
>>> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
>>> +		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
>>> +				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
>>> +
>>> +	return 0;
>>> +}
>>> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
>>> +			perf_limit_reasons_clear, "%llu\n");
>>> +
>>>    void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
>>>    {
>>> 	static const struct intel_gt_debugfs_file files[] = {
>>> @@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
>>> 		{ "forcewake_user", &forcewake_user_fops, NULL},
>>> 		{ "llc", &llc_fops, llc_eval },
>>> 		{ "rps_boost", &rps_boost_fops, rps_eval },
>>> +		{ "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
>>> 	};
>>> 		intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files),
>>> gt);
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>>> index 52462cbfdc66..58b0ed9dddd5 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -1802,6 +1802,7 @@
>>>    #define   POWER_LIMIT_4_MASK		REG_BIT(8)
>>>    #define   POWER_LIMIT_1_MASK		REG_BIT(10)
>>>    #define   POWER_LIMIT_2_MASK		REG_BIT(11)
>>> +#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
>>>      #define CHV_CLK_CTL1			_MMIO(0x101100)
>>>    #define VLV_CLK_CTL2			_MMIO(0x101104)

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Dixit, Ashutosh]

On Mon, 03 Oct 2022 01:11:21 -0700, Tvrtko Ursulin wrote:
> On 03/10/2022 06:34, Dixit, Ashutosh wrote:
> > On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
> >
> > Hi Tvrtko,
> >
> > I am adding some people who may have more background/history into this.
> >
> >> On 10/09/2022 15:38, Ashutosh Dixit wrote:
> >>> From: Tilak Tangudu <tilak.tangudu@intel.com>
> >>>
> >>> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
> >>> bits are identical to the lower 16 RO "status" bits except that the "log"
> >>> bits remain set until cleared, thereby ensuring the throttling occurrence
> >>> is not missed. The clear fop clears the upper 16 "log" bits, the get fop
> >>> gets all 32 "log" and "status" bits.
> >>>
> >>> v2: Expand commit message and clarify "log" and "status" bits in
> >>>       comment (Rodrigo)
> >>>
> >>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >>> Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
> >>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>> ---
> >>>    drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
> >>>    drivers/gpu/drm/i915/i915_reg.h               |  1 +
> >>>    2 files changed, 32 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> >>> index 108b9e76c32e..a009cf69103a 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> >>> @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
> >>>      DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
> >>>    +static int perf_limit_reasons_get(void *data, u64 *val)
> >>> +{
> >>> +	struct intel_gt *gt = data;
> >>> +	intel_wakeref_t wakeref;
> >>> +
> >>> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> >>> +		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
> >>
> >> I have a bunch of questions, given failure to apply this to
> >> drm-intel-next-fixes brought my attention to it.
> >>
> >> Why is GT0_PERF_LIMIT_REASONS_MASK not applied here?
> >
> > To expose all 32 "log" and "status" bits, since no log bits and only a few
> > status bits are available in sysfs.
> >
> >> Who resets the low bits and when in normal operation? (I mean not via this
> >> debugfs clear.)
> >
> > HW would reset the low status bits after the condition causing the
> > throttling goes away. That condition would persist in the the upper log
> > bits till cleared via debugfs.
> >
> >> Why do we have sysfs expose some of this register, but not these high log
> >> bits? Which are more important to the user?
> >
> > The low status bits should be sampled while the throttling condition is
> > "current" (still happening). The upper log bits can be looked at later to
> > see if a particular condition happened.
> >
> > I would say as long user land can sample (say every 5 ms) the low status
> > bits while a workload is running they can get a complete picture of what
> > throttling happened when (the app could sample the actual_freq sysfs and
> > correlate those values with the perf_limit_reasons sysfs e.g.).
> >
> >> What is the use case for allowing clearing of the log bits from debugfs?
> >> Why do we want to carry that code? For IGT?
> >
> > I guess the reason for exposing/clearing the log bits is that they can be
> > useful in cases where userspace does not want to sample the status bits
> > continuously while a workload is running. They can just come afterwards and
> > say, ah, these are the reasons limiting freq while the workload was
> > running.
>
> But as you say hardware clears them, then it is questionable it would show
> anything at that point?

The status bits would be cleared by HW but any events which have occured
would be coalesced and persist in the log bits.

> Do we have interrupts associated with throttling and associated log message
> or uevents?

I believe there are punit interrupts and some work-items to hook these say
into HWMON "alarms" but pretty sure none of this is implemented because
no clear customer requirements at this point.

> > Also the log bits could be used in conjunction with the low status bits to
> > infer if any limiting event got missed during sampling the status bits.
> >
> > I believe IGT's correlating the actual_freq with perf_limit_reasons are
> > planned. But yes, whether the upper log bits should also be exposed in
> > sysfs is a valid one and should be discussed.
>
> Thanks for the clarifications!
>
> Yes, it sounds like some discussion is needed as to intended use cases for
> exposing and clearing the log.
>
> TBH I am not sure how urgent it is - will there be further conflicts caused
> by divergence of 7738be973fc4e2ba22154fafd3a5d7b9666f9abf vs
> 0d2d201095e9f141d6a9fb44320afce761f8b5c2. If there would be it would
> probably be good to close on this question within the current development
> cycle.

I believe this is already resolved by the merge of drm-intel-fixes into
drm-tip.

Thanks.
--
Ashutosh


> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int perf_limit_reasons_clear(void *data, u64 val)
> >>> +{
> >>> +	struct intel_gt *gt = data;
> >>> +	intel_wakeref_t wakeref;
> >>> +
> >>> +	/*
> >>> +	 * Clear the upper 16 "log" bits, the lower 16 "status" bits are
> >>> +	 * read-only. The upper 16 "log" bits are identical to the lower 16
> >>> +	 * "status" bits except that the "log" bits remain set until cleared.
> >>> +	 */
> >>> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> >>> +		intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> >>> +				 GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> >>> +			perf_limit_reasons_clear, "%llu\n");
> >>> +
> >>>    void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> >>>    {
> >>>	static const struct intel_gt_debugfs_file files[] = {
> >>> @@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> >>>		{ "forcewake_user", &forcewake_user_fops, NULL},
> >>>		{ "llc", &llc_fops, llc_eval },
> >>>		{ "rps_boost", &rps_boost_fops, rps_eval },
> >>> +		{ "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
> >>>	};
> >>>		intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files),
> >>> gt);
> >>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> >>> index 52462cbfdc66..58b0ed9dddd5 100644
> >>> --- a/drivers/gpu/drm/i915/i915_reg.h
> >>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >>> @@ -1802,6 +1802,7 @@
> >>>    #define   POWER_LIMIT_4_MASK		REG_BIT(8)
> >>>    #define   POWER_LIMIT_1_MASK		REG_BIT(10)
> >>>    #define   POWER_LIMIT_2_MASK		REG_BIT(11)
> >>> +#define   GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
> >>>      #define CHV_CLK_CTL1			_MMIO(0x101100)
> >>>    #define VLV_CLK_CTL2			_MMIO(0x101104)

Re: [Intel-gfx] [PATCH 1/3] drm/i915/debugfs: Add perf_limit_reasons in debugfs

[Tvrtko Ursulin]

On 03/10/2022 17:16, Dixit, Ashutosh wrote:
> On Mon, 03 Oct 2022 01:11:21 -0700, Tvrtko Ursulin wrote:
>> On 03/10/2022 06:34, Dixit, Ashutosh wrote:
>>> On Tue, 27 Sep 2022 07:17:23 -0700, Tvrtko Ursulin wrote:
>>>
>>> Hi Tvrtko,
>>>
>>> I am adding some people who may have more background/history into this.
>>>
>>>> On 10/09/2022 15:38, Ashutosh Dixit wrote:
>>>>> From: Tilak Tangudu <tilak.tangudu@intel.com>
>>>>>
>>>>> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
>>>>> bits are identical to the lower 16 RO "status" bits except that the "log"
>>>>> bits remain set until cleared, thereby ensuring the throttling occurrence
>>>>> is not missed. The clear fop clears the upper 16 "log" bits, the get fop
>>>>> gets all 32 "log" and "status" bits.
>>>>>
>>>>> v2: Expand commit message and clarify "log" and "status" bits in
>>>>>        comment (Rodrigo)
>>>>>
>>>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>>>>> Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
>>>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>> ---
>>>>>     drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++++++++++++++++++
>>>>>     drivers/gpu/drm/i915/i915_reg.h               |  1 +
>>>>>     2 files changed, 32 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>>>> index 108b9e76c32e..a009cf69103a 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>>>>> @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
>>>>>       DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>>>>>     +static int perf_limit_reasons_get(void *data, u64 *val)
>>>>> +{
>>>>> +	struct intel_gt *gt = data;
>>>>> +	intel_wakeref_t wakeref;
>>>>> +
>>>>> +	with_intel_runtime_pm(gt->uncore->rpm, wakeref)
>>>>> +		*val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
>>>>
>>>> I have a bunch of questions, given failure to apply this to
>>>> drm-intel-next-fixes brought my attention to it.
>>>>
>>>> Why is GT0_PERF_LIMIT_REASONS_MASK not applied here?
>>>
>>> To expose all 32 "log" and "status" bits, since no log bits and only a few
>>> status bits are available in sysfs.
>>>
>>>> Who resets the low bits and when in normal operation? (I mean not via this
>>>> debugfs clear.)
>>>
>>> HW would reset the low status bits after the condition causing the
>>> throttling goes away. That condition would persist in the the upper log
>>> bits till cleared via debugfs.
>>>
>>>> Why do we have sysfs expose some of this register, but not these high log
>>>> bits? Which are more important to the user?
>>>
>>> The low status bits should be sampled while the throttling condition is
>>> "current" (still happening). The upper log bits can be looked at later to
>>> see if a particular condition happened.
>>>
>>> I would say as long user land can sample (say every 5 ms) the low status
>>> bits while a workload is running they can get a complete picture of what
>>> throttling happened when (the app could sample the actual_freq sysfs and
>>> correlate those values with the perf_limit_reasons sysfs e.g.).
>>>
>>>> What is the use case for allowing clearing of the log bits from debugfs?
>>>> Why do we want to carry that code? For IGT?
>>>
>>> I guess the reason for exposing/clearing the log bits is that they can be
>>> useful in cases where userspace does not want to sample the status bits
>>> continuously while a workload is running. They can just come afterwards and
>>> say, ah, these are the reasons limiting freq while the workload was
>>> running.
>>
>> But as you say hardware clears them, then it is questionable it would show
>> anything at that point?
> 
> The status bits would be cleared by HW but any events which have occured
> would be coalesced and persist in the log bits.

I think this started with my typo. :( I've asked "who resets the low 
bits in normal operation" while I meant "who resets the log bits". So 
answer is no one, that is okay.

> 
>> Do we have interrupts associated with throttling and associated log message
>> or uevents?
> 
> I believe there are punit interrupts and some work-items to hook these say
> into HWMON "alarms" but pretty sure none of this is implemented because
> no clear customer requirements at this point.

If there is a real use case for this I think that would be much better 
than mention of 5ms polling on the sysfs file. By much better I really 
mean polling shouldn't really even be considered.

>>> Also the log bits could be used in conjunction with the low status bits to
>>> infer if any limiting event got missed during sampling the status bits.
>>>
>>> I believe IGT's correlating the actual_freq with perf_limit_reasons are
>>> planned. But yes, whether the upper log bits should also be exposed in
>>> sysfs is a valid one and should be discussed.
>>
>> Thanks for the clarifications!
>>
>> Yes, it sounds like some discussion is needed as to intended use cases for
>> exposing and clearing the log.
>>
>> TBH I am not sure how urgent it is - will there be further conflicts caused
>> by divergence of 7738be973fc4e2ba22154fafd3a5d7b9666f9abf vs
>> 0d2d201095e9f141d6a9fb44320afce761f8b5c2. If there would be it would
>> probably be good to close on this question within the current development
>> cycle.
> 
> I believe this is already resolved by the merge of drm-intel-fixes into
> drm-tip.

Yeah I wasn't sure if it won't come back in the next merge window. We 
will see.

In the meantime it would be good to close on the need (or not) for the 
extra debugfs functionality versus putting it in sysfs versus 
implementing a non-polling based solution.

Regards,

Tvrtko