[PATCH v2] arm64: dts: mt8173-elm: Set GPU power regulator to always on
Anand K Mistry
amistry at google.com
Wed Aug 26 21:49:52 EDT 2020
Keep the da9212 BUCKB always-on. This works around an issue on Elm/Hana
devices where sometimes, the regulator is disabled before scpsys is
suspended, causing the suspension of scpsys to fail.
Usually, the GPU and scpsys are suspended by the runtime PM before the
system is suspended, due to the GPU being idle. In this case, scpsys is
suspended inline with the GPU suspend, which then disables the
regulator. However, if the GPU is still active when system is suspended,
GPU suspend occurs but defers suspending scpsys to the PM's noirq phase.
Since GPU suspend disables the regulator, scpsys isn't powered and
suspending it fails with the following error:
[ 523.773227] mtk-scpsys 10006000.scpsys: Failed to power off domain mfg_2d
On resume, scpsys is resumed in the noirq phase. Since scpsys requires
power from the regulator, which is still disabled at this point,
attempting to turn it on will hang the CPU. A HW watchdog eventually
reboots the system.
The obvious solution would be to add a link to the regulator from scpsys
in the devicetree. This would prevent the regulator from being disabled
until scpsys is suspended. However, in the case where suspending scpsys
is deferred to the noirq phase, disabling the regulator will fail since
it is connected over I2C which requires IRQs to be enabled. Even in the
usual case where scpsys is suspended inline with the GPU, PM will always
attempt to resume scpsys in noirq. This will attempt to enable the
regulator, which will also fail due to being unable to communicate over
I2C.
Since I2C can't be using with IRQs disabled, a workaround is to never
turn off the regulator.
Measuring power on the GPU rail on an Elm DVT device shows that the
change in power usage is negligible. The two relavent cases are S0 with
an idle GPU, and S3 (system suspended). Measurements taken using a debug
board every 100ms for 1 minute.
In S0 with an idle GPU, current behaviour with the regulator off:
@@ NAME COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw 600 1.74 1.31 6.75 0.00
... and with the regulator on, but no load:
@@ NAME COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw 600 1.68 1.25 7.13 0.00
The difference being well within the margin of error.
In S3, current behaviour with the regulator off:
@@ NAME COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw 600 0.94 0.74 3.25 0.00
... and with the regulator on:
@@ NAME COUNT AVERAGE STDDEV MAX MIN
@@ gpu_mw 600 0.83 0.66 3.25 0.00
Signed-off-by: Anand K Mistry <amistry at google.com>
---
Changes in v2:
- Remove CHROMIUM from subject line
- Correct device in subject line (8183 -> 8173)
- Grammar/clarity changes in description
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a5a12b2599a4..1294f27b21c1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -304,6 +304,7 @@ da9211_vgpu_reg: BUCKB {
regulator-min-microamp = <2000000>;
regulator-max-microamp = <3000000>;
regulator-ramp-delay = <10000>;
+ regulator-always-on;
};
};
};
--
2.28.0.297.g1956fa8f8d-goog
More information about the linux-arm-kernel
mailing list