From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 14/14] drm/i915: inline enable/disable_irq into ring->get/put_irq Date: Fri, 13 Apr 2012 11:13:53 +0200 Message-ID: <20120413091353.GD4525@phenom.ffwll.local> References: <1334175179-1514-1-git-send-email-daniel.vetter@ffwll.ch> <1334175179-1514-15-git-send-email-daniel.vetter@ffwll.ch> <20120412180330.60e1f99b@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 47E0E9E796 for ; Fri, 13 Apr 2012 02:13:00 -0700 (PDT) Received: by werp11 with SMTP id p11so2177481wer.36 for ; Fri, 13 Apr 2012 02:12:59 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120412180330.60e1f99b@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Ben Widawsky Cc: Daniel Vetter , Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Thu, Apr 12, 2012 at 06:03:30PM -0700, Ben Widawsky wrote: > On Wed, 11 Apr 2012 22:12:59 +0200 > Daniel Vetter wrote: > > > Now that these are properly refactored this additional indirection > > doesn't really buy us anything but confusion. Hence inline them. > > > > This duplicates the ironlake gt enable/disable code snippet, but we've > > already separate ilk from gen6+ gt irq in i915_irq.c, so I think this > > makes more sense. > > > > Signed-Off-by: Daniel Vetter > > Bikeshed: > While doing all this, I think put/get irq is really terribly named. I > was a much bigger fan of the enable disable. Actually that can be combined with Chris' bikeshed to move the ring->put|get_irg to dev_priv->core.ring_enable/disable_irq. But I've figured that the same patch series should also move the forcewake function pointers from dev_priv->display to dev_priv->core, so this is imo a different patch series. > Also, you could use a bit of flow control to write to the correct IMR > register and not duplicate functions at all. You already do the > POSTING_READ so performance shouldn't matter. > > Something like... > > uint32_t imr = GEN(dev) >= 5 ? GTIMR: IMR; I've figured I want to ditch all IS_GEN checks from these functions. But for this case it makes some sense. Imo could be done with the follow-up though. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48