From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH] drm/i915: clarify IS_GEN vs IS_<product>
	usage
Date: Tue, 10 May 2011 22:24:43 +0100
Message-ID: <382e69$ctpctm@azsmga001.ch.intel.com>
References: <1304633805-7505-1-git-send-email-jbarnes@virtuousgeek.org>
	<0d30dc$m4ic2q@orsmga001.jf.intel.com>
	<20110509114213.34816211@jbarnes-desktop>
	<874o52xul9.fsf@pollan.anholt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mga14.intel.com (mga14.intel.com [143.182.124.37])
	by gabe.freedesktop.org (Postfix) with ESMTP id 6BA989E7F7
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 10 May 2011 14:24:47 -0700 (PDT)
In-Reply-To: <874o52xul9.fsf@pollan.anholt.net>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Eric Anholt <eric@anholt.net>, Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Tue, 10 May 2011 11:45:54 -0700, Eric Anholt <eric@anholt.net> wrote:
> On Mon, 9 May 2011 11:42:13 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> This feels like a lot of churn to me, for the pre-gen4 chipsets at
> least.  gen2 is always is_830_display (which is overly specific), and
> gen3 is always is_i915_display.

The argument is that we want to be consistent in how we test for
capabilities so that adding new feature tests or new chipsets is easier
and has no side-effects with existing capabilities. How the macros map
on to the actual devices is another matter - a compromise between
simplicity and runtime efficiency.

If it doesn't reduce our long term maintenance burden, then there is
no point making the distinction. I think more fine-grained checks will
help in the future, (and consistency across all generations prevents silly
bugs).

I'm still skeptical that the segregation of capabilities between
chipset/display/render is as clear cut as Jesse portrays. ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre