All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go)
@ 2021-06-24 18:26 ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

This series adds support for H.264 decoding on the PX30, RK3328
and RK3326 platforms, enabling the VDPU2 core.

Given it's tested on the Odroid Advance Go, patches 1 and 2
add the basic support to report the panel orientation to
userspace (Heiko, if you like them, feel free to pick them).
Weston (for instance) picks up the orientation automagically
and rotates the render.

Patches 3 and 4 are just low-hanging fruit that was on my backlog.

Patches 5, 6 and 7 add some helpers to avoid duplicating some processes
between Hantro G1 and VDPU2. Patches 8 and 9 enable the VDPU2 H.264.
The implementation is based on a patch from Jonas Karlman [1], which
I forwarded ported to mainline.

Finally, patches 10 to 12 add support for the VPU on Rockchip PX30 SoCs.
These patches are based on patches submitted by Paul Kocialkowski [2],
which I ported and adjusted a bit.

Tested on i.MX8MQ EVK and RK3326 Odroid Advance Go, the latter
is able to decode a 1080p sample at ~100fps nicely.

Fluster conformance testing is looking good as well, and producing
expected results:

RK3326:
  Ran 135 tests in 480.067s
  FAILED (failures=9, errors=54)

i.MX8MQ:
  Ran 135 tests in 337.491s
  FAILED (failures=9, errors=54)

[1] https://lore.kernel.org/linux-media/HE1PR06MB40119DE07D38060F531D1070ACBF0@HE1PR06MB4011.eurprd06.prod.outlook.com/
[2] https://lore.kernel.org/patchwork/cover/1361795/

Ezequiel Garcia (8):
  drm/panel: kd35t133: Add panel orientation support
  arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
  hantro: vp8: Move noisy WARN_ON to vpu_debug
  hantro: Make struct hantro_variant.init() optional
  media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
  media: hantro: h264: Move DPB valid and long-term bitmaps
  media: hantro: h264: Move reference picture number to a helper
  media: hantro: Enable H.264 on Rockchip VDPU2

Jonas Karlman (1):
  media: hantro: Add H.264 support for Rockchip VDPU2

Paul Kocialkowski (3):
  dt-bindings: media: rockchip-vpu: Add PX30 compatible
  arm64: dts: rockchip: Add VPU support for the PX30
  media: hantro: Add support for the Rockchip PX30

 .../bindings/media/rockchip-vpu.yaml          |   3 +
 arch/arm64/boot/dts/rockchip/px30.dtsi        |  23 +
 .../boot/dts/rockchip/rk3326-odroid-go2.dts   |   1 +
 drivers/gpu/drm/panel/panel-elida-kd35t133.c  |   8 +
 drivers/staging/media/hantro/Makefile         |   1 +
 drivers/staging/media/hantro/hantro.h         |   4 +-
 drivers/staging/media/hantro/hantro_drv.c     |  11 +-
 .../staging/media/hantro/hantro_g1_h264_dec.c |  48 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |  31 +-
 drivers/staging/media/hantro/hantro_h264.c    |  24 +
 drivers/staging/media/hantro/hantro_hw.h      |   8 +
 .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
 .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   |  32 +-
 .../staging/media/hantro/rockchip_vpu_hw.c    |  54 +-
 .../staging/media/hantro/sama5d4_vdec_hw.c    |   6 -
 15 files changed, 671 insertions(+), 74 deletions(-)
 create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c

-- 
2.30.0


^ permalink raw reply	[flat|nested] 54+ messages in thread

* [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go)
@ 2021-06-24 18:26 ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

This series adds support for H.264 decoding on the PX30, RK3328
and RK3326 platforms, enabling the VDPU2 core.

Given it's tested on the Odroid Advance Go, patches 1 and 2
add the basic support to report the panel orientation to
userspace (Heiko, if you like them, feel free to pick them).
Weston (for instance) picks up the orientation automagically
and rotates the render.

Patches 3 and 4 are just low-hanging fruit that was on my backlog.

Patches 5, 6 and 7 add some helpers to avoid duplicating some processes
between Hantro G1 and VDPU2. Patches 8 and 9 enable the VDPU2 H.264.
The implementation is based on a patch from Jonas Karlman [1], which
I forwarded ported to mainline.

Finally, patches 10 to 12 add support for the VPU on Rockchip PX30 SoCs.
These patches are based on patches submitted by Paul Kocialkowski [2],
which I ported and adjusted a bit.

Tested on i.MX8MQ EVK and RK3326 Odroid Advance Go, the latter
is able to decode a 1080p sample at ~100fps nicely.

Fluster conformance testing is looking good as well, and producing
expected results:

RK3326:
  Ran 135 tests in 480.067s
  FAILED (failures=9, errors=54)

i.MX8MQ:
  Ran 135 tests in 337.491s
  FAILED (failures=9, errors=54)

[1] https://lore.kernel.org/linux-media/HE1PR06MB40119DE07D38060F531D1070ACBF0@HE1PR06MB4011.eurprd06.prod.outlook.com/
[2] https://lore.kernel.org/patchwork/cover/1361795/

Ezequiel Garcia (8):
  drm/panel: kd35t133: Add panel orientation support
  arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
  hantro: vp8: Move noisy WARN_ON to vpu_debug
  hantro: Make struct hantro_variant.init() optional
  media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
  media: hantro: h264: Move DPB valid and long-term bitmaps
  media: hantro: h264: Move reference picture number to a helper
  media: hantro: Enable H.264 on Rockchip VDPU2

Jonas Karlman (1):
  media: hantro: Add H.264 support for Rockchip VDPU2

Paul Kocialkowski (3):
  dt-bindings: media: rockchip-vpu: Add PX30 compatible
  arm64: dts: rockchip: Add VPU support for the PX30
  media: hantro: Add support for the Rockchip PX30

 .../bindings/media/rockchip-vpu.yaml          |   3 +
 arch/arm64/boot/dts/rockchip/px30.dtsi        |  23 +
 .../boot/dts/rockchip/rk3326-odroid-go2.dts   |   1 +
 drivers/gpu/drm/panel/panel-elida-kd35t133.c  |   8 +
 drivers/staging/media/hantro/Makefile         |   1 +
 drivers/staging/media/hantro/hantro.h         |   4 +-
 drivers/staging/media/hantro/hantro_drv.c     |  11 +-
 .../staging/media/hantro/hantro_g1_h264_dec.c |  48 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |  31 +-
 drivers/staging/media/hantro/hantro_h264.c    |  24 +
 drivers/staging/media/hantro/hantro_hw.h      |   8 +
 .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
 .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   |  32 +-
 .../staging/media/hantro/rockchip_vpu_hw.c    |  54 +-
 .../staging/media/hantro/sama5d4_vdec_hw.c    |   6 -
 15 files changed, 671 insertions(+), 74 deletions(-)
 create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c

-- 
2.30.0


^ permalink raw reply	[flat|nested] 54+ messages in thread

* [PATCH 01/12] drm/panel: kd35t133: Add panel orientation support
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

Parse the device tree rotation specifier, and set a DRM
connector orientation property. The property can then be read
by compositors to apply hardware plane rotation or a GPU transform.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index fe5ac3ef9018..5987d28c874c 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -39,6 +39,7 @@
 struct kd35t133 {
 	struct device *dev;
 	struct drm_panel panel;
+	enum drm_panel_orientation orientation;
 	struct gpio_desc *reset_gpio;
 	struct regulator *vdd;
 	struct regulator *iovcc;
@@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
 	connector->display_info.width_mm = mode->width_mm;
 	connector->display_info.height_mm = mode->height_mm;
 	drm_mode_probed_add(connector, mode);
+	drm_connector_set_panel_orientation(connector, ctx->orientation);
 
 	return 1;
 }
@@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
 		return ret;
 	}
 
+	ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
+	if (ret) {
+		dev_err(dev, "%pOF: failed to get orientation %d\n", dev->of_node, ret);
+		return ret;
+	}
+
 	mipi_dsi_set_drvdata(dsi, ctx);
 
 	ctx->dev = dev;
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 01/12] drm/panel: kd35t133: Add panel orientation support
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Parse the device tree rotation specifier, and set a DRM
connector orientation property. The property can then be read
by compositors to apply hardware plane rotation or a GPU transform.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index fe5ac3ef9018..5987d28c874c 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -39,6 +39,7 @@
 struct kd35t133 {
 	struct device *dev;
 	struct drm_panel panel;
+	enum drm_panel_orientation orientation;
 	struct gpio_desc *reset_gpio;
 	struct regulator *vdd;
 	struct regulator *iovcc;
@@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
 	connector->display_info.width_mm = mode->width_mm;
 	connector->display_info.height_mm = mode->height_mm;
 	drm_mode_probed_add(connector, mode);
+	drm_connector_set_panel_orientation(connector, ctx->orientation);
 
 	return 1;
 }
@@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
 		return ret;
 	}
 
+	ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
+	if (ret) {
+		dev_err(dev, "%pOF: failed to get orientation %d\n", dev->of_node, ret);
+		return ret;
+	}
+
 	mipi_dsi_set_drvdata(dsi, ctx);
 
 	ctx->dev = dev;
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

The Odroid Go Advance panel is rotated, so let's reflect this
in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
index 49c97f76df77..cca19660e60a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
@@ -240,6 +240,7 @@ panel@0 {
 		iovcc-supply = <&vcc_lcd>;
 		reset-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
 		vdd-supply = <&vcc_lcd>;
+		rotation = <270>;
 
 		port {
 			mipi_in_panel: endpoint {
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

The Odroid Go Advance panel is rotated, so let's reflect this
in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
index 49c97f76df77..cca19660e60a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
@@ -240,6 +240,7 @@ panel@0 {
 		iovcc-supply = <&vcc_lcd>;
 		reset-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
 		vdd-supply = <&vcc_lcd>;
+		rotation = <270>;
 
 		port {
 			mipi_in_panel: endpoint {
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 03/12] hantro: vp8: Move noisy WARN_ON to vpu_debug
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel, Nicolas Dufresne

When the VP8 decoders can't find a reference frame,
the driver falls back to the current output frame.

This will probably produce some undesirable results,
leading to frame corruption, but shouldn't cause
noisy warnings.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
 drivers/staging/media/hantro/hantro_g1_vp8_dec.c    | 13 ++++++++++---
 .../staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c | 13 ++++++++++---
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 96622a7f8279..2afd5996d75f 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -376,12 +376,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
-	if (!ref)
+	if (!ref) {
+		vpu_debug(0, "failed to find last frame ts=%llu\n",
+			  hdr->last_frame_ts);
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+	}
 	vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(0));
 
 	ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
-	WARN_ON(!ref && hdr->golden_frame_ts);
+	if (!ref && hdr->golden_frame_ts)
+		vpu_debug(0, "failed to find golden frame ts=%llu\n",
+			  hdr->golden_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -389,7 +394,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(4));
 
 	ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
-	WARN_ON(!ref && hdr->alt_frame_ts);
+	if (!ref && hdr->alt_frame_ts)
+		vpu_debug(0, "failed to find alt frame ts=%llu\n",
+			  hdr->alt_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
index 951b55f58a61..704607511b57 100644
--- a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
@@ -453,12 +453,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
-	if (!ref)
+	if (!ref) {
+		vpu_debug(0, "failed to find last frame ts=%llu\n",
+			  hdr->last_frame_ts);
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+	}
 	vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF0);
 
 	ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
-	WARN_ON(!ref && hdr->golden_frame_ts);
+	if (!ref && hdr->golden_frame_ts)
+		vpu_debug(0, "failed to find golden frame ts=%llu\n",
+			  hdr->golden_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -466,7 +471,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF2_5(2));
 
 	ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
-	WARN_ON(!ref && hdr->alt_frame_ts);
+	if (!ref && hdr->alt_frame_ts)
+		vpu_debug(0, "failed to find alt frame ts=%llu\n",
+			  hdr->alt_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 03/12] hantro: vp8: Move noisy WARN_ON to vpu_debug
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Nicolas Dufresne,
	Jonas Karlman, David Airlie, Ezequiel Garcia, Alex Bee,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

When the VP8 decoders can't find a reference frame,
the driver falls back to the current output frame.

This will probably produce some undesirable results,
leading to frame corruption, but shouldn't cause
noisy warnings.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
 drivers/staging/media/hantro/hantro_g1_vp8_dec.c    | 13 ++++++++++---
 .../staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c | 13 ++++++++++---
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 96622a7f8279..2afd5996d75f 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -376,12 +376,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
-	if (!ref)
+	if (!ref) {
+		vpu_debug(0, "failed to find last frame ts=%llu\n",
+			  hdr->last_frame_ts);
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+	}
 	vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(0));
 
 	ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
-	WARN_ON(!ref && hdr->golden_frame_ts);
+	if (!ref && hdr->golden_frame_ts)
+		vpu_debug(0, "failed to find golden frame ts=%llu\n",
+			  hdr->golden_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -389,7 +394,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(4));
 
 	ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
-	WARN_ON(!ref && hdr->alt_frame_ts);
+	if (!ref && hdr->alt_frame_ts)
+		vpu_debug(0, "failed to find alt frame ts=%llu\n",
+			  hdr->alt_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
index 951b55f58a61..704607511b57 100644
--- a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
@@ -453,12 +453,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
-	if (!ref)
+	if (!ref) {
+		vpu_debug(0, "failed to find last frame ts=%llu\n",
+			  hdr->last_frame_ts);
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+	}
 	vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF0);
 
 	ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
-	WARN_ON(!ref && hdr->golden_frame_ts);
+	if (!ref && hdr->golden_frame_ts)
+		vpu_debug(0, "failed to find golden frame ts=%llu\n",
+			  hdr->golden_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -466,7 +471,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF2_5(2));
 
 	ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
-	WARN_ON(!ref && hdr->alt_frame_ts);
+	if (!ref && hdr->alt_frame_ts)
+		vpu_debug(0, "failed to find alt frame ts=%llu\n",
+			  hdr->alt_frame_ts);
 	if (!ref)
 		ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
 	if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 04/12] hantro: Make struct hantro_variant.init() optional
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

The hantro_variant.init() function is there for platforms
to perform hardware-specific initialization, such as
clock rate bumping.

Not all platforms require it, so make it optional.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro.h          |  4 ++--
 drivers/staging/media/hantro/hantro_drv.c      | 10 ++++++----
 drivers/staging/media/hantro/sama5d4_vdec_hw.c |  6 ------
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index a70c386de6f1..c2e2dca38628 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -61,8 +61,8 @@ struct hantro_irq {
  * @num_postproc_fmts:		Number of post-processor formats.
  * @codec:			Supported codecs
  * @codec_ops:			Codec ops.
- * @init:			Initialize hardware.
- * @runtime_resume:		reenable hardware after power gating
+ * @init:			Initialize hardware, optional.
+ * @runtime_resume:		reenable hardware after power gating, optional.
  * @irqs:			array of irq names and interrupt handlers
  * @num_irqs:			number of irqs in the array
  * @clk_names:			array of clock names
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 31d8449ca1d2..9b5415176bfe 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -942,10 +942,12 @@ static int hantro_probe(struct platform_device *pdev)
 		}
 	}
 
-	ret = vpu->variant->init(vpu);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to init VPU hardware\n");
-		return ret;
+	if (vpu->variant->init) {
+		ret = vpu->variant->init(vpu);
+		if (ret) {
+			dev_err(&pdev->dev, "Failed to init VPU hardware\n");
+			return ret;
+		}
 	}
 
 	pm_runtime_set_autosuspend_delay(vpu->dev, 100);
diff --git a/drivers/staging/media/hantro/sama5d4_vdec_hw.c b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
index 58ae72c2b723..9c3b8cd0b239 100644
--- a/drivers/staging/media/hantro/sama5d4_vdec_hw.c
+++ b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
@@ -64,11 +64,6 @@ static const struct hantro_fmt sama5d4_vdec_fmts[] = {
 	},
 };
 
-static int sama5d4_hw_init(struct hantro_dev *vpu)
-{
-	return 0;
-}
-
 /*
  * Supported codec ops.
  */
@@ -109,7 +104,6 @@ const struct hantro_variant sama5d4_vdec_variant = {
 	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
 		 HANTRO_H264_DECODER,
 	.codec_ops = sama5d4_vdec_codec_ops,
-	.init = sama5d4_hw_init,
 	.irqs = sama5d4_irqs,
 	.num_irqs = ARRAY_SIZE(sama5d4_irqs),
 	.clk_names = sama5d4_clk_names,
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 04/12] hantro: Make struct hantro_variant.init() optional
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

The hantro_variant.init() function is there for platforms
to perform hardware-specific initialization, such as
clock rate bumping.

Not all platforms require it, so make it optional.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro.h          |  4 ++--
 drivers/staging/media/hantro/hantro_drv.c      | 10 ++++++----
 drivers/staging/media/hantro/sama5d4_vdec_hw.c |  6 ------
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index a70c386de6f1..c2e2dca38628 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -61,8 +61,8 @@ struct hantro_irq {
  * @num_postproc_fmts:		Number of post-processor formats.
  * @codec:			Supported codecs
  * @codec_ops:			Codec ops.
- * @init:			Initialize hardware.
- * @runtime_resume:		reenable hardware after power gating
+ * @init:			Initialize hardware, optional.
+ * @runtime_resume:		reenable hardware after power gating, optional.
  * @irqs:			array of irq names and interrupt handlers
  * @num_irqs:			number of irqs in the array
  * @clk_names:			array of clock names
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 31d8449ca1d2..9b5415176bfe 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -942,10 +942,12 @@ static int hantro_probe(struct platform_device *pdev)
 		}
 	}
 
-	ret = vpu->variant->init(vpu);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to init VPU hardware\n");
-		return ret;
+	if (vpu->variant->init) {
+		ret = vpu->variant->init(vpu);
+		if (ret) {
+			dev_err(&pdev->dev, "Failed to init VPU hardware\n");
+			return ret;
+		}
 	}
 
 	pm_runtime_set_autosuspend_delay(vpu->dev, 100);
diff --git a/drivers/staging/media/hantro/sama5d4_vdec_hw.c b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
index 58ae72c2b723..9c3b8cd0b239 100644
--- a/drivers/staging/media/hantro/sama5d4_vdec_hw.c
+++ b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
@@ -64,11 +64,6 @@ static const struct hantro_fmt sama5d4_vdec_fmts[] = {
 	},
 };
 
-static int sama5d4_hw_init(struct hantro_dev *vpu)
-{
-	return 0;
-}
-
 /*
  * Supported codec ops.
  */
@@ -109,7 +104,6 @@ const struct hantro_variant sama5d4_vdec_variant = {
 	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
 		 HANTRO_H264_DECODER,
 	.codec_ops = sama5d4_vdec_codec_ops,
-	.init = sama5d4_hw_init,
 	.irqs = sama5d4_irqs,
 	.num_irqs = ARRAY_SIZE(sama5d4_irqs),
 	.clk_names = sama5d4_clk_names,
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 05/12] media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

Getting the next src/dst buffer is relatively expensive
so avoid doing it multiple times.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/hantro_g1_h264_dec.c | 17 ++++++++---------
 .../staging/media/hantro/hantro_g1_vp8_dec.c  | 18 +++++++++---------
 .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   | 19 +++++++++----------
 3 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 5c792b7bcb79..2aa37baad0c3 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -19,13 +19,12 @@
 #include "hantro_hw.h"
 #include "hantro_v4l2.h"
 
-static void set_params(struct hantro_ctx *ctx)
+static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 {
 	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
 	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
 	const struct v4l2_ctrl_h264_sps *sps = ctrls->sps;
 	const struct v4l2_ctrl_h264_pps *pps = ctrls->pps;
-	struct vb2_v4l2_buffer *src_buf = hantro_get_src_buf(ctx);
 	struct hantro_dev *vpu = ctx->dev;
 	u32 reg;
 
@@ -226,22 +225,20 @@ static void set_ref(struct hantro_ctx *ctx)
 	}
 }
 
