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

One correction on this part...

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"

This seems to be a "wakeup interrupt", bit it isn't clear what it wakes us.

So you might want to give your clock re-enable after WFI idea a shot!  It 
would be interesting if it helps.

Might be a bit beyond me at the moment :-(

Thanks,
NeilBrown

I regret the oversight, 


- Paul