From patchwork Sat Mar 18 23:40:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Scally X-Patchwork-Id: 18409 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 DE542BD80A for ; Sat, 18 Mar 2023 23:40:34 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id F3305626EF; Sun, 19 Mar 2023 00:40:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org; s=mail; t=1679182834; bh=xDG0IXglEj2z6LvkNy5wFd9mcr8eol4s06vdo1ErnX8=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=XLSpHRCN5MRTpOBFQbW0taqzaGCg8KOyWprJwu6NMZAs+ecMzjdb+pKL9gWK7iWb5 0oL/qydkcQ9qx1khJ8xiXcajL4iBVb1oRBUskA+ZKhiosHURwcLOFQTR6l15bq3pJM Mofb6YhKx/vqoW4zMo7YIrF/xL6dXuXSo7hjyzb2A/RiMn5Vta/v5r/nVNjVdvMXAI 9Kiu+1JNVHTqB6E82VgC1YMbRNT+yj9wz1eQL9bXYrJc1VWV/tQPiG8lM26bGt3G6S EW5yJ5+hjzBnRHOUXTj+nMIpV/Op4TxvbQSS3YLWJyORy3bEc1Rcs//LJ8JpInZal1 j8E2qocXH4eiw== Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 0FE4F626D2 for ; Sun, 19 Mar 2023 00:40:32 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="S9MBZN2m"; dkim-atps=neutral Received: from mail.ideasonboard.com (cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net [86.13.91.161]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 649B9B6C; Sun, 19 Mar 2023 00:40:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1679182831; bh=xDG0IXglEj2z6LvkNy5wFd9mcr8eol4s06vdo1ErnX8=; h=From:To:Cc:Subject:Date:From; b=S9MBZN2mo9rGsKhk6+vHy1tP7LNFMMxoXUgFJY7IFNKlKfAyjSo/mN+cdV4uoqBWP ysNYTSAGp1SA9Qtv+DPN6yixA77WT+/IJbzUcWQDrlg6Qtd0r2zbaAzc9zihyfFazp z/Ir67b+RhKay4Q+LuB6cjvTm2vgWhHvg2UzMSKo= To: libcamera-devel@lists.libcamera.org Date: Sat, 18 Mar 2023 23:40:03 +0000 Message-Id: <20230318234014.29506-1-dan.scally@ideasonboard.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH 00/11] Support OV7251 in IPU3 pipeline and qcam 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: , X-Patchwork-Original-From: Daniel Scally via libcamera-devel From: Dan Scally Reply-To: Daniel Scally Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hello all This series is an attempt at adding support for the OV7251 camera on Microsoft Surface platforms to libcamera. The sensor outputs data in MEDIA_BUS_FMT_Y10_1X10 format, which is packed by the CIO2 CSI-2 reciever into V4L2_PIX_FMT_IPU3_Y10. As far as I know, these data are not intended to run through the Imgu at all. Certainly the kernel's ipu3-imgu driver does not support that format, but given the simplicity of the format we can simply use the CIO2 device's capture-capable devnode as the source of the image data. To facilitate that, I'm identifying sensors which don't have a format that needs the Imgu and simply skipping the Imgu/IPA processing in the IPU3 pipeline for them. What I don't particularly like about the way that I've done things here is that the stream only works for the Raw role, which feels wrong. The advantage is that it's contained within the existing IPU3 pipeline without too much disruption, but I do wonder whether a separate CIO2-only pipeline might not be better. In that case PipelineHandlerIPU3::match() would need amending to check whether the sensor for each "ipu3-csi-2 n" instance needed hooking into the Imgu and not adding those to the device match if it found that they didn't need it, so that a new CIO2-only pipeline could claim the media devices. I'd love to hear other people's thoughts about the best way to handle this. Thanks Dan Daniel Scally (11): pipeline: ipu3: Check if sensor supports test pattern control include: drm_fourcc: Add Y10 format libcamera/formats: Add IPU3_Y10 format pipeline: ipu3: Identify sensors that do not need the Imgu pipeline: ipu3: Add needsImgu flag to IPU3Frames pipeline: ipu3: Support sensors using only CIO2 pipeline: ipu3: Allow raw-only streams in IPU3 pipeline pipeline: ipu3: Support IPU3_Y10 format apps: qcam: Add support for IPU3_Y10 apps: qcam: Remove restriction on raw-only streams pipeline: ipu3: Increase maximum connected cameras include/linux/drm_fourcc.h | 3 + src/apps/qcam/format_converter.cpp | 50 +++++ src/apps/qcam/format_converter.h | 2 + src/apps/qcam/main_window.cpp | 6 - src/libcamera/formats.cpp | 10 + src/libcamera/formats.yaml | 3 + src/libcamera/pipeline/ipu3/cio2.cpp | 21 +++ src/libcamera/pipeline/ipu3/cio2.h | 4 + src/libcamera/pipeline/ipu3/frames.cpp | 45 +++-- src/libcamera/pipeline/ipu3/frames.h | 3 +- src/libcamera/pipeline/ipu3/ipu3.cpp | 242 ++++++++++++++----------- 11 files changed, 255 insertions(+), 134 deletions(-)