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: <26e2aa8a-912b-4e83-ad00-130cc137aa4b@oss.qualcomm.com>
Date: Thu, 29 Jan 2026 12:56:09 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Lukasz Luba <lukasz.luba@....com>, Viresh Kumar <viresh.kumar@...aro.org>
Cc: webgeek1234@...il.com, 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,
        Xilin Wu <wuxilin123@...il.com>
Subject: Re: [PATCH] arm64: dts: qcom: sm8550: Update EAS properties

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

Konrad