Hi, On 5/21/2018 2:23 PM, Andy Shevchenko wrote: > +Cc: Rafael > > 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. Best Regards Girish -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
