OpenCloudOS-Kernel/drivers/media/platform/Kconfig

535 lines
16 KiB
Plaintext
Raw Normal View History

#
# Platform drivers
# Most drivers here are currently for webcam support
menuconfig V4L_PLATFORM_DRIVERS
bool "V4L platform devices"
depends on MEDIA_CAMERA_SUPPORT
default n
---help---
Say Y here to enable support for platform-specific V4L drivers.
if V4L_PLATFORM_DRIVERS
source "drivers/media/platform/marvell-ccic/Kconfig"
config VIDEO_VIA_CAMERA
tristate "VIAFB camera controller support"
depends on FB_VIA
select VIDEOBUF_DMA_SG
select VIDEO_OV7670
help
Driver support for the integrated camera controller in VIA
Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
with ov7670 sensors.
#
# Platform multimedia device configuration
#
source "drivers/media/platform/davinci/Kconfig"
source "drivers/media/platform/omap/Kconfig"
source "drivers/media/platform/blackfin/Kconfig"
config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
[media] v4l: VIDEO_SH_VOU should depend on HAS_DMA If NO_DMA=y: warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_DM365_ISIF && VIDEO_OMAP2_VOUT && VIDEO_SH_VOU && VIDEO_VIU && VIDEO_TIMBERDALE && VIDEO_MX1 && VIDEO_OMAP1) selects VIDEOBUF_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA) drivers/built-in.o: In function `videobuf_vm_close': videobuf-dma-contig.c:(.text+0x407aa0): undefined reference to `videobuf_queue_cancel' drivers/built-in.o: In function `__videobuf_dc_alloc': videobuf-dma-contig.c:(.text+0x407ba2): undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `__videobuf_mmap_mapper': videobuf-dma-contig.c:(.text+0x407d44): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `free_buffer': sh_vou.c:(.text+0x41f73a): undefined reference to `videobuf_waiton' drivers/built-in.o: In function `sh_vou_poll': sh_vou.c:(.text+0x41f884): undefined reference to `videobuf_poll_stream' drivers/built-in.o: In function `sh_vou_buf_prepare': sh_vou.c:(.text+0x41fdf6): undefined reference to `videobuf_iolock' drivers/built-in.o: In function `sh_vou_reqbufs': sh_vou.c:(.text+0x4203b0): undefined reference to `videobuf_reqbufs' drivers/built-in.o: In function `sh_vou_querybuf': sh_vou.c:(.text+0x42040a): undefined reference to `videobuf_querybuf' drivers/built-in.o: In function `sh_vou_qbuf': sh_vou.c:(.text+0x42045e): undefined reference to `videobuf_qbuf' drivers/built-in.o: In function `sh_vou_dqbuf': sh_vou.c:(.text+0x4204c2): undefined reference to `videobuf_dqbuf' drivers/built-in.o: In function `sh_vou_streamon': sh_vou.c:(.text+0x420572): undefined reference to `videobuf_streamon' drivers/built-in.o: In function `sh_vou_streamoff': sh_vou.c:(.text+0x4205d2): undefined reference to `videobuf_streamoff' drivers/built-in.o: In function `sh_vou_mmap': sh_vou.c:(.text+0x420c46): undefined reference to `videobuf_mmap_mapper' VIDEO_SH_VOU selects VIDEOBUF_DMA_CONTIG, which bypasses its dependency on HAS_DMA. Make VIDEO_SH_VOU depend on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-22 03:57:17 +08:00
depends on VIDEO_DEV && I2C && HAS_DMA
depends on ARCH_SHMOBILE || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
help
Support for the Video Output Unit (VOU) on SuperH SoCs.
config VIDEO_VIU
tristate "Freescale VIU Video Driver"
depends on VIDEO_V4L2 && PPC_MPC512x
select VIDEOBUF_DMA_CONTIG
default y
---help---
Support for Freescale VIU video driver. This device captures
video data, or overlays video on DIU frame buffer.
Say Y here if you want to enable VIU device on MPC5121e Rev2+.
In doubt, say N.
config VIDEO_M32R_AR
tristate "AR devices"
depends on VIDEO_V4L2
depends on M32R || COMPILE_TEST
---help---
This is a video4linux driver for the Renesas AR (Artificial Retina)
camera module.
config VIDEO_M32R_AR_M64278
tristate "AR device with color module M64278(VGA)"
depends on PLAT_M32700UT
select VIDEO_M32R_AR
---help---
This is a video4linux driver for the Renesas AR (Artificial
Retina) with M64278E-800 camera module.
This module supports VGA(640x480 pixels) resolutions.
To compile this driver as a module, choose M here: the
module will be called arv.
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
depends on HAS_DMA && OF
depends on OMAP_IOMMU
select ARM_DMA_USE_IOMMU
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
---help---
Driver for an OMAP 3 camera controller.
config VIDEO_OMAP3_DEBUG
bool "OMAP 3 Camera debug messages"
depends on VIDEO_OMAP3
---help---
Enable debug messages on OMAP 3 camera controller driver.
config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on PXA27x || COMPILE_TEST
select VIDEOBUF2_DMA_SG
select SG_SPLIT
---help---
This is a v4l2 driver for the PXA27x Quick Capture Interface
config VIDEO_S3C_CAMIF
tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on PM
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
---help---
This is a v4l2 driver for s3c24xx and s3c64xx SoC series camera
host interface (CAMIF).
To compile this driver as a module, choose M here: the module
will be called s3c-camif.
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
depends on VIDEO_V4L2 && OF && HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
---help---
This module makes the STM32 Digital Camera Memory Interface (DCMI)
available as a v4l2 device.
To compile this driver as a module, choose M here: the module
will be called stm32-dcmi.
source "drivers/media/platform/soc_camera/Kconfig"
source "drivers/media/platform/exynos4-is/Kconfig"
source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
source "drivers/media/platform/rcar-vin/Kconfig"
source "drivers/media/platform/atmel/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on SOC_DRA7XX || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
Support for the TI CAL (Camera Adaptation Layer) block
found on DRA72X SoC.
In TI Technical Reference Manual this module is referred as
Camera Interface Subsystem (CAMSS).
endif # V4L_PLATFORM_DRIVERS
menuconfig V4L_MEM2MEM_DRIVERS
bool "Memory-to-memory multimedia devices"
depends on VIDEO_V4L2
depends on MEDIA_CAMERA_SUPPORT
default n
---help---
Say Y here to enable selecting drivers for V4L devices that
use system memory for both source and destination buffers, as opposed
to capture and output drivers, which use memory buffers for just
one of those.
if V4L_MEM2MEM_DRIVERS
config VIDEO_CODA
tristate "Chips&Media Coda multi-standard codec IP"
depends on VIDEO_DEV && VIDEO_V4L2 && (ARCH_MXC || COMPILE_TEST)
depends on HAS_DMA
select SRAM
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
select GENERIC_ALLOCATOR
---help---
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
config VIDEO_IMX_VDOA
def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
config VIDEO_MEDIATEK_JPEG
tristate "Mediatek JPEG Codec driver"
depends on MTK_IOMMU_V1 || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
Mediatek jpeg codec driver provides HW capability to decode
JPEG format
To compile this driver as a module, choose M here: the
module will be called mtk-jpeg
config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
---help---
This driver provides downloading VPU firmware and
communicating with VPU. This driver for hw video
codec embedded in Mediatek's MT8173 SOCs. It is able
to handle video decoding/encoding in a range of formats.
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
config VIDEO_MEDIATEK_MDP
tristate "Mediatek MDP driver"
depends on MTK_IOMMU || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select VIDEO_MEDIATEK_VPU
default n
---help---
It is a v4l2 driver and present in Mediatek MT8173 SoCs.
The driver supports for scaling and color space conversion.
To compile this driver as a module, choose M here: the
module will be called mtk-mdp.
config VIDEO_MEDIATEK_VCODEC
tristate "Mediatek Video Codec driver"
depends on MTK_IOMMU || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select VIDEO_MEDIATEK_VPU
default n
---help---
Mediatek video codec driver provides HW capability to
encode and decode in a range of video formats
This driver rely on VPU driver to communicate with VPU.
To compile this driver as a module, choose M here: the
module will be called mtk-vcodec
config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
Generic deinterlacing V4L2 driver.
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
default n
---help---
This is a v4l2 driver for Samsung S5P and EXYNOS4 G2D
2d graphics accelerator.
config VIDEO_SAMSUNG_S5P_JPEG
tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
This is a v4l2 driver for Samsung S5P, EXYNOS3250
and EXYNOS4 JPEG codec
config VIDEO_SAMSUNG_S5P_MFC
tristate "Samsung S5P MFC Video Codec"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
help
MFC 5.1 and 6.x driver for V4L2
config VIDEO_MX2_EMMAPRP
tristate "MX2 eMMa-PrP support"
depends on VIDEO_DEV && VIDEO_V4L2
depends on SOC_IMX27 || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
MX2X chips have a PrP that can be used to process buffers from
memory to memory. Operations include resizing and format
conversion.
config VIDEO_SAMSUNG_EXYNOS_GSC
tristate "Samsung Exynos G-Scaler driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
config VIDEO_STI_BDISP
tristate "STMicroelectronics BDISP 2D blitter driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on HAS_DMA
depends on ARCH_STI || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
config VIDEO_STI_HVA
tristate "STMicroelectronics HVA multi-format video encoder V4L2 driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on HAS_DMA
depends on ARCH_STI || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
This V4L2 driver enables HVA (Hardware Video Accelerator) multi-format
video encoder of STMicroelectronics SoC, allowing hardware encoding of
raw uncompressed formats in various compressed video bitstreams format.
To compile this driver as a module, choose M here:
the module will be called st-hva.
config VIDEO_STI_HVA_DEBUGFS
bool "Export STMicroelectronics HVA internals in debugfs"
depends on VIDEO_STI_HVA
depends on DEBUG_FS
help
Select this to see information about the internal state and the last
operation of STMicroelectronics HVA multi-format video encoder in
debugfs.
Choose N unless you know you need this.
config VIDEO_STI_DELTA
tristate "STMicroelectronics DELTA multi-format video decoder V4L2 driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_STI || COMPILE_TEST
depends on HAS_DMA
help
This V4L2 driver enables DELTA multi-format video decoder
of STMicroelectronics STiH4xx SoC series allowing hardware
decoding of various compressed video bitstream format in
raw uncompressed format.
Use this option to see the decoders available for such
hardware.
Please notice that the driver will only be built if
at least one of the DELTA decoder below is selected.
if VIDEO_STI_DELTA
config VIDEO_STI_DELTA_MJPEG
bool "STMicroelectronics DELTA MJPEG support"
default y
help
Enables DELTA MJPEG hardware support.
To compile this driver as a module, choose M here:
the module will be called st-delta.
config VIDEO_STI_DELTA_DRIVER
tristate
depends on VIDEO_STI_DELTA
depends on VIDEO_STI_DELTA_MJPEG
default VIDEO_STI_DELTA_MJPEG
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select RPMSG
endif # VIDEO_STI_DELTA
config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
Support for the Video Engine Unit (VEU) on SuperH and
SH-Mobile SoCs.
config VIDEO_RENESAS_FDP1
tristate "Renesas Fine Display Processor"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on ARCH_SHMOBILE || COMPILE_TEST
depends on (!ARCH_RENESAS && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
This is a V4L2 driver for the Renesas Fine Display Processor
providing colour space conversion, and de-interlacing features.
To compile this driver as a module, choose M here: the module
will be called rcar_fdp1.
[media] V4L2: platform: Add Renesas R-Car JPEG codec driver Here's the driver for the Renesas R-Car JPEG processing unit. The driver is implemented within the V4L2 framework as a memory-to-memory device. It presents two video nodes to userspace, one for the encoding part, and one for the decoding part. It was found that the only working mode for encoding is no markers output, so we generate markers with software. In the current version of driver we also use software JPEG header parsing because with hardware parsing performance is lower than desired. >From a userspace point of view the process is typical (S_FMT, REQBUF, optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination queues. STREAMON can return -EINVAL in case of mismatch of output and capture queues format. Also during decoding driver can return buffers if queued buffer with JPEG image contains image with inappropriate subsampling (e.g. 4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag. During encoding the available formats are: V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and V4L2_PIX_FMT_JPEG for destination. During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16 for destination. Performance of current version: 1280x800 NV12 image encoding/decoding decoding ~122 FPS encoding ~191 FPS Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-07-22 19:23:03 +08:00
config VIDEO_RENESAS_JPU
tristate "Renesas JPEG Processing Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
[media] V4L2: platform: Add Renesas R-Car JPEG codec driver Here's the driver for the Renesas R-Car JPEG processing unit. The driver is implemented within the V4L2 framework as a memory-to-memory device. It presents two video nodes to userspace, one for the encoding part, and one for the decoding part. It was found that the only working mode for encoding is no markers output, so we generate markers with software. In the current version of driver we also use software JPEG header parsing because with hardware parsing performance is lower than desired. >From a userspace point of view the process is typical (S_FMT, REQBUF, optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination queues. STREAMON can return -EINVAL in case of mismatch of output and capture queues format. Also during decoding driver can return buffers if queued buffer with JPEG image contains image with inappropriate subsampling (e.g. 4:2:0 in JPEG and 4:2:2 in capture). If JPEG image and queue format dimensions differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag. During encoding the available formats are: V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and V4L2_PIX_FMT_JPEG for destination. During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16 for destination. Performance of current version: 1280x800 NV12 image encoding/decoding decoding ~122 FPS encoding ~191 FPS Signed-off-by: Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-07-22 19:23:03 +08:00
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
This is a V4L2 driver for the Renesas JPEG Processing Unit.
To compile this driver as a module, choose M here: the module
will be called rcar_jpu.
config VIDEO_RENESAS_FCP
tristate "Renesas Frame Compression Processor"
depends on ARCH_RENESAS || COMPILE_TEST
depends on OF
---help---
This is a driver for the Renesas Frame Compression Processor (FCP).
The FCP is a companion module of video processing modules in the
Renesas R-Car Gen3 SoCs. It handles memory access for the codec,
VSP and FDP modules.
To compile this driver as a module, choose M here: the module
will be called rcar-fcp.
config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
depends on (ARCH_RENESAS && OF) || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
---help---
This is a V4L2 driver for the Renesas VSP1 video processing engine.
To compile this driver as a module, choose M here: the module
will be called vsp1.
[media] v4l: ti-vpe: Add VPE mem to mem driver VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja <archit@ti.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-16 13:36:47 +08:00
config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on SOC_DRA7XX || COMPILE_TEST
depends on HAS_DMA
[media] v4l: ti-vpe: Add VPE mem to mem driver VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja <archit@ti.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-16 13:36:47 +08:00
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select VIDEO_TI_VPDMA
select VIDEO_TI_SC
select VIDEO_TI_CSC
[media] v4l: ti-vpe: Add VPE mem to mem driver VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja <archit@ti.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-16 13:36:47 +08:00
default n
---help---
Support for the TI VPE(Video Processing Engine) block
found on DRA7XX SoC.
config VIDEO_TI_VPE_DEBUG
bool "VPE debug messages"
depends on VIDEO_TI_VPE
---help---
Enable debug messages on VPE driver.
endif # V4L_MEM2MEM_DRIVERS
# TI VIDEO PORT Helper Modules
# These will be selected by VPE and VIP
config VIDEO_TI_VPDMA
tristate
config VIDEO_TI_SC
tristate
config VIDEO_TI_CSC
tristate
menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
if V4L_TEST_DRIVERS
source "drivers/media/platform/vimc/Kconfig"
source "drivers/media/platform/vivid/Kconfig"
config VIDEO_VIM2M
tristate "Virtual Memory-to-Memory Driver"
depends on VIDEO_DEV && VIDEO_V4L2
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
default n
---help---
This is a virtual test device for the memory-to-memory driver
framework.
endif #V4L_TEST_DRIVERS
menuconfig DVB_PLATFORM_DRIVERS
bool "DVB platform devices"
depends on MEDIA_DIGITAL_TV_SUPPORT
default n
---help---
Say Y here to enable support for platform-specific Digital TV drivers.
if DVB_PLATFORM_DRIVERS
source "drivers/media/platform/sti/c8sectpfe/Kconfig"
endif #DVB_PLATFORM_DRIVERS
menuconfig CEC_PLATFORM_DRIVERS
bool "CEC platform devices"
depends on MEDIA_CEC_SUPPORT
if CEC_PLATFORM_DRIVERS
config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on CEC_CORE && (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
select MEDIA_CEC_NOTIFIER
---help---
This is a driver for Samsung S5P HDMI CEC interface. It uses the
generic CEC framework interface.
CEC bus is present in the HDMI connector and enables communication
between compatible devices.
config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on CEC_CORE && (ARCH_STI || COMPILE_TEST)
select MEDIA_CEC_NOTIFIER
---help---
This is a driver for STIH4xx HDMI CEC interface. It uses the
generic CEC framework interface.
CEC bus is present in the HDMI connector and enables communication
between compatible devices.
endif #CEC_PLATFORM_DRIVERS