From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/3] drm: Export routines for inserting preallocated nodes into the mm manager Date: Tue, 18 Dec 2012 09:13:34 +0000 Message-ID: References: <1354912628-7776-1-git-send-email-chris@chris-wilson.co.uk> <20121218002822.GT5737@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121218002822.GT5737@phenom.ffwll.local> 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: Daniel Vetter Cc: Dave Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, 18 Dec 2012 01:28:22 +0100, Daniel Vetter wrote: > The last parameter of search_free_generic is best_match, which isn't used > by any current caller. The only reason it's still there is that I haven't > converted yet all drm_mm.c users to preallocate drm_mm_node's, but as soon > as that's done best_match will die together with search_free_generic as a > public interface. > > So what's the atomic doing in here? I've looked through the drm/i915 > patches and couldn't see any reason ... Can we just respin the two i915 > patches with _generic and atomic = false dropped, or do I miss something > big here? It is scheduled to become a flags parameter for doing more funky searches. (Allocating preferrentially from unmappable for LLC/snoopable buffers etc) But the whole idea of the _generic functions is that they do no currying at all, otherwise we will eventually need a _generic_full. -Chris -- Chris Wilson, Intel Open Source Technology Centre