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

[Mark A. Greer]

On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote:
> On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote:
> > Hi
> 
> Hi Paul, Kevin.
> 
> > On Wed, 11 Apr 2012, Mark A. Greer wrote:
> > 
> > > From: "Mark A. Greer" <mgreer at animalcreek.com>
> > > 
> > > Currently, the OMAP3 cpuidle driver calls omap3_enter_idle()
> > > which calls omap_sram_idle().  omap_sram_idle() eventually
> > > causes a 'wfi' instruction to be executed effectively putting
> > > the system to sleep.  It is assumed that an I/O wake-up event
> > > will occur to wake the system up again.  This doesn't work on
> > > systems that don't support I/O wake-ups (indicated by
> > > omap3_has_io_wakeup() returning false).
> > > 
> > > To handle this, follow the same path in omap3_enter_idle()
> > > that would be followed if an interrupt were pending.
> > 
> > I don't quite understand this patch.  Are you saying that AM3517/3505 
> > can't wake from WFI?  That would seem odd.
> > 
> > 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?
> > 
> > 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.
> 
> I have changed the code to keep everything in the ON state and use
> cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything
> works well (except networking, see below) when using an mmc-based rootfs.
> 
> The issue is with the emac--it can't wake the system up unless there
> is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr).
> So, when using networking or using an nfs-based rootfs, there are all
> kinds of timeouts, etc.  Basically, doing a wfi (i.e., pm_idle or cpuidle)
> and expecting the emac to wake the system back up won't work.
> 
> How would you like me to proceed (to avoid the wfi in pm_idle & cpuidle)?

Just thinking out loud...

We could chose whether pm_idle & cpuidle issue a wfi based on
whether there is a davinci-emac present.  The issue with that is
that someday there may be another SoC that has a davinci-emac that
can wake up the system.  I know cpu_is_xxx() is frowned upon but
this does seem like a proper usage of it--the deciding factor
really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC
is enabled).

Mark
--