linux-stable.git/drivers/cpufreq, branch v6.1.35

cpufreq: amd-pstate: Add ->fast_switch() callback

2023-06-05T07:26:21+00:00

commit 4badf2eb1e986bdbf34dd2f5d4c979553a86fe54 upstream.

Schedutil normally calls the adjust_perf callback for drivers with
adjust_perf callback available and fast_switch_possible flag set.
However, when frequency invariance is disabled and schedutil tries to
invoke fast_switch. So, there is a chance of kernel crash if this
function pointer is not set. To protect against this scenario add
fast_switch callback to amd_pstate driver.

Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
Signed-off-by: Gautham R. Shenoy 
Signed-off-by: Wyes Karny 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: Update policy->cur in amd_pstate_adjust_perf()

2023-06-05T07:26:21+00:00

commit 3bf8c6307bad5c0cc09cde982e146d847859b651 upstream.

Driver should update policy->cur after updating the frequency.
Currently amd_pstate doesn't update policy->cur when `adjust_perf`
is used. Which causes /proc/cpuinfo to show wrong cpu frequency.
Fix this by updating policy->cur with correct frequency value in
adjust_perf function callback.

- Before the fix: (setting min freq to 1.5 MHz)

[root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count
      1 cpu MHz         : 1777.016
      1 cpu MHz         : 1797.160
      1 cpu MHz         : 1797.270
    189 cpu MHz         : 400.000

- After the fix: (setting min freq to 1.5 MHz)

[root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count
      1 cpu MHz         : 1753.353
      1 cpu MHz         : 1756.838
      1 cpu MHz         : 1776.466
      1 cpu MHz         : 1776.873
      1 cpu MHz         : 1777.308
      1 cpu MHz         : 1779.900
    183 cpu MHz         : 1805.231
      1 cpu MHz         : 1956.815
      1 cpu MHz         : 2246.203
      1 cpu MHz         : 2259.984

Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
Signed-off-by: Wyes Karny 
[ rjw: Subject edits ]
Cc: 5.17+  # 5.17+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: use correct unit when verify cur freq

2023-05-11T14:03:16+00:00

[ Upstream commit 44295af5019f1997d038ad2611086a2d1e2af167 ]

cpufreq_verify_current_freq checks() if the frequency returned by
the hardware has a slight delta with the valid frequency value
last set and returns "policy->cur" if the delta is within "1 MHz".
In the comparison, "policy->cur" is in "kHz" but it's compared
against HZ_PER_MHZ. So, the comparison range becomes "1 GHz".

Fix this by comparing against KHZ_PER_MHZ instead of HZ_PER_MHZ.

Fixes: f55ae08c8987 ("cpufreq: Avoid unnecessary frequency updates due to mismatch")
Signed-off-by: Sanjay Chandrashekara 
[ sumit gupta: Commit message update ]
Signed-off-by: Sumit Gupta 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: qcom-cpufreq-hw: Revert adding cpufreq qos

2023-05-11T14:03:12+00:00

[ Upstream commit e2b47e585931a988c856fd4ba31e1296f749aee3 ]

The OSM/EPSS hardware controls the frequency of each CPU cluster based
on requests from the OS and various throttling events in the system.
While throttling is in effect the related dcvs interrupt will be kept
high. The purpose of the code handling this interrupt is to
continuously report the thermal pressure based on the throttled
frequency.

The reasoning for adding QoS control to this mechanism is not entirely
clear, but the introduction of commit 'c4c0efb06f17 ("cpufreq:
qcom-cpufreq-hw: Add cpufreq qos for LMh")' causes the
scaling_max_frequncy to be set to the throttled frequency. On the next
iteration of polling, the throttled frequency is above or equal to the
newly requested frequency, so the polling is stopped.

With cpufreq limiting the max frequency, the hardware no longer report a
throttling state and no further updates to thermal pressure or qos
state are made.

The result of this is that scaling_max_frequency can only go down, and
the system becomes slower and slower every time a thermal throttling
event is reported by the hardware.

Even if the logic could be improved, there is no reason for software to
limit the max freqency in response to the hardware limiting the max
frequency. At best software will follow the reported hardware state, but
typically it will cause slower backoff of the throttling.

This reverts commit c4c0efb06f17fa4a37ad99e7752b18a5405c76dc.

Fixes: c4c0efb06f17 ("cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh")
Reported-by: Krzysztof Kozlowski 
Signed-off-by: Bjorn Andersson 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623

2023-05-11T14:03:12+00:00

[ Upstream commit 0883426fd07e39355362e3f2eb9aee1a154dcaf6 ]

During the addition of SRAM voltage tracking for CCI scaling, this
driver got some voltage limits set for the vtrack algorithm: these
were moved to platform data first, then enforced in a later commit
6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
using these as max values for the regulator_set_voltage() calls.

In this case, the vsram/vproc constraints for MT7622 and MT7623
were supposed to be the same as MT2701 (and a number of other SoCs),
but that turned out to be a mistake because the aforementioned two
SoCs' maximum voltage for both VPROC and VPROC_SRAM is 1.36V.

Fix that by adding new platform data for MT7622/7623 declaring the
right {proc,sram}_max_volt parameter.

Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data")
Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
Signed-off-by: AngeloGioacchino Del Regno 
Signed-off-by: Jia-Wei Chang 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek: raise proc/sram max voltage for MT8516

2023-05-11T14:03:11+00:00

[ Upstream commit d3296bb4cafd4bad4a5cf2eeab9d19cc94f9e30e ]

Since the upper boundary of proc/sram voltage of MT8516 is 1300 mV,
which is greater than the value of MT2701 1150 mV, we fix it by adding
the corresponding platform data and specify proc/sram_max_volt to
support MT8516.

Signed-off-by: Jia-Wei Chang 
Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data")
Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
Reported-by: Nick Hainke 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_put

2023-05-11T14:03:11+00:00

[ Upstream commit d51e106240bc755cbe59634b70d567c192b045b2 ]

Any kind of failure in mtk_cpu_dvfs_info_init() will lead to calling
regulator_put() or clk_put() and the KP will occur since the regulator/clk
handlers are used after released in mtk_cpu_dvfs_info_release().

To prevent the usage after regulator_put()/clk_put(), the regulator/clk
handlers are addressed in a way of "Free the Last Thing Style".

Signed-off-by: Jia-Wei Chang 
Fixes: 4b9ceb757bbb ("cpufreq: mediatek: Enable clocks and regulators")
Suggested-by: AngeloGioacchino Del Regno 
Suggested-by: Dan Carpenter 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek: fix passing zero to 'PTR_ERR'

2023-05-11T14:03:11+00:00

[ Upstream commit d51c63230994f167126d9d8381011b4cb2b0ad22 ]

In order to prevent passing zero to 'PTR_ERR' in
mtk_cpu_dvfs_info_init(), we fix the return value of of_get_cci() using
error pointer by explicitly casting error number.

Signed-off-by: Jia-Wei Chang 
Fixes: 0daa47325bae ("cpufreq: mediatek: Link CCI device to CPU")
Reported-by: Dan Carpenter 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: davinci: Fix clk use after free

2023-03-10T08:33:01+00:00

[ Upstream commit 5d8f384a9b4fc50f6a18405f1c08e5a87a77b5b3 ]

The remove function first frees the clks and only then calls
cpufreq_unregister_driver(). If one of the cpufreq callbacks is called
just before cpufreq_unregister_driver() is run, the freed clks might be
used.

Fixes: 6601b8030de3 ("davinci: add generic CPUFreq driver for DaVinci")
Signed-off-by: Uwe Kleine-König 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: qcom-hw: Fix cpufreq_driver->get() for non-LMH systems

2023-02-14T18:11:44+00:00

[ Upstream commit 51be2fffd65d9f9cb427030ab0ee85d791b4437d ]

On a sc7180-based Chromebook, when I go to
/sys/devices/system/cpu/cpu0/cpufreq I can see:

  cpuinfo_cur_freq:2995200
  cpuinfo_max_freq:1804800
  scaling_available_frequencies:300000 576000 ... 1708800 1804800
  scaling_cur_freq:1804800
  scaling_max_freq:1804800

As you can see the `cpuinfo_cur_freq` is bogus. It turns out that this
bogus info started showing up as of commit c72cf0cb1d77 ("cpufreq:
qcom-hw: Fix the frequency returned by cpufreq_driver->get()"). That
commit seems to assume that everyone is on the LMH bandwagon, but
sc7180 isn't.

Let's go back to the old code in the case where LMH isn't used.

Fixes: c72cf0cb1d77 ("cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()")
Signed-off-by: Douglas Anderson 
Reviewed-by: Konrad Dybcio 
Reviewed-by: Manivannan Sadhasivam 
[ Viresh: Fixed the 'fixes' tag ]
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin