> On Fri, 5 Mar 1999, Alan Cox wrote:
>
> OK, finally I am enlightened (by Alan and others). The story is that
> there is no portable solution for IO memory acces in current Linux. It is
> platform dependent in a non-trivial way:
> > > On Fri, 5 Mar 1999, Alan Cox wrote:
> > There really isnt an easy one
> >
> > ARM - no cache coherency
No cache coherency leads to heavily broken drivers and thus O/Ses and
requires some complexity we probably want to avoid, at least I do.
Great stupidity, in my opinion.
> > Alpha - offset PCI mapping. PCI I/O space is mapped in strange ways
> > varies by platform
Paranoia of CPU optimisation for only having to deal with 32 bits and 64
bits. Since MMIO is only usable with some flush of CPU buffers, designers
could allow 8 bits and 16 bits quantities for MMIO without addressing
weirdnesses and without complexifying CPU optimization stuff. IMO,
architects were not quite aware of how a usable IO sub-system for PCI
should be.
> > PMac - PCI bus is endian swapped in hardware
This is pretty useless and highly stupid, IMO for the following reasons:
1 - This only can speed-up a bit IOs from the CPU and the PCI BUS is slow
compared to CPU. Having some instructions that deal with endian-ness
does suffice.
2 - The right way to do IOs with PCI is to DMA from the device and
certainly not to stall the CPU and to use small bursts or no
bursts at all.
Still guys who should have learnt how IOs must be handled.
> > x86 - Sane (well its the reference bus)
> > Sparc64 - Basically sane - again PCI I/O space is mapped as memory
This one has also some design weirdness regarding PCI.
It seems that only Intel has been able to provide a reasonnable PCI
BUS implementation. But, on the other hand, they donnot seem to be
capable to provide real CPUs (I mean 64 bit) in time. ;-)
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/