On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: > > 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. 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. 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. > 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. > 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. > So this change doesn't seem quite right to me... > > More broadly, if AM3517/3505 only supports powerdomains ON, then you > should probably use your own CPUIdle driver that doesn't touch the > powerdomain states at all. Okay, I can do that. 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
