[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
> > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> > > > Every other place properly checks whether we've managed to set
> > > > up the stolen allocator at boot-up properly, with the exception
> > > > of the cleanup code. Which results in an ugly
> > > > 
> > > > *ERROR* Memory manager not clean. Delaying takedown
> > > > 
> > > > at module unload time since the drm_mm isn't initialized at all.
> > > > 
> > > > v2: While at it check whether the stolen drm_mm is initialized instead
> > > > of the more obscure stolen_base == 0 check.
> > > > 
> > > > v3: Fix up the logic. Also we need to keep the stolen_base check in
> > > > i915_gem_object_create_stolen_for_preallocated since that can be
> > > > called before stolen memory is fully set up. Spotted by Chris Wilson.
> > > 
> > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since
> > > preallocated touches the stolen mm, it should be setup by that point.
> > 
> > I haven't seen it blow up at runtime, but we have special code in
> > i915_gem_object_create_stolen_for_preallocated which handles the
> > !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
> > us to wrap the vbios framebuffer.
> 
> That's a different drm_mm for the ggtt. We still need the stolen mm setup
> in order to allocate our memory (as we don't have the same dance to
> reconstruct the reserved blocks upon initialisation of stolen).

Oh right, I'll update the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch