John Baldwin wrote:
On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote:
On 10/26/05 10:39 Scott Long said the following:
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
apologies on that, scott. an initial search only turned up your message in
the archives, but spreading it wider (not confining the google to
lists.freebsd.org) brought up more hits, and that made me post it into
-hackers.
do bear with me as i try to understand this.
Below is my response. Note that I edited it slightly to fix an error
that I found
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD);
Ask hardware for data
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD);
read from readbuf (i'm assuming that device has put data in
readbuf)
POSITION B
}
in other words, the PREREAD/POSTREAD wrap around the device's access to
memory, and not the CPU's ?
Yes, scott's notes are more correct than mine here.
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE);
notify hardware of the write
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE);
The point of the syncs is to do the proper memory barrier and cache
coherency magic between the CPU and the bus as well as do the memory
copies for bounce buffers. If you are dealing with statically mapped
buffers, i.e. for an rx/tx descriptor ring, then you'll want code
however, reading thru the syscall code, bus_dmamem_alloc() sets the dmamap
to NULL, and if it's null, bus_dmamap_sync() is not called at all. would
this mean that if memory is allocated by bus_dmamem_alloc(), it does not
need to be synced with bus_dmamap_sync() ?
The value of the map is an implementation detail, which is why it's an
opaque typedef. Portable code should always assume that the map has
valid data. Now, specifically for i386, if you have a device with a
4GB address limit, and it has no data alignment constraints (unlike
twe), and you are not using PAE, then yes the map will be NULL and the
syncs will do nothing. Assuming that all three of these cases are false
is not good, though.
Perhaps on i386. Each arch implements sync(). Argh, it does look like the
memory barriers needed on e.g., Alpha aren't used with static buffers because
of the map != NULL check in sys/busdma.h. *sigh* I guess archs that need
membars even without bounce buffers need to always allocate and setup a
bus_dmamap. None of that matters for i386 though.
Feel free to fix alpha. Again, long ago, I thought that alpha pretended
to be coherent in the 2GB DMA window that we use so that it could be
more like i386. If that's not true then that's fine. If you need to
make structural changes to the MI code on order to fix alpha, please let
me know.
Scott
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
