from:"Andrzej Pietrasiewicz"

This series addresses quality issues in encoded JPEG images.

The first patch actually restores the intention of the original submission
of this driver: due to a typo the helper variables were unused and then
have been removed in some cleanup done by Mauro.

The second patch aligns the driver's luma quantization table with
the one in the ITU-T.81 standard.

The third patch changes the order in which quantization tables are
written to the resulting file and to the hardware. The file expects
a zig-zag order, while the hardware wants some special order, neither
linear nor zig-zag. In other words, hardware-wise it rearranges which
parts of quantization tables go into which 4-byte registers - in a hardware
specific order rather than linear or zig-zag. It also affects rk3288 and
hasn't been tested with it.

The fourth patch then rearranges the sequence of register writes.
The whole luma quantization table must be written first, and then the
chroma quantization is written. In other words, while patch 3/4
changes what goes into which register, this patch changes when each
register is written to. It also affects rk3288 and hasn't been
tested with it.

Andrzej Pietrasiewicz (4):
  media: hantro: Read be32 words starting at every fourth byte
  media: hantro: Use standard luma quantization table
  media: hantro: Write the quantization tables in proper order
  media: hantro: Write quantization table registers in increasing
addresses order

 .../staging/media/hantro/hantro_h1_jpeg_enc.c | 19 -
 drivers/staging/media/hantro/hantro_jpeg.c| 76 ++-
 drivers/staging/media/hantro/hantro_jpeg.h|  2 +-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c | 24 --
 4 files changed, 89 insertions(+), 32 deletions(-)

-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/4] media: hantro: Write the quantization tables in proper order

The quantization tables as defined in the file (luma_q_table,
chroma_q_table) are in fact in linear order. The JPEG file header, which is
not generated by the hardware, but must be programatically created with the
CPU, expects the table in zigzag order. On the other hand, the hardware
doesn't expect neither linear, nor zigzag order. Instead it expects the
quantization tables in vertical groups of four quantization parameters,
and the groups are organized in blocks of two vertically adjacent groups.
On top of that the blocks must be provided to the hardware in this order:
leftmost top block, leftmost bottom block, second leftmost top block,
second leftmost bottom block and so on. So, if this is the quantization
table in linear order:

0x10, 0x0b, 0x0a, 0x10, 0x18, 0x28, 0x33, 0x3d,
0x0c, 0x0c, 0x0e, 0x13, 0x1a, 0x3a, 0x3c, 0x37,
0x0e, 0x0d, 0x10, 0x18, 0x28, 0x39, 0x45, 0x38,
0x0e, 0x11, 0x16, 0x1d, 0x33, 0x57, 0x50, 0x3e,
0x12, 0x16, 0x25, 0x38, 0x44, 0x6d, 0x67, 0x4d,
0x18, 0x23, 0x37, 0x40, 0x51, 0x68, 0x71, 0x5c,
0x31, 0x40, 0x4e, 0x57, 0x67, 0x79, 0x78, 0x65,
0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0x63

then the hardware expects this in its consecutive registers:

0x100c0e0e,
0x0b0c0d11,
0x12183148,
0x1623405c,
0x0a0e1016,
0x1013181d,
0x25374e5f,
0x38405762,

and so on.

Consequently, the same area of memory cannot be used both for dumping it
into the JPEG file header and writing its contents to the hardware
registers. Instead, a separate pair of arrays is added for properly
reordered quantization tables, to be read with get_unaligned_be32()
and linearly written to the registers.

The "ctx" parameter is not needed any more for hantro_jpeg_get_qtable().

Signed-off-by: Andrzej Pietrasiewicz 
---
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |  4 +-
 drivers/staging/media/hantro/hantro_jpeg.c| 60 +++
 drivers/staging/media/hantro/hantro_jpeg.h|  2 +-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c |  9 ++-
 4 files changed, 55 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c 
b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index be787a045c7e..bd05aea1bd71 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -108,8 +108,8 @@ void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
hantro_h1_set_src_img_ctrl(vpu, ctx);
hantro_h1_jpeg_enc_set_buffers(vpu, ctx, &src_buf->vb2_buf);
hantro_h1_jpeg_enc_set_qtable(vpu,
- hantro_jpeg_get_qtable(&jpeg_ctx, 0),
- hantro_jpeg_get_qtable(&jpeg_ctx, 1));
+ hantro_jpeg_get_qtable(0),
+ hantro_jpeg_get_qtable(1));
 
reg = H1_REG_AXI_CTRL_OUTPUT_SWAP16
| H1_REG_AXI_CTRL_INPUT_SWAP16
diff --git a/drivers/staging/media/hantro/hantro_jpeg.c 
b/drivers/staging/media/hantro/hantro_jpeg.c
index d3b381d00b23..36c140fc6a36 100644
--- a/drivers/staging/media/hantro/hantro_jpeg.c
+++ b/drivers/staging/media/hantro/hantro_jpeg.c
@@ -36,6 +36,8 @@ static const unsigned char luma_q_table[] = {
0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0x63
 };
 