-static void set_buffers(struct hantro_ctx *ctx)
+static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 {
 	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
-	struct vb2_v4l2_buffer *src_buf, *dst_buf;
+	struct vb2_v4l2_buffer *dst_buf;
 	struct hantro_dev *vpu = ctx->dev;
 	dma_addr_t src_dma, dst_dma;
 	size_t offset = 0;
 
-	src_buf = hantro_get_src_buf(ctx);
-	dst_buf = hantro_get_dst_buf(ctx);
-
 	/* Source (stream) buffer. */
 	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
 	vdpu_write_relaxed(vpu, src_dma, G1_REG_ADDR_STR);
 
 	/* Destination (decoded frame) buffer. */
+	dst_buf = hantro_get_dst_buf(ctx);
 	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
 	/* Adjust dma addr to start at second line for bottom field */
 	if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
@@ -276,6 +273,7 @@ static void set_buffers(struct hantro_ctx *ctx)
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *src_buf;
 	int ret;
 
 	/* Prepare the H264 decoder context. */
@@ -284,9 +282,10 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 		return ret;
 
 	/* Configure hardware registers. */
-	set_params(ctx);
+	src_buf = hantro_get_src_buf(ctx);
+	set_params(ctx, src_buf);
 	set_ref(ctx);
-	set_buffers(ctx);
+	set_buffers(ctx, src_buf);
 
 	hantro_end_prepare_run(ctx);
 
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 2afd5996d75f..6180b23e7d94 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -367,13 +367,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
 }
 
 static void cfg_ref(struct hantro_ctx *ctx,
-		    const struct v4l2_ctrl_vp8_frame *hdr)
+		    const struct v4l2_ctrl_vp8_frame *hdr,
+		    struct vb2_v4l2_buffer *vb2_dst)
 {
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t ref;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
 	if (!ref) {
@@ -405,16 +404,14 @@ static void cfg_ref(struct hantro_ctx *ctx,
 }
 
 static void cfg_buffers(struct hantro_ctx *ctx,
-			const struct v4l2_ctrl_vp8_frame *hdr)
+			const struct v4l2_ctrl_vp8_frame *hdr,
+			struct vb2_v4l2_buffer *vb2_dst)
 {
 	const struct v4l2_vp8_segment *seg = &hdr->segment;
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t dst_dma;
 	u32 reg;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	/* Set probability table buffer address */
 	vdpu_write_relaxed(vpu, ctx->vp8_dec.prob_tbl.dma,
 			   G1_REG_ADDR_QTABLE);
@@ -436,6 +433,7 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *vb2_dst;
 	size_t height = ctx->dst_fmt.height;
 	size_t width = ctx->dst_fmt.width;
 	u32 mb_width, mb_height;
@@ -499,8 +497,10 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 	cfg_qp(ctx, hdr);
 	cfg_parts(ctx, hdr);
 	cfg_tap(ctx, hdr);
-	cfg_ref(ctx, hdr);
-	cfg_buffers(ctx, hdr);
+
+	vb2_dst = hantro_get_dst_buf(ctx);
+	cfg_ref(ctx, hdr, vb2_dst);
+	cfg_buffers(ctx, hdr, vb2_dst);
 
 	hantro_end_prepare_run(ctx);
 
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
index 704607511b57..d079075448c9 100644
--- a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
@@ -444,14 +444,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
 }
 
 static void cfg_ref(struct hantro_ctx *ctx,
-		    const struct v4l2_ctrl_vp8_frame *hdr)
+		    const struct v4l2_ctrl_vp8_frame *hdr,
+		    struct vb2_v4l2_buffer *vb2_dst)
 {
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t ref;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
 	if (!ref) {
 		vpu_debug(0, "failed to find last frame ts=%llu\n",
@@ -482,16 +480,14 @@ static void cfg_ref(struct hantro_ctx *ctx,
 }
 
 static void cfg_buffers(struct hantro_ctx *ctx,
-			const struct v4l2_ctrl_vp8_frame *hdr)
+			const struct v4l2_ctrl_vp8_frame *hdr,
+			struct vb2_v4l2_buffer *vb2_dst)
 {
 	const struct v4l2_vp8_segment *seg = &hdr->segment;
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t dst_dma;
 	u32 reg;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	/* Set probability table buffer address */
 	vdpu_write_relaxed(vpu, ctx->vp8_dec.prob_tbl.dma,
 			   VDPU_REG_ADDR_QTABLE);
@@ -514,6 +510,7 @@ int rockchip_vpu2_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *vb2_dst;
 	size_t height = ctx->dst_fmt.height;
 	size_t width = ctx->dst_fmt.width;
 	u32 mb_width, mb_height;
@@ -590,8 +587,10 @@ int rockchip_vpu2_vp8_dec_run(struct hantro_ctx *ctx)
 	cfg_qp(ctx, hdr);
 	cfg_parts(ctx, hdr);
 	cfg_tap(ctx, hdr);
-	cfg_ref(ctx, hdr);
-	cfg_buffers(ctx, hdr);
+
+	vb2_dst = hantro_get_dst_buf(ctx);
+	cfg_ref(ctx, hdr, vb2_dst);
+	cfg_buffers(ctx, hdr, vb2_dst);
 
 	hantro_end_prepare_run(ctx);
 
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 05/12] media: hantro: Avoid redundant hantro_get_{dst, src}_buf() calls
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Getting the next src/dst buffer is relatively expensive
so avoid doing it multiple times.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/hantro_g1_h264_dec.c | 17 ++++++++---------
 .../staging/media/hantro/hantro_g1_vp8_dec.c  | 18 +++++++++---------
 .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   | 19 +++++++++----------
 3 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 5c792b7bcb79..2aa37baad0c3 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -19,13 +19,12 @@
 #include "hantro_hw.h"
 #include "hantro_v4l2.h"
 
-static void set_params(struct hantro_ctx *ctx)
+static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 {
 	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
 	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
 	const struct v4l2_ctrl_h264_sps *sps = ctrls->sps;
 	const struct v4l2_ctrl_h264_pps *pps = ctrls->pps;
-	struct vb2_v4l2_buffer *src_buf = hantro_get_src_buf(ctx);
 	struct hantro_dev *vpu = ctx->dev;
 	u32 reg;
 
@@ -226,22 +225,20 @@ static void set_ref(struct hantro_ctx *ctx)
 	}
 }
 
-static void set_buffers(struct hantro_ctx *ctx)
+static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 {
 	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
-	struct vb2_v4l2_buffer *src_buf, *dst_buf;
+	struct vb2_v4l2_buffer *dst_buf;
 	struct hantro_dev *vpu = ctx->dev;
 	dma_addr_t src_dma, dst_dma;
 	size_t offset = 0;
 
-	src_buf = hantro_get_src_buf(ctx);
-	dst_buf = hantro_get_dst_buf(ctx);
-
 	/* Source (stream) buffer. */
 	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
 	vdpu_write_relaxed(vpu, src_dma, G1_REG_ADDR_STR);
 
 	/* Destination (decoded frame) buffer. */
+	dst_buf = hantro_get_dst_buf(ctx);
 	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
 	/* Adjust dma addr to start at second line for bottom field */
 	if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
@@ -276,6 +273,7 @@ static void set_buffers(struct hantro_ctx *ctx)
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *src_buf;
 	int ret;
 
 	/* Prepare the H264 decoder context. */
@@ -284,9 +282,10 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 		return ret;
 
 	/* Configure hardware registers. */
-	set_params(ctx);
+	src_buf = hantro_get_src_buf(ctx);
+	set_params(ctx, src_buf);
 	set_ref(ctx);
-	set_buffers(ctx);
+	set_buffers(ctx, src_buf);
 
 	hantro_end_prepare_run(ctx);
 
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 2afd5996d75f..6180b23e7d94 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -367,13 +367,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
 }
 
 static void cfg_ref(struct hantro_ctx *ctx,
-		    const struct v4l2_ctrl_vp8_frame *hdr)
+		    const struct v4l2_ctrl_vp8_frame *hdr,
+		    struct vb2_v4l2_buffer *vb2_dst)
 {
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t ref;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
 
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
 	if (!ref) {
@@ -405,16 +404,14 @@ static void cfg_ref(struct hantro_ctx *ctx,
 }
 
 static void cfg_buffers(struct hantro_ctx *ctx,
-			const struct v4l2_ctrl_vp8_frame *hdr)
+			const struct v4l2_ctrl_vp8_frame *hdr,
+			struct vb2_v4l2_buffer *vb2_dst)
 {
 	const struct v4l2_vp8_segment *seg = &hdr->segment;
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t dst_dma;
 	u32 reg;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	/* Set probability table buffer address */
 	vdpu_write_relaxed(vpu, ctx->vp8_dec.prob_tbl.dma,
 			   G1_REG_ADDR_QTABLE);
@@ -436,6 +433,7 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *vb2_dst;
 	size_t height = ctx->dst_fmt.height;
 	size_t width = ctx->dst_fmt.width;
 	u32 mb_width, mb_height;
@@ -499,8 +497,10 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 	cfg_qp(ctx, hdr);
 	cfg_parts(ctx, hdr);
 	cfg_tap(ctx, hdr);
-	cfg_ref(ctx, hdr);
-	cfg_buffers(ctx, hdr);
+
+	vb2_dst = hantro_get_dst_buf(ctx);
+	cfg_ref(ctx, hdr, vb2_dst);
+	cfg_buffers(ctx, hdr, vb2_dst);
 
 	hantro_end_prepare_run(ctx);
 
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
index 704607511b57..d079075448c9 100644
--- a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
@@ -444,14 +444,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
 }
 
 static void cfg_ref(struct hantro_ctx *ctx,
-		    const struct v4l2_ctrl_vp8_frame *hdr)
+		    const struct v4l2_ctrl_vp8_frame *hdr,
+		    struct vb2_v4l2_buffer *vb2_dst)
 {
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t ref;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	ref = hantro_get_ref(ctx, hdr->last_frame_ts);
 	if (!ref) {
 		vpu_debug(0, "failed to find last frame ts=%llu\n",
@@ -482,16 +480,14 @@ static void cfg_ref(struct hantro_ctx *ctx,
 }
 
 static void cfg_buffers(struct hantro_ctx *ctx,
-			const struct v4l2_ctrl_vp8_frame *hdr)
+			const struct v4l2_ctrl_vp8_frame *hdr,
+			struct vb2_v4l2_buffer *vb2_dst)
 {
 	const struct v4l2_vp8_segment *seg = &hdr->segment;
 	struct hantro_dev *vpu = ctx->dev;
-	struct vb2_v4l2_buffer *vb2_dst;
 	dma_addr_t dst_dma;
 	u32 reg;
 
-	vb2_dst = hantro_get_dst_buf(ctx);
-
 	/* Set probability table buffer address */
 	vdpu_write_relaxed(vpu, ctx->vp8_dec.prob_tbl.dma,
 			   VDPU_REG_ADDR_QTABLE);
@@ -514,6 +510,7 @@ int rockchip_vpu2_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *vb2_dst;
 	size_t height = ctx->dst_fmt.height;
 	size_t width = ctx->dst_fmt.width;
 	u32 mb_width, mb_height;
@@ -590,8 +587,10 @@ int rockchip_vpu2_vp8_dec_run(struct hantro_ctx *ctx)
 	cfg_qp(ctx, hdr);
 	cfg_parts(ctx, hdr);
 	cfg_tap(ctx, hdr);
-	cfg_ref(ctx, hdr);
-	cfg_buffers(ctx, hdr);
+
+	vb2_dst = hantro_get_dst_buf(ctx);
+	cfg_ref(ctx, hdr, vb2_dst);
+	cfg_buffers(ctx, hdr, vb2_dst);
 
 	hantro_end_prepare_run(ctx);
 
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 06/12] media: hantro: h264: Move DPB valid and long-term bitmaps
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

In order to reuse these bitmaps, move this process to
struct hantro_h264_dec_hw_ctx. This will be used by
the Rockchip VDPU2 H.264 driver.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/hantro_g1_h264_dec.c   | 17 ++---------------
 drivers/staging/media/hantro/hantro_h264.c      | 13 +++++++++++++
 drivers/staging/media/hantro/hantro_hw.h        |  4 ++++
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 2aa37baad0c3..6faacfc44c7c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -129,25 +129,12 @@ static void set_ref(struct hantro_ctx *ctx)
 	struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
 	const u8 *b0_reflist, *b1_reflist, *p_reflist;
 	struct hantro_dev *vpu = ctx->dev;
-	u32 dpb_longterm = 0;
-	u32 dpb_valid = 0;
 	int reg_num;
 	u32 reg;
 	int i;
 
-	/*
-	 * Set up bit maps of valid and long term DPBs.
-	 * NOTE: The bits are reversed, i.e. MSb is DPB 0.
-	 */
-	for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
-			dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
-
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
-	}
-	vdpu_write_relaxed(vpu, dpb_valid << 16, G1_REG_VALID_REF);
-	vdpu_write_relaxed(vpu, dpb_longterm << 16, G1_REG_LT_REF);
+	vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_valid, G1_REG_VALID_REF);
+	vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_longterm, G1_REG_LT_REF);
 
 	/*
 	 * Set up reference frame picture numbers.
diff --git a/drivers/staging/media/hantro/hantro_h264.c b/drivers/staging/media/hantro/hantro_h264.c
index ed6eaf11d96f..6d72136760e7 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -229,12 +229,25 @@ static void prepare_table(struct hantro_ctx *ctx)
 	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
 	struct hantro_h264_dec_priv_tbl *tbl = ctx->h264_dec.priv.cpu;
 	const struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
+	u32 dpb_longterm = 0;
+	u32 dpb_valid = 0;
 	int i;
 
 	for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
 		tbl->poc[i * 2] = dpb[i].top_field_order_cnt;
 		tbl->poc[i * 2 + 1] = dpb[i].bottom_field_order_cnt;
+
+		/*
+		 * Set up bit maps of valid and long term DPBs.
+		 * NOTE: The bits are reversed, i.e. MSb is DPB 0.
+		 */
+		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
+			dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
+		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+			dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
 	}
+	ctx->h264_dec.dpb_valid = dpb_valid << 16;
+	ctx->h264_dec.dpb_longterm = dpb_longterm << 16;
 
 	tbl->poc[32] = dec_param->top_field_order_cnt;
 	tbl->poc[33] = dec_param->bottom_field_order_cnt;
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 5dcf65805396..ce678fedaad6 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -89,12 +89,16 @@ struct hantro_h264_dec_reflists {
  * @dpb:	DPB
  * @reflists:	P/B0/B1 reflists
  * @ctrls:	V4L2 controls attached to a run
+ * @dpb_longterm: DPB long-term
+ * @dpb_valid:	  DPB valid
  */
 struct hantro_h264_dec_hw_ctx {
 	struct hantro_aux_buf priv;
 	struct v4l2_h264_dpb_entry dpb[HANTRO_H264_DPB_SIZE];
 	struct hantro_h264_dec_reflists reflists;
 	struct hantro_h264_dec_ctrls ctrls;
+	u32 dpb_longterm;
+	u32 dpb_valid;
 };
 
 /**
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 06/12] media: hantro: h264: Move DPB valid and long-term bitmaps
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

In order to reuse these bitmaps, move this process to
struct hantro_h264_dec_hw_ctx. This will be used by
the Rockchip VDPU2 H.264 driver.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/hantro_g1_h264_dec.c   | 17 ++---------------
 drivers/staging/media/hantro/hantro_h264.c      | 13 +++++++++++++
 drivers/staging/media/hantro/hantro_hw.h        |  4 ++++
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 2aa37baad0c3..6faacfc44c7c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -129,25 +129,12 @@ static void set_ref(struct hantro_ctx *ctx)
 	struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
 	const u8 *b0_reflist, *b1_reflist, *p_reflist;
 	struct hantro_dev *vpu = ctx->dev;
-	u32 dpb_longterm = 0;
-	u32 dpb_valid = 0;
 	int reg_num;
 	u32 reg;
 	int i;
 
-	/*
-	 * Set up bit maps of valid and long term DPBs.
-	 * NOTE: The bits are reversed, i.e. MSb is DPB 0.
-	 */
-	for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
-			dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
-
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
-	}
-	vdpu_write_relaxed(vpu, dpb_valid << 16, G1_REG_VALID_REF);
-	vdpu_write_relaxed(vpu, dpb_longterm << 16, G1_REG_LT_REF);
+	vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_valid, G1_REG_VALID_REF);
+	vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_longterm, G1_REG_LT_REF);
 
 	/*
 	 * Set up reference frame picture numbers.
diff --git a/drivers/staging/media/hantro/hantro_h264.c b/drivers/staging/media/hantro/hantro_h264.c
index ed6eaf11d96f..6d72136760e7 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -229,12 +229,25 @@ static void prepare_table(struct hantro_ctx *ctx)
 	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
 	struct hantro_h264_dec_priv_tbl *tbl = ctx->h264_dec.priv.cpu;
 	const struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
+	u32 dpb_longterm = 0;
+	u32 dpb_valid = 0;
 	int i;
 
 	for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
 		tbl->poc[i * 2] = dpb[i].top_field_order_cnt;
 		tbl->poc[i * 2 + 1] = dpb[i].bottom_field_order_cnt;
+
+		/*
+		 * Set up bit maps of valid and long term DPBs.
+		 * NOTE: The bits are reversed, i.e. MSb is DPB 0.
+		 */
+		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
+			dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
+		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+			dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
 	}
+	ctx->h264_dec.dpb_valid = dpb_valid << 16;
+	ctx->h264_dec.dpb_longterm = dpb_longterm << 16;
 
 	tbl->poc[32] = dec_param->top_field_order_cnt;
 	tbl->poc[33] = dec_param->bottom_field_order_cnt;
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 5dcf65805396..ce678fedaad6 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -89,12 +89,16 @@ struct hantro_h264_dec_reflists {
  * @dpb:	DPB
  * @reflists:	P/B0/B1 reflists
  * @ctrls:	V4L2 controls attached to a run
+ * @dpb_longterm: DPB long-term
+ * @dpb_valid:	  DPB valid
  */
 struct hantro_h264_dec_hw_ctx {
 	struct hantro_aux_buf priv;
 	struct v4l2_h264_dpb_entry dpb[HANTRO_H264_DPB_SIZE];
 	struct hantro_h264_dec_reflists reflists;
 	struct hantro_h264_dec_ctrls ctrls;
+	u32 dpb_longterm;
+	u32 dpb_valid;
 };
 
 /**
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 07/12] media: hantro: h264: Move reference picture number to a helper
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

Add a hantro_h264_get_ref_nbr() helper function to get the reference
picture numbers. This will be used by the Rockchip VDPU2 H.264 driver.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro_g1_h264_dec.c | 14 ++------------
 drivers/staging/media/hantro/hantro_h264.c        | 11 +++++++++++
 drivers/staging/media/hantro/hantro_hw.h          |  2 ++
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 6faacfc44c7c..236ce24ca00c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -126,7 +126,6 @@ static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 
 static void set_ref(struct hantro_ctx *ctx)
 {
-	struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
 	const u8 *b0_reflist, *b1_reflist, *p_reflist;
 	struct hantro_dev *vpu = ctx->dev;
 	int reg_num;
@@ -143,17 +142,8 @@ static void set_ref(struct hantro_ctx *ctx)
 	 * subsequential reference pictures.
 	 */
 	for (i = 0; i < HANTRO_H264_DPB_SIZE; i += 2) {
-		reg = 0;
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].pic_num);
-		else
-			reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].frame_num);
-
-		if (dpb[i + 1].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].pic_num);
-		else
-			reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].frame_num);
-
+		reg = G1_REG_REF_PIC_REFER0_NBR(hantro_h264_get_ref_nbr(ctx, i)) |
+		      G1_REG_REF_PIC_REFER1_NBR(hantro_h264_get_ref_nbr(ctx, i + 1));
 		vdpu_write_relaxed(vpu, reg, G1_REG_REF_PIC(i / 2));
 	}
 
