summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-imx/gpc.c
diff options
context:
space:
mode:
authorShawn Guo <shawn.guo@linaro.org>2012-12-06 15:54:41 +0100
committerShawn Guo <shawn.guo@linaro.org>2013-01-30 14:08:08 +0100
commiteea8e326ff476e418b99b6daa97f9bd85ac6c523 (patch)
treea7ee83da9e18f2c8e64b91cac8bf2864c2670327 /arch/arm/mach-imx/gpc.c
parentMerge tag 'imx-cleanup-3.9' into imx6q-cpuidle (diff)
downloadlinux-eea8e326ff476e418b99b6daa97f9bd85ac6c523.tar.xz
linux-eea8e326ff476e418b99b6daa97f9bd85ac6c523.zip
ARM: imx: return zero in case next event gets a large increment
The return of v2_set_next_event() will lead to an infinite loop in tick_handle_oneshot_broadcast() - "goto again;" with imx6q WAIT mode (to be enabled). This happens because when global event did not expire any CPU local events, the broadcast device will be rearmed to a CPU local next_event, which could be far away from now and result in a max_delta_tick programming in set_next_event(). Fix the problem by detecting those next events with increments larger than 0x7fffffff, and simply return zero in that case. It leaves mx1_2_set_next_event() unchanged since only v2_set_next_event() will be running with imx6q WAIT mode support. Thanks Russell King for helping understand the problem. Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Diffstat (limited to 'arch/arm/mach-imx/gpc.c')
0 files changed, 0 insertions, 0 deletions