From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 2/3] drm/i915: split irq handling into
 per-chipset functions
Date: Thu, 7 Apr 2011 15:04:14 -0700
Message-ID: <20110407150414.4dc8a951@jbarnes-desktop>
References: <1302211980-10089-1-git-send-email-jbarnes@virtuousgeek.org>
	<1302211980-10089-3-git-send-email-jbarnes@virtuousgeek.org>
	<0d30dc$lom25v@orsmga001.jf.intel.com>
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 cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com
	[67.222.39.38])
	by gabe.freedesktop.org (Postfix) with SMTP id F31F79E7AF
	for <intel-gfx@lists.freedesktop.org>;
	Thu,  7 Apr 2011 15:04:22 -0700 (PDT)
In-Reply-To: <0d30dc$lom25v@orsmga001.jf.intel.com>
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Thu, 07 Apr 2011 22:50:42 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Thu,  7 Apr 2011 14:32:59 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Set the IRQ handling functions in driver load so they'll just be used
> > directly, rather than branching over most of the code in the chipset
> > functions.
> 
> This is the direction we definitely need to go in. However, it is still a
> tangled mess of which functions are called for which chipset.
> 
> Is it any clearer to have a display vfunc table for each chipset? It would
> still be a mess, but at least there will be an overview of how each chipset
> works in a single spot. Invaluable for tracing through the function
> pointers later.

Yeah, initializing it all in one place would help, but the existing
KMS/non-KMS split makes that hard for things like IRQ handling.

> One thing we need to be careful is to move the common code into small
> helper routines to avoid unnecessarily duplicating it.

But not before we're sure about the duplication!  Obviously things like
the workqueue init at IRQ install time could be shared, but I don't
like the idea of sharing hardware code unless it's absolutely
identical, given our history.

-- 
Jesse Barnes, Intel Open Source Technology Center