Hi, On Wed Jun 10, 2026 at 3:14 AM CEST, Chaoyi Chen wrote: > 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.
About a month ago on #linux-rockchip we were discussing PM 'stuff': https://libera.catirclogs.org/linux-rockchip/2026-05-15#39939137; which references this paste https://paste.sr.ht/~diederik/89d9f84e22474e837b55286d213b67f03859ce2e I've since removed the DCDC_REG2 for PineTab2 and the 'fix' should likely be extended to cover all RK3566/RK3568 devices though. It's what I made at the time hoping to fix a suspend/resume issue when trying upstream TF-A. It didn't fix the issue at the time, but may still be useful/needed and I think it's what Chaoyi hinted at. Just yesterday, Jonas posted this patch which may be useful/needed too: https://lore.kernel.org/linux-rockchip/[email protected]/ HTH, Diederik >> - (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 >>
