ARM: OMAP2+: fix lack of timer interrupts on CPU1 after hotplug
authorRussell King <rmk+kernel@armlinux.org.uk>
Wed, 12 Dec 2018 11:49:47 +0000 (11:49 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 23 Mar 2019 19:09:44 +0000 (20:09 +0100)
commitf49f7007de5933e02228909a7ee95d71e5a44bc8
tree62785ed509ced4145549161a2afb71f5162c6f37
parent8f07d76481d575ec684ac583c2dc9be5c878149b
ARM: OMAP2+: fix lack of timer interrupts on CPU1 after hotplug

[ Upstream commit 50d6b3cf9403879911e06d69c7ef41e43f8f7b4b ]

If we have a kernel configured for periodic timer interrupts, and we
have cpuidle enabled, then we end up with CPU1 losing timer interupts
after a hotplug.

This can manifest itself in RCU stall warnings, or userspace becoming
unresponsive.

The problem is that the kernel initially wants to use the TWD timer
for interrupts, but the TWD loses context when we enter the C3 cpuidle
state.  Nothing reprograms the TWD after idle.

We have solved this in the past by switching to broadcast timer ticks,
and cpuidle44xx switches to that mode at boot time.  However, there is
nothing to switch from periodic mode local timers after a hotplug
operation.

We call tick_broadcast_enter() in omap_enter_idle_coupled(), which one
would expect would take care of the issue, but internally this only
deals with one-shot local timers - tick_broadcast_enable() on the other
hand only deals with periodic local timers.  So, we need to call both.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[tony@atomide.com: just standardized the subject line]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/arm/mach-omap2/cpuidle44xx.c