From patchwork Fri Apr 26 15:33:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 792494 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B2C1148854 for ; Fri, 26 Apr 2024 15:33:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714145615; cv=none; b=X+n47rEqP+UZ4920Em9g+OBxD9MEq+xJzzXsdSjRDcUi+v7RmI0ufZLL8z0E39YcEOUPhMLPKkrrurUOnLsnpkAFYE8LSoZekzJwj+sJVc5jOAYzHaO3bXva52McwnGS2Y9jfyB90FyY0mfS03zpv+wsrtcvNsRlrHuEkOYp6ew= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714145615; c=relaxed/simple; bh=g3TtjgLkYlygqyNCwe8Gl6ON/BKmy/yXjDCndIobHQ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rYIM0UwXJjvF2ZcRTrbbPf4u6y7pBBI0Yjde7Hk42+l04JmpIU2ERhwZs+kQGto7yPPJ6JX/91kQXF+lFtBSSmm8KGrTweU7wS1H0mXqHj6MxmkvvHhGEifNb0NOC4DVHpYzi01hR8NlBFHftd2IXLqHUD9L2lXVhTRybDyY9Uc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=MRnjVJql; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="MRnjVJql" Received: from pendragon.ideasonboard.com (117.145-247-81.adsl-dyn.isp.belgacom.be [81.247.145.117]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7753E2B3; Fri, 26 Apr 2024 17:32:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1714145553; bh=g3TtjgLkYlygqyNCwe8Gl6ON/BKmy/yXjDCndIobHQ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MRnjVJqlKaZ3yqSqKMXBzpOfEQe5Q0xEHee1rLc9qbH/COVHYBeJ3Yj2TQ3cdH0So RVoPlMtiIjBn4X7nozqraSwwXj0TDvQc+j/xRIGiARLLCj0/1ybo+VTd+PYQMYOVDj e2HgggS3pWeoYcDJ7t2TcuWwXOf/JEBZpr856ySY= From: Laurent Pinchart To: linux-media@vger.kernel.org Cc: Sakari Ailus , Tomi Valkeinen , bingbu.cao@intel.com, hongju.wang@intel.com, Hans Verkuil , Jacopo Mondi , Dmitry Perchanov , Ng Khai Wen , Alain Volmat Subject: [PATCH] media: uapi: v4l: Don't expose generic metadata formats to userspace Date: Fri, 26 Apr 2024 18:33:19 +0300 Message-ID: <20240426153319.26872-1-laurent.pinchart@ideasonboard.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 The generic metadata pixel formats (V4L2_META_FMT_GENERIC_*) are meant to be used in conjunction with device-specific media bus codes. Those codes are work in progress and not available in the upstream kernel yet. To make sure the generic metadata pixel formats won't be used by userspace until we have the full infrastructure in place, keep their definition private to the kernel for now. Signed-off-by: Laurent Pinchart --- This patch can be squashed with "[PATCH v3 05/14] media: uapi: v4l: Add generic 8-bit metadata format definitions" or kept separate. --- include/uapi/linux/videodev2.h | 2 ++ 1 file changed, 2 insertions(+) base-commit: 5a6272f644afa3db2f00e77ff8b0ea9df51ea875 diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index f74aca14044f..1c0bb4f9ecac 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -842,6 +842,7 @@ struct v4l2_pix_format { #define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /* Rockchip ISP1 3A Parameters */ #define V4L2_META_FMT_RK_ISP1_STAT_3A v4l2_fourcc('R', 'K', '1', 'S') /* Rockchip ISP1 3A Statistics */ +#ifdef __KERNEL__ /* * Line-based metadata formats. Remember to update v4l_fill_fmtdesc() when * adding new ones! @@ -853,6 +854,7 @@ struct v4l2_pix_format { #define V4L2_META_FMT_GENERIC_CSI2_16 v4l2_fourcc('M', 'C', '1', 'G') /* 16-bit CSI-2 packed 8-bit metadata */ #define V4L2_META_FMT_GENERIC_CSI2_20 v4l2_fourcc('M', 'C', '1', 'K') /* 20-bit CSI-2 packed 8-bit metadata */ #define V4L2_META_FMT_GENERIC_CSI2_24 v4l2_fourcc('M', 'C', '1', 'O') /* 24-bit CSI-2 packed 8-bit metadata */ +#endif /* priv field value to indicates that subsequent fields are valid. */ #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe From patchwork Fri Apr 26 08:50:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792817 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D94213C903 for ; Fri, 26 Apr 2024 08:50:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121448; cv=none; b=JwE4krf15psK1kHU45DpIBe/7Tmw44MzcWeryHlTyzQRRHYl5VkyTdlPhetoM5rX08dl7M+RVRe0eQzYTbFeNbmE5KjkJAL+xLTigOKWBdE6Z0BAJ4WbuXmqJFvt/vXppyYZH9d9EbiFIPKUVCK2BAInsQ+FsOwq3gx4vdex/Bg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121448; c=relaxed/simple; bh=L5gyJjmTdCe1rwv2ccnxWiayZxdHhgsZ6mGNe3CfpvQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=k8ofC/xoGKIsirwgyB+8rGaEDi5uycqb3LrwJMprP88QwbQ51EZ9jqiW6hqeNaC0KwUtgyE0s+QlGUrxcU9F2RRtYKOuKx9ENop9K2eTGRFPkcZuJHgWvyIkVFY5LEfaRIYkAuWA/OzueurAerJMCSs7RVqPvaGNMR+2U189mXQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=UmcipGX4; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="UmcipGX4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121447; x=1745657447; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=L5gyJjmTdCe1rwv2ccnxWiayZxdHhgsZ6mGNe3CfpvQ=; b=UmcipGX42fpbOHBDtBQ9g5uqOf7rPxINQc0dX7jRhPyt38afbeVqcspT zfDwB4ARTLllJbE8PHDMYY8Nglw3qkL5f5PTLk8kmtk35OK0HkgmqGWde 9vTKML1je5kywKrXaoAG5yLRcuJRWXO6ZGVGujX6HvAcMrUEbpFqnXm0S YN2i3sXiQzbdVT/IrirK8Ihg9RzFnfVI9Bqqf7uWPuFl927RhGLD7DW+z PTmlN5JWlILtMd5Uxlltmjy5fkl7e5YS1CEG+MU+pyA9xv35ntPfE3QL/ zm1Dv6CQDw7c7nNm0dh915dUAwNrvCipOwZCZSCbYJFrqJGtbEdpktABm Q==; X-CSE-ConnectionGUID: 4WU6sgzLQPWAt1CJ5cMo2A== X-CSE-MsgGUID: DUgMsMvRQa6EQHAgA2xtXg== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683787" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683787" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:47 -0700 X-CSE-ConnectionGUID: SpRPKlmtROix4D1ScKi3+A== X-CSE-MsgGUID: otqjub2rQ/ybsaYmqmMB3Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598500" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:44 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 4EFAB120358; Fri, 26 Apr 2024 11:50:41 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 02/14] media: Documentation: Add "stream" into glossary Date: Fri, 26 Apr 2024 11:50:26 +0300 Message-Id: <20240426085038.943733-3-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Add term "stream" to the glossary of the Media subsystem documentation. Signed-off-by: Sakari Ailus Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart --- Documentation/userspace-api/media/glossary.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst index 96a360edbf3b..5759f4c78398 100644 --- a/Documentation/userspace-api/media/glossary.rst +++ b/Documentation/userspace-api/media/glossary.rst @@ -173,6 +173,11 @@ Glossary An integrated circuit that integrates all components of a computer or other electronic systems. + Stream + A distinct flow of data (image data or metadata) from an initial source + to a final sink. The initial source may be e.g. an image sensor and the + final sink e.g. a memory buffer. + V4L2 API **V4L2 userspace API** From patchwork Fri Apr 26 08:50:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792519 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8B7213CFBA for ; Fri, 26 Apr 2024 08:50:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121450; cv=none; b=LlzUAqSEwHhjI6OFt4aetCg2Zh/B944f0tRDGZXzXi34z9LvaLbm9SctgSyXHkVJF2U5koxGOCer+ZD2plSVUtXiy6jJ5gr2HJvY+7MVvO12TTpZIQLTEX8rISuaDhBX10iDKudq85FOwzOvG9kO2cb5vNgyXWoEdM03K/a/YsQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121450; c=relaxed/simple; bh=kosgVd86wxg8v4UmcCQD+QSQsC4uzINuWWW/Ndr3b8s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rB0Mpw1kX5wvXTmX7kPIgcVFmCS0lgwsJ7k7BD0+48hRAcOW+x+peFT0WmLUx1N9U7xXUKO4gAl3ojHU5Xnze9ivpEw9sMnX2uzJeNYK1AUrqMwO6+cUMdnVL9QdbBFF6iNhQaVj0IrDZa5mUmQ6S10Ivbolj7Xns7/TmM8aAi4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=OCrEZpEr; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="OCrEZpEr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121449; x=1745657449; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kosgVd86wxg8v4UmcCQD+QSQsC4uzINuWWW/Ndr3b8s=; b=OCrEZpErhrGI8xs4Fk7w41nv/ugHqh38z5EZdgiBHFi9wN3wvzKQfbvv Lhrfa09ZjNNuk4NZKj6Kh1ZiqCpWqGRckBtQ20vh0/baU6GUAkRH5lbhh XXruFo26vdTNFzjiM81Pd0T7GaNJkL9DLjG6i6TZVSdk3Hx6oOTsnR3S1 zlbOJkBWZziwVFHpo3P48DwaFDzlfpRboGhKQ/pdMCpYX3aTaS2/6Sgyj tdVKrFSdJY7NmgfmPyq6vKQwoVwBjv+gSrS2HeNyCbkkjm+4qBTDNGftC xUqzDW0StflD13sWQoZsQKzyVSPbxxjJE1BIkuwuAd9Fs/t3oExVCa+rk g==; X-CSE-ConnectionGUID: 5TK4G8hGTx2tlOZa+VZqLw== X-CSE-MsgGUID: TX1UANLJTQyGNOKI6xiT7g== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683792" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683792" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:48 -0700 X-CSE-ConnectionGUID: tS2RQ8l+R3e+fiXX+U7WXA== X-CSE-MsgGUID: 96eCJJTsTeK9j6P4b7kFVA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598503" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:46 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 937201203ED; Fri, 26 Apr 2024 11:50:42 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 03/14] media: uapi: Add generic serial metadata mbus formats Date: Fri, 26 Apr 2024 11:50:27 +0300 Message-Id: <20240426085038.943733-4-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Add generic serial metadata mbus formats. These formats describe data width and packing but not the content itself. The reason for specifying such formats is that the formats as such are fairly device specific but they are still handled by CSI-2 receiver drivers that should not be aware of device specific formats. What makes generic metadata formats possible is that these formats are parsed by software only, after capturing the data to system memory. Also add a definition for "Data Unit" to cover what is essentially a pixel but is not image data. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- .../userspace-api/media/glossary.rst | 7 + .../media/v4l/subdev-formats.rst | 254 ++++++++++++++++++ include/uapi/linux/media-bus-format.h | 9 + 3 files changed, 270 insertions(+) diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst index 5759f4c78398..55a9c37130ba 100644 --- a/Documentation/userspace-api/media/glossary.rst +++ b/Documentation/userspace-api/media/glossary.rst @@ -25,6 +25,13 @@ Glossary See :ref:`cec`. + Data Unit + + Unit of data transported by a bus. On parallel buses, the data unit + consists of one or more related samples while on serial buses the data + unit is logical. If the data unit is image data, it may also be called a + pixel. + Device Driver Part of the Linux Kernel that implements support for a hardware component. diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index eb3cd20b0cf2..c2cebf61d528 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -8306,3 +8306,257 @@ The following table lists the existing metadata formats. both sides of the link and the bus format is a fixed metadata format that is not configurable from userspace. Width and height will be set to 0 for this format. + +Generic Serial Metadata Formats +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Generic serial metadata formats are used on serial buses where the actual data +content is more or less device specific but the data is transmitted and received +by multiple devices that do not process the data in any way, simply writing +it to system memory for processing in software at the end of the pipeline. + +"b" in an array cell signifies a byte of data, followed by the number of the bit +and finally the bit number in subscript. "x" indicates a padding bit. + +.. _media-bus-format-generic-meta: + +.. cssclass: longtable + +.. flat-table:: Generic Serial Metadata Formats + :header-rows: 2 + :stub-columns: 0 + + * - Identifier + - Code + - + - :cspan:`23` Data organization within bus :term:`Data Unit` + * - + - + - Bit + - 23 + - 22 + - 21 + - 20 + - 19 + - 18 + - 17 + - 16 + - 15 + - 14 + - 13 + - 12 + - 11 + - 10 + - 9 + - 8 + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + * .. _MEDIA-BUS-FMT-META-8: + + - MEDIA_BUS_FMT_META_8 + - 0x8001 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + * .. _MEDIA-BUS-FMT-META-10: + + - MEDIA_BUS_FMT_META_10 + - 0x8002 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + * .. _MEDIA-BUS-FMT-META-12: + + - MEDIA_BUS_FMT_META_12 + - 0x8003 + - + - + - + - + - + - + - + - + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + - x + - x + * .. _MEDIA-BUS-FMT-META-14: + + - MEDIA_BUS_FMT_META_14 + - 0x8004 + - + - + - + - + - + - + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + - x + - x + - x + - x + * .. _MEDIA-BUS-FMT-META-16: + + - MEDIA_BUS_FMT_META_16 + - 0x8005 + - + - + - + - + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + - x + - x + - x + - x + - x + - x + * .. _MEDIA-BUS-FMT-META-20: + + - MEDIA_BUS_FMT_META_20 + - 0x8006 + - + - + - + - + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + * .. _MEDIA-BUS-FMT-META-24: + + - MEDIA_BUS_FMT_META_24 + - 0x8007 + - + - b0\ :sub:`7` + - b0\ :sub:`6` + - b0\ :sub:`5` + - b0\ :sub:`4` + - b0\ :sub:`3` + - b0\ :sub:`2` + - b0\ :sub:`1` + - b0\ :sub:`0` + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x + - x diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index f05f747e444d..d4c1d991014b 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -174,4 +174,13 @@ */ #define MEDIA_BUS_FMT_METADATA_FIXED 0x7001 +/* Generic line based metadata formats for serial buses. Next is 0x8008. */ +#define MEDIA_BUS_FMT_META_8 0x8001 +#define MEDIA_BUS_FMT_META_10 0x8002 +#define MEDIA_BUS_FMT_META_12 0x8003 +#define MEDIA_BUS_FMT_META_14 0x8004 +#define MEDIA_BUS_FMT_META_16 0x8005 +#define MEDIA_BUS_FMT_META_20 0x8006 +#define MEDIA_BUS_FMT_META_24 0x8007 + #endif /* __LINUX_MEDIA_BUS_FORMAT_H */ From patchwork Fri Apr 26 08:50:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792816 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1455F13C903 for ; Fri, 26 Apr 2024 08:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121451; cv=none; b=Q+AX8udNsC998+OtumaTaQrz95q8JWRb1L/sxSw2/Cvhkk35z/eI+sBd5RjPm6j2xyzly/58qKwacnjizvH8FQtJQaOKAIQlDMyakW2MJbAw1hOtBQ/2qtgdEY/CEhFoUNZaYZS27ThABPV75e3deaDnNprvvCBJQKRqgr/Xgqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121451; c=relaxed/simple; bh=hPkWuebURDTnjgrDczHg74a8jgVwuwoW30hYjRm6jPQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pVUOz40cQ17F4LfU3O080TZctIZcw3SjrVqHsVpNI0f+RzG+5ecmC72iZyVMq4Lsb9I3t2P4N0pvwsCp0VtpKhFpHtcyorlSHYkL5wwlaiWRt8R2C1lwZzdyHz0742BxcwsCJ+LSii9xIhHq2z7scONCjlzUeRdi92Bbtxt/Zuw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Tj8JTcUZ; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Tj8JTcUZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121450; x=1745657450; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hPkWuebURDTnjgrDczHg74a8jgVwuwoW30hYjRm6jPQ=; b=Tj8JTcUZSC5BYnGnS+mReAVtUu2ATZ58dNzzr4REHn3qw55NJsI8c8dt ysfToofgjAuat/4PQ6Iv2KHa3Ye730lNP/AUwJk/Sp3JBxL0jUwjiYCIj eB/Q+2HAt4W153XYbvr6ktDIRPwcQWxFVlMC7/7RiuHOKZ8B0Rel7al8t GMK1kCsEw/3fbbEL7dejhIvqCfhLuf7YpHZgZy9R41C+n2OMgwn/g8ya4 bMzpIubXqKxPdskw1pLnFS/t+GO32PMT9Q8FUB2WPC9UIpZKVGm8bIGk3 p+ZtJ7/gyL+Vg6CFQmjYS5aaPspa1edIm5q//pg+l02u0JdswHv3fLUcl A==; X-CSE-ConnectionGUID: 94NYwvtITeCf3oYLJegJ3w== X-CSE-MsgGUID: HSxRgyXgQXqvWiV4cmgDOA== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683798" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683798" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:50 -0700 X-CSE-ConnectionGUID: FsUQGfEySQSI7cIVCBx4Mg== X-CSE-MsgGUID: HqNU2MNlRS+uiJ+SmgZgtg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598506" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:47 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 0698112067F; Fri, 26 Apr 2024 11:50:43 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 04/14] media: uapi: Document which mbus format fields are valid for metadata Date: Fri, 26 Apr 2024 11:50:28 +0300 Message-Id: <20240426085038.943733-5-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Now that metadata mbus formats have been added, it is necessary to define which fields in struct v4l2_mbus_format are applicable to them (not many). Signed-off-by: Sakari Ailus Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart --- .../userspace-api/media/v4l/subdev-formats.rst | 15 ++++++++------- include/uapi/linux/v4l2-mediabus.h | 18 ++++++++++++------ 2 files changed, 20 insertions(+), 13 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index c2cebf61d528..d2a6cd2e1eb2 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -33,7 +33,7 @@ Media Bus Formats * - __u32 - ``field`` - Field order, from enum :c:type:`v4l2_field`. See - :ref:`field-order` for details. + :ref:`field-order` for details. Zero for metadata mbus codes. * - __u32 - ``colorspace`` - Image colorspace, from enum :c:type:`v4l2_colorspace`. @@ -45,7 +45,7 @@ Media Bus Formats conversion is supported by setting the flag V4L2_SUBDEV_MBUS_CODE_CSC_COLORSPACE in the corresponding struct :c:type:`v4l2_subdev_mbus_code_enum` during enumeration. - See :ref:`v4l2-subdev-mbus-code-flags`. + See :ref:`v4l2-subdev-mbus-code-flags`. Zero for metadata mbus codes. * - union { - (anonymous) * - __u16 @@ -61,7 +61,7 @@ Media Bus Formats that ycbcr_enc conversion is supported by setting the flag V4L2_SUBDEV_MBUS_CODE_CSC_YCBCR_ENC in the corresponding struct :c:type:`v4l2_subdev_mbus_code_enum` during enumeration. - See :ref:`v4l2-subdev-mbus-code-flags`. + See :ref:`v4l2-subdev-mbus-code-flags`. Zero for metadata mbus codes. * - __u16 - ``hsv_enc`` - HSV encoding, from enum :c:type:`v4l2_hsv_encoding`. @@ -75,7 +75,7 @@ Media Bus Formats that hsv_enc conversion is supported by setting the flag V4L2_SUBDEV_MBUS_CODE_CSC_HSV_ENC in the corresponding struct :c:type:`v4l2_subdev_mbus_code_enum` during enumeration. - See :ref:`v4l2-subdev-mbus-code-flags` + See :ref:`v4l2-subdev-mbus-code-flags`. Zero for metadata mbus codes. * - } - * - __u16 @@ -90,8 +90,8 @@ Media Bus Formats The driver indicates that quantization conversion is supported by setting the flag V4L2_SUBDEV_MBUS_CODE_CSC_QUANTIZATION in the corresponding struct :c:type:`v4l2_subdev_mbus_code_enum` - during enumeration. See :ref:`v4l2-subdev-mbus-code-flags`. - + during enumeration. See :ref:`v4l2-subdev-mbus-code-flags`. Zero for + metadata mbus codes. * - __u16 - ``xfer_func`` - Transfer function, from enum :c:type:`v4l2_xfer_func`. @@ -104,7 +104,8 @@ Media Bus Formats The driver indicates that the transfer function conversion is supported by setting the flag V4L2_SUBDEV_MBUS_CODE_CSC_XFER_FUNC in the corresponding struct :c:type:`v4l2_subdev_mbus_code_enum` - during enumeration. See :ref:`v4l2-subdev-mbus-code-flags`. + during enumeration. See :ref:`v4l2-subdev-mbus-code-flags`. Zero for + metadata mbus codes. * - __u16 - ``flags`` - flags See: :ref:v4l2-mbus-framefmt-flags diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h index 6b07b73473b5..946520bc49f1 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -19,12 +19,18 @@ * @width: image width * @height: image height * @code: data format code (from enum v4l2_mbus_pixelcode) - * @field: used interlacing type (from enum v4l2_field) - * @colorspace: colorspace of the data (from enum v4l2_colorspace) - * @ycbcr_enc: YCbCr encoding of the data (from enum v4l2_ycbcr_encoding) - * @hsv_enc: HSV encoding of the data (from enum v4l2_hsv_encoding) - * @quantization: quantization of the data (from enum v4l2_quantization) - * @xfer_func: transfer function of the data (from enum v4l2_xfer_func) + * @field: used interlacing type (from enum v4l2_field), zero for metadata + * mbus codes + * @colorspace: colorspace of the data (from enum v4l2_colorspace), zero on + * metadata mbus codes + * @ycbcr_enc: YCbCr encoding of the data (from enum v4l2_ycbcr_encoding), zero + * for metadata mbus codes + * @hsv_enc: HSV encoding of the data (from enum v4l2_hsv_encoding), zero for + * metadata mbus codes + * @quantization: quantization of the data (from enum v4l2_quantization), zero + * for metadata mbus codes + * @xfer_func: transfer function of the data (from enum v4l2_xfer_func), zero + * for metadata mbus codes * @flags: flags (V4L2_MBUS_FRAMEFMT_*) * @reserved: reserved bytes that can be later used */ From patchwork Fri Apr 26 08:50:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792518 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4036113D29B for ; Fri, 26 Apr 2024 08:50:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121454; cv=none; b=n3SEBm+RL0LgGB7lnoD05PZTJIbwOBmDlJ+ALeWBLPm6AjS5TGueH67vYquWXxtEwdRX+U6K7GM539H5XU5GvGbxMBIUgcipaPn5fzhTZ68KPLhZZxLS8ohmzZSKPV7Onvs3bcdDDYsJrTLOfSTBvBdhbBramogRs9h34Yt45Vk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121454; c=relaxed/simple; bh=jUjiv2SseKlh5j2L5lBn1Yitd0lrTXuXJsn0aSHAq7g=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LAoTKj8HjPpjKBl+JIqx+BMTrnL/BRcD9xNzv5jQ52XehwLAk2VJAkdz0CyTTOx1wQ2XOxMS/cgt+cav3IP1Ml0VxUK4ejaEHG4B97nKuqhT0GII7OEJ5KLDEZ5FAIZihZrVF6aShs2B6NZP+aaQFtmWtexA+wYAuJ6YsDlDc9s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Dlje8p0N; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Dlje8p0N" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121452; x=1745657452; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jUjiv2SseKlh5j2L5lBn1Yitd0lrTXuXJsn0aSHAq7g=; b=Dlje8p0NAQOKkcYv3sjq4N3U1Sffz8YOltEIzc3ZKTuJeGgmja8LP8p6 sjA75GQ4wJTEipwhIDsTmZGV9UfMA2HcszwZNByEtpdC318LI4GFuGdhI vHCcM6yK/c/UXSWz0BaOfy7MLMzpgLP2OiBiK/JwlraR0/RHu8oSqeNnQ KDOvqp3uvW7VqcCGO9vF1MHvZaT9uqIqWQxzkeud2EAf1mSmrJuHEbfS2 Y8MnwGLR0O/xLMIG5ldnMo/RnuZD1AjACr6fwldfIq7qG05sfpHCGngIb ZSDeQ7zVib9E6YxIbUvOcYKGg6+I5FW3pBr8xVqlca7ilv2DbEeKYhY2u g==; X-CSE-ConnectionGUID: g8PReRpzRaKidfT74P+pQw== X-CSE-MsgGUID: VZI5dm0VRlm1rXCZG5A6qg== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683803" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683803" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:52 -0700 X-CSE-ConnectionGUID: R4L5iSJcR0eUowZPWexYkQ== X-CSE-MsgGUID: tzHq3bi2T9WqQepBWtvr7Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598510" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:49 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 8CF9011F855; Fri, 26 Apr 2024 11:50:45 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 05/14] media: uapi: v4l: Add generic 8-bit metadata format definitions Date: Fri, 26 Apr 2024 11:50:29 +0300 Message-Id: <20240426085038.943733-6-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Generic 8-bit metadata formats define the in-memory data layout but not the format of the data itself. The reasoning for having such formats is to allow CSI-2 receiver drivers to receive and DMA drivers to write the data to memory without knowing a large number of device-specific formats. These formats may be used only in conjunction with a Media Controller pipeline where the internal pad of the source sub-device defines the specific format of the data (using an mbus code). Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- .../userspace-api/media/v4l/dev-subdev.rst | 2 + .../userspace-api/media/v4l/meta-formats.rst | 3 +- .../media/v4l/metafmt-generic.rst | 340 ++++++++++++++++++ drivers/media/v4l2-core/v4l2-ioctl.c | 7 + include/uapi/linux/videodev2.h | 8 + 5 files changed, 359 insertions(+), 1 deletion(-) create mode 100644 Documentation/userspace-api/media/v4l/metafmt-generic.rst diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst index 43988516acdd..f375b820ab68 100644 --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst @@ -506,6 +506,8 @@ source pads. subdev-formats +.. _subdev-routing: + Streams, multiplexed media pads and internal routing ---------------------------------------------------- diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst index 0bb61fc5bc00..c23aac823d2c 100644 --- a/Documentation/userspace-api/media/v4l/meta-formats.rst +++ b/Documentation/userspace-api/media/v4l/meta-formats.rst @@ -13,9 +13,10 @@ These formats are used for the :ref:`metadata` interface only. :maxdepth: 1 metafmt-d4xx + metafmt-generic metafmt-intel-ipu3 metafmt-rkisp1 metafmt-uvc + metafmt-vivid metafmt-vsp1-hgo metafmt-vsp1-hgt - metafmt-vivid diff --git a/Documentation/userspace-api/media/v4l/metafmt-generic.rst b/Documentation/userspace-api/media/v4l/metafmt-generic.rst new file mode 100644 index 000000000000..78ab56b21682 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/metafmt-generic.rst @@ -0,0 +1,340 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later + +******************************************************************************************************************************************************************************************************************************************************************************** +V4L2_META_FMT_GENERIC_8 ('MET8'), V4L2_META_FMT_GENERIC_CSI2_10 ('MC1A'), V4L2_META_FMT_GENERIC_CSI2_12 ('MC1C'), V4L2_META_FMT_GENERIC_CSI2_14 ('MC1E'), V4L2_META_FMT_GENERIC_CSI2_16 ('MC1G'), V4L2_META_FMT_GENERIC_CSI2_20 ('MC1K'), V4L2_META_FMT_GENERIC_CSI2_24 ('MC1O') +******************************************************************************************************************************************************************************************************************************************************************************** + + +Generic line-based metadata formats + + +Description +=========== + +These generic line-based metadata formats define the memory layout of the data +without defining the format or meaning of the metadata itself. + +.. _v4l2-meta-fmt-generic-8: + +V4L2_META_FMT_GENERIC_8 +----------------------- + +The V4L2_META_FMT_GENERIC_8 format is a plain 8-bit metadata format. This format +is used on CSI-2 for 8 bits per :term:`Data Unit`. + +Additionally it is used for 16 bits per Data Unit when two bytes of metadata are +packed into one 16-bit Data Unit. Otherwise the 16 bits per pixel dataformat is +:ref:`V4L2_META_FMT_GENERIC_CSI2_16 `. + +**Byte Order Of V4L2_META_FMT_GENERIC_8.** +Each cell is one byte. "M" denotes a byte of metadata. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - M\ :sub:`10` + - M\ :sub:`20` + - M\ :sub:`30` + * - start + 4: + - M\ :sub:`01` + - M\ :sub:`11` + - M\ :sub:`21` + - M\ :sub:`31` + +.. _v4l2-meta-fmt-generic-csi2-10: + +V4L2_META_FMT_GENERIC_CSI2_10 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_10 contains 8-bit generic metadata packed in 10-bit +Data Units, with one padding byte after every four bytes of metadata. This +format is typically used by CSI-2 receivers with a source that transmits +MEDIA_BUS_FMT_META_10 and the CSI-2 receiver writes the received data to memory +as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +This format is also used in conjunction with 20 bits per :term:`Data Unit` +formats that pack two bytes of metadata into one Data Unit. Otherwise the +20 bits per pixel dataformat is :ref:`V4L2_META_FMT_GENERIC_CSI2_20 +`. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_10.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - M\ :sub:`10` + - M\ :sub:`20` + - M\ :sub:`30` + - x + * - start + 5: + - M\ :sub:`01` + - M\ :sub:`11` + - M\ :sub:`21` + - M\ :sub:`31` + - x + +.. _v4l2-meta-fmt-generic-csi2-12: + +V4L2_META_FMT_GENERIC_CSI2_12 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_12 contains 8-bit generic metadata packed in 12-bit +Data Units, with one padding byte after every two bytes of metadata. This format +is typically used by CSI-2 receivers with a source that transmits +MEDIA_BUS_FMT_META_12 and the CSI-2 receiver writes the received data to memory +as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +This format is also used in conjunction with 24 bits per :term:`Data Unit` +formats that pack two bytes of metadata into one Data Unit. Otherwise the +24 bits per pixel dataformat is :ref:`V4L2_META_FMT_GENERIC_CSI2_24 +`. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_12.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{.8cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - M\ :sub:`10` + - x + - M\ :sub:`20` + - M\ :sub:`30` + - x + * - start + 6: + - M\ :sub:`01` + - M\ :sub:`11` + - x + - M\ :sub:`21` + - M\ :sub:`31` + - x + +.. _v4l2-meta-fmt-generic-csi2-14: + +V4L2_META_FMT_GENERIC_CSI2_14 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_14 contains 8-bit generic metadata packed in 14-bit +Data Units, with three padding bytes after every four bytes of metadata. This +format is typically used by CSI-2 receivers with a source that transmits +MEDIA_BUS_FMT_META_14 and the CSI-2 receiver writes the received data to memory +as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_14.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{.8cm}|p{.8cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - M\ :sub:`10` + - M\ :sub:`20` + - M\ :sub:`30` + - x + - x + - x + * - start + 7: + - M\ :sub:`01` + - M\ :sub:`11` + - M\ :sub:`21` + - M\ :sub:`31` + - x + - x + - x + +.. _v4l2-meta-fmt-generic-csi2-16: + +V4L2_META_FMT_GENERIC_CSI2_16 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_16 contains 8-bit generic metadata packed in 16-bit +Data Units, with one padding byte after every byte of metadata. This format is +typically used by CSI-2 receivers with a source that transmits +MEDIA_BUS_FMT_META_16 and the CSI-2 receiver writes the received data to memory +as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +Some devices support more efficient packing of metadata in conjunction with +16-bit image data. In that case the dataformat is +:ref:`V4L2_META_FMT_GENERIC_8 `. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_16.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{1.2cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - x + - M\ :sub:`10` + - x + - M\ :sub:`20` + - x + - M\ :sub:`30` + - x + * - start + 8: + - M\ :sub:`01` + - x + - M\ :sub:`11` + - x + - M\ :sub:`21` + - x + - M\ :sub:`31` + - x + +.. _v4l2-meta-fmt-generic-csi2-20: + +V4L2_META_FMT_GENERIC_CSI2_20 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_20 contains 8-bit generic metadata packed in 20-bit +Data Units, with alternating one or two padding bytes after every byte of +metadata. This format is typically used by CSI-2 receivers with a source that +transmits MEDIA_BUS_FMT_META_20 and the CSI-2 receiver writes the received data +to memory as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +Some devices support more efficient packing of metadata in conjunction with +16-bit image data. In that case the dataformat is +:ref:`V4L2_META_FMT_GENERIC_CSI2_10 `. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_20.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - x + - M\ :sub:`10` + - x + - x + - M\ :sub:`20` + - x + - M\ :sub:`30` + - x + - x + * - start + 10: + - M\ :sub:`01` + - x + - M\ :sub:`11` + - x + - x + - M\ :sub:`21` + - x + - M\ :sub:`31` + - x + - x + +.. _v4l2-meta-fmt-generic-csi2-24: + +V4L2_META_FMT_GENERIC_CSI2_24 +----------------------------- + +V4L2_META_FMT_GENERIC_CSI2_24 contains 8-bit generic metadata packed in 24-bit +Data Units, with two padding bytes after every byte of metadata. This format is +typically used by CSI-2 receivers with a source that transmits +MEDIA_BUS_FMT_META_24 and the CSI-2 receiver writes the received data to memory +as-is. + +The packing of the data follows the MIPI CSI-2 specification and the padding of +the data is defined in the MIPI CCS specification. + +Some devices support more efficient packing of metadata in conjunction with +16-bit image data. In that case the dataformat is +:ref:`V4L2_META_FMT_GENERIC_CSI2_12 `. + +This format is little endian. + +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_24.** +Each cell is one byte. "M" denotes a byte of metadata and "x" a byte of padding. + +.. tabularcolumns:: |p{2.4cm}|p{1.2cm}|p{.8cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{.8cm}|p{1.2cm}|p{.8cm}|p{.8cm}| + +.. flat-table:: Sample 4x2 Metadata Frame + :header-rows: 0 + :stub-columns: 0 + :widths: 12 8 8 8 8 8 8 8 8 8 8 8 8 + + * - start + 0: + - M\ :sub:`00` + - x + - x + - M\ :sub:`10` + - x + - x + - M\ :sub:`20` + - x + - x + - M\ :sub:`30` + - x + - x + * - start + 12: + - M\ :sub:`01` + - x + - x + - M\ :sub:`11` + - x + - x + - M\ :sub:`21` + - x + - x + - M\ :sub:`31` + - x + - x diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 5aeff5519407..ae2dca7f2817 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1460,6 +1460,13 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break; case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break; case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break; + case V4L2_META_FMT_GENERIC_8: descr = "8-bit Generic Metadata"; break; + case V4L2_META_FMT_GENERIC_CSI2_10: descr = "8-bit Generic Meta, 10b CSI-2"; break; + case V4L2_META_FMT_GENERIC_CSI2_12: descr = "8-bit Generic Meta, 12b CSI-2"; break; + case V4L2_META_FMT_GENERIC_CSI2_14: descr = "8-bit Generic Meta, 14b CSI-2"; break; + case V4L2_META_FMT_GENERIC_CSI2_16: descr = "8-bit Generic Meta, 16b CSI-2"; break; + case V4L2_META_FMT_GENERIC_CSI2_20: descr = "8-bit Generic Meta, 20b CSI-2"; break; + case V4L2_META_FMT_GENERIC_CSI2_24: descr = "8-bit Generic Meta, 24b CSI-2"; break; default: /* Compressed formats */ diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index bf12860d570a..0f44b8486ea8 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -839,6 +839,14 @@ struct v4l2_pix_format { #define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /* Rockchip ISP1 3A Parameters */ #define V4L2_META_FMT_RK_ISP1_STAT_3A v4l2_fourcc('R', 'K', '1', 'S') /* Rockchip ISP1 3A Statistics */ +#define V4L2_META_FMT_GENERIC_8 v4l2_fourcc('M', 'E', 'T', '8') /* Generic 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_10 v4l2_fourcc('M', 'C', '1', 'A') /* 10-bit CSI-2 packed 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_12 v4l2_fourcc('M', 'C', '1', 'C') /* 12-bit CSI-2 packed 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_14 v4l2_fourcc('M', 'C', '1', 'E') /* 14-bit CSI-2 packed 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_16 v4l2_fourcc('M', 'C', '1', 'G') /* 16-bit CSI-2 packed 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_20 v4l2_fourcc('M', 'C', '1', 'K') /* 20-bit CSI-2 packed 8-bit metadata */ +#define V4L2_META_FMT_GENERIC_CSI2_24 v4l2_fourcc('M', 'C', '1', 'O') /* 24-bit CSI-2 packed 8-bit metadata */ + /* priv field value to indicates that subsequent fields are valid. */ #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe From patchwork Fri Apr 26 08:50:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792517 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E1A313C9DE for ; Fri, 26 Apr 2024 08:50:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121455; cv=none; b=Qn4lD1Kj6EdtVM/R8GrSwN8l4+gGfPZA1PJxkOsHVcH5IaR3Pyn6vzTx6hV/YLyLTGf/HHBi28ZKw5rOt3LmINECZ8Wow6sPR2+5FiZ6PvirBzqQ4K9ca4maM4AU2NZQQVSeT/jPRzr2V5xvL4XYgB6fBQx5DNgweHzoM0ROat4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121455; c=relaxed/simple; bh=UiIFWJxyjKwA54XIiHVimZILpi5BbamlszO5RvS0mWA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=S9AIWr2cdvtmzzzBoqJKnBq62PZRiXgAHmv92WnuTIX1yViL/qiVMqVPKuNpiM5LoF8Erb8MRDYRw6QRE7dUx6QJqu1uqtiFT6VpYeVrbMjzZ3IujPpIuqxfZFWllwglNOe31ZiPXvpfVV5bEaaWZvl2dzApWH+uisDqqCpaLCk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=N/8RYxxq; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="N/8RYxxq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121455; x=1745657455; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=UiIFWJxyjKwA54XIiHVimZILpi5BbamlszO5RvS0mWA=; b=N/8RYxxqQu2ULsTCWf3ISL5+JxDu4pGXd6xM6gsHEr2+cIHPGbNxeKMS L4EowV8+wmSBW/SlWhi3pprCsIHCWTgLcmU2MZPAIBw1KxlW5gSyHwKPb r7GeirzFbQ6r0j8ILYqtK24DoUuZoJU1xJW/gse/UJYcMJ0B9FH0AWQju WS57FnYLnpilyXAOzX+P+7XR4Hfo+7gr5fkmionh4NnsjneigjAdD6fpP 4oQNxnMjrqngLRMQARZTQ0DfC3N39Ua64z0V+4bXu9FR5J8D8fW6pv3O5 CWdfV7PK5LLVFTIbJnqcOQCCG/MaFMxuLC2d3CfF1GtYwv0m3IWJZprKC Q==; X-CSE-ConnectionGUID: HFxq8UmuRPWkxkgpIs4n8g== X-CSE-MsgGUID: FRfMgfNvREi3COkhoXwDqQ== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683808" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683808" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:52 -0700 X-CSE-ConnectionGUID: 5iWYr0oeSjOmk10EUqlqEQ== X-CSE-MsgGUID: 1VNb6/WOSwOyW76J6xYWWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598512" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:50 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 0BDF611FA8A; Fri, 26 Apr 2024 11:50:46 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 06/14] media: v4l: Support line-based metadata capture Date: Fri, 26 Apr 2024 11:50:30 +0300 Message-Id: <20240426085038.943733-7-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Many camera sensors, among other devices, transmit embedded data and image data for each CSI-2 frame. This embedded data typically contains register configuration of the sensor that has been used to capture the image data of the same frame. The embedded data is received by the CSI-2 receiver and has the same properties as the image data, including that it is line based: it has width, height and bytesperline (stride). Add these fields to struct v4l2_meta_format and document them. Also add V4L2_FMT_FLAG_META_LINE_BASED to tell a given format is line-based i.e. these fields of struct v4l2_meta_format are valid for it. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- .../userspace-api/media/v4l/dev-meta.rst | 21 +++++++++++++++++++ .../media/v4l/vidioc-enum-fmt.rst | 7 +++++++ .../media/videodev2.h.rst.exceptions | 1 + drivers/media/v4l2-core/v4l2-ioctl.c | 5 +++-- include/uapi/linux/videodev2.h | 10 +++++++++ 5 files changed, 42 insertions(+), 2 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/dev-meta.rst b/Documentation/userspace-api/media/v4l/dev-meta.rst index 0e7e1ee1471a..5eee9ab60395 100644 --- a/Documentation/userspace-api/media/v4l/dev-meta.rst +++ b/Documentation/userspace-api/media/v4l/dev-meta.rst @@ -47,6 +47,12 @@ member of the ``fmt`` union as needed per the desired operation. Both drivers and applications must set the remainder of the :c:type:`v4l2_format` structure to 0. +Devices that capture metadata by line have the struct v4l2_fmtdesc +``V4L2_FMT_FLAG_META_LINE_BASED`` flag set for :c:func:`VIDIOC_ENUM_FMT`. Such +devices can typically also :ref:`capture image data `. This primarily +involves devices that receive the data from a different devices such as a camera +sensor. + .. c:type:: v4l2_meta_format .. tabularcolumns:: |p{1.4cm}|p{2.4cm}|p{13.5cm}| @@ -65,3 +71,18 @@ to 0. - ``buffersize`` - Maximum buffer size in bytes required for data. The value is set by the driver. + * - __u32 + - ``width`` + - Width of a line of metadata in Data Units. Valid when + :c:type`v4l2_fmtdesc` flag ``V4L2_FMT_FLAG_META_LINE_BASED`` is set, + otherwise zero. See :c:func:`VIDIOC_ENUM_FMT`. + * - __u32 + - ``height`` + - Number of rows of metadata. Valid when :c:type`v4l2_fmtdesc` flag + ``V4L2_FMT_FLAG_META_LINE_BASED`` is set, otherwise zero. See + :c:func:`VIDIOC_ENUM_FMT`. + * - __u32 + - ``bytesperline`` + - Offset in bytes between the beginning of two consecutive lines. Valid + when :c:type`v4l2_fmtdesc` flag ``V4L2_FMT_FLAG_META_LINE_BASED`` is + set, otherwise zero. See :c:func:`VIDIOC_ENUM_FMT`. diff --git a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst index 000c154b0f98..3adb3d205531 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst @@ -227,6 +227,13 @@ the ``mbus_code`` field is handled differently: The application can ask to configure the quantization of the capture device when calling the :ref:`VIDIOC_S_FMT ` ioctl with :ref:`V4L2_PIX_FMT_FLAG_SET_CSC ` set. + * - ``V4L2_FMT_FLAG_META_LINE_BASED`` + - 0x0200 + - The metadata format is line-based. In this case the ``width``, + ``height`` and ``bytesperline`` fields of :c:type:`v4l2_meta_format` are + valid. The buffer consists of ``height`` lines, each having ``width`` + Data Units of data and the offset (in bytes) between the beginning of + each two consecutive lines is ``bytesperline``. Return Value ============ diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 3e58aac4ef0b..bdc628e8c1d6 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -215,6 +215,7 @@ replace define V4L2_FMT_FLAG_CSC_XFER_FUNC fmtdesc-flags replace define V4L2_FMT_FLAG_CSC_YCBCR_ENC fmtdesc-flags replace define V4L2_FMT_FLAG_CSC_HSV_ENC fmtdesc-flags replace define V4L2_FMT_FLAG_CSC_QUANTIZATION fmtdesc-flags +replace define V4L2_FMT_FLAG_META_LINE_BASED fmtdesc-flags # V4L2 timecode types replace define V4L2_TC_TYPE_24FPS timecode-type diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index ae2dca7f2817..2cfc9106857a 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -343,8 +343,9 @@ static void v4l_print_format(const void *arg, bool write_only) case V4L2_BUF_TYPE_META_OUTPUT: meta = &p->fmt.meta; pixelformat = meta->dataformat; - pr_cont(", dataformat=%p4cc, buffersize=%u\n", - &pixelformat, meta->buffersize); + pr_cont(", dataformat=%p4cc, buffersize=%u, width=%u, height=%u, bytesperline=%u\n", + &pixelformat, meta->buffersize, meta->width, + meta->height, meta->bytesperline); break; } } diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 0f44b8486ea8..647ce3419bd8 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -877,6 +877,7 @@ struct v4l2_fmtdesc { #define V4L2_FMT_FLAG_CSC_YCBCR_ENC 0x0080 #define V4L2_FMT_FLAG_CSC_HSV_ENC V4L2_FMT_FLAG_CSC_YCBCR_ENC #define V4L2_FMT_FLAG_CSC_QUANTIZATION 0x0100 +#define V4L2_FMT_FLAG_META_LINE_BASED 0x0200 /* Frame Size and frame rate enumeration */ /* @@ -2424,10 +2425,19 @@ struct v4l2_sdr_format { * struct v4l2_meta_format - metadata format definition * @dataformat: little endian four character code (fourcc) * @buffersize: maximum size in bytes required for data + * @width: number of data units of data per line (valid for line + * based formats only, see format documentation) + * @height: number of lines of data per buffer (valid for line based + * formats only) + * @bytesperline: offset between the beginnings of two adjacent lines in + * bytes (valid for line based formats only) */ struct v4l2_meta_format { __u32 dataformat; __u32 buffersize; + __u32 width; + __u32 height; + __u32 bytesperline; } __attribute__ ((packed)); /** From patchwork Fri Apr 26 08:50:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792815 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 474A113CF85 for ; Fri, 26 Apr 2024 08:50:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121455; cv=none; b=bZThbbKoI/sJk0H7x+2eVRjERo2iNLB7yKpwTpEz3+QBTjLy3HGQ9B6RWTUM6bvpk1fh8ec5jcbCXhogVANHPiybr2xgBSLGUg1SIR/F4f9ZNlZ4MizIMmlkJEIsNh/fk+Kd584I7VPYmS6pcLx7/hV1hEuH1Xv8TCI4YRQCVxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121455; c=relaxed/simple; bh=4k+HZWL35942Ca8VTVz4rxPnzMzOqQshonyH4ZE7dW0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rxjsojJNcJyKQZgfiojLxZvrs9jQhwGmDgO33B+FS6HlxfzVdAsS5P+uhPQLu6AwyIOWCoSaqtxZHCQDFJ7+zyEI7MRzCphEs3/wGkSHxAo8ZM1NdfB2zYDQLKP/nyI/3G2UG9Dy4JlkXMUx2x+6RzkNpaUEMSf8T7JzlhCIwRM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MBruTl/7; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MBruTl/7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121454; x=1745657454; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=4k+HZWL35942Ca8VTVz4rxPnzMzOqQshonyH4ZE7dW0=; b=MBruTl/7M0LIQHMhokJrx6qo6zgopz1wx2wuTdBTXWiYh+V1NlAyyPDW HBFdmPsk1FcObE+6FV9JbZCWcNK4jIXTehg6yN3i/v2fJpWIx2iauEB6G RqqpN1gqa/wpRkzyiOY4Ar6HDEY2pvksDrA8FMgcssyKFfMvr7t3483JA +/d+tPdnRPVIlJo5jN3Vz8u8gozGcYbanW33kh39n0VIGXpA93MnZa5G+ 5VAIZfVz1s5bkJTqX6KszBfcrsVJVe+zbdxVaJeCBEViHKxbQCw22MnOd f8lxG9g+9cU635sdg8nRa4BXsiy8rw/uL30A54fIISKaVOeh6Qdw2Hn3S A==; X-CSE-ConnectionGUID: MTU0ZjAERWywneUUl1Bc/g== X-CSE-MsgGUID: Sc2R1fAjSiq52hKomyXXCw== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683813" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683813" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:54 -0700 X-CSE-ConnectionGUID: hTY7hqdRSb6hWPPBFOeqlg== X-CSE-MsgGUID: bjrRAbujQA2ECw7UVLc4nA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598517" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:51 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 4F231120358; Fri, 26 Apr 2024 11:50:48 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 07/14] media: v4l: Set line based metadata flag in V4L2 core Date: Fri, 26 Apr 2024 11:50:31 +0300 Message-Id: <20240426085038.943733-8-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Set (and unset) the V4L2_FMT_FLAG_META_LINE_BASED flag in struct v4l2_fmtdesc based on the format after returning the driver callback for enumerating formats. This way the drivers don't need to care about the flag. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- drivers/media/v4l2-core/v4l2-ioctl.c | 16 ++++++++++++++++ include/uapi/linux/videodev2.h | 4 ++++ 2 files changed, 20 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 2cfc9106857a..5e928e2a2beb 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1538,6 +1538,22 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) } } + if (fmt->type == V4L2_BUF_TYPE_META_CAPTURE) { + switch (fmt->pixelformat) { + case V4L2_META_FMT_GENERIC_8: + case V4L2_META_FMT_GENERIC_CSI2_10: + case V4L2_META_FMT_GENERIC_CSI2_12: + case V4L2_META_FMT_GENERIC_CSI2_14: + case V4L2_META_FMT_GENERIC_CSI2_16: + case V4L2_META_FMT_GENERIC_CSI2_20: + case V4L2_META_FMT_GENERIC_CSI2_24: + fmt->flags |= V4L2_FMT_FLAG_META_LINE_BASED; + break; + default: + fmt->flags &= ~V4L2_FMT_FLAG_META_LINE_BASED; + } + } + if (descr) WARN_ON(strscpy(fmt->description, descr, sz) < 0); fmt->flags |= flags; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 647ce3419bd8..d944db7ae1ed 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -839,6 +839,10 @@ struct v4l2_pix_format { #define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /* Rockchip ISP1 3A Parameters */ #define V4L2_META_FMT_RK_ISP1_STAT_3A v4l2_fourcc('R', 'K', '1', 'S') /* Rockchip ISP1 3A Statistics */ +/* + * Line-based metadata formats. Remember to update v4l_fill_fmtdesc() when + * adding new ones! + */ #define V4L2_META_FMT_GENERIC_8 v4l2_fourcc('M', 'E', 'T', '8') /* Generic 8-bit metadata */ #define V4L2_META_FMT_GENERIC_CSI2_10 v4l2_fourcc('M', 'C', '1', 'A') /* 10-bit CSI-2 packed 8-bit metadata */ #define V4L2_META_FMT_GENERIC_CSI2_12 v4l2_fourcc('M', 'C', '1', 'C') /* 12-bit CSI-2 packed 8-bit metadata */ From patchwork Fri Apr 26 08:50:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792814 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1DC613CAB7 for ; Fri, 26 Apr 2024 08:50:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121457; cv=none; b=N7I02dQHwSRgBvSAxhxro51Y5oVkdde/kM58e948UYAdjRSy/Q5WXMNdotkazEWnrXa2An7BYOcIjembJY73STz/3lWd6ZO5yf1mrlpArvCDRbw+c+5F6vRKHwVK8fNLLxubymX0wsATcxiBWv6EG5FTZ/fSTlqSV8P7wTcrJUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121457; c=relaxed/simple; bh=9NVcs+CPjK/NLXHVLxYJeBlkgHJ6cOnfdXWiFvZE//s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=K/wygHDQRe56Z4OiiMIiajmMjcoI4rZHMYlW9wLczFrt2RZZq36rhpOvMVkgpH0KxTsAQepXUuJ7wG6YHmfY8h2KsHGgmZ9PiOHJ3nK/M9IZSy8nOfYkzCQDFCOdoNJWt2HNzBZCw+i01PfgB7KjB6OCZmqZH18qu4rKPwxpOnc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aDcB7yyp; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aDcB7yyp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121456; x=1745657456; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9NVcs+CPjK/NLXHVLxYJeBlkgHJ6cOnfdXWiFvZE//s=; b=aDcB7yypcIYgNWI7GMfXt+u5zIeEKByIm00+1KDXCcnTKGO3kE0w2eMR Y9vQBPDc3TIalr9iqbBkL0InV98zjgzLfAtT4zFg2LghNKyywqAuWXT2d oDO7yNftD/En5L5CvpdsiV6n/1v9uZDMZj/D3BCJySqdUnWDUzvCWtxpA At8rqk6haTReTjtu3wxGNAmTh/kqiYy2CkHg5Y8nlXoLAlnztmNzgL0ca uRVsUeaHuByqvfV+YDVPWdqgTwa7Ro/RD8XQFk6kir1uV5gHm/n/II0TM 9oFdVUgmusI1Y3FZbrKj7RNsJ/QBcsKxgwl7nX9eC1SRnY+0/BnTtJ6eO Q==; X-CSE-ConnectionGUID: v345xABRSn+93Yxt8pBX/A== X-CSE-MsgGUID: VIFxQWCxQGeMblTYR0f6/Q== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683820" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683820" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:55 -0700 X-CSE-ConnectionGUID: RpPzXcHzS02F4xl6OH2X/Q== X-CSE-MsgGUID: /gJYeoZCQ8eg7NhbOgMK2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598522" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:52 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 926191203ED; Fri, 26 Apr 2024 11:50:49 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 08/14] media: Documentation: Additional streams generally don't harm capture Date: Fri, 26 Apr 2024 11:50:32 +0300 Message-Id: <20240426085038.943733-9-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Having extra streams on the source end of the link that cannot be captured by the sink sub-device generally are not an issue, at least not on CSI-2 bus. Still document that there may be hardware-specific limitations. For example on parallel bus this might not work on all cases. Signed-off-by: Sakari Ailus Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart --- Documentation/userspace-api/media/v4l/dev-subdev.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst index f375b820ab68..b76e02e54512 100644 --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst @@ -529,9 +529,9 @@ the its sink pad and allows to route them individually to one of its source pads. Subdevice drivers that support multiplexed streams are compatible with -non-multiplexed subdev drivers, but, of course, require a routing configuration -where the link between those two types of drivers contains only a single -stream. +non-multiplexed subdev drivers. However, if the driver at the sink end of a link +does not support streams, then only stream 0 of source end may be captured. +There may be additional limitations specific to the sink device. Understanding streams ^^^^^^^^^^^^^^^^^^^^^ From patchwork Fri Apr 26 08:50:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792516 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3501513D2B2 for ; Fri, 26 Apr 2024 08:50:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121458; cv=none; b=HfT9/WyO9cQ5v+ukUwHstKg5kgF5KwK+0U6hxvSCjiSE+8VUvGltcPeZYpSR2WPUmiMC7cHHUVcSNyEDn2UMR0KCVi6NTptg+f9+TTI4o5CXudktw8fcM//pZXYMyLSYvmkpwnkvvjAYiepefc5r6J2gPbx7A9OiAZZpoye4In0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121458; c=relaxed/simple; bh=jISX/u6dSeGJoondLr8S5bPfhwhM313glOQum48keW0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rDAdoGxed/E2CCuSK27y5KEVucIwXjCdvrrwRsQ4Vo4seVIZOJjX/MBSgfreW/7OhUBgL6GDsTH1E3Y4uFE4oj8DAJu9e+l+fhQBnahnV1Pk1d1Qiv8KzwIMLiV0PQuf7QIFZ+6HOP5VcwpUvZ2c4AIqE8BreGh6Ha9LCRw0Scg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lav0bfJ7; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lav0bfJ7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121457; x=1745657457; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jISX/u6dSeGJoondLr8S5bPfhwhM313glOQum48keW0=; b=lav0bfJ7bXJkdWhvoRNdmISf9k5I+ry8lj2MV7WpyGBD72dtHdwJYZGQ I693njsEHZdZlxy5VY+oFsx4Dk1ozbTlmJmL6QkTeAhYw/ZpTAAqqlloP LxkFS3Wj74CFC+e0X0GQujfGWoLU63aBJ+pO0NAxF4MlYgGr5DxX9Icrl X9Aj428D970u0gmnVoGH7sKWbUyyL3xwlUkNTjbqqVgfuJaC0Y8/mXlCA kX0kkseOK/lMJ0vD96M3vm7/21iphn3AV02gxoQvA8m2QaQR6svWnbl5l xKJ+1yNBmWXH9RNguoD83UzIWRMUtFDyTtEG1eHEZHNmqeV8zgjATsVV0 g==; X-CSE-ConnectionGUID: GA4j8NKDTlqcWEYrUurrRg== X-CSE-MsgGUID: btJK5fyxQNmjRPWVu9M85A== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683829" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683829" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:57 -0700 X-CSE-ConnectionGUID: 678zND38QS2tbGEQSkcfsw== X-CSE-MsgGUID: N07yxVw9ROK3T0zU/1jOkg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598531" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:54 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id ECE3412067F; Fri, 26 Apr 2024 11:50:50 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 09/14] media: Documentation: Document S_ROUTING behaviour Date: Fri, 26 Apr 2024 11:50:33 +0300 Message-Id: <20240426085038.943733-10-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Document S_ROUTING behaviour for different devices. Generally in devices that produce streams the streams are static and some can be enabled and disabled, whereas in devices that just transport them or write them to memory, more configurability is allowed. Document this. Signed-off-by: Sakari Ailus Reviewed-by: Julien Massot Reviewed-by: Laurent Pinchart --- .../userspace-api/media/v4l/dev-subdev.rst | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/Documentation/userspace-api/media/v4l/dev-subdev.rst b/Documentation/userspace-api/media/v4l/dev-subdev.rst index b76e02e54512..0f9eda3187f3 100644 --- a/Documentation/userspace-api/media/v4l/dev-subdev.rst +++ b/Documentation/userspace-api/media/v4l/dev-subdev.rst @@ -572,6 +572,29 @@ Any configurations of a stream within a pad, such as format or selections, are independent of similar configurations on other streams. This is subject to change in the future. +Device types and routing setup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Different kinds of sub-devices have differing behaviour for route activation, +depending on the hardware. In all cases, however, only routes that have the +``V4L2_SUBDEV_STREAM_FL_ACTIVE`` flag set are active. + +Devices generating the streams may allow enabling and disabling some of the +routes or have a fixed routing configuration. If the routes can be disabled, not +declaring the routes (or declaring them without +``VIDIOC_SUBDEV_STREAM_FL_ACTIVE`` flag set) in ``VIDIOC_SUBDEV_S_ROUTING`` will +disable the routes. ``VIDIOC_SUBDEV_S_ROUTING`` will still return such routes +back to the user in the routes array, with the ``V4L2_SUBDEV_STREAM_FL_ACTIVE`` +flag unset. + +Devices transporting the streams almost always have more configurability with +respect to routing. Typically any route between the sub-device's sink and source +pads is possible, and multiple routes (usually up to certain limited number) may +be active simultaneously. For such devices, no routes are created by the driver +and user-created routes are fully replaced when ``VIDIOC_SUBDEV_S_ROUTING`` is +called on the sub-device. Such newly created routes have the device's default +configuration for format and selection rectangles. + Configuring streams ^^^^^^^^^^^^^^^^^^^ From patchwork Fri Apr 26 08:50:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792813 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84E6713C9A0 for ; Fri, 26 Apr 2024 08:50:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121459; cv=none; b=tO4udToEzNu2JOzsxqQAV7KMGOzxIpz91WJwpEkGDqT0NiXAR6i94zv4UvMqqiHN0Krm99A5dfGGXj4ZtNjAX4sh/3KJDhZH5LBvvYXIDnG2WDMtuY48Rj96d03+17DnfkNmSACPbv0tqnDwjpWdnSDPlylR1zq8VXwDl08O+J8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121459; c=relaxed/simple; bh=iKlKjLWVWWEm2fX8ZeF4D+tdTozJyFKOhdNYkVekWfg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aTfq4Dfn0YL4YDmEj8TC5tRmOEFpo5dLmNTrP05V6q0QF0RcIYWVekAcTulFbM8nkKWCRuq6LK3t4q25zVxA7NQ65qxQvLQ35vFkcQql7UM8gCHDjlAKNvczuzeB9yvjUq2szVKydAWdQnS5Iao+9IQ7cVGMFJpkKuCZZcd2OgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HHCTvy7D; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HHCTvy7D" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121459; x=1745657459; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=iKlKjLWVWWEm2fX8ZeF4D+tdTozJyFKOhdNYkVekWfg=; b=HHCTvy7D/nrb8bp1pcWCmZNK31PqJ5/bJqlho9IOikCHvsRIwJfW5C3C fGnDNwMCK3k7EzhYMyJixVjNk0WQuNlxXmQAFGt5UWRhJSVBSI1m2J3GV UCYXS2UpsdYT7lewuHTE5nKoXjPwX2EomWmVI8XE6QkybAFM161Sg5ML1 Sb8PmQzorvdmXB+Hav+/J56cwp2i5L4JE9EWYSwftusl75EJN1BBjTq7v ibmCgIbI9b15/TPeQHB/51aUziTeO/GSu5vDBqsZA7W0tE+BBvTuGaHb6 zDNFM4RWdaNK0mtZmQJgrzljMBwQs9spc8zryHX9pgQO2iLf7FLnhq8Fv g==; X-CSE-ConnectionGUID: YojXfvZjQ7+Tc+FTiYJGjQ== X-CSE-MsgGUID: IITorpZRRIK/YcDCVBcumQ== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683835" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683835" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:58 -0700 X-CSE-ConnectionGUID: vx2lGcdMQH6zggx+cCfxdQ== X-CSE-MsgGUID: m3e1Mq2PQcejQm4go4m5og== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598536" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:55 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 7B67211F855; Fri, 26 Apr 2024 11:50:52 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 10/14] media: v4l: subdev: Add a function to lock two sub-device states, use it Date: Fri, 26 Apr 2024 11:50:34 +0300 Message-Id: <20240426085038.943733-11-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Add two new functions, v4l2_subdev_lock_states() and v4l2_subdev_unclock_states(), to acquire and release the state of two sub-devices. They differ from calling v4l2_subdev_{un,}lock_state() so that if the two states share the same lock, the lock is acquired only once. Also use the new functions in v4l2_subdev_link_validate(). Signed-off-by: Sakari Ailus Reviewed-by: Julien Massot Reviewed-by: Laurent Pinchart --- drivers/media/v4l2-core/v4l2-subdev.c | 12 +++----- include/media/v4l2-subdev.h | 40 +++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 8 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 2d67ec54569a..779583447eac 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -1437,17 +1437,13 @@ int v4l2_subdev_link_validate(struct media_link *link) states_locked = sink_state && source_state; - if (states_locked) { - v4l2_subdev_lock_state(sink_state); - v4l2_subdev_lock_state(source_state); - } + if (states_locked) + v4l2_subdev_lock_states(sink_state, source_state); ret = v4l2_subdev_link_validate_locked(link, states_locked); - if (states_locked) { - v4l2_subdev_unlock_state(sink_state); - v4l2_subdev_unlock_state(source_state); - } + if (states_locked) + v4l2_subdev_unlock_states(sink_state, source_state); return ret; } diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 1af16b16f0bf..e22c50ce7e05 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -1724,6 +1724,46 @@ static inline void v4l2_subdev_unlock_state(struct v4l2_subdev_state *state) mutex_unlock(state->lock); } +/** + * v4l2_subdev_lock_states - Lock two sub-device states + * @state1: One subdevice state + * @state2: The other subdevice state + * + * Locks the state of two sub-devices. + * + * The states must be unlocked with v4l2_subdev_unlock_states() after use. + * + * This differs from calling v4l2_subdev_lock_state() on both states so that if + * the states share the same lock, the lock is acquired only once (so no + * deadlock occurs). The caller is responsible for ensuring the locks will + * always be acquired in the same order. + */ +static inline void v4l2_subdev_lock_states(struct v4l2_subdev_state *state1, + struct v4l2_subdev_state *state2) +{ + mutex_lock(state1->lock); + if (state1->lock != state2->lock) + mutex_lock(state2->lock); +} + +/** + * v4l2_subdev_unlock_states() - Unlock two sub-device states + * @state1: One subdevice state + * @state2: The other subdevice state + * + * Unlocks the state of two sub-devices. + * + * This differs from calling v4l2_subdev_unlock_state() on both states so that + * if the states share the same lock, the lock is released only once. + */ +static inline void v4l2_subdev_unlock_states(struct v4l2_subdev_state *state1, + struct v4l2_subdev_state *state2) +{ + mutex_unlock(state1->lock); + if (state1->lock != state2->lock) + mutex_unlock(state2->lock); +} + /** * v4l2_subdev_get_unlocked_active_state() - Checks that the active subdev state * is unlocked and returns it From patchwork Fri Apr 26 08:50:35 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792515 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A91D13D89F for ; Fri, 26 Apr 2024 08:50:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121460; cv=none; b=s3IbnH8bKNDI+9Q1Kxgn9Ca9XyF6rIqqA5mi4QNulsJ3grD+xsB8N03IfU9QNu2ZG8SNWGB+X8rXKCf0j4zquDpqyDXA14JptZQW1Q/c6jVe5llulRcOnuCcJMhW3y9O9DgzXJ9rdjdvOowSnZLBu6uJIm7T2sg8DVy2QHS6Eig= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121460; c=relaxed/simple; bh=HWo70uAnzn4Nud/ID2UJzFa0xSOrIPMcp/Kd/BkRAak=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=KpuwwMkscCeKwATJmY/+D1KzqyUNiNHI6zMIUFErc0ptjo8dsHGVIsBOoC/j/3oDInRGlgSJiZ+D9NMYP53ykE07OEa0DawROiwm7v61WJOZ3BuKwQvBLPN+aIhBpcuDsJcpcC3R3sCLFixT5QMMEwaa+pkdUccwfK3PeYsHijs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=esSQJkQ2; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="esSQJkQ2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121459; x=1745657459; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HWo70uAnzn4Nud/ID2UJzFa0xSOrIPMcp/Kd/BkRAak=; b=esSQJkQ2bol35B5iWrCF4bkhx+vvt3QxTxvNmSJpGU3GUdmMh3Nf16Gg MjDQr8owFVN8un9KoFE3KSKEnvuEbnmNVm86CTuM0lMeBCOZHBk/xnwLq Ahb2lWmjPF9/VXc2xOkXQ/ExmFK72sXrqLudNBdnc3s4hWns29hUx/IWG yCasiK2KdwO9oqQGdR0jKZKDPhxsnD2jbYC4yb14vvi90JE0akiETMbdF rs4gEZeN7yBYJr+y3XKLwu62E6TCQWLBMF4WBqCP5TZfGaIotQZOMTOM1 UyH+Kdi0Xh33ZC5WAq7tpOwd/mbioL27tFSLgXHe2eDNgDwkbfBiH073K Q==; X-CSE-ConnectionGUID: 1DB2zjF9TU283iL7+dIbpA== X-CSE-MsgGUID: wwKW0jUwRtqhBmw4mH01+A== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683840" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683840" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:59 -0700 X-CSE-ConnectionGUID: FJlZJUMPQ/KXsOAOnG/+IA== X-CSE-MsgGUID: hkZXGFwJR0yY9SIhVU05mw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598541" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:57 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id B6F7711FA8A; Fri, 26 Apr 2024 11:50:53 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 11/14] media: v4l: subdev: Copy argument back to user also for S_ROUTING Date: Fri, 26 Apr 2024 11:50:35 +0300 Message-Id: <20240426085038.943733-12-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 As the user needs to know what went wrong for S_ROUTING, copy array arguments back to the user. Signed-off-by: Sakari Ailus Reviewed-by: Julien Massot Reviewed-by: Laurent Pinchart --- drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 5e928e2a2beb..0260acef97d2 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3461,11 +3461,14 @@ video_usercopy(struct file *file, unsigned int orig_cmd, unsigned long arg, * FIXME: subdev IOCTLS are partially handled here and partially in * v4l2-subdev.c and the 'always_copy' flag can only be set for IOCTLS * defined here as part of the 'v4l2_ioctls' array. As - * VIDIOC_SUBDEV_G_ROUTING needs to return results to applications even - * in case of failure, but it is not defined here as part of the + * VIDIOC_SUBDEV_[GS]_ROUTING needs to return results to applications + * even in case of failure, but it is not defined here as part of the * 'v4l2_ioctls' array, insert an ad-hoc check to address that. */ - if (err < 0 && !always_copy && cmd != VIDIOC_SUBDEV_G_ROUTING) + if (cmd == VIDIOC_SUBDEV_G_ROUTING || cmd == VIDIOC_SUBDEV_S_ROUTING) + always_copy = true; + + if (err < 0 && !always_copy) goto out; if (has_array_args) { From patchwork Fri Apr 26 08:50:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792812 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88CDC13D28E for ; Fri, 26 Apr 2024 08:51:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121463; cv=none; b=UJPvK7tQ91talENcVds7Bgz0QsvPxSMIHKmhakkfdVbvHxo//l7RHwalxcQf17ZTZ+gOwSv8Ybt0vLvguAklkMdNJC0ymfCnwqaFB5e6itpOpZFZrencltPXIXr8zGUgeZzd1brqWSu61Zx3Z33EcHJInrFiTLZZUSYy5ItVQqg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121463; c=relaxed/simple; bh=aihSxJbBmO6Y8Fy6lBBe1VwNPvUCi6Uf4Mevvukov8w=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NL10uMqWaExnwgPr18M4pQueYEhq4sOV+SXKR9oWyONDFQguUSCjGge5+ltR4FqAPFb5f6EeifXcrWZr/zGNfICgkHgLK79GuSxrhgYPEBM0TF2iDgfEureSkk94ntK7aIFI8P1oqGchQQ/IrDOe2KY2XOp2Xv5NgYbPnZwQ7gk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=dtQLzJkN; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="dtQLzJkN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121462; x=1745657462; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aihSxJbBmO6Y8Fy6lBBe1VwNPvUCi6Uf4Mevvukov8w=; b=dtQLzJkNosorPanVNuv7Gjl0B+GCyYoEhSJ0igs5ShFksYoBGNkXb9TL Pvr0zkauqY1J0Wiyo90N4ngPYMQdQ8utbwDS1Bb/mjEen3TLmtmmlHvgc tuh8o7nMirSTnwfyN6hIOpoUeXCb379/vgWetN0674J0VTybiv3UC6BeZ n/73O0vVYMudokJbLF87alElFMGiXoCDaiWKNXvObIuBwJo4IbRHEv2Cc eeLOgk2VjbKNk32KmB5Tphv8x+OEi3JauuP9rFdgn0NwoNpNM5oQKSzFy nwLuqodazQ8CTf/wt/C5ScGdgs5qOTjgDSX7v5LVmwP5IJOr242mujGid Q==; X-CSE-ConnectionGUID: XSWRvGc7SxiRntPROBRsiw== X-CSE-MsgGUID: E1AjfhPsRc+9D9al3e8LQA== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683846" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683846" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:51:01 -0700 X-CSE-ConnectionGUID: QltIegeTTluabW1Irp+1DQ== X-CSE-MsgGUID: M74SwB4bSAOvU1249Lf+RA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598548" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:50:58 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id F2238120358; Fri, 26 Apr 2024 11:50:54 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 12/14] media: v4l: subdev: Add len_routes field to struct v4l2_subdev_routing Date: Fri, 26 Apr 2024 11:50:36 +0300 Message-Id: <20240426085038.943733-13-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 The len_routes field is used to tell the size of the routes array in struct v4l2_subdev_routing. This way the number of routes returned from S_ROUTING IOCTL may be larger than the number of routes provided, in case there are more routes returned by the driver. Note that this uAPI is still disabled in the code, so this change can safely be done. Anyone who manually patched the code to enable this uAPI must update their code. The patch also increases the number of reserved fields in struct v4l2_subdev_routing. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- .../media/v4l/vidioc-subdev-g-routing.rst | 46 +++++++++++++------ drivers/media/v4l2-core/v4l2-ioctl.c | 4 +- drivers/media/v4l2-core/v4l2-subdev.c | 12 ++--- include/media/v4l2-subdev.h | 2 + include/uapi/linux/v4l2-subdev.h | 10 ++-- 5 files changed, 49 insertions(+), 25 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst index 26b5004bfe6d..cbd9370006b6 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst @@ -43,23 +43,38 @@ The routing configuration determines the flows of data inside an entity. Drivers report their current routing tables using the ``VIDIOC_SUBDEV_G_ROUTING`` ioctl and application may enable or disable routes with the ``VIDIOC_SUBDEV_S_ROUTING`` ioctl, by adding or removing routes and -setting or clearing flags of the ``flags`` field of a -struct :c:type:`v4l2_subdev_route`. +setting or clearing flags of the ``flags`` field of a struct +:c:type:`v4l2_subdev_route`. -All stream configurations are reset when ``VIDIOC_SUBDEV_S_ROUTING`` is called. This -means that the userspace must reconfigure all streams after calling the ioctl -with e.g. ``VIDIOC_SUBDEV_S_FMT``. +All stream configurations are reset when ``VIDIOC_SUBDEV_S_ROUTING`` is called. +This means that the userspace must reconfigure all stream formats and selections +after calling the ioctl with e.g. ``VIDIOC_SUBDEV_S_FMT``. Only subdevices which have both sink and source pads can support routing. -When inspecting routes through ``VIDIOC_SUBDEV_G_ROUTING`` and the application -provided ``num_routes`` is not big enough to contain all the available routes -the subdevice exposes, drivers return the ENOSPC error code and adjust the -value of the ``num_routes`` field. Application should then reserve enough memory -for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again. - -On a successful ``VIDIOC_SUBDEV_G_ROUTING`` call the driver updates the -``num_routes`` field to reflect the actual number of routes returned. +The ``len_routes`` field indicates the number of routes that can fit in the +``routes`` array allocated by userspace. It is set by applications for both +ioctls to indicate how many routes the kernel can return, and is never modified +by the kernel. + +The ``num_routes`` field indicates the number of routes in the routing +table. For ``VIDIOC_SUBDEV_S_ROUTING``, it is set by userspace to the number of +routes that the application stored in the ``routes`` array. For both ioctls, it +is returned by the kernel and indicates how many routes are stored in the +subdevice routing table. This may be smaller or larger than the value of +``num_routes`` set by the application for ``VIDIOC_SUBDEV_S_ROUTING``, as +drivers may adjust the requested routing table. + +The kernel can return a ``num_routes`` value larger than ``len_routes`` from +both ioctls. This indicates thare are more routes in the routing table than fits +the ``routes`` array. In this case, the ``routes`` array is filled by the kernel +with the first ``len_routes`` entries of the subdevice routing table. This is +not considered to be an error, and the ioctl call succeeds. If the applications +wants to retrieve the missing routes, it can issue a new +``VIDIOC_SUBDEV_G_ROUTING`` call with a large enough ``routes`` array. + +``VIDIOC_SUBDEV_S_ROUTING`` may return more routes than the user provided in +``num_routes`` field due to e.g. hardware properties. .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| @@ -74,6 +89,9 @@ On a successful ``VIDIOC_SUBDEV_G_ROUTING`` call the driver updates the - ``which`` - Routing table to be accessed, from enum :ref:`v4l2_subdev_format_whence `. + * - __u32 + - ``len_routes`` + - The length of the array (as in memory reserved for the array) * - struct :c:type:`v4l2_subdev_route` - ``routes[]`` - Array of struct :c:type:`v4l2_subdev_route` entries @@ -81,7 +99,7 @@ On a successful ``VIDIOC_SUBDEV_G_ROUTING`` call the driver updates the - ``num_routes`` - Number of entries of the routes array * - __u32 - - ``reserved``\ [5] + - ``reserved``\ [11] - Reserved for future extensions. Applications and drivers must set the array to zero. diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 0260acef97d2..aab671fae45b 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3201,13 +3201,13 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, case VIDIOC_SUBDEV_S_ROUTING: { struct v4l2_subdev_routing *routing = parg; - if (routing->num_routes > 256) + if (routing->len_routes > 256) return -E2BIG; *user_ptr = u64_to_user_ptr(routing->routes); *kernel_ptr = (void **)&routing->routes; *array_size = sizeof(struct v4l2_subdev_route) - * routing->num_routes; + * routing->len_routes; ret = 1; break; } diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 779583447eac..b565f202df67 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -960,14 +960,10 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, krouting = &state->routing; - if (routing->num_routes < krouting->num_routes) { - routing->num_routes = krouting->num_routes; - return -ENOSPC; - } - memcpy((struct v4l2_subdev_route *)(uintptr_t)routing->routes, krouting->routes, - krouting->num_routes * sizeof(*krouting->routes)); + min(krouting->num_routes, routing->len_routes) * + sizeof(*krouting->routes)); routing->num_routes = krouting->num_routes; return 0; @@ -989,6 +985,9 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, if (routing->which != V4L2_SUBDEV_FORMAT_TRY && ro_subdev) return -EPERM; + if (routing->num_routes > routing->len_routes) + return -EINVAL; + memset(routing->reserved, 0, sizeof(routing->reserved)); for (i = 0; i < routing->num_routes; ++i) { @@ -1015,6 +1014,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, } krouting.num_routes = routing->num_routes; + krouting.len_routes = routing->len_routes; krouting.routes = routes; return v4l2_subdev_call(sd, pad, set_routing, state, diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index e22c50ce7e05..e30c463d90e5 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -714,12 +714,14 @@ struct v4l2_subdev_stream_configs { /** * struct v4l2_subdev_krouting - subdev routing table * + * @len_routes: length of routes array, in routes * @num_routes: number of routes * @routes: &struct v4l2_subdev_route * * This structure contains the routing table for a subdev. */ struct v4l2_subdev_krouting { + unsigned int len_routes; unsigned int num_routes; struct v4l2_subdev_route *routes; }; diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h index 81a24bd38003..2347e266cf75 100644 --- a/include/uapi/linux/v4l2-subdev.h +++ b/include/uapi/linux/v4l2-subdev.h @@ -228,15 +228,19 @@ struct v4l2_subdev_route { * struct v4l2_subdev_routing - Subdev routing information * * @which: configuration type (from enum v4l2_subdev_format_whence) - * @num_routes: the total number of routes in the routes array + * @len_routes: the length of the routes array, in routes; set by the user, not + * modified by the kernel * @routes: pointer to the routes array + * @num_routes: the total number of routes, possibly more than fits in the + * routes array * @reserved: drivers and applications must zero this array */ struct v4l2_subdev_routing { __u32 which; - __u32 num_routes; + __u32 len_routes; __u64 routes; - __u32 reserved[6]; + __u32 num_routes; + __u32 reserved[11]; }; /* From patchwork Fri Apr 26 08:50:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792514 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C97E413DDB1 for ; Fri, 26 Apr 2024 08:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121465; cv=none; b=AbJ224kyuu34ba20tH2B5RfV3MswtsqU+OjY4u4UC1Iq05tRoICXfXt9bo0AcgLjcN29wW9WGodEjaBlvWuj3tgneCckGpeJ25AvVdwmBd1QAj5iJBe00HUYxdI1RhQzezPw/8xD8AQiTe7tRVxgbZnY1QyoiBqCPUVM0RAGfnA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121465; c=relaxed/simple; bh=KY+lx6CRHKbqxwavkV8vK3kxZ6KrOrEF/MbKTPBx2jQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gYx4/ZNX2v0wcuQAKL2ek1vyldb0gqSpc8MMgGtZjCDv5/SwkDFfOlV0dxLTtALgR8VTqmYek65jxPz9Gr028FWd9ppbbuXpXouvP0xqFhubLG03pSUPWGvfNma5h4MTHEngleK5jHorqzzprZNLzs5cGG0BkFCjR6PoUgSzrkc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=D3aZJFk8; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="D3aZJFk8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121463; x=1745657463; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KY+lx6CRHKbqxwavkV8vK3kxZ6KrOrEF/MbKTPBx2jQ=; b=D3aZJFk82AXsxVGcN2IhTM6yNP6RQvZgd60tOIAhQ9Jzs/jJuGdXZJpK zROzZWn4IRzq7mDo5Xexnz0jiLBbpmo/FZ0popstlceCo6vDBO+FJkULV xaHqj1wTNCdNDfbia/Bu+PkziMU4gJF6dloo2IV9bA5DEDPEn/fm/ILiW cEymt/suw94NwYvh2j+8ZLkhJaxEXi5WVb3F9oLm8sVyrr2rxC2zIS7dt AnwUXKMnN4hwp2vPpGSouwf1mqNQpblD46KsLVVq38EydbiDpLZUDnitZ Vpvfdp3QmFYZMMarHhGkL/foqfgPctRkx/kp+UHWTk3eGFUIlCX6+vq4J A==; X-CSE-ConnectionGUID: VLUnwySSSa6dL3gGFYOBvg== X-CSE-MsgGUID: FTT/0lVZRU+/U7bkrrhmKQ== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="13637483" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="13637483" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:51:02 -0700 X-CSE-ConnectionGUID: PGCrE9HkQb+9BhXqoQ/zAQ== X-CSE-MsgGUID: syYb2efBQpyIP+WwMVgCfA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="30010546" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:51:00 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id E57CE1203ED; Fri, 26 Apr 2024 11:50:56 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 13/14] media: v4l: subdev: Return routes set using S_ROUTING Date: Fri, 26 Apr 2024 11:50:37 +0300 Message-Id: <20240426085038.943733-14-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Return the routes set using S_ROUTING back to the user. Also reflect this in documentation. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- .../media/v4l/vidioc-subdev-g-routing.rst | 7 ++----- drivers/media/v4l2-core/v4l2-subdev.c | 12 +++++++++++- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst index cbd9370006b6..1cf795480602 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst @@ -44,7 +44,8 @@ Drivers report their current routing tables using the ``VIDIOC_SUBDEV_G_ROUTING`` ioctl and application may enable or disable routes with the ``VIDIOC_SUBDEV_S_ROUTING`` ioctl, by adding or removing routes and setting or clearing flags of the ``flags`` field of a struct -:c:type:`v4l2_subdev_route`. +:c:type:`v4l2_subdev_route`. Similarly to ``VIDIOC_SUBDEV_G_ROUTING``, also +``VIDIOC_SUBDEV_S_ROUTING`` returns the routes back to the user. All stream configurations are reset when ``VIDIOC_SUBDEV_S_ROUTING`` is called. This means that the userspace must reconfigure all stream formats and selections @@ -153,10 +154,6 @@ On success 0 is returned, on error -1 and the ``errno`` variable is set appropriately. The generic error codes are described at the :ref:`Generic Error Codes ` chapter. -ENOSPC - The application provided ``num_routes`` is not big enough to contain - all the available routes the subdevice exposes. - EINVAL The sink or source pad identifiers reference a non-existing pad or reference pads of different types (ie. the sink_pad identifiers refers to a source diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index b565f202df67..3d1ed8ab5229 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -1017,8 +1017,18 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, krouting.len_routes = routing->len_routes; krouting.routes = routes; - return v4l2_subdev_call(sd, pad, set_routing, state, + rval = v4l2_subdev_call(sd, pad, set_routing, state, routing->which, &krouting); + if (rval < 0) + return rval; + + memcpy((struct v4l2_subdev_route *)(uintptr_t)routing->routes, + state->routing.routes, + min(state->routing.num_routes, routing->len_routes) * + sizeof(*state->routing.routes)); + routing->num_routes = state->routing.num_routes; + + return 0; } case VIDIOC_SUBDEV_G_CLIENT_CAP: { From patchwork Fri Apr 26 08:50:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 792811 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2F9E13DDC1 for ; Fri, 26 Apr 2024 08:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121466; cv=none; b=A4Lzq+TNbdOtr/FpEjs9GklKoebxw4vrdG2O++d762gw6VHmNLvtPv3+QEeZ3PleNTg5dYHgFCCiQp5BwsbaoZLcSCfk4EKJlDkmrU0M5d49kWaWZXwG5pRRvxrLXw/jNVsww4MJupLtvCIKLsK9VeEBB2b34oCT8a2y8QZm85w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714121466; c=relaxed/simple; bh=vtKidzEiteD4Zt3ZEwOL3l5My0ctl6N0bmuqu/Q2EoA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=WYgIB/rZz8N0Ppw1SFR1rWL//uGggD39dxzXeu/PtU26SgkLfN1cbFjbIxSZFTezihoCamSZcQGgWEjW82x5Lrd/QwffctpyN9MG3b0ZLLJQl6bNtI2GBSnMv5aCl99b85iocTh5rVsj5VDbxaqNDUbuS+6NgtySHlub3JbQRRo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PZ5Ko/GS; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PZ5Ko/GS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714121464; x=1745657464; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vtKidzEiteD4Zt3ZEwOL3l5My0ctl6N0bmuqu/Q2EoA=; b=PZ5Ko/GSQAaUzbD2DcmO3mkBrXXcU74heDu4W/33i6dxrfAHXPYOsJcv z9xqtbVabP/KT9pKeQpB+3Sy6mSiMJieToNAVLG5I+n56kbdQ0gDNmXYs +aVUtyAY3Utp82cw3MwuoaOfVLsT26stKwbnL/HBeT8c9RBHD+hEjbbwL HowN5Da2n2rMOqy90uKoE0yE7DXsrqZjvevnGmDthJW/QDL/kKvZs9T9K mwA0HgnEskbGz6JiiL2ezFKdR937tfAGIcpGiEgoWCyOyWWMweeomGhw5 BkEQ5FiqDaeX0bA7TbKTloLX2MyIa3SI/RF+jw+54KYdhTZYqoyaAAGYo g==; X-CSE-ConnectionGUID: bqDqP7/8RAGH7f6aZo9NOQ== X-CSE-MsgGUID: ksNt+M29SLie0rsWcVBzpA== X-IronPort-AV: E=McAfee;i="6600,9927,11055"; a="9683854" X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="9683854" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:51:04 -0700 X-CSE-ConnectionGUID: InZ9BpngRwq9uvkkJhAGWw== X-CSE-MsgGUID: UCLSivM8QG2ueoRuQ0B8Pw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,232,1708416000"; d="scan'208";a="48598553" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2024 01:51:01 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 318F912067F; Fri, 26 Apr 2024 11:50:58 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Cc: Laurent Pinchart , tomi.valkeinen@ideasonboard.com, bingbu.cao@intel.com, hongju.wang@intel.com, hverkuil@xs4all.nl, Andrey Konovalov , Jacopo Mondi , Dmitry Perchanov , "Ng, Khai Wen" , Alain Volmat Subject: [PATCH v3 14/14] media: v4l: subdev: Add trivial set_routing support Date: Fri, 26 Apr 2024 11:50:38 +0300 Message-Id: <20240426085038.943733-15-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240426085038.943733-1-sakari.ailus@linux.intel.com> References: <20240426085038.943733-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Add trivial S_ROUTING IOCTL support for drivers where routing is static. Essentially this means returning the same information G_ROUTING call would have done. Signed-off-by: Sakari Ailus Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Reviewed-by: Julien Massot --- drivers/media/v4l2-core/v4l2-subdev.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 3d1ed8ab5229..8470d6eda9a3 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -1013,6 +1013,20 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, return -EINVAL; } + /* + * If the driver doesn't support setting routing, just return + * the routing table. + */ + if (!v4l2_subdev_has_op(sd, pad, set_routing)) { + memcpy((struct v4l2_subdev_route *)(uintptr_t)routing->routes, + state->routing.routes, + min(state->routing.num_routes, routing->len_routes) * + sizeof(*state->routing.routes)); + routing->num_routes = state->routing.num_routes; + + return 0; + } + krouting.num_routes = routing->num_routes; krouting.len_routes = routing->len_routes; krouting.routes = routes;