On 04/14/2016 03:53 PM, Jisheng Zhang wrote:
When pm_runtime_enable() was being called, the device's usage counter was 0, causing the PM layer to runtime-suspend the device. We then went on to call i2c_dw_probe() on a suspended device, which could hung.Fix this by incrementing the usage counter before pm_runtime_enable(). Signed-off-by: Jisheng Zhang <jszh...@marvell.com> --- drivers/i2c/busses/i2c-designware-platdrv.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index d656657..00f9e99 100644 --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -246,6 +246,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev) if (dev->pm_runtime_disabled) { pm_runtime_forbid(&pdev->dev); } else { + pm_runtime_get_noresume(&pdev->dev); pm_runtime_set_autosuspend_delay(&pdev->dev, 1000); pm_runtime_use_autosuspend(&pdev->dev); pm_runtime_set_active(&pdev->dev);
pm_runtime_enable() here after pm_runtime_set_active() shouldn't suspend as far as I understand which made me thinking if there is some other issue that cause the symptoms what you are seeing? Like race with runtime PM or similar.
-- Jarkko
