On 5/11/2011 6:11 AM, Menon, Nishanth wrote:
On Mon, Mar 14, 2011 at 06:38, Santosh Shilimkar
<santosh.shilimkar@xxxxxx> wrote:
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.
Signed-off-by: Santosh Shilimkar<santosh.shilimkar@xxxxxx>
Cc: Kevin Hilman<khilman@xxxxxx>
cc: Vishwanath BS<vishwanath.bs@xxxxxx>
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 73 ++++++++++++++++++++++++++-----
1 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c
[...]
rate = clk_get_rate(mpu_clk) / 1000;
@@ -74,9 +76,13 @@ static int omap_target(struct cpufreq_policy *policy,
[...]
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+#ifdef CONFIG_SMP
+ /*
+ * Note that loops_per_jiffy is not updated on SMP systems in
+ * cpufreq driver. So, update the per-CPU loops_per_jiffy value
+ * on frequency transition. We need to update all dependent CPUs.
+ */
+ for_each_cpu(i, policy->cpus)
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
+ freqs.old, freqs.new);
We have an issue here - arch/arm/lib/delay.S uses the generic
loops_per_jiffy which is not updated when smp (OMAP4) is active, as a
result loops_per_jiffy contains the value which was updated. with a
trace added as follows:
[...]
Question: what would be the best solution for this? is a solution
isolated to OMAP good enough?
We have debated on the global lpj update topic enough. The assumption
of all the CPU's in ARM SMP system are running at same speed in not
I propose this idea based on the fact that on OMAP we scale
all the CPU's in SMP clusture together. But that is not seems
to be true for all ARM SMP archs.
So there is a patch series which makes udelay() independent
of lpj and make use a timer.
Here is the link for the same.
http://eeek.borgchat.net/lists/arm-kernel/msg120702.html
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
