cgd@netbsd.org said:
> ISTR that the bit's named "cacheable" because caching is actually an
> option on the PC (and on device memory for (some, at least) TC
> alphas). 

The BUS_SPACE_MAP_CACHEABLE - it is at least wrong that the mi PCI
code translates the PCI_MAPREG_MEM_CACHEABLE bit (which should
be better called _PREFETCHABLE) into a BUS_SPACE_MAP_CACHEABLE.

Wouldn't make a difference on the alpha, but cause serious damage
on PCs. Obviously there are not many PCI devices which set this bit.

> that driver should
> be using the bus_space macros/fns and not linear mapping

OK, in the if_ti driver this might be acceptable. There in only
one place where it might be significant: Some descriptors have
to be placed into the "shared memory" in one chip version and
into host memory in another. Perhaps some indirection could be
done which still allows the linear mapping if available.
Gigabit Ethernet goes quite to the limit of bus throughput, so
every wasted cycle will degrade performance.

(One could also argue "A box before bwx is too slow for Gigabit
Ethernet anyway", but this might be a bit too extreme. I'm eg
happily using FDDI in a pmax although it can't use its
bandwidth by far...)

> As a
> short-term hack, well, hack your local kernel to allow
> non-prefetchable ("non-cacheable") mappings to use linear mapping for
> BWX.

I'd say we should really introduce a BUS_SPACE_MAP_PREFETCHABLE
flag and pass this from the PCI layer to the bus layer.
The BUS_SPACE_MAP_CACHEABLE which might turn on a CPU cache
is just too wrong.

best regards
Matthias