Hans Verkuil [Thu, 17 Jul 2014 22:24:33 +0000 (19:24 -0300)]
[media] DocBook media: fix incorrect note about packed RGB and colorspace
The fact that the pixelformat is using a packed RGB format has nothing
to do with the colorspace that is being used. Those are very different
things. The colorspace decides what color a triplet of RGB numbers
actually map to. E.g. a red color with values (255, 0, 0) is a different
type of red depending on the colorspace. If the original pixelformat was
e.g. YUV in colorspace REC709, then after the conversion to RGB the
colorspace is still REC709. Unless the hardware actually converted the
colorspace as well from REC709 to sRGB, but that rarely if ever happens.
Remove this incorrect comment.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Hans Verkuil [Thu, 17 Jul 2014 09:53:08 +0000 (06:53 -0300)]
[media] vb2: fix bytesused == 0 handling
The original report from Nikhil was that if data_offset > 0 and bytesused == 0,
then the check in __verify_length() would fail, even though the spec says that
if bytes_used == 0, then it will be replaced by the actual length of the
buffer.
After digging into it a bit more I realized that there were several other
things wrong:
- in __verify_length() it would use the application-provided length value
for USERPTR and the vb2 core length for other memory models, but it
should have used the application-provided length as well for DMABUF.
- in __fill_vb2_buffer() on the other hand it would replace bytesused == 0
by the application-provided length, even for MMAP buffers where the
length is determined by the vb2 core.
- in __fill_vb2_buffer() it tries to figure out if all the planes have
bytesused == 0 before it will decide to replace bytesused by length.
However, the spec makes no such provision, and it makes for convoluted
code. So just replace any bytesused == 0 by the proper length.
The idea behind this was that you could use bytesused to signal empty
planes, something that is currently not supported. But that is better
done in the future by using one of the reserved fields in strucy v4l2_plane.
Antti Palosaari [Fri, 18 Jul 2014 23:56:01 +0000 (20:56 -0300)]
[media] msi2500: fill FMT buffer size
Fill FMT buffer size field in order to inform app which will be
used streaming buffer size. Currently driver doesn't allow buffer
size value proposed by application.
Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Antti Palosaari [Sat, 19 Jul 2014 00:22:08 +0000 (21:22 -0300)]
[media] airspy: fill FMT buffer size
Fill FMT buffer size field in order to inform app which will be
used streaming buffer size. Currently driver doesn't allow buffer
size value proposed by application.
Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Antti Palosaari [Fri, 18 Jul 2014 19:22:29 +0000 (16:22 -0300)]
[media] rtl2832_sdr: fill FMT buffer size
Fill FMT buffer size field in order to inform app which will be
used streaming buffer size. Currently driver doesn't allow buffer
size value proposed by application.
Signed-off-by: Antti Palosaari <crope@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Olli Salonen [Fri, 18 Jul 2014 05:41:12 +0000 (02:41 -0300)]
[media] si2157: Use name si2157_ops instead of si2157_tuner_ops
The struct prototype is defined at the beginning of the code as
"si2157_ops" but the real struct is called "si2157_tuner_ops".
This is causing the name to be empty on this info msg: si2157 16-0060:
si2157: found a '' in cold state
[crope@iki.fi: commit msg from Luis email reply] Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Cc: Luis Alves <ljalvs@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Antti Palosaari [Fri, 18 Jul 2014 00:47:48 +0000 (21:47 -0300)]
[media] airspy: print notice to point SDR API is not 100% stable yet
Print notice on driver load: "SDR API is still slightly
experimental and functionality changes may follow". It is just
remind possible used SDR API is very new and surprises may occur.
Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
drivers/staging/media/airspy/airspy.c: In function 'airspy_stop_streaming':
drivers/staging/media/airspy/airspy.c:569:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^
Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Sakari Ailus [Thu, 12 Jun 2014 16:09:42 +0000 (13:09 -0300)]
[media] v4l: ctrls: Unlocked variants of v4l2_ctrl_s_ctrl{,_int64}()
Implement unlocked variants of v4l2_ctrl_s_ctrl() and
v4l2_ctrl_s_ctrl_int64(). As drivers need to set controls as they access
driver internal state elsewhere than in the control framework unlocked
variants of these functions become handy.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Sakari Ailus [Thu, 12 Jun 2014 16:09:40 +0000 (13:09 -0300)]
[media] v4l: ctrls: Provide an unlocked variant of v4l2_ctrl_modify_range()
Drivers may use the v4l2_ctrl_modify_range() internally as part of other
operations that need to be both serialised using a driver's lock which can
also be used to serialise access to the control handler. Provide an unlocked
version of the function, __v4l2_ctrl_modify_range() which then may be used
by drivers for the purpose.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Hans Verkuil [Thu, 17 Jul 2014 18:27:39 +0000 (15:27 -0300)]
[media] saa7146: fix compile warning
Fall-out from the recent struct v4l2_framebuffer change.
drivers/media/common/saa7146/saa7146_fops.c: In function ‘saa7146_vv_init’:
drivers/media/common/saa7146/saa7146_fops.c:536:6: warning: assignment from incompatible pointer type [enabled by default]
fmt = &vv->ov_fb.fmt;
^
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[linux-3.16-rc5/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:210]:
(style) Checking if unsigned variable 'val' is less than zero.
val = get_oneshot_mode(ipipeif->input);
if (val < 0) {
pr_err("ipipeif: links setup required");
return -EINVAL;
}
but
static int get_oneshot_mode(enum ipipeif_input_entity input)
Introduced temporary variable for negativity check.
"val" is afterwards used in a lot of bitwise operations, so changing its type
to signed is not safe, according to CERT C Secure Coding Standards chapter
INT13-C: "Use bitwise operators only on unsigned operands"
https://www.securecoding.cert.org/confluence/display/seccode/INT13-C.+Use+bitwise+operators+only+on+unsigned+operands
Philipp Zabel [Fri, 11 Jul 2014 09:36:16 +0000 (06:36 -0300)]
[media] coda: simplify IRAM setup
OVL and BTP IRAM buffers are never used, setup the bits for
for DBK/BIT/IP usage depending on CODA version in one place.
Also, use a simple allocator function and group IRAM addresses
and size in a coda_aux_buf structure.
This is done in preparation for CODA960 support.
Philipp Zabel [Fri, 11 Jul 2014 09:36:14 +0000 (06:36 -0300)]
[media] coda: fix h.264 quantization parameter range
If bitrate is not set, the encoder is running in VBR mode, with the
I- and P-frame quantization parameters configured from userspace.
For the quantization parameters, 0 is a valid value.
Philipp Zabel [Fri, 11 Jul 2014 09:36:12 +0000 (06:36 -0300)]
[media] coda: fix decoder I/P/B frame detection
Currently the rotator unit is used to copy decoded frames out into buffers
provided by videobuf2. Since the CODA reports the I/P/B frame type of the
last decoded frame, and this frame will be copied out in a later device_run,
depending on display order, we have to store the frame type until such time.
This patch also adds the B-frame type.
Jacek Anaszewski [Thu, 10 Jul 2014 09:00:39 +0000 (06:00 -0300)]
[media] s5p-mfc: Fix selective sclk_mfc init
fc906b6d "Remove special clock usage in driver" removed
initialization of MFC special clock, arguing that there's
no need to do it explicitly, since it's one of MFC gate clock's
dependencies and gets enabled along with it. However, there's
no promise of keeping this hierarchy across Exynos SoC
releases, therefore this approach fails to provide a stable,
portable solution.
Out of all MFC versions, only v6 doesn't use special clock at all.
For other versions log a message only in case clk_get fails,
as not all the devices with the same MFC version require
initializing the clock explicitly.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
This patch removes the null test on dvb. dvb is initialized at the
beginning of the function to &port->dvb. Since port is dereferenced
prior to the null test, port must be a valid pointer, and
&port->dvb cannot be null.
The following Coccinelle script is used for detecting the change:
WARNING: Missing a blank line after declarations
2245: FILE: radio-bcm2048.c:2245:
+ unsigned char tmpbuf[3];
+ tmpbuf[i] = bdev->rds_info.radio_text[bdev->rd_index+i+2];
WARNING: Possible unnecessary 'out of memory' message
2601: FILE: radio-bcm2048.c:2601:
+ if (!bdev) {
+ dev_dbg(&client->dev, "Failed to alloc video device.\n");
The following error was left since it seems to be a false positive:
ERROR: Macros with complex values should be enclosed in parenthesis
+#define DEFINE_SYSFS_PROPERTY(prop, signal, size, mask, check) \
+property_write(prop, signal size, mask, check) \
+property_read(prop, size, mask)
Signed-off-by: Luke Hart <luke.hart@birchleys.eu> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The issue was discovered by static analysis. It turns out that code is
somewhat insane, being
if (x) {...} else { if (x) {...} }
Edited it to do the only reasonable thing, which is to log the
information about the failed call. The most descriptive logging commands
set is taken from original code.
Hans Verkuil [Fri, 13 Jun 2014 07:31:06 +0000 (04:31 -0300)]
[media] v4l2-ioctl: call g_selection before calling cropcap
If the vidioc_cropcap op is implemented by the driver then the v4l2
core will call that directly.
If g_selection is available, then the core cropcap implementation
uses g_selection to fill in the bounds and defrect and it sets the
pixelaspect to 1x1.
But if both are available, then I would like to use g_selection to
fill in defrect and bounds before calling cropcap. That way the
driver's cropcap implementation doesn't have to set defrect or
bounds.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Hans Verkuil [Thu, 10 Jul 2014 22:51:26 +0000 (19:51 -0300)]
[media] v4l2-dev: streamon/off is only a valid ioctl for video, vbi and sdr
The VIDIOC_STREAMON/OFF ioctls are not valid for radio devices, just
like the other streaming I/O ioctls. Add the streamon/off ioctls
to the other streaming I/O ioctls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
If the driver supports enum_freq_bands, but only for certain device
nodes, then it may return -ENOTTY. But in that case the code should
fall into the fall-back case where the current tuner/modulator range
is returned.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Hans Verkuil [Sat, 12 Jul 2014 10:54:26 +0000 (07:54 -0300)]
[media] v4l2-ioctl.c: check vfl_type in ENUM_FMT
The other format ioctls (g/s/try_fmt) all check if the passed buffer type
makes sense for the device node's vfl_type. E.g. it makes no sense for a
VBI buffer type to be passed through a video node instead of a vbi node.
But this check was missing in ENUM_FMT which can cause a problem if you
have both video and sdr device nodes.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l: omap4iss: Signal fatal errors to the vb2 queue
When a fatal error occurs in the pipeline signal it to the vb2 queue
with a call to vb2_queue_error(). The queue will then take care to
return -EIO when preparing buffers, remove the driver-specific code that
now duplicates that check.
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into "tristate",
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.
When a fatal error occurs that render the device unusable, the only
options for a driver to signal the error condition to userspace is to
set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an
error from the buffer prepare handler when queuing buffers.
The buffer error flag indicates a transient error and can't be used by
applications to detect fatal errors. Returning an error from vb2_qbuf()
is thus the only real indication that a fatal error occurred. However,
this is difficult to handle for multithreaded applications that requeue
buffers from a thread other than the control thread. In particular the
poll() call in the control thread will not notify userspace of the
error.
This patch adds an explicit mechanism to report fatal errors to
userspace. Drivers can call the vb2_queue_error() function to signal a
fatal error. From this moment on, buffer preparation will return -EIO to
userspace, and vb2_poll() will set the POLLERR flag and return
immediately. The error flag is cleared when cancelling the queue, either
at stream off time (through vb2_streamoff) or when releasing the queue
with vb2_queue_release().
[media] v4l: vb2: Don't return POLLERR during transient buffer underruns
The V4L2 specification states that
"When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet
the poll() function succeeds, but sets the POLLERR flag in the revents
field."
The vb2_poll() function sets POLLERR when the queued buffers list is
empty, regardless of whether this is caused by the stream not being
active yet, or by a transient buffer underrun.
Bring the implementation in line with the specification by returning
POLLERR if no buffer has been queued only when the queue is not
streaming. Buffer underruns during streaming are not treated specially
anymore and just result in poll() blocking until the next event.
Laurent Pinchart [Sat, 31 May 2014 00:45:48 +0000 (21:45 -0300)]
[media] v4l: vsp1: uds: Fix scaling of alpha layer
Pixel color components can be scaled using either bilinear interpolation
or a multitap filter. The multitap filter provides better results, but
can't be selected when the alpha layer need to be scaled down by more
than 1/2.
Disable alpha scaling when the input has a fixed alpha value, and
program the UDS to output a fixed alpha value in that case. This ensures
the multitap filter will be used whenever possible.
Laurent Pinchart [Tue, 27 May 2014 23:35:36 +0000 (20:35 -0300)]
[media] v4l: vsp1: bru: Support premultiplied alpha at the BRU inputs
Adjust the BRU blending formula to avoid the multiplication by alpha
when the corresponding input format is premultiplied. As this requires
access to the RPFs connected to the BRU inputs from the BRU module,
store pointers to the RPFs in the BRU structure when validating the
pipeline.
Laurent Pinchart [Mon, 26 May 2014 22:57:21 +0000 (19:57 -0300)]
[media] v4l: vsp1: Switch to XRGB formats
The driver ignores the alpha component on output video nodes and
hardcodes the alpha component to 0 on capture video nodes. Make this
explicit by exposing XRGB formats.
Compatibility with existing userspace applications is handled by
selecting the XRGB format corresponding to the requested old RGB format.
Laurent Pinchart [Wed, 28 May 2014 16:10:33 +0000 (13:10 -0300)]
[media] v4l: vsp1: wpf: Clear RPF to WPF association at stream off time
The VSP1 stores the video pipelines' input (RPF) to output (WPF)
mappings in a WPF register. An RPF must never be associated with
multiple WPFs, even if all of those WPFs but one are unused, otherwise
the hardware won't function properly.
The driver doesn't ensure this correctly as it never clears the
mappings. An RPF used with one WPF and later with a different WPF will
lead to malfunction, as it will be associated with two WPFs. Clear the
mappings at stream off time to fix this.
Laurent Pinchart [Sat, 31 May 2014 23:30:11 +0000 (20:30 -0300)]
[media] v4l: vsp1: sru: Make the intensity controllable during streaming
The control value is currently stored in the SRU structure by the
control set handler and written to the hardware at stream on time,
making control set during streaming ineffective. Fix it by writing to
the registers from within the control set handler.
Laurent Pinchart [Sat, 31 May 2014 13:40:51 +0000 (10:40 -0300)]
[media] v4l: vsp1: Setup control handler automatically at stream on time
When setting a control directly on a subdev node the VSP1 driver doesn't
guarantee that the device is powered on. This leads to crashes when the
control handlers writes to hardware registers. One easy way to fix this
is to ensure that the device gets powered on when a subdev node is
opened. However, this consumes power unnecessarily, as there's no need
to power the device on when setting formats on the pipeline.
Furthermore, control handler setup at entity init time suffers from the
same problem as the device isn't powered on easier.
Fix this by extend the entity base object to setup the control handler
automatically when starting the stream. Entities must then skip writing
to registers in the set control handler when not streaming, which can be
tested with the new vsp1_entity_is_streaming() helper function.