On Saturday 24 September 2011 09:26 AM, DebBarma, Tarun Kanti wrote: > [...] >> After debugging this myself a bit, here's what I think may be going on. >> This may not be the only problem but here's at least one of them. >> >> First, debounce clocks are disabled in the runtime_suspend callback. >> >> When a GPIO is freed and it's the last one in the bank, bank->mod_usage >> goes to zero. >> >> After that, pm_runtime_put_sync() is called, which will trigger the >> driver's ->runtime_suspend callback. The ->runtime_suspend() callback >> checks bank->mod_usage as well, and if zero, doesn't do anything >> (notably, it doesn't disable debounce clocks.) > I need some clarification in reproducing/testing the fix on OMAP3430SDP. > The first thing I am trying to verify is the code flow of suspend. > > 1) With no debounce clock enabled, when I enable UART timeouts, I > automatically see > system going to retention. That is I don't have to type echo mem > > /sys/power/state > echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout > > 2) I am do not see the print in omap_gpio_suspend/resume(), but I see > the print in > *_prepare_for_idle()/*_resume_after_idle(). > Hmmm, This is mostly happening because you are missing a below fix from Kevin in the branch you are testing with. http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg54927.html {OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers} If you rebase, your branch against 3.1-rc6, you should already have this fix. Commit {126caf1376e7} 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
