[PATCH] [v3] drm: pre allocate node for create_block

[Ben Widawsky]

On Fri, Jul 05, 2013 at 09:25:35PM +0200, Daniel Vetter wrote:
> On Thu, Jul 04, 2013 at 10:32:27PM +0200, David Herrmann wrote:
> > Hi
> > 
> > On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> > > For an upcoming patch where we introduce the i915 VMA, it's ideal to
> > > have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> > > Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
> > > will break a bunch of code, but amongst them are 2 callers of
> > > drm_mm_create_block(), both related to stolen memory.
> > >
> > > It also allows us to embed the drm_mm_node into the object currently
> > > which provides a nice transition over to the new code.
> > >
> > > v2: Reordered to do before ripping out obj->gtt_offset.
> > > Some minor cleanups made available because of reordering.
> > >
> > > v3: s/continue/break on failed stolen node allocation (David)
> > > Set obj->gtt_space on failed node allocation (David)
> > > Only unref stolen (fix double free) on failed create_stolen (David)
> > > Free node, and NULL it in failed create_stolen (David)
> > > Add back accidentally removed newline (David)
> > >
> > > CC: <dri-devel at lists.freedesktop.org>
> > > CC: David Herrmann <dh.herrmann at gmail.com>
> > > Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> > 
> > I already suspected that you'd embed drm_mm_node in a follow-up patch
> > but I am not subscribed to intel-gfx so I didn't get the other
> > patches. Looks good now.
> > 
> > Reviewed-by: David Herrmann <dh.herrmann at gmail.com>
> 
> Ok, I've discussed this a bit with Dave on irc and he's a bit unhappy with
> the creat_block name. After a bit of chatting with Ben I think we should
> go with
> 
> int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node);
> 
> The start/size/color arguments would then be passed in through the
> drm_mm_node argument. Ben asked whether that's not too much poking around
> in drm_mm_node internals, but imo those three pieces of it are part of the
> public interface to drm_mm users.

Do you mind if I leave the patch as is, since it's reviewed, and put the
rename patch on top? I have a long history of screwing up simple
rebases.

> 
> Also, the patch as-is conflicts a bit too badly with my current tree. So
> can you please apply the little bikeshed, rebase, and then rebase the
> other patches in this series that I haven't merged on top of this?
> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ben Widawsky, Intel Open Source Technology Center