The locking scheme inside the vb2 thread is unsafe when stopping the
thread. In particular kthread_stop was called *after* internal data
structures were cleaned up instead of doing that before. In addition,
internal vb2 functions were called after threadio->stop was set to
true and vb2_internal_streamoff was called. This is also not allowed.
All this led to a variety of race conditions and kernel warnings and/or
oopses.
Fixed by moving the kthread_stop call up before the cleanup takes
place, and by checking threadio->stop before calling internal vb2
queuing operations.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v3.16 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This is easy to forget to do in drivers. While v4l2-compliance will check for it,
not everyone remembers to run it. So warn about it.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The function releases the queue if the file being released is the queue
owner. The check reads the queue->owner field without taking the queue
lock, creating a race condition with functions that set the queue owner,
such as vb2_ioctl_reqbufs() for instance.
Fix this by moving the queue->owner check within the mutex protected
section.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The vb2_fop_poll() implementation tries to be clever on whether it needs
to lock the queue mutex by checking whether polling might start fileio.
The test requires reading the q->num_buffer field, which is racy if we
don't hold the queue mutex in the first place.
Remove the extra cleverness and just lock the mutex.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The vb2_put_vma() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Log the new ycbcr_enc and quantization fields. Note that it now
also logs the flags field for the multiplanar buffer type. This was
forgotten when the flags field was added.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
By default dma_map_sg syncs the mapped buffer to the device. But
buf_prepare expects a buffer syncs for the cpu and the buffer
will be synced to the device in the prepare memop.
The reverse is true for dma_unmap_sg, buf_finish and the finish
memop.
To prevent unnecessary syncs we ask dma_(un)map_sg to skip the
sync.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add support for DMABUF exporting to the vb2-vmalloc implementation.
All memory models now have support for both importing and exporting of DMABUFs.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add support for importing dmabuf to videobuf2-dma-sg.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This moves dma_(un)map_sg to the get_userptr/put_userptr and alloc/put
memops of videobuf2-dma-sg.c and adds dma_sync_sg_for_device/cpu to the
prepare/finish memops.
Now that vb2-dma-sg will sync the buffers for you in the prepare/finish
memops we can drop that from the drivers that use dma-sg.
For the solo6x10 driver that was a bit more involved because it needs to
copy JPEG or MPEG headers to the buffer before returning it to userspace,
and that cannot be done in the old place since the buffer there is still
setup for DMA access, not for CPU access. However, the buf_finish
op is the ideal place to do this. By the time buf_finish is called
the buffer is available for CPU access, so copying to the buffer is fine.
[mchehab@osg.samsung.com: Fix a compilation breakage:
drivers/media/v4l2-core/videobuf2-dma-sg.c:150:19: error: 'struct vb2_dma_sg_buf' has no member named 'dma_sgt']
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Require that dma-sg also uses an allocation context. This is in preparation
for adding prepare/finish memops to sync the memory between DMA and CPU.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This is needed for the next patch where the dma-sg alloc memop needs
to know the dma_dir.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The 'write' argument is very ambiguous. I first assumed that if it is 1,
then we're doing video output but instead it meant the reverse.
Since it is used to setup the dma_dir value anyway it is now replaced by
the correct dma_dir value which is unambiguous.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The v4l2_device structure embed a v4l2_prio_state structure used by
default for priority handling, but drivers can override that default by
setting the video_dev prio pointer to a different v4l2_prio_state
instance.
However, the VIDIO_G_PRIORITY and VIDIOC_S_PRIORITY implementations use
the prio state embedded in v4l2_device unconditionally, breaking drivers
that need to override the default. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The v4l2_ctrl_check() helper function is now only used in cx2341x.
Move it there and make it static.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Several control helper functions are no longer needed since most drivers
are now converted to the control framework. So we can delete them.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
These days vdev->v4l2_dev must always be set. This means that some
old code that still tests for a NULL vdev->v4l2_dev can be removed
or simplified.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
videobuf-core.c:834:23: warning: Using plain integer as NULL pointer
videobuf-core.c:851:28: warning: Using plain integer as NULL pointer
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Similar to an earlier patch, fixing reading user-space data for the
VIDIOC_CREATE_BUFS ioctl() in 32-bit compatibility mode, this patch fixes
writing back of the possibly modified struct to the user. However, unlike
the former bug, this one is much less harmful, because it only results in
the kernel failing to write the .type field back to the user, but in fact
this is likely unneeded, because the kernel will hardly want to change
that field. Therefore this bug is more of a theoretical nature.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The warning is simple:
drivers/media/v4l2-core/v4l2-ctrls.c:1685:15: warning: incorrect type in assignment (different address spaces)
but the fix isn't.
The core problem was that the conversion from user to kernelspace was
done at too low a level and that needed to be moved up. That made it possible
to drop pointers to v4l2_ext_control from set_ctrl and validate_new and
clean up this sparse warning because those functions now always operate
on kernelspace pointers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
will assign the corresponding offset to the 'boff' field of the
videobuf_buffer for each requested buffer sequentially. Later, user
may call mmap() to map one or all of the buffers with the 'offset'
parameter which is equal to its 'boff' value. Obviously, the 'offset'
value is only used to find the matched buffer instead of to be the
real offset from the buffer's physical start address as used by
vm_iomap_memory(). So, in some case that if the offset is not zero,
vm_iomap_memory() will fail.
Signed-off-by: Fancy Fang <chen.fang@freescale.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUNr9iAAoJEAhfPr2O5OEVSygP/iVpHK7JZCFSvy1ly67gUcIw
zeO2q0Exm3WwApchaCNX0b9qB9A6jeaRiJtuqOgR7L8ksYorku7k12g0IrveK8e4
UhwscWw1HkYvTR3JG4Z2a8LoYiUatQCgcknICgjJ12fo2fCg2SnzbGp9jKiLqJew
dx1zOgn5Hslqy+PWQULtkLo/XxdlAX8YNUhXU5q5gxCfhciaJ7Kq+tvM9NodobHG
u94b10fmOclLug37b+Vpg01pxjqe+X+HbrHzbOsL7dvxW84igqzpyb9+WNH8FGZZ
+oSu66faokH8rVxzkPyODT8TSwHuqafVF1IFafsFFJpYYfRWiY0SttMACVMuuB3z
m6kVM9pTApmh736xvzB4JP4i/+aIu2qQftYTybQkTpn1AIy2kw8b09pOWbhEgdjl
5CfI7I2iSkSviZXMrIe51znIhdxohF7gEN8PyaPto3N1LHVnHAd7/J43nolSSnke
DE0lQGk+NaGFv/MiESiKC8lSiEGzqpMkrxpOIeDZAsKxQ3ihxKai3kqAYYiPt2+n
2HVhLsmfMqdd23DGSf7LjhhLqjXKhEC/+LDsLl105keRYLN/TYZuQxieJEDikRF/
NLJcuuXUQkcsdgrAChAonu1K3roAsgZ8E6BP+814CWZ5LM4xW0kQqqKN6S88eKx2
HcIz2xwveR6sZBNZE7Kl
=DUbD
-----END PGP SIGNATURE-----
Merge tag 'media/v3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
- new IR driver: hix5hd2-ir
- the virtual test driver (vivi) was replaced by vivid, with has an
almost complete set of features to emulate most v4l2 devices and
properly test all sorts of userspace apps
- the as102 driver had several bugs fixed and was properly split into a
frontend and a core driver. With that, it got promoted from staging
into mainstream
- one new CI driver got added for CIMaX SP2/SP2HF (sp2 driver)
- one new frontend driver for Toshiba ISDB-T/ISDB-S demod (tc90522)
- one new PCI driver for ISDB-T/ISDB-S (pt3 driver)
- saa7134 driver got support for go7007-based devices
- added a new PCI driver for Techwell 68xx chipsets (tw68)
- a new platform driver was added (coda)
- new tuner drivers: mxl301rf and qm1d1c0042
- a new DVB USB driver was added for DVBSky S860 & similar devices
- added a new SDR driver (hackrf)
- usbtv got audio support
- several platform drivers are now compiled with COMPILE_TEST
- a series of compiler fixup patches, making sparse/spatch happier with
the media stuff and removing several warnings, especially on those
platform drivers that didn't use to compile on x86
- Support for several new modern devices got added
- lots of other fixes, improvements and cleanups
* tag 'media/v3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (544 commits)
[media] ir-hix5hd2: fix build on c6x arch
[media] pt3: fix DTV FE I2C driver load error paths
Revert "[media] media: em28xx - remove reset_resume interface"
[media] exynos4-is: fix some warnings when compiling on arm64
[media] usb drivers: use %zu instead of %zd
[media] pci drivers: use %zu instead of %zd
[media] dvb-frontends: use %zu instead of %zd
[media] s5p-mfc: Fix several printk warnings
[media] s5p_mfc_opr: Fix warnings
[media] ti-vpe: Fix typecast
[media] s3c-camif: fix dma_addr_t printks
[media] s5p_mfc_opr_v6: get rid of warnings when compiled with 64 bits
[media] s5p_mfc_opr_v5: Fix lots of warnings on x86_64
[media] em28xx: Fix identation
[media] drxd: remove a dead code
[media] saa7146: remove return after BUG()
[media] cx88: remove return after BUG()
[media] cx88: fix cards table CodingStyle
[media] radio-sf16fmr2: declare some structs as static
[media] radio-sf16fmi: declare pnp_attached as static
...
Currently arm64 does not support PCI but it does support v4l2. Since the
PCI skeleton driver is built unconditionally as a module with no dependency
on PCI this causes build failures for arm64 allmodconfig. Fix this by
defining a symbol VIDEO_PCI_SKELETON for the skeleton and conditionalising
the build on that.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> [added VIDEO dependencies]
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
v4l_print_ext_controls() would print the 'size' if it was 0 and
'value' if size was non-zero, but it should have been the other
way around.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fix clamp_align() used in v4l_bound_align_image() to prevent overflow
when passed large value like UINT32_MAX.
In the current implementation:
clamp_align(UINT32_MAX, 8, 8192, 3)
returns 8, because in line:
x = (x + (1 << (align - 1))) & mask;
x overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192.
v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and
VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter
explicitly states that:
"The modified format should be as close as possible to the original
request."
-- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html
Thus one would expect, that passing UINT32_MAX as format width and
height will result in setting maximum possible resolution for the
device. Particularly, when the driver doesn't support
VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase.
Fixes changeset: b0d3159be9
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.
This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.
This brings the vb2 behavior in line with the old videobuf behavior.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
It's also invalid when plane_no is equal to vb->num_planes
Signed-off-by: Zhaowei Yuan <zhaowei.yuan@samsung.com>
Cc: stable@vger.kernel.org # for v3.7 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Commit bd994ddb2a (vb2: Fix stream start and
buffer completion race) broke the buffer state check in vb2_buffer_done.
So accept all three possible states there since I can no longer tell the
difference between vb2_buffer_done called from start_streaming or from
elsewhere.
Instead add a WARN_ON at the end of start_streaming that will check whether
any buffers were added to the done list, since that implies that the wrong
state was used as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@vger.kernel.org # for v3.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Recently WARN_ON() calls have been added to warn if the driver is not
properly returning buffers to vb2 in start_streaming (if it fails) or
stop_streaming(). Add comments before those WARN_ON calls that refer
to the videobuf2-core.h header that explains what drivers are supposed
to do in these situations. That should help point developers in the
right direction if they see these warnings.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If one or both of the timings being compared have the standards field
with value 0, then accept that. Only check for matching standards if
both timings have actually filled in that field.
Otherwise no match will ever be found since when timings are detected
the standards field will typically be set to 0 by the driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The V4L2_CID_PAN_SPEED and V4L2_CID_TILT_SPEED controls allow to move the
camera by setting its rotation speed around its axis.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
All the infrastructure for this is already there, and despite our desires for
the old videobuf code to go away, it is currently still in use in 18 drivers.
Allowing reqbufs(0) makes these drivers behave consistent with modern drivers,
making live easier for userspace, see e.g. :
https://bugzilla.gnome.org/show_bug.cgi?id=735660
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
(Changes since v2: dropped local variable as suggested by Laurent)
Commit f035eb4e97 (videobuf2: fix lockdep warning)
unfortunately removed the mmap_sem lock that is needed around the call to
__qbuf_userptr. Amazingly nobody noticed this (especially me as the author)
until Jan Kara pointed this out to me.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Jan Kara <jack@suse.cz>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
A lot of these warnings are caused by the fact that we don't generally use
__user in videodev2.h. Normally the video_usercopy function will copy anything
pointed to by pointers into kernel space, so having __user in the struct will only
cause lots of warnings in the drivers. But the flip side of that is that you
need to add __force casts here.
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:337:26: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:337:30: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:338:31: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:338:49: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:343:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:346:21: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:349:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:349:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:352:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:352:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:363:26: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:363:32: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:364:31: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:364:51: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:371:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:371:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:376:35: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:376:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:430:30: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:433:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:433:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:501:24: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:507:48: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:507:56: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:565:18: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:670:22: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:680:29: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:692:55: warning: incorrect type in initializer (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:773:18: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:786:30: warning: incorrect type in argument 1 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:786:44: warning: incorrect type in argument 2 (different address spaces)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:674:37: warning: dereference of noderef expression
drivers/media/v4l2-core/v4l2-compat-ioctl32.c:718:37: warning: dereference of noderef expression
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
drivers/media/v4l2-core/v4l2-ioctl.c:1156:53: warning: incorrect type in initializer (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:1158:42: warning: incorrect type in initializer (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:1161:34: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:1163:35: warning: incorrect type in assignment (different address spaces)
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
If this is a multiplanar buf_type and the plane we want to read has a
non-zero data_offset, then that data_offset was not taken into account.
Note that read() or write() for formats with more than one plane is currently
not allowed, hence the use of 'planes[0]' since this is only relevant for a
single-plane format.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Modern kernels enable dynamic printk support, which is fine, except when it is
combined with a debug module option. Enabling debug in videobuf2-core now produces
no debugging unless it is also enabled through the dynamic printk support in debugfs.
Either use a debug module option + pr_info, or use pr_debug without a debug module
option. In this case the fact that you can set various debug levels is very useful,
so I believe that for videobuf2-core.c we should use pr_info.
The mix of the two is very confusing: I've spent too much time already trying to
figure out why I am not seeing any debug output in the kernel log when I do:
echo 1 >/sys/modules/videobuf2_core/parameters/debug
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The following lockdep warning has been there ever since commit a517cca6b2
one year ago:
[ 403.117947] ======================================================
[ 403.117949] [ INFO: possible circular locking dependency detected ]
[ 403.117953] 3.16.0-rc6-test-media #961 Not tainted
[ 403.117954] -------------------------------------------------------
[ 403.117956] v4l2-ctl/15377 is trying to acquire lock:
[ 403.117959] (&dev->mutex#3){+.+.+.}, at: [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.117974]
[ 403.117974] but task is already holding lock:
[ 403.117976] (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
[ 403.117987]
[ 403.117987] which lock already depends on the new lock.
[ 403.117987]
[ 403.117990]
[ 403.117990] the existing dependency chain (in reverse order) is:
[ 403.117992]
[ 403.117992] -> #1 (&mm->mmap_sem){++++++}:
[ 403.117997] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118006] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
[ 403.118010] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
[ 403.118014] [<ffffffff8118c9ec>] might_fault+0x7c/0xb0
[ 403.118018] [<ffffffffa0028a25>] video_usercopy+0x425/0x610 [videodev]
[ 403.118028] [<ffffffffa0028c25>] video_ioctl2+0x15/0x20 [videodev]
[ 403.118034] [<ffffffffa0022764>] v4l2_ioctl+0x184/0x1a0 [videodev]
[ 403.118040] [<ffffffff811d77d0>] do_vfs_ioctl+0x2f0/0x4f0
[ 403.118307] [<ffffffff811d7a51>] SyS_ioctl+0x81/0xa0
[ 403.118311] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
[ 403.118319]
[ 403.118319] -> #0 (&dev->mutex#3){+.+.+.}:
[ 403.118324] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
[ 403.118329] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118333] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
[ 403.118336] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
[ 403.118340] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
[ 403.118344] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118349] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
[ 403.118354] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
[ 403.118359] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
[ 403.118363] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
[ 403.118366] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
[ 403.118369] [<ffffffff810085c2>] SyS_mmap+0x22/0x30
[ 403.118376] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
[ 403.118381]
[ 403.118381] other info that might help us debug this:
[ 403.118381]
[ 403.118383] Possible unsafe locking scenario:
[ 403.118383]
[ 403.118385] CPU0 CPU1
[ 403.118387] ---- ----
[ 403.118388] lock(&mm->mmap_sem);
[ 403.118391] lock(&dev->mutex#3);
[ 403.118394] lock(&mm->mmap_sem);
[ 403.118397] lock(&dev->mutex#3);
[ 403.118400]
[ 403.118400] *** DEADLOCK ***
[ 403.118400]
[ 403.118403] 1 lock held by v4l2-ctl/15377:
[ 403.118405] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
[ 403.118411]
[ 403.118411] stack backtrace:
[ 403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 3.16.0-rc6-test-media #961
[ 403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 403.118420] ffffffff82a6c9d0 ffff8800af37fb00 ffffffff819916a2 ffffffff82a6c9d0
[ 403.118425] ffff8800af37fb40 ffffffff810d5715 ffff8802308e4200 0000000000000000
[ 403.118429] ffff8802308e4a48 ffff8802308e4a48 ffff8802308e4200 0000000000000001
[ 403.118433] Call Trace:
[ 403.118441] [<ffffffff819916a2>] dump_stack+0x4e/0x7a
[ 403.118445] [<ffffffff810d5715>] print_circular_bug+0x1d5/0x2a0
[ 403.118449] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
[ 403.118455] [<ffffffff8119c172>] ? find_vmap_area+0x42/0x70
[ 403.118459] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
[ 403.118463] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
[ 403.118468] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
[ 403.118472] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118476] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118480] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
[ 403.118484] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118488] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118493] [<ffffffff810d8055>] ? mark_held_locks+0x75/0xa0
[ 403.118497] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
[ 403.118502] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
[ 403.118506] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
[ 403.118510] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
[ 403.118513] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
[ 403.118517] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
[ 403.118521] [<ffffffff810085c2>] SyS_mmap+0x22/0x30
[ 403.118525] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
The reason is that vb2_fop_mmap and vb2_fop_get_unmapped_area take the core lock
while they are called with the mmap_sem semaphore held. But elsewhere in the code
the core lock is taken first but calls to copy_to/from_user() can take the mmap_sem
semaphore as well, potentially causing a classical A-B/B-A deadlock.
However, the mmap/get_unmapped_area calls really shouldn't take the core lock
at all. So what would happen if they don't take the core lock anymore?
There are two situations that need to be taken into account: calling mmap while
new buffers are being added and calling mmap while buffers are being deleted.
The first case works almost fine without a lock: in all cases mmap relies on
correctly filled-in q->num_buffers/q->num_planes values and those are only
updated by reqbufs and create_buffers *after* any new buffers have been
initialized completely. Except in one case: if an error occurred while allocating
the buffers it will increase num_buffers and rely on __vb2_queue_free to
decrease it again. So there is a short period where the buffer information
may be wrong.
The second case definitely does pose a problem: buffers may be in the process
of being deleted, without the internal structure being updated.
In order to fix this a new mutex is added to vb2_queue that is taken when
buffers are allocated or deleted, and in vb2_mmap. That way vb2_mmap won't
get stale buffer data. Note that this is a problem only for MEMORY_MMAP, so
even though __qbuf_userptr and __qbuf_dmabuf also mess around with buffers
(mem_priv in particular), this doesn't clash with vb2_mmap or
vb2_get_unmapped_area since those are MMAP specific.
As an additional bonus the hack in __buf_prepare, the USERPTR case, can be
removed as well since mmap() no longer takes the core lock.
All in all a much cleaner solution.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The "i--" needs to happen at the start of the loop or it will try to
release something bogus (probably it will crash) and it won't release
the first ->vaddr_page[].
Fixes: 7b4eeed174 ('[media] vmalloc_sg: make sure all pages in vmalloc area are really DMA-ready')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The field order must match between the source and sink pads, or the sink
pad field order must be NONE. This allows connecting an interlaced
source to a bridge that has no hardware support for interlaced formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Enrico Butera <ebutera@users.sourceforge.net>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
In many cases the test pattern has selectable values for each colour
component. Implement controls for raw bayer components. Additional controls
should be defined for colour components that are not covered by these
controls.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
While several tuners have some sort of suspend/resume
implementation, this is currently mangled with an optional
.sleep callback that it is also used to put the device on
low power mode.
Not all drivers implement it, as returning the driver from
low power may require to re-load the firmware, with takes
some time. Also, some drivers may delay it.
So, the more coherent is to add two new optional callbacks
that will let the tuners to directy implement suspend and
resume callbacks if they need.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Pull media updates from Mauro Carvalho Chehab:
- removal of sn9c102. This device driver was replaced a long time ago
by gspca
- solo6x10 and go7007 webcam drivers moved from staging into
mainstream. They were waiting for an API to allow setting the image
detection matrix
- SDR drivers moved from staging into mainstream: sdr-msi3101 (renamed
as msi2500) and rtl2832
- added SDR driver for airspy
- added demux driver: si2165
- rework at several RC subsystem, making the code for RC-5 SZ variant
to be added at the standard RC5 decoder
- added decoder for the XMP IR protocol
- tuner driver moved from staging into mainstream: msi3101 (renamed as
msi001)
- added documentation for some additional SDR pixfmt
- some device tree bindings documented
- added support for exynos3250 at s5p-jpeg
- remove the obsolete, unmaintained and broken mx1_camera driver
- added support for remote controllers at au0828 driver
- added a RC driver: sunxi-cir
- several driver fixes, enhancements and cleanups.
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (455 commits)
[media] cx23885: fix UNSET/TUNER_ABSENT confusion
[media] coda: fix build error by making reset control optional
[media] radio-miropcm20: fix sparse NULL pointer warning
[media] MAINTAINERS: Update go7007 pattern
[media] MAINTAINERS: Update solo6x10 patterns
[media] media: atmel-isi: add primary DT support
[media] media: atmel-isi: convert the pdata from pointer to structure
[media] media: atmel-isi: add v4l2 async probe support
[media] rcar_vin: add devicetree support
[media] media: pxa_camera device-tree support
[media] media: mt9m111: add device-tree suppport
[media] soc_camera: add support for dt binding soc_camera drivers
[media] media: soc_camera: pxa_camera documentation device-tree support
[media] media: mt9m111: add device-tree documentation
[media] s5p-mfc: remove unnecessary calling to function video_devdata()
[media] s5p-jpeg: add chroma subsampling adjustment for Exynos3250
[media] s5p-jpeg: Prevent erroneous downscaling for Exynos3250 SoC
[media] s5p-jpeg: Assure proper crop rectangle initialization
[media] s5p-jpeg: fix g_selection op
[media] s5p-jpeg: Adjust jpeg_bound_align_image to Exynos3250 needs
...
Here's the big driver-core pull request for 3.17-rc1.
Largest thing in here is the dma-buf rework and fence code, that touched
many different subsystems so it was agreed it should go through this
tree to handle merge issues. There's also some firmware loading
updates, as well as tests added, and a few other tiny changes, the
changelog has the details.
All have been in linux-next for a long time.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlPf1XcACgkQMUfUDdst+ylREACdHLXBa02yLrRzbrONJ+nARuFv
JuQAoMN49PD8K9iMQpXqKBvZBsu+iCIY
=w8OJ
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here's the big driver-core pull request for 3.17-rc1.
Largest thing in here is the dma-buf rework and fence code, that
touched many different subsystems so it was agreed it should go
through this tree to handle merge issues. There's also some firmware
loading updates, as well as tests added, and a few other tiny changes,
the changelog has the details.
All have been in linux-next for a long time"
* tag 'driver-core-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits)
ARM: imx: Remove references to platform_bus in mxc code
firmware loader: Fix _request_firmware_load() return val for fw load abort
platform: Remove most references to platform_bus device
test: add firmware_class loader test
doc: fix minor typos in firmware_class README
staging: android: Cleanup style issues
Documentation: devres: Sort managed interfaces
Documentation: devres: Add devm_kmalloc() et al
fs: debugfs: remove trailing whitespace
kernfs: kernel-doc warning fix
debugfs: Fix corrupted loop in debugfs_remove_recursive
stable_kernel_rules: Add pointer to netdev-FAQ for network patches
driver core: platform: add device binding path 'driver_override'
driver core/platform: remove unused implicit padding in platform_object
firmware loader: inform direct failure when udev loader is disabled
firmware: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN
firmware: read firmware size using i_size_read()
firmware loader: allow disabling of udev as firmware loader
reservation: add suppport for read-only access using rcu
reservation: update api and add some helpers
...
Conflicts:
drivers/base/platform.c
Commit 958c7c7e65 ("[media] v4l2-ctrls: fix corner case in round-to-range code") broke
controls that use a negative range.
The cause was a s32/u32 mixup: ctrl->step is unsigned while all others are signed. So
the result type of the expression '(ctrl)->maximum - ((ctrl)->step / 2)' became unsigned,
making 'val >= (ctrl)->maximum - ((ctrl)->step / 2)' true, since '((u32)-128) > 128'
(if val = -128, maximum = 128 and step = 1).
So carefully cast (step / 2) to s32.
There was one cast of step to s32 where it should have been u32 because both offset and
step are unsigned, so casting to signed makes no sense there. You do need a cast to u32
there, because otherwise architectures that have no 64-bit division start complaining
(step is a u64).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Hans Verkuil