[PATCH v3 0/7] Add common cpuidle code for consolidation.

Kevin Hilman khilman at ti.com
Tue Jan 24 19:41:11 EST 2012


Mark Brown <broonie at opensource.wolfsonmicro.com> writes:

> On Tue, Jan 24, 2012 at 12:08:08PM -0800, Kevin Hilman wrote:
>> Robert Lee <rob.lee at linaro.org> writes:
>
>> > Besides just code consolidation, a
>> > default "WFI" state is now used with default parameters that different from your
>> > original paramenters. The assumption is that if you have a WFI only idle state,
>> > the parameters in the new default WFI are more realistic as a true WFI only
>> > hardware state incurs minimal latency(<1us) or power penalty to enter and exit.
>
>> > If your platform actually performs other platform specific functionality upon
>> > entering WFI and the default parameters do not accurately reflect the 
>> > exit_latency and target_residency given in the common default state, please
>> > say so.  
>
>> I'm not sure what you mean by "WFI only".  On OMAP, WFI is the entry
>> point for all the idle states, with varying latencies.  The latencies
>> are then dependent on how the states are programmed for the various
>> power domains.  Upon WFI, the hardware then takes over puts the
>> powerdomains to their programmed states.   
>
> The default state in the patches is set up with parameters for a state
> that literally only does the WFI and has no other hardware actions taken
> adding latencies.  I asked for this because the existing drivers for
> most of the SoCs out there currently only support that basic idle state
> and when doing something more complex (which most of the SoCs actually
> can do in hardware) it's still likely to get used during bringup of the
> feature.
>
> If there's varying levels of idle state then the SoC specific code would
> need to enumerate them and their varying latencies so that the core can
> figure out which one to enter.  This isn't a problem, it's a good thing,
> but most SoCs haven't got so far as to need it yet.

OK, makes sense now.

I see now that that default is easily overridden by platform-specific
drivers, so I don't have any problem with it.

Kevin



More information about the linux-arm-kernel mailing list