Quoting Hans de Goede (2024-02-16 22:32:33) > There is no reason to send OV2680_END_MARGIN extra columns on top of > the mode width and the same for sending extra lines over the mode height. > > This sending of extra lines/columns was inherited from the atomisp > ov2680 driver, it is unclear why this was done and this complicates > adding V4L2_CID_VBLANK support, so remove it. Was this some niave way of adding some HBLANK to let the AtomISP keep up with processing each line? Or is it an optical black region? or padding? (I hit issues around that on the IMX283 lately). Is this a sensor you have and can visually check? > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > --- > drivers/media/i2c/ov2680.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c > index 39d321e2b7f9..5b04c6c0554a 100644 > --- a/drivers/media/i2c/ov2680.c > +++ b/drivers/media/i2c/ov2680.c > @@ -86,9 +86,6 @@ > #define OV2680_PIXELS_PER_LINE 1704 > #define OV2680_LINES_PER_FRAME 1294 > > -/* If possible send 16 extra rows / lines to the ISP as padding */ > -#define OV2680_END_MARGIN 16 > - > /* Max exposure time is VTS - 8 */ > #define OV2680_INTEGRATION_TIME_MARGIN 8 > > @@ -359,11 +356,9 @@ static void ov2680_calc_mode(struct ov2680_dev *sensor) > sensor->mode.v_start = (sensor->mode.crop.top + > (sensor->mode.crop.height - height) / 2) & ~1; > sensor->mode.h_end = > - min(sensor->mode.h_start + width + OV2680_END_MARGIN - 1, > - OV2680_NATIVE_WIDTH - 1); > + min(sensor->mode.h_start + width - 1, OV2680_NATIVE_WIDTH - 1); > sensor->mode.v_end = > - min(sensor->mode.v_start + height + OV2680_END_MARGIN - 1, > - OV2680_NATIVE_HEIGHT - 1); > + min(sensor->mode.v_start + height - 1, OV2680_NATIVE_HEIGHT - 1); > sensor->mode.h_output_size = orig_width; > sensor->mode.v_output_size = orig_height; > sensor->mode.hts = OV2680_PIXELS_PER_LINE; Especially as seeing hts = OV2680_PIXELS_PER_LINE it does sound like the margin is superfluous. > -- > 2.43.0 >
