Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths

[Konrad Dybcio]

On 18-Jun-26 06:37, Aaron Kling wrote:
> On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
> <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>
>> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@xxxxxxxxx>
>>>
>>> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
>>> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
>>> by aggregating bandwidth requests of all CPU core with reference to the
>>> current OPP they are configured in by the hardware.
>>>
>>> The effect is proper caches & DDR frequency scaling when CPU cores
>>> change frequency.
>>>
>>> The OPP tables were built using the downstream memlat ddr & llcc tables
>>> for each cluster types with the actual cpufreq LUT tables from running a
>>> CQ8725S device.
>>>
>>> Also add the interconnect entry for each cpu, with 2 different paths:
>>> - CPU to Last Level Cache Controller (LLCC)
>>> - Last Level Cache Controller (LLCC) to DDR
>>>
>>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
>>> ---
>>> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
>>> ---
>>
>> [...]
>>
>>> +     cpu6_opp_table: opp-table-cpu6 {
>>> +             compatible = "operating-points-v2";
>>> +             opp-shared;
>>> +
>>> +             opp-1017600000 {
>>> +                     opp-hz = /bits/ 64 <1017600000>;
>>> +                     opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>>
>> I think this should be * 4 in both cases since the interconnect driver
>> ignores the channel count for a node in peak voting. We may have a bug
>> in all other DTs here.
> 
> If this is confirmed, I can update this patch. I based the
> calculations on my sm8550 copy of this change, which in turn was based
> on the sm8650 change. If this is wrong, that means one piece is
> scaling 4x too quickly? Making it a power consumption issue, not a
> performance issue.
> 
>> BTW, are there no lower OPPs for the fast cores?
> 
> Not on cq8725s at least. These lists came from an AYN Odin 3 with that
> soc. I don't have any sm8750 proper devices to see if that's any
> different.

Mobile SM8750:

root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu6/cpufreq/scaling_available_frequencies
1017600 1209600 1401600 1689600 1958400 2246400 2438400 2649600 2841600 3072000 3283200 3513600 3840000 4089600

root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
384000 556800 748800 960000 1152000 1363200 1555200 1785600 1996800 2227200 2400000 2745600 2918400 3072000 3321600 3532800

root@qcom-armv8a:~# grep ^ /sys/bus/soc/devices/soc0/*
/sys/bus/soc/devices/soc0/family:Snapdragon
/sys/bus/soc/devices/soc0/machine:SM8750
/sys/bus/soc/devices/soc0/revision:2.0
/sys/bus/soc/devices/soc0/serial_number:<snip>
/sys/bus/soc/devices/soc0/soc_id:618

Konrad