- 08 Jul, 2016 17 commits
-
-
Sylwester Nawrocki authored
This fixes dropping ownership of buffers in the driver's stop_streaming callback, so buffers on the memory-to-memory video nodes are properly released, also in case when the driver has a buffer only on one of the queues (OUTPUT, CAPTURE) before the video node close. The issue was being reported by videobuf2 with a following warning while checking q->owned_by_drv_count: [ 2498.310766] WARNING: CPU: 0 PID: 9358 at drivers/media/v4l2-core/videobuf2-core.c:1818 __vb2_queue_cancel+0xe8/0x14c [ 2498.320258] Modules linked in: [ 2498.323212] CPU: 0 PID: 9358 Comm: v4l2_decode Not tainted 4.7.0-rc4-next-20160627 #1210 [ 2498.331284] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2498.331327] [<c010d738>] (unwind_backtrace) from [<c010a4b0>] (show_stack+0x10/0x14) [ 2498.331344] [<c010a4b0>] (show_stack) from [<c031a4ac>] (dump_stack+0x74/0x94) [ 2498.331358] [<c031a4ac>] (dump_stack) from [<c011a52c>] (__warn+0xd4/0x100) [ 2498.331369] [<c011a52c>] (__warn) from [<c011a578>] (warn_slowpath_null+0x20/0x28) [ 2498.331381] [<c011a578>] (warn_slowpath_null) from [<c04ed420>] (__vb2_queue_cancel+0xe8/0x14c) [ 2498.331395] [<c04ed420>] (__vb2_queue_cancel) from [<c04ee10c>] (vb2_core_queue_release+0x18/0x38) [ 2498.331406] [<c04ee10c>] (vb2_core_queue_release) from [<c04eab50>] (v4l2_m2m_ctx_release+0x1c/0x28) [ 2498.331420] [<c04eab50>] (v4l2_m2m_ctx_release) from [<c04fe184>] (fimc_m2m_release+0x24/0x78) [ 2498.331437] [<c04fe184>] (fimc_m2m_release) from [<c04d76c8>] (v4l2_release+0x34/0x74) [ 2498.331455] [<c04d76c8>] (v4l2_release) from [<c01dc8d4>] (__fput+0x80/0x1bc) [ 2498.331469] [<c01dc8d4>] (__fput) from [<c0132edc>] (task_work_run+0xc0/0xe4) [ 2498.331482] [<c0132edc>] (task_work_run) from [<c011d460>] (do_exit+0x304/0xa24) [ 2498.331493] [<c011d460>] (do_exit) from [<c011dccc>] (do_group_exit+0x3c/0xbc) [ 2498.331505] [<c011dccc>] (do_group_exit) from [<c0126cac>] (get_signal+0x200/0x65c) [ 2498.331517] [<c0126cac>] (get_signal) from [<c010e928>] (do_signal+0x84/0x3c4) [ 2498.331532] [<c010e928>] (do_signal) from [<c010a0ec>] (do_work_pending+0xa4/0xb4) [ 2498.331545] [<c010a0ec>] (do_work_pending) from [<c0107954>] (slow_work_pending+0xc/0x20) Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Javier Martinez Canillas authored
According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the s5p-mfc driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also the same values are used in all the fields for both the encoder and decoder video devices. Before this patch: Driver Info (not using libv4l2): Driver name : 11000000.codec Card type : 11000000.codec Bus info : platform:11000000.codec Driver version: 4.7.0 Driver Info (not using libv4l2): Driver name : 11000000.codec Card type : 11000000.codec Bus info : platform:11000000.codec Driver version: 4.7.0 After this patch: Driver Info (not using libv4l2): Driver name : s5p-mfc Card type : s5p-mfc-dec Bus info : platform:11000000.codec Driver version: 4.7.0 Driver Info (not using libv4l2): Driver name : s5p-mfc Card type : s5p-mfc-enc Bus info : platform:11000000.codec Driver version: 4.7.0 Signed-off-by:Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't set the struct v4l2_capability bus_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail: v4l2-compliance.cpp(528): check_ustring(vcap.bus_info, sizeof(vcap.bus_info)) test VIDIOC_QUERYCAP: FAIL This patch fixes by setting the field in VIDIOC_QUERYCAP ioctl handler: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) test VIDIOC_QUERYCAP: OK Signed-off-by: -
Javier Martinez Canillas authored
The streaming field in struct vb2_queue is meant to be private and should not be used by drivers directly, instead the vb2_is_streaming() function should be used to check the videobuf2 queue streaming status. Signed-off-by:
-
Javier Martinez Canillas authored
The V4L2 documentation says that applications must call the VIDIOC_REQBUFS ioctl to determine if a memory mapped, user pointer or DMABUF based I/O is supported by the driver. For example GStreamer does this by first calling VIDIOC_REQBUFS with count zero for all the possible streaming I/O methods and then finally doing the real VIDIOC_REQBUFS with count N using a known to be supported memory type. But the driver prints an error on VIDIOC_REQBUFS if the memory type is not supported which leads to the following errors that can confuse the users: [ 178.704390] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.704666] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.714956] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.715229] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported Signed-off-by:
-
Javier Martinez Canillas authored
The function comment has an obvious typo error, so fix it. Signed-off-by:
-
Marek Szyprowski authored
This patch fixes the error path in the driver probe, so in case of any failure, the resources are not leaked. Reported-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Shuah Khan authored
Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release() attempts to enable clock and runs into null pointer deference accessing invalid pointer. [ 4869.434709] Unable to handle kernel NULL pointer dereference at virtual addr0 [ 4869.441312] pgd = e91ac000 [ 4869.443996] [00000010] *pgd=ba4f7835 [ 4869.447552] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 4869.452921] Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ca [ 4869.471728] CPU: 4 PID: 2965 Comm: lt-gst-launch-1 Not tainted 4.7.0-rc2-nex0 [ 4869.481778] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 4869.487844] task: e91f1e00 ti: ed650000 task.ti: ed650000 [ 4869.493227] PC is at clk_core_enable+0x4c/0x98 [ 4869.497637] LR is at clk_core_enable+0x40/0x98 [ 4869.502056] pc : [<c0559714>] lr : [<c0559708>] psr: 60060093 [ 4869.502056] sp : ed651f18 ip : 00000000 fp : 002641b4 [ 4869.513493] r10: e9088c08 r9 : 00000008 r8 : ed676d68 [ 4869.518692] r7 : ee3ac000 r6 : bf16b3c0 r5 : a0060013 r4 : ee37a8c0 [ 4869.525191] r3 : 00000000 r2 : 00000001 r1 : 00000004 r0 : 00000000 [ 4869.531692] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment noe [ 4869.538883] Control: 10c5387d Table: 691ac06a DAC: 00000051 [ 4869.544603] Process lt-gst-launch-1 (pid: 2965, stack limit = 0xed650210) [ 4869.551361] Stack: (0xed651f18 to 0xed652000) [ 4869.555694] 1f00: ee373 [ 4869.563841] 1f20: bf16b3c0 c055a0e0 ee3ac004 ed676c10 bf16b3c0 bf1558e0 e9080 [ 4869.571986] 1f40: 00000000 ee98a510 ee502e40 bf047344 e9088c00 ee986938 00004 [ 4869.580132] 1f60: 00000000 00000000 e91f2204 00000000 c0b4658c e91f1e00 c0100 [ 4869.588277] 1f80: 00000000 c0135c58 ed650000 c0107904 ed651fb0 00000006 c0104 [ 4869.596423] 1fa0: 00229500 b6581000 b6f7b544 c0107794 00000000 00000002 b6f90 [ 4869.604568] 1fc0: 00229500 b6581000 b6f7b544 00000006 0017b600 0002c038 00264 [ 4869.612714] 1fe0: 00000000 bee56ef0 00000000 b6d49612 00060030 00000006 00000 [ 4869.620865] [<c0559714>] (clk_core_enable) from [<c055a0e0>] (clk_enable+0x2) [ 4869.628509] [<c055a0e0>] (clk_enable) from [<bf1558e0>] (s5p_mfc_release+0x3) [ 4869.637111] [<bf1558e0>] (s5p_mfc_release [s5p_mfc]) from [<bf047344>] (v4l2) [ 4869.646706] [<bf047344>] (v4l2_release [videodev]) from [<c01e4274>] (__fput) [ 4869.654745] [<c01e4274>] (__fput) from [<c0135c58>] (task_work_run+0x94/0xc8) [ 4869.661852] [<c0135c58>] (task_work_run) from [<c010a9d4>] (do_work_pending+) [ 4869.669735] [<c010a9d4>] (do_work_pending) from [<c0107794>] (slow_work_pend) [ 4869.677878] Code: ebffffef e3500000 18bd8070 e5943004 (e5933010) Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Shuah Khan authored
s5p_mfc_remove() fails to release encoder and decoder video devices. Signed-off-by:
-
Shuah Khan authored
Fix Decoder and encoder video device double release in probe error path. video_device_release(dev->vfd_dec) get called twice if decoder register fails. Also, video_device_release(dev->vfd_enc) get called twice if encoder register fails. Signed-off-by:
-
Tiffany Lin authored
Add video encoder node for MT8173 Signed-off-by:
Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by:
-
Tiffany Lin authored
Add h264 encoder driver for MT8173 Signed-off-by:
PoChun Lin <pochun.lin@mediatek.com> Signed-off-by:
-
Tiffany Lin authored
Add vp8 encoder driver for MT8173 Signed-off-by:
-
Tiffany Lin authored
Add v4l2 layer encoder driver for MT8173 Signed-off-by:
-
Tiffany Lin authored
Add a DT binding documentation of Video Encoder for the MT8173 SoC from Mediatek. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Andrew-CT Chen authored
Add VPU drivers for MT8173 Signed-off-by:
Andrew-CT Chen <andrew-ct.chen@mediatek.com> Signed-off-by:
-
Andrew-CT Chen authored
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. It is able to handle video decoding/encoding of in a range of formats. The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU. For VPU initialization, it will create virtual memory for CPU access and IOMMU address for vcodec hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device. A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs. Signed-off-by:
-
- 28 Jun, 2016 23 commits
-
-
Laurent Pinchart authored
YUV 4:1:1 uses 12 bits per pixel on average, not 16. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Laurent Pinchart authored
The formats are interleaved with the YUV packed and miscellaneous formats, making the result confusing especially with the YUV444 format being packed and not planar like YUV410 or YUV420. Move them to their own group as the 2 planes or 3 non-contiguous planes formats to clarify the header. Signed-off-by:
-
Ulrich Hecht authored
Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS, and QUERY_DV_TIMINGS. Signed-off-by:
Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by:
-
Ulrich Hecht authored
Fix rcar_vin_try_fmt's use of an inappropriate pad number when calling the subdev set_fmt function - for the ADV7612, IDs should be non-zero. Signed-off-by:
William Towle <william.towle@codethink.co.uk> Reviewed-by:
Rob Taylor <rob.taylor@codethink.co.uk> [ulrich.hecht+renesas@gmail.com: adapted to rcar-vin rewrite] Signed-off-by:
-
Ulrich Hecht authored
Add detection of source pad number for drivers aware of the media controller API, so that rcar-vin can create device nodes to support modern drivers such as adv7604.c (for HDMI on Lager) and the converted adv7180.c (for composite) underneath. Building rcar_vin gains a dependency on CONFIG_MEDIA_CONTROLLER, in line with requirements for building the drivers associated with it. Signed-off-by:
-
Hans Verkuil authored
The comments for the unlocked v4l2_ctrl_s_ctrl* functions were wrong (copy and pasted from the locked variants). Fix this, since it is confusing. Acked-by:
-
Alexey Khoroshilov authored
Memory allocated for maxiradio device is not deallocated when the device is removed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Helen Fornazier authored
If *nplanes is not zero, it should use the requested size if valid Signed-off-by:
Helen Koike <helen.koike@collabora.co.uk> Signed-off-by:
-
Ismael Luceno authored
Additionally, now it specifies which channels it's showing. Signed-off-by:
Ismael Luceno <ismael@iodev.co.uk> Signed-off-by:
-
Laurent Pinchart authored
The dv_timings_cap() and enum_dv_timings() pad operations take a pad number as an input argument and return the DV timings capabilities and list of supported DV timings for that pad. Commit bd3e275f ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers") broke this as it started ignoring the pad number, always returning the information associated with the currently selected input. Fix it. Fixes: bd3e275f ("[media] media: i2c: adv7604: Use v4l2-dv-timings helpers") Signed-off-by:
-
Markus Pargmann authored
This patch adds V4L2 controls for Auto Exposure Control and Auto Gain Control settings. These settings include low pass filter, update frequency of these settings and the update interval for those units. [Avoid forward declarations] [Fix 80 columns limit violation] [Rename controls to avoid underscores in names] [Fix the AEC maximum shutter width on MT9V032] Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Markus Pargmann authored
The power_on function of the driver resets the chip and sets the CHIP_CONTROL register to 0. This switches the operating mode to slave. The s_stream function sets the correct mode. But this caused problems on a board where the camera chip is operated as master. The camera started after a random amount of time streaming an image, I observed between 10 and 300 seconds. The STRFM_OUT and STLN_OUT pins are not connected on this board which may cause some issues in slave mode. I could not find any documentation about this. Keeping the chip in master mode after the reset helped to fix this issue for me. Signed-off-by:
-
Axel Lin authored
Since commit b4226107 ("regmap: i2c: fallback to SMBus if the adapter does not support standard I2C"), regmap-i2c will check the I2C_FUNC_SMBUS_[BYTE|WORD]_DATA functionality based on the regmap_config setting if the adapter does not support standard I2C. So remove the I2C_FUNC_SMBUS_WORD_DATA functionality check in the driver code. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Laurent Pinchart authored
The of_gpio.h header isn't needed, don't include it. Reported-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Guennadi Liakhovetski authored
If the driver fails to reset the camera or to set up control handlers, it has to power the camera back off. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Julia Lawall authored
This v4l2_subdev_internal_ops structure is never modified. All other v4l2_subdev_internal_ops structures are declared as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Sakari Ailus authored
The value is not used after the assignment. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
Hans Verkuil authored
Users won't know what to put in this module option if it isn't described. Signed-off-by:
-
Ezequiel Garcia authored
Audio hw params are shared across all DMA channels, so if the user changes any of these while any DMA channel is enabled, it will impact the enabled channels, potentially causing serious instability issues. This commit avoids such situation, by preventing any hw param change (on any DMA channel) if any other DMA audio channel is capturing. Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Ezequiel Garcia authored
Currently, the driver has a fixed period size of 4096 bytes (2048 frames). Since this hardware can configure the audio capture size, this commit allows a period size range of [512-4096]. This is very useful to reduce the audio latency. Signed-off-by:
-
Ezequiel Garcia authored
Now that we've introduced the dma_mode parameter to pick the DMA operation, let's use it to also select the audio DMA operation. When dma_mode != memcpy, the driver will avoid using memcpy in the audio capture path, and the DMA hardware operation will act directly on the ALSA buffers. Signed-off-by:
-
Ezequiel Garcia authored
Now that the driver has the infrastructure to support more DMA modes, let's add the DMA scatter-gather mode. In this mode, the device delivers sequential top-bottom frames. The scatter-gather logic is based on staging's tw686x-kh driver (by Krzysztof Ha?asa). Tested-by:
Tim Harvey <tharvey@gateworks.com> Signed-off-by:
-
Ezequiel Garcia authored
Now that the driver has the infrastructure to support more DMA modes, let's add the DMA contiguous interlaced frame mode. In this mode, the DMA P and B buffers are programmed with the user-provided buffers. When a P (or B) frame is ready, a new buffer is dequeued into P (or B). In addition to interlaced fields, the device can also be programmed to deliver alternate fields. Only interlaced mode is supported for now. Tested-by:
-
