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

[Aaron Kling]

On Thu, Jul 23, 2026 at 3:32 PM Aaron Kling <webgeek1234@xxxxxxxxx> wrote:
>
> 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?

This patch has been sitting for quite a while with no negative
feedback. Could it please get picked up?

Aaron