From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Thu, 4 Feb 2016 09:20:25 -0800 Message-ID: <20160204172025.GQ19432@atomide.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:60160 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754394AbcBDRU2 (ORCPT ); Thu, 4 Feb 2016 12:20:28 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Alan Stern Cc: Ulf Hansson , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" * Alan Stern [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 > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 4 Feb 2016 09:20:25 -0800 Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 In-Reply-To: References: Message-ID: <20160204172025.GQ19432@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Alan Stern [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 > > 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