+static unsigned char luma_q_table_reordered[ARRAY_SIZE(luma_q_table)];
+
 static const unsigned char chroma_q_table[] = {
0x11, 0x12, 0x18, 0x2f, 0x63, 0x63, 0x63, 0x63,
0x12, 0x15, 0x1a, 0x42, 0x63, 0x63, 0x63, 0x63,
@@ -47,6 +49,30 @@ static const unsigned char chroma_q_table[] = {
0x63, 0x63, 0x63, 0x63, 0x63, 0x63, 0x63, 0x63
 };
 
+static unsigned char chroma_q_table_reordered[ARRAY_SIZE(chroma_q_table)];
+
+static const unsigned char zigzag[64] = {
+0,  1,  8, 16,  9,  2,  3, 10,
+   17, 24, 32, 25, 18, 11,  4,  5,
+   12, 19, 26, 33, 40, 48, 41, 34,
+   27, 20, 13,  6,  7, 14, 21, 28,
+   35, 42, 49, 56, 57, 50, 43, 36,
+   29, 22, 15, 23, 30, 37, 44, 51,
+   58, 59, 52, 45, 38, 31, 39, 46,
+   53, 60, 61, 54, 47, 55, 62, 63
+};
+
+static const u32 hw_reorder[64] = {
+0,  8, 16, 24,  1,  9, 17, 25,
+   32, 40, 48, 56, 33, 41, 49, 57,
+2, 10, 18, 26,  3, 11, 19, 27,
+   34, 42, 50, 58, 35, 43, 51, 59,
+4, 12, 20, 28,  5, 13, 21, 29,
+   36, 44, 52, 60, 37, 45, 53, 61,
+6, 14, 22, 30,  7, 15, 23, 31,
+   38, 46, 54, 62, 39, 47, 55, 63
+};
+
 /* Huffman tables are shared with CODA */
 static const unsigned char luma_dc_table[] = {
0x00, 0x01, 0x05, 0x01, 0x01, 0x01, 0x01, 0x01,
@@ -225,20 +251,29 @@ static const unsigned char 
hantro_jpeg_header[JPEG_HEADER_SIZE] = {
0x11, 0x03, 0x11, 0x00, 0x3f, 0x00,
 };
 
+static unsigned char jpeg_scale_qp(const unsigned char qp, int scale)
+{
+   unsigned int temp;
+
+   temp = DIV_ROUND_CLOSEST((unsigned int)qp * scale, 100);
+   if (temp <= 0)
+   temp = 1;
+   if (temp

[PATCH 1/4] media: hantro: Read be32 words starting at every fourth byte

Since (luma/chroma)_qtable is an array of unsigned char, indexing it
returns consecutive byte locations, but we are supposed to read the arrays
in four-byte words. Consequently, we should be pointing
get_unaligned_be32() at consecutive word locations instead.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/hantro/hantro_h1_jpeg_enc.c | 9 +++--
 drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c | 9 +++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c 
b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index 938b48d4d3d9..be787a045c7e 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -67,12 +67,17 @@ hantro_h1_jpeg_enc_set_qtable(struct hantro_dev *vpu,
  unsigned char *chroma_qtable)
 {
u32 reg, i;
+   __be32 *luma_qtable_p;
+   __be32 *chroma_qtable_p;
+
+   luma_qtable_p = (__be32 *)luma_qtable;
+   chroma_qtable_p = (__be32 *)chroma_qtable;
 
for (i = 0; i < H1_JPEG_QUANT_TABLE_COUNT; i++) {
-   reg = get_unaligned_be32(&luma_qtable[i]);
+   reg = get_unaligned_be32(&luma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, H1_REG_JPEG_LUMA_QUAT(i));
 
-   reg = get_unaligned_be32(&chroma_qtable[i]);
+   reg = get_unaligned_be32(&chroma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, H1_REG_JPEG_CHROMA_QUAT(i));
}
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
index 067892345b5d..bdb95652d6a8 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
@@ -98,12 +98,17 @@ rk3399_vpu_jpeg_enc_set_qtable(struct hantro_dev *vpu,
   unsigned char *chroma_qtable)
 {
u32 reg, i;
+   __be32 *luma_qtable_p;
+   __be32 *chroma_qtable_p;
+
+   luma_qtable_p = (__be32 *)luma_qtable;
+   chroma_qtable_p = (__be32 *)chroma_qtable;
 
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
-   reg = get_unaligned_be32(&luma_qtable[i]);
+   reg = get_unaligned_be32(&luma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
 
-   reg = get_unaligned_be32(&chroma_qtable[i]);
+   reg = get_unaligned_be32(&chroma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_CHROMA_QUAT(i));
}
 }
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/4] media: hantro: Use standard luma quantization table

The table is actually different in the document than in this file, so align
this file with the document.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/hantro/hantro_jpeg.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_jpeg.c 
b/drivers/staging/media/hantro/hantro_jpeg.c
index 125eb41f2ede..d3b381d00b23 100644
--- a/drivers/staging/media/hantro/hantro_jpeg.c
+++ b/drivers/staging/media/hantro/hantro_jpeg.c
@@ -23,17 +23,17 @@
 #define HUFF_CHROMA_AC_OFF 409
 
 /* Default tables from JPEG ITU-T.81
- * (ISO/IEC 10918-1) Annex K.3, I
+ * (ISO/IEC 10918-1) Annex K, tables K.1 and K.2
  */
 static const unsigned char luma_q_table[] = {
-   0x10, 0x0b, 0x0a, 0x10, 0x7c, 0x8c, 0x97, 0xa1,
-   0x0c, 0x0c, 0x0e, 0x13, 0x7e, 0x9e, 0xa0, 0x9b,
-   0x0e, 0x0d, 0x10, 0x18, 0x8c, 0x9d, 0xa9, 0x9c,
-   0x0e, 0x11, 0x16, 0x1d, 0x97, 0xbb, 0xb4, 0xa2,
-   0x12, 0x16, 0x25, 0x38, 0xa8, 0x6d, 0x67, 0xb1,
-   0x18, 0x23, 0x37, 0x40, 0xb5, 0x68, 0x71, 0xc0,
+   0x10, 0x0b, 0x0a, 0x10, 0x18, 0x28, 0x33, 0x3d,
+   0x0c, 0x0c, 0x0e, 0x13, 0x1a, 0x3a, 0x3c, 0x37,
+   0x0e, 0x0d, 0x10, 0x18, 0x28, 0x39, 0x45, 0x38,
+   0x0e, 0x11, 0x16, 0x1d, 0x33, 0x57, 0x50, 0x3e,
+   0x12, 0x16, 0x25, 0x38, 0x44, 0x6d, 0x67, 0x4d,
+   0x18, 0x23, 0x37, 0x40, 0x51, 0x68, 0x71, 0x5c,
0x31, 0x40, 0x4e, 0x57, 0x67, 0x79, 0x78, 0x65,
-   0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0xc7,
+   0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0x63
 };
 
 static const unsigned char chroma_q_table[] = {
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/4] media: hantro: Write quantization table registers in increasing addresses order

Luma and chroma qtables need to be written into two 16-register blocks,
each table consisting of 64 bytes total. The blocks are contiguous and
start at offset 0 for luma and at offset 0x40 for chroma.

The seemingly innocent optimization of writing the two blocks using one
loop causes side effects which result in improper values of quantization
tables being used by the hardware during encoding. Visually this results
in macroblocking artifacts around contrasting edges in encoded images. The
artifacts look like horizontally flipped shadows of the said edges.
Changing the write operations to non-relaxed variant doesn't help.

This patch removes this premature optimization and after this change the
macroblocking artifacts around contrasting edges are gone.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/hantro/hantro_h1_jpeg_enc.c | 6 ++
 drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c 
b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index bd05aea1bd71..fb43ec770e9e 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -73,10 +73,16 @@ hantro_h1_jpeg_enc_set_qtable(struct hantro_dev *vpu,
luma_qtable_p = (__be32 *)luma_qtable;
chroma_qtable_p = (__be32 *)chroma_qtable;
 
+   /*
+* Quantization table registers must be written in contiguous blocks.
+* DO NOT collapse the below two "for" loops into one.
+*/
for (i = 0; i < H1_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&luma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, H1_REG_JPEG_LUMA_QUAT(i));
+   }
 
+   for (i = 0; i < H1_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&chroma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, H1_REG_JPEG_CHROMA_QUAT(i));
}
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
index a0cf34073235..f4dbffda0be7 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
@@ -103,10 +103,16 @@ rk3399_vpu_jpeg_enc_set_qtable(struct hantro_dev *vpu,
luma_qtable_p = (__be32 *)luma_qtable;
chroma_qtable_p = (__be32 *)chroma_qtable;
 
+   /*
+* Quantization table registers must be written in contiguous blocks.
+* DO NOT collapse the below two "for" loops into one.
+*/
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&luma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
+   }
 
+   for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&chroma_qtable_p[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_CHROMA_QUAT(i));
}
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/4] Hantro VPU JPEG encoder fixes

2020-02-07 Thread Andrzej Pietrasiewicz


Hi All,




I've just tested RK3288, and this series is indeed fixing
these issues. So for all patches:

Tested-by: Ezequiel Garcia 


A kind reminder.

The series fixes serious encoding quality problems in both rk3399 and rk3288,
so it seems it should be included. A review is needed, though, at least for
patches 2-4.

Thank you,

Andrzej
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 1/3] media: rkvdec: Fix .buf_prepare

From: Ezequiel Garcia 

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/rkvdec.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c 
b/drivers/staging/media/rkvdec/rkvdec.c
index d821661d30f3..ef2166043127 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -481,7 +481,15 @@ static int rkvdec_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, i) < sizeimage)
return -EINVAL;
}
-   vb2_set_plane_payload(vb, 0, f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
+   /*
+* Buffer bytesused is written by driver for CAPTURE buffers.
+* (if userspace passes 0 bytesused for OUTPUT buffers, v4l2-core sets
+* it to buffer length).
+*/
+   if (!V4L2_TYPE_IS_OUTPUT(vq->type))
+   vb2_set_plane_payload(vb, 0, 
f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
return 0;
 }
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 2/3] media: uapi: Add VP9 stateless decoder controls

Add the VP9 stateless decoder controls plus the documentation that goes
with it.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 .../userspace-api/media/v4l/biblio.rst|  10 +
 .../media/v4l/ext-ctrls-codec-stateless.rst   | 523 ++
 .../media/v4l/pixfmt-compressed.rst   |  15 +
 .../media/v4l/vidioc-g-ext-ctrls.rst  |   8 +
 .../media/v4l/vidioc-queryctrl.rst|  12 +
 .../media/videodev2.h.rst.exceptions  |   2 +
 drivers/media/v4l2-core/v4l2-ctrls.c  | 244 
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|   4 +
 include/uapi/linux/v4l2-controls.h| 455 +++
 include/uapi/linux/videodev2.h|   6 +
 11 files changed, 1280 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/biblio.rst 
b/Documentation/userspace-api/media/v4l/biblio.rst
index 64d241daf63c..051982896375 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -417,3 +417,13 @@ VP8
 :title: RFC 6386: "VP8 Data Format and Decoding Guide"
 
 :author:J. Bankoski et al.
+
+.. _vp9:
+
+VP9
+===
+
+
+:title: VP9 Bitstream & Decoding Process Specification
+
+:author:Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan 
Hunt (Argon Design)
diff --git 
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3fc04daa9ffb..ab40c878c8ad 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1244,3 +1244,526 @@ FWHT Flags
 * - __u8
   - ``padding[3]``
   - Applications and drivers must set this to zero.
