Tero Kristo [off-list ref] writes:

On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:

quoted

On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo [off-list ref] wrote:

quoted

On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:

quoted

On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:

quoted

On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo [off-list ref] wrote:

quoted

On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:

quoted

Tero Kristo [off-list ref] writes:

quoted

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 ?

It is the gpio base stuff called from omap_sram_idle(), basically the
restore context part. If I force enable per domain before the code
snippet before, there is no dump, but if it is done after, I get the
dump.

The thing is that gpio driver doesn't currently have this kind of
mechanism for the restore context part, at least not on omap3 due to
above clocking issue (only autoidled interface clock is used.)

I'm not sure if it fully addresses this, but Tarun's series converts
GPIO to runtime PM.

Can you try with Tarun's series.  See the for_3.4/gpio_cleanup_fixes_v9
branch here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git

Kevin