On 3 February 2016 at 13:18, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > 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. Correct! Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER) worked fine because the HW state and the runtime PM status was in sync. The device was powered and the runtime PM status was RPM_ACTIVE. > > 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. Not correct. The hardware doesn't need a reset as it stays powered after a failed probe. Instead, only the runtime PM status needs to be synchronized with the HW state the next probe attempt. In other words, when the PM domain's ->runtime_resume() callbacks gets called due to a pm_runtime_get_sync() in the second probe attempt, it may find that the HW is already powered and can return zero instead of resetting it. 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
