Hi Kevin / Paul, On Fri, Apr 6, 2012 at 7:51 PM, Kevin Hilman <khilman@xxxxxx> wrote: > Paul Walmsley <paul@xxxxxxxxx> writes: > >> 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. > > 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. So incase of uart wakeups are disabled and uart tx/rx is requested can we prevent MPU from low power state. -- 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
