The third argument of dma_alloc_coherent() is of type dma_addr_t and is defined
as u64 for x86_64, while the member 'device_base' of struct dma_coherent_mem is
defined as u32.
While at it, clean up the code. Now if dev->dma_mem != NULL all the fields/members
are already properly initialized.
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch removes the private memory allocator
and all conjugated functions. Now the driver uses
videobuf-dma-contig module for allocations.
Added reserving 4MB coherent memory for private
per device allocations at probe time.
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch introduces a v4l2 state machine, so now
CONFIG_DT3155_STREAMING is no more needed.
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The previous patch "use_local_copy_qtype_ops.patch"
http://lkml.org/lkml/2010/5/9/40
has introduced a new BUG.
This patch corrects it.
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
dt3155v4l driver, as in -rc6-next-20100506 has a BUG.
When it modifies q->int_ops structure in videobuf-dma-contig
module the change is visible for all other modules using it.
Make a local copy of this structure and use its modification
to solve the bug.
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
dt3155v4l driver, as in -rc6-next-20100506 compiles, but will
not run properly due to recent changes in the videobuf APIs.
This patch synchronizes some functions that have been copied
from drivers/media/video/videobuf-dma-contig.c (and modified)
with the recent (-rc6 -> -rc6-next-) changes in videobuf layer
especially drivers/media/video/videobuf-dma-contig.c
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The prototypes of udelay() and msleep() are in linux/delay.h,
so include it.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
