From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 2/2] drm/i915: Track unbound pages
Date: Mon, 20 Aug 2012 11:42:55 +0200
Message-ID: <20120820094255.GC5170@phenom.ffwll.local>
References: <1344696088-24760-2-git-send-email-chris@chris-wilson.co.uk>
	<1345453239-12529-1-git-send-email-daniel.vetter@ffwll.ch>
	<1345453239-12529-2-git-send-email-daniel.vetter@ffwll.ch>
	<1345455372_2371@CP5-2952>
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 mail-wi0-f171.google.com (mail-wi0-f171.google.com
	[209.85.212.171])
	by gabe.freedesktop.org (Postfix) with ESMTP id 2B08E9F0E7
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 20 Aug 2012 02:42:31 -0700 (PDT)
Received: by wibhq4 with SMTP id hq4so3056497wib.12
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 20 Aug 2012 02:42:31 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <1345455372_2371@CP5-2952>
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: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Mon, Aug 20, 2012 at 10:36:09AM +0100, Chris Wilson wrote:
> On Mon, 20 Aug 2012 11:00:39 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >  int
> > -i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
> > -			      gfp_t gfpmask)
> > +i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
> >  {
> > +	struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> >  	int page_count, i;
> >  	struct address_space *mapping;
> > -	struct inode *inode;
> >  	struct page *page;
> > +	gfp_t gfp;
> >  
> >  	if (obj->pages || obj->sg_table)
> >  		return 0;
> >  
> > +	/* Assert that the object is not currently in any GPU domain. As it
> > +	 * wasn't in the GTT, there shouldn't be any way it could have been in
> > +	 * a GPU cache
> > +	 */
> > +	BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
> > +	BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
> > +
> >  	/* Get the list of pages out of our struct file.  They'll be pinned
> >  	 * at this point until we release them.
> >  	 */
> >  	page_count = obj->base.size / PAGE_SIZE;
> > -	BUG_ON(obj->pages != NULL);
> > -	obj->pages = drm_malloc_ab(page_count, sizeof(struct page *));
> > +	obj->pages = kmalloc(page_count*sizeof(struct page *), GFP_KERNEL);
> 
> This is a silly one (by me). At one point the patch introduced
> i915_malloc() and replaced drm_malloc_ab() with it and then I reverted
> that after transitioning to using the sg_table everywhere.
> 
> It needs to still be drm_malloc_ab() in this and the follow-on patches
> until it is replaced by sg_alloc_table().

Ok, history fixed. Can you please check whether I haven't fumbled it?

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48