- 11 Aug, 2015 36 commits
-
-
Antti Palosaari authored
Devices that were using a8293 SEC are converted to I2C platform data thus that old config structure is left unused. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Hans Verkuil authored
The zoran driver has now been converted to the control framework which means that these three subdevice drivers no longer need to support the legacy core control ops since the last bridge driver that needed that has now been converted. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
Switch this driver to the control framework and to v4l2_fh for handling control events. Signed-off-by:
-
Hans Verkuil authored
Use the standard core lock to take care of serializing ioctl calls and to serialize file operations. Signed-off-by:
-
Hans Verkuil authored
The zoran_read/write functions always return an error. Just remove them. Signed-off-by:
-
Hans Verkuil authored
There is no need to zero the v4l2_capability struct, the v4l2 core has done that already. Signed-off-by:
-
Hans Verkuil authored
The names of the pixelformats is set by the core. So there no longer is any need for drivers to fill it in. Signed-off-by:
-
Hans Verkuil authored
- Fix an off-by-one index check in vidioc_enum_fmt() - Fill in the pix.sizeimage field in vidioc_try_fmt_cap() - Fix an off-by-one index check in vidioc_s_input() Signed-off-by:
-
Hans Verkuil authored
Convert the driver to use v4l2_fh in order to support control events. Signed-off-by:
-
Hans Verkuil authored
- fill in the missing colorspace value. - don't reject incorrect field values, always replace with a valid value. Signed-off-by:
-
Hans Verkuil authored
The bus_info field was never filled. Signed-off-by:
-
Hans Verkuil authored
Interestingly enough, the existing control handling code basically did nothing. At least the new code will inherit the controls from the saa7115 driver. Signed-off-by:
-
Hans Verkuil authored
These things are only initialized if you start streaming video, but they are also used in the disconnect function. So just init them always during probe time. Signed-off-by:
-
Hans Verkuil authored
The standards supported by S-Video and Composite inputs are not limited by PAL, so make it more generic. Signed-off-by:
-
Hans Verkuil authored
In various places the stack was used to provide buffers for USB data, but this should be allocated memory. Signed-off-by:
-
Hans Verkuil authored
If remove_pending is non-zero, then the v4l2_lock is never unlocked. Signed-off-by:
-
Hans Verkuil authored
Set the colorspace and field in vidioc_try_fmt_vid_cap(). Signed-off-by:
-
Hans Verkuil authored
- setup initial radio and tv frequencies. - set/get the correct frequency (radio vs tv). - disable tuner/freq ioctls if there is no tuner. - fix some tuner index checks. Signed-off-by:
-
Hans Verkuil authored
The radio device node had the same caps as the video node. Fix this. Signed-off-by:
-
Hans Verkuil authored
The g/s_audio ioctls didn't do anything, so remove them all for both video and radio nodes and remove V4L2_CAP_AUDIO. The enum/g/s_input ioctls are invalid for radio nodes, so remove them from the radio ioctl_ops. Signed-off-by:
-
Hans Verkuil authored
Don't return -1, return a proper error code. Signed-off-by:
-
Hans Verkuil authored
Convert this driver to the control framework and struct v4l2_fh (needed for handling control events). Signed-off-by:
-
Hans Verkuil authored
This causes lots of problems and is *very* slow as well. One of the main problems is that this prohibits the use of the control framework since subdevs will be unloaded on power off which is not allowed as long as they are used by a usb device. Apparently the reason for doing this is to turn off a noisy tuner. My hardware has no problem with that, and I wonder whether the hardware with that noisy tuner wasn't just functioning improperly as I have never heard of noisy tuners. Contact me if you have one of those devices and I can take a look whether the tuner can't be powered off if necessary by letting the tuner subdevice go into standby mode. Unloading the tuner module is just evil and is not the right approach. Signed-off-by:
-
Masanari Iida authored
This patch fix spelling typos in intro.xml. This xml file is not created from comments within source, I fix the xml file. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> [hans.verkuil@cisco.com: removed mention of obsolete devfs] Signed-off-by:
-
Mikhail Ulyanov authored
Update RENESAS JPU driver maintainer in MAINTAINERS file. Signed-off-by:
Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> Signed-off-by:
-
Mikhail Ulyanov authored
Here's the driver for the Renesas R-Car JPEG processing unit. The driver is implemented within the V4L2 framework as a memory-to-memory device. It presents two video nodes to userspace, one for the encoding part, and one for the decoding part. It was found that the only working mode for encoding is no markers output, so we generate markers with software. In the current version of driver we also use software JPEG header parsing because with hardware parsing performance is lower than desired. >From a userspace point of view the process is typical (S_FMT, REQBUF, optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination queues. STREAMON can return -EINVAL in case of mismatch of output and capture queues format. Also during decoding driver can return buffers if queued buffer with JPEG image contains image with inappropriate subsampling (e.g. 4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag. During encoding the available formats are: V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and V4L2_PIX_FMT_JPEG for destination. During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16 for destination. Performance of current version: 1280x800 NV12 image encoding/decoding decoding ~122 FPS encoding ~191 FPS Signed-off-by:
-
Mikhail Ulyanov authored
Add Renesas R-Car JPEG processing unit driver device tree bindings documentation. Signed-off-by:
-
Laura Abbott authored
Currently, the warning for missing device_caps gives a backtrace like so: [<ffffffff8175c199>] dump_stack+0x45/0x57 [<ffffffff8109ad5a>] warn_slowpath_common+0x8a/0xc0 [<ffffffff8109ae8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0237453>] v4l_querycap+0x43/0x80 [videodev] [<ffffffffa0237734>] __video_do_ioctl+0x2a4/0x320 [videodev] [<ffffffff812207e5>] ? do_last+0x195/0x1210 [<ffffffffa023a11e>] video_usercopy+0x22e/0x5b0 [videodev] [<ffffffffa0237490>] ? v4l_querycap+0x80/0x80 [videodev] [<ffffffffa023a4b5>] video_ioctl2+0x15/0x20 [videodev] [<ffffffffa0233733>] v4l2_ioctl+0x113/0x150 [videodev] [<ffffffff81225798>] do_vfs_ioctl+0x2f8/0x4f0 [<ffffffff8113b2d4>] ? __audit_syscall_entry+0xb4/0x110 [<ffffffff81022d7c>] ? do_audit_syscall_entry+0x6c/0x70 [<ffffffff81225a11>] SyS_ioctl+0x81/0xa0 [<ffffffff8113b526>] ? __audit_syscall_exit+0x1f6/0x2a0 [<ffffffff81763549>] system_call_fastpath+0x12/0x17 This indicates that device_caps are missing but doesn't give much of a clue which driver is actually at fault. Improve the warning output by showing the capabilities and the responsible driver. Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Signed-off-by:
-
Hans Verkuil authored
The bt pointer was never used, remove it. Signed-off-by:
-
Hans Verkuil authored
The v4l2_m2m_fop_mmap function takes the core mutex, but this will result in a potential circular locking dependency: [ 262.517164] ====================================================== [ 262.517166] [ INFO: possible circular locking dependency detected ] [ 262.517169] 4.2.0-rc2-koryphon #844 Not tainted [ 262.517171] ------------------------------------------------------- [ 262.517173] v4l2-compliance/1379 is trying to acquire lock: [ 262.517175] (&dev->dev_mutex){+.+.+.}, at: [<ffffffffa000ddab>] v4l2_m2m_fop_mmap+0x2b/0x90 [v4l2_mem2mem] [ 262.517187] but task is already holding lock: [ 262.517189] (&mm->mmap_sem){++++++}, at: [<ffffffff81159309>] vm_mmap_pgoff+0x69/0xc0 [ 262.517199] which lock already depends on the new lock. [ 262.517202] the existing dependency chain (in reverse order) is: [ 262.517204] -> #1 (&mm->mmap_sem){++++++}: [ 262.517209] [<ffffffff810d0e6b>] __lock_acquire+0x62b/0xe80 [ 262.517215] [<ffffffff810d2095>] lock_acquire+0x65/0x90 [ 262.517218] [<ffffffff811612e5>] __might_fault+0x75/0xa0 [ 262.517222] [<ffffffffa06dead9>] video_usercopy+0x3e9/0x4e0 [videodev] [ 262.517231] [<ffffffffa06debe0>] video_ioctl2+0x10/0x20 [videodev] [ 262.517238] [<ffffffffa06d8663>] v4l2_ioctl+0xc3/0xe0 [videodev] [ 262.517243] [<ffffffff811a8cac>] do_vfs_ioctl+0x2fc/0x550 [ 262.517248] [<ffffffff811a8f74>] SyS_ioctl+0x74/0x80 [ 262.517252] [<ffffffff81a4d2ee>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 262.517258] -> #0 (&dev->dev_mutex){+.+.+.}: [ 262.517262] [<ffffffff810cf464>] validate_chain.isra.38+0xd04/0x1170 [ 262.517266] [<ffffffff810d0e6b>] __lock_acquire+0x62b/0xe80 [ 262.517270] [<ffffffff810d2095>] lock_acquire+0x65/0x90 [ 262.517273] [<ffffffff81a48e3c>] mutex_lock_interruptible_nested+0x6c/0x4b0 [ 262.517279] [<ffffffffa000ddab>] v4l2_m2m_fop_mmap+0x2b/0x90 [v4l2_mem2mem] [ 262.517284] [<ffffffffa06d80ff>] v4l2_mmap+0x4f/0x90 [videodev] [ 262.517288] [<ffffffff8116b06c>] mmap_region+0x38c/0x5b0 [ 262.517293] [<ffffffff8116b585>] do_mmap_pgoff+0x2f5/0x3e0 [ 262.517297] [<ffffffff8115932a>] vm_mmap_pgoff+0x8a/0xc0 [ 262.517300] [<ffffffff81169bab>] SyS_mmap_pgoff+0x1cb/0x270 [ 262.517304] [<ffffffff8100876d>] SyS_mmap+0x1d/0x20 [ 262.517309] [<ffffffff81a4d2ee>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 262.517313] other info that might help us debug this: [ 262.517315] Possible unsafe locking scenario: [ 262.517318] CPU0 CPU1 [ 262.517319] ---- ---- [ 262.517321] lock(&mm->mmap_sem); [ 262.517324] lock(&dev->dev_mutex); [ 262.517327] lock(&mm->mmap_sem); [ 262.517329] lock(&dev->dev_mutex); [ 262.517332] *** DEADLOCK *** Since vb2_fop_mmap doesn't take the lock, neither should v4l2_m2m_fop_mmap. Signed-off-by: -
Andrzej Pietrasiewicz authored
video_unregister_device() calls device_unregister(), which calls put_device(), which calls kobject_put(), and if this is the last reference then kobject_release() is called, which calls kobject_cleanup(), which calls ktype's release method which happens to be device_release() in this case, which calls dev->release(), which happens to be v4l2_device_release() in this case, which calls vdev->release(), which happens to be video_device_release(). But video_device_release() is called explicitly both in error recovery path of s5p_jpeg_probe() and in s5p_jpeg_remove(). The pointers in question are not nullified between the two calls, so this is harmful. This patch fixes the driver so that video_device_release() is not called twice for the same object. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
MFC hardware is known to trash random memory if one tries to use a buffer which has lower DMA addresses than the configured DMA base address. This patch adds a check for this case and proper error handling. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Kamil Debski <kamil@wypas.org> [s.nawrocki@samsung.com: fixed typo (addres -> address] Signed-off-by:
-
Marek Szyprowski authored
alloc_dev_context_buffer method might fail, so add proper return value check. Signed-off-by:
-
Seung-Woo Kim authored
MFCINST_GOT_INST state is set to encoder context with set_format only for capture buffer. In queue_setup of encoder called during reqbufs, it is checked MFCINST_GOT_INST state for both capture and output buffer. So this patch fixes encoder to check MFCINST_GOT_INST state only for capture buffer from queue_setup. Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
-
Nicholas Mc Guire authored
event API conformance testing with coccinelle spatches are being used to locate API usage inconsistencies this triggert with: ./drivers/media/platform/s5p-tv/mixer_reg.c:364 incorrect check for negative return Return type of wait_event_timeout is signed long not int and the return type is >=0 always thus the negative check is unnecessary. An appropriately named variable of type long is inserted and the call fixed up aswell as the negative return check dropped. Signed-off-by:Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
-
Krzysztof Kozlowski authored
i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
- 22 Jul, 2015 4 commits
-
-
Vaishali Thakkar authored
Use eth_zero_addr to assign the zero address to the given address array instead of memset when second argument is address of zero. The Coccinelle semantic patch that makes this change is as follows: // <smpl> @eth_zero_addr@ expression e; @@ -memset(e,0x00,ETH_ALEN); +eth_zero_addr(e); // </smpl> Signed-off-by:
Vaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by:
-
Sunil Shahu authored
Fix code indentation error by replacing tab in place of spaces. Signed-off-by:
Sunil Shahu <shshahu@gmail.com> Signed-off-by:
-
Hans Verkuil authored
COLORSPACE_JPEG should only be used for JPEGs. Use SMPTE170M instead, which is how YCbCr images are usually encoded. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Joe Perches authored
Format mac addresses with the normal kernel extension. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
