| Message ID | 20160902134714.12224-2-niklas.soderlund+renesas@ragnatech.se (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Niklas, Thank you for the patch. On Friday 02 Sep 2016 15:47:13 Niklas Söderlund wrote: > The format is used on the R-Car VSP1 video queues that carry > 2-D histogram statistics data. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > Documentation/media/uapi/v4l/meta-formats.rst | 1 + > .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst | 150 ++++++++++++++++++ > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > include/uapi/linux/videodev2.h | 3 +- > 4 files changed, 154 insertions(+), 1 deletion(-) > create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst [snip] > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst > b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode > 100644 > index 0000000..a093f0a > --- /dev/null > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst > @@ -0,0 +1,150 @@ > +.. -*- coding: utf-8; mode: rst -*- > + > +.. _v4l2-meta-fmt-vsp1-hgt: > + > +******************************* > +V4L2_META_FMT_VSP1_HGT ('VSPT') > +******************************* > + > +*man V4L2_META_FMT_VSP1_HGT(2)* > + > +Renesas R-Car VSP1 2-D Histogram Data > + > + > +Description > +=========== > + > +This format describes histogram data generated by the Renesas R-Car VSP1 > +2-D Histogram (HGT) engine. > + > +The VSP1 HGT is a histogram computation engine that operates on HSV > +data. It operates on a possibly cropped and subsampled input image and > +computes the sum, maximum and minimum of the S component as well as a > +weighted frequency histogram based on the H and S components. > + > +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in > +total. Each HSV value is added to one or more buckets with a wight s/wight/weight/ > +between 1 and 16 depending on how the Hue areas are setup. I would say 'depending on the Hue areas configuration' to insist on the fact that the configuration can be changed by the application. > Finding the > +correct buckets is done by inspecting the H and S value independently. Maybe s/correct/corresponding/ ? > +The Saturation position **n** (0 - 31) in the matrix are found by the Maybe s/in the matrix/of the bucket/, or s/in the matrix/of the bucket in the matrix/ ? s/are found/is found/ or maybe 'is computed' ? > +expression: > + > + 8 * n <= S < 8 * (n + 1) How about simply 'n = S / 8' ? > +The Hue positions **m** (0 - 5) in the matrix depends on how the HGT Hue s/positions/position/ > +areas are configured. There are 6 user configurable Hue Areas which can > +be configured to cover overlapping Hue values: > + > +:: > + > + Area 0 Area 1 Area 2 Area 3 Area 4 > Area 5 + ________ ________ ________ ________ > ________ ________ + \ /| |\ /| |\ /| |\ /| > |\ /| |\ /| |\ / + \ / | | \ / | | \ / | > | \ / | | \ / | | \ / | | \ / + X | | X | | > X | | X | | X | | X | | X + / \ | | / > \ | | / \ | | / \ | | / \ | | / \ | | / \ + / > \| |/ \| |/ \| |/ \| |/ \| |/ \| |/ > \ + 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U > 5L 5U 0L + <0..............................Hue > Value............................255> > + > +As shown in the diagram a single Hue vale can be attributed to more then s/vale/value/ s/then/than/ > +one Hue area. In such case the Hue value is attributed to both Hue > +Areas, but with a weight. The maximum weight is 16 and is associated > +with all Hue values that are inside the center of a Hue area (between nL > +-- nU). Values outside this area are weighted with a rounded down value > +along the diagonal line. If there is no overlapped areas specified the > +value is included in the lower area. This sounds a bit confusing to me. How about the following ? "The Hue position **m** (0 - 5) of the bucket [in the matrix]* depends on how the HGT Hue areas are configured. There are 6 user configurable Hue Areas which can be configured to cover overlapping Hue values: [diagram] When two consecutive areas don't overlap (n+1L is equal to nU) the boundary value is considered as part of the lower area. Pixels with a hue value included in the centre of an area (between nL and nU included) are are attributed to that single area and given a weight of 16. Pixels with a hue value included in the overlapping region between two areas (between n+1L and nU excluded) are attributed to both areas and given a weight for each of these areas proportional to their position along the diagonal lines (rounded down)." * Add "in the matrix" depending on the wording of the saturation description. > +The Hue area setup must match one of the following constrains: > + > +:: > + > + 0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U > + > +:: > + > + 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L > + > +**Byte Order.** > +All data is stored in memory in little endian format. Each cell in the > tables +contains one byte. > + > +.. flat-table:: VSP1 HGT Data - (800 bytes) > + :header-rows: 2 > + :stub-columns: 0 > + > + * - Offset > + - :cspan:`4` Memory > + * - > + - [31:24] > + - [23:16] > + - [15:8] > + - [7:0] > + * - 0 > + - - > + - S max [7:0] > + - - > + - S min [7:0] > + * - 4 > + - :cspan:`4` S sum [31:0] > + * - 8 > + - - > + - Hue Area 0 Lower Boundary (0L) [0:7] > + - - > + - Hue Area 0 Upper Boundary (0U) [0:7] > + * - 12 > + - - > + - Hue Area 1 Lower Boundary (1L) [0:7] > + - - > + - Hue Area 1 Upper Boundary (1U) [0:7] > + * - 16 > + - - > + - Hue Area 2 Lower Boundary (2L) [0:7] > + - - > + - Hue Area 2 Upper Boundary (2U) [0:7] > + * - 20 > + - - > + - Hue Area 3 Lower Boundary (3L) [0:7] > + - - > + - Hue Area 3 Upper Boundary (3U) [0:7] > + * - 24 > + - - > + - Hue Area 4 Lower Boundary (4L) [0:7] > + - - > + - Hue Area 4 Upper Boundary (4U) [0:7] > + * - 28 > + - - > + - Hue Area 5 Lower Boundary (5L) [0:7] > + - - > + - Hue Area 5 Upper Boundary (5U) [0:7] What's the rationale for including the boundaries in the statistics buffer ? Boundaries are configured by userspace, they should be known to the application already. > + * - 32 > + - :cspan:`4` Histogram bucket (m=0, n=0) [31:0] > + * - 36 > + - :cspan:`4` Histogram bucket (m=0, n=1) [31:0] > + * - > + - :cspan:`4` ... > + * - 156 > + - :cspan:`4` Histogram bucket (m=0, n=31) [31:0] > + * - 160 > + - :cspan:`4` Histogram bucket (m=1, n=0) [31:0] > + * - > + - :cspan:`4` ... > + * - 288 > + - :cspan:`4` Histogram bucket (m=2, n=0) [31:0] > + * - > + - :cspan:`4` ... > + * - 416 > + - :cspan:`4` Histogram bucket (m=3, n=0) [31:0] > + * - > + - :cspan:`4` ... > + * - 544 > + - :cspan:`4` Histogram bucket (m=4, n=0) [31:0] > + * - > + - :cspan:`4` ... > + * - 672 > + - :cspan:`4` Histogram bucket (m=5, n=0) [31:0] > + * - > + - :cspan:`4` ... > + * - 796 > + - :cspan:`4` Histogram bucket (m=5, n=31) [31:0] [snip]
Hi Laurent, Thanks for your review. On 2016-09-05 16:05:10 +0300, Laurent Pinchart wrote: > Hi Niklas, > > Thank you for the patch. > > On Friday 02 Sep 2016 15:47:13 Niklas Söderlund wrote: > > The format is used on the R-Car VSP1 video queues that carry > > 2-D histogram statistics data. > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > --- > > Documentation/media/uapi/v4l/meta-formats.rst | 1 + > > .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst | 150 ++++++++++++++++++ > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > > include/uapi/linux/videodev2.h | 3 +- > > 4 files changed, 154 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst > > [snip] > > > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst > > b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode > > 100644 > > index 0000000..a093f0a > > --- /dev/null > > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst > > @@ -0,0 +1,150 @@ > > +.. -*- coding: utf-8; mode: rst -*- > > + > > +.. _v4l2-meta-fmt-vsp1-hgt: > > + > > +******************************* > > +V4L2_META_FMT_VSP1_HGT ('VSPT') > > +******************************* > > + > > +*man V4L2_META_FMT_VSP1_HGT(2)* > > + > > +Renesas R-Car VSP1 2-D Histogram Data > > + > > + > > +Description > > +=========== > > + > > +This format describes histogram data generated by the Renesas R-Car VSP1 > > +2-D Histogram (HGT) engine. > > + > > +The VSP1 HGT is a histogram computation engine that operates on HSV > > +data. It operates on a possibly cropped and subsampled input image and > > +computes the sum, maximum and minimum of the S component as well as a > > +weighted frequency histogram based on the H and S components. > > + > > +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in > > +total. Each HSV value is added to one or more buckets with a wight > > s/wight/weight/ Will fix. > > > +between 1 and 16 depending on how the Hue areas are setup. > > I would say 'depending on the Hue areas configuration' to insist on the fact > that the configuration can be changed by the application. Will fix. > > > Finding the > > +correct buckets is done by inspecting the H and S value independently. > > Maybe s/correct/corresponding/ ? Will fix. > > > +The Saturation position **n** (0 - 31) in the matrix are found by the > > Maybe s/in the matrix/of the bucket/, or s/in the matrix/of the bucket in the > matrix/ ? > s/are found/is found/ or maybe 'is computed' ? Will fix. > > > +expression: > > + > > + 8 * n <= S < 8 * (n + 1) > > How about simply 'n = S / 8' ? Will fix. > > > +The Hue positions **m** (0 - 5) in the matrix depends on how the HGT Hue > > s/positions/position/ Will fix. > > > +areas are configured. There are 6 user configurable Hue Areas which can > > +be configured to cover overlapping Hue values: > > + > > +:: > > + > > + Area 0 Area 1 Area 2 Area 3 Area 4 > > Area 5 + ________ ________ ________ ________ > > ________ ________ + \ /| |\ /| |\ /| |\ /| > > |\ /| |\ /| |\ / + \ / | | \ / | | \ / | > > | \ / | | \ / | | \ / | | \ / + X | | X | | > > X | | X | | X | | X | | X + / \ | | / > > \ | | / \ | | / \ | | / \ | | / \ | | / \ + / > > \| |/ \| |/ \| |/ \| |/ \| |/ \| |/ > > \ + 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U > > 5L 5U 0L + <0..............................Hue > > Value............................255> > > + > > +As shown in the diagram a single Hue vale can be attributed to more then > > s/vale/value/ > s/then/than/ Will fix. > > > +one Hue area. In such case the Hue value is attributed to both Hue > > +Areas, but with a weight. The maximum weight is 16 and is associated > > +with all Hue values that are inside the center of a Hue area (between nL > > +-- nU). Values outside this area are weighted with a rounded down value > > +along the diagonal line. If there is no overlapped areas specified the > > +value is included in the lower area. > > This sounds a bit confusing to me. How about the following ? > > "The Hue position **m** (0 - 5) of the bucket [in the matrix]* depends on how > the HGT Hue areas are configured. There are 6 user configurable Hue Areas > which can be configured to cover overlapping Hue values: > > [diagram] > > When two consecutive areas don't overlap (n+1L is equal to nU) the boundary > value is considered as part of the lower area. > > Pixels with a hue value included in the centre of an area (between nL and nU > included) are are attributed to that single area and given a weight of 16. > Pixels with a hue value included in the overlapping region between two areas > (between n+1L and nU excluded) are attributed to both areas and given a weight > for each of these areas proportional to their position along the diagonal > lines (rounded down)." > > * Add "in the matrix" depending on the wording of the saturation description. > Will fix. > > +The Hue area setup must match one of the following constrains: > > + > > +:: > > + > > + 0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U > > + > > +:: > > + > > + 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L > > + > > +**Byte Order.** > > +All data is stored in memory in little endian format. Each cell in the > > tables +contains one byte. > > + > > +.. flat-table:: VSP1 HGT Data - (800 bytes) > > + :header-rows: 2 > > + :stub-columns: 0 > > + > > + * - Offset > > + - :cspan:`4` Memory > > + * - > > + - [31:24] > > + - [23:16] > > + - [15:8] > > + - [7:0] > > + * - 0 > > + - - > > + - S max [7:0] > > + - - > > + - S min [7:0] > > + * - 4 > > + - :cspan:`4` S sum [31:0] > > + * - 8 > > + - - > > + - Hue Area 0 Lower Boundary (0L) [0:7] > > + - - > > + - Hue Area 0 Upper Boundary (0U) [0:7] > > + * - 12 > > + - - > > + - Hue Area 1 Lower Boundary (1L) [0:7] > > + - - > > + - Hue Area 1 Upper Boundary (1U) [0:7] > > + * - 16 > > + - - > > + - Hue Area 2 Lower Boundary (2L) [0:7] > > + - - > > + - Hue Area 2 Upper Boundary (2U) [0:7] > > + * - 20 > > + - - > > + - Hue Area 3 Lower Boundary (3L) [0:7] > > + - - > > + - Hue Area 3 Upper Boundary (3U) [0:7] > > + * - 24 > > + - - > > + - Hue Area 4 Lower Boundary (4L) [0:7] > > + - - > > + - Hue Area 4 Upper Boundary (4U) [0:7] > > + * - 28 > > + - - > > + - Hue Area 5 Lower Boundary (5L) [0:7] > > + - - > > + - Hue Area 5 Upper Boundary (5U) [0:7] > > What's the rationale for including the boundaries in the statistics buffer ? > Boundaries are configured by userspace, they should be known to the > application already. At the time I thought it would easy userspaces consumption of the data, for example if the histograms where recorded for later processing. Other then that I have no good rationale for including them. I be happy to drop them in v2 if you see no value in them. > > > + * - 32 > > + - :cspan:`4` Histogram bucket (m=0, n=0) [31:0] > > + * - 36 > > + - :cspan:`4` Histogram bucket (m=0, n=1) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 156 > > + - :cspan:`4` Histogram bucket (m=0, n=31) [31:0] > > + * - 160 > > + - :cspan:`4` Histogram bucket (m=1, n=0) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 288 > > + - :cspan:`4` Histogram bucket (m=2, n=0) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 416 > > + - :cspan:`4` Histogram bucket (m=3, n=0) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 544 > > + - :cspan:`4` Histogram bucket (m=4, n=0) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 672 > > + - :cspan:`4` Histogram bucket (m=5, n=0) [31:0] > > + * - > > + - :cspan:`4` ... > > + * - 796 > > + - :cspan:`4` Histogram bucket (m=5, n=31) [31:0] > > [snip] > > -- > Regards, > > Laurent Pinchart >
diff --git a/Documentation/media/uapi/v4l/meta-formats.rst b/Documentation/media/uapi/v4l/meta-formats.rst index 05ab91e..01e24e3 100644 --- a/Documentation/media/uapi/v4l/meta-formats.rst +++ b/Documentation/media/uapi/v4l/meta-formats.rst @@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface only. :maxdepth: 1 pixfmt-meta-vsp1-hgo + pixfmt-meta-vsp1-hgt diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode 100644 index 0000000..a093f0a --- /dev/null +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst @@ -0,0 +1,150 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _v4l2-meta-fmt-vsp1-hgt: + +******************************* +V4L2_META_FMT_VSP1_HGT ('VSPT') +******************************* + +*man V4L2_META_FMT_VSP1_HGT(2)* + +Renesas R-Car VSP1 2-D Histogram Data + + +Description +=========== + +This format describes histogram data generated by the Renesas R-Car VSP1 +2-D Histogram (HGT) engine. + +The VSP1 HGT is a histogram computation engine that operates on HSV +data. It operates on a possibly cropped and subsampled input image and +computes the sum, maximum and minimum of the S component as well as a +weighted frequency histogram based on the H and S components. + +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in +total. Each HSV value is added to one or more buckets with a wight +between 1 and 16 depending on how the Hue areas are setup. Finding the +correct buckets is done by inspecting the H and S value independently. + +The Saturation position **n** (0 - 31) in the matrix are found by the +expression: + + 8 * n <= S < 8 * (n + 1) + +The Hue positions **m** (0 - 5) in the matrix depends on how the HGT Hue +areas are configured. There are 6 user configurable Hue Areas which can +be configured to cover overlapping Hue values: + +:: + + Area 0 Area 1 Area 2 Area 3 Area 4 Area 5 + ________ ________ ________ ________ ________ ________ + \ /| |\ /| |\ /| |\ /| |\ /| |\ /| |\ / + \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / + X | | X | | X | | X | | X | | X | | X + / \ | | / \ | | / \ | | / \ | | / \ | | / \ | | / \ + / \| |/ \| |/ \| |/ \| |/ \| |/ \| |/ \ + 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U 5L 5U 0L + <0..............................Hue Value............................255> + +As shown in the diagram a single Hue vale can be attributed to more then +one Hue area. In such case the Hue value is attributed to both Hue +Areas, but with a weight. The maximum weight is 16 and is associated +with all Hue values that are inside the center of a Hue area (between nL +-- nU). Values outside this area are weighted with a rounded down value +along the diagonal line. If there is no overlapped areas specified the +value is included in the lower area. + +The Hue area setup must match one of the following constrains: + +:: + + 0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U + +:: + + 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L + +**Byte Order.** +All data is stored in memory in little endian format. Each cell in the tables +contains one byte. + +.. flat-table:: VSP1 HGT Data - (800 bytes) + :header-rows: 2 + :stub-columns: 0 + + * - Offset + - :cspan:`4` Memory + * - + - [31:24] + - [23:16] + - [15:8] + - [7:0] + * - 0 + - - + - S max [7:0] + - - + - S min [7:0] + * - 4 + - :cspan:`4` S sum [31:0] + * - 8 + - - + - Hue Area 0 Lower Boundary (0L) [0:7] + - - + - Hue Area 0 Upper Boundary (0U) [0:7] + * - 12 + - - + - Hue Area 1 Lower Boundary (1L) [0:7] + - - + - Hue Area 1 Upper Boundary (1U) [0:7] + * - 16 + - - + - Hue Area 2 Lower Boundary (2L) [0:7] + - - + - Hue Area 2 Upper Boundary (2U) [0:7] + * - 20 + - - + - Hue Area 3 Lower Boundary (3L) [0:7] + - - + - Hue Area 3 Upper Boundary (3U) [0:7] + * - 24 + - - + - Hue Area 4 Lower Boundary (4L) [0:7] + - - + - Hue Area 4 Upper Boundary (4U) [0:7] + * - 28 + - - + - Hue Area 5 Lower Boundary (5L) [0:7] + - - + - Hue Area 5 Upper Boundary (5U) [0:7] + * - 32 + - :cspan:`4` Histogram bucket (m=0, n=0) [31:0] + * - 36 + - :cspan:`4` Histogram bucket (m=0, n=1) [31:0] + * - + - :cspan:`4` ... + * - 156 + - :cspan:`4` Histogram bucket (m=0, n=31) [31:0] + * - 160 + - :cspan:`4` Histogram bucket (m=1, n=0) [31:0] + * - + - :cspan:`4` ... + * - 288 + - :cspan:`4` Histogram bucket (m=2, n=0) [31:0] + * - + - :cspan:`4` ... + * - 416 + - :cspan:`4` Histogram bucket (m=3, n=0) [31:0] + * - + - :cspan:`4` ... + * - 544 + - :cspan:`4` Histogram bucket (m=4, n=0) [31:0] + * - + - :cspan:`4` ... + * - 672 + - :cspan:`4` Histogram bucket (m=5, n=0) [31:0] + * - + - :cspan:`4` ... + * - 796 + - :cspan:`4` Histogram bucket (m=5, n=31) [31:0] diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index b7f7d5f..f459c4f 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1259,6 +1259,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) case V4L2_SDR_FMT_CS14LE: descr = "Complex S14LE"; break; case V4L2_SDR_FMT_RU12LE: descr = "Real U12LE"; break; case V4L2_META_FMT_VSP1_HGO: descr = "R-Car VSP1 1-D Histogram"; break; + case V4L2_META_FMT_VSP1_HGT: descr = "R-Car VSP1 2-D Histogram"; break; default: /* Compressed formats */ diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 1dbe52a..c8c046c 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -638,7 +638,8 @@ struct v4l2_pix_format { #define V4L2_SDR_FMT_RU12LE v4l2_fourcc('R', 'U', '1', '2') /* real u12le */ /* Meta-data formats */ -#define V4L2_META_FMT_VSP1_HGO v4l2_fourcc('V', 'S', 'P', 'H') /* R-Car VSP1 Histogram */ +#define V4L2_META_FMT_VSP1_HGO v4l2_fourcc('V', 'S', 'P', 'H') /* R-Car VSP1 1-D Histogram */ +#define V4L2_META_FMT_VSP1_HGT v4l2_fourcc('V', 'S', 'P', 'T') /* R-Car VSP1 2-D Histogram */ /* priv field value to indicates that subsequent fields are valid. */ #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
The format is used on the R-Car VSP1 video queues that carry 2-D histogram statistics data. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- Documentation/media/uapi/v4l/meta-formats.rst | 1 + .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst | 150 +++++++++++++++++++++ drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/uapi/linux/videodev2.h | 3 +- 4 files changed, 154 insertions(+), 1 deletion(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst