Re: [Linaro-mm-sig] [RFC/PATCH] fb: Add dma-buf support
flat view
From: Tomasz Stanislawski <hidden>
Date: 2012-06-20 15:41:57
Also in:
linux-media
Hi Laurent, Thank you for the patch. On 06/20/2012 04:09 PM, Laurent Pinchart wrote:
Add support for the dma-buf exporter role to the frame buffer API. The importer role isn't meaningful for frame buffer devices, as the frame buffer device model doesn't allow using externally allocated memory. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- Documentation/fb/api.txt | 36 ++++++++++++++++++++++++++++++++++++ drivers/video/fbmem.c | 36 ++++++++++++++++++++++++++++++++++++ include/linux/fb.h | 12 ++++++++++++ 3 files changed, 84 insertions(+), 0 deletions(-)
[snip]
quoted hunk ↗ jump to hunk
+The export a frame buffer as a dma-buf file descriptors, applications call the +FBIOGET_DMABUF ioctl. The ioctl takes a pointer to a fb_dmabuf_export +structure. + +struct fb_dmabuf_export { + __u32 fd; + __u32 flags; +};
What do you think about adding some reserved fields to struct fb_dmabuf_export to make it future-proof for DMABUF extensions?
quoted hunk ↗ jump to hunk
+ +The flag field specifies the flags to be used when creating the dma-buf file +descriptor. The only supported flag is O_CLOEXEC. If the call is successful, +the driver will set the fd field to a file descriptor corresponding to the +dma-buf object. + +Applications can then pass the file descriptors to another application or +another device driver. The dma-buf object is automatically reference-counted, +applications can and should close the file descriptor as soon as they don't +need it anymore. The underlying dma-buf object will not be freed before the +last device that uses the dma-buf object releases it.diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 0dff12a..400e449 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c@@ -15,6 +15,7 @@ #include <linux/compat.h> #include <linux/types.h> +#include <linux/dma-buf.h> #include <linux/errno.h> #include <linux/kernel.h> #include <linux/major.h>@@ -1074,6 +1075,23 @@ fb_blank(struct fb_info *info, int blank) return ret; } +#ifdef CONFIG_DMA_SHARED_BUFFER +int +fb_get_dmabuf(struct fb_info *info, int flags) +{ + struct dma_buf *dmabuf; + + if (info->fbops->fb_dmabuf_export = NULL) + return -ENOTTY; + + dmabuf = info->fbops->fb_dmabuf_export(info);
IMO, it is not a good idea to delegate an implementation of DMABUF ops to the driver. Maybe exporting could be handled inside FB stack. As I understand, the FB stack needs only 'get-scatterlist' ops from an FB driver. All other DMABUF magic does not need driver involvement, does it?
quoted hunk ↗ jump to hunk
+ if (IS_ERR(dmabuf)) + return PTR_ERR(dmabuf); + + return dma_buf_fd(dmabuf, flags); +} +#endif +
[snip]
quoted hunk ↗ jump to hunk
diff --git a/include/linux/fb.h b/include/linux/fb.h index ac3f1c6..c9fee75 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h@@ -701,6 +708,11 @@ struct fb_ops { /* called at KDB enter and leave time to prepare the console */ int (*fb_debug_enter)(struct fb_info *info); int (*fb_debug_leave)(struct fb_info *info); + +#ifdef CONFIG_DMA_SHARED_BUFFER + /* Export the frame buffer as a dmabuf object */ + struct dma_buf *(*fb_dmabuf_export)(struct fb_info *info); +#endif
Memory trashing or even kernel crash may happen if a module compiled with CONFIG_DMA_SHARED_BUFFER enabled is loaded into kernel with CONFIG_DMA_SHARED_BUFFER disabled.
}; #ifdef CONFIG_FB_TILEBLITTING