Re: [PATCH] arm64: dts: qcom: sm8550: Update EAS properties

[Lukasz Luba]

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@xxxxxxxxx/
>
> > 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...

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@xxxxxxx>

Regards,
Lukasz