In message dated Tue, 24 Sep 1996 16:14:57 -0700, Jason Thorpe writes:

>In Wolfgang's framegrabber example, maybe he could have an ioctl, say
>FGIOCMAPUBUF ... the user's pages would then be wired down, and
>DMA mapped via bus_dmamap_load()...

>Perhaps bus_dmamap_unload() should also take a proc *, unless the
>state for that is kept in the dma handle...
>
>Also, bus_dmamap_load() should probably make sure the pages are wired
>down, and bus_dmamap_unload() can unwire...

To repeat an earlier plea: can we rename  the "bus_dma_load()"
and "bus_dma_unload()" operators to be "bus_dma_bind()" and
"bus_dma_unbind()", respectively?

I find those names  more intuitive, and more neutral wrt. an
underlying implementation that may do any of:

	* Allocate  mapping registers;
	* allocate a bounce-buffer, pre-copying to the bounce-buffer
	  for DMA output and post-copying on DMA input;
	* something  else (e.g., write into a software map which refills
	  a single, double-buffered, mapping register at interrupt time;
	* Nothing at all.

I think this is orthogonal to whether the interface has an upcall hook
for a hardware-dependent function to write *board*-level registers.  

Last, and most importantly, I thought the purpose of this interface
was to provide a bus-independent, machine-independent way to write
*bus* mapping registers, not *board*-level mapping registers.  That's
a fine distinction which seems to *NOT* be being made, and I think it
absolutely needs to be, or we're tlaking past each other.

Anyone who thinks it's possible or reasonable to write
driver-level "machine-indepedent" code to handle bus-level mapping
registers has, IMHO, no place , participating in this discussion.