[PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
From: Santosh Shilimkar <hidden>
Date: 2011-06-24 14:47:11
Also in:
linux-omap
On 6/24/2011 7:40 AM, Premi, Sanjeev wrote:
quoted
-----Original Message----- From: Shilimkar, Santosh Sent: Friday, June 24, 2011 8:05 PM To: Premi, Sanjeev Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation On 6/24/2011 7:23 PM, Sanjeev Premi wrote:quoted
Currently, loops_per_jiffy is being calculated twice for non-SMP processors. - Before calling cpufreq_notify_transition() - From within cpufreq_notify_transition() Double adjustment leads to incorrect value being assigned to loops_per_jiffy. This manifests as incorrect BogoMIPS in "cat /proc/cpuinfo". The value of loops_per_jiffy needs to be calculated only when CONFIG_SMP is true. It is the core change included in this patch. The patch also leverages the definition of for_each_cpu() with and without CONFIG_SMP to consolidate the mechanism to call cpufreq_notify_transition(). Signed-off-by: Sanjeev Premi<redacted>NAK. This patch again doesn't make sense considering your issue. Also jiffies should not be undated before changing the freq. If the set_rate failed for some reason then you will have wrong jiffies value. I understand your issue now. The code for global lpj updation should have been checking smp_on_up() instead of is_smp(). That one line change is enough. I will post a patch on the same once I reach to office.[sp] Suggest reading the patch before NAKing. The patch is updating the loops_per_jiffy value "AFTER" the frequency change has happenned and "BEFORE" post change notification is sent.
Sure. Let me respond to you with the patch instead of making more noise on the list. Regard Santosh