On 27 January 2016 at 08:54, Rafael J. Wysocki [off-list ref] wrote:

On Tuesday, January 26, 2016 03:52:23 PM Tony Lindgren wrote:

quoted

* Rafael J. Wysocki [off-list ref] [160126 15:38]:

quoted

On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren [off-list ref] wrote:

quoted

* Rafael J. Wysocki [off-list ref] [160126 15:15]:

quoted

On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren [off-list ref] wrote:

quoted

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.

quoted

quoted

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.

Or, you or Tony intend to send a patch?

Kind regards
Uffe