Govindraj <govindraj.ti@xxxxxxxxx> writes: [...] >> >> So here's an experiment to try with autosuspend. ÂI suspect this will >> work, just hack it up to prove the concept. ÂIf it works, we can make >> something more generic. ÂHere are a few alternatives to try. ÂI may >> experiment with some of them tomorrow as well, but please let me know >> what you try: >> >> Using autosuspend, clocks will get cut independently of the idle path. >> Then, use the PRCM ISR detection of UART module wakeups to call the >> UART's interrupt handler. ÂThe interrupt handler will pm_runtime_get(), >> enable the clocks, and then take care of the interrupt. ÂDone. >> >> Alternatively, you could test it on current code by simply removing the >> resume_from_idle call from the idle path and calling it instead from the >> PRCM ISR when UART module wakeups are detected. > > I remember doing similar experiment didn't seem to help, > To show it's possible, I did really hacky proof of concept, hard-coded to UART3 console for n900/beagle, but at least it shows that this approach can work, and the module-level wakeups are working and can be used as the trigger for UART wakeup instead of resume_from_idle. Of course, it still has problems with using serial after non-UART wakeups, but once omap-serial is using runtime PM, that will no longer be an issue. My hacky branch is called pm-wip/uart-wkup and is in my pm git tree[1] (based at the pm-core branch) To test module-level wakeups (instead of IO-ring) I again forced CORE to stay on during suspend, and tested wakeup from suspend on 3430/n900: echo 3 > /debug/pm_debug/core_pwrdm/suspend echo mem > /sys/power/state Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git -- 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
