- 05 Jun, 2018 4 commits
-
-
Dmitry Osipenko authored
A failed memory client reset doesn't prevent VDE from resetting, hence reset VDE regardless of preceding memory client resetting failure. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Arnd Bergmann authored
Testing randconfig builds after the return of the mmp ccic driver shows a link error in some configurations: drivers/media/platform/marvell-ccic/mcam-core.o: In function `mccic_register': mcam-core.c:(.text+0x2e48): undefined reference to `vb2_dma_contig_memops' A closer look at the mcam-core.c file reveals that we need to select both VIDEOBUF2_DMA_CONTIG and VIDEOBUF2_VMALLOC, as already do for VIDEO_CAFE_CCIC. Fixes: 0a9c643c ("media: marvel-ccic: re-enable mmp-driver build") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
Randconfig builds fail when one of the two is a built-in driver and the other one is a loadable module: drivers/media/platform/marvell-ccic/mcam-core.o: In function `mccic_register': mcam-core.c:(.text+0x2594): undefined reference to `__this_module' drivers/media/platform/marvell-ccic/mcam-core.o:(.rodata+0x50): undefined reference to `__this_module' The problem is that mcam-core.c can not be built both ways at the smae time. However, we can make kbuild take care of that by making the core driver a separate module, which can be either built-in or loadable as needed. Making it a separate module requires exporting a few symbols and adding the module license from the header. Fixes: 0a9c643c ("media: marvel-ccic: re-enable mmp-driver build") Signed-off-by:
-
Kieran Bingham authored
The addition of an extra operation to use the GET_INFO command overwrites all existing flags from the uvc_ctrls table. This includes setting all controls as supporting GET_MIN, GET_MAX, GET_RES, and GET_DEF regardless of whether they do or not. Move the initialisation of these control capabilities directly to the uvc_ctrl_fill_xu_info() call where they were originally located in that use case, and ensure that the new functionality in uvc_ctrl_get_flags() will only set flags based on their reported capability from the GET_INFO call. Fixes: 859086ae ("media: uvcvideo: Apply flags from device to actual properties") Cc: stable@vger.kernel.org Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 28 May, 2018 36 commits
-
-
Daniel Scheller authored
CineS2 V7(A) and Octopus CI S2 Pro/Advanced cards support faster TS speeds on the card's contained stv0910 demodulator when their FPGA was updated with a recent (>= 1.7, version number applies to all mentioned cards) vendor firmware. Enable this faster TS speed on card port 0 (contained demod) and parallel stv0910 connections when the card firmware is at least 1.7 or later. Note: The mentioned cards and their demods are handled via the STV0910_PR and STV0910_P tuner types. DuoFlex modules with such demodulators are handled via the STV0910 (without suffix) types where such TS speed increase doesn't technically make sense. Signed-off-by:
Daniel Scheller <d.scheller@gmx.net> Tested-by:
Richard Scobie <rascobie@slingshot.co.nz> Tested-by:
Helmut Auer <post@helmutauer.de> Signed-off-by:
-
Daniel Scheller authored
Add a tsspeed config option to struct stv0910_cfg which can be used by users of the driver to set the (parallel) TS speed (higher speeds enable support for higher bitrate transponders). If tsspeed isn't set in the config, it'll default to a sane value. This commit also updates the two consumers of the stv0910 driver (ngene and ddbridge) to have a default tsspeed in their stv0910_cfg templates. Signed-off-by:
-
Daniel Scheller authored
Fixes two checkpatch warnings WARNING: function definition argument 'xxx' should also have an identifier name in the ddb_mci_attach() prototype definition. checkpatch keeps complaining on the "int (**fn_set_input)" as it seems to have issues with the ptr-to-ptr, though this probably needs fixing in checkpatch. Signed-off-by:
-
Daniel Scheller authored
In stop(), an (unlikely) out-of-bounds write error can occur when setting the demod_in_use element indexed by state->demod to zero, as state->demod isn't checked for being in the range of the array size of demod_in_use, and state->demod maybe carrying the magic 0xff (demod unused) value. Prevent this by checking state->demod not exceeding the array size before setting the element value. To make the code a bit easier to read, replace the magic value and the number of array elements with defines, and use them at a few more places. Detected by CoverityScan, CID#1468550 ("Out-of-bounds write") Thanks to Colin for reporting the problem and providing an initial patch. Fixes: daeeb131 ("media: ddbridge: initial support for MCI-based MaxSX8 cards") Reported-by:Colin Ian King <colin.king@canonical.com> Cc: Ralph Metzler <rjkm@metzlerbros.de> Signed-off-by:
-
Sean Young authored
Since commit cb84343f ("media: lirc: do not call close() or open() on unregistered devices") rc_open() will return -ENODEV if rcdev->registered is false. Ensure this is set before we register the input device and the lirc device, else we have a short window where the neither the lirc or input device can be opened. Fixes: cb84343f ("media: lirc: do not call close() or open() on unregistered devices") Cc: stable@vger.kernel.org # v4.16+ Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Michał Winiarski authored
Doing writes when the device is disabled seems to be a NOOP. For CIR device, we should enable it, initialize it, and then disable it until it's opened. CIR_WAKE should always be enabled. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Michał Winiarski authored
Core rc keeps track of the users - let's use it to tweak the code and use the common code path on suspend/resume. Signed-off-by:
-
Michał Winiarski authored
It appears that we need to enable CIR device before attempting to touch some of the registers. Previously, this was not a big issue, since we were rarely seeing nvt_close() getting called. Unfortunately, since commit cb84343f ("media: lirc: do not call close() or open() on unregistered devices") the initial open() during probe from rc_setup_rx_device() is no longer successful, which means that userspace clients will actually end up calling nvt_open()/nvt_close(). Since nvt_open() is broken, the device doesn't seem to work as expected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199597Signed-off-by:
-
ming_qian authored
media: uvcvideo: Support UVC 1.5 video probe & commit controls The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1. Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be recognized. More changes to the driver are needed for full UVC 1.5 compatibility. However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been reported to work well. [laurent.pinchart@ideasonboard.com: Factor out code to helper function, update size checks] Cc: stable@vger.kernel.org Signed-off-by:
ming_qian <ming_qian@realsil.com.cn> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Ana Guerrero Lopez <ana.guerrero@collabora.com> Signed-off-by:
-
Philipp Zabel authored
kref_init initializes the reference count to 1, not 0. This additional reference is never released since the conversion to reference counters. As a result, uvc_delete is not called anymore when UVC cameras are disconnected. Fix this by adding an additional kref_put in uvc_disconnect and in the probe error path. This also allows to remove the temporary additional reference in uvc_unregister_video. Fixes: 9d15cd95 ("media: uvcvideo: Convert from using an atomic variable to a reference count") Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by:
-
Ondrej Zary authored
The 50Hz and 60Hz power line frequency settings disable short (1/120s and 1/100s) exposure times for banding filter (causing overexposed image near lamps). No flicker setting enables them (when banding filter is disabled and they're not used). Seems that the logic is just the wrong way around. (This bug came from the Windows driver.) Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Ondrej Zary authored
Power line frequency settings for OV7648 sensor contain autogain and exposure commands, affecting unrelated controls. Remove them. Signed-off-by:
-
Ondrej Zary authored
The ZS0211 internal autogain causes pumping and flickering with OV7648 sensor on 0ac8:307b webcam. Implement OV7648 autogain and exposure control and use that instead. Signed-off-by:
-
Hans Verkuil authored
The ioctl serialization mutex (vdev->lock or q->lock for vb2 queues) was taken at the highest level in v4l2-dev.c. This prevents more fine-grained locking since at that level we cannot examine the ioctl arguments, we can only do that after video_usercopy is called. So push the locking down to __video_do_ioctl() and subdev_do_ioctl_lock(). This also allows us to make a few functions in v4l2-ioctl.c static and video_usercopy() is no longer exported. The locking scheme is not changed by this patch, just pushed down. Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Hans Verkuil authored
This driver is the only V4L driver that does not set unlocked_ioctl to video_ioctl2. The only thing that pvr2_v4l2_ioctl does besides calling video_ioctl2 is calling pvr2_hdw_commit_ctl(). Add pvr2_hdw_commit_ctl() calls to the various ioctls that need this, and we can replace pvr2_v4l2_ioctl by video_ioctl2. Signed-off-by:
-
Gustavo A. R. Silva authored
This code has been there for nine years now, and it has been working "good enough" since then [1]. Remove duplicate code by getting rid of the if-else statement. [1] https://marc.info/?l=linux-kernel&m=152693550225081&w=2Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
-
Hans Verkuil authored
If a CEC message was received and the RX interrupt was set, but not yet processed, and a new transmit was issues, then the transmit code would inadvertently clear the RX interrupt and after that no new messages would ever be received. Instead it should only clear TX interrupts since register 0x97 is a clear-on-write register. Signed-off-by:
-
Hans Verkuil authored
When a message was canceled it could return tx_status with both OK and MAX_RETRIES set, which is illegal. If a canceled message was waiting for a reply, then rx_status wasn't updated, so set that as well. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in name field Signed-off-by:
-
Akinobu Mita authored
The open() operation for the pxa_camera driver always calls s_power() operation to put its subdevice sensor in normal operation mode, and the release() operation always call s_power() operation to put the subdevice in power saving mode. This requires the subdevice sensor driver to keep track of its power state in order to avoid putting the subdevice in power saving mode while the device is still opened by some users. Many subdevice drivers handle it by the boilerplate code that increments and decrements an internal counter in s_power() like below: /* * If the power count is modified from 0 to != 0 or from != 0 to 0, * update the power state. */ if (sensor->power_count == !on) { ret = ov5640_set_power(sensor, !!on); if (ret) goto out; } /* Update the power count. */ sensor->power_count += on ? 1 : -1; However, some subdevice drivers don't handle it and may cause a problem with the pxa_camera driver if the video device is opened by more than two users at the same time. Instead of propagating the boilerplate code for each subdevice driver that implement s_power, this introduces an trick that many V4L2 drivers are using with v4l2_fh_is_singular_file(). Signed-off-by:Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
DMA requests must be blocked before resetting VDE HW, otherwise it is possible to get a memory corruption or a machine hang. Use the reset control provided by the Memory Controller to block DMA before resetting the VDE HW. Signed-off-by:
-
Ezequiel Garcia authored
When the driver is configured in the "memcpy" dma-mode, it uses vb2_vmalloc_memops, which is backed by a SLAB allocator and so shouldn't be using GFP_DMA32. Fix it. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
The DMA engine subsystem provides stubs for drivers to build with !DMA_ENGINE. Drop the config dependency. Signed-off-by:
-
Ezequiel Garcia authored
The mutexes are not being destroyed in the release path. Fix it. Signed-off-by:
-
Ezequiel Garcia authored
Fix a trivial typo. Signed-off-by:
-
Geert Uytterhoeven authored
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Note: - The various VIDEOBUF*DMA* symbols had to loose their dependencies on HAS_DMA, as they are selected by several individual drivers. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Mark Brown <broonie@kernel.org> Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Dan Carpenter authored
If we pick a very large "edid->blocks" value then the "edid->start_block + edid->blocks" addition could wrap around. Fixes: ef834f78 ("[media] vivid: add the video capture and output parts") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The current logic makes Smatch to false-detect a Spectre variant 1 vulnerability. The problem is that it initializes an u32 indirectly from user space input. After trying to write a fixup, after a while I realized that, in practice, this shouldn't be a problem, as an u32 is initialized from u8, but it took some time to discover it. So, do some code cleanup to make it clearer for both humans and machines about the valid range for "op". Fix this warning: drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' Signed-off-by:
-
Ezequiel Garcia authored
Some subdrivers access the gspca_dev->urb array in the completion handler. To prevent use-after-free (actually, NULL dereferences) we need to synchronously kill all the URBs before we release them. In particular, this is currently the case for drivers such as sn9c20x and sonixj, which access the gspca_dev->urb[0] in the context of completion handler for *any* of the URBs. This commit changes the destroy_urb implementation, so it kills all URBs first, and then proceed to set the URBs to NULL in the array and release them. Signed-off-by:
-
Hans Verkuil authored
Fix v4l2-compliance error: s_parm never set V4L2_CAP_TIMEPERFRAME. Also various g/s_parm-related cleanups. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans Verkuil authored
The last user of this 'feature' was the gspca driver. Now that that driver has been converted to vb2 we can delete this code. Signed-off-by:
-
Hans Verkuil authored
Zero the reserved capture/output array. Zero the extendedmode (it is never used in drivers). Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY, as that is the only valid flag. Signed-off-by:
-
Hans Verkuil authored
The gspca core has its own buffere implementation. Use the core VB 2 instead. Signed-off-by:
-
Hans Verkuil authored
When a buffer is queued or requeued in vb2_buffer_done, then don't call the finish memop. In this case the buffer is only returned to vb2, not to userspace. Calling 'finish' here will cause an unbalance when the queue is canceled, since the core will call the same memop again. Signed-off-by:
-
Akinobu Mita authored
The banding filter ON/OFF is controlled via bit 5 of COM8 register. It is attempted to be enabled in ov772x_set_params() by the following line. ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1); But this unexpectedly results disabling the banding filter, because the mask and set bits are exclusive. On the other hand, ov772x_s_ctrl() correctly sets the bit by: ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF); Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Akinobu Mita authored
This adds a device tree binding documentation for OV7720/OV7725 sensor. Cc: Jacopo Mondi <jacopo+renesas@jmondi.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com> Cc: Rob Herring <robh+dt@kernel.org> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Reviewed-by:
-
