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: Tue, 26 Jan 2016 15:52:23 -0800 Message-ID: <20160126235222.GF19432@atomide.com> References: <20160126224804.GB19432@atomide.com> <20160126232212.GE19432@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:57808 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbcAZXwZ (ORCPT ); Tue, 26 Jan 2016 18:52:25 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: "Rafael J. Wysocki" Cc: Ulf Hansson , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" * 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? Regards, Tony