+
+.. _v4l2-codec-stateless-vp9:
+
+``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS (struct)``
+Stores VP9 probabilities updates as parsed from the current compressed 
frame
+header. A value of zero in a struct member means no update of the relevant
+probability. Motion vector-related updates contain a new value or zero. All
+other updates contain values translated with inv_map_table[] (see 6.3.5 in
+:ref:`vp9`).
+
+.. c:type:: v4l2_ctrl_vp9_compressed_hdr_probs
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_vp9_compressed_hdr_probs
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``tx8[2][1]``
+  - TX 8x8 probabilities delta.
+* - __u8
+  - ``tx16[2][2]``
+  - TX 16x16 probabilities delta.
+* - __u8
+  - ``tx32[2][3]``
+  - TX 32x32 probabilities delta.
+* - __u8
+  - ``coef[4][2][2][6][6][3]``
+  - Coefficient probabilities delta.
+* - __u8
+  - ``skip[3]``
+  - Skip probabilities delta.
+* - __u8
+  - ``inter_mode[7][3]``
+  - Inter prediction mode probabilities delta.
+* - __u8
+  - ``interp_filter[4][2]``
+  - Interpolation filter probabilities delta.
+* - __u8
+  - ``is_inter[4]``
+  - Is inter-block probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound prediction mode probabilities delta.
+* - __u8
+  - ``single_ref[5][2]``
+  - Single reference probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound reference probabilities delta.
+* - __u8
+  - ``y_mode[4][9]``
+  - Y prediction mode probabilities delta.
+* - __u8
+  - ``uv_mode[10][9]``
+  - UV prediction mode probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``mv.joint[3]``
+  - Motion vector joint probabilities delta.
+* - __u8
+  - ``mv.sign[2]``
+  - Motion vector sign probabilities delta.
+* - __u8
+  - ``mv.class[2][10]``
+  - Motion vector class probabilities delta.
+* - __u8
+  - ``mv.class0_bit[2]``
+  - Motion vector class0 bit probabilities delta.
+* - __u8
+  - ``mv.bits[2][10]``
+  - Motion vector bits probabilities delta.
+* - __u8
+  - ``mv.class0_fr[2][2][3]``
+  - Motion vector class0 fractional bit probabilities delta.
+* - __u8
+  - ``mv.fr[2][3]``
+  - Motion vector fractional bit probabilities delta.
+* - __u8
+  - ``mv.class0_hp[2]``
+  - Motion vector class0 high precision fractional bit probabilities delta.
+* - __u8
+  - ``mv.hp[2]``
+  - Motion vector high precision fractional bit probabilities delta.
+
+``V4L2_CID_STATELESS_VP9_FRAME_DECODE_PARAMS (struct)``
+Specifies the frame parameters for the associated VP9 frame decode request.
+Thi

[RFC 3/3] media: rkvdec: Add the VP9 backend

From: Boris Brezillon 

The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
a backend for this new format.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/Makefile |2 +-
 drivers/staging/media/rkvdec/rkvdec-vp9.c | 2846 +
 drivers/staging/media/rkvdec/rkvdec.c |   52 +-
 drivers/staging/media/rkvdec/rkvdec.h |6 +
 4 files changed, 2901 insertions(+), 5 deletions(-)
 create mode 100644 drivers/staging/media/rkvdec/rkvdec-vp9.c

diff --git a/drivers/staging/media/rkvdec/Makefile 
b/drivers/staging/media/rkvdec/Makefile
index c08fed0a39f9..cb86b429cfaa 100644
--- a/drivers/staging/media/rkvdec/Makefile
+++ b/drivers/staging/media/rkvdec/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rockchip-vdec.o
 
-rockchip-vdec-y += rkvdec.o rkvdec-h264.o
+rockchip-vdec-y += rkvdec.o rkvdec-h264.o rkvdec-vp9.o
diff --git a/drivers/staging/media/rkvdec/rkvdec-vp9.c 
b/drivers/staging/media/rkvdec/rkvdec-vp9.c
new file mode 100644
index ..82e5dcfe5ef0
--- /dev/null
+++ b/drivers/staging/media/rkvdec/rkvdec-vp9.c
@@ -0,0 +1,2846 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip Video Decoder VP9 backend
+ *
+ * Copyright (C) 2019 Collabora, Ltd.
+ * Boris Brezillon 
+ * Copyright (C) 2021 Collabora, Ltd.
+ * Andrzej Pietrasiewicz 
+ *
+ * Copyright (C) 2016 Rockchip Electronics Co., Ltd.
+ * Alpha Lin 
+ */
+
+/*
+ * For following the vp9 spec please start reading this driver
+ * code from rkvdec_vp9_run() followed by rkvdec_vp9_done().
+ */
+
+#include 
+#include 
+#include 
+
+#include "rkvdec.h"
+#include "rkvdec-regs.h"
+
+#define RKVDEC_VP9_PROBE_SIZE  4864
+#define RKVDEC_VP9_COUNT_SIZE  13232
+#define RKVDEC_VP9_MAX_SEGMAP_SIZE 73728
+
+struct rkvdec_vp9_intra_mode_probs {
+   u8 y_mode[105];
+   u8 uv_mode[23];
+};
+
+struct rkvdec_vp9_intra_only_frame_probs {
+   u8 coef_intra[4][2][128];
+   struct rkvdec_vp9_intra_mode_probs intra_mode[10];
+};
+
+struct rkvdec_vp9_inter_frame_probs {
+   u8 y_mode[4][9];
+   u8 comp_mode[5];
+   u8 comp_ref[5];
+   u8 single_ref[5][2];
+   u8 inter_mode[7][3];
+   u8 interp_filter[4][2];
+   u8 padding0[11];
+   u8 coef[2][4][2][128];
+   u8 uv_mode_0_2[3][9];
+   u8 padding1[5];
+   u8 uv_mode_3_5[3][9];
+   u8 padding2[5];
+   u8 uv_mode_6_8[3][9];
+   u8 padding3[5];
+   u8 uv_mode_9[9];
+   u8 padding4[7];
+   u8 padding5[16];
+   struct {
+   u8 joint[3];
+   u8 sign[2];
+   u8 class[2][10];
+   u8 class0_bit[2];
+   u8 bits[2][10];
+   u8 class0_fr[2][2][3];
+   u8 fr[2][3];
+   u8 class0_hp[2];
+   u8 hp[2];
+   } mv;
+};
+
+struct rkvdec_vp9_probs {
+   u8 partition[16][3];
+   u8 pred[3];
+   u8 tree[7];
+   u8 skip[3];
+   u8 tx32[2][3];
+   u8 tx16[2][2];
+   u8 tx8[2][1];
+   u8 is_inter[4];
+   /* 128 bit alignment */
+   u8 padding0[3];
+   union {
+   struct rkvdec_vp9_inter_frame_probs inter;
+   struct rkvdec_vp9_intra_only_frame_probs intra_only;
+   };
+};
+
+/* Data structure describing auxiliary buffer format. */
+struct rkvdec_vp9_priv_tbl {
+   struct rkvdec_vp9_probs probs;
+   u8 segmap[2][RKVDEC_VP9_MAX_SEGMAP_SIZE];
+};
+
+struct rkvdec_vp9_refs_counts {
+   u32 eob[2];
+   u32 coeff[3];
+};
+
+struct rkvdec_vp9_inter_frame_symbol_counts {
+   u32 partition[16][4];
+   u32 skip[3][2];
+   u32 inter[4][2];
+   u32 tx32p[2][4];
+   u32 tx16p[2][4];
+   u32 tx8p[2][2];
+   u32 y_mode[4][10];
+   u32 uv_mode[10][10];
+   u32 comp[5][2];
+   u32 comp_ref[5][2];
+   u32 single_ref[5][2][2];
+   u32 mv_mode[7][4];
+   u32 filter[4][3];
+   u32 mv_joint[4];
+   u32 sign[2][2];
+   /* add 1 element for align */
+   u32 classes[2][11 + 1];
+   u32 class0[2][2];
+   u32 bits[2][10][2];
+   u32 class0_fp[2][2][4];
+   u32 fp[2][4];
+   u32 class0_hp[2][2];
+   u32 hp[2][2];
+   struct rkvdec_vp9_refs_counts ref_cnt[2][4][2][6][6];
+};
+
+struct rkvdec_vp9_intra_frame_symbol_counts {
+   u32 partition[4][4][4];
+   u32 skip[3][2];
+   u32 intra[4][2];
+   u32 tx32p[2][4];
+   u32 tx16p[2][4];
+   u32 tx8p[2][2];
+   struct rkvdec_vp9_refs_counts ref_cnt[2][4][2][6][6];
+};
+
+struct rkvdec_vp9_run {
+   struct rkvdec_run base;
+   const struct v4l2_ctrl_vp9_frame_decode_params *decode_params;
+};
+
+struct rkvdec_vp9_frame_info {
+   u32 valid : 1;
+   u32 segmapid : 1;
+   u32 frame_context_idx : 2;
+   u32 reference_mode : 2;
+   u32 tx_mode : 3;
+   u32 interpolation_fil

[RFC RESEND 0/3] vp9 v4l2 stateless uapi

Dear All,

This is an RFC on stateless uapi for vp9 decoding with v4l2. This work is based 
on https://lkml.org/lkml/2020/11/2/1043, but has been substantially reworked. 
The important change is that the v4l2 control used to pass boolean decoder 
probabilities has been made unidirectional, and is now called 
V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS.

In the previous proposal, to queue a frame the userspace must fully dequeue the 
previous one, which effectively results in a forced lockstep behavior and 
defeats vb2's capability to enqueue multiple buffers. Such a design was a 
consequence of backward probability updates being performed by the kernel 
driver (which has direct access to appropriate counter values) but forward 
probability updates being coupled with compressed header parsing performed by 
the userspace.

In vp9 the boolean decoder used to decode the bitstream needs certain 
parameters to work. Those are probabilities, which change with each frame. 
After each frame is decoded it is known how many times a given symbol occured 
in the frame, so the probabilities can be adapted. This process is known as 
backward probabilities update. A next frame header can also contain information 
which modifies probabilities resulting from backward update. The said 
modification is called forward probabilities update. The data for backward 
update is generated by the decoder hardware, while the data for forward update 
is prepared by reading the compressed frame header. The natural place to parse 
something is userspace, while the natural place to access hardware-provided 
counters is the kernel. Such responsibilties assignment was used in the 
original work.

To overcome the lockstep, we moved forward probability updates to the kernel, 
while leaving parsing them in userspace. This way the v4l2 control which is 
used to pass the probs becomes unidirectional (user->kernel) and the userspace 
can keep parsing and enqueueing succeeding frames.

If a particular driver parses the compressed header and does backward 
probability updates on its own then V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS 
does not need to be used.

This series adds vp9 uapi in proper locations, which means it is a proper, 
"official" uapi, as opposed to staging uapi which was proposed in the above 
mentioned lkml thread.

The series adds vp9 support to rkvdec driver.

Rebased onto media_tree.

I kindly ask for your comments.

TODO:

- potentially fine-tune the uAPI (add/remove fields, move between structs)
- write another driver (intended g2 @ iMX8)
- verify the added documentation

Regards,

Andrzej

Andrzej Pietrasiewicz (1):
  media: uapi: Add VP9 stateless decoder controls

Boris Brezillon (1):
  media: rkvdec: Add the VP9 backend

Ezequiel Garcia (1):
  media: rkvdec: Fix .buf_prepare

 .../userspace-api/media/v4l/biblio.rst|   10 +
 .../media/v4l/ext-ctrls-codec-stateless.rst   |  523 +++
 .../media/v4l/pixfmt-compressed.rst   |   15 +
 .../media/v4l/vidioc-g-ext-ctrls.rst  |8 +
 .../media/v4l/vidioc-queryctrl.rst|   12 +
 .../media/videodev2.h.rst.exceptions  |2 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  244 ++
 drivers/media/v4l2-core/v4l2-ioctl.c  |1 +
 drivers/staging/media/rkvdec/Makefile |2 +-
 drivers/staging/media/rkvdec/rkvdec-vp9.c | 2846 +
 drivers/staging/media/rkvdec/rkvdec.c |   62 +-
 drivers/staging/media/rkvdec/rkvdec.h |6 +
 include/media/v4l2-ctrls.h|4 +
 include/uapi/linux/v4l2-controls.h|  455 +++
 include/uapi/linux/videodev2.h|6 +
 15 files changed, 4190 insertions(+), 6 deletions(-)
 create mode 100644 drivers/staging/media/rkvdec/rkvdec-vp9.c

-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC RESEND 1/3] media: rkvdec: Fix .buf_prepare

