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@xxxxxxxxxxxxxxx> > > > > > > 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 -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
