[PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
Mark A. Greer
mgreer at animalcreek.com
Tue Apr 24 16:51:05 EDT 2012
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)?
Thanks,
Mark
More information about the linux-arm-kernel
mailing list