Subject: Re: Machine-independent bus DMA interface proposal
To: Jason Thorpe <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 09/24/1996 17:04:46
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
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.