Skip to content
  1. Jan 22, 2021
  3. Jan 21, 2021
  5. Jan 19, 2021
  7. Jan 16, 2021
  9. Jan 15, 2021
  11. Jan 12, 2021
    • Danny Lin's avatar
      arm64: dts: qcom: sm8150: Add support for deep CPU cluster idle · b2e3f897
      Danny Lin authored 
      

This commit adds support for deep idling of the entire unified DynamIQ
CPU cluster on sm8150. In this idle state, the LLCC (Last-Level Cache
Controller) is powered off and the AOP (Always-On Processor) enters a
low-power sleep state.

I'm not sure what the per-CPU 0x400000f4 idle state previously
contributed by Qualcomm as the "cluster sleep" state is, but the
downstream kernel has no such state. The real deep cluster idle state
is 0x41000c244, composed of:

    Cluster idle state: (0xc24) << 4 = 0xc240
    Is reset state: 1 << 30 = 0x40000000
    Affinity level: 1 << 24 = 0x1000000
    CPU idle state: 0x4 (power collapse)

This setup can be replicated with the PSCI power domain cpuidle driver,
which utilizes OSI to enter cluster idle when the last active CPU
enters idle.

The cluster idle state cannot be used as a plain cpuidle state because
it requires that all CPUs in the cluster are idling.

Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: default avatarDanny Lin <danny@kdrag0n.dev>
Link: https://lore.kernel.org/r/20210105201000.913183-1-danny@kdrag0n.dev


Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      b2e3f897
    • Douglas Anderson's avatar
      arm64: dts: qcom: Clean up sc7180-trogdor voltage rails · e5376f2e
      Douglas Anderson authored 
      

For a bunch of rails we really don't do anything with them in Linux.
These are things like modem voltage rails that the modem manages these
itself and core rails (like IO rails) that are setup to just
automagically do the right thing by the firmware.

Let's stop even listing those rails in our device tree.

The net result of this is that some of these rails might be able to go
down to a lower voltage or perhaps transition to LPM (low power mode)
sometimes.

Here's a list of what we're doing and why:

* L1A - only goes to SoC and doesn't seem associated with any
  particular peripheral. Kernel isn't doing anything with
  this. Removing from dts. NET IMPACT: rail might drop from 1.2V to
  1.178V and switch to LPM in some cases depending on firmware.
* L2A - only goes to SoC and doesn't seem associated with any
  particular peripheral. Kernel isn't doing anything with
  this. Removing from dts. NET IMPACT: rail might switch to LPM in
  some cases depending on firmware.
* L3A - only goes to SoC and doesn't seem associated with any
  particular peripheral. Kernel isn't doing anything with
  this. Removing from dts. NET IMPACT: rail might switch to LPM in
  some cases depending on firmware.
* L5A - seems to be totally unused as far as I can tell and doesn't
  even come off QSIP. Removing from dts.
* L6A - only goes to SoC and doesn't seem associated with any
  particular peripheral (I think?). Kernel isn't doing anything with
  this. Removing from dts. NET IMPACT: rail might switch to LPM in
  some cases depending on firmware.
* L16A - Looks like this is only used for internal RF stuff. Removing
  from dts. NET IMPACT: rail might switch to LPM in some cases
  depending on firmware.
* L1C - Just goes to WiFi / Bluetooth. Trust how IDP has this set and
  put this back at 1.616V min.
* L4C - This goes out to the eSIM among other places. This looks like
  it's intended to be for SIM card and modem manages. NET IMPACT:
  rail might switch to LPM in some cases depending on firmware.
* L5C - This goes to the physical SIM.  This looks like it's intended
  to be for SIM card and modem manages. NET IMPACT: rail might drop
  from 1.8V to 1.648V and switch to LPM in some cases depending on
  firmware.

NOTE: in general for anything which is supposed to be managed by Linux
I still left it all forced to HPM since I'm not 100% sure that all the
needed calls to regulator_set_load() are in place and HPM is safer.
Switching more things to LPM can happen in a future patch.

ALSO NOTE: Power measurements showed no measurable difference after
applying this patch, so perhaps it should be viewed more as a cleanup
than any power savings.

Reviewed-by: default avatarAlexandru M Stan <amstan@google.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201207143255.1.Ib92ec35163682dec4b2fbb4bde0785cb6e6dde27@changeid


Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      e5376f2e
  13. Jan 08, 2021
  15. Jan 06, 2021
    • Danny Lin's avatar
      arm64: dts: qcom: sm8150: Add CPU capacities and energy model · 5b2dae72
      Danny Lin authored 
      Power and performance measurements were made using my freqbench [1]
