On Sat, 4 Feb 2012, NeilBrown wrote: > On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > > > 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. > > How does that relate to the RX_CTS_WU_EN bit which enables an interrupt on > "a falling edge of pins RX, nCTS, or nDSR" That's the bit I'm talking about :-) Maybe it might work appropriately, then, if it also tests RX. Section 19.3.2.3 "Wake-up Request" only mentions the CTS lines. Flip a coin ;-) > This seems to be a "wakeup interrupt", bit it isn't clear what it wakes us. The UART. It should send an SWAKEUP to the PRCM and bring the UART out of idle-ack. - 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
