Staging: Yet another (third) dt3155 driver PCI/video4linux compliant

Staging: Yet another (third) dt3155 driver PCI/video4linux compliant

Kernel module (device driver) for dt3155 frame grabber
video4linux2 compliant (finally). Works with "xawtv -f".

======================================================

This driver is written (almost) from scratch, using the
allocator developed for dt3155pci see bellow). The driver
uses videobuf-dma-contig interface modified to use the above
mentioned allocator instead of dma_alloc_coheren().

The first thing to do was to design a new allocator based
on allocating a configurable number of 4MB chunks of memory,
that latter are broken into frame buffers of 768x576 bytes
kept in different FIFOs (queues). As far as the driver autoloads
as a kernel module during kernel boot, the allocation of 4MB
chunks succeeds.

The driver keeps three FIFOs: one for 4MB chunks, one for free
buffers (available for allocations) and one for buffers already
allocated. Allocation/deallocation is done automatically though
the video4linux videobuf subsystem (some pointers to functions
are replaced by driver supplied functions).

Sure, there are problems:

1. The device tested to work with "xawtv -f" either via read()
   method (DT3155_STREAMING not selected), or via mmap() method
   (DT3155_STREAMING is selected) only. This coresponds to either
   cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE;
   or
   cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
   but not when
   cap->capabilities = V4L2_CAP_VIDEO_CAPTURE |
                           V4L2_CAP_STREAMING |
                           V4L2_CAP_READWRITE;
   This is because xawtv calls poll() before starting streaming,
   but videobuf_poll_stream() automatically starts reading if streaming
   is not started.
   This selection is made during kernel configuration (for now).

2. Works for CCIR, but should work for RS-170 (not tested)
   This is made also during kernel configuration.

3. Could work for multiple dt3155 frame grabbers in a PC,
   (private data is allocated during PCI probe() method), but
   is not tested due to lack of a second board.

4. Not tested on a BIG ENDIAN architecture.

5. Many others you could find .... :-)

All critics, comments, suggestions are wellcome.

Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>