mmc: core: fix deadlock between runtime-suspend and devfreq
There's a deadlock between runtime-suspend and devfreq monitor.
runtime-suspend context:
[<ffffffc00008771c>] __switch_to+0x7c
[<ffffffc000e0212c>] __schedule+0x53c
[<ffffffc000e02404>] schedule+0x74
[<ffffffc000e02770>] schedule_preempt_disabled+0x14
[<ffffffc000e04c8c>] __mutex_lock_slowpath+0x1dc
[<ffffffc000e04e54>] mutex_lock+0x2c
[<ffffffc000acfc98>] devfreq_monitor_suspend+0x1c
[<ffffffc000ad160c>] devfreq_simple_ondemand_handler+0x4c
[<ffffffc000acf8b4>] devfreq_suspend_device+0x2c
[<ffffffc0008fa5a0>] mmc_suspend_clk_scaling+0xac
[<ffffffc000900398>] _mmc_suspend.isra.11+0x38
[<ffffffc000900798>] mmc_runtime_suspend+0x1cc
[<ffffffc0008fd4c4>] mmc_runtime_suspend+0x18
[<ffffffc000579c98>] __rpm_callback+0x40
[<ffffffc000579d0c>] rpm_callback+0x40
[<ffffffc00057a338>] rpm_suspend+0x25c
In the above stack, runtime-suspend is waiting on the devfreq mutex.
In the below stack, the mutex has been acquired and since the device
power state is DEV_SUSPENDING, devfreq is waiting for the device to
resume, thus causing a deadlock.
[<ffffffc000e02404>] schedule+0x74
[<ffffffc00057abdc>] rpm_resume+0x264
[<ffffffc00057ae80>] __pm_runtime_resume+0x70
[<ffffffc0008f880c>] mmc_get_card+0x1c
[<ffffffc0008f9d08>] mmc_devfreq_set_target+0x154
[<ffffffc000acf9d0>] update_devfreq+0xd0
[<ffffffc000acfb38>] devfreq_monitor+0x2c
Fix this by not waiting for device to resume in devfreq. The suspend would
ensure that this devfreq monitor thread is suspended before suspending the
device.
Change-Id: Ic0e89becbfded35c90c4061f0fe03d61125f66d5
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
1 file changed