All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jesse Barnes <jbarnes@virtuousgeek.org>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: clarify IS_GEN vs IS_<product> usage
Date: Thu, 05 May 2011 23:57:56 +0100	[thread overview]
Message-ID: <0d30dc$m4ic2q@orsmga001.jf.intel.com> (raw)
In-Reply-To: <1304633805-7505-1-git-send-email-jbarnes@virtuousgeek.org>

On Thu,  5 May 2011 15:16:45 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> We generally use the gen number to indicate the generation of the render
> portion of the chip.  In some cases this isn't the same as the display
> generation (as in the case of G33 and GMA500).  So codify the de facto
> usage by converting some IS_GEN checks into product specific checks for
> display related differences.  (Note this makes me wonder about our G33
> watermark handling; shouldn't it be like 965 not 945?  I don't have one
> to test with...).

As far as I've been able to tell, the current code works... So it can't
be too far wrong, and I don't recall any mention of deviations in the gen3
docs.

Whilst you are in the vicinity, does it make sense to rename info->gen to
info->render (or info->render_gen)?

> @@ -230,6 +231,7 @@ struct intel_device_info {
>  	u8 is_broadwater : 1;
>  	u8 is_crestline : 1;
>  	u8 is_ivybridge : 1;
> +	u8 is_sandybridge : 1;
>  	u8 has_fbc : 1;
>  	u8 has_pipe_cxsr : 1;
>  	u8 has_hotplug : 1;

What's the sort order here? ;-)

> @@ -915,10 +917,13 @@ enum intel_chip_family {
>  #define IS_845G(dev)		((dev)->pci_device == 0x2562)
>  #define IS_I85X(dev)		(INTEL_INFO(dev)->is_i85x)
>  #define IS_I865G(dev)		((dev)->pci_device == 0x2572)
> +#define IS_I8XX(dev)		(INTEL_INFO(dev)->is_i8xx)
>  #define IS_I915G(dev)		(INTEL_INFO(dev)->is_i915g)
>  #define IS_I915GM(dev)		((dev)->pci_device == 0x2592)
> +#define IS_I915(dev)		(IS_I915G(dev) || IS_I915GM(dev))
>  #define IS_I945G(dev)		((dev)->pci_device == 0x2772)
>  #define IS_I945GM(dev)		(INTEL_INFO(dev)->is_i945gm)
> +#define IS_I945(dev)		(IS_I945G(dev) || IS_I945GM(dev))
>  #define IS_BROADWATER(dev)	(INTEL_INFO(dev)->is_broadwater)
>  #define IS_CRESTLINE(dev)	(INTEL_INFO(dev)->is_crestline)
>  #define IS_GM45(dev)		((dev)->pci_device == 0x2A42)
> @@ -927,8 +932,10 @@ enum intel_chip_family {
>  #define IS_PINEVIEW_M(dev)	((dev)->pci_device == 0xa011)
>  #define IS_PINEVIEW(dev)	(INTEL_INFO(dev)->is_pineview)
>  #define IS_G33(dev)		(INTEL_INFO(dev)->is_g33)
> +#define IS_I915_DISPLAY(dev)	(IS_I915(dev) || IS_I945(dev) || IS_G33(dev))

Not more nested predicates that mix capability bits and devids - just add
a new bit for the display engine! IS_I915_DISPLAY() is a good name, and
makes me want IS_I830_DISPLAY rather than IS_I8XX. And I think you've just
set a new precedent to distinguish the display engines from the render
engine from the chipsets. Don't let me stop you from completing the job ;)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-05-05 22:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 22:16 [PATCH] drm/i915: clarify IS_GEN vs IS_<product> usage Jesse Barnes
2011-05-05 22:57 ` Chris Wilson [this message]
2011-05-09 18:42   ` Jesse Barnes
2011-05-09 19:09     ` Chris Wilson
2011-05-10 18:45     ` Eric Anholt
2011-05-10 21:24       ` Chris Wilson

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='0d30dc$m4ic2q@orsmga001.jf.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    /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.