* [PATCH 0/4] media Kconfig reorg - part 2 @ 2020-03-25 16:03 Mauro Carvalho Chehab 2020-03-25 16:03 ` [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC Mauro Carvalho Chehab 2020-03-25 19:36 ` [PATCH 0/4] media Kconfig reorg - part 2 Helen Koike 0 siblings, 2 replies; 10+ 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] 10+ messages in thread
* [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC 2020-03-25 16:03 [PATCH 0/4] media Kconfig reorg - part 2 Mauro Carvalho Chehab @ 2020-03-25 16:03 ` Mauro Carvalho Chehab 2020-03-25 19:36 ` [PATCH 0/4] media Kconfig reorg - part 2 Helen Koike 1 sibling, 0 replies; 10+ 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] 10+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2 2020-03-25 16:03 [PATCH 0/4] media Kconfig reorg - part 2 Mauro Carvalho Chehab 2020-03-25 16:03 ` [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC Mauro Carvalho Chehab @ 2020-03-25 19:36 ` Helen Koike 2020-03-25 21:38 ` Mauro Carvalho Chehab 2020-04-01 10:59 ` Dan Carpenter 1 sibling, 2 replies; 10+ 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] 10+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2 2020-03-25 19:36 ` [PATCH 0/4] media Kconfig reorg - part 2 Helen Koike @ 2020-03-25 21:38 ` Mauro Carvalho Chehab 2020-03-25 22:13 ` Laurent Pinchart 2020-04-01 10:59 ` Dan Carpenter 1 sibling, 1 reply; 10+ 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] 10+ 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 2020-03-26 8:28 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 10+ 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] 10+ 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 2020-03-26 10:13 ` Laurent Pinchart 0 siblings, 1 reply; 10+ 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] 10+ 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 2020-03-26 12:51 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 10+ 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] 10+ 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 0 siblings, 0 replies; 10+ 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] 10+ messages in thread
* Re: [PATCH 0/4] media Kconfig reorg - part 2 2020-03-25 19:36 ` [PATCH 0/4] media Kconfig reorg - part 2 Helen Koike 2020-03-25 21:38 ` Mauro Carvalho Chehab @ 2020-04-01 10:59 ` Dan Carpenter 2020-04-02 9:27 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 10+ 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] 10+ 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 0 siblings, 0 replies; 10+ 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] 10+ messages in thread
end of thread, other threads:[~2020-04-02 9:28 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-25 16:03 [PATCH 0/4] media Kconfig reorg - part 2 Mauro Carvalho Chehab 2020-03-25 16:03 ` [PATCH 2/4] media: Kconfig files: use select for V4L2 subdevs and MC Mauro Carvalho Chehab 2020-03-25 19:36 ` [PATCH 0/4] media Kconfig reorg - part 2 Helen Koike 2020-03-25 21:38 ` Mauro Carvalho Chehab 2020-03-25 22:13 ` Laurent Pinchart 2020-03-26 8:28 ` Mauro Carvalho Chehab 2020-03-26 10:13 ` Laurent Pinchart 2020-03-26 12:51 ` Mauro Carvalho Chehab 2020-04-01 10:59 ` Dan Carpenter 2020-04-02 9:27 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).