[libcamera-devel] [PATCH v2 00/10] libcamera: ipu3: Allow zero-copy RAW stream

[Laurent Pinchart]

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
> 

-- 
Regards,

Laurent Pinchart