Date: Wed, 26 Oct 2005 16:47:10 +0800 From: Dinesh Nair <dinesh@alphaque.com> To: Scott Long <scottl@samsco.org> Cc: hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] Message-ID: <435F428E.50609@alphaque.com> In-Reply-To: <435EEC56.9080708@samsco.org> References: <435EEC56.9080708@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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." dinesh@alphaque.com (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 | +=========================================================================+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?435F428E.50609>