Dragos Bogdan [Wed, 22 Jun 2016 11:30:42 +0000 (08:30 -0300)]
[media] adv7604: Add support for hardware reset
The part can be reset by a low pulse on the RESET pin (i.e. a hardware
reset) with a minimum width of 5 ms. It is recommended to wait 5 ms
after the low pulse before an I2C write is performed to the part.
For safety reasons, the delays will be between 5 and 10 ms.
The RESET pin can be tied high, so the GPIO is optional.
Arnd Bergmann [Fri, 17 Jun 2016 20:46:28 +0000 (17:46 -0300)]
[media] dvb: use ktime_t for internal timeout
The dvb demuxer code uses a 'struct timespec' to pass a timeout
as absolute time. This will cause problems on 32-bit architectures
in 2038 when time_t overflows, and it is racy with a concurrent
settimeofday() call.
This patch changes the code to use ktime_get() instead, using
the monotonic time base to avoid both the race and the overflow.
Lubomir Rintel [Wed, 1 Jun 2016 13:04:07 +0000 (10:04 -0300)]
[media] usbtv: improve a comment
Patrick Keshishian improved the explanation of the protocol when porting
the driver to OpenBSD. Given it's a reverse engineering one and there's
no documetnation it might be helpful to whoever hacks on the driver.
Signed-off-by: Patrick Keshishian <sidster@boxsoft.com> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Florian Echtler [Tue, 31 May 2016 20:15:33 +0000 (17:15 -0300)]
[media] sur40: fix occasional oopses on device close
Closing the V4L2 device sometimes triggers a kernel oops.
Present patch fixes this.
Signed-off-by: Martin Kaltenbrunner <modin@yuri.at> Signed-off-by: Florian Echtler <floe@butterbrot.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.2 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Florian Echtler [Tue, 31 May 2016 20:15:32 +0000 (17:15 -0300)]
[media] sur40: lower poll interval to fix occasional FPS drops to ~56 FPS
The framerate sometimes drops below 60 Hz if the poll interval is too high.
Lowering it to the minimum of 1 ms fixes this.
Signed-off-by: Martin Kaltenbrunner <modin@yuri.at> Signed-off-by: Florian Echtler <floe@butterbrot.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.2 and up Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[media] DocBook: mention the memory type to be set for all streaming I/O
The DMA buffer importing streaming I/O section mentions the memory type
value that has to be set when calling the VIDIOC_REQBUFS ioctl but this
isn't mentioned in neither the Memory Mapping nor User Pointer sections.
A user can know the values by looking at the examples but it's better
to explicitly mention in the documentation, and also makes all sections
about streaming I/O methods more consistent.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[media] DocBook: add dmabuf as streaming I/O in VIDIOC_REQBUFS description
Commit 4b9c1cb641c46 ("[media] Documentation: media: description of DMABUF
importing in V4L2") documented the V4L2 dma-buf importing support but did
not update the VIDIOC_REQBUFS description, so only the Memory Mapping and
User Pointer I/O methods are mentioned.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
It is responsibility of a caller of fops->open(),
to make sure an owner of the fops is available until file is closed.
So, there is no need to lock THIS_MODULE explicitly.
Found by Linux Driver Verification project (linuxtesting.org).
Hans Verkuil [Sun, 26 Jun 2016 10:44:56 +0000 (07:44 -0300)]
[media] rc-main: fix kernel oops after unloading keymap module
When the rc_map table is created the char pointer of the name of the keymap
is copied to the rc_map->name field. However, this pointer points to memory
from the keymap module itself.
Since these keymap modules are not refcounted, that means anyone can call
rmmod to unload that module. Which is not a big deal because the contents of
the map is all copied to rc_map, except for the keymap name.
So after a keymap module is unloaded the name pointer has become stale. Unloading
the rc-core module will now cause a kernel oops in rc_dev_uevent().
The solution is to kstrdup the name so there are no more references to the
keymap module remaining.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hans Verkuil [Fri, 8 Jul 2016 19:11:18 +0000 (16:11 -0300)]
[media] mtk-vcodec: convert driver to use the new vb2_queue dev field
The patch dropping the vb2_dma_contig_init_ctx() and _cleanup_ctx()
functions was already applied before this driver was added. So convert
this driver as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When CONFIG_INPUT is disabled, multiple gspca backend drivers
print compile-time warnings about unused variables:
media/usb/gspca/cpia1.c: In function 'sd_stopN':
media/usb/gspca/cpia1.c:1627:13: error: unused variable 'sd' [-Werror=unused-variable]
media/usb/gspca/konica.c: In function 'sd_stopN':
media/usb/gspca/konica.c:246:13: error: unused variable 'sd' [-Werror=unused-variable]
This annotates the variables as __maybe_unused, to let the compiler
know that they are declared intentionally.
Fixes: ee186fd96a5f ("[media] gscpa_t613: Add support for the camera button") Fixes: c2f644aeeba3 ("[media] gspca_cpia1: Add support for button") Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hans Verkuil [Mon, 4 Jul 2016 13:18:10 +0000 (10:18 -0300)]
[media] MAINTAINERS: change maintainer for gscpa/pwc/radio-shark
Hans de Goede has no more time to work on those, so I'll take over.
For gspca/pwc I'll do 'Odd Fixes', for radio-shark I'll be a
full maintainer.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The workqueue "workqueue" is involved in transmitting hdpvr buffers.
It has a single work item(&dev->worker) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path. Hence,
the singlethreaded workqueue has been replaced with the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Work item has been flushed in hdpvr_device_release() to ensure
that there are no pending tasks while disconnecting the driver.
The workqueue "work_queues" enables hotplugging.
It has a single work item(&state->delayed_work_enable_hotplug) and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path. Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Work item has been sync cancelled in adv76xx_remove() to ensure
that there are no pending tasks while disconnecting the driver.
The workqueue "work_queues" enables hotplugging.
It has a single work item(&state->delayed_work_enable_hotplug) and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path. Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Work item has been sync cancelled in tc358743_remove() to ensure
that there are no pending tasks while disconnecting the driver.
The workqueue "work_queues" enables hotplugging.
It has a single work item(&state->delayed_work_enable_hotplug) and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path. Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Work item has been sync cancelled in adv7842_remove() to ensure
that there are no pending tasks while disconnecting the driver.
The workqueue "work_thread" is involved in JPEG quality update.
It has a single work item(&sd->work) and hence doesn't require ordering.
Also, it is not being used on a memory reclaim path. Hence, the
singlethreaded workqueue has been replaced with the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.
When setting the frame time, gspca uses v4l2_get_timestamp() which uses
ktime_get_ts() which uses ktime_get_ts64() which returns a monotonic
timestamp, so it's safe to initialize the buffer flags to
V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC to fix the failure.
Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Antonio Ospite [Wed, 9 Mar 2016 16:03:18 +0000 (13:03 -0300)]
[media] gspca: fix a v4l2-compliance failure about VIDIOC_ENUM_FRAMEINTERVALS
According to v4l2-compliance VIDIOC_ENUM_FRAMEINTERVALS should fail for
unsupported frame sizes, but gspca is too tolerant and tries to find
the frame intervals for the frame size nearest to the requested one.
This makes v4l2-compliance fail with this message:
fail: v4l2-test-formats.cpp(123): \
found frame intervals for invalid size 321x240
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
Fix this by using an exact match for the frame size when enumerating
frame intervals, and retuning an error if the frame size for which the
frame intervals have been asked is not supported.
Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Antonio Ospite [Wed, 9 Mar 2016 16:03:15 +0000 (13:03 -0300)]
[media] gspca: ov534/topro: use a define for the default framerate
When writing the change in commit dcc7fdbec53a ("[media] gspca:
ov534/topro: prevent a division by 0") I used magic numbers for the
default framerate to minimize the code footprint to make it easier to
backport the patch to the stable trees.
However it's better if the default framerate has its own define to avoid
risking using different values in different places, and for readability.
While at it also remove some trivial comments about the framerates which
don't add much to the code anymore.
Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Arnd Bergmann [Tue, 26 Jan 2016 16:17:24 +0000 (14:17 -0200)]
[media] pwc: hide unused label
The pwc driver causes a warning when CONFIG_USB_PWC_INPUT_EVDEV is unset:
drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
drivers/media/usb/pwc/pwc-if.c:1115:1: warning: label 'err_video_unreg' defined but not used [-Wunused-label]
This moves the unused label and code inside another #ifdef to
get rid of the warning.
Hans Verkuil [Fri, 15 Apr 2016 12:15:05 +0000 (09:15 -0300)]
[media] vb2: replace void *alloc_ctxs by struct device *alloc_devs
Make this a proper typed array. Drop the old allocate context code since
that is no longer used.
Note that the memops functions now get a struct device pointer instead of
the struct device ** that was there initially (actually a void pointer to
a struct containing only a struct device pointer).
This code is now a lot cleaner.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hans Verkuil [Wed, 16 Dec 2015 10:30:43 +0000 (08:30 -0200)]
[media] vb2: add a dev field to use for the default allocation context
The allocation context is nothing more than a per-plane device pointer
to use when allocating buffers. So just provide a dev pointer in vb2_queue
for that purpose and drivers can skip allocating/releasing/filling in
the allocation context unless they require different per-plane device
pointers as used by some Samsung SoCs.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: Florian Echtler <floe@butterbrot.org> Cc: Federico Vaga <federico.vaga@gmail.com> Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> Cc: Scott Jiang <scott.jiang.linux@gmail.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: Fabien Dessenne <fabien.dessenne@st.com> Acked-by: Benoit Parrot <bparrot@ti.com> Cc: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hans Verkuil [Fri, 15 Apr 2016 12:15:05 +0000 (09:15 -0300)]
[media] vb2: move dma_attrs to vb2_queue
Make the dma attributes struct part of vb2_queue. This greatly simplifies
the remainder of the patch series since the dma_contig alloc context is
now (as before) just a struct device pointer.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[media] exynos4-is: Fix buffer release issue on fimc m2m video nodes
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)
[media] s5p-mfc: improve v4l2_capability driver and card fields
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: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[media] s5p-mfc: use vb2_is_streaming() to check vb2 queue status
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.
[media] s5p-mfc: don't print errors on VIDIOC_REQBUFS unsupported mem type
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
Shuah Khan [Tue, 28 Jun 2016 19:17:18 +0000 (16:17 -0300)]
[media] s5p-mfc: fix null pointer deference in clk_core_enable()
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.
Shuah Khan [Tue, 28 Jun 2016 19:17:16 +0000 (16:17 -0300)]
[media] s5p-mfc: fix video device release double release in probe error path
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.
Tiffany Lin [Tue, 3 May 2016 10:11:24 +0000 (07:11 -0300)]
[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
Add v4l2 layer encoder driver for MT8173
Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
[hans.verkuil@cisco.com: drop unnecessary ARM || ARM64 dependency] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Andrew-CT Chen [Tue, 3 May 2016 10:11:21 +0000 (07:11 -0300)]
[media] VPU: mediatek: support Mediatek VPU
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: Andrew-CT Chen <andrew-ct.chen@mediatek.com> Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
[hans.verkuil@cisco.com: drop unnecessary ARM || ARM64 dependency] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Laurent Pinchart [Wed, 15 Jun 2016 23:27:58 +0000 (20:27 -0300)]
[media] videodev2.h: Group YUV 3 planes formats together
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.
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: William Towle <william.towle@codethink.co.uk> Signed-off-by: Rob Taylor <rob.taylor@codethink.co.uk>
[ulrich.hecht+renesas@gmail.com: adapted to rcar-vin rewrite] Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Laurent Pinchart [Tue, 24 May 2016 11:53:39 +0000 (08:53 -0300)]
[media] adv7604: Don't ignore pad number in subdev DV timings pad operations
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 bd3e275f3ec0 ("[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.
Markus Pargmann [Mon, 14 Dec 2015 14:41:53 +0000 (12:41 -0200)]
[media] v4l: mt9v032: Add V4L2 controls for AEC and AGC
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]
Markus Pargmann [Mon, 14 Dec 2015 14:41:52 +0000 (12:41 -0200)]
[media] v4l: mt9v032: Do not unset master_mode
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.
Axel Lin [Sun, 10 Aug 2014 09:41:49 +0000 (06:41 -0300)]
[media] v4l: mt9v032: Remove duplicate test for I2C_FUNC_SMBUS_WORD_DATA functionality
Since commit b42261078a91 ("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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Ezequiel Garcia [Sat, 4 Jun 2016 23:47:20 +0000 (20:47 -0300)]
[media] tw686x: audio: Prevent hw param changes while busy
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.
Ezequiel Garcia [Sat, 4 Jun 2016 23:47:19 +0000 (20:47 -0300)]
[media] tw686x: audio: Allow to configure the period size
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].
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.
Ezequiel Garcia [Sat, 4 Jun 2016 23:47:16 +0000 (20:47 -0300)]
[media] tw686x: Add support for DMA contiguous interlaced frame mode
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: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Ezequiel Garcia [Sat, 4 Jun 2016 23:47:15 +0000 (20:47 -0300)]
[media] tw686x: Introduce an interface to support multiple DMA modes
Let's set the corner stone to support all the DMA modes
available on this device.
For stability reasons, the driver is currently setting DMA frame
mode, and using single DMA buffers to get the P and B buffers.
Each frame is then memcpy'ed into the user buffer.
However, other platforms might be interested in avoiding this
memcpy, or in taking advantage of the chip's DMA scatter-gather
capabilities.
To achieve this, this commit introduces a "dma_mode" module parameter,
and a tw686x_dma_ops struct. This will allow to define functions to
alloc/free DMA buffers, and to return the frames to userspace.
The memcpy-based method described above is named as dma_mode="memcpy".
Current alloc/free functions are renamed as tw686x_memcpy_xxx,
and are now used through a memcpy_dma_ops.
Tested-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Those structs are used only at bdisp-hw, so they shouldn't be
there in a header file that it is used elsewhere.
This fixes the following Gcc 6.1 warnings:
In file included from drivers/media/platform/sti/bdisp/bdisp-debug.c:11:0:
drivers/media/platform/sti/bdisp/bdisp-filter.h:207:65: warning: ‘bdisp_v_spec’ defined but not used [-Wunused-const-variable=]
static const struct __maybe_unused bdisp_filter_v_spec bdisp_v_spec[] = {
^~~~~~~~~
In file included from drivers/media/platform/sti/bdisp/bdisp-debug.c:11:0:
drivers/media/platform/sti/bdisp/bdisp-filter.h:23:65: warning: ‘bdisp_h_spec’ defined but not used [-Wunused-const-variable=]
static const struct __maybe_unused bdisp_filter_h_spec bdisp_h_spec[] = {
^~~~~~~~~
drivers/media/i2c/adv7842.c:2400:27: warning: 'prim_mode_txt' defined but not used [-Wunused-const-variable=]
static const char * const prim_mode_txt[] = {
^~~~~~~~~~~~~
That seems to be useful for debug, and likely were used before.
While we could simply remove, let's comment it out, for now.
drivers/media/usb/em28xx/em28xx-dvb.c:907:38: warning: 'pctv_461e_m88ds3103_config' defined but not used [-Wunused-const-variable=]
static const struct m88ds3103_config pctv_461e_m88ds3103_config = {
^~~~~~~~~~~~~~~~~~~~~~~~~~
That's a left over of patch 76b91be3d360a ('em28xx: PCTV 461e use I2C
client for demod and SEC').
Gcc 6.1 warns about some unused vars. Remove them:
drivers/media/platform/vivid/vivid-vid-cap.c:40:2: warning: 'tpf_default' defined but not used [-Wunused-const-variable=]
tpf_default = {.numerator = 1, .denominator = 30};
^~~~~~~~~~~
drivers/media/platform/vivid/vivid-sdr-cap.c:54:27: warning: 'NUM_FORMATS' defined but not used [-Wunused-const-variable=]
static const unsigned int NUM_FORMATS = ARRAY_SIZE(formats);
^~~~~~~~~~~
drivers/media/pci/zoran/zr36016.c:251:18: warning: 'zr016_yoff' defined but not used [-Wunused-const-variable=]
static const int zr016_yoff[] = { 8, 9, 7 };
^~~~~~~~~~
drivers/media/pci/zoran/zr36016.c:250:18: warning: 'zr016_xoff' defined but not used [-Wunused-const-variable=]
static const int zr016_xoff[] = { 20, 20, 20 };
^~~~~~~~~~
Those tables aren't used anywere. So, remove them.
As Gcc6.1 warned, those tables are currently unused:
drivers/media/tuners/r820t.c:349:18: warning: 'r820t_mixer_gain_steps' defined but not used [-Wunused-const-variable=]
static const int r820t_mixer_gain_steps[] = {
^~~~~~~~~~~~~~~~~~~~~~
drivers/media/tuners/r820t.c:345:18: warning: 'r820t_lna_gain_steps' defined but not used [-Wunused-const-variable=]
static const int r820t_lna_gain_steps[] = {
^~~~~~~~~~~~~~~~~~~~
They're actually used only by a routine that it is currently
commented out. So, move those tables to be together with such
code and comment them out.
Those tables are currently unused, so comment them out:
drivers/media/dvb-frontends/dib0090.c:852:18: warning: 'rf_ramp_pwm_sband' defined but not used [-Wunused-const-variable=]
static const u16 rf_ramp_pwm_sband[] = {
^~~~~~~~~~~~~~~~~
drivers/media/dvb-frontends/dib0090.c:800:18: warning: 'bb_ramp_pwm_boost' defined but not used [-Wunused-const-variable=]
static const u16 bb_ramp_pwm_boost[] = {
^~~~~~~~~~~~~~~~~
drxj: comment out the unused nicam_presc_table_val table
Avoid this warning:
drivers/media/dvb-frontends/drx39xyj/drxj.c:1243:18: warning: 'nicam_presc_table_val' defined but not used [-Wunused-const-variable=]
static const u16 nicam_presc_table_val[43] = {
^~~~~~~~~~~~~~~~~~~~~
The PCI device ID table is only used if compiled with modules
support. When compiled with modules disabled, this is now
producing this bogus warning:
drivers/media/pci/cx25821/cx25821-alsa.c:696:35: warning: 'cx25821_audio_pci_tbl' defined but not used [-Wunused-const-variable=]
static const struct pci_device_id cx25821_audio_pci_tbl[] = {
^~~~~~~~~~~~~~~~~~~~~
Fix it by annotating that the function may not be used.
projects / karo-tx-linux.git / log