On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
> Hi Hans,
>
> On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
> > On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
> > > +/**
> > > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > > descriptor + *
> > > + * @fd: file descriptor associated with DMABUF (set by driver)
> > > + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
> > > struct + * v4l2_buffer::m.offset (for single-plane formats) or
> > > + * v4l2_plane::m.offset (for multi-planar formats)
> > > + * @flags: flags for newly created file, currently only O_CLOEXEC is
> > > + * supported, refer to manual of open syscall for more details
> > > + *
> > > + * Contains data used for exporting a video buffer as DMABUF file
> > > descriptor. + * The buffer is identified by a 'cookie' returned by
> > > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > > userspace). All + * reserved fields must be set to zero. The field
> > > reserved0 is expected to + * become a structure 'type' allowing an
> > > alternative layout of the structure + * content. Therefore this field
> > > should not be used for any other extensions. + */
> > > +struct v4l2_exportbuffer {
> > > + __u32 fd;
> > > + __u32 reserved0;
> > > + __u32 mem_offset;
> >
> > This should be a union identical to the m union in v4l2_plane, together with
> > a u32 memory field. That way you can just copy memory and m from
> > v4l2_plane/buffer and call expbuf. If new memory types are added in the
> > future, then you don't need to change this struct.
>
> OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
> export types in the future not corresponding to a memory type ? I don't see
> any use case right now though.
The memory type should be all you need. And the union is also needed since the
userptr value is unsigned long, thus ensuring that you have 64-bits available
for pointer types in the future. That's really my main point: the union should
have the same size as the union in v4l2_buffer/plane, allowing for the same
size pointers or whatever to be added in the future.
> > For that matter, wouldn't it be useful to support exporting a userptr buffer
> > at some point in the future?
>
> Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
Why? It's perfectly fine to use it and it's not going away.
I'm not saying that we should support exporting a userptr buffer as a dmabuf fd,
but I'm just wondering if that is possible at all and how difficult it would be.
Regards,
Hans
>
> > BTW, this patch series needs to be rebased to the latest for_v3.6. Quite a
> > few core things have changed when it comes to adding new ioctls.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
