Re: [PATCH v5 03/10] media: imx219: Account rate_factor in setting upper exposure limit

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

Hi Dave,

On Mon, Jun 08, 2026 at 04:42:44PM +0100, Dave Stevenson wrote:
> Hi Sakari
> 
> On Sun, 7 Jun 2026 at 22:54, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> >
> > The rate_factor multiplier is used to multiply a few values in the
> > sensor's timing configuration and the exposure time is one of them. This
> > also needs to be taken into account in exposure time margin: multiply it
> > by rate_factor so that sensor's exposure time margin is respected.
> 
> Testing the 1640x1232 mode with FRM_LENGTH_A set to 0x288 (79.07fps),
> I can write register 0x15a (COARSE_INTEGRATION_TIME_A) with values up
> to and including 0x284 without it affecting the output frame rate, and
> without image corruption.
> With IMX219_EXPOSURE_OFFSET being 4, the current code implements
> exactly those limits, so why do you believe the offset should be
> increased?

I agree with the upper exposure time limit (with FRM_LENGTH_A set to 0x288)
and the margin above but the issue is that the driver only implements
these limits when rate_factor is 1.

The margin is subtracted from the frame length to calculate the upper
exposure limit, but as the frame length in lines an the exposure values are
divided by rate_factor, the margin gets divided, too, resulting the
effective margin of 2.

I tested that setting the exposure value to higher than FRM_LENGTH_A -
margin increases the frame time. This shouldn't be the case i.e. it's a
driver bug.

> 
> To my mind section 5-5 Frame Rate Calculation Formula of the datasheet
> is fairly clear with
> [ In the case of (frame_length_lines - 4 > coarse_integration_time) ]:
> Frame_Length = frame_length_lines
> [ In the case of (frame_length_lines - 4 < coarse_integration_time) ]:
> Frame_Length = coarse_integration_time + 4
> 
> The register FRM_LENGTH_A (0x160) being in units of 2 lines doesn't
> change that calculation.

-- 
Kind regards,

Sakari Ailus