From patchwork Mon Oct 7 17:45:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ezequiel Garcia X-Patchwork-Id: 59333 X-Patchwork-Delegate: hverkuil@xs4all.nl Received: from vger.kernel.org ([209.132.180.67]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHX6F-00019f-5Y; Mon, 07 Oct 2019 17:47:11 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729266AbfJGRrF (ORCPT + 1 other); Mon, 7 Oct 2019 13:47:05 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:60856 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728121AbfJGRrF (ORCPT ); Mon, 7 Oct 2019 13:47:05 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id D87EB28D41F From: Ezequiel Garcia To: linux-media@vger.kernel.org Cc: kernel@collabora.com, Nicolas Dufresne , Tomasz Figa , linux-rockchip@lists.infradead.org, Heiko Stuebner , Jonas Karlman , Philipp Zabel , Boris Brezillon , Alexandre Courbot , fbuergisser@chromium.org, linux-kernel@vger.kernel.org, Douglas Anderson , Ezequiel Garcia Subject: [PATCH v2 for 5.4 4/4] media: hantro: Fix picture order count table enable Date: Mon, 7 Oct 2019 14:45:05 -0300 Message-Id: <20191007174505.10681-5-ezequiel@collabora.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20191007174505.10681-1-ezequiel@collabora.com> References: <20191007174505.10681-1-ezequiel@collabora.com> MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org From: Francois Buergisser The picture order count table only makes sense for profiles higher than Baseline. This is confirmed by the H.264 specification (See 8.2.1 Decoding process for picture order count), which clarifies how POC are used for features not present in Baseline. """ Picture order counts are used to determine initial picture orderings for reference pictures in the decoding of B slices, to represent picture order differences between frames or fields for motion vector derivation in temporal direct mode, for implicit mode weighted prediction in B slices, and for decoder conformance checking. """ As a side note, this change matches various vendors downstream codebases, including ChromiumOS and IMX VPU libraries. Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1") Signed-off-by: Francois Buergisser Signed-off-by: Ezequiel Garcia --- v2: * New patch. drivers/staging/media/hantro/hantro_g1_h264_dec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c index c92460407613..05576dbd39e2 100644 --- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c +++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c @@ -34,9 +34,9 @@ static void set_params(struct hantro_ctx *ctx) reg = G1_REG_DEC_CTRL0_DEC_AXI_WR_ID(0x0); if (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD) reg |= G1_REG_DEC_CTRL0_SEQ_MBAFF_E; - reg |= G1_REG_DEC_CTRL0_PICORD_COUNT_E; if (sps->profile_idc > 66) - reg |= G1_REG_DEC_CTRL0_WRITE_MVS_E; + reg = G1_REG_DEC_CTRL0_PICORD_COUNT_E | + G1_REG_DEC_CTRL0_WRITE_MVS_E; if (!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY) && (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD ||