Re: New resources - pls, explain :-(

Peter Desnoyers (pjd@fred001.dynip.com)
Mon, 16 Aug 1999 21:30:13 -0400 (EDT)


Jes Sorensen wrote:
>
> >>>>> "Peter" == Peter Desnoyers <pjd@fred001.dynip.com> writes:
>
>
> Peter> (which brings up my confusion over Linus' definition of
> Peter> "PCI-like". In prior lives I worked on 68K systems, and now
> Peter> I'm working on a PCI card that has only memory regions, not I/O
> Peter> ones, so I guess I tend to think of all I/O as memory-mapped,
> Peter> with in/out defining a weird separate address space. I have a
> Peter> hard time figuring out a definition of PCI-like that allows my
> Peter> card and PCI on an UltraSparc but excludes NuBus and SBus.)
>
> Actually it is not very hard to imagine, some busses a cache coherent,
> some are not. Some busses do not provide a linear mapping of the
> memory even when it is memory mapped, the sparse memory found in some
> Alphas is an example of this. So basically you cannot expect PCI
> shared memory to have the same access semantics as NuBus memory.

I'm still confused. PCI is cache-coherent w.r.t. DMA by the spec,
but not on UltraSparcs, and maybe not sometimes on Cyrix. It doesn't
define memory ordering - the most common platform is strictly ordered,
while others (UltraSparc, yet again) have selectable looser ordering.
The address space is sparse for non-word access on Alphas, and non-sparse
in all other cases that I know. Although it defines separate IO and
memory spaces, the IO space will be memory mapped on most platform
types. (It could be on the x86, as well, if someone insane enough made
a chipset to do it...)

As far as I can tell, SBus and NuBus are subsets of these possible
semantics. The biggest difference I can think of, compared to PCI/ISA/
MCA/EISA, is that they both have well-defined per-card config ROM specs,
and the per-slot address spaces in NuBus. (or do you mean that SBus
and NuBus have much stricter semantics, and so should not fall in the
PCI framework?)

For that matter, I don't think cache coherency affects readl/writel
semantics - it affects the sequence of actions a driver must take to
ensure that the CPU reads the correct value out of *motherboard* memory,
not over the bus. The non-endian stuff that's been kicked around in this
thread has mostly been memory ordering and barriers, not cache coherency.

-- 
............................................................................
 Peter Desnoyers 
 162 Pleasant St.         (617) 661-1979          pjd@fred.cambridge.ma.us
 Cambridge, Mass. 02139   (978) 461-0402 (work)   pjd@giga-net.com 

- 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/