The v4l2_m2m_fop_mmap function takes the core mutex, but this will result in a potential
circular locking dependency:

[  262.517164] ======================================================
[  262.517166] [ INFO: possible circular locking dependency detected ]
[  262.517169] 4.2.0-rc2-koryphon #844 Not tainted
[  262.517171] -------------------------------------------------------
[  262.517173] v4l2-compliance/1379 is trying to acquire lock:
[  262.517175]  (&dev->dev_mutex){+.+.+.}, at: [<ffffffffa000ddab>] v4l2_m2m_fop_mmap+0x2b/0x90 [v4l2_mem2mem]
[  262.517187]
               but task is already holding lock:
[  262.517189]  (&mm->mmap_sem){++++++}, at: [<ffffffff81159309>] vm_mmap_pgoff+0x69/0xc0
[  262.517199]
               which lock already depends on the new lock.

[  262.517202]
               the existing dependency chain (in reverse order) is:
[  262.517204]
               -> #1 (&mm->mmap_sem){++++++}:
[  262.517209]        [<ffffffff810d0e6b>] __lock_acquire+0x62b/0xe80
[  262.517215]        [<ffffffff810d2095>] lock_acquire+0x65/0x90
[  262.517218]        [<ffffffff811612e5>] __might_fault+0x75/0xa0
[  262.517222]        [<ffffffffa06dead9>] video_usercopy+0x3e9/0x4e0 [videodev]
[  262.517231]        [<ffffffffa06debe0>] video_ioctl2+0x10/0x20 [videodev]
[  262.517238]        [<ffffffffa06d8663>] v4l2_ioctl+0xc3/0xe0 [videodev]
[  262.517243]        [<ffffffff811a8cac>] do_vfs_ioctl+0x2fc/0x550
[  262.517248]        [<ffffffff811a8f74>] SyS_ioctl+0x74/0x80
[  262.517252]        [<ffffffff81a4d2ee>] entry_SYSCALL_64_fastpath+0x12/0x76
[  262.517258]
               -> #0 (&dev->dev_mutex){+.+.+.}:
[  262.517262]        [<ffffffff810cf464>] validate_chain.isra.38+0xd04/0x1170
[  262.517266]        [<ffffffff810d0e6b>] __lock_acquire+0x62b/0xe80
[  262.517270]        [<ffffffff810d2095>] lock_acquire+0x65/0x90
[  262.517273]        [<ffffffff81a48e3c>] mutex_lock_interruptible_nested+0x6c/0x4b0
[  262.517279]        [<ffffffffa000ddab>] v4l2_m2m_fop_mmap+0x2b/0x90 [v4l2_mem2mem]
[  262.517284]        [<ffffffffa06d80ff>] v4l2_mmap+0x4f/0x90 [videodev]
[  262.517288]        [<ffffffff8116b06c>] mmap_region+0x38c/0x5b0
[  262.517293]        [<ffffffff8116b585>] do_mmap_pgoff+0x2f5/0x3e0
[  262.517297]        [<ffffffff8115932a>] vm_mmap_pgoff+0x8a/0xc0
[  262.517300]        [<ffffffff81169bab>] SyS_mmap_pgoff+0x1cb/0x270
[  262.517304]        [<ffffffff8100876d>] SyS_mmap+0x1d/0x20
[  262.517309]        [<ffffffff81a4d2ee>] entry_SYSCALL_64_fastpath+0x12/0x76
[  262.517313]
               other info that might help us debug this:

[  262.517315]  Possible unsafe locking scenario:

[  262.517318]        CPU0                    CPU1
[  262.517319]        ----                    ----
[  262.517321]   lock(&mm->mmap_sem);
[  262.517324]                                lock(&dev->dev_mutex);
[  262.517327]                                lock(&mm->mmap_sem);
[  262.517329]   lock(&dev->dev_mutex);
[  262.517332]
                *** DEADLOCK ***

Since vb2_fop_mmap doesn't take the lock, neither should v4l2_m2m_fop_mmap.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NMikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The queue owner will be used by videobuf2 trace events to determine and
record the device minor number. It is set in v4l2_m2m_reqbufs instead of
v4l2_m2m_ioctl_reqbufs because several drivers implement their own
vidioc_reqbufs handlers that still call v4l2_m2m_reqbufs directly.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This was never added for some reason, so add it now.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The first time b is used, it is assigned to the first element of the rdy_queue
list. There is no need to set it to NULL before.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Some drivers might allow to decode remaining frames from an internal ringbuffer
after a decoder stop command. Allow those to call v4l2_m2m_try_schedule
directly.
Signed-off-by: NMichael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch makes the queue lock taken in v4l2_m2m_poll interruptible.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch adds ioctl helpers to the V4L2 mem-to-mem API, so we can avoid
several ioctl handlers in the mem-to-mem video node drivers that are simply
a pass-through to the v4l2_m2m_* calls. These helpers will only be useful
for drivers that use same mutex for both OUTPUT and CAPTURE queue, which
is the case for all currently in tree v4l2 m2m drivers. In order to use
the helpers the drivers are required to use struct v4l2_fh.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When the current context is running,
1] If release is called, it waits until the job is finished.
2] As soon as the job is finished, v4l2_mem_ctx_release()tries to
   release the vb2 queues.
