Skip to content

L
linux
Switch branch/tag
  1. 02 Feb, 2021 2 commits
  3. 26 Jan, 2021 4 commits
  5. 25 Jan, 2021 12 commits
  7. 22 Jan, 2021 1 commit
  9. 21 Jan, 2021 5 commits
  11. 19 Jan, 2021 1 commit
  13. 16 Jan, 2021 1 commit
  15. 15 Jan, 2021 10 commits
  17. 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
  19. 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
  21. 07 Jan, 2021 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7