From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33788C43460 for ; Thu, 29 Apr 2021 08:46:39 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8349561040 for ; Thu, 29 Apr 2021 08:46:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8349561040 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Fyuom3D4+OCRgZ6CFx5mOMiaGjz7a7/L2Qlj4aZvbK8=; b=Qy2r3TWCKJsVn7EAkQzXQHJl5 xIcic+EimUy03ve4/J71xL4f5sSkth8BKwnG8z/WYTIP0ouRqYorI+RuC+Oalm4Cq34M0Y8WmL75t 3kkVebBcGeB7SMWIVXpaVRkQFCd5tV+1VOoHx0Uexm0j8L7OOCV4dPySoNMtg/IsLnTBi0bJC6Oay tz501/NfAZ4qBhHfuuNncFrOAcqKbErSGarACl9EQLFRufn7eyztg1qZqUew/q6THd5EkXSH0u+5v HcPnb21ohe1EF4/Es9E/BzS1UP+BpWEX9acWPtAYqkSyuak/MVMyYQvulZ2ylCQKYKewoFzAEcc6s lE8iYXvQQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lc2I7-005LmH-5H; Thu, 29 Apr 2021 08:44:59 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lc2I4-005Lm7-5H for linux-arm-kernel@desiato.infradead.org; Thu, 29 Apr 2021 08:44:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description; bh=9NVrn0NiC5dFM5oL9ZsuUP33/wymCpsuwGpN9fIScKA=; b=4cvF4GYB9HWVlALOW3gtd7AwxA hyH0nVBHTuNNPVhUG9zph6KzV/gMkTqh1zFx+l4RdSHw7Qwd+q4AOZuy28HsnMbvqeVjXzk/q0oXz Xq8Rbxtx4/C9btCJFlk5seAuQXX6QMp/43N+EYFJEUmSdBBvJbkEg5m0BTA/EX0WixivrqwdMPors 8Cl7BKL2i6I2Al7NLdmHsoUSjIO+f/TfS8XLGTMUwa93l3dhLjzokuAds5ZgaDlc1f53ATpFsnBBN IewxCD1AlAlcuukI3W3fIeQDrJVjZx2rQSQfgVF+A0GtKMlUOABSr1EYNof5W3nsk4V3ho1reV9vK na0cxT4Q==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lc2Hy-000Uw9-2U for linux-arm-kernel@lists.infradead.org; Thu, 29 Apr 2021 08:44:54 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 138D3613CC; Thu, 29 Apr 2021 08:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619685889; bh=nreTIL12xFUZvcTt96xXR/SXb8AuvPvSOpFf5HLbZBk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ctm04I2L0o3FWHtSWTxE2sQX1e+ZmPA5xsrdUhXKKaW8D+JLzhpvrWKpOuSvnLtXx hTDc4pYn65X695XUfiFQOUwoqVA4SUmM11S4aoKAgRJjyqmpHGQLZ7KHLUBrDA2GGH p8WZA84JGK703LsszUILEkGefqaTcCPxWsLJdPfhohHqCTz7w+OBR+LySL/kAeyKtv xwEuHOJkDEEPKXKk2bMovqcj/idehQwNAzKoNd1o/5gSAOco95JBuS+aeNYCeJbTSu nDJbuuv23IGBSos6VNYrz1yqAZhdMLJENlE6A/HbKpFNjXX2mbmWJkXbtf/twEu0YM 4JzILU/CZ1k4w== Date: Thu, 29 Apr 2021 10:44:41 +0200 From: Mauro Carvalho Chehab To: Marco Felsch Cc: Laurent Pinchart , p.zabel@pengutronix.de, slongerbeam@gmail.com, hverkuil-cisco@xs4all.nl, sakari.ailus@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats Message-ID: <20210429104441.3e85d81b@coco.lan> In-Reply-To: <20210429074903.cc5gohn52cgv4i5z@pengutronix.de> References: <20210427120701.21809-1-m.felsch@pengutronix.de> <20210427120701.21809-2-m.felsch@pengutronix.de> <20210429074903.cc5gohn52cgv4i5z@pengutronix.de> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210429_014450_227703_EF4688EA X-CRM114-Status: GOOD ( 23.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu: > Hi Laurent, > > On 21-04-29 04:51, Laurent Pinchart wrote: > > Hi Marco, > > > > Thank you for the patch. > > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote: > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array > > > with the interleaved IR pixels looks like: > > > > > > | G | R | G | B | ... > > > +----+----+----+----+--- > > > | IR | G | IR | G | ... > > > +----+----+----+----+--- > > > | G | B | G | R | ... > > > +----+----+----+----+--- > > > | IR | G | IR | G | ... > > > +----+----+----+----+--- > > > | .. | .. | .. | .. | .. > > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf > > > > I think we're reaching a limit of the media bus codes model here, due to > > a historical mistake. The four possible Bayer patterns, times the > > different number of bits per pixel, creates a lot of media bus codes, > > and drivers for CSI-2 receivers and IP cores further down the pipeline > > have to support them all. > > That's correct but it is not bayer related. Err... there are two separate things here: 1) for the uAPI part, we're not even close to the limit of a 4-bytes fourcc; 2) the kAPI is currently sharing the same fourcc from the uAPI, because it is a lot simpler than doing something different. Yet, nothing prevents that the kAPI could be improved in order to better describe each format, provided that: 1. there will be a 1:1 mapping with the uAPI. In other words, it would be possible to write a function that would convert a "struct foo" from/to a 32-bits fourcc; 2. such new kAPI should be optional, as usually only drivers for hardware with ISP (plus the UVC driver) would be flexible enough to allow random formats. For the rest, the bridges are typically limited to support only a few formats, so it doesn't make sense to modify existing drivers to use such new kAPI. Ok, someone has to come up with a proposal about what a "struct foo" would contain. On a real quick brainstorm, something like this could be a start: enum v4l2_pixformat_type { VIDEO_PIXFORMAT_RGB, VIDEO_PIXFORMAT_YUV, VIDEO_PIXFORMAT_COMPRESSED, VIDEO_PIXFORMAT_BAYER_RGB, VIDEO_PIXFORMAT_BAYER_RGB_IR, }; struct v4l2_pixformat_desc { enum v4l2_pixformat_type pixfmt_type; bool is_packed; int bits_per_component; union { enum v4l2_pixformat_rgb_order rgb_order; enum v4l2_pixformat_yuv_order yuv_order; enum v4l2_pixformat_bayer_rgb_order bayer_rgb_order; enum v4l2_pixformat_bayer_rgb_ir_order bayer_rgb_ir_order; enum v4l2_pixformat_compress_type compress_type; }; ... }; Btw, I remember someone suggested a model similar to that in the past, shared with DRM. Well, I don't think it would be easy to share an internal subsystem-specific kAPI like that with other subsystems, as this is the kind of thing that people will change from time to time, and coordinating something like that can be painful, but we can try to fork the model applied to DRM on media. For instance, I doubt that Bayer RGB + IR would make any sense for DRM drivers. Thanks, Mauro _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB8E2C433B4 for ; Thu, 29 Apr 2021 08:44:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AAB31613CC for ; Thu, 29 Apr 2021 08:44:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239885AbhD2Ipm (ORCPT ); Thu, 29 Apr 2021 04:45:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:49704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239903AbhD2Ipg (ORCPT ); Thu, 29 Apr 2021 04:45:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 138D3613CC; Thu, 29 Apr 2021 08:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619685889; bh=nreTIL12xFUZvcTt96xXR/SXb8AuvPvSOpFf5HLbZBk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ctm04I2L0o3FWHtSWTxE2sQX1e+ZmPA5xsrdUhXKKaW8D+JLzhpvrWKpOuSvnLtXx hTDc4pYn65X695XUfiFQOUwoqVA4SUmM11S4aoKAgRJjyqmpHGQLZ7KHLUBrDA2GGH p8WZA84JGK703LsszUILEkGefqaTcCPxWsLJdPfhohHqCTz7w+OBR+LySL/kAeyKtv xwEuHOJkDEEPKXKk2bMovqcj/idehQwNAzKoNd1o/5gSAOco95JBuS+aeNYCeJbTSu nDJbuuv23IGBSos6VNYrz1yqAZhdMLJENlE6A/HbKpFNjXX2mbmWJkXbtf/twEu0YM 4JzILU/CZ1k4w== Date: Thu, 29 Apr 2021 10:44:41 +0200 From: Mauro Carvalho Chehab To: Marco Felsch Cc: Laurent Pinchart , p.zabel@pengutronix.de, slongerbeam@gmail.com, hverkuil-cisco@xs4all.nl, sakari.ailus@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats Message-ID: <20210429104441.3e85d81b@coco.lan> In-Reply-To: <20210429074903.cc5gohn52cgv4i5z@pengutronix.de> References: <20210427120701.21809-1-m.felsch@pengutronix.de> <20210427120701.21809-2-m.felsch@pengutronix.de> <20210429074903.cc5gohn52cgv4i5z@pengutronix.de> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu: > Hi Laurent, > > On 21-04-29 04:51, Laurent Pinchart wrote: > > Hi Marco, > > > > Thank you for the patch. > > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote: > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array > > > with the interleaved IR pixels looks like: > > > > > > | G | R | G | B | ... > > > +----+----+----+----+--- > > > | IR | G | IR | G | ... > > > +----+----+----+----+--- > > > | G | B | G | R | ... > > > +----+----+----+----+--- > > > | IR | G | IR | G | ... > > > +----+----+----+----+--- > > > | .. | .. | .. | .. | .. > > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf > > > > I think we're reaching a limit of the media bus codes model here, due to > > a historical mistake. The four possible Bayer patterns, times the > > different number of bits per pixel, creates a lot of media bus codes, > > and drivers for CSI-2 receivers and IP cores further down the pipeline > > have to support them all. > > That's correct but it is not bayer related. Err... there are two separate things here: 1) for the uAPI part, we're not even close to the limit of a 4-bytes fourcc; 2) the kAPI is currently sharing the same fourcc from the uAPI, because it is a lot simpler than doing something different. Yet, nothing prevents that the kAPI could be improved in order to better describe each format, provided that: 1. there will be a 1:1 mapping with the uAPI. In other words, it would be possible to write a function that would convert a "struct foo" from/to a 32-bits fourcc; 2. such new kAPI should be optional, as usually only drivers for hardware with ISP (plus the UVC driver) would be flexible enough to allow random formats. For the rest, the bridges are typically limited to support only a few formats, so it doesn't make sense to modify existing drivers to use such new kAPI. Ok, someone has to come up with a proposal about what a "struct foo" would contain. On a real quick brainstorm, something like this could be a start: enum v4l2_pixformat_type { VIDEO_PIXFORMAT_RGB, VIDEO_PIXFORMAT_YUV, VIDEO_PIXFORMAT_COMPRESSED, VIDEO_PIXFORMAT_BAYER_RGB, VIDEO_PIXFORMAT_BAYER_RGB_IR, }; struct v4l2_pixformat_desc { enum v4l2_pixformat_type pixfmt_type; bool is_packed; int bits_per_component; union { enum v4l2_pixformat_rgb_order rgb_order; enum v4l2_pixformat_yuv_order yuv_order; enum v4l2_pixformat_bayer_rgb_order bayer_rgb_order; enum v4l2_pixformat_bayer_rgb_ir_order bayer_rgb_ir_order; enum v4l2_pixformat_compress_type compress_type; }; ... }; Btw, I remember someone suggested a model similar to that in the past, shared with DRM. Well, I don't think it would be easy to share an internal subsystem-specific kAPI like that with other subsystems, as this is the kind of thing that people will change from time to time, and coordinating something like that can be painful, but we can try to fork the model applied to DRM on media. For instance, I doubt that Bayer RGB + IR would make any sense for DRM drivers. Thanks, Mauro