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/