On Mon, Aug 31, 2026 at 6:08 AM Jiaxing Hu <[email protected]> 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/[email protected]/ > > 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
