From patchwork Thu Jun 25 22:38:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Niklas_S=C3=B6derlund?= X-Patchwork-Id: 8425 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 0E00AC2E65 for ; Thu, 25 Jun 2020 22:39:20 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 1ED21609C7; Fri, 26 Jun 2020 00:39:19 +0200 (CEST) Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 67859603BA for ; Fri, 26 Jun 2020 00:39:17 +0200 (CEST) X-Halon-ID: ace39f9b-b734-11ea-933e-005056917a89 Authorized-sender: niklas@soderlund.pp.se Received: from bismarck.berto.se (p4fca2eca.dip0.t-ipconnect.de [79.202.46.202]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPA id ace39f9b-b734-11ea-933e-005056917a89; Fri, 26 Jun 2020 00:39:12 +0200 (CEST) From: =?utf-8?q?Niklas_S=C3=B6derlund?= To: libcamera-devel@lists.libcamera.org Date: Fri, 26 Jun 2020 00:38:51 +0200 Message-Id: <20200625223900.1282164-1-niklas.soderlund@ragnatech.se> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v4 0/9] libcamera: ipu3: Allow zero-copy RAW stream X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" 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. 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. This should either be solved in the kernel or by reworking how sequence numbers handled going out of libcamera, does it make sens to have seq numbers on the buffer level ? 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 next. Niklas Söderlund (9): 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: Consolidate information about formats 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 | 297 ++++++++++++++ src/libcamera/pipeline/ipu3/cio2.h | 68 ++++ src/libcamera/pipeline/ipu3/ipu3.cpp | 497 +++++------------------- src/libcamera/pipeline/ipu3/meson.build | 1 + 4 files changed, 469 insertions(+), 394 deletions(-) create mode 100644 src/libcamera/pipeline/ipu3/cio2.cpp create mode 100644 src/libcamera/pipeline/ipu3/cio2.h