[PATCH v10 00/13] accel/rocket: RK3576 NPU (RKNN) enablement
Tomeu Vizoso
tomeu at tomeuvizoso.net
Mon Aug 31 00:20:09 PDT 2026
On Mon, Aug 31, 2026 at 6:08 AM Jiaxing Hu <gahing at gahingwoo.com> wrote:
>
> Based on Igor Paunovic's "[PATCH v2] accel/rocket: request the core
> clocks by name", as v6 through v9 were.
>
> https://lore.kernel.org/linux-rockchip/20260729130743.128876-1-royalnet026@gmail.com/
>
> Tested on a Radxa ROCK 4D, on next-20260814. The tree is byte identical
> to v9, so that is the same test rather than a new one.
>
> This adds the RK3576 NPU to accel/rocket, which today supports RK3588
> only. The RK3576 carries two cores of the same RKNN block, wired up
> differently. Two extra convolution buffer clocks, two power domains per
> core, one reset rather than two, no NPU SRAM rail, and a PC_TASK_CON
> that packs the task number into sixteen bits rather than twelve.
>
> What changed since v9
>
> No code. Every patch's diff is byte identical to its v9 counterpart, and
> below the --- the only change anywhere is 5/13's git note. Above it, six
> commit messages each gained one trailer line and nothing else. Six tags,
> that note, and the base-commit trailers back where v8 had them.
>
> The note first, because v9's cover letter said 5/13 carried it and the
> posted mail did not. Rob Herring's bot asked on v8 for the dependency to
> be recorded in the patch rather than only in the letter, v9 said it was
> there, and it was not: my send script never passed --notes. Igor
> Paunovic noticed while applying the series and said so before v10 rather
> than after, and he had the cause right. Nothing was lost in a rebase;
> the flag was missing. The script now regenerates with --notes and
> refuses to send unless exactly one patch carries a Notes block.
>
> Igor also ran the 19 August protocol again on v9 as posted, on RK3588,
> an Orange Pi 5 Plus with all three cores bound, PROVE_LOCKING=y and
> DEBUG_ATOMIC_SLEEP=y, and a local test-only patch lowering
> JOB_TIMEOUT_MS to 2 ms so healthy jobs cross the timeout. Two passes per
> kernel at console loglevel 8 and 4, serial captured on a second machine.
>
> v9, two passes 12 and 11 induced resets, all recovered,
> 48 of 48 within 1 on both, including the
> inference after a forced autosuspend and
> resume. No MMU faults, no lockdep hits,
> nothing on the console.
>
> without 1 and 2/13, 8, 10, 12, 8 and 15 induced resets, all
> five runs in the recovered. Four runs clean. In the
> same session remaining one the inference after autosuspend
> reported success and returned a constant
> buffer, all 48 output channels at 0x80,
> which is not this model's output zero
> point, while the CPU reference varied
> normally. Zero kernel messages, zero
> lockdep hits, nothing on the console.
>
> 1, 2 and 3/13 only, 13 and 13 induced resets, all recovered,
> two passes oracle 48 of 48 throughout, including after a
> forced autosuspend and resume. On the 1+2 arm
> a round that ends in a timeout leaves the
> affected core runtime-active even through a
> forced autosuspend; with 3/13 applied the same
> sequence leaves all three cores suspended.
> That arm is where 3/13's Tested-by comes from.
>
> A job that signals completion while its output buffer is never written
> is the silent form of the race 1/13 and 2/13 close, and across 102
> induced resets in nine runs that day it appeared only on the arm without
> them. It is a better statement of what those two patches are for than
> anything my own logs have caught, which has always been the loud form:
> a message, a wrong answer, something to look at.
>
> The tags, and where each came from:
>
> 02/13 Tested-by: Igor Paunovic # RK3588, three cores, induced
> # reset, differential base,
> # JOB_TIMEOUT_MS=2
> 03/13 Tested-by: Igor Paunovic # RK3588, three cores, induced
> # reset, JOB_TIMEOUT_MS=2
> 06/13 Acked-by: Conor Dooley
> 07/13 Acked-by: Conor Dooley
> 08/13 Reviewed-by: Abel Vesa
> 09/13 Reviewed-by: Abel Vesa
>
> The two Tested-by comments are not the same string, and that is how they
> were given. 1/13, 4/13 and 5/13 keep the tags they had; Igor checked before
> testing that 1/13 is byte identical to v8 1/12 up to the base-commit
> trailer and 4/13 identical to v8 3/12, so those tags still describe what
> was tested.
>
> The bindings are unchanged since v9, where dt_binding_check was clean on
> all three with dtschema 2026.6 and yamllint 1.38.0, and CHECK_DTBS was
> clean on all 13 rk3576 and all 48 rk3588 dtbs.
>
> Two things I raised in v9 and would still rather hear about than guess
> at. 8/13 does three things: it adds the settle delay, renames a macro,
> and gives RK3576_PD_NPU a regulator, which also makes every RK3576 board
> force that domain off at probe. I asked whether it wants splitting;
> Abel Vesa's Reviewed-by may be the answer, but nobody has said so, and I
> would rather split it than have it merged on my silence. And 12/13 gives
> each core both NPU domains, which is the description that has been
> tested here rather than the topology; if it should be one domain per
> core, 5/13's minItems has to change with it. That one has had no reply
> at all.
>
> Nothing else moved.
>
> Jiaxing Hu (13):
> accel/rocket: take the completion register writes under job_lock
> accel/rocket: wait for a running IRQ handler before resetting a core
> accel/rocket: let the core suspend after a reset
> accel/rocket: factor the completion tail out of the IRQ handler
> dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core
> dt-bindings: power: rockchip: allow resets in a power domain node
> dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU
> pmdomain/rockchip: add optional per-domain power-on settle delay
> pmdomain/rockchip: cycle optional power-domain resets on power-on
> accel/rocket: select the per-core clock and reset counts from match
> data
> accel/rocket: add RK3576 NPU (RKNN) support
> arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes
> arm64: dts: rockchip: rk3576-rock-4d: enable NPU
>
> .../bindings/iommu/rockchip,iommu.yaml | 28 +++++
> .../npu/rockchip,rk3588-rknn-core.yaml | 47 ++++++-
> .../power/rockchip,power-controller.yaml | 8 ++
> .../boot/dts/rockchip/rk3576-rock-4d.dts | 13 ++
> arch/arm64/boot/dts/rockchip/rk3576.dtsi | 82 +++++++++++-
> drivers/accel/rocket/rocket_core.c | 28 ++++-
> drivers/accel/rocket/rocket_core.h | 11 +-
> drivers/accel/rocket/rocket_device.c | 7 +-
> drivers/accel/rocket/rocket_drv.c | 28 ++++-
> drivers/accel/rocket/rocket_drv.h | 2 +
> drivers/accel/rocket/rocket_job.c | 119 ++++++++++++++----
> drivers/pmdomain/rockchip/pm-domains.c | 75 +++++++----
> 12 files changed, 385 insertions(+), 63 deletions(-)
>
>
> base-commit: 4477a78374a57c3809b172ad30cceabda48c47c6
> prerequisite-patch-id: 46ebb679e93d3d25393e8cbf8fc3c955bcc01bd4
Hi Jiaxing,
I want to get soon to review this and the other pending rocket series,
and in the meantime something that could help this moving would be to
get a review from Sashiko.
As you can see in [0], Sashiko is not reviewing this series because it
doesn't not understand yet prerequisite-patch-id. Can you please
resubmit the series with Igor's (presumably) patches bundled in it?
[0] https://sashiko.dev/#/patchset/20260831040804.24111-1-gahing%40gahingwoo.com
Thanks,
Tomeu
More information about the linux-arm-kernel
mailing list