From: Ezequiel Garcia 

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/rkvdec.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c 
b/drivers/staging/media/rkvdec/rkvdec.c
index d821661d30f3..ef2166043127 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -481,7 +481,15 @@ static int rkvdec_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, i) < sizeimage)
return -EINVAL;
}
-   vb2_set_plane_payload(vb, 0, f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
+   /*
+* Buffer bytesused is written by driver for CAPTURE buffers.
+* (if userspace passes 0 bytesused for OUTPUT buffers, v4l2-core sets
+* it to buffer length).
+*/
+   if (!V4L2_TYPE_IS_OUTPUT(vq->type))
+   vb2_set_plane_payload(vb, 0, 
f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
return 0;
 }
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC RESEND 2/3] media: uapi: Add VP9 stateless decoder controls

Add the VP9 stateless decoder controls plus the documentation that goes
with it.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 .../userspace-api/media/v4l/biblio.rst|  10 +
 .../media/v4l/ext-ctrls-codec-stateless.rst   | 523 ++
 .../media/v4l/pixfmt-compressed.rst   |  15 +
 .../media/v4l/vidioc-g-ext-ctrls.rst  |   8 +
 .../media/v4l/vidioc-queryctrl.rst|  12 +
 .../media/videodev2.h.rst.exceptions  |   2 +
 drivers/media/v4l2-core/v4l2-ctrls.c  | 244 
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|   4 +
 include/uapi/linux/v4l2-controls.h| 455 +++
 include/uapi/linux/videodev2.h|   6 +
 11 files changed, 1280 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/biblio.rst 
b/Documentation/userspace-api/media/v4l/biblio.rst
index 64d241daf63c..051982896375 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -417,3 +417,13 @@ VP8
 :title: RFC 6386: "VP8 Data Format and Decoding Guide"
 
 :author:J. Bankoski et al.
+
+.. _vp9:
+
+VP9
+===
+
+
+:title: VP9 Bitstream & Decoding Process Specification
+
+:author:Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan 
Hunt (Argon Design)
diff --git 
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3fc04daa9ffb..ab40c878c8ad 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1244,3 +1244,526 @@ FWHT Flags
 * - __u8
   - ``padding[3]``
   - Applications and drivers must set this to zero.
+
+.. _v4l2-codec-stateless-vp9:
+
+``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS (struct)``
+Stores VP9 probabilities updates as parsed from the current compressed 
frame
+header. A value of zero in a struct member means no update of the relevant
+probability. Motion vector-related updates contain a new value or zero. All
+other updates contain values translated with inv_map_table[] (see 6.3.5 in
+:ref:`vp9`).
+
+.. c:type:: v4l2_ctrl_vp9_compressed_hdr_probs
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_vp9_compressed_hdr_probs
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``tx8[2][1]``
+  - TX 8x8 probabilities delta.
+* - __u8
+  - ``tx16[2][2]``
+  - TX 16x16 probabilities delta.
+* - __u8
+  - ``tx32[2][3]``
+  - TX 32x32 probabilities delta.
+* - __u8
+  - ``coef[4][2][2][6][6][3]``
+  - Coefficient probabilities delta.
+* - __u8
+  - ``skip[3]``
+  - Skip probabilities delta.
+* - __u8
+  - ``inter_mode[7][3]``
+  - Inter prediction mode probabilities delta.
+* - __u8
+  - ``interp_filter[4][2]``
+  - Interpolation filter probabilities delta.
+* - __u8
+  - ``is_inter[4]``
+  - Is inter-block probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound prediction mode probabilities delta.
+* - __u8
+  - ``single_ref[5][2]``
+  - Single reference probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound reference probabilities delta.
+* - __u8
+  - ``y_mode[4][9]``
+  - Y prediction mode probabilities delta.
+* - __u8
+  - ``uv_mode[10][9]``
+  - UV prediction mode probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``mv.joint[3]``
+  - Motion vector joint probabilities delta.
+* - __u8
+  - ``mv.sign[2]``
+  - Motion vector sign probabilities delta.
+* - __u8
+  - ``mv.class[2][10]``
+  - Motion vector class probabilities delta.
+* - __u8
+  - ``mv.class0_bit[2]``
+  - Motion vector class0 bit probabilities delta.
+* - __u8
+  - ``mv.bits[2][10]``
+  - Motion vector bits probabilities delta.
+* - __u8
+  - ``mv.class0_fr[2][2][3]``
+  - Motion vector class0 fractional bit probabilities delta.
+* - __u8
+  - ``mv.fr[2][3]``
+  - Motion vector fractional bit probabilities delta.
+* - __u8
+  - ``mv.class0_hp[2]``
+  - Motion vector class0 high precision fractional bit probabilities delta.
+* - __u8
+  - ``mv.hp[2]``
+  - Motion vector high precision fractional bit probabilities delta.
+
+``V4L2_CID_STATELESS_VP9_FRAME_DECODE_PARAMS (struct)``
+Specifies the frame parameters for the associated VP9 frame decode request.
+Thi

