Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20231103105440.23904-1-quic_anshar@quicinc.com>
 <feca8e74-6653-4cec-943d-47302431e1fc@linaro.org> <CAD=FV=VTCXSQo3Bo3G7oJ48qA-fUet5rHAzT8WLM1Hx70KyYMA@mail.gmail.com>
 <a3f3c391-370a-4ed2-92ed-afcfbea829e8@linaro.org>
In-Reply-To: <a3f3c391-370a-4ed2-92ed-afcfbea829e8@linaro.org>
From:   Doug Anderson <dianders@chromium.org>
Date:   Mon, 6 Nov 2023 13:58:29 -0800
Message-ID: <CAD=FV=VojU57uDUi3uByNKKBQnUhTXP6f=kK1C9E_Mgih2aMCA@mail.gmail.com>
Subject: Re: [PATCH v2] arm64: dts: qcom: sc7280: Add capacity and DPC properties
To:     Konrad Dybcio <konrad.dybcio@linaro.org>
Cc:     Ankit Sharma <quic_anshar@quicinc.com>,
        cros-qcom-dts-watchers@chromium.org, agross@kernel.org,
        andersson@kernel.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, quic_ashayj@quicinc.com,
        quic_atulpant@quicinc.com, quic_rgottimu@quicinc.com,
        quic_shashim@quicinc.com, quic_pkondeti@quicinc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Mon, Nov 6, 2023 at 1:52=E2=80=AFPM Konrad Dybcio <konrad.dybcio@linaro.=
org> wrote:
>
>
>
> On 11/6/23 17:56, Doug Anderson wrote:
> > Hi,
> >
> > On Sat, Nov 4, 2023 at 4:52=E2=80=AFAM Konrad Dybcio <konrad.dybcio@lin=
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@quicinc.com>
> >>> ---Hi, thanks for this patch
> >>
> >> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.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=3DFV=3DU1FP0e3_AVHpauUUZtD-5X3XCwh5aT9f=
H_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