[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Sumit Semwal sumit.semwal at linaro.org
Mon Dec 17 00:55:26 PST 2012


Hi Maarten,

On 14 December 2012 17:27, Maarten Lankhorst <m.b.lankhorst at gmail.com>wrote:

> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
> > From: Sumit Semwal <sumit.semwal at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/15bff657/attachment.html>


More information about the dri-devel mailing list