From: Jonas Karlman <jonas@kwiboo.se>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Ezequiel Garcia <ezequiel@collabora.com>
Cc: Jonas Karlman <jonas@kwiboo.se>,
Hans Verkuil <hverkuil@xs4all.nl>,
Boris Brezillon <boris.brezillon@collabora.com>,
Tomasz Figa <tfiga@chromium.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [PATCH v3 1/5] media: hantro: Fix H264 motion vector buffer offset
Date: Wed, 6 Nov 2019 22:34:20 +0000 [thread overview]
Message-ID: <HE1PR06MB4011A23596DCD988F2CAC603AC790@HE1PR06MB4011.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <HE1PR06MB4011EDD5F2686A05BC35F61CAC790@HE1PR06MB4011.eurprd06.prod.outlook.com>
A decoded 8-bit 4:2:0 frame need memory for up to 448 bytes per
macroblock and is laid out in memory as follow:
+---------------------------+
| Y-plane 256 bytes x MBs |
+---------------------------+
| UV-plane 128 bytes x MBs |
+---------------------------+
| MV buffer 64 bytes x MBs |
+---------------------------+
The motion vector buffer offset is currently correct for 4:2:0 because the
extra space for motion vectors is overallocated with an extra 64 bytes x MBs.
Wrong offset for both destination and motion vector buffer are used
for the bottom field of field encoded content, wrong offset is
also used for 4:0:0 (monochrome) content.
Fix this by setting the motion vector address to the expected 384 bytes x MBs
offset for 4:2:0 and 256 bytes x MBs offset for 4:0:0 content.
Also use correct destination and motion vector buffer offset
for the bottom field of field encoded content.
While at it also extend the check for 4:0:0 (monochrome) to include an
additional check for High Profile (100).
Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
Changes in v3:
* address remarks from Boris
- use src_fmt instead of dst_fmt
Changes in v2:
* address remarks from Philipp and Ezequiel
- update commit message
- rename offset to bytes_per_mb
- remove MV_OFFSET macros
- move PIC_MB_WIDTH/HEIGHT_P change to separate patch
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 31 +++++++++++++------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 70a6b5b26477..30d977c3d529 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -81,7 +81,7 @@ static void set_params(struct hantro_ctx *ctx)
reg |= G1_REG_DEC_CTRL4_CABAC_E;
if (sps->flags & V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE)
reg |= G1_REG_DEC_CTRL4_DIR_8X8_INFER_E;
- if (sps->chroma_format_idc == 0)
+ if (sps->profile_idc >= 100 && sps->chroma_format_idc == 0)
reg |= G1_REG_DEC_CTRL4_BLACKWHITE_E;
if (pps->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED)
reg |= G1_REG_DEC_CTRL4_WEIGHT_PRED_E;
@@ -234,6 +234,7 @@ static void set_buffers(struct hantro_ctx *ctx)
struct vb2_v4l2_buffer *src_buf, *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);
@@ -244,18 +245,30 @@ static void set_buffers(struct hantro_ctx *ctx)
/* Destination (decoded frame) buffer. */
dst_dma = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
- vdpu_write_relaxed(vpu, dst_dma, G1_REG_ADDR_DST);
+ /* Adjust dma addr to start at second line for bottom field */
+ if (ctrls->slices[0].flags & V4L2_H264_SLICE_FLAG_BOTTOM_FIELD)
+ offset = ALIGN(ctx->src_fmt.width, MB_DIM);
+ vdpu_write_relaxed(vpu, dst_dma + offset, G1_REG_ADDR_DST);
/* Higher profiles require DMV buffer appended to reference frames. */
if (ctrls->sps->profile_idc > 66 && ctrls->decode->nal_ref_idc) {
- size_t pic_size = ctx->h264_dec.pic_size;
- size_t mv_offset = round_up(pic_size, 8);
-
+ 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->slices[0].flags & V4L2_H264_SLICE_FLAG_BOTTOM_FIELD)
- mv_offset += 32 * MB_WIDTH(ctx->dst_fmt.width);
-
- vdpu_write_relaxed(vpu, dst_dma + mv_offset,
- G1_REG_ADDR_DIR_MV);
+ offset += 32 * MB_WIDTH(ctx->src_fmt.width) *
+ MB_HEIGHT(ctx->src_fmt.height);
+ vdpu_write_relaxed(vpu, dst_dma + offset, G1_REG_ADDR_DIR_MV);
}
/* Auxiliary buffer prepared in hantro_g1_h264_dec_prepare_table(). */
--
2.17.1
next prev parent reply other threads:[~2019-11-06 22:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 22:32 [PATCH v3 0/5] media: hantro: H264 fixes and improvements Jonas Karlman
2019-11-06 22:34 ` Jonas Karlman [this message]
2019-11-20 12:40 ` [PATCH v3 1/5] media: hantro: Fix H264 motion vector buffer offset Tomasz Figa
[not found] ` <20191106223408.2176-1-jonas@kwiboo.se>
2019-11-06 22:34 ` [PATCH v3 2/5] media: hantro: Reduce H264 extra space for motion vectors Jonas Karlman
2019-11-20 12:44 ` Tomasz Figa
2019-12-09 18:11 ` Ezequiel Garcia
2020-01-08 12:59 ` Tomasz Figa
2020-01-08 15:10 ` Jonas Karlman
2020-01-16 3:56 ` Tomasz Figa
2019-11-06 22:34 ` [PATCH v3 3/5] media: hantro: Use output buffer width and height for H264 decoding Jonas Karlman
2019-11-09 19:04 ` Boris Brezillon
2019-11-06 22:35 ` [PATCH v3 4/5] media: hantro: Remove now unused H264 pic_size Jonas Karlman
[not found] ` <20191106223456.2231-1-jonas@kwiboo.se>
2019-11-06 22:35 ` [PATCH v3 5/5] media: hantro: Set H264 FIELDPIC_FLAG_E flag correctly Jonas Karlman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=HE1PR06MB4011A23596DCD988F2CAC603AC790@HE1PR06MB4011.eurprd06.prod.outlook.com \
--to=jonas@kwiboo.se \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=tfiga@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).