- 23 Apr, 2014 26 commits
-
-
Sakari Ailus authored
Add a quirk for diverting registers for on some sensors, even the standard registers are not where they can be expected to be found. Add a quirk to to help using such sensors. smiapp_write_no_quirk() and smiapp_read_no_quirk() functions are provided for the use of quirk implementations. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Sakari Ailus authored
This is more flexible. Quirk flags may be affected by configuration. Signed-off-by:
-
Sakari Ailus authored
No reason to keep this u8, really. Signed-off-by:
-
Sakari Ailus authored
It doesn't make sense to just copy the information to the PLL flags. Add a new fields for the quirks to contain the PLL flags. Signed-off-by:
-
Sakari Ailus authored
The sub-device names should be unique. Should two identical sensors be present in the same media device they would be indistinguishable. The names will change e.g. from "vs6555 pixel array" to "vs6555 1-0010 pixel array". Signed-off-by:
-
Sakari Ailus authored
Signed-off-by:
-
Sakari Ailus authored
8-bit reads are needed in some cases; however the condition used was wrong. Regular access (register width) was used if: len == SMIAPP_REG_8BIT && !only8 This causes 8-bit read access to be used always. The operator should be || instead: regular access can be used for 8-bit reads OR if allowed otherwise. Signed-off-by:
-
Sakari Ailus authored
SMIAPP_REG_ is the common prefix used in the driver for register related definitions. Use it consistently. Signed-off-by:
-
Sakari Ailus authored
The quirk registers mechanism which allows register to have a static read access value from the sensor specific quirks, is not used. Remove it. It is to be replaced by a more generic register diversion quirk soon. Signed-off-by:
-
Hans Verkuil authored
When compiling this for older kernels using the compatibility build the compiler complains about uninitialized variables: In file included from include/linux/kernel.h:20:0, from include/linux/cache.h:4, from include/linux/time.h:7, from include/linux/input.h:13, from /home/hans/work/build/media_build/v4l/compat.h:9, from <command-line>:0: /home/hans/work/build/media_build/v4l/videobuf2-core.c: In function 'vb2_mmap': include/linux/dynamic_debug.h:60:9: warning: 'plane' may be used uninitialized in this function [-Wmaybe-uninitialized] printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \ ^ /home/hans/work/build/media_build/v4l/videobuf2-core.c:2381:23: note: 'plane' was declared here unsigned int buffer, plane; ^ In file included from include/linux/kernel.h:20:0, from include/linux/cache.h:4, from include/linux/time.h:7, from include/linux/input.h:13, from /home/hans/work/build/media_build/v4l/compat.h:9, from <command-line>:0: include/linux/dynamic_debug.h:60:9: warning: 'buffer' may be used uninitialized in this function [-Wmaybe-uninitialized] printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \ ^ /home/hans/work/build/media_build/v4l/videobuf2-core.c:2381:15: note: 'buffer' was declared here unsigned int buffer, plane; ^ While these warnings are bogus (the call to __find_plane_by_offset will set buffer and plane), it doesn't hurt to initialize these variables. Signed-off-by:Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
The stop_streaming op is only called if streaming is in progress, so drop the unnecessary 'if (!vb2_is_streaming(vq))' check. Signed-off-by:
Pawel Osciak <pawel@osciak.com> Acked-by:
-
Hans Verkuil authored
The vb2 core ignores any return code from the stop_streaming op. And there really isn't anything it can do anyway in case of an error. So change the return type to void and update any drivers that implement it. The int return gave drivers the idea that this operation could actually fail, but that's really not the case. The pwc amd sdr-msi3101 drivers both had this construction: if (mutex_lock_interruptible(&s->v4l2_lock)) return -ERESTARTSYS; This has been updated to just call mutex_lock(). The stop_streaming op expects this to really stop streaming and I very much doubt this will work reliably if stop_streaming just returns without really stopping the DMA. Signed-off-by: -
Robert Butora authored
Warnings due to __le16 / u16 conversions. Replace offending struct and so stay on cpu domain. Signed-off-by:
Robert Butora <robert.butora.fi@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Two new devices were added, but the cardlists weren't updated. Signed-off-by: -
Antti Palosaari authored
External LNA between antenna connector and RF tuner is controlled by EM28178 GPIO 0. GPIO value 1 is LNA active and value 0 is LNA disabled. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
bit3 was not cleared always leaving driver reporting demod is not fully locked. Do not check bit0 as it seems to be always 0. Signed-off-by:
-
Antti Palosaari authored
Silicon Labs Si2157 silicon tuner driver. Signed-off-by:
-
Antti Palosaari authored
Silicon Labs Si2168 DVB-T/T2/C demod driver Signed-off-by:
-
Antti Palosaari authored
Add copyright and license for each file. Signed-off-by:
-
Antti Palosaari authored
Add copyright and license for each file. Signed-off-by:
-
Antti Palosaari authored
Add support for DVB-C (annex A version). Signed-off-by:
-
Antti Palosaari authored
DVB-C uses lower frequencies than DVB-T. Extend frequency range down to 110 MHz in order to support DVB-C. 110 - 862 MHz range is defined by NorDig Unified 2.2 specification. Signed-off-by:
-
Antti Palosaari authored
Add support for DVB-T2. Signed-off-by:
-
Antti Palosaari authored
Empia EM28178, Silicon Labs Si2168, Silicon Labs Si2157. Signed-off-by:
-
Antti Palosaari authored
Silicon Labs Si2168 DVB-T/T2/C demod driver. That driver version supports only DVB-T. Signed-off-by:
-
Antti Palosaari authored
Silicon Labs Si2157 silicon tuner driver. Currently it supports only DVB-T. Signed-off-by:
-
- 16 Apr, 2014 14 commits
-
-
Hans Verkuil authored
With the new vb2_thread_start/stop core code it is very easy to implement videobuf2-dvb. This should simplify converting existing videobuf drivers to vb2. Signed-off-by:
-
Hans Verkuil authored
In order to implement vb2 DVB support you need to be able to start a kernel thread that queues and dequeues buffers, calling a callback function for every buffer. This patch adds support for that. It's based on drivers/media/v4l2-core/videobuf-dvb.c, but with all the DVB specific stuff stripped out, thus making it much more generic. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
For interlaced HDTV timings the correct field setting is FIELD_ALTERNATE, not INTERLACED. Update this template driver accordingly: - add check for the invalid combination of read() and FIELD_ALTERNATE. - in the interrupt handler set v4l2_buffer field to alternating TOP and BOTTOM. Signed-off-by:
-
Hans Verkuil authored
For output buffers the application has to set the bytesused field. In reality applications often do not set this since drivers that deal with fix image sizes just override it anyway. The vb2 framework will replace this field with the length field if bytesused was set to 0 by the application, which is what happens in practice. Document this behavior. Signed-off-by:
-
Hans Verkuil authored
The kernel debug messages produced by vb2 started either with a lower or an upper case character. Switched all to use lower-case which seemed to be what was used in the majority of the messages. Signed-off-by:
-
Hans Verkuil authored
It was impossible to read() or write() a frame if the queue type was multiplanar. Even if the current format is single planar. Change this to just check whether the number of planes is 1 or more. Signed-off-by:
-
Hans Verkuil authored
Added a vb2_fileio_is_active inline function that returns true if fileio is in progress. Check for this too in mmap() (you don't want apps mmap()ing buffers used by fileio) and expbuf() (same reason). In addition drivers should be able to check for this in queue_setup() to return an error if an attempt is made to read() or write() with V4L2_FIELD_ALTERNATE being configured. This is illegal (there is no way to pass the TOP/BOTTOM information around using file I/O). However, in order to be able to check for this the init_fileio function needs to set q->fileio early on, before the buffers are allocated. So switch to using internal functions (__reqbufs, vb2_internal_qbuf and vb2_internal_streamon) to skip the fileio check. Well, that's why the internal functions were created... Signed-off-by:
-
Hans Verkuil authored
q->start_streaming_called is always true, so the WARN_ON check against it being false can be dropped. Signed-off-by:
-
Hans Verkuil authored
This is not allowed by the spec and does in fact not make any sense. Return -EINVAL if this is the case. Signed-off-by:
-
Hans Verkuil authored
When using write() to write data to an output video node the vb2 core should set timestamps if V4L2_BUF_FLAG_TIMESTAMP_COPY is set. Nobody else is able to provide this information with the write() operation. Signed-off-by:
-
Hans Verkuil authored
__qbuf_mmap was sort of hidden in between the much larger __qbuf_userptr and __qbuf_dmabuf functions. Move it before __qbuf_userptr which is also conform the usual order these memory models are implemented: first mmap, then userptr, then dmabuf. Signed-off-by:
-
Hans Verkuil authored
Many dprintk's in vb2 use a hardcoded prefix with the function name. In many cases that is now outdated. To keep things consistent the dprintk macro has been changed to print the function name in addition to the "vb2:" prefix. Superfluous prefixes elsewhere in the code have been removed. Signed-off-by:
-
Hans Verkuil authored
The application should really always fill in bytesused for output buffers, unfortunately the vb2 framework never checked for that. So for single planar formats replace a bytesused of 0 by the length of the buffer, and for multiplanar format do the same if bytesused is 0 for ALL planes. This seems to be what the user really intended if v4l2_buffer was just memset to 0. I'm afraid that just checking for this and returning an error would break too many applications. Quite a few drivers never check for bytesused at all and just use the buffer length instead. Signed-off-by:
-
Hans Verkuil authored
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:
-
