Subject: Re: On the subject of bus_dma(9) (fwd)
To: None <firstname.lastname@example.org>
From: Matthew Jacob <email@example.com>
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
I certainly would support the last.