msm: thermal: Notify LMH DCVSh driver after freq mitigation request

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>

diff --git a/drivers/thermal/msm_thermal.c b/drivers/thermal/msm_thermal.c
index 002cafb..7158fb1 100644 (file)
--- a/drivers/thermal/msm_thermal.c
+++ b/drivers/thermal/msm_thermal.c
@@ -1056,6 +1056,11 @@ static int msm_lmh_dcvs_update(int cpu)
                                        MSM_LIMITS_DOMAIN_MIN, min_freq);
        if (ret)
                return ret;
+       /*
+        * Notify LMH dcvs driver about the new software limit. This will
+        * trigger LMH DCVS driver polling for the mitigated frequency.
+        */
+       msm_lmh_dcvsh_sw_notify(cpu);
 
        return ret;
 }