[RFC RESEND 3/3] media: rkvdec: Add the VP9 backend

From: Boris Brezillon 

The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
a backend for this new format.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/Makefile |2 +-
 drivers/staging/media/rkvdec/rkvdec-vp9.c | 2846 +
 drivers/staging/media/rkvdec/rkvdec.c |   52 +-
 drivers/staging/media/rkvdec/rkvdec.h |6 +
 4 files changed, 2901 insertions(+), 5 deletions(-)
 create mode 100644 drivers/staging/media/rkvdec/rkvdec-vp9.c

diff --git a/drivers/staging/media/rkvdec/Makefile 
b/drivers/staging/media/rkvdec/Makefile
index c08fed0a39f9..cb86b429cfaa 100644
--- a/drivers/staging/media/rkvdec/Makefile
+++ b/drivers/staging/media/rkvdec/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rockchip-vdec.o
 
-rockchip-vdec-y += rkvdec.o rkvdec-h264.o
+rockchip-vdec-y += rkvdec.o rkvdec-h264.o rkvdec-vp9.o
diff --git a/drivers/staging/media/rkvdec/rkvdec-vp9.c 
b/drivers/staging/media/rkvdec/rkvdec-vp9.c
new file mode 100644
index ..82e5dcfe5ef0
--- /dev/null
+++ b/drivers/staging/media/rkvdec/rkvdec-vp9.c
@@ -0,0 +1,2846 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip Video Decoder VP9 backend
+ *
+ * Copyright (C) 2019 Collabora, Ltd.
+ * Boris Brezillon 
+ * Copyright (C) 2021 Collabora, Ltd.
+ * Andrzej Pietrasiewicz 
+ *
+ * Copyright (C) 2016 Rockchip Electronics Co., Ltd.
+ * Alpha Lin 
+ */
+
+/*
+ * For following the vp9 spec please start reading this driver
+ * code from rkvdec_vp9_run() followed by rkvdec_vp9_done().
+ */
+
+#include 
+#include 
+#include 
+
+#include "rkvdec.h"
+#include "rkvdec-regs.h"
+
+#define RKVDEC_VP9_PROBE_SIZE  4864
+#define RKVDEC_VP9_COUNT_SIZE  13232
+#define RKVDEC_VP9_MAX_SEGMAP_SIZE 73728
+
+struct rkvdec_vp9_intra_mode_probs {
+   u8 y_mode[105];
+   u8 uv_mode[23];
+};
+
+struct rkvdec_vp9_intra_only_frame_probs {
+   u8 coef_intra[4][2][128];
+   struct rkvdec_vp9_intra_mode_probs intra_mode[10];
+};
+
+struct rkvdec_vp9_inter_frame_probs {
+   u8 y_mode[4][9];
+   u8 comp_mode[5];
+   u8 comp_ref[5];
+   u8 single_ref[5][2];
+   u8 inter_mode[7][3];
+   u8 interp_filter[4][2];
+   u8 padding0[11];
+   u8 coef[2][4][2][128];
+   u8 uv_mode_0_2[3][9];
+   u8 padding1[5];
+   u8 uv_mode_3_5[3][9];
+   u8 padding2[5];
+   u8 uv_mode_6_8[3][9];
+   u8 padding3[5];
+   u8 uv_mode_9[9];
+   u8 padding4[7];
+   u8 padding5[16];
+   struct {
+   u8 joint[3];
+   u8 sign[2];
+   u8 class[2][10];
+   u8 class0_bit[2];
+   u8 bits[2][10];
+   u8 class0_fr[2][2][3];
+   u8 fr[2][3];
+   u8 class0_hp[2];
+   u8 hp[2];
+   } mv;
+};
+
+struct rkvdec_vp9_probs {
+   u8 partition[16][3];
+   u8 pred[3];
+   u8 tree[7];
+   u8 skip[3];
+   u8 tx32[2][3];
+   u8 tx16[2][2];
+   u8 tx8[2][1];
+   u8 is_inter[4];
+   /* 128 bit alignment */
+   u8 padding0[3];
+   union {
+   struct rkvdec_vp9_inter_frame_probs inter;
+   struct rkvdec_vp9_intra_only_frame_probs intra_only;
+   };
+};
+
+/* Data structure describing auxiliary buffer format. */
+struct rkvdec_vp9_priv_tbl {
+   struct rkvdec_vp9_probs probs;
+   u8 segmap[2][RKVDEC_VP9_MAX_SEGMAP_SIZE];
+};
+
+struct rkvdec_vp9_refs_counts {
+   u32 eob[2];
+   u32 coeff[3];
+};
+
+struct rkvdec_vp9_inter_frame_symbol_counts {
+   u32 partition[16][4];
+   u32 skip[3][2];
+   u32 inter[4][2];
+   u32 tx32p[2][4];
+   u32 tx16p[2][4];
+   u32 tx8p[2][2];
+   u32 y_mode[4][10];
+   u32 uv_mode[10][10];
+   u32 comp[5][2];
+   u32 comp_ref[5][2];
+   u32 single_ref[5][2][2];
+   u32 mv_mode[7][4];
+   u32 filter[4][3];
+   u32 mv_joint[4];
+   u32 sign[2][2];
+   /* add 1 element for align */
+   u32 classes[2][11 + 1];
+   u32 class0[2][2];
+   u32 bits[2][10][2];
+   u32 class0_fp[2][2][4];
+   u32 fp[2][4];
+   u32 class0_hp[2][2];
+   u32 hp[2][2];
+   struct rkvdec_vp9_refs_counts ref_cnt[2][4][2][6][6];
+};
+
+struct rkvdec_vp9_intra_frame_symbol_counts {
+   u32 partition[4][4][4];
+   u32 skip[3][2];
+   u32 intra[4][2];
+   u32 tx32p[2][4];
+   u32 tx16p[2][4];
+   u32 tx8p[2][2];
+   struct rkvdec_vp9_refs_counts ref_cnt[2][4][2][6][6];
+};
+
+struct rkvdec_vp9_run {
+   struct rkvdec_run base;
+   const struct v4l2_ctrl_vp9_frame_decode_params *decode_params;
+};
+
+struct rkvdec_vp9_frame_info {
+   u32 valid : 1;
+   u32 segmapid : 1;
+   u32 frame_context_idx : 2;
+   u32 reference_mode : 2;
+   u32 tx_mode : 3;
+   u32 interpolation_fil

Re: [RFC RESEND 2/3] media: uapi: Add VP9 stateless decoder controls

2021-04-30 Thread Andrzej Pietrasiewicz


Hi Hans,

Thank you for the review. I'm working on a v2 to address your comments.
Also please see inline.

Andrzej

W dniu 29.04.2021 o 12:20, Hans Verkuil pisze:

On 21/04/2021 12:00, Andrzej Pietrasiewicz wrote:

Add the VP9 stateless decoder controls plus the documentation that goes
with it.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
  .../userspace-api/media/v4l/biblio.rst|  10 +
  .../media/v4l/ext-ctrls-codec-stateless.rst   | 523 ++
  .../media/v4l/pixfmt-compressed.rst   |  15 +
  .../media/v4l/vidioc-g-ext-ctrls.rst  |   8 +
  .../media/v4l/vidioc-queryctrl.rst|  12 +
  .../media/videodev2.h.rst.exceptions  |   2 +
  drivers/media/v4l2-core/v4l2-ctrls.c  | 244 
  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
  include/media/v4l2-ctrls.h|   4 +
  include/uapi/linux/v4l2-controls.h| 455 +++
  include/uapi/linux/videodev2.h|   6 +
  11 files changed, 1280 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/biblio.rst 
b/Documentation/userspace-api/media/v4l/biblio.rst
index 64d241daf63c..051982896375 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -417,3 +417,13 @@ VP8
  :title: RFC 6386: "VP8 Data Format and Decoding Guide"
  
  :author:J. Bankoski et al.

+
+.. _vp9:
+
+VP9
+===
+
+
+:title: VP9 Bitstream & Decoding Process Specification
+
+:author:Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan 
Hunt (Argon Design)
diff --git 
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3fc04daa9ffb..ab40c878c8ad 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1244,3 +1244,526 @@ FWHT Flags
  * - __u8
- ``padding[3]``
- Applications and drivers must set this to zero.
+
+.. _v4l2-codec-stateless-vp9:
+
+``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS (struct)``
+Stores VP9 probabilities updates as parsed from the current compressed 
frame
+header. A value of zero in a struct member means no update of the relevant
+probability. Motion vector-related updates contain a new value or zero. All
+other updates contain values translated with inv_map_table[] (see 6.3.5 in
+:ref:`vp9`).
+
+.. c:type:: v4l2_ctrl_vp9_compressed_hdr_probs
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_vp9_compressed_hdr_probs
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``tx8[2][1]``
+  - TX 8x8 probabilities delta.
+* - __u8
+  - ``tx16[2][2]``
+  - TX 16x16 probabilities delta.
+* - __u8
+  - ``tx32[2][3]``
+  - TX 32x32 probabilities delta.
+* - __u8
+  - ``coef[4][2][2][6][6][3]``
+  - Coefficient probabilities delta.
+* - __u8
+  - ``skip[3]``
+  - Skip probabilities delta.
+* - __u8
+  - ``inter_mode[7][3]``
+  - Inter prediction mode probabilities delta.
+* - __u8
+  - ``interp_filter[4][2]``
+  - Interpolation filter probabilities delta.
+* - __u8
+  - ``is_inter[4]``
+  - Is inter-block probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound prediction mode probabilities delta.
+* - __u8
+  - ``single_ref[5][2]``
+  - Single reference probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound reference probabilities delta.
+* - __u8
+  - ``y_mode[4][9]``
+  - Y prediction mode probabilities delta.
+* - __u8
+  - ``uv_mode[10][9]``
+  - UV prediction mode probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``mv.joint[3]``
+  - Motion vector joint probabilities delta.
+* - __u8
+  - ``mv.sign[2]``
+  - Motion vector sign probabilities delta.
+* - __u8
+  - ``mv.class[2][10]``
+  - Motion vector class probabilities delta.
+* - __u8
+  - ``mv.class0_bit[2]``
+  - Motion vector class0 bit probabilities delta.
+* - __u8
+  - ``mv.bits[2][10]``
+  - Motion vector bits probabilities delta.
+* - __u8
+  - ``mv.class0_fr[2][2][3]``
+  - Motion vector class0 fractional bit probabilities delta.
+* - __u8
+  - ``mv.fr[2][3]``
+  - Motion vector fractional bit probabilities delta.
+* - __u8
+  - ``mv.class0_hp[2]``
+  - Motion vector class0 high precision fractional bit probabilities delta.
+* - __u8

[PATCH] media: rkvdec: Fix .buf_prepare

2021-05-04 Thread Andrzej Pietrasiewicz

From: Ezequiel Garcia 

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 

---
@Hans: I haven't had anyone complain about the issue. The fix is needed for
the rkvdec vp9 work, so I think 5.14 is fine.

 drivers/staging/media/rkvdec/rkvdec.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c 
b/drivers/staging/media/rkvdec/rkvdec.c
index d821661d30f3..ef2166043127 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -481,7 +481,15 @@ static int rkvdec_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, i) < sizeimage)
return -EINVAL;
}
-   vb2_set_plane_payload(vb, 0, f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
+   /*
+* Buffer bytesused is written by driver for CAPTURE buffers.
+* (if userspace passes 0 bytesused for OUTPUT buffers, v4l2-core sets
+* it to buffer length).
+*/
+   if (!V4L2_TYPE_IS_OUTPUT(vq->type))
+   vb2_set_plane_payload(vb, 0, 
f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
return 0;
 }
 

base-commit: 0b276e470a4d43e1365d3eb53c608a3d208cabd4
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: rkvdec: Fix .buf_prepare


Hi Ezequiel,

W dniu 04.05.2021 o 13:56, Ezequiel Garcia pisze:

Hi Andrzej,

Thanks a lot for picking this up.

On Tue, 2021-05-04 at 13:37 +0200, Andrzej Pietrasiewicz wrote:

From: Ezequiel Garcia 

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 

---
@Hans: I haven't had anyone complain about the issue. The fix is needed for
the rkvdec vp9 work, so I think 5.14 is fine.

  drivers/staging/media/rkvdec/rkvdec.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c 
b/drivers/staging/media/rkvdec/rkvdec.c
index d821661d30f3..ef2166043127 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -481,7 +481,15 @@ static int rkvdec_buf_prepare(struct vb2_buffer *vb)
 if (vb2_plane_size(vb, i) < sizeimage)
 return -EINVAL;
 }
