On Wed, Feb 3, 2016 at 5:24 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 3 February 2016 at 17:09, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [160203 07:46]: >>> On Wed, 3 Feb 2016, Ulf Hansson wrote: >>> >>> > > 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. >>> > >>> > Correct! >> >> Well not quite correct. After failed probe PM runtime is set to reset >> state while hardware is still enabled. > > Yes, but that's *after* pm_runtime_reinit() was added. > > I think Rafael was thinking about how it worked *before*. Right. 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
