Re: [RFC PATCH v3 4/6] accel/rocket: add RK3576 NPU (RKNN) support
Igor Paunovic <[email protected]> Fri, 31 Jul 2026 18:10:26 +0200
| Newsgroups | org.infradead.lists.linux-rockchip,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 _______________________________________________ Linux-rockchip mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-rockchip