[libcamera-devel] [PATCH v1 2/4] ipa: ipu3: ipa_context: Extend FCQueue::get()

[Kieran Bingham]

Quoting Jean-Michel Hautbois (2022-06-13 15:39:59)
> Hi Umang, Jacopo, Kieran,
> 

<snip>

> >>>>
> >>>> We manually give it a value of '0' in clear(). It should work out from
> >>>> there.
> >>>
> >>> Right. Again careful that if frame numbers are numbered using the
> >>> CSI-2 frame number, it will count from 1.
> >>
> >> Where have you got this '1' from ?  Is that 'just' the IPU3 CIO2
> > 
> >  From the CSI-2 specification.
> > 
> > I admit I have an old version: "Version 1.01.00 r0.04 2-Apr-2009"
> > Section 9.8.1 "Frame Synchonization Packets"
> > 
> > ------------------------------------------------------------------------------
> > For FS and FE synchronization packets the Short Packet Data Field
> > shall contain a 16-bit frame number.  This frame number shall be the
> > same for the FS and FE synchronization packets corresponding to a
> > given frame.
> > 
> > The 16-bit frame number, when used, shall be non-zero to distinguish
> > it from the use-case where frame number is inoperative and remains set
> > to zero.
> > 
> > The behavior of the 16-bit frame number shall be as one of the
> > following
> > •Frame number is always zero – frame number is inoperative.
> > •Frame number increments by 1 for every FS packet with the same
> >   Virtual Channel and is periodically reset to one e.g. 1, 2, 1, 2, 1,
> >   2, 1, 2 or 1, 2, 3, 4, 1, 2, 3, 4
> > ------------------------------------------------------------------------------
> > 
> >> receiver?
> >>
> > 
> > As far as I can see IPU3, RPi and RKISP1 use a counter and not the
> > CSI-2 frame number
> > 
> 
> The sequence number beeing forced to 0 in Kieran's patch [1] is 
> correcting the CSI-2 issue. But I agree with Jacopo, we have another 
> one, because we set the frame number to the request->sequence() and when 
> we are in a stop/start it won't be reset to 0.
> 
> Quoting d874b3e34173811fa89b68b4b71f22182bc5fd98:
> "When requests are queued, they are given a sequential number to track 
> the order in which requests are queued to a camera. This number counts 
> all requests given to a camera through its lifetime, and is not reset to 
> zero between camera stop/start sequences.
> 
> It can be used to support debugging and identifying the flow of requests
> through a pipeline, but does not guarantee to represent the sequence 
> number of any images in the stream. The sequence number is stored as an 
> unsigned integer and will wrap when overflowed.
> "

Good spot. I wonder if we'll need to make that reset to zero, or ensure
that the sequence counts resume correctly from a streamOn/streamOff.

I suspect we'll just make the request numbers restart, as they are only
used internally anyway I think ...


> Thus, I think IPU3Frames is not using the correct counter...
> 
> [1]: https://patchwork.libcamera.org/project/libcamera/list/?series=3173
> 
> >> It's precisely why I created the patch to V4L2VideoDevice to make all
> >> devices consistent.

--
Kieran