benchmark coordinator, which isolates, offlines, and disables the timer
tick on test CPUs to maximize accuracy. It uses EEMBC CoreMark [2] as
the workload and measures power usage using the PM8150B PMIC's fuel
gauge.

The energy model dynamic-power-coefficient values were calculated with
    DPC = µW / MHz / V^2
for each OPP, and averaged across all OPPs within each cluster for the
final coefficient. Voltages were obtained from the qcom-cpufreq-hw
driver that reads voltages from the OSM LUT programmed into the SoC.

Normalized DMIPS/MHz capacity scale values for each CPU were calculated
from CoreMarks/MHz (CoreMark iterations per second per MHz), which
serves the same purpose. For each CPU, the final capacity-dmips-mhz
value is the C/MHz value of its maximum frequency normalized to
SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system.

An Asus ZenFone 6 device running a downstream Qualcomm 4.14 kernel
(LA.UM.8.1.r1-15600-sm8150.0) was used for benchmarks to ensure proper
frequency scaling and other low-level controls.

Raw benchmark results can be found in the freqbench repository [3].
Below is a human-readable summary:

Frequency domains: cpu1 cpu4 cpu7
Offline CPUs: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7
Baseline power usage: 1400 mW

===== CPU 1 =====
Frequencies: 300 403 499 576 672 768 844 940 1036 1113 1209 1305 1382 1478 1555 1632 1708 1785

 300:  1114     3.7 C/MHz     52 mW   11.8 J   21.3 I/mJ   224.4 s
 403:  1497     3.7 C/MHz     57 mW    9.5 J   26.2 I/mJ   167.0 s
 499:  1854     3.7 C/MHz     73 mW    9.8 J   25.5 I/mJ   134.9 s
 576:  2139     3.7 C/MHz     83 mW    9.7 J   25.8 I/mJ   116.9 s
 672:  2495     3.7 C/MHz     65 mW    6.5 J   38.6 I/mJ   100.2 s
 768:  2852     3.7 C/MHz     72 mW    6.3 J   39.4 I/mJ    87.7 s
 844:  3137     3.7 C/MHz     77 mW    6.2 J   40.5 I/mJ    79.7 s
 940:  3493     3.7 C/MHz     84 mW    6.0 J   41.8 I/mJ    71.6 s
1036:  3850     3.7 C/MHz     91 mW    5.9 J   42.5 I/mJ    64.9 s
1113:  4135     3.7 C/MHz     96 mW    5.8 J   43.2 I/mJ    60.5 s
1209:  4491     3.7 C/MHz    102 mW    5.7 J   44.2 I/mJ    55.7 s
1305:  4848     3.7 C/MHz    110 mW    5.7 J   44.0 I/mJ    51.6 s
1382:  5133     3.7 C/MHz    114 mW    5.5 J   45.2 I/mJ    48.7 s
1478:  5490     3.7 C/MHz    120 mW    5.5 J   45.7 I/mJ    45.5 s
1555:  5775     3.7 C/MHz    126 mW    5.5 J   45.8 I/mJ    43.3 s
1632:  6060     3.7 C/MHz    131 mW    5.4 J   46.1 I/mJ    41.3 s
1708:  6345     3.7 C/MHz    137 mW    5.4 J   46.3 I/mJ    39.4 s
1785:  6630     3.7 C/MHz    146 mW    5.5 J   45.5 I/mJ    37.7 s

===== CPU 4 =====
Frequencies: 710 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419

 710:  2765     3.9 C/MHz    126 mW   11.4 J   22.0 I/mJ    90.4 s
 825:  6432     7.8 C/MHz    206 mW    8.0 J   31.2 I/mJ    38.9 s
 940:  7331     7.8 C/MHz    227 mW    7.7 J   32.3 I/mJ    34.1 s
1056:  8227     7.8 C/MHz    249 mW    7.6 J   33.0 I/mJ    30.4 s
1171:  9127     7.8 C/MHz    261 mW    7.2 J   34.9 I/mJ    27.4 s
1286: 10020     7.8 C/MHz    289 mW    7.2 J   34.6 I/mJ    25.0 s
1401: 10918     7.8 C/MHz    311 mW    7.1 J   35.1 I/mJ    22.9 s
1497: 11663     7.8 C/MHz    336 mW    7.2 J   34.7 I/mJ    21.4 s
1612: 12546     7.8 C/MHz    375 mW    7.5 J   33.5 I/mJ    19.9 s
1708: 13320     7.8 C/MHz    398 mW    7.5 J   33.5 I/mJ    18.8 s
1804: 14069     7.8 C/MHz    456 mW    8.1 J   30.9 I/mJ    17.8 s
1920: 14909     7.8 C/MHz    507 mW    8.5 J   29.4 I/mJ    16.8 s
2016: 15706     7.8 C/MHz    558 mW    8.9 J   28.1 I/mJ    15.9 s
2131: 16612     7.8 C/MHz    632 mW    9.5 J   26.3 I/mJ    15.1 s
2227: 17349     7.8 C/MHz    698 mW   10.1 J   24.8 I/mJ    14.4 s
2323: 18088     7.8 C/MHz    717 mW    9.9 J   25.2 I/mJ    13.8 s
2419: 18835     7.8 C/MHz    845 mW   11.2 J   22.3 I/mJ    13.3 s

