Testing the atomisp can be a bit tricky. The BYT/CHT CPUs are not
very powerful so some apps like camorama cannot run at full FPS.

Add instructions for how to test with gstreamer which does
runs at full FPS without issues.

Link: https://lore.kernel.org/r/20230604161406.69369-6-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

The data sheets say the registers at offset 0x3700 - 0x373f are
"sensor control" registers rename the unknown variable in
ov2680_set_mode() to sensor_ctrl_0a and add
a OV2680_REG_SENSOR_CTRL_0A define.

Link: https://lore.kernel.org/r/20230604161406.69369-5-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Many of the values in ov2680_global_setting[] match the default/reset
register value for the ov2680 sensor (verified with both datasheet
and actual hw) so they are no-ops.

And there are also a couple of others which are later overwritten
by ctrls or by ov2680_set_mode().

Remove all the unnecessary entries and add annotations to
the remaining entries documenting what they change
(in so far as things are documented in the datasheet).

This also removes the double writing of OV2680_REG_SOFT_RESET in
ov2680_init_registers() (one direct write, one in ov2680_global_setting[])
instead add a short sleep after the first write to give the sensor
time to reset.

Link: https://lore.kernel.org/r/20230604161406.69369-4-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Stop using half pixelclock for binned modes this fixes:
1. The exposure being twice as high for binned mods (due to the half clk)
2. The framerate being 15 fps instead of 30 fps

The original code with fixed per mode register lists did use half pixel
clk, but this should be combined with using half for the VTS value too.

Using half VTS fixes the framerate issue, but this has the undesired
side-effect of change the exposure ctrl range (half the range, double
the amount of exposure per step).

Link: https://lore.kernel.org/r/20230604161406.69369-3-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

No other V4L2 driver resets the selected input (front cam or back cam
selected in case of the atomisp).

Stop resetting selected input to 0 between /dev/video# opens.

This allows e.g. using v4l2-ctl -i to switch the input before starting
another app, which is useful since most apps don't support selecting
the input.

Note more in general the whole resetting of a bunch of internal
state from the open fop needs to be removed there to allow multiple
opens of /dev/video# for full v4l2 API compliance.

Link: https://lore.kernel.org/r/20230604161406.69369-2-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

The fmt / size passed to atomisp_set_crop() includes padding,
so the binning check should be against 1/2 of the native rect.
of the sensor, rather then 1/2 of the active rect.

This fixes binning not being used when using e.g. 800x600 on
a 1600x1200 sensor leading to a very small field of view.

Link: https://lore.kernel.org/r/20230601145858.59652-4-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Now that atomisp_get_padding() takes minimum padding requirements
on BYT/ISP2400 into account, it is possible for a resolution which
fits in the active area of the sensor to not fit in the native area
once padding is added.

For example on the ov2680 which has a native resolution of 1616x1216
the max active resolution of 1600x1200 leaves 16x16 for padding which
meets the worst-case minimum padding requirement of 14x14 on BYT.

But after binning we are left with an native area of 808x608 and
an active area of 800x600. This leaves 8x8 for padding which is not
enough. So on BYT 800x600 is not a valid resolution (it could be
made by lots of cropping without binning but then the remaining
field of view is no good).

Modify atomisp_enum_framesizes_crop() to check the resolution +
padding fits in the native rectangle, removing 800x600 from
the list of valid modes on BYT.

Link: https://lore.kernel.org/r/20230601145858.59652-3-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

The main binary for the pipeline on BYT/ISP2400 has its
ia_css_binary_info.pipeline.left_cropping and .top_cropping fields
set to 12. So a minimum padding of 12 is required.

And for certain bayer-orders additional width / height padding is
necessary so that the ISP crop rectangle for the raw sensor data
can be used to change the bayer-order to the fixed bayer-order
supported by the debayer block.

Without the minmum required padding ia_css_ifmtr_configure() will fail
inside ifmtr_input_start_line() and/or ifmtr_start_column() because
it cannot set the ISP crop rectangle for the raw sensor data.

Fix this by making atomisp_get_padding() take the minimum padding
requirements into account on BYT/ISP2400 (CHT/ISP2401 does not seem to
need this).

Link: https://lore.kernel.org/r/20230601145858.59652-2-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

