Re: [PATCH] media: Documentation: Fix frame interval calculation for raw camera sensors

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Jai,

On Tue, Feb 24, 2026 at 10:55:33AM +0530, Jai Luthra wrote:
> >         LLP = (analog_crop_width + HBLANK) / binning_timing_h
> >         FLL = (analog_crop_height + VBLANK) / binning_timing_v
> >         frame_interval = LLP * FLL / pixel_rate
> > 
> > I'm not 100% sure this is correct however, as the blankings should be
> > expressed on a different clock domain that the pixel sampling rate,
> > but I guess this is a reasonable approximation ?
> 
> What does these two extra controls really offer us?

The conclusion earlier on (well, maybe 10 years ago?) was that we should
have had these to begin with, and not to use the blanking values to control
the frame rate, largely because it requires a reference rectangle -- and
the current drivers use a wrong one, mostly because the API doesn't offer
the right one. The assumption back then was that everything would soon be
SMIA (or now CCS) compliant so this wouldn't matter much. But here we
are...

The VBLANK and HBLANK controls effectively also use the wrong reference
(output size) in most drivers and that can't really be changed meaningfully
without breaking things.

> 
> All sensors we have seen thus far map their LLP/FLL (or equivalent HTOT/VTOT)
> values with respect to the digital readout, and not the analogue pixel array.
> 
> If we add these two controls, we will have to support two different models for
> frame interval calculation in the application layer too. Which I'm fine with if
> it has a practical benefit, that is, it makes it easier to deal with some
> particular sensor.

There are three models, effectively:

1. CCS, where vblank and hblank are related to analogue crop rectangle, as in
   hardware;

2. Common raw sensor model, with LLP and FLL; and

3. the rest of the existing drivers (vblank and hblank relative to format
   on source pad).

In the case of frame length vs. blanking, I'd presume the difference in the
user space will be relatively small.

> 
> And if exposing the LLP/FLL directly offer the same benefit, then that is
> cleaner, as it leaves the HBLANK/VBLANK as-is in the new model.

-- 
Kind regards,

Sakari Ailus