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

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley <paul@pwsan.com> wrote:

> One correction on this part...
> 
> 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"

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]