[Fwd: Re: use of bus_dmamap_sync]

[Dinesh Nair]

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 at 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                                                              |
+=========================================================================+