diff options
author | Bhupesh Sharma <bhupesh.sharma@st.com> | 2013-03-28 15:11:52 +0530 |
---|---|---|
committer | Felipe Balbi <balbi@ti.com> | 2013-04-02 11:42:48 +0300 |
commit | d692522577c051058efbe9e3c8aef68a4c36e4f7 (patch) | |
tree | 68e82cc467c8c507980037d0bb860ee8dbe4cfed /Documentation/i2c | |
parent | 225da3e3cb1f0db9e4cb7fa2a7dc3a360d1cf788 (diff) |
usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
This patch reworks the videobuffer management logic present in the UVC
webcam gadget and ports it to use the "more apt" videobuf2 framework for
video buffer management.
To support routing video data captured from a real V4L2 video capture
device with a "zero copy" operation on videobuffers (as they pass from
the V4L2 domain to UVC domain via a user-space application), we need to
support USER_PTR IO method at the UVC gadget side.
So the V4L2 capture device driver can still continue to use MMAP IO
method and now the user-space application can just pass a pointer to the
video buffers being dequeued from the V4L2 device side while queueing
them at the UVC gadget end. This ensures that we have a "zero-copy"
design as the videobuffers pass from the V4L2 capture device to the UVC
gadget.
Note that there will still be a need to apply UVC specific payload
headers on top of each UVC payload data, which will still require a copy
operation to be performed in the 'encode' routines of the UVC gadget.
This patch also addresses one issue found out while porting the UVC
gadget to videobuf2 framework:
- In case the usb requests queued by the gadget get completed
with a status of -ESHUTDOWN (disconnected from host),
the queue of videobuf2 should be cancelled to ensure that the
application space daemon is not left in a state waiting for
a vb2 to be successfully absorbed at the USB side.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Diffstat (limited to 'Documentation/i2c')
0 files changed, 0 insertions, 0 deletions