[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 03:37:47PM -0600, Paul Walmsley wrote:
> 
> 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.

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
--