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>

0 files changed, 0 insertions, 0 deletions