2016-03-12 3:46 GMT+09:00 Alan Stern <st...@rowland.harvard.edu>: > On Fri, 11 Mar 2016, Krzysztof Kozlowski wrote: > >> Hi, >> >> >> Could be related (the same?) with [0]. >> >> I have a driver (hwrng/exynos-rng) which in probe does: >> pm_runtime_set_autosuspend_delay(&pdev->dev, EXYNOS_AUTOSUSPEND_DELAY); >> pm_runtime_use_autosuspend(&pdev->dev); >> pm_runtime_enable(&pdev->dev); >> >> and in remove: >> pm_runtime_disable(&pdev->dev) > > But not pm_runtime_dont_use_autosuspend()?
Ahh, that one is missing. Thanks! > > Why disable runtime PM if you want the runtime-PM methods to put the > device into a low-power state? I don't want to play with runtime PM anymore at this time. I am removing the device so I am cleaning what was done in probe. Without the pm_runtime_disable() the next probe of device will trigger error of unbalanced enable: https://lkml.org/lkml/2016/3/11/59 > >> Just before unbinding in __device_release_driver() the device is resumed >> but unfortunately not suspended later. I mean the >> __device_release_driver()->pm_runtime_put_sync() does not trigger >> runtime suspend. > > Because autosuspend is still in use at this point. > >> This leads to leaving the device in active state (e.g. clocks enabled). >> >> It does not happen after removal of autosuspend. Also runtime suspend >> happens after very fast unbind-bind. > > Overall it sounds like the system is behaving the way it is supposed > to. > > But maybe we should make pm_runtime_use_autosuspend() call > pm_runtime_mark_last_busy(), to avoid the unbind - bind - immediate > autosuspend behavior. The need of disabling autosuspend was not quite obvious to me and I did not find information about it in documentation. However now it makes sense... I'll send a patch updating the docs. Thank you for feedback! Best regards, Krzysztof