On Mon, May 21, 2018 at 04:19:07PM -0600, Mahadevan, Girish wrote: > On 5/21/2018 2:23 PM, Andy Shevchenko wrote: > > On Mon, May 21, 2018 at 6:46 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> On Fri, May 18, 2018 at 10:30:07AM -0700, Tony Lindgren wrote: > >>> If pm_runtime_get_sync() fails we should call pm_runtime_put_noidle(). > >>> This is probably not a critical fix as we should only hit this when > >>> things are broken elsewhere. > >> This feels like a bug in the runtime PM APIs to be honest - I'd really > >> not expect that if a function call like a get failed there'd be any > >> cleanup to do. I'd expect a very high proportion of users to have the > >> same problem due to this. > > I don't remember the full and correct explanation, but there is a > > rationale behind such behaviour (I suppose it's related to sync/async > > agnosticism of RPM ops) > We've seen this behavior before and have had similar code to protect > against these failures before. > The pm_runtime_get_sync() fails in certain conditions (for e.g when > called during certain portions of the system suspend/resume). > AFAIK: > Since the runtime APIs internally increment the refcount then call > rpm_resume(), in case rpm_resume() fails (for e.g in case RPM is > disabled) then the driver has to either put the refcount and not go > through with the transaction OR manually move the RPM state and call the > RPM callback APIs internally. That's still really confusing and surprising, it seems like if the driver wants to manually call the callbacks there should be a specific API that it can use to get that behaviour rather than requiring every user to know that this might happen and manually handle it.
Attachment:
signature.asc
Description: PGP signature
