patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

On Sat, 4 Feb 2012, NeilBrown wrote:

> On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley <paul at pwsan.com> 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