On 3 February 2016 at 18:18, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [160202 13:46]: >>> On Tue, 2 Feb 2016, Tony Lindgren wrote: >>> >>> > > Also, what is autosuspend_delay set to for your device? And is >>> > > runtime_auto set? >>> > >>> > It's 100 at that point, see the commented snippet below from >>> > omap_hsmmc_probe(): >>> > >>> > pm_runtime_enable(host->dev); >>> > pm_runtime_get_sync(host->dev); >>> > pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY); >>> > /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */ >>> > pm_runtime_use_autosuspend(host->dev); >>> > ... >>> > /* gets -EPROBE_DEFER */ >>> > err_irq: >>> > ... >>> > pm_runtime_put_sync(host->dev); >>> >>> You could try changing this to pm_runtime_put_sync_suspend(). But >>> putting pm_runtime_dont_use_autosuspend() before the put_sync seems >>> like a perfectly reasonable thing to do, especially if you feel you >>> should reverse all the changes you made at the start. > > FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync(). > > After all, the driver doesn't want to use autosuspend going forward, > so stating that explicitly looks like the right thing to do. Just wanted to add yet some new findings while I was looking into this regression. So, the reason why pm_runtime_put_sync() doesn't idle the device in these cases, is because autosuspend is respected and for some reason the autosuspend timer hasn't expired. I was wondering *why* the timer isn't considered as expired, because the driver don't call pm_runtime_mark_last_busy() in the failing probe case... Then I realized the following commit was merged a few releases ago, which makes the runtime PM core to invoke pm_runtime_mark_last_busy() for us. commit 56f487c78015936097474fd89b2ccb229d500d0f Author: Tony Lindgren <tony@xxxxxxxxxxx> Date: Wed May 13 16:36:32 2015 -0700 PM / Runtime: Update last_busy in rpm_resume So, this commit actually causes the devices to stay active after a failed probe attempt. I think it's a good idea to revert this change, but what to you think? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
