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: <Ykx4u+E/vDNrQRUg@ripper>
Date:   Tue, 5 Apr 2022 10:13:31 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Bean Huo <beanhuo@...ron.com>,
        Bart Van Assche <bvanassche@....org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Taniya Das <tdas@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-scsi@...r.kernel.org
Subject: Re: [RFC PATCH 3/4] arm64: dts: qcom: sdm845: control RPMHPD
 performance states with UFS

On Sun 03 Apr 17:02 PDT 2022, Dmitry Baryshkov wrote:

> On 01/04/2022 17:58, Krzysztof Kozlowski wrote:
> > UFS, when scaling gears, should choose appropriate performance state of
> > RPMHPD power domain controller.  Since UFS belongs to UFS_PHY_GDSC power
> > domain, add necessary parent power domain to GCC.
> 
> This will cause all gcc GDSCs to be rooted in the CX. Are we sure that this
> is an expected (and correct) change?
> 

Per the last part of Rajendra's reply in [1], this should be fine.
Naturally we might have to come up with some way to bind gdscs to one of
multiple power-domains if that changes.

[1] https://lore.kernel.org/all/5e572c50-d6fe-5a21-d09f-f11a072538c5@codeaurora.org/

Regards,
Bjorn

> > 
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> > ---
> >   arch/arm64/boot/dts/qcom/sdm845.dtsi | 17 ++++++++++++++++-
> >   1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index b31bf62e8680..c999b41c2605 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -1078,6 +1078,7 @@ gcc: clock-controller@...000 {
> >   			#clock-cells = <1>;
> >   			#reset-cells = <1>;
> >   			#power-domain-cells = <1>;
> > +			power-domains = <&rpmhpd SDM845_CX>;
> >   		};
> >   		qfprom@...000 {
> > @@ -2336,8 +2337,22 @@ ufs_mem_hc: ufshc@...4000 {
> >   				<0 0>,
> >   				<0 0>,
> >   				<0 300000000>;
> > -
> > +			operating-points-v2 = <&ufs_opp_table>;
> >   			status = "disabled";
> > +
> > +			ufs_opp_table: opp-table {
> > +				compatible = "operating-points-v2";
> > +
> > +				opp-50000000 {
> > +					opp-hz = /bits/ 64 <50000000>;
> > +					required-opps = <&rpmhpd_opp_svs>;
> > +				};
> > +
> > +				opp-200000000 {
> > +					opp-hz = /bits/ 64 <200000000>;
> > +					required-opps = <&rpmhpd_opp_nom>;
> > +				};
> > +			};
> >   		};
> >   		ufs_mem_phy: phy@...7000 {
> 
> 
> -- 
> With best wishes
> Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