[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAATStaPRS0Tduo7czesD9rzBDfVLgiWrHUQi+kAadGZAvUv+GA@mail.gmail.com>
Date: Tue, 25 Aug 2020 15:30:22 +1000
From: "Anand K. Mistry" <amistry@...gle.com>
To: "moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>
Cc: djkurtz@...omium.org, Matthias Brugger <matthias.bgg@...il.com>,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] CHROMIUM: arm64: dts: mt8183-elm: Set GPU power regulator
to always on
:facepalm: sorry about the subject line. I'll fix it up in the next revision.
On Tue, 25 Aug 2020 at 15:26, Anand K Mistry <amistry@...gle.com> wrote:
>
> 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 a Elm DVT shows that the change in
> power usage is negligible. The two relavent cases are S0 with an idle
> GPU, and S3.
>
> 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@...gle.com>
>
> ---
>
> 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
>
--
Anand K. Mistry
Software Engineer
Google Australia
Powered by blists - more mailing lists