From patchwork Tue Mar 12 12:12:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacopo Mondi X-Patchwork-Id: 715 Return-Path: Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 971E5600FC for ; Tue, 12 Mar 2019 13:12:19 +0100 (CET) X-Originating-IP: 2.224.242.101 Received: from uno.lan (2-224-242-101.ip172.fastwebnet.it [2.224.242.101]) (Authenticated sender: jacopo@jmondi.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0DC461C000A; Tue, 12 Mar 2019 12:12:18 +0000 (UTC) From: Jacopo Mondi To: libcamera-devel@lists.libcamera.org Date: Tue, 12 Mar 2019 13:12:28 +0100 Message-Id: <20190312121242.2253-1-jacopo@jmondi.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v2 00/14] libcamera: ipu3: ImgU support X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 12:12:19 -0000 Hello, v2 of ImgU support series for Intel IPU3 devices. Rebased on top of recent master, which includes Laurent's rework of request completion handling, which removes a few hacks compared to v1. I have included review comments on patchs 3-11 which now look nicer. Patches 1 and 2 adds a few updates to v4l2-subdevice to get a string representation of a format and shorten the image format enumeration type name. The less-nice part are patches 13 and 14. The first one limits the default output resolution to 2560x1920, as the maximum resolutions reported by image sensors installed on Soraka are not processed correctly by the ImgU device. There might be some issue to be clarified regarding alignement and scaling constraints. Resolutions up to 2560x1920 have been verified successfully. 14/14 enable links on the ImgU instance, which is more tricky then expected. Links enable on one instance interfere with capture operations of the other one, and thus links should be disabled when the ImgU is not in use. Unfortunately, I'm struggling to find what the right place to do so would be, and for now I simply disable all links in the ImgU media graph at streamConfiguration time. I have confirmed that viewfinder and stat output have to be linked and queued with buffers to have the main output video device produce frames. I have tried removing linking, configuration and buffer queueing of the two (singularly and together) and what I get is the capture application to freeze uninterruptedly without any frame being produced on the ImgU main output. If this behaviour is intended or not should probably be clarified with IPU3 driver developers. Tested on Soraka, inspecting images at various resolutions (1920x1080, 2560x1920, 640x480) from both front and back camera. Thanks j Jacopo Mondi (14): libcamera: formats: Add toString() methods libcamera: v4l2_subdevice: Define format enumeration type libcamera: ipu3: Get default image sizes from sensor libcamera: ipu3: Initialize and configure CIO2 libcamera: ipu3: Initialize and configure ImgUs libcamera: ipu3: Propagate image format libcamera: ipu3: Implement camera start/stop libcamera: ipu3: Implement buffer allocation libcamera: ipu3: Implement buffer release libcamera: ipu3: Queue requests to the pipeline libcamera: ipu3: Connect CIO2 and ImgU bufferReady signals libcamera: ipu3: Use NV12 as default image format HACK: Soraka: Limit resolution to 2560x1920 RFC: libcamera: ipu3: Enable ImgU media links src/libcamera/include/v4l2_device.h | 2 + src/libcamera/include/v4l2_subdevice.h | 7 +- src/libcamera/pipeline/ipu3/ipu3.cpp | 1093 ++++++++++++++++++++---- src/libcamera/v4l2_device.cpp | 18 + src/libcamera/v4l2_subdevice.cpp | 32 +- 5 files changed, 978 insertions(+), 174 deletions(-) --- 2.20.1