summaryrefslogtreecommitdiff
path: root/arch/xtensa
diff options
context:
space:
mode:
authorHans Verkuil <hans.verkuil@cisco.com>2014-04-07 11:44:56 (GMT)
committerMauro Carvalho Chehab <m.chehab@samsung.com>2014-04-16 21:41:36 (GMT)
commit412376a1532a9eb3eb66c9d07175f21cdbebdc09 (patch)
treef9ad6194c430b6f412d2f148171d9649a3ad979e /arch/xtensa
parentbc96f30c3b96ccb0b9bc0f79d1538cba75e501a9 (diff)
downloadlinux-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