The ACPI code takes care of enabling/disabling the PMC clk(s) for
the sensors as necessary based on the runtime-pm state of the sensor.

But the GMIN code this replaces also set the clk-rate of the PMC clk
to 19.2 MHz. At least on BYT devices the PMC clks may come up running
at 25 MHz instead of the expected 19.2 MHz.

Ensure the sensor clk also runs at the expected 19.2 MHz for sensors
using v4l2-async probing by explicitly setting it to 19.2 MHz when
enumerating sensors in atomisp_csi2_bridge.c.

Link: https://lore.kernel.org/r/20230529103741.11904-22-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Some sensor drivers with crop support (e.g. the ov5693 driver) only
return the current crop rectangle + 1/2 (binning) of the current crop
rectangle when calling their enum_frame_sizes op.

This causes 2 issues:
1. Atomisp sets to the crop area to include the padding, where as
   the enum_framesizes ioctl should return values without padding.

2. With cropping a lot more standard resolutions are possible then
   just these 2 and many apps limit the list given to the end user
   to the list returned by enum_framesizes.

Add an alternative enum_framesizes function for sensors which support
cropping to fix both issues.

Link: https://lore.kernel.org/r/20230529103741.11904-21-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Some drivers which implement selections/crop only allow setting the format
with and height to either the crop rectangle width and height or to half
the crop rectangle width and height (binning). An example of such
a driver is the standard v4l2 ov5693 driver.

First set the crop rectangle to match the requested format
when trying or setting the sensor format, to match these drivers
expectations.

Link: https://lore.kernel.org/r/20230529103741.11904-20-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Using the selection / crop info to determine the padding values
to use with a specific resolution on specific sensor.

This allows e.g. automatically halving the padding when using
the max binned resolution and also ensures the right amount
of padding is used on models with 2 sensors with different
padding requirements.

Link: https://lore.kernel.org/r/20230529103741.11904-19-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Make atomisp_init_sensor() check if the sensor supports binning.

This is a preparation patch for using the selection / crop support
to determine the padding values to use with a specific sensor.

Link: https://lore.kernel.org/r/20230529103741.11904-18-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

A sensor driver's enum_frame_size pad-op may return -EINVAL when
v4l2_subdev_frame_size_enum.code is not set to a supported
MEDIA_BUS_FMT_* code.

Make atomisp_init_sensor() get the sensor's MEDIA_BUS_FMT_* code and
pass this when calling the enum_frame_size pad-op.

Link: https://lore.kernel.org/r/20230529103741.11904-17-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Sensor drivers which implement set_selection V4L2_SEL_TGT_CROP expect
v4l2_subdev_state.pads[pad].try_crop to have valid contents when calling
set_fmt with which == V4L2_SUBDEV_FORMAT_TRY since the crop-rectangle
may influence the available image size.

Just passing an uninitalized struct v4l2_subdev_pad_config from
the stack to set_fmt with which == V4L2_SUBDEV_FORMAT_TRY will result
in wrong results with such drivers.

