linux/drivers/media/pci/dt3155/Kconfig

config VIDEO_DT3155
	tristate "DT3155 frame grabber"
	depends on PCI && VIDEO_DEV && VIDEO_V4L2
	depends on HAS_DMA
	select VIDEOBUF2_DMA_CONTIG
	default n
	---help---
	  Enables dt3155 device driver for the DataTranslation DT3155 frame grabber.
	  Say Y here if you have this hardware.
	  In doubt, say N.

	  To compile this driver as a module, choose M here: the
	  module will be called dt3155.
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 15:36:09 +00:00			`config VIDEO_DT3155`
[media] dt3155: move out of staging into drivers/media/pci The dt3155 code is now in good shape, so move it out of staging into drivers/media/pci. Mark in MAINTAINERS that I'll do Odd Fixes for this driver. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> 2015-04-25 15:36:18 +00:00			`tristate "DT3155 frame grabber"`
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 15:36:09 +00:00			`depends on PCI && VIDEO_DEV && VIDEO_V4L2`
[media] be sure that HAS_DMA is enabled for vb2-dma-contig vb2-dma-contig depends on HAS_DMA, but the Kbuild doesn't take it into account at select. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> 2014-08-26 19:45:39 +00:00			`depends on HAS_DMA`
staging: use videobuf2 framework for drivers/staging/dt3155v4l driver This patch transforms drivers/staging/dt3155v4l driver to use videobuf2 framework. Tested and works with "xawtv -f". Either streaming API or read method should be selected during kernel configuration. If both are selected into the driver (not possible without another patching), either due to my misunderstanding or problems in xawtv (or both), I get kernel panic after some start/stop of xawtv (not strictly reproducible). Signed-off-by: Marin Mitov <mitov@issp.bas.bg> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2011-05-28 18:45:27 +00:00			`select VIDEOBUF2_DMA_CONTIG`
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 15:36:09 +00:00			`default n`
			`---help---`
			`Enables dt3155 device driver for the DataTranslation DT3155 frame grabber.`
			`Say Y here if you have this hardware.`
			`In doubt, say N.`

			`To compile this driver as a module, choose M here: the`
[media] dt3155: move out of staging into drivers/media/pci The dt3155 code is now in good shape, so move it out of staging into drivers/media/pci. Mark in MAINTAINERS that I'll do Odd Fixes for this driver. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> 2015-04-25 15:36:18 +00:00			`module will be called dt3155.`