Re: [PATCH 1/3] Documentation: media: camera-sensor: Correct frame interval

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jacopo,

On Mon, Nov 07, 2022 at 09:49:57PM +0100, Jacopo Mondi wrote:
> The formula to compute the frame interval uses the analogue crop
> rectangle dimensions to compute the total frame size in conjunction with
> blankings.
> 
> Horizontal and vertical blankings are realized by extending the time
> interval during which no valid pixels are sent on the bus between
> visible lines and between consecutive frames, whose size is smaller than
> the analogue crop rectangle if any additional cropping or pixel
> subsampling is applied on the sensor processing pipeline.
> 
> Correct the documentation to use the visible line length and frame
> height instead of the analogue crop dimensions.
> 
> Signed-off-by: Jacopo Mondi <jacopo@xxxxxxxxxx>
> ---
>  Documentation/driver-api/media/camera-sensor.rst | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst
> index c7d4891bd24e..bb7d62db4cd1 100644
> --- a/Documentation/driver-api/media/camera-sensor.rst
> +++ b/Documentation/driver-api/media/camera-sensor.rst
> @@ -87,12 +87,11 @@ less all modern raw camera sensors.
>  
>  The frame interval is calculated using the following equation::
>  
> -	frame interval = (analogue crop width + horizontal blanking) *
> -			 (analogue crop height + vertical blanking) / pixel rate
> +	frame interval = (visible width + horizontal blanking) *
> +			 (visibile height + vertical blanking) / pixel rate
>  
>  The formula is bus independent and is applicable for raw timing parameters on
> -large variety of devices beyond camera sensors. Devices that have no analogue
> -crop, use the full source image size, i.e. pixel array size.
> +large variety of devices beyond camera sensors.

This would break frame interval computation for CCS and possibly for some
other devices as well. Analogue crop effectively means leaving some parts
of the pixel array unread, which is why it affects sensor timing. Digital
crop, on the other hand, involves throwing out data later in the process
and so it does not have such an effect on timing.

There are two ways the issue could be addressed for drivers exposing a
single sub-device:

1) adding FLL and LLP controls that are independent of analogue crop or

2) adding a special analogue crop rectangle.

I think 1) is preferred, as it always has been somewhat cumbersome that you
have to find the size the blanking controls are related using another
interface.

Some drivers could take digital crop into account in blanking values
already but that is just working around the problem, although for single
sub-device drivers there haven't been proper solutions provided either.

>  
>  Horizontal and vertical blanking are specified by ``V4L2_CID_HBLANK`` and
>  ``V4L2_CID_VBLANK``, respectively. The unit of the ``V4L2_CID_HBLANK`` control

-- 
Kind regards,

Sakari Ailus



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux