<snip>--<snip> > >>> Hi Kevin, > >>> > >>> I was able to test against the HEAD 'pm' branch on the EVM. > >>> Here are my observations with default configuration: > >>> > >>> 1) CONFIG_DEBUG_LL=y is set by default. The kernel boots fine. > >>> I did not notice any 'garbage' problems you and Koen seem to > >>> be getting. > >>> > >>> 2) Same result when CONFIG_DEBUG_LL is deselcted. > >> Sanjeev, > >> > >> Is this on an an ES3 EVM? What boot loader revs are you using? > > > > [sp] I am using EVM with ES3.0 while Vaibhav is using one with ES2.1 > > What are your x-loader and u-boot versions? Mine are: > > Texas Instruments X-Loader 1.41 > [...] > U-Boot 1.1.4 (Jun 5 2008 - 17:53:37) > > > >>> 3) With default config, suspend operation fails with this message: > >>> <3>omapfb omapfb: timeout waiting for FRAME DONE > >> This is not a failure, just a warning from the fb driver. > >> This should not prevent retention. I see this on beagle > as well, and > >> it doesn't prevent retention. > >> > >> From the log below, you didn't copy the part which > reports whether > >> all domains hit target state. > > > > [sp] This is where it hangs :( > > It's not hung. It's just sleeping, but refuses to wakeup [sp] True. > (like I should've done this morning.) [sp] me too! > > What are you using as your wakeup source? UART? keypad? [sp] I try using both (after a reboot). Also tried the kernel image without FB driver. But observations don't change. Checking further, with: # echo 1 > /sys/power/sleep_while_idle Suspend / resume 'appear' to work fine with these warnings: Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 However, after: # echo 1 > /sys/power/clocks_off_while_idle Observation is same as mentioned in prev mail. Best regards, Sanjeev > > I'm not sure how the UARTs are mux'd on this board, but you > probably want to check the wake-enable bits in the padconf > reg for the UART pins. > This is done by arch/arm/mach-omap2/serial.c but assumes > the UARTs are mux'd using the default registers. Each UART > has a couple possible ways to be mux'd. > > > After sending the last mail, I tried the same without > enabling "clocks_off_while_idle" and "sleep_while_idle" then: > > > > omapfb omapfb: timeout waiting for FRAME DONE Powerdomain > (core_pwrdm) > > didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter > > target state 1 Could not enter target state in pm_suspend > > > > I am building a config without FB. Will update as soon as I > can test it. > > > >> Kevin > >> > >>> Here is a sample session from my terminal: > >>> > >>> [root@OMAP3EVM /]# uname -a > >>> Linux OMAP3EVM 2.6.28-omap1-00115-g998bd56 #146 Thu Jan > 15 18:47:26 > >>> IST 2009 armv7l unknown [root@OMAP3EVM /]# echo 1 > > >>> /sys/power/clocks_off_while_idle [root@OMAP3EVM /]# echo 1 > > >>> /sys/power/sleep_while_idle [root@OMAP3EVM /]# > >> [root@OMAP3EVM /]# echo > >>> mem > /sys/power/state > >>> <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > >>> done. > >>> Freezing user space processes ... Freezing user space > >> processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. > >>> done. > >>> Freezing remaining freezable tasks ... Freezing remaining > >> freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 > >> seconds) done.done. > >>> Suspending console(s) (use no_console_suspend to debug) Suspending > >>> console(s) (use no_console_suspend to debug) > >>> > >>> Best regards, > >>> Sanjeev > >>> <snip>--<snip>-- 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
