Re: [PATCH 3/3] arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths
From: Aaron Kling
Date: Tue Feb 17 2026 - 21:06:58 EST
On Thu, Feb 12, 2026 at 5:59 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 2/8/26 2:28 AM, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@xxxxxxxxx>
> >
> > Add the OPP tables for each CPU clusters (cpu0-1-2, cpu3-4-5-6 & cpu7)
> > to permit scaling the Last Level Cache Controller (LLCC), DDR and L3 cache
> > frequency by aggregating bandwidth requests of all CPU core with referenc
> > to the current OPP they are configured in by the LMH/EPSS hardware.
> >
> > The effect is a proper caches & DDR frequency scaling when CPU cores
> > changes frequency.
> >
> > The OPP tables were built using the downstream memlat ddr, llcc & l3
> > tables for each cluster types with the actual EPSS cpufreq LUT tables
> > from running a QCS8550 device.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > ---
>
> [...]
>
> > + cpu0_opp_table: opp-table-cpu0 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp-307200000 {
> > + opp-hz = /bits/ 64 <307200000>;
> > + opp-peak-kBps = <(300000 * 16) (547000 * 4) (307200 * 32)>;
>
> I think that entries below the first in that memlat table should use the lowest
> frequency (i.e. if (freq > tbl_entry.min_freq) { vote_for(tbl_entry.bw) }), etc.
Let me make sure I understand what you're saying. Given the following
example from the downstream dt:
silver {
qcom,cpufreq-memfreq-tbl =
< 1113600 547000 >,
< 1555200 768000 >,
< 2016000 1555000 >;
};
you're saying that everything up to but not including 1555200 should
using 547000? So in effect, round down instead of round up like I did?
> You can retrieve the list of supported frequencies through debugfs if you apply
> patch1 from my my in-flight patchset:
>
> https://lore.kernel.org/linux-arm-msm/20260108-topic-smem_dramc-v3-0-6b64df58a017@xxxxxxxxxxxxxxxx/
>
> via /sys/kernel/debug/qcom_smem/dram_frequencies
>
> Konrad
Aaron