API change for bus_dma
Terry Lambert
tlambert2 at mindspring.com
Sat Jun 28 01:54:59 PDT 2003
John-Mark Gurney wrote:
> I'm sorry, no, this will not solve the problem he is talking about.
> You need to reread the information that Andrew has provided before.
> In a previous email you got confused on the STREAMING/COHERENT flag's
> meaning. Using contigmalloc only gives you a linear address space,
> but does not guarantee that the processor will snoop the memory write
> cycles by the bridge or device to keep the cache of the cpu the same
> with the memory. For what Andrew needs, he needs the processor to have
> the same information as in memory. On multiprocessor systems, it can
> get expensive if every processor has to snoop every memory write that
> happens.
Clearly, I don't have a deep understanding of SPARC64 SMP hardware;
given what he was saying, it still looks to me that the issue he
was attempting to address was related to whether or not the memory
in question was physically vs. logically contiguous:
<http://docs.freebsd.org/cgi/getmsg.cgi?fetch=153914+0+current/freebsd-arch>
It also still looks to me that the use of "cache coherent" in:
<http://docs.freebsd.org/cgi/getmsg.cgi?fetch=138580+0+current/freebsd-arch>
was referring to user space memory and device memory, and not the
processor cache. Reading the Solaris ddi_dma_sync(9) man page:
<http://www.FreeBSD.org/cgi/man.cgi?query=ddi_dma_sync&apropos=0&sektion=0&manpath=SunOS+5.9&format=html>
Doesn't change that impression for me (it mentions that explicitly
calling the function may result in cache flushes, but doesn't imply
snooping will occur).
There's a good programming article on "Writing Device Drivers" in
the "Sun Product Documentation" online:
<http://docs.sun.com/db/doc/802-5900/6i9kj7oq6?a=view>
That discusses this in detail, and which seems (to me) to be
authoritative.
I'd be happy to be corrected, but if you're going to correct me,
please tell me *why* I'm wrong, instead of just telling me *that*
I'm wrong, since I really *am* interested in not being wrong for
the same root cause in the future.
Thanks,
-- Terry
More information about the freebsd-arch
mailing list