On Fri, Jul 23, 2004 at 03:34:13PM -0700, Jason Thorpe wrote:
> 
> On Jul 23, 2004, at 1:38 PM, David Young wrote:
> 
> >On Fri, Jul 23, 2004 at 05:19:23PM +0200, Manuel Bouyer wrote:
> >>
> >>bus_dmamem_alloc(9) says:
> >>            The mapping of this memory is machine-dependent (or 
> >>"opaque");
> >>	    machine-independent code is not to assume that the addresses
> >>	    returned are valid in kernel virtual address space, or that the
> >>	    addresses returned are system physical addresses.  The address
> >>
> >>To me, this means that we can't make any assumptions about the values 
> >>returned
> >>by bus_dmamem_alloc(), and especially it's wrong to assume we can do
> >>memory-related operations on ds_addr/ds_len.
> >
> >Network drivers don't copy ds_addr into transmit/receive descriptors?
> >How does this work if they are not "system physical addresses" ?
> 
> System physical addresses != DMA addresses.  At least, on many 
> platforms this is the case.
> 
> The whole idea is that bus_dmamem_alloc() returns addresses that are 
> opaque to the driver.  The driver MUST use bus_dmamap_load*() in order 
> to translate an address to one valid for use in DMA.

Hmm....  I see what you're saying, but I have misgivings about the way
it is worded....

Seems like there are kernel virtual addresses, CPU physical addresses,
DMA physical addresses, and DMA opaque addresses.  None of these are
the same.  bus_dmamap_load*() converts from the DMA opaque addresses to
DMA physical addresses.  I think the docs should be explicit (or clearer)
on this point.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933