If all cores for a cluster are offline or not brought up during
lmh dcvsh probe, it fails to register cooling device and it leads
to probe failure. If later these cores come online, lmh dcvsh doesn't
re-probe it and eventually that cluster lmh dcvsh is broken.
Register for cpu online notification and register cpu cooling device
in cpu online notification callback context. It makes sure that
both lmh dcvsh probing and cooling device register are proper.
Change-Id: Id5345a578aab920d12bd9d9e2ccf1d5059582de9
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
The frequency value that is calculated in Hz can be of a large value to
cause unsigned integer overflow. DCVSh though fetches the final
frequency value in HZ in a unsigned long variable, the intermediate
variable used in the estimation is unsigned integer. This will result in
a wrong frequency value being reported to userspace and clients.
Fix the overflow by using a unsigned long datatype for the frequency
computation.
Change-Id: I4bba53b9f5bd243c4aaaf67a831ce77ef231b38f
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The frequency requested by LMH DCVSh hardware may not match an actual
frequency in the CPU clock plan. LMH DCVSh driver uses OPP framework to
match the hardware frequency request to a nearest valid CPU frequency. OPP
interface expects the frequency input in Hz and DCVSh driver is passing the
frequency value in kHz, which will result in error. So the hardware
mitigation frequency reported by the driver may not reflect the actual
frequency that the CPU is mitigated to.
Provide the hardware frequency input in Hz for OPP interface in LMH DCVSh
driver. Hardware mitigation frequency can be lower than the lowest
possible CPU frequency. In that case freq floor call will fail. So call
dev_pm_opp_find_freq_ceil to match to the lowest CPU frequency.
Change-Id: I6e9f7f5129320c37d41e20ca9735129f25440134
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
LMH DCVS driver doesn't change the low threshold from HLOS. When there is
new request to lower the high threshold, the low threshold will be
modified if the new high threshold is lower than the existing low
threshold. But the low threshold is not increased when the high
threshold is moved back again.
Update the LMH DCVSh driver to always update the low threshold value
when there is a new high threshold request. The new low threshold will
be 0.5C less than the high threshold.
Change-Id: I356e47de585ae81bd27859f790f673b31ae5ba72
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
HLOS can place a mitigation frequency via the LMH DCVSh hardware using
the software cap register and this request doesn't trigger a debug
interrupt. Thus, this frequency mitigation change will not result in
scheduler being notified by LMH DCVSh driver.
Introduce a new API in LMH DCVSh driver, that can be used by other
drivers to trigger the scheduler notification. This API and the
interrupt handler follows the same code path to poll and notify the
scheduler.
Change-Id: Iefcdb57ff598ecb1bafc535958684f75b1f6e645
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The hardware frequency that LMH DCVSh hardware has requested may not
match an actual frequency of CPU. The OSM hardware will aggregate and
match this request to a nearest frequency mentioned in the clock plan.
The current lmh dcvs driver exposes this request without matching to
a frequency value in the OPP table.
In order to reflect the final mitigated frequency, match the mitigation
frequency request from LMH DCVSh to a nearest CPU frequency floor
in OPP table.
Change-Id: Iffc380898eac33f6c30c3808eb38d7bb499f5769
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The LMH DCVS hardware along with different monitoring algorithms, also
provides support for HLOS to vote for a CPU mitigation request. The
hardware will aggregate this request and will place the aggregated
mitigation request to OSM. The generic CPU cooling device doesn't take
advantage of this platform CPU mitigation feature.
Register the LMH DCVSh device as a platform cpu cooling device. When
registered, thermal CPU cooling device will place the mitigation request
with the LMH DCVSh hardware bypassing the cpufreq software. This will
allow faster mitigation action.
Also, thermal core framework exposes standard sysfs interfaces for
querying the cooling device state. Using this sysfs interface, users
can query the instantaneous CPU frequency mitigation request from
LMH DCVSh hardware.
Change-Id: I23762895d04dd6f1da8bb496f2a4cf22c1b34216
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: I2bc1eb26bcc7ed4aaa381417045d08b6779679ee
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
LMH DCVSh will retain the mitigation till it clears the Low
threshold. With mitigation happening at 95C, configuring the
low threshold as 65C will hold the mitigation till it clears 65C,
which will impact the performance.
Instead of configuring the low threshold, configure the ARM threshold
from HLOS and low threshold will be configured 2C less than the
high threshold in the trust zone.
CRs-Fixed: 1024370
Change-Id: Ifb303d7266c98eb94c5eb6f806b7c5e1d95236d3
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
LMH DCVSh driver receives interrupt from hardware whenever there is a
new mitigation frequency decision is made in hardware.
Add ftrace event to print the hardware mitigation frequency value from
driver.
Change-Id: Ib357ee3c3a461613bfd1268ec8f98973c2982c10
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
LMH DCVSh hardware can send interrupts whenever the hardware mitigation
blocks make a new frequency mitigation vote. scheduler is not aware of
any of the hardware mitigation.
Add support to listen for this interrupt, read the aggregated mitigation
frequency from all LMH DCVSh block and notify scheduler. After receiving
interrupt, poll the hardware periodically for the mitigation frequency
till the mitigation is cleared by hardware. Once the mitigation is
cleared, interrupt is re-enabled.
Change-Id: I38bc0c80710038f135289420d6b20c1ff0ab06eb
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The Limits Management Hardware (LMH-DCVS) is a hardware block for
monitoring thermal profiles and taking immediate action to control
temperature without software intervention. The h/w block can only be
configured under secure mode.
The LMH-DCVS block reads CPU temperatures of a cluster by sensing
information from the TSENS hardware and determines the course of action.
When enabled, the h/w triggers when the high threshold is hit for any
CPU in the cluster. The mitigative action is frequency and voltage
control that is provided to the OSM hardware.
The driver registers a virtual thermal zone device for each hardware
instance. The thermal zone device is used to set the thresholds for the
hardware to work on. Once the thresholds are setup and the trip type is
enabled, the hardware functions autonomously. Mitigative action is
completely controlled in the h/w.
Writing to the actual hardware is done through the SCM call.
Change-Id: I70d4bc387717491256fec1ef6bd8cd6a28ea641b
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
