| Message ID | 20230607164712.63579-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | media: ov2680: Bugfixes + ACPI + selection(crop-tgt) API support | expand |
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
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