2019-05-27 09:55:06 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
/***************************************************************************
|
|
|
|
|
* Copyright (C) 2006-2010 by Marin Mitov *
|
|
|
|
|
* mitov@issp.bas.bg *
|
|
|
|
|
* *
|
|
|
|
|
* *
|
|
|
|
|
***************************************************************************/
|
|
|
|
|
|
|
|
|
|
/* DT3155 header file */
|
|
|
|
|
#ifndef _DT3155_H_
|
|
|
|
|
#define _DT3155_H_
|
|
|
|
|
|
|
|
|
|
#include <linux/pci.h>
|
|
|
|
|
#include <linux/interrupt.h>
|
2015-04-25 17:32:54 +03:00
|
|
|
#include <media/v4l2-device.h>
|
|
|
|
|
#include <media/v4l2-dev.h>
|
[media] media: videobuf2: Restructure vb2_buffer
Remove v4l2 stuff - v4l2_buf, v4l2_plane - from struct vb2_buffer.
Add new member variables - bytesused, length, offset, userptr, fd,
data_offset - to struct vb2_plane in order to cover all information
of v4l2_plane.
struct vb2_plane {
<snip>
unsigned int bytesused;
unsigned int length;
union {
unsigned int offset;
unsigned long userptr;
int fd;
} m;
unsigned int data_offset;
}
Replace v4l2_buf with new member variables - index, type, memory - which
are common fields for buffer management.
struct vb2_buffer {
<snip>
unsigned int index;
unsigned int type;
unsigned int memory;
unsigned int num_planes;
struct vb2_plane planes[VIDEO_MAX_PLANES];
<snip>
};
v4l2 specific fields - flags, field, timestamp, timecode,
sequence - are moved to vb2_v4l2_buffer in videobuf2-v4l2.c
struct vb2_v4l2_buffer {
struct vb2_buffer vb2_buf;
__u32 flags;
__u32 field;
struct timeval timestamp;
struct v4l2_timecode timecode;
__u32 sequence;
};
Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-09-22 16:30:30 +03:00
|
|
|
#include <media/videobuf2-v4l2.h>
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
|
|
|
|
|
#define DT3155_NAME "dt3155"
|
2015-04-25 18:36:18 +03:00
|
|
|
#define DT3155_VER_MAJ 2
|
|
|
|
|
#define DT3155_VER_MIN 0
|
2010-05-18 14:05:29 +04:00
|
|
|
#define DT3155_VER_EXT 0
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
#define DT3155_VERSION __stringify(DT3155_VER_MAJ) "." \
|
|
|
|
|
__stringify(DT3155_VER_MIN) "." \
|
|
|
|
|
__stringify(DT3155_VER_EXT)
|
|
|
|
|
|
|
|
|
|
/* DT3155 Base Register offsets (memory mapped) */
|
|
|
|
|
#define EVEN_DMA_START 0x00
|
|
|
|
|
#define ODD_DMA_START 0x0C
|
|
|
|
|
#define EVEN_DMA_STRIDE 0x18
|
|
|
|
|
#define ODD_DMA_STRIDE 0x24
|
|
|
|
|
#define EVEN_PIXEL_FMT 0x30
|
|
|
|
|
#define ODD_PIXEL_FMT 0x34
|
2020-06-16 14:52:55 +03:00
|
|
|
#define FIFO_TRIGGER 0x38
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
#define XFER_MODE 0x3C
|
|
|
|
|
#define CSR1 0x40
|
|
|
|
|
#define RETRY_WAIT_CNT 0x44
|
|
|
|
|
#define INT_CSR 0x48
|
|
|
|
|
#define EVEN_FLD_MASK 0x4C
|
|
|
|
|
#define ODD_FLD_MASK 0x50
|
|
|
|
|
#define MASK_LENGTH 0x54
|
|
|
|
|
#define FIFO_FLAG_CNT 0x58
|
|
|
|
|
#define IIC_CLK_DUR 0x5C
|
|
|
|
|
#define IIC_CSR1 0x60
|
|
|
|
|
#define IIC_CSR2 0x64
|
|
|
|
|
|
|
|
|
|
/* DT3155 Internal Registers indexes (i2c/IIC mapped) */
|
|
|
|
|
#define CSR2 0x10
|
|
|
|
|
#define EVEN_CSR 0x11
|
|
|
|
|
#define ODD_CSR 0x12
|
|
|
|
|
#define CONFIG 0x13
|
|
|
|
|
#define DT_ID 0x1F
|
|
|
|
|
#define X_CLIP_START 0x20
|
|
|
|
|
#define Y_CLIP_START 0x22
|
|
|
|
|
#define X_CLIP_END 0x24
|
|
|
|
|
#define Y_CLIP_END 0x26
|
|
|
|
|
#define AD_ADDR 0x30
|
|
|
|
|
#define AD_LUT 0x31
|
|
|
|
|
#define AD_CMD 0x32
|
|
|
|
|
#define DIG_OUT 0x40
|
|
|
|
|
#define PM_LUT_ADDR 0x50
|
|
|
|
|
#define PM_LUT_DATA 0x51
|
|
|
|
|
|
|
|
|
|
/* AD command register values */
|
|
|
|
|
#define AD_CMD_REG 0x00
|
|
|
|
|
#define AD_POS_REF 0x01
|
|
|
|
|
#define AD_NEG_REF 0x02
|
|
|
|
|
|
|
|
|
|
/* CSR1 bit masks */
|
2015-04-25 17:41:31 +03:00
|
|
|
#define RANGE_EN 0x00008000
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
#define CRPT_DIS 0x00004000
|
2015-04-25 17:41:31 +03:00
|
|
|
#define ADDR_ERR_ODD 0x00000800
|
|
|
|
|
#define ADDR_ERR_EVEN 0x00000400
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
#define FLD_CRPT_ODD 0x00000200
|
|
|
|
|
#define FLD_CRPT_EVEN 0x00000100
|
|
|
|
|
#define FIFO_EN 0x00000080
|
|
|
|
|
#define SRST 0x00000040
|
|
|
|
|
#define FLD_DN_ODD 0x00000020
|
|
|
|
|
#define FLD_DN_EVEN 0x00000010
|
|
|
|
|
/* These should not be used.
|
|
|
|
|
* Use CAP_CONT_ODD/EVEN instead
|
|
|
|
|
#define CAP_SNGL_ODD 0x00000008
|
|
|
|
|
#define CAP_SNGL_EVEN 0x00000004
|
|
|
|
|
*/
|
|
|
|
|
#define CAP_CONT_ODD 0x00000002
|
|
|
|
|
#define CAP_CONT_EVEN 0x00000001
|
|
|
|
|
|
|
|
|
|
/* INT_CSR bit masks */
|
|
|
|
|
#define FLD_START_EN 0x00000400
|
|
|
|
|
#define FLD_END_ODD_EN 0x00000200
|
|
|
|
|
#define FLD_END_EVEN_EN 0x00000100
|
|
|
|
|
#define FLD_START 0x00000004
|
|
|
|
|
#define FLD_END_ODD 0x00000002
|
|
|
|
|
#define FLD_END_EVEN 0x00000001
|
|
|
|
|
|
|
|
|
|
/* IIC_CSR1 bit masks */
|
|
|
|
|
#define DIRECT_ABORT 0x00000200
|
|
|
|
|
|
|
|
|
|
/* IIC_CSR2 bit masks */
|
|
|
|
|
#define NEW_CYCLE 0x01000000
|
|
|
|
|
#define DIR_RD 0x00010000
|
|
|
|
|
#define IIC_READ 0x01010000
|
|
|
|
|
#define IIC_WRITE 0x01000000
|
|
|
|
|
|
|
|
|
|
/* CSR2 bit masks */
|
|
|
|
|
#define DISP_PASS 0x40
|
|
|
|
|
#define BUSY_ODD 0x20
|
|
|
|
|
#define BUSY_EVEN 0x10
|
|
|
|
|
#define SYNC_PRESENT 0x08
|
|
|
|
|
#define VT_50HZ 0x04
|
|
|
|
|
#define SYNC_SNTL 0x02
|
|
|
|
|
#define CHROM_FILT 0x01
|
|
|
|
|
#define VT_60HZ 0x00
|
|
|
|
|
|
|
|
|
|
/* CSR_EVEN/ODD bit masks */
|
|
|
|
|
#define CSR_ERROR 0x04
|
|
|
|
|
#define CSR_SNGL 0x02
|
|
|
|
|
#define CSR_DONE 0x01
|
|
|
|
|
|
|
|
|
|
/* CONFIG bit masks */
|
|
|
|
|
#define PM_LUT_PGM 0x80
|
|
|
|
|
#define PM_LUT_SEL 0x40
|
|
|
|
|
#define CLIP_EN 0x20
|
|
|
|
|
#define HSCALE_EN 0x10
|
|
|
|
|
#define EXT_TRIG_UP 0x0C
|
|
|
|
|
#define EXT_TRIG_DOWN 0x04
|
|
|
|
|
#define ACQ_MODE_NEXT 0x02
|
|
|
|
|
#define ACQ_MODE_ODD 0x01
|
|
|
|
|
#define ACQ_MODE_EVEN 0x00
|
|
|
|
|
|
|
|
|
|
/* AD_CMD bit masks */
|
|
|
|
|
#define VIDEO_CNL_1 0x00
|
|
|
|
|
#define VIDEO_CNL_2 0x40
|
|
|
|
|
#define VIDEO_CNL_3 0x80
|
|
|
|
|
#define VIDEO_CNL_4 0xC0
|
|
|
|
|
#define SYNC_CNL_1 0x00
|
|
|
|
|
#define SYNC_CNL_2 0x10
|
|
|
|
|
#define SYNC_CNL_3 0x20
|
|
|
|
|
#define SYNC_CNL_4 0x30
|
|
|
|
|
#define SYNC_LVL_1 0x00
|
|
|
|
|
#define SYNC_LVL_2 0x04
|
|
|
|
|
#define SYNC_LVL_3 0x08
|
|
|
|
|
#define SYNC_LVL_4 0x0C
|
|
|
|
|
|
|
|
|
|
/* DT3155 identificator */
|
|
|
|
|
#define DT3155_ID 0x20
|
|
|
|
|
|
|
|
|
|
/* per board private data structure */
|
|
|
|
|
/**
|
|
|
|
|
* struct dt3155_priv - private data structure
|
|
|
|
|
*
|
2015-04-25 17:32:54 +03:00
|
|
|
* @v4l2_dev: v4l2_device structure
|
2015-03-09 19:33:59 +03:00
|
|
|
* @vdev: video_device structure
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
* @pdev: pointer to pci_dev structure
|
2015-04-25 17:51:36 +03:00
|
|
|
* @vidq: vb2_queue structure
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
* @curr_buf: pointer to curren buffer
|
2011-05-28 22:45:27 +04:00
|
|
|
* @mux: mutex to protect the instance
|
2015-04-25 18:11:50 +03:00
|
|
|
* @dmaq: queue for dma buffers
|
|
|
|
|
* @lock: spinlock for dma queue
|
|
|
|
|
* @std: input standard
|
|
|
|
|
* @width: frame width
|
|
|
|
|
* @height: frame height
|
2015-04-25 18:19:02 +03:00
|
|
|
* @input: current input
|
2015-04-25 18:11:50 +03:00
|
|
|
* @sequence: frame counter
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
* @stats: statistics structure
|
|
|
|
|
* @regs: local copy of mmio base register
|
|
|
|
|
* @csr2: local copy of csr2 register
|
|
|
|
|
* @config: local copy of config register
|
|
|
|
|
*/
|
|
|
|
|
struct dt3155_priv {
|
2015-04-25 17:32:54 +03:00
|
|
|
struct v4l2_device v4l2_dev;
|
2015-03-09 19:33:59 +03:00
|
|
|
struct video_device vdev;
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
struct pci_dev *pdev;
|
2015-04-25 17:51:36 +03:00
|
|
|
struct vb2_queue vidq;
|
[media] media: videobuf2: Restructure vb2_buffer
Remove v4l2 stuff - v4l2_buf, v4l2_plane - from struct vb2_buffer.
Add new member variables - bytesused, length, offset, userptr, fd,
data_offset - to struct vb2_plane in order to cover all information
of v4l2_plane.
struct vb2_plane {
<snip>
unsigned int bytesused;
unsigned int length;
union {
unsigned int offset;
unsigned long userptr;
int fd;
} m;
unsigned int data_offset;
}
Replace v4l2_buf with new member variables - index, type, memory - which
are common fields for buffer management.
struct vb2_buffer {
<snip>
unsigned int index;
unsigned int type;
unsigned int memory;
unsigned int num_planes;
struct vb2_plane planes[VIDEO_MAX_PLANES];
<snip>
};
v4l2 specific fields - flags, field, timestamp, timecode,
sequence - are moved to vb2_v4l2_buffer in videobuf2-v4l2.c
struct vb2_v4l2_buffer {
struct vb2_buffer vb2_buf;
__u32 flags;
__u32 field;
struct timeval timestamp;
struct v4l2_timecode timecode;
__u32 sequence;
};
Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-09-22 16:30:30 +03:00
|
|
|
struct vb2_v4l2_buffer *curr_buf;
|
2011-05-28 22:45:27 +04:00
|
|
|
struct mutex mux;
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
struct list_head dmaq;
|
|
|
|
|
spinlock_t lock;
|
2015-04-25 18:11:50 +03:00
|
|
|
v4l2_std_id std;
|
|
|
|
|
unsigned width, height;
|
2015-04-25 18:19:02 +03:00
|
|
|
unsigned input;
|
2015-04-25 18:01:55 +03:00
|
|
|
unsigned int sequence;
|
2011-09-08 01:46:05 +04:00
|
|
|
void __iomem *regs;
|
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>
2010-04-30 19:36:09 +04:00
|
|
|
u8 csr2, config;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif /* _DT3155_H_ */
|
