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@xxxxxxxxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
