[PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work

[Mark A. Greer]

On Wed, Apr 11, 2012 at 04:47:31PM -0600, Paul Walmsley wrote:
> cc Govindraj
> 
> On Wed, 11 Apr 2012, Mark A. Greer wrote:
> 
> > On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote:
> >
> > > I don't quite understand this patch.  Are you saying that AM3517/3505 
> > > can't wake from WFI?  That would seem odd.
> > 
> > No, I'm saying that I/O doesn't seem to wake it up from the WFI.
> > I've learned to not trust the am35x TRM much so I'm pretty much
> > feeling my way along in the dark.
> 
> Hehe, no worries, just curious.
> 
> > I do know that without this patch, the system is extremely slow which I 
> > believe is from it only returning from the WFI because of a timer 
> > expiration or something like that.
> 
> How are you trying to wake it up -- from an incoming character via 
> the UART?
> 
> Does the system pause in the middle of UART transmits, or does it get the 
> transmit buffers out cleanly and just not respond promptly to incoming 
> characters?

Both cpu_idle/pm_idle thread (arch/arm/kernel/process.c:cpu_idle()) and
the cpu idle driver (arch/arm/mach-omap2/cpuidle34xx.c:omap3_enter_idle())
behave the same without the 2 patches I posted.  During boot, things
become extremely sluggish.  I took that to mean that the WFI wasn't being
woken up unless a timer expired.  I also believed that not having I/O
wake-ups would cause that so I made those patches.

There don't appear to be any missing or additional characters from the UART.
This is all during the boot-up so I'm not even trying to enter characters
via the UART.  That's all I did for "testing", if you can call it that.

For the emif4, etc. patches, I would do a suspend-to-RAM and hit a key
on the keyboard to wake it up again.  There are no dropped or added
characters in the [serial] console output.  It does complain that the
expected state wasn't entered (INACTIVE) and by looking at
/sys/kernel/debug/pm_debug/count, the CORE domain is the only one that
didn't increment its "INA" count.

> > > There are other sources of wakeup on the system other than I/O wakeup.  
> > > I/O wakeup only applies to wakeups from the I/O pads when the chip is in 
> > > RETENTION or OFF.  And as I understand it, neither of those apply to 
> > > AM3517/3505?
> > 
> > Hmm, its true that RETENTION and OFF aren't supported.  It does wake up
> > occasionally (as mentioned above) it just seems that I/O doesn't wake
> > it up.  I may be mistaken.  I'm only going from what I've seen since and
> > the TRM seems to have lots of errors so I'm not sure what to trust in it.
> 
> OK no problem, just trying to understand what's going on.  Sounds like 
> you've gotten tossed into the deep end :-)

:)

> > > Even if I/O wakeups aren't supported, many of the IP blocks on the system 
> > > should be able to cause the ARM to exit WFI by asserting their 
> > > SWAKEUP lines and raising their interrupt lines.
> > 
> > Okay, but that doesn't seem to be working.  I'll look some more to see
> > why they aren't working.
> 
> There could be a hidden dependency on I/O wakeup being present in the UART 
> driver. We've been going through some UART driver angst recently...

OK.

Mark
--