Message ID | 20200606150436.1851700-1-niklas.soderlund@ragnatech.se |
---|---|
Headers | show |
Series |
|
Related | show |
Hi Niklas, Thank you for the patches. On Sat, Jun 06, 2020 at 05:04:26PM +0200, Niklas Söderlund wrote: > Hi, > > This series removes the need to copy the buffer when capturing RAW > buffers from the IPU3 pipeline. This is made possible by allocating an > internal queue of buffers in the pipeline handler which is used when the > application does not provide an buffer for the RAW stream. > > The first 9 out of 10 patches in this series cleans up the IPU3 pipeline > handler a but and breaks out the CIO2Device helper class into separate > cio.{cpp,h} files. The CIO2Device is also reworked to make its interface > more strict, making it easier to grasp what is going in in ipu3.cpp. I > plan to post similar patches breaking out the ImgU on top of this > series. I'm not fully convinced by some of the changes to the CIO2Device class, as shown in review comments for the corresponding patches. On the other hand, I don't see anything that makes the code worse, so I'm not pushing back. I think it will be easier to review the CIO2Device abstraction when the ImgU will be split to a separate file, also with a stricter interface. > There is on issue with this series. If the camera is configured to > supply the application with more then one stream and one of them is a > RAW stream. Then the sequence number of the RAW buffers in all requests > are set to 0 before the request completes. This is due to that if two or > more streams are used the RAW buffer is always queued to the ImgU input > to serve as input to the vf and/or output buffers. When the RAW buffers > is dequeued from the ImgU input device the kernel sets the sequence > number to zero. I believe this is a kernel issue and should be fixed > there. Could you propose a patch ? :-) Regardless of whether this is a kernel issue or not, I think we'll have to rework sequence number handling. It may not make sense to have per-buffer sequence numbers, maybe handling that at the request level would be a better option. Or, given that requests are never lost, maybe sequence numbers don't make sense and should be removed altogether. This needs to be researched, we haven't really put much effort yet in the handling of dropped frames. > As the RPi pipeline handler already started using the copy approach we > can not yet rename to role nor remove the copyFrom() helper. I aim to > work on that once the approach taken in this series is agreed upon. > > Niklas Söderlund (10): > libcamera: stream: Initialize stride and bufferCount > libcamera: ipu3: Remove id from camera names > libcamera: ipu3: Fold mediaBusToFormat() into only caller > libcamera: ipu3: Breakout stream assignment to new function > libcamera: ipu3: Calculate number of buffers for ImgU > libcamera: ipu3: cio2: Move the CIO2Device class to separate files > libcamera: ipu3: cio2: Add function to generate configuration > libcamera: ipu3: cio2: Make the V4L2 devices private > libcamera: ipu3: cio2: Hide buffer allocation and freeing from users > libcamera: ipu3: Allow zero-copy RAW stream capture > > src/libcamera/pipeline/ipu3/cio2.cpp | 314 +++++++++++++++ > src/libcamera/pipeline/ipu3/cio2.h | 68 ++++ > src/libcamera/pipeline/ipu3/ipu3.cpp | 486 +++++------------------- > src/libcamera/pipeline/ipu3/meson.build | 1 + > src/libcamera/stream.cpp | 5 +- > 5 files changed, 478 insertions(+), 396 deletions(-) > create mode 100644 src/libcamera/pipeline/ipu3/cio2.cpp > create mode 100644 src/libcamera/pipeline/ipu3/cio2.h >