Hello Deepthi,
On Wed, Feb 29, 2012 at 10:15 PM, Deepthi Dharwar deepthi@linux.vnet.ibm.com wrote:
Hi Rob,
On 03/01/2012 06:12 AM, Robert Lee wrote:
Make necessary changes to implement time keeping and irq enabling in the core cpuidle code. This will allow the removal of these functionalities from various platform cpuidle implementations whose timekeeping and irq enabling follows the form in this common code.
The generic cpuidle changes look good, but is there a reason as to why these changes are enabled only for ARM and not other archs ?
Besides ARM, this patchset also enables some of this new consolidation functionality on arch/SH and for archs that use the CONFIG_ARCH_HAS_CPU_RELAX (maybe x86 uses this?).
For the powerpc P-series, it could probably could be modified to use the consolidated timekeeping but I didn't feel comfortable making that change myself for a couple of reasons. First, the common wrapper also includes the local_irq_enable() call, but the p-series cpuidle code doesn't include this call, as instead, it relies on the local_irq_enable() call in the cpu_idle() function in arch/powerpc/kernel/idle.c. Is it OK to remove this local_irq_enable() once the wrapper is used? Second, is there any special coordination needed with the timekeeping functions and the mfspr() calls?
Looking at the intel and acpi cpuidle implementations, their current organization does seem to be able to use the common time keeping / irq enabling wrapper. Upon first glance, it appears that there are special timer/timekeeping requirements for x86 that aren't required by other platforms. But that may not be correct.
If you look back at v4 of this patch series, you'll see an attempt at a common timekeeping that could be used by x86 and acpi , but it causes other compromises that to me aren't worth the extra gain from a 100% common timekeeping / irq enable solution. I requested feedback/opinions on this issue after v4 but didn't hear anything about changes made to the intel or acpi implementations. So I continued on with the common wrapper direction from v3 when making v5.
Ultimately, even if the consolidated code only can be used by most and not all arch or platform cpuidle implementations, it still reduces some platform cpuidle fragmentation and duplicated code and hopefully improves the maintainability of the core cpuidle.