From: Arun Iyengar via B4 Relay <devnull+aiyengar1990.gmail.com@kernel.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Nicolas Frattaroli <frattaroli.nicolas@gmail.com>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Hans Verkuil <hverkuil@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Sergei Khomenkov <shomenkow@gmail.com>,
Tharit Tangkijwanichakul <tharitt97@gmail.com>,
Arun Iyengar <aiyengar1990@gmail.com>
Subject: [PATCH v2 4/6] media: verisilicon: Reset the Rockchip encoder cores on timeout
Date: Thu, 12 Nov 2026 08:30:50 +0000 [thread overview]
Message-ID: <20261112-hantro-robust-v2-4-18561fd48838@gmail.com> (raw)
In-Reply-To: <20261112-hantro-robust-v2-0-18561fd48838@gmail.com>
From: Arun Iyengar <aiyengar1990@gmail.com>
On a job timeout, the Rockchip VEPU1 and VEPU2 reset operations mask the
interrupt and clear the encode enable and AXI control registers. That
only stops a core that is still responsive. On RK3588, when a VEPU121
core reads an IOVA that isn't mapped, the IOMMU reports a page fault and
the core never becomes idle again: its AXI transactions stay
outstanding, the IOMMU can't be stalled anymore ("Enable stall request
timed out", then "Disable paging request timed out" on runtime
suspend), every later job times out as well, and unbinding the driver
can lock up the system.
The driver already gets the optional reset lines of the device and
deasserts them at probe. Pulse them in the encoder reset operations,
after stopping the core through its registers, to return it to a clean
idle state. The clocks are still enabled at that point, as the job that
timed out holds them. This is a no-op on device trees that don't
describe the resets, which is the case for all of them so far.
The Rockchip BSP MPP driver resets these cores the same way, through
their AXI and AHB reset lines.
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
.../media/platform/verisilicon/rockchip_vpu_hw.c | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/media/platform/verisilicon/rockchip_vpu_hw.c b/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
index 5d4e46bd9cd6..114010d6a5c9 100644
--- a/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
+++ b/drivers/media/platform/verisilicon/rockchip_vpu_hw.c
@@ -7,6 +7,7 @@
*/
#include <linux/clk.h>
+#include <linux/delay.h>
#include "hantro.h"
#include "hantro_jpeg.h"
@@ -468,6 +469,33 @@ static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
vdpu_write(vpu, G1_REG_CONFIG_DEC_CLK_GATE_E, G1_REG_CONFIG);
}
+/*
+ * Stopping the encoder through its registers isn't enough when it is stuck
+ * on the bus, for instance after a translation fault in its IOMMU: it keeps
+ * AXI transactions outstanding and never becomes idle, which also prevents
+ * the IOMMU from stalling. Pulse the reset lines of the core, if the device
+ * tree describes them, to return it to its idle state.
+ */
+static void rockchip_vpu_enc_hw_reset(struct hantro_dev *vpu)
+{
+ int ret;
+
+ if (!vpu->resets)
+ return;
+
+ ret = reset_control_assert(vpu->resets);
+ if (ret) {
+ dev_warn(vpu->dev, "Failed to assert resets: %d\n", ret);
+ return;
+ }
+
+ udelay(5);
+
+ ret = reset_control_deassert(vpu->resets);
+ if (ret)
+ dev_err(vpu->dev, "Failed to deassert resets: %d\n", ret);
+}
+
static void rockchip_vpu1_enc_reset(struct hantro_ctx *ctx)
{
struct hantro_dev *vpu = ctx->dev;
@@ -475,6 +503,7 @@ static void rockchip_vpu1_enc_reset(struct hantro_ctx *ctx)
vepu_write(vpu, H1_REG_INTERRUPT_DIS_BIT, H1_REG_INTERRUPT);
vepu_write(vpu, 0, H1_REG_ENC_CTRL);
vepu_write(vpu, 0, H1_REG_AXI_CTRL);
+ rockchip_vpu_enc_hw_reset(vpu);
/*
* The encoder runs don't write the interrupt register, only the
* interrupt handler clears it after each frame. Clear it here too,
@@ -499,6 +528,7 @@ static void rockchip_vpu2_enc_reset(struct hantro_ctx *ctx)
vepu_write(vpu, VEPU_REG_INTERRUPT_DIS_BIT, VEPU_REG_INTERRUPT);
vepu_write(vpu, 0, VEPU_REG_ENCODE_START);
vepu_write(vpu, 0, VEPU_REG_AXI_CTRL);
+ rockchip_vpu_enc_hw_reset(vpu);
/*
* The encoder runs don't write the interrupt register, only the
* interrupt handler clears it after each frame. Clear it here too,
--
2.55.0
next prev parent reply other threads:[~2026-11-12 8:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 8:30 [PATCH v2 0/6] media: verisilicon: Recover the Rockchip VPUs from faults and timeouts Arun Iyengar via B4 Relay
2026-11-12 8:30 ` [PATCH v2 1/6] dt-bindings: media: rockchip,rk3568-vepu: Add the reset lines Arun Iyengar via B4 Relay
2026-11-12 8:30 ` [PATCH v2 2/6] media: verisilicon: Don't hold the VPU in reset after remove Arun Iyengar via B4 Relay
2026-11-12 10:19 ` Philipp Zabel
2026-11-12 14:13 ` Benjamin Gaignard
2026-11-12 8:30 ` [PATCH v2 3/6] media: verisilicon: Enable the Rockchip encoder interrupt again after a reset Arun Iyengar via B4 Relay
2026-11-12 8:30 ` Arun Iyengar via B4 Relay [this message]
2026-11-12 8:30 ` [PATCH v2 5/6] media: verisilicon: Reinitialize the IOMMU after resetting an encoder core Arun Iyengar via B4 Relay
2026-11-12 8:55 ` sashiko-bot
2026-11-12 8:30 ` [PATCH v2 6/6] arm64: dts: rockchip: Add the reset lines of the RK3588 VEPU121 cores Arun Iyengar via B4 Relay
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=20261112-hantro-robust-v2-4-18561fd48838@gmail.com \
--to=devnull+aiyengar1990.gmail.com@kernel.org \
--cc=aiyengar1990@gmail.com \
--cc=andrzej.p@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=frattaroli.nicolas@gmail.com \
--cc=heiko@sntech.de \
--cc=hverkuil@kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=shomenkow@gmail.com \
--cc=tharitt97@gmail.com \
/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