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]
+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?
+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?
- if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);- return dma_buf_fd(dmabuf, flags);
+} +#endif
[snip]
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