[PATCH v2 2/2] ARM: delay: allow timer-based delay implementation to be selected

[Shilimkar, Santosh]

On Fri, Jul 13, 2012 at 4:43 PM, Will Deacon <will.deacon at arm.com> wrote:
> 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 <will.deacon at arm.com> wrote:
>> > 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.
>
I just tried the suggested change + two patches.
I haven't gone through the complete discussion but quick test of your patches
on OMAP5, shows me, the BOGOMIPS is completely wrong. Looks like
you are not updating the  'loops_per_jiffy' in the calibration loop.

What Am I missing ?

Regards
santosh