Re: Suspend broken on 3.3?

[Kevin Hilman <khilman@ti.com>]

+Govindraj,

"Joe Woodward" <jw@terrafix.co.uk> 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