patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree
NeilBrown
neilb at suse.de
Fri Feb 3 17:10:48 EST 2012
On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley <paul at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120204/773388a0/attachment.sig>
More information about the linux-arm-kernel
mailing list