summaryrefslogtreecommitdiff
path: root/chip/ish/power_mgt.c
diff options
context:
space:
mode:
authorHu, Hebo <hebo.hu@intel.com>2019-06-04 15:46:33 +0800
committerCommit Bot <commit-bot@chromium.org>2019-06-21 16:30:59 +0000
commit37e37749de6a969275bd9453204a01b494bfd854 (patch)
tree153bd4398c09d5c01d003b2f471717463b46a6fa /chip/ish/power_mgt.c
parent8fd4f4548eba5f2ad1d22ebd1b345f7cbce68579 (diff)
downloadchrome-ec-37e37749de6a969275bd9453204a01b494bfd854.tar.gz
ish: fixed wrongly entered D0ix states in some times
In __idle() task, when calculate the 'next_delay' value (the sleep time), in most time, 'next_delay' should be always positive, but ISH HPET timer HW has some latency for interrupt, so it's possible in some times when its very close to the expire time of the event timer, the current time could advance the 'last_deadline' which should be updated in event timer ISR, in this case, 'next_delay' could be negative. We calibrated the 'last_deadline' in timer driver for this interrupt latency impact. So, the negative case for 'next_delay' should be not happen. If still happens, its doesn't matter, we can just ignore it , and if not want to see this case, can adjust the 'HPET_INT_LATENCY_TICKS' for new calibration till its not happen anymore. BUG=b:133459192 BRANCH=none TEST=tested on arcada platform, with 10ms timer loop task, D0i2/D0i3 should not entered. Change-Id: Ie84fb630900dd7d59a41c98c08da4a71a831c030 Signed-off-by: Hu, Hebo <hebo.hu@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1643247 Tested-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Denis Brockus <dbrockus@chromium.org> Commit-Queue: Jack Rosenthal <jrosenth@chromium.org>
Diffstat (limited to 'chip/ish/power_mgt.c')
-rw-r--r--chip/ish/power_mgt.c11
1 files changed, 10 insertions, 1 deletions
diff --git a/chip/ish/power_mgt.c b/chip/ish/power_mgt.c
index dea5b4cf1c..cd5d17034e 100644
--- a/chip/ish/power_mgt.c
+++ b/chip/ish/power_mgt.c
@@ -585,7 +585,16 @@ void __idle(void)
t0 = get_time();
next_delay = __hw_clock_event_get() - t0.le.lo;
- pm_process(t0, next_delay);
+ /*
+ * Most of the time, 'next_delay' will be positive. But, due to
+ * interrupt latency, it's possible that get_time() returns
+ * the value bigger than the one from __hw_clock_event_get()
+ * which is supposed to be updated by ISR before control reaches
+ * to the get_time().
+ *
+ * Here, we handle the delayed update by changing negative to 0.
+ */
+ pm_process(t0, MAX(0, next_delay));
}
}