Re: [PATCH v2 2/2] media: i2c: ov02e10: add OV02E10 image sensor driver

[Sakari Ailus]

Hi Hans, Bryan,

On Tue, Apr 01, 2025 at 10:12:35AM +0200, Hans de Goede wrote:
> Hi Bryan, Sakari,
> 
> On 1-Apr-25 2:34 AM, Bryan O'Donoghue wrote:
> > On 27/03/2025 07:36, Sakari Ailus wrote:
> >>> +static u64 to_pixel_rate(u32 f_index)
> >>> +{
> >>> +    u64 pixel_rate = link_freq_menu_items[f_index] * 2 * OV02E10_DATA_LANES;
> >>> +
> >>> +    do_div(pixel_rate, OV02E10_RGB_DEPTH);
> >> The pixel rate control is for the pixel rate on the pixel array, not on the
> >> CSI-2 interface. Without binning or sub-sampling these may the same still,
> >> but this only works in special cases really.
> > 
> > Hmm computer says no, I don't think I have understood this comment..
> > 
> > Looking at other drivers, I'd say the above pattern is pretty common - taking ov8856 as an example that's pretty much equivalent logic to the above, ov08x40 does something similar.
> > 
> > =>
> > 
> > pixel_rate == link_freq * 2 * #oflanes / RGB_DEPTH
> >            => 360MHz * 2 * 2 / 10
> >            => 360000000 * 2 * 2 / 10
> >            => 144000000
> > 
> > If I'm understanding you though you mean the pixel rate for the control V4L2_CID_PIXEL_RATE expressed here should be the resolution * the FPS / bits_per_pixel
> 
> I have to agree with Bryan here that the pixelrate typically is const
> and directly derived from the link-frequency. Even the
> __v4l2_get_link_freq_ctrl() helper from drivers/media/v4l2-core/v4l2-common.c
> assumes this.

That is there to support old drivers that don't use the LINK_FREQ control.
All new ones do.

> 
> binning / subsampling does not change anything wrt the pixelrate it
> just means that either the blanking becomes much bigger keeping
> vts / hts the same, or that the FPS becomes much higher.
> 
> It is not like the sensor is sending an empty pixel on the CSI
> link every other pixel when binning, since there is no such
> thing as an empty pixel. So the sensor must go faster when doing
> horizontal binning to keep the CSI link filled effectively
> doubling the FPS, or requiring a much larger hblank after having
> taken only half the time sending pixels.

Please see
<URL:https://hverkuil.home.xs4all.nl/spec/userspace-api/drivers/camera-sensor.html#raw-camera-sensors>
and
<URL:https://hverkuil.home.xs4all.nl/spec/userspace-api/v4l/ext-ctrls-image-process.html#image-process-control-ids>.

As noted, this may be correct if the sensor doesn't use binning or
sub-sampling, but conceptually pixel rate on the pixel array and on the
CSI-2 bus are different. The PIXEL_RATE control is for the former albeit in
the past some drivers have presumably used it for the latter as well.

> 
> (and the same applies to vts when vertical binning)
> 
> > pixel_rate = wdith x height x fps / bpp
> >            => 1928 * 1088 * 30 / 10
> >            => 6292992
> > 
> > i.e. the pixel rate not related to the CSI2 link frequency ?
> 
> No the pixel-rate control includes vblank + hblank "pixels"
> and is in pixels/sec so no dividing by bpp, iow it is:
> 
> vts * hts * fps
> 
> and this must match
> 
> link_freq * 2 * #oflanes / RGB_DEPTH

-- 
Kind regards,

Sakari Ailus