diff options
| author |   Matt Roper <matthew.d.roper@intel.com> | 2021-07-13 12:36:26 -0700 |
|---|---|---|
| committer | Matt Roper <matthew.d.roper@intel.com> | 2021-07-14 17:35:59 -0700 |
| commit | 0f93f5da1cdc40d78fa2df8a62168e2362a0b34e (patch) | |
| tree | 1663eda3655fb2e7ef30f0561dbaa112b1f3d64b /drivers/gpu/drm/i915/intel_step.c | |
| parent | drm/i915: Make pre-production detection use direct revid comparison (diff) | |
| download | linux-dev-0f93f5da1cdc40d78fa2df8a62168e2362a0b34e.tar.xz linux-dev-0f93f5da1cdc40d78fa2df8a62168e2362a0b34e.zip | |
drm/i915/skl: Use revid->stepping tables
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-4-matthew.d.roper@intel.com
Diffstat (limited to 'drivers/gpu/drm/i915/intel_step.c')
| -rw-r--r-- | drivers/gpu/drm/i915/intel_step.c | 30 |
1 files changed, 25 insertions, 5 deletions
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. */ |