From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
Signed-off-by: Sumit Semwal sumit.semwal@ti.com --- drivers/base/dma-buf.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 6 +- 2 files changed, 154 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index a3f79c4..49fcf0f 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -27,9 +27,18 @@ #include <linux/dma-buf.h> #include <linux/anon_inodes.h> #include <linux/export.h> +#include <linux/debugfs.h> +#include <linux/seq_file.h>
static inline int is_dma_buf_file(struct file *);
+struct dma_buf_list { + struct list_head head; + struct mutex lock; +}; + +static struct dma_buf_list db_list; + static int dma_buf_release(struct inode *inode, struct file *file) { struct dma_buf *dmabuf; @@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct file *file) dmabuf = file->private_data;
dmabuf->ops->release(dmabuf); + + mutex_lock(&db_list.lock); + list_del(&dmabuf->list_node); + mutex_unlock(&db_list.lock); + kfree(dmabuf); return 0; } @@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments);
+ mutex_lock(&db_list.lock); + list_add(&dmabuf->list_node, &db_list.head); + mutex_unlock(&db_list.lock); + return dmabuf; } EXPORT_SYMBOL_GPL(dma_buf_export); @@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) dmabuf->ops->vunmap(dmabuf, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_vunmap); + +static int dma_buf_init_debugfs(void); +static void dma_buf_uninit_debugfs(void); + +static void __init dma_buf_init(void) +{ + mutex_init(&db_list.lock); + INIT_LIST_HEAD(&db_list.head); + dma_buf_init_debugfs(); +} + +static void __exit dma_buf_deinit(void) +{ + dma_buf_uninit_debugfs(); +} + +#ifdef CONFIG_DEBUG_FS +static int dma_buf_describe(struct seq_file *s) +{ + int ret; + struct dma_buf *buf_obj; + struct dma_buf_attachment *attach_obj; + int count = 0, attach_count; + size_t size = 0; + + ret = mutex_lock_interruptible(&db_list.lock); + + if (ret) + return ret; + + seq_printf(s, "\nDma-buf Objects:\n"); + seq_printf(s, "\tsize\tflags\tmode\tcount\n"); + + list_for_each_entry(buf_obj, &db_list.head, list_node) { + seq_printf(s, "\t"); + + seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n", + buf_obj->size, buf_obj->file->f_flags, + buf_obj->file->f_mode, + buf_obj->file->f_count.counter); + + seq_printf(s, "\t\tAttached Devices:\n"); + attach_count = 0; + + list_for_each_entry(attach_obj, &buf_obj->attachments, node) { + seq_printf(s, "\t\t"); + + seq_printf(s, "%s\n", attach_obj->dev->init_name); + attach_count++; + } + + seq_printf(s, "\n\t\tTotal %d devices attached\n", + attach_count); + + count++; + size += buf_obj->size; + } + + seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size); + + mutex_unlock(&db_list.lock); + return 0; +} + +static int dma_buf_show(struct seq_file *s, void *unused) +{ + void (*func)(struct seq_file *) = s->private; + func(s); + return 0; +} + +static int dma_buf_debug_open(struct inode *inode, struct file *file) +{ + return single_open(file, dma_buf_show, inode->i_private); +} + +static const struct file_operations dma_buf_debug_fops = { + .open = dma_buf_debug_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static struct dentry *dma_buf_debugfs_dir; + +static int dma_buf_init_debugfs(void) +{ + int err = 0; + dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL); + if (IS_ERR(dma_buf_debugfs_dir)) { + err = PTR_ERR(dma_buf_debugfs_dir); + dma_buf_debugfs_dir = NULL; + return err; + } + + err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe); + + if (err) + pr_debug("dma_buf: debugfs: failed to create node bufinfo\n"); + + return err; +} + +static void dma_buf_uninit_debugfs(void) +{ + if (dma_buf_debugfs_dir) + debugfs_remove_recursive(dma_buf_debugfs_dir); +} + +int dma_buf_debugfs_create_file(const char *name, + int (*write)(struct seq_file *)) +{ + struct dentry *d; + + d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir, + write, &dma_buf_debug_fops); + + if (IS_ERR(d)) + return PTR_ERR(d); + + return 0; +} +#else +static inline int dma_buf_init_debugfs(void) +{ + return 0; +} +static inline void dma_buf_uninit_debugfs(void) +{ +} +#endif diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index bd2e52c..160453f 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -112,6 +112,7 @@ struct dma_buf_ops { * @file: file pointer used for sharing buffers across, and for refcounting. * @attachments: list of dma_buf_attachment that denotes all devices attached. * @ops: dma_buf_ops associated with this buffer object. + * @list_node: node for dma_buf accounting and debugging. * @priv: exporter specific private data for this buffer object. */ struct dma_buf { @@ -121,6 +122,8 @@ struct dma_buf { const struct dma_buf_ops *ops; /* mutex to serialize list manipulation and attach/detach */ struct mutex lock; + + struct list_head list_node; void *priv; };
@@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); - +int dma_buf_debugfs_create_file(const char *name, + int (*write)(struct seq_file *)); #endif /* __DMA_BUF_H__ */
On Fri, Dec 14, 2012 at 10:36 AM, sumit.semwal@ti.com wrote:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
Signed-off-by: Sumit Semwal sumit.semwal@ti.com
Looks line, only nitpick is that we have no idea who exported a given buffer. So what about adding a new dma_buf_export_named which takes a char * to identify the exporter, and then add a bit of cpp magic like this:
#define dma_buf_export(args) dma_buf_export_named(args, stringify(__FILE))
At least for drm drivers using the prime helpers this should add the file of the exporting driver, so would be good enough to identify the exporter. Or we could add a dma_buf_export_dev which has a struct device * as additional argument ... Otoh that wouldn't really work for exporting dma_bufs from ION, so maybe a const char * is better. -Daniel
drivers/base/dma-buf.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 6 +- 2 files changed, 154 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index a3f79c4..49fcf0f 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -27,9 +27,18 @@ #include <linux/dma-buf.h> #include <linux/anon_inodes.h> #include <linux/export.h> +#include <linux/debugfs.h> +#include <linux/seq_file.h>
static inline int is_dma_buf_file(struct file *);
+struct dma_buf_list {
struct list_head head;struct mutex lock;+};
+static struct dma_buf_list db_list;
static int dma_buf_release(struct inode *inode, struct file *file) { struct dma_buf *dmabuf; @@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct file *file) dmabuf = file->private_data;
dmabuf->ops->release(dmabuf);
mutex_lock(&db_list.lock);list_del(&dmabuf->list_node);mutex_unlock(&db_list.lock);kfree(dmabuf); return 0;} @@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments);
mutex_lock(&db_list.lock);list_add(&dmabuf->list_node, &db_list.head);mutex_unlock(&db_list.lock);return dmabuf;} EXPORT_SYMBOL_GPL(dma_buf_export); @@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) dmabuf->ops->vunmap(dmabuf, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+static int dma_buf_init_debugfs(void); +static void dma_buf_uninit_debugfs(void);
+static void __init dma_buf_init(void) +{
mutex_init(&db_list.lock);INIT_LIST_HEAD(&db_list.head);dma_buf_init_debugfs();+}
+static void __exit dma_buf_deinit(void) +{
dma_buf_uninit_debugfs();+}
+#ifdef CONFIG_DEBUG_FS +static int dma_buf_describe(struct seq_file *s) +{
int ret;struct dma_buf *buf_obj;struct dma_buf_attachment *attach_obj;int count = 0, attach_count;size_t size = 0;ret = mutex_lock_interruptible(&db_list.lock);if (ret)return ret;seq_printf(s, "\nDma-buf Objects:\n");seq_printf(s, "\tsize\tflags\tmode\tcount\n");list_for_each_entry(buf_obj, &db_list.head, list_node) {seq_printf(s, "\t");seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n",buf_obj->size, buf_obj->file->f_flags,buf_obj->file->f_mode,buf_obj->file->f_count.counter);seq_printf(s, "\t\tAttached Devices:\n");attach_count = 0;list_for_each_entry(attach_obj, &buf_obj->attachments, node) {seq_printf(s, "\t\t");seq_printf(s, "%s\n", attach_obj->dev->init_name);attach_count++;}seq_printf(s, "\n\t\tTotal %d devices attached\n",attach_count);count++;size += buf_obj->size;}seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);mutex_unlock(&db_list.lock);return 0;+}
+static int dma_buf_show(struct seq_file *s, void *unused) +{
void (*func)(struct seq_file *) = s->private;func(s);return 0;+}
+static int dma_buf_debug_open(struct inode *inode, struct file *file) +{
return single_open(file, dma_buf_show, inode->i_private);+}
+static const struct file_operations dma_buf_debug_fops = {
.open = dma_buf_debug_open,.read = seq_read,.llseek = seq_lseek,.release = single_release,+};
+static struct dentry *dma_buf_debugfs_dir;
+static int dma_buf_init_debugfs(void) +{
int err = 0;dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);if (IS_ERR(dma_buf_debugfs_dir)) {err = PTR_ERR(dma_buf_debugfs_dir);dma_buf_debugfs_dir = NULL;return err;}err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);if (err)pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");return err;+}
+static void dma_buf_uninit_debugfs(void) +{
if (dma_buf_debugfs_dir)debugfs_remove_recursive(dma_buf_debugfs_dir);+}
+int dma_buf_debugfs_create_file(const char *name,
int (*write)(struct seq_file *))+{
struct dentry *d;d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,write, &dma_buf_debug_fops);if (IS_ERR(d))return PTR_ERR(d);return 0;+} +#else +static inline int dma_buf_init_debugfs(void) +{
return 0;+} +static inline void dma_buf_uninit_debugfs(void) +{ +} +#endif diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index bd2e52c..160453f 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -112,6 +112,7 @@ struct dma_buf_ops {
- @file: file pointer used for sharing buffers across, and for refcounting.
- @attachments: list of dma_buf_attachment that denotes all devices attached.
- @ops: dma_buf_ops associated with this buffer object.
*/
- @list_node: node for dma_buf accounting and debugging.
- @priv: exporter specific private data for this buffer object.
struct dma_buf { @@ -121,6 +122,8 @@ struct dma_buf { const struct dma_buf_ops *ops; /* mutex to serialize list manipulation and attach/detach */ struct mutex lock;
struct list_head list_node; void *priv;};
@@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr);
+int dma_buf_debugfs_create_file(const char *name,
int (*write)(struct seq_file *));#endif /* __DMA_BUF_H__ */
1.7.10.4
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, sumit.semwal@ti.com wrote:
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {seq_printf(s, "\t\t");seq_printf(s, "%s\n", attach_obj->dev->init_name);attach_count++;}
You need to hold dmabuf->lock while walking the attachment list. -Daniel
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry?
Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
Also I think the name of the device and process that exported the dma-buf would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it.
I was thinking of having a directory structure like this:
/sys/kernel/debug/dma_buf/stats
and then for each dma-buf:
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
~Maarten
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry?
Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
Also I think the name of the device and process that exported the dma-buf would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it.
I was thinking of having a directory structure like this:
/sys/kernel/debug/dma_buf/stats
and then for each dma-buf:
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
yeah.. but sort of back-door's the security benefits of an anonymous fd..
BR, -R
~Maarten
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Op 14-12-12 15:11, Rob Clark schreef:
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry?
Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
Also I think the name of the device and process that exported the dma-buf would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it.
I was thinking of having a directory structure like this:
/sys/kernel/debug/dma_buf/stats
and then for each dma-buf:
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
yeah.. but sort of back-door's the security benefits of an anonymous fd..
BR, -R
If you have access to debugfs you're root, so what stops you from stealing it through a ptrace?
~Maarten
Hi,
On 12/14/2012 10:36 AM, sumit.semwal@ti.com wrote:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
Signed-off-by: Sumit Semwal sumit.semwal@ti.com
drivers/base/dma-buf.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 6 +- 2 files changed, 154 insertions(+), 1 deletion(-)
[...]
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index bd2e52c..160453f 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -112,6 +112,7 @@ struct dma_buf_ops {
- @file: file pointer used for sharing buffers across, and for refcounting.
- @attachments: list of dma_buf_attachment that denotes all devices attached.
- @ops: dma_buf_ops associated with this buffer object.
*/
- @list_node: node for dma_buf accounting and debugging.
- @priv: exporter specific private data for this buffer object.
struct dma_buf { @@ -121,6 +122,8 @@ struct dma_buf { const struct dma_buf_ops *ops; /* mutex to serialize list manipulation and attach/detach */ struct mutex lock;
- struct list_head list_node; void *priv;
}; @@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr);
+int dma_buf_debugfs_create_file(const char *name,
int (*write)(struct seq_file *));
Why is this function declared in the public header file?
-- Francesco
Hi Maarten,
On 14 December 2012 17:27, Maarten Lankhorst m.b.lankhorst@gmail.comwrote:
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry?
Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
Also I think the name of the device and process that exported the dma-buf
would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it.
I was thinking of having a directory structure like this:
/sys/kernel/debug/dma_buf/stats
and then for each dma-buf:
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
Let me think more about it, but I am inclined to add simple support first, and then add more features to dma_buf debugfs as it grows.
I still would want to take Daniel's suggestion on dma_buf_export_named() before I push this patch, so I guess I'll try to work a little more and prepare it for 3.9?
I quite like your idea of .../dma-buf/<exporting_file.c>/... , which would need the above as well :)
~Maarten
Best regards,
~Sumit.
On 14 December 2012 16:04, Daniel Vetter daniel@ffwll.ch wrote:
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, sumit.semwal@ti.com wrote:
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {seq_printf(s, "\t\t");seq_printf(s, "%s\n", attach_obj->dev->init_name);attach_count++;}You need to hold dmabuf->lock while walking the attachment list. -Daniel
Thanks Daniel!
Will update in next version.
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Best regards,
Sumit Semwal
On 17 December 2012 14:25, Sumit Semwal sumit.semwal@linaro.org wrote: Apologies for re-sending, since the gmail ui 'decided' to set some formatting options by default!
Hi Maarten,
On 14 December 2012 17:27, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry?
Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
Also I think the name of the device and process that exported the dma-buf would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it.
I was thinking of having a directory structure like this:
/sys/kernel/debug/dma_buf/stats
and then for each dma-buf:
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
Let me think more about it, but I am inclined to add simple support first, and then add more features to dma_buf debugfs as it grows.
I still would want to take Daniel's suggestion on dma_buf_export_named() before I push this patch, so I guess I'll try to work a little more and prepare it for 3.9?
I quite like your idea of .../dma-buf/<exporting_file.c>/... , which would need the above as well :)
~Maarten
Best regards, ~Sumit.
-- Thanks and regards,
Sumit Semwal
Linaro Kernel Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Fri, Dec 14, 2012 at 7:36 PM, sumit.semwal@ti.com wrote:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I like thie idea,
/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function ‘dma_buf_describe’: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:563:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long int’ [-Wformat] /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: At top level: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:528:123: warning: ‘dma_buf_init’ defined but not used [-Wunused-function]
not sure my compiler does though.
Dave.
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie airlied@gmail.com wrote:
On Fri, Dec 14, 2012 at 7:36 PM, sumit.semwal@ti.com wrote:
From: Sumit Semwal sumit.semwal@linaro.org
Add debugfs support to make it easier to print debug information about the dma-buf buffers.
I've attached two patches that make it work on my system, and fix the warnings,
I've used it to debug some leaks I was seeing, feel free to squash these patches into the original patch.
Dave.
linaro-mm-sig@lists.linaro.org
-
Daniel Vetter -
Dave Airlie -
Francesco Lavra -
Maarten Lankhorst -
Maarten Lankhorst -
Rob Clark -
Sumit Semwal -
sumit.semwal＠ti.com