-   vb2_set_plane_payload(vb, 0, f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
+   /*
+    * Buffer bytesused is written by driver for CAPTURE buffers.
+    * (if userspace passes 0 bytesused for OUTPUT buffers, v4l2-core sets
+    * it to buffer length).
+    */
+   if (!V4L2_TYPE_IS_OUTPUT(vq->type))


Please use V4L2_TYPE_IS_CAPTURE here.

Also, why is this change needed in rkvdec, but not in cedrus
or hantro?



As a matter of fact I think it is needed in all three, because later on,
whenever a driver uses vb2_get_plane_payload(), without such a patch it
will get an invalid number and write that to a hardware register, causing
incorrect behavior.

I will respond with a v2 series.

Regards,

Andrzej
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv2 0/3] Fix .buf_prepare

Drivers should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

If we overwrite bytesused for OUTPUT buffers, too, then
vb2_get_plane_payload() will return incorrect value which might be then
written to hw registers by the driver.

Andrzej Pietrasiewicz (2):
  media: hantro: Fix .buf_prepare
  media: cedrus: Fix .buf_prepare

Ezequiel Garcia (1):
  media: rkvdec: Fix .buf_prepare

 drivers/staging/media/hantro/hantro_v4l2.c|  9 -
 drivers/staging/media/rkvdec/rkvdec.c | 10 +-
 drivers/staging/media/sunxi/cedrus/cedrus_video.c |  8 +++-
 3 files changed, 24 insertions(+), 3 deletions(-)


base-commit: 0b276e470a4d43e1365d3eb53c608a3d208cabd4
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv2 1/3] media: rkvdec: Fix .buf_prepare

From: Ezequiel Garcia 

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

If we overwrite bytesused for OUTPUT buffers, too, then
vb2_get_plane_payload() will return incorrect value which might be then
written to hw registers by the driver in rkvdec-h264.c.

Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
[Changed the comment and used V4L2_TYPE_IS_CAPTURE macro]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/rkvdec.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c 
b/drivers/staging/media/rkvdec/rkvdec.c
index d821661d30f3..cd65ad2af8d4 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -481,7 +481,15 @@ static int rkvdec_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, i) < sizeimage)
return -EINVAL;
}
-   vb2_set_plane_payload(vb, 0, f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
+   /*
+* Buffer's bytesused must be written by driver for CAPTURE buffers.
+* (for OUTPUT buffers, if userspace passes 0 bytesused, v4l2-core sets
+* it to buffer length).
+*/
+   if (V4L2_TYPE_IS_CAPTURE(vq->type))
+   vb2_set_plane_payload(vb, 0, 
f->fmt.pix_mp.plane_fmt[0].sizeimage);
+
return 0;
 }
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv2 2/3] media: hantro: Fix .buf_prepare

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

