[PATCH 1/3] drm/mm: fix debug table BUG

[PATCH 1/3] drm/mm: fix debug table BUG

[Daniel Vetter]

In

commit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Apr 20 12:08:11 2013 +0200

    drm/mm: fix dump table BUG

I've failed to fix both instances of the regression introduced in

commit 9e8944ab564f2e3dde90a518cd32048c58918608
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 15 11:32:17 2012 +0000

   drm: Introduce an iterator over holes in the drm_mm range manager

Patch this up in the same way by extracting the hole debug logic
into it's own function, since that'll also clarify the logic a bit.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_mm.c | 37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 07cf99c..f9d4873 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -716,36 +716,37 @@ void drm_mm_takedown(struct drm_mm * mm)
 }
 EXPORT_SYMBOL(drm_mm_takedown);
 
-void drm_mm_debug_table(struct drm_mm *mm, const char *prefix)
+static unsigned long drm_mm_debug_hole(struct drm_mm_node *entry,
+				       const char *prefix)
 {
-	struct drm_mm_node *entry;
-	unsigned long total_used = 0, total_free = 0, total = 0;
 	unsigned long hole_start, hole_end, hole_size;
 
-	hole_start = drm_mm_hole_node_start(&mm->head_node);
-	hole_end = drm_mm_hole_node_end(&mm->head_node);
-	hole_size = hole_end - hole_start;
-	if (hole_size)
+	if (entry->hole_follows) {
+		hole_start = drm_mm_hole_node_start(entry);
+		hole_end = drm_mm_hole_node_end(entry);
+		hole_size = hole_end - hole_start;
 		printk(KERN_DEBUG "%s 0x%08lx-0x%08lx: %8lu: free\n",
 			prefix, hole_start, hole_end,
 			hole_size);
-	total_free += hole_size;
+		return hole_size;
+	}
+
+	return 0;
+}
+
+void drm_mm_debug_table(struct drm_mm *mm, const char *prefix)
+{
+	struct drm_mm_node *entry;
+	unsigned long total_used = 0, total_free = 0, total = 0;
+
+	total_free += drm_mm_debug_hole(&mm->head_node, prefix);
 
 	drm_mm_for_each_node(entry, mm) {
 		printk(KERN_DEBUG "%s 0x%08lx-0x%08lx: %8lu: used\n",
 			prefix, entry->start, entry->start + entry->size,
 			entry->size);
 		total_used += entry->size;
-
-		if (entry->hole_follows) {
-			hole_start = drm_mm_hole_node_start(entry);
-			hole_end = drm_mm_hole_node_end(entry);
-			hole_size = hole_end - hole_start;
-			printk(KERN_DEBUG "%s 0x%08lx-0x%08lx: %8lu: free\n",
-				prefix, hole_start, hole_end,
-				hole_size);
-			total_free += hole_size;
-		}
+		total_free += drm_mm_debug_hole(entry, prefix);
 	}
 	total = total_free + total_used;
 
-- 
1.8.3.1

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

[Daniel Vetter]

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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..32e63a8 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (drm_mm_initialized(&dev_priv->mm.stolen))
 		return -ENODEV;
 
 	if (size < dev_priv->fbc.size)
@@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
+	if (drm_mm_initialized(&dev_priv->mm.stolen))
+		return;
+
 	i915_gem_stolen_cleanup_compression(dev);
 	drm_mm_takedown(&dev_priv->mm.stolen);
 }
@@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
 	struct drm_i915_gem_object *obj;
 	struct drm_mm_node *stolen;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
 	DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
@@ -331,7 +334,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	struct drm_i915_gem_object *obj;
 	struct drm_mm_node *stolen;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
 	DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, gtt_offset=%x, size=%x\n",
-- 
1.8.3.1

[PATCH 3/3] drm/mm: WARN for unclean mm takedown

[Daniel Vetter]

