Hi Midgy, On 6/9/2026 7:11 PM, Midgy Balon wrote: > Hello Chaoyi, > > You were right - building rocket as a module fixes it. Thanks for the pointer. > > I rebuilt with CONFIG_DRM_ACCEL_ROCKET=m (everything else the same: > need_regulator on > the RK3568 NPU power domain via a DOMAIN_M_R variant, domain-supply = > <&vdd_npu>, and the > regulator-always-on workaround dropped). The board now boots cleanly > and, more importantly, > an NPU job submit no longer hangs: I ran the test workload five times > with no RCU stall and > no freeze. > > So with rocket=m the need_regulator approach works on RK3568, and I'll > keep it for v4 > (domain-supply + need_regulator, instead of marking vdd_npu > always-on). rocket=m is the > normal configuration anyway; my earlier hang came from building it =y > in a self-contained > image, so it probed in the initcalls (around 2 s) and the genpd -> > I2C-PMIC regulator > transition ran before the system was ready. As a module it loads from > udev much later > (~6.8 s here), after the I2C controller and regulator core are fully up. > > On your question of when the device-link error is printed - it is at > power-domain > controller probe, not at the rocket probe: > > [ 2.700618] vdd_npu: Bringing 500000uV into 825000-825000uV > [ 2.749637] rockchip-pm-domain > fdd90000.power-management:power-controller: > Failed to create device link (0x180) with supplier 0-0020 for > /power-management@fdd90000/power-controller/power-domain@6 > [ 2.945955] platform fde40000.npu: Adding to iommu group 3 > ... > [ 6.840374] rocket: loading out-of-tree module taints kernel. > [ 6.877647] [drm] Initialized rocket 0.0.0 for rknn on minor 0 > [ 6.879950] rocket fde40000.npu: Rockchip NPU core 0 version: 0 > > So the device-link to the rk809 PMIC (0-0020) fails to form at ~2.75 > s, well before rocket > loads at ~6.8 s. It is non-fatal here - the vdd_npu rail is brought up > by the regulator core > and all jobs run - and there is no "failed to get ack on domain npu" > NoC warning this boot > (the always-on kernel had one). The complete boot log is attached. > > Two notes / one question: > - This boot used fw_devlink=permissive on the command line. Is the > "Failed to create device > link ... supplier 0-0020" at pmdomain probe expected/benign, or is > there a clean way to make > it order correctly (so it also works without permissive, and a =y > build wouldn't deadlock in > the initcalls)?
We encountered the same issue on the RK3588 NPU before. And it was resolved with the following patch at that time. https://lore.kernel.org/all/[email protected]/ Please compare the differences in NPU pmdomain and DTS configuration between the RK3568 and RK3588. > - (The convolution output is still uniform zero-point / the job times > out - that is the > separate NPU compute-completion issue, unrelated to the power-domain > work. Finley, that is > the one I flagged earlier re PVTPLL/NoC.) > > Kind regards, > Midgy > -- Best, Chaoyi
