drivers/media/video/v4l2-common.c:719:16: warning: Using plain integer as NULL pointer
drivers/media/video/au0828/au0828-dvb.c:122:19: warning: Using plain integer as NULL pointer
drivers/media/video/ivtv/ivtv-yuv.c:1101:22: warning: Using plain integer as NULL pointer
drivers/media/video/ivtv/ivtv-yuv.c:1102:23: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-audio.c:78:39: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-video-v4l.c:84:39: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-v4l2.c:1264:9: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-context.c:197:28: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c:126:39: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-dvb.c:133:32: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-dvb.c:145:31: warning: Using plain integer as NULL pointer
drivers/media/video/pvrusb2/pvrusb2-dvb.c:177:55: warning: Using plain integer as NULL pointer
drivers/media/video/videobuf-core.c:100:9: warning: Using plain integer as NULL pointer
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.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>

A spinlock is necessary for queue_cancel to work with every driver in the tree.
Otherwise a race exists between IRQ handlers removing buffers from the queue
and queue_cancel invalidating the queue.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Before the patch, there were a risk of freeing and unmapping userspace memory,
while there were pending requests.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

There were some bugs on videobuf-vmalloc.

Basically, remap were called with a wrong parameter. Due to that, a later remap
were needed, generating the need of some hacks on videobuf-vmalloc and
videobuf-core.

This patch fixes the remap and removes the hacks.

TODO:

- V4L2_MEMORY_USERPTR is not implemented yet. This method should be
  properly implemented, in order to work with a few userspace applications.

- The driver also doesn't implement V4L2_MEMORY_OVERLAY. This method is used
  only by a few applications, and are becaming obsolete, due to the increment
  of cpu performance. So, most apps prefer to retrieve data to an internal
  buffer, doing some processing like de-interlacing.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
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>

Possible missed wakeup- use kernel helpers for wait queues
  http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg27983.htmlSigned-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The waitqueues must be woken up every time state changes.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

flags used for spinlocks don't need to be initialized, except where the
compiler has no way to see, that the spin_unlock_irqrestore is only called
if the spin_lock_irqsave has been called before. Local variable
initialization doesn't have to be protected.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
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>

Avoid a deadlock where DQBUF is holding the vb_lock while waiting on a QBUF
which also needs the vb_lock.  Reported by Hans Verkuil <hverkuil@xs4all.nl>.
Signed-off-by: NBrandon Philips <bphilips@suse.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>

Changeset 7e65d6e8f6df removed a very bad hack on mmap(). However, the fixes
weren't considering usermap and overlay memory models. This were breaking
direct reading from /dev/video?, used mostly by mpeg aware drivers.

Thanks to Steven Toth <stoth@linuxtv.org> for reporting the issue and
bissecting it.
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>

Thanks to Jean Delvare <khali@linux-fr.org> for pointing this.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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>

After commit 19fb1457 the callers in
videobuf-core.c that already hold the lock must call
__videobuf_read_start() instead of videobuf_read_start().
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

videobuf_dvb needs videobuf_read_start. The EXPORT_SYMBOL_GPL() were removed by
a previous patch. However, videobuf_dvb needs this.

This patch re-adds videobuf_read_start, doing the proper lock.
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>

As videobuf_cgmbuf is defined only if CONFIG_VIDEO_V4L1_COMPAT is enabled,
move the EXPORT_SYMBOL_GPL declaration inside the #ifdef block.  Fixes
compilation for x86_64 defconfig.
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
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>

The rest of V4L files.

There is one list_for_each+list_entry in cpia_pp.c that
wasn't changed because it expects the loop iterator to remain NULL if
the list is empty.

A bug in vivi is fixed; the 'safe' version needs to be used because the loop
deletes the list entries.

Simplify a second loop in vivi and get rid if an un-used variable in that loop.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The return value of videobuf_alloc() is unchecked but this function will
return NULL on an error.  Check for NULL and make videobuf_reqbufs()
return the number of successfully allocated buffers.

Also, fix saa7146_video.c and bttv-driver.c to use this returned
buffer count.

Tested against the vivi driver.  Not tested against saa7146 or bt8xx
devices.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.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>

This workaround fix a bug that happens on some SMP machines. On those machines,
videobuf_iolock is called too soon, before file .mmap handler. This patch calls
the scheduler before iolocking, allowing it to properly call the pending mmap.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

If videobuf_read_stream reads two or more buffers it was overwriting the first one
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
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>

The reading/streaming fields are used for mutual exclusion of the queue and
should be protected by the queue lock.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
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>

videobuf_qbuf takes q->lock, and then calls
q->ops->buf_prepare which by design in all drivers calls
videobuf_iolock which calls videobuf_dma_init_user and this
takes current->mm->mmap_sem

on the other hand if user calls mumap from other thread, sys_munmap
takes current->mm->mmap_sem and videobuf_vm_close takes q->lock

Since this can occur only for V4L2_MEMORY_MMAP buffers, take
current->mm->mmap_sem in qbuf, before q->lock, and don't take
current->mm->mmap_sem videobuf_dma_init_user for those buffers
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981Reviewed-by: NRicardo Cerqueira <v4l@cerqueira.org>
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>

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>

Since at least kernel 2.6.12-rc2, module.h includes moduleparm.h. This
patch removes all occurences of moduleparm.h from drivers/media files.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

videobuf_qbuf queues buffers to q->stream but does not properly check
the state of the buffer before queueing. It was possible to queue
buffers that already were in the queue.
Only buffers that are in states STATE_NEEDS_INIT and STATE_IDLE can be
queued.
Signed-off-by: NSakari Ailus <sakari.ailus@nokia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.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>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.
Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

We have a DMA32 zone now, lets use it to make sure the card
can reach the memory we have allocated for the video frame
buffers.
Signed-off-by: NGerds Hoffmann <kraxel@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Using a double cast to avoid compiler warnings when building for PAE. 
Compiler doesn't like direct casting of a 32 bit ptr to 64 bit integer.
Signed-off-by: NMartin J. Bligh <mbligh@google.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

After the recent video-buf "generic" adaptation, the PCI wrappers got
completely broken, and all of the DMA sound modules stopped working (and
failed with an oops)
Signed-off-by: NRicardo Cerqueira <v4l@cerqueira.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>