One correction on this part... On Fri, 3 Feb 2012, Paul Walmsley wrote: > On Fri, 3 Feb 2012, NeilBrown wrote: > > > My theory is that there is a delay between the falling RX line waking the > > system up, and the CPU enabling the UART - whether enabling the clocks or > > doing a full config, I am not sure - though I think the former. > > > > Maybe if we could enable the UART clocks immediately after returning from the > > WFI instruction we could avoid the corruption.... > > The PRCM should be re-enabling the UART's functional clock itself, with no > kernel involvement. The sequence should go something like this > (simplified): > > 1. I/O wakeup occurs > > 2. CORE & PER powerdomains are awakened > > 3. The UART notices an event on its input lines and deasserts its idle-ack It just occurred to me that, supposedly, the only UART input line that is attached to the SWAKEUP signal is CTS. So the UART may not in fact be able to deassert its idle-ack autonomously at this point. So you might want to give your clock re-enable after WFI idea a shot! It would be interesting if it helps. I regret the oversight, - 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
