Subject: Re: On the subject of bus_dma(9) (fwd)
To: None <>
From: Matthew Jacob <>
List: tech-kern
Date: 03/07/2001 10:51:33
> [ 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

> 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.