On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo <t-kristo@xxxxxx> wrote: > On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote: >> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote: >> > On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo <t-kristo@xxxxxx> wrote: >> > > On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote: >> > >> Tero Kristo <t-kristo@xxxxxx> writes: >> > >> >> > >> > Attempting this will cause problems especially with off-mode enabled. >> > >> >> > >> Please be more verbose about the problems seen, and the root cause(s). >> > >> >> > > >> > > I was actually looking forward for some help with this commit message, >> > > as I am still not quite sure what is going on in here. :) Here is the >> > > log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but >> > > I think that is probably fixed by the patch from Paul, >> > > omap_set_pwrdm_state() does not work properly.) The warning comes out >> > > after wakeup from off-mode, and it is triggered by the disabling of >> > > autodeps before off-mode entry. >> > > >> > This mostly indicates that one of the per clock-domain module >> > clock turning ON seems to be not working well with auto deps >> > disabled. This leads to interconnect violation. >> > >> > if not tried already, can you put the per_clockdomain in SW_WKUP >> > in the low power code early resume path and see if this >> > error goes away. >> >> This seems to get rid of the dump also. It looks like some driver resume >> is not behaving nicely, I am trying to pinpoint the culprit currently >> and see whether it can provide more info. > > Okay, I have some more info about this now. > > What happens is that when entering off-mode, PER domain remains OFF even > during the execution of the exit phase from omap_sram_idle. Adding a > manual SW_WKUP it comes up and there are no issues. If autodeps are > enabled on the domain, it comes back from off mode as active. > > Looking further in the code, we have this at the end of omap_sram_idle: > > if (per_next_state < PWRDM_POWER_ON) { > per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm); > omap2_gpio_resume_after_idle(); > wake_per(); > if (per_prev_state == PWRDM_POWER_OFF) > omap3_per_restore_context(); > } > > ... which seems to assume that per domain is on. Gpio code does not > control any clocks currently, as it only requires the interface clock to > be on, and as this is autoidled.... > > Any comments how we should handle this? Shall we just keep these two > patches for handling this or add some different hackery for the gpio > issue? > Good. I thought too that issue will disappear. The issue is pretty clear. Technically every driver pm_runtime() code should be able to manage a clock->clockdomain->power domain power up/down sequence. That should work without auto deps. Do you narrowed down which driver resume is creating the dump ? UART , GPIO ? Regards Santosh -- 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