If we overwrite bytesused for OUTPUT buffers, too, then
vb2_get_plane_payload() will return incorrect value which might be then
written to hw registers by the driver in hantro_g1_h264_dec.c.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/hantro/hantro_v4l2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/hantro/hantro_v4l2.c 
b/drivers/staging/media/hantro/hantro_v4l2.c
index 1bc118e375a1..7ccc6405036a 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -639,7 +639,14 @@ static int hantro_buf_prepare(struct vb2_buffer *vb)
ret = hantro_buf_plane_check(vb, pix_fmt);
if (ret)
return ret;
-   vb2_set_plane_payload(vb, 0, pix_fmt->plane_fmt[0].sizeimage);
+   /*
+* Buffer's bytesused must be written by driver for CAPTURE buffers.
+* (for OUTPUT buffers, if userspace passes 0 bytesused, v4l2-core sets
+* it to buffer length).
+*/
+   if (V4L2_TYPE_IS_CAPTURE(vq->type))
+   vb2_set_plane_payload(vb, 0, pix_fmt->plane_fmt[0].sizeimage);
+
return 0;
 }
 
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv2 3/3] media: cedrus: Fix .buf_prepare

The driver should only set the payload on .buf_prepare if the
buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused
set by userspace then v4l2-core will set it to buffer length.

If we overwrite bytesused for OUTPUT buffers, too, then
vb2_get_plane_payload() will return incorrect value which might be then
written to hw registers by the driver in cedrus_h264.c or cedrus_vp8.c.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index b62eb8e84057..bf731caf2ed5 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -457,7 +457,13 @@ static int cedrus_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, 0) < pix_fmt->sizeimage)
return -EINVAL;
 
-   vb2_set_plane_payload(vb, 0, pix_fmt->sizeimage);
+   /*
+* Buffer's bytesused must be written by driver for CAPTURE buffers.
+* (for OUTPUT buffers, if userspace passes 0 bytesused, v4l2-core sets
+* it to buffer length).
+*/
+   if (V4L2_TYPE_IS_CAPTURE(vq->type))
+   vb2_set_plane_payload(vb, 0, pix_fmt->sizeimage);
 
return 0;
 }
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFCv2 0/3] vp9 v4l2 stateless uapi

Dear All,

This is a follow-up work for
https://patchwork.linuxtv.org/project/linux-media/list/?series=5268
I addressed Hans's comments.

Changes:

v1..v2:
- improve documentation
- imrpove coding style
- factor out of common vp9 code into v4l2-vp9.c
- rename V4L2_CID_STATELESS_VP9_FRAME_DECODE_PARAMS into
V4L2_CID_STATELESS_VP9_FRAME

This is still sent as an RFC because the works for adding the second driver
(g2@imx8)
are ongoing.

The v1 was an RFC on stateless uapi for vp9 decoding with v4l2, which was based
on
https://lkml.org/lkml/2020/11/2/1043, but had been substantially reworked. The
important
change was that the v4l2 control used to pass boolean decoder probabilities had
been made
unidirectional, and was renamed V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS.

In the original proposal from Boris, to queue a frame the userspace must fully
dequeue
the previous one, which effectively results in a forced lockstep behavior and
defeats
vb2's capability to enqueue multiple buffers. Such a design was a consequence
of backward
probability updates being performed by the kernel driver (which has direct
access to
appropriate counter values) but forward probability updates being coupled with
compressed
header parsing performed by the userspace.

In vp9 the boolean decoder used to decode the bitstream needs certain
parameters to work.
Those are probabilities, which change with each frame. After each frame is
decoded it is
known how many times a given symbol occured in the frame, so the probabilities
can be adapted.
This process is known as backward probabilities update. A next frame header can
also contain
information which modifies probabilities resulting from backward update. The
said modification
is called forward probabilities update. The data for backward update is
generated by the decoder
hardware, while the data for forward update is prepared by reading the
compressed frame header.
The natural place to parse something is userspace, while the natural place to
access
hardware-provided counters is the kernel. Such responsibilties assignment was
used in the
original work.

To overcome the lockstep, we moved forward probability updates to the kernel,
while leaving
parsing them in userspace. This way the v4l2 control which is used to pass the
probs becomes
unidirectional (user->kernel) and the userspace can keep parsing and enqueueing
succeeding
frames.

If a particular driver parses the compressed header and does backward
probability updates
on its own then V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS does not need to be
used.

This series adds vp9 uapi in proper locations, which means it is a proper,
"official" uapi,
as opposed to staging uapi which was proposed in the above mentioned lkml
thread.

The series adds vp9 support to rkvdec driver.

Rebased onto media_tree, requires this patch:

https://patchwork.linuxtv.org/project/linux-media/patch/20210505122347.7576-2-andrze...@collabora.com/

You can test rkvdec implementation with gstreamer, please clone gstreamer and
then
use these branches for -base and -bad:

https://gitlab.freedesktop.org/dwlsalmeida/gst-plugins-base/-/tree/vp9-upstream-padding
https://gitlab.freedesktop.org/dwlsalmeida/gst-plugins-bad/-/tree/vp9-upstream

Example invocation:

without format conversion:

gst-launch-1.0 filesrc location=Big_Buck_Bunny_1080_10s_1MB.webm ! parsebin !
v4l2slvp9dec ! filesink location=out.yuv

with format conversion to match vpxdec output:

gst-launch-1.0 filesrc location=Big_Buck_Bunny_1080_10s_1MB.webm ! parsebin !
v4l2slvp9dec ! videoconvert ! video/x-raw,format=I420 ! filesink
location=out.yuv

I kindly ask for your comments.

Andrzej Pietrasiewicz (2):
media: uapi: Add VP9 stateless decoder controls
media: uapi: Add VP9 v4l2 library

Boris Brezillon (1):
media: rkvdec: Add the VP9 backend

[RFCv2 1/3] media: uapi: Add VP9 stateless decoder controls

Add the VP9 stateless decoder controls plus the documentation that goes
with it.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 .../userspace-api/media/v4l/biblio.rst|  10 +
 .../media/v4l/ext-ctrls-codec-stateless.rst   | 547 ++
 .../media/v4l/pixfmt-compressed.rst   |  15 +
 .../media/v4l/vidioc-g-ext-ctrls.rst  |   8 +
 .../media/v4l/vidioc-queryctrl.rst|  12 +
 .../media/videodev2.h.rst.exceptions  |   2 +
 drivers/media/v4l2-core/v4l2-ctrls.c  | 229 
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|   4 +
 include/uapi/linux/v4l2-controls.h| 425 ++
 include/uapi/linux/videodev2.h|   6 +
 11 files changed, 1259 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/biblio.rst 
b/Documentation/userspace-api/media/v4l/biblio.rst
index 64d241daf63c..051982896375 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -417,3 +417,13 @@ VP8
 :title: RFC 6386: "VP8 Data Format and Decoding Guide"
 
 :author:J. Bankoski et al.
+
+.. _vp9:
+
+VP9
+===
+
+
+:title: VP9 Bitstream & Decoding Process Specification
+
+:author:Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan 
Hunt (Argon Design)
diff --git 
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3fc04daa9ffb..2d15d2d419a6 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1244,3 +1244,550 @@ FWHT Flags
 * - __u8
   - ``padding[3]``
   - Applications and drivers must set this to zero.
