There are several fixes which I am committing in a bit unless I get an
objection to this note.
I won't pretend these won't break some things for people but our usage of
delay has been pretty ad-hoc in the past so here is our chance to clean
things up.
Also I've found another udelay function in src/cpu/i786, so I'll have to
see how we want to fix this. I have a simple proposal below, I don't think
it is a big deal.
First, src/lib/delay.c now only has this:
#include <delay.h>
void mdelay(int msecs)
{
int i;
for(i = 0; i < msecs; i++) {
udelay(1000);
}
}
void delay(int secs)
{
int i;
for(i = 0; i < secs; i++) {
mdelay(1000);
}
}
===
In other words, architecture-independent delay functions which assume some
sort of udelay.
The udelay you get depends on the platform.
If you want to use p5 rdtsc style delay, you would do the following in
your mainboard file:
option CONFIG_UDELAY_TSC=1
If you want old TIMER2-style delay, there is
option CONFIG_UDELAY_TIMER2
These two are mutually exclusive!
The default way to calibrate the rdtsc is via the 1,000,000 outb's to port
0x80. There is an option to configure the rdtsc delay with TIMER2.
option CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1
Now as for the i786 udelay. I would like to recommend that we finish this
job with:
option CONFIG_UDELAY_I786=1
Eric, is that ok? Then I would change src/cpu/i786/config as follows:
object delay.o CONFIG_UDELAY_I786
and all mainboard files that use the i786 udelay set set that option:
option CONFIG_UDELAY_I786=1
The added advantage is that you can test other udelay functions with a 786
CPU board.
Sound ok? Tyan Guiness now builds fine with this scheme.
Eric I just got your note re your TIMER2 calibration code for rdtsc-based
udelay. I'll try to get that in soon too unless you beat me to it
(likely). First I want to do some testing.
ron
