[PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC

[Shuwei Wu]

Hi Anand,

Thank you for your consistent attention and practical suggestions.

On Sun May 17, 2026 at 12:35 PM CST, Anand Moon wrote:
> Hi Shuwei,
>
> On Wed, 22 Apr 2026 at 11:44, Anand Moon <linux.amoon at gmail.com> wrote:
>>
>> Hi Shuwei,
>>
>> On Tue, 21 Apr 2026 at 22:41, Aurelien Jarno <aurelien at aurel32.net> wrote:
>> >
>> > Hi,
>> >
>> > On 2026-04-21 16:10, Shuwei Wu wrote:
>> > > Hi Aurelien,
>> > >
>> > > Thanks for your addition.
>> > >
>> > > On Tue Apr 21, 2026 at 5:16 AM CST, Aurelien Jarno wrote:
>> > > > Hi Anand,
>> > > >
>> > > > On 2026-04-16 17:07, Anand Moon wrote:
>> > > >> After reviewing the Banana Pi F3 schematics, I confirmed that Buck1 and Buck2
>> > > >> Both supply the CORE_0V9 with 0.9V±1% rail. To resolve the restriction errors,
>> > > >> I expanded the voltage range in the DTS to 500,000–950,000 µV.
>> > > >>
>> sorry I was wrong from the doc below 1.2.1 CORE Power Design
>>
>> The typical core voltage is 0.9 V to 1.05 V. Actual voltage is
>> dynamically regulated by
>> the **remote-sense dynamic voltage** adjustment circuit inside P1.
>> P1 BUCK1 and BUCK2 must be combined to supply the core rail.
>>
>> [1] https://www.spacemit.com/community/document/info?nodepath=hardware/key_stone/k1/k1_hw/k1_hw_design_guide.md&lang=en
>>
>> > > >> Additionally, I updated the DTS to map the second CPU cluster (cores 4–7)
>> > > >> to Buck2 to better align with the hardware's power distribution.
>> > > >
>> > > > Actually the output of Buck1 and Buck2 are connected together, so they
>> > > > should always be configured with the same output voltage. And both
>> > > > clusters should be mapped to both outputs.
>> > >
>> > > You are right, I received the same response from the official developers.
>> > >
>> > > Therefore, I'm wondering if an additional regulator-coupled-with: property
>> > > definition is also needed here?
>> >
>> correct.
>> > Yes, I think this is the way to go. I even wonder if this shouldn't be a
>> > fix with Cc: stable. This also has to be done for the Milk-V Jupiter
>> > board, I haven't checked the other boards yet, but I guess they all use
>> > the same schematics at that the PMIC level.
>> >
>> > Regards
>> > Aurelien
>> >
>
> The following changes resolve the warning on my setup.
> If possible, please integrate them into the next version.
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> index c2a1b759d41f..8512c7417f94 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> @@ -116,19 +116,19 @@ &cpu_3 {
>  };
>
>  &cpu_4 {
> -       cpu-supply = <&buck1_3v45>;
> +       cpu-supply = <&buck2_3v45>;
>  };
>
>  &cpu_5 {
> -       cpu-supply = <&buck1_3v45>;
> +       cpu-supply = <&buck2_3v45>;
>  };
>
>  &cpu_6 {
> -       cpu-supply = <&buck1_3v45>;
> +       cpu-supply = <&buck2_3v45>;
>  };
>
>  &cpu_7 {
> -       cpu-supply = <&buck1_3v45>;
> +       cpu-supply = <&buck2_3v45>;
>  };
>
>  &emmc {
> @@ -248,14 +248,14 @@ pmic at 41 {
>                 regulators {
>                         buck1_3v45: buck1 {
>                                 regulator-min-microvolt = <500000>;
> -                               regulator-max-microvolt = <3450000>;
> +                               regulator-max-microvolt = <950000>;
>                                 regulator-ramp-delay = <5000>;
>                                 regulator-always-on;
>                         };
>
> -                       buck2 {
> +                       buck2_3v45: buck2 {
>                                 regulator-min-microvolt = <500000>;
> -                               regulator-max-microvolt = <3450000>;
> +                               regulator-max-microvolt = <1050000>;
>                                 regulator-ramp-delay = <5000>;
>                                 regulator-always-on;
>                         };

As previously discussed, Buck1 and Buck2 are connected and must share the same
voltage. However, you not only separated them but also set their voltage ranges
to different values, which violates the requirement.

Additionally, in the schematic, 0.9V represents the default output voltage,
not the maximum.

The problem you noted likely stems from different clusters sharing
the same voltage while having different OPP tables.

In the new patch, I will unify them to use the same OPP table.

>
> Thnaks
> -Anand

-- 
Best regards,
Shuwei Wu