On Fri, Sep 23, 2011 at 2:37 AM, Kevin Hilman <[email protected]> wrote:
> From: Russell King <[email protected]>
>
> On OMAP SMP configuartion, both processors share the voltage
> and clock. So both CPUs needs to be scaled together and hence
> needs software co-ordination.
>
> Also, update lpj with reference value to avoid progressive error.
>
> Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
> them with with reference to the initial values to avoid a
> progressively bigger and bigger error in the value over time.
>
> While at this, re-use the notifiers for UP/SMP since on UP machine or
> UP_ON_SMP policy->cpus mask would contain only the boot CPU.
>
> Based on initial SMP support by Santosh Shilimkar.
>
> Signed-off-by: Russell King <[email protected]>
> Signed-off-by: Santosh Shilimkar <[email protected]>
> [[email protected]: due to overlap/rework, combined original Santosh patch
> and Russell's rework]
> Signed-off-by: Kevin Hilman <[email protected]>
> ---
> drivers/cpufreq/omap-cpufreq.c | 80
> +++++++++++++++++++++++++++++++++++-----
> 1 files changed, 70 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
> + /*
> + * On OMAP SMP configuartion, both processors share the voltage
> + * and clock. So both CPUs needs to be scaled together and hence
> + * needs software co-ordination. Use cpufreq affected_cpus
> + * interface to handle this scenario. Additional is_smp() check
> + * is to keep SMP_ON_UP build working.
> + */
> + if (is_smp()) {
> + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> + cpumask_or(cpumask, cpumask_of(policy->cpu), cpumask);
> + cpumask_copy(policy->cpus, cpumask);
> + }
Does somebody remember importance of is_smp() here??
Current code looks like:
if (is_smp())
cpumask_setall(policy->cpus);
And I was looking to remove this check if it is no more useful.. And
so simply do
cpumask_setall(policy->cpus);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
