K8 developers:
I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok.
Greg
On Wed, 3 Sep 2003, Greg Watson wrote:
K8 developers:
I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok.
yes, and there is a bigger issue. putting init_timer() in hardwaremain as an explicit call breaks machines that have no timer. These do exist.
Thanks, Greg.
ron
ron minnich rminnich@lanl.gov writes:
On Wed, 3 Sep 2003, Greg Watson wrote:
K8 developers:
I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok.
yes, and there is a bigger issue. putting init_timer() in hardwaremain as an explicit call breaks machines that have no timer. These do exist.
Here is the issue.
In various places we need functions that wait a certain amount of time. And the code that needs it is not directly tied to the platform. Things like the IDE driver require it.
So we need to a source of delays, and that source potentially needs initialization. How to do that I don't know.
Putting that initialization in hardwaremain.c is obviously not perfect but we need to do something and we need not to brush the issue under the rug.
Except that everything on the k8 is in the cpu it really does not belong in cpufixup.c At least not on a general basis.
Eric
On 4 Sep 2003, Eric W. Biederman wrote:
Except that everything on the k8 is in the cpu it really does not belong in cpufixup.c At least not on a general basis.
agreed, the solution is not exactly what we want.
I really think there should be a timer device, built into the static tree.
For those platforms without timers? The best you'll get is a cpu cycle counter.
ron
-
ebiederman＠lnxi.com -
Greg Watson -
ron minnich