From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 07431CA0EE6 for ; Tue, 19 Aug 2025 23:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MKODV7CpAUp95lkkEPnnCdnNsoREymj9Ln9wwVN1t9E=; b=11RlBtcWkwibcBZs0LUwJJ2Drn dGoJ+CniY2FwnObTTzbGNACcl9tpJYgVS0norSxz8IvMPEtMlNQY4nnbS9n15TV72b26wBYbZJeo3 Qs3/D42ut83A1r2No258TnlZOiH/iX7Mr8Yd6ZY2z9MENI1G5T4s8K4Oixyd0Zx+TR7ywvopUXfaf 38ImmA5nzz1GinO8UcMy5Ynr7yBaAmdtp7YT+HlHlPwfPc1LsXLjql9qXDELSAiyJbnLsZ38Lfac6 wtIXLN1VMDYyyeMe+ILBYPUAjpNTgMRqlNePPNpouCAAXWJ1saLwre1FY2uHJeURK9oxAiIlVpLVq fZvriK0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uoVj4-0000000Bqn0-0xyM; Tue, 19 Aug 2025 23:26:46 +0000 Received: from mgamail.intel.com ([198.175.65.9]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uoUUw-0000000Bi2N-3VkY; Tue, 19 Aug 2025 22:08:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755641286; x=1787177286; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IER2tH70jw4bUvxU7SJwvA7uocCmfea8E42TaoI/+JE=; b=JmDUdDDOozwNs16Tljz0o8FBrcqObscN5mHgUfKLNFbGIH8MsiCaVpYu WDCbaiFMusmpjNobl8035tzdW3LIxZDrYcm6BJMMlLzv4OcwAGinKy2Cx u6RDY0QAyzqOWG2SuijJoQURSJOgM+FH/niVIWTCdBeOn4kCJvJEh5vK7 MoKY0HGWoEo7JkIkQOkLgH9jaadmLjQzYUopzI/KdLud73E1h/mK+/MQt aSH3mWjM6WozmsaJDQ3Qf/C0xVgJCvINcX/WhXJynH6HMz3FqmHKtFGgz C7LSXsh/pS6SA/Ha0cLihcQo4N41GWBEq6ZhRaOW+feExnCLmW1KGZJ6X w==; X-CSE-ConnectionGUID: 1VVHyt97Qz+4hEcedgbHqA== X-CSE-MsgGUID: jNb6PeaoTHW2psZsiCEpIw== X-IronPort-AV: E=McAfee;i="6800,10657,11527"; a="80491874" X-IronPort-AV: E=Sophos;i="6.17,302,1747724400"; d="scan'208";a="80491874" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Aug 2025 15:08:04 -0700 X-CSE-ConnectionGUID: FnrUrLyiReypiU0rUAmo7A== X-CSE-MsgGUID: u5PAcqNEQROpMrxv+0NYTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,302,1747724400"; d="scan'208";a="173324580" Received: from sschumil-mobl2.ger.corp.intel.com (HELO kekkonen.fi.intel.com) ([10.245.244.235]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Aug 2025 15:08:02 -0700 Received: from kekkonen.localdomain (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with SMTP id 4123511F8D4; Wed, 20 Aug 2025 01:07:58 +0300 (EEST) Date: Wed, 20 Aug 2025 01:07:58 +0300 Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo From: Sakari Ailus To: Jacopo Mondi Cc: Dafna Hirschfeld , Laurent Pinchart , Keke Li , Mauro Carvalho Chehab , Heiko Stuebner , Dan Scally , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 1/8] media: uapi: Introduce V4L2 extensible params Message-ID: References: <20250819-extensible-parameters-validation-v3-0-9dc008348b30@ideasonboard.com> <20250819-extensible-parameters-validation-v3-1-9dc008348b30@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250819-extensible-parameters-validation-v3-1-9dc008348b30@ideasonboard.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250819_150806_917528_DAF64213 X-CRM114-Status: GOOD ( 48.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jacopo, Thank you for working on this. On Tue, Aug 19, 2025 at 04:54:42PM +0200, Jacopo Mondi wrote: > Introduce v4l2-extensible-params.h in the Linux kernel uAPI. > > The header defines two types that all drivers that use the extensible > parameters format for ISP configuration shall use to build their own > format versions. > > The newly introduce type v4l2_params_block represent the > header to be prepend to each ISP configuration block and the > v4l2_params_buffer type represent the base type for the configuration > parameters buffer. > > The v4l2_params_buffer represents the container for the ISP > configuration data block. The generic type is defined with a 0-sized > data block that specific ISP implementation shall properly size > according to their capabilities. > > [Add v4l2_params_buffer_size()] > > Signed-off-by: Daniel Scally > Reviewed-by: Daniel Scally > Signed-off-by: Jacopo Mondi > --- > MAINTAINERS | 6 + > include/uapi/linux/media/v4l2-extensible-params.h | 144 ++++++++++++++++++++++ > 2 files changed, 150 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index fe168477caa45799dfe07de2f54de6d6a1ce0615..67216d1e92d7ac81617bb3c4329e4096aa205706 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -26380,6 +26380,12 @@ F: drivers/media/i2c/vd55g1.c > F: drivers/media/i2c/vd56g3.c > F: drivers/media/i2c/vgxy61.c > > +V4L2 EXTENSIBLE PARAMETERS FORMAT > +M: Jacopo Mondi > +L: linux-media@vger.kernel.org > +S: Maintained > +F: include/uapi/linux/media/v4l2-extensible-params.h > + > VF610 NAND DRIVER > M: Stefan Agner > L: linux-mtd@lists.infradead.org > diff --git a/include/uapi/linux/media/v4l2-extensible-params.h b/include/uapi/linux/media/v4l2-extensible-params.h > new file mode 100644 > index 0000000000000000000000000000000000000000..ace89299a4b37e428c0bc9a72fbc079b1dcda91a > --- /dev/null > +++ b/include/uapi/linux/media/v4l2-extensible-params.h > @@ -0,0 +1,144 @@ > +/* SPDX-License-Identifier: ((GPL-2.0+ WITH Linux-syscall-note) OR MIT) */ > +/* > + * Video4Linux2 extensible configuration parameters base types > + * > + * Copyright (C) 2025 Ideas On Board Oy > + * Author: Jacopo Mondi > + */ > + > +#ifndef _UAPI_V4L2_PARAMS_H_ > +#define _UAPI_V4L2_PARAMS_H_ > + > +#include > + > +#define V4L2_PARAMS_FL_BLOCK_DISABLE (1U << 0) > +#define V4L2_PARAMS_FL_BLOCK_ENABLE (1U << 1) > + > +/* > + * Reserve the first 8 bits for V4L2_PARAMS_FL_* flag. Platform-specific flags > + * should be defined as: > + * #define PLATFORM_SPECIFIC_FLAG0 ((1U << V4L2_PARAMS_FL_PLATFORM_FLAGS(0)) > + * #define PLATFORM_SPECIFIC_FLAG1 ((1U << V4L2_PARAMS_FL_PLATFORM_FLAGS(1)) How many bits are you shifting left here again? > + */ > +#define V4L2_PARAMS_FL_PLATFORM_FLAGS(n) ((n) << 8) n really needs to be unsigned. > + > +/** > + * struct v4l2_params_block_header - V4L2 extensible parameters block header > + * > + * This structure represents the common part of all the ISP configuration > + * blocks. Each parameters block shall embed an instance of this structure type > + * as its first member, followed by the block-specific configuration data. The > + * driver inspects this common header to discern the block type and its size and > + * properly handle the block content by casting it to the correct block-specific > + * type. > + * > + * The @type field is one of the values enumerated by each platform-specific ISP > + * block types which specifies how the data should be interpreted by the driver. > + * The @size field specifies the size of the parameters block and is used by the > + * driver for validation purposes. > + * > + * The @flags field is a bitmask of per-block flags V4L2_PARAMS_FL_* and > + * platform-specific flags specified by the platform-specific header. > + * > + * Documentation of the platform-specific flags handling is specified by the > + * platform-specific block header type: > + * > + * - Rockchip RkISP1: :c:type:`rkisp1_ext_params_block_type` > + * - Amlogic C3: :c:type:`c3_isp_params_block_type` > + * > + * Userspace is responsible for correctly populating the parameters block header > + * fields (@type, @flags and @size) and the block-specific parameters. > + * > + * @type: The parameters block type (platform-specific) > + * @flags: A bitmask of block flags (platform-specific) > + * @size: Size (in bytes) of the parameters block, including this header > + */ > +struct v4l2_params_block_header { > + __u16 type; > + __u16 flags; > + __u32 size; > +} __attribute__((aligned(8))); > + > +/** > + * v4l2_params_buffer_size - Calculate size of v4l2_params_buffer for a platform > + * > + * Users of the v4l2 extensible parameters will have differing sized data arrays > + * depending on their specific parameter buffers. Drivers and userspace will > + * need to be able to calculate the appropriate size of the struct to > + * accommodate all ISP configuration blocks provided by the platform. > + * This macro provides a convenient tool for the calculation. > + * > + * Each driver shall provide a definition of their extensible parameters > + * implementation data buffer size. As an example: > + * > + * #define PLATFORM_BLOCKS_MAX_SIZE \ > + * sizeof(platform_block_0) + \ > + * sizeof(platform_block_1) > + * > + * #define PLATFORM_BUFFER_SIZE \ > + * v4l2_params_buffer_size(PLATFORM_BLOCKS_MAX_SIZE) > + * > + * Drivers are then responsible for allocating buffers of the proper size > + * by assigning PLATFORM_BUFFER_SIZE to the per-plane size of the videobuf2 > + * .queue_setup() operation and userspace shall use PLATFORM_BUFFER_SIZE > + * when populating the ISP configuration data buffer. > + * > + * @max_params_size: The total size of the ISP configuration blocks > + */ > +#define v4l2_params_buffer_size(max_params_size) \ > + (offsetof(struct v4l2_params_buffer, data) + (max_params_size)) > + > +/** > + * struct v4l2_params_buffer - V4L2 extensible parameters configuration > + * > + * This struct contains the configuration parameters of the ISP algorithms, > + * serialized by userspace into a data buffer. Each configuration parameter > + * block is represented by a block-specific structure which contains a > + * :c:type:`v4l2_params_block_header` entry as first member. Userspace populates > + * the @data buffer with configuration parameters for the blocks that it intends > + * to configure. As a consequence, the data buffer effective size changes > + * according to the number of ISP blocks that userspace intends to configure and > + * is set by userspace in the @data_size field. > + * > + * The parameters buffer is versioned by the @version field to allow modifying > + * and extending its definition. Userspace shall populate the @version field to > + * inform the driver about the version it intends to use. The driver will parse > + * and handle the @data buffer according to the data layout specific to the > + * indicated version and return an error if the desired version is not > + * supported. > + * > + * For each ISP block that userspace wants to configure, a block-specific > + * structure is appended to the @data buffer, one after the other without gaps > + * in between nor overlaps. Userspace shall populate the @data_size field with > + * the effective size, in bytes, of the @data buffer. > + * > + * Drivers shall take care of properly sizing of the extensible parameters > + * buffer @data array. The v4l2_params_buffer type is defined with a > + * flexible-array-member at the end, which resolves to a size of 0 bytes when > + * inspected with sizeof(struct v4l2_params_buffer). This of course is not > + * suitable for neither buffer allocation in the kernel driver nor for proper > + * handling in userspace of the @data buffer it has to populate. > + * > + * Drivers using this type in their userspace API definition are responsible > + * for providing the exact definition of the @data buffer size using the > + * v4l2_params_buffer_size() macro. The size shall be used > + * by the driver for buffers allocation and by userspace for populating the > + * @data buffer before queueing it to the driver > + * > + * Drivers that were already using extensible-parameters before the introduction > + * of this file define their own type-convertible implementation of this > + * type, see: > + * - Rockchip RkISP1: :c:type:`rkisp1_ext_params_cfg` > + * - Amlogic C3: :c:type:`c3_isp_params_cfg` > + * > + * @version: The parameters buffer version (platform-specific) > + * @data_size: The configuration data effective size, excluding this header > + * @data: The configuration data > + */ > +struct v4l2_params_buffer { > + __u32 version; > + __u32 data_size; > + __u8 data[]; Would __attribute__((__counted_by__(data_size))) be problematic here? Perhaps not now but it could be added later on? > +}; > + > +#endif /* _UAPI_V4L2_PARAMS_H_ */ > -- Kind regards, Sakari Ailus