linux-kernel - Re: [PATCH v2] arm64: dts: qcom: sc7280: Add capacity and DPC properties

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Nov 2023 13:58:29 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Ankit Sharma <quic_anshar@...cinc.com>,
        cros-qcom-dts-watchers@...omium.org, agross@...nel.org,
        andersson@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, quic_ashayj@...cinc.com,
        quic_atulpant@...cinc.com, quic_rgottimu@...cinc.com,
        quic_shashim@...cinc.com, quic_pkondeti@...cinc.com
Subject: Re: [PATCH v2] arm64: dts: qcom: sc7280: Add capacity and DPC properties

Hi,

On Mon, Nov 6, 2023 at 1:52 PM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>
>
>
> On 11/6/23 17:56, Doug Anderson wrote:
> > Hi,
> >
> > On Sat, Nov 4, 2023 at 4:52 AM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
> >>
> >>
> >>
> >> On 11/3/23 11:54, Ankit Sharma wrote:
> >>> The "capacity-dmips-mhz" and "dynamic-power-coefficient" are
> >>> used to build Energy Model which in turn is used by EAS to take
> >>> placement decisions. So add it to SC7280 soc.
> >>>
> >>> Signed-off-by: Ankit Sharma <quic_anshar@...cinc.com>
> >>> ---Hi, thanks for this patch
> >>
> >> Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> >>
> >> I performed a quick grep in arch/arm64/boot/dts/qcom and noticed
> >> that at least one of these values is missing for:
> >>
> >> rg -l --files-without-match dynamic-power-coeff $(rg cpu@ -l) | sort
> >> ipq5018.dtsi (homogeneous cluster)
> >> ipq5332.dtsi (homogeneous cluster)
> >> ipq6018.dtsi (homogeneous cluster)
> >> ipq8074.dtsi (homogeneous cluster)
> >> ipq9574.dtsi (homogeneous cluster)
> >> msm8916.dtsi (homogeneous cluster)
> >> msm8939.dtsi
> >> msm8953.dtsi
> >> msm8976.dtsi
> >> msm8994.dtsi
> >> msm8996.dtsi
> >> msm8998.dtsi
> >> qcs404.dtsi (homogeneous cluster)
> >> qdu1000.dtsi (homogeneous cluster)
> >> sa8775p.dtsi
> >> sc7280.dtsi
> >> sc8180x.dtsi
> >> sc8280xp.dtsi
> >> sdm630.dtsi
> >> sm4450.dtsi
> >> sm6125.dtsi
> >> sm6375.dtsi
> >> sm8350.dtsi
> >> sm8450.dtsi
> >>
> >> rg -l --files-without-match capacity-dmips $(rg cpu@ -l) | sort
> >> ipq5018.dtsi (homogeneous cluster)
> >> ipq5332.dtsi (homogeneous cluster)
> >> ipq6018.dtsi (homogeneous cluster)
> >> ipq8074.dtsi (homogeneous cluster)
> >> ipq9574.dtsi (homogeneous cluster)
> >> msm8916.dtsi (homogeneous cluster)
> >> msm8939.dtsi
> >> msm8994.dtsi
> >> qcs404.dtsi (homogeneous cluster)
> >> qdu1000.dtsi (homogeneous cluster)
> >> sa8775p.dtsi
> >> sc7280.dtsi
> >> sm4450.dtsi
> >> sm6375.dtsi
> >> sm8350.dtsi
> >> sm8450.dtsi
> >>
> >> Where platforms with a single, homogeneous cluster likely don't
> >> benefit from EAS..
> >>
> >> Is there any chance you could dig up the correct values, for at least
> >> some of these platforms? Or would you know whom to ask?
> >>
> >> FWIW the one we're missing the most is sc8280xp..
> >
> > FWIW, I wrote up a longwinded commit message when I added these values
> > for sc7180. See commit 82ea7d411d43 ("arm64: dts: qcom: sc7180: Base
> > dynamic CPU power coefficients in reality").
> >
> > The short of it is that if you have hardware and a basic "smart
> > battery" to measure power consumption it's pretty easy for anyone to
> > add some reasonable numbers.
> That's a big ask, especially with stupid laptop battmgr firmware that
> only refreshes data every 5 to 25 seconds :)

Meh, the script I wrote (which you can find by following the text of
the commit message or just looking here [1] should handle that OK.
While the script is ugly, I wrote it to handle pretty non-granular
measurements. Right now it's set to test each frequency for 2 minutes
(min_time_per_freq) but it wouldn't be hard to make that 10 minutes
per frequency.

[1] https://lore.kernel.org/all/CAD=FV=U1FP0e3_AVHpauUUZtD-5X3XCwh5aT9fH_8S_FFML2Uw@mail.gmail.com/


> Qcom probably has some reasonable numbers somewhere, given they are
> likely to test their SoCs' characteristics before taping them out
> en masse :P

Sure, if Qualcomm can give numbers that'd be wonderful. In the past
they haven't been willing to and I tried to convince them that was
silly because anyone with access to the hardware could measure this
themselves. If Qualcomm has become more reasonable about this then
that makes me happy.

-Doug