+Govindraj, "Joe Woodward" <jw@xxxxxxxxxxxxxx> writes: > Right, I've stepped back a bit and dug out a GUSMTIX Palo43 carrier > board on which to test the Overo OMAP3530 COM and I've found: > - Running a stock 3.3 (with absolutely no changes) does indeed suspend correctly. > - Running the 3.3 kernel with my (minor) board modifications > (basically defining some buttons) suspends correctly as well. > > Then I went back to my original board and the 3.3 still wakes up from > suspend immediately. So I had a think, and the only real differences > between my board the the GUMSTIX Palo43 board is that I am using > multiple UARTs. > > Up to this point I've only wanted to wake on the console (ttyO2), and > not any other UARTs so I've stopped them waking with: > echo disabled > /sys/devices/platform/omap/omap_uart.0/power/wakeup > echo disabled > /sys/devices/platform/omap/omap_uart.1/power/wakeup > > I wanted to check that this still worked, so tried disabling wakeup on > the console (ttyO2): > echo disabled > /sys/devices/platform/omap/omap_uart.2/power/wakeup > > And if I do "echo mem > /sys/power/state" I was expecting to stay in > suspend when I typed on my keyboard... However, the kernel still woke > from suspend, which leads me to believe that the UART wakeup hasn't > been disabled? Just to confirm: did the above work for you before v3.3? > Could you test if this is also the case your end? Yes, I get the same behavior, which is indeed broken. Govindraj, can you look into this? A quick glance suggests that disabling wakeups via the sysfs file is only disabling runtime PM, but not actually disabling wakups at the module-level or at the IO ring. 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
