* Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [160204 08:05]: > On Thu, 4 Feb 2016, Ulf Hansson wrote: > > > 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. > > No doubt the autosuspend delay is longer than the time it takes for a > probe to fail. > > > 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? > > I disagree. The whole idea of autosuspend is to prevent the device's > power state from bouncing up and down too rapidly. This implies that > whenever the device gets resumed, we should wait at least the minimum > autosuspend delay before allowing the next autosuspend. Yeah let's not revert 56f487c78015. Without that we have devices falling right back to sleep. Regards, Tony -- 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
