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

[Aaron Kling]

On Thu, Jun 25, 2026 at 7:23 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> 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

This list matches cq8725s and what I put in the commit. Is there
anything I need to change for this patch to move forward?

Aaron