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

Mark A. Greer mgreer at animalcreek.com
Mon Apr 30 18:18:59 EDT 2012


On Mon, Apr 30, 2012 at 03:00:56PM -0700, Kevin Hilman wrote:
> "Mark A. Greer" <mgreer at animalcreek.com> writes:
> 
> > On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote:
> >> "Mark A. Greer" <mgreer at animalcreek.com> writes:
> >> 
> >> > On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote:
> >
> >> > 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).
> >> 
> >> The presence of the davinci_emac is probably overkill, avoiding WFI
> >> should really only be done when the davinci_emac is *active*.
> >> e.g. using an am35x with an EMAC *present*, but not in use because
> >> there's an MMC rootfs for example.
> >> 
> >> If there's a good way to detect an in-use davinci_emac, then
> >> disable_hlt() can be used to avoid WFI.  When the davinci_emac is not in
> >> use (e.g. module unloaded etc.) then enable_hlt() can be used to
> >> (re)allow WFI.
> >
> > This can work for pm_idle but what should be done for cpu_idle
> > (as in, omap3_enter_idle[_bm])?  We should have some sort of
> > solution for that so users can safely enable CONFIG_CPU_IDLE
> > and not have the am3517 fall apart.
> 
> disable_hlt() will prevent either the default idle *or* CPUidle from
> being called.
> 
> It will simply call cpu_relax() instead of calling any idle
> function. (c.f. cpu_idle() in arch/arm/kernel/process.c)

Yep, you're right.  Sorry.

Mark



More information about the linux-arm-kernel mailing list