On Wed, Feb 3, 2016 at 11:25 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> >> I don't see the problem, but of course you know omap for better than I do. >> >> So if you are concerned about this, perhaps adding a dev_dbg print >> when the omap hwmod's ->runtime_suspend() callback returns zero could > > /s/runtime_suspend/runtime_resume OK Let me summarize my understanding of this thread so far. It looks like the omap3 code initializes hardware in ->probe() and then it may return -EPROBE_DEFER due to some unmet dependencies. In that case the hardware is not reset to the previous state and the runtime PM framework is left in the state that corresponds to the current hardware state. Before we had pm_runtime_reinit(), everything worked as expected on the second ->probe() call, because things were in sync then. The introduction of pm_runtime_reinit() changed the situation and now effectively the hardware is required to be reset to the initial state if -EPROBE_DEFER is to be returned too. Is that correct? Thanks, Rafael -- 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
