diff options
author | Hans Verkuil <hans.verkuil@cisco.com> | 2014-04-07 11:44:56 (GMT) |
---|---|---|
committer | Mauro Carvalho Chehab <m.chehab@samsung.com> | 2014-04-16 21:41:36 (GMT) |
commit | 412376a1532a9eb3eb66c9d07175f21cdbebdc09 (patch) | |
tree | f9ad6194c430b6f412d2f148171d9649a3ad979e /arch/xtensa | |
parent | bc96f30c3b96ccb0b9bc0f79d1538cba75e501a9 (diff) | |
download | linux-412376a1532a9eb3eb66c9d07175f21cdbebdc09.tar.xz |
[media] vb2: fix handling of data_offset and v4l2_plane.reserved[]
The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
array in struct v4l2_plane would be non-zero, causing v4l2-compliance
errors.
More serious is the fact that data_offset was not handled correctly:
- for capture devices it was never zeroed, which meant that it was
uninitialized. Unless the driver sets it it was a completely random
number. With the memset above this is now fixed.
- __qbuf_dmabuf had a completely incorrect length check that included
data_offset.
- in __fill_vb2_buffer in the DMABUF case the data_offset field was
unconditionally copied from v4l2_buffer to v4l2_plane when this
should only happen in the output case.
- in the single-planar case data_offset was never correctly set to 0.
The single-planar API doesn't support data_offset, so setting it
to 0 is the right thing to do. This too is now solved by the memset.
All these issues were found with v4l2-compliance.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Diffstat (limited to 'arch/xtensa')
0 files changed, 0 insertions, 0 deletions