From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Wed, 27 Jan 2016 23:51:32 +0100 Message-ID: <1490733.Lnn2KRpEYo@vostro.rjw.lan> References: <20160126224804.GB19432@atomide.com> <2779316.34ov6YOQgv@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Return-path: Received: from v094114.home.net.pl ([79.96.170.134]:48875 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S933995AbcA0Wui (ORCPT ); Wed, 27 Jan 2016 17:50:38 -0500 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Ulf Hansson Cc: Tony Lindgren , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" On Wednesday, January 27, 2016 09:17:45 AM Ulf Hansson wrote: > On 27 January 2016 at 08:54, Rafael J. Wysocki wrote: > > On Tuesday, January 26, 2016 03:52:23 PM Tony Lindgren wrote: > >> * Rafael J. Wysocki [160126 15:38]: > >> > On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren wrote: > >> > > * Rafael J. Wysocki [160126 15:15]: > >> > >> On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren wrote: > >> > >> > Hi, > >> > >> > > >> > >> > Looks like commit 5de85b9d57ab ("PM / runtime: Re-init runtime > >> > >> > PM states at probe error and driver unbind") broke PM on at least > >> > >> > omap3. It seems we now need to additionally also call > >> > >> > pm_runtime_dont_use_autosuspend() to get things working again? > >> > >> > > >> > >> > The following fixes idling on omap3, but I'm wondering if we > >> > >> > should do something in pm_runtime_reinit() instead? > >> > >> > >> > >> Well, does it actually help if you add > >> > >> pm_runtime_dont_use_autosuspend(dev) to pm_runtime_reinit()? > >> > > > >> > > No adding it to pm_runtime_reinit() does not help. > >> > > >> > Yes, I realized that it wouldn't help only after sending the previous > >> > message, sorry about that. > >> > > >> > The reason why it helps in the driver code seems to be that > >> > autosuspend_delay happens to be negative, so update_autosuspend() > >> > decrements the usage counter that would have stayed incremented > >> > otherwise. Or at least that's the only way it can help I see ATM. > >> > >> Oh OK. > >> > >> > > Looks like we have RPM_ACTIVE set in pm_runtime_reinit() if that > >> > > gives any clues. > >> > > >> > It looks like pm_runtime_reinit() should clear the usage counter too. > >> > >> Yeah if we do this when !pm_runtime_enabled(dev) it seems it's > >> safe to pretty much reset everything? > > > > Not only safe, but also a good idea apparently. :-) > > I happy to send a patch, extending pm_runtime_reinit() with some more > data to be reset. Please do. Thanks, Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 From: rjw@rjwysocki.net (Rafael J. Wysocki) Date: Wed, 27 Jan 2016 23:51:32 +0100 Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 In-Reply-To: References: <20160126224804.GB19432@atomide.com> <2779316.34ov6YOQgv@vostro.rjw.lan> Message-ID: <1490733.Lnn2KRpEYo@vostro.rjw.lan> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday, January 27, 2016 09:17:45 AM Ulf Hansson wrote: > On 27 January 2016 at 08:54, Rafael J. Wysocki wrote: > > On Tuesday, January 26, 2016 03:52:23 PM Tony Lindgren wrote: > >> * Rafael J. Wysocki [160126 15:38]: > >> > On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren wrote: > >> > > * Rafael J. Wysocki [160126 15:15]: > >> > >> On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren wrote: > >> > >> > Hi, > >> > >> > > >> > >> > Looks like commit 5de85b9d57ab ("PM / runtime: Re-init runtime > >> > >> > PM states at probe error and driver unbind") broke PM on at least > >> > >> > omap3. It seems we now need to additionally also call > >> > >> > pm_runtime_dont_use_autosuspend() to get things working again? > >> > >> > > >> > >> > The following fixes idling on omap3, but I'm wondering if we > >> > >> > should do something in pm_runtime_reinit() instead? > >> > >> > >> > >> Well, does it actually help if you add > >> > >> pm_runtime_dont_use_autosuspend(dev) to pm_runtime_reinit()? > >> > > > >> > > No adding it to pm_runtime_reinit() does not help. > >> > > >> > Yes, I realized that it wouldn't help only after sending the previous > >> > message, sorry about that. > >> > > >> > The reason why it helps in the driver code seems to be that > >> > autosuspend_delay happens to be negative, so update_autosuspend() > >> > decrements the usage counter that would have stayed incremented > >> > otherwise. Or at least that's the only way it can help I see ATM. > >> > >> Oh OK. > >> > >> > > Looks like we have RPM_ACTIVE set in pm_runtime_reinit() if that > >> > > gives any clues. > >> > > >> > It looks like pm_runtime_reinit() should clear the usage counter too. > >> > >> Yeah if we do this when !pm_runtime_enabled(dev) it seems it's > >> safe to pretty much reset everything? > > > > Not only safe, but also a good idea apparently. :-) > > I happy to send a patch, extending pm_runtime_reinit() with some more > data to be reset. Please do. Thanks, Rafael