[00/28] media: ov2680: Bugfixes + ACPI + selection(crop-tgt) API support

  Hi All,

During all the work done on the atomisp driver I have mostly been testing
on devices with an ov2680 sensor. As such I have also done a lot of work
on the atomisp-ov2680.c atomisp specific sensor driver.

With the latest atomisp code from:
https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tag/?h=media-atomisp-6.5-1

The atomisp code can now work with standard v4l2 sensor drivers using
the selections (crop-tgt) api and v4l2-async sensor driver registration.

This patch series modifies the main drivers/media/i2c/ov2680.c driver
to add bugfixes, ACPI enumeration, selection API support and further
improvments. After this the driver can be used with the atomisp driver
and atomisp-ov2680.c can be dropped.

This also gets the driver much closer to having everything needed for
use with IPU3 / libcamera. I have a Lenovo Miix 510 now with an IPU3 +
ov2680 sensor and I plan to work on this soonish.

This series consist of 3 parts:

1. Patches 0-7 are bugfixes these are put first for backporting

2.1 Patch 8 adds the new CCI register helpers, these are being
reviewed here:
https://lore.kernel.org/linux-media/20230606165808.70751-2-hdegoede@redhat.com/

the intend is to merge that patch separately before this series.
This patch is only here so that the series actually compiles.

2.2 Patch 9 converts the ov2680 driver to the new CCI helpers,
the same has been done in the other series with the atomisp-ov2680
driver and this makes it much easier to sync things up

3. Patches 10 - 28 implement the ACPI enumeration,
selection API support and further improvments.

Regards,

Hans


Hans de Goede (28):
  media: ov2680: Remove auto-gain and auto-exposure controls
  media: ov2680: Fix ov2680_bayer_order()
  media: ov2680: Fix vflip / hflip set functions
  media: ov2680: Use select VIDEO_V4L2_SUBDEV_API
  media: ov2680: Don't take the lock for try_fmt calls
  media: ov2680: Add ov2680_fill_format() helper function
  media: ov2680: Fix ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY
    not working
  media: Add MIPI CCI register access helper functions
  media: ov2680: Convert to new CCI register access helpers
  media: ov2680: Store dev instead of i2c_client in ov2680_dev
  media: ov2680: Check for "powerdown" GPIO con-id before checking for
    "reset" GPIO con-id
  media: ov2680: Add runtime-pm support
  media: ov2680: Drop is_enabled flag
  media: ov2680: Add support for more clk setups
  media: ov2680: Add support for 19.2 MHz clock
  media: ov2680: Add endpoint matching support
  media: ov2680: Add support for ACPI enumeration
  media: ov2680: Fix ov2680_enum_frame_interval()
  media: ov2680: Annotate the per mode register setting lists
  media: ov2680: Add ov2680_mode struct
  media: ov2680: Make setting the mode algorithm based
  media: ov2680: Add an __ov2680_get_pad_format() helper function
  media: ov2680: Implement selection support
  media: ov2680: Fix exposure and gain ctrls range and default value
  media: ov2680: Add a bunch of register tweaks
  media: ov2680: Add g_skip_frames op support
  media: ov2680: Drop unnecessary pad checks
  media: ov2680: Read and log sensor revision during probe

 Documentation/driver-api/media/v4l2-cci.rst  |    5 +
 Documentation/driver-api/media/v4l2-core.rst |    1 +
 drivers/media/i2c/Kconfig                    |    2 +
 drivers/media/i2c/ov2680.c                   | 1251 +++++++++---------
 drivers/media/v4l2-core/Kconfig              |    5 +
 drivers/media/v4l2-core/Makefile             |    1 +
 drivers/media/v4l2-core/v4l2-cci.c           |  142 ++
 include/media/v4l2-cci.h                     |  109 ++
 8 files changed, 889 insertions(+), 627 deletions(-)
 create mode 100644 Documentation/driver-api/media/v4l2-cci.rst
 create mode 100644 drivers/media/v4l2-core/v4l2-cci.c
 create mode 100644 include/media/v4l2-cci.h
  

Hi Hans,

On Wed, Jun 07, 2023 at 06:46:44PM +0200, Hans de Goede wrote:
> Hi All,
> 
> During all the work done on the atomisp driver I have mostly been testing
> on devices with an ov2680 sensor. As such I have also done a lot of work
> on the atomisp-ov2680.c atomisp specific sensor driver.

Could you wrap the lines at or before 80 characters, unless there are
reason (generally other coding style rules) to keep them longer?
  

Hi Sakari,

On 6/9/23 11:37, Sakari Ailus wrote:
> Hi Hans,
> 
> On Wed, Jun 07, 2023 at 06:46:44PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> During all the work done on the atomisp driver I have mostly been testing
>> on devices with an ov2680 sensor. As such I have also done a lot of work
>> on the atomisp-ov2680.c atomisp specific sensor driver.
> 
> Could you wrap the lines at or before 80 characters, unless there are
> reason (generally other coding style rules) to keep them longer?

I can certainly do that. But the kernel has stopped requiring this now
and I often find that sticking within the new official limit of
100 chars leads to IMHO better readable code the needlessly breaking
the lines in 2.

Are there any specific reasons why you want to keep enforcing
the old and obsolete 80 chars limit ?

I must say that inconsistent enforcing of a 80 vs 100 chars limit
across the kernel is quite confusing for contributors.

E.g. I'm pretty sure that if I had stuck to 80 chars with this
patch-set from the start that Andy would then have pointed out
several places where I had needlessly broken a lone in 2.

So having 2 different limits leads to reviewers contradicting
each other which is really not helpful.

SO IMHO if drivers/media is going to keep enforcing a 80 chars
limit then this needs to be clearly documented (with rationale)
somewhere. Or did I miss this already being documented somewhere ?

Regards,

Hans