From: NeilBrown [mailto:neilb at suse.de]
Sent: Friday, February 03, 2012 8:31 PM

So... if flow control is available, then when we idle the uart we should
set <snip> ...

Yes I think you can improve situation with such tricks.

Unfortunately there are a few types of low-power idle wakeups which muddy the water when trying to understand TRMs.

- The IOpad type wakes are the ones being discussed now. These are used in conjunction with isolation rings which stop external signals from propagating into chip and causing undefined things. This protection is used to enable OFF mode (but can be armed outside of from 34xx+ and beyond). The wakeup event here travels through pins to wakeup domain then to prcm which reactivates subdomains and signals can then reflow (if there are still valid). You get IOpad status which can map to function.

- A shade of idle up is module idle wakes. Here if the isolation latch is not enabled you need to program omap-ocp&ip wake-function wrappers in uart itself. Here the wake signal comes through pads to uart-ip then it signals prcm to reflow signals.

- A wakeup which no one seems to use above this is the 16x50 UART has some internal sleep/wake features. The generic linux driver might know these but they are rarely used.
 

quoted

Outside of debug console, this loss has not been huge. Protocols like

irda would retransmit their magic wake packets. You can move between DMA
and interrupt modes with activity. So far there has been a work around per
attached device.

What about bluetooth?  HCI/UART doesn't seem to have a lot of error
handling.  Maybe it has enough though.
(I have bluetooth on UART1 ... of course we might not have the same
problems
on UART1 .. I haven't played with bluetooth much yet).

I heard of solutions but don't recall as I personally didn't donate blood to get them working. I recall some activity timer + wake packets but would have to dig up old PPTs.

Regards,
Richard W.