Re: [PATCH v13 13/14] arm64: dts: rockchip: add NPU (RKNN) nodes to rk3576

[Heiko Stuebner <heiko@sntech.de>]

Hi,

Am Dienstag, 15. September 2026, 12:43:27 Mitteleuropäische Sommerzeit schrieb Jiaxing Hu:
> Add the two RKNN cores and their IOMMUs. Both cores are disabled by
> default; boards enable what they wire up.
> 
> PD_NPU0 and PD_NPU1 are siblings under PD_NPUTOP and hold one core each,
> but the convolution buffer and the DSU sit above them: ACLK_RKNN_CBUF,
> HCLK_RKNN_CBUF and CLK_RKNN_DSU0 belong to the block rather than to either
> core, and PD_NPUTOP already lists all three. Add them to both core domains
> as well, so a core domain switching state has the clocks of the path it
> shares running, and give each core domain the BIU reset that the pmdomain
> driver now cycles once power is on.
> 
> Each core lists both core domains, its own first, so that a core in use has
> the whole block powered. Whether a single core can reach the shared path
> with the sibling domain off is not something this series establishes;
> listing both is the description that has been tested here. The IOMMU in
> front of each core lists that core's domain only.
> 
> Label the outer PD_NPU node so a board can attach the NPU rail to the
> domain that gates the block.
> 
> Clock the NPU inside the voltage its rail is given. CLK_RKNN_DSU0 clocks
> both cores and the CBUF they share, nothing in mainline sets its rate, and
> the block comes up at 786.432 MHz. Rockchip's OPP table for this NPU asks
> 800 mV of its 800 MHz step at the worst leakage bins, and nothing in
> mainline sets the rail either, so a board that follows this DTS runs the
> NPU above the step whose voltage it happens to boot with.
> 
> On a ROCK 4D with both cores enabled and vdd_npu_s0 at the 750 mV its PMIC
> comes up with, two jobs in flight at once make the second core write single
> words of its output wrong: the right value with a bit of the accumulator
> set, always the same position in the array. Either core alone is exact.
> Four device trees, same board, kernel and userspace, four passes of 5400
> rows each, every row compared with the same multiply done one row at a
> time:
> 
>   786 MHz, 750 mV    13 to 20 wrong rows a pass
>   594 MHz, 750 mV    0, 0, 0, 0
>   786 MHz, 800 mV    0, 0, 0, 0
>   786 MHz, 850 mV    0, 0, 0, 0
> 
> 594 MHz is a divider off GPLL and sits between that table's 500 and 600 MHz
> steps, both of which ask 725 mV at every leakage bin, so it is inside the
> voltage a board that describes no NPU rail already provides.
> 
> The trade it buys is a core against a clock, and both halves are measured.
> The rate lives in the device tree, so the two clocks cannot share a boot,
> which means this comparison is across boots and has to clear the noise of
> one. Twenty readings of a single arm inside one boot, nothing changed
> between them, span 2.5%; across boots it can only be worse. So the 4.0 to
> 4.2% below clears that floor by under a factor of two, and the 26 to 37%
> clears it by ten. Five runs an arm, the arms alternating inside a boot,
> one warm-up a model discarded, medians of five:
> 
>   decode tok/s      594 MHz   786 MHz
>   Llama-3.2-1B        17.85     18.60   two cores
>                       11.17     13.77   one core
>   SmolLM2-135M        41.46     43.12   two cores
>                       38.26     41.90   one core
> 
> Losing 192 MHz costs 4.0 to 4.2% of decode with both cores running. Losing
> a core costs 26 to 37% on the 1B model, at either clock. The rate is the
> cheaper of the two by six to nine times.
> 
> The two arms cross-check each other: the clock is worth 23% on ONE core
> against 4% on two. With both cores running the bottleneck is no longer the
> clock, which is why this configuration can afford to give up 192 MHz.
> 
> A core is worth much less on a small model, 2.8 to 7.7% on 135M, where the
> second core's dispatch overhead is not repaid. TTFT moves by under 2%
> either way, so none of this says anything about prefill.
> 
> An OPP table with the rail attached is the proper answer, and it wants
> driver support this series does not have.

please trim that commit message A LOT :-) .

You're just adding the nodes for the NPU cores, that does
not need a novel-sized commit message.


Additionally, please split this into two commits:
- Adding the resets to the power-domains
- Adding the nodes for the NPU cores (add pd_npu phandle here too)


Thanks a lot
Heiko