Store a per sensor v4l2_subdev_pad_config and add a new
atomisp_init_sensor_crop() function to initialize this before
registering /dev/* nodes with userspace.

Sensor drivers which implement the selection API will allow
the atomisp to properly deal with the extra padding the ISP wants
on a per sensor basis instead of hardcoding this.
atomisp_init_sensor_crop() stores the native and active rects
of the sensor in preparation for using these for this.

Link: https://lore.kernel.org/r/20230529103741.11904-16-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

There are a number of bugs in atomisp_try_fmt_cap() and atomisp_set_fmt():

1. atomisp_try_fmt_cap() uses atomisp_adjust_fmt() which adds the sensor
   padding to the width passed to atomisp_adjust_fmt() to calculate
   bytesperline. This is buggy for 2 reasons:

   a) The width passed to atomisp_adjust_fmt() already contains
      the sensor padding.

   b) The fmt returned by atomisp_try_fmt_cap() is the fmt outputted by
      the ISP and the sensor padding applies to the input side of the ISP
      not the output side. The output side of the ISP has its own padding /
      pitch requirements which have nothing to do with the sensor.

   Both these issues are fixed in this refactor by switching to
   ia_css_frame_pad_width() to calculate the padding.

2. atomisp_set_fmt() takes the passed in bytesperline value without
   doing any validation on it and then passes this unchecked value to
   the configure_output() callback.

   If bytesperline converted to pixels is > 1920 ia_css_binary_find()
   will fail to find a valid binary for the preview pipeline triggering
   a dump_stack_lvl() call inside ia_css_binary_find() and causing
   atomisp_set_fmt() to fail.

   This is fixed by making atomisp_set_fmt() call atomisp_try_fmt()
   first which we override the userspace specified bytesperline with
   the correct value.

Besides this bug there is also a bunch of weirdness and a lot of
duplication in the code:

1. atomisp_try_fmt_cap() adds the sensor padding itself but then
   it gets substracted again in atomisp_adjust_fmt() not doing
   the addition + substraction in the same place makes the code hard
   to follow (weirdness).

2. atomisp_set_fmt() starts with basically an atomisp_try_fmt() call,
   except that the only atomisp_try_fmt() caller: atomisp_try_fmt_cap()
   adds the sensor padding itself rather than letting atomisp_try_fmt()
   do this (duplication).

3. Both atomisp_try_fmt_cap() and atomisp_set_fmt() contain code to
   lookup the bridge-format matching the requested pixelformat and
   both will fallback to YUV420 if this is not set (duplication).

4. Both atomisp_try_fmt_cap() and atomisp_set_fmt() contain code to
   fill in the passed in v4l2_pix_format struct (duplication).

Cleanup all of this (and fix the bugs mentioned above) by:

1. Adding a new atomisp_fill_pix_format() helper which properly uses
   ia_css_frame_pad_width() to calculate bytesperline.

2. Move all sensor padding handling to atomisp_try_fmt() and
   make atomisp_try_fmt() fill the passed in v4l2_pix_format struct.

3. This reduces atomisp_try_fmt_cap() to just a small wrapper around
   atomisp_try_fmt().

4. Replace the DIY try_fmt code at the beginning of atomisp_set_fmt()
   with atomisp_try_fmt(), this will also override/fix the bytersperline
   passed by userspace.

5. Replace the DIY v4l2_pix_format filling at the end of atomisp_set_fmt()
   with atomisp_fill_pix_format().

Link: https://lore.kernel.org/r/20230529103741.11904-15-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Factor the code to go from width to a properly aligned pitch out of
ia_css_frame_info_set_width().

This is a preparation patch to fix try_fmt() calls returning a bogus
bytesperline value.

Link: https://lore.kernel.org/r/20230529103741.11904-14-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Passing 'isp->asd->inputs[asd->input_curr].foo' as argument to
various function calls is rather long.

Add a local input helper variable for this, so that the function
calls will fit on one line.

Link: https://lore.kernel.org/r/20230529103741.11904-13-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

atomisp_set_fmt*() use a local v4l2_subdev_fh declared on the stack,
specifically they use fh.state which is never initialized so when
passing fh.state to atomisp_subdev_set_ffmt() / to
atomisp_subdev_set_selection() these functions are passing random
stack contents as a pointer.

The reason this works is because when the which parameter is
V4L2_SUBDEV_FORMAT_ACTIVE the passed in state is not used.

Remove the bogus fh usage and just pass NULL as state.

Link: https://lore.kernel.org/r/20230529103741.11904-12-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

As the 2 comments in the function already say both the sink and the source
pads only support setting the selection for 1 target:

		/* Only crop target supported on sink pad. */
		/* Only compose target is supported on source pads. */

Validate that the passed in target actually matches these expectations.

Link: https://lore.kernel.org/r/20230529103741.11904-11-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

With the atomisp_subdev_set_selection(sink-pad, V4L2_SEL_TGT_CROP, rect)
calls dropped. The first and last compount code blocks of the 3 code blocks
in the if (...) {} else if (...) {} else {} code setting the source-pad
V4L2_SEL_TGT_COMPOSE selection are the same.

The both set V4L2_SEL_TGT_COMPOSE to a rectangle with the same dimensions
as f->fmt.pix.height.

Remove the else {} block at the end, drop the second if and prepend
the first if condition with "!second-if-condition ||" to remove
the code duplication.

Link: https://lore.kernel.org/r/20230529103741.11904-10-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

