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
