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@xxxxxx <mailto:santosh.shilimkar@xxxxxx>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
