From now on, I'll start using my @kernel.org as my development e-mail.

As such, let's remove the entries that point to the old
mchehab@s-opensource.com at MAINTAINERS file.

For the files written with a copyright with mchehab@s-opensource,
let's keep Samsung on their names, using mchehab+samsung@kernel.org,
in order to keep pointing to my employer, with sponsors the work.

For the files written before I join Samsung (on July, 4 2013),
let's just use mchehab@kernel.org.

For bug reports, we can simply point to just kernel.org, as
this will reach my mchehab+samsung inbox anyway.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NBrian Warner <brian.warner@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Looks like the word "contiguous" is often mistyped.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Now that the input fields got removed from the userspace API,
there's no sense to keep there at the VB struct. Remove it.

Cc: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

videobuf_waiton() must unlock and relock ext_lock if it has to wait.
For that to happen it needs the videobuf_queue pointer.

Don't attempt to unlock/relock q->ext_lock unless it was locked in the
first place.

vb->state has to be protected by a spinlock to be safe.

This patch is based on code from Mauro Carvalho Chehab <mchehab@redhat.com>.

[mchehab@redhat.com: add extra argument to a few missing places]
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add an ext_lock argument to the videobuf init functions. This allows
drivers to pass the vdev->lock pointer (or any other externally held lock)
to videobuf. For now all drivers just pass NULL.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
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>

The fields are assigned but never used, remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

These functions allocate videobuf_buffer structures only. Renaming in order
to prevent confusion with functions allocating actual video buffer memory.

Rename the functions in videobuf-core.h videobuf-dma-sg.c as well.
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

mmap_mapper should operate on a buffer, not on a complete queue. So let
the videobuf-core find the correct buffer instead of duplicating that
code in each mmap_mapper implementation.

The dma-sg implementation has backwards compatibility code for handling
the V4L1_COMPAT layer. This code is now under the v4L1_COMPAT config option.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The video_copy_to_user and copy_stream ops are almost identical for all
videobuf memtype variants. All that is needed is to use the new vaddr
op and these functions can be moved into the core, ensuring we have just
one single implementation instead of three.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Ths function returns the virtual kernel address of the buffer and has
nothing to do with allocation.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rename the .vmalloc op in struct videobuf_qtype_ops to .vaddr. This op returns
the virtual kernel address of a buffer. vaddr is a lot less confusing than
vmalloc since this callback does do any allocations.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

videobuf_alloc() returned a void *. Change to struct videobuf_buffer *
to get better type checking.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Pawel Osciak for noticing this.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove the mmap_free callback from struct videobuf_qtype_ops.

All implementations of this callback do the same trivial check: return
-EBUSY if any buffer is mmapped. That can also be tested in the
videobuf core.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The mmap callback in struct videobuf_qtype_ops is never used.
Remove.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make videobuf pass checkpatch; minor code cleanups.
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The videobuf_queue_ops function vector is not declared constant, but
there's no need for the videobuf layer to ever change it.  Make it const
so that videobuf users can make their operations const without warnings.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vidiocgmbuf() does this:
        mutex_lock(&fh->cap.vb_lock);
        retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
                                     V4L2_MEMORY_MMAP);

and videobuf_mmap_setup() then just does
        mutex_lock(&q->vb_lock);
        ret = __videobuf_mmap_setup(q, bcount, bsize, memory);
        mutex_unlock(&q->vb_lock);

which is an obvious double-take deadlock.

This patch fixes this by having vidiocgmbuf() just call the
__videobuf_mmap_setup function instead.
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Reported-by: NKoos Vriezen <koos.vriezen@gmail.com>
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

videobuf-dvb were still using a function that were videobuf-dma-sg
dependent. This patch creates a generic handler for this function. This
way, videobuf-dvb can now work with all videobuf implementations.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Add a waitqueue to wait on when there are no buffers in the buffer queue.
DQBUF waits on this queue without holding vb_lock to allow a QBUF to happen.
Once a buffer has been queued we recheck that the queue is still streaming and
wait on the new buffer's waitqueue while holding the vb_lock.  The driver
should come along in a timely manner and put the buffer into its next state
finishing the DQBUF.

By implementing this waitqueue it also brings the videobuf DQBUF up to spec and
it now blocks on O_NONBLOCK even when no buffers have been queued via QBUF:

"By default VIDIOC_DQBUF blocks when no buffer is in the outgoing queue."
 - V4L2 spec
