Messages in this thread | | | From | Russell King <> | Subject | Re: Exporting calibrate_delay() | Date | Fri, 25 Aug 2000 18:25:51 +0100 (BST) |
| |
Philipp Rumpf writes: > cases since we know the cycle counter frequency (ARM doesn't use cycle counters > currently).
ARM doesn't have cycle counters; such a thing would be up to the hardware external to the core. Don't forget ARM is RISC, and the cores are designed primearily for embedding. With such things, you don't want to add neadless hardware that some application in 1000 may want to use, so cycle counters get excluded (no one has had a requirement for these).
> 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.
The former involves extra run-time instructions which, if you can do the calculation, why end up doing it multiple times? It makes much more sense to modify the "loops_per_sec" once per change of clock speed (see below).
The latter adds in yet another platform dependency that I just don't want to think about (we're up to about 16 unique hardware types, covering some 34 platforms). Maybe we ought to follow Linus' recent advice on this mailing list and have arch/arm-footbridge arch/arm-sa1100 and so forth?
No, I'd prefer to keep the things that can reasonably be kept generic without too much pain generic, and for that you can adjust the "loops_per_sec" (or a derived variable that udelay can use) to compensate for clock speed variations.
After all, if you know you've halved the clock speed, you have to double loops_per_sec. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk@arm.linux.org.uk --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | - 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/
| |