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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox