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 ?
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() ?
bus_dmamap_sync() only seems critical when a dma map is created with
bus_dmamap_create() and the buffer space allocated dynamically thru
contigmalloc.
well for storage devices where the load operation must succeed. It
doesn't work as well for network devices where the latency of the
indirect calls is measurable. So for that, I added
bus_dmamap_load_mbuf_sg(). It eliminates the callback function and
returns the scatter gather list directly. So, the above example would
be:
i'm basically trying to debug a problem with a driver which works like a
charm on freebsd 5.x, but somehow doesnt on freebsd 4.x. the source for the
driver is /exactly/ the same on both systems. the symptoms i keep seeing
are that the same data which is written out is also read in by the read
routines, which is what made me suspect that somewhere the dma transfers
were not happenning and stumbled upon this.
for each buffer. It's often better to pre-allocate the maps at init
time, put them on a list, and then just push and pop them off the list
i do this, for each buffer, at init time.
int *readbuf
bus_dma_tag_create()
bus_dmamem_alloc()
bus_dmamap_load()
int *writebuf
bus_dma_tag_create()
bus_dmamem_alloc()
bus_dmamap_load()
subsequently, the device interrupts once every ms (1000Hz) and the buffers
are read/written to. in the interrupt handler, i currently have,
bus_dmamap_sync(POSTREAD)
read data from readbuf (readval = readbuf)
write data to writebuf (writebuf = someval)
bus_dmamap_sync(PREWRITE)
i've left out PREREAD and POSTWRITE as both seem to be no ops in freebsd
4.x. this seems consistent with your explanation. is this correct ?
--
Regards, /\_/\ "All dogs go to heaven."
[EMAIL PROTECTED] (0 0) http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |
+=========================================================================+
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