atomisp_subdev_set_selection(sink-pad, V4L2_SEL_TGT_CROP, rect)
ignores the passed in rect, using the width and height from the last
atomisp_subdev_set_ffmt(ATOMISP_SUBDEV_PAD_SINK, ffmt) call instead.

The atomisp_subdev_set_ffmt() call done by atomisp_set_fmt_to_snr()
already propagates the sink ffmt changes to V4L2_SEL_TGT_CROP
(this is what allows atomisp_set_fmt() to get the isp_sink_crop in
the first place).

Remove the redundant atomisp_subdev_set_selection(sink-pad, ...)
calls.

Note the removed aspect ratio correction in the last else block is
is already done by atomisp_subdev_set_selection() itself when
setting V4L2_SEL_TGT_COMPOSE on the source-pad.

Link: https://lore.kernel.org/r/20230529103741.11904-9-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Remove a bunch of sensor related custom IOCTLs because:

1. They are custom IOCTLs and all custom IOCTLs should be removed
2. Userspace should directly talk to the sensor v4l2-subdev, rather
   then relying on ioctl-s on the output /dev/video# node to pass
   through ioctl-s to the senor
3. Some of these rely on the atomisp specific camera_mipi_info struct
   which is going away as we are switching to using standard v4l2
   sensor drivers
4. In the case of ATOMISP_IOC_S_EXPOSURE_WINDOW this was using the
   v4l2-subdev set_selection API in an undocumented atomisp custom way

Link: https://lore.kernel.org/r/20230529103741.11904-8-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Implement selection support. Modelled after ov5693 selection support,
but allow setting sizes smaller than crop-size through set_fmt since
that was already allowed.

Link: https://lore.kernel.org/r/20230529103741.11904-7-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Having an init_cfg to initialize the passed in subdev-state is
important to make which == V4L2_SUBDEV_FORMAT_TRY ops work when
userspace is talking to a /dev/v4l2-subdev# node.

Copy the ov2680_init_cfg() from the standard drivers/media/i2c/ov2680.c
driver.

This is esp. relevant once support for cropping is added where
the v4l2_subdev_state.pads[pad].try_crop rectangle needs to be set
correctly for set_fmt which == V4L2_SUBDEV_FORMAT_TRY calls to work.

Link: https://lore.kernel.org/r/20230529103741.11904-6-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Call ov2680_calc_mode() from probe() instead of relying on userspace
to make at least one s_fmt call to fill the mode parameters.

Link: https://lore.kernel.org/r/20230529103741.11904-5-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

s/input_lock/lock/ lock is used by the generic drivers/media/i2c/ov2680.c
driver. Bring the atomisp ov2680 code inline to make it easier to port
changes between the two, with the end goal of getting rid of
the atomisp specific version.

Link: https://lore.kernel.org/r/20230529103741.11904-4-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

s/ov2680_device/ov2680_dev/ ov2680_dev is used by the generic
drivers/media/i2c/ov2680.c driver. Bring the atomisp ov2680 code
inline to make it easier to port changes between the two,
with the end goal of getting rid of the atomisp specific version.

Link: https://lore.kernel.org/r/20230529103741.11904-3-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

A lot of work has been done on the atomisp driver lately.

Rewrite the TODO file to drop all the already fixed items:

* Moved to videobuf2 + fixed mmap support
* Whole bunch of v4l2 API fixes making more apps work
* v4l2-async sensor probing support
* pm-runtime support (for some sensor drivers at least)
* buffer MM code was cleaned up / replaced when moving the videobuf2

And add a new TODO list (retaining some of the old items) split
into items which absolutely must be fixed before the driver can
be moved out of staging:

1. Conflicting hw-ids with regular sensor drivers
2. Private userspace API stuff

As well as a list of items which also definitely needs to be fixed
but which could also be fixed after moving the driver out of staging.

Link: https://lore.kernel.org/r/20230529103741.11904-2-hdegoede@redhat.comSigned-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Not all functions used in gmin_get_var_int() update len to the actual
length of the returned string. So len may still have its initial value
of the length of val[] when "val[len] = 0;" is run to ensure 0 termination.

If this happens we end up writing one beyond the bounds of val[], fix this.

Note this is a quick fix for this since the entirety of
atomisp_gmin_platform.c will be removed once all atomisp sensor
drivers have been moved over to runtime-pm + v4l2-async device
registration.

