* [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
First two patches add 10-bit formats to UAPI, third extends filtering
mechanism, fourth fixes incorrect assumption, fifth moves register
configuration code to proper place, sixth and seventh enable 10-bit
VP9 decoding on Allwinner H6 and last increases core frequency on
Allwinner H6.
I'm sending this as RFC to get some comments:
1. format definitions - are fourcc's ok? are comments/descriptions ok?
2. is extended filtering mechanism ok?
I would also like if these patches are tested on some more HW.
Additionally, can someone test tiled P010?
Please take a look.
Best regards,
Jernej
Ezequiel Garcia (1):
media: Add P010 tiled format
Jernej Skrabec (7):
media: Add P010 format
media: hantro: Support format filtering by depth
media: hantro: postproc: Fix buffer size calculation
media: hantro: postproc: Fix legacy regs configuration
media: hantro: Store VP9 bit depth in context
media: hantro: sunxi: Enable 10-bit decoding
media: hantro: sunxi: Increase frequency
drivers/media/v4l2-core/v4l2-common.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
drivers/staging/media/hantro/hantro.h | 4 ++
drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
.../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
.../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
include/uapi/linux/videodev2.h | 2 +
10 files changed, 122 insertions(+), 20 deletions(-)
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
First two patches add 10-bit formats to UAPI, third extends filtering
mechanism, fourth fixes incorrect assumption, fifth moves register
configuration code to proper place, sixth and seventh enable 10-bit
VP9 decoding on Allwinner H6 and last increases core frequency on
Allwinner H6.
I'm sending this as RFC to get some comments:
1. format definitions - are fourcc's ok? are comments/descriptions ok?
2. is extended filtering mechanism ok?
I would also like if these patches are tested on some more HW.
Additionally, can someone test tiled P010?
Please take a look.
Best regards,
Jernej
Ezequiel Garcia (1):
media: Add P010 tiled format
Jernej Skrabec (7):
media: Add P010 format
media: hantro: Support format filtering by depth
media: hantro: postproc: Fix buffer size calculation
media: hantro: postproc: Fix legacy regs configuration
media: hantro: Store VP9 bit depth in context
media: hantro: sunxi: Enable 10-bit decoding
media: hantro: sunxi: Increase frequency
drivers/media/v4l2-core/v4l2-common.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
drivers/staging/media/hantro/hantro.h | 4 ++
drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
.../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
.../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
include/uapi/linux/videodev2.h | 2 +
10 files changed, 122 insertions(+), 20 deletions(-)
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 1/8] media: Add P010 tiled format
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Add P010 tiled format
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
[rebased and updated pixel format name]
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index df34b2a283bc..1db0020e08c0 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -277,6 +277,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+ { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
/* YUV planar formats, non contiguous variant */
{ .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 9ac557b8e146..048f326c57b9 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1302,6 +1302,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_NV12_4L4: descr = "Y/CbCr 4:2:0 (4x4 Linear)"; break;
case V4L2_PIX_FMT_NV12_16L16: descr = "Y/CbCr 4:2:0 (16x16 Linear)"; break;
case V4L2_PIX_FMT_NV12_32L32: descr = "Y/CbCr 4:2:0 (32x32 Linear)"; break;
+ case V4L2_PIX_FMT_P010_4L4: descr = "P010 tiled"; break;
case V4L2_PIX_FMT_NV12M: descr = "Y/CbCr 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV21M: descr = "Y/CrCb 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV16M: descr = "Y/CbCr 4:2:2 (N-C)"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index df8b9c486ba1..772dbadd1a24 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -628,6 +628,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV12_4L4 v4l2_fourcc('V', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 4x4 tiles */
#define V4L2_PIX_FMT_NV12_16L16 v4l2_fourcc('H', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 tiles */
#define V4L2_PIX_FMT_NV12_32L32 v4l2_fourcc('S', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 32x32 tiles */
+#define V4L2_PIX_FMT_P010_4L4 v4l2_fourcc('T', '0', '1', '0') /* 12 Y/CbCr 4:2:0 10-bit 4x4 macroblocks */
/* Tiled YUV formats, non contiguous planes */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 tiles */
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 1/8] media: Add P010 tiled format
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Add P010 tiled format
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
[rebased and updated pixel format name]
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index df34b2a283bc..1db0020e08c0 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -277,6 +277,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+ { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
/* YUV planar formats, non contiguous variant */
{ .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 9ac557b8e146..048f326c57b9 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1302,6 +1302,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_NV12_4L4: descr = "Y/CbCr 4:2:0 (4x4 Linear)"; break;
case V4L2_PIX_FMT_NV12_16L16: descr = "Y/CbCr 4:2:0 (16x16 Linear)"; break;
case V4L2_PIX_FMT_NV12_32L32: descr = "Y/CbCr 4:2:0 (32x32 Linear)"; break;
+ case V4L2_PIX_FMT_P010_4L4: descr = "P010 tiled"; break;
case V4L2_PIX_FMT_NV12M: descr = "Y/CbCr 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV21M: descr = "Y/CrCb 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV16M: descr = "Y/CbCr 4:2:2 (N-C)"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index df8b9c486ba1..772dbadd1a24 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -628,6 +628,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV12_4L4 v4l2_fourcc('V', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 4x4 tiles */
#define V4L2_PIX_FMT_NV12_16L16 v4l2_fourcc('H', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 tiles */
#define V4L2_PIX_FMT_NV12_32L32 v4l2_fourcc('S', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 32x32 tiles */
+#define V4L2_PIX_FMT_P010_4L4 v4l2_fourcc('T', '0', '1', '0') /* 12 Y/CbCr 4:2:0 10-bit 4x4 macroblocks */
/* Tiled YUV formats, non contiguous planes */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 tiles */
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 1/8] media: Add P010 tiled format
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Add P010 tiled format
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
[rebased and updated pixel format name]
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index df34b2a283bc..1db0020e08c0 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -277,6 +277,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+ { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
/* YUV planar formats, non contiguous variant */
{ .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 9ac557b8e146..048f326c57b9 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1302,6 +1302,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_NV12_4L4: descr = "Y/CbCr 4:2:0 (4x4 Linear)"; break;
case V4L2_PIX_FMT_NV12_16L16: descr = "Y/CbCr 4:2:0 (16x16 Linear)"; break;
case V4L2_PIX_FMT_NV12_32L32: descr = "Y/CbCr 4:2:0 (32x32 Linear)"; break;
+ case V4L2_PIX_FMT_P010_4L4: descr = "P010 tiled"; break;
case V4L2_PIX_FMT_NV12M: descr = "Y/CbCr 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV21M: descr = "Y/CrCb 4:2:0 (N-C)"; break;
case V4L2_PIX_FMT_NV16M: descr = "Y/CbCr 4:2:2 (N-C)"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index df8b9c486ba1..772dbadd1a24 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -628,6 +628,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV12_4L4 v4l2_fourcc('V', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 4x4 tiles */
#define V4L2_PIX_FMT_NV12_16L16 v4l2_fourcc('H', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 tiles */
#define V4L2_PIX_FMT_NV12_32L32 v4l2_fourcc('S', 'T', '1', '2') /* 12 Y/CbCr 4:2:0 32x32 tiles */
+#define V4L2_PIX_FMT_P010_4L4 v4l2_fourcc('T', '0', '1', '0') /* 12 Y/CbCr 4:2:0 10-bit 4x4 macroblocks */
/* Tiled YUV formats, non contiguous planes */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 tiles */
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [RFC PATCH 2/8] media: Add P010 format
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Add P010 format, which is commonly used for 10-bit videos.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 1db0020e08c0..4ede36546e9c 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
{ .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
{ .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 048f326c57b9..a8d999e23e5b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
+ case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 772dbadd1a24..211bc11a48cb 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -597,6 +597,7 @@ struct v4l2_pix_format {
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
#define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
+#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
#define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
#define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
#define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Add P010 format, which is commonly used for 10-bit videos.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 1db0020e08c0..4ede36546e9c 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
{ .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
{ .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 048f326c57b9..a8d999e23e5b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
+ case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 772dbadd1a24..211bc11a48cb 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -597,6 +597,7 @@ struct v4l2_pix_format {
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
#define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
+#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
#define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
#define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
#define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Add P010 format, which is commonly used for 10-bit videos.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 1db0020e08c0..4ede36546e9c 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
{ .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
+
/* Tiled YUV formats */
{ .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
{ .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 048f326c57b9..a8d999e23e5b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
+ case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 772dbadd1a24..211bc11a48cb 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -597,6 +597,7 @@ struct v4l2_pix_format {
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
#define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
+#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
#define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
#define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
#define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread* Re: [RFC PATCH 2/8] media: Add P010 format
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-28 12:48 ` Nicolas Dufresne
-1 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 12:48 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> Add P010 format, which is commonly used for 10-bit videos.
There is a much more complete patch that was sent previously (with documentation
and all):
https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
regards,
Nicolas
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 1db0020e08c0..4ede36546e9c 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>
> + { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> +
> /* Tiled YUV formats */
> { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 048f326c57b9..a8d999e23e5b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
> case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 772dbadd1a24..211bc11a48cb 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> /* two planes -- one Y, one Cr + Cb interleaved */
> #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
> #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
> +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
> #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
> #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
> #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 12:48 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 12:48 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> Add P010 format, which is commonly used for 10-bit videos.
There is a much more complete patch that was sent previously (with documentation
and all):
https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
regards,
Nicolas
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 1db0020e08c0..4ede36546e9c 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>
> + { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> +
> /* Tiled YUV formats */
> { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 048f326c57b9..a8d999e23e5b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
> case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 772dbadd1a24..211bc11a48cb 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> /* two planes -- one Y, one Cr + Cb interleaved */
> #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
> #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
> +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
> #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
> #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
> #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 12:48 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 12:48 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> Add P010 format, which is commonly used for 10-bit videos.
There is a much more complete patch that was sent previously (with documentation
and all):
https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
regards,
Nicolas
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 1db0020e08c0..4ede36546e9c 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .hdiv = 1, .vdiv = 1 },
>
> + { .format = V4L2_PIX_FMT_P010, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> +
> /* Tiled YUV formats */
> { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .hdiv = 2, .vdiv = 2 },
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 048f326c57b9..a8d999e23e5b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0 (M420)"; break;
> case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0"; break;
> case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 772dbadd1a24..211bc11a48cb 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> /* two planes -- one Y, one Cr + Cb interleaved */
> #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */
> #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */
> +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr 4:2:0 10-bit */
> #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
> #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
> #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr 4:4:4 */
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
2022-02-28 12:48 ` Nicolas Dufresne
(?)
@ 2022-02-28 16:32 ` Jernej Škrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-28 16:32 UTC (permalink / raw)
To: ezequiel, p.zabel, Nicolas Dufresne
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
napisal(a):
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with
documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/
20210618131526.566762-5-benjamin.gaignard@collabora.com/
Great, I'll take it for next revision. Although I'm not sure what "much more
complete" means. Only additional thing is documentation.
Best regards,
Jernej
>
> regards,
> Nicolas
>
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > include/uapi/linux/videodev2.h | 1 +
> > 3 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
core/v4l2-common.c
> > index 1db0020e08c0..4ede36546e9c 100644
> > --- a/drivers/media/v4l2-core/v4l2-common.c
> > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
format)
> > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1 },
> > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
.hdiv = 1, .vdiv = 1 },
> >
> > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > +
> > /* Tiled YUV formats */
> > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
core/v4l2-ioctl.c
> > index 048f326c57b9..a8d999e23e5b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
*fmt)
> > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
(M420)"; break;
> > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
break;
> > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
videodev2.h
> > index 772dbadd1a24..211bc11a48cb 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > /* two planes -- one Y, one Cr + Cb interleaved */
> > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
> > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
> > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
4:2:0 10-bit */
> > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
4:2:2 */
> > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
> > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 16:32 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-28 16:32 UTC (permalink / raw)
To: ezequiel, p.zabel, Nicolas Dufresne
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
napisal(a):
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with
documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/
20210618131526.566762-5-benjamin.gaignard@collabora.com/
Great, I'll take it for next revision. Although I'm not sure what "much more
complete" means. Only additional thing is documentation.
Best regards,
Jernej
>
> regards,
> Nicolas
>
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > include/uapi/linux/videodev2.h | 1 +
> > 3 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
core/v4l2-common.c
> > index 1db0020e08c0..4ede36546e9c 100644
> > --- a/drivers/media/v4l2-core/v4l2-common.c
> > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
format)
> > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1 },
> > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
.hdiv = 1, .vdiv = 1 },
> >
> > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > +
> > /* Tiled YUV formats */
> > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
core/v4l2-ioctl.c
> > index 048f326c57b9..a8d999e23e5b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
*fmt)
> > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
(M420)"; break;
> > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
break;
> > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
videodev2.h
> > index 772dbadd1a24..211bc11a48cb 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > /* two planes -- one Y, one Cr + Cb interleaved */
> > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
> > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
> > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
4:2:0 10-bit */
> > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
4:2:2 */
> > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
> > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 16:32 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-28 16:32 UTC (permalink / raw)
To: ezequiel, p.zabel, Nicolas Dufresne
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
napisal(a):
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with
documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/
20210618131526.566762-5-benjamin.gaignard@collabora.com/
Great, I'll take it for next revision. Although I'm not sure what "much more
complete" means. Only additional thing is documentation.
Best regards,
Jernej
>
> regards,
> Nicolas
>
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > include/uapi/linux/videodev2.h | 1 +
> > 3 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
core/v4l2-common.c
> > index 1db0020e08c0..4ede36546e9c 100644
> > --- a/drivers/media/v4l2-core/v4l2-common.c
> > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
format)
> > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1 },
> > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
.hdiv = 1, .vdiv = 1 },
> >
> > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > +
> > /* Tiled YUV formats */
> > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
.hdiv = 2, .vdiv = 2 },
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
core/v4l2-ioctl.c
> > index 048f326c57b9..a8d999e23e5b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
*fmt)
> > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
(M420)"; break;
> > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
break;
> > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
videodev2.h
> > index 772dbadd1a24..211bc11a48cb 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > /* two planes -- one Y, one Cr + Cb interleaved */
> > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
> > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
> > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
4:2:0 10-bit */
> > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
4:2:2 */
> > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
> > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
2022-02-28 16:32 ` Jernej Škrabec
(?)
@ 2022-02-28 17:02 ` Nicolas Dufresne
-1 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 17:02 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le lundi 28 février 2022 à 17:32 +0100, Jernej Škrabec a écrit :
> Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
> napisal(a):
> > Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > > Add P010 format, which is commonly used for 10-bit videos.
> >
> > There is a much more complete patch that was sent previously (with
> documentation
> > and all):
> >
> > https://patchwork.kernel.org/project/linux-rockchip/patch/
> 20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
> Great, I'll take it for next revision. Although I'm not sure what "much more
> complete" means. Only additional thing is documentation.
When adding uAPI, doc is really important, so having the format documented means
the other patch is "much more" ready to be merged.
cheers,
Nicolas
>
> Best regards,
> Jernej
>
> >
> > regards,
> > Nicolas
> >
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > > ---
> > > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > > include/uapi/linux/videodev2.h | 1 +
> > > 3 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
> core/v4l2-common.c
> > > index 1db0020e08c0..4ede36546e9c 100644
> > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
> format)
> > > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
> .hdiv = 2, .vdiv = 1 },
> > > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
> .hdiv = 1, .vdiv = 1 },
> > >
> > > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > +
> > > /* Tiled YUV formats */
> > > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
> core/v4l2-ioctl.c
> > > index 048f326c57b9..a8d999e23e5b 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
> (M420)"; break;
> > > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
> break;
> > > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
> videodev2.h
> > > index 772dbadd1a24..211bc11a48cb 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
> 4:2:0 */
> > > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
> 4:2:0 */
> > > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
> 4:2:0 10-bit */
> > > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
> 4:4:4 */
> >
> >
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 17:02 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 17:02 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le lundi 28 février 2022 à 17:32 +0100, Jernej Škrabec a écrit :
> Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
> napisal(a):
> > Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > > Add P010 format, which is commonly used for 10-bit videos.
> >
> > There is a much more complete patch that was sent previously (with
> documentation
> > and all):
> >
> > https://patchwork.kernel.org/project/linux-rockchip/patch/
> 20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
> Great, I'll take it for next revision. Although I'm not sure what "much more
> complete" means. Only additional thing is documentation.
When adding uAPI, doc is really important, so having the format documented means
the other patch is "much more" ready to be merged.
cheers,
Nicolas
>
> Best regards,
> Jernej
>
> >
> > regards,
> > Nicolas
> >
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > > ---
> > > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > > include/uapi/linux/videodev2.h | 1 +
> > > 3 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
> core/v4l2-common.c
> > > index 1db0020e08c0..4ede36546e9c 100644
> > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
> format)
> > > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
> .hdiv = 2, .vdiv = 1 },
> > > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
> .hdiv = 1, .vdiv = 1 },
> > >
> > > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > +
> > > /* Tiled YUV formats */
> > > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
> core/v4l2-ioctl.c
> > > index 048f326c57b9..a8d999e23e5b 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
> (M420)"; break;
> > > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
> break;
> > > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
> videodev2.h
> > > index 772dbadd1a24..211bc11a48cb 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
> 4:2:0 */
> > > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
> 4:2:0 */
> > > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
> 4:2:0 10-bit */
> > > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
> 4:4:4 */
> >
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-02-28 17:02 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-02-28 17:02 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le lundi 28 février 2022 à 17:32 +0100, Jernej Škrabec a écrit :
> Dne ponedeljek, 28. februar 2022 ob 13:48:53 CET je Nicolas Dufresne
> napisal(a):
> > Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > > Add P010 format, which is commonly used for 10-bit videos.
> >
> > There is a much more complete patch that was sent previously (with
> documentation
> > and all):
> >
> > https://patchwork.kernel.org/project/linux-rockchip/patch/
> 20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
> Great, I'll take it for next revision. Although I'm not sure what "much more
> complete" means. Only additional thing is documentation.
When adding uAPI, doc is really important, so having the format documented means
the other patch is "much more" ready to be merged.
cheers,
Nicolas
>
> Best regards,
> Jernej
>
> >
> > regards,
> > Nicolas
> >
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > > ---
> > > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > > include/uapi/linux/videodev2.h | 1 +
> > > 3 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-
> core/v4l2-common.c
> > > index 1db0020e08c0..4ede36546e9c 100644
> > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > @@ -275,6 +275,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
> format)
> > > { .format = V4L2_PIX_FMT_YUV422P, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
> .hdiv = 2, .vdiv = 1 },
> > > { .format = V4L2_PIX_FMT_GREY, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
> .hdiv = 1, .vdiv = 1 },
> > >
> > > + { .format = V4L2_PIX_FMT_P010, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > +
> > > /* Tiled YUV formats */
> > > { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc =
> V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 },
> .hdiv = 2, .vdiv = 2 },
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-
> core/v4l2-ioctl.c
> > > index 048f326c57b9..a8d999e23e5b 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > @@ -1295,6 +1295,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > > case V4L2_PIX_FMT_M420: descr = "YUV 4:2:0
> (M420)"; break;
> > > case V4L2_PIX_FMT_NV12: descr = "Y/CbCr 4:2:0"; break;
> > > case V4L2_PIX_FMT_NV21: descr = "Y/CrCb 4:2:0"; break;
> > > + case V4L2_PIX_FMT_P010: descr = "10-bit Y/CbCr 4:2:0";
> break;
> > > case V4L2_PIX_FMT_NV16: descr = "Y/CbCr 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV61: descr = "Y/CrCb 4:2:2"; break;
> > > case V4L2_PIX_FMT_NV24: descr = "Y/CbCr 4:4:4"; break;
> > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/
> videodev2.h
> > > index 772dbadd1a24..211bc11a48cb 100644
> > > --- a/include/uapi/linux/videodev2.h
> > > +++ b/include/uapi/linux/videodev2.h
> > > @@ -597,6 +597,7 @@ struct v4l2_pix_format {
> > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
> 4:2:0 */
> > > #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
> 4:2:0 */
> > > +#define V4L2_PIX_FMT_P010 v4l2_fourcc('P', '0', '1', '0') /* 24 Y/CbCr
> 4:2:0 10-bit */
> > > #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
> 4:2:2 */
> > > #define V4L2_PIX_FMT_NV24 v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
> 4:4:4 */
> >
> >
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
2022-02-28 12:48 ` Nicolas Dufresne
(?)
@ 2022-04-04 0:04 ` Ezequiel Garcia
-1 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:04 UTC (permalink / raw)
To: Nicolas Dufresne, Benjamin Gaignard
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Hi Nicolas, Benjamin,
On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
I believe "media: Add P010 video format" should be good to go, I think
we could merge it.
I can't find it on my gmail inbox, for some reason.. can you guys
please repost it,
and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
Thanks!
Ezequiel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-04-04 0:04 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:04 UTC (permalink / raw)
To: Nicolas Dufresne, Benjamin Gaignard
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Hi Nicolas, Benjamin,
On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
I believe "media: Add P010 video format" should be good to go, I think
we could merge it.
I can't find it on my gmail inbox, for some reason.. can you guys
please repost it,
and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
Thanks!
Ezequiel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-04-04 0:04 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:04 UTC (permalink / raw)
To: Nicolas Dufresne, Benjamin Gaignard
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Hi Nicolas, Benjamin,
On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
> > Add P010 format, which is commonly used for 10-bit videos.
>
> There is a much more complete patch that was sent previously (with documentation
> and all):
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>
I believe "media: Add P010 video format" should be good to go, I think
we could merge it.
I can't find it on my gmail inbox, for some reason.. can you guys
please repost it,
and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
Thanks!
Ezequiel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
2022-04-04 0:04 ` Ezequiel Garcia
(?)
@ 2022-04-04 9:02 ` Benjamin Gaignard
-1 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-04 9:02 UTC (permalink / raw)
To: Ezequiel Garcia, Nicolas Dufresne
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Le 04/04/2022 à 02:04, Ezequiel Garcia a écrit :
> Hi Nicolas, Benjamin,
>
> On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
>>> Add P010 format, which is commonly used for 10-bit videos.
>> There is a much more complete patch that was sent previously (with documentation
>> and all):
>>
>> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>>
> I believe "media: Add P010 video format" should be good to go, I think
> we could merge it.
>
> I can't find it on my gmail inbox, for some reason.. can you guys
> please repost it,
> and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
I have rebased it on v5-18-rc1 tag and send it.
You should have it in your mailbox now.
Regards,
Benjamin
>
> Thanks!
> Ezequiel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-04-04 9:02 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-04 9:02 UTC (permalink / raw)
To: Ezequiel Garcia, Nicolas Dufresne
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Le 04/04/2022 à 02:04, Ezequiel Garcia a écrit :
> Hi Nicolas, Benjamin,
>
> On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
>>> Add P010 format, which is commonly used for 10-bit videos.
>> There is a much more complete patch that was sent previously (with documentation
>> and all):
>>
>> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>>
> I believe "media: Add P010 video format" should be good to go, I think
> we could merge it.
>
> I can't find it on my gmail inbox, for some reason.. can you guys
> please repost it,
> and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
I have rebased it on v5-18-rc1 tag and send it.
You should have it in your mailbox now.
Regards,
Benjamin
>
> Thanks!
> Ezequiel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 2/8] media: Add P010 format
@ 2022-04-04 9:02 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-04 9:02 UTC (permalink / raw)
To: Ezequiel Garcia, Nicolas Dufresne
Cc: Jernej Skrabec, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Greg KH, Chen-Yu Tsai, Samuel Holland, linux-media,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
open list:STAGING SUBSYSTEM, linux-arm-kernel, linux-sunxi
Le 04/04/2022 à 02:04, Ezequiel Garcia a écrit :
> Hi Nicolas, Benjamin,
>
> On Mon, Feb 28, 2022 at 9:48 AM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>> Le dimanche 27 février 2022 à 15:49 +0100, Jernej Skrabec a écrit :
>>> Add P010 format, which is commonly used for 10-bit videos.
>> There is a much more complete patch that was sent previously (with documentation
>> and all):
>>
>> https://patchwork.kernel.org/project/linux-rockchip/patch/20210618131526.566762-5-benjamin.gaignard@collabora.com/
>>
> I believe "media: Add P010 video format" should be good to go, I think
> we could merge it.
>
> I can't find it on my gmail inbox, for some reason.. can you guys
> please repost it,
> and/or reply to with a gently ping for Hans (and please Cc me on this mail) ?
I have rebased it on v5-18-rc1 tag and send it.
You should have it in your mailbox now.
Regards,
Benjamin
>
> Thanks!
> Ezequiel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 3/8] media: hantro: Support format filtering by depth
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
In preparation for supporting 10-bit formats, add mechanism which will
filter formats based on pixel depth.
Hantro G2 supports only one decoding format natively and that is based
on bit depth of current video frame. Additionally, it makes no sense to
upconvert bitness, so filter those out too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro.h | 4 ++
drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
drivers/staging/media/hantro/hantro_v4l2.h | 1 +
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 06d0f3597694..c6525ee8d89a 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -227,6 +227,7 @@ struct hantro_dev {
*
* @ctrl_handler: Control handler used to register controls.
* @jpeg_quality: User-specified JPEG compression quality.
+ * @bit_depth: Bit depth of current frame
*
* @codec_ops: Set of operations related to codec mode.
* @postproc: Post-processing context.
@@ -252,6 +253,7 @@ struct hantro_ctx {
struct v4l2_ctrl_handler ctrl_handler;
int jpeg_quality;
+ int bit_depth;
const struct hantro_codec_ops *codec_ops;
struct hantro_postproc_ctx postproc;
@@ -278,6 +280,7 @@ struct hantro_ctx {
* @enc_fmt: Format identifier for encoder registers.
* @frmsize: Supported range of frame sizes (only for bitstream formats).
* @postprocessed: Indicates if this format needs the post-processor.
+ * @match_depth: Indicates if format bit depth must match video bit depth
*/
struct hantro_fmt {
char *name;
@@ -288,6 +291,7 @@ struct hantro_fmt {
enum hantro_enc_fmt enc_fmt;
struct v4l2_frmsize_stepwise frmsize;
bool postprocessed;
+ bool match_depth;
};
struct hantro_reg {
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index e595905b3bd7..1214fa2f64ae 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
return ctx->dev->variant->postproc_fmts;
}
+int hantro_get_formath_depth(u32 fourcc)
+{
+ switch (fourcc) {
+ case V4L2_PIX_FMT_P010:
+ case V4L2_PIX_FMT_P010_4L4:
+ return 10;
+ default:
+ return 8;
+ }
+}
+
+static bool
+hantro_check_depth_match(const struct hantro_ctx *ctx,
+ const struct hantro_fmt *fmt)
+{
+ int fmt_depth, ctx_depth = 8;
+
+ if (!fmt->match_depth && !fmt->postprocessed)
+ return true;
+
+ /* 0 means default depth, which is 8 */
+ if (ctx->bit_depth)
+ ctx_depth = ctx->bit_depth;
+
+ fmt_depth = hantro_get_formath_depth(fmt->fourcc);
+
+ /*
+ * Allow only downconversion for postproc formats for now.
+ * It may be possible to relax that on some HW.
+ */
+ if (!fmt->match_depth)
+ return fmt_depth <= ctx_depth;
+
+ return fmt_depth == ctx_depth;
+}
+
static const struct hantro_fmt *
hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
{
@@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
if (bitstream == (formats[i].codec_mode !=
- HANTRO_MODE_NONE))
+ HANTRO_MODE_NONE) &&
+ hantro_check_depth_match(ctx, &formats[i]))
return &formats[i];
}
return NULL;
@@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
+ fmt = &formats[i];
if (skip_mode_none == mode_none)
continue;
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
@@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
return -EINVAL;
formats = hantro_get_postproc_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
+ fmt = &formats[i];
+
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index 18bc682c8556..f4a5905ed518 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
+int hantro_get_formath_depth(u32 fourcc);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
In preparation for supporting 10-bit formats, add mechanism which will
filter formats based on pixel depth.
Hantro G2 supports only one decoding format natively and that is based
on bit depth of current video frame. Additionally, it makes no sense to
upconvert bitness, so filter those out too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro.h | 4 ++
drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
drivers/staging/media/hantro/hantro_v4l2.h | 1 +
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 06d0f3597694..c6525ee8d89a 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -227,6 +227,7 @@ struct hantro_dev {
*
* @ctrl_handler: Control handler used to register controls.
* @jpeg_quality: User-specified JPEG compression quality.
+ * @bit_depth: Bit depth of current frame
*
* @codec_ops: Set of operations related to codec mode.
* @postproc: Post-processing context.
@@ -252,6 +253,7 @@ struct hantro_ctx {
struct v4l2_ctrl_handler ctrl_handler;
int jpeg_quality;
+ int bit_depth;
const struct hantro_codec_ops *codec_ops;
struct hantro_postproc_ctx postproc;
@@ -278,6 +280,7 @@ struct hantro_ctx {
* @enc_fmt: Format identifier for encoder registers.
* @frmsize: Supported range of frame sizes (only for bitstream formats).
* @postprocessed: Indicates if this format needs the post-processor.
+ * @match_depth: Indicates if format bit depth must match video bit depth
*/
struct hantro_fmt {
char *name;
@@ -288,6 +291,7 @@ struct hantro_fmt {
enum hantro_enc_fmt enc_fmt;
struct v4l2_frmsize_stepwise frmsize;
bool postprocessed;
+ bool match_depth;
};
struct hantro_reg {
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index e595905b3bd7..1214fa2f64ae 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
return ctx->dev->variant->postproc_fmts;
}
+int hantro_get_formath_depth(u32 fourcc)
+{
+ switch (fourcc) {
+ case V4L2_PIX_FMT_P010:
+ case V4L2_PIX_FMT_P010_4L4:
+ return 10;
+ default:
+ return 8;
+ }
+}
+
+static bool
+hantro_check_depth_match(const struct hantro_ctx *ctx,
+ const struct hantro_fmt *fmt)
+{
+ int fmt_depth, ctx_depth = 8;
+
+ if (!fmt->match_depth && !fmt->postprocessed)
+ return true;
+
+ /* 0 means default depth, which is 8 */
+ if (ctx->bit_depth)
+ ctx_depth = ctx->bit_depth;
+
+ fmt_depth = hantro_get_formath_depth(fmt->fourcc);
+
+ /*
+ * Allow only downconversion for postproc formats for now.
+ * It may be possible to relax that on some HW.
+ */
+ if (!fmt->match_depth)
+ return fmt_depth <= ctx_depth;
+
+ return fmt_depth == ctx_depth;
+}
+
static const struct hantro_fmt *
hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
{
@@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
if (bitstream == (formats[i].codec_mode !=
- HANTRO_MODE_NONE))
+ HANTRO_MODE_NONE) &&
+ hantro_check_depth_match(ctx, &formats[i]))
return &formats[i];
}
return NULL;
@@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
+ fmt = &formats[i];
if (skip_mode_none == mode_none)
continue;
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
@@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
return -EINVAL;
formats = hantro_get_postproc_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
+ fmt = &formats[i];
+
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index 18bc682c8556..f4a5905ed518 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
+int hantro_get_formath_depth(u32 fourcc);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
In preparation for supporting 10-bit formats, add mechanism which will
filter formats based on pixel depth.
Hantro G2 supports only one decoding format natively and that is based
on bit depth of current video frame. Additionally, it makes no sense to
upconvert bitness, so filter those out too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro.h | 4 ++
drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
drivers/staging/media/hantro/hantro_v4l2.h | 1 +
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 06d0f3597694..c6525ee8d89a 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -227,6 +227,7 @@ struct hantro_dev {
*
* @ctrl_handler: Control handler used to register controls.
* @jpeg_quality: User-specified JPEG compression quality.
+ * @bit_depth: Bit depth of current frame
*
* @codec_ops: Set of operations related to codec mode.
* @postproc: Post-processing context.
@@ -252,6 +253,7 @@ struct hantro_ctx {
struct v4l2_ctrl_handler ctrl_handler;
int jpeg_quality;
+ int bit_depth;
const struct hantro_codec_ops *codec_ops;
struct hantro_postproc_ctx postproc;
@@ -278,6 +280,7 @@ struct hantro_ctx {
* @enc_fmt: Format identifier for encoder registers.
* @frmsize: Supported range of frame sizes (only for bitstream formats).
* @postprocessed: Indicates if this format needs the post-processor.
+ * @match_depth: Indicates if format bit depth must match video bit depth
*/
struct hantro_fmt {
char *name;
@@ -288,6 +291,7 @@ struct hantro_fmt {
enum hantro_enc_fmt enc_fmt;
struct v4l2_frmsize_stepwise frmsize;
bool postprocessed;
+ bool match_depth;
};
struct hantro_reg {
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index e595905b3bd7..1214fa2f64ae 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
return ctx->dev->variant->postproc_fmts;
}
+int hantro_get_formath_depth(u32 fourcc)
+{
+ switch (fourcc) {
+ case V4L2_PIX_FMT_P010:
+ case V4L2_PIX_FMT_P010_4L4:
+ return 10;
+ default:
+ return 8;
+ }
+}
+
+static bool
+hantro_check_depth_match(const struct hantro_ctx *ctx,
+ const struct hantro_fmt *fmt)
+{
+ int fmt_depth, ctx_depth = 8;
+
+ if (!fmt->match_depth && !fmt->postprocessed)
+ return true;
+
+ /* 0 means default depth, which is 8 */
+ if (ctx->bit_depth)
+ ctx_depth = ctx->bit_depth;
+
+ fmt_depth = hantro_get_formath_depth(fmt->fourcc);
+
+ /*
+ * Allow only downconversion for postproc formats for now.
+ * It may be possible to relax that on some HW.
+ */
+ if (!fmt->match_depth)
+ return fmt_depth <= ctx_depth;
+
+ return fmt_depth == ctx_depth;
+}
+
static const struct hantro_fmt *
hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
{
@@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
if (bitstream == (formats[i].codec_mode !=
- HANTRO_MODE_NONE))
+ HANTRO_MODE_NONE) &&
+ hantro_check_depth_match(ctx, &formats[i]))
return &formats[i];
}
return NULL;
@@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
formats = hantro_get_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
+ fmt = &formats[i];
if (skip_mode_none == mode_none)
continue;
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
@@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
return -EINVAL;
formats = hantro_get_postproc_formats(ctx, &num_fmts);
for (i = 0; i < num_fmts; i++) {
+ fmt = &formats[i];
+
+ if (!hantro_check_depth_match(ctx, fmt))
+ continue;
if (j == f->index) {
- fmt = &formats[i];
f->pixelformat = fmt->fourcc;
return 0;
}
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index 18bc682c8556..f4a5905ed518 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
+int hantro_get_formath_depth(u32 fourcc);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-04-05 16:09 ` Benjamin Gaignard
-1 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:09 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> In preparation for supporting 10-bit formats, add mechanism which will
> filter formats based on pixel depth.
>
> Hantro G2 supports only one decoding format natively and that is based
> on bit depth of current video frame. Additionally, it makes no sense to
> upconvert bitness, so filter those out too.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> 3 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
> index 06d0f3597694..c6525ee8d89a 100644
> --- a/drivers/staging/media/hantro/hantro.h
> +++ b/drivers/staging/media/hantro/hantro.h
> @@ -227,6 +227,7 @@ struct hantro_dev {
> *
> * @ctrl_handler: Control handler used to register controls.
> * @jpeg_quality: User-specified JPEG compression quality.
> + * @bit_depth: Bit depth of current frame
> *
> * @codec_ops: Set of operations related to codec mode.
> * @postproc: Post-processing context.
> @@ -252,6 +253,7 @@ struct hantro_ctx {
>
> struct v4l2_ctrl_handler ctrl_handler;
> int jpeg_quality;
> + int bit_depth;
>
> const struct hantro_codec_ops *codec_ops;
> struct hantro_postproc_ctx postproc;
> @@ -278,6 +280,7 @@ struct hantro_ctx {
> * @enc_fmt: Format identifier for encoder registers.
> * @frmsize: Supported range of frame sizes (only for bitstream formats).
> * @postprocessed: Indicates if this format needs the post-processor.
> + * @match_depth: Indicates if format bit depth must match video bit depth
> */
> struct hantro_fmt {
> char *name;
> @@ -288,6 +291,7 @@ struct hantro_fmt {
> enum hantro_enc_fmt enc_fmt;
> struct v4l2_frmsize_stepwise frmsize;
> bool postprocessed;
> + bool match_depth;
> };
>
> struct hantro_reg {
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
> index e595905b3bd7..1214fa2f64ae 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.c
> +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
> return ctx->dev->variant->postproc_fmts;
> }
>
> +int hantro_get_formath_depth(u32 fourcc)
Just a typo here:
s/hantro_get_formath_depth -> hantro_get_format_depth
regards
Benjamin
> +{
> + switch (fourcc) {
> + case V4L2_PIX_FMT_P010:
> + case V4L2_PIX_FMT_P010_4L4:
> + return 10;
> + default:
> + return 8;
> + }
> +}
> +
> +static bool
> +hantro_check_depth_match(const struct hantro_ctx *ctx,
> + const struct hantro_fmt *fmt)
> +{
> + int fmt_depth, ctx_depth = 8;
> +
> + if (!fmt->match_depth && !fmt->postprocessed)
> + return true;
> +
> + /* 0 means default depth, which is 8 */
> + if (ctx->bit_depth)
> + ctx_depth = ctx->bit_depth;
> +
> + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> +
> + /*
> + * Allow only downconversion for postproc formats for now.
> + * It may be possible to relax that on some HW.
> + */
> + if (!fmt->match_depth)
> + return fmt_depth <= ctx_depth;
> +
> + return fmt_depth == ctx_depth;
> +}
> +
> static const struct hantro_fmt *
> hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> {
> @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> if (bitstream == (formats[i].codec_mode !=
> - HANTRO_MODE_NONE))
> + HANTRO_MODE_NONE) &&
> + hantro_check_depth_match(ctx, &formats[i]))
> return &formats[i];
> }
> return NULL;
> @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
> + fmt = &formats[i];
>
> if (skip_mode_none == mode_none)
> continue;
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> return -EINVAL;
> formats = hantro_get_postproc_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> + fmt = &formats[i];
> +
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
> index 18bc682c8556..f4a5905ed518 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.h
> +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> extern const struct vb2_ops hantro_queue_ops;
>
> void hantro_reset_fmts(struct hantro_ctx *ctx);
> +int hantro_get_formath_depth(u32 fourcc);
>
> #endif /* HANTRO_V4L2_H_ */
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-04-05 16:09 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:09 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> In preparation for supporting 10-bit formats, add mechanism which will
> filter formats based on pixel depth.
>
> Hantro G2 supports only one decoding format natively and that is based
> on bit depth of current video frame. Additionally, it makes no sense to
> upconvert bitness, so filter those out too.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> 3 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
> index 06d0f3597694..c6525ee8d89a 100644
> --- a/drivers/staging/media/hantro/hantro.h
> +++ b/drivers/staging/media/hantro/hantro.h
> @@ -227,6 +227,7 @@ struct hantro_dev {
> *
> * @ctrl_handler: Control handler used to register controls.
> * @jpeg_quality: User-specified JPEG compression quality.
> + * @bit_depth: Bit depth of current frame
> *
> * @codec_ops: Set of operations related to codec mode.
> * @postproc: Post-processing context.
> @@ -252,6 +253,7 @@ struct hantro_ctx {
>
> struct v4l2_ctrl_handler ctrl_handler;
> int jpeg_quality;
> + int bit_depth;
>
> const struct hantro_codec_ops *codec_ops;
> struct hantro_postproc_ctx postproc;
> @@ -278,6 +280,7 @@ struct hantro_ctx {
> * @enc_fmt: Format identifier for encoder registers.
> * @frmsize: Supported range of frame sizes (only for bitstream formats).
> * @postprocessed: Indicates if this format needs the post-processor.
> + * @match_depth: Indicates if format bit depth must match video bit depth
> */
> struct hantro_fmt {
> char *name;
> @@ -288,6 +291,7 @@ struct hantro_fmt {
> enum hantro_enc_fmt enc_fmt;
> struct v4l2_frmsize_stepwise frmsize;
> bool postprocessed;
> + bool match_depth;
> };
>
> struct hantro_reg {
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
> index e595905b3bd7..1214fa2f64ae 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.c
> +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
> return ctx->dev->variant->postproc_fmts;
> }
>
> +int hantro_get_formath_depth(u32 fourcc)
Just a typo here:
s/hantro_get_formath_depth -> hantro_get_format_depth
regards
Benjamin
> +{
> + switch (fourcc) {
> + case V4L2_PIX_FMT_P010:
> + case V4L2_PIX_FMT_P010_4L4:
> + return 10;
> + default:
> + return 8;
> + }
> +}
> +
> +static bool
> +hantro_check_depth_match(const struct hantro_ctx *ctx,
> + const struct hantro_fmt *fmt)
> +{
> + int fmt_depth, ctx_depth = 8;
> +
> + if (!fmt->match_depth && !fmt->postprocessed)
> + return true;
> +
> + /* 0 means default depth, which is 8 */
> + if (ctx->bit_depth)
> + ctx_depth = ctx->bit_depth;
> +
> + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> +
> + /*
> + * Allow only downconversion for postproc formats for now.
> + * It may be possible to relax that on some HW.
> + */
> + if (!fmt->match_depth)
> + return fmt_depth <= ctx_depth;
> +
> + return fmt_depth == ctx_depth;
> +}
> +
> static const struct hantro_fmt *
> hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> {
> @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> if (bitstream == (formats[i].codec_mode !=
> - HANTRO_MODE_NONE))
> + HANTRO_MODE_NONE) &&
> + hantro_check_depth_match(ctx, &formats[i]))
> return &formats[i];
> }
> return NULL;
> @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
> + fmt = &formats[i];
>
> if (skip_mode_none == mode_none)
> continue;
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> return -EINVAL;
> formats = hantro_get_postproc_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> + fmt = &formats[i];
> +
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
> index 18bc682c8556..f4a5905ed518 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.h
> +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> extern const struct vb2_ops hantro_queue_ops;
>
> void hantro_reset_fmts(struct hantro_ctx *ctx);
> +int hantro_get_formath_depth(u32 fourcc);
>
> #endif /* HANTRO_V4L2_H_ */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-04-05 16:09 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:09 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> In preparation for supporting 10-bit formats, add mechanism which will
> filter formats based on pixel depth.
>
> Hantro G2 supports only one decoding format natively and that is based
> on bit depth of current video frame. Additionally, it makes no sense to
> upconvert bitness, so filter those out too.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> 3 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
> index 06d0f3597694..c6525ee8d89a 100644
> --- a/drivers/staging/media/hantro/hantro.h
> +++ b/drivers/staging/media/hantro/hantro.h
> @@ -227,6 +227,7 @@ struct hantro_dev {
> *
> * @ctrl_handler: Control handler used to register controls.
> * @jpeg_quality: User-specified JPEG compression quality.
> + * @bit_depth: Bit depth of current frame
> *
> * @codec_ops: Set of operations related to codec mode.
> * @postproc: Post-processing context.
> @@ -252,6 +253,7 @@ struct hantro_ctx {
>
> struct v4l2_ctrl_handler ctrl_handler;
> int jpeg_quality;
> + int bit_depth;
>
> const struct hantro_codec_ops *codec_ops;
> struct hantro_postproc_ctx postproc;
> @@ -278,6 +280,7 @@ struct hantro_ctx {
> * @enc_fmt: Format identifier for encoder registers.
> * @frmsize: Supported range of frame sizes (only for bitstream formats).
> * @postprocessed: Indicates if this format needs the post-processor.
> + * @match_depth: Indicates if format bit depth must match video bit depth
> */
> struct hantro_fmt {
> char *name;
> @@ -288,6 +291,7 @@ struct hantro_fmt {
> enum hantro_enc_fmt enc_fmt;
> struct v4l2_frmsize_stepwise frmsize;
> bool postprocessed;
> + bool match_depth;
> };
>
> struct hantro_reg {
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
> index e595905b3bd7..1214fa2f64ae 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.c
> +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx *ctx,
> return ctx->dev->variant->postproc_fmts;
> }
>
> +int hantro_get_formath_depth(u32 fourcc)
Just a typo here:
s/hantro_get_formath_depth -> hantro_get_format_depth
regards
Benjamin
> +{
> + switch (fourcc) {
> + case V4L2_PIX_FMT_P010:
> + case V4L2_PIX_FMT_P010_4L4:
> + return 10;
> + default:
> + return 8;
> + }
> +}
> +
> +static bool
> +hantro_check_depth_match(const struct hantro_ctx *ctx,
> + const struct hantro_fmt *fmt)
> +{
> + int fmt_depth, ctx_depth = 8;
> +
> + if (!fmt->match_depth && !fmt->postprocessed)
> + return true;
> +
> + /* 0 means default depth, which is 8 */
> + if (ctx->bit_depth)
> + ctx_depth = ctx->bit_depth;
> +
> + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> +
> + /*
> + * Allow only downconversion for postproc formats for now.
> + * It may be possible to relax that on some HW.
> + */
> + if (!fmt->match_depth)
> + return fmt_depth <= ctx_depth;
> +
> + return fmt_depth == ctx_depth;
> +}
> +
> static const struct hantro_fmt *
> hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> {
> @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> if (bitstream == (formats[i].codec_mode !=
> - HANTRO_MODE_NONE))
> + HANTRO_MODE_NONE) &&
> + hantro_check_depth_match(ctx, &formats[i]))
> return &formats[i];
> }
> return NULL;
> @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> formats = hantro_get_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
> + fmt = &formats[i];
>
> if (skip_mode_none == mode_none)
> continue;
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> return -EINVAL;
> formats = hantro_get_postproc_formats(ctx, &num_fmts);
> for (i = 0; i < num_fmts; i++) {
> + fmt = &formats[i];
> +
> + if (!hantro_check_depth_match(ctx, fmt))
> + continue;
> if (j == f->index) {
> - fmt = &formats[i];
> f->pixelformat = fmt->fourcc;
> return 0;
> }
> diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
> index 18bc682c8556..f4a5905ed518 100644
> --- a/drivers/staging/media/hantro/hantro_v4l2.h
> +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> extern const struct vb2_ops hantro_queue_ops;
>
> void hantro_reset_fmts(struct hantro_ctx *ctx);
> +int hantro_get_formath_depth(u32 fourcc);
>
> #endif /* HANTRO_V4L2_H_ */
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
2022-04-05 16:09 ` Benjamin Gaignard
(?)
@ 2022-04-05 18:41 ` Jernej Škrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:41 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne torek, 05. april 2022 ob 18:09:03 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > In preparation for supporting 10-bit formats, add mechanism which will
> > filter formats based on pixel depth.
> >
> > Hantro G2 supports only one decoding format natively and that is based
> > on bit depth of current video frame. Additionally, it makes no sense to
> > upconvert bitness, so filter those out too.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> >
> > drivers/staging/media/hantro/hantro.h | 4 ++
> > drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> > drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> > 3 files changed, 50 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro.h
> > b/drivers/staging/media/hantro/hantro.h index 06d0f3597694..c6525ee8d89a
> > 100644
> > --- a/drivers/staging/media/hantro/hantro.h
> > +++ b/drivers/staging/media/hantro/hantro.h
> > @@ -227,6 +227,7 @@ struct hantro_dev {
> >
> > *
> > * @ctrl_handler: Control handler used to register controls.
> > * @jpeg_quality: User-specified JPEG compression quality.
> >
> > + * @bit_depth: Bit depth of current frame
> >
> > *
> > * @codec_ops: Set of operations related to codec mode.
> > * @postproc: Post-processing context.
> >
> > @@ -252,6 +253,7 @@ struct hantro_ctx {
> >
> > struct v4l2_ctrl_handler ctrl_handler;
> > int jpeg_quality;
> >
> > + int bit_depth;
> >
> > const struct hantro_codec_ops *codec_ops;
> > struct hantro_postproc_ctx postproc;
> >
> > @@ -278,6 +280,7 @@ struct hantro_ctx {
> >
> > * @enc_fmt: Format identifier for encoder registers.
> > * @frmsize: Supported range of frame sizes (only for bitstream
> > formats).
> > * @postprocessed: Indicates if this format needs the post-processor.
> >
> > + * @match_depth: Indicates if format bit depth must match video bit depth
> >
> > */
> >
> > struct hantro_fmt {
> >
> > char *name;
> >
> > @@ -288,6 +291,7 @@ struct hantro_fmt {
> >
> > enum hantro_enc_fmt enc_fmt;
> > struct v4l2_frmsize_stepwise frmsize;
> > bool postprocessed;
> >
> > + bool match_depth;
> >
> > };
> >
> > struct hantro_reg {
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
> > b/drivers/staging/media/hantro/hantro_v4l2.c index
> > e595905b3bd7..1214fa2f64ae 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.c
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> > @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx
> > *ctx,>
> > return ctx->dev->variant->postproc_fmts;
> >
> > }
> >
> > +int hantro_get_formath_depth(u32 fourcc)
>
> Just a typo here:
>
> s/hantro_get_formath_depth -> hantro_get_format_depth
Good catch! I'll fix it in new series.
Best regards,
Jernej
>
> regards
> Benjamin
>
> > +{
> > + switch (fourcc) {
> > + case V4L2_PIX_FMT_P010:
> > + case V4L2_PIX_FMT_P010_4L4:
> > + return 10;
> > + default:
> > + return 8;
> > + }
> > +}
> > +
> > +static bool
> > +hantro_check_depth_match(const struct hantro_ctx *ctx,
> > + const struct hantro_fmt *fmt)
> > +{
> > + int fmt_depth, ctx_depth = 8;
> > +
> > + if (!fmt->match_depth && !fmt->postprocessed)
> > + return true;
> > +
> > + /* 0 means default depth, which is 8 */
> > + if (ctx->bit_depth)
> > + ctx_depth = ctx->bit_depth;
> > +
> > + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> > +
> > + /*
> > + * Allow only downconversion for postproc formats for now.
> > + * It may be possible to relax that on some HW.
> > + */
> > + if (!fmt->match_depth)
> > + return fmt_depth <= ctx_depth;
> > +
> > + return fmt_depth == ctx_depth;
> > +}
> > +
> >
> > static const struct hantro_fmt *
> > hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> > {
> >
> > @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx,
> > bool bitstream)>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > if (bitstream == (formats[i].codec_mode !=
> >
> > - HANTRO_MODE_NONE))
> > + HANTRO_MODE_NONE) &&
> > + hantro_check_depth_match(ctx, &formats[i]))
> >
> > return &formats[i];
> >
> > }
> > return NULL;
> >
> > @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > bool mode_none = formats[i].codec_mode ==
HANTRO_MODE_NONE;
> >
> > + fmt = &formats[i];
> >
> > if (skip_mode_none == mode_none)
> >
> > continue;
> >
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > return -EINVAL;
> >
> > formats = hantro_get_postproc_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > + fmt = &formats[i];
> > +
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.h
> > b/drivers/staging/media/hantro/hantro_v4l2.h index
> > 18bc682c8556..f4a5905ed518 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.h
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> > @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> >
> > extern const struct vb2_ops hantro_queue_ops;
> >
> > void hantro_reset_fmts(struct hantro_ctx *ctx);
> >
> > +int hantro_get_formath_depth(u32 fourcc);
> >
> > #endif /* HANTRO_V4L2_H_ */
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-04-05 18:41 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:41 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne torek, 05. april 2022 ob 18:09:03 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > In preparation for supporting 10-bit formats, add mechanism which will
> > filter formats based on pixel depth.
> >
> > Hantro G2 supports only one decoding format natively and that is based
> > on bit depth of current video frame. Additionally, it makes no sense to
> > upconvert bitness, so filter those out too.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> >
> > drivers/staging/media/hantro/hantro.h | 4 ++
> > drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> > drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> > 3 files changed, 50 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro.h
> > b/drivers/staging/media/hantro/hantro.h index 06d0f3597694..c6525ee8d89a
> > 100644
> > --- a/drivers/staging/media/hantro/hantro.h
> > +++ b/drivers/staging/media/hantro/hantro.h
> > @@ -227,6 +227,7 @@ struct hantro_dev {
> >
> > *
> > * @ctrl_handler: Control handler used to register controls.
> > * @jpeg_quality: User-specified JPEG compression quality.
> >
> > + * @bit_depth: Bit depth of current frame
> >
> > *
> > * @codec_ops: Set of operations related to codec mode.
> > * @postproc: Post-processing context.
> >
> > @@ -252,6 +253,7 @@ struct hantro_ctx {
> >
> > struct v4l2_ctrl_handler ctrl_handler;
> > int jpeg_quality;
> >
> > + int bit_depth;
> >
> > const struct hantro_codec_ops *codec_ops;
> > struct hantro_postproc_ctx postproc;
> >
> > @@ -278,6 +280,7 @@ struct hantro_ctx {
> >
> > * @enc_fmt: Format identifier for encoder registers.
> > * @frmsize: Supported range of frame sizes (only for bitstream
> > formats).
> > * @postprocessed: Indicates if this format needs the post-processor.
> >
> > + * @match_depth: Indicates if format bit depth must match video bit depth
> >
> > */
> >
> > struct hantro_fmt {
> >
> > char *name;
> >
> > @@ -288,6 +291,7 @@ struct hantro_fmt {
> >
> > enum hantro_enc_fmt enc_fmt;
> > struct v4l2_frmsize_stepwise frmsize;
> > bool postprocessed;
> >
> > + bool match_depth;
> >
> > };
> >
> > struct hantro_reg {
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
> > b/drivers/staging/media/hantro/hantro_v4l2.c index
> > e595905b3bd7..1214fa2f64ae 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.c
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> > @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx
> > *ctx,>
> > return ctx->dev->variant->postproc_fmts;
> >
> > }
> >
> > +int hantro_get_formath_depth(u32 fourcc)
>
> Just a typo here:
>
> s/hantro_get_formath_depth -> hantro_get_format_depth
Good catch! I'll fix it in new series.
Best regards,
Jernej
>
> regards
> Benjamin
>
> > +{
> > + switch (fourcc) {
> > + case V4L2_PIX_FMT_P010:
> > + case V4L2_PIX_FMT_P010_4L4:
> > + return 10;
> > + default:
> > + return 8;
> > + }
> > +}
> > +
> > +static bool
> > +hantro_check_depth_match(const struct hantro_ctx *ctx,
> > + const struct hantro_fmt *fmt)
> > +{
> > + int fmt_depth, ctx_depth = 8;
> > +
> > + if (!fmt->match_depth && !fmt->postprocessed)
> > + return true;
> > +
> > + /* 0 means default depth, which is 8 */
> > + if (ctx->bit_depth)
> > + ctx_depth = ctx->bit_depth;
> > +
> > + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> > +
> > + /*
> > + * Allow only downconversion for postproc formats for now.
> > + * It may be possible to relax that on some HW.
> > + */
> > + if (!fmt->match_depth)
> > + return fmt_depth <= ctx_depth;
> > +
> > + return fmt_depth == ctx_depth;
> > +}
> > +
> >
> > static const struct hantro_fmt *
> > hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> > {
> >
> > @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx,
> > bool bitstream)>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > if (bitstream == (formats[i].codec_mode !=
> >
> > - HANTRO_MODE_NONE))
> > + HANTRO_MODE_NONE) &&
> > + hantro_check_depth_match(ctx, &formats[i]))
> >
> > return &formats[i];
> >
> > }
> > return NULL;
> >
> > @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > bool mode_none = formats[i].codec_mode ==
HANTRO_MODE_NONE;
> >
> > + fmt = &formats[i];
> >
> > if (skip_mode_none == mode_none)
> >
> > continue;
> >
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > return -EINVAL;
> >
> > formats = hantro_get_postproc_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > + fmt = &formats[i];
> > +
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.h
> > b/drivers/staging/media/hantro/hantro_v4l2.h index
> > 18bc682c8556..f4a5905ed518 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.h
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> > @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> >
> > extern const struct vb2_ops hantro_queue_ops;
> >
> > void hantro_reset_fmts(struct hantro_ctx *ctx);
> >
> > +int hantro_get_formath_depth(u32 fourcc);
> >
> > #endif /* HANTRO_V4L2_H_ */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 3/8] media: hantro: Support format filtering by depth
@ 2022-04-05 18:41 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:41 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne torek, 05. april 2022 ob 18:09:03 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > In preparation for supporting 10-bit formats, add mechanism which will
> > filter formats based on pixel depth.
> >
> > Hantro G2 supports only one decoding format natively and that is based
> > on bit depth of current video frame. Additionally, it makes no sense to
> > upconvert bitness, so filter those out too.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> >
> > drivers/staging/media/hantro/hantro.h | 4 ++
> > drivers/staging/media/hantro/hantro_v4l2.c | 48 ++++++++++++++++++++--
> > drivers/staging/media/hantro/hantro_v4l2.h | 1 +
> > 3 files changed, 50 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro.h
> > b/drivers/staging/media/hantro/hantro.h index 06d0f3597694..c6525ee8d89a
> > 100644
> > --- a/drivers/staging/media/hantro/hantro.h
> > +++ b/drivers/staging/media/hantro/hantro.h
> > @@ -227,6 +227,7 @@ struct hantro_dev {
> >
> > *
> > * @ctrl_handler: Control handler used to register controls.
> > * @jpeg_quality: User-specified JPEG compression quality.
> >
> > + * @bit_depth: Bit depth of current frame
> >
> > *
> > * @codec_ops: Set of operations related to codec mode.
> > * @postproc: Post-processing context.
> >
> > @@ -252,6 +253,7 @@ struct hantro_ctx {
> >
> > struct v4l2_ctrl_handler ctrl_handler;
> > int jpeg_quality;
> >
> > + int bit_depth;
> >
> > const struct hantro_codec_ops *codec_ops;
> > struct hantro_postproc_ctx postproc;
> >
> > @@ -278,6 +280,7 @@ struct hantro_ctx {
> >
> > * @enc_fmt: Format identifier for encoder registers.
> > * @frmsize: Supported range of frame sizes (only for bitstream
> > formats).
> > * @postprocessed: Indicates if this format needs the post-processor.
> >
> > + * @match_depth: Indicates if format bit depth must match video bit depth
> >
> > */
> >
> > struct hantro_fmt {
> >
> > char *name;
> >
> > @@ -288,6 +291,7 @@ struct hantro_fmt {
> >
> > enum hantro_enc_fmt enc_fmt;
> > struct v4l2_frmsize_stepwise frmsize;
> > bool postprocessed;
> >
> > + bool match_depth;
> >
> > };
> >
> > struct hantro_reg {
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c
> > b/drivers/staging/media/hantro/hantro_v4l2.c index
> > e595905b3bd7..1214fa2f64ae 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.c
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.c
> > @@ -64,6 +64,42 @@ hantro_get_postproc_formats(const struct hantro_ctx
> > *ctx,>
> > return ctx->dev->variant->postproc_fmts;
> >
> > }
> >
> > +int hantro_get_formath_depth(u32 fourcc)
>
> Just a typo here:
>
> s/hantro_get_formath_depth -> hantro_get_format_depth
Good catch! I'll fix it in new series.
Best regards,
Jernej
>
> regards
> Benjamin
>
> > +{
> > + switch (fourcc) {
> > + case V4L2_PIX_FMT_P010:
> > + case V4L2_PIX_FMT_P010_4L4:
> > + return 10;
> > + default:
> > + return 8;
> > + }
> > +}
> > +
> > +static bool
> > +hantro_check_depth_match(const struct hantro_ctx *ctx,
> > + const struct hantro_fmt *fmt)
> > +{
> > + int fmt_depth, ctx_depth = 8;
> > +
> > + if (!fmt->match_depth && !fmt->postprocessed)
> > + return true;
> > +
> > + /* 0 means default depth, which is 8 */
> > + if (ctx->bit_depth)
> > + ctx_depth = ctx->bit_depth;
> > +
> > + fmt_depth = hantro_get_formath_depth(fmt->fourcc);
> > +
> > + /*
> > + * Allow only downconversion for postproc formats for now.
> > + * It may be possible to relax that on some HW.
> > + */
> > + if (!fmt->match_depth)
> > + return fmt_depth <= ctx_depth;
> > +
> > + return fmt_depth == ctx_depth;
> > +}
> > +
> >
> > static const struct hantro_fmt *
> > hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
> > {
> >
> > @@ -91,7 +127,8 @@ hantro_get_default_fmt(const struct hantro_ctx *ctx,
> > bool bitstream)>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > if (bitstream == (formats[i].codec_mode !=
> >
> > - HANTRO_MODE_NONE))
> > + HANTRO_MODE_NONE) &&
> > + hantro_check_depth_match(ctx, &formats[i]))
> >
> > return &formats[i];
> >
> > }
> > return NULL;
> >
> > @@ -163,11 +200,13 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > formats = hantro_get_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > bool mode_none = formats[i].codec_mode ==
HANTRO_MODE_NONE;
> >
> > + fmt = &formats[i];
> >
> > if (skip_mode_none == mode_none)
> >
> > continue;
> >
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > @@ -183,8 +222,11 @@ static int vidioc_enum_fmt(struct file *file, void
> > *priv,>
> > return -EINVAL;
> >
> > formats = hantro_get_postproc_formats(ctx, &num_fmts);
> > for (i = 0; i < num_fmts; i++) {
> >
> > + fmt = &formats[i];
> > +
> > + if (!hantro_check_depth_match(ctx, fmt))
> > + continue;
> >
> > if (j == f->index) {
> >
> > - fmt = &formats[i];
> >
> > f->pixelformat = fmt->fourcc;
> > return 0;
> >
> > }
> >
> > diff --git a/drivers/staging/media/hantro/hantro_v4l2.h
> > b/drivers/staging/media/hantro/hantro_v4l2.h index
> > 18bc682c8556..f4a5905ed518 100644
> > --- a/drivers/staging/media/hantro/hantro_v4l2.h
> > +++ b/drivers/staging/media/hantro/hantro_v4l2.h
> > @@ -22,5 +22,6 @@ extern const struct v4l2_ioctl_ops hantro_ioctl_ops;
> >
> > extern const struct vb2_ops hantro_queue_ops;
> >
> > void hantro_reset_fmts(struct hantro_ctx *ctx);
> >
> > +int hantro_get_formath_depth(u32 fourcc);
> >
> > #endif /* HANTRO_V4L2_H_ */
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
When allocating aux buffers for postprocessing, it's assumed that base
buffer size is the same as that of output. Coincidentally, that's true
most of the time, but not always. 10-bit source also needs aux buffer
size which is appropriate for 10-bit native format, even if the output
format is 8-bit. Similarly, mv sizes and other extra buffer size also
depends on source width/height, not destination.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
.../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 248abe5423f0..1a76628d5754 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -12,6 +12,7 @@
#include "hantro_hw.h"
#include "hantro_g1_regs.h"
#include "hantro_g2_regs.h"
+#include "hantro_v4l2.h"
#define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
{ \
@@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
unsigned int num_buffers = cap_queue->num_buffers;
+ struct v4l2_pix_format_mplane pix_mp;
+ const struct hantro_fmt *fmt;
unsigned int i, buf_size;
- buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
+ /* this should always pick native format */
+ fmt = hantro_get_default_fmt(ctx, false);
+ if (!fmt)
+ return -EINVAL;
+ v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
+ ctx->src_fmt.height);
+
+ buf_size = pix_mp.plane_fmt[0].sizeimage;
if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE)
- buf_size += hantro_h264_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_h264_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_VP9_FRAME)
- buf_size += hantro_vp9_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_vp9_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_HEVC_SLICE)
- buf_size += hantro_hevc_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_hevc_mv_size(pix_mp.width,
+ pix_mp.height);
for (i = 0; i < num_buffers; ++i) {
struct hantro_aux_buf *priv = &ctx->postproc.dec_q[i];
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1214fa2f64ae..69d2a108e1e6 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -118,7 +118,7 @@ hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
return NULL;
}
-static const struct hantro_fmt *
+const struct hantro_fmt *
hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
{
const struct hantro_fmt *formats;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index f4a5905ed518..cc9a645be886 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -23,5 +23,7 @@ extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
int hantro_get_formath_depth(u32 fourcc);
+const struct hantro_fmt *
+hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
When allocating aux buffers for postprocessing, it's assumed that base
buffer size is the same as that of output. Coincidentally, that's true
most of the time, but not always. 10-bit source also needs aux buffer
size which is appropriate for 10-bit native format, even if the output
format is 8-bit. Similarly, mv sizes and other extra buffer size also
depends on source width/height, not destination.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
.../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 248abe5423f0..1a76628d5754 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -12,6 +12,7 @@
#include "hantro_hw.h"
#include "hantro_g1_regs.h"
#include "hantro_g2_regs.h"
+#include "hantro_v4l2.h"
#define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
{ \
@@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
unsigned int num_buffers = cap_queue->num_buffers;
+ struct v4l2_pix_format_mplane pix_mp;
+ const struct hantro_fmt *fmt;
unsigned int i, buf_size;
- buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
+ /* this should always pick native format */
+ fmt = hantro_get_default_fmt(ctx, false);
+ if (!fmt)
+ return -EINVAL;
+ v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
+ ctx->src_fmt.height);
+
+ buf_size = pix_mp.plane_fmt[0].sizeimage;
if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE)
- buf_size += hantro_h264_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_h264_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_VP9_FRAME)
- buf_size += hantro_vp9_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_vp9_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_HEVC_SLICE)
- buf_size += hantro_hevc_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_hevc_mv_size(pix_mp.width,
+ pix_mp.height);
for (i = 0; i < num_buffers; ++i) {
struct hantro_aux_buf *priv = &ctx->postproc.dec_q[i];
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1214fa2f64ae..69d2a108e1e6 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -118,7 +118,7 @@ hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
return NULL;
}
-static const struct hantro_fmt *
+const struct hantro_fmt *
hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
{
const struct hantro_fmt *formats;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index f4a5905ed518..cc9a645be886 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -23,5 +23,7 @@ extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
int hantro_get_formath_depth(u32 fourcc);
+const struct hantro_fmt *
+hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
When allocating aux buffers for postprocessing, it's assumed that base
buffer size is the same as that of output. Coincidentally, that's true
most of the time, but not always. 10-bit source also needs aux buffer
size which is appropriate for 10-bit native format, even if the output
format is 8-bit. Similarly, mv sizes and other extra buffer size also
depends on source width/height, not destination.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
.../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 248abe5423f0..1a76628d5754 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -12,6 +12,7 @@
#include "hantro_hw.h"
#include "hantro_g1_regs.h"
#include "hantro_g2_regs.h"
+#include "hantro_v4l2.h"
#define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
{ \
@@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
unsigned int num_buffers = cap_queue->num_buffers;
+ struct v4l2_pix_format_mplane pix_mp;
+ const struct hantro_fmt *fmt;
unsigned int i, buf_size;
- buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
+ /* this should always pick native format */
+ fmt = hantro_get_default_fmt(ctx, false);
+ if (!fmt)
+ return -EINVAL;
+ v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
+ ctx->src_fmt.height);
+
+ buf_size = pix_mp.plane_fmt[0].sizeimage;
if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE)
- buf_size += hantro_h264_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_h264_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_VP9_FRAME)
- buf_size += hantro_vp9_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_vp9_mv_size(pix_mp.width,
+ pix_mp.height);
else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_HEVC_SLICE)
- buf_size += hantro_hevc_mv_size(ctx->dst_fmt.width,
- ctx->dst_fmt.height);
+ buf_size += hantro_hevc_mv_size(pix_mp.width,
+ pix_mp.height);
for (i = 0; i < num_buffers; ++i) {
struct hantro_aux_buf *priv = &ctx->postproc.dec_q[i];
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1214fa2f64ae..69d2a108e1e6 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -118,7 +118,7 @@ hantro_find_format(const struct hantro_ctx *ctx, u32 fourcc)
return NULL;
}
-static const struct hantro_fmt *
+const struct hantro_fmt *
hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream)
{
const struct hantro_fmt *formats;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.h b/drivers/staging/media/hantro/hantro_v4l2.h
index f4a5905ed518..cc9a645be886 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.h
+++ b/drivers/staging/media/hantro/hantro_v4l2.h
@@ -23,5 +23,7 @@ extern const struct vb2_ops hantro_queue_ops;
void hantro_reset_fmts(struct hantro_ctx *ctx);
int hantro_get_formath_depth(u32 fourcc);
+const struct hantro_fmt *
+hantro_get_default_fmt(const struct hantro_ctx *ctx, bool bitstream);
#endif /* HANTRO_V4L2_H_ */
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread* Re: [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-04-04 0:16 ` Ezequiel Garcia
-1 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:16 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Jernej,
On Sun, Feb 27, 2022 at 03:49:22PM +0100, Jernej Skrabec wrote:
> When allocating aux buffers for postprocessing, it's assumed that base
> buffer size is the same as that of output. Coincidentally, that's true
> most of the time, but not always. 10-bit source also needs aux buffer
> size which is appropriate for 10-bit native format, even if the output
> format is 8-bit. Similarly, mv sizes and other extra buffer size also
> depends on source width/height, not destination.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> .../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
> drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
> drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 248abe5423f0..1a76628d5754 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -12,6 +12,7 @@
> #include "hantro_hw.h"
> #include "hantro_g1_regs.h"
> #include "hantro_g2_regs.h"
> +#include "hantro_v4l2.h"
>
> #define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
> { \
> @@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
> struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
> unsigned int num_buffers = cap_queue->num_buffers;
> + struct v4l2_pix_format_mplane pix_mp;
> + const struct hantro_fmt *fmt;
> unsigned int i, buf_size;
>
> - buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
> + /* this should always pick native format */
> + fmt = hantro_get_default_fmt(ctx, false);
> + if (!fmt)
> + return -EINVAL;
> + v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
> + ctx->src_fmt.height);
> +
> + buf_size = pix_mp.plane_fmt[0].sizeimage;
Took me a while to see that the main change is taking buf_size
from pix_mp, which now takes into account the bit-depth :)
To me this makes sense.
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Thanks,
Ezequiel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
@ 2022-04-04 0:16 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:16 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Jernej,
On Sun, Feb 27, 2022 at 03:49:22PM +0100, Jernej Skrabec wrote:
> When allocating aux buffers for postprocessing, it's assumed that base
> buffer size is the same as that of output. Coincidentally, that's true
> most of the time, but not always. 10-bit source also needs aux buffer
> size which is appropriate for 10-bit native format, even if the output
> format is 8-bit. Similarly, mv sizes and other extra buffer size also
> depends on source width/height, not destination.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> .../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
> drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
> drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 248abe5423f0..1a76628d5754 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -12,6 +12,7 @@
> #include "hantro_hw.h"
> #include "hantro_g1_regs.h"
> #include "hantro_g2_regs.h"
> +#include "hantro_v4l2.h"
>
> #define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
> { \
> @@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
> struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
> unsigned int num_buffers = cap_queue->num_buffers;
> + struct v4l2_pix_format_mplane pix_mp;
> + const struct hantro_fmt *fmt;
> unsigned int i, buf_size;
>
> - buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
> + /* this should always pick native format */
> + fmt = hantro_get_default_fmt(ctx, false);
> + if (!fmt)
> + return -EINVAL;
> + v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
> + ctx->src_fmt.height);
> +
> + buf_size = pix_mp.plane_fmt[0].sizeimage;
Took me a while to see that the main change is taking buf_size
from pix_mp, which now takes into account the bit-depth :)
To me this makes sense.
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Thanks,
Ezequiel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 4/8] media: hantro: postproc: Fix buffer size calculation
@ 2022-04-04 0:16 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:16 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Jernej,
On Sun, Feb 27, 2022 at 03:49:22PM +0100, Jernej Skrabec wrote:
> When allocating aux buffers for postprocessing, it's assumed that base
> buffer size is the same as that of output. Coincidentally, that's true
> most of the time, but not always. 10-bit source also needs aux buffer
> size which is appropriate for 10-bit native format, even if the output
> format is 8-bit. Similarly, mv sizes and other extra buffer size also
> depends on source width/height, not destination.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> .../staging/media/hantro/hantro_postproc.c | 24 +++++++++++++------
> drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
> drivers/staging/media/hantro/hantro_v4l2.h | 2 ++
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 248abe5423f0..1a76628d5754 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -12,6 +12,7 @@
> #include "hantro_hw.h"
> #include "hantro_g1_regs.h"
> #include "hantro_g2_regs.h"
> +#include "hantro_v4l2.h"
>
> #define HANTRO_PP_REG_WRITE(vpu, reg_name, val) \
> { \
> @@ -137,18 +138,27 @@ int hantro_postproc_alloc(struct hantro_ctx *ctx)
> struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> struct vb2_queue *cap_queue = &m2m_ctx->cap_q_ctx.q;
> unsigned int num_buffers = cap_queue->num_buffers;
> + struct v4l2_pix_format_mplane pix_mp;
> + const struct hantro_fmt *fmt;
> unsigned int i, buf_size;
>
> - buf_size = ctx->dst_fmt.plane_fmt[0].sizeimage;
> + /* this should always pick native format */
> + fmt = hantro_get_default_fmt(ctx, false);
> + if (!fmt)
> + return -EINVAL;
> + v4l2_fill_pixfmt_mp(&pix_mp, fmt->fourcc, ctx->src_fmt.width,
> + ctx->src_fmt.height);
> +
> + buf_size = pix_mp.plane_fmt[0].sizeimage;
Took me a while to see that the main change is taking buf_size
from pix_mp, which now takes into account the bit-depth :)
To me this makes sense.
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Thanks,
Ezequiel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Some postproc legacy registers were set in VP9 code. Move them to
postproc and fix their value.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
index 91c21b634fab..c9cb11fd95af 100644
--- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
+++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
@@ -515,16 +515,8 @@ static void
config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
{
if (ctx->dev->variant->legacy_regs) {
- u8 pp_shift = 0;
-
hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
- hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
-
- if (dec_params->bit_depth > 8)
- pp_shift = 16 - dec_params->bit_depth;
-
- hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
} else {
hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 1a76628d5754..11ae663f11b7 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
+ if (ctx->dev->variant->legacy_regs) {
+ int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
+ u8 pp_shift = 0;
+
+ if (out_depth > 8)
+ pp_shift = 16 - out_depth;
+
+ hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
+ hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
+ }
hantro_reg_write(vpu, &g2_out_rs_e, 1);
}
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Some postproc legacy registers were set in VP9 code. Move them to
postproc and fix their value.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
index 91c21b634fab..c9cb11fd95af 100644
--- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
+++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
@@ -515,16 +515,8 @@ static void
config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
{
if (ctx->dev->variant->legacy_regs) {
- u8 pp_shift = 0;
-
hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
- hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
-
- if (dec_params->bit_depth > 8)
- pp_shift = 16 - dec_params->bit_depth;
-
- hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
} else {
hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 1a76628d5754..11ae663f11b7 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
+ if (ctx->dev->variant->legacy_regs) {
+ int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
+ u8 pp_shift = 0;
+
+ if (out_depth > 8)
+ pp_shift = 16 - out_depth;
+
+ hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
+ hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
+ }
hantro_reg_write(vpu, &g2_out_rs_e, 1);
}
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Some postproc legacy registers were set in VP9 code. Move them to
postproc and fix their value.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
index 91c21b634fab..c9cb11fd95af 100644
--- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
+++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
@@ -515,16 +515,8 @@ static void
config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
{
if (ctx->dev->variant->legacy_regs) {
- u8 pp_shift = 0;
-
hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
- hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
-
- if (dec_params->bit_depth > 8)
- pp_shift = 16 - dec_params->bit_depth;
-
- hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
} else {
hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 1a76628d5754..11ae663f11b7 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
+ if (ctx->dev->variant->legacy_regs) {
+ int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
+ u8 pp_shift = 0;
+
+ if (out_depth > 8)
+ pp_shift = 16 - out_depth;
+
+ hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
+ hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
+ }
hantro_reg_write(vpu, &g2_out_rs_e, 1);
}
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread* Re: [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-04-04 0:24 ` Ezequiel Garcia
-1 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:24 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
On Sun, Feb 27, 2022 at 03:49:23PM +0100, Jernej Skrabec wrote:
> Some postproc legacy registers were set in VP9 code. Move them to
> postproc and fix their value.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> ---
> drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
> drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> index 91c21b634fab..c9cb11fd95af 100644
> --- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> +++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> @@ -515,16 +515,8 @@ static void
> config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
> {
> if (ctx->dev->variant->legacy_regs) {
> - u8 pp_shift = 0;
> -
> hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
> hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
> - hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
> -
> - if (dec_params->bit_depth > 8)
> - pp_shift = 16 - dec_params->bit_depth;
> -
> - hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
> } else {
> hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 1a76628d5754..11ae663f11b7 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
>
> hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
> hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
> + if (ctx->dev->variant->legacy_regs) {
> + int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
> + u8 pp_shift = 0;
> +
> + if (out_depth > 8)
> + pp_shift = 16 - out_depth;
> +
> + hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
> + hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> + }
> hantro_reg_write(vpu, &g2_out_rs_e, 1);
> }
>
> --
> 2.35.1
>
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
@ 2022-04-04 0:24 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:24 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
On Sun, Feb 27, 2022 at 03:49:23PM +0100, Jernej Skrabec wrote:
> Some postproc legacy registers were set in VP9 code. Move them to
> postproc and fix their value.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> ---
> drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
> drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> index 91c21b634fab..c9cb11fd95af 100644
> --- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> +++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> @@ -515,16 +515,8 @@ static void
> config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
> {
> if (ctx->dev->variant->legacy_regs) {
> - u8 pp_shift = 0;
> -
> hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
> hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
> - hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
> -
> - if (dec_params->bit_depth > 8)
> - pp_shift = 16 - dec_params->bit_depth;
> -
> - hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
> } else {
> hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 1a76628d5754..11ae663f11b7 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
>
> hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
> hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
> + if (ctx->dev->variant->legacy_regs) {
> + int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
> + u8 pp_shift = 0;
> +
> + if (out_depth > 8)
> + pp_shift = 16 - out_depth;
> +
> + hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
> + hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> + }
> hantro_reg_write(vpu, &g2_out_rs_e, 1);
> }
>
> --
> 2.35.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [RFC PATCH 5/8] media: hantro: postproc: Fix legacy regs configuration
@ 2022-04-04 0:24 ` Ezequiel Garcia
0 siblings, 0 replies; 72+ messages in thread
From: Ezequiel Garcia @ 2022-04-04 0:24 UTC (permalink / raw)
To: Jernej Skrabec
Cc: p.zabel, mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
On Sun, Feb 27, 2022 at 03:49:23PM +0100, Jernej Skrabec wrote:
> Some postproc legacy registers were set in VP9 code. Move them to
> postproc and fix their value.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> ---
> drivers/staging/media/hantro/hantro_g2_vp9_dec.c | 8 --------
> drivers/staging/media/hantro/hantro_postproc.c | 10 ++++++++++
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> index 91c21b634fab..c9cb11fd95af 100644
> --- a/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> +++ b/drivers/staging/media/hantro/hantro_g2_vp9_dec.c
> @@ -515,16 +515,8 @@ static void
> config_bit_depth(struct hantro_ctx *ctx, const struct v4l2_ctrl_vp9_frame *dec_params)
> {
> if (ctx->dev->variant->legacy_regs) {
> - u8 pp_shift = 0;
> -
> hantro_reg_write(ctx->dev, &g2_bit_depth_y, dec_params->bit_depth);
> hantro_reg_write(ctx->dev, &g2_bit_depth_c, dec_params->bit_depth);
> - hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, dec_params->bit_depth);
> -
> - if (dec_params->bit_depth > 8)
> - pp_shift = 16 - dec_params->bit_depth;
> -
> - hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> hantro_reg_write(ctx->dev, &g2_pix_shift, 0);
> } else {
> hantro_reg_write(ctx->dev, &g2_bit_depth_y_minus8, dec_params->bit_depth - 8);
> diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
> index 1a76628d5754..11ae663f11b7 100644
> --- a/drivers/staging/media/hantro/hantro_postproc.c
> +++ b/drivers/staging/media/hantro/hantro_postproc.c
> @@ -113,6 +113,16 @@ static void hantro_postproc_g2_enable(struct hantro_ctx *ctx)
>
> hantro_write_addr(vpu, G2_RS_OUT_LUMA_ADDR, dst_dma);
> hantro_write_addr(vpu, G2_RS_OUT_CHROMA_ADDR, dst_dma + chroma_offset);
> + if (ctx->dev->variant->legacy_regs) {
> + int out_depth = hantro_get_formath_depth(ctx->dst_fmt.pixelformat);
> + u8 pp_shift = 0;
> +
> + if (out_depth > 8)
> + pp_shift = 16 - out_depth;
> +
> + hantro_reg_write(ctx->dev, &g2_rs_out_bit_depth, out_depth);
> + hantro_reg_write(ctx->dev, &g2_pp_pix_shift, pp_shift);
> + }
> hantro_reg_write(vpu, &g2_out_rs_e, 1);
> }
>
> --
> 2.35.1
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* [RFC PATCH 6/8] media: hantro: Store VP9 bit depth in context
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that we have proper infrastructure for postprocessing 10-bit
formats, store VP9 bit depth in context.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 6a51f39dde56..305090365e74 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -320,6 +320,24 @@ static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
return 0;
}
+static int hantro_vp9_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct hantro_ctx *ctx;
+
+ ctx = container_of(ctrl->handler,
+ struct hantro_ctx, ctrl_handler);
+
+ switch (ctrl->id) {
+ case V4L2_CID_STATELESS_VP9_FRAME:
+ ctx->bit_depth = ctrl->p_new.p_vp9_frame->bit_depth;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
.try_ctrl = hantro_try_ctrl,
};
@@ -332,6 +350,10 @@ static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
.s_ctrl = hantro_hevc_s_ctrl,
};
+static const struct v4l2_ctrl_ops hantro_vp9_ctrl_ops = {
+ .s_ctrl = hantro_vp9_s_ctrl,
+};
+
static const struct hantro_ctrl controls[] = {
{
.codec = HANTRO_JPEG_ENCODER,
@@ -478,6 +500,7 @@ static const struct hantro_ctrl controls[] = {
.codec = HANTRO_VP9_DECODER,
.cfg = {
.id = V4L2_CID_STATELESS_VP9_FRAME,
+ .ops = &hantro_vp9_ctrl_ops,
},
}, {
.codec = HANTRO_VP9_DECODER,
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 6/8] media: hantro: Store VP9 bit depth in context
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that we have proper infrastructure for postprocessing 10-bit
formats, store VP9 bit depth in context.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 6a51f39dde56..305090365e74 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -320,6 +320,24 @@ static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
return 0;
}
+static int hantro_vp9_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct hantro_ctx *ctx;
+
+ ctx = container_of(ctrl->handler,
+ struct hantro_ctx, ctrl_handler);
+
+ switch (ctrl->id) {
+ case V4L2_CID_STATELESS_VP9_FRAME:
+ ctx->bit_depth = ctrl->p_new.p_vp9_frame->bit_depth;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
.try_ctrl = hantro_try_ctrl,
};
@@ -332,6 +350,10 @@ static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
.s_ctrl = hantro_hevc_s_ctrl,
};
+static const struct v4l2_ctrl_ops hantro_vp9_ctrl_ops = {
+ .s_ctrl = hantro_vp9_s_ctrl,
+};
+
static const struct hantro_ctrl controls[] = {
{
.codec = HANTRO_JPEG_ENCODER,
@@ -478,6 +500,7 @@ static const struct hantro_ctrl controls[] = {
.codec = HANTRO_VP9_DECODER,
.cfg = {
.id = V4L2_CID_STATELESS_VP9_FRAME,
+ .ops = &hantro_vp9_ctrl_ops,
},
}, {
.codec = HANTRO_VP9_DECODER,
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 6/8] media: hantro: Store VP9 bit depth in context
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that we have proper infrastructure for postprocessing 10-bit
formats, store VP9 bit depth in context.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 6a51f39dde56..305090365e74 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -320,6 +320,24 @@ static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
return 0;
}
+static int hantro_vp9_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct hantro_ctx *ctx;
+
+ ctx = container_of(ctrl->handler,
+ struct hantro_ctx, ctrl_handler);
+
+ switch (ctrl->id) {
+ case V4L2_CID_STATELESS_VP9_FRAME:
+ ctx->bit_depth = ctrl->p_new.p_vp9_frame->bit_depth;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
.try_ctrl = hantro_try_ctrl,
};
@@ -332,6 +350,10 @@ static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
.s_ctrl = hantro_hevc_s_ctrl,
};
+static const struct v4l2_ctrl_ops hantro_vp9_ctrl_ops = {
+ .s_ctrl = hantro_vp9_s_ctrl,
+};
+
static const struct hantro_ctrl controls[] = {
{
.codec = HANTRO_JPEG_ENCODER,
@@ -478,6 +500,7 @@ static const struct hantro_ctrl controls[] = {
.codec = HANTRO_VP9_DECODER,
.cfg = {
.id = V4L2_CID_STATELESS_VP9_FRAME,
+ .ops = &hantro_vp9_ctrl_ops,
},
}, {
.codec = HANTRO_VP9_DECODER,
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [RFC PATCH 7/8] media: hantro: sunxi: Enable 10-bit decoding
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that infrastructure for 10-bit decoding exists, enable it for
Allwinner H6.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index c0edd5856a0c..8d8a8937d6aa 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -15,12 +15,23 @@ static const struct hantro_fmt sunxi_vpu_postproc_fmts[] = {
.codec_mode = HANTRO_MODE_NONE,
.postprocessed = true,
},
+ {
+ .fourcc = V4L2_PIX_FMT_P010,
+ .codec_mode = HANTRO_MODE_NONE,
+ .postprocessed = true,
+ },
};
static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
{
.fourcc = V4L2_PIX_FMT_NV12_4L4,
.codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_P010_4L4,
+ .codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
},
{
.fourcc = V4L2_PIX_FMT_VP9_FRAME,
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 7/8] media: hantro: sunxi: Enable 10-bit decoding
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that infrastructure for 10-bit decoding exists, enable it for
Allwinner H6.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index c0edd5856a0c..8d8a8937d6aa 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -15,12 +15,23 @@ static const struct hantro_fmt sunxi_vpu_postproc_fmts[] = {
.codec_mode = HANTRO_MODE_NONE,
.postprocessed = true,
},
+ {
+ .fourcc = V4L2_PIX_FMT_P010,
+ .codec_mode = HANTRO_MODE_NONE,
+ .postprocessed = true,
+ },
};
static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
{
.fourcc = V4L2_PIX_FMT_NV12_4L4,
.codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_P010_4L4,
+ .codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
},
{
.fourcc = V4L2_PIX_FMT_VP9_FRAME,
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 7/8] media: hantro: sunxi: Enable 10-bit decoding
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
Now that infrastructure for 10-bit decoding exists, enable it for
Allwinner H6.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index c0edd5856a0c..8d8a8937d6aa 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -15,12 +15,23 @@ static const struct hantro_fmt sunxi_vpu_postproc_fmts[] = {
.codec_mode = HANTRO_MODE_NONE,
.postprocessed = true,
},
+ {
+ .fourcc = V4L2_PIX_FMT_P010,
+ .codec_mode = HANTRO_MODE_NONE,
+ .postprocessed = true,
+ },
};
static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
{
.fourcc = V4L2_PIX_FMT_NV12_4L4,
.codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_P010_4L4,
+ .codec_mode = HANTRO_MODE_NONE,
+ .match_depth = true,
},
{
.fourcc = V4L2_PIX_FMT_VP9_FRAME,
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [RFC PATCH 8/8] media: hantro: sunxi: Increase frequency
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 14:49 ` Jernej Skrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
It turns Android boxes use G2 core on much higher frequency. Let's match
that here too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index 8d8a8937d6aa..c86749c406fc 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -50,7 +50,7 @@ static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
static int sunxi_vpu_hw_init(struct hantro_dev *vpu)
{
- clk_set_rate(vpu->clocks[0].clk, 300000000);
+ clk_set_rate(vpu->clocks[0].clk, 576000000);
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 8/8] media: hantro: sunxi: Increase frequency
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
It turns Android boxes use G2 core on much higher frequency. Let's match
that here too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index 8d8a8937d6aa..c86749c406fc 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -50,7 +50,7 @@ static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
static int sunxi_vpu_hw_init(struct hantro_dev *vpu)
{
- clk_set_rate(vpu->clocks[0].clk, 300000000);
+ clk_set_rate(vpu->clocks[0].clk, 576000000);
return 0;
}
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 72+ messages in thread* [RFC PATCH 8/8] media: hantro: sunxi: Increase frequency
@ 2022-02-27 14:49 ` Jernej Skrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Skrabec @ 2022-02-27 14:49 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi, Jernej Skrabec
It turns Android boxes use G2 core on much higher frequency. Let's match
that here too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
---
drivers/staging/media/hantro/sunxi_vpu_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/sunxi_vpu_hw.c b/drivers/staging/media/hantro/sunxi_vpu_hw.c
index 8d8a8937d6aa..c86749c406fc 100644
--- a/drivers/staging/media/hantro/sunxi_vpu_hw.c
+++ b/drivers/staging/media/hantro/sunxi_vpu_hw.c
@@ -50,7 +50,7 @@ static const struct hantro_fmt sunxi_vpu_dec_fmts[] = {
static int sunxi_vpu_hw_init(struct hantro_dev *vpu)
{
- clk_set_rate(vpu->clocks[0].clk, 300000000);
+ clk_set_rate(vpu->clocks[0].clk, 576000000);
return 0;
}
--
2.35.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-02-27 17:03 ` Jernej Škrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-27 17:03 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne nedelja, 27. februar 2022 ob 15:49:18 CET je Jernej Skrabec napisal(a):
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
FYI, additional patch is needed for linear P010 output:
https://github.com/jernejsk/linux-1/commit/
28338c00749b821819690c9fd548fd5c311682b5
With that, only native format was not tested.
Regards,
Jernej
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
> --
> 2.35.1
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-02-27 17:03 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-27 17:03 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne nedelja, 27. februar 2022 ob 15:49:18 CET je Jernej Skrabec napisal(a):
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
FYI, additional patch is needed for linear P010 output:
https://github.com/jernejsk/linux-1/commit/
28338c00749b821819690c9fd548fd5c311682b5
With that, only native format was not tested.
Regards,
Jernej
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
> --
> 2.35.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-02-27 17:03 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-02-27 17:03 UTC (permalink / raw)
To: ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne nedelja, 27. februar 2022 ob 15:49:18 CET je Jernej Skrabec napisal(a):
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
FYI, additional patch is needed for linear P010 output:
https://github.com/jernejsk/linux-1/commit/
28338c00749b821819690c9fd548fd5c311682b5
With that, only native format was not tested.
Regards,
Jernej
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
> --
> 2.35.1
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-02-27 14:49 ` Jernej Skrabec
(?)
@ 2022-04-05 16:07 ` Benjamin Gaignard
-1 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:07 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
Hi Jernej,
I have create a branch to test this series with VP9 and HEVC:
https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx8m
Feel free to pick what I may need in it.
That doesn't improve fluster scores, I think more dev are still needed in GST
before getting something fully functional.
Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-05 16:07 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:07 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
Hi Jernej,
I have create a branch to test this series with VP9 and HEVC:
https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx8m
Feel free to pick what I may need in it.
That doesn't improve fluster scores, I think more dev are still needed in GST
before getting something fully functional.
Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-05 16:07 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-05 16:07 UTC (permalink / raw)
To: Jernej Skrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> First two patches add 10-bit formats to UAPI, third extends filtering
> mechanism, fourth fixes incorrect assumption, fifth moves register
> configuration code to proper place, sixth and seventh enable 10-bit
> VP9 decoding on Allwinner H6 and last increases core frequency on
> Allwinner H6.
>
> I'm sending this as RFC to get some comments:
> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> 2. is extended filtering mechanism ok?
>
> I would also like if these patches are tested on some more HW.
> Additionally, can someone test tiled P010?
>
> Please take a look.
Hi Jernej,
I have create a branch to test this series with VP9 and HEVC:
https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx8m
Feel free to pick what I may need in it.
That doesn't improve fluster scores, I think more dev are still needed in GST
before getting something fully functional.
Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
> Ezequiel Garcia (1):
> media: Add P010 tiled format
>
> Jernej Skrabec (7):
> media: Add P010 format
> media: hantro: Support format filtering by depth
> media: hantro: postproc: Fix buffer size calculation
> media: hantro: postproc: Fix legacy regs configuration
> media: hantro: Store VP9 bit depth in context
> media: hantro: sunxi: Enable 10-bit decoding
> media: hantro: sunxi: Increase frequency
>
> drivers/media/v4l2-core/v4l2-common.c | 3 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
> drivers/staging/media/hantro/hantro.h | 4 ++
> drivers/staging/media/hantro/hantro_drv.c | 23 +++++++++
> .../staging/media/hantro/hantro_g2_vp9_dec.c | 8 ---
> .../staging/media/hantro/hantro_postproc.c | 34 ++++++++++---
> drivers/staging/media/hantro/hantro_v4l2.c | 50 +++++++++++++++++--
> drivers/staging/media/hantro/hantro_v4l2.h | 3 ++
> drivers/staging/media/hantro/sunxi_vpu_hw.c | 13 ++++-
> include/uapi/linux/videodev2.h | 2 +
> 10 files changed, 122 insertions(+), 20 deletions(-)
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-04-05 16:07 ` Benjamin Gaignard
(?)
@ 2022-04-05 18:40 ` Jernej Škrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:40 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Benjamin!
Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > First two patches add 10-bit formats to UAPI, third extends filtering
> > mechanism, fourth fixes incorrect assumption, fifth moves register
> > configuration code to proper place, sixth and seventh enable 10-bit
> > VP9 decoding on Allwinner H6 and last increases core frequency on
> > Allwinner H6.
> >
> > I'm sending this as RFC to get some comments:
> > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > 2. is extended filtering mechanism ok?
> >
> > I would also like if these patches are tested on some more HW.
> > Additionally, can someone test tiled P010?
> >
> > Please take a look.
>
> Hi Jernej,
>
> I have create a branch to test this series with VP9 and HEVC:
> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
> 8m Feel free to pick what I may need in it.
>
> That doesn't improve fluster scores, I think more dev are still needed in
> GST before getting something fully functional.
> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
What kind of improvements do you expect? Actually, this series is designed to
change nothing for platforms, where 10-bit format is not added into the list
of supported formats. I think reasons are quite obvious. First, not every
device may support 10-bit output. Second, as you might already figured it out,
registers in this series are set only for legacy cores. I have no idea, what
needs to be done for newer ones, since I don't have them. Anyway, I tested
this with fluster and only one additional test passes, because it is the only
one for 10-bit YUV420.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-05 18:40 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:40 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Benjamin!
Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > First two patches add 10-bit formats to UAPI, third extends filtering
> > mechanism, fourth fixes incorrect assumption, fifth moves register
> > configuration code to proper place, sixth and seventh enable 10-bit
> > VP9 decoding on Allwinner H6 and last increases core frequency on
> > Allwinner H6.
> >
> > I'm sending this as RFC to get some comments:
> > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > 2. is extended filtering mechanism ok?
> >
> > I would also like if these patches are tested on some more HW.
> > Additionally, can someone test tiled P010?
> >
> > Please take a look.
>
> Hi Jernej,
>
> I have create a branch to test this series with VP9 and HEVC:
> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
> 8m Feel free to pick what I may need in it.
>
> That doesn't improve fluster scores, I think more dev are still needed in
> GST before getting something fully functional.
> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
What kind of improvements do you expect? Actually, this series is designed to
change nothing for platforms, where 10-bit format is not added into the list
of supported formats. I think reasons are quite obvious. First, not every
device may support 10-bit output. Second, as you might already figured it out,
registers in this series are set only for legacy cores. I have no idea, what
needs to be done for newer ones, since I don't have them. Anyway, I tested
this with fluster and only one additional test passes, because it is the only
one for 10-bit YUV420.
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-05 18:40 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-05 18:40 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Hi Benjamin!
Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > First two patches add 10-bit formats to UAPI, third extends filtering
> > mechanism, fourth fixes incorrect assumption, fifth moves register
> > configuration code to proper place, sixth and seventh enable 10-bit
> > VP9 decoding on Allwinner H6 and last increases core frequency on
> > Allwinner H6.
> >
> > I'm sending this as RFC to get some comments:
> > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > 2. is extended filtering mechanism ok?
> >
> > I would also like if these patches are tested on some more HW.
> > Additionally, can someone test tiled P010?
> >
> > Please take a look.
>
> Hi Jernej,
>
> I have create a branch to test this series with VP9 and HEVC:
> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
> 8m Feel free to pick what I may need in it.
>
> That doesn't improve fluster scores, I think more dev are still needed in
> GST before getting something fully functional.
> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
What kind of improvements do you expect? Actually, this series is designed to
change nothing for platforms, where 10-bit format is not added into the list
of supported formats. I think reasons are quite obvious. First, not every
device may support 10-bit output. Second, as you might already figured it out,
registers in this series are set only for legacy cores. I have no idea, what
needs to be done for newer ones, since I don't have them. Anyway, I tested
this with fluster and only one additional test passes, because it is the only
one for 10-bit YUV420.
Best regards,
Jernej
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-04-05 18:40 ` Jernej Škrabec
(?)
@ 2022-04-06 6:54 ` Benjamin Gaignard
-1 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-06 6:54 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> Hi Benjamin!
>
> Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
>> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
>>> First two patches add 10-bit formats to UAPI, third extends filtering
>>> mechanism, fourth fixes incorrect assumption, fifth moves register
>>> configuration code to proper place, sixth and seventh enable 10-bit
>>> VP9 decoding on Allwinner H6 and last increases core frequency on
>>> Allwinner H6.
>>>
>>> I'm sending this as RFC to get some comments:
>>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
>>> 2. is extended filtering mechanism ok?
>>>
>>> I would also like if these patches are tested on some more HW.
>>> Additionally, can someone test tiled P010?
>>>
>>> Please take a look.
>> Hi Jernej,
>>
>> I have create a branch to test this series with VP9 and HEVC:
>> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
>> 8m Feel free to pick what I may need in it.
>>
>> That doesn't improve fluster scores, I think more dev are still needed in
>> GST before getting something fully functional.
>> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
> What kind of improvements do you expect? Actually, this series is designed to
> change nothing for platforms, where 10-bit format is not added into the list
> of supported formats. I think reasons are quite obvious. First, not every
> device may support 10-bit output. Second, as you might already figured it out,
> registers in this series are set only for legacy cores. I have no idea, what
> needs to be done for newer ones, since I don't have them. Anyway, I tested
> this with fluster and only one additional test passes, because it is the only
> one for 10-bit YUV420.
In this series you will find that I have added the registers for the new cores,
fix hevc to be able to use 10-bit, and enable that in IMX8M.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 6:54 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-06 6:54 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> Hi Benjamin!
>
> Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
>> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
>>> First two patches add 10-bit formats to UAPI, third extends filtering
>>> mechanism, fourth fixes incorrect assumption, fifth moves register
>>> configuration code to proper place, sixth and seventh enable 10-bit
>>> VP9 decoding on Allwinner H6 and last increases core frequency on
>>> Allwinner H6.
>>>
>>> I'm sending this as RFC to get some comments:
>>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
>>> 2. is extended filtering mechanism ok?
>>>
>>> I would also like if these patches are tested on some more HW.
>>> Additionally, can someone test tiled P010?
>>>
>>> Please take a look.
>> Hi Jernej,
>>
>> I have create a branch to test this series with VP9 and HEVC:
>> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
>> 8m Feel free to pick what I may need in it.
>>
>> That doesn't improve fluster scores, I think more dev are still needed in
>> GST before getting something fully functional.
>> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
> What kind of improvements do you expect? Actually, this series is designed to
> change nothing for platforms, where 10-bit format is not added into the list
> of supported formats. I think reasons are quite obvious. First, not every
> device may support 10-bit output. Second, as you might already figured it out,
> registers in this series are set only for legacy cores. I have no idea, what
> needs to be done for newer ones, since I don't have them. Anyway, I tested
> this with fluster and only one additional test passes, because it is the only
> one for 10-bit YUV420.
In this series you will find that I have added the registers for the new cores,
fix hevc to be able to use 10-bit, and enable that in IMX8M.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 6:54 ` Benjamin Gaignard
0 siblings, 0 replies; 72+ messages in thread
From: Benjamin Gaignard @ 2022-04-06 6:54 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> Hi Benjamin!
>
> Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard napisal(a):
>> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
>>> First two patches add 10-bit formats to UAPI, third extends filtering
>>> mechanism, fourth fixes incorrect assumption, fifth moves register
>>> configuration code to proper place, sixth and seventh enable 10-bit
>>> VP9 decoding on Allwinner H6 and last increases core frequency on
>>> Allwinner H6.
>>>
>>> I'm sending this as RFC to get some comments:
>>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
>>> 2. is extended filtering mechanism ok?
>>>
>>> I would also like if these patches are tested on some more HW.
>>> Additionally, can someone test tiled P010?
>>>
>>> Please take a look.
>> Hi Jernej,
>>
>> I have create a branch to test this series with VP9 and HEVC:
>> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_imx
>> 8m Feel free to pick what I may need in it.
>>
>> That doesn't improve fluster scores, I think more dev are still needed in
>> GST before getting something fully functional.
>> Anyway I able to select P010 pixel format if the input is a 10bit bitstream.
> What kind of improvements do you expect? Actually, this series is designed to
> change nothing for platforms, where 10-bit format is not added into the list
> of supported formats. I think reasons are quite obvious. First, not every
> device may support 10-bit output. Second, as you might already figured it out,
> registers in this series are set only for legacy cores. I have no idea, what
> needs to be done for newer ones, since I don't have them. Anyway, I tested
> this with fluster and only one additional test passes, because it is the only
> one for 10-bit YUV420.
In this series you will find that I have added the registers for the new cores,
fix hevc to be able to use 10-bit, and enable that in IMX8M.
Regards,
Benjamin
>
> Best regards,
> Jernej
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-04-06 6:54 ` Benjamin Gaignard
(?)
@ 2022-04-06 17:21 ` Jernej Škrabec
-1 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-06 17:21 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > Hi Benjamin!
> >
> > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
napisal(a):
> >> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> >>> First two patches add 10-bit formats to UAPI, third extends filtering
> >>> mechanism, fourth fixes incorrect assumption, fifth moves register
> >>> configuration code to proper place, sixth and seventh enable 10-bit
> >>> VP9 decoding on Allwinner H6 and last increases core frequency on
> >>> Allwinner H6.
> >>>
> >>> I'm sending this as RFC to get some comments:
> >>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> >>> 2. is extended filtering mechanism ok?
> >>>
> >>> I would also like if these patches are tested on some more HW.
> >>> Additionally, can someone test tiled P010?
> >>>
> >>> Please take a look.
> >>
> >> Hi Jernej,
> >>
> >> I have create a branch to test this series with VP9 and HEVC:
> >> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> >> imx 8m Feel free to pick what I may need in it.
> >>
> >> That doesn't improve fluster scores, I think more dev are still needed in
> >> GST before getting something fully functional.
> >> Anyway I able to select P010 pixel format if the input is a 10bit
> >> bitstream.>
> > What kind of improvements do you expect? Actually, this series is designed
> > to change nothing for platforms, where 10-bit format is not added into
> > the list of supported formats. I think reasons are quite obvious. First,
> > not every device may support 10-bit output. Second, as you might already
> > figured it out, registers in this series are set only for legacy cores. I
> > have no idea, what needs to be done for newer ones, since I don't have
> > them. Anyway, I tested this with fluster and only one additional test
> > passes, because it is the only one for 10-bit YUV420.
>
> In this series you will find that I have added the registers for the new
> cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
Your changes seems reasonable, but at this point I wouldn't bother with
fluster. Instead, try to test with one specific bitstream or even a sample video
file. I just tested with one random 10-bit VP9 video that I found when working
on this series. That way you avoid any corner cases which sometimes plaque
fluster testing (reference bitstreams smaller than min. supported size).
Anyway, re-check vendor lib if there is any other place to adjust something
for 10-bit.
Best regards,
Jernej
>
> Regards,
> Benjamin
>
> > Best regards,
> > Jernej
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 17:21 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-06 17:21 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > Hi Benjamin!
> >
> > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
napisal(a):
> >> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> >>> First two patches add 10-bit formats to UAPI, third extends filtering
> >>> mechanism, fourth fixes incorrect assumption, fifth moves register
> >>> configuration code to proper place, sixth and seventh enable 10-bit
> >>> VP9 decoding on Allwinner H6 and last increases core frequency on
> >>> Allwinner H6.
> >>>
> >>> I'm sending this as RFC to get some comments:
> >>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> >>> 2. is extended filtering mechanism ok?
> >>>
> >>> I would also like if these patches are tested on some more HW.
> >>> Additionally, can someone test tiled P010?
> >>>
> >>> Please take a look.
> >>
> >> Hi Jernej,
> >>
> >> I have create a branch to test this series with VP9 and HEVC:
> >> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> >> imx 8m Feel free to pick what I may need in it.
> >>
> >> That doesn't improve fluster scores, I think more dev are still needed in
> >> GST before getting something fully functional.
> >> Anyway I able to select P010 pixel format if the input is a 10bit
> >> bitstream.>
> > What kind of improvements do you expect? Actually, this series is designed
> > to change nothing for platforms, where 10-bit format is not added into
> > the list of supported formats. I think reasons are quite obvious. First,
> > not every device may support 10-bit output. Second, as you might already
> > figured it out, registers in this series are set only for legacy cores. I
> > have no idea, what needs to be done for newer ones, since I don't have
> > them. Anyway, I tested this with fluster and only one additional test
> > passes, because it is the only one for 10-bit YUV420.
>
> In this series you will find that I have added the registers for the new
> cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
Your changes seems reasonable, but at this point I wouldn't bother with
fluster. Instead, try to test with one specific bitstream or even a sample video
file. I just tested with one random 10-bit VP9 video that I found when working
on this series. That way you avoid any corner cases which sometimes plaque
fluster testing (reference bitstreams smaller than min. supported size).
Anyway, re-check vendor lib if there is any other place to adjust something
for 10-bit.
Best regards,
Jernej
>
> Regards,
> Benjamin
>
> > Best regards,
> > Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 17:21 ` Jernej Škrabec
0 siblings, 0 replies; 72+ messages in thread
From: Jernej Škrabec @ 2022-04-06 17:21 UTC (permalink / raw)
To: ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, nicolas, hverkuil-cisco, gregkh, wens, samuel,
linux-media, linux-kernel, linux-rockchip, linux-staging,
linux-arm-kernel, linux-sunxi
Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > Hi Benjamin!
> >
> > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
napisal(a):
> >> Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> >>> First two patches add 10-bit formats to UAPI, third extends filtering
> >>> mechanism, fourth fixes incorrect assumption, fifth moves register
> >>> configuration code to proper place, sixth and seventh enable 10-bit
> >>> VP9 decoding on Allwinner H6 and last increases core frequency on
> >>> Allwinner H6.
> >>>
> >>> I'm sending this as RFC to get some comments:
> >>> 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> >>> 2. is extended filtering mechanism ok?
> >>>
> >>> I would also like if these patches are tested on some more HW.
> >>> Additionally, can someone test tiled P010?
> >>>
> >>> Please take a look.
> >>
> >> Hi Jernej,
> >>
> >> I have create a branch to test this series with VP9 and HEVC:
> >> https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> >> imx 8m Feel free to pick what I may need in it.
> >>
> >> That doesn't improve fluster scores, I think more dev are still needed in
> >> GST before getting something fully functional.
> >> Anyway I able to select P010 pixel format if the input is a 10bit
> >> bitstream.>
> > What kind of improvements do you expect? Actually, this series is designed
> > to change nothing for platforms, where 10-bit format is not added into
> > the list of supported formats. I think reasons are quite obvious. First,
> > not every device may support 10-bit output. Second, as you might already
> > figured it out, registers in this series are set only for legacy cores. I
> > have no idea, what needs to be done for newer ones, since I don't have
> > them. Anyway, I tested this with fluster and only one additional test
> > passes, because it is the only one for 10-bit YUV420.
>
> In this series you will find that I have added the registers for the new
> cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
Your changes seems reasonable, but at this point I wouldn't bother with
fluster. Instead, try to test with one specific bitstream or even a sample video
file. I just tested with one random 10-bit VP9 video that I found when working
on this series. That way you avoid any corner cases which sometimes plaque
fluster testing (reference bitstreams smaller than min. supported size).
Anyway, re-check vendor lib if there is any other place to adjust something
for 10-bit.
Best regards,
Jernej
>
> Regards,
> Benjamin
>
> > Best regards,
> > Jernej
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
2022-04-06 17:21 ` Jernej Škrabec
(?)
@ 2022-04-06 17:50 ` Nicolas Dufresne
-1 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-04-06 17:50 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le mercredi 06 avril 2022 à 19:21 +0200, Jernej Škrabec a écrit :
> Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> > Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > > Hi Benjamin!
> > >
> > > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
> napisal(a):
> > > > Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > > > > First two patches add 10-bit formats to UAPI, third extends filtering
> > > > > mechanism, fourth fixes incorrect assumption, fifth moves register
> > > > > configuration code to proper place, sixth and seventh enable 10-bit
> > > > > VP9 decoding on Allwinner H6 and last increases core frequency on
> > > > > Allwinner H6.
> > > > >
> > > > > I'm sending this as RFC to get some comments:
> > > > > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > > > > 2. is extended filtering mechanism ok?
> > > > >
> > > > > I would also like if these patches are tested on some more HW.
> > > > > Additionally, can someone test tiled P010?
> > > > >
> > > > > Please take a look.
> > > >
> > > > Hi Jernej,
> > > >
> > > > I have create a branch to test this series with VP9 and HEVC:
> > > > https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> > > > imx 8m Feel free to pick what I may need in it.
> > > >
> > > > That doesn't improve fluster scores, I think more dev are still needed in
> > > > GST before getting something fully functional.
> > > > Anyway I able to select P010 pixel format if the input is a 10bit
> > > > bitstream.>
> > > What kind of improvements do you expect? Actually, this series is designed
> > > to change nothing for platforms, where 10-bit format is not added into
> > > the list of supported formats. I think reasons are quite obvious. First,
> > > not every device may support 10-bit output. Second, as you might already
> > > figured it out, registers in this series are set only for legacy cores. I
> > > have no idea, what needs to be done for newer ones, since I don't have
> > > them. Anyway, I tested this with fluster and only one additional test
> > > passes, because it is the only one for 10-bit YUV420.
> >
> > In this series you will find that I have added the registers for the new
> > cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
>
> Your changes seems reasonable, but at this point I wouldn't bother with
> fluster. Instead, try to test with one specific bitstream or even a sample video
> file. I just tested with one random 10-bit VP9 video that I found when working
> on this series. That way you avoid any corner cases which sometimes plaque
> fluster testing (reference bitstreams smaller than min. supported size).
> Anyway, re-check vendor lib if there is any other place to adjust something
> for 10-bit.
Just so we don't forget, there is a handful of 10bit tests that Daniel Almeida
omitted when he added tests to fluster (though only 1 is 420). I will try and
fix that later on. There is otherwise 5G worth of 10bit tests available. In
fluster we decided to go for the same subset libvpx uses, otherwise no one would
ever want to download these tests.
https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_2_10bit.
About the "min supported", G2 VP9 scores is 157/303 here (in comparision rkvdec
is 225, and MTK VCODEC 275). At this failure level this has no longer anything
to do with the size of the render. There is likely couple of bugs hidden in the
driver for the corner cases tested by the suite. Also, to illustrate that the
size isn't the only variable in the failures, we have a vp90-2-02-size-
64x34.webm that pass (the driver pretends that 64x64 is the minimum). I didn't
look at G2 output very closely, but on RKVDEC, in similar failures we have
perfect keyframe, and a single corrupted tile on the following decode. My belief
is that there is bugs in the drivers to be found and fixed. In absence of vendor
support, or working reference it will be difficult / near impossible to fix, but
I'm documenting this so we stop thinking this is just "not supported".
cheers,
Nicolas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 17:50 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-04-06 17:50 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le mercredi 06 avril 2022 à 19:21 +0200, Jernej Škrabec a écrit :
> Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> > Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > > Hi Benjamin!
> > >
> > > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
> napisal(a):
> > > > Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > > > > First two patches add 10-bit formats to UAPI, third extends filtering
> > > > > mechanism, fourth fixes incorrect assumption, fifth moves register
> > > > > configuration code to proper place, sixth and seventh enable 10-bit
> > > > > VP9 decoding on Allwinner H6 and last increases core frequency on
> > > > > Allwinner H6.
> > > > >
> > > > > I'm sending this as RFC to get some comments:
> > > > > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > > > > 2. is extended filtering mechanism ok?
> > > > >
> > > > > I would also like if these patches are tested on some more HW.
> > > > > Additionally, can someone test tiled P010?
> > > > >
> > > > > Please take a look.
> > > >
> > > > Hi Jernej,
> > > >
> > > > I have create a branch to test this series with VP9 and HEVC:
> > > > https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> > > > imx 8m Feel free to pick what I may need in it.
> > > >
> > > > That doesn't improve fluster scores, I think more dev are still needed in
> > > > GST before getting something fully functional.
> > > > Anyway I able to select P010 pixel format if the input is a 10bit
> > > > bitstream.>
> > > What kind of improvements do you expect? Actually, this series is designed
> > > to change nothing for platforms, where 10-bit format is not added into
> > > the list of supported formats. I think reasons are quite obvious. First,
> > > not every device may support 10-bit output. Second, as you might already
> > > figured it out, registers in this series are set only for legacy cores. I
> > > have no idea, what needs to be done for newer ones, since I don't have
> > > them. Anyway, I tested this with fluster and only one additional test
> > > passes, because it is the only one for 10-bit YUV420.
> >
> > In this series you will find that I have added the registers for the new
> > cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
>
> Your changes seems reasonable, but at this point I wouldn't bother with
> fluster. Instead, try to test with one specific bitstream or even a sample video
> file. I just tested with one random 10-bit VP9 video that I found when working
> on this series. That way you avoid any corner cases which sometimes plaque
> fluster testing (reference bitstreams smaller than min. supported size).
> Anyway, re-check vendor lib if there is any other place to adjust something
> for 10-bit.
Just so we don't forget, there is a handful of 10bit tests that Daniel Almeida
omitted when he added tests to fluster (though only 1 is 420). I will try and
fix that later on. There is otherwise 5G worth of 10bit tests available. In
fluster we decided to go for the same subset libvpx uses, otherwise no one would
ever want to download these tests.
https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_2_10bit.
About the "min supported", G2 VP9 scores is 157/303 here (in comparision rkvdec
is 225, and MTK VCODEC 275). At this failure level this has no longer anything
to do with the size of the render. There is likely couple of bugs hidden in the
driver for the corner cases tested by the suite. Also, to illustrate that the
size isn't the only variable in the failures, we have a vp90-2-02-size-
64x34.webm that pass (the driver pretends that 64x64 is the minimum). I didn't
look at G2 output very closely, but on RKVDEC, in similar failures we have
perfect keyframe, and a single corrupted tile on the following decode. My belief
is that there is bugs in the drivers to be found and fixed. In absence of vendor
support, or working reference it will be difficult / near impossible to fix, but
I'm documenting this so we stop thinking this is just "not supported".
cheers,
Nicolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [RFC PATCH 0/8] media: hantro: Add 10-bit support
@ 2022-04-06 17:50 ` Nicolas Dufresne
0 siblings, 0 replies; 72+ messages in thread
From: Nicolas Dufresne @ 2022-04-06 17:50 UTC (permalink / raw)
To: Jernej Škrabec, ezequiel, p.zabel, Benjamin Gaignard
Cc: mchehab, hverkuil-cisco, gregkh, wens, samuel, linux-media,
linux-kernel, linux-rockchip, linux-staging, linux-arm-kernel,
linux-sunxi
Le mercredi 06 avril 2022 à 19:21 +0200, Jernej Škrabec a écrit :
> Dne sreda, 06. april 2022 ob 08:54:07 CEST je Benjamin Gaignard napisal(a):
> > Le 05/04/2022 à 20:40, Jernej Škrabec a écrit :
> > > Hi Benjamin!
> > >
> > > Dne torek, 05. april 2022 ob 18:07:41 CEST je Benjamin Gaignard
> napisal(a):
> > > > Le 27/02/2022 à 15:49, Jernej Skrabec a écrit :
> > > > > First two patches add 10-bit formats to UAPI, third extends filtering
> > > > > mechanism, fourth fixes incorrect assumption, fifth moves register
> > > > > configuration code to proper place, sixth and seventh enable 10-bit
> > > > > VP9 decoding on Allwinner H6 and last increases core frequency on
> > > > > Allwinner H6.
> > > > >
> > > > > I'm sending this as RFC to get some comments:
> > > > > 1. format definitions - are fourcc's ok? are comments/descriptions ok?
> > > > > 2. is extended filtering mechanism ok?
> > > > >
> > > > > I would also like if these patches are tested on some more HW.
> > > > > Additionally, can someone test tiled P010?
> > > > >
> > > > > Please take a look.
> > > >
> > > > Hi Jernej,
> > > >
> > > > I have create a branch to test this series with VP9 and HEVC:
> > > > https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/tree/10bit_
> > > > imx 8m Feel free to pick what I may need in it.
> > > >
> > > > That doesn't improve fluster scores, I think more dev are still needed in
> > > > GST before getting something fully functional.
> > > > Anyway I able to select P010 pixel format if the input is a 10bit
> > > > bitstream.>
> > > What kind of improvements do you expect? Actually, this series is designed
> > > to change nothing for platforms, where 10-bit format is not added into
> > > the list of supported formats. I think reasons are quite obvious. First,
> > > not every device may support 10-bit output. Second, as you might already
> > > figured it out, registers in this series are set only for legacy cores. I
> > > have no idea, what needs to be done for newer ones, since I don't have
> > > them. Anyway, I tested this with fluster and only one additional test
> > > passes, because it is the only one for 10-bit YUV420.
> >
> > In this series you will find that I have added the registers for the new
> > cores, fix hevc to be able to use 10-bit, and enable that in IMX8M.
>
> Your changes seems reasonable, but at this point I wouldn't bother with
> fluster. Instead, try to test with one specific bitstream or even a sample video
> file. I just tested with one random 10-bit VP9 video that I found when working
> on this series. That way you avoid any corner cases which sometimes plaque
> fluster testing (reference bitstreams smaller than min. supported size).
> Anyway, re-check vendor lib if there is any other place to adjust something
> for 10-bit.
Just so we don't forget, there is a handful of 10bit tests that Daniel Almeida
omitted when he added tests to fluster (though only 1 is 420). I will try and
fix that later on. There is otherwise 5G worth of 10bit tests available. In
fluster we decided to go for the same subset libvpx uses, otherwise no one would
ever want to download these tests.
https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_2_10bit.
About the "min supported", G2 VP9 scores is 157/303 here (in comparision rkvdec
is 225, and MTK VCODEC 275). At this failure level this has no longer anything
to do with the size of the render. There is likely couple of bugs hidden in the
driver for the corner cases tested by the suite. Also, to illustrate that the
size isn't the only variable in the failures, we have a vp90-2-02-size-
64x34.webm that pass (the driver pretends that 64x64 is the minimum). I didn't
look at G2 output very closely, but on RKVDEC, in similar failures we have
perfect keyframe, and a single corrupted tile on the following decode. My belief
is that there is bugs in the drivers to be found and fixed. In absence of vendor
support, or working reference it will be difficult / near impossible to fix, but
I'm documenting this so we stop thinking this is just "not supported".
cheers,
Nicolas
^ permalink raw reply [flat|nested] 72+ messages in thread