[PATCH 07/15] ARM: cpuidle: add init/exit routine

[Amit Kucheria]

On Tue, Mar 26, 2013 at 12:50 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On 03/25/2013 08:09 PM, Andrew Lunn wrote:
>>>> Please could you add a comment in the code about which piece is
>>>> specific to ARM, because its not obvious to me. Its not like there is
>>>> a reference to WFI for example. It looks like this code could go in
>>>> drivers/cpuidle/cpuidle.c
>>>
>>> Yes, I agree. At the first glance, the code, as it is, could go in this
>>> file but more ARM specific code will be moved to this ARM generic code
>>> driver like device tree description and couple idle states. The init
>>> function would be more arch specific then.
>>
>> Hi Daniel
>>
>> There was a discussion about device tree bindings when i posted
>> the kirkwood cpuidle driver, now in drivers/cpuidle/cpuidle-kirkwood.c.
>>
>> The conclusion was that pseudo devices, like cpuidle, do not have DT
>> bindings. They can check of_machine_is_compatible(), like
>> cpuidle-calxeda.c does, or they are platform drivers, which is what
>> cpuidle-kirkwood.c is.
>>
>> Even if DT binding was allowed, it again should not be ARM specific.
>
> If the DT binding was allowed, I *may* not be ARM specific but will
> certainly used only by the ARM drivers as the x86 platform uses ACPI or
> static tables.
>
>> Are coupled idle states ARM specific?
>
> Well the code is not arch specific but today the idle coupling is ARM
> specific because it is the only arch using this kind of synchronization.
> There is also a last man standing algorithm common to ux500 and imx
> (maybe exynos soon) I would like to merge into this ARM driver.

Nico has developed a last man standing algorithm[1] for big.LITTLE
TC2. That too needs to be considered during this consolidation. While
it was developed for multi-cluster configurations, I don't see what it
shouldn't work here too.

[1] http://lwn.net/Articles/539082/