KTM prolong KTM hotplug mitigation, cpu frequency mitigation etc. till
thermal-engine takes over. It is helping thermal runaway issues during
the boot time from KTM kernel late init level to thermal-engine
starts. Since BCL is also using KTM interface for mitigation, it
delays BCL mitigation till thermal-engine starts. Again target which
has LMH support enables Tj based mitigation very early in the boot.
So there is no risk of thermal runaway issues mentioned above.
Enable KTM interrupt mode mitigation back from kernel late init
itself. This reverts commit <07f3dcfc7f7c> ("msm: thermal: Prolong
KTM mitigation till thermal-engine takesover").
Change-Id: I7e4beaed2dd003c6ed36cc10e4bf003826fad827
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Currently VDD restriction feature monitors all tsens for low
temperature condition. There can be interrupt storm due to
temperature oscillation between trigger and clear thresholds
of all these sensors. It may lead to power issues due to frequent
tsens interrupt wake up.
Add support to monitor only one sensor for VDD restriction feature.
It helps to configure one optimal sensor for this feature if above
mentioned scenario is a concern. Add an optional devicetree property
"qcom,vdd-restriction-sensor-id" to specify sensor id to monitor.
If not defined, monitor all tsens for VDD restriction.
Change-Id: I9a36952cbcb40ebca4de5e8357529842b2f77187
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
KTM lmh dcvs frequency mitigation uses given online/first cpu max/min
mitigation request. There can be cases like emergency frequency
mitigation where mitigation request is for a particular cpu only and
online/first cpu may be one of the other cpus from the same cluster.
In this case lmh dcvs takes online/first cpu max request which can be
in no mitigation state. It leads to unmitigated state even though one
of the cpus is triggered.
If device supports cluster mitigation, use min/max request of that
cluster instead of min/max request of given online/first cpu.
It ensures lmh dcvs mitigation if one of the cpu mitigation is
triggered and other unmitigated cpu of same cluster is given as
online/first cpu.
Change-Id: Ibbb913eb67a7f84d4c3658d0edae495990ca9010
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Userspace thermal daemon initiate KTM hotplug monitor related
initialization. Thermal core control can be disabled/enabled from
userspace via KTM sysfs for cpu related initialization after boot.
There is a possible race condition between KTM hotplug initialization
from thermal daemon and KTM core control re-enablement from userpsace
shell. When these both events are triggered at the same time,
thermal core control enablement tries to set emergency hotplug
threshold prior to per cpu hotplug related initialization like sensor
id, trip and threshold value etc. This leads to wrong sensor
threshold settings and eventually thermal core sensor threshold list
will be broken.
To avoid this wrong threshold settings during thermal core control
enablement, check KTM hotplug related initialization is done prior
to threshold setting for each core.
Change-Id: I916527d187146d5e292dd57897aa70b21cf87fbc
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
KTM suspend/reboot frequency mitigation is not required for target
which has LMH DCVS hardware support. lmh_dcvs_available flag in the
KTM is initialized only post OSM driver is up. But during KTM probe,
it checks this flag to register suspend/reboot notifier. Since
it is not initialized, it always register with these notifier and
does frequency mitigation whenever it notifies KTM.
To avoid this, check if the LMH DCVS related devicetree node is
enabled during KTM probe before enabling suspend/reboot notifier
registration. To be safe use the same check in CPU frequency policy
callback for KTM max cpu frequency request as well.
Change-Id: I337477dd296e1e681498d702ab03c164d7554186
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
KTM ignores software secure watchdog bite if it is a secure device
since this call support is not there in secure device. But API
scm_is_secure_device() returns false if it is secure device,
true otherwise. But KTM return value check is wrong and leads to
no secure watchdog bite call from KTM for all targets.
Fix return value check properly in KTM to resolve this issue.
Change-Id: I1612fee3f57f6c2d27c4329abc2c563b7b1d8102
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Sensor info probe is parsing available sensors info for device tree
including each sensor scaling factor. Sensor scaling factor needs to
be initialized prior to other mitigation feature initialization
because mitgation features initialize threshold setting at probe
itself. Initialize sensor info feature prior to mitigation features
initialization.
Change-Id: Ieacd805a4d547d1b74ca8f0eeb5c93ea0e445e0c
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
KTM triggers a secure watchdog bite, when temperature reaches very high
threshold. In the secure device this call is not supported.
Avoid triggering the watchdog bite, on a secure device. This bite is
triggered in KTM for debug purpose to save the software state.
In the latest hardware, the tsens controller is capable of initiating a
hardware reset after saving the software state. So this feature is used
only to print the tsens ID which crossed the very high threshold.
Change-Id: Iacef4b64e16f9c2d9789d8faba474429dfcecd4e
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
KTM right now won't update the mitigation frequency cap to LMH DCVSh if
all the cores in a cluster are offline. It will notify the LMH DCVSh
when at least one core is online. Due to race condition, there is a
possibility that this update can be missed or cores will be running
unmitigated for a short duration after being online.
LMH DCVSh hardware can accept the frequency cap even when the cores are
offline and apply the cap later when the cores are brought back online.
So in KTM update the LMH DCVSh hardware, even if the cores are offline
to avoid any race condition.
Change-Id: Idc04c35a9c5de66cfd8edb4150106ed65f9f4bf1
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
KTM won't apply a frequency mitigation request for an offline cluster.
Instead when the CPU is brought back online, the cpufreq will ask for
new request and KTM will limit the frequency at that time. With the LMH
DCVSh doing the frequency mitigation, the frequency request is not
applied when the CPU comes back online.
For targets with LMH DCVSh frequency mitigation, apply the latest
frequency mitigation request when the CPU comes back online.
Change-Id: If280e4e19fc5dd717aae4f0992d2e2950c057c57
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Add support for CX junction temperature monitor and thermal client
vote to CXIP LM hardware in KTM. When all pre-defined clients on
CX rail including thermal client set their vote, CXIP LM hardware
throttles pre-defined client on the same rail. During boot up,
KTM will set a pre-defined bypass clients bits of CXIP LM hardware
and monitors pre-defined tsens for preset threshold. Once it triggers,
it will vote for CXIP LM and clears vote when preset clear threshold
is reached. KTM enables this feature only if devicetree entry
'qcom,cxip-lm-enable' is configured with a non zero value.
If value is zero, then it disable this hardware feature explicitly.
Change-Id: Ibd95a6657d6bbf62710de2a677cb1ed70c972523
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
When device enters suspend, the suspend framework disables CPU hotplug
functionality. During the suspend, any attempt from KTM to hotplug CPU
will return error and in this case, KTM wont clear the cpus_offlined
mask. In this case, the device framework assumes the core is still
online. Next time the device resumes from suspend the core
online attempt will be nacked by KTM. Thus the core will be offlined and
subsequent attempts to bring the core online using device framework will
fail.
Update KTM error handling to remove the CPUs from the cpus_offlined
mask, when device offline APIs return error. Thus KTM wont block suspend
framework from bringing the core online. Also, update KTM not to
evaluate new request to offline or online a core when the device is in
suspend entry or exit. The re-evaluation will be triggered when the
device exits suspend.
Change-Id: I334fd782a2c5d604cafb94f44832d9c700891ba2
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
LMH DCVSh hardware doesn't generate a debug interrupt, when HLOS
CPU frequency cap is the only throttling value coming to the hardware
aggregator logic. The LMH DCVSh requires atleast one of the hardware
algorithm to throttle to generate a debug interrupt. So there will be
a case where, LMH DCVS driver won't notify scheduler about the
throttling frequency if HLOS is the only reason for throttling.
LMH DCVSh driver now exposes a new API, to trigger the frequency polling
loop. KTM is updated to use this API to trigger the LMH DCVSh polling,
whenever there is a new software frequency cap. This will ensure that
the LMH DCVSh will notify the scheduler even if software is the only
throttling reason.
Change-Id: I92b1bd9a5efc9810eea721b088dff1bd6eef3838
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The reliability algorithm has a dependency for OSM to be initialized
before it is enabled.
Enable reliability algorithm in the LMH DCVSh hardware for both the
clusters from KTM. KTM is enabled, only after OSM populates the OPP
table. So this solves the dependency.
Change-Id: I4a382915a6c3a6b9d445ec1f5d57fb499a011f1a
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Correct the input argument to pass in the valid end address for the dmac
flush range function.
Change-Id: Ib0e9690fc158a76dcebbd5ae45f67aaeca016a48
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
tsens_get_hw_id_mapping() API is used by thermal
client to obtain the logical ID or HW ID mapping
for the available temperature sensors (TSENS)
controller with sensor ID details. Clients
currently query the driver on a per sensor basis.
The API update allows the clients to get the sensor
ID information at once for the available number
of sensors.
Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org>
Change-Id: Ibae066276b099ffb78c72a890a689f83e4df56a9
Hotplug initialization will trigger a hotplug if temperature stays above
the trip threshold and will try to online if temperature is below the
clear threshold. Since KTM does boot mitigation till thermal-engine is
running, hotplug init can be called twice. First from post init script
and second when the hotplug task is initialized. There is a possiblity
the first init call can set the hotplug local mask and the second init
call wont clear or update the mask with correct value if the temperature
is between the hotplug trip and clear threshold.
Update the hotplug init API to perform the check only if the hotplug
task is initialized. Also the hotplug check will clear the hotplug local
mask if the temperature is not above the trip threshold.
Change-Id: Ica1325f8aa65c338ea0e5b201f566607c3ddf904
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Currently VDD MX restriction feature monitors all tsens for low
temperature condition. Some targets which has higher MX restriction
thresholds shows frequent interrupts from multiple sensors causing
power impact.
Add support to monitor only one sensor for VDD MX restriction feature.
Add an optional device tree property "qcom,mx-restriction-sensor_id"
to specify sensor id for monitor. If not defined, monitor all tsens
for VDD MX restriction.
Change-Id: Ib709b00c27f43c2603ac8a08b75f2fbd5800983b
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
If KTM get a trip threshold trigger notification and if the
temperature stays the same as the recent trip threshold, KTM will
re-activate the recently triggered threshold, resulting in back to
back interrupts. To avoid this add support in KTM to maintain the
recently triggered threshold state and then re-active the threshold
based on the last threshold trip.
This state is updated for mitigation features like VDD MX retention,
CX phase control, VDD restriction, OCR monitor and external clients
like CPR low temperature monitor etc.
CRs-Fixed: 969112 972634
Change-Id: I44c0a93e1507a9f0b8a65e5c2ce5a98962bb335b
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
KTM frequency mitigation thread initializes during late init call.
Prior to this, client can request frequency mitigation. But request
will not be processed, since frequency mitigation thread won't be
initialized. Notify frequency mitigation thread to aggregate clients
current request immediately after thread initialization.
Change-Id: Id2425041b14554d58f944794e1b5db273f5ded26
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
With LMH DCVSh hardware, the current check will use cpufreq to
limit both scaling min and max frequency. But cpufreq should be
used only for scaling min frequency.
Update the check to use cpufreq only to limit scaling min frequency.
Change-Id: I38de1699a7cdd5bc3fecef80dd34c4d22d2fd200
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
With LMH DCVSh hardware, thermal driver can directly vote in the
hardware to limit the scaling max frequency. Voting to the cpufreq
driver along side the hardware, will introduce software delay when
removing the mitigation.
So avoid voting the scaling max frequency to the cpufreq when LMH DCVSh
is available.
Change-Id: I8a5f913ae41263b06af99b0ee802b4fa68312f33
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
KTM has support for handling cluster with asynchronous cores within
a cluster. KTM can get the individual clock plans for the cores and
mitigate them separately. This feature is not supported in
hardware.
So remove the asynchronous cluster support from KTM.
CRs-Fixed: 1010111
Change-Id: I13348a16e2e1c11053cf5b99b921fd8ea65c7d89
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
For the targets with the LMH DCVSh mitigation, HLOS boot-up
mitigation is not required. So make the devicetree properties
related to boot-up mitigation as optional.
CRs-Fixed: 1010111
Change-Id: I7f254f579182effbc1f1a3d49c3c917d3c7af162
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
KTM stops the boot time mitigation during late init
and thermal engine takes over the mitigation only after
a delay.
Modify KTM to prolong the boot time mitigation till
thermal-engine sends a disable command. This ensures a
safe handover.
CRs-Fixed: 1007266
Change-Id: Icb876f16cac9471c523f3ef5b5fd3ede9d5d597c
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Reorganize KTM probe function by grouping and separating them
based on functionalities. The deferrable properties and sysfs
node creation are grouped into two separate function
calls.
CRs-Fixed: 1010111
Change-Id: If144319371a5c65f193ffac8fb9852a836125966
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Vdd restriction probe will apply mitigation, which will be cleared
later during the KTM boot mitigation. KTM now initializes the
data structures to do this mitigation only after vdd restriction probe.
So remove this pro-active mitigation in the probe function. KTM boot
mitigation will be started immediately after the KTM probe and can take
care of this mitigation.
CRs-Fixed: 1010111
Change-Id: Ica59aeb0c94581e3c37b5b7df16c187ced45c28a
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
On SoCs that have OSM hardware, use the hardware to setup the CPU
mitigation limits. Having the OSM control CPU frequencies offloads
mitigation from the CPU, resulting in faster thermal mitigation
response.
The LMH DCVS aggregation does not do a max of the min frequency limits.
Therefore to avoid cpufreq voting any lesser than what KTM decides based
on vdd min restrictions, we update cpufreq as well, only if the min freq
has changed.
Change-Id: I2912eaf418d5e7ea4d62a9a55702e02b744a785b
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Fix compilation issues. Replace deprecated APIs with
the new APIs for 4.4 kernel.
Change-Id: I0cd5adc5c9c6ff9979b6d3a626541e6755029d2f
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
During Vdd restriction trigger/clear request, KTM request it's vote
to regulator via regulator_set_voltage() API. KTM is interested only
in min value for this feature, always request INT_MAX as max value
instead of supported MAX corner of that regulator. It makes sure
that there is no impact if MAX corner for that regulator is changed
at any time.
Change-Id: Iebcb0383ea7b44d8584adb610ca7b56f0db2e755
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Currently Vdd scaling max frequency variable is not initialized,
which leads to wrong aggregation of thermal cpu scaling max frequency
request especially during KTM boot up mitigation. Initialize low
temperature scaling max frequency variable to UINT_MAX at
probe function.
Change-Id: I0220b9390cac33d40af0e4419d7451553ba6c5b5
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Modify the thermal driver to use the new device framework API
instead of the cpu_up/cpu_down call. The new framework API, will
keep the online/offline value reported in sysfs in sync with the
actual core status. Bypassing this framework by using cpu_up/cpu_down
will not update the value reported in the sysfs.
Also protect the device framework APIs with device hotplug lock to
provide mutual exclusion between multiple drivers using the same API.
Change-Id: I55e578ec6afdcdd7537ff7afc411bd03f277d59e
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
This snapshot is taken as of msm-3.18 commit e70ad0c (Promotion of
kernel.lnx.3.18-151201.)
Include necessary thermal_core changes to convert long to int inline with
upstream kernel changes.
Change-Id: I642b666518fe72385794b743989a0f5e5120ec03
Conflicts:
drivers/thermal/Makefile
