linux-kernel - Re: [PATCH] arm64: dts: qcom: sm8550: Update EAS 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] [day] [month] [year] [list]

Message-ID: <8ba352c0-7674-4e94-9cd4-c1327179034e@oss.qualcomm.com>
Date: Tue, 3 Feb 2026 11:19:11 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Lukasz Luba <lukasz.luba@....com>, Viresh Kumar
 <viresh.kumar@...aro.org>,
        webgeek1234@...il.com, Xilin Wu <wuxilin123@...il.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>, Viresh Kumar <vireshk@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: qcom: sm8550: Update EAS properties

On 2/2/26 10:28 AM, Lukasz Luba wrote:
> 
> 
> On 1/29/26 11:56, Konrad Dybcio wrote:
>> On 1/29/26 12:38 PM, Lukasz Luba wrote:
>>>
>>>
>>> On 1/29/26 11:23, Konrad Dybcio wrote:
>>>> On 1/29/26 12:05 PM, Viresh Kumar wrote:
>>>>> On 29-01-26, 12:00, Konrad Dybcio wrote:
>>>>>> On 1/28/26 8:11 PM, Aaron Kling via B4 Relay wrote:
>>>>>>> It should be noted that the A715 cores seem less efficient than the
>>>>>>> A710 cores. Therefore, an average value has been assigned to them,
>>>>>>> considering that the A715 and A710 cores share a single cpufreq
>>>>>>> domain.
>>>>>>
>>>>>> Regarding the CPUFreq domain shared across cores with different power
>>>>>> characteristics, I think we shouldn't be lying to the OS, rather Linux
>>>>>> should be able to deal with it, somehow.
>>>>>
>>>>> cpufreq-domain == cpufreq-policy here I guess. All CPUs that change
>>>>> their DVFS state together should be part of one policy. Not sure if
>>>>> there is something else you were pointing at.
>>>>
>>>> Yes, they change their state together.
>>>>
>>>> The question is whether it's okay for these CPUs to have different
>>>> dynamic-power-coefficient values, and whether the EM code won't be
>>>> thrown off by that.
>>>
>>> The Energy Model won't support that, since it's a single
>>> instance per-cpufreq-policy and we have to pick 'some' values (in this
>>> case).
>>
>> Do you think taking an average, like suggested by the original author,
>> makes sense here?
>>
>>>> Again, they differ because within that shared policy, there's 2
>>>> separate kinds of cores (2x Cortex-A715 + 2x Cortex-A710).
>>>>
>>>
>>> For this SoC I assume the physical HW (power rail and frequency domain)
>>> is linked to those 4 CPUs. That's quite novel configuration...
>>>
>>> Maybe I could give you some hint at least for the EAS part (the EM
>>> for EAS), because for something in other areas (e.g. thermal) might
>>> be really tough.
>>
>> In this case, these cores have **fairly** similar power/perf
>> characteristics, as evidenced by the measurements in the root of
>> this thread, see:
>>
>> https://lore.kernel.org/linux-arm-msm/20260128-sm8550-eas-v1-1-fb80615bed5c@gmail.com/
>>
>>> What are the other CPUs in that SoC and their DVFS configs?
>>
>> Domain 0: 3x A510
>> Domain 1: 2x A715 + 2x A710
>> Domain 2: 1x X3
>>
> 
> I have analyzed that data both: power and performance
> (the 7-zip benchmark). It looks good and might fly upstream.
> Although, I wonder if that benchmark truly reflects the
> workload for that gaming handheld...

FWIW this is the common SoC DT, the author of the patch only happens
to have that SoC inside a gaming handheld


> For 'normal' usage (mix of stuff running on a device, not
> mainly games) these derived numbers are promising.
> The plot that I got for the Energy Model shows fairly
> similar efficiency for a710 and a715 - which is expected.
> There is also a nice size (60%) of an overlapping region to operate
> on for the EAS. That would be typical model for day-of-usage
> with mixed scenario.
> The platform engineers can later modify the EM data in run-time
> to better reflect their workload's behavior on the SoC.
> 
> Since this is mainline change for sm8550 and looks - LGTM.
> 
> Reviewed-by: Lukasz Luba <lukasz.luba@....com>

Thanks for your insight!

Konrad