On Tue, Mar 26, 2013 at 12:50 AM, Daniel Lezcano daniel.lezcano@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.