"Bedia, Vaibhav" <vaibhav.bedia@xxxxxx> writes: > On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote: [...] >> >> Also, if there are drivers for these devices, won't this interfere? >> > > Hmm, I can think of the following scenarios > > 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that > in their suspend callbacks they end up doing omap_hwmod_idle() via the > runtime PM APIs. That already happens for all omap_devices. > In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is > not necessary in the PM code. Correct. > 2. The drivers are not compiled in - In this case, the hwmod code puts > the IPs in standby during bootup so the first suspend-resume iteration > will pass. During resuming, the SYSC configuration for forced standby will > be lost, Please clarify how the SYSC is lost in this case. > so in the subsequent iterations these IPs won't go standby and the > hwmod code does not touch them since they never got enabled. In this case > we do need the sequence that is there currently. > > 3. For some reason the respective drivers don't idle the IPs during suspend - > (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think > we should abort the suspend process since we know that the suspend is not > going to work. Agreed. > Is there some other scenario that needs to be covered? You covered the ones I was thinking of. > How about adding some flag in hwmod code for handling this? Something > similar to what was done for MMC [1]. I think the problem that we have > is in some ways similar to the one addressed in [1]. Except that in the absence of drivers, no hwmod code is executed on the suspend/resume path. Kevin -- 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
