[libcamera-devel] [PATCH 04/13] libcamera: pipeline: rkisp1: Prepare buffer ready handlers for multiple streams

Jacopo Mondi jacopo at jmondi.org
Thu Aug 20 10:30:41 CEST 2020


Hi Niklas,

On Thu, Aug 13, 2020 at 02:52:37AM +0200, Niklas Söderlund wrote:
> The buffer ready handlers are designed for a single application facing
> stream from the main path. To prepare for multiple application facing
> streams from main and/or self path the handlers need to be prepared.
>
> The data keeping tasks of frame number and advancing the timeline can be
> moved from the application facing buffer ready handler to the statistics
> handler. For each request processed there will always be a statistic
> buffer and as the ISP is inline and is the source of both main, self and
> statistic paths there is no lose in precision from this.
>
> The application facing handler no longer needs a special case for

Why isn't this required anymore ?

> cancelled frames and can be made simpler. With this change the handlers
> are ready to deal with any combinations of application facing streams.

It's alla bit terse.. Don't repeat 'application facing' all the times
and it might read better.
We don't have internal streams for this pipeline after all, am I wrong ?

>
> Signed-off-by: Niklas Söderlund <niklas.soderlund at ragnatech.se>
> ---
>  src/libcamera/pipeline/rkisp1/rkisp1.cpp | 17 +++++------------
>  1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/src/libcamera/pipeline/rkisp1/rkisp1.cpp b/src/libcamera/pipeline/rkisp1/rkisp1.cpp
> index 38382a6894dac22a..a1cda12d244f2d97 100644
> --- a/src/libcamera/pipeline/rkisp1/rkisp1.cpp
> +++ b/src/libcamera/pipeline/rkisp1/rkisp1.cpp
> @@ -1074,20 +1074,8 @@ void PipelineHandlerRkISP1::tryCompleteRequest(Request *request)
>  void PipelineHandlerRkISP1::bufferReady(FrameBuffer *buffer)
>  {
>  	ASSERT(activeCamera_);
> -	RkISP1CameraData *data = cameraData(activeCamera_);
>  	Request *request = buffer->request();
>
> -	if (buffer->metadata().status == FrameMetadata::FrameCancelled) {
> -		completeBuffer(activeCamera_, request, buffer);
> -		completeRequest(activeCamera_, request);
> -		return;
> -	}
> -
> -	data->timeline_.bufferReady(buffer);
> -
> -	if (data->frame_ <= buffer->metadata().sequence)
> -		data->frame_ = buffer->metadata().sequence + 1;
> -
>  	completeBuffer(activeCamera_, request, buffer);
>  	tryCompleteRequest(request);
>  }
> @@ -1118,6 +1106,11 @@ void PipelineHandlerRkISP1::statReady(FrameBuffer *buffer)
>  	if (!info)
>  		return;
>
> +	data->timeline_.bufferReady(buffer);
> +
> +	if (data->frame_ <= buffer->metadata().sequence)
> +		data->frame_ = buffer->metadata().sequence + 1;
> +

So we're moving advancing the timeline and sequence number from buffer
complete to stat complete, as we are sure there's one single stat for
each frame processed by the ISP, right ?

Seems fair to me, but there might be implications I cannot see at the
moment (ie. is stat mandatory to be queued with buffers ? How does
this play with RAW capture, asking as I don't know where we do get RAW
frames on RkISP1)

Seems legit to me
Reviewed-by: Jacopo Mondi <jacopo at jmondi.org>

Thanks
  j

>  	IPAOperationData op;
>  	op.operation = RKISP1_IPA_EVENT_SIGNAL_STAT_BUFFER;
>  	op.data = { info->frame, info->statBuffer->cookie() };
> --
> 2.28.0
>
> _______________________________________________
> libcamera-devel mailing list
> libcamera-devel at lists.libcamera.org
> https://lists.libcamera.org/listinfo/libcamera-devel


More information about the libcamera-devel mailing list