user/sven/linux.git/include/media, branch v6.6.6

media: ipu-bridge: increase sensor_name size

2023-11-28T17:19:46Z

[ Upstream commit 83d0d4cc1423194b580356966107379490edd02e ] Fixes this compiler warning: In file included from include/linux/property.h:14, from include/linux/acpi.h:16, from drivers/media/pci/intel/ipu-bridge.c:4: In function 'ipu_bridge_init_swnode_names', inlined from 'ipu_bridge_create_connection_swnodes' at drivers/media/pci/intel/ipu-bridge.c:445:2, inlined from 'ipu_bridge_connect_sensor' at drivers/media/pci/intel/ipu-bridge.c:656:3: include/linux/fwnode.h:81:49: warning: '%u' directive output may be truncated writing between 1 and 3 bytes into a region of size 2 [-Wformat-truncation=] 81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u" | ^~~~~~~~~ drivers/media/pci/intel/ipu-bridge.c:384:18: note: in expansion of macro 'SWNODE_GRAPH_PORT_NAME_FMT' 384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/fwnode.h: In function 'ipu_bridge_connect_sensor': include/linux/fwnode.h:81:55: note: format string is defined here 81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u" | ^~ In function 'ipu_bridge_init_swnode_names', inlined from 'ipu_bridge_create_connection_swnodes' at drivers/media/pci/intel/ipu-bridge.c:445:2, inlined from 'ipu_bridge_connect_sensor' at drivers/media/pci/intel/ipu-bridge.c:656:3: include/linux/fwnode.h:81:49: note: directive argument in the range [0, 255] 81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u" | ^~~~~~~~~ drivers/media/pci/intel/ipu-bridge.c:384:18: note: in expansion of macro 'SWNODE_GRAPH_PORT_NAME_FMT' 384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/media/pci/intel/ipu-bridge.c:382:9: note: 'snprintf' output between 7 and 9 bytes into a destination of size 7 382 | snprintf(sensor->node_names.remote_port, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 383 | sizeof(sensor->node_names.remote_port), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Hans Verkuil Acked-by: Arnd Bergmann Signed-off-by: Sasha Levin

Merge tag 'media/v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2023-09-01T19:21:32Z

Pull media updates from Mauro Carvalho Chehab: - new i2c drivers: ds90ub913, ds90ub953, ds90ub960, dw9719, ds90ub913 - new Intel IVSC MEI drivers - some Mediatek platform drivers were moved to a common location - Intel atomisp2 driver is now working with the main ov2680 driver. Due to that, the atomisp2 ov2680 staging one was removed - the bttv driver was finally converted to videobuf2 framework. This was the last one upstream using videobuf version 1 core. We'll likely remove the old videobuf framework on 6.7 - lots of improvements at atomisp driver: it now works with normal I2C sensors. Several compile-mode dependecies to select between ISP2400 and ISP2401 are now solved in runtime - a new ipu-bridge logic was added to work with IVSC MEI drivers - venus driver gained better support for new VPU versions - the v4l core async framework has gained lots of improvements and cleanups - lots of other cleanups, improvements and driver fixes * tag 'media/v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (358 commits) media: ivsc: Add ACPI dependency media: bttv: convert to vb2 media: bttv: use audio defaults for winfast2000 media: bttv: refactor bttv_set_dma() media: bttv: move vbi_skip/vbi_count out of buffer media: bttv: remove crop info from bttv_buffer media: bttv: remove tvnorm field from bttv_buffer media: bttv: remove format field from bttv_buffer media: bttv: move do_crop flag out of bttv_fh media: bttv: copy vbi_fmt from bttv_fh media: bttv: copy vid fmt/width/height from fh media: bttv: radio use v4l2_fh instead of bttv_fh media: bttv: replace BUG with WARN_ON media: bttv: use video_drvdata to get bttv media: i2c: rdacm21: Fix uninitialized value media: coda: Remove duplicated include media: vivid: fix the racy dev->radio_tx_rds_owner media: i2c: ccs: Check rules is non-NULL media: i2c: ds90ub960: Fix PLL config for 1200 MHz CSI rate media: i2c: ds90ub953: Fix use of uninitialized variables ...

media: pci: intel: Add IVSC support for IPU bridge driver

2023-08-14T18:27:55Z

