On 7/27/21 10:29 AM, Thara Gopinath wrote:

On 7/21/21 11:14 PM, Steev Klimaszewski wrote:

quoted

Hi Thara!

On 7/8/21 7:06 AM, Thara Gopinath wrote:

quoted

Limits Management Hardware(LMh) is a hardware infrastructure on some
Qualcomm SoCs that can enforce temperature and current limits as
programmed
by software for certain IPs like CPU. On many newer SoCs LMh is
configured
by firmware/TZ and no programming is needed from the kernel side.
But on
certain SoCs like sdm845 the firmware does not do a complete
programming of
the h/w block. On such SoCs kernel software has to explicitly set up
the
temperature limits and turn on various monitoring and enforcing
algorithms
on the hardware.

Introduce support for enabling and programming various limit
settings and
monitoring capabilities of Limits Management Hardware(LMh)
associated with
cpu clusters. Also introduce support in cpufreq hardware driver to
monitor
the interrupt associated with cpu frequency throttling so that this
information can be conveyed to the schdeuler via thermal pressure
interface.

With this patch series following cpu performance improvement(30-70%) is
observed on sdm845. The reasoning here is that without LMh being
programmed
properly from the kernel, the default settings were enabling thermal
mitigation for CPUs at too low a temperature (around 70-75 degree
C).  This
in turn meant that many a time CPUs were never actually allowed to
hit the
maximum possible/required frequencies.

UnixBench whets and dhry (./Run whets dhry)
System Benchmarks Index Score

                 Without LMh Support             With LMh Support
1 copy test     1353.7                          1773.2

8 copy tests    4473.6                          7402.3

Sysbench cpu
sysbench cpu --threads=8 --time=60 --cpu-max-prime=100000 run

                 Without LMh Support             With LMh Support
Events per
second                  355                             614

Avg Latency(ms)         21.84                           13.02

v2->v3:
    - Included patch adding dt binding documentation for LMh nodes.
    - Rebased to v5.13

Thara Gopinath (6):
   firmware: qcom_scm: Introduce SCM calls to access LMh
   thermal: qcom: Add support for LMh driver
   cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support
   arm64: boot: dts: qcom: sdm45: Add support for LMh node
   arm64: boot: dts: qcom: sdm845: Remove cpufreq cooling devices
for CPU
     thermal zones
   dt-bindings: thermal: Add dt binding for QCOM LMh

  .../devicetree/bindings/thermal/qcom-lmh.yaml | 100 ++++++++
  arch/arm64/boot/dts/qcom/sdm845.dtsi          | 162 ++----------
  drivers/cpufreq/qcom-cpufreq-hw.c             | 118 +++++++++
  drivers/firmware/qcom_scm.c                   |  58 +++++
  drivers/firmware/qcom_scm.h                   |   4 +
  drivers/thermal/qcom/Kconfig                  |  10 +
  drivers/thermal/qcom/Makefile                 |   1 +
  drivers/thermal/qcom/lmh.c                    | 239
++++++++++++++++++
  include/linux/qcom_scm.h                      |  14 +
  9 files changed, 570 insertions(+), 136 deletions(-)
  create mode 100644
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
  create mode 100644 drivers/thermal/qcom/lmh.c

I've been using these patches on a 5.13 kernel
(https://github.com/steev/linux/tree/linux-5.13.y - while trying to
track down a different issue, while playing a video on youtube, as well
as compressing a 9.2GB file with xz, I got the following

Hi Steev,

Thanks for testing this. I was unable to reproduce this. I have posted
v4 moving the interrupt handling in qcom-cpufreq-hw to threaded
interrupt handler and hopefully this should fix the issue. It will be
great if you can test and let me know.

Hi Thara,

I've been testing v4 for a little bit here, and so far I can't seem to
get it to reproduce anymore.  I will keep trying but fingers crossed
that that did the trick.

For setup, I'm using https://github.com/steev/linux/tree/linux-5.13.y
with the "distro_defconfig" configuration here on my c630s.  I'm also
running https://github.com/steev/scheduler as a systemd service.  So far
I've been able to sleep/suspend without issue while running "make
-j$(nproc) deb-pkg" in those kernel sources as well as `xz
--memlimit-compress=50 -T 4 imagefile.img" on a 9.2GB file at the same
time.  One system is running the Budgie desktop on top of Xorg, and the
other is running Gnome 3.38 on top of Wayland.

-- steev