On Fri, 3 Feb 2012 14:42:09 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> 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:
signature.asc
Description: PGP signature
