From: Antoine Bouyer <antoine.bouyer@nxp.com>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: julien.vuillaumier@nxp.com, alexi.birlinger@nxp.com,
daniel.baluta@nxp.com, peng.fan@nxp.com, frank.li@nxp.com,
laurent.pinchart@ideasonboard.com, mchehab@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Jai Luthra <jai.luthra@ideasonboard.com>,
paul elder <paul.elder@ideasonboard.com>
Subject: Re: [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
Date: Tue, 7 Apr 2026 09:37:03 +0200 [thread overview]
Message-ID: <4e669a11-38ff-41a5-b54d-8f50841b0411@nxp.com> (raw)
In-Reply-To: <ac93m33MhldSpYDj@zed>
Hi Jacopo
On 4/3/26 10:19 AM, Jacopo Mondi wrote:
>
>
> Hello Antoine
>
> in cc Jai and Paul
>
> Jai and Paul are working on upstreaming new ISP formats which would
> benefit from usage of extensible stats.
>
> No pressure of course, just wanted to check how things are progressing
> on your side. Do you have an updated version of this patch which can
> be taken in ? Should we sync and work on an updated version ?
I'm still on it. Things are progressing well, but little bit delayed
because of neoisp rework. I hope to submit patchset (v4l2-isp + neo) by
end of this week.
BR
Antoine
>
> Thanks!
> j
>
> On Fri, Jan 23, 2026 at 09:09:28AM +0100, Antoine Bouyer wrote:
>> Extend the v4l2-isp extensible format introduced for isp parameters buffer
>> to the statistics buffer as well.
>>
>> Like for ISP configuration purpose, that will help supporting various ISP
>> hardware versions reporting different statistics data with less impact on
>> userspace.
>>
>> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
>> definitions, with similar header, versions and flags. V0 and V1 versions
>> are provided to match with params versions. On the other side, ENABLE and
>> DISABLE flags are not really meaningfull for statistics purpose. So VALID
>> and INVALID flags are introduced. Purpose is to force ISP driver to
>> validate a statistics buffer, before it is consumed by userspace.
>>
>> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
>> ---
>> include/uapi/linux/media/v4l2-isp.h | 85 +++++++++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
>> index 779168f9058e..ed1279b86694 100644
>> --- a/include/uapi/linux/media/v4l2-isp.h
>> +++ b/include/uapi/linux/media/v4l2-isp.h
>> @@ -99,4 +99,89 @@ struct v4l2_isp_params_buffer {
>> __u8 data[] __counted_by(data_size);
>> };
>>
>> +/**
>> + * enum v4l2_isp_stats_version - V4L2 ISP statistics versioning
>> + *
>> + * @V4L2_ISP_STATS_VERSION_V0: First version of the V4L2 ISP statistics format
>> + * (for compatibility)
>> + * @V4L2_ISP_STATS_VERSION_V1: First version of the V4L2 ISP statistics format
>> + *
>> + * V0 and V1 are identical, and comply with V4l2 ISP parameters versions. So
>> + * both V0 and V1 refers to the first version of the V4L2 ISP statistics
>> + * format.
>> + *
>> + * Future revisions of the V4L2 ISP statistics format should start from the
>> + * value of 2.
>> + */
>> +enum v4l2_isp_stats_version {
>> + V4L2_ISP_STATS_VERSION_V0 = 0,
>> + V4L2_ISP_STATS_VERSION_V1,
>> +};
>> +
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_VALID (1U << 0)
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_INVALID (1U << 1)
>> +
>> +/*
>> + * Reserve the first 8 bits for V4L2_ISP_STATS_FL_* flag.
>> + *
>> + * Driver-specific flags should be defined as:
>> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(0))
>> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(1))
>> + */
>> +#define V4L2_ISP_STATS_FL_DRIVER_FLAGS(n) ((n) + 8)
>> +
>> +/**
>> + * struct v4l2_isp_stats_block_header - V4L2 extensible statistics block header
>> + * @type: The statistics block type (driver-specific)
>> + * @flags: A bitmask of block flags (driver-specific)
>> + * @size: Size (in bytes) of the statistics block, including this header
>> + *
>> + * This structure represents the common part of all the ISP statistics blocks.
>> + * Each statistics block shall embed an instance of this structure type as its
>> + * first member, followed by the block-specific statistics data.
>> + *
>> + * The @type field is an ISP driver-specific value that identifies the block
>> + * type. The @size field specifies the size of the parameters block.
>> + *
>> + * The @flags field is a bitmask of per-block flags V4L2_STATS_ISP_FL_* and
>> + * driver-specific flags specified by the driver header.
>> + */
>> +struct v4l2_isp_stats_block_header {
>> + __u16 type;
>> + __u16 flags;
>> + __u32 size;
>> +} __attribute__((aligned(8)));
>> +
>> +/**
>> + * struct v4l2_isp_stats_buffer - V4L2 extensible statistics data
>> + * @version: The statistics buffer version (driver-specific)
>> + * @data_size: The statistics data effective size, excluding this header
>> + * @data: The statistics data
>> + *
>> + * This structure contains the statistics information of the ISP hardware,
>> + * serialized for userspace into a data buffer. Each statistics block is
>> + * represented by a block-specific structure which contains a
>> + * :c:type:`v4l2_isp_stats_block_header` entry as first member. Driver
>> + * populates the @data buffer with statistics information of the ISP blocks it
>> + * intends to share to userspace. As a consequence, the data buffer effective
>> + * size changes according to the number of ISP blocks that driver intends to
>> + * provide and is set by the driver in the @data_size field.
>> + *
>> + * The statistics buffer is versioned by the @version field to allow modifying
>> + * and extending its definition. Driver shall populate the @version field to
>> + * inform the userpsace about the version it intends to use. The userspace will
>> + * parse and handle the @data buffer according to the data layout specific to
>> + * the indicated version.
>> + *
>> + * For each ISP block that driver wants to report, a block-specific structure
>> + * is appended to the @data buffer, one after the other without gaps in
>> + * between. Driver shall populate the @data_size field with the effective
>> + * size, in bytes, of the @data buffer.
>> + */
>> +struct v4l2_isp_stats_buffer {
>> + __u32 version;
>> + __u32 data_size;
>> + __u8 data[] __counted_by(data_size);
>> +};
>> +
>> #endif /* _UAPI_V4L2_ISP_H_ */
>> --
>> 2.52.0
>>
next prev parent reply other threads:[~2026-04-07 7:37 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 8:09 [RFC v1 00/11] Add iMX95 neoisp driver Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions Antoine Bouyer
2026-02-03 16:15 ` Jacopo Mondi
2026-02-04 11:07 ` Antoine Bouyer
2026-02-04 13:14 ` Jacopo Mondi
2026-02-09 23:00 ` Laurent Pinchart
2026-03-02 9:41 ` Antoine Bouyer
2026-03-03 8:48 ` Jacopo Mondi
2026-04-03 8:19 ` Jacopo Mondi
2026-04-07 7:37 ` Antoine Bouyer [this message]
2026-01-23 8:09 ` [RFC v1 02/11] media: v4l2-isp: Add helper function to compute extended stats size Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 03/11] media: Documentation: uapi: Update V4L2 ISP for extensible stats Antoine Bouyer
2026-02-03 16:58 ` Jacopo Mondi
2026-02-09 23:16 ` Laurent Pinchart
2026-01-23 8:09 ` [RFC v1 04/11] media: Documentation: Add NXP neoisp driver documentation Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 05/11] dt-bindings: media: Add nxp neoisp support Antoine Bouyer
2026-01-26 17:12 ` Frank Li
2026-02-05 9:43 ` Krzysztof Kozlowski
2026-02-16 13:16 ` Antoine Bouyer
2026-02-16 13:38 ` Krzysztof Kozlowski
2026-01-23 8:09 ` [RFC v1 06/11] media: v4l2-ctrls: Add user control base for NXP neoisp controls Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 07/11] media: Add meta formats supported by NXP neoisp driver Antoine Bouyer
2026-02-03 17:11 ` Jacopo Mondi
2026-02-04 13:31 ` Antoine Bouyer
2026-02-04 13:36 ` Jacopo Mondi
2026-02-04 14:04 ` Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 08/11] media: uapi: Add NXP NEOISP user interface header file Antoine Bouyer
2026-02-09 23:29 ` Laurent Pinchart
2026-01-23 8:09 ` [RFC v1 10/11] media: platform: neoisp: Add debugfs support Antoine Bouyer
2026-01-23 8:09 ` [RFC v1 11/11] arm64: dts: freescale: imx95: Add NXP neoisp device tree node Antoine Bouyer
2026-02-05 9:44 ` Krzysztof Kozlowski
2026-01-26 9:44 ` [RFC v1 00/11] Add iMX95 neoisp driver Michael Riesch
2026-01-28 8:17 ` [EXT] " Antoine Bouyer
2026-01-28 23:00 ` Michael Riesch
2026-02-03 18:37 ` Jacopo Mondi
2026-02-04 17:12 ` Jacopo Mondi
2026-02-04 18:30 ` Antoine Bouyer
2026-02-05 9:40 ` Jacopo Mondi
2026-02-09 13:19 ` Anthony McGivern
2026-02-10 0:20 ` Laurent Pinchart
2026-02-10 12:20 ` Anthony McGivern
2026-02-10 16:02 ` Laurent Pinchart
2026-02-12 8:43 ` Anthony McGivern
2026-02-10 0:03 ` Laurent Pinchart
[not found] ` <cf9c2d21-fc0e-42ad-a554-b1d47549bc54@nxp.com>
2026-02-23 16:52 ` Jacopo Mondi
[not found] ` <596e5efa-4fdc-45ac-a9aa-7d4a40abfd9b@nxp.com>
2026-02-25 8:44 ` Jacopo Mondi
2026-03-20 16:29 ` Antoine Bouyer
2026-03-23 13:18 ` Jacopo Mondi
2026-03-24 17:44 ` Antoine Bouyer
2026-03-25 13:23 ` Jacopo Mondi
2026-02-06 20:51 ` Michael Riesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e669a11-38ff-41a5-b54d-8f50841b0411@nxp.com \
--to=antoine.bouyer@nxp.com \
--cc=alexi.birlinger@nxp.com \
--cc=conor+dt@kernel.org \
--cc=daniel.baluta@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=jacopo.mondi@ideasonboard.com \
--cc=jai.luthra@ideasonboard.com \
--cc=julien.vuillaumier@nxp.com \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=paul.elder@ideasonboard.com \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox