[Fwd: Re: use of bus_dmamap_sync]

[Scott Long]

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