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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/28/2011 4:03 PM, Russell King - ARM Linux wrote:
On Tue, Jun 28, 2011 at 03:45:22PM -0700, Santosh Shilimkar wrote:
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..

And there's also the issue where you can start a udelay loop on one CPU,
be pre-empted and end up running it on a different CPU running at a
different speed.

Indeed.

The thing to bear in mind is that udelays are approximate at best - I did
some investigation into the accuracy of the loops_per_jiffy calculation,
and it _will_ produce shorter delays than expected by the fact that
what is being calibrated is the udelay() loop _plus_ the timer interrupt
overhead.
>
Sure but as Colin pointed out 4 times shorter delay will be too much.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux