2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2012-05-28 11:17:49 +00:00
|
|
|
#
|
|
|
|
|
# Platform drivers
|
2015-07-30 17:09:00 +00:00
|
|
|
# Most drivers here are currently for webcam support
|
2012-05-28 11:17:49 +00:00
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
config V4L_PLATFORM_DRIVERS
|
2011-11-08 14:02:34 +00:00
|
|
|
bool "V4L platform devices"
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2011-11-08 14:02:34 +00:00
|
|
|
Say Y here to enable support for platform-specific V4L drivers.
|
|
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
config SDR_PLATFORM_DRIVERS
|
|
|
|
|
bool "SDR platform devices"
|
|
|
|
|
depends on MEDIA_SDR_SUPPORT
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable support for platform-specific SDR Drivers.
|
|
|
|
|
|
|
|
|
|
config DVB_PLATFORM_DRIVERS
|
|
|
|
|
bool "DVB platform devices"
|
|
|
|
|
depends on MEDIA_DIGITAL_TV_SUPPORT
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable support for platform-specific Digital TV drivers.
|
|
|
|
|
|
|
|
|
|
config V4L_MEM2MEM_DRIVERS
|
|
|
|
|
bool "Memory-to-memory multimedia devices"
|
|
|
|
|
depends on VIDEO_V4L2
|
|
|
|
|
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.
|
|
|
|
|
|
2022-03-10 15:40:21 +00:00
|
|
|
source "drivers/media/platform/nxp/Kconfig"
|
|
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
# V4L platform drivers
|
2011-11-08 14:02:34 +00:00
|
|
|
|
2012-08-14 20:31:16 +00:00
|
|
|
source "drivers/media/platform/marvell-ccic/Kconfig"
|
2011-06-11 17:46:42 +00:00
|
|
|
|
2011-09-30 12:06:11 +00:00
|
|
|
config VIDEO_VIA_CAMERA
|
|
|
|
|
tristate "VIAFB camera controller support"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2020-04-23 14:46:07 +00:00
|
|
|
depends on FB_VIA && VIDEO_V4L2
|
2019-07-28 14:43:41 +00:00
|
|
|
select VIDEOBUF2_DMA_SG
|
2011-09-30 12:06:11 +00:00
|
|
|
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.
|
|
|
|
|
|
2018-05-04 14:08:08 +00:00
|
|
|
source "drivers/media/platform/cadence/Kconfig"
|
2011-09-30 12:06:11 +00:00
|
|
|
|
2012-08-14 20:31:16 +00:00
|
|
|
source "drivers/media/platform/davinci/Kconfig"
|
2011-09-30 12:06:11 +00:00
|
|
|
|
2012-08-14 20:31:16 +00:00
|
|
|
source "drivers/media/platform/omap/Kconfig"
|
2011-09-30 12:06:11 +00:00
|
|
|
|
2022-03-11 09:01:12 +00:00
|
|
|
source "drivers/media/platform/aspeed/Kconfig"
|
2018-12-11 16:57:01 +00:00
|
|
|
|
2011-09-30 12:06:11 +00:00
|
|
|
config VIDEO_SH_VOU
|
|
|
|
|
tristate "SuperH VOU video output driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && I2C
|
2013-11-27 01:18:28 +00:00
|
|
|
depends on ARCH_SHMOBILE || COMPILE_TEST
|
2015-10-16 00:35:40 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2011-09-30 12:06:11 +00:00
|
|
|
help
|
|
|
|
|
Support for the Video Output Unit (VOU) on SuperH SoCs.
|
|
|
|
|
|
2017-06-07 18:33:55 +00:00
|
|
|
config VIDEO_MUX
|
|
|
|
|
tristate "Video Multiplexer"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2017-07-18 13:26:00 +00:00
|
|
|
select MULTIPLEXER
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2 && OF
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2017-06-07 18:33:55 +00:00
|
|
|
select REGMAP
|
2018-09-29 19:54:10 +00:00
|
|
|
select V4L2_FWNODE
|
2017-06-07 18:33:55 +00:00
|
|
|
help
|
|
|
|
|
This driver provides support for N:1 video bus multiplexers.
|
|
|
|
|
|
2011-02-12 21:05:06 +00:00
|
|
|
config VIDEO_OMAP3
|
2013-01-17 02:53:43 +00:00
|
|
|
tristate "OMAP 3 Camera support"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2 && I2C
|
2018-04-09 09:48:01 +00:00
|
|
|
depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on COMMON_CLK && OF
|
2018-04-09 09:48:01 +00:00
|
|
|
select ARM_DMA_USE_IOMMU if OMAP_IOMMU
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2014-07-04 07:51:47 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2015-03-25 22:57:34 +00:00
|
|
|
select MFD_SYSCON
|
2016-08-26 23:17:25 +00:00
|
|
|
select V4L2_FWNODE
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2011-02-12 21:05:06 +00:00
|
|
|
Driver for an OMAP 3 camera controller.
|
|
|
|
|
|
|
|
|
|
config VIDEO_OMAP3_DEBUG
|
|
|
|
|
bool "OMAP 3 Camera debug messages"
|
|
|
|
|
depends on VIDEO_OMAP3
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2011-02-12 21:05:06 +00:00
|
|
|
Enable debug messages on OMAP 3 camera controller driver.
|
|
|
|
|
|
2022-03-11 08:56:53 +00:00
|
|
|
source "drivers/media/platform/intel/Kconfig"
|
2016-09-06 09:04:23 +00:00
|
|
|
|
2017-08-08 13:30:08 +00:00
|
|
|
config VIDEO_QCOM_CAMSS
|
2018-07-25 16:38:13 +00:00
|
|
|
tristate "Qualcomm V4L2 Camera Subsystem driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2
|
2017-08-08 13:30:08 +00:00
|
|
|
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2017-08-08 13:30:08 +00:00
|
|
|
select VIDEOBUF2_DMA_SG
|
|
|
|
|
select V4L2_FWNODE
|
|
|
|
|
|
2012-08-22 23:09:18 +00:00
|
|
|
config VIDEO_S3C_CAMIF
|
|
|
|
|
tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2 && I2C && PM
|
2014-08-20 19:21:35 +00:00
|
|
|
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2012-08-22 23:09:18 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2012-08-22 23:09:18 +00:00
|
|
|
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.
|
|
|
|
|
|
2017-05-05 15:31:21 +00:00
|
|
|
config VIDEO_STM32_DCMI
|
|
|
|
|
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2 && OF
|
2017-05-05 15:31:21 +00:00
|
|
|
depends on ARCH_STM32 || COMPILE_TEST
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
select MEDIA_CONTROLLER
|
2016-08-26 23:17:25 +00:00
|
|
|
select V4L2_FWNODE
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2017-05-05 15:31:21 +00:00
|
|
|
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.
|
|
|
|
|
|
2018-02-22 10:37:19 +00:00
|
|
|
config VIDEO_RENESAS_CEU
|
|
|
|
|
tristate "Renesas Capture Engine Unit (CEU) driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2018-02-22 10:37:19 +00:00
|
|
|
depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_FWNODE
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2018-02-22 10:37:19 +00:00
|
|
|
This is a v4l2 driver for the Renesas CEU Interface
|
|
|
|
|
|
2020-11-06 12:19:37 +00:00
|
|
|
config VIDEO_ROCKCHIP_ISP1
|
|
|
|
|
tristate "Rockchip Image Signal Processing v1 Unit driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2020-11-06 12:19:37 +00:00
|
|
|
depends on VIDEO_V4L2 && OF
|
|
|
|
|
depends on ARCH_ROCKCHIP || COMPILE_TEST
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select VIDEOBUF2_VMALLOC
|
|
|
|
|
select V4L2_FWNODE
|
|
|
|
|
select GENERIC_PHY_MIPI_DPHY
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable this to support the Image Signal Processing (ISP) module
|
|
|
|
|
present in RK3399 SoCs.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called rockchip-isp1.
|
|
|
|
|
|
2013-03-24 15:54:25 +00:00
|
|
|
source "drivers/media/platform/exynos4-is/Kconfig"
|
2014-12-09 19:43:44 +00:00
|
|
|
source "drivers/media/platform/am437x/Kconfig"
|
2013-05-15 14:36:19 +00:00
|
|
|
source "drivers/media/platform/xilinx/Kconfig"
|
2016-04-26 13:22:19 +00:00
|
|
|
source "drivers/media/platform/rcar-vin/Kconfig"
|
2016-08-17 06:05:27 +00:00
|
|
|
source "drivers/media/platform/atmel/Kconfig"
|
2019-08-22 08:21:13 +00:00
|
|
|
source "drivers/media/platform/sunxi/Kconfig"
|
2011-03-02 16:16:37 +00:00
|
|
|
|
2016-01-06 23:37:26 +00:00
|
|
|
config VIDEO_TI_CAL
|
|
|
|
|
tristate "TI CAL (Camera Adaptation Layer) driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2019-11-12 14:53:42 +00:00
|
|
|
depends on SOC_DRA7XX || ARCH_K3 || COMPILE_TEST
|
2016-01-06 23:37:26 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2016-08-26 23:17:25 +00:00
|
|
|
select V4L2_FWNODE
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-01-06 23:37:26 +00:00
|
|
|
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).
|
|
|
|
|
|
2021-03-04 13:45:21 +00:00
|
|
|
config VIDEO_TI_CAL_MC
|
|
|
|
|
bool "Media Controller centric mode by default"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on VIDEO_TI_CAL
|
2021-03-04 13:45:21 +00:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enables Media Controller centric mode by default.
|
|
|
|
|
|
|
|
|
|
If set, CAL driver will start in Media Controller mode by
|
|
|
|
|
default. Note that this behavior can be overridden via
|
|
|
|
|
module parameter 'mc_api'.
|
|
|
|
|
|
2021-10-05 19:04:27 +00:00
|
|
|
config VIDEO_RCAR_ISP
|
|
|
|
|
tristate "R-Car Image Signal Processor (ISP)"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_PLATFORM_DRIVERS
|
2021-10-05 19:04:27 +00:00
|
|
|
depends on VIDEO_V4L2 && OF
|
|
|
|
|
depends on ARCH_RENESAS || COMPILE_TEST
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
|
|
|
|
select RESET_CONTROLLER
|
|
|
|
|
select V4L2_FWNODE
|
|
|
|
|
help
|
|
|
|
|
Support for Renesas R-Car Image Signal Processor (ISP).
|
|
|
|
|
Enable this to support the Renesas R-Car Image Signal
|
|
|
|
|
Processor (ISP).
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called rcar-isp.
|
|
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
# Mem2mem drivers
|
2010-04-23 08:38:38 +00:00
|
|
|
|
2020-12-02 13:30:37 +00:00
|
|
|
config VIDEO_ALLEGRO_DVT
|
|
|
|
|
tristate "Allegro DVT Video IP Core"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2020-12-02 13:30:37 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_ZYNQMP || COMPILE_TEST
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select REGMAP_MMIO
|
|
|
|
|
help
|
|
|
|
|
Support for the encoder video IP core by Allegro DVT. This core is
|
|
|
|
|
found for example on the Xilinx ZynqMP SoC in the EV family and is
|
|
|
|
|
called VCU in the reference manual.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called allegro.
|
|
|
|
|
|
2012-07-26 08:53:35 +00:00
|
|
|
config VIDEO_CODA
|
|
|
|
|
tristate "Chips&Media Coda multi-standard codec IP"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2020-12-02 14:13:26 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2 && OF && (ARCH_MXC || COMPILE_TEST)
|
2013-09-30 14:12:22 +00:00
|
|
|
select SRAM
|
2012-07-26 08:53:35 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2015-01-23 16:51:30 +00:00
|
|
|
select VIDEOBUF2_VMALLOC
|
2020-03-18 18:35:33 +00:00
|
|
|
select V4L2_JPEG_HELPER
|
2012-07-26 08:53:35 +00:00
|
|
|
select V4L2_MEM2MEM_DEV
|
2014-07-11 09:36:25 +00:00
|
|
|
select GENERIC_ALLOCATOR
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2012-07-26 08:53:35 +00:00
|
|
|
Coda is a range of video codec IPs that supports
|
|
|
|
|
H.264, MPEG-4, and other video formats.
|
|
|
|
|
|
2017-01-20 14:00:20 +00:00
|
|
|
config VIDEO_IMX_VDOA
|
|
|
|
|
def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
|
|
|
|
|
|
2016-12-14 08:04:48 +00:00
|
|
|
config VIDEO_MEDIATEK_JPEG
|
|
|
|
|
tristate "Mediatek JPEG Codec driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2020-01-13 03:52:02 +00:00
|
|
|
depends on MTK_IOMMU_V1 || MTK_IOMMU || COMPILE_TEST
|
2016-12-14 08:04:48 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_MEDIATEK || COMPILE_TEST
|
2021-02-26 14:07:14 +00:00
|
|
|
depends on MTK_SMI || (COMPILE_TEST && MTK_SMI=n)
|
2016-12-14 08:04:48 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-12-14 08:04:48 +00:00
|
|
|
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
|
|
|
|
|
|
2016-05-03 10:11:21 +00:00
|
|
|
config VIDEO_MEDIATEK_VPU
|
|
|
|
|
tristate "Mediatek Video Processor Unit"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2016-05-03 10:11:21 +00:00
|
|
|
depends on ARCH_MEDIATEK || COMPILE_TEST
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-05-03 10:11:21 +00:00
|
|
|
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.
|
|
|
|
|
|
2016-09-08 13:09:03 +00:00
|
|
|
config VIDEO_MEDIATEK_MDP
|
|
|
|
|
tristate "Mediatek MDP driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2016-09-08 13:09:03 +00:00
|
|
|
depends on MTK_IOMMU || COMPILE_TEST
|
|
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_MEDIATEK || COMPILE_TEST
|
2021-02-26 14:07:14 +00:00
|
|
|
depends on MTK_SMI || (COMPILE_TEST && MTK_SMI=n)
|
2016-09-08 13:09:03 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
select VIDEO_MEDIATEK_VPU
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-09-08 13:09:03 +00:00
|
|
|
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.
|
|
|
|
|
|
2016-05-03 10:11:24 +00:00
|
|
|
config VIDEO_MEDIATEK_VCODEC
|
|
|
|
|
tristate "Mediatek Video Codec driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2016-07-08 19:11:19 +00:00
|
|
|
depends on MTK_IOMMU || COMPILE_TEST
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2016-05-03 10:11:24 +00:00
|
|
|
depends on ARCH_MEDIATEK || COMPILE_TEST
|
2020-10-13 12:44:28 +00:00
|
|
|
depends on VIDEO_MEDIATEK_VPU || MTK_SCP
|
|
|
|
|
# The two following lines ensure we have the same state ("m" or "y") as
|
|
|
|
|
# our dependencies, to avoid missing symbols during link.
|
|
|
|
|
depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
|
|
|
|
|
depends on MTK_SCP || !MTK_SCP
|
2021-02-26 14:07:14 +00:00
|
|
|
depends on MTK_SMI || (COMPILE_TEST && MTK_SMI=n)
|
2016-05-03 10:11:24 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2020-10-13 12:44:28 +00:00
|
|
|
select VIDEO_MEDIATEK_VCODEC_VPU if VIDEO_MEDIATEK_VPU
|
|
|
|
|
select VIDEO_MEDIATEK_VCODEC_SCP if MTK_SCP
|
2021-08-06 04:15:27 +00:00
|
|
|
select V4L2_H264
|
2021-08-06 04:15:28 +00:00
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select MEDIA_CONTROLLER_REQUEST_API
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2020-10-13 12:44:28 +00:00
|
|
|
Mediatek video codec driver provides HW capability to
|
|
|
|
|
encode and decode in a range of video formats on MT8173
|
|
|
|
|
and MT8183.
|
|
|
|
|
|
|
|
|
|
Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
|
|
|
|
|
also be selected. Support for MT8183 depends on MTK_SCP.
|
|
|
|
|
|
|
|
|
|
To compile this driver as modules, choose M here: the
|
|
|
|
|
modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
|
|
|
|
|
|
|
|
|
|
config VIDEO_MEDIATEK_VCODEC_VPU
|
|
|
|
|
bool
|
2016-05-03 10:11:24 +00:00
|
|
|
|
2020-10-13 12:44:28 +00:00
|
|
|
config VIDEO_MEDIATEK_VCODEC_SCP
|
|
|
|
|
bool
|
2016-05-03 10:11:24 +00:00
|
|
|
|
2012-07-26 08:55:18 +00:00
|
|
|
config VIDEO_MEM2MEM_DEINTERLACE
|
|
|
|
|
tristate "Deinterlace support"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2018-05-18 21:07:47 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2014-08-26 19:45:39 +00:00
|
|
|
depends on HAS_DMA
|
2012-07-26 08:55:18 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
Generic deinterlacing V4L2 driver.
|
|
|
|
|
|
2020-12-02 17:44:15 +00:00
|
|
|
config VIDEO_MESON_GE2D
|
|
|
|
|
tristate "Amlogic 2D Graphic Acceleration Unit"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2020-12-02 17:44:15 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_MESON || COMPILE_TEST
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
This is a v4l2 driver for Amlogic GE2D 2D graphics accelerator.
|
|
|
|
|
GE2D is a standalone 2D graphic acceleration unit, with color converter,
|
|
|
|
|
image scaling, BitBLT & alpha blending operations.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
2011-10-06 14:32:12 +00:00
|
|
|
config VIDEO_SAMSUNG_S5P_G2D
|
|
|
|
|
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2014-08-20 19:21:35 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2014-10-06 16:08:06 +00:00
|
|
|
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
|
2011-10-06 14:32:12 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2011-10-06 14:32:12 +00:00
|
|
|
This is a v4l2 driver for Samsung S5P and EXYNOS4 G2D
|
|
|
|
|
2d graphics accelerator.
|
2010-08-03 12:50:29 +00:00
|
|
|
|
2011-11-24 14:15:23 +00:00
|
|
|
config VIDEO_SAMSUNG_S5P_JPEG
|
2014-07-11 15:19:42 +00:00
|
|
|
tristate "Samsung S5P/Exynos3250/Exynos4 JPEG codec driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2014-08-20 19:21:35 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2014-10-06 16:08:06 +00:00
|
|
|
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
|
2011-11-24 14:15:23 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2014-07-11 15:19:42 +00:00
|
|
|
This is a v4l2 driver for Samsung S5P, EXYNOS3250
|
|
|
|
|
and EXYNOS4 JPEG codec
|
2011-11-24 14:15:23 +00:00
|
|
|
|
2011-06-21 13:51:26 +00:00
|
|
|
config VIDEO_SAMSUNG_S5P_MFC
|
2012-10-04 01:19:11 +00:00
|
|
|
tristate "Samsung S5P MFC Video Codec"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2014-08-20 19:21:35 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2014-10-06 16:08:06 +00:00
|
|
|
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
|
2011-06-21 13:51:26 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
help
|
2012-10-04 01:19:11 +00:00
|
|
|
MFC 5.1 and 6.x driver for V4L2
|
2011-06-21 13:51:26 +00:00
|
|
|
|
2012-08-16 13:19:56 +00:00
|
|
|
config VIDEO_SAMSUNG_EXYNOS_GSC
|
|
|
|
|
tristate "Samsung Exynos G-Scaler driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2014-08-20 19:21:35 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2016-11-09 14:29:37 +00:00
|
|
|
depends on ARCH_EXYNOS || COMPILE_TEST
|
2012-08-16 13:19:56 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
|
|
|
|
|
|
2015-05-12 16:02:10 +00:00
|
|
|
config VIDEO_STI_BDISP
|
|
|
|
|
tristate "STMicroelectronics BDISP 2D blitter driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2015-05-12 16:02:10 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
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.
|
|
|
|
|
|
2016-09-05 14:06:29 +00:00
|
|
|
config VIDEO_STI_HVA
|
|
|
|
|
tristate "STMicroelectronics HVA multi-format video encoder V4L2 driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2016-09-05 14:06:29 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
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.
|
|
|
|
|
|
[media] st-hva: add debug file system
This patch creates 4 static debugfs entries to dump:
- the device-related information ("st-hva/device")
- the list of registered encoders ("st-hva/encoders")
- the current values of the hva registers ("st-hva/regs")
- the information about the last closed instance ("st-hva/last")
It also creates dynamically a debugfs entry for each opened instance,
("st-hva/<instance identifier>") to dump:
- the information about the frame (format, resolution)
- the information about the stream (format, profile, level,
resolution)
- the control parameters (bitrate mode, framerate, GOP size...)
- the potential (system, encoding...) errors
- the performance information about the encoding (HW processing
duration, average bitrate, average framerate...)
Each time a running instance is closed, its context (including the
debug information) is saved to feed, on demand, the last closed
instance debugfs entry.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Jean-Christophe Trotin <jean-christophe.trotin@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-31 10:37:57 +00:00
|
|
|
config VIDEO_STI_HVA_DEBUGFS
|
|
|
|
|
bool "Export STMicroelectronics HVA internals in debugfs"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
[media] st-hva: add debug file system
This patch creates 4 static debugfs entries to dump:
- the device-related information ("st-hva/device")
- the list of registered encoders ("st-hva/encoders")
- the current values of the hva registers ("st-hva/regs")
- the information about the last closed instance ("st-hva/last")
It also creates dynamically a debugfs entry for each opened instance,
("st-hva/<instance identifier>") to dump:
- the information about the frame (format, resolution)
- the information about the stream (format, profile, level,
resolution)
- the control parameters (bitrate mode, framerate, GOP size...)
- the potential (system, encoding...) errors
- the performance information about the encoding (HW processing
duration, average bitrate, average framerate...)
Each time a running instance is closed, its context (including the
debug information) is saved to feed, on demand, the last closed
instance debugfs entry.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Jean-Christophe Trotin <jean-christophe.trotin@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-31 10:37:57 +00:00
|
|
|
depends on VIDEO_STI_HVA
|
|
|
|
|
depends on DEBUG_FS
|
|
|
|
|
help
|
|
|
|
|
Select this to see information about the internal state and the last
|
2018-01-04 11:47:28 +00:00
|
|
|
operation of STMicroelectronics HVA multi-format video encoder in
|
|
|
|
|
debugfs.
|
[media] st-hva: add debug file system
This patch creates 4 static debugfs entries to dump:
- the device-related information ("st-hva/device")
- the list of registered encoders ("st-hva/encoders")
- the current values of the hva registers ("st-hva/regs")
- the information about the last closed instance ("st-hva/last")
It also creates dynamically a debugfs entry for each opened instance,
("st-hva/<instance identifier>") to dump:
- the information about the frame (format, resolution)
- the information about the stream (format, profile, level,
resolution)
- the control parameters (bitrate mode, framerate, GOP size...)
- the potential (system, encoding...) errors
- the performance information about the encoding (HW processing
duration, average bitrate, average framerate...)
Each time a running instance is closed, its context (including the
debug information) is saved to feed, on demand, the last closed
instance debugfs entry.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Jean-Christophe Trotin <jean-christophe.trotin@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-31 10:37:57 +00:00
|
|
|
|
2018-01-04 11:47:28 +00:00
|
|
|
Choose N unless you know you need this.
|
[media] st-hva: add debug file system
This patch creates 4 static debugfs entries to dump:
- the device-related information ("st-hva/device")
- the list of registered encoders ("st-hva/encoders")
- the current values of the hva registers ("st-hva/regs")
- the information about the last closed instance ("st-hva/last")
It also creates dynamically a debugfs entry for each opened instance,
("st-hva/<instance identifier>") to dump:
- the information about the frame (format, resolution)
- the information about the stream (format, profile, level,
resolution)
- the control parameters (bitrate mode, framerate, GOP size...)
- the potential (system, encoding...) errors
- the performance information about the encoding (HW processing
duration, average bitrate, average framerate...)
Each time a running instance is closed, its context (including the
debug information) is saved to feed, on demand, the last closed
instance debugfs entry.
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Jean-Christophe Trotin <jean-christophe.trotin@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-01-31 10:37:57 +00:00
|
|
|
|
2017-02-02 14:59:48 +00:00
|
|
|
config VIDEO_STI_DELTA
|
|
|
|
|
tristate "STMicroelectronics DELTA multi-format video decoder V4L2 driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2017-02-02 14:59:48 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_STI || COMPILE_TEST
|
|
|
|
|
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.
|
|
|
|
|
|
2017-02-02 14:59:52 +00:00
|
|
|
config VIDEO_STI_DELTA_MJPEG
|
|
|
|
|
bool "STMicroelectronics DELTA MJPEG support"
|
|
|
|
|
default y
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on VIDEO_STI_DELTA
|
2017-02-02 14:59:52 +00:00
|
|
|
help
|
|
|
|
|
Enables DELTA MJPEG hardware support.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here:
|
|
|
|
|
the module will be called st-delta.
|
|
|
|
|
|
2017-02-02 14:59:48 +00:00
|
|
|
config VIDEO_STI_DELTA_DRIVER
|
|
|
|
|
tristate
|
|
|
|
|
depends on VIDEO_STI_DELTA
|
2017-02-02 14:59:52 +00:00
|
|
|
depends on VIDEO_STI_DELTA_MJPEG
|
|
|
|
|
default VIDEO_STI_DELTA_MJPEG
|
2017-02-02 14:59:48 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2017-02-02 14:59:50 +00:00
|
|
|
select RPMSG
|
2017-02-02 14:59:48 +00:00
|
|
|
|
2021-10-19 08:43:23 +00:00
|
|
|
config VIDEO_STM32_DMA2D
|
|
|
|
|
tristate "STM32 Chrom-Art Accelerator (DMA2D)"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2021-10-28 06:40:20 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_STM32 || COMPILE_TEST
|
2021-10-19 08:43:23 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
Enables DMA2D hardware support on stm32.
|
|
|
|
|
|
|
|
|
|
The STM32 DMA2D is a memory-to-memory engine for pixel conversion
|
|
|
|
|
and specialized DMA dedicated to image manipulation.
|
|
|
|
|
|
2016-06-30 13:41:23 +00:00
|
|
|
config VIDEO_RENESAS_FDP1
|
|
|
|
|
tristate "Renesas Fine Display Processor"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2018-05-18 10:51:23 +00:00
|
|
|
depends on ARCH_RENESAS || COMPILE_TEST
|
2018-07-11 14:23:32 +00:00
|
|
|
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
|
2016-06-30 13:41:23 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-06-30 13:41:23 +00:00
|
|
|
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 11:23:03 +00:00
|
|
|
config VIDEO_RENESAS_JPU
|
|
|
|
|
tristate "Renesas JPEG Processing Unit"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2016-03-25 01:46:45 +00:00
|
|
|
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 11:23:03 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
[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 11:23:03 +00:00
|
|
|
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.
|
|
|
|
|
|
2016-02-12 00:29:58 +00:00
|
|
|
config VIDEO_RENESAS_FCP
|
|
|
|
|
tristate "Renesas Frame Compression Processor"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2016-02-12 00:29:58 +00:00
|
|
|
depends on ARCH_RENESAS || COMPILE_TEST
|
|
|
|
|
depends on OF
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2016-02-12 00:29:58 +00:00
|
|
|
This is a driver for the Renesas Frame Compression Processor (FCP).
|
|
|
|
|
The FCP is a companion module of video processing modules in the
|
2020-09-11 10:10:46 +00:00
|
|
|
Renesas R-Car Gen3 and RZ/G2 SoCs. It handles memory access for
|
|
|
|
|
the codec, VSP and FDP modules.
|
2016-02-12 00:29:58 +00:00
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module
|
|
|
|
|
will be called rcar-fcp.
|
|
|
|
|
|
2013-06-04 14:22:30 +00:00
|
|
|
config VIDEO_RENESAS_VSP1
|
|
|
|
|
tristate "Renesas VSP1 Video Processing Engine"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
depends on VIDEO_V4L2
|
2018-02-26 18:09:10 +00:00
|
|
|
depends on ARCH_RENESAS || COMPILE_TEST
|
2016-06-30 12:23:03 +00:00
|
|
|
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
|
media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.
Right now, someone need to first enable those APIs before
using those drivers.
Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.
So, be it.
Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-25 14:36:56 +00:00
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select VIDEO_V4L2_SUBDEV_API
|
2013-06-04 14:22:30 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2016-09-07 11:58:49 +00:00
|
|
|
select VIDEOBUF2_VMALLOC
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2013-06-04 14:22:30 +00:00
|
|
|
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.
|
|
|
|
|
|
2017-10-11 07:29:35 +00:00
|
|
|
config VIDEO_ROCKCHIP_RGA
|
|
|
|
|
tristate "Rockchip Raster 2d Graphic Acceleration Unit"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
2017-10-11 07:29:35 +00:00
|
|
|
depends on ARCH_ROCKCHIP || COMPILE_TEST
|
|
|
|
|
select VIDEOBUF2_DMA_SG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2017-10-11 07:29:35 +00:00
|
|
|
This is a v4l2 driver for Rockchip SOC RGA 2d graphics accelerator.
|
|
|
|
|
Rockchip RGA is a separate 2D raster graphic acceleration unit.
|
|
|
|
|
It accelerates 2D graphics operations, such as point/line drawing,
|
|
|
|
|
image scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
[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 05:36:47 +00:00
|
|
|
config VIDEO_TI_VPE
|
|
|
|
|
tristate "TI VPE (Video Processing Engine) driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2014-08-20 19:41:56 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on SOC_DRA7XX || COMPILE_TEST
|
[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 05:36:47 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
2016-11-18 23:20:11 +00:00
|
|
|
select VIDEO_TI_VPDMA
|
2016-11-18 23:20:39 +00:00
|
|
|
select VIDEO_TI_SC
|
2016-11-18 23:20:43 +00:00
|
|
|
select VIDEO_TI_CSC
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
[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 05:36:47 +00:00
|
|
|
Support for the TI VPE(Video Processing Engine) block
|
|
|
|
|
found on DRA7XX SoC.
|
|
|
|
|
|
|
|
|
|
config VIDEO_TI_VPE_DEBUG
|
|
|
|
|
bool "VPE debug messages"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
[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 05:36:47 +00:00
|
|
|
depends on VIDEO_TI_VPE
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
[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 05:36:47 +00:00
|
|
|
Enable debug messages on VPE driver.
|
|
|
|
|
|
2017-06-15 16:31:50 +00:00
|
|
|
config VIDEO_QCOM_VENUS
|
|
|
|
|
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2021-04-12 08:05:08 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM
|
2017-06-20 13:13:50 +00:00
|
|
|
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
|
2017-07-17 08:56:49 +00:00
|
|
|
select QCOM_MDT_LOADER if ARCH_QCOM
|
2021-09-28 07:50:27 +00:00
|
|
|
select QCOM_SCM
|
2020-12-14 12:57:03 +00:00
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
2017-06-15 16:31:50 +00:00
|
|
|
select V4L2_MEM2MEM_DEV
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2017-06-15 16:31:50 +00:00
|
|
|
This is a V4L2 driver for Qualcomm Venus video accelerator
|
|
|
|
|
hardware. It accelerates encoding and decoding operations
|
|
|
|
|
on various Qualcomm SoCs.
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
media: sun4i: Add H3 deinterlace driver
Allwinner H3 SoC contains deinterlace unit, which has several modes of
operation - bypass, weave, bob and mixed (advanced) mode. I don't know
how mixed mode works, but according to Allwinner it gives best results,
so they use it exclusively. Currently this mode is also hardcoded here.
For each interleaved frame queued, this driver produces 2 deinterlaced
frames. Deinterlaced frames are based on 2 consequtive output buffers,
except for the first 2, where same output buffer is given to peripheral
as current and previous.
There is no documentation for this core, so register layout and fixed
values were taken from BSP driver.
I'm not sure if maximum size of the image unit is capable to process is
governed by size of "flag" buffers, frequency or it really is some HW
limitation. Currently driver can process full HD image in ~15ms (7.5ms
for each capture buffer), which allows to process 1920x1080@60i video
smoothly in real time.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
[hverkuil-cisco@xs4all.nl: add static to deinterlace_ioctl_ops]
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-23 22:13:31 +00:00
|
|
|
config VIDEO_SUN8I_DEINTERLACE
|
|
|
|
|
tristate "Allwinner Deinterlace driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
media: sun4i: Add H3 deinterlace driver
Allwinner H3 SoC contains deinterlace unit, which has several modes of
operation - bypass, weave, bob and mixed (advanced) mode. I don't know
how mixed mode works, but according to Allwinner it gives best results,
so they use it exclusively. Currently this mode is also hardcoded here.
For each interleaved frame queued, this driver produces 2 deinterlaced
frames. Deinterlaced frames are based on 2 consequtive output buffers,
except for the first 2, where same output buffer is given to peripheral
as current and previous.
There is no documentation for this core, so register layout and fixed
values were taken from BSP driver.
I'm not sure if maximum size of the image unit is capable to process is
governed by size of "flag" buffers, frequency or it really is some HW
limitation. Currently driver can process full HD image in ~15ms (7.5ms
for each capture buffer), which allows to process 1920x1080@60i video
smoothly in real time.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
[hverkuil-cisco@xs4all.nl: add static to deinterlace_ioctl_ops]
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-23 22:13:31 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_SUNXI || COMPILE_TEST
|
|
|
|
|
depends on COMMON_CLK && OF
|
|
|
|
|
depends on PM
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
Support for the Allwinner deinterlace unit with scaling
|
|
|
|
|
capability found on some SoCs, like H3.
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
2020-01-24 23:20:12 +00:00
|
|
|
config VIDEO_SUN8I_ROTATE
|
|
|
|
|
tristate "Allwinner DE2 rotation driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2020-01-24 23:20:12 +00:00
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
depends on ARCH_SUNXI || COMPILE_TEST
|
|
|
|
|
depends on COMMON_CLK && OF
|
|
|
|
|
depends on PM
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
Support for the Allwinner DE2 rotation unit.
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
2022-02-20 20:46:21 +00:00
|
|
|
config VIDEO_TEGRA_VDE
|
|
|
|
|
tristate "NVIDIA Tegra Video Decoder Engine driver"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2022-02-20 20:46:21 +00:00
|
|
|
depends on ARCH_TEGRA || COMPILE_TEST
|
|
|
|
|
depends on VIDEO_DEV && VIDEO_V4L2
|
|
|
|
|
select DMA_SHARED_BUFFER
|
|
|
|
|
select IOMMU_IOVA
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select MEDIA_CONTROLLER_REQUEST_API
|
|
|
|
|
select SRAM
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select VIDEOBUF2_DMA_SG
|
|
|
|
|
select V4L2_H264
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
help
|
|
|
|
|
Support for the NVIDIA Tegra video decoder unit.
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
2022-02-24 03:10:13 +00:00
|
|
|
config VIDEO_AMPHION_VPU
|
|
|
|
|
tristate "Amphion VPU (Video Processing Unit) Codec IP"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on V4L_MEM2MEM_DRIVERS
|
2022-02-24 03:10:13 +00:00
|
|
|
depends on ARCH_MXC || COMPILE_TEST
|
|
|
|
|
depends on MEDIA_SUPPORT
|
|
|
|
|
depends on VIDEO_DEV
|
|
|
|
|
depends on VIDEO_V4L2
|
|
|
|
|
select MEDIA_CONTROLLER
|
|
|
|
|
select V4L2_MEM2MEM_DEV
|
|
|
|
|
select VIDEOBUF2_DMA_CONTIG
|
|
|
|
|
select VIDEOBUF2_VMALLOC
|
|
|
|
|
help
|
|
|
|
|
Amphion VPU Codec IP contains two parts: Windsor and Malone.
|
|
|
|
|
Windsor is encoder that supports H.264, and Malone is decoder
|
|
|
|
|
that supports H.264, HEVC, and other video formats.
|
|
|
|
|
This is a V4L2 driver for NXP MXC 8Q video accelerator hardware.
|
|
|
|
|
It accelerates encoding and decoding operations on
|
|
|
|
|
various NXP SoCs.
|
|
|
|
|
To compile this driver as a module choose m here.
|
|
|
|
|
|
2016-11-18 23:20:11 +00:00
|
|
|
# TI VIDEO PORT Helper Modules
|
|
|
|
|
# These will be selected by VPE and VIP
|
|
|
|
|
config VIDEO_TI_VPDMA
|
|
|
|
|
tristate
|
|
|
|
|
|
2016-11-18 23:20:39 +00:00
|
|
|
config VIDEO_TI_SC
|
|
|
|
|
tristate
|
|
|
|
|
|
2016-11-18 23:20:43 +00:00
|
|
|
config VIDEO_TI_CSC
|
|
|
|
|
tristate
|
|
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
# DVB platform drivers
|
2015-07-30 17:09:00 +00:00
|
|
|
source "drivers/media/platform/sti/c8sectpfe/Kconfig"
|
2017-06-12 13:26:19 +00:00
|
|
|
|
2022-03-11 10:21:45 +00:00
|
|
|
# SDR platform drivers
|
2017-06-12 13:26:19 +00:00
|
|
|
config VIDEO_RCAR_DRIF
|
2019-02-18 19:29:00 +00:00
|
|
|
tristate "Renesas Digital Radio Interface (DRIF)"
|
2022-03-11 10:21:45 +00:00
|
|
|
depends on SDR_PLATFORM_DRIVERS
|
2018-05-17 17:18:12 +00:00
|
|
|
depends on VIDEO_V4L2
|
2017-06-12 13:26:19 +00:00
|
|
|
depends on ARCH_RENESAS || COMPILE_TEST
|
|
|
|
|
select VIDEOBUF2_VMALLOC
|
2021-07-21 15:24:59 +00:00
|
|
|
select V4L2_ASYNC
|
2019-03-20 10:39:44 +00:00
|
|
|
help
|
2017-06-12 13:26:19 +00:00
|
|
|
Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is Digital
|
|
|
|
|
Radio Interface that interfaces with an RF front end chip. It is a
|
|
|
|
|
receiver of digital data which uses DMA to transfer received data to
|
|
|
|
|
a configured location for an application to use.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here; the module
|
|
|
|
|
will be called rcar_drif.
|
