Message ID | 20220610125215.240539-2-nicolas.dufresne@collabora.com (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | Hans Verkuil |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1nze81-00Ex27-GO; Fri, 10 Jun 2022 12:52:41 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245274AbiFJMwj (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 10 Jun 2022 08:52:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234166AbiFJMwh (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 10 Jun 2022 08:52:37 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F057729361; Fri, 10 Jun 2022 05:52:35 -0700 (PDT) Received: from whitebuilder.lan (192-222-136-102.qc.cable.ebox.net [192.222.136.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nicolas) by madras.collabora.co.uk (Postfix) with ESMTPSA id 45E776601723; Fri, 10 Jun 2022 13:52:33 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1654865554; bh=p58BGLd7hMm8p/2ISuy3Dy0LlqXqYJNmYcWNBWGs/eo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k/12mt8TUAGfUMKdUILYc1U9Q0mcOKvYLKWOvKQehdBhmZwNiUxJswfiOfpoooU6Y K7SyrWEXe2qjxHIqPHedkJ37gilThxf4XJm1pghTKSzfqIS5CJyy/DGRM6cwux/56x BJC76p7e5Fq2jAX5N9L4Q+7mVubr9Jjllr2y0C1llKCJP6kL7yxELDiubw4W84nWK5 y2J3cAIz0OPwwKlQj8IYtTfQsYgJi0tzCounvyIkiAzE3Nbynsh4HGqqJjeLMjn96a wnXDKPIFQARXVZqpvN92Lkf+CAUBKMooUOkILCPvyNcXkpfILLtadGlIz7x/dGu5lp QNoDgEhEwkwOA== From: Nicolas Dufresne <nicolas.dufresne@collabora.com> To: linux-media@vger.kernel.org, Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>, Mauro Carvalho Chehab <mchehab@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, Boris Brezillon <boris.brezillon@collabora.com> Cc: Nicolas Dufresne <nicolas.dufresne@collabora.com>, kernel@collabora.com, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 1/5] media: rkvdec: Disable H.264 error detection Date: Fri, 10 Jun 2022 08:52:11 -0400 Message-Id: <20220610125215.240539-2-nicolas.dufresne@collabora.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220610125215.240539-1-nicolas.dufresne@collabora.com> References: <20220610125215.240539-1-nicolas.dufresne@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
media: rkvdec: Fix H.264 error resilience
|
|
Commit Message
Nicolas Dufresne
June 10, 2022, 12:52 p.m. UTC
Quite often, the HW get stuck in error condition if a stream error
was detected. As documented, the HW should stop immediately and self
reset. There is likely a problem or a miss-understanding of the self
self reset mechanism, as unless we make a long pause, the next command
will then report an error even if there is no error in it.
Disabling error detection fixes the issue, and let the decoder continue
after an error. This patch is safe for backport into older kernels.
Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 6/10/22 15:52, Nicolas Dufresne wrote: > Quite often, the HW get stuck in error condition if a stream error > was detected. As documented, the HW should stop immediately and self > reset. There is likely a problem or a miss-understanding of the self > self reset mechanism, as unless we make a long pause, the next command > will then report an error even if there is no error in it. > > Disabling error detection fixes the issue, and let the decoder continue > after an error. This patch is safe for backport into older kernels. > > Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> > --- Nit: won't hurt to add the explicit stable tag if you'll make the v2. Cc: stable@vger.kernel.org
On Fri, Jun 10, 2022 at 08:52:11AM -0400, Nicolas Dufresne wrote: > Quite often, the HW get stuck in error condition if a stream error > was detected. As documented, the HW should stop immediately and self > reset. There is likely a problem or a miss-understanding of the self > self reset mechanism, as unless we make a long pause, the next command > will then report an error even if there is no error in it. > > Disabling error detection fixes the issue, and let the decoder continue > after an error. This patch is safe for backport into older kernels. > > Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> This is effectively how ChromeOS previously was using this hardware for years. When moving to the upstream/staging driver, this started giving us problems. This fix is helpful; we'd rather sacrifice error detection for now, to avoid hanging the hardware in error cases ;) Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org>
Hi Hans, On Fri, Jun 10, 2022 at 09:39:19AM -0700, Brian Norris wrote: > On Fri, Jun 10, 2022 at 08:52:11AM -0400, Nicolas Dufresne wrote: > > Quite often, the HW get stuck in error condition if a stream error > > was detected. As documented, the HW should stop immediately and self > > reset. There is likely a problem or a miss-understanding of the self > > self reset mechanism, as unless we make a long pause, the next command > > will then report an error even if there is no error in it. > > > > Disabling error detection fixes the issue, and let the decoder continue > > after an error. This patch is safe for backport into older kernels. > > > > Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") > > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> > > This is effectively how ChromeOS previously was using this hardware for > years. When moving to the upstream/staging driver, this started giving > us problems. This fix is helpful; we'd rather sacrifice error detection > for now, to avoid hanging the hardware in error cases ;) > > Reviewed-by: Brian Norris <briannorris@chromium.org> > Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Given this is stable material, looks like we should queue it, while the rest of the series is still being discussed. Thanks, Ezequiel
diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c index 2992fb87cf72..55596ce6bb6e 100644 --- a/drivers/staging/media/rkvdec/rkvdec-h264.c +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c @@ -1175,8 +1175,8 @@ static int rkvdec_h264_run(struct rkvdec_ctx *ctx) schedule_delayed_work(&rkvdec->watchdog_work, msecs_to_jiffies(2000)); - writel(0xffffffff, rkvdec->regs + RKVDEC_REG_STRMD_ERR_EN); - writel(0xffffffff, rkvdec->regs + RKVDEC_REG_H264_ERR_E); + writel(0, rkvdec->regs + RKVDEC_REG_STRMD_ERR_EN); + writel(0, rkvdec->regs + RKVDEC_REG_H264_ERR_E); writel(1, rkvdec->regs + RKVDEC_REG_PREF_LUMA_CACHE_COMMAND); writel(1, rkvdec->regs + RKVDEC_REG_PREF_CHR_CACHE_COMMAND);