Messages in this thread |  | | Date | Fri, 25 Aug 2000 12:57:09 +0100 | From | Philipp Rumpf <> | Subject | Re: Exporting calibrate_delay() |
| |
On Fri, Aug 25, 2000 at 12:57:59AM +0200, Erik Mouw wrote: > Alan Cox wrote: > > > Is there a specific reason why calibrate_delay() (in init/main.c) > > > needs to be an __init function? I need to recalibrate the delay > > > loop for a CPU that supports multiple clock speeds (the Intel > > > StrongARM SA1100), so I'd rather use this code instead of > > > replicating it. > > > > Do you actually need to rerun the entire loop, and for that matter if so > > have you checked all the code paths running while you are recalibrating dont > > use udelay ? > > The idea is to have a different value for loops_per_sec for all > (read: 12) clock speeds. I want to calculate the values when the > driver loads so I can just plug in a new value for loops_per_sec > at a clock speed change. If I disable all interrupts while > recalibrating it shouldn't hurt udelay, right?
The way calibrate_delay is currently written it won't work unless the timer interrupt is there and behaves as expected. It's also terribly slow (depending on HZ and your final BogoMIPS value it takes ages) and unnecessary in most cases since we know the cycle counter frequency (ARM doesn't use cycle counters currently).
What I'm wondering is why you don't keep bogomips constant and have extra code in delay.S to adjust for the (known ?) clock speed degradation; the other option is to use any known constant-frequency clock in the system (you can use the PIT on i386), as long as accessing it doesn't take away bus bandwidth from other CPUs on SMP or DMA transfers.
> > If you know the CPU clock ratio when power saving you can just do the maths > > directly > > How correct is that? More specifically: how sensitive are the other > drivers for slightly incorrect values of loops_per_sec?
It is unlikely you'll end up with significantly higher errors than calibrate_delay introduced in the first place - it's only 8 bits of precision.
Philipp Rumpf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |