Re: Suspend broken on 3.3?

[Kevin Hilman <khilman@ti.com>]

Paul Walmsley <paul@pwsan.com> writes:

> On Wed, 4 Apr 2012, Raja, Govindraj wrote:
>
>> On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Mon, 2 Apr 2012, Raja, Govindraj wrote:
>> >
>> >> As of now what I can think of is to update qos reqest to prevent MPU
>> >> from transitioning in case of port activity if wakeup capability for port
>> >> is disabled.
>> >
>> > Haven't been following this thread closely, but this doesn't seem right.
>> > Why would changing the UART driver's ability to wake from suspend via the
>> > sysfs file prevent the driver from using hardware wakeups to wake from
>> > dynamic idle?
>> 
>> 
>> IIUC wakeup capability is needed in suspend path or in cpu idle path.
>> 
>> once uart wakeup capability is disabled from sysfs the Module level 
>> wakeup from PM_WKEN1 reg on omap3 and pad wakeup from pin mux data given 
>> will be disabled..
>
> As far as I know, that sysfs wakeup file is not meant to disable 
> all module-level wakeup.  Kevin can correct me if I'm wrong, but I think
> it's only supposed to control wakeup from suspend.

In theory, sysfs control is meant for static suspend.  ISTR though that
we were using it for idle as well so there weren't unncessary UART
wakeups from idle on UART activity that was not serial console.

Kevin