From e219034e0473f7cade281d7e59d9cc6418040884 Mon Sep 17 00:00:00 2001 From: Ram Chandrasekar Date: Wed, 23 Nov 2016 14:39:13 -0700 Subject: [PATCH] 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 --- drivers/thermal/msm_thermal.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/thermal/msm_thermal.c b/drivers/thermal/msm_thermal.c index 002cafb08f37..7158fb1239df 100644 --- 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; } -- 2.11.0