Re: [PATCH v3 15/17] media: i2c: os05b10: fix negative hblank calculation

[Tarang Raval]

Hi Jai,

Thanks for the review.

> Quoting Tarang Raval (2026-07-19 01:39:06)
> > hblank is computed as "mode->hts - mode->width", but both are u32.
> > For every mode hts < width (e.g. 1744 vs 2592 for 2592x1944), so the
> > subtraction wraps in unsigned 32-bit arithmetic instead of going
> > negative. That wrapped value ends up in the control's s64 min/max,
> > which v4l2-compliance flags as out of range:
> >
> >     fail: v4l2-test-controls.cpp(413): returned control value out of range
> >     fail: v4l2-test-controls.cpp(476): invalid control 009e0902
> >
> > and v4l2-ctl shows:
> >
> >     horizontal_blanking 0x009e0902 (int): min=4294966448 max=4294966448
> >     step=1 default=4294966448 value=-848 flags=read-only, has-min-max
> >
> > The same bug exists in os05b10_init_controls(), which sets the
> > control's default before os05b10_set_framing_limits() runs.
> >
> > Fix both sites by casting to a signed type before subtracting, so the
> > real (possibly negative) value is computed directly.
> >
>
> While the framework accepts negative blankings, IMHO they physically don't
> make much sense.
>
> Many sensors scale their HTS register by some constant factor, so increment
> of 1 in HTS does not mean 1 pixel on a line, but 4 or 8 or n pixels.
> This also affects the internal "pixel rate" for framerate calculation.
>
> Please look at imx283, imx678 etc.

Sure, I'll look into this properly.

Before that, I want to flag something, I went through the OS05B10 datasheet
carefully, and it doesn't explicitly state what clock domain HTS is
counted in, or what its actual unit is relative to the output pixel clock.
The register description just says "Total horizontal timing size" with no
further detail.

That said, looking at the clock scheme section (PLL1 driving separate SCLK
and PCLK dividers) and the register defaults themselves (default output
width is larger than the default HTS value), it does look like HTS isn't
counted in output-pixel units directly, so there's likely a scale factor
between the two, similar to imx283 or imx678's HMAX.

I don't have vendor support to get the exact PLL divider table to confirm
this precisely, so I'll try to derive the real value empirically on
hardware and cross-check it across the supported resolutions before
sending a proper fix.

Best Regards,
Tarang