linux-dev/drivers/media/pci/intel, branch master

media: drivers: use video device pipeline start/stop

2022-09-24T07:14:20Z

Convert the media drivers to use video device based pipeline start/stop where possible. Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: mc-entity: Rename media_entity_remote_pad() to media_pad_remote_pad_first()

2022-07-17T10:21:35Z

The media_entity_remote_pad() is misnamed, as it operates on a pad and not an entity. Rename it to media_pad_remote_pad_first() to clarify its behaviour. Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu3-cio2: Add INT347E to cio2-bridge

2022-05-17T07:52:18Z

The OVTI7251 sensor can be found on x86 laptops with an IPU3, and so needs to be supported by the cio2-bridge. Add it to the table of supported sensors. Signed-off-by: Daniel Scally Acked-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu3-cio2: Add support for V4L2_PIX_FMT_IPU3_Y10

2022-05-17T07:38:32Z

We have platforms where a camera sensor transmits Y10 data to the CIO2 device - add support for that (packed) format to the ipu3-cio2 driver. Signed-off-by: Daniel Scally Acked-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: v4l: ioctl: Set bus_info in v4l_querycap()

2022-04-24T07:07:08Z

The bus_info field is set by most drivers based on the type of the device bus as well as the name of the device. Do this in v4l_querycap() so drivers don't need to. This keeps compatibility with non-default and silly bus_info. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

media: mc: Set bus_info in media_device_init()

2022-04-24T07:05:53Z

Set bus_info field based on struct device in media_device_init() and remove corresponding code from drivers. Also update media_device_init() documentation: the dev field must be now initialised before calling it. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

media: Kconfig: cleanup VIDEO_DEV dependencies

2022-03-18T04:58:35Z

media Kconfig has two entries associated to V4L API: VIDEO_DEV and VIDEO_V4L2. On Kernel 2.6.x, there were two V4L APIs, each one with its own flag. VIDEO_DEV were meant to: 1) enable Video4Linux and make its Kconfig options to appear; 2) it makes the Kernel build the V4L core. while VIDEO_V4L2 where used to distinguish between drivers that implement the newer API and drivers that implemented the former one. With time, such meaning changed, specially after the removal of all V4L version 1 drivers. At the current implementation, VIDEO_DEV only does (1): it enables the media options related to V4L, that now has: menu "Video4Linux options" visible if VIDEO_DEV source "drivers/media/v4l2-core/Kconfig" endmenu but it doesn't affect anymore the V4L core drivers. The rationale is that the V4L2 core has a "soft" dependency at the I2C bus, and now requires to select a number of other Kconfig options: config VIDEO_V4L2 tristate depends on (I2C || I2C=n) && VIDEO_DEV select RATIONAL select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE default (I2C || I2C=n) && VIDEO_DEV In the past, merging them would be tricky, but it seems that it is now possible to merge those symbols, in order to simplify V4L dependencies. Let's keep VIDEO_DEV, as this one is used on some make *defconfig configurations. Suggested-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Reviewed-by: Neil Armstrong # for meson-vdec & meson-ge2d Acked-by: Andrzej Pietrasiewicz Acked-by: Łukasz Stelmach Signed-off-by: Mauro Carvalho Chehab

media: ipu3-cio2: Add support for instantiating i2c-clients for VCMs

2021-12-16T19:58:56Z

Some sensors come with a variable-focus lens where the lens focus is controller by a VCM (Voice Coil Motor). If there is a VCM for the lens-focus, and if so which one, is described on the vcm_type field of the ACPI SSDB table. These VCMs are a second I2C device listed as an extra I2cSerialBusV2 resource in the same ACPI device as the sensor. The i2c-core-acpi.c code only instantiates an i2c-client for the first I2cSerialBusV2 resource. Add support for instantiating an i2c-client for the VCM with the type of the i2c-client set based on the SSDB vcm_type field. Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu3-cio2: Call cio2_bridge_init() before anything else

2021-12-16T19:57:58Z

Since cio2_bridge_init() may now return -EPROBE_DEFER it is best to call it before anything else. Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu3-cio2: Defer probing until the PMIC is fully setup

2021-12-16T19:57:21Z

On devices where things are not fully describe in devicetree (1) and where the code thus falls back to calling cio2_bridge_init(), the i2c-clients for any VCMs also need to be instantiated manually. The VCM can be probed by its driver as soon as the code instantiates the i2c-client and this probing must not happen before the PMIC is fully setup. Make cio2_bridge_init() return -EPROBE_DEFER when the PMIC is not fully-setup, deferring the probe of the ipu3-cio2 driver. This is a preparation patch for adding VCM enumeration support to the ipu3-cio2-bridge code. 1) Through embedding of devicetree info in the ACPI tables Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab