Re: [PATCH] arm64: dts: rockchip: Add OPP voltage ranges to RK3399 OP1 SoC dtsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Alexey,

On 2024-11-06 08:55, Alexey Charkov wrote:
On Wed, Nov 6, 2024 at 11:50 AM Dragan Simic <dsimic@xxxxxxxxxxx> wrote:

Add support for voltage ranges to the CPU, GPU and DMC OPPs defined in the SoC dtsi for Rockchip OP1, as a variant of the Rockchip RK3399. This may be useful if there are any OP1-based boards whose associated voltage regulators are unable to deliver the exact voltages; otherwise, it causes no functional
changes to the resulting OPP voltages at runtime.

These changes cannot cause stability issues or any kind of damage, because it's perfectly safe to use the highest voltage from an OPP group for each OPP in the same group. The only possible negative effect of using higher voltages
is wasted energy in form of some additionally generated heat.

Reported-by: Quentin Schulz <quentin.schulz@xxxxxxxxx>
Signed-off-by: Dragan Simic <dsimic@xxxxxxxxxxx>
---
arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi | 52 ++++++++++----------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi
index b24bff511513..aa79219471d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi
@@ -12,125 +12,125 @@ cluster0_opp: opp-table-0 {

                opp00 {
                        opp-hz = /bits/ 64 <408000000>;
-                       opp-microvolt = <800000>;
+                       opp-microvolt = <800000 800000 1150000>;
                        clock-latency-ns = <40000>;
                };
                opp01 {
                        opp-hz = /bits/ 64 <600000000>;
-                       opp-microvolt = <825000>;
+                       opp-microvolt = <825000 825000 1150000>;
                };
                opp02 {
                        opp-hz = /bits/ 64 <816000000>;
-                       opp-microvolt = <850000>;
+                       opp-microvolt = <850000 850000 1150000>;
                };
                opp03 {
                        opp-hz = /bits/ 64 <1008000000>;
-                       opp-microvolt = <900000>;
+                       opp-microvolt = <900000 900000 1150000>;
                };
                opp04 {
                        opp-hz = /bits/ 64 <1200000000>;
-                       opp-microvolt = <975000>;
+                       opp-microvolt = <975000 975000 1150000>;
                };
                opp05 {
                        opp-hz = /bits/ 64 <1416000000>;
-                       opp-microvolt = <1100000>;
+                       opp-microvolt = <1100000 1100000 1150000>;
                };
                opp06 {
                        opp-hz = /bits/ 64 <1512000000>;
-                       opp-microvolt = <1150000>;
+                       opp-microvolt = <1150000 1150000 1150000>;
                };
        };

        cluster1_opp: opp-table-1 {
                compatible = "operating-points-v2";
                opp-shared;

                opp00 {
                        opp-hz = /bits/ 64 <408000000>;
                        opp-microvolt = <800000>;
-                       clock-latency-ns = <40000>;
+                       clock-latency-ns = <40000 40000 1250000>;

Did you mean to update opp-microvolt instead?

Oops, look at that! :/  Thanks for the correction, I'll send the v2
with the fix.  I created some macro in vim that produced the voltage
range additions, and as you can see, I applied that macro more than
a few times, and sometimes a bit carelessly. :/

Speaking of which, this single opp having clock-latency-ns while none
of the others do (except the first one in cluster0) looks weird.

Yes, I also noticed that.  Though, the way the OPP driver works, only
one of the OPPs need to have clock-latency-ns defined for everything
to work as expected.

I did "sprinkle" the missing clock-latency-ns values in one of my
other patches, [*] using the values from the vendor kernel source,
but in this case no such values are available from the vendor, so
we cannot go with "inventing" them somehow, and we need to keep
relying on the above-described OPP driver's behavior.

[*] https://lore.kernel.org/linux-rockchip/2e1e100284b1edb470d6e7fde021a0f1779336c8.1728752527.git.dsimic@xxxxxxxxxxx/




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux