> 
> [ Eduardo said he sent a response on this subject to the list, but I didn't
>   see it nor is it in the archives, so I'm taking the liberty of forwarding a
>   slightly trimmed version ]
> 
> ...
> 
> 	As I said- *I* don't care which one of either. I just want it to be
> 	clearer. Hopefully Eduardo can weigh in and we can come to closure on
> 	this and move on.
> 
> O.K.  You asked for it.
> 
> 1) The man page does not say any of this.  You could argue that
> it is documented in the bus_dma* paper, but very few people ever
> read that.  So the man page should describe the interface 
> unambiguously, which it doesn't.
> 
> 2) A hint to how to map memory in to the CPU does not handle
> mapping the memory into the dma engine.

That's correct- or there's an assumption that COHERENT means for both CPU and
Device at the same time. In  which case the peer-peer DMA case can't work
because you need to map things into CPU's virtual address space to give the
COHERENT hint.

> 
> 3) The assumption that bus_dmamap_sync() will always work
> with no other support needed is flawed.

'flawed' is possibly too strong a word- and I don't think now that this is
what was intended. What apparently has been intended is that if
bus_dmamap_sync doesn't work, you should use bounce buffers. I think we hope
to avoid that.

> 
> 4) The example for the use of bus_dmamap_load_raw() and
> bus_dmamem_mmap() demonstrates how the interface is broken.
> If the memory needs to be mapped into the dma engine
> coherently, by the time bus_dmamem_mmap() is called, 
> it is much too late to map it in coherently. 

Well, yes. I'm *really* confused by how the description of bus_dmamap_load_raw
got into the man page. It's just plain different from what Jason says this
interface should be.

> 
> 5) If you change the definition of bus_dmamem_alloc()
> so it does imply that the memory is DMA coherent, you also
> need a method to allocate streaming dma memory if you will
> use streaming access instead.

I think documenting this as:

	If you want to allocate memory that can be mapped without
	the BUS_DMA_COHERENT, use malloc(9) and perform the usual
	bus_dma_map and bus_dma_load functions. Note that you may
	not be able to, in all cases, create a completely byte-coherent
	view of this memory whilst it is mapped for device and CPU
	access at the same time.

> 
> So, maybe we should be passing the BUS_DMA_COHERENT flag
> in to bus_dmamem_alloc() instead of bus_dmamem_map() or
> bus_dmamap_load().

I certainly would support the last.

-matt