From patchwork Tue Jan 22 18:12:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacopo Mondi X-Patchwork-Id: 325 Return-Path: Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 20B6260B23 for ; Tue, 22 Jan 2019 19:12:23 +0100 (CET) Received: from uno.lan (2-224-242-101.ip172.fastwebnet.it [2.224.242.101]) (Authenticated sender: jacopo@jmondi.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id A32AC10000C; Tue, 22 Jan 2019 18:12:22 +0000 (UTC) From: Jacopo Mondi To: libcamera-devel@lists.libcamera.org Date: Tue, 22 Jan 2019 19:12:23 +0100 Message-Id: <20190122181225.12922-1-jacopo@jmondi.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [libcamera-devel] [RFC 0/2] Add support for pipeline specific data to Cameras 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, 22 Jan 2019 18:12:23 -0000 RFC as I'm not sure about the idea of delegating ownership of platform data to Cameras, as that requires the pipeline handler to dynamically allocate the resources (if they go away at pipeline handler destruction time, is pointless to store them in Camera). The other way around is the idea of borrowing pipeline handler data to Cameras, but as Cameras are shared objects, they might stay around longer that pipeline handlers, and thus I felt it is safer to tie the CameraData lifetime to the one of the Camera instance they're associated to. Thanks j Jacopo Mondi (2): libcamera: camera: Add CameraData libcamera: ipu3: Create CIO2 V4L2 devices include/libcamera/camera.h | 13 ++++++++ src/libcamera/camera.cpp | 50 ++++++++++++++++++++++++++++ src/libcamera/pipeline/ipu3/ipu3.cpp | 42 +++++++++++++++++++++++ 3 files changed, 105 insertions(+) --- 2.20.1