diff mbox

[1/2] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine

Message ID 20160902134714.12224-2-niklas.soderlund+renesas@ragnatech.se (mailing list archive)
State New, archived
Headers show

Commit Message

Niklas Söderlund Sept. 2, 2016, 1:47 p.m. UTC
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

Comments

Laurent Pinchart Sept. 5, 2016, 1:05 p.m. UTC | #1
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]
Niklas Söderlund Sept. 5, 2016, 1:34 p.m. UTC | #2
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 mbox

Patch

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