summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpio-vx855.c
diff options
context:
space:
mode:
authorSrivatsa Vaddagiri <vatsa@codeaurora.org>2013-12-20 18:56:07 -0800
committerDavid Keitel <dkeitel@codeaurora.org>2016-03-23 19:58:42 -0700
commitdf74672faf8421bf0f133d7fe7422a7cd2f757a1 (patch)
tree46bbbcd99e95a04527c64c02f8444e7a44c5ecd8 /drivers/gpio/gpio-vx855.c
parente80ff9a87c1a797ed6f8fe2ef2f43f3f858170ad (diff)
cpufreq: cpu-boost: Resolve deadlock when waking up sync thread
CPU boost driver receives notification from scheduler when threads migrate towards a cpu and in turn wakes up a sync thread associated with that cpu to handle any required frequency transitions. The wakeup call however can lead to a deadlock inside scheduler under some circumstance. The deadlock is seen when sync thread is the only thread running on a cpu and goes to sleep (say by calling wait_event() -> schedule()). Midway through this sleep (schedule()) call, while cpu is still running in context of sync thread, scheduler attempts a load balance (realizing that cpu is about to become idle) which can result in tasks being migrated towards the cpu going idle. This will cause migration notification to be issued and in turn a wakeup on sync thread. The wakeup call however gets stuck in below while() loop inside scheduler: try_to_wake_up(struct task_struct *p, ...) { /* * If the owning (remote) cpu is still in the middle of * schedule() with this task as prev, wait until its done * referencing the task. */ while (p->on_cpu) cpu_relax(); } A possible fix could be to teach try_to_wake_up() about this special case. Another fix, implemented in this patch and that helps minimize scheduler changes, is to have cpu boost driver not issue a wakeup under this special circumstance, which was found to occur very infrequently. Change-Id: I92bc68a22d51595a208673fe2a1eedfa97004f9e Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Diffstat (limited to 'drivers/gpio/gpio-vx855.c')
0 files changed, 0 insertions, 0 deletions