In the past the transfer function was implied by the colorspace. However,
it is an independent entity in its own right. Add support for explicitly
choosing the transfer function.
This change will allow us to represent linear RGB (as is used by openGL), and
it will make it easier to work with decoded video material since most codecs
store the transfer function as a separate property as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Instead of using a state machine and a switch with lots of
fall-trough, use gotos and cleanup the error handling loop.
That removes those two smatch warnings:
drivers/staging/media/lirc/lirc_imon.c:933 imon_probe() warn: possible memory leak of 'context'
drivers/staging/media/lirc/lirc_imon.c:933 imon_probe() warn: possible memory leak of 'driver'
And make the error handling code more standard.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
There's a dead code on usbvision that makes it harder to read
and produces a smatch warning about bad identation.
Improve the code readability and add a FIXME to warn about
the current hack there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Smatch reports a warning:
drivers/media/usb/tm6000/tm6000-video.c:646 tm6000_prepare_isoc() error: we previously assumed 'dev->urb_buffer' could be null (see line 624)
This is not really a problem, but it actually shows that the check
if urb_buffer is NULL is being done twice: at the if and at
tm6000_alloc_urb_buffers().
We don't need to do it twice. So, remove the extra check. The code
become cleaner, and, as a collateral effect, smatch becomes happy.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Smatch currently produces two warnings:
drivers/media/pci/ivtv/ivtv-fileops.c:901 ivtv_v4l2_close() warn: suspicious bitop condition
drivers/media/pci/ivtv/ivtv-fileops.c:1026 ivtv_open() warn: suspicious bitop condition
Those are false positives, but it is not hard to get rid of them by
using a different way to evaluate the macro, splitting the logical
boolean evaluation from the bitmap one.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
As reported by smatch:
drivers/media/pci/bt8xx/dst_ca.c:323 ca_get_message() warn: this array is probably non-NULL. 'p_ca_message->msg'
drivers/media/pci/bt8xx/dst_ca.c:498 ca_send_message() warn: this array is probably non-NULL. 'p_ca_message->msg'
Those two checks are needless/useless, as the ca_msg struct is
declared as:
typedef struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
So, if the p_ca_message pointer is not null, msg will also be
not null.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
As reported by smatch:
drivers/media/dvb-frontends/dib0090.c:1710 dib0090_dc_offset_calibration() warn: missing break? reassigning '*tune_state'
There's no need to change tune_state there, as the fall though code
will change it again to another state. So, simplify it by
removing the dead code.
While here, fix a typo:
Sart => Start
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Smatch reports two issues:
drivers/media/platform/sh_vou.c:670 vou_adjust_output() error: buffer overflow 'vou_scale_v_num' 3 <= 4
drivers/media/platform/sh_vou.c:670 vou_adjust_output() error: buffer overflow 'vou_scale_v_den' 3 <= 4
It seems that there's actually a bug here: the same var (idx) is used
as an index for vertical and horizontal scaling arrays. However,
there are 4 elements on the h arrays, and only 3 at the v ones.
On the first loop, it may select index 4 for the horizontal array.
In this case, if the second loop fails to select an index, the
code would keep using 4 for the vertical array, with is past of
the array sizes.
The intent here seems to use index 0, if the scale is not found.
So, use a separate var for the vertical index.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
As reported by smatch:
drivers/media/dvb-frontends/drxk_hard.c:3277 dvbt_sc_command() warn: missing break? reassigning 'status'
This is basically because the error handling logic there was crappy.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Remove the following compilation warnings:
drivers/media/platform/vivid/vivid-tpg.c: In function 'tpg_gen_text':
drivers/media/platform/vivid/vivid-tpg.c:1562:1: warning: the frame size of 1308 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
This seems to be due to some bad optimization done by gcc.
Moving the for() loop to happen inside the macro solves the
issue.
While here, fix CodingStyle at the switch().
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Commits a0f10c131c and
6c9fe76536 ("media: s5p-mfc: fix broken
pointer cast on 64bit arch") fixed issue with lossy cast on 64-bit
architectures. However it also removed __iomem attribute from that cast.
This leads to sparse warnings. This patch fixes those warnings by adding
__iomem cast in case of v6+ code version and replacing readl/writel by
simple u32 load/store operations in case of v5 code (which is called on
system memory allocated by dma_alloc_coherent() instead of io registers).
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
V4L2 drivers should use MONOTONIC timestamps instead of gettimeofday,
which is affected by daylight savings time.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
this patch sets nbuffers to three or more and drops the
unset member video_limit which just a copy paste from
earlier driver.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
clear of the output_specs before passing it to the
configure_resizer_out_params(), so that no garbage values
are set.
This fixes following build warning:
drivers/staging/media/davinci_vpfe/dm365_resizer.c: In function 'resizer_set_stream':
drivers/staging/media/davinci_vpfe/dm365_resizer.c:190:46: warning: 'output_specs.vst_c'
may be used uninitialized in this function [-Wmaybe-uninitialized]
param->ext_mem_param[index].rsz_sdr_ptr_s_c = output->vst_c;
^
drivers/staging/media/davinci_vpfe/dm365_resizer.c:316:30: note: 'output_specs.vst_c' was declared here
struct vpfe_rsz_output_spec output_specs;
^
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We need own I2C locking because of tuner I2C adapter/repeater.
Firmware command is executed using I2C send + reply message. Default
I2C adapter locking protects only single I2C operation, not whole
send + reply sequence as needed. Due to that, it was possible tuner
I2C message interrupts firmware command sequence.
Reported-by: Adam Baker <linux@baker-net.org.uk>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Adam Baker <linux@baker-net.org.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The changeset dc9ef7d112 change the open() ioctl documentation to
match the V4L2 open(). However, some cut-and-pasted stuff doesn't
match what actually happens at the DVB core.
So, fix the documentation entry to be more accurate with the DVB
frontend open() specifics.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To fix the last xmllint errors the open and close function reference
description was rewritten based on the v4l2 open and close functions.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Hans Verkuil
Mauro Carvalho Chehab
Marek Szyprowski
Lad, Prabhakar
Antti Palosaari