All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [CI v4 03/12] drm/i915/skl: Use revid->stepping tables
Date: Tue, 13 Jul 2021 13:03:43 -0700	[thread overview]
Message-ID: <20210713200343.23a2mg245zee66cm@ldmartin-desk2> (raw)
In-Reply-To: <20210713193635.3390052-4-matthew.d.roper@intel.com>

On Tue, Jul 13, 2021 at 12:36:26PM -0700, Matt Roper wrote:
>Switch SKL to use a revid->stepping table as we're trying to do on all
>platforms going forward.  Also drop the preproduction revisions and add
>the newer steppings we hadn't already handled.
>
>Note that SKL has a case where a newer revision ID corresponds to an
>older GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1).  Also, the lack
>of a revision ID 0x8 in the table is intentional and not an oversight.
>We'll re-write the KBL-specific comment to make it clear that these kind
>of quirks are expected.
>
>v2:
> - Since GT and display steppings are always identical on SKL use a
>   macro to set both values at once in a more readable manner.  (Anusha)
> - Drop preproduction steppings.
>
>Bspec: 13626
>Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
>Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>


Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>

Lucas De Marchi

>---
> drivers/gpu/drm/i915/gt/intel_workarounds.c |  2 +-
> drivers/gpu/drm/i915/i915_drv.h             | 11 +-------
> drivers/gpu/drm/i915/intel_step.c           | 30 +++++++++++++++++----
> drivers/gpu/drm/i915/intel_step.h           |  4 +++
> 4 files changed, 31 insertions(+), 16 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>index 72562c233ad2..9f7cd2e54894 100644
>--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>@@ -890,7 +890,7 @@ skl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
> 		    GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
>
> 	/* WaInPlaceDecompressionHang:skl */
>-	if (IS_SKL_REVID(i915, SKL_REVID_H0, REVID_FOREVER))
>+	if (IS_SKL_GT_STEP(i915, STEP_H0, STEP_FOREVER))
> 		wa_write_or(wal,
> 			    GEN9_GAMT_ECO_REG_RW_IA,
> 			    GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index c4747f4407ef..f30499ed6787 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -1515,16 +1515,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_TGL_Y(dev_priv) \
> 	IS_SUBPLATFORM(dev_priv, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_ULX)
>
>-#define SKL_REVID_A0		0x0
>-#define SKL_REVID_B0		0x1
>-#define SKL_REVID_C0		0x2
>-#define SKL_REVID_D0		0x3
>-#define SKL_REVID_E0		0x4
>-#define SKL_REVID_F0		0x5
>-#define SKL_REVID_G0		0x6
>-#define SKL_REVID_H0		0x7
>-
>-#define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since, until))
>+#define IS_SKL_GT_STEP(p, since, until) (IS_SKYLAKE(p) && IS_GT_STEP(p, since, until))
>
> #define BXT_REVID_A0		0x0
> #define BXT_REVID_A1		0x1
>diff --git a/drivers/gpu/drm/i915/intel_step.c b/drivers/gpu/drm/i915/intel_step.c
>index 93ccd42f2514..4e6a2b3b4f8a 100644
>--- a/drivers/gpu/drm/i915/intel_step.c
>+++ b/drivers/gpu/drm/i915/intel_step.c
>@@ -7,14 +7,31 @@
> #include "intel_step.h"
>
> /*
>- * KBL revision ID ordering is bizarre; higher revision ID's map to lower
>- * steppings in some cases.  So rather than test against the revision ID
>- * directly, let's map that into our own range of increasing ID's that we
>- * can test against in a regular manner.
>+ * Some platforms have unusual ways of mapping PCI revision ID to GT/display
>+ * steppings.  E.g., in some cases a higher PCI revision may translate to a
>+ * lower stepping of the GT and/or display IP.  This file provides lookup
>+ * tables to map the PCI revision into a standard set of stepping values that
>+ * can be compared numerically.
>+ *
>+ * Also note that some revisions/steppings may have been set aside as
>+ * placeholders but never materialized in real hardware; in those cases there
>+ * may be jumps in the revision IDs or stepping values in the tables below.
>  */
>
>+/*
>+ * Some platforms always have the same stepping value for GT and display;
>+ * use a macro to define these to make it easier to identify the platforms
>+ * where the two steppings can deviate.
>+ */
>+#define COMMON_STEP(x)  .gt_step = STEP_##x, .display_step = STEP_##x
>+
>+static const struct intel_step_info skl_revids[] = {
>+	[0x6] = { COMMON_STEP(G0) },
>+	[0x7] = { COMMON_STEP(H0) },
>+	[0x9] = { COMMON_STEP(J0) },
>+	[0xA] = { COMMON_STEP(I1) },
>+};
>
>-/* FIXME: what about REVID_E0 */
> static const struct intel_step_info kbl_revids[] = {
> 	[0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> 	[1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
>@@ -76,6 +93,9 @@ void intel_step_init(struct drm_i915_private *i915)
> 	} else if (IS_KABYLAKE(i915)) {
> 		revids = kbl_revids;
> 		size = ARRAY_SIZE(kbl_revids);
>+	} else if (IS_SKYLAKE(i915)) {
>+		revids = skl_revids;
>+		size = ARRAY_SIZE(skl_revids);
> 	}
>
> 	/* Not using the stepping scheme for the platform yet. */
>diff --git a/drivers/gpu/drm/i915/intel_step.h b/drivers/gpu/drm/i915/intel_step.h
>index 958a8bb5d677..88a77159703e 100644
>--- a/drivers/gpu/drm/i915/intel_step.h
>+++ b/drivers/gpu/drm/i915/intel_step.h
>@@ -31,6 +31,10 @@ enum intel_step {
> 	STEP_E0,
> 	STEP_F0,
> 	STEP_G0,
>+	STEP_H0,
>+	STEP_I0,
>+	STEP_I1,
>+	STEP_J0,
> 	STEP_FUTURE,
> 	STEP_FOREVER,
> };
>-- 
>2.25.4
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-07-13 20:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 19:36 [Intel-gfx] [CI v4 00/12] Minor revid/stepping and workaround cleanup Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 01/12] drm/i915/step: s/<platform>_revid_tbl/<platform>_revids Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 02/12] drm/i915: Make pre-production detection use direct revid comparison Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 03/12] drm/i915/skl: Use revid->stepping tables Matt Roper
2021-07-13 20:03   ` Lucas De Marchi [this message]
2021-07-13 19:36 ` [Intel-gfx] [CI v4 04/12] drm/i915/kbl: Drop pre-production revision from stepping table Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 05/12] drm/i915/bxt: Use revid->stepping tables Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 06/12] drm/i915/glk: " Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 07/12] drm/i915/icl: " Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 08/12] drm/i915/jsl_ehl: " Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 09/12] drm/i915/rkl: " Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 10/12] drm/i915/dg1: " Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 11/12] drm/i915/cnl: Drop all workarounds Matt Roper
2021-07-13 19:36 ` [Intel-gfx] [CI v4 12/12] drm/i915/icl: Drop workarounds that only apply to pre-production steppings Matt Roper
2021-07-13 22:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Minor revid/stepping and workaround cleanup (rev5) Patchwork
2021-07-13 22:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-07-14  8:48 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-07-15  1:10   ` Matt Roper

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=20210713200343.23a2mg245zee66cm@ldmartin-desk2 \
    --to=lucas.demarchi@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.