1. 15 Jan, 2021 8 commits
  2. 12 Jan, 2021 1 commit
    • 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.devSigned-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      b2e3f897
  3. 11 Jan, 2021 1 commit
    • 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@changeidSigned-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      e5376f2e
  4. 07 Jan, 2021 2 commits
  5. 05 Jan, 2021 3 commits
    • 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/mainSigned-off-by: default avatarDanny Lin <danny@kdrag0n.dev>
      Link: https://lore.kernel.org/r/20201221002907.2870059-4-danny@kdrag0n.devSigned-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.devSigned-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.devSigned-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      066d21bc
  6. 28 Dec, 2020 19 commits
  7. 27 Dec, 2020 6 commits