Subject: Re: On the subject of bus_dma(9) (fwd)
To: None <tech-kern@netbsd.org>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 03/07/2001 07:56:31
[ 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.

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

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. 

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.

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

Eduardo