diff --git a/drivers/staging/media/hantro/hantro_h264.c b/drivers/staging/media/hantro/hantro_h264.c
index 6d72136760e7..0b4d2491be3b 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -348,6 +348,17 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 	return dma_addr;
 }
 
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx, unsigned int dpb_idx)
+{
+	const struct v4l2_h264_dpb_entry *dpb = &ctx->h264_dec.dpb[dpb_idx];
+
+	if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
+		return 0;
+	if (dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+		return dpb->pic_num;
+	return dpb->frame_num;
+}
+
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx)
 {
 	struct hantro_h264_dec_hw_ctx *h264_ctx = &ctx->h264_dec;
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index ce678fedaad6..7a8048afe357 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -238,6 +238,8 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
 
 dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 				   unsigned int dpb_idx);
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx,
+			    unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 07/12] media: hantro: h264: Move reference picture number to a helper
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Add a hantro_h264_get_ref_nbr() helper function to get the reference
picture numbers. This will be used by the Rockchip VDPU2 H.264 driver.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro_g1_h264_dec.c | 14 ++------------
 drivers/staging/media/hantro/hantro_h264.c        | 11 +++++++++++
 drivers/staging/media/hantro/hantro_hw.h          |  2 ++
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 6faacfc44c7c..236ce24ca00c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -126,7 +126,6 @@ static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 
 static void set_ref(struct hantro_ctx *ctx)
 {
-	struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
 	const u8 *b0_reflist, *b1_reflist, *p_reflist;
 	struct hantro_dev *vpu = ctx->dev;
 	int reg_num;
@@ -143,17 +142,8 @@ static void set_ref(struct hantro_ctx *ctx)
 	 * subsequential reference pictures.
 	 */
 	for (i = 0; i < HANTRO_H264_DPB_SIZE; i += 2) {
-		reg = 0;
-		if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].pic_num);
-		else
-			reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].frame_num);
-
-		if (dpb[i + 1].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
-			reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].pic_num);
-		else
-			reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].frame_num);
-
+		reg = G1_REG_REF_PIC_REFER0_NBR(hantro_h264_get_ref_nbr(ctx, i)) |
+		      G1_REG_REF_PIC_REFER1_NBR(hantro_h264_get_ref_nbr(ctx, i + 1));
 		vdpu_write_relaxed(vpu, reg, G1_REG_REF_PIC(i / 2));
 	}
 
diff --git a/drivers/staging/media/hantro/hantro_h264.c b/drivers/staging/media/hantro/hantro_h264.c
index 6d72136760e7..0b4d2491be3b 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -348,6 +348,17 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 	return dma_addr;
 }
 
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx, unsigned int dpb_idx)
+{
+	const struct v4l2_h264_dpb_entry *dpb = &ctx->h264_dec.dpb[dpb_idx];
+
+	if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
+		return 0;
+	if (dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+		return dpb->pic_num;
+	return dpb->frame_num;
+}
+
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx)
 {
 	struct hantro_h264_dec_hw_ctx *h264_ctx = &ctx->h264_dec;
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index ce678fedaad6..7a8048afe357 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -238,6 +238,8 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
 
 dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 				   unsigned int dpb_idx);
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx,
+			    unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 08/12] media: hantro: Add H.264 support for Rockchip VDPU2
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel, Ezequiel Garcia

From: Jonas Karlman <jonas@kwiboo.se>

Rockchip VDPU2 core is present on RK3328, RK3326/PX30, RK3399
and others. It's similar to Hantro G1, but it's not compatible with it.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/Makefile         |   1 +
 drivers/staging/media/hantro/hantro_hw.h      |   1 +
 .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
 3 files changed, 493 insertions(+)
 create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c

diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile
index 287370188d2a..90036831fec4 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -13,6 +13,7 @@ hantro-vpu-y += \
 		hantro_g2_hevc_dec.o \
 		hantro_g1_vp8_dec.o \
 		rockchip_vpu2_hw_jpeg_enc.o \
+		rockchip_vpu2_hw_h264_dec.o \
 		rockchip_vpu2_hw_mpeg2_dec.o \
 		rockchip_vpu2_hw_vp8_dec.o \
 		hantro_jpeg.o \
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 7a8048afe357..9296624654a6 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -241,6 +241,7 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx,
 			    unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
+int rockchip_vpu2_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
new file mode 100644
index 000000000000..64a6330475eb
--- /dev/null
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU codec driver
+ *
+ * Copyright (c) 2014 Rockchip Electronics Co., Ltd.
+ *	Hertz Wong <hertz.wong@rock-chips.com>
+ *	Herman Chen <herman.chen@rock-chips.com>
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *	Tomasz Figa <tfiga@chromium.org>
+ */
+
+#include <linux/types.h>
+#include <linux/sort.h>
+
+#include <media/v4l2-mem2mem.h>
+
+#include "hantro_hw.h"
+#include "hantro_v4l2.h"
+
+#define VDPU_SWREG(nr)			((nr) * 4)
+
+#define VDPU_REG_DEC_OUT_BASE		VDPU_SWREG(63)
+#define VDPU_REG_RLC_VLC_BASE		VDPU_SWREG(64)
+#define VDPU_REG_QTABLE_BASE		VDPU_SWREG(61)
+#define VDPU_REG_DIR_MV_BASE		VDPU_SWREG(62)
+#define VDPU_REG_REFER_BASE(i)		(VDPU_SWREG(84 + (i)))
+#define VDPU_REG_DEC_E(v)		((v) ? BIT(0) : 0)
+
+#define VDPU_REG_DEC_ADV_PRE_DIS(v)	((v) ? BIT(11) : 0)
+#define VDPU_REG_DEC_SCMD_DIS(v)	((v) ? BIT(10) : 0)
+#define VDPU_REG_FILTERING_DIS(v)	((v) ? BIT(8) : 0)
+#define VDPU_REG_PIC_FIXED_QUANT(v)	((v) ? BIT(7) : 0)
+#define VDPU_REG_DEC_LATENCY(v)		(((v) << 1) & GENMASK(6, 1))
+
+#define VDPU_REG_INIT_QP(v)		(((v) << 25) & GENMASK(30, 25))
+#define VDPU_REG_STREAM_LEN(v)		(((v) << 0) & GENMASK(23, 0))
+
+#define VDPU_REG_APF_THRESHOLD(v)	(((v) << 17) & GENMASK(30, 17))
+#define VDPU_REG_STARTMB_X(v)		(((v) << 8) & GENMASK(16, 8))
+#define VDPU_REG_STARTMB_Y(v)		(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_DEC_MODE(v)		(((v) << 0) & GENMASK(3, 0))
+
+#define VDPU_REG_DEC_STRENDIAN_E(v)	((v) ? BIT(5) : 0)
+#define VDPU_REG_DEC_STRSWAP32_E(v)	((v) ? BIT(4) : 0)
+#define VDPU_REG_DEC_OUTSWAP32_E(v)	((v) ? BIT(3) : 0)
+#define VDPU_REG_DEC_INSWAP32_E(v)	((v) ? BIT(2) : 0)
+#define VDPU_REG_DEC_OUT_ENDIAN(v)	((v) ? BIT(1) : 0)
+#define VDPU_REG_DEC_IN_ENDIAN(v)	((v) ? BIT(0) : 0)
+
+#define VDPU_REG_DEC_DATA_DISC_E(v)	((v) ? BIT(22) : 0)
+#define VDPU_REG_DEC_MAX_BURST(v)	(((v) << 16) & GENMASK(20, 16))
+#define VDPU_REG_DEC_AXI_WR_ID(v)	(((v) << 8) & GENMASK(15, 8))
+#define VDPU_REG_DEC_AXI_RD_ID(v)	(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_START_CODE_E(v)	((v) ? BIT(22) : 0)
+#define VDPU_REG_CH_8PIX_ILEAV_E(v)	((v) ? BIT(21) : 0)
+#define VDPU_REG_RLC_MODE_E(v)		((v) ? BIT(20) : 0)
+#define VDPU_REG_PIC_INTERLACE_E(v)	((v) ? BIT(17) : 0)
+#define VDPU_REG_PIC_FIELDMODE_E(v)	((v) ? BIT(16) : 0)
+#define VDPU_REG_PIC_TOPFIELD_E(v)	((v) ? BIT(13) : 0)
+#define VDPU_REG_WRITE_MVS_E(v)		((v) ? BIT(10) : 0)
+#define VDPU_REG_SEQ_MBAFF_E(v)		((v) ? BIT(7) : 0)
+#define VDPU_REG_PICORD_COUNT_E(v)	((v) ? BIT(6) : 0)
+#define VDPU_REG_DEC_TIMEOUT_E(v)	((v) ? BIT(5) : 0)
+#define VDPU_REG_DEC_CLK_GATE_E(v)	((v) ? BIT(4) : 0)
+
+#define VDPU_REG_PRED_BC_TAP_0_0(v)	(((v) << 22) & GENMASK(31, 22))
+#define VDPU_REG_PRED_BC_TAP_0_1(v)	(((v) << 12) & GENMASK(21, 12))
+#define VDPU_REG_PRED_BC_TAP_0_2(v)	(((v) << 2) & GENMASK(11, 2))
+
+#define VDPU_REG_REFBU_E(v)		((v) ? BIT(31) : 0)
+
+#define VDPU_REG_PINIT_RLIST_F9(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_PINIT_RLIST_F8(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_PINIT_RLIST_F7(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F6(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F5(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F4(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_PINIT_RLIST_F15(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_PINIT_RLIST_F14(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_PINIT_RLIST_F13(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F12(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F11(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F10(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_REFER1_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER0_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER3_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER2_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER5_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER4_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER7_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER6_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER9_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER8_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER11_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER10_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER13_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER12_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER15_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER14_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_BINIT_RLIST_F5(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_F4(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_F3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_F11(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_F10(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_F9(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F8(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F7(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F6(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_F15(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F14(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F13(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F12(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B5(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_B4(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_B3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B11(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_B10(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_B9(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B8(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B7(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B6(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B15(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B14(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B13(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B12(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_PINIT_RLIST_F3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_REFER_LTERM_E(v)	(((v) << 0) & GENMASK(31, 0))
+
+#define VDPU_REG_REFER_VALID_E(v)	(((v) << 0) & GENMASK(31, 0))
+
+#define VDPU_REG_STRM_START_BIT(v)	(((v) << 0) & GENMASK(5, 0))
+
+#define VDPU_REG_CH_QP_OFFSET2(v)	(((v) << 22) & GENMASK(26, 22))
+#define VDPU_REG_CH_QP_OFFSET(v)	(((v) << 17) & GENMASK(21, 17))
+#define VDPU_REG_PIC_MB_HEIGHT_P(v)	(((v) << 9) & GENMASK(16, 9))
+#define VDPU_REG_PIC_MB_WIDTH(v)	(((v) << 0) & GENMASK(8, 0))
+
+#define VDPU_REG_WEIGHT_BIPR_IDC(v)	(((v) << 16) & GENMASK(17, 16))
+#define VDPU_REG_REF_FRAMES(v)		(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_FILT_CTRL_PRES(v)	((v) ? BIT(31) : 0)
+#define VDPU_REG_RDPIC_CNT_PRES(v)	((v) ? BIT(30) : 0)
+#define VDPU_REG_FRAMENUM_LEN(v)	(((v) << 16) & GENMASK(20, 16))
+#define VDPU_REG_FRAMENUM(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFPIC_MK_LEN(v)	(((v) << 16) & GENMASK(26, 16))
+#define VDPU_REG_IDR_PIC_ID(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_PPS_ID(v)		(((v) << 24) & GENMASK(31, 24))
+#define VDPU_REG_REFIDX1_ACTIVE(v)	(((v) << 19) & GENMASK(23, 19))
+#define VDPU_REG_REFIDX0_ACTIVE(v)	(((v) << 14) & GENMASK(18, 14))
+#define VDPU_REG_POC_LENGTH(v)		(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_IDR_PIC_E(v)		((v) ? BIT(8) : 0)
+#define VDPU_REG_DIR_8X8_INFER_E(v)	((v) ? BIT(7) : 0)
+#define VDPU_REG_BLACKWHITE_E(v)	((v) ? BIT(6) : 0)
+#define VDPU_REG_CABAC_E(v)		((v) ? BIT(5) : 0)
+#define VDPU_REG_WEIGHT_PRED_E(v)	((v) ? BIT(4) : 0)
+#define VDPU_REG_CONST_INTRA_E(v)	((v) ? BIT(3) : 0)
+#define VDPU_REG_8X8TRANS_FLAG_E(v)	((v) ? BIT(2) : 0)
+#define VDPU_REG_TYPE1_QUANT_E(v)	((v) ? BIT(1) : 0)
+#define VDPU_REG_FIELDPIC_FLAG_E(v)	((v) ? BIT(0) : 0)
+
+static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
+{
+	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
+	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
+	const struct v4l2_ctrl_h264_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_h264_pps *pps = ctrls->pps;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 reg;
+
+	reg = VDPU_REG_DEC_ADV_PRE_DIS(0) |
+	      VDPU_REG_DEC_SCMD_DIS(0) |
+	      VDPU_REG_FILTERING_DIS(0) |
+	      VDPU_REG_PIC_FIXED_QUANT(0) |
+	      VDPU_REG_DEC_LATENCY(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(50));
+
+	reg = VDPU_REG_INIT_QP(pps->pic_init_qp_minus26 + 26) |
+	      VDPU_REG_STREAM_LEN(vb2_get_plane_payload(&src_buf->vb2_buf, 0));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(51));
+
+	reg = VDPU_REG_APF_THRESHOLD(8) |
+	      VDPU_REG_STARTMB_X(0) |
+	      VDPU_REG_STARTMB_Y(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(52));
+
+	reg = VDPU_REG_DEC_MODE(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(53));
+
+	reg = VDPU_REG_DEC_STRENDIAN_E(1) |
+	      VDPU_REG_DEC_STRSWAP32_E(1) |
+	      VDPU_REG_DEC_OUTSWAP32_E(1) |
+	      VDPU_REG_DEC_INSWAP32_E(1) |
+	      VDPU_REG_DEC_OUT_ENDIAN(1) |
+	      VDPU_REG_DEC_IN_ENDIAN(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(54));
+
+	reg = VDPU_REG_DEC_DATA_DISC_E(0) |
+	      VDPU_REG_DEC_MAX_BURST(16) |
+	      VDPU_REG_DEC_AXI_WR_ID(0) |
+	      VDPU_REG_DEC_AXI_RD_ID(0xff);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(56));
+
+	reg = VDPU_REG_START_CODE_E(1) |
+	      VDPU_REG_CH_8PIX_ILEAV_E(0) |
+	      VDPU_REG_RLC_MODE_E(0) |
+	      VDPU_REG_PIC_INTERLACE_E(!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) &&
+				       (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD ||
+					dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC)) |
+	      VDPU_REG_PIC_FIELDMODE_E(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC) |
+	      VDPU_REG_PIC_TOPFIELD_E(!(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)) |
+	      VDPU_REG_WRITE_MVS_E((sps->profile_idc > 66) && dec_param->nal_ref_idc) |
+	      VDPU_REG_SEQ_MBAFF_E(sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD) |
+	      VDPU_REG_PICORD_COUNT_E(sps->profile_idc > 66) |
+	      VDPU_REG_DEC_TIMEOUT_E(1) |
+	      VDPU_REG_DEC_CLK_GATE_E(1);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(57));
+
+	reg = VDPU_REG_PRED_BC_TAP_0_0(1) |
+	      VDPU_REG_PRED_BC_TAP_0_1((u32)-5) |
+	      VDPU_REG_PRED_BC_TAP_0_2(20);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(59));
+
+	reg = VDPU_REG_REFBU_E(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(65));
+
+	reg = VDPU_REG_STRM_START_BIT(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(109));
+
+	reg = VDPU_REG_CH_QP_OFFSET2(pps->second_chroma_qp_index_offset) |
+	      VDPU_REG_CH_QP_OFFSET(pps->chroma_qp_index_offset) |
+	      VDPU_REG_PIC_MB_HEIGHT_P(MB_HEIGHT(ctx->src_fmt.height)) |
+	      VDPU_REG_PIC_MB_WIDTH(MB_WIDTH(ctx->src_fmt.width));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(110));
+
+	reg = VDPU_REG_WEIGHT_BIPR_IDC(pps->weighted_bipred_idc) |
+	      VDPU_REG_REF_FRAMES(sps->max_num_ref_frames);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(111));
+
+	reg = VDPU_REG_FILT_CTRL_PRES(pps->flags & V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT) |
+	      VDPU_REG_RDPIC_CNT_PRES(pps->flags & V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT) |
+	      VDPU_REG_FRAMENUM_LEN(sps->log2_max_frame_num_minus4 + 4) |
+	      VDPU_REG_FRAMENUM(dec_param->frame_num);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(112));
+
+	reg = VDPU_REG_REFPIC_MK_LEN(dec_param->dec_ref_pic_marking_bit_size) |
+	      VDPU_REG_IDR_PIC_ID(dec_param->idr_pic_id);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(113));
+
+	reg = VDPU_REG_PPS_ID(pps->pic_parameter_set_id) |
+	      VDPU_REG_REFIDX1_ACTIVE(pps->num_ref_idx_l1_default_active_minus1 + 1) |
+	      VDPU_REG_REFIDX0_ACTIVE(pps->num_ref_idx_l0_default_active_minus1 + 1) |
+	      VDPU_REG_POC_LENGTH(dec_param->pic_order_cnt_bit_size);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(114));
+
+	reg = VDPU_REG_IDR_PIC_E(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC) |
+	      VDPU_REG_DIR_8X8_INFER_E(sps->flags & V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE) |
+	      VDPU_REG_BLACKWHITE_E(sps->profile_idc >= 100 && sps->chroma_format_idc == 0) |
+	      VDPU_REG_CABAC_E(pps->flags & V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE) |
+	      VDPU_REG_WEIGHT_PRED_E(pps->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) |
+	      VDPU_REG_CONST_INTRA_E(pps->flags & V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED) |
+	      VDPU_REG_8X8TRANS_FLAG_E(pps->flags & V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE) |
+	      VDPU_REG_TYPE1_QUANT_E(pps->flags & V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT) |
+	      VDPU_REG_FIELDPIC_FLAG_E(!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(115));
+}
+
+static void set_ref(struct hantro_ctx *ctx)
+{
+	const u8 *b0_reflist, *b1_reflist, *p_reflist;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 reg;
+	int i;
+
+	b0_reflist = ctx->h264_dec.reflists.b0;
+	b1_reflist = ctx->h264_dec.reflists.b1;
+	p_reflist = ctx->h264_dec.reflists.p;
+
+	reg = VDPU_REG_PINIT_RLIST_F9(p_reflist[9]) |
+	      VDPU_REG_PINIT_RLIST_F8(p_reflist[8]) |
+	      VDPU_REG_PINIT_RLIST_F7(p_reflist[7]) |
+	      VDPU_REG_PINIT_RLIST_F6(p_reflist[6]) |
+	      VDPU_REG_PINIT_RLIST_F5(p_reflist[5]) |
+	      VDPU_REG_PINIT_RLIST_F4(p_reflist[4]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(74));
+
+	reg = VDPU_REG_PINIT_RLIST_F15(p_reflist[15]) |
+	      VDPU_REG_PINIT_RLIST_F14(p_reflist[14]) |
+	      VDPU_REG_PINIT_RLIST_F13(p_reflist[13]) |
+	      VDPU_REG_PINIT_RLIST_F12(p_reflist[12]) |
+	      VDPU_REG_PINIT_RLIST_F11(p_reflist[11]) |
+	      VDPU_REG_PINIT_RLIST_F10(p_reflist[10]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(75));
+
+	reg = VDPU_REG_REFER1_NBR(hantro_h264_get_ref_nbr(ctx, 1)) |
+	      VDPU_REG_REFER0_NBR(hantro_h264_get_ref_nbr(ctx, 0));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(76));
+
+	reg = VDPU_REG_REFER3_NBR(hantro_h264_get_ref_nbr(ctx, 3)) |
+	      VDPU_REG_REFER2_NBR(hantro_h264_get_ref_nbr(ctx, 2));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(77));
+
+	reg = VDPU_REG_REFER5_NBR(hantro_h264_get_ref_nbr(ctx, 5)) |
+	      VDPU_REG_REFER4_NBR(hantro_h264_get_ref_nbr(ctx, 4));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(78));
+
+	reg = VDPU_REG_REFER7_NBR(hantro_h264_get_ref_nbr(ctx, 7)) |
+	      VDPU_REG_REFER6_NBR(hantro_h264_get_ref_nbr(ctx, 6));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(79));
+
+	reg = VDPU_REG_REFER9_NBR(hantro_h264_get_ref_nbr(ctx, 9)) |
+	      VDPU_REG_REFER8_NBR(hantro_h264_get_ref_nbr(ctx, 8));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(80));
+
+	reg = VDPU_REG_REFER11_NBR(hantro_h264_get_ref_nbr(ctx, 11)) |
+	      VDPU_REG_REFER10_NBR(hantro_h264_get_ref_nbr(ctx, 10));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(81));
+
+	reg = VDPU_REG_REFER13_NBR(hantro_h264_get_ref_nbr(ctx, 13)) |
+	      VDPU_REG_REFER12_NBR(hantro_h264_get_ref_nbr(ctx, 12));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(82));
+
+	reg = VDPU_REG_REFER15_NBR(hantro_h264_get_ref_nbr(ctx, 15)) |
+	      VDPU_REG_REFER14_NBR(hantro_h264_get_ref_nbr(ctx, 14));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(83));
+
+	reg = VDPU_REG_BINIT_RLIST_F5(b0_reflist[5]) |
+	      VDPU_REG_BINIT_RLIST_F4(b0_reflist[4]) |
+	      VDPU_REG_BINIT_RLIST_F3(b0_reflist[3]) |
+	      VDPU_REG_BINIT_RLIST_F2(b0_reflist[2]) |
+	      VDPU_REG_BINIT_RLIST_F1(b0_reflist[1]) |
+	      VDPU_REG_BINIT_RLIST_F0(b0_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(100));
+
+	reg = VDPU_REG_BINIT_RLIST_F11(b0_reflist[11]) |
+	      VDPU_REG_BINIT_RLIST_F10(b0_reflist[10]) |
+	      VDPU_REG_BINIT_RLIST_F9(b0_reflist[9]) |
+	      VDPU_REG_BINIT_RLIST_F8(b0_reflist[8]) |
+	      VDPU_REG_BINIT_RLIST_F7(b0_reflist[7]) |
+	      VDPU_REG_BINIT_RLIST_F6(b0_reflist[6]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(101));
+
+	reg = VDPU_REG_BINIT_RLIST_F15(b0_reflist[15]) |
+	      VDPU_REG_BINIT_RLIST_F14(b0_reflist[14]) |
+	      VDPU_REG_BINIT_RLIST_F13(b0_reflist[13]) |
+	      VDPU_REG_BINIT_RLIST_F12(b0_reflist[12]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(102));
+
+	reg = VDPU_REG_BINIT_RLIST_B5(b1_reflist[5]) |
+	      VDPU_REG_BINIT_RLIST_B4(b1_reflist[4]) |
+	      VDPU_REG_BINIT_RLIST_B3(b1_reflist[3]) |
+	      VDPU_REG_BINIT_RLIST_B2(b1_reflist[2]) |
+	      VDPU_REG_BINIT_RLIST_B1(b1_reflist[1]) |
+	      VDPU_REG_BINIT_RLIST_B0(b1_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(103));
+
+	reg = VDPU_REG_BINIT_RLIST_B11(b1_reflist[11]) |
+	      VDPU_REG_BINIT_RLIST_B10(b1_reflist[10]) |
+	      VDPU_REG_BINIT_RLIST_B9(b1_reflist[9]) |
+	      VDPU_REG_BINIT_RLIST_B8(b1_reflist[8]) |
+	      VDPU_REG_BINIT_RLIST_B7(b1_reflist[7]) |
+	      VDPU_REG_BINIT_RLIST_B6(b1_reflist[6]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(104));
+
+	reg = VDPU_REG_BINIT_RLIST_B15(b1_reflist[15]) |
+	      VDPU_REG_BINIT_RLIST_B14(b1_reflist[14]) |
+	      VDPU_REG_BINIT_RLIST_B13(b1_reflist[13]) |
+	      VDPU_REG_BINIT_RLIST_B12(b1_reflist[12]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(105));
+
+	reg = VDPU_REG_PINIT_RLIST_F3(p_reflist[3]) |
+	      VDPU_REG_PINIT_RLIST_F2(p_reflist[2]) |
+	      VDPU_REG_PINIT_RLIST_F1(p_reflist[1]) |
+	      VDPU_REG_PINIT_RLIST_F0(p_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(106));
+
+	reg = VDPU_REG_REFER_LTERM_E(ctx->h264_dec.dpb_longterm);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(107));
+
+	reg = VDPU_REG_REFER_VALID_E(ctx->h264_dec.dpb_valid);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(108));
+
+	/* Set up addresses of DPB buffers. */
+	for (i = 0; i < HANTRO_H264_DPB_SIZE; i++) {
+		dma_addr_t dma_addr = hantro_h264_get_ref_buf(ctx, i);
+
+		vdpu_write_relaxed(vpu, dma_addr, VDPU_REG_REFER_BASE(i));
+	}
+}
+
+static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
+{
+	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
+	struct vb2_v4l2_buffer *dst_buf;
+	struct hantro_dev *vpu = ctx->dev;
+	dma_addr_t src_dma, dst_dma;
+	size_t offset = 0;
+
+	/* Source (stream) buffer. */
+	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+	vdpu_write_relaxed(vpu, src_dma, VDPU_REG_RLC_VLC_BASE);
+
+	/* Destination (decoded frame) buffer. */
+	dst_buf = hantro_get_dst_buf(ctx);
+	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
+	/* Adjust dma addr to start at second line for bottom field */
+	if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
+		offset = ALIGN(ctx->src_fmt.width, MB_DIM);
+	vdpu_write_relaxed(vpu, dst_dma + offset, VDPU_REG_DEC_OUT_BASE);
+
+	/* Higher profiles require DMV buffer appended to reference frames. */
+	if (ctrls->sps->profile_idc > 66 && ctrls->decode->nal_ref_idc) {
+		unsigned int bytes_per_mb = 384;
+
+		/* DMV buffer for monochrome start directly after Y-plane */
+		if (ctrls->sps->profile_idc >= 100 &&
+		    ctrls->sps->chroma_format_idc == 0)
+			bytes_per_mb = 256;
+		offset = bytes_per_mb * MB_WIDTH(ctx->src_fmt.width) *
+			 MB_HEIGHT(ctx->src_fmt.height);
+
+		/*
+		 * DMV buffer is split in two for field encoded frames,
+		 * adjust offset for bottom field
+		 */
+		if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
+			offset += 32 * MB_WIDTH(ctx->src_fmt.width) *
+				  MB_HEIGHT(ctx->src_fmt.height);
+		vdpu_write_relaxed(vpu, dst_dma + offset, VDPU_REG_DIR_MV_BASE);
+	}
+
+	/* Auxiliary buffer prepared in hantro_g1_h264_dec_prepare_table(). */
+	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, VDPU_REG_QTABLE_BASE);
+}
+
+int rockchip_vpu2_h264_dec_run(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *src_buf;
+	u32 reg;
+	int ret;
+
+	/* Prepare the H264 decoder context. */
+	ret = hantro_h264_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
+
+	src_buf = hantro_get_src_buf(ctx);
+	set_params(ctx, src_buf);
+	set_ref(ctx);
+	set_buffers(ctx, src_buf);
+
+	hantro_end_prepare_run(ctx);
+
+	/* Start decoding! */
+	reg = vdpu_read(vpu, VDPU_SWREG(57)) | VDPU_REG_DEC_E(1);
+	vdpu_write(vpu, reg, VDPU_SWREG(57));
+
+	return 0;
+}
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 08/12] media: hantro: Add H.264 support for Rockchip VDPU2
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