Signed-off-by: NBrandon Philips <bphilips@suse.de>
CC: Trent Piepho <xyzzy@speakeasy.org>
CC: Carl Karsten <carl@personnelware.com>
CC: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Make the dev member of the struct videobuf_queue of type "struct device *"
to avoid future problems. Also change the prototype of the
videobuf_queue_core_init() function.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This helps to identify where vb_lock is being used, and find missusages of the
locks.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

In order to videobuf_iolock to work, mmap_mapper should be called first.
Otherwise, an OOPS is generated.

On some cases, .mmap file handler used to took some time to be called. On those
situations, mmap_mmapper() were called after iolock.

This patch properly waits for mmap_mapper to be called, otherwise generating an
error.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

s/STATE_NEEDS_INIT/VIDEOBUF_NEEDS_INIT/g
s/STATE_PREPARED/VIDEOBUF_PREPARED/g
s/STATE_QUEUED/VIDEOBUF_QUEUED/g
s/STATE_ACTIVE/VIDEOBUF_ACTIVE/g
s/STATE_DONE/VIDEOBUF_DONE/g
s/STATE_ERROR/VIDEOBUF_ERROR/g
s/STATE_IDLE/VIDEOBUF_IDLE/g
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Add comments to functions that require that caller hold q->lock
- Add __videobuf_mmap_free that doesn't hold q->lock for use within videobuf
- Add locking to videobuf_mmap_free
- Fix linux/drivers/media/common/saa7146_video.c which was holding lock around
  videobuf_read_stop
- Add locking to functions that operate on a queue
- Add videobuf_stop to take care of stopping in both the read and stream case

TODO: bttv still has an unsafe call to videobuf_queue_is_busy
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Breaks on any target that has copy_to_user() defined as a non-trivial
macro.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In the past, videobuf_queue_init were used to initialize PCI DMA videobuffers.
This patch renames it, to avoid confusion with the previous kernel API, doing:
	s/videobuf_queue_init/void videobuf_queue_core_init/

Also, the operations is now part of the function parameter. The function will
also add a test if this is defined, otherwise producing BUG.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Before the videobuf redesign, a procedure for re-using videobuf without PCI
scatter/gather where provided by changing the pci-dependent operations by
other operations.

With the newer approach, those methods are obsolete and can safelly be removed.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981Reviewed-by: NRicardo Cerqueira <v4l@cerqueira.org>

video-buf currently does two different tasks:

- Manages video buffers with a common code that allows
  implementing all the V4L2 different modes of buffering;

- Controls memory allocations

While the first task is generic, the second were written to support PCI DMA
Scatter/Gather needs. The original approach can't even work for those
video capture hardware that don't support scatter/gather.

I did one approach to make it more generic. While the approach worked
fine for vivi driver, it were not generic enough to handle USB needs.

This patch creates two different modules, one containing the generic
video buffer handling (videobuf-core) and another with PCI DMA S/G.
After this patch, it would be simpler to write an USB video-buf and a
non-SG DMA module.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981Reviewed-by: NRicardo Cerqueira <v4l@cerqueira.org>

Before this patch, vivi were simulating a scatter gather DMA transfer.
While this is academic, showing how stuff really works on a real PCI 
device, this means a non-optimized code. 
There are only two memory models that vivi implements:
	1) kernel alloced memory. This is also used by read() method.
	   On this case, a vmalloc32 buffer is allocated at kernel;
	2) userspace allocated memory. This is used by most userspace apps.
	   video-buf will store this pointer.
	   a simple copy_to_user is enough to transfer data.
The third memory model scenario supported by video-buf is overlay mode. 
This model is not implemented on vivi and unlikely to be implemented on 
newer drivers, since now, most userspace apps do some post-processing 
(like de-interlacing).
After this patch, some cleanups may be done at video-buf.c to avoid 
allocating pages, when the driver doesn't need a PCI buffer. This is the 
case of vivi and usb drivers.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Videodev now is capable of better handling V4L2 api, by
processing V4L2 ioctls and using callbacks to the driver.
The drivers should be migrated to the newer way and the older
one will be obsoleted soon.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Video_buf were concerned to allow PCI devices to be used as
video capture devices. This patch extends video_buf features
by virtualizing pci-dependent functions and allowing other
type of devices to use it.
It is still DMA centric, although it may be used also by
devices that emulates scatter/gather behavior or a DMA device
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Some changes to allow compiling cx88 and saa7134 without V4L1 support.
- This patch will help obsoleting V4L1 API.
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>