"Raja, Govindraj" <govindraj.raja@xxxxxx> writes: > Hi Kevin, > > On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman <khilman@xxxxxx> wrote: >> Paul Walmsley <paul@xxxxxxxxx> writes: >> >> [...] >> >>> I don't understand why a user would ever want to disable dynamic wakeups >>> on an in-use serial port via the sysfs power/wakeup file. (Disabling >>> wakeups from suspend is a different matter, of course.) The OMAP UART >>> driver needs hardware wakeups to function for FIFO drain wakeups, etc. >>> So to me it really doesn't make sense to disable those types of wakeup >>> events, ever. But maybe you know of some use-case that I don't? >> >> No, I don't have a use-case in mind. >> >> The more I try to remember why we added support to use the sysfs wakeup >> attribute to manage idle, the more I think we can probably drop it now. >> IIRC, it was added because on most boards we used to blindly initialize >> all the UARTs, including default wakeup settings (we still do this on >> many boards.) >> >> However, now that we have a real PM-aware driver for OMAP UARTs, this >> should all be handled from the driver itself, so the sysfs wakeup >> attribute should go back to only managing wakeups from suspend and >> wakeups during idle should always be on for in-use UARTs. > > Just to summarize on how the behavior should be IIUC if user disables uart > wakeup from sysfs and does system wide suspend it should _not_ wakeup > from uart. Correct. > And if the system is woken up from suspend due to keypad press and > uart resumes we have keep module level wakeup enabled from here. Keypad press, or any other wakeup source, yes. Basically, UART wakeups (module and IO) should be enabled all the time, *except* when suspending and wakeups were disabled by sysfs control. > We might need some minor changes in omap-serial to have this behavior > which I plan to do once we are aligned on this. Sure, this changes previous behavior based on assumptions that are no longer true (namely, UARTs only disabled in idle path), so I would expect some changes. Kevin -- 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
