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]
Message-ID: <CAMdYzYqOEzNqwwRWx2U85uBBXtkz3OfVEWXDS-YCGmFg8Z7q5Q@mail.gmail.com>
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>;
> >
> >
>
>
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