From: Jonas Karlman <jonas@kwiboo.se>

Rockchip VDPU2 core is present on RK3328, RK3326/PX30, RK3399
and others. It's similar to Hantro G1, but it's not compatible with it.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/Makefile         |   1 +
 drivers/staging/media/hantro/hantro_hw.h      |   1 +
 .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
 3 files changed, 493 insertions(+)
 create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c

diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile
index 287370188d2a..90036831fec4 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -13,6 +13,7 @@ hantro-vpu-y += \
 		hantro_g2_hevc_dec.o \
 		hantro_g1_vp8_dec.o \
 		rockchip_vpu2_hw_jpeg_enc.o \
+		rockchip_vpu2_hw_h264_dec.o \
 		rockchip_vpu2_hw_mpeg2_dec.o \
 		rockchip_vpu2_hw_vp8_dec.o \
 		hantro_jpeg.o \
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 7a8048afe357..9296624654a6 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -241,6 +241,7 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx,
 			    unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
+int rockchip_vpu2_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
new file mode 100644
index 000000000000..64a6330475eb
--- /dev/null
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU codec driver
+ *
+ * Copyright (c) 2014 Rockchip Electronics Co., Ltd.
+ *	Hertz Wong <hertz.wong@rock-chips.com>
+ *	Herman Chen <herman.chen@rock-chips.com>
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *	Tomasz Figa <tfiga@chromium.org>
+ */
+
+#include <linux/types.h>
+#include <linux/sort.h>
+
+#include <media/v4l2-mem2mem.h>
+
+#include "hantro_hw.h"
+#include "hantro_v4l2.h"
+
+#define VDPU_SWREG(nr)			((nr) * 4)
+
+#define VDPU_REG_DEC_OUT_BASE		VDPU_SWREG(63)
+#define VDPU_REG_RLC_VLC_BASE		VDPU_SWREG(64)
+#define VDPU_REG_QTABLE_BASE		VDPU_SWREG(61)
+#define VDPU_REG_DIR_MV_BASE		VDPU_SWREG(62)
+#define VDPU_REG_REFER_BASE(i)		(VDPU_SWREG(84 + (i)))
+#define VDPU_REG_DEC_E(v)		((v) ? BIT(0) : 0)
+
+#define VDPU_REG_DEC_ADV_PRE_DIS(v)	((v) ? BIT(11) : 0)
+#define VDPU_REG_DEC_SCMD_DIS(v)	((v) ? BIT(10) : 0)
+#define VDPU_REG_FILTERING_DIS(v)	((v) ? BIT(8) : 0)
+#define VDPU_REG_PIC_FIXED_QUANT(v)	((v) ? BIT(7) : 0)
+#define VDPU_REG_DEC_LATENCY(v)		(((v) << 1) & GENMASK(6, 1))
+
+#define VDPU_REG_INIT_QP(v)		(((v) << 25) & GENMASK(30, 25))
+#define VDPU_REG_STREAM_LEN(v)		(((v) << 0) & GENMASK(23, 0))
+
+#define VDPU_REG_APF_THRESHOLD(v)	(((v) << 17) & GENMASK(30, 17))
+#define VDPU_REG_STARTMB_X(v)		(((v) << 8) & GENMASK(16, 8))
+#define VDPU_REG_STARTMB_Y(v)		(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_DEC_MODE(v)		(((v) << 0) & GENMASK(3, 0))
+
+#define VDPU_REG_DEC_STRENDIAN_E(v)	((v) ? BIT(5) : 0)
+#define VDPU_REG_DEC_STRSWAP32_E(v)	((v) ? BIT(4) : 0)
+#define VDPU_REG_DEC_OUTSWAP32_E(v)	((v) ? BIT(3) : 0)
+#define VDPU_REG_DEC_INSWAP32_E(v)	((v) ? BIT(2) : 0)
+#define VDPU_REG_DEC_OUT_ENDIAN(v)	((v) ? BIT(1) : 0)
+#define VDPU_REG_DEC_IN_ENDIAN(v)	((v) ? BIT(0) : 0)
+
+#define VDPU_REG_DEC_DATA_DISC_E(v)	((v) ? BIT(22) : 0)
+#define VDPU_REG_DEC_MAX_BURST(v)	(((v) << 16) & GENMASK(20, 16))
+#define VDPU_REG_DEC_AXI_WR_ID(v)	(((v) << 8) & GENMASK(15, 8))
+#define VDPU_REG_DEC_AXI_RD_ID(v)	(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_START_CODE_E(v)	((v) ? BIT(22) : 0)
+#define VDPU_REG_CH_8PIX_ILEAV_E(v)	((v) ? BIT(21) : 0)
+#define VDPU_REG_RLC_MODE_E(v)		((v) ? BIT(20) : 0)
+#define VDPU_REG_PIC_INTERLACE_E(v)	((v) ? BIT(17) : 0)
+#define VDPU_REG_PIC_FIELDMODE_E(v)	((v) ? BIT(16) : 0)
+#define VDPU_REG_PIC_TOPFIELD_E(v)	((v) ? BIT(13) : 0)
+#define VDPU_REG_WRITE_MVS_E(v)		((v) ? BIT(10) : 0)
+#define VDPU_REG_SEQ_MBAFF_E(v)		((v) ? BIT(7) : 0)
+#define VDPU_REG_PICORD_COUNT_E(v)	((v) ? BIT(6) : 0)
+#define VDPU_REG_DEC_TIMEOUT_E(v)	((v) ? BIT(5) : 0)
+#define VDPU_REG_DEC_CLK_GATE_E(v)	((v) ? BIT(4) : 0)
+
+#define VDPU_REG_PRED_BC_TAP_0_0(v)	(((v) << 22) & GENMASK(31, 22))
+#define VDPU_REG_PRED_BC_TAP_0_1(v)	(((v) << 12) & GENMASK(21, 12))
+#define VDPU_REG_PRED_BC_TAP_0_2(v)	(((v) << 2) & GENMASK(11, 2))
+
+#define VDPU_REG_REFBU_E(v)		((v) ? BIT(31) : 0)
+
+#define VDPU_REG_PINIT_RLIST_F9(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_PINIT_RLIST_F8(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_PINIT_RLIST_F7(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F6(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F5(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F4(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_PINIT_RLIST_F15(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_PINIT_RLIST_F14(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_PINIT_RLIST_F13(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F12(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F11(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F10(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_REFER1_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER0_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER3_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER2_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER5_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER4_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER7_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER6_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER9_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER8_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER11_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER10_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER13_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER12_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFER15_NBR(v)		(((v) << 16) & GENMASK(31, 16))
+#define VDPU_REG_REFER14_NBR(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_BINIT_RLIST_F5(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_F4(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_F3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_F11(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_F10(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_F9(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F8(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F7(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F6(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_F15(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_F14(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_F13(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_F12(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B5(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_B4(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_B3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B11(v)	(((v) << 25) & GENMASK(29, 25))
+#define VDPU_REG_BINIT_RLIST_B10(v)	(((v) << 20) & GENMASK(24, 20))
+#define VDPU_REG_BINIT_RLIST_B9(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B8(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B7(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B6(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_BINIT_RLIST_B15(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_BINIT_RLIST_B14(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_BINIT_RLIST_B13(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_BINIT_RLIST_B12(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_PINIT_RLIST_F3(v)	(((v) << 15) & GENMASK(19, 15))
+#define VDPU_REG_PINIT_RLIST_F2(v)	(((v) << 10) & GENMASK(14, 10))
+#define VDPU_REG_PINIT_RLIST_F1(v)	(((v) << 5) & GENMASK(9, 5))
+#define VDPU_REG_PINIT_RLIST_F0(v)	(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_REFER_LTERM_E(v)	(((v) << 0) & GENMASK(31, 0))
+
+#define VDPU_REG_REFER_VALID_E(v)	(((v) << 0) & GENMASK(31, 0))
+
+#define VDPU_REG_STRM_START_BIT(v)	(((v) << 0) & GENMASK(5, 0))
+
+#define VDPU_REG_CH_QP_OFFSET2(v)	(((v) << 22) & GENMASK(26, 22))
+#define VDPU_REG_CH_QP_OFFSET(v)	(((v) << 17) & GENMASK(21, 17))
+#define VDPU_REG_PIC_MB_HEIGHT_P(v)	(((v) << 9) & GENMASK(16, 9))
+#define VDPU_REG_PIC_MB_WIDTH(v)	(((v) << 0) & GENMASK(8, 0))
+
+#define VDPU_REG_WEIGHT_BIPR_IDC(v)	(((v) << 16) & GENMASK(17, 16))
+#define VDPU_REG_REF_FRAMES(v)		(((v) << 0) & GENMASK(4, 0))
+
+#define VDPU_REG_FILT_CTRL_PRES(v)	((v) ? BIT(31) : 0)
+#define VDPU_REG_RDPIC_CNT_PRES(v)	((v) ? BIT(30) : 0)
+#define VDPU_REG_FRAMENUM_LEN(v)	(((v) << 16) & GENMASK(20, 16))
+#define VDPU_REG_FRAMENUM(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_REFPIC_MK_LEN(v)	(((v) << 16) & GENMASK(26, 16))
+#define VDPU_REG_IDR_PIC_ID(v)		(((v) << 0) & GENMASK(15, 0))
+
+#define VDPU_REG_PPS_ID(v)		(((v) << 24) & GENMASK(31, 24))
+#define VDPU_REG_REFIDX1_ACTIVE(v)	(((v) << 19) & GENMASK(23, 19))
+#define VDPU_REG_REFIDX0_ACTIVE(v)	(((v) << 14) & GENMASK(18, 14))
+#define VDPU_REG_POC_LENGTH(v)		(((v) << 0) & GENMASK(7, 0))
+
+#define VDPU_REG_IDR_PIC_E(v)		((v) ? BIT(8) : 0)
+#define VDPU_REG_DIR_8X8_INFER_E(v)	((v) ? BIT(7) : 0)
+#define VDPU_REG_BLACKWHITE_E(v)	((v) ? BIT(6) : 0)
+#define VDPU_REG_CABAC_E(v)		((v) ? BIT(5) : 0)
+#define VDPU_REG_WEIGHT_PRED_E(v)	((v) ? BIT(4) : 0)
+#define VDPU_REG_CONST_INTRA_E(v)	((v) ? BIT(3) : 0)
+#define VDPU_REG_8X8TRANS_FLAG_E(v)	((v) ? BIT(2) : 0)
+#define VDPU_REG_TYPE1_QUANT_E(v)	((v) ? BIT(1) : 0)
+#define VDPU_REG_FIELDPIC_FLAG_E(v)	((v) ? BIT(0) : 0)
+
+static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
+{
+	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
+	const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
+	const struct v4l2_ctrl_h264_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_h264_pps *pps = ctrls->pps;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 reg;
+
+	reg = VDPU_REG_DEC_ADV_PRE_DIS(0) |
+	      VDPU_REG_DEC_SCMD_DIS(0) |
+	      VDPU_REG_FILTERING_DIS(0) |
+	      VDPU_REG_PIC_FIXED_QUANT(0) |
+	      VDPU_REG_DEC_LATENCY(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(50));
+
+	reg = VDPU_REG_INIT_QP(pps->pic_init_qp_minus26 + 26) |
+	      VDPU_REG_STREAM_LEN(vb2_get_plane_payload(&src_buf->vb2_buf, 0));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(51));
+
+	reg = VDPU_REG_APF_THRESHOLD(8) |
+	      VDPU_REG_STARTMB_X(0) |
+	      VDPU_REG_STARTMB_Y(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(52));
+
+	reg = VDPU_REG_DEC_MODE(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(53));
+
+	reg = VDPU_REG_DEC_STRENDIAN_E(1) |
+	      VDPU_REG_DEC_STRSWAP32_E(1) |
+	      VDPU_REG_DEC_OUTSWAP32_E(1) |
+	      VDPU_REG_DEC_INSWAP32_E(1) |
+	      VDPU_REG_DEC_OUT_ENDIAN(1) |
+	      VDPU_REG_DEC_IN_ENDIAN(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(54));
+
+	reg = VDPU_REG_DEC_DATA_DISC_E(0) |
+	      VDPU_REG_DEC_MAX_BURST(16) |
+	      VDPU_REG_DEC_AXI_WR_ID(0) |
+	      VDPU_REG_DEC_AXI_RD_ID(0xff);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(56));
+
+	reg = VDPU_REG_START_CODE_E(1) |
+	      VDPU_REG_CH_8PIX_ILEAV_E(0) |
+	      VDPU_REG_RLC_MODE_E(0) |
+	      VDPU_REG_PIC_INTERLACE_E(!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) &&
+				       (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD ||
+					dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC)) |
+	      VDPU_REG_PIC_FIELDMODE_E(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC) |
+	      VDPU_REG_PIC_TOPFIELD_E(!(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)) |
+	      VDPU_REG_WRITE_MVS_E((sps->profile_idc > 66) && dec_param->nal_ref_idc) |
+	      VDPU_REG_SEQ_MBAFF_E(sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD) |
+	      VDPU_REG_PICORD_COUNT_E(sps->profile_idc > 66) |
+	      VDPU_REG_DEC_TIMEOUT_E(1) |
+	      VDPU_REG_DEC_CLK_GATE_E(1);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(57));
+
+	reg = VDPU_REG_PRED_BC_TAP_0_0(1) |
+	      VDPU_REG_PRED_BC_TAP_0_1((u32)-5) |
+	      VDPU_REG_PRED_BC_TAP_0_2(20);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(59));
+
+	reg = VDPU_REG_REFBU_E(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(65));
+
+	reg = VDPU_REG_STRM_START_BIT(0);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(109));
+
+	reg = VDPU_REG_CH_QP_OFFSET2(pps->second_chroma_qp_index_offset) |
+	      VDPU_REG_CH_QP_OFFSET(pps->chroma_qp_index_offset) |
+	      VDPU_REG_PIC_MB_HEIGHT_P(MB_HEIGHT(ctx->src_fmt.height)) |
+	      VDPU_REG_PIC_MB_WIDTH(MB_WIDTH(ctx->src_fmt.width));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(110));
+
+	reg = VDPU_REG_WEIGHT_BIPR_IDC(pps->weighted_bipred_idc) |
+	      VDPU_REG_REF_FRAMES(sps->max_num_ref_frames);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(111));
+
+	reg = VDPU_REG_FILT_CTRL_PRES(pps->flags & V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT) |
+	      VDPU_REG_RDPIC_CNT_PRES(pps->flags & V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT) |
+	      VDPU_REG_FRAMENUM_LEN(sps->log2_max_frame_num_minus4 + 4) |
+	      VDPU_REG_FRAMENUM(dec_param->frame_num);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(112));
+
+	reg = VDPU_REG_REFPIC_MK_LEN(dec_param->dec_ref_pic_marking_bit_size) |
+	      VDPU_REG_IDR_PIC_ID(dec_param->idr_pic_id);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(113));
+
+	reg = VDPU_REG_PPS_ID(pps->pic_parameter_set_id) |
+	      VDPU_REG_REFIDX1_ACTIVE(pps->num_ref_idx_l1_default_active_minus1 + 1) |
+	      VDPU_REG_REFIDX0_ACTIVE(pps->num_ref_idx_l0_default_active_minus1 + 1) |
+	      VDPU_REG_POC_LENGTH(dec_param->pic_order_cnt_bit_size);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(114));
+
+	reg = VDPU_REG_IDR_PIC_E(dec_param->flags & V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC) |
+	      VDPU_REG_DIR_8X8_INFER_E(sps->flags & V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE) |
+	      VDPU_REG_BLACKWHITE_E(sps->profile_idc >= 100 && sps->chroma_format_idc == 0) |
+	      VDPU_REG_CABAC_E(pps->flags & V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE) |
+	      VDPU_REG_WEIGHT_PRED_E(pps->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) |
+	      VDPU_REG_CONST_INTRA_E(pps->flags & V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED) |
+	      VDPU_REG_8X8TRANS_FLAG_E(pps->flags & V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE) |
+	      VDPU_REG_TYPE1_QUANT_E(pps->flags & V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT) |
+	      VDPU_REG_FIELDPIC_FLAG_E(!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(115));
+}
+
+static void set_ref(struct hantro_ctx *ctx)
+{
+	const u8 *b0_reflist, *b1_reflist, *p_reflist;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 reg;
+	int i;
+
+	b0_reflist = ctx->h264_dec.reflists.b0;
+	b1_reflist = ctx->h264_dec.reflists.b1;
+	p_reflist = ctx->h264_dec.reflists.p;
+
+	reg = VDPU_REG_PINIT_RLIST_F9(p_reflist[9]) |
+	      VDPU_REG_PINIT_RLIST_F8(p_reflist[8]) |
+	      VDPU_REG_PINIT_RLIST_F7(p_reflist[7]) |
+	      VDPU_REG_PINIT_RLIST_F6(p_reflist[6]) |
+	      VDPU_REG_PINIT_RLIST_F5(p_reflist[5]) |
+	      VDPU_REG_PINIT_RLIST_F4(p_reflist[4]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(74));
+
+	reg = VDPU_REG_PINIT_RLIST_F15(p_reflist[15]) |
+	      VDPU_REG_PINIT_RLIST_F14(p_reflist[14]) |
+	      VDPU_REG_PINIT_RLIST_F13(p_reflist[13]) |
+	      VDPU_REG_PINIT_RLIST_F12(p_reflist[12]) |
+	      VDPU_REG_PINIT_RLIST_F11(p_reflist[11]) |
+	      VDPU_REG_PINIT_RLIST_F10(p_reflist[10]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(75));
+
+	reg = VDPU_REG_REFER1_NBR(hantro_h264_get_ref_nbr(ctx, 1)) |
+	      VDPU_REG_REFER0_NBR(hantro_h264_get_ref_nbr(ctx, 0));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(76));
+
+	reg = VDPU_REG_REFER3_NBR(hantro_h264_get_ref_nbr(ctx, 3)) |
+	      VDPU_REG_REFER2_NBR(hantro_h264_get_ref_nbr(ctx, 2));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(77));
+
+	reg = VDPU_REG_REFER5_NBR(hantro_h264_get_ref_nbr(ctx, 5)) |
+	      VDPU_REG_REFER4_NBR(hantro_h264_get_ref_nbr(ctx, 4));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(78));
+
+	reg = VDPU_REG_REFER7_NBR(hantro_h264_get_ref_nbr(ctx, 7)) |
+	      VDPU_REG_REFER6_NBR(hantro_h264_get_ref_nbr(ctx, 6));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(79));
+
+	reg = VDPU_REG_REFER9_NBR(hantro_h264_get_ref_nbr(ctx, 9)) |
+	      VDPU_REG_REFER8_NBR(hantro_h264_get_ref_nbr(ctx, 8));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(80));
+
+	reg = VDPU_REG_REFER11_NBR(hantro_h264_get_ref_nbr(ctx, 11)) |
+	      VDPU_REG_REFER10_NBR(hantro_h264_get_ref_nbr(ctx, 10));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(81));
+
+	reg = VDPU_REG_REFER13_NBR(hantro_h264_get_ref_nbr(ctx, 13)) |
+	      VDPU_REG_REFER12_NBR(hantro_h264_get_ref_nbr(ctx, 12));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(82));
+
+	reg = VDPU_REG_REFER15_NBR(hantro_h264_get_ref_nbr(ctx, 15)) |
+	      VDPU_REG_REFER14_NBR(hantro_h264_get_ref_nbr(ctx, 14));
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(83));
+
+	reg = VDPU_REG_BINIT_RLIST_F5(b0_reflist[5]) |
+	      VDPU_REG_BINIT_RLIST_F4(b0_reflist[4]) |
+	      VDPU_REG_BINIT_RLIST_F3(b0_reflist[3]) |
+	      VDPU_REG_BINIT_RLIST_F2(b0_reflist[2]) |
+	      VDPU_REG_BINIT_RLIST_F1(b0_reflist[1]) |
+	      VDPU_REG_BINIT_RLIST_F0(b0_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(100));
+
+	reg = VDPU_REG_BINIT_RLIST_F11(b0_reflist[11]) |
+	      VDPU_REG_BINIT_RLIST_F10(b0_reflist[10]) |
+	      VDPU_REG_BINIT_RLIST_F9(b0_reflist[9]) |
+	      VDPU_REG_BINIT_RLIST_F8(b0_reflist[8]) |
+	      VDPU_REG_BINIT_RLIST_F7(b0_reflist[7]) |
+	      VDPU_REG_BINIT_RLIST_F6(b0_reflist[6]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(101));
+
+	reg = VDPU_REG_BINIT_RLIST_F15(b0_reflist[15]) |
+	      VDPU_REG_BINIT_RLIST_F14(b0_reflist[14]) |
+	      VDPU_REG_BINIT_RLIST_F13(b0_reflist[13]) |
+	      VDPU_REG_BINIT_RLIST_F12(b0_reflist[12]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(102));
+
+	reg = VDPU_REG_BINIT_RLIST_B5(b1_reflist[5]) |
+	      VDPU_REG_BINIT_RLIST_B4(b1_reflist[4]) |
+	      VDPU_REG_BINIT_RLIST_B3(b1_reflist[3]) |
+	      VDPU_REG_BINIT_RLIST_B2(b1_reflist[2]) |
+	      VDPU_REG_BINIT_RLIST_B1(b1_reflist[1]) |
+	      VDPU_REG_BINIT_RLIST_B0(b1_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(103));
+
+	reg = VDPU_REG_BINIT_RLIST_B11(b1_reflist[11]) |
+	      VDPU_REG_BINIT_RLIST_B10(b1_reflist[10]) |
+	      VDPU_REG_BINIT_RLIST_B9(b1_reflist[9]) |
+	      VDPU_REG_BINIT_RLIST_B8(b1_reflist[8]) |
+	      VDPU_REG_BINIT_RLIST_B7(b1_reflist[7]) |
+	      VDPU_REG_BINIT_RLIST_B6(b1_reflist[6]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(104));
+
+	reg = VDPU_REG_BINIT_RLIST_B15(b1_reflist[15]) |
+	      VDPU_REG_BINIT_RLIST_B14(b1_reflist[14]) |
+	      VDPU_REG_BINIT_RLIST_B13(b1_reflist[13]) |
+	      VDPU_REG_BINIT_RLIST_B12(b1_reflist[12]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(105));
+
+	reg = VDPU_REG_PINIT_RLIST_F3(p_reflist[3]) |
+	      VDPU_REG_PINIT_RLIST_F2(p_reflist[2]) |
+	      VDPU_REG_PINIT_RLIST_F1(p_reflist[1]) |
+	      VDPU_REG_PINIT_RLIST_F0(p_reflist[0]);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(106));
+
+	reg = VDPU_REG_REFER_LTERM_E(ctx->h264_dec.dpb_longterm);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(107));
+
+	reg = VDPU_REG_REFER_VALID_E(ctx->h264_dec.dpb_valid);
+	vdpu_write_relaxed(vpu, reg, VDPU_SWREG(108));
+
+	/* Set up addresses of DPB buffers. */
+	for (i = 0; i < HANTRO_H264_DPB_SIZE; i++) {
+		dma_addr_t dma_addr = hantro_h264_get_ref_buf(ctx, i);
+
+		vdpu_write_relaxed(vpu, dma_addr, VDPU_REG_REFER_BASE(i));
+	}
+}
+
+static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
+{
+	const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
+	struct vb2_v4l2_buffer *dst_buf;
+	struct hantro_dev *vpu = ctx->dev;
+	dma_addr_t src_dma, dst_dma;
+	size_t offset = 0;
+
+	/* Source (stream) buffer. */
+	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+	vdpu_write_relaxed(vpu, src_dma, VDPU_REG_RLC_VLC_BASE);
+
+	/* Destination (decoded frame) buffer. */
+	dst_buf = hantro_get_dst_buf(ctx);
+	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
+	/* Adjust dma addr to start at second line for bottom field */
+	if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
+		offset = ALIGN(ctx->src_fmt.width, MB_DIM);
+	vdpu_write_relaxed(vpu, dst_dma + offset, VDPU_REG_DEC_OUT_BASE);
+
+	/* Higher profiles require DMV buffer appended to reference frames. */
+	if (ctrls->sps->profile_idc > 66 && ctrls->decode->nal_ref_idc) {
+		unsigned int bytes_per_mb = 384;
+
+		/* DMV buffer for monochrome start directly after Y-plane */
+		if (ctrls->sps->profile_idc >= 100 &&
+		    ctrls->sps->chroma_format_idc == 0)
+			bytes_per_mb = 256;
+		offset = bytes_per_mb * MB_WIDTH(ctx->src_fmt.width) *
+			 MB_HEIGHT(ctx->src_fmt.height);
+
+		/*
+		 * DMV buffer is split in two for field encoded frames,
+		 * adjust offset for bottom field
+		 */
+		if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
+			offset += 32 * MB_WIDTH(ctx->src_fmt.width) *
+				  MB_HEIGHT(ctx->src_fmt.height);
+		vdpu_write_relaxed(vpu, dst_dma + offset, VDPU_REG_DIR_MV_BASE);
+	}
+
+	/* Auxiliary buffer prepared in hantro_g1_h264_dec_prepare_table(). */
+	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, VDPU_REG_QTABLE_BASE);
+}
+
+int rockchip_vpu2_h264_dec_run(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct vb2_v4l2_buffer *src_buf;
+	u32 reg;
+	int ret;
+
+	/* Prepare the H264 decoder context. */
+	ret = hantro_h264_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
+
+	src_buf = hantro_get_src_buf(ctx);
+	set_params(ctx, src_buf);
+	set_ref(ctx);
+	set_buffers(ctx, src_buf);
+
+	hantro_end_prepare_run(ctx);
+
+	/* Start decoding! */
+	reg = vdpu_read(vpu, VDPU_SWREG(57)) | VDPU_REG_DEC_E(1);
+	vdpu_write(vpu, reg, VDPU_SWREG(57));
+
+	return 0;
+}
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	Ezequiel Garcia, kernel

Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/rockchip_vpu_hw.c    | 26 ++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index 3ccc16413f42..e4e3b5e7689b 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -162,6 +162,19 @@ static const struct hantro_fmt rk3399_vpu_dec_fmts[] = {
 		.fourcc = V4L2_PIX_FMT_NV12,
 		.codec_mode = HANTRO_MODE_NONE,
 	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.codec_mode = HANTRO_MODE_H264_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = 48,
+			.max_width = 1920,
+			.step_width = MB_DIM,
+			.min_height = 48,
+			.max_height = 1088,
+			.step_height = MB_DIM,
+		},
+	},
 	{
 		.fourcc = V4L2_PIX_FMT_MPEG2_SLICE,
 		.codec_mode = HANTRO_MODE_MPEG2_DEC,
@@ -388,6 +401,12 @@ static const struct hantro_codec_ops rk3399_vpu_codec_ops[] = {
 		.init = hantro_jpeg_enc_init,
 		.exit = hantro_jpeg_enc_exit,
 	},
+	[HANTRO_MODE_H264_DEC] = {
+		.run = rockchip_vpu2_h264_dec_run,
+		.reset = rockchip_vpu2_dec_reset,
+		.init = hantro_h264_dec_init,
+		.exit = hantro_h264_dec_exit,
+	},
 	[HANTRO_MODE_MPEG2_DEC] = {
 		.run = rockchip_vpu2_mpeg2_dec_run,
 		.reset = rockchip_vpu2_dec_reset,
@@ -433,6 +452,8 @@ static const char * const rockchip_vpu_clk_names[] = {
 	"aclk", "hclk"
 };
 
+/* VDPU1/VEPU1 */
+
 const struct hantro_variant rk3036_vpu_variant = {
 	.dec_offset = 0x400,
 	.dec_fmts = rk3066_vpu_dec_fmts,
@@ -495,11 +516,14 @@ const struct hantro_variant rk3288_vpu_variant = {
 	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
 };
 
+/* VDPU2/VEPU2 */
+
 const struct hantro_variant rk3328_vpu_variant = {
 	.dec_offset = 0x400,
 	.dec_fmts = rk3399_vpu_dec_fmts,
 	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
-	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER,
+	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
+		 HANTRO_H264_DECODER,
 	.codec_ops = rk3399_vpu_codec_ops,
 	.irqs = rockchip_vdpu2_irqs,
 	.num_irqs = ARRAY_SIZE(rockchip_vdpu2_irqs),
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 .../staging/media/hantro/rockchip_vpu_hw.c    | 26 ++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index 3ccc16413f42..e4e3b5e7689b 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -162,6 +162,19 @@ static const struct hantro_fmt rk3399_vpu_dec_fmts[] = {
 		.fourcc = V4L2_PIX_FMT_NV12,
 		.codec_mode = HANTRO_MODE_NONE,
 	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.codec_mode = HANTRO_MODE_H264_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = 48,
+			.max_width = 1920,
+			.step_width = MB_DIM,
+			.min_height = 48,
+			.max_height = 1088,
+			.step_height = MB_DIM,
+		},
+	},
 	{
 		.fourcc = V4L2_PIX_FMT_MPEG2_SLICE,
 		.codec_mode = HANTRO_MODE_MPEG2_DEC,
@@ -388,6 +401,12 @@ static const struct hantro_codec_ops rk3399_vpu_codec_ops[] = {
 		.init = hantro_jpeg_enc_init,
 		.exit = hantro_jpeg_enc_exit,
 	},
+	[HANTRO_MODE_H264_DEC] = {
+		.run = rockchip_vpu2_h264_dec_run,
+		.reset = rockchip_vpu2_dec_reset,
+		.init = hantro_h264_dec_init,
+		.exit = hantro_h264_dec_exit,
+	},
 	[HANTRO_MODE_MPEG2_DEC] = {
 		.run = rockchip_vpu2_mpeg2_dec_run,
 		.reset = rockchip_vpu2_dec_reset,
@@ -433,6 +452,8 @@ static const char * const rockchip_vpu_clk_names[] = {
 	"aclk", "hclk"
 };
 
+/* VDPU1/VEPU1 */
+
 const struct hantro_variant rk3036_vpu_variant = {
 	.dec_offset = 0x400,
 	.dec_fmts = rk3066_vpu_dec_fmts,
@@ -495,11 +516,14 @@ const struct hantro_variant rk3288_vpu_variant = {
 	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
 };
 
+/* VDPU2/VEPU2 */
+
 const struct hantro_variant rk3328_vpu_variant = {
 	.dec_offset = 0x400,
 	.dec_fmts = rk3399_vpu_dec_fmts,
 	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
-	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER,
+	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
+		 HANTRO_H264_DECODER,
 	.codec_ops = rk3399_vpu_codec_ops,
 	.irqs = rockchip_vdpu2_irqs,
 	.num_irqs = ARRAY_SIZE(rockchip_vdpu2_irqs),
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel, Ezequiel Garcia

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2).

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index b88172a59de7..3b9c5aa91fcc 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -28,6 +28,9 @@ properties:
       - items:
           - const: rockchip,rk3228-vpu
           - const: rockchip,rk3399-vpu
+      - items:
+          - const: rockchip,px30-vpu
+          - const: rockchip,rk3399-vpu
 
   reg:
     maxItems: 1
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2).

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index b88172a59de7..3b9c5aa91fcc 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -28,6 +28,9 @@ properties:
       - items:
           - const: rockchip,rk3228-vpu
           - const: rockchip,rk3399-vpu
+      - items:
+          - const: rockchip,px30-vpu
+          - const: rockchip,rk3399-vpu
 
   reg:
     maxItems: 1
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 11/12] arm64: dts: rockchip: Add VPU support for the PX30
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel, Ezequiel Garcia

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a167ce..892eb074775b 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1016,6 +1016,29 @@ gpu: gpu@ff400000 {
 		status = "disabled";
 	};
 
+	vpu: video-codec@ff442000 {
+		compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
+		reg = <0x0 0xff442000 0x0 0x800>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vepu", "vdpu";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "hclk";
+		iommus = <&vpu_mmu>;
+		power-domains = <&power PX30_PD_VPU>;
+	};
+
+	vpu_mmu: iommu@ff442800 {
+		compatible = "rockchip,iommu";
+		reg = <0x0 0xff442800 0x0 0x100>;
+		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vpu_mmu";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "iface";
+		#iommu-cells = <0>;
+		power-domains = <&power PX30_PD_VPU>;
+	};
+
 	dsi: dsi@ff450000 {
 		compatible = "rockchip,px30-mipi-dsi";
 		reg = <0x0 0xff450000 0x0 0x10000>;
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 11/12] arm64: dts: rockchip: Add VPU support for the PX30
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a167ce..892eb074775b 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1016,6 +1016,29 @@ gpu: gpu@ff400000 {
 		status = "disabled";
 	};
 
+	vpu: video-codec@ff442000 {
+		compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
+		reg = <0x0 0xff442000 0x0 0x800>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vepu", "vdpu";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "hclk";
+		iommus = <&vpu_mmu>;
+		power-domains = <&power PX30_PD_VPU>;
+	};
+
+	vpu_mmu: iommu@ff442800 {
+		compatible = "rockchip,iommu";
+		reg = <0x0 0xff442800 0x0 0x100>;
+		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vpu_mmu";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "iface";
+		#iommu-cells = <0>;
+		power-domains = <&power PX30_PD_VPU>;
+	};
+
 	dsi: dsi@ff450000 {
 		compatible = "rockchip,px30-mipi-dsi";
 		reg = <0x0 0xff450000 0x0 0x10000>;
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-24 18:26   ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel, Ezequiel Garcia

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro_drv.c     |  1 +
 drivers/staging/media/hantro/hantro_hw.h      |  1 +
 .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
 3 files changed, 30 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 9b5415176bfe..8a2edd67f2c6 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
 
 static const struct of_device_id of_hantro_match[] = {
 #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
+	{ .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
 	{ .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
 	{ .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
 	{ .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 9296624654a6..df7b5e3a57b9 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -209,6 +209,7 @@ enum hantro_enc_fmt {
 
 extern const struct hantro_variant imx8mq_vpu_g2_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant px30_vpu_variant;
 extern const struct hantro_variant rk3036_vpu_variant;
 extern const struct hantro_variant rk3066_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index e4e3b5e7689b..e7f56e30b4a8 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -16,6 +16,7 @@
 
 #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
 #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
+#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
 
 /*
  * Supported formats.
@@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
 	return 0;
 }
 
+static int px30_vpu_hw_init(struct hantro_dev *vpu)
+{
+	clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
+	return 0;
+}
+
 static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
@@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
 	"aclk", "hclk"
 };
 
+static const char * const px30_clk_names[] = {
+	"aclk", "hclk"
+};
+
 /* VDPU1/VEPU1 */
 
 const struct hantro_variant rk3036_vpu_variant = {
@@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
 	.clk_names = rockchip_vpu_clk_names,
 	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
 };
+
+const struct hantro_variant px30_vpu_variant = {
+	.enc_offset = 0x0,
+	.enc_fmts = rockchip_vpu_enc_fmts,
+	.num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
+	.dec_offset = 0x400,
+	.dec_fmts = rk3399_vpu_dec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
+	.codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
+		 HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+	.codec_ops = rk3399_vpu_codec_ops,
+	.irqs = rockchip_vpu2_irqs,
+	.num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
+	.init = px30_vpu_hw_init,
+	.clk_names = px30_clk_names,
+	.num_clocks = ARRAY_SIZE(px30_clk_names)
+};
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
@ 2021-06-24 18:26   ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:26 UTC (permalink / raw)
  To: linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
 drivers/staging/media/hantro/hantro_drv.c     |  1 +
 drivers/staging/media/hantro/hantro_hw.h      |  1 +
 .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
 3 files changed, 30 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 9b5415176bfe..8a2edd67f2c6 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
 
 static const struct of_device_id of_hantro_match[] = {
 #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
+	{ .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
 	{ .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
 	{ .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
 	{ .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 9296624654a6..df7b5e3a57b9 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -209,6 +209,7 @@ enum hantro_enc_fmt {
 
 extern const struct hantro_variant imx8mq_vpu_g2_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant px30_vpu_variant;
 extern const struct hantro_variant rk3036_vpu_variant;
 extern const struct hantro_variant rk3066_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index e4e3b5e7689b..e7f56e30b4a8 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -16,6 +16,7 @@
 
 #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
 #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
+#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
 
 /*
  * Supported formats.
@@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
 	return 0;
 }
 
+static int px30_vpu_hw_init(struct hantro_dev *vpu)
+{
+	clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
+	return 0;
+}
+
 static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
@@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
 	"aclk", "hclk"
 };
 
+static const char * const px30_clk_names[] = {
+	"aclk", "hclk"
+};
+
 /* VDPU1/VEPU1 */
 
 const struct hantro_variant rk3036_vpu_variant = {
@@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
 	.clk_names = rockchip_vpu_clk_names,
 	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
 };
+
+const struct hantro_variant px30_vpu_variant = {
+	.enc_offset = 0x0,
+	.enc_fmts = rockchip_vpu_enc_fmts,
+	.num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
+	.dec_offset = 0x400,
+	.dec_fmts = rk3399_vpu_dec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
+	.codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
+		 HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+	.codec_ops = rk3399_vpu_codec_ops,
+	.irqs = rockchip_vpu2_irqs,
+	.num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
+	.init = px30_vpu_hw_init,
+	.clk_names = px30_clk_names,
+	.num_clocks = ARRAY_SIZE(px30_clk_names)
+};
-- 
2.30.0


^ permalink raw reply related	[flat|nested] 54+ messages in thread

* Re: [PATCH 01/12] drm/panel: kd35t133: Add panel orientation support
  2021-06-24 18:26   ` Ezequiel Garcia
@ 2021-06-24 18:36     ` Heiko Stübner
  -1 siblings, 0 replies; 54+ messages in thread
From: Heiko Stübner @ 2021-06-24 18:36 UTC (permalink / raw)
  To: linux-media, dri-devel, Ezequiel Garcia
  Cc: Hans Verkuil, Philipp Zabel, Alex Bee, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, Ezequiel Garcia,
	kernel

Am Donnerstag, 24. Juni 2021, 20:26:01 CEST schrieb Ezequiel Garcia:
> Parse the device tree rotation specifier, and set a DRM
> connector orientation property. The property can then be read
> by compositors to apply hardware plane rotation or a GPU transform.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>

similar patch already applied for 5.14:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-elida-kd35t133.c?id=610d9c311b1387f8c4ac602fee1f2a1cb0508707

> ---
>  drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index fe5ac3ef9018..5987d28c874c 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -39,6 +39,7 @@
>  struct kd35t133 {
>  	struct device *dev;
>  	struct drm_panel panel;
> +	enum drm_panel_orientation orientation;
>  	struct gpio_desc *reset_gpio;
>  	struct regulator *vdd;
>  	struct regulator *iovcc;
> @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
>  	connector->display_info.width_mm = mode->width_mm;
>  	connector->display_info.height_mm = mode->height_mm;
>  	drm_mode_probed_add(connector, mode);
> +	drm_connector_set_panel_orientation(connector, ctx->orientation);
>  
>  	return 1;
>  }
> @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
>  		return ret;
>  	}
>  
> +	ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
> +	if (ret) {
> +		dev_err(dev, "%pOF: failed to get orientation %d\n", dev->of_node, ret);
> +		return ret;
> +	}
> +
>  	mipi_dsi_set_drvdata(dsi, ctx);
>  
>  	ctx->dev = dev;
> 





^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 01/12] drm/panel: kd35t133: Add panel orientation support
@ 2021-06-24 18:36     ` Heiko Stübner
  0 siblings, 0 replies; 54+ messages in thread
From: Heiko Stübner @ 2021-06-24 18:36 UTC (permalink / raw)
  To: linux-media, dri-devel, Ezequiel Garcia
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Am Donnerstag, 24. Juni 2021, 20:26:01 CEST schrieb Ezequiel Garcia:
> Parse the device tree rotation specifier, and set a DRM
> connector orientation property. The property can then be read
> by compositors to apply hardware plane rotation or a GPU transform.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>

similar patch already applied for 5.14:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-elida-kd35t133.c?id=610d9c311b1387f8c4ac602fee1f2a1cb0508707

> ---
>  drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index fe5ac3ef9018..5987d28c874c 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -39,6 +39,7 @@
>  struct kd35t133 {
>  	struct device *dev;
>  	struct drm_panel panel;
> +	enum drm_panel_orientation orientation;
>  	struct gpio_desc *reset_gpio;
>  	struct regulator *vdd;
>  	struct regulator *iovcc;
> @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
>  	connector->display_info.width_mm = mode->width_mm;
>  	connector->display_info.height_mm = mode->height_mm;
>  	drm_mode_probed_add(connector, mode);
> +	drm_connector_set_panel_orientation(connector, ctx->orientation);
>  
>  	return 1;
>  }
> @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
>  		return ret;
>  	}
>  
> +	ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
> +	if (ret) {
> +		dev_err(dev, "%pOF: failed to get orientation %d\n", dev->of_node, ret);
> +		return ret;
> +	}
> +
>  	mipi_dsi_set_drvdata(dsi, ctx);
>  
>  	ctx->dev = dev;
> 





^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
  2021-06-24 18:26   ` Ezequiel Garcia
@ 2021-06-24 18:37     ` Heiko Stübner
  -1 siblings, 0 replies; 54+ messages in thread
From: Heiko Stübner @ 2021-06-24 18:37 UTC (permalink / raw)
  To: linux-media, dri-devel, Ezequiel Garcia
  Cc: Hans Verkuil, Philipp Zabel, Alex Bee, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, Ezequiel Garcia,
	kernel

Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> The Odroid Go Advance panel is rotated, so let's reflect this
> in the device tree.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>

similar patch already applied for 5.14:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?id=edb39de5d731f147c7b08c4a5eb246ae1dbdd947

> ---
>  arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> index 49c97f76df77..cca19660e60a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> @@ -240,6 +240,7 @@ panel@0 {
>  		iovcc-supply = <&vcc_lcd>;
>  		reset-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
>  		vdd-supply = <&vcc_lcd>;
> +		rotation = <270>;
>  
>  		port {
>  			mipi_in_panel: endpoint {
> 





^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
@ 2021-06-24 18:37     ` Heiko Stübner
  0 siblings, 0 replies; 54+ messages in thread
From: Heiko Stübner @ 2021-06-24 18:37 UTC (permalink / raw)
  To: linux-media, dri-devel, Ezequiel Garcia
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Ezequiel Garcia, Alex Bee, Hans Verkuil, Thierry Reding, kernel,
	Sam Ravnborg, Chris Healy, maccraft123mc

Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> The Odroid Go Advance panel is rotated, so let's reflect this
> in the device tree.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>

similar patch already applied for 5.14:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?id=edb39de5d731f147c7b08c4a5eb246ae1dbdd947

> ---
>  arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> index 49c97f76df77..cca19660e60a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
> @@ -240,6 +240,7 @@ panel@0 {
>  		iovcc-supply = <&vcc_lcd>;
>  		reset-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
>  		vdd-supply = <&vcc_lcd>;
> +		rotation = <270>;
>  
>  		port {
>  			mipi_in_panel: endpoint {
> 





^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
  2021-06-24 18:37     ` Heiko Stübner
@ 2021-06-24 18:44       ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:44 UTC (permalink / raw)
  To: Heiko Stübner, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Alex Bee, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

On Thu, 2021-06-24 at 20:37 +0200, Heiko Stübner wrote:
> Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> > The Odroid Go Advance panel is rotated, so let's reflect this
> > in the device tree.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> 
> similar patch already applied for 5.14:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?id=edb39de5d731f147c7b08c4a5eb246ae1dbdd947

Great minds think alike! :)

Thanks,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
@ 2021-06-24 18:44       ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-24 18:44 UTC (permalink / raw)
  To: Heiko Stübner, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Alex Bee, Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg,
	Chris Healy, maccraft123mc

On Thu, 2021-06-24 at 20:37 +0200, Heiko Stübner wrote:
> Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> > The Odroid Go Advance panel is rotated, so let's reflect this
> > in the device tree.
> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> 
> similar patch already applied for 5.14:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?id=edb39de5d731f147c7b08c4a5eb246ae1dbdd947

Great minds think alike! :)

Thanks,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
  2021-06-24 18:26   ` Ezequiel Garcia
@ 2021-06-24 22:39     ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-24 22:39 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Ezequiel,

Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> to the RK3399 (Hantro G1/H1 with shuffled registers).
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   drivers/staging/media/hantro/hantro_drv.c     |  1 +
>   drivers/staging/media/hantro/hantro_hw.h      |  1 +
>   .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
>   3 files changed, 30 insertions(+)
>
> diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
> index 9b5415176bfe..8a2edd67f2c6 100644
> --- a/drivers/staging/media/hantro/hantro_drv.c
> +++ b/drivers/staging/media/hantro/hantro_drv.c
> @@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
>   
>   static const struct of_device_id of_hantro_match[] = {
>   #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> +	{ .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
>   	{ .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
>   	{ .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
>   	{ .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
> diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
> index 9296624654a6..df7b5e3a57b9 100644
> --- a/drivers/staging/media/hantro/hantro_hw.h
> +++ b/drivers/staging/media/hantro/hantro_hw.h
> @@ -209,6 +209,7 @@ enum hantro_enc_fmt {
>   
>   extern const struct hantro_variant imx8mq_vpu_g2_variant;
>   extern const struct hantro_variant imx8mq_vpu_variant;
> +extern const struct hantro_variant px30_vpu_variant;
>   extern const struct hantro_variant rk3036_vpu_variant;
>   extern const struct hantro_variant rk3066_vpu_variant;
>   extern const struct hantro_variant rk3288_vpu_variant;
> diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> index e4e3b5e7689b..e7f56e30b4a8 100644
> --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> @@ -16,6 +16,7 @@
>   
>   #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
>   #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> +#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
>   

Not sure it is required (besides semantics) to introduce a new 
*ACLK_MAX_FREQ here. rk3036_vpu_hw_init could be used to entirely 
replace px30_vpu_hw_init in px30_vpu_variant.

(Maybe we can find some more common names, after we know which variant 
combinations exist)

>   /*
>    * Supported formats.
> @@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
>   	return 0;
>   }
>   
> +static int px30_vpu_hw_init(struct hantro_dev *vpu)
> +{
> +	clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
> +	return 0;
> +}
> +
>   static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
>   {
>   	struct hantro_dev *vpu = ctx->dev;
> @@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
>   	"aclk", "hclk"
>   };
>   
> +static const char * const px30_clk_names[] = {
> +	"aclk", "hclk"
> +};
> +
>   /* VDPU1/VEPU1 */
>   
>   const struct hantro_variant rk3036_vpu_variant = {
> @@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
>   	.clk_names = rockchip_vpu_clk_names,
>   	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
>   };
> +
> +const struct hantro_variant px30_vpu_variant = {
> +	.enc_offset = 0x0,
> +	.enc_fmts = rockchip_vpu_enc_fmts,
> +	.num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
> +	.dec_offset = 0x400,
> +	.dec_fmts = rk3399_vpu_dec_fmts,
> +	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> +	.codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
> +		 HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> +	.codec_ops = rk3399_vpu_codec_ops,
> +	.irqs = rockchip_vpu2_irqs,
> +	.num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
> +	.init = px30_vpu_hw_init,
> +	.clk_names = px30_clk_names,
> +	.num_clocks = ARRAY_SIZE(px30_clk_names)
Better re-use rockchip_vpu_clk_names for these two.
> +};
Alex.

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
@ 2021-06-24 22:39     ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-24 22:39 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Ezequiel,

Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> to the RK3399 (Hantro G1/H1 with shuffled registers).
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   drivers/staging/media/hantro/hantro_drv.c     |  1 +
>   drivers/staging/media/hantro/hantro_hw.h      |  1 +
>   .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
>   3 files changed, 30 insertions(+)
>
> diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
> index 9b5415176bfe..8a2edd67f2c6 100644
> --- a/drivers/staging/media/hantro/hantro_drv.c
> +++ b/drivers/staging/media/hantro/hantro_drv.c
> @@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
>   
>   static const struct of_device_id of_hantro_match[] = {
>   #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> +	{ .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
>   	{ .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
>   	{ .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
>   	{ .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
> diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
> index 9296624654a6..df7b5e3a57b9 100644
> --- a/drivers/staging/media/hantro/hantro_hw.h
> +++ b/drivers/staging/media/hantro/hantro_hw.h
> @@ -209,6 +209,7 @@ enum hantro_enc_fmt {
>   
>   extern const struct hantro_variant imx8mq_vpu_g2_variant;
>   extern const struct hantro_variant imx8mq_vpu_variant;
> +extern const struct hantro_variant px30_vpu_variant;
>   extern const struct hantro_variant rk3036_vpu_variant;
>   extern const struct hantro_variant rk3066_vpu_variant;
>   extern const struct hantro_variant rk3288_vpu_variant;
> diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> index e4e3b5e7689b..e7f56e30b4a8 100644
> --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> @@ -16,6 +16,7 @@
>   
>   #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
>   #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> +#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
>   

Not sure it is required (besides semantics) to introduce a new 
*ACLK_MAX_FREQ here. rk3036_vpu_hw_init could be used to entirely 
replace px30_vpu_hw_init in px30_vpu_variant.

(Maybe we can find some more common names, after we know which variant 
combinations exist)

>   /*
>    * Supported formats.
> @@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
>   	return 0;
>   }
>   
> +static int px30_vpu_hw_init(struct hantro_dev *vpu)
> +{
> +	clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
> +	return 0;
> +}
> +
>   static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
>   {
>   	struct hantro_dev *vpu = ctx->dev;
> @@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
>   	"aclk", "hclk"
>   };
>   
> +static const char * const px30_clk_names[] = {
> +	"aclk", "hclk"
> +};
> +
>   /* VDPU1/VEPU1 */
>   
>   const struct hantro_variant rk3036_vpu_variant = {
> @@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
>   	.clk_names = rockchip_vpu_clk_names,
>   	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
>   };
> +
> +const struct hantro_variant px30_vpu_variant = {
> +	.enc_offset = 0x0,
> +	.enc_fmts = rockchip_vpu_enc_fmts,
> +	.num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
> +	.dec_offset = 0x400,
> +	.dec_fmts = rk3399_vpu_dec_fmts,
> +	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> +	.codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
> +		 HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> +	.codec_ops = rk3399_vpu_codec_ops,
> +	.irqs = rockchip_vpu2_irqs,
> +	.num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
> +	.init = px30_vpu_hw_init,
> +	.clk_names = px30_clk_names,
> +	.num_clocks = ARRAY_SIZE(px30_clk_names)
Better re-use rockchip_vpu_clk_names for these two.
> +};
Alex.

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-24 18:26   ` Ezequiel Garcia
@ 2021-06-24 23:13     ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-24 23:13 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Ezequiel,

Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> Given H.264 support for VDPU2 was just added, let's enable it.
> For now, this is only enabled on platform that don't have
> an RKVDEC core, such as RK3328.

Is there any reason, you do not want to enabe H.264 on RK3399? I know 
H.264 can be done by by rkvdec already, but from what I understand that 
shouldn't be an issue: The first decoder found that meets the 
requirements will be taken.

RK3328 has a variant (mpp calls it vdpu341) of rkvdec also which also 
supports H.264 (and HEVC/VP9). rkvdec driver needs a (much simpler) 
variant implementation in order to support it there also, since its has 
some additional registers.

Thanks,

Alex

>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   .../staging/media/hantro/rockchip_vpu_hw.c    | 26 ++++++++++++++++++-
>   1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> index 3ccc16413f42..e4e3b5e7689b 100644
> --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> @@ -162,6 +162,19 @@ static const struct hantro_fmt rk3399_vpu_dec_fmts[] = {
>   		.fourcc = V4L2_PIX_FMT_NV12,
>   		.codec_mode = HANTRO_MODE_NONE,
>   	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> +		.codec_mode = HANTRO_MODE_H264_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = 48,
> +			.max_width = 1920,
> +			.step_width = MB_DIM,
> +			.min_height = 48,
> +			.max_height = 1088,
> +			.step_height = MB_DIM,
> +		},
> +	},
>   	{
>   		.fourcc = V4L2_PIX_FMT_MPEG2_SLICE,
>   		.codec_mode = HANTRO_MODE_MPEG2_DEC,
> @@ -388,6 +401,12 @@ static const struct hantro_codec_ops rk3399_vpu_codec_ops[] = {
>   		.init = hantro_jpeg_enc_init,
>   		.exit = hantro_jpeg_enc_exit,
>   	},
> +	[HANTRO_MODE_H264_DEC] = {
> +		.run = rockchip_vpu2_h264_dec_run,
> +		.reset = rockchip_vpu2_dec_reset,
> +		.init = hantro_h264_dec_init,
> +		.exit = hantro_h264_dec_exit,
> +	},
>   	[HANTRO_MODE_MPEG2_DEC] = {
>   		.run = rockchip_vpu2_mpeg2_dec_run,
>   		.reset = rockchip_vpu2_dec_reset,
> @@ -433,6 +452,8 @@ static const char * const rockchip_vpu_clk_names[] = {
>   	"aclk", "hclk"
>   };
>   
> +/* VDPU1/VEPU1 */
> +
>   const struct hantro_variant rk3036_vpu_variant = {
>   	.dec_offset = 0x400,
>   	.dec_fmts = rk3066_vpu_dec_fmts,
> @@ -495,11 +516,14 @@ const struct hantro_variant rk3288_vpu_variant = {
>   	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
>   };
>   
> +/* VDPU2/VEPU2 */
> +
>   const struct hantro_variant rk3328_vpu_variant = {
>   	.dec_offset = 0x400,
>   	.dec_fmts = rk3399_vpu_dec_fmts,
>   	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> -	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER,
> +	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
> +		 HANTRO_H264_DECODER,
>   	.codec_ops = rk3399_vpu_codec_ops,
>   	.irqs = rockchip_vdpu2_irqs,
>   	.num_irqs = ARRAY_SIZE(rockchip_vdpu2_irqs),

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-24 23:13     ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-24 23:13 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Ezequiel,

Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> Given H.264 support for VDPU2 was just added, let's enable it.
> For now, this is only enabled on platform that don't have
> an RKVDEC core, such as RK3328.

Is there any reason, you do not want to enabe H.264 on RK3399? I know 
H.264 can be done by by rkvdec already, but from what I understand that 
shouldn't be an issue: The first decoder found that meets the 
requirements will be taken.

RK3328 has a variant (mpp calls it vdpu341) of rkvdec also which also 
supports H.264 (and HEVC/VP9). rkvdec driver needs a (much simpler) 
variant implementation in order to support it there also, since its has 
some additional registers.

Thanks,

Alex

>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   .../staging/media/hantro/rockchip_vpu_hw.c    | 26 ++++++++++++++++++-
>   1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> index 3ccc16413f42..e4e3b5e7689b 100644
> --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> @@ -162,6 +162,19 @@ static const struct hantro_fmt rk3399_vpu_dec_fmts[] = {
>   		.fourcc = V4L2_PIX_FMT_NV12,
>   		.codec_mode = HANTRO_MODE_NONE,
>   	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> +		.codec_mode = HANTRO_MODE_H264_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = 48,
> +			.max_width = 1920,
> +			.step_width = MB_DIM,
> +			.min_height = 48,
> +			.max_height = 1088,
> +			.step_height = MB_DIM,
> +		},
> +	},
>   	{
>   		.fourcc = V4L2_PIX_FMT_MPEG2_SLICE,
>   		.codec_mode = HANTRO_MODE_MPEG2_DEC,
> @@ -388,6 +401,12 @@ static const struct hantro_codec_ops rk3399_vpu_codec_ops[] = {
>   		.init = hantro_jpeg_enc_init,
>   		.exit = hantro_jpeg_enc_exit,
>   	},
> +	[HANTRO_MODE_H264_DEC] = {
> +		.run = rockchip_vpu2_h264_dec_run,
> +		.reset = rockchip_vpu2_dec_reset,
> +		.init = hantro_h264_dec_init,
> +		.exit = hantro_h264_dec_exit,
> +	},
>   	[HANTRO_MODE_MPEG2_DEC] = {
>   		.run = rockchip_vpu2_mpeg2_dec_run,
>   		.reset = rockchip_vpu2_dec_reset,
> @@ -433,6 +452,8 @@ static const char * const rockchip_vpu_clk_names[] = {
>   	"aclk", "hclk"
>   };
>   
> +/* VDPU1/VEPU1 */
> +
>   const struct hantro_variant rk3036_vpu_variant = {
>   	.dec_offset = 0x400,
>   	.dec_fmts = rk3066_vpu_dec_fmts,
> @@ -495,11 +516,14 @@ const struct hantro_variant rk3288_vpu_variant = {
>   	.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
>   };
>   
> +/* VDPU2/VEPU2 */
> +
>   const struct hantro_variant rk3328_vpu_variant = {
>   	.dec_offset = 0x400,
>   	.dec_fmts = rk3399_vpu_dec_fmts,
>   	.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> -	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER,
> +	.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
> +		 HANTRO_H264_DECODER,
>   	.codec_ops = rk3399_vpu_codec_ops,
>   	.irqs = rockchip_vdpu2_irqs,
>   	.num_irqs = ARRAY_SIZE(rockchip_vdpu2_irqs),

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
  2021-06-24 18:26   ` Ezequiel Garcia
@ 2021-06-25  9:21     ` Dafna Hirschfeld
  -1 siblings, 0 replies; 54+ messages in thread
From: Dafna Hirschfeld @ 2021-06-25  9:21 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel

Hi,

On 24.06.21 21:26, Ezequiel Garcia wrote:
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> 
> The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
> and an encoder (VEPU2).
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> index b88172a59de7..3b9c5aa91fcc 100644
> --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> @@ -28,6 +28,9 @@ properties:
>         - items:
>             - const: rockchip,rk3228-vpu
>             - const: rockchip,rk3399-vpu
> +      - items:
> +          - const: rockchip,px30-vpu
> +          - const: rockchip,rk3399-vpu

This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?

Thanks,
Dafna

>   
>     reg:
>       maxItems: 1
> 

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
@ 2021-06-25  9:21     ` Dafna Hirschfeld
  0 siblings, 0 replies; 54+ messages in thread
From: Dafna Hirschfeld @ 2021-06-25  9:21 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Alex Bee, Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg,
	Chris Healy, maccraft123mc

Hi,

On 24.06.21 21:26, Ezequiel Garcia wrote:
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> 
> The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
> and an encoder (VEPU2).
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
>   Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> index b88172a59de7..3b9c5aa91fcc 100644
> --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> @@ -28,6 +28,9 @@ properties:
>         - items:
>             - const: rockchip,rk3228-vpu
>             - const: rockchip,rk3399-vpu
> +      - items:
> +          - const: rockchip,px30-vpu
> +          - const: rockchip,rk3399-vpu

This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?

Thanks,
Dafna

>   
>     reg:
>       maxItems: 1
> 

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-24 23:13     ` Alex Bee
@ 2021-06-26  0:46       ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:46 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel, Nicolas Dufresne
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

(Adding Nicolas)

Hi Alex,

On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > Given H.264 support for VDPU2 was just added, let's enable it.
> > For now, this is only enabled on platform that don't have
> > an RKVDEC core, such as RK3328.
> 
> Is there any reason, you do not want to enabe H.264 on RK3399? I know 
> H.264 can be done by by rkvdec already, but from what I understand that 
> shouldn't be an issue: The first decoder found that meets the 
> requirements will be taken.
> 

Thanks a lot the review.

I really doubt userspace stacks are readily supporting that strategy.

The first decoder device supporting the codec format will be selected,
I doubt features such as profile and levels are checked to decide
which decoder to use.

I'd rather play safe on the kernel side and avoid offering
two competing devices for the same codec.

Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-26  0:46       ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:46 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel, Nicolas Dufresne
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

(Adding Nicolas)

Hi Alex,

On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > Given H.264 support for VDPU2 was just added, let's enable it.
> > For now, this is only enabled on platform that don't have
> > an RKVDEC core, such as RK3328.
> 
> Is there any reason, you do not want to enabe H.264 on RK3399? I know 
> H.264 can be done by by rkvdec already, but from what I understand that 
> shouldn't be an issue: The first decoder found that meets the 
> requirements will be taken.
> 

Thanks a lot the review.

I really doubt userspace stacks are readily supporting that strategy.

The first decoder device supporting the codec format will be selected,
I doubt features such as profile and levels are checked to decide
which decoder to use.

I'd rather play safe on the kernel side and avoid offering
two competing devices for the same codec.

Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
  2021-06-25  9:21     ` Dafna Hirschfeld
@ 2021-06-26  0:47       ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:47 UTC (permalink / raw)
  To: Dafna Hirschfeld, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, Alex Bee,
	maccraft123mc, Chris Healy, Paul Kocialkowski, Jernej Skrabec,
	Jonas Karlman, Thierry Reding, Sam Ravnborg, David Airlie,
	kernel

Hey Dafna,

Thanks a lot for reviewing this.

On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
> Hi,
> 
> On 24.06.21 21:26, Ezequiel Garcia wrote:
> > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > 
> > The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
> > and an encoder (VEPU2).
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> > ---
> >   Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > index b88172a59de7..3b9c5aa91fcc 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > @@ -28,6 +28,9 @@ properties:
> >         - items:
> >             - const: rockchip,rk3228-vpu
> >             - const: rockchip,rk3399-vpu
> > +      - items:
> > +          - const: rockchip,px30-vpu
> > +          - const: rockchip,rk3399-vpu
> 
> This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?
> 

What we are mandating here is that "rockchip,px30-vpu" can only be used
with "rockchip,rk3399-vpu".

I.e.:

  compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";

-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
@ 2021-06-26  0:47       ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:47 UTC (permalink / raw)
  To: Dafna Hirschfeld, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Alex Bee, Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg,
	Chris Healy, maccraft123mc

Hey Dafna,

Thanks a lot for reviewing this.

On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
> Hi,
> 
> On 24.06.21 21:26, Ezequiel Garcia wrote:
> > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > 
> > The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
> > and an encoder (VEPU2).
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> > ---
> >   Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > index b88172a59de7..3b9c5aa91fcc 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > @@ -28,6 +28,9 @@ properties:
> >         - items:
> >             - const: rockchip,rk3228-vpu
> >             - const: rockchip,rk3399-vpu
> > +      - items:
> > +          - const: rockchip,px30-vpu
> > +          - const: rockchip,rk3399-vpu
> 
> This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?
> 

What we are mandating here is that "rockchip,px30-vpu" can only be used
with "rockchip,rk3399-vpu".

I.e.:

  compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";

-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
  2021-06-24 22:39     ` Alex Bee
@ 2021-06-26  0:49       ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:49 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Alex,

On Fri, 2021-06-25 at 00:39 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > 
> > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > to the RK3399 (Hantro G1/H1 with shuffled registers).
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> > ---
> >   drivers/staging/media/hantro/hantro_drv.c     |  1 +
> >   drivers/staging/media/hantro/hantro_hw.h      |  1 +
> >   .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
> >   3 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
> > index 9b5415176bfe..8a2edd67f2c6 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
> >   
> >   static const struct of_device_id of_hantro_match[] = {
> >   #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> > +       { .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
> >         { .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
> >         { .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
> >         { .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
> > diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
> > index 9296624654a6..df7b5e3a57b9 100644
> > --- a/drivers/staging/media/hantro/hantro_hw.h
> > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > @@ -209,6 +209,7 @@ enum hantro_enc_fmt {
> >   
> >   extern const struct hantro_variant imx8mq_vpu_g2_variant;
> >   extern const struct hantro_variant imx8mq_vpu_variant;
> > +extern const struct hantro_variant px30_vpu_variant;
> >   extern const struct hantro_variant rk3036_vpu_variant;
> >   extern const struct hantro_variant rk3066_vpu_variant;
> >   extern const struct hantro_variant rk3288_vpu_variant;
> > diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > index e4e3b5e7689b..e7f56e30b4a8 100644
> > --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > @@ -16,6 +16,7 @@
> >   
> >   #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
> >   #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> > +#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
> >   
> 
> Not sure it is required (besides semantics) to introduce a new 
> *ACLK_MAX_FREQ here. rk3036_vpu_hw_init could be used to entirely 
> replace px30_vpu_hw_init in px30_vpu_variant.
> 
> (Maybe we can find some more common names, after we know which variant 
> combinations exist)
> 

TBH, I considered getting rid of all the macros and just use something
like 300 * MHZ.

Another alternative is to encode the clock rate in struct hantro_variant
itself.

In any case, I don't see this adding any value, so maybe I'll
just reuse rk3036_vpu_hw_init as you suggest.

> >   /*
> >    * Supported formats.
> > @@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
> >         return 0;
> >   }
> >   
> > +static int px30_vpu_hw_init(struct hantro_dev *vpu)
> > +{
> > +       clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
> > +       return 0;
> > +}
> > +
> >   static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
> >   {
> >         struct hantro_dev *vpu = ctx->dev;
> > @@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
> >         "aclk", "hclk"
> >   };
> >   
> > +static const char * const px30_clk_names[] = {
> > +       "aclk", "hclk"
> > +};
> > +
> >   /* VDPU1/VEPU1 */
> >   
> >   const struct hantro_variant rk3036_vpu_variant = {
> > @@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
> >         .clk_names = rockchip_vpu_clk_names,
> >         .num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
> >   };
> > +
> > +const struct hantro_variant px30_vpu_variant = {
> > +       .enc_offset = 0x0,
> > +       .enc_fmts = rockchip_vpu_enc_fmts,
> > +       .num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
> > +       .dec_offset = 0x400,
> > +       .dec_fmts = rk3399_vpu_dec_fmts,
> > +       .num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> > +       .codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
> > +                HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> > +       .codec_ops = rk3399_vpu_codec_ops,
> > +       .irqs = rockchip_vpu2_irqs,
> > +       .num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
> > +       .init = px30_vpu_hw_init,
> > +       .clk_names = px30_clk_names,
> > +       .num_clocks = ARRAY_SIZE(px30_clk_names)
> Better re-use rockchip_vpu_clk_names for these two.

Ah, this slipped through. You are right of course.

-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
@ 2021-06-26  0:49       ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-26  0:49 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Alex,

On Fri, 2021-06-25 at 00:39 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > 
> > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > to the RK3399 (Hantro G1/H1 with shuffled registers).
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> > ---
> >   drivers/staging/media/hantro/hantro_drv.c     |  1 +
> >   drivers/staging/media/hantro/hantro_hw.h      |  1 +
> >   .../staging/media/hantro/rockchip_vpu_hw.c    | 28 +++++++++++++++++++
> >   3 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
> > index 9b5415176bfe..8a2edd67f2c6 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
> >   
> >   static const struct of_device_id of_hantro_match[] = {
> >   #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> > +       { .compatible = "rockchip,px30-vpu",   .data = &px30_vpu_variant, },
> >         { .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
> >         { .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
> >         { .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
> > diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
> > index 9296624654a6..df7b5e3a57b9 100644
> > --- a/drivers/staging/media/hantro/hantro_hw.h
> > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > @@ -209,6 +209,7 @@ enum hantro_enc_fmt {
> >   
> >   extern const struct hantro_variant imx8mq_vpu_g2_variant;
> >   extern const struct hantro_variant imx8mq_vpu_variant;
> > +extern const struct hantro_variant px30_vpu_variant;
> >   extern const struct hantro_variant rk3036_vpu_variant;
> >   extern const struct hantro_variant rk3066_vpu_variant;
> >   extern const struct hantro_variant rk3288_vpu_variant;
> > diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > index e4e3b5e7689b..e7f56e30b4a8 100644
> > --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > @@ -16,6 +16,7 @@
> >   
> >   #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
> >   #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> > +#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
> >   
> 
> Not sure it is required (besides semantics) to introduce a new 
> *ACLK_MAX_FREQ here. rk3036_vpu_hw_init could be used to entirely 
> replace px30_vpu_hw_init in px30_vpu_variant.
> 
> (Maybe we can find some more common names, after we know which variant 
> combinations exist)
> 

TBH, I considered getting rid of all the macros and just use something
like 300 * MHZ.

Another alternative is to encode the clock rate in struct hantro_variant
itself.

In any case, I don't see this adding any value, so maybe I'll
just reuse rk3036_vpu_hw_init as you suggest.

> >   /*
> >    * Supported formats.
> > @@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
> >         return 0;
> >   }
> >   
> > +static int px30_vpu_hw_init(struct hantro_dev *vpu)
> > +{
> > +       clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
> > +       return 0;
> > +}
> > +
> >   static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
> >   {
> >         struct hantro_dev *vpu = ctx->dev;
> > @@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
> >         "aclk", "hclk"
> >   };
> >   
> > +static const char * const px30_clk_names[] = {
> > +       "aclk", "hclk"
> > +};
> > +
> >   /* VDPU1/VEPU1 */
> >   
> >   const struct hantro_variant rk3036_vpu_variant = {
> > @@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
> >         .clk_names = rockchip_vpu_clk_names,
> >         .num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
> >   };
> > +
> > +const struct hantro_variant px30_vpu_variant = {
> > +       .enc_offset = 0x0,
> > +       .enc_fmts = rockchip_vpu_enc_fmts,
> > +       .num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
> > +       .dec_offset = 0x400,
> > +       .dec_fmts = rk3399_vpu_dec_fmts,
> > +       .num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> > +       .codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
> > +                HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> > +       .codec_ops = rk3399_vpu_codec_ops,
> > +       .irqs = rockchip_vpu2_irqs,
> > +       .num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
> > +       .init = px30_vpu_hw_init,
> > +       .clk_names = px30_clk_names,
> > +       .num_clocks = ARRAY_SIZE(px30_clk_names)
> Better re-use rockchip_vpu_clk_names for these two.

Ah, this slipped through. You are right of course.

-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-26  0:46       ` Ezequiel Garcia
@ 2021-06-26  8:33         ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  8:33 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel, Nicolas Dufresne
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Ezequiel,

Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
> (Adding Nicolas)
>
> Hi Alex,
>
> On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
>> Hi Ezequiel,
>>
>> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
>>> Given H.264 support for VDPU2 was just added, let's enable it.
>>> For now, this is only enabled on platform that don't have
>>> an RKVDEC core, such as RK3328.
>> Is there any reason, you do not want to enabe H.264 on RK3399? I know
>> H.264 can be done by by rkvdec already, but from what I understand that
>> shouldn't be an issue: The first decoder found that meets the
>> requirements will be taken.
>>
> Thanks a lot the review.
>
> I really doubt userspace stacks are readily supporting that strategy.
>
> The first decoder device supporting the codec format will be selected,
> I doubt features such as profile and levels are checked to decide
> which decoder to use.
>
> I'd rather play safe on the kernel side and avoid offering
> two competing devices for the same codec.

I wasn't aware of that. Current ffmpeg v4l2_request implementation seems 
to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to 
decode up to 1920x1088 only if hantro decoder is picked/checked first.

Thanks for pointing that out.

Alex

> Kindly,
> Ezequiel
>

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-26  8:33         ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  8:33 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel, Nicolas Dufresne
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Ezequiel,

Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
> (Adding Nicolas)
>
> Hi Alex,
>
> On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
>> Hi Ezequiel,
>>
>> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
>>> Given H.264 support for VDPU2 was just added, let's enable it.
>>> For now, this is only enabled on platform that don't have
>>> an RKVDEC core, such as RK3328.
>> Is there any reason, you do not want to enabe H.264 on RK3399? I know
>> H.264 can be done by by rkvdec already, but from what I understand that
>> shouldn't be an issue: The first decoder found that meets the
>> requirements will be taken.
>>
> Thanks a lot the review.
>
> I really doubt userspace stacks are readily supporting that strategy.
>
> The first decoder device supporting the codec format will be selected,
> I doubt features such as profile and levels are checked to decide
> which decoder to use.
>
> I'd rather play safe on the kernel side and avoid offering
> two competing devices for the same codec.

I wasn't aware of that. Current ffmpeg v4l2_request implementation seems 
to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to 
decode up to 1920x1088 only if hantro decoder is picked/checked first.

Thanks for pointing that out.

Alex

> Kindly,
> Ezequiel
>

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
  2021-06-26  0:47       ` Ezequiel Garcia
@ 2021-06-26  8:49         ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  8:49 UTC (permalink / raw)
  To: Ezequiel Garcia, Dafna Hirschfeld, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Ezequiel,

Am 26.06.21 um 02:47 schrieb Ezequiel Garcia:
> Hey Dafna,
>
> Thanks a lot for reviewing this.
>
> On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
>> Hi,
>>
>> On 24.06.21 21:26, Ezequiel Garcia wrote:
>>> From: Paul Kocialkowski<paul.kocialkowski@bootlin.com>
>>>
>>> The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
>>> and an encoder (VEPU2).
>>>
>>> Signed-off-by: Paul Kocialkowski<paul.kocialkowski@bootlin.com>
>>> Signed-off-by: Ezequiel Garcia<ezequiel@collabora.com>
>>> ---
>>>    Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> index b88172a59de7..3b9c5aa91fcc 100644
>>> --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> @@ -28,6 +28,9 @@ properties:
>>>          - items:
>>>              - const: rockchip,rk3228-vpu
>>>              - const: rockchip,rk3399-vpu
>>> +      - items:
>>> +          - const: rockchip,px30-vpu
>>> +          - const: rockchip,rk3399-vpu
>> This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?
>>
> What we are mandating here is that "rockchip,px30-vpu" can only be used
> with "rockchip,rk3399-vpu".
>
> I.e.:
>
>    compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
>
So why not making the already existing to:

       - items:
           - enum:
               - rockchip,px30-vpu
               - rockchip,rk3228-vpu
           - const: rockchip,rk3399-vpu

Alex

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
@ 2021-06-26  8:49         ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  8:49 UTC (permalink / raw)
  To: Ezequiel Garcia, Dafna Hirschfeld, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Ezequiel,

Am 26.06.21 um 02:47 schrieb Ezequiel Garcia:
> Hey Dafna,
>
> Thanks a lot for reviewing this.
>
> On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
>> Hi,
>>
>> On 24.06.21 21:26, Ezequiel Garcia wrote:
>>> From: Paul Kocialkowski<paul.kocialkowski@bootlin.com>
>>>
>>> The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
>>> and an encoder (VEPU2).
>>>
>>> Signed-off-by: Paul Kocialkowski<paul.kocialkowski@bootlin.com>
>>> Signed-off-by: Ezequiel Garcia<ezequiel@collabora.com>
>>> ---
>>>    Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> index b88172a59de7..3b9c5aa91fcc 100644
>>> --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
>>> @@ -28,6 +28,9 @@ properties:
>>>          - items:
>>>              - const: rockchip,rk3228-vpu
>>>              - const: rockchip,rk3399-vpu
>>> +      - items:
>>> +          - const: rockchip,px30-vpu
>>> +          - const: rockchip,rk3399-vpu
>> This rk3399 compatible is already mentioned in the last 'items' list, should we add it again?
>>
> What we are mandating here is that "rockchip,px30-vpu" can only be used
> with "rockchip,rk3399-vpu".
>
> I.e.:
>
>    compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
>
So why not making the already existing to:

       - items:
           - enum:
               - rockchip,px30-vpu
               - rockchip,rk3228-vpu
           - const: rockchip,rk3399-vpu

Alex

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go)
  2021-06-24 18:26 ` Ezequiel Garcia
@ 2021-06-26  9:17   ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  9:17 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel


Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> This series adds support for H.264 decoding on the PX30, RK3328
> and RK3326 platforms, enabling the VDPU2 core.
>
> Given it's tested on the Odroid Advance Go, patches 1 and 2
> add the basic support to report the panel orientation to
> userspace (Heiko, if you like them, feel free to pick them).
> Weston (for instance) picks up the orientation automagically
> and rotates the render.
>
> Patches 3 and 4 are just low-hanging fruit that was on my backlog.
>
> Patches 5, 6 and 7 add some helpers to avoid duplicating some processes
> between Hantro G1 and VDPU2. Patches 8 and 9 enable the VDPU2 H.264.
> The implementation is based on a patch from Jonas Karlman [1], which
> I forwarded ported to mainline.
>
> Finally, patches 10 to 12 add support for the VPU on Rockchip PX30 SoCs.
> These patches are based on patches submitted by Paul Kocialkowski [2],
> which I ported and adjusted a bit.
>
> Tested on i.MX8MQ EVK and RK3326 Odroid Advance Go, the latter
> is able to decode a 1080p sample at ~100fps nicely.
>
> Fluster conformance testing is looking good as well, and producing
> expected results:
>
> RK3326:
>    Ran 135 tests in 480.067s
>    FAILED (failures=9, errors=54)
>
> i.MX8MQ:
>    Ran 135 tests in 337.491s
>    FAILED (failures=9, errors=54)
>
> [1] https://lore.kernel.org/linux-media/HE1PR06MB40119DE07D38060F531D1070ACBF0@HE1PR06MB4011.eurprd06.prod.outlook.com/
> [2] https://lore.kernel.org/patchwork/cover/1361795/

FWIW: Patches 03/12 - 09/12 are

Tested-by: Alex Bee <knaerzche@gmail.com>

> Ezequiel Garcia (8):
>    drm/panel: kd35t133: Add panel orientation support
>    arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
>    hantro: vp8: Move noisy WARN_ON to vpu_debug
>    hantro: Make struct hantro_variant.init() optional
>    media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
>    media: hantro: h264: Move DPB valid and long-term bitmaps
>    media: hantro: h264: Move reference picture number to a helper
>    media: hantro: Enable H.264 on Rockchip VDPU2
>
> Jonas Karlman (1):
>    media: hantro: Add H.264 support for Rockchip VDPU2
>
> Paul Kocialkowski (3):
>    dt-bindings: media: rockchip-vpu: Add PX30 compatible
>    arm64: dts: rockchip: Add VPU support for the PX30
>    media: hantro: Add support for the Rockchip PX30
>
>   .../bindings/media/rockchip-vpu.yaml          |   3 +
>   arch/arm64/boot/dts/rockchip/px30.dtsi        |  23 +
>   .../boot/dts/rockchip/rk3326-odroid-go2.dts   |   1 +
>   drivers/gpu/drm/panel/panel-elida-kd35t133.c  |   8 +
>   drivers/staging/media/hantro/Makefile         |   1 +
>   drivers/staging/media/hantro/hantro.h         |   4 +-
>   drivers/staging/media/hantro/hantro_drv.c     |  11 +-
>   .../staging/media/hantro/hantro_g1_h264_dec.c |  48 +-
>   .../staging/media/hantro/hantro_g1_vp8_dec.c  |  31 +-
>   drivers/staging/media/hantro/hantro_h264.c    |  24 +
>   drivers/staging/media/hantro/hantro_hw.h      |   8 +
>   .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
>   .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   |  32 +-
>   .../staging/media/hantro/rockchip_vpu_hw.c    |  54 +-
>   .../staging/media/hantro/sama5d4_vdec_hw.c    |   6 -
>   15 files changed, 671 insertions(+), 74 deletions(-)
>   create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
>

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go)
@ 2021-06-26  9:17   ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-26  9:17 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc


Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> This series adds support for H.264 decoding on the PX30, RK3328
> and RK3326 platforms, enabling the VDPU2 core.
>
> Given it's tested on the Odroid Advance Go, patches 1 and 2
> add the basic support to report the panel orientation to
> userspace (Heiko, if you like them, feel free to pick them).
> Weston (for instance) picks up the orientation automagically
> and rotates the render.
>
> Patches 3 and 4 are just low-hanging fruit that was on my backlog.
>
> Patches 5, 6 and 7 add some helpers to avoid duplicating some processes
> between Hantro G1 and VDPU2. Patches 8 and 9 enable the VDPU2 H.264.
> The implementation is based on a patch from Jonas Karlman [1], which
> I forwarded ported to mainline.
>
> Finally, patches 10 to 12 add support for the VPU on Rockchip PX30 SoCs.
> These patches are based on patches submitted by Paul Kocialkowski [2],
> which I ported and adjusted a bit.
>
> Tested on i.MX8MQ EVK and RK3326 Odroid Advance Go, the latter
> is able to decode a 1080p sample at ~100fps nicely.
>
> Fluster conformance testing is looking good as well, and producing
> expected results:
>
> RK3326:
>    Ran 135 tests in 480.067s
>    FAILED (failures=9, errors=54)
>
> i.MX8MQ:
>    Ran 135 tests in 337.491s
>    FAILED (failures=9, errors=54)
>
> [1] https://lore.kernel.org/linux-media/HE1PR06MB40119DE07D38060F531D1070ACBF0@HE1PR06MB4011.eurprd06.prod.outlook.com/
> [2] https://lore.kernel.org/patchwork/cover/1361795/

FWIW: Patches 03/12 - 09/12 are

Tested-by: Alex Bee <knaerzche@gmail.com>

> Ezequiel Garcia (8):
>    drm/panel: kd35t133: Add panel orientation support
>    arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
>    hantro: vp8: Move noisy WARN_ON to vpu_debug
>    hantro: Make struct hantro_variant.init() optional
>    media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
>    media: hantro: h264: Move DPB valid and long-term bitmaps
>    media: hantro: h264: Move reference picture number to a helper
>    media: hantro: Enable H.264 on Rockchip VDPU2
>
> Jonas Karlman (1):
>    media: hantro: Add H.264 support for Rockchip VDPU2
>
> Paul Kocialkowski (3):
>    dt-bindings: media: rockchip-vpu: Add PX30 compatible
>    arm64: dts: rockchip: Add VPU support for the PX30
>    media: hantro: Add support for the Rockchip PX30
>
>   .../bindings/media/rockchip-vpu.yaml          |   3 +
>   arch/arm64/boot/dts/rockchip/px30.dtsi        |  23 +
>   .../boot/dts/rockchip/rk3326-odroid-go2.dts   |   1 +
>   drivers/gpu/drm/panel/panel-elida-kd35t133.c  |   8 +
>   drivers/staging/media/hantro/Makefile         |   1 +
>   drivers/staging/media/hantro/hantro.h         |   4 +-
>   drivers/staging/media/hantro/hantro_drv.c     |  11 +-
>   .../staging/media/hantro/hantro_g1_h264_dec.c |  48 +-
>   .../staging/media/hantro/hantro_g1_vp8_dec.c  |  31 +-
>   drivers/staging/media/hantro/hantro_h264.c    |  24 +
>   drivers/staging/media/hantro/hantro_hw.h      |   8 +
>   .../media/hantro/rockchip_vpu2_hw_h264_dec.c  | 491 ++++++++++++++++++
>   .../media/hantro/rockchip_vpu2_hw_vp8_dec.c   |  32 +-
>   .../staging/media/hantro/rockchip_vpu_hw.c    |  54 +-
>   .../staging/media/hantro/sama5d4_vdec_hw.c    |   6 -
>   15 files changed, 671 insertions(+), 74 deletions(-)
>   create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
>

^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-26  8:33         ` Alex Bee
@ 2021-06-29 12:28           ` Ezequiel Garcia
  -1 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-29 12:28 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel, Nicolas Dufresne
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jernej Skrabec, Jonas Karlman,
	Thierry Reding, Sam Ravnborg, David Airlie, kernel

Hi Alex,

On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
> > (Adding Nicolas)
> > 
> > Hi Alex,
> > 
> > On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> > > Hi Ezequiel,
> > > 
> > > Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > > > Given H.264 support for VDPU2 was just added, let's enable it.
> > > > For now, this is only enabled on platform that don't have
> > > > an RKVDEC core, such as RK3328.
> > > Is there any reason, you do not want to enabe H.264 on RK3399? I know
> > > H.264 can be done by by rkvdec already, but from what I understand that
> > > shouldn't be an issue: The first decoder found that meets the
> > > requirements will be taken.
> > > 
> > Thanks a lot the review.
> > 
> > I really doubt userspace stacks are readily supporting that strategy.
> > 
> > The first decoder device supporting the codec format will be selected,
> > I doubt features such as profile and levels are checked to decide
> > which decoder to use.
> > 
> > I'd rather play safe on the kernel side and avoid offering
> > two competing devices for the same codec.
> 
> I wasn't aware of that. Current ffmpeg v4l2_request implementation seems 
> to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to 
> decode up to 1920x1088 only if hantro decoder is picked/checked first.
> 

Speaking of ffmpeg, now that MPEG-2, VP8 and H.264 control interfaces
are stable, I think one of the next priorities would be to push Jonas'
ffmpeg patches.

It would be really cool if someone could take the lead on that front,
as it would reduce kodi's out of tree stack, enable mpv, and so on.
-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-29 12:28           ` Ezequiel Garcia
  0 siblings, 0 replies; 54+ messages in thread
From: Ezequiel Garcia @ 2021-06-29 12:28 UTC (permalink / raw)
  To: Alex Bee, linux-media, dri-devel, Nicolas Dufresne
  Cc: Paul Kocialkowski, Jernej Skrabec, Jonas Karlman, David Airlie,
	Hans Verkuil, Thierry Reding, kernel, Sam Ravnborg, Chris Healy,
	maccraft123mc

Hi Alex,

On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
> Hi Ezequiel,
> 
> Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
> > (Adding Nicolas)
> > 
> > Hi Alex,
> > 
> > On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> > > Hi Ezequiel,
> > > 
> > > Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > > > Given H.264 support for VDPU2 was just added, let's enable it.
> > > > For now, this is only enabled on platform that don't have
> > > > an RKVDEC core, such as RK3328.
> > > Is there any reason, you do not want to enabe H.264 on RK3399? I know
> > > H.264 can be done by by rkvdec already, but from what I understand that
> > > shouldn't be an issue: The first decoder found that meets the
> > > requirements will be taken.
> > > 
> > Thanks a lot the review.
> > 
> > I really doubt userspace stacks are readily supporting that strategy.
> > 
> > The first decoder device supporting the codec format will be selected,
> > I doubt features such as profile and levels are checked to decide
> > which decoder to use.
> > 
> > I'd rather play safe on the kernel side and avoid offering
> > two competing devices for the same codec.
> 
> I wasn't aware of that. Current ffmpeg v4l2_request implementation seems 
> to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to 
> decode up to 1920x1088 only if hantro decoder is picked/checked first.
> 

Speaking of ffmpeg, now that MPEG-2, VP8 and H.264 control interfaces
are stable, I think one of the next priorities would be to push Jonas'
ffmpeg patches.

It would be really cool if someone could take the lead on that front,
as it would reduce kodi's out of tree stack, enable mpv, and so on.
-- 
Kindly,
Ezequiel


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
  2021-06-29 12:28           ` Ezequiel Garcia
@ 2021-06-30 11:36             ` Alex Bee
  -1 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-30 11:36 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel, Nicolas Dufresne,
	Jernej Skrabec
  Cc: Hans Verkuil, Philipp Zabel, Heiko Stuebner, maccraft123mc,
	Chris Healy, Paul Kocialkowski, Jonas Karlman, Thierry Reding,
	Sam Ravnborg, David Airlie, kernel

Hi Ezequiel,

Am 29.06.21 um 14:28 schrieb Ezequiel Garcia:
> Hi Alex,
>
> On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
>> Hi Ezequiel,
>>
>> Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
>>> (Adding Nicolas)
>>>
>>> Hi Alex,
>>>
>>> On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
>>>> Hi Ezequiel,
>>>>
>>>> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
>>>>> Given H.264 support for VDPU2 was just added, let's enable it.
>>>>> For now, this is only enabled on platform that don't have
>>>>> an RKVDEC core, such as RK3328.
>>>> Is there any reason, you do not want to enabe H.264 on RK3399? I know
>>>> H.264 can be done by by rkvdec already, but from what I understand that
>>>> shouldn't be an issue: The first decoder found that meets the
>>>> requirements will be taken.
>>>>
>>> Thanks a lot the review.
>>>
>>> I really doubt userspace stacks are readily supporting that strategy.
>>>
>>> The first decoder device supporting the codec format will be selected,
>>> I doubt features such as profile and levels are checked to decide
>>> which decoder to use.
>>>
>>> I'd rather play safe on the kernel side and avoid offering
>>> two competing devices for the same codec.
>> I wasn't aware of that. Current ffmpeg v4l2_request implementation seems
>> to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to
>> decode up to 1920x1088 only if hantro decoder is picked/checked first.
>>
> Speaking of ffmpeg, now that MPEG-2, VP8 and H.264 control interfaces
> are stable, I think one of the next priorities would be to push Jonas'
> ffmpeg patches.
>
> It would be really cool if someone could take the lead on that front,
> as it would reduce kodi's out of tree stack, enable mpv, and so on.

That's absolutely true.

Note that Jonas himself started upstreaming those patches right after 
H264 uapi got stable [1].

Unfortunately I'm the absolut wrong person for doing/continuing this, 
since the very first time I ever looked at the implementation details 
was just for the response I wrote here. So I asked Jernej whos know all 
the details and contributed to those patches as well - he told me he'll 
continue whenever he finds time next.

Best,

Alex

[1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898


^ permalink raw reply	[flat|nested] 54+ messages in thread

* Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
@ 2021-06-30 11:36             ` Alex Bee
  0 siblings, 0 replies; 54+ messages in thread
From: Alex Bee @ 2021-06-30 11:36 UTC (permalink / raw)
  To: Ezequiel Garcia, linux-media, dri-devel, Nicolas Dufresne,
	Jernej Skrabec
  Cc: Paul Kocialkowski, Jonas Karlman, David Airlie, Hans Verkuil,
	Thierry Reding, kernel, Sam Ravnborg, Chris Healy, maccraft123mc

Hi Ezequiel,

Am 29.06.21 um 14:28 schrieb Ezequiel Garcia:
> Hi Alex,
>
> On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
>> Hi Ezequiel,
>>
>> Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
>>> (Adding Nicolas)
>>>
>>> Hi Alex,
>>>
>>> On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
>>>> Hi Ezequiel,
>>>>
>>>> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
>>>>> Given H.264 support for VDPU2 was just added, let's enable it.
>>>>> For now, this is only enabled on platform that don't have
>>>>> an RKVDEC core, such as RK3328.
>>>> Is there any reason, you do not want to enabe H.264 on RK3399? I know
>>>> H.264 can be done by by rkvdec already, but from what I understand that
>>>> shouldn't be an issue: The first decoder found that meets the
>>>> requirements will be taken.
>>>>
>>> Thanks a lot the review.
>>>
>>> I really doubt userspace stacks are readily supporting that strategy.
>>>
>>> The first decoder device supporting the codec format will be selected,
>>> I doubt features such as profile and levels are checked to decide
>>> which decoder to use.
>>>
>>> I'd rather play safe on the kernel side and avoid offering
>>> two competing devices for the same codec.
>> I wasn't aware of that. Current ffmpeg v4l2_request implementation seems
>> to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to
>> decode up to 1920x1088 only if hantro decoder is picked/checked first.
>>
> Speaking of ffmpeg, now that MPEG-2, VP8 and H.264 control interfaces
> are stable, I think one of the next priorities would be to push Jonas'
> ffmpeg patches.
>
> It would be really cool if someone could take the lead on that front,
> as it would reduce kodi's out of tree stack, enable mpv, and so on.

That's absolutely true.

Note that Jonas himself started upstreaming those patches right after 
H264 uapi got stable [1].

Unfortunately I'm the absolut wrong person for doing/continuing this, 
since the very first time I ever looked at the implementation details 
was just for the response I wrote here. So I asked Jernej whos know all 
the details and contributed to those patches as well - he told me he'll 
continue whenever he finds time next.

Best,

Alex

[1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898


^ permalink raw reply	[flat|nested] 54+ messages in thread

end of thread, other threads:[~2021-06-30 16:30 UTC | newest]

Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-24 18:26 [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go) Ezequiel Garcia
2021-06-24 18:26 ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 01/12] drm/panel: kd35t133: Add panel orientation support Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:36   ` Heiko Stübner
2021-06-24 18:36     ` Heiko Stübner
2021-06-24 18:26 ` [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:37   ` Heiko Stübner
2021-06-24 18:37     ` Heiko Stübner
2021-06-24 18:44     ` Ezequiel Garcia
2021-06-24 18:44       ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 03/12] hantro: vp8: Move noisy WARN_ON to vpu_debug Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 04/12] hantro: Make struct hantro_variant.init() optional Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 05/12] media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls Ezequiel Garcia
2021-06-24 18:26   ` [PATCH 05/12] media: hantro: Avoid redundant hantro_get_{dst, src}_buf() calls Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 06/12] media: hantro: h264: Move DPB valid and long-term bitmaps Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 07/12] media: hantro: h264: Move reference picture number to a helper Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 08/12] media: hantro: Add H.264 support for Rockchip VDPU2 Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 09/12] media: hantro: Enable H.264 on " Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 23:13   ` Alex Bee
2021-06-24 23:13     ` Alex Bee
2021-06-26  0:46     ` Ezequiel Garcia
2021-06-26  0:46       ` Ezequiel Garcia
2021-06-26  8:33       ` Alex Bee
2021-06-26  8:33         ` Alex Bee
2021-06-29 12:28         ` Ezequiel Garcia
2021-06-29 12:28           ` Ezequiel Garcia
2021-06-30 11:36           ` Alex Bee
2021-06-30 11:36             ` Alex Bee
2021-06-24 18:26 ` [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-25  9:21   ` Dafna Hirschfeld
2021-06-25  9:21     ` Dafna Hirschfeld
2021-06-26  0:47     ` Ezequiel Garcia
2021-06-26  0:47       ` Ezequiel Garcia
2021-06-26  8:49       ` Alex Bee
2021-06-26  8:49         ` Alex Bee
2021-06-24 18:26 ` [PATCH 11/12] arm64: dts: rockchip: Add VPU support for the PX30 Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 18:26 ` [PATCH 12/12] media: hantro: Add support for the Rockchip PX30 Ezequiel Garcia
2021-06-24 18:26   ` Ezequiel Garcia
2021-06-24 22:39   ` Alex Bee
2021-06-24 22:39     ` Alex Bee
2021-06-26  0:49     ` Ezequiel Garcia
2021-06-26  0:49       ` Ezequiel Garcia
2021-06-26  9:17 ` [PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go) Alex Bee
2021-06-26  9:17   ` Alex Bee

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.