In message: [EMAIL PROTECTED]
Mark Santcroos [EMAIL PROTECTED] writes:
: It looks like CPU_UPGRADE_HW_CACHE is only used in PC98, so it can be
: removed from all I386 specific code.
:
: Any objections to the following patch?
This does appear to be a pc98 only item. A grep of the tree shows
this to be the clase.
However, there's more opportunity here for cleanup. One can easily
move nearly all the PC98 code out of initcpu.
First, there's some redudant code:
In initcput.c we see:
static void
init_bluelightning(void)
{
u_long eflags;
#if defined(PC98) !defined(CPU_UPGRADE_HW_CACHE)
need_post_dma_flush = 1;
#endif
...
but we also see:
#if defined(PC98) !defined(CPU_UPGRADE_HW_CACHE)
...
} else if (strcmp(cpu_vendor, IBM) == 0) {
need_post_dma_flush = 1;
...
#endif
So, we set it once in init_bluelightning, and again at the tail end of
initialize cpu. So that code should be just eliminated, unless I've
missed something subtle in my analysis of the code.
In addition, one can easily add the CPU_I486_ON_386 tests to the same
code at the end of initializecpu(). In fact, it may already be there,
or there may be a bug:
#ifdef CPU_I486_ON_386
case CPU_486:
init_i486_on_386();
break;
#endif
vs
case CPU_CY486DX:
need_pre_dma_flush = 1;
#ifdef CPU_I486_ON_386
need_post_dma_flush = 1;
#endif
break;
Note that the comments say that this flushing is necessary for
non-intel hardware only, yet CPU_486 is a true intel part. At the
very least, the ifdef code in init_i486_on_386 can be eliminated,
since it appears redudant with code later on:
} else {
#ifdef CPU_I486_ON_386
need_pre_dma_flush = 1;
#endif
This makes the code fairly well contained, and it could be convered to
a function an placed somehere appropriate in pc98/pc98, maybe
pc98_machine.c? This would localize the use of the
need_{pre,post}_dma_flush variables to pc98/pc98 (well, and one
instance in dev/ct, which doesn't call the standard DMA complete
routines, but I've not investigated further). This would shrink the
size of the ifdefs down to a single one-liner...
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
