On 3 February 2016 at 17:27, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >> >> To me, it's the responsible of the PM domain to *help* with the >> >> synchronization, not prevent it as it currently does. >> > >> > The problem is that the hardware state gets out of sync with >> > PM runtime. And that's going to be a pain to debug later on. >> >> I don't see the problem, but of course you know omap for better than I do. > > Well there's also the long term maintenance aspect at least I > need to consider. > >> So if you are concerned about this, perhaps adding a dev_dbg print >> when the omap hwmod's ->runtime_suspend() callback returns zero could >> be a way forward? > > If we downgrade it to a debug statement or a warning, we'll soon end > up with even more driver specific warnings than we already have. > And I don't want to be chasing people around to fix their drivers > for eavery new driver that gets submitted. > > Also, without this error I would not even originally have noticed we > have a problem :) So I suggest the following: Well, I am actually not removing that existing warning in the omap_device_enable(), as it's being called from other places as well. It's just the runtime PM path that's being changed. > > 1. I'll do a series of patches to fix up the handful of omap > specific drivers with pm_runtime_use_autosuspend() that depend > on omap_device > > 2. I'll also do a patch to improve the omap_device error message > so new drivers are easy to fix. Something like: > > "%() called from invalid state %d, use pm_runtime_put_sync_suspend()?" > > Does that sounds OK to you? Sure. > > Regards, > > Tony One more thing though. I just realized that you have yet another issue to consider going for the approach fixing *only* drivers. Let me summarize it here: If userspace has prevented runtime PM (pm_runtime_forbid()) when a driver becomes unbound, the driver will not be able to suspend the device by using any of the pm_runtime_suspend() APIs, as the usage count is isn't zero. As pm_runtime_reinit() is invoked as part of the driver unbind sequence, the runtime PM status goes out of sync. A following driver rebind will then trigger the warning when the PM domain's ->runtime_resume() callback gets invoked. Again, forever preventing the device from being runtime suspended. How do you intend to solve this case? I guess there are two options, pick up the patch I posted for omap hwmod or make use of pm_runtime_force_suspend() in the driver. Kind regards Uffe -- 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
