- 23 Apr, 2014 7 commits
-
-
Antti Palosaari authored
Add copyright and license for each file. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
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 30 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 <hans.verkuil@cisco.com> 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:
Sakari Ailus <sakari.ailus@linux.intel.com> 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:
Pawel Osciak <pawel@osciak.com> Acked-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:
-
Hans Verkuil authored
Add the new CEA-861-F and DMT 4K timings to the list of predefined timings. Signed-off-by:
-
Hans Verkuil authored
Add the CEA-861-F timings for 3840x2160p24/25/30/50/60 and 4096x2160p24/25/30/50/60. Signed-off-by:
-
Lad, Prabhakar authored
this patch releases the buffer by calling vb2_buffer_done(), with state marked as VB2_BUF_STATE_QUEUED if start_streaming() call back fails. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Lad, Prabhakar authored
Signed-off-by:
-
Mike Sampson authored
Signed-off-by:
Mike Sampson <mike@sambodata.com> Signed-off-by:
-
Lad, Prabhakar authored
This patch migrates the vpfe driver to use v4l2_fh for priority handling. Signed-off-by:
-
Lad, Prabhakar authored
This patch migrates the vpbe driver to use v4l2_fh for priority handling. This also fixes v4l2-compliance test. Signed-off-by:
-
Daniel Glöckner authored
This patch adds support for the PCI-8604PW card equipped with four 878A. It is unknown who the manufacturer of this card is and no drivers were available during development of the patch. According to images found online, the card is originally sold with Linux DVR software. A CPLD on the card prevents the 878A from requesting access to the bus until an initialization sequence has been issued via GPIOs. The implemented sequence uses the minimum number of GPIOs needed to successfully unlock bus access. As there are many more GPIOs connected to the CPLD, it is very likely that some of the others have an influence on the bus arbitration scheduling. This should be investigated further in case of performance issues. The tested card contains an EEPROM on one of the 878A, but it is completely empty (i.e. contains only 0xff), so it is not possible to detect the card. Signed-off-by:
Daniel Glöckner <daniel-gl@gmx.net> Tested-by:
Robert Longbottom <rongblor@googlemail.com> Signed-off-by:
-
Martin Bugge authored
In core_init make sure access to EDID DDC lines are disabled before chip is powered up. Also DISABLE_AUTO_EDID before power up. The correct setting is applied later when setting the EDID. Some sources (MAC) kept on reading EDID even when Hotplug was low and in the short period in core_init before the DDC lines was enabled read a corrupt EDID. Signed-off-by:
Martin Bugge <marbugge@cisco.com> Signed-off-by:
-
Martin Bugge authored
This was the reason for enabling the HDMI/DVI-D mode irq in the first place. Signed-off-by:
-
ileana@telecom-paristech.fr authored
Fix missing parentheses in macros Errors found by checkpatch.pl Signed-off-by:
Ioana Ileana <ileana@enst.fr> Signed-off-by:
-
Hans Verkuil authored
Fix the use of __user in the check_array_args() prototype: instead of using 'void * __user *' you should use 'void __user **' for sparse to understand this correctly. This also required the use of __force in the '*kernel_ptr = user_ptr' assignment. Also replace a wrong cast (void *) with the correct one (void **) in check_array_args(). This fixes these sparse warnings: drivers/media/v4l2-core/v4l2-ioctl.c:2284:35: warning: incorrect type in assignment (different address spaces) drivers/media/v4l2-core/v4l2-ioctl.c:2301:35: warning: incorrect type in assignment (different address spaces) drivers/media/v4l2-core/v4l2-ioctl.c:2319:35: warning: incorrect type in assignment (different address spaces) drivers/media/v4l2-core/v4l2-ioctl.c:2386:57: warning: incorrect type in argument 4 (different address spaces) drivers/media/v4l2-core/v4l2-ioctl.c:2420:29: warning: incorrect type in assignment (different address spaces) Signed-off-by:
-
Hans Verkuil authored
The edid array is copied to kernelspace by the v4l2 core, so drivers shouldn't see the __user annotation. This conforms to other structs like v4l2_ext_controls where the data pointed to is copied to from user to kernelspace. Signed-off-by:
-
Hans Verkuil authored
Sparse generated a bunch of errors like this: drivers/media/v4l2-core/videobuf2-core.c:2045:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:136:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:151:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:168:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:183:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:185:9: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:385:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1115:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1268:33: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1270:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1315:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1324:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1396:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1457:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1482:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1484:9: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1523:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1525:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1815:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1828:17: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1914:25: error: incompatible types in conditional expression (different base types) drivers/media/v4l2-core/videobuf2-core.c:1944:9: error: incompatible types in conditional expression (different base types) These are caused by the call*op defines which do something like this: (ops->op) ? ops->op(args) : 0 which is OK as long as op is not a void function, because in that case one part of the conditional expression returns void, the other an integer. Hence the sparse errors. I've replaced this by introducing three variants of the call_ macros: call_*op for int returns, call_void_*op for void returns and call_ptr_*op for pointer returns. That's the bad news. The good news is that the fail_*op macros could be removed since the call_*op macros now have enough information to determine if the op succeeded or not and can increment the op counter only on success. This at least makes it more robust w.r.t. future changes. Signed-off-by: -
Hans Verkuil authored
The notify function is a void function, yet the v4l2_subdev_notify define uses it in a ? : construction, which causes sparse warnings. Replace the define by a static inline function and move it to v4l2-device.h, which is where it belongs since it needs to know the v4l2_device struct. This wasn't a problem when it was a define, but as a static inline function this no longer compiles in v4l2-subdev.h. Signed-off-by:
-
Ismael Luceno authored
Signed-off-by:
Ismael Luceno <ismael.luceno@gmail.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 15 Apr, 2014 3 commits
-
-
Robert Butora authored
This patch does not modify existing drivers. It adds subdriver to gspca for DTCS033 (Scopium) webcam for astrophotography. The patch adds dtcs033.c and modifies Kconfig and Makefile. Signed-off-by:
Robert Butora <robert.butora.fi@gmail.com> Signed-off-by:
-
Jean Delvare authored
The sn9c102 driver is deprecated. It was moved to staging in anticipation of its removal in a future kernel version. However, USB devices 0C45:6024 and 0C45:6025 are still handled by sn9c102 when both sn9c102 and gspca_sonixb are enabled. We must migrate all the users of these devices to the gspca_sonixb driver now, so that it gets sufficient testing before the sn9c102 driver is finally phased out. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Lad, Prabhakar authored
this patch makes sure that it terminates if any IO in progress and also makes sure that all the buffers are unmapped. It was observed that with several runs of application the application sometimes failed to allocate memory, This patch makes sure it all the buffers are released. Using kmemleak it was found that buffer were not released, this patch fixes following issue, echo scan > /sys/kernel/debug/kmemleak Kernel message reads: memleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Then, cat /sys/kernel/debug/kmemleak unreferenced object 0xc564a480 (size 192): comm "mttest", pid 764, jiffies 4294945878 (age 487.160s) hex dump (first 32 bytes): 00 00 00 00 28 07 07 20 d0 02 00 00 e0 01 00 00 ....(.. ........ 00 00 00 00 00 64 05 00 01 00 00 00 01 00 00 00 .....d.......... backtrace: [<c00a98dc>] create_object+0x10c/0x28c [<c03ba8ec>] kmemleak_alloc+0x3c/0x70 [<c00a67c0>] __kmalloc+0x11c/0x1d4 [<c02b6f48>] __videobuf_alloc+0x1c/0x3c [<c02b6194>] videobuf_alloc_vb+0x38/0x80 [<c02b6638>] __videobuf_mmap_setup+0x9c/0x108 [<c02b6da0>] videobuf_reqbufs.part.10+0x12c/0x1bc [<c02b6e9c>] videobuf_reqbufs+0x6c/0x8c [<c02be2c4>] vpfe_reqbufs+0xcc/0x130 [<c02aae90>] v4l_reqbufs+0x50/0x54 [<c02aab54>] __video_do_ioctl+0x260/0x2c4 [<c02a9dd4>] video_usercopy+0xf0/0x310 [<c02aa008>] video_ioctl2+0x14/0x1c [<c02a562c>] v4l2_ioctl+0x104/0x14c [<c00bd320>] do_vfs_ioctl+0x80/0x2d0 [<c00bd5b4>] SyS_ioctl+0x44/0x64 unreferenced object 0xc564ac00 (size 192): comm "mttest", pid 764, jiffies 4294945878 (age 487.160s) hex dump (first 32 bytes): 01 00 00 00 28 07 07 20 d0 02 00 00 e0 01 00 00 ....(.. ........ 00 00 00 00 00 64 05 00 01 00 00 00 01 00 00 00 .....d.......... backtrace: [<c00a98dc>] create_object+0x10c/0x28c [<c03ba8ec>] kmemleak_alloc+0x3c/0x70 [<c00a67c0>] __kmalloc+0x11c/0x1d4 [<c02b6f48>] __videobuf_alloc+0x1c/0x3c [<c02b6194>] videobuf_alloc_vb+0x38/0x80 [<c02b6638>] __videobuf_mmap_setup+0x9c/0x108 [<c02b6da0>] videobuf_reqbufs.part.10+0x12c/0x1bc [<c02b6e9c>] videobuf_reqbufs+0x6c/0x8c [<c02be2c4>] vpfe_reqbufs+0xcc/0x130 [<c02aae90>] v4l_reqbufs+0x50/0x54 [<c02aab54>] __video_do_ioctl+0x260/0x2c4 [<c02a9dd4>] video_usercopy+0xf0/0x310 [<c02aa008>] video_ioctl2+0x14/0x1c [<c02a562c>] v4l2_ioctl+0x104/0x14c [<c00bd320>] do_vfs_ioctl+0x80/0x2d0 [<c00bd5b4>] SyS_ioctl+0x44/0x64 unreferenced object 0xc564a180 (size 192): comm "mttest", pid 764, jiffies 4294945880 (age 487.140s) hex dump (first 32 bytes): 02 00 00 00 28 07 07 20 d0 02 00 00 e0 01 00 00 ....(.. ........ 00 00 00 00 00 64 05 00 01 00 00 00 01 00 00 00 .....d.......... backtrace: [<c00a98dc>] create_object+0x10c/0x28c [<c03ba8ec>] kmemleak_alloc+0x3c/0x70 [<c00a67c0>] __kmalloc+0x11c/0x1d4 [<c02b6f48>] __videobuf_alloc+0x1c/0x3c [<c02b6194>] videobuf_alloc_vb+0x38/0x80 [<c02b6638>] __videobuf_mmap_setup+0x9c/0x108 [<c02b6da0>] videobuf_reqbufs.part.10+0x12c/0x1bc [<c02b6e9c>] videobuf_reqbufs+0x6c/0x8c [<c02be2c4>] vpfe_reqbufs+0xcc/0x130 [<c02aae90>] v4l_reqbufs+0x50/0x54 [<c02aab54>] __video_do_ioctl+0x260/0x2c4 [<c02a9dd4>] video_usercopy+0xf0/0x310 [<c02aa008>] video_ioctl2+0x14/0x1c [<c02a562c>] v4l2_ioctl+0x104/0x14c [<c00bd320>] do_vfs_ioctl+0x80/0x2d0 [<c00bd5b4>] SyS_ioctl+0x44/0x64 Reported-by:Jimmy Ho <jimmygge@gmail.com> Signed-off-by:
-
