Re: [PATCH v4 17/20] media: i2c: ov4689: Configurable analogue crop

[Mikhail Rudenko <mike.rudenko@gmail.com>]

On 2024-04-16 at 06:47 GMT, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:

> On Mon, Apr 15, 2024 at 11:22:09PM +0300, Mikhail Rudenko wrote:
>>
>> Hi Sakari,
>>
>> On 2024-04-15 at 06:08 GMT, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>>
>> > Hi Mikhail,
>> >
>> > On Tue, Apr 02, 2024 at 07:45:48PM +0300, Mikhail Rudenko wrote:
>> >> Implement configurable analogue crop via .set_selection call.
>> >> ov4689_init_cfg is modified to initialize default subdev selection.
>> >> Offsets are aligned to 2 to preserve Bayer order, selection width is
>> >> aligned to 4 and height to 2 to meet hardware requirements.
>> >>
>> >> Experimentally discovered values of the cropping-related registers and
>> >> vfifo_read_start for various output sizes are used. Default BLC anchor
>> >> positions are used for the default analogue crop, scaling down
>> >> proportionally for the smaller crop sizes.
>> >>
>> >> When analogue crop is adjusted, several consequential actions take
>> >> place: the output format is reset, exposure/vblank/hblank control
>> >> ranges and default values are adjusted accordingly. Additionally,
>> >> ov4689_set_ctrl utilizes pad crop instead of cur_mode width and
>> >> height for HTS and VTS calculation. Also, ov4689_enum_frame_sizes is
>> >> modified to report crop size as available frame size.
>> >
>> > We're amidst of a change to the APIs touching sensors with the the
>> > introduction of the internal pads.
>> > <URL:https://lore.kernel.org/linux-media/20240313072516.241106-1-sakari.ailus@linux.intel.com/T/#t>.
>> >
>> > I'd therefore postpone this bit so it would align with the new practices
>> > (also subject to change in the metadata set).
>> >
>> > The rest of the patches would seem more or less ready for merging to me.
>>
>> Okay, so I'll post a v5 of patches 1-16 with whitespace fixes (as you
>> suggested in patch 20) soon, and the remaining patches affected by the
>> metadata-related API changes as a separate series as soon those changes
>> land in media_stage. Do I get you right?
>
> Yes, please.

Done, see [1].

[1] https://lore.kernel.org/all/20240416224524.1511357-1-mike.rudenko@gmail.com/

--
Best regards,
Mikhail Rudenko