On Sat, 4 Feb 2012, NeilBrown wrote:

On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley [off-list ref] wrote:

quoted

On Fri, 3 Feb 2012, Paul Walmsley wrote:

quoted

On Fri, 3 Feb 2012, NeilBrown wrote:

quoted

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