[PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

[Santosh Shilimkar]

On 6/28/2011 3:53 PM, Colin Cross wrote:
> On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
> <santosh.shilimkar at ti.com <mailto:santosh.shilimkar at ti.com>> wrote:

[....]

>         Can't this rewrite the loops_per_jiffy for the other CPU while it is
>         in a udelay?  If it has already calculated the number of loops
>         necessary, and the CPU frequency increases, it could end up
>         returning
>         too early from udelay.
>
>         There were previous discussions about polling a fixed-frequency
>         timer
>         for udelay on SMP systems.
>
>     The udelay code doesn't use the per-cpu lpj variable. It uses the global
>     lpj. Secondly the calibration of no. of loops to be done is
>     precalculateed so overwrite shouldn't impact the scenario you mentioned.
>
>     Though it has an issue where, pre-calculated loops can become short/long
>     based on new clock change which impacts both CPU's on OMAP, when the
>     other CPU is in in the middle of u-delay routine..
>
>
> The precalculated loops is exactly the problem I described.  udelay(100)
> can return in 50 microseconds if the cpu speed is doubled.  On OMAP4,
> frequencies can range from 350Mhz to 1.5GHz, so udelay can be more than
> 4 times too short.  That breaks the guarantees of udelay.
>
You have a point and I agree with you on above.
And to fix that scenrio, the only option is to use hardware
timer based u-delay() which can remain constant across the
CPU freq change.

Regards,
Santosh