Re: Suspend broken on 3.3?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> Hello Govindraj
>
> 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..

So after we enter suspend and wakeup from suspend using keypad press,
now through pm workqueue the MPU enters retention and uart module level
wakeups disabled at this point console becomes slower to respond.

Now enabling wakeups from sysfs enter suspend/resume to enable wakeups
and once we come back from wakeup console response is better.

So disabling uart module level wake up and allowing MPU to enter retention
is making console slow.

--
Thanks,
Govindraj.R
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux