.../boot/dts/rockchip/rk3588s-lubancat-4.dts | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+)
The three RKNN cores and their IOMMUs are disabled by default in the SoC
dtsi, so the board has to describe the NPU supply before they can be
enabled.
This board feeds both the NPU logic and its SRAM from a single RK8602
output on i2c1. The vendor DTS makes that explicit by giving the same
regulator node two labels, vdd_npu_s0 and vdd_npu_mem_s0, and then
handing one to rknpu-supply and the other to mem-supply. There is no
separate memory rail to describe, so npu-supply and sram-supply both
point at vdd_npu_s0. The binding requires both properties.
Neither property is what actually enables the rail: the rocket driver
never requests a regulator, it only takes clocks, resets, register
ranges and a power domain. The rk3588 power domain driver marks
RK3588_PD_NPU as needing a regulator, so the rail has to be described on
pd_npu, the root of VD_NPU that the three per-core domains hang off.
This matches what rock-5b does.
Mainline has no NPU OPP table, so all three cores stay at the 200 MHz
the SoC dtsi assigns to the shared SCMI clock. Clocking them higher
needs an OPP table to move vdd_npu_s0 along with the frequency, which is
left for later work.
Tested on rev 20241026 hardware: all three cores probe, each reporting
NPU core version 1179210309 and landing in its own IOMMU group, the
rocket driver registers /dev/accel/accel0, vdd_npu_s0 comes up enabled
at 800 mV and dmesg is free of NPU errors.
Signed-off-by: Pufan Jin <2254650260@qq.com>
---
.../boot/dts/rockchip/rk3588s-lubancat-4.dts | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts b/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
index a0fc128ce6e1..c623a4c46d22 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
@@ -365,6 +365,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
hym8563_int: hym8563-int {
@@ -407,6 +411,36 @@ &pwm0 {
status = "okay";
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&saradc {
vref-supply = <&avcc_1v8_s0>;
status = "okay";
--
2.55.0On Tue, Aug 4, 2026 at 9:49 AM Pufan Jin <2254650260@qq.com> wrote: > > The three RKNN cores and their IOMMUs are disabled by default in the SoC > dtsi, so the board has to describe the NPU supply before they can be > enabled. > > This board feeds both the NPU logic and its SRAM from a single RK8602 > output on i2c1. The vendor DTS makes that explicit by giving the same > regulator node two labels, vdd_npu_s0 and vdd_npu_mem_s0, and then > handing one to rknpu-supply and the other to mem-supply. There is no > separate memory rail to describe, so npu-supply and sram-supply both > point at vdd_npu_s0. The binding requires both properties. > > Neither property is what actually enables the rail: the rocket driver > never requests a regulator, it only takes clocks, resets, register > ranges and a power domain. The rk3588 power domain driver marks > RK3588_PD_NPU as needing a regulator, so the rail has to be described on > pd_npu, the root of VD_NPU that the three per-core domains hang off. > This matches what rock-5b does. As you mentioned here, the power domain will control the regulator. So please remove the regulator-always-on from the regulator. Jimmy
On Wed, Aug 5, 2026 at 11:48 AM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> As you mentioned here, the power domain will control the regulator. So
> please remove the regulator-always-on from the regulator.
You are right, thanks. always_on makes _regulator_disable() skip its
last-user branch, so the regulator_disable() that pd_npu issues never
reaches the hardware and the rail stays up regardless.
Dropped in v2 and retested: the three cores still probe and
regulator_summary shows vdd_npu_s0 back at a use count of zero while the
NPU is idle, so nothing pins the rail any more.
Same change commit de5b39d16318 ("arm64: dts: rockchip: Remove
workaround that prevented Turing RK1 GPU power regulator control") made
for vdd_gpu_s0. I did not add a Fixes: tag, since pd_npu had no
domain-supply before this patch and so there was nothing for always_on
to block.
Pufan
The three RKNN cores and their IOMMUs are disabled by default in the SoC
dtsi, so the board has to describe the NPU supply before they can be
enabled.
This board feeds both the NPU logic and its SRAM from a single RK8602
output on i2c1. The vendor DTS makes that explicit by giving the same
regulator node two labels, vdd_npu_s0 and vdd_npu_mem_s0, and then
handing one to rknpu-supply and the other to mem-supply. There is no
separate memory rail to describe, so npu-supply and sram-supply both
point at vdd_npu_s0. The binding requires both properties.
Neither property is what actually enables the rail: the rocket driver
never requests a regulator, it only takes clocks, resets, register
ranges and a power domain. The rk3588 power domain driver marks
RK3588_PD_NPU as needing a regulator, so the rail has to be described on
pd_npu, the root of VD_NPU that the three per-core domains hang off.
This matches what rock-5b does.
Since pd_npu now controls the rail, drop regulator-always-on from
vdd_npu_s0 so the domain can power it down while the NPU is idle.
Nothing else is supplied from this rail, and rock-5b describes the same
regulator without the property.
Mainline has no NPU OPP table, so all three cores stay at the 200 MHz
the SoC dtsi assigns to the shared SCMI clock. Clocking them higher
needs an OPP table to move vdd_npu_s0 along with the frequency, which is
left for later work.
Tested on rev 20241026 hardware: all three cores probe, each reporting
NPU core version 1179210309 and landing in its own IOMMU group, the
rocket driver registers /dev/accel/accel0, and dmesg is free of NPU
errors. With the rail no longer pinned on, regulator_summary shows
vdd_npu_s0 at a use count of zero while the NPU is idle, so pd_npu is
free to drop it.
Signed-off-by: Pufan Jin <2254650260@qq.com>
---
Changes in v2:
- Drop regulator-always-on from vdd_npu_s0, so pd_npu can actually power
the rail down. Thanks to Jimmy Hon for spotting it. This mirrors
commit de5b39d16318 ("arm64: dts: rockchip: Remove workaround that
prevented Turing RK1 GPU power regulator control"), which did the same
for vdd_gpu_s0 once the domain-supply was in place.
- Mention the change in the commit message and retest with it.
- v1: https://lore.kernel.org/linux-rockchip/tencent_FF56D057857A89EBFD82C037D80A53598C06@qq.com/
.../boot/dts/rockchip/rk3588s-lubancat-4.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts b/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
index a0fc128ce6e1..e5c2e77d86c2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4.dts
@@ -276,7 +276,6 @@ vdd_npu_s0: regulator@42 {
reg = <0x42>;
fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_npu_s0";
- regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
@@ -365,6 +364,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
hym8563_int: hym8563-int {
@@ -407,6 +410,36 @@ &pwm0 {
status = "okay";
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&saradc {
vref-supply = <&avcc_1v8_s0>;
status = "okay";
--
2.55.0© 2016 - 2026 Red Hat, Inc.