linux-kernel - Re: [PATCH 1/3] arm64: dts: rockchip: set display regulators to always-on on BPI-R2-Pro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 18 May 2022 18:46:12 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     Frank Wunderlich <linux@...web.de>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] arm64: dts: rockchip: set display regulators to
 always-on on BPI-R2-Pro

On Tue, May 17, 2022 at 2:47 PM Heiko Stuebner <heiko@...ech.de> wrote:
>
> Am Freitag, 15. April 2022, 12:49:49 CEST schrieb Frank Wunderlich:
> > From: Frank Wunderlich <frank-w@...lic-files.de>
> >
> > Set display related regulators to always-on on Banana PI R2 Pro
> > board.
>
> Hmm, I'd expect some sort of explanation for the "why" here.
> It looks like both the gpu patch as well as the vop patch do
> reference the relevant regulators for the gpu+hdmi nodes,
> so in theory this shouldn't be necessary anymore?

I agree the hdmi power nodes don't need to be always on, if the hdmi
driver is handling them correctly. Unfortunately the gpu power supply
needs to stay always on until the issues with power-domains not being
regulator aware is resolved. Otherwise we run into issues like the one
mentioned in Lee's email, and issues where the gpu-regulator gets shut
down and we start getting mmu faults.

>
> >
> > Signed-off-by: Frank Wunderlich <frank-w@...lic-files.de>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> > index 2700fb18a3bc..0950f9659bb4 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> > @@ -225,6 +225,7 @@ regulator-state-mem {
> >
> >                       vdd_gpu: DCDC_REG2 {
> >                               regulator-name = "vdd_gpu";
> > +                             regulator-always-on;
> >                               regulator-init-microvolt = <900000>;
> >                               regulator-initial-mode = <0x2>;
> >                               regulator-min-microvolt = <500000>;
> > @@ -274,6 +275,7 @@ regulator-state-mem {
> >
> >                       vdda0v9_image: LDO_REG1 {
> >                               regulator-name = "vdda0v9_image";
> > +                             regulator-always-on;
> >                               regulator-min-microvolt = <900000>;
> >                               regulator-max-microvolt = <900000>;
> >
> > @@ -369,6 +371,7 @@ regulator-state-mem {
> >
> >                       vcca1v8_image: LDO_REG9 {
> >                               regulator-name = "vcca1v8_image";
> > +                             regulator-always-on;
> >                               regulator-min-microvolt = <1800000>;
> >                               regulator-max-microvolt = <1800000>;
> >
> >
>
>
>
>