Re: [RFC PATCH v3 4/6] accel/rocket: add RK3576 NPU (RKNN) support

[Igor Paunovic <royalnet026@gmail.com>]

Hi Jiaxing,

You mentioned you cannot exercise RK3588, so I ran this one on mine.

Tested on RK3588 (Orange Pi 5 Plus, all three rknn cores). Applied on a
v7.0-based Rockchip tree rather than next-20260730, so it went in with
small offsets in rocket_job.c, but the RK3588 paths it touches are
identical there.

What I checked:

- all three cores probe and report their version, runtime PM suspends
  and resumes them across a 60 s inference run;
- a MobileNetV1 run through the Teflon TFLite delegate is bit-identical
  to the stock driver - five output tensors hashed every iteration,
  4260 iterations, no mismatch;
- throughput measured back to back against the unpatched module in the
  same session: 70.99 vs 71.18 inf/s, i.e. no change. (Both are above
  my usual ~68 baseline because the firmware happened to be serving
  the 200 MHz request from a different clock path that session - it is
  unrelated to your patch, which is why I measured the stock module
  again straight afterwards rather than reporting the first number.)

Tested-by: Igor Paunovic <royalnet026@gmail.com>

I also went through the RK3588 side of the soc_data conversion, since
that is the part your board cannot tell you about. All seven soc->
users keep RK3588 on its old values: num_clks 4 and num_resets 2 match
the previous ARRAY_SIZE() results, and multi_power_domain and
poll_completion are both false, so both new branches are skipped. Worth
noting for anyone reading the diff quickly: growing clks[4] to clks[6]
is exactly why num_clks had to become explicit - leaving ARRAY_SIZE()
there would have made RK3588 ask for six clocks and fail probe. The
conversion looks right to me.

I am not commenting on the RK3576-specific parts - no hardware here for
that - and I have not tested 2/6 and 3/6, since those are built in and
would need a kernel rebuild.

Thanks,
Igor