linux.git/drivers/staging/media/atomisp, branch v6.6

media: ipu-bridge: Fix Kconfig dependencies

2023-10-02T08:02:53+00:00

The current Kconfig symbol dependencies allow having the following Kconfig
symbol values

	CONFIG_IPU_BRIDGE=m
	CONFIG_VIDEO_IPU3_CIO2=y
	CONFIG_CIO2_BRIDGE=n

This does not work as the IPU bridge API is conditional to
IS_ENABLED(CONFIG_IPU_BRIDGE). Fix this by changing the dependencies so
that CONFIG_IPU_BRIDGE can be separately selected.

The CONFIG_CIO2_BRIDGE symbol becomes redundant as a result and is
removed.

Fixes: 2545a2c02ba1 ("media: ipu3-cio2: allow ipu_bridge to be a module again")
Suggested-by: Arnd Bergmann 
Signed-off-by: Sakari Ailus 
Signed-off-by: Hans Verkuil

media: atomisp: Drop atomisp-ov2680 sensor driver

2023-08-14T18:27:58+00:00

After recent improvements to atomisp and the standard ov2680
sensor driver, the atomisp driver now works fine with
the standard ov2680 driver.

Drop the no longer necessary atomisp specific atomisp-ov2680
sensor driver.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: csi2-bridge: Add support for VCM I2C-client instantiation

2023-08-10T05:58:41+00:00

Fill sensor->vcm_type and call intel_cio2_bridge_instantiate_vcm() from
the v4l2-async bound op so that an I2C-client will be instatiated for
the VCM.

Note unfortunately on atomisp the _DSM to get the VCM type sometimes
returns a VCM even though there is none. Since VCMs are typically only
used together with certain sensors, work around this by adding a vcm
field to atomisp_sensor_config and only check for a VCM when that is set.

Signed-off-by: Hans de Goede 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: csi2-bridge: Add dev_name() to acpi_handle_info() logging

2023-08-10T05:58:41+00:00

acpi_handle_info() uses the ACPI path to the handle as prefix for messages
e.g. : "\_SB_.I2C2.CAM8".

This makes it hard for users to figure out which csi2-bridge messages
belong to which sensor since the actual sensor drivers uses the ACPI
device name (typically "HID:00") for logging.

Extend the acpi_handle_info() (and err and warn) logging to also log
the device name to make it easier to match csi2-bridge messages with
sensor driver log messages.

Suggested-by: Sakari Ailus 
Signed-off-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: csi2-bridge: Switch to new common ipu_bridge_init()

2023-08-10T05:58:40+00:00

Remove the duplicate IPU ACPI bridge code and use the new
shared ipu_bridge_init() functionality.

Note this will also use / assume v4l2-async device instantiation for
ov5693 sensors on atomisp devices since ipu_supported_sensors[]
already contains a match for this.

This is fine since recent atomisp improvements allow the atomisp code
to work with generic v4l2 sensor drivers and using an unmodified
drivers/media/i2c/ov5693.c has been successfully tested on
an Acer Iconia W4 820 tablet with an ISP2400 + OV5693 sensor.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Daniel Scally 
Signed-off-by: Hans de Goede 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: ov2680: Convert to new CCI register access helpers

2023-08-10T05:58:39+00:00

Use the new comon CCI register access helpers to replace the private
register access helpers in the ov2680 driver.

While at it also switch to using the same register address defines
as the standard drivers/media/i2c/ov2680.c driver to make merging
the 2 drivers simpler.

Reviewed-by: Laurent Pinchart 
Signed-off-by: Hans de Goede 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: Fix me->stages error checking in sh_css_sp_init_pipeline()

2023-08-10T05:58:33+00:00

The current error-checking of me->stages in sh_css_sp_init_pipeline()
has some issues / weirdness:

1. It is checked at the top of the function, but only using the atomisp
   custom assert() macro which e.g. smatch does not recognize

2. It is first dereferenced in "first_binary = me->stages->binary", but
   outside of the assert it is checked much later, triggering the following
   smatch warning:

drivers/staging/media/atomisp/pci/sh_css_sp.c:1255 sh_css_sp_init_pipeline()
warn: variable dereferenced before check 'me->stages' (see line 1224)

Drop the custom assert() calls (note 'me' is never NULL) and instead add
a regular check for me->stages not being set.

Reported-by: Hans Verkuil 
Closes: https://lore.kernel.org/linux-media/7c8fc5b4-280e-844e-cdf5-b6ec2a1616aa@xs4all.nl/
Signed-off-by: Hans de Goede 
Signed-off-by: Hans Verkuil

media: atomisp: Fix smatch warnings caused by atomisp custom assert() usage

2023-08-10T05:58:32+00:00

The atomisp code base has a custom assert() macro, a couple of functions
use this in a construction like the following:

   assert(pipe);
   assert(pipe->stream);
   if ((!pipe) || (!pipe->stream)) {
           ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE_PRIVATE,
                               "allocate_mipi_frames(%p) exit: ...\n",
                               pipe);
           return -EINVAL;
   }

The second assert is seen by smatch as dereferencing "pipe" in the above
example (and dereferencing "dvs_6axis_config" in the other case).

Following by the dereferenced variable being checked (a second time)
in the following if () statement.

This triggers the following smatch warnings:
drivers/staging/media/atomisp/pci/sh_css_mipi.c:356 allocate_mipi_frames() warn: variable dereferenced before check 'pipe' (see line 355)
drivers/staging/media/atomisp/pci/sh_css_mipi.c:562 send_mipi_frames() warn: variable dereferenced before check 'pipe' (see line 561)
drivers/staging/media/atomisp/pci/sh_css_param_dvs.c:208 free_dvs_6axis_table() warn: variable dereferenced before check 'dvs_6axis_config' (see line 206)

The custom assert() macro actually expands to a BUG() call and BUG()
calls should not be used in the kernel.

Remove the assert() calls to fix the smatch warnings and in case of
[allocate|send]_mipi_frames() also remove the if () return -EINVAL
block since these functions are never called with a NULL pipe.

Reported-by: Hans Verkuil 
Signed-off-by: Hans de Goede 
Signed-off-by: Hans Verkuil

media: atomisp: Remove bogus asd == NULL checks

2023-08-10T05:58:32+00:00

The asd is a sub-structure of the main driver data struct, so it is
never NULL. Drop the unnecessary NULL checks in a couple of places.

Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/linux-media/533f6930-434a-45f3-afff-127003fa64c9@moroto.mountain/
Signed-off-by: Hans de Goede 
Signed-off-by: Hans Verkuil

media: v4l: async: Set v4l2_device and subdev in async notifier init

2023-08-10T05:58:32+00:00

Set the v4l2_device already in async notifier init, so struct device
related to it will be available before the notifier is registered. This
requires separating notifier initialisation into two functions, one that
takes v4l2_device as its argument, v4l2_async_nf_init and
v4l2_async_subdev_nf_init, for sub-device notifiers. Registering the
notifier will use a single function, v4l2_async_nf_register.

This is done in order to make struct device available earlier, during
construction of the async connections, for sensible debug prints.

Signed-off-by: Sakari Ailus 
Tested-by: Philipp Zabel  # imx6qp
Tested-by: Niklas Söderlund  # rcar + adv746x
Tested-by: Aishwarya Kothari  # Apalis i.MX6Q with TC358743
Tested-by: Lad Prabhakar  # Renesas RZ/G2L SMARC
Signed-off-by: Mauro Carvalho Chehab