Re: [Patch v3 0/6] Introduce LMh driver for Qualcomm SoCs

Thara Gopinath
2021-07-27T15:29:43Z

On 7/21/21 11:14 PM, Steev Klimaszewski wrote:
> Hi Thara!
>
> On 7/8/21 7:06 AM, Thara Gopinath wrote:
>> 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.

--
Warm Regards
Thara (She/Her/Hers)