3] But if the current context can be scheduled in the v4l2_m2m_job_finish()
   it schedules the context and tries to call device_run().
4] As the release() and device_run() sequence can't be predicted sometimes
   device_run() may get empty vb2 buffers.

This patch adds the ABORT state to the job_flags. Once the job_abort() or
release() is called on the context, the same context will not be scheduled in
the v4l2_m2m_job_finish().
Signed-off-by: NShaik Ameer Basha <shaik.ameer@samsung.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

v4l2_m2m_streamoff drops the list of ready buffers but failed to reset the
num_rdy counter to zero. This would lead to v4l2_m2m_num_src/dst_bufs_ready
reporting wrong values after streamoff.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Just clearing the m2m_ctx->queue list_head will leave the m2m_dev->job_queue
in a broken state and can cause scheduling of device_runs after streamoff was
called.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

When streamoff is called on the context and the context
is added to the job_queue,
1] sometimes device_run receives the empty vb2 buffers (as
   v4l2_m2m_streamoff is dropping the ready queue).
2] sometimes v4l2_m2m_job_finish may not succeed as the m2m_dev->curr_ctx
   is made NULL in the v4l2_m2m_streamoff()
The above points may stop the execution of the other queued contexts.
This patch makes sure that before streamoff is executed on any context,
that context should "not be running" or "not queued" in the job_queue.
1] If the current context is running, then abort job will be called.
2] If the current context is queued, then the context will be removed from
   the job_queue.
Signed-off-by: NShaik Ameer Basha <shaik.ameer@samsung.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

On mem2mem decoders with a hardware bitstream ringbuffer, to drain the
buffer at the end of the stream, remaining frames might need to be decoded
from the bitstream buffer without additional input buffers being provided.
To achieve this, allow a queue to be marked as buffered by the driver, and
allow scheduling of device_runs when buffered ready queues are empty.
This also allows a driver to copy input buffers into their bitstream
ringbuffer and immediately mark them as done to be dequeued.
The motivation for this patch is hardware assisted h.264 reordering support
in the coda driver. For high profile streams, the coda can hold back
out-of-order frames, causing a few mem2mem device runs in the beginning, that
don't produce any decompressed buffer at the v4l2 capture side. At the same
time, the last few frames can be decoded from the bitstream with mem2mem device
runs that don't need a new input buffer at the v4l2 output side. The decoder
command ioctl can be used to put the decoder into the ringbuffer draining
end-of-stream mode.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Save flags correctly when taking spinlocks in v4l2_m2m_try_schedule.
Signed-off-by: NJohn Sheu <sheu@google.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The v4l2_m2m_poll() does not need to wait if there is already a buffer in
done_list of source and destination queues, but current v4l2_m2m_poll() always
waits. So done_list of each queue is checked before calling poll_wait().
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When a v4l2-mem2mem context gets a STREAMOFF call on either its CAPTURE
or OUTPUT queues, we should:
* Drop the corresponding rdy_queue, since a subsequent STREAMON expects
  an empty queue.
* Deschedule the context, as it now has at least one empty queue and
  cannot run.
Signed-off-by: NJohn Sheu <sheu@google.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In v4l2_m2m_try_schedule(), use the CAPTURE queue lock when accessing
the CAPTURE queue, instead of relying on just holding the OUTPUT queue
lock.
Signed-off-by: NJohn Sheu <sheu@google.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The mem2mem core doesn't change struct m2m_ops, provided by the driver,
make references to it const.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds extension to videobuf2-core. It allow to export an mmap buffer
as a DMABUF file descriptor.
Signed-off-by: NTomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

See following thread for rationale:
	http://www.spinics.net/lists/linux-media/msg52462.html
Tested by compilation only.
Signed-off-by: NNicolas Thery <nicolas.thery@st.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use list_first_entry instead of list_entry which makes the intention
of the code more clear.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the v4l2 core is mixed together with other non-core drivers.
Move them into a separate directory.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

v4l2_m2m_poll didn't support events, but that's essential if you want to
be able to use control events for example.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch removes the possible NULL pointer dereference in mem2mem
code.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Port memory-to-memory framework to videobuf2 framework.

Add support for multi-planar Video for Linux 2 API extensions to the
memory-to-memory driver framework.

Based on the original patch written by Pawel Osciak.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently videobuf uses the vb_lock mutex to lock its data structures.
But this locking will (optionally) move into the v4l2 core, which means
that in that case vb_lock shouldn't be used since the external lock is already
held.

Prepare for this by adding a pointer to such an external mutex and
don't lock if that pointer is set.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both their source and destination data. This
is different from existing drivers, which utilize memory buffers for either
input or output, but not both.

In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type.

Examples of such devices would be: image 'resizers', 'rotators',
'colorspace converters', etc.

This patch adds a separate Kconfig sub-menu for mem-to-mem devices as well.
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NVaibhav Hiremath <hvaibhav@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>