summaryrefslogtreecommitdiff
path: root/drivers/media/video/omap1_camera.c
diff options
context:
space:
mode:
authorAlberto Panizzo <maramaopercheseimorto@gmail.com>2011-01-17 09:52:10 (GMT)
committerMauro Carvalho Chehab <mchehab@redhat.com>2011-03-21 23:32:14 (GMT)
commita48be1d626ceb05b58a980a962214431af8041e8 (patch)
treeba83dcc99d9884dfbc4f731aeed61f7985f00728 /drivers/media/video/omap1_camera.c
parent44facdc8c43a8b5172d6cbe995845c9889561aa0 (diff)
downloadlinux-a48be1d626ceb05b58a980a962214431af8041e8.tar.xz
[media] V4L: mx3_camera: fix capture issues for non 8-bit per pixel formats
If the camera was set to output formats like RGB565 YUYV or SBGGR10, the resulting image was scrambled due to erroneous interpretations of horizontal parameter's units. This patch in fourcc_to_ipu_pix, eliminate also the pixel formats mappings that, first are not used within mainline code and second, standing at the datasheets, they will not work properly: The IPU internal bus support only the following data formatting (44.1.1.3 Data Flows and Formats): 1 YUV 4:4:4 or RGB-8 bits per color component 2 YUV 4:4:4 or RGB-10 bits per color component 3 Generic data (from sensor to the system memory only) And format conversions are done: - from memory: unpacking from other formats to IPU supported ones - to memory: packing in the inverse order. So, assigning a packing/unpacking strategy to the IPU for those formats will produce a packing to memory and not the inverse. Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers/media/video/omap1_camera.c')
0 files changed, 0 insertions, 0 deletions