intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/i915: Warn on obsolete revision checks
Date: Mon, 11 Jun 2018 15:26:45 +0300	[thread overview]
Message-ID: <874li94igq.fsf@intel.com> (raw)
In-Reply-To: <20180608134205.6452-5-mika.kuoppala@linux.intel.com>

On Fri, 08 Jun 2018, Mika Kuoppala <mika.kuoppala@linux.intel.com> wrote:
> If we are doing revision checks against a preproduction
> range, when there is already a product, it is a sign
> that there is code to be removed.
>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_chipset.h | 30 +++++++++++++++++++++-------
>  1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_chipset.h b/drivers/gpu/drm/i915/intel_chipset.h
> index 946c889c0118..bc9ff02dc8df 100644
> --- a/drivers/gpu/drm/i915/intel_chipset.h
> +++ b/drivers/gpu/drm/i915/intel_chipset.h
> @@ -131,6 +131,12 @@
>  #define IS_PREPRODUCTION_HW(dev_priv)   (INTEL_REVID(dev_priv) < FIRST_PRODUCT_REVID(INTEL_INFO(dev_priv)))
>  #define IS_PLATFORM_SUPPORT_ALPHA(intel_info) (FIRST_PRODUCT_REVID(intel_info) == PRODUCT_REVID_UNKNOWN)
>  
> +#define BUILD_BUG_ON_REVID_LT(revid, production_revid) ({ \
> +		BUILD_BUG_ON((production_revid) != PRODUCT_REVID_UNKNOWN && \
> +			     (revid) < (production_revid)); \
> +		1; \
> +	})
> +
>  #define SKL_REVID_A0		0x0
>  #define SKL_REVID_B0		0x1
>  #define SKL_REVID_C0		0x2
> @@ -141,7 +147,9 @@
>  #define SKL_REVID_PRODUCT	SKL_REVID_G0
>  #define SKL_REVID_H0		0x7
>  
> -#define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since, until))
> +#define IS_SKL_REVID(p, since, until) \
> +	(BUILD_BUG_ON_REVID_LT(until, SKL_REVID_PRODUCT) && \
> +	 IS_SKYLAKE(p) && IS_REVID(p, since, until))
>  
>  #define BXT_REVID_A0		0x0
>  #define BXT_REVID_A1		0x1
> @@ -151,7 +159,8 @@
>  #define BXT_REVID_PRODUCT	BXT_REVID_C0
>  
>  #define IS_BXT_REVID(dev_priv, since, until) \
> -	(IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
> +	(BUILD_BUG_ON_REVID_LT(until, BXT_REVID_PRODUCT) && \
> +	 IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
>  
>  #define KBL_REVID_A0		0x0
>  #define KBL_REVID_B0		0x1
> @@ -161,29 +170,36 @@
>  #define KBL_REVID_E0		0x4
>  
>  #define IS_KBL_REVID(dev_priv, since, until) \
> -	(IS_KABYLAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> +	(BUILD_BUG_ON_REVID_LT(until, KBL_REVID_PRODUCT) && \
> +	 IS_KABYLAKE(dev_priv) && IS_REVID(dev_priv, since, until))
>  
>  #define GLK_REVID_A0		0x0
>  #define GLK_REVID_A1		0x1
> +#define GLK_REVID_PRODUCT	PRODUCT_REVID_UNKNOWN
>  
> -#define IS_GLK_REVID(dev_priv, since, until) \
> -	(IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> +#define IS_GLK_REVID(dev_priv, since, until)		    \
> +	(BUILD_BUG_ON_REVID_LT(until, GLK_REVID_PRODUCT) && \
> +	 IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
>  
>  #define CNL_REVID_A0		0x0
>  #define CNL_REVID_B0		0x1
>  #define CNL_REVID_C0		0x2
> +#define CNL_REVID_PRODUCT	PRODUCT_REVID_UNKNOWN
>  
>  #define IS_CNL_REVID(p, since, until) \
> -	(IS_CANNONLAKE(p) && IS_REVID(p, since, until))
> +	(BUILD_BUG_ON_REVID_LT(until, CNL_REVID_PRODUCT) && \
> +	 IS_CANNONLAKE(p) && IS_REVID(p, since, until))
>  
>  #define ICL_REVID_A0		0x0
>  #define ICL_REVID_A2		0x1
>  #define ICL_REVID_B0		0x3
>  #define ICL_REVID_B2		0x4
>  #define ICL_REVID_C0		0x5
> +#define ICL_REVID_PRODUCT	PRODUCT_REVID_UNKNOWN
>  
>  #define IS_ICL_REVID(p, since, until) \
> -	(IS_ICELAKE(p) && IS_REVID(p, since, until))
> +	(BUILD_BUG_ON_REVID_LT(until, ICL_REVID_PRODUCT) && \
> +	IS_ICELAKE(p) && IS_REVID(p, since, until))

The trouble with this is that it ties the macros *_REVID_PRODUCT to
having to get rid of all the pre-production revid checks. We'll
typically know the product revid *before* we can drop all the
checks. And we can't drop all the checks because there'll be plenty of
hardware to phase out and replace, and it doesn't happen overnight. But
we'd still like to start complaining about the pre-pro hardware use as
soon as possible.

BR,
Jani.

>  
>  /*
>   * The genX designation typically refers to the render engine, so render

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-06-11 12:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08 13:42 [PATCH 1/5] drm/i915: Move chipset definitions to intel_chipset.h Mika Kuoppala
2018-06-08 13:42 ` [PATCH 2/5] drm/i915: Store first production revid into device info Mika Kuoppala
2018-06-08 14:30   ` Chris Wilson
2018-06-08 13:42 ` [PATCH 3/5] drm/i915: Use unknown production revid as alpha quality flag Mika Kuoppala
2018-06-08 13:53   ` Chris Wilson
2018-06-11 11:23   ` Joonas Lahtinen
2018-06-11 12:22     ` Jani Nikula
2018-06-08 13:42 ` [PATCH 4/5] drm/i915: Remove kbl preproduction workarounds Mika Kuoppala
2018-06-08 13:52   ` Chris Wilson
2018-06-08 13:42 ` [PATCH 5/5] drm/i915: Warn on obsolete revision checks Mika Kuoppala
2018-06-08 13:51   ` Chris Wilson
2018-06-11 12:26   ` Jani Nikula [this message]
2018-06-08 13:56 ` [PATCH 1/5] drm/i915: Move chipset definitions to intel_chipset.h Chris Wilson
2018-06-08 14:06 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] " Patchwork
2018-06-08 14:08 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-06-08 14:26 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-08 15:04 ` [PATCH 1/5] " Michal Wajdeczko
2018-06-11  8:35   ` Tvrtko Ursulin
2018-06-08 17:56 ` ✓ Fi.CI.IGT: success for series starting with [1/5] " Patchwork

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=874li94igq.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.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;
as well as URLs for NNTP newsgroup(s).