Co-ordinate the frequency decision on multiple cores

Status:
In Progress

[LDS cpuidle session 2/11/2010]
 * when adding some cpu freq devices, you can choose to use the same policy or governor for several cores. The .related_cpus and .cpus fields of the cpufreq_policy struct are used to set this relation.
 * We need to check the feature of Arm Soc (STE, Orion and OMAP platform)
 * Task becomes one of verification
Verified this on OMAP4 and confirmed that same policy can be applied on multiple cores so that both the cores scale together.
Verified the multicore cpu scaling on samsung platform for both ondemand and conservative governor.
The new sysfs interface of the ondemand/conservative governor provides the userspace tunables like sampling_rate,
io_is_busy, up_threshold, sampling_down_factor, ignore_nice and powersave_bias as global parameters.
Therefore, the governor and its parameters remains same for all the cores in the system. The old sysfs interface which places these tunables for each cpu core is deprecated.
Some platforms like the V310(orion) have the requirement that both the cores should be scaled up/down
together, so a single governor thread runs periodically at the sampling interval.
However other SOC's like omap and u8500 have a governor thread running for each cpu core.

Work Items for 2011-01-01:
[vincent-guittot] How is multi-core cpufreq handled today: DONE
[vishwanath-bs] Check multi-core behaviour on OMAP: DONE
[amitdanielk] Check multi-core behaviour on Orion: DONE
[vincent-guittot] Check multi-core behaviour on ST-E: DONE
[vincent-guittot] What would an arch-specific governor gain us?: DONE
[amitdanielk] Verified that the global parameters exported by ondemand governor new sysfs interface has same effect on all cpu cores: DONE