"Mark A. Greer" <mgr...@animalcreek.com> writes:

> On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote:
>> "Mark A. Greer" <mgr...@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)

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to