+
+.. _v4l2-codec-stateless-vp9:
+
+``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR_PROBS (struct)``
+Stores VP9 probabilities updates as parsed from the current compressed 
frame
+header. A value of zero in an array element means no update of the relevant
+probability. Motion vector-related updates contain a new value or zero. All
+other updates contain values translated with inv_map_table[] (see 6.3.5 in
+:ref:`vp9`).
+
+.. c:type:: v4l2_ctrl_vp9_compressed_hdr_probs
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_vp9_compressed_hdr_probs
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``tx8[2][1]``
+  - TX 8x8 probabilities delta.
+* - __u8
+  - ``tx16[2][2]``
+  - TX 16x16 probabilities delta.
+* - __u8
+  - ``tx32[2][3]``
+  - TX 32x32 probabilities delta.
+* - __u8
+  - ``coef[4][2][2][6][6][3]``
+  - Coefficient probabilities delta.
+* - __u8
+  - ``skip[3]``
+  - Skip probabilities delta.
+* - __u8
+  - ``inter_mode[7][3]``
+  - Inter prediction mode probabilities delta.
+* - __u8
+  - ``interp_filter[4][2]``
+  - Interpolation filter probabilities delta.
+* - __u8
+  - ``is_inter[4]``
+  - Is inter-block probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound prediction mode probabilities delta.
+* - __u8
+  - ``single_ref[5][2]``
+  - Single reference probabilities delta.
+* - __u8
+  - ``comp_mode[5]``
+  - Compound reference probabilities delta.
+* - __u8
+  - ``y_mode[4][9]``
+  - Y prediction mode probabilities delta.
+* - __u8
+  - ``uv_mode[10][9]``
+  - UV prediction mode probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``partition[16][3]``
+  - Partition probabilities delta.
+* - __u8
+  - ``mv.joint[3]``
+  - Motion vector joint probabilities delta.
+* - __u8
+  - ``mv.sign[2]``
+  - Motion vector sign probabilities delta.
+* - __u8
+  - ``mv.class[2][10]``
+  - Motion vector class probabilities delta.
+* - __u8
+  - ``mv.class0_bit[2]``
+  - Motion vector class0 bit probabilities delta.
+* - __u8
+  - ``mv.bits[2][10]``
+  - Motion vector bits probabilities delta.
+* - __u8
+  - ``mv.class0_fr[2][2][3]``
+  - Motion vector class0 fractional bit probabilities delta.
+* - __u8
+  - ``mv.fr[2][3]``
+  - Motion vector fractional bit probabilities delta.
+* - __u8
+  - ``mv.class0_hp[2]``
+  - Motion vector class0 high precision fractional bit probabilities delta.
+* - __u8
+  - ``mv.hp[2]``
+  - Motion vector high precision fractional bit probabilities delta.
+
+``V4L2_CID_STATELESS_VP9_FRAME (struct)``
+Specifies the frame parameters for the associated VP9 frame decode request.
+This includes

[RFCv2 3/3] media: rkvdec: Add the VP9 backend

From: Boris Brezillon 

The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add
a backend for this new format.

Signed-off-by: Boris Brezillon 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/staging/media/rkvdec/Kconfig  |1 +
 drivers/staging/media/rkvdec/Makefile |2 +-
 drivers/staging/media/rkvdec/rkvdec-vp9.c | 1084 +
 drivers/staging/media/rkvdec/rkvdec.c |   52 +-
 drivers/staging/media/rkvdec/rkvdec.h |6 +
 5 files changed, 1140 insertions(+), 5 deletions(-)
 create mode 100644 drivers/staging/media/rkvdec/rkvdec-vp9.c

diff --git a/drivers/staging/media/rkvdec/Kconfig 
b/drivers/staging/media/rkvdec/Kconfig
index c02199b5e0fd..dc7292f346fa 100644
--- a/drivers/staging/media/rkvdec/Kconfig
+++ b/drivers/staging/media/rkvdec/Kconfig
@@ -9,6 +9,7 @@ config VIDEO_ROCKCHIP_VDEC
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
select V4L2_H264
+   select V4L2_VP9
help
  Support for the Rockchip Video Decoder IP present on Rockchip SoCs,
  which accelerates video decoding.
diff --git a/drivers/staging/media/rkvdec/Makefile 
b/drivers/staging/media/rkvdec/Makefile
index c08fed0a39f9..cb86b429cfaa 100644
--- a/drivers/staging/media/rkvdec/Makefile
+++ b/drivers/staging/media/rkvdec/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rockchip-vdec.o
 
-rockchip-vdec-y += rkvdec.o rkvdec-h264.o
+rockchip-vdec-y += rkvdec.o rkvdec-h264.o rkvdec-vp9.o
diff --git a/drivers/staging/media/rkvdec/rkvdec-vp9.c 
b/drivers/staging/media/rkvdec/rkvdec-vp9.c
new file mode 100644
index ..d40e4ff7e3f6
--- /dev/null
+++ b/drivers/staging/media/rkvdec/rkvdec-vp9.c
@@ -0,0 +1,1084 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip Video Decoder VP9 backend
+ *
+ * Copyright (C) 2019 Collabora, Ltd.
+ * Boris Brezillon 
+ * Copyright (C) 2021 Collabora, Ltd.
+ * Andrzej Pietrasiewicz 
+ *
+ * Copyright (C) 2016 Rockchip Electronics Co., Ltd.
+ * Alpha Lin 
+ */
+
+/*
+ * For following the vp9 spec please start reading this driver
+ * code from rkvdec_vp9_run() followed by rkvdec_vp9_done().
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rkvdec.h"
+#include "rkvdec-regs.h"
+
+#define RKVDEC_VP9_PROBE_SIZE  4864
+#define RKVDEC_VP9_COUNT_SIZE  13232
+#define RKVDEC_VP9_MAX_SEGMAP_SIZE 73728
+
+struct rkvdec_vp9_intra_mode_probs {
+   u8 y_mode[105];
+   u8 uv_mode[23];
+};
+
+struct rkvdec_vp9_intra_only_frame_probs {
+   u8 coef_intra[4][2][128];
+   struct rkvdec_vp9_intra_mode_probs intra_mode[10];
+};
+
+struct rkvdec_vp9_inter_frame_probs {
+   u8 y_mode[4][9];
+   u8 comp_mode[5];
+   u8 comp_ref[5];
+   u8 single_ref[5][2];
+   u8 inter_mode[7][3];
+   u8 interp_filter[4][2];
+   u8 padding0[11];
+   u8 coef[2][4][2][128];
+   u8 uv_mode_0_2[3][9];
+   u8 padding1[5];
+   u8 uv_mode_3_5[3][9];
+   u8 padding2[5];
+   u8 uv_mode_6_8[3][9];
+   u8 padding3[5];
+   u8 uv_mode_9[9];
+   u8 padding4[7];
+   u8 padding5[16];
+   struct {
+   u8 joint[3];
+   u8 sign[2];
+   u8 class[2][10];
+   u8 class0_bit[2];
+   u8 bits[2][10];
+   u8 class0_fr[2][2][3];
+   u8 fr[2][3];
+   u8 class0_hp[2];
+   u8 hp[2];
+   } mv;
+};
+
+struct rkvdec_vp9_probs {
+   u8 partition[16][3];
+   u8 pred[3];
+   u8 tree[7];
+   u8 skip[3];
+   u8 tx32[2][3];
+   u8 tx16[2][2];
+   u8 tx8[2][1];
+   u8 is_inter[4];
+   /* 128 bit alignment */
+   u8 padding0[3];
+   union {
+   struct rkvdec_vp9_inter_frame_probs inter;
+   struct rkvdec_vp9_intra_only_frame_probs intra_only;
+   };
+};
+
+/* Data structure describing auxiliary buffer format. */
+struct rkvdec_vp9_priv_tbl {
+   struct rkvdec_vp9_probs probs;
+   u8 segmap[2][RKVDEC_VP9_MAX_SEGMAP_SIZE];
+};
+
+struct rkvdec_vp9_refs_counts {
+   u32 eob[2];
+   u32 coeff[3];
+};
+
+struct rkvdec_vp9_inter_frame_symbol_counts {
+   u32 partition[16][4];
+   u32 skip[3][2];
+   u32 inter[4][2];
+   u32 tx32p[2][4];
+   u32 tx16p[2][4];
+   u32 tx8p[2][2];
+   u32 y_mode[4][10];
+   u32 uv_mode[10][10];
+   u32 comp[5][2];
+   u32 comp_ref[5][2];
+   u32 single_ref[5][2][2];
+   u32 mv_mode[7][4];
+   u32 filter[4][3];
+   u32 mv_joint[4];
+   u32 sign[2][2];
+   /* add 1 element for align */
+   u32 classes[2][11 + 1];
+   u32 class0[2][2];
+   u32 bits[2][10][2];
+   u32 class0_fp[2][2][4];
+   u32 fp[2][4];
+   u32 class0_hp[2][2];
+   u32 hp[2][2];
+   struct rkvdec_vp9_refs_counts ref_cnt[2][4][2][6][6];
+};
+
+struct rkvdec_vp9_intra

[RFCv2 2/3] media: uapi: Add VP9 v4l2 library