* [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, Fabio Estevam, devel,
linux-renesas-soc, linux-samsung-soc, Mauro Carvalho Chehab,
Chen-Yu Tsai, Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Philipp Zabel, Sakari Ailus, Sascha Hauer,
Maxime Ripard, Niklas Söderlund, Helen Koike, Yong Deng,
Ezequiel Garcia, linux-arm-kernel, Hyun Kwon, Heungjun Kim,
Paul Kocialkowski, Kyungmin Park, Pengutronix Kernel Team,
Greg Kroah-Hartman, Hans Verkuil, Shawn Guo
That's the second part of media Kconfig changes. The entire series is
at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
It addresses some issues I noticed when reviewing the series, and do
some changes on how things will be displayed.
It also simplify dependencencies on media-controller-dependent drivers,
by auto-selecting the needed deps.
It should be noticed that the media controller may also optionally
selected for several other drivers, so there is still a prompt to allow
manually enabling it, in the case it was not auto-selected.
PS.: While not needed anymore, because all dependent drivers auto
select, at least for now, I opted to keep the prompt for:
- VIDEO_V4L2_SUBDEV_API
The rationale is that there are a few drivers that can optionally depend
on it (like tvp5150). So, better to keep the dependency, in order to be
able to test those drivers with and without the option.
- MEDIA_CONTROLLER_REQUEST_API
The rationale is that there are some warnings at the Request API, and
it would be good to keep it, at least while drivers are on staging.
Mauro Carvalho Chehab (4):
media: dvb-core: Kconfig: default to use dynamic minors
media: Kconfig files: use select for V4L2 subdevs and MC
media: i2c/Kconfig: reorganize items there
media: Kconfig: don't use visible for device type select
drivers/media/Kconfig | 25 +-
drivers/media/dvb-core/Kconfig | 1 +
drivers/media/i2c/Kconfig | 406 +++++++++++-------
drivers/media/i2c/et8ek8/Kconfig | 4 +-
drivers/media/i2c/m5mols/Kconfig | 5 +-
drivers/media/i2c/smiapp/Kconfig | 5 +-
drivers/media/pci/cobalt/Kconfig | 4 +-
drivers/media/pci/intel/ipu3/Kconfig | 4 +-
drivers/media/pci/sta2x11/Kconfig | 6 +-
drivers/media/platform/Kconfig | 28 +-
drivers/media/platform/am437x/Kconfig | 4 +-
drivers/media/platform/atmel/Kconfig | 4 +-
drivers/media/platform/cadence/Kconfig | 8 +-
drivers/media/platform/exynos4-is/Kconfig | 5 +-
drivers/media/platform/rcar-vin/Kconfig | 8 +-
.../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
.../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
drivers/media/platform/xilinx/Kconfig | 4 +-
drivers/media/spi/Kconfig | 4 +-
drivers/media/test_drivers/vimc/Kconfig | 4 +-
drivers/staging/media/hantro/Kconfig | 5 +-
drivers/staging/media/imx/Kconfig | 5 +-
drivers/staging/media/ipu3/Kconfig | 3 +-
drivers/staging/media/omap4iss/Kconfig | 4 +-
drivers/staging/media/rkisp1/Kconfig | 4 +-
drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
26 files changed, 349 insertions(+), 214 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, devel,
linux-renesas-soc, linux-samsung-soc, Mauro Carvalho Chehab,
Chen-Yu Tsai, Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Philipp Zabel, Sakari Ailus, Sascha Hauer,
Maxime Ripard, Niklas Söderlund, Helen Koike, Yong Deng,
Ezequiel Garcia, linux-arm-kernel, Hyun Kwon, Heungjun Kim,
Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Shawn Guo
That's the second part of media Kconfig changes. The entire series is
at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
It addresses some issues I noticed when reviewing the series, and do
some changes on how things will be displayed.
It also simplify dependencencies on media-controller-dependent drivers,
by auto-selecting the needed deps.
It should be noticed that the media controller may also optionally
selected for several other drivers, so there is still a prompt to allow
manually enabling it, in the case it was not auto-selected.
PS.: While not needed anymore, because all dependent drivers auto
select, at least for now, I opted to keep the prompt for:
- VIDEO_V4L2_SUBDEV_API
The rationale is that there are a few drivers that can optionally depend
on it (like tvp5150). So, better to keep the dependency, in order to be
able to test those drivers with and without the option.
- MEDIA_CONTROLLER_REQUEST_API
The rationale is that there are some warnings at the Request API, and
it would be good to keep it, at least while drivers are on staging.
Mauro Carvalho Chehab (4):
media: dvb-core: Kconfig: default to use dynamic minors
media: Kconfig files: use select for V4L2 subdevs and MC
media: i2c/Kconfig: reorganize items there
media: Kconfig: don't use visible for device type select
drivers/media/Kconfig | 25 +-
drivers/media/dvb-core/Kconfig | 1 +
drivers/media/i2c/Kconfig | 406 +++++++++++-------
drivers/media/i2c/et8ek8/Kconfig | 4 +-
drivers/media/i2c/m5mols/Kconfig | 5 +-
drivers/media/i2c/smiapp/Kconfig | 5 +-
drivers/media/pci/cobalt/Kconfig | 4 +-
drivers/media/pci/intel/ipu3/Kconfig | 4 +-
drivers/media/pci/sta2x11/Kconfig | 6 +-
drivers/media/platform/Kconfig | 28 +-
drivers/media/platform/am437x/Kconfig | 4 +-
drivers/media/platform/atmel/Kconfig | 4 +-
drivers/media/platform/cadence/Kconfig | 8 +-
drivers/media/platform/exynos4-is/Kconfig | 5 +-
drivers/media/platform/rcar-vin/Kconfig | 8 +-
.../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
.../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
drivers/media/platform/xilinx/Kconfig | 4 +-
drivers/media/spi/Kconfig | 4 +-
drivers/media/test_drivers/vimc/Kconfig | 4 +-
drivers/staging/media/hantro/Kconfig | 5 +-
drivers/staging/media/imx/Kconfig | 5 +-
drivers/staging/media/ipu3/Kconfig | 3 +-
drivers/staging/media/omap4iss/Kconfig | 4 +-
drivers/staging/media/rkisp1/Kconfig | 4 +-
drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
26 files changed, 349 insertions(+), 214 deletions(-)
--
2.25.1
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 1/4] media: dvb-core: Kconfig: default to use dynamic minors
2020-03-25 16:03 ` Mauro Carvalho Chehab
(?)
(?)
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab
All modern Linux distributions nowadays use udev or some
alternative (like systemd). So, it makes sense to change
the default to use dynamic minors.
Please notice that this default doesn't enable any code.
It just changes the dvb-core behavior.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
drivers/media/dvb-core/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-core/Kconfig b/drivers/media/dvb-core/Kconfig
index 0f8e53692b86..6ffac618417b 100644
--- a/drivers/media/dvb-core/Kconfig
+++ b/drivers/media/dvb-core/Kconfig
@@ -45,6 +45,7 @@ config DVB_MAX_ADAPTERS
config DVB_DYNAMIC_MINORS
bool "Dynamic DVB minor allocation"
depends on DVB_CORE
+ default y
help
If you say Y here, the DVB subsystem will use dynamic minor
allocation for any device that uses the DVB major number.
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC
2020-03-25 16:03 ` Mauro Carvalho Chehab
(?)
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Pavel Machek, Sakari Ailus, Kyungmin Park,
Heungjun Kim, Hans Verkuil, Yong Zhi, Bingbu Cao, Tian Shu Qiu,
Lad, Prabhakar, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Sylwester Nawrocki, Kukjin Kim,
Krzysztof Kozlowski, Niklas Söderlund, Maxime Ripard,
Chen-Yu Tsai, Yong Deng, Hyun Kwon, Laurent Pinchart,
Michal Simek, Ezequiel Garcia, Greg Kroah-Hartman,
Steve Longerbeam, Philipp Zabel, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Helen Koike, Paul Kocialkowski, linux-arm-kernel,
linux-samsung-soc, linux-renesas-soc, devel
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>
---
drivers/media/i2c/Kconfig | 210 ++++++++++++------
drivers/media/i2c/et8ek8/Kconfig | 4 +-
drivers/media/i2c/m5mols/Kconfig | 5 +-
drivers/media/i2c/smiapp/Kconfig | 5 +-
drivers/media/pci/cobalt/Kconfig | 4 +-
drivers/media/pci/intel/ipu3/Kconfig | 4 +-
drivers/media/pci/sta2x11/Kconfig | 6 +-
drivers/media/platform/Kconfig | 28 ++-
drivers/media/platform/am437x/Kconfig | 4 +-
drivers/media/platform/atmel/Kconfig | 4 +-
drivers/media/platform/cadence/Kconfig | 8 +-
drivers/media/platform/exynos4-is/Kconfig | 5 +-
drivers/media/platform/rcar-vin/Kconfig | 8 +-
.../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
.../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
drivers/media/platform/xilinx/Kconfig | 4 +-
drivers/media/spi/Kconfig | 4 +-
drivers/media/test_drivers/vimc/Kconfig | 4 +-
drivers/staging/media/hantro/Kconfig | 5 +-
drivers/staging/media/imx/Kconfig | 5 +-
drivers/staging/media/ipu3/Kconfig | 3 +-
drivers/staging/media/omap4iss/Kconfig | 4 +-
drivers/staging/media/rkisp1/Kconfig | 4 +-
drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
24 files changed, 236 insertions(+), 105 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596c13dd..4bc4cfea2f20 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -19,7 +19,7 @@ config VIDEO_IR_I2C
In doubt, say Y.
#
-# Encoder / Decoder module configuration
+# V4L2 I2C drivers that aren't related with Camera support
#
comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
@@ -28,6 +28,10 @@ comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
menu "I2C Encoders, decoders, sensors and other helper chips"
visible if !MEDIA_HIDE_ANCILLARY_SUBDRV
+#
+# Encoder / Decoder module configuration
+#
+
comment "Audio decoders, processors and mixers"
config VIDEO_TVAUDIO
@@ -62,11 +66,13 @@ config VIDEO_TDA9840
config VIDEO_TDA1997X
tristate "NXP TDA1997x HDMI receiver"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on SND_SOC
select HDMI
select SND_PCM
select V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
@@ -204,7 +210,9 @@ comment "Video decoders"
config VIDEO_ADV7180
tristate "Analog Devices ADV7180 decoder"
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Support for the Analog Devices ADV7180 video decoder.
@@ -223,8 +231,10 @@ config VIDEO_ADV7183
config VIDEO_ADV748X
tristate "Analog Devices ADV748x decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -236,8 +246,10 @@ config VIDEO_ADV748X
config VIDEO_ADV7604
tristate "Analog Devices ADV7604 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on GPIOLIB || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select HDMI
select V4L2_FWNODE
@@ -260,7 +272,9 @@ config VIDEO_ADV7604_CEC
config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7842 video decoder.
@@ -347,7 +361,9 @@ config VIDEO_SAA711X
config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
select V4L2_FWNODE
help
@@ -515,8 +531,10 @@ config VIDEO_ADV7393
config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on DRM_I2C_ADV7511=n || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7511 video encoder.
@@ -536,7 +554,10 @@ config VIDEO_ADV7511_CEC
config VIDEO_AD9389B
tristate "Analog Devices AD9389B encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+
help
Support for the Analog Devices AD9389B video encoder.
@@ -568,12 +589,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+#
+# All drivers that are related to Media Camera Support should be here
+#
+
if MEDIA_CAMERA_SUPPORT
config VIDEO_HI556
tristate "Hynix Hi-556 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Hynix
@@ -584,8 +610,10 @@ config VIDEO_HI556
config VIDEO_IMX214
tristate "Sony IMX214 sensor support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && I2C && VIDEO_V4L2
depends on V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a Video4Linux2 sensor driver for the Sony
@@ -596,7 +624,9 @@ config VIDEO_IMX214
config VIDEO_IMX219
tristate "Sony IMX219 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Sony
@@ -607,7 +637,9 @@ config VIDEO_IMX219
config VIDEO_IMX258
tristate "Sony IMX258 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX258 camera.
@@ -617,7 +649,9 @@ config VIDEO_IMX258
config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a V4L2 sensor driver for the Sony IMX274
@@ -625,7 +659,9 @@ config VIDEO_IMX274
config VIDEO_IMX290
tristate "Sony IMX290 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -637,7 +673,9 @@ config VIDEO_IMX290
config VIDEO_IMX319
tristate "Sony IMX319 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX319 camera.
@@ -647,7 +685,9 @@ config VIDEO_IMX319
config VIDEO_IMX355
tristate "Sony IMX355 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX355 camera.
@@ -678,7 +718,8 @@ config VIDEO_OV2659
config VIDEO_OV2680
tristate "OmniVision OV2680 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -689,7 +730,8 @@ config VIDEO_OV2680
config VIDEO_OV2685
tristate "OmniVision OV2685 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -701,7 +743,9 @@ config VIDEO_OV2685
config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Omnivision
@@ -710,7 +754,9 @@ config VIDEO_OV5640
config VIDEO_OV5645
tristate "OmniVision OV5645 sensor support"
depends on OF
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -721,7 +767,9 @@ config VIDEO_OV5645
config VIDEO_OV5647
tristate "OmniVision OV5647 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -742,8 +790,9 @@ config VIDEO_OV6650
config VIDEO_OV5670
tristate "OmniVision OV5670 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -754,8 +803,9 @@ config VIDEO_OV5670
config VIDEO_OV5675
tristate "OmniVision OV5675 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -777,7 +827,9 @@ config VIDEO_OV5695
config VIDEO_OV7251
tristate "OmniVision OV7251 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -826,7 +878,9 @@ config VIDEO_OV7740
config VIDEO_OV8856
tristate "OmniVision OV8856 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -844,7 +898,9 @@ config VIDEO_OV9640
config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_SCCB
help
This is a V4L2 sensor driver for the Omnivision
@@ -852,7 +908,9 @@ config VIDEO_OV9650
config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -870,14 +928,18 @@ config VIDEO_VS6624
config VIDEO_MT9M001
tristate "mt9m001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
config VIDEO_MT9M032
tristate "MT9M032 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This driver supports MT9M032 camera sensors from Aptina, monochrome
@@ -893,7 +955,9 @@ config VIDEO_MT9M111
config VIDEO_MT9P031
tristate "Aptina MT9P031 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This is a Video4Linux2 sensor driver for the Aptina
@@ -901,7 +965,9 @@ config VIDEO_MT9P031
config VIDEO_MT9T001
tristate "Aptina MT9T001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Aptina
(Micron) mt0t001 3 Mpixel camera.
@@ -926,7 +992,9 @@ config VIDEO_MT9V011
config VIDEO_MT9V032
tristate "Micron MT9V032 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -951,7 +1019,9 @@ config VIDEO_SR030PC30
config VIDEO_NOON010PC30
tristate "Siliconfile NOON010PC30 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports NOON010PC30 CIF camera from Siliconfile
@@ -969,21 +1039,27 @@ config VIDEO_RJ54N1
config VIDEO_S5K6AA
tristate "Samsung S5K6AAFX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
config VIDEO_S5K6A3
tristate "Samsung S5K6A3 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6A3 raw
camera sensor.
config VIDEO_S5K4ECGX
tristate "Samsung S5K4ECGX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select CRC32
help
This is a V4L2 sensor driver for Samsung S5K4ECGX 5M
@@ -991,7 +1067,9 @@ config VIDEO_S5K4ECGX
config VIDEO_S5K5BAF
tristate "Samsung S5K5BAF sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5K5BAF 2M
@@ -1002,28 +1080,29 @@ source "drivers/media/i2c/et8ek8/Kconfig"
config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
- depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5C73M3
8 Mpixel camera.
-endif
comment "Lens drivers"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_AD5820
tristate "AD5820 lens voice coil support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on GPIOLIB && I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the AD5820 camera lens voice coil.
It is used for example in Nokia N900 (RX-51).
config VIDEO_AK7375
tristate "AK7375 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the AK7375 camera lens voice coil.
AK7375 is a 12 bit DAC with 120mA output current sink
@@ -1032,8 +1111,9 @@ config VIDEO_AK7375
config VIDEO_DW9714
tristate "DW9714 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9714 camera lens voice coil.
DW9714 is a 10 bit DAC with 120mA output current sink
@@ -1042,30 +1122,30 @@ config VIDEO_DW9714
config VIDEO_DW9807_VCM
tristate "DW9807 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9807 camera lens voice coil.
DW9807 is a 10 bit DAC with 100mA output current sink
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
-endif
comment "Flash devices"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_ADP1653
tristate "ADP1653 flash support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the ADP1653 flash controller. It is used for
example in Nokia N900.
config VIDEO_LM3560
tristate "LM3560 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3560 dual flash controllers. It controls
@@ -1073,13 +1153,18 @@ config VIDEO_LM3560
config VIDEO_LM3646
tristate "LM3646 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
-endif
+endif # MEDIA_CAMERA_SUPPORT
+
+#
+# Other V4L2 drivers that aren't related with Camera support
+#
comment "Video improvement chips"
@@ -1168,8 +1253,9 @@ config VIDEO_I2C
config VIDEO_ST_MIPID02
tristate "STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge.
@@ -1181,4 +1267,4 @@ config VIDEO_ST_MIPID02
endmenu
-endif
+endif # VIDEO_V4L2
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
index 1c6909874d56..afcc4ea764f6 100644
--- a/drivers/media/i2c/et8ek8/Kconfig
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ET8EK8
tristate "ET8EK8 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index e573482f269f..6f0ef33b7ee1 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,7 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports Fujitsu M-5MOLS camera sensor with ISP
diff --git a/drivers/media/i2c/smiapp/Kconfig b/drivers/media/i2c/smiapp/Kconfig
index fcaa7f9494a8..6893b532824f 100644
--- a/drivers/media/i2c/smiapp/Kconfig
+++ b/drivers/media/i2c/smiapp/Kconfig
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SMIAPP
tristate "SMIA++/SMIA sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAVE_CLK
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2 && HAVE_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_SMIAPP_PLL
select V4L2_FWNODE
help
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index e0e7df460a92..d8d9ea6b09bc 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_COBALT
tristate "Cisco Cobalt support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on (GPIOLIB && DRM_I2C_ADV7511=n) || COMPILE_TEST
depends on SND
depends on MTD
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select I2C_ALGOBIT
select SND_PCM
select VIDEO_ADV7604
diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig
index f35bba16b60e..82d7f17e6a02 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -2,9 +2,9 @@
config VIDEO_IPU3_CIO2
tristate "Intel ipu3-cio2 driver"
depends on VIDEO_V4L2 && PCI
- depends on VIDEO_V4L2_SUBDEV_API
depends on (X86 && ACPI) || COMPILE_TEST
- depends on MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
index 011b766f0bff..4dd98f94a91e 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,12 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
+ depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS && I2C
depends on STA2X11 || COMPILE_TEST
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
- depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
- depends on VIDEO_V4L2_SUBDEV_API
- depends on I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Say Y for support for STA2X11 VIP (Video Input Port) capture
device.
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 80028337bf00..c11386bfc24b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -63,7 +63,9 @@ config VIDEO_VIU
config VIDEO_MUX
tristate "Video Multiplexer"
select MULTIPLEXER
- depends on VIDEO_V4L2 && OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP
select V4L2_FWNODE
help
@@ -71,10 +73,12 @@ config VIDEO_MUX
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
depends on COMMON_CLK && OF
select ARM_DMA_USE_IOMMU if OMAP_IOMMU
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
select V4L2_FWNODE
@@ -99,16 +103,19 @@ config VIDEO_PXA27x
config VIDEO_QCOM_CAMSS
tristate "Qualcomm V4L2 Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_SG
select V4L2_FWNODE
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 VIDEO_V4L2 && I2C && PM
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
help
This is a v4l2 driver for s3c24xx and s3c64xx SoC series camera
@@ -119,9 +126,10 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This module makes the STM32 Digital Camera Memory Interface (DCMI)
@@ -148,7 +156,9 @@ source "drivers/media/platform/sunxi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on SOC_DRA7XX || ARCH_K3 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
@@ -432,9 +442,11 @@ config VIDEO_RENESAS_FCP
config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
help
diff --git a/drivers/media/platform/am437x/Kconfig b/drivers/media/platform/am437x/Kconfig
index d6f2e3d0cbef..9ef898f512de 100644
--- a/drivers/media/platform/am437x/Kconfig
+++ b/drivers/media/platform/am437x/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_AM437X_VPFE
tristate "TI AM437x VPFE video capture driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on SOC_AM43XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 5ae3f60b81b1..1850fe7f9360 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ATMEL_ISC
tristate "ATMEL Image Sensor Controller (ISC) support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && COMMON_CLK
depends on ARCH_AT91 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/cadence/Kconfig b/drivers/media/platform/cadence/Kconfig
index c154e368d701..80cf601323ce 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -13,8 +13,8 @@ if VIDEO_CADENCE
config VIDEO_CADENCE_CSI2RX
tristate "Cadence MIPI-CSI2 RX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Receiver controller.
@@ -25,8 +25,8 @@ config VIDEO_CADENCE_CSI2RX
config VIDEO_CADENCE_CSI2TX
tristate "Cadence MIPI-CSI2 TX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Transceiver controller.
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index be4effcbfe7b..136d3b2a0fbb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,9 +2,10 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
tristate "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && OF && COMMON_CLK
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
- depends on OF && COMMON_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Say Y here to enable camera host interface devices for
diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig
index 240ac3f3c941..ca0d906dce2f 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_RCAR_CSI2
tristate "R-Car MIPI CSI-2 Receiver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ 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
@@ -14,8 +16,10 @@ config VIDEO_RCAR_CSI2
config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_RENESAS || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
index e86e29b6a603..5054e7b0d1ac 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
@@ -1,7 +1,9 @@
config VIDEO_SUN4I_CSI
tristate "Allwinner A10 CMOS Sensor Interface Support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
index 269b3ebf4f52..586e3fb3a80d 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SUN6I_CSI
tristate "Allwinner V3s Camera Sensor Interface driver"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
index a2773ad7c185..01c96fb66414 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -2,7 +2,9 @@
config VIDEO_XILINX
tristate "Xilinx Video IP (EXPERIMENTAL)"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
+ depends on VIDEO_V4L2 && OF && HAS_DMA
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
index bcc49cb47de6..bf385d503cab 100644
--- a/drivers/media/spi/Kconfig
+++ b/drivers/media/spi/Kconfig
@@ -9,7 +9,9 @@ menu "SPI helper chips"
config VIDEO_GS1662
tristate "Gennum Serializers video"
- depends on SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Enable the GS1662 driver which serializes video streams.
diff --git a/drivers/media/test_drivers/vimc/Kconfig b/drivers/media/test_drivers/vimc/Kconfig
index bd221d3e1a4a..4068a67585f9 100644
--- a/drivers/media/test_drivers/vimc/Kconfig
+++ b/drivers/media/test_drivers/vimc/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_VIMC
tristate "Virtual Media Controller Driver (VIMC)"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_VMALLOC
select VIDEO_V4L2_TPG
help
diff --git a/drivers/staging/media/hantro/Kconfig b/drivers/staging/media/hantro/Kconfig
index de77fe6554e7..59741c35c9b8 100644
--- a/drivers/staging/media/hantro/Kconfig
+++ b/drivers/staging/media/hantro/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_HANTRO
tristate "Hantro VPU driver"
depends on ARCH_ROCKCHIP || COMPILE_TEST
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on MEDIA_CONTROLLER_REQUEST_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
index 8f1ae50a4abd..f555aac8a9d5 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
depends on ARCH_MXC || COMPILE_TEST
- depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && IMX_IPUV3_CORE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig
index 4b51c67eac88..3e9640523e50 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IPU3_IMGU
tristate "Intel ipu3-imgu driver"
depends on PCI && VIDEO_V4L2
- depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select IOMMU_IOVA
select VIDEOBUF2_DMA_SG
help
diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig
index 4dcbc5065821..6c254907a27b 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_OMAP4
tristate "OMAP 4 Camera support"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
+ depends on VIDEO_V4L2 && I2C
depends on ARCH_OMAP4 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select MFD_SYSCON
select VIDEOBUF2_DMA_CONTIG
help
diff --git a/drivers/staging/media/rkisp1/Kconfig b/drivers/staging/media/rkisp1/Kconfig
index b859a493caba..5ecbefa0f5ec 100644
--- a/drivers/staging/media/rkisp1/Kconfig
+++ b/drivers/staging/media/rkisp1/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_ROCKCHIP_ISP1
tristate "Rockchip Image Signal Processing v1 Unit driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_FWNODE
diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig b/drivers/staging/media/sunxi/cedrus/Kconfig
index 17733e9a088f..da369950bbf2 100644
--- a/drivers/staging/media/sunxi/cedrus/Kconfig
+++ b/drivers/staging/media/sunxi/cedrus/Kconfig
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_SUNXI_CEDRUS
tristate "Allwinner Cedrus VPU driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on VIDEO_DEV && VIDEO_V4L2
depends on HAS_DMA
depends on OF
- depends on MEDIA_CONTROLLER_REQUEST_API
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select SUNXI_SRAM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, Fabio Estevam, devel,
linux-renesas-soc, linux-samsung-soc, Mauro Carvalho Chehab,
Chen-Yu Tsai, Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Philipp Zabel, Sascha Hauer, Maxime Ripard,
Hans Verkuil, Helen Koike, Yong Deng, Ezequiel Garcia,
Pengutronix Kernel Team, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Paul Kocialkowski, Kyungmin Park, Sakari Ailus,
Greg Kroah-Hartman, Niklas Söderlund, Shawn Guo
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>
---
drivers/media/i2c/Kconfig | 210 ++++++++++++------
drivers/media/i2c/et8ek8/Kconfig | 4 +-
drivers/media/i2c/m5mols/Kconfig | 5 +-
drivers/media/i2c/smiapp/Kconfig | 5 +-
drivers/media/pci/cobalt/Kconfig | 4 +-
drivers/media/pci/intel/ipu3/Kconfig | 4 +-
drivers/media/pci/sta2x11/Kconfig | 6 +-
drivers/media/platform/Kconfig | 28 ++-
drivers/media/platform/am437x/Kconfig | 4 +-
drivers/media/platform/atmel/Kconfig | 4 +-
drivers/media/platform/cadence/Kconfig | 8 +-
drivers/media/platform/exynos4-is/Kconfig | 5 +-
drivers/media/platform/rcar-vin/Kconfig | 8 +-
.../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
.../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
drivers/media/platform/xilinx/Kconfig | 4 +-
drivers/media/spi/Kconfig | 4 +-
drivers/media/test_drivers/vimc/Kconfig | 4 +-
drivers/staging/media/hantro/Kconfig | 5 +-
drivers/staging/media/imx/Kconfig | 5 +-
drivers/staging/media/ipu3/Kconfig | 3 +-
drivers/staging/media/omap4iss/Kconfig | 4 +-
drivers/staging/media/rkisp1/Kconfig | 4 +-
drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
24 files changed, 236 insertions(+), 105 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596c13dd..4bc4cfea2f20 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -19,7 +19,7 @@ config VIDEO_IR_I2C
In doubt, say Y.
#
-# Encoder / Decoder module configuration
+# V4L2 I2C drivers that aren't related with Camera support
#
comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
@@ -28,6 +28,10 @@ comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
menu "I2C Encoders, decoders, sensors and other helper chips"
visible if !MEDIA_HIDE_ANCILLARY_SUBDRV
+#
+# Encoder / Decoder module configuration
+#
+
comment "Audio decoders, processors and mixers"
config VIDEO_TVAUDIO
@@ -62,11 +66,13 @@ config VIDEO_TDA9840
config VIDEO_TDA1997X
tristate "NXP TDA1997x HDMI receiver"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on SND_SOC
select HDMI
select SND_PCM
select V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
@@ -204,7 +210,9 @@ comment "Video decoders"
config VIDEO_ADV7180
tristate "Analog Devices ADV7180 decoder"
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Support for the Analog Devices ADV7180 video decoder.
@@ -223,8 +231,10 @@ config VIDEO_ADV7183
config VIDEO_ADV748X
tristate "Analog Devices ADV748x decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -236,8 +246,10 @@ config VIDEO_ADV748X
config VIDEO_ADV7604
tristate "Analog Devices ADV7604 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on GPIOLIB || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select HDMI
select V4L2_FWNODE
@@ -260,7 +272,9 @@ config VIDEO_ADV7604_CEC
config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7842 video decoder.
@@ -347,7 +361,9 @@ config VIDEO_SAA711X
config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
select V4L2_FWNODE
help
@@ -515,8 +531,10 @@ config VIDEO_ADV7393
config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on DRM_I2C_ADV7511=n || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7511 video encoder.
@@ -536,7 +554,10 @@ config VIDEO_ADV7511_CEC
config VIDEO_AD9389B
tristate "Analog Devices AD9389B encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+
help
Support for the Analog Devices AD9389B video encoder.
@@ -568,12 +589,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+#
+# All drivers that are related to Media Camera Support should be here
+#
+
if MEDIA_CAMERA_SUPPORT
config VIDEO_HI556
tristate "Hynix Hi-556 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Hynix
@@ -584,8 +610,10 @@ config VIDEO_HI556
config VIDEO_IMX214
tristate "Sony IMX214 sensor support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && I2C && VIDEO_V4L2
depends on V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a Video4Linux2 sensor driver for the Sony
@@ -596,7 +624,9 @@ config VIDEO_IMX214
config VIDEO_IMX219
tristate "Sony IMX219 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Sony
@@ -607,7 +637,9 @@ config VIDEO_IMX219
config VIDEO_IMX258
tristate "Sony IMX258 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX258 camera.
@@ -617,7 +649,9 @@ config VIDEO_IMX258
config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a V4L2 sensor driver for the Sony IMX274
@@ -625,7 +659,9 @@ config VIDEO_IMX274
config VIDEO_IMX290
tristate "Sony IMX290 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -637,7 +673,9 @@ config VIDEO_IMX290
config VIDEO_IMX319
tristate "Sony IMX319 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX319 camera.
@@ -647,7 +685,9 @@ config VIDEO_IMX319
config VIDEO_IMX355
tristate "Sony IMX355 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX355 camera.
@@ -678,7 +718,8 @@ config VIDEO_OV2659
config VIDEO_OV2680
tristate "OmniVision OV2680 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -689,7 +730,8 @@ config VIDEO_OV2680
config VIDEO_OV2685
tristate "OmniVision OV2685 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -701,7 +743,9 @@ config VIDEO_OV2685
config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Omnivision
@@ -710,7 +754,9 @@ config VIDEO_OV5640
config VIDEO_OV5645
tristate "OmniVision OV5645 sensor support"
depends on OF
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -721,7 +767,9 @@ config VIDEO_OV5645
config VIDEO_OV5647
tristate "OmniVision OV5647 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -742,8 +790,9 @@ config VIDEO_OV6650
config VIDEO_OV5670
tristate "OmniVision OV5670 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -754,8 +803,9 @@ config VIDEO_OV5670
config VIDEO_OV5675
tristate "OmniVision OV5675 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -777,7 +827,9 @@ config VIDEO_OV5695
config VIDEO_OV7251
tristate "OmniVision OV7251 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -826,7 +878,9 @@ config VIDEO_OV7740
config VIDEO_OV8856
tristate "OmniVision OV8856 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -844,7 +898,9 @@ config VIDEO_OV9640
config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_SCCB
help
This is a V4L2 sensor driver for the Omnivision
@@ -852,7 +908,9 @@ config VIDEO_OV9650
config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -870,14 +928,18 @@ config VIDEO_VS6624
config VIDEO_MT9M001
tristate "mt9m001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
config VIDEO_MT9M032
tristate "MT9M032 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This driver supports MT9M032 camera sensors from Aptina, monochrome
@@ -893,7 +955,9 @@ config VIDEO_MT9M111
config VIDEO_MT9P031
tristate "Aptina MT9P031 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This is a Video4Linux2 sensor driver for the Aptina
@@ -901,7 +965,9 @@ config VIDEO_MT9P031
config VIDEO_MT9T001
tristate "Aptina MT9T001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Aptina
(Micron) mt0t001 3 Mpixel camera.
@@ -926,7 +992,9 @@ config VIDEO_MT9V011
config VIDEO_MT9V032
tristate "Micron MT9V032 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -951,7 +1019,9 @@ config VIDEO_SR030PC30
config VIDEO_NOON010PC30
tristate "Siliconfile NOON010PC30 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports NOON010PC30 CIF camera from Siliconfile
@@ -969,21 +1039,27 @@ config VIDEO_RJ54N1
config VIDEO_S5K6AA
tristate "Samsung S5K6AAFX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
config VIDEO_S5K6A3
tristate "Samsung S5K6A3 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6A3 raw
camera sensor.
config VIDEO_S5K4ECGX
tristate "Samsung S5K4ECGX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select CRC32
help
This is a V4L2 sensor driver for Samsung S5K4ECGX 5M
@@ -991,7 +1067,9 @@ config VIDEO_S5K4ECGX
config VIDEO_S5K5BAF
tristate "Samsung S5K5BAF sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5K5BAF 2M
@@ -1002,28 +1080,29 @@ source "drivers/media/i2c/et8ek8/Kconfig"
config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
- depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5C73M3
8 Mpixel camera.
-endif
comment "Lens drivers"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_AD5820
tristate "AD5820 lens voice coil support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on GPIOLIB && I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the AD5820 camera lens voice coil.
It is used for example in Nokia N900 (RX-51).
config VIDEO_AK7375
tristate "AK7375 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the AK7375 camera lens voice coil.
AK7375 is a 12 bit DAC with 120mA output current sink
@@ -1032,8 +1111,9 @@ config VIDEO_AK7375
config VIDEO_DW9714
tristate "DW9714 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9714 camera lens voice coil.
DW9714 is a 10 bit DAC with 120mA output current sink
@@ -1042,30 +1122,30 @@ config VIDEO_DW9714
config VIDEO_DW9807_VCM
tristate "DW9807 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9807 camera lens voice coil.
DW9807 is a 10 bit DAC with 100mA output current sink
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
-endif
comment "Flash devices"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_ADP1653
tristate "ADP1653 flash support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the ADP1653 flash controller. It is used for
example in Nokia N900.
config VIDEO_LM3560
tristate "LM3560 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3560 dual flash controllers. It controls
@@ -1073,13 +1153,18 @@ config VIDEO_LM3560
config VIDEO_LM3646
tristate "LM3646 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
-endif
+endif # MEDIA_CAMERA_SUPPORT
+
+#
+# Other V4L2 drivers that aren't related with Camera support
+#
comment "Video improvement chips"
@@ -1168,8 +1253,9 @@ config VIDEO_I2C
config VIDEO_ST_MIPID02
tristate "STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge.
@@ -1181,4 +1267,4 @@ config VIDEO_ST_MIPID02
endmenu
-endif
+endif # VIDEO_V4L2
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
index 1c6909874d56..afcc4ea764f6 100644
--- a/drivers/media/i2c/et8ek8/Kconfig
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ET8EK8
tristate "ET8EK8 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index e573482f269f..6f0ef33b7ee1 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,7 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports Fujitsu M-5MOLS camera sensor with ISP
diff --git a/drivers/media/i2c/smiapp/Kconfig b/drivers/media/i2c/smiapp/Kconfig
index fcaa7f9494a8..6893b532824f 100644
--- a/drivers/media/i2c/smiapp/Kconfig
+++ b/drivers/media/i2c/smiapp/Kconfig
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SMIAPP
tristate "SMIA++/SMIA sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAVE_CLK
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2 && HAVE_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_SMIAPP_PLL
select V4L2_FWNODE
help
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index e0e7df460a92..d8d9ea6b09bc 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_COBALT
tristate "Cisco Cobalt support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on (GPIOLIB && DRM_I2C_ADV7511=n) || COMPILE_TEST
depends on SND
depends on MTD
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select I2C_ALGOBIT
select SND_PCM
select VIDEO_ADV7604
diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig
index f35bba16b60e..82d7f17e6a02 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -2,9 +2,9 @@
config VIDEO_IPU3_CIO2
tristate "Intel ipu3-cio2 driver"
depends on VIDEO_V4L2 && PCI
- depends on VIDEO_V4L2_SUBDEV_API
depends on (X86 && ACPI) || COMPILE_TEST
- depends on MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
index 011b766f0bff..4dd98f94a91e 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,12 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
+ depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS && I2C
depends on STA2X11 || COMPILE_TEST
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
- depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
- depends on VIDEO_V4L2_SUBDEV_API
- depends on I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Say Y for support for STA2X11 VIP (Video Input Port) capture
device.
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 80028337bf00..c11386bfc24b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -63,7 +63,9 @@ config VIDEO_VIU
config VIDEO_MUX
tristate "Video Multiplexer"
select MULTIPLEXER
- depends on VIDEO_V4L2 && OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP
select V4L2_FWNODE
help
@@ -71,10 +73,12 @@ config VIDEO_MUX
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
depends on COMMON_CLK && OF
select ARM_DMA_USE_IOMMU if OMAP_IOMMU
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
select V4L2_FWNODE
@@ -99,16 +103,19 @@ config VIDEO_PXA27x
config VIDEO_QCOM_CAMSS
tristate "Qualcomm V4L2 Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_SG
select V4L2_FWNODE
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 VIDEO_V4L2 && I2C && PM
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
help
This is a v4l2 driver for s3c24xx and s3c64xx SoC series camera
@@ -119,9 +126,10 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This module makes the STM32 Digital Camera Memory Interface (DCMI)
@@ -148,7 +156,9 @@ source "drivers/media/platform/sunxi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on SOC_DRA7XX || ARCH_K3 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
@@ -432,9 +442,11 @@ config VIDEO_RENESAS_FCP
config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
help
diff --git a/drivers/media/platform/am437x/Kconfig b/drivers/media/platform/am437x/Kconfig
index d6f2e3d0cbef..9ef898f512de 100644
--- a/drivers/media/platform/am437x/Kconfig
+++ b/drivers/media/platform/am437x/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_AM437X_VPFE
tristate "TI AM437x VPFE video capture driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on SOC_AM43XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 5ae3f60b81b1..1850fe7f9360 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ATMEL_ISC
tristate "ATMEL Image Sensor Controller (ISC) support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && COMMON_CLK
depends on ARCH_AT91 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/cadence/Kconfig b/drivers/media/platform/cadence/Kconfig
index c154e368d701..80cf601323ce 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -13,8 +13,8 @@ if VIDEO_CADENCE
config VIDEO_CADENCE_CSI2RX
tristate "Cadence MIPI-CSI2 RX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Receiver controller.
@@ -25,8 +25,8 @@ config VIDEO_CADENCE_CSI2RX
config VIDEO_CADENCE_CSI2TX
tristate "Cadence MIPI-CSI2 TX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Transceiver controller.
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index be4effcbfe7b..136d3b2a0fbb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,9 +2,10 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
tristate "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && OF && COMMON_CLK
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
- depends on OF && COMMON_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Say Y here to enable camera host interface devices for
diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig
index 240ac3f3c941..ca0d906dce2f 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_RCAR_CSI2
tristate "R-Car MIPI CSI-2 Receiver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ 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
@@ -14,8 +16,10 @@ config VIDEO_RCAR_CSI2
config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_RENESAS || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
index e86e29b6a603..5054e7b0d1ac 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
@@ -1,7 +1,9 @@
config VIDEO_SUN4I_CSI
tristate "Allwinner A10 CMOS Sensor Interface Support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
index 269b3ebf4f52..586e3fb3a80d 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SUN6I_CSI
tristate "Allwinner V3s Camera Sensor Interface driver"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
index a2773ad7c185..01c96fb66414 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -2,7 +2,9 @@
config VIDEO_XILINX
tristate "Xilinx Video IP (EXPERIMENTAL)"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
+ depends on VIDEO_V4L2 && OF && HAS_DMA
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
index bcc49cb47de6..bf385d503cab 100644
--- a/drivers/media/spi/Kconfig
+++ b/drivers/media/spi/Kconfig
@@ -9,7 +9,9 @@ menu "SPI helper chips"
config VIDEO_GS1662
tristate "Gennum Serializers video"
- depends on SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Enable the GS1662 driver which serializes video streams.
diff --git a/drivers/media/test_drivers/vimc/Kconfig b/drivers/media/test_drivers/vimc/Kconfig
index bd221d3e1a4a..4068a67585f9 100644
--- a/drivers/media/test_drivers/vimc/Kconfig
+++ b/drivers/media/test_drivers/vimc/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_VIMC
tristate "Virtual Media Controller Driver (VIMC)"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_VMALLOC
select VIDEO_V4L2_TPG
help
diff --git a/drivers/staging/media/hantro/Kconfig b/drivers/staging/media/hantro/Kconfig
index de77fe6554e7..59741c35c9b8 100644
--- a/drivers/staging/media/hantro/Kconfig
+++ b/drivers/staging/media/hantro/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_HANTRO
tristate "Hantro VPU driver"
depends on ARCH_ROCKCHIP || COMPILE_TEST
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on MEDIA_CONTROLLER_REQUEST_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
index 8f1ae50a4abd..f555aac8a9d5 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
depends on ARCH_MXC || COMPILE_TEST
- depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && IMX_IPUV3_CORE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig
index 4b51c67eac88..3e9640523e50 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IPU3_IMGU
tristate "Intel ipu3-imgu driver"
depends on PCI && VIDEO_V4L2
- depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select IOMMU_IOVA
select VIDEOBUF2_DMA_SG
help
diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig
index 4dcbc5065821..6c254907a27b 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_OMAP4
tristate "OMAP 4 Camera support"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
+ depends on VIDEO_V4L2 && I2C
depends on ARCH_OMAP4 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select MFD_SYSCON
select VIDEOBUF2_DMA_CONTIG
help
diff --git a/drivers/staging/media/rkisp1/Kconfig b/drivers/staging/media/rkisp1/Kconfig
index b859a493caba..5ecbefa0f5ec 100644
--- a/drivers/staging/media/rkisp1/Kconfig
+++ b/drivers/staging/media/rkisp1/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_ROCKCHIP_ISP1
tristate "Rockchip Image Signal Processing v1 Unit driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_FWNODE
diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig b/drivers/staging/media/sunxi/cedrus/Kconfig
index 17733e9a088f..da369950bbf2 100644
--- a/drivers/staging/media/sunxi/cedrus/Kconfig
+++ b/drivers/staging/media/sunxi/cedrus/Kconfig
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_SUNXI_CEDRUS
tristate "Allwinner Cedrus VPU driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on VIDEO_DEV && VIDEO_V4L2
depends on HAS_DMA
depends on OF
- depends on MEDIA_CONTROLLER_REQUEST_API
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select SUNXI_SRAM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, devel,
linux-renesas-soc, linux-samsung-soc, Mauro Carvalho Chehab,
Chen-Yu Tsai, Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Philipp Zabel, Sascha Hauer, Maxime Ripard,
Hans Verkuil, Helen Koike, Yong Deng, Ezequiel Garcia,
Pengutronix Kernel Team, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Sakari Ailus, Greg Kroah-Hartman, Niklas Söderlund,
Shawn Guo
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>
---
drivers/media/i2c/Kconfig | 210 ++++++++++++------
drivers/media/i2c/et8ek8/Kconfig | 4 +-
drivers/media/i2c/m5mols/Kconfig | 5 +-
drivers/media/i2c/smiapp/Kconfig | 5 +-
drivers/media/pci/cobalt/Kconfig | 4 +-
drivers/media/pci/intel/ipu3/Kconfig | 4 +-
drivers/media/pci/sta2x11/Kconfig | 6 +-
drivers/media/platform/Kconfig | 28 ++-
drivers/media/platform/am437x/Kconfig | 4 +-
drivers/media/platform/atmel/Kconfig | 4 +-
drivers/media/platform/cadence/Kconfig | 8 +-
drivers/media/platform/exynos4-is/Kconfig | 5 +-
drivers/media/platform/rcar-vin/Kconfig | 8 +-
.../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
.../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
drivers/media/platform/xilinx/Kconfig | 4 +-
drivers/media/spi/Kconfig | 4 +-
drivers/media/test_drivers/vimc/Kconfig | 4 +-
drivers/staging/media/hantro/Kconfig | 5 +-
drivers/staging/media/imx/Kconfig | 5 +-
drivers/staging/media/ipu3/Kconfig | 3 +-
drivers/staging/media/omap4iss/Kconfig | 4 +-
drivers/staging/media/rkisp1/Kconfig | 4 +-
drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
24 files changed, 236 insertions(+), 105 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596c13dd..4bc4cfea2f20 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -19,7 +19,7 @@ config VIDEO_IR_I2C
In doubt, say Y.
#
-# Encoder / Decoder module configuration
+# V4L2 I2C drivers that aren't related with Camera support
#
comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
@@ -28,6 +28,10 @@ comment "I2C drivers hidden by 'Autoselect ancillary drivers'"
menu "I2C Encoders, decoders, sensors and other helper chips"
visible if !MEDIA_HIDE_ANCILLARY_SUBDRV
+#
+# Encoder / Decoder module configuration
+#
+
comment "Audio decoders, processors and mixers"
config VIDEO_TVAUDIO
@@ -62,11 +66,13 @@ config VIDEO_TDA9840
config VIDEO_TDA1997X
tristate "NXP TDA1997x HDMI receiver"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on SND_SOC
select HDMI
select SND_PCM
select V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
@@ -204,7 +210,9 @@ comment "Video decoders"
config VIDEO_ADV7180
tristate "Analog Devices ADV7180 decoder"
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Support for the Analog Devices ADV7180 video decoder.
@@ -223,8 +231,10 @@ config VIDEO_ADV7183
config VIDEO_ADV748X
tristate "Analog Devices ADV748x decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -236,8 +246,10 @@ config VIDEO_ADV748X
config VIDEO_ADV7604
tristate "Analog Devices ADV7604 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on GPIOLIB || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select HDMI
select V4L2_FWNODE
@@ -260,7 +272,9 @@ config VIDEO_ADV7604_CEC
config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7842 video decoder.
@@ -347,7 +361,9 @@ config VIDEO_SAA711X
config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
select V4L2_FWNODE
help
@@ -515,8 +531,10 @@ config VIDEO_ADV7393
config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on DRM_I2C_ADV7511=n || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select HDMI
help
Support for the Analog Devices ADV7511 video encoder.
@@ -536,7 +554,10 @@ config VIDEO_ADV7511_CEC
config VIDEO_AD9389B
tristate "Analog Devices AD9389B encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+
help
Support for the Analog Devices AD9389B video encoder.
@@ -568,12 +589,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+#
+# All drivers that are related to Media Camera Support should be here
+#
+
if MEDIA_CAMERA_SUPPORT
config VIDEO_HI556
tristate "Hynix Hi-556 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Hynix
@@ -584,8 +610,10 @@ config VIDEO_HI556
config VIDEO_IMX214
tristate "Sony IMX214 sensor support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && I2C && VIDEO_V4L2
depends on V4L2_FWNODE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a Video4Linux2 sensor driver for the Sony
@@ -596,7 +624,9 @@ config VIDEO_IMX214
config VIDEO_IMX219
tristate "Sony IMX219 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Sony
@@ -607,7 +637,9 @@ config VIDEO_IMX219
config VIDEO_IMX258
tristate "Sony IMX258 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX258 camera.
@@ -617,7 +649,9 @@ config VIDEO_IMX258
config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
help
This is a V4L2 sensor driver for the Sony IMX274
@@ -625,7 +659,9 @@ config VIDEO_IMX274
config VIDEO_IMX290
tristate "Sony IMX290 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -637,7 +673,9 @@ config VIDEO_IMX290
config VIDEO_IMX319
tristate "Sony IMX319 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX319 camera.
@@ -647,7 +685,9 @@ config VIDEO_IMX319
config VIDEO_IMX355
tristate "Sony IMX355 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Sony
IMX355 camera.
@@ -678,7 +718,8 @@ config VIDEO_OV2659
config VIDEO_OV2680
tristate "OmniVision OV2680 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -689,7 +730,8 @@ config VIDEO_OV2680
config VIDEO_OV2685
tristate "OmniVision OV2685 sensor support"
- depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -701,7 +743,9 @@ config VIDEO_OV2685
config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
- depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Omnivision
@@ -710,7 +754,9 @@ config VIDEO_OV5640
config VIDEO_OV5645
tristate "OmniVision OV5645 sensor support"
depends on OF
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -721,7 +767,9 @@ config VIDEO_OV5645
config VIDEO_OV5647
tristate "OmniVision OV5647 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -742,8 +790,9 @@ config VIDEO_OV6650
config VIDEO_OV5670
tristate "OmniVision OV5670 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -754,8 +803,9 @@ config VIDEO_OV5670
config VIDEO_OV5675
tristate "OmniVision OV5675 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -777,7 +827,9 @@ config VIDEO_OV5695
config VIDEO_OV7251
tristate "OmniVision OV7251 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -826,7 +878,9 @@ config VIDEO_OV7740
config VIDEO_OV8856
tristate "OmniVision OV8856 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -844,7 +898,9 @@ config VIDEO_OV9640
config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_SCCB
help
This is a V4L2 sensor driver for the Omnivision
@@ -852,7 +908,9 @@ config VIDEO_OV9650
config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
@@ -870,14 +928,18 @@ config VIDEO_VS6624
config VIDEO_MT9M001
tristate "mt9m001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
config VIDEO_MT9M032
tristate "MT9M032 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This driver supports MT9M032 camera sensors from Aptina, monochrome
@@ -893,7 +955,9 @@ config VIDEO_MT9M111
config VIDEO_MT9P031
tristate "Aptina MT9P031 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_APTINA_PLL
help
This is a Video4Linux2 sensor driver for the Aptina
@@ -901,7 +965,9 @@ config VIDEO_MT9P031
config VIDEO_MT9T001
tristate "Aptina MT9T001 support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Aptina
(Micron) mt0t001 3 Mpixel camera.
@@ -926,7 +992,9 @@ config VIDEO_MT9V011
config VIDEO_MT9V032
tristate "Micron MT9V032 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
@@ -951,7 +1019,9 @@ config VIDEO_SR030PC30
config VIDEO_NOON010PC30
tristate "Siliconfile NOON010PC30 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports NOON010PC30 CIF camera from Siliconfile
@@ -969,21 +1039,27 @@ config VIDEO_RJ54N1
config VIDEO_S5K6AA
tristate "Samsung S5K6AAFX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
config VIDEO_S5K6A3
tristate "Samsung S5K6A3 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a V4L2 sensor driver for Samsung S5K6A3 raw
camera sensor.
config VIDEO_S5K4ECGX
tristate "Samsung S5K4ECGX sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select CRC32
help
This is a V4L2 sensor driver for Samsung S5K4ECGX 5M
@@ -991,7 +1067,9 @@ config VIDEO_S5K4ECGX
config VIDEO_S5K5BAF
tristate "Samsung S5K5BAF sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5K5BAF 2M
@@ -1002,28 +1080,29 @@ source "drivers/media/i2c/et8ek8/Kconfig"
config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
- depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a V4L2 sensor driver for Samsung S5C73M3
8 Mpixel camera.
-endif
comment "Lens drivers"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_AD5820
tristate "AD5820 lens voice coil support"
- depends on GPIOLIB && I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on GPIOLIB && I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the AD5820 camera lens voice coil.
It is used for example in Nokia N900 (RX-51).
config VIDEO_AK7375
tristate "AK7375 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the AK7375 camera lens voice coil.
AK7375 is a 12 bit DAC with 120mA output current sink
@@ -1032,8 +1111,9 @@ config VIDEO_AK7375
config VIDEO_DW9714
tristate "DW9714 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9714 camera lens voice coil.
DW9714 is a 10 bit DAC with 120mA output current sink
@@ -1042,30 +1122,30 @@ config VIDEO_DW9714
config VIDEO_DW9807_VCM
tristate "DW9807 lens voice coil support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This is a driver for the DW9807 camera lens voice coil.
DW9807 is a 10 bit DAC with 100mA output current sink
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
-endif
comment "Flash devices"
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_ADP1653
tristate "ADP1653 flash support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
help
This is a driver for the ADP1653 flash controller. It is used for
example in Nokia N900.
config VIDEO_LM3560
tristate "LM3560 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3560 dual flash controllers. It controls
@@ -1073,13 +1153,18 @@ config VIDEO_LM3560
config VIDEO_LM3646
tristate "LM3646 dual flash driver support"
- depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
select REGMAP_I2C
help
This is a driver for the lm3646 dual flash controllers. It controls
flash, torch LEDs.
-endif
+endif # MEDIA_CAMERA_SUPPORT
+
+#
+# Other V4L2 drivers that aren't related with Camera support
+#
comment "Video improvement chips"
@@ -1168,8 +1253,9 @@ config VIDEO_I2C
config VIDEO_ST_MIPID02
tristate "STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge.
@@ -1181,4 +1267,4 @@ config VIDEO_ST_MIPID02
endmenu
-endif
+endif # VIDEO_V4L2
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
index 1c6909874d56..afcc4ea764f6 100644
--- a/drivers/media/i2c/et8ek8/Kconfig
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ET8EK8
tristate "ET8EK8 camera sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index e573482f269f..6f0ef33b7ee1 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,7 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
This driver supports Fujitsu M-5MOLS camera sensor with ISP
diff --git a/drivers/media/i2c/smiapp/Kconfig b/drivers/media/i2c/smiapp/Kconfig
index fcaa7f9494a8..6893b532824f 100644
--- a/drivers/media/i2c/smiapp/Kconfig
+++ b/drivers/media/i2c/smiapp/Kconfig
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SMIAPP
tristate "SMIA++/SMIA sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAVE_CLK
- depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2 && HAVE_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEO_SMIAPP_PLL
select V4L2_FWNODE
help
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index e0e7df460a92..d8d9ea6b09bc 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_COBALT
tristate "Cisco Cobalt support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on (GPIOLIB && DRM_I2C_ADV7511=n) || COMPILE_TEST
depends on SND
depends on MTD
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select I2C_ALGOBIT
select SND_PCM
select VIDEO_ADV7604
diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig
index f35bba16b60e..82d7f17e6a02 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -2,9 +2,9 @@
config VIDEO_IPU3_CIO2
tristate "Intel ipu3-cio2 driver"
depends on VIDEO_V4L2 && PCI
- depends on VIDEO_V4L2_SUBDEV_API
depends on (X86 && ACPI) || COMPILE_TEST
- depends on MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig
index 011b766f0bff..4dd98f94a91e 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,12 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
+ depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS && I2C
depends on STA2X11 || COMPILE_TEST
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
- depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
- depends on VIDEO_V4L2_SUBDEV_API
- depends on I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Say Y for support for STA2X11 VIP (Video Input Port) capture
device.
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 80028337bf00..c11386bfc24b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -63,7 +63,9 @@ config VIDEO_VIU
config VIDEO_MUX
tristate "Video Multiplexer"
select MULTIPLEXER
- depends on VIDEO_V4L2 && OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select REGMAP
select V4L2_FWNODE
help
@@ -71,10 +73,12 @@ config VIDEO_MUX
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C
depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
depends on COMMON_CLK && OF
select ARM_DMA_USE_IOMMU if OMAP_IOMMU
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
select V4L2_FWNODE
@@ -99,16 +103,19 @@ config VIDEO_PXA27x
config VIDEO_QCOM_CAMSS
tristate "Qualcomm V4L2 Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_SG
select V4L2_FWNODE
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 VIDEO_V4L2 && I2C && PM
depends on ARCH_S3C64XX || PLAT_S3C24XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
help
This is a v4l2 driver for s3c24xx and s3c64xx SoC series camera
@@ -119,9 +126,10 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This module makes the STM32 Digital Camera Memory Interface (DCMI)
@@ -148,7 +156,9 @@ source "drivers/media/platform/sunxi/Kconfig"
config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on SOC_DRA7XX || ARCH_K3 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
@@ -432,9 +442,11 @@ config VIDEO_RENESAS_FCP
config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_RENESAS || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
help
diff --git a/drivers/media/platform/am437x/Kconfig b/drivers/media/platform/am437x/Kconfig
index d6f2e3d0cbef..9ef898f512de 100644
--- a/drivers/media/platform/am437x/Kconfig
+++ b/drivers/media/platform/am437x/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_AM437X_VPFE
tristate "TI AM437x VPFE video capture driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on SOC_AM43XX || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 5ae3f60b81b1..1850fe7f9360 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_ATMEL_ISC
tristate "ATMEL Image Sensor Controller (ISC) support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && COMMON_CLK
depends on ARCH_AT91 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/cadence/Kconfig b/drivers/media/platform/cadence/Kconfig
index c154e368d701..80cf601323ce 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -13,8 +13,8 @@ if VIDEO_CADENCE
config VIDEO_CADENCE_CSI2RX
tristate "Cadence MIPI-CSI2 RX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Receiver controller.
@@ -25,8 +25,8 @@ config VIDEO_CADENCE_CSI2RX
config VIDEO_CADENCE_CSI2TX
tristate "Cadence MIPI-CSI2 TX Controller"
depends on VIDEO_V4L2
- depends on MEDIA_CONTROLLER
- depends on VIDEO_V4L2_SUBDEV_API
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Support for the Cadence MIPI CSI2 Transceiver controller.
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index be4effcbfe7b..136d3b2a0fbb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -2,9 +2,10 @@
config VIDEO_SAMSUNG_EXYNOS4_IS
tristate "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && OF && COMMON_CLK
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
- depends on OF && COMMON_CLK
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
Say Y here to enable camera host interface devices for
diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig
index 240ac3f3c941..ca0d906dce2f 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_RCAR_CSI2
tristate "R-Car MIPI CSI-2 Receiver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ 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
@@ -14,8 +16,10 @@ config VIDEO_RCAR_CSI2
config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2 && OF
depends on ARCH_RENESAS || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
index e86e29b6a603..5054e7b0d1ac 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig
@@ -1,7 +1,9 @@
config VIDEO_SUN4I_CSI
tristate "Allwinner A10 CMOS Sensor Interface Support"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
index 269b3ebf4f52..586e3fb3a80d 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/Kconfig
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -1,8 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_SUN6I_CSI
tristate "Allwinner V3s Camera Sensor Interface driver"
- depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+ depends on VIDEO_V4L2 && COMMON_CLK && HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
select V4L2_FWNODE
diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
index a2773ad7c185..01c96fb66414 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -2,7 +2,9 @@
config VIDEO_XILINX
tristate "Xilinx Video IP (EXPERIMENTAL)"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
+ depends on VIDEO_V4L2 && OF && HAS_DMA
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
help
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
index bcc49cb47de6..bf385d503cab 100644
--- a/drivers/media/spi/Kconfig
+++ b/drivers/media/spi/Kconfig
@@ -9,7 +9,9 @@ menu "SPI helper chips"
config VIDEO_GS1662
tristate "Gennum Serializers video"
- depends on SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on SPI && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
help
Enable the GS1662 driver which serializes video streams.
diff --git a/drivers/media/test_drivers/vimc/Kconfig b/drivers/media/test_drivers/vimc/Kconfig
index bd221d3e1a4a..4068a67585f9 100644
--- a/drivers/media/test_drivers/vimc/Kconfig
+++ b/drivers/media/test_drivers/vimc/Kconfig
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config VIDEO_VIMC
tristate "Virtual Media Controller Driver (VIMC)"
- depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_VMALLOC
select VIDEO_V4L2_TPG
help
diff --git a/drivers/staging/media/hantro/Kconfig b/drivers/staging/media/hantro/Kconfig
index de77fe6554e7..59741c35c9b8 100644
--- a/drivers/staging/media/hantro/Kconfig
+++ b/drivers/staging/media/hantro/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_HANTRO
tristate "Hantro VPU driver"
depends on ARCH_ROCKCHIP || COMPILE_TEST
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
- depends on MEDIA_CONTROLLER_REQUEST_API
+ depends on VIDEO_DEV && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
index 8f1ae50a4abd..f555aac8a9d5 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
depends on ARCH_MXC || COMPILE_TEST
- depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
- depends on VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && IMX_IPUV3_CORE
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig
index 4b51c67eac88..3e9640523e50 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -2,8 +2,9 @@
config VIDEO_IPU3_IMGU
tristate "Intel ipu3-imgu driver"
depends on PCI && VIDEO_V4L2
- depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select IOMMU_IOVA
select VIDEOBUF2_DMA_SG
help
diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig
index 4dcbc5065821..6c254907a27b 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_OMAP4
tristate "OMAP 4 Camera support"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
+ depends on VIDEO_V4L2 && I2C
depends on ARCH_OMAP4 || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select MFD_SYSCON
select VIDEOBUF2_DMA_CONTIG
help
diff --git a/drivers/staging/media/rkisp1/Kconfig b/drivers/staging/media/rkisp1/Kconfig
index b859a493caba..5ecbefa0f5ec 100644
--- a/drivers/staging/media/rkisp1/Kconfig
+++ b/drivers/staging/media/rkisp1/Kconfig
@@ -2,8 +2,10 @@
config VIDEO_ROCKCHIP_ISP1
tristate "Rockchip Image Signal Processing v1 Unit driver"
- depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2
depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_FWNODE
diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig b/drivers/staging/media/sunxi/cedrus/Kconfig
index 17733e9a088f..da369950bbf2 100644
--- a/drivers/staging/media/sunxi/cedrus/Kconfig
+++ b/drivers/staging/media/sunxi/cedrus/Kconfig
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
config VIDEO_SUNXI_CEDRUS
tristate "Allwinner Cedrus VPU driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on VIDEO_DEV && VIDEO_V4L2
depends on HAS_DMA
depends on OF
- depends on MEDIA_CONTROLLER_REQUEST_API
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
select SUNXI_SRAM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
2.25.1
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 3/4] media: i2c/Kconfig: reorganize items there
2020-03-25 16:03 ` Mauro Carvalho Chehab
` (3 preceding siblings ...)
(?)
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab
Right now, there are I2C drivers that don't depend on
camera support before and after those.
Move the camera support drivers to the end, and add
a notice at the "endif", in order to make easier to
maintain and to avoid adding extra dependencies at
the other i2c/*/Kconfig files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
drivers/media/i2c/Kconfig | 218 +++++++++++++++++++-------------------
1 file changed, 107 insertions(+), 111 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 4bc4cfea2f20..efd12bf4f8eb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -581,6 +581,113 @@ config VIDEO_THS8200
To compile this driver as a module, choose M here: the
module will be called ths8200.
+comment "Video improvement chips"
+
+config VIDEO_UPD64031A
+ tristate "NEC Electronics uPD64031A Ghost Reduction"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for the NEC Electronics uPD64031A Ghost Reduction
+ video chip. It is most often found in NTSC TV cards made for
+ Japan and is used to reduce the 'ghosting' effect that can
+ be present in analog TV broadcasts.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd64031a.
+
+config VIDEO_UPD64083
+ tristate "NEC Electronics uPD64083 3-Dimensional Y/C separation"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for the NEC Electronics uPD64083 3-Dimensional Y/C
+ separation video chip. It is used to improve the quality of
+ the colors of a composite signal.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd64083.
+
+comment "Audio/Video compression chips"
+
+config VIDEO_SAA6752HS
+ tristate "Philips SAA6752HS MPEG-2 Audio/Video Encoder"
+ depends on VIDEO_V4L2 && I2C
+ select CRC32
+ help
+ Support for the Philips SAA6752HS MPEG-2 video and MPEG-audio/AC-3
+ audio encoder with multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called saa6752hs.
+
+comment "SDR tuner chips"
+
+config SDR_MAX2175
+ tristate "Maxim 2175 RF to Bits tuner"
+ depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
+ select REGMAP_I2C
+ help
+ Support for Maxim 2175 tuner. It is an advanced analog/digital
+ radio receiver with RF-to-Bits front-end designed for SDR solutions.
+
+ To compile this driver as a module, choose M here; the
+ module will be called max2175.
+
+comment "Miscellaneous helper chips"
+
+config VIDEO_THS7303
+ tristate "THS7303/53 Video Amplifier"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for TI THS7303/53 video amplifier
+
+ To compile this driver as a module, choose M here: the
+ module will be called ths7303.
+
+config VIDEO_M52790
+ tristate "Mitsubishi M52790 A/V switch"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for the Mitsubishi M52790 A/V switch.
+
+ To compile this driver as a module, choose M here: the
+ module will be called m52790.
+
+config VIDEO_I2C
+ tristate "I2C transport video support"
+ depends on VIDEO_V4L2 && I2C
+ select VIDEOBUF2_VMALLOC
+ imply HWMON
+ help
+ Enable the I2C transport video support which supports the
+ following:
+ * Panasonic AMG88xx Grid-Eye Sensors
+ * Melexis MLX90640 Thermal Cameras
+
+ To compile this driver as a module, choose M here: the
+ module will be called video-i2c
+
+config VIDEO_ST_MIPID02
+ tristate "STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge"
+ depends on I2C && VIDEO_V4L2
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ help
+ Support for STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge.
+ It is used to allow usage of CSI-2 sensor with PARALLEL port
+ controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called st-mipid02.
+
+endmenu
+
+#
+# All drivers that are related to Media Camera Support should be here
+#
+
+if MEDIA_CAMERA_SUPPORT
+
comment "Camera sensor devices"
config VIDEO_APTINA_PLL
@@ -589,12 +696,6 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
-#
-# All drivers that are related to Media Camera Support should be here
-#
-
-if MEDIA_CAMERA_SUPPORT
-
config VIDEO_HI556
tristate "Hynix Hi-556 sensor support"
depends on I2C && VIDEO_V4L2
@@ -1162,109 +1263,4 @@ config VIDEO_LM3646
endif # MEDIA_CAMERA_SUPPORT
-#
-# Other V4L2 drivers that aren't related with Camera support
-#
-
-comment "Video improvement chips"
-
-config VIDEO_UPD64031A
- tristate "NEC Electronics uPD64031A Ghost Reduction"
- depends on VIDEO_V4L2 && I2C
- help
- Support for the NEC Electronics uPD64031A Ghost Reduction
- video chip. It is most often found in NTSC TV cards made for
- Japan and is used to reduce the 'ghosting' effect that can
- be present in analog TV broadcasts.
-
- To compile this driver as a module, choose M here: the
- module will be called upd64031a.
-
-config VIDEO_UPD64083
- tristate "NEC Electronics uPD64083 3-Dimensional Y/C separation"
- depends on VIDEO_V4L2 && I2C
- help
- Support for the NEC Electronics uPD64083 3-Dimensional Y/C
- separation video chip. It is used to improve the quality of
- the colors of a composite signal.
-
- To compile this driver as a module, choose M here: the
- module will be called upd64083.
-
-comment "Audio/Video compression chips"
-
-config VIDEO_SAA6752HS
- tristate "Philips SAA6752HS MPEG-2 Audio/Video Encoder"
- depends on VIDEO_V4L2 && I2C
- select CRC32
- help
- Support for the Philips SAA6752HS MPEG-2 video and MPEG-audio/AC-3
- audio encoder with multiplexer.
-
- To compile this driver as a module, choose M here: the
- module will be called saa6752hs.
-
-comment "SDR tuner chips"
-
-config SDR_MAX2175
- tristate "Maxim 2175 RF to Bits tuner"
- depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
- select REGMAP_I2C
- help
- Support for Maxim 2175 tuner. It is an advanced analog/digital
- radio receiver with RF-to-Bits front-end designed for SDR solutions.
-
- To compile this driver as a module, choose M here; the
- module will be called max2175.
-
-comment "Miscellaneous helper chips"
-
-config VIDEO_THS7303
- tristate "THS7303/53 Video Amplifier"
- depends on VIDEO_V4L2 && I2C
- help
- Support for TI THS7303/53 video amplifier
-
- To compile this driver as a module, choose M here: the
- module will be called ths7303.
-
-config VIDEO_M52790
- tristate "Mitsubishi M52790 A/V switch"
- depends on VIDEO_V4L2 && I2C
- help
- Support for the Mitsubishi M52790 A/V switch.
-
- To compile this driver as a module, choose M here: the
- module will be called m52790.
-
-config VIDEO_I2C
- tristate "I2C transport video support"
- depends on VIDEO_V4L2 && I2C
- select VIDEOBUF2_VMALLOC
- imply HWMON
- help
- Enable the I2C transport video support which supports the
- following:
- * Panasonic AMG88xx Grid-Eye Sensors
- * Melexis MLX90640 Thermal Cameras
-
- To compile this driver as a module, choose M here: the
- module will be called video-i2c
-
-config VIDEO_ST_MIPID02
- tristate "STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge"
- depends on I2C && VIDEO_V4L2
- select MEDIA_CONTROLLER
- select VIDEO_V4L2_SUBDEV_API
- select V4L2_FWNODE
- help
- Support for STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge.
- It is used to allow usage of CSI-2 sensor with PARALLEL port
- controller.
-
- To compile this driver as a module, choose M here: the
- module will be called st-mipid02.
-
-endmenu
-
endif # VIDEO_V4L2
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 4/4] media: Kconfig: don't use visible for device type select
2020-03-25 16:03 ` Mauro Carvalho Chehab
` (4 preceding siblings ...)
(?)
@ 2020-03-25 16:03 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 16:03 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab
While making the menu invisible seemed a good idea, there's
a drawback: when the menu is not visible, it is not parsing
the "default" dependency.
So, instead, let's just avoid the items at the menu to be
prompted, by using the "prompt ... if" construction.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
drivers/media/Kconfig | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 787a8b8f288a..e880c7fae664 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -57,13 +57,13 @@ config MEDIA_SUBDRV_AUTOSELECT
If unsure say Y.
menu "Media device types"
- visible if MEDIA_SUPPORT_FILTER
#
# Multimedia support - automatically enable V4L2 and DVB core
#
config MEDIA_CAMERA_SUPPORT
- bool "Cameras and video grabbers"
+ bool
+ prompt "Cameras and video grabbers" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable support for webcams and video grabbers.
@@ -71,7 +71,8 @@ config MEDIA_CAMERA_SUPPORT
Say Y when you have a webcam or a video capture grabber board.
config MEDIA_ANALOG_TV_SUPPORT
- bool "Analog TV"
+ bool
+ prompt "Analog TV" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable analog TV support.
@@ -79,7 +80,8 @@ config MEDIA_ANALOG_TV_SUPPORT
Say Y when you have a board with analog TV support.
config MEDIA_DIGITAL_TV_SUPPORT
- bool "Digital TV"
+ bool
+ prompt "Digital TV" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable digital TV support.
@@ -87,7 +89,8 @@ config MEDIA_DIGITAL_TV_SUPPORT
Say Y when you have a board with digital TV support.
config MEDIA_RADIO_SUPPORT
- bool "AM/FM radio receivers/transmitters"
+ bool
+ prompt "AM/FM radio receivers/transmitters" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable AM/FM radio support.
@@ -98,7 +101,8 @@ config MEDIA_RADIO_SUPPORT
Say Y when you have a board with radio support.
config MEDIA_SDR_SUPPORT
- bool "Software defined radio"
+ bool
+ prompt "Software defined radio" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable software defined radio support.
@@ -106,7 +110,8 @@ config MEDIA_SDR_SUPPORT
Say Y when you have a software defined radio device.
config MEDIA_CEC_SUPPORT
- bool "HDMI CEC support"
+ bool
+ prompt "HDMI CEC support" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable support for HDMI CEC (Consumer Electronics Control),
@@ -116,7 +121,8 @@ config MEDIA_CEC_SUPPORT
adapter that supports HDMI CEC.
config MEDIA_PLATFORM_SUPPORT
- bool "Platform-specific devices"
+ bool
+ prompt "Platform-specific devices" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Enable support for complex cameras, codecs, and other hardware
@@ -129,7 +135,8 @@ config MEDIA_PLATFORM_SUPPORT
Say Y when you want to be able so see such devices.
config MEDIA_TEST_SUPPORT
- bool "Test drivers"
+ bool
+ prompt "Test drivers" if MEDIA_SUPPORT_FILTER
default y if !MEDIA_SUPPORT_FILTER
help
Those drivers should not be used on production Kernels, but
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 16:03 ` Mauro Carvalho Chehab
(?)
@ 2020-03-25 19:36 ` Helen Koike
-1 siblings, 0 replies; 34+ messages in thread
From: Helen Koike @ 2020-03-25 19:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Ezequiel Garcia, Ludovic Desroches, Shawn Guo, Sascha Hauer,
Chen-Yu Tsai, Nicolas Ferre, linux-renesas-soc, Yong Deng,
Kukjin Kim, Michal Simek, Pavel Machek, Paul Kocialkowski,
Yong Zhi, linux-samsung-soc, Fabio Estevam, Hyun Kwon,
Pengutronix Kernel Team, Hans Verkuil, Krzysztof Kozlowski,
Sakari Ailus, Sylwester Nawrocki, Kyungmin Park, NXP Linux Team,
Heungjun Kim, linux-arm-kernel, Maxime Ripard, devel, Bingbu Cao,
Lad, Prabhakar, Alexandre Belloni, Philipp Zabel,
Steve Longerbeam, Greg Kroah-Hartman, Tian Shu Qiu,
Niklas Söderlund, Laurent Pinchart
Hello,
On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> That's the second part of media Kconfig changes. The entire series is
> at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
I asked him to enable Vimc (from default configs, where multimedia starts disabled).
He knows that Vimc is a virtual camera driver, and this is how he behaved:
=== Start of experiment:
* He pressed '/' and searched for vimc to see the location path.
* Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
* He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
* He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
* He seemed a bit lost, going back and forth in the menus a couple of times.
* Then he pressed '/' again to search for vimc and see the location path, and he realized that there
should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
* He went back to "Media device types" again and start re-reading the options.
* He selected "Cameras and video grabbers" ant went back to "Media drivers".
* He sees "V4L test drivers", selects it, and enter this menu.
* He selects "Virtual Media Controller Driver".
I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
to combine "Test drivers" with "Cameras and video grabbers".
He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
realized by himself until that moment, nor tried it out to see what would happen).
He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
=== End of experiment
This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
kernel development (kernel dev newbies for instance).
Just another remark from me:
From the default config, "Media drivers" shows USB and PCI, and selecting those doesn't do anything, and people can even think
that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
shows up.
I hope this helps
Helen
>
> It addresses some issues I noticed when reviewing the series, and do
> some changes on how things will be displayed.
>
> It also simplify dependencencies on media-controller-dependent drivers,
> by auto-selecting the needed deps.
>
> It should be noticed that the media controller may also optionally
> selected for several other drivers, so there is still a prompt to allow
> manually enabling it, in the case it was not auto-selected.
>
> PS.: While not needed anymore, because all dependent drivers auto
> select, at least for now, I opted to keep the prompt for:
>
> - VIDEO_V4L2_SUBDEV_API
>
> The rationale is that there are a few drivers that can optionally depend
> on it (like tvp5150). So, better to keep the dependency, in order to be
> able to test those drivers with and without the option.
>
> - MEDIA_CONTROLLER_REQUEST_API
>
> The rationale is that there are some warnings at the Request API, and
> it would be good to keep it, at least while drivers are on staging.
>
> Mauro Carvalho Chehab (4):
> media: dvb-core: Kconfig: default to use dynamic minors
> media: Kconfig files: use select for V4L2 subdevs and MC
> media: i2c/Kconfig: reorganize items there
> media: Kconfig: don't use visible for device type select
>
> drivers/media/Kconfig | 25 +-
> drivers/media/dvb-core/Kconfig | 1 +
> drivers/media/i2c/Kconfig | 406 +++++++++++-------
> drivers/media/i2c/et8ek8/Kconfig | 4 +-
> drivers/media/i2c/m5mols/Kconfig | 5 +-
> drivers/media/i2c/smiapp/Kconfig | 5 +-
> drivers/media/pci/cobalt/Kconfig | 4 +-
> drivers/media/pci/intel/ipu3/Kconfig | 4 +-
> drivers/media/pci/sta2x11/Kconfig | 6 +-
> drivers/media/platform/Kconfig | 28 +-
> drivers/media/platform/am437x/Kconfig | 4 +-
> drivers/media/platform/atmel/Kconfig | 4 +-
> drivers/media/platform/cadence/Kconfig | 8 +-
> drivers/media/platform/exynos4-is/Kconfig | 5 +-
> drivers/media/platform/rcar-vin/Kconfig | 8 +-
> .../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
> .../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
> drivers/media/platform/xilinx/Kconfig | 4 +-
> drivers/media/spi/Kconfig | 4 +-
> drivers/media/test_drivers/vimc/Kconfig | 4 +-
> drivers/staging/media/hantro/Kconfig | 5 +-
> drivers/staging/media/imx/Kconfig | 5 +-
> drivers/staging/media/ipu3/Kconfig | 3 +-
> drivers/staging/media/omap4iss/Kconfig | 4 +-
> drivers/staging/media/rkisp1/Kconfig | 4 +-
> drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
> 26 files changed, 349 insertions(+), 214 deletions(-)
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 19:36 ` Helen Koike
0 siblings, 0 replies; 34+ messages in thread
From: Helen Koike @ 2020-03-25 19:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, Fabio Estevam, devel,
linux-renesas-soc, linux-samsung-soc, Ludovic Desroches,
Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim, NXP Linux Team,
Steve Longerbeam, Bingbu Cao, Tian Shu Qiu, Yong Zhi,
Philipp Zabel, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Niklas Söderlund, Yong Deng, Ezequiel Garcia,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Paul Kocialkowski,
Kyungmin Park, Pengutronix Kernel Team, Greg Kroah-Hartman,
Hans Verkuil, Shawn Guo
Hello,
On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> That's the second part of media Kconfig changes. The entire series is
> at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
I asked him to enable Vimc (from default configs, where multimedia starts disabled).
He knows that Vimc is a virtual camera driver, and this is how he behaved:
=== Start of experiment:
* He pressed '/' and searched for vimc to see the location path.
* Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
* He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
* He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
* He seemed a bit lost, going back and forth in the menus a couple of times.
* Then he pressed '/' again to search for vimc and see the location path, and he realized that there
should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
* He went back to "Media device types" again and start re-reading the options.
* He selected "Cameras and video grabbers" ant went back to "Media drivers".
* He sees "V4L test drivers", selects it, and enter this menu.
* He selects "Virtual Media Controller Driver".
I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
to combine "Test drivers" with "Cameras and video grabbers".
He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
realized by himself until that moment, nor tried it out to see what would happen).
He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
=== End of experiment
This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
kernel development (kernel dev newbies for instance).
Just another remark from me:
From the default config, "Media drivers" shows USB and PCI, and selecting those doesn't do anything, and people can even think
that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
shows up.
I hope this helps
Helen
>
> It addresses some issues I noticed when reviewing the series, and do
> some changes on how things will be displayed.
>
> It also simplify dependencencies on media-controller-dependent drivers,
> by auto-selecting the needed deps.
>
> It should be noticed that the media controller may also optionally
> selected for several other drivers, so there is still a prompt to allow
> manually enabling it, in the case it was not auto-selected.
>
> PS.: While not needed anymore, because all dependent drivers auto
> select, at least for now, I opted to keep the prompt for:
>
> - VIDEO_V4L2_SUBDEV_API
>
> The rationale is that there are a few drivers that can optionally depend
> on it (like tvp5150). So, better to keep the dependency, in order to be
> able to test those drivers with and without the option.
>
> - MEDIA_CONTROLLER_REQUEST_API
>
> The rationale is that there are some warnings at the Request API, and
> it would be good to keep it, at least while drivers are on staging.
>
> Mauro Carvalho Chehab (4):
> media: dvb-core: Kconfig: default to use dynamic minors
> media: Kconfig files: use select for V4L2 subdevs and MC
> media: i2c/Kconfig: reorganize items there
> media: Kconfig: don't use visible for device type select
>
> drivers/media/Kconfig | 25 +-
> drivers/media/dvb-core/Kconfig | 1 +
> drivers/media/i2c/Kconfig | 406 +++++++++++-------
> drivers/media/i2c/et8ek8/Kconfig | 4 +-
> drivers/media/i2c/m5mols/Kconfig | 5 +-
> drivers/media/i2c/smiapp/Kconfig | 5 +-
> drivers/media/pci/cobalt/Kconfig | 4 +-
> drivers/media/pci/intel/ipu3/Kconfig | 4 +-
> drivers/media/pci/sta2x11/Kconfig | 6 +-
> drivers/media/platform/Kconfig | 28 +-
> drivers/media/platform/am437x/Kconfig | 4 +-
> drivers/media/platform/atmel/Kconfig | 4 +-
> drivers/media/platform/cadence/Kconfig | 8 +-
> drivers/media/platform/exynos4-is/Kconfig | 5 +-
> drivers/media/platform/rcar-vin/Kconfig | 8 +-
> .../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
> .../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
> drivers/media/platform/xilinx/Kconfig | 4 +-
> drivers/media/spi/Kconfig | 4 +-
> drivers/media/test_drivers/vimc/Kconfig | 4 +-
> drivers/staging/media/hantro/Kconfig | 5 +-
> drivers/staging/media/imx/Kconfig | 5 +-
> drivers/staging/media/ipu3/Kconfig | 3 +-
> drivers/staging/media/omap4iss/Kconfig | 4 +-
> drivers/staging/media/rkisp1/Kconfig | 4 +-
> drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
> 26 files changed, 349 insertions(+), 214 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 19:36 ` Helen Koike
0 siblings, 0 replies; 34+ messages in thread
From: Helen Koike @ 2020-03-25 19:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, devel,
linux-renesas-soc, linux-samsung-soc, Ludovic Desroches,
Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim, NXP Linux Team,
Steve Longerbeam, Bingbu Cao, Tian Shu Qiu, Yong Zhi,
Philipp Zabel, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Niklas Söderlund, Yong Deng, Ezequiel Garcia,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Nicolas Ferre,
Paul Kocialkowski, Kyungmin Park, Pengutronix Kernel Team,
Greg Kroah-Hartman, Hans Verkuil, Shawn Guo
Hello,
On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> That's the second part of media Kconfig changes. The entire series is
> at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
I asked him to enable Vimc (from default configs, where multimedia starts disabled).
He knows that Vimc is a virtual camera driver, and this is how he behaved:
=== Start of experiment:
* He pressed '/' and searched for vimc to see the location path.
* Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
* He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
* He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
* He seemed a bit lost, going back and forth in the menus a couple of times.
* Then he pressed '/' again to search for vimc and see the location path, and he realized that there
should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
* He went back to "Media device types" again and start re-reading the options.
* He selected "Cameras and video grabbers" ant went back to "Media drivers".
* He sees "V4L test drivers", selects it, and enter this menu.
* He selects "Virtual Media Controller Driver".
I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
to combine "Test drivers" with "Cameras and video grabbers".
He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
realized by himself until that moment, nor tried it out to see what would happen).
He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
=== End of experiment
This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
kernel development (kernel dev newbies for instance).
Just another remark from me:
From the default config, "Media drivers" shows USB and PCI, and selecting those doesn't do anything, and people can even think
that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
shows up.
I hope this helps
Helen
>
> It addresses some issues I noticed when reviewing the series, and do
> some changes on how things will be displayed.
>
> It also simplify dependencencies on media-controller-dependent drivers,
> by auto-selecting the needed deps.
>
> It should be noticed that the media controller may also optionally
> selected for several other drivers, so there is still a prompt to allow
> manually enabling it, in the case it was not auto-selected.
>
> PS.: While not needed anymore, because all dependent drivers auto
> select, at least for now, I opted to keep the prompt for:
>
> - VIDEO_V4L2_SUBDEV_API
>
> The rationale is that there are a few drivers that can optionally depend
> on it (like tvp5150). So, better to keep the dependency, in order to be
> able to test those drivers with and without the option.
>
> - MEDIA_CONTROLLER_REQUEST_API
>
> The rationale is that there are some warnings at the Request API, and
> it would be good to keep it, at least while drivers are on staging.
>
> Mauro Carvalho Chehab (4):
> media: dvb-core: Kconfig: default to use dynamic minors
> media: Kconfig files: use select for V4L2 subdevs and MC
> media: i2c/Kconfig: reorganize items there
> media: Kconfig: don't use visible for device type select
>
> drivers/media/Kconfig | 25 +-
> drivers/media/dvb-core/Kconfig | 1 +
> drivers/media/i2c/Kconfig | 406 +++++++++++-------
> drivers/media/i2c/et8ek8/Kconfig | 4 +-
> drivers/media/i2c/m5mols/Kconfig | 5 +-
> drivers/media/i2c/smiapp/Kconfig | 5 +-
> drivers/media/pci/cobalt/Kconfig | 4 +-
> drivers/media/pci/intel/ipu3/Kconfig | 4 +-
> drivers/media/pci/sta2x11/Kconfig | 6 +-
> drivers/media/platform/Kconfig | 28 +-
> drivers/media/platform/am437x/Kconfig | 4 +-
> drivers/media/platform/atmel/Kconfig | 4 +-
> drivers/media/platform/cadence/Kconfig | 8 +-
> drivers/media/platform/exynos4-is/Kconfig | 5 +-
> drivers/media/platform/rcar-vin/Kconfig | 8 +-
> .../media/platform/sunxi/sun4i-csi/Kconfig | 4 +-
> .../media/platform/sunxi/sun6i-csi/Kconfig | 4 +-
> drivers/media/platform/xilinx/Kconfig | 4 +-
> drivers/media/spi/Kconfig | 4 +-
> drivers/media/test_drivers/vimc/Kconfig | 4 +-
> drivers/staging/media/hantro/Kconfig | 5 +-
> drivers/staging/media/imx/Kconfig | 5 +-
> drivers/staging/media/ipu3/Kconfig | 3 +-
> drivers/staging/media/omap4iss/Kconfig | 4 +-
> drivers/staging/media/rkisp1/Kconfig | 4 +-
> drivers/staging/media/sunxi/cedrus/Kconfig | 5 +-
> 26 files changed, 349 insertions(+), 214 deletions(-)
>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 19:36 ` Helen Koike
(?)
@ 2020-03-25 21:38 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 21:38 UTC (permalink / raw)
To: Helen Koike
Cc: Linux Media Mailing List, Ezequiel Garcia, Ludovic Desroches,
Shawn Guo, Sascha Hauer, Chen-Yu Tsai, Nicolas Ferre,
linux-renesas-soc, Yong Deng, Kukjin Kim, Michal Simek,
Pavel Machek, Paul Kocialkowski, Yong Zhi, linux-samsung-soc,
Fabio Estevam, Hyun Kwon, Pengutronix Kernel Team, Hans Verkuil,
Krzysztof Kozlowski, Sakari Ailus, Sylwester Nawrocki,
Kyungmin Park, NXP Linux Team, Heungjun Kim, linux-arm-kernel,
Maxime Ripard, devel, Bingbu Cao, Lad, Prabhakar,
Alexandre Belloni, Philipp Zabel, Steve Longerbeam,
Greg Kroah-Hartman, Tian Shu Qiu, Niklas Söderlund,
Laurent Pinchart
Em Wed, 25 Mar 2020 16:36:31 -0300
Helen Koike <helen.koike@collabora.com> escreveu:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> He knows that Vimc is a virtual camera driver, and this is how he behaved:
>
> === Start of experiment:
>
> * He pressed '/' and searched for vimc to see the location path.
> * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> * He seemed a bit lost, going back and forth in the menus a couple of times.
> * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> * He went back to "Media device types" again and start re-reading the options.
> * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> * He sees "V4L test drivers", selects it, and enter this menu.
> * He selects "Virtual Media Controller Driver".
>
> I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> to combine "Test drivers" with "Cameras and video grabbers".
> He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
>
> Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> realized by himself until that moment, nor tried it out to see what would happen).
>
> He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
That's easy to solve: all it needs is to add something similar
to this at drivers/media/Kconfig:
+ comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
+ visible if MEDIA_SUPPORT_FILTER
+
+ comment "All available drivers are shown below"
+ visible if !MEDIA_SUPPORT_FILTER
+
menu "Media drivers"
source "drivers/media/usb/Kconfig"
> === End of experiment
>
> This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> kernel development (kernel dev newbies for instance).
>
> Just another remark from me:
>
> From the default config, "Media drivers" shows USB and PCI,
Well, assuming that there are 2 billion computers, 1% with Linux
installed, and 10% of them have a media device (camera or TV),
we have about 2 millions of people running Linux. That excludes
Android and Embedded devices, where people usually don't touch.
During an entire year, there are about 4000 of Kernel developers
that has at least one patch accepted upstream (this number
includes developers for Android and other SoCs). Also, the
number of Kernel developers submitting patches upstream for the
media subsystem is around 20-40 people along an year.
So, about 99,9998% of the users using the media subsystems aren't
Kernel hackers. I bet that almost all of those will either need
to enable USB or a PCI driver.
Granted, 99,9998% seems too optimistic, but, assuming that this
would reduce to something like 80% (e. g. only 200 users
would ever try to build a media driver, with is a *very conservative*
number) this is still a lot more than the number of media Kernel
developers.
Also, a Kernel hacker will sooner or later find a way to enable it.
A normal user may find it a lot more trickier and will very likely
require more support, if the menus are too technical and the
default options are wrong.
-
Even with that, based on your small experiment (of someone from the
area), I suspect that, if you had asked him to enable, for example,
em28xx or dvbsky (with are some of the most popular drivers
those days), he would be able to enable it a lot faster.
> and selecting those doesn't do anything, and people can even think
> that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> shows up.
It is hard to comment on individual experiments. In the past, our
Kconfig system were like that: written for technical people with
background on computer engineering and some experience building the
Kernel.
E.g. people that knows that "/" activates a search mechanism at
the Kernel building system.
We usually had to spend *a lot of time* both on IRC and on e-mail
explaining people that just want to have their card supported,
how to do that. After the reorg (with added those more user-faced
interfaces), the number of people with problems reduced a lot.
Btw, if one tries to compile from media-build (with lots of users
do), this is even more relevant.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 21:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 21:38 UTC (permalink / raw)
To: Helen Koike
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, Fabio Estevam, devel,
linux-renesas-soc, linux-samsung-soc, Ludovic Desroches,
Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim, NXP Linux Team,
Steve Longerbeam, Bingbu Cao, Tian Shu Qiu, Yong Zhi,
Philipp Zabel, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Niklas Söderlund, Yong Deng, Ezequiel Garcia,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Paul Kocialkowski,
Kyungmin Park, Pengutronix Kernel Team, Greg Kroah-Hartman,
Hans Verkuil, Linux Media Mailing List, Shawn Guo
Em Wed, 25 Mar 2020 16:36:31 -0300
Helen Koike <helen.koike@collabora.com> escreveu:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> He knows that Vimc is a virtual camera driver, and this is how he behaved:
>
> === Start of experiment:
>
> * He pressed '/' and searched for vimc to see the location path.
> * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> * He seemed a bit lost, going back and forth in the menus a couple of times.
> * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> * He went back to "Media device types" again and start re-reading the options.
> * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> * He sees "V4L test drivers", selects it, and enter this menu.
> * He selects "Virtual Media Controller Driver".
>
> I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> to combine "Test drivers" with "Cameras and video grabbers".
> He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
>
> Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> realized by himself until that moment, nor tried it out to see what would happen).
>
> He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
That's easy to solve: all it needs is to add something similar
to this at drivers/media/Kconfig:
+ comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
+ visible if MEDIA_SUPPORT_FILTER
+
+ comment "All available drivers are shown below"
+ visible if !MEDIA_SUPPORT_FILTER
+
menu "Media drivers"
source "drivers/media/usb/Kconfig"
> === End of experiment
>
> This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> kernel development (kernel dev newbies for instance).
>
> Just another remark from me:
>
> From the default config, "Media drivers" shows USB and PCI,
Well, assuming that there are 2 billion computers, 1% with Linux
installed, and 10% of them have a media device (camera or TV),
we have about 2 millions of people running Linux. That excludes
Android and Embedded devices, where people usually don't touch.
During an entire year, there are about 4000 of Kernel developers
that has at least one patch accepted upstream (this number
includes developers for Android and other SoCs). Also, the
number of Kernel developers submitting patches upstream for the
media subsystem is around 20-40 people along an year.
So, about 99,9998% of the users using the media subsystems aren't
Kernel hackers. I bet that almost all of those will either need
to enable USB or a PCI driver.
Granted, 99,9998% seems too optimistic, but, assuming that this
would reduce to something like 80% (e. g. only 200 users
would ever try to build a media driver, with is a *very conservative*
number) this is still a lot more than the number of media Kernel
developers.
Also, a Kernel hacker will sooner or later find a way to enable it.
A normal user may find it a lot more trickier and will very likely
require more support, if the menus are too technical and the
default options are wrong.
-
Even with that, based on your small experiment (of someone from the
area), I suspect that, if you had asked him to enable, for example,
em28xx or dvbsky (with are some of the most popular drivers
those days), he would be able to enable it a lot faster.
> and selecting those doesn't do anything, and people can even think
> that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> shows up.
It is hard to comment on individual experiments. In the past, our
Kconfig system were like that: written for technical people with
background on computer engineering and some experience building the
Kernel.
E.g. people that knows that "/" activates a search mechanism at
the Kernel building system.
We usually had to spend *a lot of time* both on IRC and on e-mail
explaining people that just want to have their card supported,
how to do that. After the reorg (with added those more user-faced
interfaces), the number of people with problems reduced a lot.
Btw, if one tries to compile from media-build (with lots of users
do), this is even more relevant.
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 21:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-25 21:38 UTC (permalink / raw)
To: Helen Koike
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, devel,
linux-renesas-soc, linux-samsung-soc, Ludovic Desroches,
Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim, NXP Linux Team,
Steve Longerbeam, Bingbu Cao, Tian Shu Qiu, Yong Zhi,
Philipp Zabel, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Niklas Söderlund, Yong Deng, Ezequiel Garcia,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Nicolas Ferre,
Paul Kocialkowski, Kyungmin Park, Pengutronix Kernel Team,
Greg Kroah-Hartman, Hans Verkuil, Linux Media Mailing List,
Shawn Guo
Em Wed, 25 Mar 2020 16:36:31 -0300
Helen Koike <helen.koike@collabora.com> escreveu:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> He knows that Vimc is a virtual camera driver, and this is how he behaved:
>
> === Start of experiment:
>
> * He pressed '/' and searched for vimc to see the location path.
> * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> * He seemed a bit lost, going back and forth in the menus a couple of times.
> * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> * He went back to "Media device types" again and start re-reading the options.
> * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> * He sees "V4L test drivers", selects it, and enter this menu.
> * He selects "Virtual Media Controller Driver".
>
> I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> to combine "Test drivers" with "Cameras and video grabbers".
> He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
>
> Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> realized by himself until that moment, nor tried it out to see what would happen).
>
> He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
That's easy to solve: all it needs is to add something similar
to this at drivers/media/Kconfig:
+ comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
+ visible if MEDIA_SUPPORT_FILTER
+
+ comment "All available drivers are shown below"
+ visible if !MEDIA_SUPPORT_FILTER
+
menu "Media drivers"
source "drivers/media/usb/Kconfig"
> === End of experiment
>
> This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> kernel development (kernel dev newbies for instance).
>
> Just another remark from me:
>
> From the default config, "Media drivers" shows USB and PCI,
Well, assuming that there are 2 billion computers, 1% with Linux
installed, and 10% of them have a media device (camera or TV),
we have about 2 millions of people running Linux. That excludes
Android and Embedded devices, where people usually don't touch.
During an entire year, there are about 4000 of Kernel developers
that has at least one patch accepted upstream (this number
includes developers for Android and other SoCs). Also, the
number of Kernel developers submitting patches upstream for the
media subsystem is around 20-40 people along an year.
So, about 99,9998% of the users using the media subsystems aren't
Kernel hackers. I bet that almost all of those will either need
to enable USB or a PCI driver.
Granted, 99,9998% seems too optimistic, but, assuming that this
would reduce to something like 80% (e. g. only 200 users
would ever try to build a media driver, with is a *very conservative*
number) this is still a lot more than the number of media Kernel
developers.
Also, a Kernel hacker will sooner or later find a way to enable it.
A normal user may find it a lot more trickier and will very likely
require more support, if the menus are too technical and the
default options are wrong.
-
Even with that, based on your small experiment (of someone from the
area), I suspect that, if you had asked him to enable, for example,
em28xx or dvbsky (with are some of the most popular drivers
those days), he would be able to enable it a lot faster.
> and selecting those doesn't do anything, and people can even think
> that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> shows up.
It is hard to comment on individual experiments. In the past, our
Kconfig system were like that: written for technical people with
background on computer engineering and some experience building the
Kernel.
E.g. people that knows that "/" activates a search mechanism at
the Kernel building system.
We usually had to spend *a lot of time* both on IRC and on e-mail
explaining people that just want to have their card supported,
how to do that. After the reorg (with added those more user-faced
interfaces), the number of people with problems reduced a lot.
Btw, if one tries to compile from media-build (with lots of users
do), this is even more relevant.
Thanks,
Mauro
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 21:38 ` Mauro Carvalho Chehab
(?)
@ 2020-03-25 22:13 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-25 22:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Helen Koike, Linux Media Mailing List, Ezequiel Garcia,
Ludovic Desroches, Shawn Guo, Sascha Hauer, Chen-Yu Tsai,
Nicolas Ferre, linux-renesas-soc, Yong Deng, Kukjin Kim,
Michal Simek, Pavel Machek, Paul Kocialkowski, Yong Zhi,
linux-samsung-soc, Fabio Estevam, Hyun Kwon,
Pengutronix Kernel Team, Hans Verkuil, Krzysztof Kozlowski,
Sakari Ailus, Sylwester Nawrocki, Kyungmin Park, NXP Linux Team,
Heungjun Kim, linux-arm-kernel, Maxime Ripard, devel, Bingbu Cao,
Lad, Prabhakar, Alexandre Belloni, Philipp Zabel,
Steve Longerbeam, Greg Kroah-Hartman, Tian Shu Qiu,
Niklas Söderlund
Hi Mauro,
On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> >
> > === Start of experiment:
> >
> > * He pressed '/' and searched for vimc to see the location path.
> > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > * He went back to "Media device types" again and start re-reading the options.
> > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > * He sees "V4L test drivers", selects it, and enter this menu.
> > * He selects "Virtual Media Controller Driver".
> >
> > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > to combine "Test drivers" with "Cameras and video grabbers".
> > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> >
> > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > realized by himself until that moment, nor tried it out to see what would happen).
> >
> > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
>
> That's easy to solve: all it needs is to add something similar
> to this at drivers/media/Kconfig:
>
> + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> + visible if MEDIA_SUPPORT_FILTER
> +
> + comment "All available drivers are shown below"
> + visible if !MEDIA_SUPPORT_FILTER
> +
> menu "Media drivers"
>
> source "drivers/media/usb/Kconfig"
>
> > === End of experiment
> >
> > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > kernel development (kernel dev newbies for instance).
> >
> > Just another remark from me:
> >
> > From the default config, "Media drivers" shows USB and PCI,
>
> Well, assuming that there are 2 billion computers, 1% with Linux
> installed, and 10% of them have a media device (camera or TV),
> we have about 2 millions of people running Linux. That excludes
> Android and Embedded devices, where people usually don't touch.
>
> During an entire year, there are about 4000 of Kernel developers
> that has at least one patch accepted upstream (this number
> includes developers for Android and other SoCs). Also, the
> number of Kernel developers submitting patches upstream for the
> media subsystem is around 20-40 people along an year.
$ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
215
There's some duplication of e-mail addresses, but it's still roughly an
order or magnitude bigger (and it's not counting staging, headers or
documentation).
> So, about 99,9998% of the users using the media subsystems aren't
> Kernel hackers. I bet that almost all of those will either need
> to enable USB or a PCI driver.
And the extremely vast majority of these will never enable a kernel
option because they will never compile a kernel. They don't even know
what a kernel is :-)
> Granted, 99,9998% seems too optimistic, but, assuming that this
> would reduce to something like 80% (e. g. only 200 users
> would ever try to build a media driver, with is a *very conservative*
> number) this is still a lot more than the number of media Kernel
> developers.
>
> Also, a Kernel hacker will sooner or later find a way to enable it.
> A normal user may find it a lot more trickier and will very likely
> require more support, if the menus are too technical and the
> default options are wrong.
I'm not sure to follow you. Are you implying that this patch series,
which Helen has tested against a real user, not an experienced kernel
hacker, may make the configuration options more difficult for kernel
hackers, but improves the situation for users ?
>
> -
>
> Even with that, based on your small experiment (of someone from the
> area), I suspect that, if you had asked him to enable, for example,
> em28xx or dvbsky (with are some of the most popular drivers
> those days), he would be able to enable it a lot faster.
This is the *only* real piece of evidence we have, let's not assume we
know better.
> > and selecting those doesn't do anything, and people can even think
> > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > shows up.
>
> It is hard to comment on individual experiments. In the past, our
> Kconfig system were like that: written for technical people with
> background on computer engineering and some experience building the
> Kernel.
>
> E.g. people that knows that "/" activates a search mechanism at
> the Kernel building system.
>
> We usually had to spend *a lot of time* both on IRC and on e-mail
> explaining people that just want to have their card supported,
> how to do that. After the reorg (with added those more user-faced
> interfaces), the number of people with problems reduced a lot.
Don't you think that could come mainly from better support for media
devices in distributions ?
> Btw, if one tries to compile from media-build (with lots of users
> do), this is even more relevant.
Can you quantify "lots of users" ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 22:13 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-25 22:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, Fabio Estevam, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Hi Mauro,
On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> >
> > === Start of experiment:
> >
> > * He pressed '/' and searched for vimc to see the location path.
> > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > * He went back to "Media device types" again and start re-reading the options.
> > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > * He sees "V4L test drivers", selects it, and enter this menu.
> > * He selects "Virtual Media Controller Driver".
> >
> > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > to combine "Test drivers" with "Cameras and video grabbers".
> > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> >
> > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > realized by himself until that moment, nor tried it out to see what would happen).
> >
> > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
>
> That's easy to solve: all it needs is to add something similar
> to this at drivers/media/Kconfig:
>
> + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> + visible if MEDIA_SUPPORT_FILTER
> +
> + comment "All available drivers are shown below"
> + visible if !MEDIA_SUPPORT_FILTER
> +
> menu "Media drivers"
>
> source "drivers/media/usb/Kconfig"
>
> > === End of experiment
> >
> > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > kernel development (kernel dev newbies for instance).
> >
> > Just another remark from me:
> >
> > From the default config, "Media drivers" shows USB and PCI,
>
> Well, assuming that there are 2 billion computers, 1% with Linux
> installed, and 10% of them have a media device (camera or TV),
> we have about 2 millions of people running Linux. That excludes
> Android and Embedded devices, where people usually don't touch.
>
> During an entire year, there are about 4000 of Kernel developers
> that has at least one patch accepted upstream (this number
> includes developers for Android and other SoCs). Also, the
> number of Kernel developers submitting patches upstream for the
> media subsystem is around 20-40 people along an year.
$ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
215
There's some duplication of e-mail addresses, but it's still roughly an
order or magnitude bigger (and it's not counting staging, headers or
documentation).
> So, about 99,9998% of the users using the media subsystems aren't
> Kernel hackers. I bet that almost all of those will either need
> to enable USB or a PCI driver.
And the extremely vast majority of these will never enable a kernel
option because they will never compile a kernel. They don't even know
what a kernel is :-)
> Granted, 99,9998% seems too optimistic, but, assuming that this
> would reduce to something like 80% (e. g. only 200 users
> would ever try to build a media driver, with is a *very conservative*
> number) this is still a lot more than the number of media Kernel
> developers.
>
> Also, a Kernel hacker will sooner or later find a way to enable it.
> A normal user may find it a lot more trickier and will very likely
> require more support, if the menus are too technical and the
> default options are wrong.
I'm not sure to follow you. Are you implying that this patch series,
which Helen has tested against a real user, not an experienced kernel
hacker, may make the configuration options more difficult for kernel
hackers, but improves the situation for users ?
>
> -
>
> Even with that, based on your small experiment (of someone from the
> area), I suspect that, if you had asked him to enable, for example,
> em28xx or dvbsky (with are some of the most popular drivers
> those days), he would be able to enable it a lot faster.
This is the *only* real piece of evidence we have, let's not assume we
know better.
> > and selecting those doesn't do anything, and people can even think
> > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > shows up.
>
> It is hard to comment on individual experiments. In the past, our
> Kconfig system were like that: written for technical people with
> background on computer engineering and some experience building the
> Kernel.
>
> E.g. people that knows that "/" activates a search mechanism at
> the Kernel building system.
>
> We usually had to spend *a lot of time* both on IRC and on e-mail
> explaining people that just want to have their card supported,
> how to do that. After the reorg (with added those more user-faced
> interfaces), the number of people with problems reduced a lot.
Don't you think that could come mainly from better support for media
devices in distributions ?
> Btw, if one tries to compile from media-build (with lots of users
> do), this is even more relevant.
Can you quantify "lots of users" ?
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-25 22:13 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-25 22:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Hi Mauro,
On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> >
> > === Start of experiment:
> >
> > * He pressed '/' and searched for vimc to see the location path.
> > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > * He went back to "Media device types" again and start re-reading the options.
> > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > * He sees "V4L test drivers", selects it, and enter this menu.
> > * He selects "Virtual Media Controller Driver".
> >
> > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > to combine "Test drivers" with "Cameras and video grabbers".
> > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> >
> > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > realized by himself until that moment, nor tried it out to see what would happen).
> >
> > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
>
> That's easy to solve: all it needs is to add something similar
> to this at drivers/media/Kconfig:
>
> + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> + visible if MEDIA_SUPPORT_FILTER
> +
> + comment "All available drivers are shown below"
> + visible if !MEDIA_SUPPORT_FILTER
> +
> menu "Media drivers"
>
> source "drivers/media/usb/Kconfig"
>
> > === End of experiment
> >
> > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > kernel development (kernel dev newbies for instance).
> >
> > Just another remark from me:
> >
> > From the default config, "Media drivers" shows USB and PCI,
>
> Well, assuming that there are 2 billion computers, 1% with Linux
> installed, and 10% of them have a media device (camera or TV),
> we have about 2 millions of people running Linux. That excludes
> Android and Embedded devices, where people usually don't touch.
>
> During an entire year, there are about 4000 of Kernel developers
> that has at least one patch accepted upstream (this number
> includes developers for Android and other SoCs). Also, the
> number of Kernel developers submitting patches upstream for the
> media subsystem is around 20-40 people along an year.
$ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
215
There's some duplication of e-mail addresses, but it's still roughly an
order or magnitude bigger (and it's not counting staging, headers or
documentation).
> So, about 99,9998% of the users using the media subsystems aren't
> Kernel hackers. I bet that almost all of those will either need
> to enable USB or a PCI driver.
And the extremely vast majority of these will never enable a kernel
option because they will never compile a kernel. They don't even know
what a kernel is :-)
> Granted, 99,9998% seems too optimistic, but, assuming that this
> would reduce to something like 80% (e. g. only 200 users
> would ever try to build a media driver, with is a *very conservative*
> number) this is still a lot more than the number of media Kernel
> developers.
>
> Also, a Kernel hacker will sooner or later find a way to enable it.
> A normal user may find it a lot more trickier and will very likely
> require more support, if the menus are too technical and the
> default options are wrong.
I'm not sure to follow you. Are you implying that this patch series,
which Helen has tested against a real user, not an experienced kernel
hacker, may make the configuration options more difficult for kernel
hackers, but improves the situation for users ?
>
> -
>
> Even with that, based on your small experiment (of someone from the
> area), I suspect that, if you had asked him to enable, for example,
> em28xx or dvbsky (with are some of the most popular drivers
> those days), he would be able to enable it a lot faster.
This is the *only* real piece of evidence we have, let's not assume we
know better.
> > and selecting those doesn't do anything, and people can even think
> > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > shows up.
>
> It is hard to comment on individual experiments. In the past, our
> Kconfig system were like that: written for technical people with
> background on computer engineering and some experience building the
> Kernel.
>
> E.g. people that knows that "/" activates a search mechanism at
> the Kernel building system.
>
> We usually had to spend *a lot of time* both on IRC and on e-mail
> explaining people that just want to have their card supported,
> how to do that. After the reorg (with added those more user-faced
> interfaces), the number of people with problems reduced a lot.
Don't you think that could come mainly from better support for media
devices in distributions ?
> Btw, if one tries to compile from media-build (with lots of users
> do), this is even more relevant.
Can you quantify "lots of users" ?
--
Regards,
Laurent Pinchart
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 22:13 ` Laurent Pinchart
(?)
@ 2020-03-26 8:28 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 8:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Helen Koike, Linux Media Mailing List, Ezequiel Garcia,
Ludovic Desroches, Shawn Guo, Sascha Hauer, Chen-Yu Tsai,
Nicolas Ferre, linux-renesas-soc, Yong Deng, Kukjin Kim,
Michal Simek, Pavel Machek, Paul Kocialkowski, Yong Zhi,
linux-samsung-soc, Fabio Estevam, Hyun Kwon,
Pengutronix Kernel Team, Hans Verkuil, Krzysztof Kozlowski,
Sakari Ailus, Sylwester Nawrocki, Kyungmin Park, NXP Linux Team,
Heungjun Kim, linux-arm-kernel, Maxime Ripard, devel, Bingbu Cao,
Lad, Prabhakar, Alexandre Belloni, Philipp Zabel,
Steve Longerbeam, Greg Kroah-Hartman, Tian Shu Qiu,
Niklas Söderlund
Em Thu, 26 Mar 2020 00:13:43 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > That's the second part of media Kconfig changes. The entire series is
> > > > at:
> > > >
> > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > >
> > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > >
> > > === Start of experiment:
> > >
> > > * He pressed '/' and searched for vimc to see the location path.
> > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > * He went back to "Media device types" again and start re-reading the options.
> > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > * He selects "Virtual Media Controller Driver".
> > >
> > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > to combine "Test drivers" with "Cameras and video grabbers".
> > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > >
> > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > realized by himself until that moment, nor tried it out to see what would happen).
> > >
> > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> >
> > That's easy to solve: all it needs is to add something similar
> > to this at drivers/media/Kconfig:
> >
> > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > + visible if MEDIA_SUPPORT_FILTER
> > +
> > + comment "All available drivers are shown below"
> > + visible if !MEDIA_SUPPORT_FILTER
> > +
> > menu "Media drivers"
> >
> > source "drivers/media/usb/Kconfig"
> >
> > > === End of experiment
> > >
> > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > kernel development (kernel dev newbies for instance).
> > >
> > > Just another remark from me:
> > >
> > > From the default config, "Media drivers" shows USB and PCI,
> >
> > Well, assuming that there are 2 billion computers, 1% with Linux
> > installed, and 10% of them have a media device (camera or TV),
> > we have about 2 millions of people running Linux. That excludes
> > Android and Embedded devices, where people usually don't touch.
> >
> > During an entire year, there are about 4000 of Kernel developers
> > that has at least one patch accepted upstream (this number
> > includes developers for Android and other SoCs). Also, the
> > number of Kernel developers submitting patches upstream for the
> > media subsystem is around 20-40 people along an year.
>
> $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> 215
>
> There's some duplication of e-mail addresses, but it's still roughly an
> order or magnitude bigger (and it's not counting staging, headers or
> documentation).
>
> > So, about 99,9998% of the users using the media subsystems aren't
> > Kernel hackers. I bet that almost all of those will either need
> > to enable USB or a PCI driver.
>
> And the extremely vast majority of these will never enable a kernel
> option because they will never compile a kernel. They don't even know
> what a kernel is :-)
>
> > Granted, 99,9998% seems too optimistic, but, assuming that this
> > would reduce to something like 80% (e. g. only 200 users
> > would ever try to build a media driver, with is a *very conservative*
> > number) this is still a lot more than the number of media Kernel
> > developers.
> >
> > Also, a Kernel hacker will sooner or later find a way to enable it.
> > A normal user may find it a lot more trickier and will very likely
> > require more support, if the menus are too technical and the
> > default options are wrong.
>
> I'm not sure to follow you. Are you implying that this patch series,
> which Helen has tested against a real user, not an experienced kernel
> hacker, may make the configuration options more difficult for kernel
> hackers, but improves the situation for users ?
Come on, it is not harder for Kernel hackers. It is just different than
what it used to be before the changes. At the above experience, at the
very first time this Kernel hacker looked on it, it was able to figure
out how to enable the driver. I bet that, if you now repeat the experiment
with the same guy, he would be able to enable another driver a lot quicker.
My view is that, with the option of either enable or disable the
filtering mechanism, it will be easier for everybody:
- Distro maintainers for PCs can just disable platform and
test drivers, and keep the other drivers enabled;
- An experienced Kernel hacker will disable the filter and select
the needed drivers directly.
- An user wanting to test a driver with new patches (or a new driver)
use the filters to select the USB driver he needs (probably using the
media_tree.git, in order to see only the media options).
> > -
> >
> > Even with that, based on your small experiment (of someone from the
> > area), I suspect that, if you had asked him to enable, for example,
> > em28xx or dvbsky (with are some of the most popular drivers
> > those days), he would be able to enable it a lot faster.
>
> This is the *only* real piece of evidence we have, let's not assume we
> know better.
>
> > > and selecting those doesn't do anything, and people can even think
> > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > shows up.
> >
> > It is hard to comment on individual experiments. In the past, our
> > Kconfig system were like that: written for technical people with
> > background on computer engineering and some experience building the
> > Kernel.
> >
> > E.g. people that knows that "/" activates a search mechanism at
> > the Kernel building system.
> >
> > We usually had to spend *a lot of time* both on IRC and on e-mail
> > explaining people that just want to have their card supported,
> > how to do that. After the reorg (with added those more user-faced
> > interfaces), the number of people with problems reduced a lot.
>
> Don't you think that could come mainly from better support for media
> devices in distributions ?
>
> > Btw, if one tries to compile from media-build (with lots of users
> > do), this is even more relevant.
>
> Can you quantify "lots of users" ?
Enough to make us to decide that re-working the Kconfig menus and
add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
efforts.
Guess what? The efforts were fully paid, as it reduced a lot the
amount of time we had to weekly spend helping people to build their
Kernels in order to test support for their new hardware.
It also helped a lot to set the right Kconfig options on distros.
I did my contributions on that time by improving Fedora and on RHEL,
making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
See, for some random distro maintainer, new Kconfig symbols pops up
every time. Enabling all of them is usually a very bad idea. So, a
filtering mechanism that would, for example, hide test and skeleton
drivers to be built is a very nice feat, as it means a lot less
symbols for them to study and decide whether such new options should
be enabled or not
Thanks,
Mauro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 8:28 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 8:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, Fabio Estevam, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Em Thu, 26 Mar 2020 00:13:43 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > That's the second part of media Kconfig changes. The entire series is
> > > > at:
> > > >
> > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > >
> > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > >
> > > === Start of experiment:
> > >
> > > * He pressed '/' and searched for vimc to see the location path.
> > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > * He went back to "Media device types" again and start re-reading the options.
> > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > * He selects "Virtual Media Controller Driver".
> > >
> > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > to combine "Test drivers" with "Cameras and video grabbers".
> > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > >
> > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > realized by himself until that moment, nor tried it out to see what would happen).
> > >
> > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> >
> > That's easy to solve: all it needs is to add something similar
> > to this at drivers/media/Kconfig:
> >
> > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > + visible if MEDIA_SUPPORT_FILTER
> > +
> > + comment "All available drivers are shown below"
> > + visible if !MEDIA_SUPPORT_FILTER
> > +
> > menu "Media drivers"
> >
> > source "drivers/media/usb/Kconfig"
> >
> > > === End of experiment
> > >
> > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > kernel development (kernel dev newbies for instance).
> > >
> > > Just another remark from me:
> > >
> > > From the default config, "Media drivers" shows USB and PCI,
> >
> > Well, assuming that there are 2 billion computers, 1% with Linux
> > installed, and 10% of them have a media device (camera or TV),
> > we have about 2 millions of people running Linux. That excludes
> > Android and Embedded devices, where people usually don't touch.
> >
> > During an entire year, there are about 4000 of Kernel developers
> > that has at least one patch accepted upstream (this number
> > includes developers for Android and other SoCs). Also, the
> > number of Kernel developers submitting patches upstream for the
> > media subsystem is around 20-40 people along an year.
>
> $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> 215
>
> There's some duplication of e-mail addresses, but it's still roughly an
> order or magnitude bigger (and it's not counting staging, headers or
> documentation).
>
> > So, about 99,9998% of the users using the media subsystems aren't
> > Kernel hackers. I bet that almost all of those will either need
> > to enable USB or a PCI driver.
>
> And the extremely vast majority of these will never enable a kernel
> option because they will never compile a kernel. They don't even know
> what a kernel is :-)
>
> > Granted, 99,9998% seems too optimistic, but, assuming that this
> > would reduce to something like 80% (e. g. only 200 users
> > would ever try to build a media driver, with is a *very conservative*
> > number) this is still a lot more than the number of media Kernel
> > developers.
> >
> > Also, a Kernel hacker will sooner or later find a way to enable it.
> > A normal user may find it a lot more trickier and will very likely
> > require more support, if the menus are too technical and the
> > default options are wrong.
>
> I'm not sure to follow you. Are you implying that this patch series,
> which Helen has tested against a real user, not an experienced kernel
> hacker, may make the configuration options more difficult for kernel
> hackers, but improves the situation for users ?
Come on, it is not harder for Kernel hackers. It is just different than
what it used to be before the changes. At the above experience, at the
very first time this Kernel hacker looked on it, it was able to figure
out how to enable the driver. I bet that, if you now repeat the experiment
with the same guy, he would be able to enable another driver a lot quicker.
My view is that, with the option of either enable or disable the
filtering mechanism, it will be easier for everybody:
- Distro maintainers for PCs can just disable platform and
test drivers, and keep the other drivers enabled;
- An experienced Kernel hacker will disable the filter and select
the needed drivers directly.
- An user wanting to test a driver with new patches (or a new driver)
use the filters to select the USB driver he needs (probably using the
media_tree.git, in order to see only the media options).
> > -
> >
> > Even with that, based on your small experiment (of someone from the
> > area), I suspect that, if you had asked him to enable, for example,
> > em28xx or dvbsky (with are some of the most popular drivers
> > those days), he would be able to enable it a lot faster.
>
> This is the *only* real piece of evidence we have, let's not assume we
> know better.
>
> > > and selecting those doesn't do anything, and people can even think
> > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > shows up.
> >
> > It is hard to comment on individual experiments. In the past, our
> > Kconfig system were like that: written for technical people with
> > background on computer engineering and some experience building the
> > Kernel.
> >
> > E.g. people that knows that "/" activates a search mechanism at
> > the Kernel building system.
> >
> > We usually had to spend *a lot of time* both on IRC and on e-mail
> > explaining people that just want to have their card supported,
> > how to do that. After the reorg (with added those more user-faced
> > interfaces), the number of people with problems reduced a lot.
>
> Don't you think that could come mainly from better support for media
> devices in distributions ?
>
> > Btw, if one tries to compile from media-build (with lots of users
> > do), this is even more relevant.
>
> Can you quantify "lots of users" ?
Enough to make us to decide that re-working the Kconfig menus and
add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
efforts.
Guess what? The efforts were fully paid, as it reduced a lot the
amount of time we had to weekly spend helping people to build their
Kernels in order to test support for their new hardware.
It also helped a lot to set the right Kconfig options on distros.
I did my contributions on that time by improving Fedora and on RHEL,
making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
See, for some random distro maintainer, new Kconfig symbols pops up
every time. Enabling all of them is usually a very bad idea. So, a
filtering mechanism that would, for example, hide test and skeleton
drivers to be built is a very nice feat, as it means a lot less
symbols for them to study and decide whether such new options should
be enabled or not
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 8:28 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 8:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Em Thu, 26 Mar 2020 00:13:43 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > That's the second part of media Kconfig changes. The entire series is
> > > > at:
> > > >
> > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > >
> > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > >
> > > === Start of experiment:
> > >
> > > * He pressed '/' and searched for vimc to see the location path.
> > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > * He went back to "Media device types" again and start re-reading the options.
> > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > * He selects "Virtual Media Controller Driver".
> > >
> > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > to combine "Test drivers" with "Cameras and video grabbers".
> > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > >
> > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > realized by himself until that moment, nor tried it out to see what would happen).
> > >
> > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> >
> > That's easy to solve: all it needs is to add something similar
> > to this at drivers/media/Kconfig:
> >
> > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > + visible if MEDIA_SUPPORT_FILTER
> > +
> > + comment "All available drivers are shown below"
> > + visible if !MEDIA_SUPPORT_FILTER
> > +
> > menu "Media drivers"
> >
> > source "drivers/media/usb/Kconfig"
> >
> > > === End of experiment
> > >
> > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > kernel development (kernel dev newbies for instance).
> > >
> > > Just another remark from me:
> > >
> > > From the default config, "Media drivers" shows USB and PCI,
> >
> > Well, assuming that there are 2 billion computers, 1% with Linux
> > installed, and 10% of them have a media device (camera or TV),
> > we have about 2 millions of people running Linux. That excludes
> > Android and Embedded devices, where people usually don't touch.
> >
> > During an entire year, there are about 4000 of Kernel developers
> > that has at least one patch accepted upstream (this number
> > includes developers for Android and other SoCs). Also, the
> > number of Kernel developers submitting patches upstream for the
> > media subsystem is around 20-40 people along an year.
>
> $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> 215
>
> There's some duplication of e-mail addresses, but it's still roughly an
> order or magnitude bigger (and it's not counting staging, headers or
> documentation).
>
> > So, about 99,9998% of the users using the media subsystems aren't
> > Kernel hackers. I bet that almost all of those will either need
> > to enable USB or a PCI driver.
>
> And the extremely vast majority of these will never enable a kernel
> option because they will never compile a kernel. They don't even know
> what a kernel is :-)
>
> > Granted, 99,9998% seems too optimistic, but, assuming that this
> > would reduce to something like 80% (e. g. only 200 users
> > would ever try to build a media driver, with is a *very conservative*
> > number) this is still a lot more than the number of media Kernel
> > developers.
> >
> > Also, a Kernel hacker will sooner or later find a way to enable it.
> > A normal user may find it a lot more trickier and will very likely
> > require more support, if the menus are too technical and the
> > default options are wrong.
>
> I'm not sure to follow you. Are you implying that this patch series,
> which Helen has tested against a real user, not an experienced kernel
> hacker, may make the configuration options more difficult for kernel
> hackers, but improves the situation for users ?
Come on, it is not harder for Kernel hackers. It is just different than
what it used to be before the changes. At the above experience, at the
very first time this Kernel hacker looked on it, it was able to figure
out how to enable the driver. I bet that, if you now repeat the experiment
with the same guy, he would be able to enable another driver a lot quicker.
My view is that, with the option of either enable or disable the
filtering mechanism, it will be easier for everybody:
- Distro maintainers for PCs can just disable platform and
test drivers, and keep the other drivers enabled;
- An experienced Kernel hacker will disable the filter and select
the needed drivers directly.
- An user wanting to test a driver with new patches (or a new driver)
use the filters to select the USB driver he needs (probably using the
media_tree.git, in order to see only the media options).
> > -
> >
> > Even with that, based on your small experiment (of someone from the
> > area), I suspect that, if you had asked him to enable, for example,
> > em28xx or dvbsky (with are some of the most popular drivers
> > those days), he would be able to enable it a lot faster.
>
> This is the *only* real piece of evidence we have, let's not assume we
> know better.
>
> > > and selecting those doesn't do anything, and people can even think
> > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > shows up.
> >
> > It is hard to comment on individual experiments. In the past, our
> > Kconfig system were like that: written for technical people with
> > background on computer engineering and some experience building the
> > Kernel.
> >
> > E.g. people that knows that "/" activates a search mechanism at
> > the Kernel building system.
> >
> > We usually had to spend *a lot of time* both on IRC and on e-mail
> > explaining people that just want to have their card supported,
> > how to do that. After the reorg (with added those more user-faced
> > interfaces), the number of people with problems reduced a lot.
>
> Don't you think that could come mainly from better support for media
> devices in distributions ?
>
> > Btw, if one tries to compile from media-build (with lots of users
> > do), this is even more relevant.
>
> Can you quantify "lots of users" ?
Enough to make us to decide that re-working the Kconfig menus and
add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
efforts.
Guess what? The efforts were fully paid, as it reduced a lot the
amount of time we had to weekly spend helping people to build their
Kernels in order to test support for their new hardware.
It also helped a lot to set the right Kconfig options on distros.
I did my contributions on that time by improving Fedora and on RHEL,
making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
See, for some random distro maintainer, new Kconfig symbols pops up
every time. Enabling all of them is usually a very bad idea. So, a
filtering mechanism that would, for example, hide test and skeleton
drivers to be built is a very nice feat, as it means a lot less
symbols for them to study and decide whether such new options should
be enabled or not
Thanks,
Mauro
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-26 8:28 ` Mauro Carvalho Chehab
(?)
@ 2020-03-26 10:13 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-26 10:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Helen Koike, Linux Media Mailing List, Ezequiel Garcia,
Ludovic Desroches, Shawn Guo, Sascha Hauer, Chen-Yu Tsai,
Nicolas Ferre, linux-renesas-soc, Yong Deng, Kukjin Kim,
Michal Simek, Pavel Machek, Paul Kocialkowski, Yong Zhi,
linux-samsung-soc, Fabio Estevam, Hyun Kwon,
Pengutronix Kernel Team, Hans Verkuil, Krzysztof Kozlowski,
Sakari Ailus, Sylwester Nawrocki, Kyungmin Park, NXP Linux Team,
Heungjun Kim, linux-arm-kernel, Maxime Ripard, devel, Bingbu Cao,
Lad, Prabhakar, Alexandre Belloni, Philipp Zabel,
Steve Longerbeam, Greg Kroah-Hartman, Tian Shu Qiu,
Niklas Söderlund
Hi Mauro,
On Thu, Mar 26, 2020 at 09:28:32AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart escreveu:
> > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > > That's the second part of media Kconfig changes. The entire series is
> > > > > at:
> > > > >
> > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > > >
> > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > > >
> > > > === Start of experiment:
> > > >
> > > > * He pressed '/' and searched for vimc to see the location path.
> > > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > > * He went back to "Media device types" again and start re-reading the options.
> > > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > > * He selects "Virtual Media Controller Driver".
> > > >
> > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > > to combine "Test drivers" with "Cameras and video grabbers".
> > > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > > >
> > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > > realized by himself until that moment, nor tried it out to see what would happen).
> > > >
> > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> > >
> > > That's easy to solve: all it needs is to add something similar
> > > to this at drivers/media/Kconfig:
> > >
> > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > > + visible if MEDIA_SUPPORT_FILTER
> > > +
> > > + comment "All available drivers are shown below"
> > > + visible if !MEDIA_SUPPORT_FILTER
> > > +
> > > menu "Media drivers"
> > >
> > > source "drivers/media/usb/Kconfig"
> > >
> > > > === End of experiment
> > > >
> > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > > kernel development (kernel dev newbies for instance).
> > > >
> > > > Just another remark from me:
> > > >
> > > > From the default config, "Media drivers" shows USB and PCI,
> > >
> > > Well, assuming that there are 2 billion computers, 1% with Linux
> > > installed, and 10% of them have a media device (camera or TV),
> > > we have about 2 millions of people running Linux. That excludes
> > > Android and Embedded devices, where people usually don't touch.
> > >
> > > During an entire year, there are about 4000 of Kernel developers
> > > that has at least one patch accepted upstream (this number
> > > includes developers for Android and other SoCs). Also, the
> > > number of Kernel developers submitting patches upstream for the
> > > media subsystem is around 20-40 people along an year.
> >
> > $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> > 215
> >
> > There's some duplication of e-mail addresses, but it's still roughly an
> > order or magnitude bigger (and it's not counting staging, headers or
> > documentation).
> >
> > > So, about 99,9998% of the users using the media subsystems aren't
> > > Kernel hackers. I bet that almost all of those will either need
> > > to enable USB or a PCI driver.
> >
> > And the extremely vast majority of these will never enable a kernel
> > option because they will never compile a kernel. They don't even know
> > what a kernel is :-)
> >
> > > Granted, 99,9998% seems too optimistic, but, assuming that this
> > > would reduce to something like 80% (e. g. only 200 users
> > > would ever try to build a media driver, with is a *very conservative*
> > > number) this is still a lot more than the number of media Kernel
> > > developers.
> > >
> > > Also, a Kernel hacker will sooner or later find a way to enable it.
> > > A normal user may find it a lot more trickier and will very likely
> > > require more support, if the menus are too technical and the
> > > default options are wrong.
> >
> > I'm not sure to follow you. Are you implying that this patch series,
> > which Helen has tested against a real user, not an experienced kernel
> > hacker, may make the configuration options more difficult for kernel
> > hackers, but improves the situation for users ?
>
> Come on, it is not harder for Kernel hackers. It is just different than
> what it used to be before the changes.
Sorry, I didn't meant to say it would be more complex for me (I mostly
don't use menuconfig anyway, I edit the .config file manually :-)), but
I was reading your e-mail as implying that, and was wondering if it was
me misreading it.
> At the above experience, at the
> very first time this Kernel hacker looked on it, it was able to figure
> out how to enable the driver. I bet that, if you now repeat the experiment
> with the same guy, he would be able to enable another driver a lot quicker.
>
> My view is that, with the option of either enable or disable the
> filtering mechanism, it will be easier for everybody:
>
> - Distro maintainers for PCs can just disable platform and
> test drivers, and keep the other drivers enabled;
>
> - An experienced Kernel hacker will disable the filter and select
> the needed drivers directly.
>
> - An user wanting to test a driver with new patches (or a new driver)
> use the filters to select the USB driver he needs (probably using the
> media_tree.git, in order to see only the media options).
My personal view is that this makes things more complex, and more
complexity usually means less clarity. If we want to be serious about
the usability of our Kconfig menu, we should get real users involved in
the design, at least by testing it on them, and getting feedback.
Otherwise we'll just be a bunch of kernel developers sitting in our
ivory tower thinking we know better than our users what is good for
them.
> > > -
> > >
> > > Even with that, based on your small experiment (of someone from the
> > > area), I suspect that, if you had asked him to enable, for example,
> > > em28xx or dvbsky (with are some of the most popular drivers
> > > those days), he would be able to enable it a lot faster.
> >
> > This is the *only* real piece of evidence we have, let's not assume we
> > know better.
> >
> > > > and selecting those doesn't do anything, and people can even think
> > > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > > shows up.
> > >
> > > It is hard to comment on individual experiments. In the past, our
> > > Kconfig system were like that: written for technical people with
> > > background on computer engineering and some experience building the
> > > Kernel.
> > >
> > > E.g. people that knows that "/" activates a search mechanism at
> > > the Kernel building system.
> > >
> > > We usually had to spend *a lot of time* both on IRC and on e-mail
> > > explaining people that just want to have their card supported,
> > > how to do that. After the reorg (with added those more user-faced
> > > interfaces), the number of people with problems reduced a lot.
> >
> > Don't you think that could come mainly from better support for media
> > devices in distributions ?
> >
> > > Btw, if one tries to compile from media-build (with lots of users
> > > do), this is even more relevant.
> >
> > Can you quantify "lots of users" ?
>
> Enough to make us to decide that re-working the Kconfig menus and
> add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
> efforts.
>
> Guess what? The efforts were fully paid, as it reduced a lot the
> amount of time we had to weekly spend helping people to build their
> Kernels in order to test support for their new hardware.
>
> It also helped a lot to set the right Kconfig options on distros.
> I did my contributions on that time by improving Fedora and on RHEL,
> making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
>
> See, for some random distro maintainer, new Kconfig symbols pops up
> every time. Enabling all of them is usually a very bad idea. So, a
> filtering mechanism that would, for example, hide test and skeleton
> drivers to be built is a very nice feat, as it means a lot less
> symbols for them to study and decide whether such new options should
> be enabled or not
The fact that test drivers are not shipped by some distros is annoying
for developers ;-) But that's a very small minority, and out of topic.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 10:13 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-26 10:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, Fabio Estevam, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Hi Mauro,
On Thu, Mar 26, 2020 at 09:28:32AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart escreveu:
> > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > > That's the second part of media Kconfig changes. The entire series is
> > > > > at:
> > > > >
> > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > > >
> > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > > >
> > > > === Start of experiment:
> > > >
> > > > * He pressed '/' and searched for vimc to see the location path.
> > > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > > * He went back to "Media device types" again and start re-reading the options.
> > > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > > * He selects "Virtual Media Controller Driver".
> > > >
> > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > > to combine "Test drivers" with "Cameras and video grabbers".
> > > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > > >
> > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > > realized by himself until that moment, nor tried it out to see what would happen).
> > > >
> > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> > >
> > > That's easy to solve: all it needs is to add something similar
> > > to this at drivers/media/Kconfig:
> > >
> > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > > + visible if MEDIA_SUPPORT_FILTER
> > > +
> > > + comment "All available drivers are shown below"
> > > + visible if !MEDIA_SUPPORT_FILTER
> > > +
> > > menu "Media drivers"
> > >
> > > source "drivers/media/usb/Kconfig"
> > >
> > > > === End of experiment
> > > >
> > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > > kernel development (kernel dev newbies for instance).
> > > >
> > > > Just another remark from me:
> > > >
> > > > From the default config, "Media drivers" shows USB and PCI,
> > >
> > > Well, assuming that there are 2 billion computers, 1% with Linux
> > > installed, and 10% of them have a media device (camera or TV),
> > > we have about 2 millions of people running Linux. That excludes
> > > Android and Embedded devices, where people usually don't touch.
> > >
> > > During an entire year, there are about 4000 of Kernel developers
> > > that has at least one patch accepted upstream (this number
> > > includes developers for Android and other SoCs). Also, the
> > > number of Kernel developers submitting patches upstream for the
> > > media subsystem is around 20-40 people along an year.
> >
> > $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> > 215
> >
> > There's some duplication of e-mail addresses, but it's still roughly an
> > order or magnitude bigger (and it's not counting staging, headers or
> > documentation).
> >
> > > So, about 99,9998% of the users using the media subsystems aren't
> > > Kernel hackers. I bet that almost all of those will either need
> > > to enable USB or a PCI driver.
> >
> > And the extremely vast majority of these will never enable a kernel
> > option because they will never compile a kernel. They don't even know
> > what a kernel is :-)
> >
> > > Granted, 99,9998% seems too optimistic, but, assuming that this
> > > would reduce to something like 80% (e. g. only 200 users
> > > would ever try to build a media driver, with is a *very conservative*
> > > number) this is still a lot more than the number of media Kernel
> > > developers.
> > >
> > > Also, a Kernel hacker will sooner or later find a way to enable it.
> > > A normal user may find it a lot more trickier and will very likely
> > > require more support, if the menus are too technical and the
> > > default options are wrong.
> >
> > I'm not sure to follow you. Are you implying that this patch series,
> > which Helen has tested against a real user, not an experienced kernel
> > hacker, may make the configuration options more difficult for kernel
> > hackers, but improves the situation for users ?
>
> Come on, it is not harder for Kernel hackers. It is just different than
> what it used to be before the changes.
Sorry, I didn't meant to say it would be more complex for me (I mostly
don't use menuconfig anyway, I edit the .config file manually :-)), but
I was reading your e-mail as implying that, and was wondering if it was
me misreading it.
> At the above experience, at the
> very first time this Kernel hacker looked on it, it was able to figure
> out how to enable the driver. I bet that, if you now repeat the experiment
> with the same guy, he would be able to enable another driver a lot quicker.
>
> My view is that, with the option of either enable or disable the
> filtering mechanism, it will be easier for everybody:
>
> - Distro maintainers for PCs can just disable platform and
> test drivers, and keep the other drivers enabled;
>
> - An experienced Kernel hacker will disable the filter and select
> the needed drivers directly.
>
> - An user wanting to test a driver with new patches (or a new driver)
> use the filters to select the USB driver he needs (probably using the
> media_tree.git, in order to see only the media options).
My personal view is that this makes things more complex, and more
complexity usually means less clarity. If we want to be serious about
the usability of our Kconfig menu, we should get real users involved in
the design, at least by testing it on them, and getting feedback.
Otherwise we'll just be a bunch of kernel developers sitting in our
ivory tower thinking we know better than our users what is good for
them.
> > > -
> > >
> > > Even with that, based on your small experiment (of someone from the
> > > area), I suspect that, if you had asked him to enable, for example,
> > > em28xx or dvbsky (with are some of the most popular drivers
> > > those days), he would be able to enable it a lot faster.
> >
> > This is the *only* real piece of evidence we have, let's not assume we
> > know better.
> >
> > > > and selecting those doesn't do anything, and people can even think
> > > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > > shows up.
> > >
> > > It is hard to comment on individual experiments. In the past, our
> > > Kconfig system were like that: written for technical people with
> > > background on computer engineering and some experience building the
> > > Kernel.
> > >
> > > E.g. people that knows that "/" activates a search mechanism at
> > > the Kernel building system.
> > >
> > > We usually had to spend *a lot of time* both on IRC and on e-mail
> > > explaining people that just want to have their card supported,
> > > how to do that. After the reorg (with added those more user-faced
> > > interfaces), the number of people with problems reduced a lot.
> >
> > Don't you think that could come mainly from better support for media
> > devices in distributions ?
> >
> > > Btw, if one tries to compile from media-build (with lots of users
> > > do), this is even more relevant.
> >
> > Can you quantify "lots of users" ?
>
> Enough to make us to decide that re-working the Kconfig menus and
> add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
> efforts.
>
> Guess what? The efforts were fully paid, as it reduced a lot the
> amount of time we had to weekly spend helping people to build their
> Kernels in order to test support for their new hardware.
>
> It also helped a lot to set the right Kconfig options on distros.
> I did my contributions on that time by improving Fedora and on RHEL,
> making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
>
> See, for some random distro maintainer, new Kconfig symbols pops up
> every time. Enabling all of them is usually a very bad idea. So, a
> filtering mechanism that would, for example, hide test and skeleton
> drivers to be built is a very nice feat, as it means a lot less
> symbols for them to study and decide whether such new options should
> be enabled or not
The fact that test drivers are not shipped by some distros is annoying
for developers ;-) But that's a very small minority, and out of topic.
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 10:13 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-03-26 10:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Hi Mauro,
On Thu, Mar 26, 2020 at 09:28:32AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart escreveu:
> > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > > > That's the second part of media Kconfig changes. The entire series is
> > > > > at:
> > > > >
> > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> > > >
> > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > > > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > > > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > > >
> > > > === Start of experiment:
> > > >
> > > > * He pressed '/' and searched for vimc to see the location path.
> > > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > > > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > > > * He went back to "Media device types" again and start re-reading the options.
> > > > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > > > * He sees "V4L test drivers", selects it, and enter this menu.
> > > > * He selects "Virtual Media Controller Driver".
> > > >
> > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > > > to combine "Test drivers" with "Cameras and video grabbers".
> > > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > > >
> > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > > > realized by himself until that moment, nor tried it out to see what would happen).
> > > >
> > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> > >
> > > That's easy to solve: all it needs is to add something similar
> > > to this at drivers/media/Kconfig:
> > >
> > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> > > + visible if MEDIA_SUPPORT_FILTER
> > > +
> > > + comment "All available drivers are shown below"
> > > + visible if !MEDIA_SUPPORT_FILTER
> > > +
> > > menu "Media drivers"
> > >
> > > source "drivers/media/usb/Kconfig"
> > >
> > > > === End of experiment
> > > >
> > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > > > kernel development (kernel dev newbies for instance).
> > > >
> > > > Just another remark from me:
> > > >
> > > > From the default config, "Media drivers" shows USB and PCI,
> > >
> > > Well, assuming that there are 2 billion computers, 1% with Linux
> > > installed, and 10% of them have a media device (camera or TV),
> > > we have about 2 millions of people running Linux. That excludes
> > > Android and Embedded devices, where people usually don't touch.
> > >
> > > During an entire year, there are about 4000 of Kernel developers
> > > that has at least one patch accepted upstream (this number
> > > includes developers for Android and other SoCs). Also, the
> > > number of Kernel developers submitting patches upstream for the
> > > media subsystem is around 20-40 people along an year.
> >
> > $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l
> > 215
> >
> > There's some duplication of e-mail addresses, but it's still roughly an
> > order or magnitude bigger (and it's not counting staging, headers or
> > documentation).
> >
> > > So, about 99,9998% of the users using the media subsystems aren't
> > > Kernel hackers. I bet that almost all of those will either need
> > > to enable USB or a PCI driver.
> >
> > And the extremely vast majority of these will never enable a kernel
> > option because they will never compile a kernel. They don't even know
> > what a kernel is :-)
> >
> > > Granted, 99,9998% seems too optimistic, but, assuming that this
> > > would reduce to something like 80% (e. g. only 200 users
> > > would ever try to build a media driver, with is a *very conservative*
> > > number) this is still a lot more than the number of media Kernel
> > > developers.
> > >
> > > Also, a Kernel hacker will sooner or later find a way to enable it.
> > > A normal user may find it a lot more trickier and will very likely
> > > require more support, if the menus are too technical and the
> > > default options are wrong.
> >
> > I'm not sure to follow you. Are you implying that this patch series,
> > which Helen has tested against a real user, not an experienced kernel
> > hacker, may make the configuration options more difficult for kernel
> > hackers, but improves the situation for users ?
>
> Come on, it is not harder for Kernel hackers. It is just different than
> what it used to be before the changes.
Sorry, I didn't meant to say it would be more complex for me (I mostly
don't use menuconfig anyway, I edit the .config file manually :-)), but
I was reading your e-mail as implying that, and was wondering if it was
me misreading it.
> At the above experience, at the
> very first time this Kernel hacker looked on it, it was able to figure
> out how to enable the driver. I bet that, if you now repeat the experiment
> with the same guy, he would be able to enable another driver a lot quicker.
>
> My view is that, with the option of either enable or disable the
> filtering mechanism, it will be easier for everybody:
>
> - Distro maintainers for PCs can just disable platform and
> test drivers, and keep the other drivers enabled;
>
> - An experienced Kernel hacker will disable the filter and select
> the needed drivers directly.
>
> - An user wanting to test a driver with new patches (or a new driver)
> use the filters to select the USB driver he needs (probably using the
> media_tree.git, in order to see only the media options).
My personal view is that this makes things more complex, and more
complexity usually means less clarity. If we want to be serious about
the usability of our Kconfig menu, we should get real users involved in
the design, at least by testing it on them, and getting feedback.
Otherwise we'll just be a bunch of kernel developers sitting in our
ivory tower thinking we know better than our users what is good for
them.
> > > -
> > >
> > > Even with that, based on your small experiment (of someone from the
> > > area), I suspect that, if you had asked him to enable, for example,
> > > em28xx or dvbsky (with are some of the most popular drivers
> > > those days), he would be able to enable it a lot faster.
> >
> > This is the *only* real piece of evidence we have, let's not assume we
> > know better.
> >
> > > > and selecting those doesn't do anything, and people can even think
> > > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > > > shows up.
> > >
> > > It is hard to comment on individual experiments. In the past, our
> > > Kconfig system were like that: written for technical people with
> > > background on computer engineering and some experience building the
> > > Kernel.
> > >
> > > E.g. people that knows that "/" activates a search mechanism at
> > > the Kernel building system.
> > >
> > > We usually had to spend *a lot of time* both on IRC and on e-mail
> > > explaining people that just want to have their card supported,
> > > how to do that. After the reorg (with added those more user-faced
> > > interfaces), the number of people with problems reduced a lot.
> >
> > Don't you think that could come mainly from better support for media
> > devices in distributions ?
> >
> > > Btw, if one tries to compile from media-build (with lots of users
> > > do), this is even more relevant.
> >
> > Can you quantify "lots of users" ?
>
> Enough to make us to decide that re-working the Kconfig menus and
> add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the
> efforts.
>
> Guess what? The efforts were fully paid, as it reduced a lot the
> amount of time we had to weekly spend helping people to build their
> Kernels in order to test support for their new hardware.
>
> It also helped a lot to set the right Kconfig options on distros.
> I did my contributions on that time by improving Fedora and on RHEL,
> making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT.
>
> See, for some random distro maintainer, new Kconfig symbols pops up
> every time. Enabling all of them is usually a very bad idea. So, a
> filtering mechanism that would, for example, hide test and skeleton
> drivers to be built is a very nice feat, as it means a lot less
> symbols for them to study and decide whether such new options should
> be enabled or not
The fact that test drivers are not shipped by some distros is annoying
for developers ;-) But that's a very small minority, and out of topic.
--
Regards,
Laurent Pinchart
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-26 10:13 ` Laurent Pinchart
(?)
@ 2020-03-26 12:51 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 12:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Helen Koike, Linux Media Mailing List, Ezequiel Garcia,
Ludovic Desroches, Shawn Guo, Sascha Hauer, Chen-Yu Tsai,
Nicolas Ferre, linux-renesas-soc, Yong Deng, Kukjin Kim,
Michal Simek, Pavel Machek, Paul Kocialkowski, Yong Zhi,
linux-samsung-soc, Fabio Estevam, Hyun Kwon,
Pengutronix Kernel Team, Hans Verkuil, Krzysztof Kozlowski,
Sakari Ailus, Sylwester Nawrocki, Kyungmin Park, NXP Linux Team,
Heungjun Kim, linux-arm-kernel, Maxime Ripard, devel, Bingbu Cao,
Lad, Prabhakar, Alexandre Belloni, Philipp Zabel,
Steve Longerbeam, Greg Kroah-Hartman, Tian Shu Qiu,
Niklas Söderlund
Em Thu, 26 Mar 2020 12:13:33 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > > I'm not sure to follow you. Are you implying that this patch series,
> > > which Helen has tested against a real user, not an experienced kernel
> > > hacker, may make the configuration options more difficult for kernel
> > > hackers, but improves the situation for users ?
> >
> > Come on, it is not harder for Kernel hackers. It is just different than
> > what it used to be before the changes.
>
> Sorry, I didn't meant to say it would be more complex for me (I mostly
> don't use menuconfig anyway, I edit the .config file manually :-)), but
> I was reading your e-mail as implying that, and was wondering if it was
> me misreading it.
So, the new design will be less complex for you, as some dependencies were
changed to be automatically set when a driver is selected (media controller
and V4L2 subdev APIs) ;-)
>
> > At the above experience, at the
> > very first time this Kernel hacker looked on it, it was able to figure
> > out how to enable the driver. I bet that, if you now repeat the experiment
> > with the same guy, he would be able to enable another driver a lot quicker.
> >
> > My view is that, with the option of either enable or disable the
> > filtering mechanism, it will be easier for everybody:
> >
> > - Distro maintainers for PCs can just disable platform and
> > test drivers, and keep the other drivers enabled;
> >
> > - An experienced Kernel hacker will disable the filter and select
> > the needed drivers directly.
> >
> > - An user wanting to test a driver with new patches (or a new driver)
> > use the filters to select the USB driver he needs (probably using the
> > media_tree.git, in order to see only the media options).
>
> My personal view is that this makes things more complex, and more
> complexity usually means less clarity. If we want to be serious about
> the usability of our Kconfig menu, we should get real users involved in
> the design, at least by testing it on them, and getting feedback.
> Otherwise we'll just be a bunch of kernel developers sitting in our
> ivory tower thinking we know better than our users what is good for
> them.
The entire thing started by a proposal to change, in a way that it
would be make things easier for m2m developers but harder for
normal users.
My proposal is to keep both behaviors, with a menu that would
allow switching between those two different behaviors.
So, it should make both groups happy :-)
Not much complexity added. It is the other way around: I took the
time to do several Kconfig cleanups, in order to make the Kconfig
files cleaner and better organized (both internally and visually).
-
I don't object getting feedback from real users, but if we're
willing to use such feedback in a consistent way, we need to have
a group of people that could statistically represent the diversity
that we have with the people which builds their own kernels.
> > See, for some random distro maintainer, new Kconfig symbols pops up
> > every time. Enabling all of them is usually a very bad idea. So, a
> > filtering mechanism that would, for example, hide test and skeleton
> > drivers to be built is a very nice feat, as it means a lot less
> > symbols for them to study and decide whether such new options should
> > be enabled or not
>
> The fact that test drivers are not shipped by some distros is annoying
> for developers ;-) But that's a very small minority, and out of topic.
Yes, agreed. Things could be easier for us if we could ask people
to use a test driver when reporting certain bugs.
On the other hand, having a test driver shipped by default together
with a production Kernel don't make any sense for most usages. It
would just make the Kernel package bigger and would never be used
by the vast majority of users. It would also mean more work for
security people that would be trying to do OS hardening.
Well, Fedora has a kernel-debug Kernel, meant to be used
when someone finds an issue on production and may require extra stuff
to debug the Kernel. IMHO, it makes a lot of sense to have those test
drivers shipped there (perhaps packaged in separate, like on a
kernel-debug-media-test rpm).
Thanks,
Mauro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 12:51 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 12:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, Fabio Estevam, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Em Thu, 26 Mar 2020 12:13:33 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > > I'm not sure to follow you. Are you implying that this patch series,
> > > which Helen has tested against a real user, not an experienced kernel
> > > hacker, may make the configuration options more difficult for kernel
> > > hackers, but improves the situation for users ?
> >
> > Come on, it is not harder for Kernel hackers. It is just different than
> > what it used to be before the changes.
>
> Sorry, I didn't meant to say it would be more complex for me (I mostly
> don't use menuconfig anyway, I edit the .config file manually :-)), but
> I was reading your e-mail as implying that, and was wondering if it was
> me misreading it.
So, the new design will be less complex for you, as some dependencies were
changed to be automatically set when a driver is selected (media controller
and V4L2 subdev APIs) ;-)
>
> > At the above experience, at the
> > very first time this Kernel hacker looked on it, it was able to figure
> > out how to enable the driver. I bet that, if you now repeat the experiment
> > with the same guy, he would be able to enable another driver a lot quicker.
> >
> > My view is that, with the option of either enable or disable the
> > filtering mechanism, it will be easier for everybody:
> >
> > - Distro maintainers for PCs can just disable platform and
> > test drivers, and keep the other drivers enabled;
> >
> > - An experienced Kernel hacker will disable the filter and select
> > the needed drivers directly.
> >
> > - An user wanting to test a driver with new patches (or a new driver)
> > use the filters to select the USB driver he needs (probably using the
> > media_tree.git, in order to see only the media options).
>
> My personal view is that this makes things more complex, and more
> complexity usually means less clarity. If we want to be serious about
> the usability of our Kconfig menu, we should get real users involved in
> the design, at least by testing it on them, and getting feedback.
> Otherwise we'll just be a bunch of kernel developers sitting in our
> ivory tower thinking we know better than our users what is good for
> them.
The entire thing started by a proposal to change, in a way that it
would be make things easier for m2m developers but harder for
normal users.
My proposal is to keep both behaviors, with a menu that would
allow switching between those two different behaviors.
So, it should make both groups happy :-)
Not much complexity added. It is the other way around: I took the
time to do several Kconfig cleanups, in order to make the Kconfig
files cleaner and better organized (both internally and visually).
-
I don't object getting feedback from real users, but if we're
willing to use such feedback in a consistent way, we need to have
a group of people that could statistically represent the diversity
that we have with the people which builds their own kernels.
> > See, for some random distro maintainer, new Kconfig symbols pops up
> > every time. Enabling all of them is usually a very bad idea. So, a
> > filtering mechanism that would, for example, hide test and skeleton
> > drivers to be built is a very nice feat, as it means a lot less
> > symbols for them to study and decide whether such new options should
> > be enabled or not
>
> The fact that test drivers are not shipped by some distros is annoying
> for developers ;-) But that's a very small minority, and out of topic.
Yes, agreed. Things could be easier for us if we could ask people
to use a test driver when reporting certain bugs.
On the other hand, having a test driver shipped by default together
with a production Kernel don't make any sense for most usages. It
would just make the Kernel package bigger and would never be used
by the vast majority of users. It would also mean more work for
security people that would be trying to do OS hardening.
Well, Fedora has a kernel-debug Kernel, meant to be used
when someone finds an issue on production and may require extra stuff
to debug the Kernel. IMHO, it makes a lot of sense to have those test
drivers shipped there (perhaps packaged in separate, like on a
kernel-debug-media-test rpm).
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-03-26 12:51 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 12:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Pavel Machek, devel, linux-renesas-soc,
linux-samsung-soc, Chen-Yu Tsai, Krzysztof Kozlowski,
Ludovic Desroches, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Helen Koike,
Yong Deng, Ezequiel Garcia, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Linux Media Mailing List, Shawn Guo
Em Thu, 26 Mar 2020 12:13:33 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > > I'm not sure to follow you. Are you implying that this patch series,
> > > which Helen has tested against a real user, not an experienced kernel
> > > hacker, may make the configuration options more difficult for kernel
> > > hackers, but improves the situation for users ?
> >
> > Come on, it is not harder for Kernel hackers. It is just different than
> > what it used to be before the changes.
>
> Sorry, I didn't meant to say it would be more complex for me (I mostly
> don't use menuconfig anyway, I edit the .config file manually :-)), but
> I was reading your e-mail as implying that, and was wondering if it was
> me misreading it.
So, the new design will be less complex for you, as some dependencies were
changed to be automatically set when a driver is selected (media controller
and V4L2 subdev APIs) ;-)
>
> > At the above experience, at the
> > very first time this Kernel hacker looked on it, it was able to figure
> > out how to enable the driver. I bet that, if you now repeat the experiment
> > with the same guy, he would be able to enable another driver a lot quicker.
> >
> > My view is that, with the option of either enable or disable the
> > filtering mechanism, it will be easier for everybody:
> >
> > - Distro maintainers for PCs can just disable platform and
> > test drivers, and keep the other drivers enabled;
> >
> > - An experienced Kernel hacker will disable the filter and select
> > the needed drivers directly.
> >
> > - An user wanting to test a driver with new patches (or a new driver)
> > use the filters to select the USB driver he needs (probably using the
> > media_tree.git, in order to see only the media options).
>
> My personal view is that this makes things more complex, and more
> complexity usually means less clarity. If we want to be serious about
> the usability of our Kconfig menu, we should get real users involved in
> the design, at least by testing it on them, and getting feedback.
> Otherwise we'll just be a bunch of kernel developers sitting in our
> ivory tower thinking we know better than our users what is good for
> them.
The entire thing started by a proposal to change, in a way that it
would be make things easier for m2m developers but harder for
normal users.
My proposal is to keep both behaviors, with a menu that would
allow switching between those two different behaviors.
So, it should make both groups happy :-)
Not much complexity added. It is the other way around: I took the
time to do several Kconfig cleanups, in order to make the Kconfig
files cleaner and better organized (both internally and visually).
-
I don't object getting feedback from real users, but if we're
willing to use such feedback in a consistent way, we need to have
a group of people that could statistically represent the diversity
that we have with the people which builds their own kernels.
> > See, for some random distro maintainer, new Kconfig symbols pops up
> > every time. Enabling all of them is usually a very bad idea. So, a
> > filtering mechanism that would, for example, hide test and skeleton
> > drivers to be built is a very nice feat, as it means a lot less
> > symbols for them to study and decide whether such new options should
> > be enabled or not
>
> The fact that test drivers are not shipped by some distros is annoying
> for developers ;-) But that's a very small minority, and out of topic.
Yes, agreed. Things could be easier for us if we could ask people
to use a test driver when reporting certain bugs.
On the other hand, having a test driver shipped by default together
with a production Kernel don't make any sense for most usages. It
would just make the Kernel package bigger and would never be used
by the vast majority of users. It would also mean more work for
security people that would be trying to do OS hardening.
Well, Fedora has a kernel-debug Kernel, meant to be used
when someone finds an issue on production and may require extra stuff
to debug the Kernel. IMHO, it makes a lot of sense to have those test
drivers shipped there (perhaps packaged in separate, like on a
kernel-debug-media-test rpm).
Thanks,
Mauro
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 19:36 ` Helen Koike
` (2 preceding siblings ...)
(?)
@ 2020-03-26 16:07 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-03-26 16:07 UTC (permalink / raw)
To: Helen Koike, linux-media
(removed that big c/c list - kept just media)
Em Wed, 25 Mar 2020 16:36:31 -0300
Helen Koike <helen.koike@collabora.com> escreveu:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> He knows that Vimc is a virtual camera driver, and this is how he behaved:
>
> === Start of experiment:
>
> * He pressed '/' and searched for vimc to see the location path.
> * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
There was an issue with test driver dependencies. this patch
fixes it:
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=media-kconfig&id=c267c23e0884172beac4fb4e68c35fc26ff2e615
Basically, the VIDEO_DEV was not selected with MEDIA_TEST_SUPPORT.
So, the "Media drivers" menu would be empty.
After this change, the only thing a .config file would need to build
a test driver would either need to select those:
CONFIG_MODULES=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_SUPPORT_FILTER=y
CONFIG_MEDIA_TEST_SUPPORT=y
CONFIG_V4L_TEST_DRIVERS=y
CONFIG_VIDEO_VIMC=y
(filtering way)
or those:
CONFIG_MODULES=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_VIDEO_DEV=y
CONFIG_MEDIA_TEST_SUPPORT=y
CONFIG_V4L_TEST_DRIVERS=y
CONFIG_VIDEO_VIMC=y
(non-filtering way)
(MODULES config is optional. I opted to use modules just to be able
to use make M=drivers/media)
For testing purposes, here, I stored just the above on a file
called media_config, and then I did:
$ make allnoconfig
$ cp media_config >.config
$ make olddefconfig && make init 2>/dev/null
$ rm $(find drivers/media -name '*.ko') $(find drivers/media -name '*.o') 2>/dev/null
$ make M=drivers/media
CC [M] drivers/media/common/v4l2-tpg/v4l2-tpg-core.o
CC [M] drivers/media/common/videobuf2/videobuf2-core.o
...
MODPOST 8 modules
...
LD [M] drivers/media/v4l2-core/v4l2-dv-timings.ko
LD [M] drivers/media/v4l2-core/videodev.ko
In this specific case, either using the filtered or non-filtered way,
the number of options to enable "vimc" are the same.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-03-25 19:36 ` Helen Koike
(?)
@ 2020-04-01 10:59 ` Dan Carpenter
-1 siblings, 0 replies; 34+ messages in thread
From: Dan Carpenter @ 2020-04-01 10:59 UTC (permalink / raw)
To: Helen Koike
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Alexandre Belloni, Sylwester Nawrocki, Michal Simek, Lad,
Prabhakar, Laurent Pinchart, Pavel Machek, devel,
linux-renesas-soc, linux-samsung-soc, Ludovic Desroches,
Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim, NXP Linux Team,
Steve Longerbeam, Bingbu Cao, Tian Shu Qiu, Yong Zhi,
Philipp Zabel, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Niklas Söderlund, Yong Deng, Ezequiel Garcia,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Nicolas Ferre,
Paul Kocialkowski, Kyungmin Park, Pengutronix Kernel Team,
Greg Kroah-Hartman, Hans Verkuil, Shawn Guo
On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works
> with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
The whole config system is really outdated.
It should be that this task was done with a command like "kconfig enable
vimc". It would ask necessary questions and pull in the dependencies
automatically.
Twenty years ago it made sense to go through the menus and select things
one by one. Does anyone really start from defconfig any more? Surely
everyone starts with a known working config and just enables specific
options.
I started to hack together some code to create a kconfig program to
enable and disable options. The problem is that all library code
assumes we want to display menus so it was a lot of work and I gave up.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-04-01 10:59 ` Dan Carpenter
0 siblings, 0 replies; 34+ messages in thread
From: Dan Carpenter @ 2020-04-01 10:59 UTC (permalink / raw)
To: Helen Koike
Cc: Alexandre Belloni, Sylwester Nawrocki, Lad, Prabhakar,
Laurent Pinchart, Pavel Machek, devel, Paul Kocialkowski,
linux-samsung-soc, Mauro Carvalho Chehab, Michal Simek,
Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Hans Verkuil, Yong Deng, Chen-Yu Tsai, Ezequiel Garcia,
Pengutronix Kernel Team, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, linux-renesas-soc, Kyungmin Park, Philipp Zabel,
Greg Kroah-Hartman, Niklas Söderlund,
Linux Media Mailing List, Shawn Guo
On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works
> with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
The whole config system is really outdated.
It should be that this task was done with a command like "kconfig enable
vimc". It would ask necessary questions and pull in the dependencies
automatically.
Twenty years ago it made sense to go through the menus and select things
one by one. Does anyone really start from defconfig any more? Surely
everyone starts with a known working config and just enables specific
options.
I started to hack together some code to create a kconfig program to
enable and disable options. The problem is that all library code
assumes we want to display menus so it was a lot of work and I gave up.
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-04-01 10:59 ` Dan Carpenter
0 siblings, 0 replies; 34+ messages in thread
From: Dan Carpenter @ 2020-04-01 10:59 UTC (permalink / raw)
To: Helen Koike
Cc: Alexandre Belloni, Sylwester Nawrocki, Lad, Prabhakar,
Laurent Pinchart, Pavel Machek, devel, Paul Kocialkowski,
linux-samsung-soc, Mauro Carvalho Chehab, Michal Simek,
Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Sakari Ailus, Sascha Hauer, Maxime Ripard,
Hans Verkuil, Yong Deng, Chen-Yu Tsai, Ezequiel Garcia,
Pengutronix Kernel Team, linux-arm-kernel, Hyun Kwon,
Heungjun Kim, Nicolas Ferre, linux-renesas-soc, Kyungmin Park,
Philipp Zabel, Greg Kroah-Hartman, Niklas Söderlund,
Linux Media Mailing List, Shawn Guo
On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> Hello,
>
> On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > That's the second part of media Kconfig changes. The entire series is
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
>
> I made a quick experiment (using this branch) with someone who works
> with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> I asked him to enable Vimc (from default configs, where multimedia starts disabled).
The whole config system is really outdated.
It should be that this task was done with a command like "kconfig enable
vimc". It would ask necessary questions and pull in the dependencies
automatically.
Twenty years ago it made sense to go through the menus and select things
one by one. Does anyone really start from defconfig any more? Surely
everyone starts with a known working config and just enables specific
options.
I started to hack together some code to create a kconfig program to
enable and disable options. The problem is that all library code
assumes we want to display menus so it was a lot of work and I gave up.
regards,
dan carpenter
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
2020-04-01 10:59 ` Dan Carpenter
(?)
@ 2020-04-02 9:27 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-04-02 9:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: Helen Koike, Linux Media Mailing List, Alexandre Belloni,
Sylwester Nawrocki, Michal Simek, Lad, Prabhakar,
Laurent Pinchart, Pavel Machek, devel, linux-renesas-soc,
linux-samsung-soc, Ludovic Desroches, Krzysztof Kozlowski,
Chen-Yu Tsai, Kukjin Kim, NXP Linux Team, Steve Longerbeam,
Bingbu Cao, Tian Shu Qiu, Yong Zhi, Philipp Zabel, Sakari Ailus,
Sascha Hauer, Maxime Ripard, Niklas Söderlund, Yong Deng,
Ezequiel Garcia, linux-arm-kernel, Hyun Kwon, Heungjun Kim,
Nicolas Ferre, Paul Kocialkowski, Kyungmin Park,
Pengutronix Kernel Team, Greg Kroah-Hartman, Hans Verkuil,
Shawn Guo, Masahiro Yamada, linux-kbuild
Em Wed, 1 Apr 2020 13:59:49 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:
> On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> > Hello,
> >
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works
> > with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
>
> The whole config system is really outdated.
Agreed.
Btw, when compiled against Qt 5.14, "make xconfig" is currently
broken. I'm sending in a few some fixup patches for it.
> It should be that this task was done with a command like "kconfig enable
> vimc". It would ask necessary questions and pull in the dependencies
> automatically.
Yes. That's something that it is missing for a long time. There were
some efforts to add a SAT solver at the Kernel that could be used for
that, but I dunno what's current status.
> Twenty years ago it made sense to go through the menus and select things
> one by one. Does anyone really start from defconfig any more? Surely
> everyone starts with a known working config and just enables specific
> options.
Yeah, that's my feeling too.
> I started to hack together some code to create a kconfig program to
> enable and disable options. The problem is that all library code
> assumes we want to display menus so it was a lot of work and I gave up.
:-(
Thanks,
Mauro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-04-02 9:27 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-04-02 9:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alexandre Belloni, Sylwester Nawrocki, Lad, Prabhakar,
Laurent Pinchart, Pavel Machek, devel, Paul Kocialkowski,
linux-samsung-soc, Masahiro Yamada, Michal Simek,
Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Sakari Ailus, linux-kbuild, Sascha Hauer,
Maxime Ripard, Hans Verkuil, Helen Koike, Yong Deng,
Chen-Yu Tsai, Ezequiel Garcia, Pengutronix Kernel Team,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, linux-renesas-soc,
Kyungmin Park, Philipp Zabel, Greg Kroah-Hartman,
Niklas Söderlund, Linux Media Mailing List, Shawn Guo
Em Wed, 1 Apr 2020 13:59:49 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:
> On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> > Hello,
> >
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works
> > with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
>
> The whole config system is really outdated.
Agreed.
Btw, when compiled against Qt 5.14, "make xconfig" is currently
broken. I'm sending in a few some fixup patches for it.
> It should be that this task was done with a command like "kconfig enable
> vimc". It would ask necessary questions and pull in the dependencies
> automatically.
Yes. That's something that it is missing for a long time. There were
some efforts to add a SAT solver at the Kernel that could be used for
that, but I dunno what's current status.
> Twenty years ago it made sense to go through the menus and select things
> one by one. Does anyone really start from defconfig any more? Surely
> everyone starts with a known working config and just enables specific
> options.
Yeah, that's my feeling too.
> I started to hack together some code to create a kconfig program to
> enable and disable options. The problem is that all library code
> assumes we want to display menus so it was a lot of work and I gave up.
:-(
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2
@ 2020-04-02 9:27 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2020-04-02 9:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: Alexandre Belloni, Sylwester Nawrocki, Lad, Prabhakar,
Laurent Pinchart, Pavel Machek, devel, Paul Kocialkowski,
linux-samsung-soc, Masahiro Yamada, Michal Simek,
Krzysztof Kozlowski, Ludovic Desroches, Kukjin Kim,
NXP Linux Team, Steve Longerbeam, Bingbu Cao, Tian Shu Qiu,
Yong Zhi, Sakari Ailus, linux-kbuild, Sascha Hauer,
Maxime Ripard, Hans Verkuil, Helen Koike, Yong Deng,
Chen-Yu Tsai, Ezequiel Garcia, Pengutronix Kernel Team,
linux-arm-kernel, Hyun Kwon, Heungjun Kim, Nicolas Ferre,
linux-renesas-soc, Kyungmin Park, Philipp Zabel,
Greg Kroah-Hartman, Niklas Söderlund,
Linux Media Mailing List, Shawn Guo
Em Wed, 1 Apr 2020 13:59:49 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:
> On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote:
> > Hello,
> >
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > >
> > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig
> >
> > I made a quick experiment (using this branch) with someone who works
> > with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
>
> The whole config system is really outdated.
Agreed.
Btw, when compiled against Qt 5.14, "make xconfig" is currently
broken. I'm sending in a few some fixup patches for it.
> It should be that this task was done with a command like "kconfig enable
> vimc". It would ask necessary questions and pull in the dependencies
> automatically.
Yes. That's something that it is missing for a long time. There were
some efforts to add a SAT solver at the Kernel that could be used for
that, but I dunno what's current status.
> Twenty years ago it made sense to go through the menus and select things
> one by one. Does anyone really start from defconfig any more? Surely
> everyone starts with a known working config and just enables specific
> options.
Yeah, that's my feeling too.
> I started to hack together some code to create a kconfig program to
> enable and disable options. The problem is that all library code
> assumes we want to display menus so it was a lot of work and I gave up.
:-(
Thanks,
Mauro
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply [flat|nested] 34+ messages in thread