Linux Power Management development
 help / color / mirror / Atom feed
From: Jiaxing Hu <gahing@gahingwoo.com>
To: tomeu@tomeuvizoso.net, heiko@sntech.de, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, joro@8bytes.org,
	will@kernel.org, robin.murphy@arm.com, ulfh@kernel.org,
	p.zabel@pengutronix.de, ogabbay@kernel.org,
	zhangqing@rock-chips.com
Cc: royalnet026@gmail.com, u.kleine-koenig@baylibre.com,
	chaoyi.chen@rock-chips.com, diederik@cknow-tech.com,
	alchark@flipper.net, dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, iommu@lists.linux.dev,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Jiaxing Hu <gahing@gahingwoo.com>
Subject: [PATCH v9 03/13] accel/rocket: let the core suspend after a reset
Date: Mon, 24 Aug 2026 23:08:52 +1200	[thread overview]
Message-ID: <b5265e47492897d0ada844c2ff7f477bb715cd07.1787568944.git.gahing@gahingwoo.com> (raw)
In-Reply-To: <f1805c2bce56c89d8ace35f67c665b24bab90965.1787568944.git.gahing@gahingwoo.com>

rocket_reset() drops the in-flight job's runtime PM reference with
pm_runtime_put_noidle(), a bare decrement that requests nothing. The core
is left at usage_count 0 but still runtime-active with no idle request
pending, so it does not suspend until something else asks, and on a
platform whose power domain does work on power-on that work never happens.

On RK3576 that work is a bus interface reset the domain cycles when it
comes up. Without it the NPU's IOMMU stops answering, and the job after a
timeout returns a surface of the output zero point with rk_iommu reporting
that MMU_DTE_ADDR is not functioning.

Measured on a ROCK 4D in one boot, three runs, one variable between them.
With the bare put the core reads runtime-active with its rail still up
after the reset, the IOMMU reports the failure on the next attach and the
inference returns 0 of 128 channels. With the reference put back through
pm_runtime_put_autosuspend() the core reads suspended with the rail down,
there is no IOMMU message, and the same inference returns 128 of 128. A
third run repeating the first failed the same way.

It also matches the put in the completion path a few lines away, so the
reset path no longer leaves the device in a state the rest of the driver
never produces. The remaining put, on the error path in rocket_job_run(),
is a plain pm_runtime_put() and is left alone here: it unwinds a
get_sync() that never reached the hardware, and changing it belongs in
its own patch.

Igor Paunovic ran the differential on RK3588: 45 induced resets across
three cores, with and without the two preceding patches, and the domain
dropped every single time with no MMU message on either kernel. So this
is not rocket-wide. His conditions cross a healthy block with a lowered
timeout rather than a hung one, which he was careful to say his protocol
cannot settle, but it is what scopes the change to RK3576.

Link: https://lore.kernel.org/all/20260819073530.6087-1-royalnet026@gmail.com/
Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL")
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
---
 drivers/accel/rocket/rocket_job.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c
index 3c0ed4605..a89ab49e1 100644
--- a/drivers/accel/rocket/rocket_job.c
+++ b/drivers/accel/rocket/rocket_job.c
@@ -406,12 +406,12 @@ rocket_reset(struct rocket_core *core, struct drm_sched_job *bad)
 
 	/*
 	 * No handler is running now, but we might still have stuck jobs. Let's
-	 * make sure the PM counters stay balanced by manually calling
-	 * pm_runtime_put_noidle().
+	 * make sure the PM counters stay balanced by putting the reference the
+	 * job took, and request idle while doing it so the core can suspend.
 	 */
 	scoped_guard(mutex, &core->job_lock) {
 		if (core->in_flight_job)
-			pm_runtime_put_noidle(core->dev);
+			pm_runtime_put_autosuspend(core->dev);
 
 		iommu_detach_group(NULL, core->iommu_group);
 
-- 
2.43.0


  parent reply	other threads:[~2026-08-24 11:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 11:08 [PATCH v9 00/13] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-08-24 11:08 ` [PATCH v9 01/13] accel/rocket: take the completion register writes under job_lock Jiaxing Hu
2026-08-24 11:08   ` [PATCH v9 02/13] accel/rocket: wait for a running IRQ handler before resetting a core Jiaxing Hu
2026-08-25 12:31     ` Igor Paunovic
2026-08-25 12:45       ` Igor Paunovic
2026-08-24 11:08   ` Jiaxing Hu [this message]
2026-08-25 12:32     ` [PATCH v9 03/13] accel/rocket: let the core suspend after a reset Igor Paunovic
2026-08-25 12:45       ` Igor Paunovic
2026-08-24 11:08   ` [PATCH v9 04/13] accel/rocket: factor the completion tail out of the IRQ handler Jiaxing Hu
2026-08-24 11:08   ` [PATCH v9 05/13] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-08-25 12:32     ` Igor Paunovic
2026-08-24 11:08   ` [PATCH v9 06/13] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-08-24 16:24     ` Conor Dooley
2026-08-24 11:08   ` [PATCH v9 07/13] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Jiaxing Hu
2026-08-24 16:25     ` Conor Dooley
2026-08-24 11:08   ` [PATCH v9 08/13] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-08-24 11:31     ` Abel Vesa
2026-08-24 11:08   ` [PATCH v9 09/13] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-08-24 11:30     ` Abel Vesa
2026-08-24 11:08   ` [PATCH v9 10/13] accel/rocket: select the per-core clock and reset counts from match data Jiaxing Hu
2026-08-24 11:09   ` [PATCH v9 11/13] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-08-24 11:09   ` [PATCH v9 12/13] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-08-24 11:09   ` [PATCH v9 13/13] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu

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=b5265e47492897d0ada844c2ff7f477bb715cd07.1787568944.git.gahing@gahingwoo.com \
    --to=gahing@gahingwoo.com \
    --cc=alchark@flipper.net \
    --cc=chaoyi.chen@rock-chips.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=diederik@cknow-tech.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=ogabbay@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=royalnet026@gmail.com \
    --cc=tomeu@tomeuvizoso.net \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=ulfh@kernel.org \
    --cc=will@kernel.org \
    --cc=zhangqing@rock-chips.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