[libcamera-devel] [PATCH v3 05/16] libcamera: ipu3: Report sensor timestamp

[Niklas Söderlund]

Hi Jacopo,

On 2021-04-21 18:03:08 +0200, Jacopo Mondi wrote:
> Report the sensor's timestamp in the Request metadata by using the
> CIO2 buffer timestamp as an initial approximation.
> 
> The buffer's timestamp is recorded at DMA-transfer time, and it does not
> theoretically matches the 'start of exposure' definition, but when used
> to compare two consecutive frames it gives an acceptable estimation of
> the sensor frame period duration.
> 
> Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> Reviewed-by: Hirokazu Honda <hiroh at chromium.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Signed-off-by: Jacopo Mondi <jacopo at jmondi.org>
> ---
>  src/libcamera/pipeline/ipu3/ipu3.cpp | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/libcamera/pipeline/ipu3/ipu3.cpp b/src/libcamera/pipeline/ipu3/ipu3.cpp
> index 51446fcf5bc1..28e849a43a3e 100644
> --- a/src/libcamera/pipeline/ipu3/ipu3.cpp
> +++ b/src/libcamera/pipeline/ipu3/ipu3.cpp
> @@ -1255,6 +1255,15 @@ void IPU3CameraData::cio2BufferReady(FrameBuffer *buffer)
>  
>  	Request *request = info->request;
>  
> +	/*
> +	 * Record the sensor's timestamp in the request metadata.
> +	 *
> +	 * \todo The sensor timestamp should be better estimated by connecting
> +	 * to the V4L2Device::frameStart signal.
> +	 */

I'm OK with this patch as is, but just in case you missed it. The signal 
is already wired to CIO2Device::frameStart() is and used to feed the 
DelayedControls state machine. So all the building blocks for this todo 
I think is already in place,

    void PipelineHandlerIPU3::stamp(uint32_t sequence)
    {
        IPU3Frames::Info *info = frameInfos_.find(buffer);

        ...

        info->request->metadata().set(controls::SensorTimestamp, ...);
    }

    int PipelineHandlerIPU3::registerCameras()
    {
        ....

        data->cio2_.frameStart().connect(this, &PipelineHandlerIPU3::stamp);

        ....
    }

That being said I think we might get better values using the buffer 
timestamp as done in this patch, if nothing else less jitter. Only draw 
back I can think of is that we can't grantee the timestamp coming from 
the kernel relates to BOOTTIME.

> +	request->metadata().set(controls::SensorTimestamp,
> +				buffer->metadata().timestamp);
> +
>  	/* If the buffer is cancelled force a complete of the whole request. */
>  	if (buffer->metadata().status == FrameMetadata::FrameCancelled) {
>  		for (auto it : request->buffers())
> -- 
> 2.31.1
> 
> _______________________________________________
> libcamera-devel mailing list
> libcamera-devel at lists.libcamera.org
> https://lists.libcamera.org/listinfo/libcamera-devel

-- 
Regards,
Niklas Söderlund