soc: qcom: Use a deferrable timer base for the msm watchdog

It is possible that normal CFS latencies in the presence of
very heavy task load causes timer migration to be delayed
in hotplug paths. This may in turn prevent the watchdog kthread
from waking up, resulting in a bark.

Technically the watchdog is supposed to be a last-resort
failure recovery; even in this stressful hotplug scenario
the device is *usable*, just incredibly slow. It is arguable
that the watchdog should not have fired in this case, and
the petting mechanism should handle this scenario.

Move the timer to a deferrable timer base. We are really not
using the "deferrable" aspect of the timer, but the fact that
we (msm) also changed deferrable timers to run on any CPU.
This underlying change will allow the watchdog timer to be
handled on any CPU.

This completely depends on the fact that we don't have to
pet the watchdog when *all* CPUs go idle, which would
make sense from a power perspective anyway.

Change-Id: Ie389e28ff890a805854f921e4cd491a296a32925
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>

1 files changed, 1 insertions, 1 deletions

diff --git a/drivers/soc/qcom/watchdog_v2.c b/drivers/soc/qcom/watchdog_v2.c
index 8f58eaa537b1..470ecfdd9f5e 100644
--- a/drivers/soc/qcom/watchdog_v2.c
+++ b/drivers/soc/qcom/watchdog_v2.c
@@ -701,7 +701,7 @@ static void init_watchdog_data(struct msm_watchdog_data *wdog_dd)
 	wdog_dd->user_pet_complete = true;
 	wdog_dd->user_pet_enabled = false;
 	wake_up_process(wdog_dd->watchdog_task);
-	init_timer(&wdog_dd->pet_timer);
+	init_timer_deferrable(&wdog_dd->pet_timer);
 	wdog_dd->pet_timer.data = (unsigned long)wdog_dd;
 	wdog_dd->pet_timer.function = pet_task_wakeup;
 	wdog_dd->pet_timer.expires = jiffies + delay_time;