The usual drm driver has tons of different drm_mm memory managers so the drm
error message in dmesg is pretty useless. WARN instead so that we have the full
backtrace.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_mm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index f9d4873..d303e31 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -699,8 +699,8 @@ void drm_mm_takedown(struct drm_mm * mm)
 {
 	struct drm_mm_node *entry, *next;
 
-	if (!list_empty(&mm->head_node.node_list)) {
-		DRM_ERROR("Memory manager not clean. Delaying takedown\n");
+	if (WARN(!list_empty(&mm->head_node.node_list),
+		 "Memory manager not clean. Delaying takedown\n")) {
 		return;
 	}
 
-- 
1.8.3.1

Re: [PATCH 2/3] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Mon, Jul 01, 2013 at 10:01:03PM +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.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 8e02344..32e63a8 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  
> -	if (dev_priv->mm.stolen_base == 0)
> +	if (drm_mm_initialized(&dev_priv->mm.stolen))

Logically reversed? Which is more obscure now :-p
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

[Daniel Vetter]

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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..fbfc2c7 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return -ENODEV;
 
 	if (size < dev_priv->fbc.size)
@@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
+		return;
+
 	i915_gem_stolen_cleanup_compression(dev);
 	drm_mm_takedown(&dev_priv->mm.stolen);
 }
@@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
 	struct drm_i915_gem_object *obj;
 	struct drm_mm_node *stolen;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
 	DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
-- 
1.8.3.1

Re: [Intel-gfx] [PATCH 3/3] drm/mm: WARN for unclean mm takedown

[Ben Widawsky]

On Mon,  1 Jul 2013 22:01:04 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> The usual drm driver has tons of different drm_mm memory managers so
> the drm error message in dmesg is pretty useless. WARN instead so
> that we have the full backtrace.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I've written this patch myself a number of times.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>

> ---
>  drivers/gpu/drm/drm_mm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index f9d4873..d303e31 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -699,8 +699,8 @@ void drm_mm_takedown(struct drm_mm * mm)
>  {
>  	struct drm_mm_node *entry, *next;
>  
> -	if (!list_empty(&mm->head_node.node_list)) {
> -		DRM_ERROR("Memory manager not clean. Delaying
> takedown\n");
> +	if (WARN(!list_empty(&mm->head_node.node_list),
> +		 "Memory manager not clean. Delaying takedown\n")) {
>  		return;
>  	}
>  

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

[Chris Wilson]

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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [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 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.

Hm, on that notion I wonder whether we should keep the display up while
doing a module reload - it would be a neat exercise for all that fastboot
state reconstruction code. Especially the fb reconstruction code would get
much more pacing than what it gets now (since grub tends to leave the
display in VGA mode so often ...).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Daniel Vetter]

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.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Tested-by: lu hua <huax.lu@intel.com>

> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 8e02344..fbfc2c7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  
> -	if (dev_priv->mm.stolen_base == 0)
> +	if (!drm_mm_initialized(&dev_priv->mm.stolen))
>  		return -ENODEV;
>  
>  	if (size < dev_priv->fbc.size)
> @@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  
> +	if (!drm_mm_initialized(&dev_priv->mm.stolen))
> +		return;
> +
>  	i915_gem_stolen_cleanup_compression(dev);
>  	drm_mm_takedown(&dev_priv->mm.stolen);
>  }
> @@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
>  	struct drm_i915_gem_object *obj;
>  	struct drm_mm_node *stolen;
>  
> -	if (dev_priv->mm.stolen_base == 0)
> +	if (!drm_mm_initialized(&dev_priv->mm.stolen))
>  		return NULL;
>  
>  	DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
> -- 
> 1.8.3.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Chris Wilson]

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).

> Hm, on that notion I wonder whether we should keep the display up while
> doing a module reload - it would be a neat exercise for all that fastboot
> state reconstruction code. Especially the fb reconstruction code would get
> much more pacing than what it gets now (since grub tends to leave the
> display in VGA mode so often ...).

Yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [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

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

[Daniel Vetter]

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.

v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function (if
we indeed have stolen memory).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..0f8cf62 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return -ENODEV;
 
 	if (size < dev_priv->fbc.size)
@@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
+		return;
+
 	i915_gem_stolen_cleanup_compression(dev);
 	drm_mm_takedown(&dev_priv->mm.stolen);
 }
@@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
 	struct drm_i915_gem_object *obj;
 	struct drm_mm_node *stolen;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
 	DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
@@ -331,7 +334,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	struct drm_i915_gem_object *obj;
 	struct drm_mm_node *stolen;
 
-	if (dev_priv->mm.stolen_base == 0)
+	if (!drm_mm_initialized(&dev_priv->mm.stolen))
 		return NULL;
 
 	DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, gtt_offset=%x, size=%x\n",
-- 
1.8.3.1

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

[Chris Wilson]

On Tue, Jul 02, 2013 at 10:48:31AM +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.
> 
> v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
> the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
> allocatot must already be initialized when calling that function (if
> we indeed have stolen memory).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Tested-by: lu hua <huax.lu@intel.com> (v3)
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Once thing I noticed is that we should probably warn if vlv_reserved >=
stolen_size.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [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 10:25:17AM +0100, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 10:48:31AM +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.
> > 
> > v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
> > the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
> > allocatot must already be initialized when calling that function (if
> > we indeed have stolen memory).
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Tested-by: lu hua <huax.lu@intel.com> (v3)
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks for the review, merged to -fixes.
> 
> Once thing I noticed is that we should probably warn if vlv_reserved >=
> stolen_size.

I've added that patch to my queue, I'll submit it together with the gm45
reset fixes (once QA has tested them).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch