[RFC PATCH v3 0/9] accel: rocket: Add RK3568 NPU support

[Midgy Balon]

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 at fdd90000/power-controller/power-domain at 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)?
- (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

Le lun. 8 juin 2026 à 11:38, Chaoyi Chen <chaoyi.chen at rock-chips.com> a écrit :
>
> Hi Midgy,
>
> On 6/8/2026 5:14 PM, Midgy Balon wrote:
> > Hello Chaoyi,
> >
> > Following up on the need_regulator suggestion -- I implemented and
> > tested it on the
> > board, and unfortunately it doesn't avoid the deadlock on RK3568; it
> > moves it from
> > boot to the NPU job submit.
> >
> > What I did: gave the RK3568 NPU power domain a regulator (a DOMAIN_M_R
> > variant with
> > need_regulator = true), wired domain-supply = <&vdd_npu>, and dropped the
> > regulator-always-on workaround.
> >
> > Boot is now clean and the NPU probes, but there is a warning during boot:
> >
> >   rockchip-pm-domain ...: Failed to create device link (0x180) with supplier
> >   0-0020 for .../power-domain at 6
> >
> > (0-0020 is the rk809 PMIC that supplies vdd_npu.) Then on the first NPU job
> > submit the board hard-hangs with an RCU stall:
> >
> >   rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> >   rcu:     3-...!: (1 GPs behind) ...
> >   rcu: rcu_preempt kthread starved for 5115 jiffies! ... RCU_GP_WAIT_FQS(5)
> >   rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected
> >
> > My reading: vdd_npu is on the rk809 *I2C* PMIC, so when genpd
> > enables/disables the
> > regulator during the NPU's runtime-PM power transition, the I2C
> > transfer runs in a
> > context that starves RCU and the box freezes. (I suspect
> > need_regulator is fine on
> > the RK3588 NPU because its supply isn't behind an I2C PMIC.) The always-on
> > workaround avoids this precisely because genpd never touches the I2C
> > regulator in
> > that path.
> >
>
> No, they are all controlled by RK809.
>
> And This looks werid. Is your rocket driver compiled as a module?
> Please try compiling it as a module. When is the above error printed?
> Please provide the complete boot log.
>
> > So: for an NPU domain whose supply is an I2C PMIC, is there a
> > supported way to let
> > genpd own the regulator without performing the I2C op in the
> > power-transition path
> > (a deferred/async regulator enable, or a flag), or should RK3568 keep vdd_npu as
> > regulator-always-on? For v4 I'll keep always-on unless there's a cleaner path.
> >
>
> --
> Best,
> Chaoyi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2026-06-09_rocket-m-needreg.log
Type: text/x-log
Size: 70113 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260609/554e3e6d/attachment-0001.bin>