Previously on ACPI platforms, sensors that are intended to be connected to an IPU device for use with the ipu3-cio2 driver lacking the necessary connection information in firmware. IPU bridge driver is to connect sensors to IPU device via software nodes. Currently IVSC located between IPU device and sensors is available in existing commercial platforms from multiple OEMs. But the connection information between them in firmware is also not enough to build V4L2 connection graph. This patch parses the connection properties from the SSDB buffer in DSDT and build the connection using software nodes. IVSC driver is based on MEI framework (previously known as HECI), it has two MEI clients, MEI CSI and MEI ACE. Both clients are used to communicate messages with IVSC firmware. Linux abstracts MEI client as a device, whose bus type is MEI. And the device is addressed by a GUID/UUID which is part of the device name of MEI client. After figured out MEI CSI via the UUID composed device name, this patch setup the connection between MEI CSI and IPU, and the connection between MEI CSI and sensor via software nodes. Signed-off-by: Wentong Wu Reviewed-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu-bridge: Add a runtime-pm device-link between VCM and sensor

2023-08-10T05:58:40Z

In most cases when a VCM is used there is a single integrated module with the sensor + VCM + lens. This means that the sensor and VCM often share regulators and possibly also something like a powerdown pin. In the ACPI tables this is modelled as a single ACPI device with multiple I2cSerialBus resources. On atomisp devices the regulators and clks are modelled as ACPI power-resources, which are controlled by the (ACPI) power state of the sensor. So the sensor must be in D0 power state for the VCM to work. To make this work add a device-link with DL_FLAG_PM_RUNTIME flag so that the sensor will automatically be runtime-resumed whenever the VCM is runtime-resumed. This requires the probing of the VCM and thus the creation of the VCM I2C-client to be delayed till after the sensor driver has bound. Move the instantiation of the VCM I2C-client to the v4l2_async_notifier bound op, so that it is done after the sensor driver has bound; and add code to add the device-link. This fixes the problem with the shared ACPI power-resources on atomisp2 and this avoids the need for VCM related workarounds on IPU3 / IPU6. E.g. until now the dw9719 driver needed to get and control a Vsio (V sensor IO) regulator since that needs to be enabled to enable I2C pass-through on the PMIC on the sensor module. So the driver was controlling this regulator even though the actual dw9719 chip has no Vsio pin / power-plane. This also removes the need for ipu_bridge_init() to return -EPROBE_DEFER since the VCM is now instantiated later. Reviewed-by: Andy Shevchenko Reviewed-by: Daniel Scally Tested-by: Daniel Scally Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: ipu-bridge: Move ipu-bridge.h to include/media/

2023-08-10T05:58:40Z

Move ipu-bridge.h to include/media/, so that it can also be used by the atomisp code. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: Remove ov_16bit_addr_reg_helpers.h

2023-08-10T05:58:39Z

The helpers in this header are not used anywhere anymore, they have been superseded by the new CCI register access helpers. Reviewed-by: Laurent Pinchart Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: Add MIPI CCI register access helper functions

2023-08-10T05:58:38Z

The CSI2 specification specifies a standard method to access camera sensor registers called "Camera Control Interface (CCI)". This uses either 8 or 16 bit (big-endian wire order) register addresses and supports 8, 16, 24 or 32 bit (big-endian wire order) register widths. Currently a lot of Linux camera sensor drivers all have their own custom helpers for this, often copy and pasted from other drivers. Add a set of generic helpers for this so that all sensor drivers can switch to a single common implementation. These helpers take an extra optional "int *err" function parameter, this can be used to chain a bunch of register accesses together with only a single error check at the end, rather than needing to error check each individual register access. The first failing call will set the contents of err to a non 0 value and all other calls will then become no-ops. Link: https://lore.kernel.org/linux-media/59aefa7f-7bf9-6736-6040-39551329cd0a@redhat.com/ Reviewed-by: Andy Shevchenko Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: subdev: Constify v4l2_subdev_set_routing_with_fmt() param

2023-08-10T05:58:38Z

The routing parameter of v4l2_subdev_set_routing_with_fmt() is missing 'const'. Add it. Signed-off-by: Tomi Valkeinen Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: cec: core: add adap_unconfigured() callback

2023-08-10T05:58:32Z

The adap_configured() callback was called with the adap->lock mutex held if the 'configured' argument was false, and without the adap->lock mutex held if that argument was true. That was very confusing, and so split this up in a adap_unconfigured() callback and a high-level configured() callback. This also makes it easier to understand when the mutex is held: all low-level adap_* callbacks are called with the mutex held. All other callbacks are called without that mutex held. Signed-off-by: Hans Verkuil Fixes: f1b57164305d ("media: cec: add optional adap_configured callback") Signed-off-by: Mauro Carvalho Chehab

media: cec: core: add adap_nb_transmit_canceled() callback

2023-08-10T05:58:32Z

A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang Signed-off-by: Hans Verkuil Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab