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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST