On Wed, 4 Apr 2012, Raja, Govindraj wrote: > On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley <paul@xxxxxxxxx> 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. So in my opinion, that sysfs file should not affect dynamic module-level, or I/O ring wakeup at all. If it is intended to affect dynamic idle wakeup, then we also will need code to prevent the UART from disabling its clocks when the sysfs wakeup file is set to 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. - Paul -- 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
