On Fri, Jul 13, 2012 at 11:48:25AM +0100, Shilimkar, Santosh wrote:

Wiil,

Hi Saantosh :),

On Fri, Jul 13, 2012 at 2:27 PM, Will Deacon [off-list ref] wrote:

quoted

That should work, providing you can get a sensible initial estimate for
loops_per_jiffy.

Do you have an updated version of the patch ?

I was anticipating that the platform would set the initial loops_per_jiffy
value if it requires udelays before loop calibration and the default of 4k
is wildly off.

If people need loops_per_jiffy to be updated at the same time as lpj_fine,
I can post that as a separate patch (below) as Russell has merged v2 of these
patches into his delay branch. That said, I'd certainly like to know if this
is actually a real problem (and can't be solved by choosing a compromise value
as the initial loops_per_jiffy). I think Shinya was doing some tests so
I'll wait to see how those went.

Will

---8<---

diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index d6dacc6..395d5fb 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c

@@ -59,6 +59,7 @@ void __init init_current_timer_delay(unsigned long freq)
 {
        pr_info("Switching to timer-based delay loop\n");
        lpj_fine                        = freq / HZ;
+       loops_per_jiffy                 = lpj_fine;
        arm_delay_ops.delay             = __timer_delay;
        arm_delay_ops.const_udelay      = __timer_const_udelay;
        arm_delay_ops.udelay            = __timer_udelay;