Dave Airlie wrote:
> 2009/8/21 Thomas Hellström <tho...@shipmail.org>:
>
>> Dave Airlie wrote:
>>
>>> From: Dave Airlie <airl...@linux.ie>
>>>
>>> This adds code to the drm_mm to talk to debugfs, and adds
>>> support to radeon to add the VRAM and GTT mm lists to debugfs.
>>>
>>> changes since v1:
>>> don't bother with free list just add used/free to main list
>>> add totals in pages
>>>
>>> Signed-off-by: Dave Airlie <airl...@redhat.com>
>>> ---
>>> drivers/gpu/drm/drm_mm.c | 25 ++++++++++++++++++++++
>>> drivers/gpu/drm/radeon/radeon_ttm.c | 39
>>> +++++++++++++++++++++++++++++++++++
>>> include/drm/drm_mm.h | 4 +++
>>> 3 files changed, 68 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>>> index 3e47869..a454e55 100644
>>> --- a/drivers/gpu/drm/drm_mm.c
>>> +++ b/drivers/gpu/drm/drm_mm.c
>>> @@ -44,6 +44,7 @@
>>> #include "drmP.h"
>>> #include "drm_mm.h"
>>> #include <linux/slab.h>
>>> +#include <linux/seq_file.h>
>>> #define MM_UNUSED_TARGET 4
>>> @@ -370,3 +371,27 @@ void drm_mm_takedown(struct drm_mm * mm)
>>> BUG_ON(mm->num_unused != 0);
>>> }
>>> EXPORT_SYMBOL(drm_mm_takedown);
>>> +
>>> +#if defined(CONFIG_DEBUG_FS)
>>> +int drm_mm_dump_table(struct seq_file *m, void *data)
>>> +{
>>> + struct drm_info_node *node = (struct drm_info_node *)m->private;
>>> + struct drm_mm *mm = (struct drm_mm *)node->info_ent->data;
>>> + struct drm_mm_node *entry;
>>> + int total_used = 0, total_free = 0, total = 0;
>>> + spin_lock(&mm->unused_lock);
>>>
>>>
>> This is not correct. The mm::unused_lock is there only to protect the list
>> of cached drm_mm_node allocations that we
>> use instead of kmalloc() when atomic.
>>
>> Instead the lock the user uses to protect the mm:s must be taken. In the TTM
>> case IIRC its the bo_glob::lru_lock.
>>
>> Is it safe to use seq_printf() from within a spinlocked region?
>>
>>
>
> Good point, this was one of those quick hacks to have a look at fragmentation
> so I sorta guessed at the lock,
>
> I'd probably be best not locking anything, but I'll try and add a
> driver layer before
> drm_mm to do the correct locking, though as its debugging info even
> inconsistent
> is better than none.
>
Yes, but you might end up traversing the list in the middle of a list
pointer modification, which is bad.
> I'll fix it up next week and send v3, thanks again.
> Dave.
>
/Thomas
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