Closes: https://lore.kernel.org/linux-media/26f37e19-c240-4d77-831d-ef3f1a4dd51d@kili.mountain/Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Ideally, strlen(cur->string.pointer) and strlen(out) would be the same.
But this code is using strscpy() to avoid a potential buffer overflow.
So in the same way we should take the strlen() of the smaller string to
avoid a buffer overflow in the caller, gmin_get_var_int().

Link: https://lore.kernel.org/r/26124bcd-8132-4483-9d67-225c87d424e8@kili.mountain

Fixes: 387041cd ("media: atomisp: improve sensor detection code to use _DSM table")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Drop v4l2_get_acpi_sensor_info() the 2 sensor drivers which were
using this have both been converted to v4l2-async probing, relying
on the atomisp_csi2_bridge.c code to add the GPIO mappings instead.

Link: https://lore.kernel.org/r/20230525190100.130010-5-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Switch the atomisp-gc0310 driver to v4l2 async device registration.

After this change this driver no longer depends on
atomisp_gmin_platform and all atomisp-isms are gone.

Link: https://lore.kernel.org/r/20230525190100.130010-4-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Turn the atomisp-ov2680 driver into a standard v4l2 sensor driver:

1. Stop filling camera_mipi_info
2. Stop calling v4l2_get_acpi_sensor_info() this will be done by
   atomisp_csi2_bridge_parse_firmware() now
3. Switch to v4l2 async device registration

After this change this driver no longer depends on
atomisp_gmin_platform and all atomisp-isms are gone.

While at it, also add missing mutex_destroy() to ov2680_remove().

Link: https://lore.kernel.org/r/20230525190100.130010-3-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Add support for using v4l2-async sensor registration.

This has been tested with both the gc0310 and the ov2680 sensor drivers.

Drivers must add the ACPI HIDs they match on to the supported_sensors[]
array in the same commit as that they are converted to
v4l2_async_register_subdev_sensor().

Sensor drivers also must check they have a fwnode graph endpoint and return
-EPROBE_DEFER from probe() if there is no endpoint yet. This guarantees
that the GPIO mappings are in place before the driver tries to get GPIOs.

For now it also is still possible to use the old atomisp_gmin_platform
based sensor drivers. This is mainly intended for testing while moving
other sensor drivers over to runtime-pm + v4l2-async.

Link: https://lore.kernel.org/r/20230525190100.130010-2-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

The sanity checks were done too late, so move them up.

This fixes this smatch warning:

drivers/staging/media/atomisp/pci/sh_css_firmware.c:247 sh_css_load_firmware() warn: variable dereferenced before check 'fw_data' (see line 237)

Link: https://lore.kernel.org/r/20230524121150.435736-9-hverkuil-cisco@xs4all.nlSigned-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Fix a compiler warning:

drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:1525:13: warning: 'settings' may be used uninitialized [-Wmaybe-uninitialized]

The 'settings' variable is actually always initialized, but the
compiler isn't quite able to figure that out. Just initialize it
to 0 to avoid this warning.

Link: https://lore.kernel.org/r/20230524121150.435736-2-hverkuil-cisco@xs4all.nlSigned-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

After commit b8a1a4cd ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
commit 03c835f4 ("i2c: Switch .probe() to not take an id parameter")
convert back to (the new) .probe() to be able to eventually drop
.probe_new() from struct i2c_driver.

Link: https://lore.kernel.org/r/20230524151646.486847-3-u.kleine-koenig@pengutronix.deSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

camera_mipi_info is an atomisp / atomisp_gmin_platform specific struct,
allow mipi_info pointers to be NULL.

This is a preparation patch for making atomisp work with
standard v4l2 sensor drivers.

Link: https://lore.kernel.org/r/20230518153733.195306-9-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

atomisp_register_device_nodes() already iterates over the ports/sensors
in a loop and that loop already does not include the TPG input.

So we can simply setup the CSI2-port <-> ISP and sensor <-> CSI2-port
mediactl-pad links there instead of repeating the loop in
atomisp_create_pads_links(), which atomisp_register_device_nodes()
used to call later on.

Link: https://lore.kernel.org/r/20230518153733.195306-8-hdegoede@redhat.comReviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>