===== CPU 7 =====
Frequencies: 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419 2534 2649 2745 2841

 825:  3215     3.9 C/MHz    158 mW   12.3 J   20.3 I/mJ    77.8 s
 940:  7330     7.8 C/MHz    269 mW    9.2 J   27.3 I/mJ    34.1 s
1056:  8227     7.8 C/MHz    291 mW    8.8 J   28.2 I/mJ    30.4 s
1171:  9125     7.8 C/MHz    316 mW    8.7 J   28.9 I/mJ    27.4 s
1286: 10024     7.8 C/MHz    338 mW    8.4 J   29.6 I/mJ    25.0 s
1401: 10922     7.8 C/MHz    365 mW    8.4 J   29.9 I/mJ    22.9 s
1497: 11674     7.8 C/MHz    383 mW    8.2 J   30.4 I/mJ    21.4 s
1612: 12564     7.8 C/MHz    406 mW    8.1 J   30.9 I/mJ    19.9 s
1708: 13317     7.8 C/MHz    427 mW    8.0 J   31.2 I/mJ    18.8 s
1804: 14062     7.8 C/MHz    446 mW    7.9 J   31.5 I/mJ    17.8 s
1920: 14966     7.8 C/MHz    498 mW    8.3 J   30.1 I/mJ    16.7 s
2016: 15711     7.8 C/MHz    513 mW    8.2 J   30.6 I/mJ    15.9 s
2131: 16599     7.8 C/MHz    599 mW    9.0 J   27.7 I/mJ    15.1 s
2227: 17353     7.8 C/MHz    622 mW    9.0 J   27.9 I/mJ    14.4 s
2323: 18095     7.8 C/MHz    704 mW    9.7 J   25.7 I/mJ    13.8 s
2419: 18849     7.8 C/MHz    738 mW    9.8 J   25.5 I/mJ    13.3 s
2534: 19761     7.8 C/MHz    824 mW   10.4 J   23.9 I/mJ    12.7 s
2649: 20658     7.8 C/MHz    882 mW   10.7 J   23.4 I/mJ    12.1 s
2745: 21400     7.8 C/MHz   1003 mW   11.7 J   21.3 I/mJ    11.7 s
2841: 22147     7.8 C/MHz   1092 mW   12.3 J   20.3 I/mJ    11.3 s

[1] https://github.com/kdrag0n/freqbench
[2] https://www.eembc.org/coremark/
[3] https://github.com/kdrag0n/freqbench/tree/master/results/sm8150/main



Signed-off-by: default avatarDanny Lin <danny@kdrag0n.dev>
Link: https://lore.kernel.org/r/20201221002907.2870059-4-danny@kdrag0n.dev


Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      5b2dae72
    • Danny Lin's avatar
      arm64: dts: qcom: sm8150: Add PSCI idle states · 81188f58
      Danny Lin authored 
      

Like other Qualcomm SoCs, sm8150 exposes CPU and cluster idle states
through PSCI. Define the idle states to save power when the CPU is not
in active use.

These idle states, latency, and residency values match the downstream
4.14 kernel from Qualcomm as of LA.UM.8.1.r1-15600-sm8150.0.

It's worth noting that the CPU has an additional C3 power collapse idle
state between WFI and rail power collapse (with PSCI mode 0x40000003),
but it is not officially used in downstream kernels due to "thermal
throttling issues."

Signed-off-by: default avatarDanny Lin <danny@kdrag0n.dev>
Link: https://lore.kernel.org/r/20201221002907.2870059-3-danny@kdrag0n.dev


Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      81188f58
    • Danny Lin's avatar
      arm64: dts: qcom: sm8150: Define CPU topology · 066d21bc
      Danny Lin authored 
      

sm8150 has a big.LITTLE CPU setup with DynamIQ, so all cores are within
the same CPU cluster and LLC (Last-Level Cache) domain. Define this
topology to help the scheduler make decisions.

Signed-off-by: default avatarDanny Lin <danny@kdrag0n.dev>
Link: https://lore.kernel.org/r/20201221002907.2870059-2-danny@kdrag0n.dev


Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      066d21bc
  17. Dec 29, 2020