From: sashiko-bot@kernel.org
To: "Jiaxing Hu" <gahing@gahingwoo.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
conor+dt@kernel.org, robh@kernel.org
Subject: Re: [RFC PATCH v5 v5 7/8] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes
Date: Wed, 05 Aug 2026 07:46:51 +0000 [thread overview]
Message-ID: <20260805074652.7AD9B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805063826.95682-8-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree nodes are padded with fake power-domain dependencies to bypass the Linux driver core's single-domain auto-attach mechanism.
--
--- Patch [7]: [RFC PATCH v5 v5 7/8] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes ---
commit 2901ef2a9f2683429a8cc97e3be5786a1b6b21b5
Author: Jiaxing Hu <gahing@gahingwoo.com>
arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes
Add the two RKNN cores and their IOMMUs for the rk3576. Both cores are
disabled by default, and boards can enable what they wire up. The NPU
power-domain resets are also added.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
[ ... ]
> @@ -1832,6 +1840,74 @@ qos_npu_m1ro: qos@27f22100 {
[ ... ]
> + rknn_core_0: npu@27700000 {
> + compatible = "rockchip,rk3576-rknn-core";
[ ... ]
> + resets = <&cru SRST_A_RKNN0>;
> + reset-names = "srst_a";
> + power-domains = <&power RK3576_PD_NPU0>, <&power RK3576_PD_NPU1>;
[Severity: Medium]
Are these power domains accurately describing the hardware topology, or are they
encoding a software workaround?
The commit message mentions that listing both domains prevents the driver core
from auto-attaching a single domain. Device trees should accurately describe the
hardware instead of encoding software workarounds to bypass driver core behavior.
[ ... ]
> + rknn_core_1: npu@27708000 {
> + compatible = "rockchip,rk3576-rknn-core";
[ ... ]
> + resets = <&cru SRST_A_RKNN1>;
> + reset-names = "srst_a";
> + power-domains = <&power RK3576_PD_NPU1>, <&power RK3576_PD_NPU0>;
[Severity: Medium]
Will padding the power-domains list with RK3576_PD_NPU0 on rknn_core_1 cause
unintended side effects?
Since this artificially inflates the power-domain count to bypass the OS
auto-attach mechanism, it appears it will cause the system to unnecessarily
power on NPU0 when only Core 1 is active, wasting energy.
> + iommus = <&rknn_mmu_1>;
> + status = "disabled";
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805063826.95682-1-gahing@gahingwoo.com?part=7
next prev parent reply other threads:[~2026-08-05 7:46 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 6:38 [RFC PATCH v5 0/8] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 6:38 ` [RFC PATCH v5 v5 1/8] dt-bindings: npu: rockchip: add rockchip, rk3576-rknn-core Jiaxing Hu
2026-08-05 6:38 ` [RFC PATCH v5 v5 1/8] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 6:38 ` [RFC PATCH v5 v5 2/8] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 6:38 ` [RFC PATCH v5 v5 3/8] dt-bindings: iommu: rockchip: allow the RK3576 NPU MMU clock set Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 7:10 ` sashiko-bot
2026-08-05 6:38 ` [RFC PATCH v5 v5 4/8] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 7:19 ` sashiko-bot
2026-08-05 6:38 ` [RFC PATCH v5 v5 5/8] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 7:27 ` sashiko-bot
2026-08-05 12:13 ` Philipp Zabel
2026-08-05 12:13 ` Philipp Zabel
2026-08-05 6:38 ` [RFC PATCH v5 v5 6/8] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 7:39 ` sashiko-bot
2026-08-05 10:34 ` Igor Paunovic
2026-08-05 10:34 ` Igor Paunovic
2026-08-05 12:52 ` Diederik de Haas
2026-08-05 12:52 ` Diederik de Haas
2026-08-05 14:06 ` Igor Paunovic
2026-08-05 14:06 ` Igor Paunovic
2026-08-05 14:07 ` Igor Paunovic
2026-08-05 14:07 ` Igor Paunovic
2026-08-05 14:35 ` Igor Paunovic
2026-08-05 14:35 ` Igor Paunovic
2026-08-05 6:38 ` [RFC PATCH v5 v5 7/8] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 7:46 ` sashiko-bot [this message]
2026-08-05 6:38 ` [RFC PATCH v5 v5 8/8] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-08-05 6:38 ` Jiaxing Hu
2026-08-05 9:06 ` [RFC PATCH v5 0/8] accel/rocket: RK3576 NPU (RKNN) enablement Igor Paunovic
2026-08-05 9:06 ` Igor Paunovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260805074652.7AD9B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.