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

[Shilimkar, Santosh]

On Fri, Jul 13, 2012 at 5:38 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Jul 13, 2012 at 01:04:27PM +0100, Shilimkar, Santosh wrote:
>> On Fri, Jul 13, 2012 at 4:43 PM, Will Deacon <will.deacon at arm.com> wrote:
>> > 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 is your bogomips reading and what frequency is your architected timer
> ticking at? loops_per_jiffy is updated by calibrate_delay in
> init/calibrate.c so we shouldn't need to worry about that (the diff I posted
> in my last email is just for udelay calls between switching to the timer and
> doing the calibration).
>
>> What Am I missing ?
>
> Well, your bogomips number will probably be *much* lower than before, so
> don't be surprised by that.
>
Indeed !!
This is what I observed. Can we not keep that behavior old way. BogoMIPS and
CPU clock is often very easy to co-related and helpful for CPUFREQ stats.

Regards
Santosh