Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: matthew.d.roper@intel.com, Lucas De Marchi <lucas.demarchi@intel.com>
Subject: [PATCH v2 2/3] drm/xe: Don't try to derive GT clock freq from display register on Xe2
Date: Fri, 13 Sep 2024 09:29:12 -0700	[thread overview]
Message-ID: <20240913162910.4145142-5-matthew.d.roper@intel.com> (raw)
In-Reply-To: <20240913162910.4145142-4-matthew.d.roper@intel.com>

Driver initialization has two approaches for calculating the GT clock --
it either derives it from the crystal clock frequency as read from a GT
register, or it derives it from the display's TIMESTAMP_OVERRIDE
register.  The driver is informed of which approach needs to be used by
a bit setting in the CTC_MODE register.

Use of a display register to initialize the GT frequency seems a bit
suspicious and doesn't seem to really be documented clearly in the
bspec.  However there is a note on the CTC_MODE register indicating that
the setting that corresponds to use of the display register (which the
bspec simply describes as "Broadwell Divide logic") is no longer
supported on Xe2 and beyond.  Furthermore, the TIMESTAMP_OVERRIDE
register itself was removed in display version 20.  Rework the GT clock
init function to only consider CTC_MODE (and then possibly use display's
TIMESTAMP_OVERRIDE) on pre-Xe2 platforms.

Bspec: 62395
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 drivers/gpu/drm/xe/xe_gt_clock.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_gt_clock.c b/drivers/gpu/drm/xe/xe_gt_clock.c
index 886c071c10f5..93940dc2c146 100644
--- a/drivers/gpu/drm/xe/xe_gt_clock.c
+++ b/drivers/gpu/drm/xe/xe_gt_clock.c
@@ -43,29 +43,29 @@ static u32 get_crystal_clock_freq(u32 rpm_config_reg)
 int xe_gt_clock_init(struct xe_gt *gt)
 {
 	struct xe_device *xe = gt_to_xe(gt);
-	u32 ctc_reg = xe_mmio_read32(&gt->mmio, CTC_MODE);
-	u32 freq = 0;
+	u32 c0, freq = 0;
 
 	/* Assuming gen11+ so assert this assumption is correct */
 	xe_gt_assert(gt, GRAPHICS_VER(xe) >= 11);
 
-	if (ctc_reg & CTC_SOURCE_DIVIDE_LOGIC) {
+	if (GRAPHICS_VER(gt_to_xe(gt)) < 20 &&
+	    xe_mmio_read32(&gt->mmio, CTC_MODE) & CTC_SOURCE_DIVIDE_LOGIC) {
 		xe_gt_assert(gt, xe->info.probe_display);
+		gt->info.reference_clock = xe_display_read_ref_ts_freq(xe);
 
-		freq = xe_display_read_ref_ts_freq(xe);
-	} else {
-		u32 c0 = xe_mmio_read32(&gt->mmio, RPM_CONFIG0);
-
-		freq = get_crystal_clock_freq(c0);
-
-		/*
-		 * Now figure out how the command stream's timestamp
-		 * register increments from this frequency (it might
-		 * increment only every few clock cycle).
-		 */
-		freq >>= 3 - REG_FIELD_GET(RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK, c0);
+		return 0;
 	}
 
+	c0 = xe_mmio_read32(&gt->mmio, RPM_CONFIG0);
+	freq = get_crystal_clock_freq(c0);
+
+	/*
+	 * Now figure out how the command stream's timestamp
+	 * register increments from this frequency (it might
+	 * increment only every few clock cycle).
+	 */
+	freq >>= 3 - REG_FIELD_GET(RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK, c0);
+
 	gt->info.reference_clock = freq;
 	return 0;
 }
-- 
2.45.2


  reply	other threads:[~2024-09-13 16:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 16:29 [PATCH v2 1/3] drm/xe: Move display reference timestamp readout to display/ Matt Roper
2024-09-13 16:29 ` Matt Roper [this message]
2024-09-18 21:27   ` [PATCH v2 2/3] drm/xe: Don't try to derive GT clock freq from display register on Xe2 Lucas De Marchi
2024-09-13 16:29 ` [PATCH v2 3/3] drm/xe/sriov: Drop TIMESTAMP_OVERRIDE from Xe2 runtime regs Matt Roper
2024-09-18 21:27   ` Lucas De Marchi
2024-09-13 19:03 ` ✓ CI.Patch_applied: success for series starting with [v2,1/3] drm/xe: Move display reference timestamp readout to display/ Patchwork
2024-09-13 19:04 ` ✓ CI.checkpatch: " Patchwork
2024-09-13 19:05 ` ✓ CI.KUnit: " Patchwork
2024-09-13 19:16 ` ✓ CI.Build: " Patchwork
2024-09-13 19:19 ` ✓ CI.Hooks: " Patchwork
2024-09-13 19:20 ` ✓ CI.checksparse: " Patchwork
2024-09-13 19:38 ` ✓ CI.BAT: " Patchwork
2024-09-14 15:47 ` ✗ CI.FULL: failure " Patchwork
2024-09-16 18:09 ` [PATCH v2 1/3] " Rodrigo Vivi
2024-09-16 20:39   ` Matt Roper
2024-09-18 21:28     ` Lucas De Marchi
2024-09-17  7:55 ` Jani Nikula
2024-09-18 21:19   ` Lucas De Marchi
2024-09-19 10:00     ` Jani Nikula
2024-09-19 11:10       ` Ville Syrjälä
2024-09-30 23:26         ` Matt Roper
2025-01-27  9:23           ` Lionel Landwerlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240913162910.4145142-5-matthew.d.roper@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox