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

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

On 6/28/2011 4:00 PM, Santosh Shilimkar wrote:
> On 6/28/2011 3:53 PM, Colin Cross wrote:
>> On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com <mailto:santosh.shilimkar@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.
>
Or block CPUFREQ change when any CPU which is in udelay() is done with
it, which will be stupid to do :-)

Regards
Santosh